On 2024-04-21, motk <meh@meh.meh> wrote:
> On 20/04/2024 7:44 am, John Dallman wrote:
>
>> That's an extremely sweeping statement. I'm working for a very large and
>> paranoid corporation. I wouldn't try using X11 across the internet, but
>> for working with a lot of different Linuxes, macOS and Solaris in a
>> secured development lab, it is truly excellent, and nobody is trying to
>> stop me.
>
> I'd love that sort of gig myself, but everywhere I've been for the past
> twenty years would have conniptions if I asked to open firewall holes
> for X, or to add stuff to /etc/skel for xhosts, or to add selinux
> policy, etc etc.
>

If anyone is doing anything with xhost for X11 these days, they are doing
it _very_ wrong. :-) The only acceptable way to run X11 remotely is over
ssh (and that is with "ssh -X" and not "ssh -Y").

>> It lets me have editors and terminal windows on lots of different Linuxes
>> without needing to deal with their different GUIs and desktop
>> environments. As far as I can see, Wayland doesn't offer that unless you
>> slap on a remote desktop protocol. I actively don't want remote desktop:
>> it is not useful to me, it will suck bandwidth, and it gives me much,
>> much more setup to do.
>
> Wayland is not X. It was never designed to do that, and I've personally
> berated Keith et al about that decision. RDP pretty much exploded and
> all interest in replicated X in that way vanished, but there is yet
> hope, ie https://gitlab.freedesktop.org/mstoeckl/waypipe/
>

When running in a lower-bandwidth situation, what are the bandwidth
requirements with the above approach, versus running the X11 protocol
directly over ssh ?

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.

Dan Cross <cross@spitfire.i.gajendra.net> wrote:
>
>Sendmail.cf was hardly typical of most Unix configuration files,
>but surely you already know that. Indeed, I think one could
>make a strong argument that sendmail's design, not to mention
>its configuration, wasn't very Unix-y at all. At this point, I
>imagine that Eric would agree.

This is true although the extensive use of regexps and rewrite rules is
very Unixlike.

Sendmail was a thing that started out clean and small and accreted more and
more crap as time went by, until it got to the point where it just was not
really much good anymore. And then it got replaced (for the most part) by
more modular and maintainable systems.

>But a fair counter argument to the "but it's not Unix!" cries is
>that Unix lacked a robust configuration language that was
>ubiquitous across systems and packages. That was a bit of a
>shame, but perhaps inevitable: some programs had very domain
>specific requirements for configuration that would be difficult
>to express in a generic configuration language (lookin' at you,
>sendmail). Surely any given universal language would either be
>insufficient to express the full generality required for all
>use cases, or it would be too baroque for simple, common cases.

This is true, although with JSON things are changing a bit.

>Anyway. I can get behind the idea that modern service
>management is essential for server operation. But it doesn't
>follow that the expression of that concept in systemd is a great
>example of how to do it.

IF you believe this, and I am not sure that I do, then it seems to me
that the Solaris approach is far, far better than the systemd approach.
Certainly a good argument can be made for service management and there are
certainly some systems where it is a good idea, but that does not mean
that systemd is a good idea.
--scott
--
"C'est un Nagra. C'est suisse, et tres, tres precis."

Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> wrote:
>On 2024-04-21, motk <meh@meh.meh> wrote:
>> Wayland is not X. It was never designed to do that, and I've personally
>> berated Keith et al about that decision. RDP pretty much exploded and
>> all interest in replicated X in that way vanished, but there is yet
>> hope, ie https://gitlab.freedesktop.org/mstoeckl/waypipe/
>
>When running in a lower-bandwidth situation, what are the bandwidth
>requirements with the above approach, versus running the X11 protocol
>directly over ssh ?

rdp is a little bit faster than remote X11 but it's still really awful
if there is any channel latency. FastX, which is a proprietary solution
but an excellent one, is definitely a win.

Neither x11 nor rdp were ever intended for cross-country use.
--scott

--
"C'est un Nagra. C'est suisse, et tres, tres precis."

