The part you're missing is that if any given voter can verify their vote, that means the votes can be audited. Each vote is stored, not just a running total. Each vote can be verified by the person that voted, and if they can't verify their vote, it's a red flag.
The part you're missing is that how you voted is irrelevant. It's how everyone else voted that swung the election. Seeing something that proves you voted for candidate A is meaningless. You don't have any way of knowing who the 499 others who really voted for A are. As far as you are concerned, you and 389 anonymous strangers voted for A.
If the running total doesn't match the actual votes cast, then that's a red flag.
But you are relying on the same system that counts the votes, to raise the alerts.
I'm talking about the machinery being purpose-designed so that the running totals deliberately do not match the actual votes, but are merely plausible when viewed in the light of what is likely to be known about the actual votes.
You can have your paper ballot (which matches the record of the vote, which can be checked by you or anyone seeking to know how you voted, but doesn't necessarily contribute to the running total for the candidate you thought you were voting for) and drop it in a box; but if those paper ballots aren't going to be counted by hand (because there is a plausible alternative explanation for the discrepancy, i.e. "That is how the people actually voted, and it must be true because the machine says so") then what's the point in having them? If the paper ballots are going to be counted by hand (which will reveal that the election was rigged somehow, but the Powers That Be have all manner of techniques at their disposal to prevent that happening), then what was the point in having all that expensive machinery in the first place when you could just have used paper ballots and hand-counting? And if the paper ballots are going to be counted by machine, then the counting machine can always be rigged to produce totals which do not reflect reality: 500 in the "A" pile under a display reading "390", 480 in the "B" pile under a display reading "600" and 120 in the "C" pile under a display reading "110". If the ballots are deliberately "mistreated" by the machine, so as to give them a slight but randomly-variable curvature, then the discrepancy in sizes of the piles won't be so apparent.
I'm assuming throughout, by the way, that a hand count is certain to be correct. This is a reasonable assumption since an adversarial relationship exists between candidates. That is to say, candidate A and their aides do not trust candidates B, C or their respective aides; candidate B + aides do not trust candidates A, C or their aides; and candidate C + aides don't trust candidates A, B or their aides. As long as the actual candidates and/or their aides do the counting themselves, and all sides are represented, everyone will be watching everyone else like a hawk and no-one will dare to try anything on.
And all these layers of complexity you are introducing add failure modes.
The problem is, you can have a list of how everyone actually voted, and you can even add restrictions that prevent anyone seeing anyone else's vote. (In fact, the surer you are that you can do that, the better.) But if there's even one layer of abstraction between the physical action taken by the voter and what actually gets counted, what's to prevent them from claiming some utterly bogus totals as the "final count"? Just because you know how you voted, that doesn't prove anything about how your vote was recorded. You could have 500 people voting for A, 480 people voting for B and 120 people voting for C; but the totals could be claimed as 390 for A, 600 for B and 110 for C. And nobody would be any the wiser, because the errors are just about within the bounds of plausibility (people often lie to reporters about who they have just voted for / are going to vote for). To discover the error, you would have to check everybody's votes and see that the final totals are not as claimed; and you'd be arrested for Treason long before you got far enough to notice any anomaly.
But the amusement machine industry is self-regulating anyway, because there is an adversarial relationship between punters and casino operators. If you are operating several amusement machines, you won't buy ones that pay out too much because you'll lose money on them; but you won't buy ones that pay out too little because the punters won't play them and you'll still lose money on them. All the regulations are pretty much for show.
There isn't any such adversarial relationship between presiding officers and voters. (But there is an exploitable adversarial relationship between the various candidates in an election: no candidate, nor any of their aides, trusts any of the other candidates or their aides. If the candidates themselves were hand-counting the ballot papers, they'd have no choice but to declare the true count.)
Uh, stop right there. There's no way to have traceability and anonymisation. The two goals are in conflict. Instead, what you have to be able to do is to make sure that errors are detectable. If you know there was one duff ballot in a batch of 2000 (but you don't know which of the 2000 it was or how it should have been filled), you can hold those 2000 out of the final count temporarily. If that error was enough to spoil the whole result, then you repeat the polling from scratch in just that one ward.
You can't trust what you don't understand, so any voting system needs to be Universally Comprehensible. An electronic system based on Open Source principles -- where the blueprints for the hardware and the listings of the software are available for all to examine -- is still really only comprehensible to a minority of the population. It doesn't satisfy the goal. (In the worst case, you could conceal a deliberate design defect by a combination of hardware and software techniques: anybody examining the hardware and not the software, or vice versa, will miss it.)
Just forget the whole thing as a failed experiment, and go back to pencil and paper and manual counting. Everybody knows what all the possible failure modes are, and how to minimise their effects.
Let us also digress into a micro-kernel vs monolith-kernel discussion.
Oh, that's an easy one. With a microkernel, you put up fences where they look pretty. With a monolithic kernel and loadable modules, you put up fences where as little stuff as possible has to traverse them. Ting! Next, please.
Well..... you don't have to type every single filename, you can use a for construct. Something like (off the top of my head so may be wrong; can't be bothered to check it right now; if you try this and it doesn't work, please don't just mod me down -- post a reply and we can all learn from it)
for BIG in $(ls *.jpg |grep -v _mini.jpg); do SMALL=$(echo $BIG |sed 's/.jpg/_mini/jpg/'); convert -resize 160x160 $BIG $SMALL && echo "Shrunk $BIG giving $SMALL"; done
which creates a thumbnail no bigger than 160x160 from every.jpg picture in the current folder (but without _mini.jpg in its name), giving it a similar filename but with _mini inserted before the.jpg, and just for the sake of reassurance generates a progress report as it goes along. So for example dscf1102.jpg would become dscf1102_mini.jpg.
And no, I don't expect anyone to learn that straight away; I fully admit that there are a lot of concepts going on in there (for loops, taking the output of one command as an argument to another, directory listing, pipes, regular expressions, variable assignment, sed, the double-and sign and imagemagick). But there are enough sites around where you can pick up little tips like that, and you don't really have to understand it fully to be able to use it.
Anyway, for the times when it makes more sense to use a GUI (e.g. if you need to select several files based on visual previews): If you select multiple items (holding down CTRL lets you EOR the item just clicked on / items in box just drawn with the existing selection) and then drag them, you will only get prompted once for an action -- everything in the selection will be treated the same. It does mean that if you want to move some files and copy some files, you have to make two separate multiple selections, but it's still more efficient on clicks than being prompted for an action for each file in turn. Furthermore, holding down SHIFT (for move -- you're SHIFTing the files from one place to another), CTRL (for copy -- CTRL is also what you use to add to a selection) or SHIFT + CTRL (for link; two modifier keys are used together for a rare action) as you drag will bypass the menu (which even includes a handy little guide to the shortcut keys, incase you forget) altogether.
That's not true. You can run it as a non-root user if you installed the binary under $HOME.
Anyway, the Mozilla auto-update pulls in a binary pre-compiled by the Mozilla people. Using apt-get or equivalent pulls in a binary pre-compiled by your distro maintainers (except emerge, of course, which pulls in the sources for you to compile locally). I know who I trust more.....
If you want to edit a file, use kwrite. If you want to edit several files, or perhaps copy and paste between files, use kate. (Personally, I think there's something not-quite-right about giving a program a girl's name. Hardware is personified in the feminine, but software is personified in the masculine.)
You can even drag and drop a file into kate (if you hover over kate's taskbar entry, the desktop containing its window will appear), and it will open it as a new document.
Another kate feature that would be nice to have in Konqueror would be if, when you are in overstrike mode in a textarea form element, the cursor would change to a fat block so you could know you were in overstrike mode. As it stands, the cursor is always thin, no matter whether you are in insert or overstrike mode.
20 browser buttons? You fail it! I only have two browser buttons in my taskbar: one for Konqueror, and one for Iceweasel. Tabs, y'see. Mozilla and Opera had them since way back, and Konqueror wasn't so late to the tabbed-browsing party that it had to drink something that tastes like floor cleaner. I also have only one text editor button in my taskbar, even while working on several documents opened from several machines. Kate isn't strictly tabbed as per the browser, but it supports multiple documents with a list down the side.
With all due respect, you are using the wrong tool for the job.
Nobody should really be using drag-and-drop to move, copy or link files on a regular basis. Dragging and dropping is strictly for n00bs. The KDE developers assume (quite reasonably, IMHO) that if you're still using that method of managing your files, rather than doing so directly via the shell, then you probably want a little bit of help with it. (As opposed to Microsoft, who are perfectly happy to keep everyone stuck at n00b level forever; I'm half-surprised they don't charge you extra for a shell. Maybe they do in Vista.) The "cancel" option is there because some mice, and mouse-like devices such as graphics tablets, are a wee bit sensitive; and if you are not insanely careful, then you can end up dragging a file without meaning it and making a bollocks of your system.
What you should be doing instead, if you're a power user, is opening up Konsole and then typing one of the following:
mv file1 file2 -- to move a file
cp file1 file2 -- to copy a file
ln file1 file2 -- to make a hard link to a file -- hard links transcend chroot environments but must be within the same filesystem
ln -s file1 file2 to make a symbolic link to a file -- symbolic links transcend filesystems but break under chroot. If you don't know what one of those is, then use a symbolic link.
Anyone who can send an SMS can learn these basic commands; and once you have done so, there's no reason to fuck around with the GUI for stupidly simple tasks. If you want stabilisers on your bike, bigger kids will laugh at you.
Well, you can always compile a hacked-up Linux driver into Solaris -- it means you will end up with a non-distributable kernel, due to the licence conflict, but since a kernel tends to be tied to a particular box anyway that's a bit less of an issue. If it was that much work to hack the Linux driver into the Solaris kernel, then it may even count as a new work in its own right rather than a derivative work.
My point was that device drivers, specifically faulty and poorly written device drivers are the problem on windows. Obviously device drivers can be done well. Linux shows this fairly well.
Yes, but they're a problem for a reason; and if we could eliminate the reason why device drivers are such a problem on Windows, then we would end up with decent device drivers.
The real reason is that the windows device drivers are often thrown together in a hurry, and lack of sufficient internal comments and proper coding standards makes it all to easy for really nasty bugs to crop up. In a kernel mode driver, nasty bugs are a big problem. The code of many windows drivers is in such a state that the code would never get checked into the Linux kernel.
The fact of the driver source being closed isn't helping anyone. When you write a driver to be checked into The Tree, you know that your code is going to be seen by many competent programmers around the world. When you write a driver to be compiled with a pirate copy of Visual Studio and shipped without Source Code on a CD in the garishly-coloured box of some cheap peripheral destined for a landfill site (and you'll make damn sure of that by never releasing a driver for the next incompatible version of Windows), you just don't take the same level of care.
If a company tried to get similar quality code into the Linux kernel, somebody would work with them to clean it up.
Or just burst into fits of uncontrollable laughter. Or floods of tears.
But no such cleanup ever happens on many Windows drivers. I'm quite sure the same would be true of many kernel mode drivers written for the Mac too.
What I really wonder now, seriously, knowing what bitter experience has taught me, is why the fuck anybody would ever use a piece of software without seeing the Source Code -- let alone pay for it?
The big advantage of drivers for Linux is not that the kernel source is available, but for the vast vast majority of supported devices the source code for the drivers are available.
No, I think that the kernel source (or at least full and accurate API documentation, and it doesn't come fuller or more accurate than the Source Code) is just as important. I've known of products with excellent manufacturer-provided GPL drivers for Linux, and unreliable manufacturer-provided Caged drivers for Windows. If the manufacturer owns the copyright on the GPL Linux driver code, then they are at liberty to make a Caged derivative work for the Windows driver, and vice versa: if they own the copyright on the closed-source driver, then they can open it up to include in Linux. So why are Windows drivers still so flaky?
My guess is that it's the whole culture of closedness around Windows that breeds shoddy drivers. If nobody's ever going to see the Source Code, the programmer can pull all manner of dodgy stunts and make assumptions that wouldn't stand up to scrutiny. You've only got to look at the nightmare that was OpenOffice.org 1.X -- based on the caged StarOffice -- to see that. It wasn't a driver, but the principle is the same.
Besides not paying for the special expensive shiny sticker, in what ways (if any) does Linux fail the technical tests (if any) that would be required for it to be eligible for said sticker?
The claim that "BSD is more free" is a bit like saying "In states where slavery is prohibited, citizens are less free". Certainly the freest citizen in a state where slavery was permitted would be freer than the freest citizen in a state where slavery was forbidden (because one would have the freedom to own slaves, which the other would not). However, the average citizen almost certainly would be freer in the second state, due to all those legally-owned slaves skewing the figures with their zero freedom.
It's my understanding that if you received a BSD-licenced program in Source Code form, you could modify it, distribute it in binary form only with a copy of the licence, and still remain in compliance -- you are passing on permission to do something (distribute the program in Source Code form, as per section 1) that nonetheless is technically impossible (since the recipients don't have the Source Code). I don't know of anything that would oblige you to supply the Source Code to a binary recipient seeking to make use of the permissions granted under the licence. (I hope that one day, the distributors of software will be required by law to supply Source Code -- but I guess that will be awhile coming. After all, they only banned foxhunting three years ago.)
Note that historically, Source Code was practically a given anyway. It was really only in the mid-1980s with the emergence of IBM clones that it became viable to distribute software in binary form only -- before then, even two computers of the same make and model couldn't necessarily be assumed binary-compatible if they had some slight hardware configuration difference (disk / memory capacity, number of terminals, &c).
Laziness here is just a desire for efficiency -- a desire to not have to do the boring repetitive task of asking people who use code in closed projects to contribute that code back to the original project.
True. In this context, laziness actually is a virtue. Blame them damn proddies for making it look otherwise:)
P.S. If you liked the first four lines, please feel free to quote them. With modifications if necessary.
Give it a few years and there'll be a usable decompiler. That is to say, a program which, given a binary as input, produces as its output a file of Source Code in some language which, when compiled, generates a bit-identical binary.
At that point, Caged software will be effectively as dead as slavery was following the invention of the steam engine. Everyone will be able to take Freedoms One and Three by force as easily as they can already take Freedoms Zero and Two by force.
That is the scary bit. With one hand they will make a big deal about your right to a phone call -- and with the other, they will rip out your vocal cords and burst your eardrums.
[I]f Linux is an UNIX, someone ought to get paid for the licensing.
Why?
[W]hy should Linux projects be allowed to copy everything under the sun without having to pay for it?
Why should Linux projects have to pay if they want to copy something that already exists using their own tools and materials? When I bake my own bread, I don't have to pay any money to the big bakeries -- just the cost of the flour, water, sugar, yeast, salt and electricity. RMS, Linus and a growing band of contributors worldwide are using their own efforts to create alternatives to proprietary software -- why should they have to pay anyone anything?
Believe it or not, but the single largest cause of instability in the Windows operating system is device drivers.
Not quite.
There's an operating system which actually has drivers for more devices than Windows (since there are some devices which are supported only in older versions of Windows and some devices which are only supported in newer versions of Windows), and it's not generally noted for its instability. The big difference is that unlike Windows, which is renowned for incomplete and occasionally downright wrong API documentation, this operating system has the most complete and correct API documentation it's possible to provide.
It'd be more correct to say that the single largest cause of instability in the Windows operating system is the unavailability of Source Code to device driver developers.
If someone outside the RIAA wanted to release a song under a licence which specifically permitted copying, sampling, remixing &c., they couldn't do so through iTunes. The iTunes DRM scheme didn't include a way to permit those things even with the blessing of the copyright holder.
Nor was there any way to deal with special issues. For instance, I managed to secure special permission from the band Ocean Colour Scene to copy any recording they ever released for my own use. (This was in 1990 and we were all pissed at the time, but a promise is a promise.) If I were to download something by OCS from iTunes (except I'm unlikely to, unless an Open Source iTunes client comes along) I would be prevented from doing what I was originally given permission to do.
EULA: "Sharing is stealing".
BSD licence: "Sharing is not stealing".
GPL2 = "Not sharing is stealing".
GPL3 = "Not sharing is definitely stealing, but just simply sharing is not necessarily not stealing either".
The BSD licence interpreted literally can permit distribution of binaries without Source Code. The BSD people work their backsides off to ensure that nobody does this. The GNU people decided to write their own licence explicitly forbidding it. There is no other word for this except laziness. On the other hand, taking somebody else's code to use in your Caged software project, as opposed to writing it yourself from scratch, is also laziness; so those who bitch about it are like the pot calling the kettle black.
Slashdot Mirror
I'm talking about the machinery being purpose-designed so that the running totals deliberately do not match the actual votes, but are merely plausible when viewed in the light of what is likely to be known about the actual votes.
You can have your paper ballot (which matches the record of the vote, which can be checked by you or anyone seeking to know how you voted, but doesn't necessarily contribute to the running total for the candidate you thought you were voting for) and drop it in a box; but if those paper ballots aren't going to be counted by hand (because there is a plausible alternative explanation for the discrepancy, i.e. "That is how the people actually voted, and it must be true because the machine says so") then what's the point in having them? If the paper ballots are going to be counted by hand (which will reveal that the election was rigged somehow, but the Powers That Be have all manner of techniques at their disposal to prevent that happening), then what was the point in having all that expensive machinery in the first place when you could just have used paper ballots and hand-counting? And if the paper ballots are going to be counted by machine, then the counting machine can always be rigged to produce totals which do not reflect reality: 500 in the "A" pile under a display reading "390", 480 in the "B" pile under a display reading "600" and 120 in the "C" pile under a display reading "110". If the ballots are deliberately "mistreated" by the machine, so as to give them a slight but randomly-variable curvature, then the discrepancy in sizes of the piles won't be so apparent.
I'm assuming throughout, by the way, that a hand count is certain to be correct. This is a reasonable assumption since an adversarial relationship exists between candidates. That is to say, candidate A and their aides do not trust candidates B, C or their respective aides; candidate B + aides do not trust candidates A, C or their aides; and candidate C + aides don't trust candidates A, B or their aides. As long as the actual candidates and/or their aides do the counting themselves, and all sides are represented, everyone will be watching everyone else like a hawk and no-one will dare to try anything on.
And all these layers of complexity you are introducing add failure modes.
The problem is, you can have a list of how everyone actually voted, and you can even add restrictions that prevent anyone seeing anyone else's vote. (In fact, the surer you are that you can do that, the better.) But if there's even one layer of abstraction between the physical action taken by the voter and what actually gets counted, what's to prevent them from claiming some utterly bogus totals as the "final count"? Just because you know how you voted, that doesn't prove anything about how your vote was recorded. You could have 500 people voting for A, 480 people voting for B and 120 people voting for C; but the totals could be claimed as 390 for A, 600 for B and 110 for C. And nobody would be any the wiser, because the errors are just about within the bounds of plausibility (people often lie to reporters about who they have just voted for / are going to vote for). To discover the error, you would have to check everybody's votes and see that the final totals are not as claimed; and you'd be arrested for Treason long before you got far enough to notice any anomaly.
But the amusement machine industry is self-regulating anyway, because there is an adversarial relationship between punters and casino operators. If you are operating several amusement machines, you won't buy ones that pay out too much because you'll lose money on them; but you won't buy ones that pay out too little because the punters won't play them and you'll still lose money on them. All the regulations are pretty much for show.
There isn't any such adversarial relationship between presiding officers and voters. (But there is an exploitable adversarial relationship between the various candidates in an election: no candidate, nor any of their aides, trusts any of the other candidates or their aides. If the candidates themselves were hand-counting the ballot papers, they'd have no choice but to declare the true count.)
Uh, stop right there. There's no way to have traceability and anonymisation. The two goals are in conflict. Instead, what you have to be able to do is to make sure that errors are detectable. If you know there was one duff ballot in a batch of 2000 (but you don't know which of the 2000 it was or how it should have been filled), you can hold those 2000 out of the final count temporarily. If that error was enough to spoil the whole result, then you repeat the polling from scratch in just that one ward.
Electronic voting IS the problem.
You can't trust what you don't understand, so any voting system needs to be Universally Comprehensible. An electronic system based on Open Source principles -- where the blueprints for the hardware and the listings of the software are available for all to examine -- is still really only comprehensible to a minority of the population. It doesn't satisfy the goal. (In the worst case, you could conceal a deliberate design defect by a combination of hardware and software techniques: anybody examining the hardware and not the software, or vice versa, will miss it.)
Just forget the whole thing as a failed experiment, and go back to pencil and paper and manual counting. Everybody knows what all the possible failure modes are, and how to minimise their effects.
And no, I don't expect anyone to learn that straight away; I fully admit that there are a lot of concepts going on in there (for loops, taking the output of one command as an argument to another, directory listing, pipes, regular expressions, variable assignment, sed, the double-and sign and imagemagick). But there are enough sites around where you can pick up little tips like that, and you don't really have to understand it fully to be able to use it.
Anyway, for the times when it makes more sense to use a GUI (e.g. if you need to select several files based on visual previews): If you select multiple items (holding down CTRL lets you EOR the item just clicked on / items in box just drawn with the existing selection) and then drag them, you will only get prompted once for an action -- everything in the selection will be treated the same. It does mean that if you want to move some files and copy some files, you have to make two separate multiple selections, but it's still more efficient on clicks than being prompted for an action for each file in turn. Furthermore, holding down SHIFT (for move -- you're SHIFTing the files from one place to another), CTRL (for copy -- CTRL is also what you use to add to a selection) or SHIFT + CTRL (for link; two modifier keys are used together for a rare action) as you drag will bypass the menu (which even includes a handy little guide to the shortcut keys, incase you forget) altogether.
That's not true. You can run it as a non-root user if you installed the binary under $HOME.
.....
Anyway, the Mozilla auto-update pulls in a binary pre-compiled by the Mozilla people. Using apt-get or equivalent pulls in a binary pre-compiled by your distro maintainers (except emerge, of course, which pulls in the sources for you to compile locally). I know who I trust more
No there aren't.
.....
Or maybe it's just my well-configured advert-blocking proxy server
You fail it, for trying to compare a savoury snack with a sweet one.
If you want to edit a file, use kwrite. If you want to edit several files, or perhaps copy and paste between files, use kate. (Personally, I think there's something not-quite-right about giving a program a girl's name. Hardware is personified in the feminine, but software is personified in the masculine.)
You can even drag and drop a file into kate (if you hover over kate's taskbar entry, the desktop containing its window will appear), and it will open it as a new document.
Another kate feature that would be nice to have in Konqueror would be if, when you are in overstrike mode in a textarea form element, the cursor would change to a fat block so you could know you were in overstrike mode. As it stands, the cursor is always thin, no matter whether you are in insert or overstrike mode.
20 browser buttons? You fail it! I only have two browser buttons in my taskbar: one for Konqueror, and one for Iceweasel. Tabs, y'see. Mozilla and Opera had them since way back, and Konqueror wasn't so late to the tabbed-browsing party that it had to drink something that tastes like floor cleaner. I also have only one text editor button in my taskbar, even while working on several documents opened from several machines. Kate isn't strictly tabbed as per the browser, but it supports multiple documents with a list down the side.
Nobody should really be using drag-and-drop to move, copy or link files on a regular basis. Dragging and dropping is strictly for n00bs. The KDE developers assume (quite reasonably, IMHO) that if you're still using that method of managing your files, rather than doing so directly via the shell, then you probably want a little bit of help with it. (As opposed to Microsoft, who are perfectly happy to keep everyone stuck at n00b level forever; I'm half-surprised they don't charge you extra for a shell. Maybe they do in Vista.) The "cancel" option is there because some mice, and mouse-like devices such as graphics tablets, are a wee bit sensitive; and if you are not insanely careful, then you can end up dragging a file without meaning it and making a bollocks of your system.
What you should be doing instead, if you're a power user, is opening up Konsole and then typing one of the following:
- mv file1 file2 -- to move a file
- cp file1 file2 -- to copy a file
- ln file1 file2 -- to make a hard link to a file -- hard links transcend chroot environments but must be within the same filesystem
- ln -s file1 file2 to make a symbolic link to a file -- symbolic links transcend filesystems but break under chroot. If you don't know what one of those is, then use a symbolic link.
Anyone who can send an SMS can learn these basic commands; and once you have done so, there's no reason to fuck around with the GUI for stupidly simple tasks. If you want stabilisers on your bike, bigger kids will laugh at you.Feet that have recently been removed from shoes and socks smell.
Feet that have been bare for longer than half an hour don't smell.
Well, you can always compile a hacked-up Linux driver into Solaris -- it means you will end up with a non-distributable kernel, due to the licence conflict, but since a kernel tends to be tied to a particular box anyway that's a bit less of an issue. If it was that much work to hack the Linux driver into the Solaris kernel, then it may even count as a new work in its own right rather than a derivative work.
My guess is that it's the whole culture of closedness around Windows that breeds shoddy drivers. If nobody's ever going to see the Source Code, the programmer can pull all manner of dodgy stunts and make assumptions that wouldn't stand up to scrutiny. You've only got to look at the nightmare that was OpenOffice.org 1.X -- based on the caged StarOffice -- to see that. It wasn't a driver, but the principle is the same.
Besides not paying for the special expensive shiny sticker, in what ways (if any) does Linux fail the technical tests (if any) that would be required for it to be eligible for said sticker?
It's my understanding that if you received a BSD-licenced program in Source Code form, you could modify it, distribute it in binary form only with a copy of the licence, and still remain in compliance -- you are passing on permission to do something (distribute the program in Source Code form, as per section 1) that nonetheless is technically impossible (since the recipients don't have the Source Code). I don't know of anything that would oblige you to supply the Source Code to a binary recipient seeking to make use of the permissions granted under the licence. (I hope that one day, the distributors of software will be required by law to supply Source Code -- but I guess that will be awhile coming. After all, they only banned foxhunting three years ago.)
Note that historically, Source Code was practically a given anyway. It was really only in the mid-1980s with the emergence of IBM clones that it became viable to distribute software in binary form only -- before then, even two computers of the same make and model couldn't necessarily be assumed binary-compatible if they had some slight hardware configuration difference (disk / memory capacity, number of terminals, &c).True. In this context, laziness actually is a virtue. Blame them damn proddies for making it look otherwise
P.S. If you liked the first four lines, please feel free to quote them. With modifications if necessary.
Give it a few years and there'll be a usable decompiler. That is to say, a program which, given a binary as input, produces as its output a file of Source Code in some language which, when compiled, generates a bit-identical binary.
At that point, Caged software will be effectively as dead as slavery was following the invention of the steam engine. Everyone will be able to take Freedoms One and Three by force as easily as they can already take Freedoms Zero and Two by force.
That is the scary bit. With one hand they will make a big deal about your right to a phone call -- and with the other, they will rip out your vocal cords and burst your eardrums.
There's an operating system which actually has drivers for more devices than Windows (since there are some devices which are supported only in older versions of Windows and some devices which are only supported in newer versions of Windows), and it's not generally noted for its instability. The big difference is that unlike Windows, which is renowned for incomplete and occasionally downright wrong API documentation, this operating system has the most complete and correct API documentation it's possible to provide.
It'd be more correct to say that the single largest cause of instability in the Windows operating system is the unavailability of Source Code to device driver developers.
If someone outside the RIAA wanted to release a song under a licence which specifically permitted copying, sampling, remixing &c., they couldn't do so through iTunes. The iTunes DRM scheme didn't include a way to permit those things even with the blessing of the copyright holder.
Nor was there any way to deal with special issues. For instance, I managed to secure special permission from the band Ocean Colour Scene to copy any recording they ever released for my own use. (This was in 1990 and we were all pissed at the time, but a promise is a promise.) If I were to download something by OCS from iTunes (except I'm unlikely to, unless an Open Source iTunes client comes along) I would be prevented from doing what I was originally given permission to do.
EULA: "Sharing is stealing".
BSD licence: "Sharing is not stealing".
GPL2 = "Not sharing is stealing".
GPL3 = "Not sharing is definitely stealing, but just simply sharing is not necessarily not stealing either".
The BSD licence interpreted literally can permit distribution of binaries without Source Code. The BSD people work their backsides off to ensure that nobody does this. The GNU people decided to write their own licence explicitly forbidding it. There is no other word for this except laziness. On the other hand, taking somebody else's code to use in your Caged software project, as opposed to writing it yourself from scratch, is also laziness; so those who bitch about it are like the pot calling the kettle black.
So, which bits of Linux do you consider make it not a "real UNIX" ?