The onus is on the company to come up with a business model that will compel you to buy from them.
Ugg, be careful what you wish for: DRM systems are exactly designed to 'compel' you to pay money for things which were previously your fair use rights.
The onus is on government to make a system that creates just enough artificial monopoly rights to 'promote progress in science and the useful arts', while minimizing the effect on individual liberty.
His point was that you don't need to keep things patched as regularly if you have a wider variety of OSes because there will be less people finding vulnerabilities, less incentive to exploit them,and less hackers writing worms for a given OS.
That is the definition of 'security through obscurity'. I would not want to run an insecure system and hope to be safe because nobody else had heard about it. True security means using well-known and peer-reviewed code (but not 'well known to be crap').
No but it would be a lot harder to exploit and that is GP point.
Why? It is often only necessary to attack the weakest link in the chain. To get inside a company network and copy documents available to employees, for example, only one employee workstation needs to be subverted. That is easier if there are several different systems running - just pick the crappest one and exploit that.
Of course, it's arguable that the one system which is widely deployed in a monoculture today is in fact that one crappest and least secure of all the choices available. In which case adding a bit more variety would not hurt things, but it wouldn't improve them either, unless almost all the Windows systems were removed.
Yeah, because obviously the answer is to have a hundred different systems with a hundred different sets of vulnerabilities. That will be much easier to keep patched.
How long before each worm includes a copy of its source code in a git repository, searches out other variants of the same worm on the infected system or across the net, and randomly exchanges patches with them to create hybrid offspring? The worm would need some way to compile itself, of course (unless written in Javascript or other scripting language where the interpreter is included with Windows).
If you want a successful platform, you need to remove the ability to have a bazillion widget sets and weird ways of doing something the OS should do.
Windows suffers from this too - for example Firefox implements its own widgets, and so does Qt. The difference is that there's a clear baseline of 'the' standard widget set, a reasonably clear set of expectations for how all apps should behave, and so when people do decide to roll their own (for good reasons or bad) they take some care to keep the user interface consistent.
Of course, if you really try, you can still create peculiar nonstandard interfaces, Windows Media Player and Safari for Windows being obvious examples.
The good news is that the Linux desktop is converging on an agreed standard for how apps should look and feel: Firefox and OpenOffice, although they have their own widget implementations under the hood, don't look massively out of place on a normal GNOME desktop. Nor do KDE/Qt applications.
It's not so much a technical matter of having the _ability_ to make a bazillion widget sets, more a social understanding that consistency is important.
The BBC news article about this breaks new ground by including not one, but two car-based analogies, both of which fail to reach the (admittedly high) benchmark of bad analogies set here on Slashdot.
The robot was able to work out the role of the genes by observing yeast cells as they grew.
It used existing information about the function of known genes to make predictions about the role an unknown gene might play in the cell's growth.
It then tested this by looking at a strain of yeast from which that gene had been removed.
"It's like a car," Professor King said. "If you remove one component from the engine, then drive the car to see how it performs, you can find out what that particular component does."
and later,
"If you spent all of the money we've spent on Adam on employing human biologists, Adam probably wouldn't turn out to be the cost-effective option," he said.
"But that was the case with the first car. Initially, the investment in the technology wasn't as cost-effective as sticking with horses."
Usually the Linux Hater sees the same reality of the situation that an ordinary user sees. An ordinary user doesn't know or care what ACPI is, they just see that suspend and resume doesn't work reliably. For any of Linux's defects there are all sorts of excuses, most of them entirely valid (software patents, manufacturers not releasing specs, etc) but ordinary users don't care, they just care whether it works or not.
The article is quite right; there is too much groupthink and myopia. The Linux Hater's blog is a must-read as an antidote to all that, and he or she has some useful points to make. The articles on Linux Weekly News still have a Linux-centric viewpoint, naturally, but usually aren't afraid to point out shortcomings (especially when quoting the latest Linus flaming on the kernel list).
Using this analogy someone can bribe you to vote in a certain way when visiting the polling station, too.
They cannot because they cannot see how you voted - even if you want to let them see. Nobody is allowed to come with you into the polling booth, and when you leave, you take no evidence with you to show how you voted (though you may have something to show that you did vote). This is the purpose of a secret ballot. Of course they can offer a bribe and hope that people are 'honest' enough to vote the way they were paid to - no system can prevent that.
Hmm, so the coercion is limited to somebody encouraging you to e-vote a certain way, and then not bother to visit the polling station. That could still be fairly effective. In principle, the Australian system is ideal - you must go to the polling station or be fined, although you are free to enter an unmarked ballot - but it would probably be judged too inconvenient and bullying to be implemented in most countries.
In Estonia people can change their vote after e-voting. If somebody made you vote for something they wanted, you can later re-vote electronically or physically. The latest vote counts.
That doesn't seem to solve the problem at all. There is surely a cut-off date after which you cannot change your vote? And this 'somebody' can simply pay you a bribe based on the most recent vote you registered before the cut-off.
Indeed, allowing voting by mail is a bad idea. I know that in the United Kingdom postal voting has been associated with high levels of fraud, but that is not the main point against it. Fundamentally, there is nothing to stop you showing your vote to someone else before you mail it, and so nothing to prevent coercion of various kinds (from 'voting parties' upwards).
Any form of online voting is insecure because it's not a secret ballot. You can prove to someone else how you voted (by letting them look over your shoulder) and that means it is possible to bribe or threaten voters. A secret ballot means that you cannot show your vote to anyone, even if you wanted to. It's surprising that governments are so quick to give up this basic guarantee of a fair election.
You think this is a sign Microsoft is legitimately trying to reach out to the web community? Or is this just another attempt to grab server market share from Apache and the Linux community?
Well, duh, it's both.
Do you think Burger King's new Whopper is a legitimate attempt to reach out to the fast-food community? Or are they just trying to take market share from McDonald's?
Generally, I think the last thing the web needs is more servers running IIS.
I'm inclined to agree, but I think recent IISes are not the crapfest that early versions were. (Admittedly that's a low bar to clear.) Still if this easy packaging of web apps prompts the free software world to make things even easier to set up it'll be a good thing. Apache runs well on Windows - I wonder if a prepackaged Apache for Windows with an easy installer for popular web apps would take off?
It still seems a bit pointless. If you have a null-pointer bug, just fix it and move on. It's not worth worrying about whether it is exploitable or not: a bug is a bug.
I suppose it might influence the decision of whether to push out a patch. But even there I prefer the Linux approach of issuing an advisory for anything that might possibly be a vulnerability, even if no obvious exploit yet exists. Maybe on Windows installing updates is more likely to break things or require reboots (empirical data needed here) so there is a greater cost in making a bugfix release of software?
It would take a rank ideologue to assume that making legislation neutral to sex and race would be a pragmatic approach to addressing institutionalized imbalances in equity and social justice.
Or perhaps the people pushing it didn't assume that at all, but thought that the federal government should not be in the business of 'addressing institutionalized imbalances' in the first place.
Classical UNIX ran sync(1) from the crontab every 30 seconds to flush data to disk, so I guess if there is an informal precedent for the maximum time writes can be held back, that would be it.
You make a good point. Another example would be that when sending packets via UDP, there is no guarantee they will reach the other end, but obviously any network which dropped all UDP packets would be considered broken. And yet... if an application were written so that it relied on the UDP delivery succeeding for correct operation, and left corrupted data otherwise, it would be the application that's considered buggy. I would be annoyed if my terminal output were delayed by 60 seconds, but if you were writing a safety-critical real-time application you could not use Linux terminal output for just this reason, that there is no upper limit to the delay before the output reaches the user.
I think both sides, OS and application, need to follow Postel's maxim: be conservative in what you send, liberal in what you accept. In this case the filesystem should try harder to meet traditional expectations of safety, even if the letter of the law doesn't require it. And the applications should be written more carefully, such that they won't lose data even under the worst circumstances and do not rely on filesystem guarantees that aren't really guarantees.
Putting versioning in the filesystem is an interesting idea but it has all sorts of rough edges in practice.
Dave Cutler (the designer of VMS and later Windows NT) was asked whether he regretted not putting file versioning into Windows NT the same as VMS, and I believe he replied that on second thoughts, it's probably better that way. Linux has several very good revision control systems such as git which can track the history of your files without much effort. Certainly, it would be handy to have some kind of filesystem plugin or hook to automatically commit changes to a version control repository when a file is saved.
YES!! That is EXACTLY what I expect the every modern file system to do.
Your expectation is quite reasonable. When the application writes something to disk, it should be there on disk, right? The way the article is presented makes it sound like a horrible bug in ext4 that it doesn't do this. But believe it or not, almost no filesystem provides this guarantee by default. ext3 doesn't (in the default mode), nor does ext2, nor a typical implementation of FAT or NTFS or the Minix filesystem or whatever.
For decades now it has been an accepted trade-off that the filesystem can hold back disk writes and do them later, giving better disk performance at the expense of losing data if there is a crash. Losing file data is bad but losing metadata is even worse, since corrupt filesystem metadata can trash the contents of many files and requires a lengthy fsck on startup. So journalling filesystems, as typically configured, keep a journal for metadata so it's not corrupted even if the power gets cut at the most inconvenient moment. But they don't extend the same care to file contents, because it would be too slow. You can enable it by setting the data=journal parameter in ext3 (and I guess ext4 too) but this isn't the detail.
It is certainly a bit unfair that the filesystem takes such pains with its own bookkeeping information but doesn't bother to be so careful about user data. But as I said, it's a known tradeoff to get better performance. If you want to be sure your file has reached disk you need to fsync(). This sucks, but it's the Unix way, and has been so for like, forever. So it's not a bug in ext4 - just bad luck and perhaps a misunderstanding between kernel and userspace about what guarantees the filesystem provides.
As SSDs replace rotating storage, there is less need to buffer writes (certainly the need to minimize seek time goes away, and that's the biggest reason), so we might see this whole situation resolved within a few years. Perhaps in 2015, when the system call returns, you can be sure that the data is written. Until that longed-for day, bear in mind that your filesystem is permitted to temporarily lie to you about what has been written, and call fsync() if you are paranoid.
Slashdot Mirror
Ugg, be careful what you wish for: DRM systems are exactly designed to 'compel' you to pay money for things which were previously your fair use rights.
The onus is on government to make a system that creates just enough artificial monopoly rights to 'promote progress in science and the useful arts', while minimizing the effect on individual liberty.
Sounds great! Is the output from the new accelerometers in an easy-to-decode format so it works on Linux with libwiimote and similar software?
Wouldn't you need one Wiimote in each hand and one on each foot?
I am interested in using motion sensors such as the Wiimote as a learning aid for katas, and I wonder if any work has been done on this.
That is the definition of 'security through obscurity'. I would not want to run an insecure system and hope to be safe because nobody else had heard about it. True security means using well-known and peer-reviewed code (but not 'well known to be crap').
Why? It is often only necessary to attack the weakest link in the chain. To get inside a company network and copy documents available to employees, for example, only one employee workstation needs to be subverted. That is easier if there are several different systems running - just pick the crappest one and exploit that.
Of course, it's arguable that the one system which is widely deployed in a monoculture today is in fact that one crappest and least secure of all the choices available. In which case adding a bit more variety would not hurt things, but it wouldn't improve them either, unless almost all the Windows systems were removed.
Yeah, because obviously the answer is to have a hundred different systems with a hundred different sets of vulnerabilities. That will be much easier to keep patched.
How long before each worm includes a copy of its source code in a git repository, searches out other variants of the same worm on the infected system or across the net, and randomly exchanges patches with them to create hybrid offspring? The worm would need some way to compile itself, of course (unless written in Javascript or other scripting language where the interpreter is included with Windows).
Windows suffers from this too - for example Firefox implements its own widgets, and so does Qt. The difference is that there's a clear baseline of 'the' standard widget set, a reasonably clear set of expectations for how all apps should behave, and so when people do decide to roll their own (for good reasons or bad) they take some care to keep the user interface consistent.
Of course, if you really try, you can still create peculiar nonstandard interfaces, Windows Media Player and Safari for Windows being obvious examples.
The good news is that the Linux desktop is converging on an agreed standard for how apps should look and feel: Firefox and OpenOffice, although they have their own widget implementations under the hood, don't look massively out of place on a normal GNOME desktop. Nor do KDE/Qt applications.
It's not so much a technical matter of having the _ability_ to make a bazillion widget sets, more a social understanding that consistency is important.
and later,
Usually the Linux Hater sees the same reality of the situation that an ordinary user sees. An ordinary user doesn't know or care what ACPI is, they just see that suspend and resume doesn't work reliably. For any of Linux's defects there are all sorts of excuses, most of them entirely valid (software patents, manufacturers not releasing specs, etc) but ordinary users don't care, they just care whether it works or not.
The article is quite right; there is too much groupthink and myopia. The Linux Hater's blog is a must-read as an antidote to all that, and he or she has some useful points to make. The articles on Linux Weekly News still have a Linux-centric viewpoint, naturally, but usually aren't afraid to point out shortcomings (especially when quoting the latest Linus flaming on the kernel list).
Linus's mother tongue is Swedish. He speaks some Finnish too but not as much as English.
They cannot because they cannot see how you voted - even if you want to let them see. Nobody is allowed to come with you into the polling booth, and when you leave, you take no evidence with you to show how you voted (though you may have something to show that you did vote). This is the purpose of a secret ballot. Of course they can offer a bribe and hope that people are 'honest' enough to vote the way they were paid to - no system can prevent that.
A great idea. And to fix the useless subject lines in Slashdot comments, the subject field should appear below the text body field.
Hmm, so the coercion is limited to somebody encouraging you to e-vote a certain way, and then not bother to visit the polling station. That could still be fairly effective. In principle, the Australian system is ideal - you must go to the polling station or be fined, although you are free to enter an unmarked ballot - but it would probably be judged too inconvenient and bullying to be implemented in most countries.
That doesn't seem to solve the problem at all. There is surely a cut-off date after which you cannot change your vote? And this 'somebody' can simply pay you a bribe based on the most recent vote you registered before the cut-off.
Indeed, allowing voting by mail is a bad idea. I know that in the United Kingdom postal voting has been associated with high levels of fraud, but that is not the main point against it. Fundamentally, there is nothing to stop you showing your vote to someone else before you mail it, and so nothing to prevent coercion of various kinds (from 'voting parties' upwards).
Any form of online voting is insecure because it's not a secret ballot. You can prove to someone else how you voted (by letting them look over your shoulder) and that means it is possible to bribe or threaten voters. A secret ballot means that you cannot show your vote to anyone, even if you wanted to. It's surprising that governments are so quick to give up this basic guarantee of a fair election.
Well, duh, it's both.
Do you think Burger King's new Whopper is a legitimate attempt to reach out to the fast-food community? Or are they just trying to take market share from McDonald's?
I'm inclined to agree, but I think recent IISes are not the crapfest that early versions were. (Admittedly that's a low bar to clear.) Still if this easy packaging of web apps prompts the free software world to make things even easier to set up it'll be a good thing. Apache runs well on Windows - I wonder if a prepackaged Apache for Windows with an easy installer for popular web apps would take off?
It still seems a bit pointless. If you have a null-pointer bug, just fix it and move on. It's not worth worrying about whether it is exploitable or not: a bug is a bug.
I suppose it might influence the decision of whether to push out a patch. But even there I prefer the Linux approach of issuing an advisory for anything that might possibly be a vulnerability, even if no obvious exploit yet exists. Maybe on Windows installing updates is more likely to break things or require reboots (empirical data needed here) so there is a greater cost in making a bugfix release of software?
Can you cite anywhere in the world, at any point in history, that was not a 'tyranny' by your standard?
Or perhaps the people pushing it didn't assume that at all, but thought that the federal government should not be in the business of 'addressing institutionalized imbalances' in the first place.
Classical UNIX ran sync(1) from the crontab every 30 seconds to flush data to disk, so I guess if there is an informal precedent for the maximum time writes can be held back, that would be it.
You make a good point. Another example would be that when sending packets via UDP, there is no guarantee they will reach the other end, but obviously any network which dropped all UDP packets would be considered broken. And yet... if an application were written so that it relied on the UDP delivery succeeding for correct operation, and left corrupted data otherwise, it would be the application that's considered buggy. I would be annoyed if my terminal output were delayed by 60 seconds, but if you were writing a safety-critical real-time application you could not use Linux terminal output for just this reason, that there is no upper limit to the delay before the output reaches the user.
I think both sides, OS and application, need to follow Postel's maxim: be conservative in what you send, liberal in what you accept. In this case the filesystem should try harder to meet traditional expectations of safety, even if the letter of the law doesn't require it. And the applications should be written more carefully, such that they won't lose data even under the worst circumstances and do not rely on filesystem guarantees that aren't really guarantees.
Putting versioning in the filesystem is an interesting idea but it has all sorts of rough edges in practice.
Dave Cutler (the designer of VMS and later Windows NT) was asked whether he regretted not putting file versioning into Windows NT the same as VMS, and I believe he replied that on second thoughts, it's probably better that way. Linux has several very good revision control systems such as git which can track the history of your files without much effort. Certainly, it would be handy to have some kind of filesystem plugin or hook to automatically commit changes to a version control repository when a file is saved.
Your expectation is quite reasonable. When the application writes something to disk, it should be there on disk, right? The way the article is presented makes it sound like a horrible bug in ext4 that it doesn't do this. But believe it or not, almost no filesystem provides this guarantee by default. ext3 doesn't (in the default mode), nor does ext2, nor a typical implementation of FAT or NTFS or the Minix filesystem or whatever.
For decades now it has been an accepted trade-off that the filesystem can hold back disk writes and do them later, giving better disk performance at the expense of losing data if there is a crash. Losing file data is bad but losing metadata is even worse, since corrupt filesystem metadata can trash the contents of many files and requires a lengthy fsck on startup. So journalling filesystems, as typically configured, keep a journal for metadata so it's not corrupted even if the power gets cut at the most inconvenient moment. But they don't extend the same care to file contents, because it would be too slow. You can enable it by setting the data=journal parameter in ext3 (and I guess ext4 too) but this isn't the detail.
It is certainly a bit unfair that the filesystem takes such pains with its own bookkeeping information but doesn't bother to be so careful about user data. But as I said, it's a known tradeoff to get better performance. If you want to be sure your file has reached disk you need to fsync(). This sucks, but it's the Unix way, and has been so for like, forever. So it's not a bug in ext4 - just bad luck and perhaps a misunderstanding between kernel and userspace about what guarantees the filesystem provides.
As SSDs replace rotating storage, there is less need to buffer writes (certainly the need to minimize seek time goes away, and that's the biggest reason), so we might see this whole situation resolved within a few years. Perhaps in 2015, when the system call returns, you can be sure that the data is written. Until that longed-for day, bear in mind that your filesystem is permitted to temporarily lie to you about what has been written, and call fsync() if you are paranoid.