In article <v05mjt$ugqt$5@dont-email.me>,
Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> wrote:
>On 2024-04-21, Grant Taylor <gtaylor@tnetconsulting.net> wrote:
>> On 4/21/24 04:20, Andreas Eder wrote:
>>> I think the problem is that they grew up in a Windows dominated world,
>>> not like us greybeards.
>>
>> I really would like to agree. However we have some 20 year old
>> developers that have been using Linux their entire life making these
>> types of questionable decisions.
>>
>> I think it's more apt to say that they have grown up with frameworks
>> that abstract things away from them and they have no idea how the
>> underlying infrastructure works.
>
>I would hope that this generation of programmers still knows some of
>the basics and (for example) still knows what a device or CPU register is...

Some do, many do not.

In defense of the kids, there's a lot more computer science to
learn these days than there was $x$ many years ago, and the same
amount of time to teach it to them in a standard 4 year degree
course. It's a balancing act fitting it all in.

That said, some of the greybeards have no idea (and I mean none
whatsoever) of how modern systems _actually_ work under the hood
themselves. Those in glass houses....

- Dan C.

In article <v05omg$cnu$1@panix2.panix.com>,
Scott Dorsey <kludge@panix.com> wrote:
>Dan Cross <cross@spitfire.i.gajendra.net> wrote:
>>
>>Sendmail.cf was hardly typical of most Unix configuration files,
>>but surely you already know that. Indeed, I think one could
>>make a strong argument that sendmail's design, not to mention
>>its configuration, wasn't very Unix-y at all. At this point, I
>>imagine that Eric would agree.
>
>This is true although the extensive use of regexps and rewrite rules is
>very Unixlike.

Is it? Did sendmail really make much use of regular expressions
for example? The production rules are related, but dissimilar.
The closest seems like the state-driven tokenization code in the
address parser, but I don't think it actually implements
generalized regular expressions. Perhaps it would have been
cleaner if it had.

>Sendmail was a thing that started out clean and small and accreted more and
>more crap as time went by, until it got to the point where it just was not
>really much good anymore. And then it got replaced (for the most part) by
>more modular and maintainable systems.

Yup. The problem got harder and harder, too.

>>But a fair counter argument to the "but it's not Unix!" cries is
>>that Unix lacked a robust configuration language that was
>>ubiquitous across systems and packages. That was a bit of a
>>shame, but perhaps inevitable: some programs had very domain
>>specific requirements for configuration that would be difficult
>>to express in a generic configuration language (lookin' at you,
>>sendmail). Surely any given universal language would either be
>>insufficient to express the full generality required for all
>>use cases, or it would be too baroque for simple, common cases.
>
>This is true, although with JSON things are changing a bit.

Eh, JSON has its own problems; since the representation of
numbers is specified to be compatible with floats, it's possible
to lose data by translating it through JSON (I've seen people
put e.g. machine addresses in JSON and then be surprised when
the low bits disappear: floating point representations are not
exact over the range of 64-bit integers!).

>>Anyway. I can get behind the idea that modern service
>>management is essential for server operation. But it doesn't
>>follow that the expression of that concept in systemd is a great
>>example of how to do it.
>
>IF you believe this, and I am not sure that I do, then it seems to me
>that the Solaris approach is far, far better than the systemd approach.
>Certainly a good argument can be made for service management and there are
>certainly some systems where it is a good idea, but that does not mean
>that systemd is a good idea.

100%. I'd prefer something like Solaris's SMF to systemd,
though hopefully with something nicer than XML for configuration
files.

- Dan C.

In article <v05lmo$ugqt$3@dont-email.me>,
Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> wrote:
>On 2024-04-20, Arne Vajh�j <arne@vajhoej.dk> wrote:
>> On 4/20/2024 11:40 AM, Grant Taylor wrote:
>>> On 4/20/24 07:32, bill wrote:
>>>> Nothing wrong with DECTerm.� But there was a lot more you could do
>>>> with DECWindows.� Worked great back when I had labs of X-terminals to
>>>> support both VMS and SunOS for the students (and yes, faculty liked
>>>> it, too.)
>>>
>>> I think that X11's ability to work across platforms is something that's
>>> unmet by any other protocol that I'm aware of.
>>>
>>> GUI applications could run on their native / optimal platform and
>>> display on whatever platform the user wanted to use.
>>>
>>> No, I don't consider web based interfaces to be comparable.
>>
>> Cool feature.
>>
>> But how many does really need it?
>>
>
>Everyone who needs to run a GUI application on an embedded Linux box
>or everyone who needs to run a GUI application on various Linux servers
>from the comfort of your own desk and workstation.
>
>Even at home, I routinely use this capability.
>
>Also note that the GUI application could be anything, including a debugger.

