I think price fixing is dishonest in all circumstances (unfortunately not illegal in these cases) but to varying degrees. In this case Apple is further in the wrong in my book.
You are very ill-informed. One company setting a price for a product is not "price fixing". Other companies can and do compete against Apple's iPod with lower prices, so go buy those instead if you don't like the prices. Now, if Apple got together with Dell and Rio or whoever else, and conspired to keep prices at a certain level, then that's "price fixing" and it is anti-competitive and illegal. Secondly, if Apple is a monopoly in the market, they can also achieve the results of price fixing without conspiring with another company. A couple of months ago, Apple had about 30-40% of the market in terms of unit, and about 50% in terms of dollars spent. It is not a monopoly.
Similarly, BMW and Benz are not "fixing prices" just because their products are expensive. The are simply luxury goods, like $500 portable music players.
I wonder if Linux is going to have to drop the support, of if we'll be able to slip in under the "interoperability" loophole.)
What loophole? There are interoperability clauses that allow for reverse engineering which would otherwise have violated copyright or a specific user license in some countries, but none that cover patents that I know of. You can't write an MP3 encoder, violating the relevant patents, and claim it's just to be compatible with the MP3 format.
Let me remind you, this is the kind of B.S. that can happen when you rely on proprietary software [...] Someone can pull the rug right out from under you whenever they want to.
No, you are vulnerable to the patent even if your open source file system has nothing to do with FAT, but use the patented algorithms. The software patent crisis affects all.
Which should be considered a flaw in MacOS X, because previous versions did not rely on the command line at all
It doesn't matter. MacOS X remains popular, and useful as a desktop OS. I'm not saying it's not a worthy goal, just that we don't need to distract ourselves with putting a GUI on every last task when there are other important things to fix.
there's only about a million firewall and mail server products with GUIs.
Notice the word "novice" in my statement?
However, neither of those have anything to do with a end-user distribution.
A firewall is very useful even on a desktop machine. MacOS X ships with a firewall, and IIRC so does WinXP. A mail server is less common.
GUI everything: If it's not a system crash, the desktop PC should be able to handle everything in GUI.
Gosh, no. Not even Mac OS X does that. All you need to take care of in a GUI are the tasks that normal users are expected to do. Advanced users, developers, and administrators can cope with more complex interfaces. I think the more important task is to make it a good GUI, which is very hard. Imagine a UI that can allow a novice to configure a firewall or mail server correctly.
I don't know enough to comment on how the system should keep tabs on packages, but it would be nice to be able to make sense of dependancies.
Or ignore dependencies (at the user level). Most users want to install a named program, like "OpenOffice.org" or "Mozilla", and could not care less what libraries that will bring in.
What will determine the success of Linux on the desktop is not what you add, but what you successfully hide. This includes many options and details that a developer might think nobody can live without, and may include entire applications that are not as good in most respects to another. "Successful" here is determined by the percentage of time the user can spend doing productive work.
Philosophically, the desktop is about "because it's really useful", not "because we can". Win or lose will depend on whether the Linux community can change its mindset.
I just did the math. It's only about six thousand times better, which should not fill you with confidence.
You go on to propose several ways to improve the pass phrase, and they are all good. I did not say that a word-based system cannot be effective, but that we should not consider the search space simply to be the number of words in the English language raised to the power of number of words used. A heuristics-based dictionary attack may find a weak password with a search space many magnitudes smaller.
This won't help you crack a slashdot password-sentence
You might be joking, but yes, it will. If I know or can guess that the person is a Slashdot reader, then I simply expand my dictionary. Just because it's misspelled doesn't mean it's random! For example, there are really just one common misspelling of the word "weird". How hard do you think it'll be for a bot to crawl through Slashdot postings to find these novel spellings?
The basic lesson is, the more I know about the password (English sentence, Slashdot user, etc), the smaller my search space can be. Naively assuming that the search space is always going to be 45000^6 (which is essentially six random words) shows little understanding of how these things are cracked.
The computer isn't smart enough. Determining
part of speech in English is AI-complete. [...]
You've missed the point, in more than one way, I think. The heuristics I proposed as an example are not meant to be rules that will help crack every password. These are assumptions that may very well be completely wrong, but dramatically narrow the search space if they are right.
Furthermore, what I proposed includes identifying words that can be used as verbs in my dictionary, not from an arbitrary sentence. It's a simple (if tedious) task of classification.
By the way, what's "AI-complete"? Do you mean "NP complete"?
Re:Two minds about it
on
Real Security?
·
· Score: 2, Interesting
thisismylongasspassword
That's better than you think. My/usr/share/dict/words has over 45000 words
in it, which is probably typical. The above password is six words long (which
if anything is pretty short, as sentences go). That means you can brute force
it in about (45000^6)/2 tries, on average.
I fear not. If the cracker knows that your password is a valid English sentence, then the search space is significantly reduced. For example, you can trivially discard any combination that doesn't include a verb. This observation alone probably takes the search space down to 6v*(45000^5), where v is the number of verbs in the dictionary, presumably much smaller than 45,000. A reasonable guess that one of the words is "password" would make the search space 6*(6v*(45000^4)). More importantly, most of your 45000 words are obscure. An attacker would likely initially try at most 5000 common words (which would cover every word in that password). All of a sudden, we're talking about 6*(6v*(5000^4)).
By making three assumptions, I have narrowed the search space down by maybe eight zeroes - a hundred million times easier - assuming 'v' is in the thousands range. Now, you might say I chose those three assumptions because I already know the password. That is of course true, but what you need to consider is whether the worst password in your entire system satisfies those assumptions (derived entirely from only the knowledge that the password is an English sentence). Crackers can get lucky, too.
In real life, you'd attack such a password by picking strings from the fortunes files, books, and other sources of quotes, and then we're only talking hundreds of thousands of tries. Remember that many crackers only need the weakest password.
Value is subjective. So there is no absolute value that can be placed on "...a generation of children with free access to the classic writings"
You're absolutely right, except that wasn't my point. I'm also not trying to say that government can be a very good judge of such subjective values at all. What I am trying to say is that the capitalist free market is not one.
I think maybe you meant to phrase that as "...a generation of children with access to the classic writings" (without the "free").
Unfortunately, the "free" does matter. People, for their own strange reasons, would take advantage of free public stuff like libraries and parks, but not if you had to spend even a minimal overt sum. So no, I did not mean to leave out the word "free".
We don't all have the same interests/strengths, but a library can only hold so many books to try and cover all our interests...which very likely leads to a library with books not distributed in topics even close to the interests of the actual population.
Again, this is true, but it is not an indictment of the public library system. In theory, at least, a community pooling its resources together to buy general interest books is an efficient way of spending money. If each person contributes one book (in terms of taxes) to the library, then you're already ahead if you just borrow two books to read. This is highly efficient even if you factor in a vibrant used book marketplace.
Now, if the library doesn't stock the books you (the general community and you personally) like, then what's needed is a process to get them to listen. Cutting their budget is not going to improve their selection.
What's the (capitalist market) value of a generation of children with free access to the classic writings?
If that's the goal of Public Libraries - they should all close shop, and give each new child a PDA with all 10,000 Project Gutenberg books on ROM.
I didn't say that was the only goal of a public library, just that it is one whose benefits are difficult to measure in terms of money. Capitalism fails again and again where money cannot accurately represent the value of something, which is why most countries have environmental laws, national parks, and some have anti-trust laws and mandatory vacations.
The point is, it's wonderful to scrutinize government to correct inefficiencies. However, it's unwise to throw every government service into the capitalist market, as a general cure.
Of course! Why hold a government library to the unrealistic standards of being financially responsible when we can just force the taxpayers to cough up some more money to cover their inefficiencies?
Unfortunately, not funding government doesn't mean it can or will become more efficient with the money it does have. Quite often, it will end up cutting essential programs and services, rather than providing the same level of service at lower cost. Now, I'm not saying governmental efficiency is not a worthy goal to pursue, just that it's not as simple as "starving the beast".
In the case of a public library, its value is difficult or impossible to quantify with money, and therefore is not appropriately subjected to the capitalist market. What's the (capitalist market) value of a generation of children with free access to the classic writings?
With digital signatures is of course managing the signatures! If a key is cracked you have no way to revoke it cleanly. Then you have to deal with who signs the code. Do you compile and sign your own code? How do you know the source is good? If someone else signs it who are they? Do you trust that person?
That's more like four or five problems.:)
I'm not sure what "management" you are worried about. Tape the key phrase to the front of the machine. (We're talking about a server, locked in a room.)
To revoke the key, you can reinstall the entire OS with a different key, or simply replace the key in the existing kernel if you're confident. The former should be pretty standard practice in a breach scenario. Note also that "if the key is cracked" should be an unlikely scenario. Crackers are like water, flowing downhill towards the easiest attacks. Cracking a good encryption key is a pretty significant enterprise.
In the scheme we're talking about, the administrator signs the code. This can either be done by a compiler, or by an installer program, depending on your paranoia level. This is not much more complex than apt-get or rpm asking for a root password before proceeding.
If the source is compromised, then the key buys you nothing. However, realize that this is no worse than before, so it's not a "problem" of this scheme, but simply an attack it does not protect against. (This doesn't protect against somebody prying open the door to your server room, either.)
It's rediculously complicated to use public key encryption even with only server software. [...] They're banking on the fact it's confusing, possibly impossible, to manage all those keys and signatures
How so? The compiler (on a different, preferably disconnected machine) would ask you for the private key when you build the software. It is no more complex than managing licensed software with keys tied to a machine, which most administrators already do competently. Maybe there's a misunderstanding. I'm talking about one key (to match the public key installed in the kernel) per machine, which should be no more trouble than a notebook locked in a room.
I did read it on LKML (in the thread where it was firmly decided that adding digital signatures to the standard kernel was not going to happen).
Oh, I wasn't talking about Linux in particular. I was responding to a post that made it sound as if system call bugs are trivially exploited by any user. It may not be practical to implement this in Linux (possibly because of having many ways to run an application), but I was referring to (server) operating systems in general where that problem may not apply.
Sorry, I must have been vague, although some responses have grasped the main point of what I'm talking about.
The binaries are signed by the local root user (preferably on a separate box), at install time. The public key is installed in the kernel. This is about the root user preventing the box from running anything he did not install, not for the program's copyright owner or whoever else to control if it can run. As you can see, this has little to do with DRM, where another party controls what runs and what doesn't on your machine.
I'm also mainly talking about servers, on which ideally only a few trusted programs are installed. This lowers the signing overhead, and doesn't have a "power user" problem.
Since it is hard to coax an existing signed application into making your evil system call, the most likely target would then be the various script interpreters. That's a valid concern, and you should restrict yourself to those interpreters with a sandbox concept, and are well implemented.
The point is, by requiring two separate "points of failure", we are restricting the exploit to the intersection of time between the introduction and fixing of each bug. If no application bugs are known (to the cracker) at the time the kernel is vulnerable, you cannot exploit the bug. The reverse is also true.
Digital signatures don't help much, there is a multitude of other ways to mmap/read an executable into memory and run it.
I suggest you consider the solution again. The underlying bug (kernel buffer overflow, for instance) doesn't disappear. It's just much harder to exploit. In an unsigned system, it's a pretty trivial task to download a binary that makes the "proper" kernel call. If a compiler is installed, you can even just type in a program.
On the other hand, on a signed system the only way is to get an existing signed binary to make a bad system call. That's still possible, but now we're talking about two bugs, one in the kernel and a corresponding one in an user space program. Given that a dedicated server should be running the smallest number of the most trusted programs, this may not be such an easy task, and at the very least may slow down the attacker.
So what are these multitude of ways you can run an arbitrary application?
The "nice" thing about kernel exploits (from a cracker's perspective, of course), is that it doesn't matter what sort of userland software is running on the machine -- if you can get local access, by whatever means, it is very easy to boost yourself to root.
We should point out that you're talking about common kernels like Linux today, not that this must apply to any OS kernel. For example, if the kernel verifies the binaries it runs using digital signatures, then it can refuse to run unsigned binaries. The cracker's problem then becomes how to get an existing userland program (compiled by the trusted administrator) to issue the kernel call that results in the exploit, which is a much harder problem. A program may not ever make that system call, or may check its input so that you can't make it do the system call with (presumably) invalid parameters. In most cases, I expect that this means you have to insert a backdoor into a common program and wait for the trusted administrator to compile it for you.
This sort of security is probably overkill and too tedious for a desktop box, but not unreasonable for a server which should only have a few programs installed and running anyway.
Ah, but is it truly innovative? [...] apple deserves kudos for putting the pieces together, but they weren't the inventor of those pieces.
You set an impossibly high bar for the word, rendering it almost meaningless. All human inventions are built on top of prior art (human-made or naturally occuring), so by your criteria it appears that nothing can be considered "truly innovative".
Let me propose some alternative criteria. One, is it original? If not, it's not innovative. Two, is it worth copying? If not, it's not innovative.
Re:One way to improve it. Don't use it.
on
Effective XML
·
· Score: 1
Yes, XML is an improvement for truly hierarchical or repeating data, but efficient it isn't and a pain in the butt to use with AWK or anyone of a million Unix utilities.
Agreed, so design new utilities that understand XML. Take/etc/passwd or any CSV file for example. If you grep it for a user whose first name is "Richard", you'll also find somebody whose last name is "Richards" or lives on "Richard Street". An XML sensitive grep equivalent could understand a command like this:
xmlgrep "firstname" "Richard"
and return better results without intimate knowledge of the file format (which column corresponds to which field, etc).
Re:What are you talking about?
on
Effective XML
·
· Score: 2, Insightful
my previous company used XML everywhere (it was cool, after all), but after a while performance (when sclaed to many users) became an issue. Rewriting the XML-handling object to use a binary format made things much, much, much faster. The XML blobs were then only used for the browser front end, and for debugging on a developer machine.
No, your company did the exact right thing in choosing XML. When the nascent system is still being actively debugged, you made the process much easier because XML is human readable. As you begin to scale up its use, you proved a performance problem and relied on the modularity of the code to simply replace the XML code with efficient binary formats. If you had not seen a performance problem (perhaps the bottleneck is elsewhere and inevitable anyway), then presumably you'd leave the XML code alone.
You started with a general solution, and then optimized as necessary. I consider this an example of a job well done.
DRM has not, does not and will not prevent commercial 'piracy'; it just restricts the utility of digital media formats to the average consumer.
I think you miss the RIAA's point almost entirely.
Nothing will stop a dedicated and technologically sophisticated person from violating copyright. The CD, as someone points out, is utterly unprotected. Even the Apple DRM has a glaring hole that lets you burn to CD and re-rip. None of these are intended to stop the determined would-be infringer.
The ones they do stop are the casual ones. If it's tedious (burning hundreds of songs to CD and re-ripping them for the sole purpose of sharing them is not most people's idea of fun) and dangerous (the RIAA very publicly goes after "normal people" for this purpose), then there will only be a few willing to do it and risk it.
Those few are easy to take care of. They can be tracked down and sued into oblivion. What the RIAA really fears is if music sharing is easy, because despite what they say, they can't sue everybody. Something that everybody (not just geeks) doesn't feel is criminal soon becomes so.
The easiest way to describe why Kasparov loses to a computer is because he is human. How often does he play his best chess? Not often - he's human.
Actually, chess players at Kasparov's level train mentally and physically so that they can perform at or near their peak when it matters: during a match. This is the same whether you are facing a computer or human opponent.
It doesn't work every time, of course, but you make it sound as if Kasparov just walked up to the computer and started playing. No, he would've prepared for months.
The world chess champion will ALWAYS be a human, not a machine. A fork lift can lift much more than a human, but do we say that forklifts hold the world lifting record? A car can go much faster than a human, but is a car listed in Guinness under the fastest mile?
This is psychologically different. Many animals can lift more weight or run faster than we can, and that has been true for as long as humans existed. However, we were the best in chess.
You can ensure that the word "champion" is reserved for humans, but the honor will be as hollow as the difference in skill between the human champion and the best machine player.
My original point is not really about your specific choices, using them only as examples. However, since you decided to defend them in detail, I'll go into some more detail as well.
Retired PC's generally consume less power than modern ones.
I'm comparing a typical old desktop, compared to something designed to be up 24/7. The old PC is also likely to have a smaller, older, and less reliable hard drive. Worse, it's tempting for a geek to turn an old PC into a home server even if he doesn't actually need one. (I'm not talking about your specific case, because I obviously don't know your needs.)
A PDA in a cradle won't consume much more power than an alarm clock, and will do so without creating the toxic waste of AA batteries.
Two AA batteries in an alarm clock can last years. I'd be lucky if they last 2 weeks on my old PDA, so I don't think they are as energy efficient as you think. While you're not adding toxic waste, somebody still has to generate your power, possibly by burning something.
I'd hardly consider any kitchen with adequate ventilation to be a "harsh environment."
I was referring more to smoke and grease, and grubby fingers. "Harsh" is used not relative to factory floors or coal mines, but the clean desktop office they were designed for.
Keeping a machine out of a landfill is a good reason.
I completely agree. However, my point is that selling your machine or giving it away may be a better use for it than to invent household uses for them that they were never designed for. Sometimes...
we have retired 2 NeXT slabs, a NeXT cube, and a Sparc Station because they didn't make sense in terms of money, time, noise, or power requirements.
Why couldn't he just measure performance with and without each optimization and see which had the greatest improvement? Yes, this might not take into account interactions between different optimizations, but to the extent such interactions occur, it would probably be specific to his test cases anyway.
That's exactly the point. The goal is not to find a set of gcc switches that will work best on any program on any supported platform. The goal is to find the set that works best with this particular input, without human guidance.
10% or 20% improvements in compiler performance are of largely academic interest only these days most software's time is spent waiting on user input, disk IO, or network activity anyway?
First of all, what if you can get the 10% or 20% basically for free? That is, simply run your compile for a few unattended days to get the optimization? What is not worth human tweaking time can easily be worth machine time. Gentoo, although I do not use it myself, appears to be a vibrant Linux distribution based exactly on this point.
Secondly, most existing software are running on small CPUs all around you, not on your desktop. The constraints of memory usage and CPU power are still very real for them.
Finally, consider also that more efficient software may result in more idle hardware and lower power consumption. Imagine if all PCs in the world can get by with 5% less electrical power.
Slashdot Mirror
You are very ill-informed. One company setting a price for a product is not "price fixing". Other companies can and do compete against Apple's iPod with lower prices, so go buy those instead if you don't like the prices. Now, if Apple got together with Dell and Rio or whoever else, and conspired to keep prices at a certain level, then that's "price fixing" and it is anti-competitive and illegal. Secondly, if Apple is a monopoly in the market, they can also achieve the results of price fixing without conspiring with another company. A couple of months ago, Apple had about 30-40% of the market in terms of unit, and about 50% in terms of dollars spent. It is not a monopoly.
Similarly, BMW and Benz are not "fixing prices" just because their products are expensive. The are simply luxury goods, like $500 portable music players.
What loophole? There are interoperability clauses that allow for reverse engineering which would otherwise have violated copyright or a specific user license in some countries, but none that cover patents that I know of. You can't write an MP3 encoder, violating the relevant patents, and claim it's just to be compatible with the MP3 format.
No, you are vulnerable to the patent even if your open source file system has nothing to do with FAT, but use the patented algorithms. The software patent crisis affects all.
It doesn't matter. MacOS X remains popular, and useful as a desktop OS. I'm not saying it's not a worthy goal, just that we don't need to distract ourselves with putting a GUI on every last task when there are other important things to fix.
there's only about a million firewall and mail server products with GUIs.
Notice the word "novice" in my statement?
However, neither of those have anything to do with a end-user distribution.
A firewall is very useful even on a desktop machine. MacOS X ships with a firewall, and IIRC so does WinXP. A mail server is less common.
Gosh, no. Not even Mac OS X does that. All you need to take care of in a GUI are the tasks that normal users are expected to do. Advanced users, developers, and administrators can cope with more complex interfaces. I think the more important task is to make it a good GUI, which is very hard. Imagine a UI that can allow a novice to configure a firewall or mail server correctly.
I don't know enough to comment on how the system should keep tabs on packages, but it would be nice to be able to make sense of dependancies.
Or ignore dependencies (at the user level). Most users want to install a named program, like "OpenOffice.org" or "Mozilla", and could not care less what libraries that will bring in.
What will determine the success of Linux on the desktop is not what you add, but what you successfully hide. This includes many options and details that a developer might think nobody can live without, and may include entire applications that are not as good in most respects to another. "Successful" here is determined by the percentage of time the user can spend doing productive work.
Philosophically, the desktop is about "because it's really useful", not "because we can". Win or lose will depend on whether the Linux community can change its mindset.
I just did the math. It's only about six thousand times better, which should not fill you with confidence.
You go on to propose several ways to improve the pass phrase, and they are all good. I did not say that a word-based system cannot be effective, but that we should not consider the search space simply to be the number of words in the English language raised to the power of number of words used. A heuristics-based dictionary attack may find a weak password with a search space many magnitudes smaller.
You might be joking, but yes, it will. If I know or can guess that the person is a Slashdot reader, then I simply expand my dictionary. Just because it's misspelled doesn't mean it's random! For example, there are really just one common misspelling of the word "weird". How hard do you think it'll be for a bot to crawl through Slashdot postings to find these novel spellings?
The basic lesson is, the more I know about the password (English sentence, Slashdot user, etc), the smaller my search space can be. Naively assuming that the search space is always going to be 45000^6 (which is essentially six random words) shows little understanding of how these things are cracked.
You've missed the point, in more than one way, I think. The heuristics I proposed as an example are not meant to be rules that will help crack every password. These are assumptions that may very well be completely wrong, but dramatically narrow the search space if they are right.
Furthermore, what I proposed includes identifying words that can be used as verbs in my dictionary, not from an arbitrary sentence. It's a simple (if tedious) task of classification.
By the way, what's "AI-complete"? Do you mean "NP complete"?
I fear not. If the cracker knows that your password is a valid English sentence, then the search space is significantly reduced. For example, you can trivially discard any combination that doesn't include a verb. This observation alone probably takes the search space down to 6v*(45000^5), where v is the number of verbs in the dictionary, presumably much smaller than 45,000. A reasonable guess that one of the words is "password" would make the search space 6*(6v*(45000^4)). More importantly, most of your 45000 words are obscure. An attacker would likely initially try at most 5000 common words (which would cover every word in that password). All of a sudden, we're talking about 6*(6v*(5000^4)).
By making three assumptions, I have narrowed the search space down by maybe eight zeroes - a hundred million times easier - assuming 'v' is in the thousands range. Now, you might say I chose those three assumptions because I already know the password. That is of course true, but what you need to consider is whether the worst password in your entire system satisfies those assumptions (derived entirely from only the knowledge that the password is an English sentence). Crackers can get lucky, too.
In real life, you'd attack such a password by picking strings from the fortunes files, books, and other sources of quotes, and then we're only talking hundreds of thousands of tries. Remember that many crackers only need the weakest password.
You're absolutely right, except that wasn't my point. I'm also not trying to say that government can be a very good judge of such subjective values at all. What I am trying to say is that the capitalist free market is not one.
I think maybe you meant to phrase that as "...a generation of children with access to the classic writings" (without the "free").
Unfortunately, the "free" does matter. People, for their own strange reasons, would take advantage of free public stuff like libraries and parks, but not if you had to spend even a minimal overt sum. So no, I did not mean to leave out the word "free".
We don't all have the same interests/strengths, but a library can only hold so many books to try and cover all our interests...which very likely leads to a library with books not distributed in topics even close to the interests of the actual population.
Again, this is true, but it is not an indictment of the public library system. In theory, at least, a community pooling its resources together to buy general interest books is an efficient way of spending money. If each person contributes one book (in terms of taxes) to the library, then you're already ahead if you just borrow two books to read. This is highly efficient even if you factor in a vibrant used book marketplace.
Now, if the library doesn't stock the books you (the general community and you personally) like, then what's needed is a process to get them to listen. Cutting their budget is not going to improve their selection.
I didn't say that was the only goal of a public library, just that it is one whose benefits are difficult to measure in terms of money. Capitalism fails again and again where money cannot accurately represent the value of something, which is why most countries have environmental laws, national parks, and some have anti-trust laws and mandatory vacations.
The point is, it's wonderful to scrutinize government to correct inefficiencies. However, it's unwise to throw every government service into the capitalist market, as a general cure.
Unfortunately, not funding government doesn't mean it can or will become more efficient with the money it does have. Quite often, it will end up cutting essential programs and services, rather than providing the same level of service at lower cost. Now, I'm not saying governmental efficiency is not a worthy goal to pursue, just that it's not as simple as "starving the beast".
In the case of a public library, its value is difficult or impossible to quantify with money, and therefore is not appropriately subjected to the capitalist market. What's the (capitalist market) value of a generation of children with free access to the classic writings?
That's more like four or five problems. :)
I'm not sure what "management" you are worried about. Tape the key phrase to the front of the machine. (We're talking about a server, locked in a room.)
To revoke the key, you can reinstall the entire OS with a different key, or simply replace the key in the existing kernel if you're confident. The former should be pretty standard practice in a breach scenario. Note also that "if the key is cracked" should be an unlikely scenario. Crackers are like water, flowing downhill towards the easiest attacks. Cracking a good encryption key is a pretty significant enterprise.
In the scheme we're talking about, the administrator signs the code. This can either be done by a compiler, or by an installer program, depending on your paranoia level. This is not much more complex than apt-get or rpm asking for a root password before proceeding.
If the source is compromised, then the key buys you nothing. However, realize that this is no worse than before, so it's not a "problem" of this scheme, but simply an attack it does not protect against. (This doesn't protect against somebody prying open the door to your server room, either.)
It's rediculously complicated to use public key encryption even with only server software. [...] They're banking on the fact it's confusing, possibly impossible, to manage all those keys and signatures
How so? The compiler (on a different, preferably disconnected machine) would ask you for the private key when you build the software. It is no more complex than managing licensed software with keys tied to a machine, which most administrators already do competently. Maybe there's a misunderstanding. I'm talking about one key (to match the public key installed in the kernel) per machine, which should be no more trouble than a notebook locked in a room.
Oh, I wasn't talking about Linux in particular. I was responding to a post that made it sound as if system call bugs are trivially exploited by any user. It may not be practical to implement this in Linux (possibly because of having many ways to run an application), but I was referring to (server) operating systems in general where that problem may not apply.
Sorry, I must have been vague, although some responses have grasped the main point of what I'm talking about.
The binaries are signed by the local root user (preferably on a separate box), at install time. The public key is installed in the kernel. This is about the root user preventing the box from running anything he did not install, not for the program's copyright owner or whoever else to control if it can run. As you can see, this has little to do with DRM, where another party controls what runs and what doesn't on your machine.
I'm also mainly talking about servers, on which ideally only a few trusted programs are installed. This lowers the signing overhead, and doesn't have a "power user" problem.
Since it is hard to coax an existing signed application into making your evil system call, the most likely target would then be the various script interpreters. That's a valid concern, and you should restrict yourself to those interpreters with a sandbox concept, and are well implemented.
The point is, by requiring two separate "points of failure", we are restricting the exploit to the intersection of time between the introduction and fixing of each bug. If no application bugs are known (to the cracker) at the time the kernel is vulnerable, you cannot exploit the bug. The reverse is also true.
I hope this helps clarify the point.
I suggest you consider the solution again. The underlying bug (kernel buffer overflow, for instance) doesn't disappear. It's just much harder to exploit. In an unsigned system, it's a pretty trivial task to download a binary that makes the "proper" kernel call. If a compiler is installed, you can even just type in a program.
On the other hand, on a signed system the only way is to get an existing signed binary to make a bad system call. That's still possible, but now we're talking about two bugs, one in the kernel and a corresponding one in an user space program. Given that a dedicated server should be running the smallest number of the most trusted programs, this may not be such an easy task, and at the very least may slow down the attacker.
So what are these multitude of ways you can run an arbitrary application?
We should point out that you're talking about common kernels like Linux today, not that this must apply to any OS kernel. For example, if the kernel verifies the binaries it runs using digital signatures, then it can refuse to run unsigned binaries. The cracker's problem then becomes how to get an existing userland program (compiled by the trusted administrator) to issue the kernel call that results in the exploit, which is a much harder problem. A program may not ever make that system call, or may check its input so that you can't make it do the system call with (presumably) invalid parameters. In most cases, I expect that this means you have to insert a backdoor into a common program and wait for the trusted administrator to compile it for you.
This sort of security is probably overkill and too tedious for a desktop box, but not unreasonable for a server which should only have a few programs installed and running anyway.
You set an impossibly high bar for the word, rendering it almost meaningless. All human inventions are built on top of prior art (human-made or naturally occuring), so by your criteria it appears that nothing can be considered "truly innovative".
Let me propose some alternative criteria. One, is it original? If not, it's not innovative. Two, is it worth copying? If not, it's not innovative.
Agreed, so design new utilities that understand XML. Take /etc/passwd or any CSV file for example. If you grep it for a user whose first name is "Richard", you'll also find somebody whose last name is "Richards" or lives on "Richard Street". An XML sensitive grep equivalent could understand a command like this:
and return better results without intimate knowledge of the file format (which column corresponds to which field, etc).No, your company did the exact right thing in choosing XML. When the nascent system is still being actively debugged, you made the process much easier because XML is human readable. As you begin to scale up its use, you proved a performance problem and relied on the modularity of the code to simply replace the XML code with efficient binary formats. If you had not seen a performance problem (perhaps the bottleneck is elsewhere and inevitable anyway), then presumably you'd leave the XML code alone.
You started with a general solution, and then optimized as necessary. I consider this an example of a job well done.
I think you miss the RIAA's point almost entirely.
Nothing will stop a dedicated and technologically sophisticated person from violating copyright. The CD, as someone points out, is utterly unprotected. Even the Apple DRM has a glaring hole that lets you burn to CD and re-rip. None of these are intended to stop the determined would-be infringer.
The ones they do stop are the casual ones. If it's tedious (burning hundreds of songs to CD and re-ripping them for the sole purpose of sharing them is not most people's idea of fun) and dangerous (the RIAA very publicly goes after "normal people" for this purpose), then there will only be a few willing to do it and risk it.
Those few are easy to take care of. They can be tracked down and sued into oblivion. What the RIAA really fears is if music sharing is easy, because despite what they say, they can't sue everybody. Something that everybody (not just geeks) doesn't feel is criminal soon becomes so.
Actually, chess players at Kasparov's level train mentally and physically so that they can perform at or near their peak when it matters: during a match. This is the same whether you are facing a computer or human opponent. It doesn't work every time, of course, but you make it sound as if Kasparov just walked up to the computer and started playing. No, he would've prepared for months.
This is psychologically different. Many animals can lift more weight or run faster than we can, and that has been true for as long as humans existed. However, we were the best in chess.
You can ensure that the word "champion" is reserved for humans, but the honor will be as hollow as the difference in skill between the human champion and the best machine player.
Retired PC's generally consume less power than modern ones.
I'm comparing a typical old desktop, compared to something designed to be up 24/7. The old PC is also likely to have a smaller, older, and less reliable hard drive. Worse, it's tempting for a geek to turn an old PC into a home server even if he doesn't actually need one. (I'm not talking about your specific case, because I obviously don't know your needs.)
A PDA in a cradle won't consume much more power than an alarm clock, and will do so without creating the toxic waste of AA batteries.
Two AA batteries in an alarm clock can last years. I'd be lucky if they last 2 weeks on my old PDA, so I don't think they are as energy efficient as you think. While you're not adding toxic waste, somebody still has to generate your power, possibly by burning something.
I'd hardly consider any kitchen with adequate ventilation to be a "harsh environment."
I was referring more to smoke and grease, and grubby fingers. "Harsh" is used not relative to factory floors or coal mines, but the clean desktop office they were designed for.
Keeping a machine out of a landfill is a good reason.
I completely agree. However, my point is that selling your machine or giving it away may be a better use for it than to invent household uses for them that they were never designed for. Sometimes...
we have retired 2 NeXT slabs, a NeXT cube, and a Sparc Station because they didn't make sense in terms of money, time, noise, or power requirements.
is exactly the best solution.
That's exactly the point. The goal is not to find a set of gcc switches that will work best on any program on any supported platform. The goal is to find the set that works best with this particular input, without human guidance.
10% or 20% improvements in compiler performance are of largely academic interest only these days most software's time is spent waiting on user input, disk IO, or network activity anyway?
First of all, what if you can get the 10% or 20% basically for free? That is, simply run your compile for a few unattended days to get the optimization? What is not worth human tweaking time can easily be worth machine time. Gentoo, although I do not use it myself, appears to be a vibrant Linux distribution based exactly on this point.
Secondly, most existing software are running on small CPUs all around you, not on your desktop. The constraints of memory usage and CPU power are still very real for them.
Finally, consider also that more efficient software may result in more idle hardware and lower power consumption. Imagine if all PCs in the world can get by with 5% less electrical power.