You downloaded the software at their last two releases, and have kept that same public key in your keyring each time. Or your friends or colleagues can vouch for having trusted a particular public key in the past. Either way, you keep notes documenting the fingerprint of the identity which signs every release.
That's a lie. There must be a half dozen providers for high-speed Internet service where I live, in podunk Spokane, WA (pop. 205,500).
Okay, is it a truly free market? No, usually a lot of the private infrastructure is paid for in taxes, which is certainly not free. But there sure as hell are options (2+) in most mid-sized cities and higher. Don't forget about wireless and third-party DSL providers.
Go is designed with internal messaging capabilities, intended to simplify the creation of applications running on different nodes, and improve their performance.
"It's a way to try to address how to write concurrent software that's more robust, as opposed to using the old threading model of Java and others," Voss said.
...
In this regard, Go offers "a new programming paradigm" that makes it easier to solve a wide variety of programming problems by simplifying many types of parallel processing.
No, Go doesn't bring anything new to the concurrency table. The two things I've seen about Go concurrency that are regarded as special are M:N/"green" threads and CSP-style channels.
M:N threading is an implementation detail of a language runtime. Whereas the standard library of a language might specify how threads are available to client applications (programs written in the language), it's best left to the implementation (runtime or compiler) to decide how to translate those threads onto the machine. Some implementations might want to focus on scalable, high-performance threading, and so they'd choose M:N. Some others might emphasize simplicity, and map language threads directly to OS threads. What Go has done is standardized this implementation detail into the language specification. (I don't think that's a good idea, but that's a matter of taste.) Other language implementations offer M:N threading, including GHC and (I think) Erlang.
On channels: they're cool. I love them. But there's a lot of prior art here, and many languages have great CSP-style channel libraries written for them that offer the same great flavor of relatively safe message passing and alternation between sets of channels:
A: Nope. Sorry. Nobody needs files in Phantom. All the operating system state is saved across shutdowns. Phantom is the only global persistent OS in the world, AFAIK. All the state of all the objects is saved. Even power failure is not a problem, because of the unique Phantom's ability to store frequently its complete state on the disk.
To illustrate the utility and awesomeness of persistence, there's a famous story about KeyKOS, an earlier OS that embraced this notion:
At the 1990 uniforum vendor exhibition, key logic, inc. found that their booth was next to the novell booth. Novell, it seems, had been bragging in their advertisements about their recovery speed. Being basically neighborly folks, the key logic team suggested the following friendly challenge to the novell exhibitionists: let's both pull the plugs, and see who is up and running first.
Now one thing Novell is not is stupid. They refused.
Somehow, the story of the challenge got around the exhibition floor, and a crowd assembled. Perhaps it was gremlins. Never eager to pass up an opportunity, the keykos staff happily spent the next hour kicking their plug out of the wall. Each time, the system would come back within 30 seconds (15 of which were spent in the bios prom, which was embarassing, but not really key logic's fault). Each time key logic did this, more of the audience would give novell a dubious look.
Eventually, the novell folks couldn't take it anymore, and gritting their teeth they carefully turned the power off on their machine, hoping that nothing would go wrong. As you might expect, the machine successfully stopped running. Very reliable.
Having successfully stopped their machine, novell crossed their fingers and turned the machine back on. 40 minutes later, they were still checking their file systems. Not a single useful program had been started.
Figuring they probably had made their point, and not wanting to cause undeserved embarassment, the keykos folks stopped pulling the plug after five or six recoveries.
The notion of a language-based OS exploiting the semantics of pointerless/"safe" programming languages in order to isolate processes, rather than the norm of executing untrusted native machine code in different address spaces, is nothing new either.
If these ideas shift your bits, take a look at some real, interesting work done by real people that have more clue than fashion:
Coyotos, an OS whose orthogonal persistence falls out of the capability model of security that they embrace. Coyotos is written in BitC, a purpose-built high-level programming language with special focus on formal semantics and reasoning.
Singularity, a language-based OS in development by none other than Microsoft Research. (Certainly the most interesting Microsoft project that I am aware of.) Singularity exploits language semantics to isolate processes.
TUNES, a collective wet-dream of what the OS, programming language, and generally computing system of tomorrow should look like. With all due respect towards the insurmountable difficulty and endless complexity of a task like this, it must be said that TUNES is just vaporware.
The brilliant thing about anarchocapitalism is that if I dislike a company, I can choose to not do business with them. With the current system, I can wait until election time, try writing letters, and waste a lot of time drumming up support and persuading people. Or expatriate. With everything that I don't like about the US, that would be a full-time job to do properly.
I believe a private system is more fluid to change than a bureaucratic one.
You're telling me that, with a third-party DSL ISP, Bell will peek into the ATM cells passing between your equipment and the ISP's in order to detect which are associated with BitTorrent and throttle those cells accordingly?
I'm sorry; I know your comment is old, but: no. No, no. No no no no no.
syslog is insecure; messages are unauthenticated. Don't believe me? Use the logger(1) utility to forge a message from any daemon on your system, as an unprivileged user. Send a UDP packet to an open syslog daemon to forge a message to look as if it came from any daemon on the originating host. Forge that UDP packet as if it came from any system in the world; there's no two-way handshake to verify the path to the sender is legitimate, like as with TCP.
The only thing you couldn't do—given that the open syslog server is secure—is forge a message time, reliably cover up old log messages, or forge a message from a host where IPsec is used to protect against forgery. (Since syslog uses UDP, an unguaranteed delivery protocol, an attacker could use a DoS attack on the syslog server to overwhelm it with bogus messages, causing it to drop real messages. Or it could drop them anyway. UDP doesn't guarantee a thing.)
DJB gets this right. daemontools devotes a separate security context—a separate user—for the logging needs of every single service that might wish to log a message. Filesystem security ensures no program can forge a message to look as if it came from an unrelated daemon.
If you're not interested in the current layout, where 1.5 pages of content (printed) is expanded across four separate web pages, with a layout/ads/bullshit to content ratio of about 5, try the printable version—the web's best kept secret.
That doesn't stop somebody from surreptitiously swiping your stick, loading trojan horse software on it, and replacing it. e.g. keyloggers, etc.
Unless you sleep with your stick under your pillow and never let it leave you, you can't trust the (unencrypted and unauthenticated) software on it. And you don't ever want to give software you can't trust information that is secret (passphrases).
The same also applies for public and shared computers. Think paranoid!
1) Nothing. What's to stop someone from creating a new username and password each time they visit your site?
2) Don't work in terms of "local" users in your database. Work in terms of OpenID identities—or "remote" users as you put it. Require your local users to enter their full identity URI of http://username.VGPowerlord.rofliron/[1]—or, as a shortcut, if only a username is entered, add the implicit domain name and hand the full, canonical identity URI to your login/logging/user-management functions.
Disregard the space. Thanks, Slashdot, for linkifying a bogus, example URL, tokenizing before the "em" element, when I'm working explicitly in HTML composition mode.
This comment makes me sad. What you need is package management.
There are times you'll want to compile from source. A minor price to pay is to ensure you have supporting libraries in place.
What are the alternatives?
Software developer writes not only the software to solve the problem they're interested in—they have to write other supporting code that duplicates the functionality of existing libraries. This unnecessarily duplicates work. If you have n applications implementing some feature that could have been solved by one library, you get:
n different implementations, with n times the security flaws and other bugs than one would have if a single common library were written.
n "90%" solutions, rather than 1 "100%" solution—each implementation will only go so far as to support the minimum necessary for the original application. A common library can focus on doing it once, the right way, the general way.
About n*0.9-1 additional work expended than would be required for a common library. This depletes energy that could be devoted toward the interesting application you wish to compile.
Software developer bundles all supporting libraries with application, at the source level.
Bugs discovered in the source application will need to be fixed in each bundling application by the developers that maintain the bundling applications, instead of once by software distributors (e.g. Linux distributions). Sometimes this may be easy on a per-case basis. Other times, a copy of the bundled library may be highly customized to the application (effectively a fork).
This also applies to security problems: c.f. zlib
Code size is increased. (This is usually a minor problem.)
Which of these has the acceptable set of trade-offs to you? And, do you write software?
The method you illustrate will not allow for localdev access, will not allow for sound (unless you do some major work with esd as you mentioned earlier in your post), AND still requires you keeping an additional machine up-to-date. It can be done (I did it what a laptop so I could have a wireless "thin-client") Do a little more research before you begin attacking something. You clearly do not understand how LTSP works.
I think you missed a closing tag; sorry I missed this.
Sound is as easy as creating an esound system user on the thin-client and throwing sudo -u esound esd -tcp -public -nobeeps -terminate into its/etc/inittab—though for X and ESD process management, I prefer using supervise, part of DJB's daemontools. Many clients Just Work without setting ESPEAKER on the environment; for others, set that in ~/.xsession.
A thin-client is always an additional machine, and needs to be kept up-to-date as anything else. It runs software that gets new features and is subject to security problems from time to time: the Linux kernel, the X server, the sound server, any daemons to permit remote utilization of removable devices and media, SSH, and soforth. You're probably right in that I'm not familiar with many recent aspects of LTSP; it's been years since I've used it. I found that using a mainstream Linux distribution on my thin-clients gives me excellent package-management, extensibility, and doesn't require me to install "black-box" packages on the system running my workstation software.
USB in a Linux thin-client environment blows chunks. There's a project to encapsulate USB over TCP streams; it's semi-dead and has some reliability and polish issues. There's no other way to smoothly support floppy or CD-ROM drives on your thin-clients, even if they have that hardware.
Funny, I have 3 clients. Each are actually old sub-500MHz pcs. Each has a floppy drive, a cd-rom, and a usb slot. I can plug in any of the three, and they show up on the users desktop (if he/she is using GNOME/KDE). LTSP refers to it as localdev (local devices)
From what I gather on LtspFS/local-device support, they basically invented their own network filesystem. This is wrong in two ways: 1) it would have been better to modify NFS, an established and reliable network filesystem; 2) this is the wrong level to abstract—it's too high-level. They should be exporting block devices on a block device level, not block devices on a filesystem level. Otherwise, you can't burn CDs or DVDs, rip CDs, low-level format a floppy, create a new filesystem on your removable media, or perform a consistency check of the filesystem on your removable media. Furthermore, they should be exporting USB devices on the USB level, so that you can use arbitrary USB devices on your thin-client, like scanners, printers, webcams, and so forth. Tell me, can you do any of these things with "localdev?" If so, I'd love to read the technical details of the system and see how tightly-coupled to LTSP it is. If not, it's perhaps a small step up from floppyd or whatever.
Just plan wrong. LTSP is not run ON thin-clients. It runs the thin-clients.
LTSP is a bundle of software that installs on the "server," may or may not provide scripts and binaries to run on the "server," and definitely provides a Linux kernel and userland filesystem to run on the thin-clients. Arguably, most of the value of LTSP is in the distribution it provides for execution on the thin-client. Therefore, it runs on the thin-clients.
The confusingly-named server, as you say, IS THE SERVER. It serve out the desktop to the thin clients. You don't install anything on the thin clients.
As a matter of fact, the LTSP terminology flies in the face of that of X11 (around for decades), ESound, and probably other software and technology that LTSP depends on. The thin-client runs the X "server." The thin-client runs the ESound "server." The programs on what you call the server, and I call the workstation or back-room machine, are clients of the X11 and ESD protocols, and clients of the servers provided on the thin-client. That's why I say it's confusingly-named. I'll admit a fault in my usage of the term "thin-client;" the traditional term would be X terminal.
If you get a big-endian (e.g. PowerPC) thin-client and use a little-endian (e.g. i386) back-room machine (your existing workstation), you're in for pain: conceptually all things X should be endianness-neutral, but lots of software simply has bugs that hinder features or render that software unusable. Examples: MPlayer, XScreenSaver, and things that do "exotic" things with the display: video playback, 3D graphics, etc.
For ordinary programs and plain graphics, X11 over a LAN works tremendously well. You'll probably be without sound, though: lots of programs expect to be able to open a local sound card and pump stuff out to that. You'll need to run a sound server (ESound works well) and ensure all sound-utilizing programs you'll run will work with that sound server. For GNOME on Ubuntu on a virtual machine without/dev/dsp, sound "just worked" as clients apparently deduced the location of the ESound server from the DISPLAY environment variable; I don't use GNOME much at all, though; YMMV.
If you do like tinkering, search eBay for the IBM NetworkStation 1000; I got mine for less than $20, after shipping. These are powered by PowerPC processors, and have Ethernet, PS/2 keyboard and mouse connectors, a serial port, and a parallel port. They also have sound and smart card hardware, not supported by Linux. They are extremely small, and contain no moving parts. They use a laptop-style power supply. There's an unofficial modification to the Linux 2.4 kernel to get it booting on these things; though the project seems dead.
You can find other thin-clients on eBay for dirt cheap. For maximum party pleasure, make sure you can run Linux on whatever you consider purchasing. If you want sound or USB support, make sure you check that the machine has this hardware. Make sure yours uses Ethernet; there's at least some Token Ring thin-clients in existence.
USB in a Linux thin-client environment blows chunks. There's a project to encapsulate USB over TCP streams; it's semi-dead and has some reliability and polish issues. There's no other way to smoothly support floppy or CD-ROM drives on your thin-clients, even if they have that hardware. Some people might suggest running an FTP server on your thin-client and SSHing in to mount or unmount; I find that disgusting.
As somebody mentioned, iMacs work. Linux runs fairly well out-of-the-box on this platform. These also support netbooting. Make sure to get one without a system fan—remove the hard disk, and you'll have no moving parts.
Whatever you do, don't waste your time with LTSP. It's a distribution of Linux specialized for running on thin-clients, but for some unimaginable reason the "LTSP way" also involves installing their opaque software packages on the (confusingly-named) "server." If you can even run Linux on some platform, you're better off installing Linux on it directly. After that, enable XDMCP with xdm, gdm, or whatever you use on your existing workstation, and throw a line into/etc/inittab on the thin-client (e.g. 7X:23:respawn:/usr/bin/X11/X -query workstation-address).
All iMacs win for new enough OpenFirmware to support netbooting. Certain iMacs win for having no cooling fans. That means: remove the hard disk. When you're not using the CD-ROM drive, you have no moving parts.
A combination of X.org and Linux do an awful job for running multiple, independent X displays. Some things that work okay in a Xinerama or dual-screen configuration (X jargon: 1 display, two independent screens, not like Xinerama) fall flat when you want separate displays.
First, you're at the mercy of your X display drivers. I know the nVidia binary driver works okay with Xinerama on my dual-VGA card ("Twin-View"), but neither the nv or the nvidia drivers can drive two separate X server processes for the same card and different connectors. There's also compatibility problems if you'd like to use two separate cards: I had an nVidia dual-VGA PCI card, a 3Dfx Voodoo3 2000 AGP, a 3Dfx Voodoo3 3000 PCI, and some other forgotten card. The only combination of two cards that I could get working together reliably with two separate processes were the two 3Dfx cards.
Also, running long lengths of VGA cable may be expensive and result in poor quality. It's probably a "choose one of cheap or clear, but not both" situation.
A single Ethernet cable is much thinner, more flexible (physically and conceptually), and supports longer runs than VGA and USB.
These people you list are involved in trade—they are in the business of making money, not providing some public charity out of the goodwill of their hearts.
If the "original sellers" of these properties (landowners, registrars, ticket vendors, etc.) have the sense to know the demand of their product, they would adjust the price accordingly themselves. The only one losing out in such a case would be the original seller. On the other hand, if the "speculator" is mistaken and ends up purchasing some property above value, it ends up being their loss. This is the market at work.
Slashdot Mirror
You downloaded the software at their last two releases, and have kept that same public key in your keyring each time. Or your friends or colleagues can vouch for having trusted a particular public key in the past. Either way, you keep notes documenting the fingerprint of the identity which signs every release.
Guess what? The GuruPlug Server Plus does have dual gigabit Ethernet and eSATA. Unfortunately, it's notorious for overheating.
That's a lie. There must be a half dozen providers for high-speed Internet service where I live, in podunk Spokane, WA (pop. 205,500).
Okay, is it a truly free market? No, usually a lot of the private infrastructure is paid for in taxes, which is certainly not free. But there sure as hell are options (2+) in most mid-sized cities and higher. Don't forget about wireless and third-party DSL providers.
Gee, what do you need that can't be handled with a Turing machine and a lot of tape?
So, what has Go brought to the table?
No, Go doesn't bring anything new to the concurrency table. The two things I've seen about Go concurrency that are regarded as special are M:N/"green" threads and CSP-style channels.
M:N threading is an implementation detail of a language runtime. Whereas the standard library of a language might specify how threads are available to client applications (programs written in the language), it's best left to the implementation (runtime or compiler) to decide how to translate those threads onto the machine. Some implementations might want to focus on scalable, high-performance threading, and so they'd choose M:N. Some others might emphasize simplicity, and map language threads directly to OS threads. What Go has done is standardized this implementation detail into the language specification. (I don't think that's a good idea, but that's a matter of taste.) Other language implementations offer M:N threading, including GHC and (I think) Erlang.
On channels: they're cool. I love them. But there's a lot of prior art here, and many languages have great CSP-style channel libraries written for them that offer the same great flavor of relatively safe message passing and alternation between sets of channels:
In summary, I just don't get what the buzz with Go is about, besides that it's Google's very own language.
There's little or nothing original that's being presented here. The Phantom people claim originality to the idea of orthogonal persistence, but they are flat-out wrong:
To illustrate the utility and awesomeness of persistence, there's a famous story about KeyKOS, an earlier OS that embraced this notion:
The notion of a language-based OS exploiting the semantics of pointerless/"safe" programming languages in order to isolate processes, rather than the norm of executing untrusted native machine code in different address spaces, is nothing new either.
If these ideas shift your bits, take a look at some real, interesting work done by real people that have more clue than fashion:
$500! Hot damn. That sure is a pretty penny to pay for something as EXOTIC AND EXPENSIVE as magnetic force microscopy.
The brilliant thing about anarchocapitalism is that if I dislike a company, I can choose to not do business with them. With the current system, I can wait until election time, try writing letters, and waste a lot of time drumming up support and persuading people. Or expatriate. With everything that I don't like about the US, that would be a full-time job to do properly.
I believe a private system is more fluid to change than a bureaucratic one.
You're telling me that, with a third-party DSL ISP, Bell will peek into the ATM cells passing between your equipment and the ISP's in order to detect which are associated with BitTorrent and throttle those cells accordingly?
Forgive my skepticism.
I'm sorry; I know your comment is old, but: no. No, no. No no no no no.
syslog is insecure; messages are unauthenticated. Don't believe me? Use the logger(1) utility to forge a message from any daemon on your system, as an unprivileged user. Send a UDP packet to an open syslog daemon to forge a message to look as if it came from any daemon on the originating host. Forge that UDP packet as if it came from any system in the world; there's no two-way handshake to verify the path to the sender is legitimate, like as with TCP.
The only thing you couldn't do—given that the open syslog server is secure—is forge a message time, reliably cover up old log messages, or forge a message from a host where IPsec is used to protect against forgery. (Since syslog uses UDP, an unguaranteed delivery protocol, an attacker could use a DoS attack on the syslog server to overwhelm it with bogus messages, causing it to drop real messages. Or it could drop them anyway. UDP doesn't guarantee a thing.)
DJB gets this right. daemontools devotes a separate security context—a separate user—for the logging needs of every single service that might wish to log a message. Filesystem security ensures no program can forge a message to look as if it came from an unrelated daemon.
Where "TB" and "GB" refer to the SI/marketing quantifiers, 4TB ~= 3.6TiB:
As we expect "1 terabyte" to mean exactly 1024**4 bytes, the disk manufacturers would be short-changing us by about 370.7GiB.
If you're not interested in the current layout, where 1.5 pages of content (printed) is expanded across four separate web pages, with a layout/ads/bullshit to content ratio of about 5, try the printable version—the web's best kept secret.
You might want to use tune2fs to change the proportion of reserved blocks from 5% to 0—that's ~47GiB.
Of course, since Estonia is such a backwards, impoverished country.
That doesn't stop somebody from surreptitiously swiping your stick, loading trojan horse software on it, and replacing it. e.g. keyloggers, etc.
Unless you sleep with your stick under your pillow and never let it leave you, you can't trust the (unencrypted and unauthenticated) software on it. And you don't ever want to give software you can't trust information that is secret (passphrases).
The same also applies for public and shared computers. Think paranoid!
1) Nothing. What's to stop someone from creating a new username and password each time they visit your site?
2) Don't work in terms of "local" users in your database. Work in terms of OpenID identities—or "remote" users as you put it. Require your local users to enter their full identity URI of http: //username.VGPowerlord.rofliron/[1]—or, as a shortcut, if only a username is entered, add the implicit domain name and hand the full, canonical identity URI to your login/logging/user-management functions.
This comment makes me sad. What you need is package management.
There are times you'll want to compile from source. A minor price to pay is to ensure you have supporting libraries in place.
What are the alternatives?
Which of these has the acceptable set of trade-offs to you? And, do you write software?
I think you missed a closing tag; sorry I missed this.
Sound is as easy as creating an esound system user on the thin-client and throwing sudo -u esound esd -tcp -public -nobeeps -terminate into its /etc/inittab—though for X and ESD process management, I prefer using supervise, part of DJB's daemontools. Many clients Just Work without setting ESPEAKER on the environment; for others, set that in ~/.xsession.
A thin-client is always an additional machine, and needs to be kept up-to-date as anything else. It runs software that gets new features and is subject to security problems from time to time: the Linux kernel, the X server, the sound server, any daemons to permit remote utilization of removable devices and media, SSH, and soforth. You're probably right in that I'm not familiar with many recent aspects of LTSP; it's been years since I've used it. I found that using a mainstream Linux distribution on my thin-clients gives me excellent package-management, extensibility, and doesn't require me to install "black-box" packages on the system running my workstation software.
...
From what I gather on LtspFS/local-device support, they basically invented their own network filesystem. This is wrong in two ways: 1) it would have been better to modify NFS, an established and reliable network filesystem; 2) this is the wrong level to abstract—it's too high-level. They should be exporting block devices on a block device level, not block devices on a filesystem level. Otherwise, you can't burn CDs or DVDs, rip CDs, low-level format a floppy, create a new filesystem on your removable media, or perform a consistency check of the filesystem on your removable media. Furthermore, they should be exporting USB devices on the USB level, so that you can use arbitrary USB devices on your thin-client, like scanners, printers, webcams, and so forth. Tell me, can you do any of these things with "localdev?" If so, I'd love to read the technical details of the system and see how tightly-coupled to LTSP it is. If not, it's perhaps a small step up from floppyd or whatever.
LTSP is a bundle of software that installs on the "server," may or may not provide scripts and binaries to run on the "server," and definitely provides a Linux kernel and userland filesystem to run on the thin-clients. Arguably, most of the value of LTSP is in the distribution it provides for execution on the thin-client. Therefore, it runs on the thin-clients.
As a matter of fact, the LTSP terminology flies in the face of that of X11 (around for decades), ESound, and probably other software and technology that LTSP depends on. The thin-client runs the X "server." The thin-client runs the ESound "server." The programs on what you call the server, and I call the workstation or back-room machine, are clients of the X11 and ESD protocols, and clients of the servers provided on the thin-client. That's why I say it's confusingly-named. I'll admit a fault in my usage of the term "thin-client;" the traditional term would be X terminal.
Are we done with the capitals and abused italics?
You're going to be doing a lot of tinkering.
If you get a big-endian (e.g. PowerPC) thin-client and use a little-endian (e.g. i386) back-room machine (your existing workstation), you're in for pain: conceptually all things X should be endianness-neutral, but lots of software simply has bugs that hinder features or render that software unusable. Examples: MPlayer, XScreenSaver, and things that do "exotic" things with the display: video playback, 3D graphics, etc.
For ordinary programs and plain graphics, X11 over a LAN works tremendously well. You'll probably be without sound, though: lots of programs expect to be able to open a local sound card and pump stuff out to that. You'll need to run a sound server (ESound works well) and ensure all sound-utilizing programs you'll run will work with that sound server. For GNOME on Ubuntu on a virtual machine without /dev/dsp, sound "just worked" as clients apparently deduced the location of the ESound server from the DISPLAY environment variable; I don't use GNOME much at all, though; YMMV.
If you do like tinkering, search eBay for the IBM NetworkStation 1000; I got mine for less than $20, after shipping. These are powered by PowerPC processors, and have Ethernet, PS/2 keyboard and mouse connectors, a serial port, and a parallel port. They also have sound and smart card hardware, not supported by Linux. They are extremely small, and contain no moving parts. They use a laptop-style power supply. There's an unofficial modification to the Linux 2.4 kernel to get it booting on these things; though the project seems dead.
You can find other thin-clients on eBay for dirt cheap. For maximum party pleasure, make sure you can run Linux on whatever you consider purchasing. If you want sound or USB support, make sure you check that the machine has this hardware. Make sure yours uses Ethernet; there's at least some Token Ring thin-clients in existence.
USB in a Linux thin-client environment blows chunks. There's a project to encapsulate USB over TCP streams; it's semi-dead and has some reliability and polish issues. There's no other way to smoothly support floppy or CD-ROM drives on your thin-clients, even if they have that hardware. Some people might suggest running an FTP server on your thin-client and SSHing in to mount or unmount; I find that disgusting.
As somebody mentioned, iMacs work. Linux runs fairly well out-of-the-box on this platform. These also support netbooting. Make sure to get one without a system fan—remove the hard disk, and you'll have no moving parts.
Whatever you do, don't waste your time with LTSP. It's a distribution of Linux specialized for running on thin-clients, but for some unimaginable reason the "LTSP way" also involves installing their opaque software packages on the (confusingly-named) "server." If you can even run Linux on some platform, you're better off installing Linux on it directly. After that, enable XDMCP with xdm, gdm, or whatever you use on your existing workstation, and throw a line into /etc/inittab on the thin-client (e.g. 7X:23:respawn:/usr/bin/X11/X -query workstation-address ).
All iMacs win for new enough OpenFirmware to support netbooting. Certain iMacs win for having no cooling fans. That means: remove the hard disk. When you're not using the CD-ROM drive, you have no moving parts.
A combination of X.org and Linux do an awful job for running multiple, independent X displays. Some things that work okay in a Xinerama or dual-screen configuration (X jargon: 1 display, two independent screens, not like Xinerama) fall flat when you want separate displays. First, you're at the mercy of your X display drivers. I know the nVidia binary driver works okay with Xinerama on my dual-VGA card ("Twin-View"), but neither the nv or the nvidia drivers can drive two separate X server processes for the same card and different connectors. There's also compatibility problems if you'd like to use two separate cards: I had an nVidia dual-VGA PCI card, a 3Dfx Voodoo3 2000 AGP, a 3Dfx Voodoo3 3000 PCI, and some other forgotten card. The only combination of two cards that I could get working together reliably with two separate processes were the two 3Dfx cards. Also, running long lengths of VGA cable may be expensive and result in poor quality. It's probably a "choose one of cheap or clear, but not both" situation. A single Ethernet cable is much thinner, more flexible (physically and conceptually), and supports longer runs than VGA and USB.
Next time, use a URL proxy service, like the article submitter did for the link to their hosting company.
These people you list are involved in trade—they are in the business of making money, not providing some public charity out of the goodwill of their hearts.
If the "original sellers" of these properties (landowners, registrars, ticket vendors, etc.) have the sense to know the demand of their product, they would adjust the price accordingly themselves. The only one losing out in such a case would be the original seller. On the other hand, if the "speculator" is mistaken and ends up purchasing some property above value, it ends up being their loss. This is the market at work.
Why support that kind of business?