Well, actually, I quite certainly *do* handle the bulk of my dentistry in-house (the general-maintenance bits, at least) and only outsource in the event that I've managed to get myself into a quite serious pickle requiring 3rd-party intervention -- something which hasn't happened since I had my wisdom teeth pulled. Likewise, I do my own general-purpose kernel upgrades/patching/minor bugfixes -- and haven't yet needed to go the 3rd-party-intervention route there.
On Debian, apt *absolutely* can upgrade your kernel and resolve dependencies automatically -- no settings changes needed. It's only Red Hat where they may (or may not) be -- I've never checked.
Hmm -- I'd never heard of QVCS before. Just curious -- are you familiar with Arch?
Ya know, having someone else do your dentistry isn't all that safe either. (I don't recall the statistics, but dentists -- not requiring anesthesiologists' training and licensing -- kill quite a lot of people each year).
Seriously, though... yes, you can override damn near anything you want to wrt apt; it's got a big fancy perl-flavor-syntax config file where just about every aspect of its operation can be controlled.
Yes, yum is like apt in that respect (though, having used both, I vastly prefer apt, even on rpm-based distros -- and several apt repositories are available for Fedora). No idea about kernel updates -- frequently, the rpm autoupdate tools come preconfigured to ignore them, but I've no idea whether that's true of yum.
I work at a startup with a very good IT staff (which has, thus far, been quite capable of supporting ourselves without vendor contracts) but a very low IT budget. We purchase RHES for our customer-deployed servers, and -- hitherto -- have used RH9 for our workstations.
With the RHL line ended, and RHWS outside of our price range (which really doesn't permit for *any* per-system fees on developers' stations), where are we expected to go? Fedora's poor QA (even more than its short lifespan) makes it of questionable value to us. Does Red Hat consider businesses of this type a customer worth keeping?
Note that we decided on RHAS/ES on deployment servers as opposed to SLES for the purpose of standardizing on a single vendor; should we determine to switch to SuSE for our workstation OS, the argument we initially used in deciding to purchase RHES would cease to hold.
Really? Then why can I download Red Hat AS, ES, or WS and install them on any of the computers I own for free
Actually, no, you can't download binaries for AS, ES or WS. (Sources, yes. Binaries, no -- so the process is more like "download onto a separate computer, recompile and install" -- a rather different thing from "download and install").
The subject of this article first fell into the former category, and only after they were ignored moved themselves into the latter.
Personally, I don't think that's so inappropriate -- as one of the deployment/security engineers for my company's product, I'd be damned (not to mention in muddy legal waters, given the sensitivity of the data our app handles) if I let a security-relevant bug report go unresolved for multiple releases.
Folks who screw themselves over that badly (by ignoring security-relevant bug reports) deserve what they get.
Are they saying "home desktop" or "business desktop"?
The business desktop doesn't requires easy administration of new hardware or software -- the configuration is standardized and the software is imaged. Adding new software involves approval from the gods of IT, or it's unsupported or (worse) a major policy violation; software installs aren't something end users do.
The business desktop doesn't require support for little USB puppets that dance to music the user plays.
The business desktop doesn't need the latest 3D games to run out-of-the-box.
The business desktop needs to have a low cost-per-unit and be secure and easy to remotely administer.
Linux is very, very ready for the business desktop -- because the typical "it's not ready for the desktop" arguments just don't apply there. Not only that, but it's actively in use as a business desktop environment in a great many places, from Ernie Ball to the software development startup where I work to municipal governments and all the places where IBM and SuSE have been doing massive rollouts.
Do you think IBM sells to (or is talking to) home users? Of course not. When they say Linux is ready for the desktop, they mean the business desktop, and that's exactly where it is ready, now.
If you don't have any open ports, you're not subject to remote root explots without an app-level security bug in the way (web browser, mail reader, etc). Such things have happened on Linux, but very rarely and (to my knowledge) never beyond proof-of-concept stage to date.
Sure, you still want security updates to work around local exploits (if you have untrusted users logging in) -- but that's what Red Hat's little pulsing RHN update icon is for, or Debian's apt tools, or (etc).
So sure, no distribution is a panacia, but the chances of a security-optimized one on a system being used as a *workstation* being successfully attacked is very low.
(And btw, being a "true blue kernel hacker" is typically rather different from being a security specialist -- generally speaking, kernel-bug-based exploits are local only as opposed to being remotely exploitable).
I've found webpages on which the fonts are so bad the page is unreadable.
WORKSFORME -- and I spend a fair bit of time in front of Mozilla at home, and a fair bit more at work supporting users on RH9-based corporate workstations.
Don't even get me started on printing. Good god, setting up a printer can be hell at the best of times in Linux.
I just set up Fedora Core 1 on a roommate's box. I logged in as root, and there was an icon that launched a graphical print setup program. I told it about her printer (using a few drop-down boxes), it asked if I wanted to print a test page and it Just Worked.
Granted, 6 months ago it was much, much more of a hassle.
...imagine installing a package requiring some 10-20 other packages thru dependencies. If you try to uninstall said package, why don't the dependencies uninstall (as long as nothing else depends on them)?
Debian's aptitude does that perfectly; "deborphan" likewise performs that function.
Almost all of the 802.11b cards I run into are Orinoco-based, and work fine with Linux. I've mostly just seen the Broadcom chipsets used on cards supporting a or g, rarely on b-only cards.
Then again, I'm in the states; perhaps, for whatever reason, there are some availability differences.
Well, if you *ahem* read the article *ahem*, you'd realize that the reason they're taking such measures is because they're actually losing deals because of security -- customers spending more money on patch management and like infrastructure and not having money left to spend on shiny new MS products are the same customers who are liable to decide that they get more bang for their IT dollar going with IBM.
I think this pattern is fairly consistent in the OSS community.
Not just in OSS, either -- the QA tool I mentioned is something I did as company-internal, no-public-release code at a former employer (though IIRC any releases need to be GPL'd on account of it being a derivative of some GPL-encumbered code, such hardly matters if it's not released, right?)
WRT the simple scripting interface, btw, you might want to consider playing with pyglade (an interface to libglade for Python). What it comes together is that you can drag-and-drop your interface together with a GUI builder (Glade), save it as an XML file, write your app logic in Python (an extremely easy-to-read, easy-to-learn, and generally *simple* language while also exceedingly powerful) and tie the two together with a few library calls. It doesn't have the integration between the GUI builder and the code editing tools that VB has -- but it still absolutely kicks ass for throwing together a quick GUI tool fast. And no, with Python you don't need to worry about variable types or semicolons.:)
Libglade is *almost* as easy to use with other languages, too -- like C -- so you can use the same GUI builder with code written in pretty much whatever language you like... very sweet stuff.
Sorry to babble, but like I said I don't think we're in harsh disagreement.
Neither do I -- and frankly, some of your objections are right, particularly as far as home users are concerned. I'm well behind Linux as a corporate desktop environment, though, at my workplace (where it's getting increasingly entrenched) among others.
For that matter, I'm not sure how much we don't agree on, except maybe wrt considering many of the differences between the UNIX way of doing things and the Windows way of doing things unambiguously better ("evolv[ed]") for either party. Conf files, for instance -- arcane though they may often be to the uninitiated -- are easy to distribute, deploy, edit, debug, and so forth, as long as one's put forth the initial effort to gain the prerequisite knowledge. Is this a Good Thing to require end-users to do? Of course not. Is it a Good Thing to have available to (say) corporate IT staff who want to use the more powerful, though arcane, interface? Hell, yes!
Of course, what we all want is a win/win -- an interface that lets end-users click together every piece of their system's configuration easily, and simultaniously gives the seasoned guru all the benefits of more traditional configuration interfaces. (OTOH, who's going to write it? When I'm writing a QA tool which parses its configuration files as Python scripts -- letting the user put some *very* fancy logic in the configuration files themselves -- I'm not about to put a GUI configuration interface into the box; I'm too busy getting all the functionality to work right, the bugs out, and then going on to my next project).
Linux would not exist if there was no Windows. Think hardware economy of scale.
No -- if there were no Windows, there'd still be enough demand for consumer-grade operating systems that *something* would be in that niche. Maybe it'd be OS/2, maybe it'd be Desqview, maybe it'd be MacOS, maybe more money would have gone into making Linux consumer-ready earlier -- but there would be something, because there's enough demand to be sure that the market will provide something.
Likewise, you can be assured that there's enough mass demand for some kind of music that speakers will always be mass-produced... though I can't promise albums with cover art and such.
Also I once spent a highly productive TWO DAYS sitting around watching two CNEs trying to install Oracle 7.2 on Netware 4.1. Arcane doesn't begin to describe the pain those guys went through. I finally got to do my DBA stuff at 16:30 on day 2 - it took me less than an hour...
Part of that's Oracle, though -- it frequently takes me about 6 hours or so to get an install done right (and my company's Oracle DBA takes even longer).
So? Set up opportunistic IPsec and a tunnel is automatically set up between whenever you communicate with someone also so configured, and 3rd parties can even determine the type of packet within the IPsec wrapper -- much less block based on it.
Converting everything to lowercase before comparing is "a bunch" of code? Well, I guess there's unicode to worry about.
Not only that, but if you notice, Windows doesn't convert everything to lowercase -- rather, it preserves the original case of a file (such that listings etc show the original case) but makes it accessible via alternate representations. (BTW, it's not "converting everything to lowercase" that's common practice -- there are case-insensitive string compare operations on both platforms, but software developed elsewhere generally won't use them unless the folks doing the Windows ports actually manage to remember that it's an issue). Hence, one can't merely discard case information if it might need to be displayed to the user.
Typically, though, we're not just talking about "comparing". A rule restricting/foobar/baz typically won't be written to match that exact string, but rather as a regular expression -- which means that ones' regex compiler needs to be instructed to operate in case-insensitive mode (which, by the way, typically produces a slower-to-evaluate regex).
Thus, if you do the relevant calls to pull a directory listing, you can't assume that everything's pre-normalized. You can't do a bunch of neat tricks using filenames' hash values that might otherwise be possible without extra preprocessing.
Besides, you can just as easily argue that Unix is more prone to "security problems" because the sysadmin might fat finger the shift key
Hasn't happened to me in practice yet, and I've been doing UNIX for years; thus, I'm inclined to put this one into the "silly theoretical arguments people make without experience to back them" bin. Keep in mind, the issue I mentioned (denormalization of path names complicating pattern-matching) is a real software design issue, and has caused *real* security holes. (Likewise wrt file extensions -- there's been *real* software in the field that has evaluated file.cgi but displayed the text of file.CgI, which presumably isn't The Right Thing on Windows).
How is "fat fingering the shift key" any different than typo'ing out the wrong letter? Same ominous security implications, but the latter one is just as much user error (and a lot more common!), and I don't see anyone arguing that an OS redesign is ncessary to fix it.
I'm talking about how at a very high level -- that is, at the requirements-identification stage -- the design of Windows is user-centric. Indeed, MS sometimes uses "we brought these {students,teachers,whoever} in to help design our product"-style marketing copy.
Of course I don't mean to imply that the actual software design is done by a non-professional.
Yah, but if you know up-front that you'll be running it on Linux, and bring a copy of the SANE supported-hardware list along when you're shopping, there's no problem at all.
If you want to impulse-buy without doing your homework, yes, you might well have problems. That said, though, frequently the lower-priced hardware that's well-supported on Linux is often better quality than the like-priced hardware that isn't, so buying supported hardware is ofter a Good Thing for reasons other than OS flexibility.
I do have one other observation to make. Windows is designed by users for users. Users insist on having the guts hidden away where they're hard to access. They'll insist on a case-insensitive CLI despite the incurred security problems, compatibility issues and bugs. Until this attitude becomes a little more programmer-friendly, it really is difficult to imagine a release of Windows that isn't hard to fix, insecure and bug-ridden.
(Think that I'm kidding about the "security problems and bugs" bit related to case sensitivity? Look at some of the changes Tomcat had to implement to operate securely on Windows -- basically, there's a whole bunch of extra code needed to be sure that a rule restricting access to/foobar/baz also applies to/FoObAR/baz; such vulnerabilities are far from uncommon).
Anyhow, what I'm saying here is that there really is a point to some of the tradeoffs that were made -- well, good points on either side. The UNIX developers-first design philosophy makes it easier to write reliable and secure software (not that all UNIX software *is* reliable or secure, by any means, just that not all of the same opportunities to screw it up exist), while the Windows user-centric philosophy encourages software that's easy to use -- until it breaks down or someone tries to break it down. Sometimes that's the right thing to do -- but don't dismiss any other approach as wrong just because it's not the one you're used to.
Just about any 802.11b hardware; it's the a/b/g stuff that doesn't have Linux drivers available (typically due to FCC regs not permitting release of programming specs for software radios which can be programmed to use bands they legally shouldn't be on -- which the a/b/g cards are).
5) allow voter to enter their bar code number into a web form and display their ballot choices. The voter can then verify that their choices were properly recorded, and any changes can be proven by the checksum held by the voter
Is this web form something they can access from outside the physical polling place?
If so, that means they can use it to prove who they voted to to a third party, and thus their vote can be bought or coerced.
This can only be done if the receipt the voter takes home can't be used to determine who they voted for -- otherwise vote-selling and related fraud is enabled.
Now, if the receipt the voter takes home contains a *signature* of the data on receipt they dropped in the box (such that it can't be used to determine who they voted for but can be used to determine that their vote hasn't been tampered with), that's a different story.
Personally, though, I think that's overkill -- putting a chain-signed receipt into a lockbox is Good Enough For Me.
(chaining digital signatures, fyi, is a way to make it very hard to modify just one -- because the next receipt also happens to contain a signature of the previous one).
I would expect that they'd allow me to inspect the software running on the machine, and compare it to that same software compiled myself (with the same compiler/libc/whatever). Not during the election process itself, of course, but immediately before or afterwards, on a voting machine or two which I randomly select. (Yes, I'd have to make arrangements beforehand -- I have no doubt they wouldn't want somebody they don't know waltzing in without notice -- but if I ask the right folks nicely beforehand, I'm sure arrangements could be made).
Granted, most of my experience dealing with local government is of the small-town-city-council variety... but I'm quite sure that if I wanted to audit a voting machine, it could be done.
Slashdot Mirror
Well, actually, I quite certainly *do* handle the bulk of my dentistry in-house (the general-maintenance bits, at least) and only outsource in the event that I've managed to get myself into a quite serious pickle requiring 3rd-party intervention -- something which hasn't happened since I had my wisdom teeth pulled. Likewise, I do my own general-purpose kernel upgrades/patching/minor bugfixes -- and haven't yet needed to go the 3rd-party-intervention route there.
On Debian, apt *absolutely* can upgrade your kernel and resolve dependencies automatically -- no settings changes needed. It's only Red Hat where they may (or may not) be -- I've never checked.
Hmm -- I'd never heard of QVCS before. Just curious -- are you familiar with Arch?
Ya know, having someone else do your dentistry isn't all that safe either. (I don't recall the statistics, but dentists -- not requiring anesthesiologists' training and licensing -- kill quite a lot of people each year).
Seriously, though... yes, you can override damn near anything you want to wrt apt; it's got a big fancy perl-flavor-syntax config file where just about every aspect of its operation can be controlled.
Yes, yum is like apt in that respect (though, having used both, I vastly prefer apt, even on rpm-based distros -- and several apt repositories are available for Fedora). No idea about kernel updates -- frequently, the rpm autoupdate tools come preconfigured to ignore them, but I've no idea whether that's true of yum.
I work at a startup with a very good IT staff (which has, thus far, been quite capable of supporting ourselves without vendor contracts) but a very low IT budget. We purchase RHES for our customer-deployed servers, and -- hitherto -- have used RH9 for our workstations.
With the RHL line ended, and RHWS outside of our price range (which really doesn't permit for *any* per-system fees on developers' stations), where are we expected to go? Fedora's poor QA (even more than its short lifespan) makes it of questionable value to us. Does Red Hat consider businesses of this type a customer worth keeping?
Note that we decided on RHAS/ES on deployment servers as opposed to SLES for the purpose of standardizing on a single vendor; should we determine to switch to SuSE for our workstation OS, the argument we initially used in deciding to purchase RHES would cease to hold.
Really? Then why can I download Red Hat AS, ES, or WS and install them on any of the computers I own for free
Actually, no, you can't download binaries for AS, ES or WS. (Sources, yes. Binaries, no -- so the process is more like "download onto a separate computer, recompile and install" -- a rather different thing from "download and install").
The subject of this article first fell into the former category, and only after they were ignored moved themselves into the latter.
Personally, I don't think that's so inappropriate -- as one of the deployment/security engineers for my company's product, I'd be damned (not to mention in muddy legal waters, given the sensitivity of the data our app handles) if I let a security-relevant bug report go unresolved for multiple releases.
Folks who screw themselves over that badly (by ignoring security-relevant bug reports) deserve what they get.
Simple question:
Are they saying "home desktop" or "business desktop"?
The business desktop doesn't requires easy administration of new hardware or software -- the configuration is standardized and the software is imaged. Adding new software involves approval from the gods of IT, or it's unsupported or (worse) a major policy violation; software installs aren't something end users do.
The business desktop doesn't require support for little USB puppets that dance to music the user plays.
The business desktop doesn't need the latest 3D games to run out-of-the-box.
The business desktop needs to have a low cost-per-unit and be secure and easy to remotely administer.
Linux is very, very ready for the business desktop -- because the typical "it's not ready for the desktop" arguments just don't apply there. Not only that, but it's actively in use as a business desktop environment in a great many places, from Ernie Ball to the software development startup where I work to municipal governments and all the places where IBM and SuSE have been doing massive rollouts.
Do you think IBM sells to (or is talking to) home users? Of course not. When they say Linux is ready for the desktop, they mean the business desktop, and that's exactly where it is ready, now.
If you don't have any open ports, you're not subject to remote root explots without an app-level security bug in the way (web browser, mail reader, etc). Such things have happened on Linux, but very rarely and (to my knowledge) never beyond proof-of-concept stage to date.
Sure, you still want security updates to work around local exploits (if you have untrusted users logging in) -- but that's what Red Hat's little pulsing RHN update icon is for, or Debian's apt tools, or (etc).
So sure, no distribution is a panacia, but the chances of a security-optimized one on a system being used as a *workstation* being successfully attacked is very low.
(And btw, being a "true blue kernel hacker" is typically rather different from being a security specialist -- generally speaking, kernel-bug-based exploits are local only as opposed to being remotely exploitable).
WORKSFORME -- and I spend a fair bit of time in front of Mozilla at home, and a fair bit more at work supporting users on RH9-based corporate workstations.
Don't even get me started on printing. Good god, setting up a printer can be hell at the best of times in Linux.
I just set up Fedora Core 1 on a roommate's box. I logged in as root, and there was an icon that launched a graphical print setup program. I told it about her printer (using a few drop-down boxes), it asked if I wanted to print a test page and it Just Worked.
Granted, 6 months ago it was much, much more of a hassle.
Debian's aptitude does that perfectly; "deborphan" likewise performs that function.
Almost all of the 802.11b cards I run into are Orinoco-based, and work fine with Linux. I've mostly just seen the Broadcom chipsets used on cards supporting a or g, rarely on b-only cards.
Then again, I'm in the states; perhaps, for whatever reason, there are some availability differences.
Well, if you *ahem* read the article *ahem*, you'd realize that the reason they're taking such measures is because they're actually losing deals because of security -- customers spending more money on patch management and like infrastructure and not having money left to spend on shiny new MS products are the same customers who are liable to decide that they get more bang for their IT dollar going with IBM.
I think this pattern is fairly consistent in the OSS community.
:)
Not just in OSS, either -- the QA tool I mentioned is something I did as company-internal, no-public-release code at a former employer (though IIRC any releases need to be GPL'd on account of it being a derivative of some GPL-encumbered code, such hardly matters if it's not released, right?)
WRT the simple scripting interface, btw, you might want to consider playing with pyglade (an interface to libglade for Python). What it comes together is that you can drag-and-drop your interface together with a GUI builder (Glade), save it as an XML file, write your app logic in Python (an extremely easy-to-read, easy-to-learn, and generally *simple* language while also exceedingly powerful) and tie the two together with a few library calls. It doesn't have the integration between the GUI builder and the code editing tools that VB has -- but it still absolutely kicks ass for throwing together a quick GUI tool fast. And no, with Python you don't need to worry about variable types or semicolons.
Libglade is *almost* as easy to use with other languages, too -- like C -- so you can use the same GUI builder with code written in pretty much whatever language you like... very sweet stuff.
And have a good weekend yourself!
Sorry to babble, but like I said I don't think we're in harsh disagreement.
Neither do I -- and frankly, some of your objections are right, particularly as far as home users are concerned. I'm well behind Linux as a corporate desktop environment, though, at my workplace (where it's getting increasingly entrenched) among others.
For that matter, I'm not sure how much we don't agree on, except maybe wrt considering many of the differences between the UNIX way of doing things and the Windows way of doing things unambiguously better ("evolv[ed]") for either party. Conf files, for instance -- arcane though they may often be to the uninitiated -- are easy to distribute, deploy, edit, debug, and so forth, as long as one's put forth the initial effort to gain the prerequisite knowledge. Is this a Good Thing to require end-users to do? Of course not. Is it a Good Thing to have available to (say) corporate IT staff who want to use the more powerful, though arcane, interface? Hell, yes!
Of course, what we all want is a win/win -- an interface that lets end-users click together every piece of their system's configuration easily, and simultaniously gives the seasoned guru all the benefits of more traditional configuration interfaces. (OTOH, who's going to write it? When I'm writing a QA tool which parses its configuration files as Python scripts -- letting the user put some *very* fancy logic in the configuration files themselves -- I'm not about to put a GUI configuration interface into the box; I'm too busy getting all the functionality to work right, the bugs out, and then going on to my next project).
Okay, 'nuff rambling for now.
Linux would not exist if there was no Windows. Think hardware economy of scale.
No -- if there were no Windows, there'd still be enough demand for consumer-grade operating systems that *something* would be in that niche. Maybe it'd be OS/2, maybe it'd be Desqview, maybe it'd be MacOS, maybe more money would have gone into making Linux consumer-ready earlier -- but there would be something, because there's enough demand to be sure that the market will provide something.
Likewise, you can be assured that there's enough mass demand for some kind of music that speakers will always be mass-produced... though I can't promise albums with cover art and such.
Also I once spent a highly productive TWO DAYS sitting around watching two CNEs trying to install Oracle 7.2 on Netware 4.1. Arcane doesn't begin to describe the pain those guys went through. I finally got to do my DBA stuff at 16:30 on day 2 - it took me less than an hour...
Part of that's Oracle, though -- it frequently takes me about 6 hours or so to get an install done right (and my company's Oracle DBA takes even longer).
So? Set up opportunistic IPsec and a tunnel is automatically set up between whenever you communicate with someone also so configured, and 3rd parties can even determine the type of packet within the IPsec wrapper -- much less block based on it.
Converting everything to lowercase before comparing is "a bunch" of code? Well, I guess there's unicode to worry about.
/foobar/baz typically won't be written to match that exact string, but rather as a regular expression -- which means that ones' regex compiler needs to be instructed to operate in case-insensitive mode (which, by the way, typically produces a slower-to-evaluate regex).
Not only that, but if you notice, Windows doesn't convert everything to lowercase -- rather, it preserves the original case of a file (such that listings etc show the original case) but makes it accessible via alternate representations. (BTW, it's not "converting everything to lowercase" that's common practice -- there are case-insensitive string compare operations on both platforms, but software developed elsewhere generally won't use them unless the folks doing the Windows ports actually manage to remember that it's an issue). Hence, one can't merely discard case information if it might need to be displayed to the user.
Typically, though, we're not just talking about "comparing". A rule restricting
Thus, if you do the relevant calls to pull a directory listing, you can't assume that everything's pre-normalized. You can't do a bunch of neat tricks using filenames' hash values that might otherwise be possible without extra preprocessing.
Besides, you can just as easily argue that Unix is more prone to "security problems" because the sysadmin might fat finger the shift key
Hasn't happened to me in practice yet, and I've been doing UNIX for years; thus, I'm inclined to put this one into the "silly theoretical arguments people make without experience to back them" bin. Keep in mind, the issue I mentioned (denormalization of path names complicating pattern-matching) is a real software design issue, and has caused *real* security holes. (Likewise wrt file extensions -- there's been *real* software in the field that has evaluated file.cgi but displayed the text of file.CgI, which presumably isn't The Right Thing on Windows).
How is "fat fingering the shift key" any different than typo'ing out the wrong letter? Same ominous security implications, but the latter one is just as much user error (and a lot more common!), and I don't see anyone arguing that an OS redesign is ncessary to fix it.
I'm talking about how at a very high level -- that is, at the requirements-identification stage -- the design of Windows is user-centric. Indeed, MS sometimes uses "we brought these {students,teachers,whoever} in to help design our product"-style marketing copy.
Of course I don't mean to imply that the actual software design is done by a non-professional.
Yah, but if you know up-front that you'll be running it on Linux, and bring a copy of the SANE supported-hardware list along when you're shopping, there's no problem at all.
If you want to impulse-buy without doing your homework, yes, you might well have problems. That said, though, frequently the lower-priced hardware that's well-supported on Linux is often better quality than the like-priced hardware that isn't, so buying supported hardware is ofter a Good Thing for reasons other than OS flexibility.
I do have one other observation to make. Windows is designed by users for users. Users insist on having the guts hidden away where they're hard to access. They'll insist on a case-insensitive CLI despite the incurred security problems, compatibility issues and bugs. Until this attitude becomes a little more programmer-friendly, it really is difficult to imagine a release of Windows that isn't hard to fix, insecure and bug-ridden.
/foobar/baz also applies to /FoObAR/baz; such vulnerabilities are far from uncommon).
(Think that I'm kidding about the "security problems and bugs" bit related to case sensitivity? Look at some of the changes Tomcat had to implement to operate securely on Windows -- basically, there's a whole bunch of extra code needed to be sure that a rule restricting access to
Anyhow, what I'm saying here is that there really is a point to some of the tradeoffs that were made -- well, good points on either side. The UNIX developers-first design philosophy makes it easier to write reliable and secure software (not that all UNIX software *is* reliable or secure, by any means, just that not all of the same opportunities to screw it up exist), while the Windows user-centric philosophy encourages software that's easy to use -- until it breaks down or someone tries to break it down. Sometimes that's the right thing to do -- but don't dismiss any other approach as wrong just because it's not the one you're used to.
What's their motivation? Your hardware is suddenly available to more customers, and your driver is still binary-only... what's not to like?
Just about any 802.11b hardware; it's the a/b/g stuff that doesn't have Linux drivers available (typically due to FCC regs not permitting release of programming specs for software radios which can be programmed to use bands they legally shouldn't be on -- which the a/b/g cards are).
5) allow voter to enter their bar code number into a web form and display their ballot choices. The voter can then verify that their choices were properly recorded, and any changes can be proven by the checksum held by the voter
Is this web form something they can access from outside the physical polling place?
If so, that means they can use it to prove who they voted to to a third party, and thus their vote can be bought or coerced.
This can only be done if the receipt the voter takes home can't be used to determine who they voted for -- otherwise vote-selling and related fraud is enabled.
Now, if the receipt the voter takes home contains a *signature* of the data on receipt they dropped in the box (such that it can't be used to determine who they voted for but can be used to determine that their vote hasn't been tampered with), that's a different story.
Personally, though, I think that's overkill -- putting a chain-signed receipt into a lockbox is Good Enough For Me.
(chaining digital signatures, fyi, is a way to make it very hard to modify just one -- because the next receipt also happens to contain a signature of the previous one).
I would expect that they'd allow me to inspect the software running on the machine, and compare it to that same software compiled myself (with the same compiler/libc/whatever). Not during the election process itself, of course, but immediately before or afterwards, on a voting machine or two which I randomly select. (Yes, I'd have to make arrangements beforehand -- I have no doubt they wouldn't want somebody they don't know waltzing in without notice -- but if I ask the right folks nicely beforehand, I'm sure arrangements could be made).
Granted, most of my experience dealing with local government is of the small-town-city-council variety... but I'm quite sure that if I wanted to audit a voting machine, it could be done.