No, everything you drag to the trash sits in the trash, just like the real world. You have to empty it later. Although the Mac doesn't have Garbage Chute, Compacter, Dumpster, Truck or Landfill icons to truly implement the real-world experience. Maybe "Empty Trash" should have been called "Incinerate"?
Drag-to-trash to unmount a filesystem (and also eject removable media) is odd, but since the trash doesn't erase things, it isn't as bad as could have been. The problem is really with users who are already used to a "Delete file" operation from other systems; the Mac doesn't give you that directly. So you tell people who want to delete a file to drag it to the trash, and they associate "drag to trash" with "erase the file". But, of course, it's really just moved to a special directory on the disk; the file is still there, and you can drag it back if you want.
Really? My company is quite happy to shell out for 30 or so seats for GCC, via Cygnus' (oops I mean RedHat's) GNUPro compiler suite.
It is similarly priced to a vendor's compiler suite. But there's no license mangler to mess with, I can muck with the source myself for simple problems, I can build on platforms we are prototyping and haven't paid for--the ultimate try-n-buy. And we get a consistent option group and extension syntax across all platforms.
And their defect turnaround is pretty amazing; usually in a few days. "Hard" problems can take longer. I used to work for a compiler vendor, and we'd frequently tell customers that their bugs just wouldn't be fixed, ever--just work around it. (Us techs didn't like having to say that, but management insisted. Must get the new, incompatible version out the door at all costs! Even if we lose all our customers!) When we did fix a bug, it would typically be 3-4 months from the date reported to when the fix was finally available to the paying customer. (And they have to pay for every user, or the compiler won't even run!)
Borrow an ammeter from someone and measure the actual consumption. That 300W is so the machine can handle spike loads (disk seeks, for example), not continuous average.
I was working out how many UPSes were needed for a build lab. We had 12 RS/6000s with 1 KW (actually, 1 KVA, but we'll gloss over that) power supplies, so I figured we'd need a whole mess of UPSes. Plus a 30 or so PCs with bog-standard 250W supplies, about half of which we wanted protected.
The results: The RS/6000s drew peak.8 amps, giving about 100 VA, making real power less than 100 watts. They would idle around.5 to.7 amps, depending; the newer ones with the faster memory and CPUs used less power. The PCs peaked a little higher and idled a little lower;.9 to 1 amp peak and.3 to.4 idle. (And remember, the PCs had a nameplate rating 1/4th that of the RS/6Ks.)
The absolute worst pig of a machine I could find was one of the early SMP RS/6Ks--one that runs so hot you can feel the heat when you walk by it. It drew 3-4 amps. Even the old multi-chip processor RS/6000s drew a measly 1.2 to 2 amps.
My SyQuest Syjet, with a 1 amp supply, drew peak 0.1 amp and idle 0.01 amp; though this was running into the low end of the meter's resolution.
Monitors were also depressingly light on the power; just under an amp for a modern one and about 1.5 for an older 6091 (big, hot, heavy) set.
Your amperage will obviously vary; but those nameplate ratings are the absolute top max. If your drives coming up together exceed that number, your power supply will shut down. (Not fun if you're trying to hot-swap on an not-hot-swappable machine.) But they only do that once; and bigger systems will stagger disk spin to reduce the need for excess power overhead.
You can happily omit , as it can always be inferred from context. Check out the W3C if you really care.
In Netscape, omitting </TABLE> will leave you with utterly blank space. So the example fails not because of a missing </td> or </tr> (or </body> or </html>) but the unclosed <table>.
The HTML spec encourages you to omit unnecssary tags. They clearly indicate which tags are required and which are optional. It's generally pretty sensible too: you can't have a <td> in a <td>, so you know starting a new table cell must also end the first one.
For real fun, read the explanation as to why <head> and <body> are no longer required.
For example, it turns out that growing volumes is fairly straightforward, but shrinking them is much more difficult
Yes, this is an unfortunate limitation in AIX also. There are always ways around it, given a sufficiently large tape drive and time to do it.
However, I think with the Linux crowd, there will be enough people who want to mess around with filesystems that the changes will be made to support shrinking. I know I would be happy to help, although right now I'd spend a lot of time just learning how things work. (Which is always fun in any case.)
With AIX, shrinking filesystems was always on the Would Be Nice list. Other things just take precedence. (And believe me, being able to grow a filesystem is sufficiently nice that I was always willing to forgive the inability to shrink one.)
There is a simple trick you can pull to avoid needing shrink-ability as well: Make a new filesystem for stuff you want to try out. With LVM, you can create and destroy LVs without rebooting (unlike partitions), so you can create a scratch LV, put an FS in it, mount it, try out the program, decide it sucks, unmount the FS and destroy the LV. Not elegant, but you're not dead in the water either.
And when you do find that/var is a tad too small for that ClearCase log, growing an FS is really all that matters....
...a simple portscan would've turned up the fact that something was amiss.
That's a good idea. Another good idea is to do a simple ``netstat'' dump of listening sockets on the firewall. I hope that any firewall admin is already doing this--it is an important check that things are as you intended them to be. Any program which cannot bind to specific interfaces has no business on a firewall. It certainly shouldn't call itself a ``proxy''.
I know the first time I ran ``netstat -l'' on a RedHat 6.1 system I was quite surprised by the cruft hanging around. Before that machine took on its firewall/masq duties, all those unwanted daemons were removed.
The PPC kernel runs fine on IBM RS/6000 machines, and even some of the not-ever-released Personal Computer-branded PPC systems. I was looking at their Canadian prices recently, and some of the 2U rackmount RS6K systems weren't too expensive. They didn't have prices on the desktop machines, but it looks like an RS/6000 might be almost affordable now. And there's often used ones to be found if you look.
As someone who has a Mac with Apple's DVD player, I really look forward to a free Linux player. Apple's is awful; the software decode performance is very poor under MacOS. (And yes, I have the patch released in December.)
But it looks like OS X will be out first, which should solve some of the scheduling and virtual memory problems which affect the Apple player.
If nothing else, why should I shut down and reboot just to watch a movie?
Well, it would allow you to use a newer Motif toolkit than is currently provided by the vendor.
Keep in mind it is very common for people to still be running UNIX versions that are many years old now. We still support Solaris 2.5, AIX 4.2, and HP-UX 10.20 where I work, and all three are Motif 1.2-ish.
But if we want to do Motif 2.1 on them, we'll have to spring for the license. (Instead, what we have been doing is using Motif 1.2 on all the newer systems. Lowest common denominator.)
Actually, that sounds very much like AIX installp plus the ``FixDist'' package which monitors lists of updates on the Internet and offers to download them and install them. IIRC, FixDist uses a date to determine if its list of fixes is out-of-date, and then uses installp version numbers to check your local system.
Unfortunately, IBM's patent server seems to be suffering from the slashdot effect... which is too bad, because I think they've got prior art on this one.
It depends greatly on how the various parts of the larger product fit together.
One could call a Linux distro one large software product. In that case, it is quite possible to add programs to the distro which do not need to be covered by the GPL. On the other hand, adding a new terminal driver to Emacs would need to be GPLed.
Note carefully the clause about independent and separate works in section 2. This is where you can quickly get yourself in trouble, as using a library means your work is not independent of that library.
So, a separately-invokable program linked only against LGPL (or other non-GPL) code would be a separate work, and would not need to be GPLed.
I'm sure there's been discussion on binary-only Linux kernel modules, and I don't see how they can be considered separate works.
Another point, some of us have very weird high-speed connections. PPPoE ADSL, for example. Basically, I cannot run the ADSL connection from an install kernel; so there is no way to do a network-sourced install onto the Linux machine. I need enough stuff installed to be able to build a new kernel, the PPPoE stuff, and get IP MASQ back up.
The solution that I chose for all that is to get a second scrap PC for non-firewall related stuff. I could also wedge PPPoE onto it long enough to bootstrap the firewall if I had to. (Say, total disk failure without backup. Or buggy package manager.) But not everyone has space, money, or the LAN lying around necessary to do that.
Maybe there should be something smaller than the normal "everything that fits" ISO image. Most users could probably get by with a bootable image that can build a new kernel and install from the 'net. (It's lots of fun dealing with the fact that you can't get on the 'net until you download new kernel sources and some support programs.... I love monopolies!)
USB support is excellent, despite the big warnings in the kernel config menus. Especially the backport present in the 2.2.15pre builds. (The PowerPC-patched version, not the kernel.org version.) In fact, I merged some of the PowerPC USB patches into the Intel kernel on my work machine and brought my USB trackball into the office. Very nice. The only tricky thing is my 5-button+wheel trackball. I haven't sat down with a big heap of X resources to get the 4th and 5th buttons doing anything. Yet. Toss that one button mouse; more buttons = happier hacker. Even in MacOS. Especially with InputSprocket-aware games.
On the plus side, it has the Video/TV capture card, so I can hook it up to any composite video camera and have a Web cam. All I need is something worth pointing the camera at.
(Ethernet on MacOS for these things is dead easy, BTW. Get either a Comm Slot or LC PDS Ethernet card, and make sure you've got "Ethernet CS" or "Ethernet LC" in the extensions folder. The pain part is the price.)
Or maybe it'll become the kitchen recipe box and television set.
I know very few people like AIX's "smit" tool, except where the running man falls flat on his face when something goes wrong, but this was its saving grace: you could press a function key and it would show you the command line it would run. This is how I learned to not need the GUI for some pretty esoteric tasks. (Unfortunately, some of the updated SMIT panes have a huge crufty option translator in a for...case...esac...done blob that hides the true command, which removes the whole point... but that's progress I guess.)
Anyway, I think this is an excellent idea for all GUIs--allow the user who "just wants it working" (which is sometimes me) to just get it working, and the person who wants to know more can get access to underlying command lines or file deltas--from within the GUI. I hate searching the filesystem for a log file which might not be there, or figuring out which bit in the log is related to the change I just made. (Fortunately, most Linux programs timestamp log entries, which makes the latter much easier.)
I just hope IBM hasn't patented the "show command" button.
A friend of mine had this _other_ funny strange theory about RSI; having gotten a rather bad case of it (RSI, not theory) from trying to switch between proper piano and synth keyboards. After he wrecked his wrists bad enough to give up playing for several years, he did some research on the topic and noted one tiny little detail that he decided makes all the difference: The synth sounds at the bottom of the keystroke, and the piano sounds partway thorugh. Since he learned piano first, he was trying to drive the synth keys past their sounding point, in effect, past their end of travel.
I've noticed a similar thing. The IBM Click-o-Matic keyboards send the keysequence partway down; so after you hear the click, you've got some (seemingly) useless key travel, which lets your finger stop without hitting something. The two keyboards I "grew up" with the most had a similar, though quiet, mechanism: the Amiga, with a weird move-the-plastic-doohickey-out-from-between-two-co ntacts keyswitch; and the CEMCORP Icon (remember that?), which had a put-a-ferrite-bead-through-two-coils mechanism. Both allowed extra travel at the end of the keystroke, but without the benefit of the tactile (and acoustic) feedback from IBM's proper keyboards. (There may be an IBM logo on this keyboard, but after just a couple of days with it I'm already feeling pain in my fingers. We hates it we do.)
Most modern keyboards are descendents of the PET rubber-widget-hitting-a-contact-pad (okay, my history is biased) family, only without honest springs... just a stupid rubber cup that would be more at home on a remote control. Of course, the key doesn't activate until the rubber bit hits the circuit board; and you've got all that inertia to do something with. (And so many of these have weak contacts... so you almost have to smash at them. That's fine for the junk-shop special on the router, but has no place on a serious keyboard.)
The point being: No matter how you hold your wrists, if you smash your fingers down on a hard surface all day, your hands are going to hurt.
however, I cannot give it to a minor, since I cannot insure that they abide by the contract (indeed, I have foreknowledge that they CANNOT), which is a further condition of the GPL.
Well, I think this is a bit strong. Although a minor cannot be compelled, by Canadian law, there is no reason why a minor cannot act in good faith and uphold the contract even though he is not legally bound to do so.
I think this is well demonstrated by the number of minors making successful contributions to GPL projects.
There's a little twist that prevents the GPL from being invalid if someone who cannot legally agree to the licence downloads GPL source.
Normaly copyright law provides _more_ protection than the GPL. The GPL grants you the right to modify and distribute, with important restrictions. You wouldn't normally have this right, even if you could see the source. If you can't be bound by the GPL, then you no longer have any of those rights to modify and distribute, and everything falls back on the author's basic copyright.
Maybe we should get our legal friends to host an AskSlashdot on the subject? The relevance to other EULAs, such as movies or video games, is intriguing. Although I suspect the fall-back to copyright will protect the owner.
Well, I've got a 14-year-old Honda Magna (no, only the 700 cc model, so it only goes fast, instead of exceptionally fast).
I'm one of those weird people who actually like the "good ol'" UJMs from the early 80s. They were (for the most part) solid machines that weren't pretending to be anything. And you can fix them in your own backyard. And they're cheap to buy, which is important when all your hobbies are expensive.
This doesn't mean I haven't been eyeing the new shiny go-really-fast German and Japanese machines... maybe when there's a bit less of the mortgage left.
(Unless Santa brings one for Christmas, along with the competent Internet provider I've been asking for.)
Well, if by X desktop you mean the non-open CDE (which may be an open standard that you can buy, but is not open source), yes, there may be an original X desktop.
But X users have not been able to agree on a window manager: Motif, OpenLook, fvwm, tvwm, WindowMaker, dtwm (CDE's) and so on. Most well-behaved X programs will be usable under any window manager, so people pick the one they like best.
Sun has a desktop envrionment of their own and offers CDE; IBM used to have their own but forced everyone to switch to CDE or just use plain Motif; I think HP did something similar; NeXT had a desktop which predated CDE (and which a number of the Linux desktops and window managers mimic).
The point is, there was no one X desktop environment to fork. Had the X server itself forked on Linux, that could become a serious problem. (X is already forked; every vendor's X is proprietary and closed source. XFree86, XFree68, and so on are the only open source X servers I know of... that can actually render on a display.)
The X base code is free, but derivative works do not have to be free. Since the base code does not support any display hardware, we have vendor forks for every UNIX, plus the XFree* forks.
Fortunately, people only mess with the device driver side, and so X programs continue to work across many window managers, and display properly on different remote systems.
Slashdot Mirror
No, everything you drag to the trash sits in the trash, just like the real world. You have to empty it later. Although the Mac doesn't have Garbage Chute, Compacter, Dumpster, Truck or Landfill icons to truly implement the real-world experience. Maybe "Empty Trash" should have been called "Incinerate"?
Drag-to-trash to unmount a filesystem (and also eject removable media) is odd, but since the trash doesn't erase things, it isn't as bad as could have been. The problem is really with users who are already used to a "Delete file" operation from other systems; the Mac doesn't give you that directly. So you tell people who want to delete a file to drag it to the trash, and they associate "drag to trash" with "erase the file". But, of course, it's really just moved to a special directory on the disk; the file is still there, and you can drag it back if you want.
It is similarly priced to a vendor's compiler suite. But there's no license mangler to mess with, I can muck with the source myself for simple problems, I can build on platforms we are prototyping and haven't paid for--the ultimate try-n-buy. And we get a consistent option group and extension syntax across all platforms.
And their defect turnaround is pretty amazing; usually in a few days. "Hard" problems can take longer. I used to work for a compiler vendor, and we'd frequently tell customers that their bugs just wouldn't be fixed, ever--just work around it. (Us techs didn't like having to say that, but management insisted. Must get the new, incompatible version out the door at all costs! Even if we lose all our customers!) When we did fix a bug, it would typically be 3-4 months from the date reported to when the fix was finally available to the paying customer. (And they have to pay for every user, or the compiler won't even run!)
Borrow an ammeter from someone and measure the actual consumption. That 300W is so the machine can handle spike loads (disk seeks, for example), not continuous average.
I was working out how many UPSes were needed for a build lab. We had 12 RS/6000s with 1 KW (actually, 1 KVA, but we'll gloss over that) power supplies, so I figured we'd need a whole mess of UPSes. Plus a 30 or so PCs with bog-standard 250W supplies, about half of which we wanted protected.
The results: The RS/6000s drew peak .8 amps, giving about 100 VA, making real power less than 100 watts. They would idle around .5 to .7 amps, depending; the newer ones with the faster memory and CPUs used less power. The PCs peaked a little higher and idled a little lower; .9 to 1 amp peak and .3 to .4 idle. (And remember, the PCs had a nameplate rating 1/4th that of the RS/6Ks.)
The absolute worst pig of a machine I could find was one of the early SMP RS/6Ks--one that runs so hot you can feel the heat when you walk by it. It drew 3-4 amps. Even the old multi-chip processor RS/6000s drew a measly 1.2 to 2 amps.
My SyQuest Syjet, with a 1 amp supply, drew peak 0.1 amp and idle 0.01 amp; though this was running into the low end of the meter's resolution.
Monitors were also depressingly light on the power; just under an amp for a modern one and about 1.5 for an older 6091 (big, hot, heavy) set.
Your amperage will obviously vary; but those nameplate ratings are the absolute top max. If your drives coming up together exceed that number, your power supply will shut down. (Not fun if you're trying to hot-swap on an not-hot-swappable machine.) But they only do that once; and bigger systems will stagger disk spin to reduce the need for excess power overhead.
In Netscape, omitting </TABLE> will leave you with utterly blank space. So the example fails not because of a missing </td> or </tr> (or </body> or </html>) but the unclosed <table>.
The HTML spec encourages you to omit unnecssary tags. They clearly indicate which tags are required and which are optional. It's generally pretty sensible too: you can't have a <td> in a <td>, so you know starting a new table cell must also end the first one.
For real fun, read the explanation as to why <head> and <body> are no longer required.
Yes, this is an unfortunate limitation in AIX also. There are always ways around it, given a sufficiently large tape drive and time to do it.
However, I think with the Linux crowd, there will be enough people who want to mess around with filesystems that the changes will be made to support shrinking. I know I would be happy to help, although right now I'd spend a lot of time just learning how things work. (Which is always fun in any case.)
With AIX, shrinking filesystems was always on the Would Be Nice list. Other things just take precedence. (And believe me, being able to grow a filesystem is sufficiently nice that I was always willing to forgive the inability to shrink one.)
There is a simple trick you can pull to avoid needing shrink-ability as well: Make a new filesystem for stuff you want to try out. With LVM, you can create and destroy LVs without rebooting (unlike partitions), so you can create a scratch LV, put an FS in it, mount it, try out the program, decide it sucks, unmount the FS and destroy the LV. Not elegant, but you're not dead in the water either.
And when you do find that /var is a tad too small for that ClearCase log, growing an FS is really all that matters....
That's a good idea. Another good idea is to do a simple ``netstat'' dump of listening sockets on the firewall. I hope that any firewall admin is already doing this--it is an important check that things are as you intended them to be. Any program which cannot bind to specific interfaces has no business on a firewall. It certainly shouldn't call itself a ``proxy''.
I know the first time I ran ``netstat -l'' on a RedHat 6.1 system I was quite surprised by the cruft hanging around. Before that machine took on its firewall/masq duties, all those unwanted daemons were removed.
As someone who has a Mac with Apple's DVD player, I really look forward to a free Linux player. Apple's is awful; the software decode performance is very poor under MacOS. (And yes, I have the patch released in December.)
But it looks like OS X will be out first, which should solve some of the scheduling and virtual memory problems which affect the Apple player.
If nothing else, why should I shut down and reboot just to watch a movie?
Keep in mind it is very common for people to still be running UNIX versions that are many years old now. We still support Solaris 2.5, AIX 4.2, and HP-UX 10.20 where I work, and all three are Motif 1.2-ish.
But if we want to do Motif 2.1 on them, we'll have to spring for the license. (Instead, what we have been doing is using Motif 1.2 on all the newer systems. Lowest common denominator.)
Actually, that sounds very much like AIX installp plus the ``FixDist'' package which monitors lists of updates on the Internet and offers to download them and install them. IIRC, FixDist uses a date to determine if its list of fixes is out-of-date, and then uses installp version numbers to check your local system.
Unfortunately, IBM's patent server seems to be suffering from the slashdot effect... which is too bad, because I think they've got prior art on this one.
It depends greatly on how the various parts of the larger product fit together.
One could call a Linux distro one large software product. In that case, it is quite possible to add programs to the distro which do not need to be covered by the GPL. On the other hand, adding a new terminal driver to Emacs would need to be GPLed.
Note carefully the clause about independent and separate works in section 2. This is where you can quickly get yourself in trouble, as using a library means your work is not independent of that library.
So, a separately-invokable program linked only against LGPL (or other non-GPL) code would be a separate work, and would not need to be GPLed.
I'm sure there's been discussion on binary-only Linux kernel modules, and I don't see how they can be considered separate works.
The solution that I chose for all that is to get a second scrap PC for non-firewall related stuff. I could also wedge PPPoE onto it long enough to bootstrap the firewall if I had to. (Say, total disk failure without backup. Or buggy package manager.) But not everyone has space, money, or the LAN lying around necessary to do that.
Maybe there should be something smaller than the normal "everything that fits" ISO image. Most users could probably get by with a bootable image that can build a new kernel and install from the 'net. (It's lots of fun dealing with the fact that you can't get on the 'net until you download new kernel sources and some support programs.... I love monopolies!)
USB support is excellent, despite the big warnings in the kernel config menus. Especially the backport present in the 2.2.15pre builds. (The PowerPC-patched version, not the kernel.org version.) In fact, I merged some of the PowerPC USB patches into the Intel kernel on my work machine and brought my USB trackball into the office. Very nice. The only tricky thing is my 5-button+wheel trackball. I haven't sat down with a big heap of X resources to get the 4th and 5th buttons doing anything. Yet. Toss that one button mouse; more buttons = happier hacker. Even in MacOS. Especially with InputSprocket-aware games.
Yeah, I've got a 6300 in the same boat [anchor].
On the plus side, it has the Video/TV capture card, so I can hook it up to any composite video camera and have a Web cam. All I need is something worth pointing the camera at.
(Ethernet on MacOS for these things is dead easy, BTW. Get either a Comm Slot or LC PDS Ethernet card, and make sure you've got "Ethernet CS" or "Ethernet LC" in the extensions folder. The pain part is the price.)
Or maybe it'll become the kitchen recipe box and television set.
I know very few people like AIX's "smit" tool, except where the running man falls flat on his face when something goes wrong, but this was its saving grace: you could press a function key and it would show you the command line it would run. This is how I learned to not need the GUI for some pretty esoteric tasks. (Unfortunately, some of the updated SMIT panes have a huge crufty option translator in a for...case...esac...done blob that hides the true command, which removes the whole point... but that's progress I guess.)
Anyway, I think this is an excellent idea for all GUIs--allow the user who "just wants it working" (which is sometimes me) to just get it working, and the person who wants to know more can get access to underlying command lines or file deltas--from within the GUI. I hate searching the filesystem for a log file which might not be there, or figuring out which bit in the log is related to the change I just made. (Fortunately, most Linux programs timestamp log entries, which makes the latter much easier.)
I just hope IBM hasn't patented the "show command" button.
A friend of mine had this _other_ funny strange theory about RSI; having gotten a rather bad case of it (RSI, not theory) from trying to switch between proper piano and synth keyboards. After he wrecked his wrists bad enough to give up playing for several years, he did some research on the topic and noted one tiny little detail that he decided makes all the difference: The synth sounds at the bottom of the keystroke, and the piano sounds partway thorugh. Since he learned piano first, he was trying to drive the synth keys past their sounding point, in effect, past their end of travel.
o ntacts keyswitch; and the CEMCORP Icon (remember that?), which had a put-a-ferrite-bead-through-two-coils mechanism. Both allowed extra travel at the end of the keystroke, but without the benefit of the tactile (and acoustic) feedback from IBM's proper keyboards. (There may be an IBM logo on this keyboard, but after just a couple of days with it I'm already feeling pain in my fingers. We hates it we do.)
I've noticed a similar thing. The IBM Click-o-Matic keyboards send the keysequence partway down; so after you hear the click, you've got some (seemingly) useless key travel, which lets your finger stop without hitting something. The two keyboards I "grew up" with the most had a similar, though quiet, mechanism: the Amiga, with a weird move-the-plastic-doohickey-out-from-between-two-c
Most modern keyboards are descendents of the PET rubber-widget-hitting-a-contact-pad (okay, my history is biased) family, only without honest springs... just a stupid rubber cup that would be more at home on a remote control. Of course, the key doesn't activate until the rubber bit hits the circuit board; and you've got all that inertia to do something with. (And so many of these have weak contacts... so you almost have to smash at them. That's fine for the junk-shop special on the router, but has no place on a serious keyboard.)
The point being: No matter how you hold your wrists, if you smash your fingers down on a hard surface all day, your hands are going to hurt.
Rubber-dome keyboards: Just Say No.
however, I cannot give it to a minor, since I cannot insure that they abide by the contract (indeed, I have foreknowledge that they CANNOT), which is a further condition of the GPL.
Well, I think this is a bit strong. Although a minor cannot be compelled, by Canadian law, there is no reason why a minor cannot act in good faith and uphold the contract even though he is not legally bound to do so.
I think this is well demonstrated by the number of minors making successful contributions to GPL projects.
There's a little twist that prevents the GPL from being invalid if someone who cannot legally agree to the licence downloads GPL source.
Normaly copyright law provides _more_ protection than the GPL. The GPL grants you the right to modify and distribute, with important restrictions. You wouldn't normally have this right, even if you could see the source. If you can't be bound by the GPL, then you no longer have any of those rights to modify and distribute, and everything falls back on the author's basic copyright.
Maybe we should get our legal friends to host an AskSlashdot on the subject? The relevance to other EULAs, such as movies or video games, is intriguing. Although I suspect the fall-back to copyright will protect the owner.
Well, I've got a 14-year-old Honda Magna (no, only the 700 cc model, so it only goes fast, instead of exceptionally fast).
I'm one of those weird people who actually like the "good ol'" UJMs from the early 80s. They were (for the most part) solid machines that weren't pretending to be anything. And you can fix them in your own backyard. And they're cheap to buy, which is important when all your hobbies are expensive.
This doesn't mean I haven't been eyeing the new shiny go-really-fast German and Japanese machines... maybe when there's a bit less of the mortgage left.
(Unless Santa brings one for Christmas, along with the competent Internet provider I've been asking for.)
Well, if by X desktop you mean the non-open CDE (which may be an open standard that you can buy, but is not open source), yes, there may be an original X desktop.
But X users have not been able to agree on a window manager: Motif, OpenLook, fvwm, tvwm, WindowMaker, dtwm (CDE's) and so on. Most well-behaved X programs will be usable under any window manager, so people pick the one they like best.
Sun has a desktop envrionment of their own and offers CDE; IBM used to have their own but forced everyone to switch to CDE or just use plain Motif; I think HP did something similar; NeXT had a desktop which predated CDE (and which a number of the Linux desktops and window managers mimic).
The point is, there was no one X desktop environment to fork. Had the X server itself forked on Linux, that could become a serious problem. (X is already forked; every vendor's X is proprietary and closed source. XFree86, XFree68, and so on are the only open source X servers I know of... that can actually render on a display.)
The X base code is free, but derivative works do not have to be free. Since the base code does not support any display hardware, we have vendor forks for every UNIX, plus the XFree* forks.
Fortunately, people only mess with the device driver side, and so X programs continue to work across many window managers, and display properly on different remote systems.