It seemed to me that i810 was fine up until Intel got involved with it. I have an unusual chipset (855GM on a desktop with no LVDS output), and new versions of Intel drivers keep totally failing to work on it in various exciting ways. Before Intel engineers started showing up on xorg bugzilla (i.e. when the module was called 'i810' instead of 'intel'), this happened once in a blue moon and I got responsive, polite fixes reasonably quickly. Now, it happens constantly, and I have to beat the engineers over the heads just to stop them closing a bug with comments which more or less translate to "we can't be bothered, sod off". When bugs do get fixed, it tends to take them a respectable fraction of a year to do it.
Interacting with Intel engineers on xorg bugzilla has sort of made me yearn for the days when GNU/Linux hardware drivers were crappy, desperate efforts slapped together with enormous difficulty without any specifications to work from.
Linux desktops get 95% or more of their software from a single, trusted source, and savvy users will not click on random executables that they download. Windows users are forced to run executables they download from web sites without really having a way to verify that the source is trusted. I have to do this all the time on Windows; even though I consider myself reasonably savvy, there's simply no way around third-party software if you want to get your work done. That right there constitutes the largest difference between the two in terms of desktop security IMHO.
"Opening an infected file," if that file is a data file opened by an already-installed program, and being compromised, indicates that the already-installed program has a vulnerability. Linux security advisories consider these vulnerabilities serious business (they make up the majority of Linux security patches), and have a centralized mechanism for solving them, neither of which seem to be true on Windows in my experience.
Servers, by their nature, process requests from anyone anywhere in the world. There's no need to "trick" anyone into clicking on something to get your foot in the door; you can run any CGI program with any input you like anytime you like. The CGI program has to be vulnerable, just as a user program has to be vulnerable to the "infected data file" that you're putting into it. I think the two are different (not really one more vulnerable than the other; they're just not immediately comparable), but saying, "once you've gotten the exploit onto a consumer PC, they're more readily vulnerable than a server is once you've gotten the exploit there, therefore desktops are easier to attack" is just as one-sided as saying, "it's much easier to get access to a server to exploit it than it is to get the exploit onto a desktop PC, therefore servers are easier to attack."
You do realize that using Linux to host a world-accessible web site based on custom PHP scripts, and using Windows to browse the internet as an end-user, and having them both get broken into is not an apples-to-apples comparison?
If you were using IIS to host a web site with a boatload of custom ASP scripts, and that got broken into, I would not be surprised. If that breakin installed an exploit which invaded your up-to-date-with-security-patches Linux/Firefox machine when you browsed the site from Linux, that would be serious news (and an indication that the two were comparably vulnerable to attack).
I agree with the poster who said you are blaming the victim. ISO manages a process and counts votes. Nothing more. Nothing less. There is nobody at ISO with the authority to say: "Well this standard passed through the procedures but we can't allow it through, so we'll change the procedures." After the fact it might make sense to change the procedures but it would be totally wrong to change the rules of the game in the middle of a standardization process.
Well, that's a problem with ISO then. There _is_ a proper balance to be struck between "we counts the votes and we reports the totals, questioning the totals is not permitted for people in my position, have a nice day" and "the vote may have passed but I don't like it, nyah nyah." The people in charge of implementing the ISO procedures should keep firmly in mind that the end goal is _not_ to follow every procedure to the letter no matter how badly distorted the outcome, but to use the procedure as a means to the end. The end is to ratify standards which have broad support in the technical community; if the voting procedures are showing strong evidence of being blatantly rigged -- which they are -- the ISO leadership needs to say so, and deal with the problem. That's not arbitrary. That's taking responsibility. At most organizations it's required for anyone above the level of assistant manager.
It's not clear to me whether the ISO leadership is also corrupted by Microsoft, and is letting the irregularities go unchallenged on a nudge-nudge-wink-wink basis, or if someone at ISO honestly believes that it's not their place to call out blatant corruption when they see it, but either one is a black eye for ISO.
My best hope was a Google search for the error that I was experiencing and hope that copying the listed instructions verbatim would solve the problem. If it didn't, it usually left the computer in worse shape than when I began. One might argue that I shouldn't be giving my computer instructions that I don't understand, but the alternative is reinstalling anyway.
Did you ever consider attempting to learn what the instructions google provided you were going to do, and then entering them into your computer?
Hogswallop. Deliberate features that happen to allow the circumvention of security are not as common as buffer overflows, but they certainly happen, and serious security people consider them to be vulnerabilities (what else would they be?). ActiveX is one. Debian categorizes them as "design flaws" in their advisories. To say that it's not a vulnerability "in the traditional sense", or recommend that people disable the impossible-to-secure system "when you aren't using it", is a bunch of crap.
It's true of all hardware that if you have physical access, then you can do whatever you want with it anyway.
That's certainly not true. To use one of a huge multitude of examples, students at my school had physical access to the machines in the computer lab, but it would definitely be a problem if they installed a keylogger to sniff other students' passwords.
Paul Ducklin, head of technology for security firm Sophos, said the security hole found by Boileau was not a vulnerability or bug in the traditional sense, because the ability to use the Firewire port to access a computer's memory was actually a feature of Firewire.
"If you have a Firewire port, disable it when you aren't using it," Ducklin said.
"That way, if someone does plug into your port unexpectedly, your side of the Firewire link is dead, so they can't interact with your PC, legitimately or otherwise."
"You see, this serious security problem was designed in from the start, so therefore... it's not a problem! Ta-da!"
I've done it before. I had a Dell PE 2950 server with an internal PERC 5 RAID controller that got intermittent data errors with the standard Debian kernel... I poked around on the mailing lists and found that there was a workaround (a one-line kernel change that substantially reduced the aggressiveness with which the driver would load down the RAID controller). I made it, ran a disk benchmark for several days without a hitch, and crossed my fingers and put it into production. Thankfully, the problem never recurred, and a firmware update several months later resolved the problem entirely, so that I could switch back to Debian-provided kernels and get easy security updates and peace of mind again.
Was I happy about doing it? Absolutely not. I would have much, much preferred to have a kernel running on my production system that I had _not_ edited the source to by hand:-). But the system absolutely needed to go into production, and that was the most straightforward way I could see to make it happen.
This sort of problem doesn't seem to be unique to Linux systems; I've seen Windows admins go through exactly the same sort of heartache, but their only recourse seems to be to beg the vendor for a fix or to, well, take it and like it. This is the number one thing I like about administrating Linux servers -- no software problem is genuinely unsolvable, and it's up to me to make the determination whether it's worth the investment of time and risk to make the fix. In this case, it was nerve-wracking, but ultimately being able to make this fix saved my ass.
And again, WHAT IS IT? Sure, there is a LOT of code out there. But show me the OSS software out there that screams, "Wow! That's unbelievably clever!" And sure, there's some *popular* OSS software, but as I pointed out in another post, popular does not mean innovative.
So far, I haven't seen any posts with a long list of examples of OSS innovation. Just screaming that there "just has" to be a lot of innovation... look at all the lines of code!
Are you kidding? Or are you just not familiar enough with OSS to know what innovative software is out there?
perl
python
bittorrent
apt/aptitude (and whole-system package management in general)
fuse
git
valgrind
iptables
There's plenty of innovation on the closed-source side, too (Incredibuild/XGE is actually the first thing that comes to mind). But dismissing OSS as just copying the work of others is simple ignorance.
make it so that when you try to fix a small problem (say upgrade or install some small application) that you don't end up with having to upgrade more and more of the system.
Suggestion number one: You're running the wrong version of Linux if this is what you want. You seem to be using a continuously updated version (like Debian unstable), which means that, well, it's continuously updated. If you want to stick with what you've got and not be bothered with frequent upgrades, you should be using Debian stable (not sure what the Ubuntu equivalent terminology is).
Suggestion number two: For complex operations, use aptitude, not apt-get. It's much better at sorting out what to install, upgrade, and remove in order to get what you probably want (and you can tell it what to do differently if it gets it wrong). apt-get just sort of guesses and is only good for very simple operations.
48 upgraded, 13 newly installed, 10 to remove and 843 not upgraded.
Suggestion number three: If you are going to run a continuously updated version of Linux, don't let it get this far behind. Do 'aptitude dist-upgrade' from time to time. You're surely missing a few security updates (as well as suffering from the every-install-needs-a-partial-upgrade problem you expressed unhappiness about).
- stop switching kernel API's around every few releases, release a binary driver spec and stick to it
So that those of us that want to get some work done can just concentrate on that and leave the 'information wants to be free' bs to others
Suggestion number four: Don't tell the kernel developers how to do their jobs:-). The ABI isn't even stable within a single kernel version on a single architecture; structures change depending on the kernel config, for example. Having to support a stable driver ABI would require a massive change to the way the kernel is structured, and the new way would carry all sorts of new difficulties for open-source driver writers without significant benefits.
Out of curiosity, what work are you trying to get done that's made more difficult by the lack of a stable ABI for Linux drivers?
FWIW, I've seen plenty of expensive support contracts that add up to "the right to talk to clueless support people who deny that your problem exists" in my time. I have, though, also heard a few conversations between my boss and our vendors of the nature, "Look, we're paying you guys X thousand dollars for support, and we're having a problem and you're not bloody fixing it. We're going to start looking at other vendors because you're not working out for us." In a lot of those situations, we got to talk to someone who knew what they were doing and/or could fix our problem reasonably quickly. It might have helped that he wasn't bluffing; that he actually had the power and was pissed enough to switch vendors because our current one was falling down on the job (which they were).
Besides, my understanding of Sab-Ox is that it makes spreadsheets an absolute minefield - because spreadsheets make it trivially easy to change things, save it under alternative names and otherwise mess about with the numbers with no audit trail.
No, computers make that easy. The only "audit trail" that ever exists is what gets backed up to a trusted location and kept offline under literal lock and key. As long as the files are on an untrusted computer (read: anyone's), anyone with the proper skills can change the numbers anywhere in them, save them under alternate names, and generally do whatever they like. Even if it's true that you've figured out a way to totally, 100% prevent Excel from presenting any interface which makes it possible to cook the books, any knowledgeable hacker with a hex editor and a few days (possibly hired by an unscrupulous middle manager with a few millions in illegal transactions to hide) can make a shredded mess out of your "audit trail."
My former manager has apparently succeeded in making a specific spreadsheet compliant - that was with a team of a few people basically reskinning Excel with VB macros and the like so the user interface looked similar but kept audit trails, enforced per-user access control on parts of the spreadsheet and removed functionality which was completely at odds with the regulations.
Oh, you used VB macros? Never mind about what I said before. It must be bulletproof.
Thank you. I inherited a single Gentoo server at work once, and I had assumed for all the intervening years that it was only my own ignorance that had made it impossible to do any maintenance to it. I simply assumed that no one would have set up a server based on a distribution so obviously unsuited as a production server, and so there must have been possibilities I was unaware of that would make it easy to maintain once in production.
I limped it along until the happy day when it was retired, but until this day I always assumed that the problem was me.
You know that Linux already does what you're asking for, for these bullet points at least:
1) The Official Apple "Software update" that updates OSX and Apple Apps. 3) The Firefox/Thunderbird updater 4) Dozens of updaters for individual apps like TextMate and OSS software 5) Updaters for OSS packages (Fink/darwinports)
... and has for years, right? I'm not trying to be snide, but good Linux distributions have been upgrading all their software since long before there was a Firefox or a Mac OSX. You're right that it's a lot better that way:-).
At the same time, Smith was having Microsoft's lawyers figure out how many of its patents were being infringed by free and open-source software. Gutierrez refuses to identify specific patents or explain how they're being infringed, lest FOSS advocates start filing challenges to them.
IOW, we've learned from the SCO lawsuit how to handle these situations. Make a big stink in the press, share as few of the details as possible, and ride the wave of FUD to the promised land.
It's not just that -- there's a whole little gang of design flaws responsible here, each of them egging the others on like adolescent boys with dangerous tools at their disposal. To all of the people saying, "well, it has to be that way because Microsoft has 5 billion trillion gazillion apps to support and they're not responsible for third party blah blah blah," I say this: No. Shut up. Linux vendors release updates for a body of software that is a massive superset of what Windows Update covers, often with a tiny fraction of the QA manpower, and problems like this are still quite rare. Why? Well, let's take a look at design flaws that caused the vulnerability Chen was solving:
Windows handles OS extensions by loading DLLs into Explorer's address space, instead of introducing a layer of separation and interacting with a separate process (a design which would have allowed graceful handling of arbitrary errors in the extension).
It's apparently easy to accidentally construct code which Explorer believes is a usable shell extension, and likewise impossible to add checks to Explorer such that it will only use, as a shell extension, something which was deliberately intended to be a shell extension. Stop and think about that for a long, long second. That's shockingly shitty design even for Microsoft. Chen blames the application programmers (saying, "lots of people mess up IUnknown::QueryInterface" and linking to a page containing what appears to be an excerpt from the Nag Hammadi scriptures in the original Coptic), instead of realizing that if professional programmers show a consistent pattern of making particular mistakes interacting with an interface, the interface is probably poorly designed.
As you mention, this seems like a design flaw in the implementation of threading, DLL handling, and process exit. The same construct in Linux does not hang -- it waits until the thread terminates, and then exits normally:
I can feel Chen's pain -- it must have been awful trying to botch around the fallout from the first two stupidities, and then getting screwed by the third. I don't think that lets Microsoft off the hook at all, though. The responsibility for the hacked-together, poorly-planned, teetering heap of an OS that they now have to support (at tremendous cost) lies nowhere but at their own metaphorical feet.
Considering that the entire point of the article is the discovery that the airplane's computer system is poorly designed, I'd say it was less "fortunately" as in "by random luck, it turns out the systems are separate" and more "fortunately" as in "well, as luck would have it, they're not total idiots, and they made the systems separate."
It's not unheard-of, after all, for software failures to cascade from trivial areas to more vital areas in passenger craft.
Again, lack of tool support, not a problem with the concept. (In the case of FTP servers, you almost HAVE to forget about the alternate streams (or serialize them) because most other filesystems don't support them.
It's not "lack of tool support," it's the accepted definition of the word "file". A file as a single variable-sized series of bytes is an abstraction that's been around for decades; suddenly there are people who have arbitraily redefined it and are complaining about every program on earth is failing to support their new, now-different abstraction.
Why is it better for every program in the world that reads files to add an extra layer of "streams" complexity, than it is for the few selected programs that need multiple bytestreams to implement them via a file format?
Hell, do whatever you want with your own computing equipment -- but don't complain when you upload your files to a web server and they lose their icons (or whatever it is that they're storing in their alternate streams). That problem is not going to go away no matter how much you ask for it to.
(Plus X-11 and related display technologies reverse the terms anyhow, so they really have no meaning.
I applaud your clarity of reason, sir!
"Normally, your boss pays you, but when you buy him a Christmas present, you're effectively paying him. So you can see that this whole 'employee' thing is pretty meaningless."
"Cheap, unpowered speakers normally emit sound, but if you plug them into the microphone jack, you'll be able to record. It just goes to show you what a bourgeoisie lie this so-called 'stereo equipment' is."
"I flew from New York to LA last week. Now I'm flying back, so as you can see names of cities have no meaning."
I prefer digraphs -- data/command comes from here and goes there.)
Oh, I see -- you don't like words that describe things that are different at some times than they are at others. You'd rather use digraphs. Now I understand.
"I connected to the mail Ph using my work Oo instead of the Ee I use at home."
This is as useless as suggesting "Install Linux" when a Windows vulnerability has been found!
You sound like you're attacking this piece of advice from the advisory, which is blaming the messenger. People who are running the binary nvidia driver really do have precisely two choices:
Switch to the open source driver until a fix is released.
Risk their computer being taken over when they visit random web pages.
There really are no other options. That may not be "useful," but it's true. What did you expect them to put under "suggested action," a big "fuck you"?
The A-bomb is a Z-bomb, and the arms race is a race between nuclear weapons and ourselves. It is them or us. What do nukes do? What are they for? Since when did we all want to kill each other? Nuclear weapons deter a nuclear holocaust by threatening a nuclear holocaust, and if things go wrong then that is what you get: a nuclear holocaust. If things don't go wrong, and continue not going wrong for the next millenium of millenia (the boasted forty years being no more than forty winks in cosmic time), you get... What do you get? What are we getting?
At the multiracial children's tea party the guests have, perhaps, behaved slightly better since the Keepers were introduced. Little Ivan has stopped pulling Fetnab's hair, though he is still kicking her leg under the table. Bobby has returned the slice of cake that rightfully belonged to tiny Conchita, though he has his eye on that sandwich and will probably make a lunge for it sooner or later. Out on the lawn the Keepers maintain a kind of order, but standards of behavior are pretty well as trogolodytic as they ever were. At best the children seem strangely subdued or off-color. Although they are aware of the Keepers, they don't want to look at them, they don't want to catch their eye. They don't want to think about them. For the Keepers are a thousand feet tall, and covered in gelignite and razor blades, toting flamethrowers and machine guns, cleavers and skewers, and fizzing with rabies, anthrax, plague. Curiously enough, they are not looking at the children at all. With bleeding hellhound eyes, mouthing foul threats and shaking their fists, they are looking at each other. They want to take on someone their own size...
If they only knew it -- no, if they only believed it -- the children could simply ask the Keepers to leave. But it doesn't seem possible, does it? It seems -- it seems unthinkable. A silence starts to fall across the lawn. The party has not been going on for very long and must last until the end of time. Already the children are weepy and feverish. They all feel sick and want to go home.
Slashdot Mirror
It seemed to me that i810 was fine up until Intel got involved with it. I have an unusual chipset (855GM on a desktop with no LVDS output), and new versions of Intel drivers keep totally failing to work on it in various exciting ways. Before Intel engineers started showing up on xorg bugzilla (i.e. when the module was called 'i810' instead of 'intel'), this happened once in a blue moon and I got responsive, polite fixes reasonably quickly. Now, it happens constantly, and I have to beat the engineers over the heads just to stop them closing a bug with comments which more or less translate to "we can't be bothered, sod off". When bugs do get fixed, it tends to take them a respectable fraction of a year to do it.
Interacting with Intel engineers on xorg bugzilla has sort of made me yearn for the days when GNU/Linux hardware drivers were crappy, desperate efforts slapped together with enormous difficulty without any specifications to work from.
You do realize that using Linux to host a world-accessible web site based on custom PHP scripts, and using Windows to browse the internet as an end-user, and having them both get broken into is not an apples-to-apples comparison?
If you were using IIS to host a web site with a boatload of custom ASP scripts, and that got broken into, I would not be surprised. If that breakin installed an exploit which invaded your up-to-date-with-security-patches Linux/Firefox machine when you browsed the site from Linux, that would be serious news (and an indication that the two were comparably vulnerable to attack).
Well, that's a problem with ISO then. There _is_ a proper balance to be struck between "we counts the votes and we reports the totals, questioning the totals is not permitted for people in my position, have a nice day" and "the vote may have passed but I don't like it, nyah nyah." The people in charge of implementing the ISO procedures should keep firmly in mind that the end goal is _not_ to follow every procedure to the letter no matter how badly distorted the outcome, but to use the procedure as a means to the end. The end is to ratify standards which have broad support in the technical community; if the voting procedures are showing strong evidence of being blatantly rigged -- which they are -- the ISO leadership needs to say so, and deal with the problem. That's not arbitrary. That's taking responsibility. At most organizations it's required for anyone above the level of assistant manager.
It's not clear to me whether the ISO leadership is also corrupted by Microsoft, and is letting the irregularities go unchallenged on a nudge-nudge-wink-wink basis, or if someone at ISO honestly believes that it's not their place to call out blatant corruption when they see it, but either one is a black eye for ISO.
Did you ever consider attempting to learn what the instructions google provided you were going to do, and then entering them into your computer?
Hogswallop. Deliberate features that happen to allow the circumvention of security are not as common as buffer overflows, but they certainly happen, and serious security people consider them to be vulnerabilities (what else would they be?). ActiveX is one. Debian categorizes them as "design flaws" in their advisories. To say that it's not a vulnerability "in the traditional sense", or recommend that people disable the impossible-to-secure system "when you aren't using it", is a bunch of crap.
That's certainly not true. To use one of a huge multitude of examples, students at my school had physical access to the machines in the computer lab, but it would definitely be a problem if they installed a keylogger to sniff other students' passwords.
"You see, this serious security problem was designed in from the start, so therefore... it's not a problem! Ta-da!"
FWIW, dmcrypt+luks is what the Debian installer uses if you ask for an encrypted disk, and for me it's worked a treat so far.
I've done it before. I had a Dell PE 2950 server with an internal PERC 5 RAID controller that got intermittent data errors with the standard Debian kernel... I poked around on the mailing lists and found that there was a workaround (a one-line kernel change that substantially reduced the aggressiveness with which the driver would load down the RAID controller). I made it, ran a disk benchmark for several days without a hitch, and crossed my fingers and put it into production. Thankfully, the problem never recurred, and a firmware update several months later resolved the problem entirely, so that I could switch back to Debian-provided kernels and get easy security updates and peace of mind again.
:-). But the system absolutely needed to go into production, and that was the most straightforward way I could see to make it happen.
Was I happy about doing it? Absolutely not. I would have much, much preferred to have a kernel running on my production system that I had _not_ edited the source to by hand
This sort of problem doesn't seem to be unique to Linux systems; I've seen Windows admins go through exactly the same sort of heartache, but their only recourse seems to be to beg the vendor for a fix or to, well, take it and like it. This is the number one thing I like about administrating Linux servers -- no software problem is genuinely unsolvable, and it's up to me to make the determination whether it's worth the investment of time and risk to make the fix. In this case, it was nerve-wracking, but ultimately being able to make this fix saved my ass.
Are you kidding? Or are you just not familiar enough with OSS to know what innovative software is out there?
There's plenty of innovation on the closed-source side, too (Incredibuild/XGE is actually the first thing that comes to mind). But dismissing OSS as just copying the work of others is simple ignorance.
Suggestion number one: You're running the wrong version of Linux if this is what you want. You seem to be using a continuously updated version (like Debian unstable), which means that, well, it's continuously updated. If you want to stick with what you've got and not be bothered with frequent upgrades, you should be using Debian stable (not sure what the Ubuntu equivalent terminology is).
Suggestion number two: For complex operations, use aptitude, not apt-get. It's much better at sorting out what to install, upgrade, and remove in order to get what you probably want (and you can tell it what to do differently if it gets it wrong). apt-get just sort of guesses and is only good for very simple operations.
Suggestion number three: If you are going to run a continuously updated version of Linux, don't let it get this far behind. Do 'aptitude dist-upgrade' from time to time. You're surely missing a few security updates (as well as suffering from the every-install-needs-a-partial-upgrade problem you expressed unhappiness about).
Suggestion number four: Don't tell the kernel developers how to do their jobs
Out of curiosity, what work are you trying to get done that's made more difficult by the lack of a stable ABI for Linux drivers?
FWIW, I've seen plenty of expensive support contracts that add up to "the right to talk to clueless support people who deny that your problem exists" in my time. I have, though, also heard a few conversations between my boss and our vendors of the nature, "Look, we're paying you guys X thousand dollars for support, and we're having a problem and you're not bloody fixing it. We're going to start looking at other vendors because you're not working out for us." In a lot of those situations, we got to talk to someone who knew what they were doing and/or could fix our problem reasonably quickly. It might have helped that he wasn't bluffing; that he actually had the power and was pissed enough to switch vendors because our current one was falling down on the job (which they were).
No, computers make that easy. The only "audit trail" that ever exists is what gets backed up to a trusted location and kept offline under literal lock and key. As long as the files are on an untrusted computer (read: anyone's), anyone with the proper skills can change the numbers anywhere in them, save them under alternate names, and generally do whatever they like. Even if it's true that you've figured out a way to totally, 100% prevent Excel from presenting any interface which makes it possible to cook the books, any knowledgeable hacker with a hex editor and a few days (possibly hired by an unscrupulous middle manager with a few millions in illegal transactions to hide) can make a shredded mess out of your "audit trail."
Oh, you used VB macros? Never mind about what I said before. It must be bulletproof.
Thank you. I inherited a single Gentoo server at work once, and I had assumed for all the intervening years that it was only my own ignorance that had made it impossible to do any maintenance to it. I simply assumed that no one would have set up a server based on a distribution so obviously unsuited as a production server, and so there must have been possibilities I was unaware of that would make it easy to maintain once in production.
I limped it along until the happy day when it was retired, but until this day I always assumed that the problem was me.
Thanks.
IOW, we've learned from the SCO lawsuit how to handle these situations. Make a big stink in the press, share as few of the details as possible, and ride the wave of FUD to the promised land.
I can feel Chen's pain -- it must have been awful trying to botch around the fallout from the first two stupidities, and then getting screwed by the third. I don't think that lets Microsoft off the hook at all, though. The responsibility for the hacked-together, poorly-planned, teetering heap of an OS that they now have to support (at tremendous cost) lies nowhere but at their own metaphorical feet.
Considering that the entire point of the article is the discovery that the airplane's computer system is poorly designed, I'd say it was less "fortunately" as in "by random luck, it turns out the systems are separate" and more "fortunately" as in "well, as luck would have it, they're not total idiots, and they made the systems separate."
It's not unheard-of, after all, for software failures to cascade from trivial areas to more vital areas in passenger craft.
It's not "lack of tool support," it's the accepted definition of the word "file". A file as a single variable-sized series of bytes is an abstraction that's been around for decades; suddenly there are people who have arbitraily redefined it and are complaining about every program on earth is failing to support their new, now-different abstraction.
Why is it better for every program in the world that reads files to add an extra layer of "streams" complexity, than it is for the few selected programs that need multiple bytestreams to implement them via a file format?
Hell, do whatever you want with your own computing equipment -- but don't complain when you upload your files to a web server and they lose their icons (or whatever it is that they're storing in their alternate streams). That problem is not going to go away no matter how much you ask for it to.
It's good to hear you're not bitter. My mean-spiritedness was meant with nothing but the best of intentions
I applaud your clarity of reason, sir!
"Normally, your boss pays you, but when you buy him a Christmas present, you're effectively paying him. So you can see that this whole 'employee' thing is pretty meaningless."
"Cheap, unpowered speakers normally emit sound, but if you plug them into the microphone jack, you'll be able to record. It just goes to show you what a bourgeoisie lie this so-called 'stereo equipment' is."
"I flew from New York to LA last week. Now I'm flying back, so as you can see names of cities have no meaning."
Oh, I see -- you don't like words that describe things that are different at some times than they are at others. You'd rather use digraphs. Now I understand.
"I connected to the mail Ph using my work Oo instead of the Ee I use at home."
- Switch to the open source driver until a fix is released.
- Risk their computer being taken over when they visit random web pages.
There really are no other options. That may not be "useful," but it's true. What did you expect them to put under "suggested action," a big "fuck you"?It's also possible that they've been keeping tabs on galeon, which has had tabs like this since before Firefox existed.