I do wonder how many people actually need this. Indeed, one
sometimes wonders if a shell is even really necessary for pure
server applications. I suppose that when one needs it, one
really needs it.

- Dan C.

Dan Cross <cross@spitfire.i.gajendra.net> wrote:
>
>That said, some of the greybeards have no idea (and I mean none
>whatsoever) of how modern systems _actually_ work under the hood
>themselves. Those in glass houses....

I am certainly in that category and believe me it absolutely terrifies me.
It terrifies me even more that when I ask people how things work inside,
nobody else seems to know either!

What worries me is that we have a generation of people who don't really care.
Or maybe more than one generation.
--scott

--
"C'est un Nagra. C'est suisse, et tres, tres precis."

On 4/22/2024 11:16 AM, Scott Dorsey wrote:
> Dan Cross <cross@spitfire.i.gajendra.net> wrote:
>>
>> That said, some of the greybeards have no idea (and I mean none
>> whatsoever) of how modern systems _actually_ work under the hood
>> themselves. Those in glass houses....
>
> I am certainly in that category and believe me it absolutely terrifies me.
> It terrifies me even more that when I ask people how things work inside,
> nobody else seems to know either!
>
> What worries me is that we have a generation of people who don't really care.
> Or maybe more than one generation.
> --scott
>
>

Well, sometimes they SHOULD care ...

A while back, an employee at a customer site, when attempting to discuss
security, the employee said "my boss doesn't care about security". Ok, no sense
continuing discussion.

Time passes, and as it happens, site gets hit with ransomware. Not the VMS
system, the WEENDOZE PCs. Cost them maybe $100K to get over that. Makes one
wonder if boss now cares about security.

--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: davef@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486

In article <v05v0g$4sr$1@panix2.panix.com>,
Scott Dorsey <kludge@panix.com> wrote:
>Dan Cross <cross@spitfire.i.gajendra.net> wrote:
>>
>>That said, some of the greybeards have no idea (and I mean none
>>whatsoever) of how modern systems _actually_ work under the hood
>>themselves. Those in glass houses....
>
>I am certainly in that category and believe me it absolutely terrifies me.
>It terrifies me even more that when I ask people how things work inside,
>nobody else seems to know either!
>
>What worries me is that we have a generation of people who don't really care.
>Or maybe more than one generation.

It's not even that people don't care, it's that the entire thing
is so ridiculously complex that it's beyond the understanding of
a single person, and much of it is hidden from the OS, buried
under layers of firmware blobs running on hidden cores outside
of the visibility, let alone control, of an operating system.

Consider IO buses; these days, the dominant high-end peripheral
interconnect is PCIe, which uses a serial protocol over
differential pairs for signalling at the electrical layer. But
that protocol is complex, and it runs at absurd speeds; small
variations in trace length matter. To even begin to use it, the
link pairs must be "trained" to work out timing parameters for
signalling. How does THAT happen? It turns out, a hidden core
with a serious DSP usually does it for you. How do you debug
that? Long gone are the days of attaching some probes to a few
test points and seeing what the hell the bus is doing, let alone
understanding what this random IP inside the SoC complex is
doing. Sometimes the system vendors don't even know; they got
the IP (and its firmware) from a third party themselves.

Just booting a system is ridiculous. Most of it is punted to
vendor code running inside of UEFI or the BIOS or whatever.
Most of that is inscruitable.

- Dan C.

On Sun, 21 Apr 2024 23:09:20 +0000, Lawrence D'Oliveiro wrote:

> On Sun, 21 Apr 2024 11:16:07 +0200, Andreas Eder wrote:
>
>> On So 21 Apr 2024 at 02:08, Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
>>
>>> Why is it the Linux distros are able to maintain a common kernel, but
>>> the BSDs are not? Aren’t the BSD kernels flexible enough for such
>>> different uses? Which aren’t even that different, compared to how
>>> distinct the various Linux distros can be?
>>
>> Because they do not want to! They have different objectives and they
>> are really different projects. Not at all comparable to Linux
>> distributions.
>
> And yet the range of variety they are able to offer, with their
> fragmented kernels, is only a small fraction of what Linux distros have
> achieved, with their unified kernel base.

You just carry on with your crusade.

On 4/22/24 07:53, Simon Clubley wrote:
> I would hope that this generation of programmers still knows some
> of the basics and (for example) still knows what a device or CPU
> register is...

I would not bet on it. Much less hold my breath.

--
Grant. . . .

On 4/22/24 13:50, Dan Cross wrote:
> It's not even that people don't care, it's that the entire thing is so
> ridiculously complex that it's beyond the understanding of a single
> person, and much of it is hidden from the OS, buried under layers
> of firmware blobs running on hidden cores outside of the visibility,
> let alone control, of an operating system.

There is some truth to the complexity.

But you can't have anyone, or even a team of people, effectively
understand if their bosses don't care and won't give them time to learn
how things work.

There is way too much apathy going around.

--
Grant. . . .

On 4/21/24 21:37, Dan Cross wrote:
> Sendmail.cf was hardly typical of most Unix configuration files,

I'll argue that sendmail.cf or sendmail.mc aren't as much configuration
files as they are source code for a domain specific language used to
impart configuration on the sendmail binary. In some ways it's closer
to modifying a Makefile / header file for a program than a more typical
configuration file.

> You may have a point, but to suggest that anyone who objects to systemd
> doesn't "have an argument" or is reactionarily change averse is going
> too far. There are valid arguments against systemd, in particular.

Agreed.

> I'll concede that modern Unix systems (including Linux systems), that
> work in terms of services, need a robust service management subsystem.

For the sake of discussion, please explain why traditional SysV init
scripts aren't a service management subsystem / facility / etc.

> If one takes a step back and thinks about what such a service
> management framework actually has to do, a few things pop out: managing
> the processes that implement the service, including possibly running
> commands both before the "main" process starts and possibly after
> it ends. It must manage dependencies between services; arguably it
> should manage the resources assigned to services.

I feel like the pre / post commands should not be part of the system
management ${PICK_YOUR_TERM}. Instead there should be a command (script
or binary) that can be called to start / stop / restart / etc. a service
and that it is the responsibility of that command (...) to run the pre
and / or post commands related to the actual primary program executable.

I feel like the traditional SysV / /etc/init.d scripts did the pre and /
or post commands fairly well.

What the SysV init system didn't do is manage dependencies. Instead
that dependency management was offloaded to the system administrator.

> So this suggests that it should expose some way to express
> inter-service dependencies, presumably with some sort of
> human-maintainable representation; it must support some sort of
> inter-service scheduling to satisfy those dependencies; and it
> must work with the operating system to enforce resource management
> constraints.

I'm okay with that in spirit. But I'm not okay with what I've witnessed
execution of this. I've seen a service restart, when a HUP would
suffice, cause multiple other things stop and restart because of the
dependency configuration.

Yes, things like a web server and an email server probably really do
need networking. But that doesn't mean that they need the primary
Ethernet interface to be up/up. The loopback / localhost and other
Ethernet interfaces are probably more than sufficient to keep the
servers happy while I re-configure the primary Ethernet interface.

> But what else should it do? Does it necessarily need to handle
> logging, or network interface management, or provide name or time
> services? Probably not.

I think almost certainly not. Or more specifically I think that -- what
I colloquially call -- an init system should keep it's bits off name
resolution and network interface management.

> SMF didn't do all of that (it did sort of support logging, but not
> the rest), and that was fine.

The only bits of logging that I've seen in association with SMF was
logging of SMF's processing of starting / stopping / etc. services. The
rest of the logging was handled by the standard system logging daemon.

> And is it enough? I would argue not really, and this is really the
> issue with the big monolithic approach that something like systemd
> takes. What does it mean for each and every service to be "up"?
> Is systemd able to express that sufficiently richly in all cases?
> How does one express the sorts of probes that would be used to test,
> anyway?

I would argue that this is a status / ping operation that a venerable
init script should provide and manage.

If the system management framework wants to periodically call the init
script to check the status of the process, fine. Let the service's init
script manage what tests are done and how to do them. The service's
init script almost certainly knows more about the service than a generic
init / service lifecycle manager thing.

I feel like there are many layering violations in the pursuit of service
lifecycle manager.

Here's a thought, have a separate system that does monitoring / health
checks of things and have it report it's findings and possibly try to
restart the unhealthy service using the init / SMF / etc. system in the
event that is necessary.

Multiple sub-systems should work in concert with each other. No single
subsystem should try to do multiple subsystems jobs.

> The counter that things like NTP can drag in big dependencies that
> aren't needed (for something that's arguably table stakes, like
> time) feels valid, but that's more of an indictment of the upstream
> NTP projects, rather than justification for building it all into
> a monolith.

+10

> Anyway. I can get behind the idea that modern service management
> is essential for server operation. But it doesn't follow that the
> expression of that concept in systemd is a great example of how to
> do it.

+1

--
Grant. . . .

On 4/22/24 08:10, Simon Clubley wrote:
> If anyone is doing anything with xhost for X11 these days, they are
> doing it _very_ wrong. :-)

I agree with that.

> The only acceptable way to run X11 remotely is over ssh (and that is
> with "ssh -X" and not "ssh -Y").

I don't agree with that.

I don't need to use ssh to run between two systems in my home or over a
cross over cable.

xauth (in a trusted LAN) works sufficiently well, is native to
contemporary X, and doesn't incur the ssh overhead.

> When running in a lower-bandwidth situation, what are the bandwidth
> requirements with the above approach, versus running the X11 protocol
> directly over ssh ?

I've found that X11 is one of the fatter remote GUI protocols. RDP and
VNC tend to be lighter.

But, RDP and VNC tend to imply a full desktop whereas X easily has
programs from different hosts display as windows on a single X server.

There are some hacks to emulate this with RDP and VNC, but they are not
native and not reliable.

--
Grant. . . .

On 4/22/24 19:05, Grant Taylor wrote:
> I've found that X11 is one of the fatter remote GUI protocols.  RDP and
> VNC tend to be lighter.
>
> But, RDP and VNC tend to imply a full desktop whereas X easily has
> programs from different hosts display as windows on a single X server.
>
> There are some hacks to emulate this with RDP and VNC, but they are not
> native and not reliable.

I believe that X11 has something going for it that RDP and VNC can't
touch. That's the ability to do X11 over protocols other than IP, e.g.
DECnet. Something that some in this newsgroup may have an affinity for.
}:-)

--
Grant. . . .

On 23/4/24 01:16, Scott Dorsey wrote:

> What worries me is that we have a generation of people who don't really care.
> Or maybe more than one generation.

That's ubiquitous computing for you. There's enough complexity in
scale-out and edge systems now that knowing TTL or assembler or whatever
is just a distraction. You're not paid to know that, your job is to make
sure the bank or whatever can keep running.

> --scott

--
motk

On 23/4/24 09:05, Grant Taylor wrote:

> There is way too much apathy going around.

Perhaps, but there's also the matter of finite time and actual desired
outcomes.

--
motk

On 23/4/24 09:53, Grant Taylor wrote:

> For the sake of discussion, please explain why traditional SysV init
> scripts aren't a service management subsystem / facility / etc.

[tears out remaining hair, goes bald, wife divorces me]

Can the greybeards please stop sooking about it not being 1999 anymore
please. Once upon a time, knowing inscrutable regex and gluing stuff
together with sed and awk make you a sage superhero. Now people look at
you funny for gluing in tech debt, and they are right to do so.

--
motk

On 22/4/24 22:44, Simon Clubley wrote:

> Quantity does not equal quality. :-)

I dunno, I'm not unintelligent but have you seen how much stress a
browser engine has to endure? Thousands of people with phds smash these
things to bits on the regular. Hundreds of thousands of people use
electron/react/whatever apps every day and never notice. Grousing about
this isn't a good look anymore.

> Simon.

--
motk

On 22/4/24 23:10, Simon Clubley wrote:

> If anyone is doing anything with xhost for X11 these days, they are doing
> it _very_ wrong. :-) The only acceptable way to run X11 remotely is over
> ssh (and that is with "ssh -X" and not "ssh -Y").

Of course, but you'd think some of the respondents here have barely let
go of telnet.

> When running in a lower-bandwidth situation, what are the bandwidth
> requirements with the above approach, versus running the X11 protocol
> directly over ssh ?

X11 is famously insanely chattery and requires a fast, jitter free link.
Try running it on a machine overseas - yes, you can finagle things but
it's still awful due to the core design of X. The network design that X
expects no longer exists for the most part.

waypipe works fine AFAICT, no worse than RDP.

> Simon.

--
motk

On 22/4/24 22:28, Simon Clubley wrote:
> On 2024-04-19, motk <yep@yep.yep> wrote:
>>
>> Because it's _broken_. ssh x11 forwarding has been deliberately broken
>> by _design_ for a _decade_, if you're found using X11 in a corporate
>> environemt you will get an earnest conversation with people with no
>> sense of humour, the world is real and here and now.

> In what way has it been deliberately broken (and in which versions of
> software) ?

The expectations that -X requires no longer exist by default, for a
start. The complete lack of interest in keeping it working.

> BTW, to anyone using X11 over ssh, it is a standard recommendation to use
> "ssh -X" instead of "ssh -Y" so that additional security restrictions
> are active. See the ssh man page for details.

-Y exists because people complained that -X was too restrictive IMR.

> Simon.

--
motk

On 4/22/24 19:13, motk wrote:
> Can the greybeards please stop sooking about it not being 1999 anymore
> please. Once upon a time, knowing inscrutable regex and gluing stuff
> together with sed and awk make you a sage superhero. Now people look at
> you funny for gluing in tech debt, and they are right to do so.

That's a non-answer.

I was hoping to see a ${SERVICE_MANAGEMENT_THING} provides:

- this
- this
- that
- and this
- don't forget about that

Type answer.

I hear people say that systemd and smf are service management things and
that traditional SysV style init scripts aren't. But they never explain
why the former is and the latter isn't.

I was genuinely trying to learn something.

--
Grant. . . .

On 4/22/24 19:13, motk wrote:
> Once upon a time, knowing inscrutable regex and gluing stuff together
> with sed and awk make you a sage superhero.

I'm not advocating for using regex / sed / awk as part of init systems.

There are places for those. I think that an init system is the
antithesis of it.

IMHO an init system; whatever it's name is, and most of a Unix / VMS
system should be as boring as the day is long. Boring has low technical
debt, easy to teach, easy to maintain, easy to change.

--
Grant. . . .

On 4/22/24 19:15, motk wrote:
> I dunno, I'm not unintelligent but have you seen how much stress a
> browser engine has to endure? Thousands of people with phds smash these
> things to bits on the regular. Hundreds of thousands of people use
> electron/react/whatever apps every day and never notice. Grousing about
> this isn't a good look anymore.

How much more productive work is done with a contemporary web browser in
2024 than in 2004 or even in 1998 (save for encryption)?

How much more productive work are computers doing in general in 2024
than in 1994?

Have the frameworks and fancy things that are done in 2024 actually
improved things?

I feel like there is massively disproportionately more computation power
/ resources consumed for very questionable things with not much to show
for it. Think what could have been done in the mid '90s with today's
computing resources.

As such, I believe that there is some room for grousing about many
questionable practices today.

--
Grant. . . .

Grant Taylor <gtaylor@tnetconsulting.net> wrote:
>
>I hear people say that systemd and smf are service management things and
>that traditional SysV style init scripts aren't. But they never explain
>why the former is and the latter isn't.

The one thing that smf and systemd have is the ability to watch a process
and restart it if it crashes. Many people find this very important, although
personally I suspect that if your service is crashing a lot that you should
fix it rather than rely on something else to restart it.

Something else that they do provide is automated management of dependencies
to start everything in order without the admin having to manually set the
order of execution up. This can be a benefit and if done well can also speed
boot times, but I am not sure that this is necessary to call a startup
mechanism a service manager.

>I was genuinely trying to learn something.

This is not likely to be a thread in which anyone will learn much, I am sorry
to say.
--scott
--
"C'est un Nagra. C'est suisse, et tres, tres precis."