no more obscure textfiles in obscure places on your hardrive, no more.blablabla files in your homedirectory.
This doesn't make any sense. The XML would have to be stored somewhere. My guess is in/etc/something. As for user-specific settings, where else would they go but some.something/ directory in the user's home?
Plain ASCII files with fixed syntax are obsolete. The revolutionary thing about XML is not it's syntax, not the way it stores stuff but the fact that you can define extensible syntax structures with it and that you can use generic software to read and write to it.
Such "generic software" already exists for flat ASCII text files. It is called emacs, vi, perl, sed, awk, grep, diff . . . the list goes on and on.
In fact I have an idea that may be shocking for hardcore UNIX guys (stop reading if you want to sleep tonight): why not replace the syntax of programming languages like C and Java with XML equivalents.
This isn't that shocking a suggestion, since it's been done. Those who have programmed ColdFusion Server's CFML language, to take one example, already know that XML-based programming languages tend to have heavy, verbose, and annoying syntax because you have to enclose everything in angle brackets.
One feature of markup languages like XML and HTML is that anything not enclosed in angle brackets is a string literal. This is good when you want to mark up content, but annoying for general-purpose programming. How much of the average program consists of string literals?
I know that c++ syntax is more complex than Java syntax (one of the reason why you don't find so much tools like javadoc for c++).
The reason there is no javadoc for C++ is cultural: Bjarne Stroustrup did not decide that there should be a way to automatically generate documentation from code, and Arnold Gosling did. The task of parsing special comments, which is what javadoc uses to generate its output, is pretty trivial and would not be hard to do for C++.
A filesystem may look nice from the outside and have lots of great features, but when something goes wrong and the settings for your favorite daemon are in a corrupt filesystem what are you going to do?
Restore from backups of course. This is easy for a filesystem because filesystem interactions are standardized, and hence many tools are available to do periodic filesystem backups of all kinds. Furthermore, since every scripting tool understands the filesystem, it is also easy to write any kind of customized backup scheme of your own.
A relational database, on the other hand, *especially* if it has capabilities beyond those of a filesystem (transaction processing, record locking, rollback and recovery), tends to require that you use some special application-specific backup utility. This is a big loss for data as simple as configuration files, though for, say, financial records it's worth it.
However, binary files may have an arguable advantage - space and speed.
Space and speed are cheap, especially given the negligible cycles required to parse config files.
Part of the Unix philosophy is that the pervasiveness of text is considered a feature, not a bug. Text is a good interface for many reasons. Three of the most important ones are:
It is easy for a human who knows what (s)he is doing to hand-edit text. This becomes very important in cases like config file corruption or broken configuration tools.
Text editors are well-understood and mature, and almost never broken: emacs, vi, etc.
Most existing Unix tools are very good at working with text, making it easy to write scripts to automatically process anything made of text.
I don't know why everyone is so opposed to copying the Windows Registry idea. Granted, you can edit XML with a text editor, but if every Linux distribution which used a "registry" or configuration came with command-line and GUI tools to edit it, and reasonable precautions were made for redundancy and backups to protect the database integrity, who could object?
Q: What is the purpose of a registry?
A: To provide a unified heirarchical view of configuration data and an API for accessing that data.
A heirarchical view of configuration data is provided by the Linux filesystem. An API for accessing that data is provided by stdlib.c.
Adding a binary database gives us exactly zero advantages over merely (a) standardizing the configuration file heirarchy under/etc and (b) using XML in selected cases to represent complex structured and semi-structured data.
Registries in and of themselves are not a bad idea. However, we don't need an opaque binary file coupled with a superfluous API in order to have a registry: we can implement one just fine using only the existing filesystem, text, and existing libraries. It would have all the features that you outline above.
I find it interesting that someone with enough know-how to co-create the computer, Brutus.1, would have such a limited mindset. My dog doesn't have a human body, but I'm reasonably sure that it's conscious.
This isn't a limited mindset at all. Douglas Coupland speculates in Microserfs that the peripheral nervous system functions as a peripheral memory storage device. In that case, part of that which makes up your mind might be stored in your body: peripheral memory. Such peripheral memory might in fact function in a very different way than central memory.
Anyway, what evidence of consciousness does your dog display? Consciousness implies self-consciousness, which implies a capacity for reasoning about oneself. No dog that I've ever met is really capable of any such thing: for the most part they're idiots.
This was not obvious, as a previous poster noted, until court decisions in the past few decades ruled that it was.
In any case, I am perfectly aware that patents have been awarded on purely mathematical processes. My assertion was that this should never have been possible, and constitutes a betrayal of the original intent (as well as court precedent) regarding patents. Which would have been clear had you thought for half a second before replying.
It's true that my opinion doesn't matter, mostly because I don't have a lot of money with which to influence the government. But I'm still entitled to my opinion.
It's not the math - it's not the process that's patented - it's the utility arising from the math and process that's patented.
This is one of the silliest things I have ever read. "Utility" is a vague, abstract economic quantity and cannot be patented. Specific inventions are patented. Utility is what people gain from these inventions, and the idea is that some of this utility should funnel back, in the from of money, to those inventors. But it is not utility that is patented. Lots of people generate nonpatentable utility all day long by, for example, cutting up meat.
BTW: I was mistaken about the processes thing. This link explains the different kinds of patents. Processes can be patented. Oops.
However, the original intention was to allow inventors to patent specifically mechanical (i.e., physical) processes. The US patent office site writes:
Interpretations of the statute by the courts have defined the limits of the field of subject matter which can be patented, thus it has been held that the laws of nature, physical phenomena and abstract ideas are not patentable subject matter.
Many people, myself included, assert that an algorithm, as an abstract mathematical process, is much more like an idea than a machine or a technique for manufacturing doughnuts. A closer software analogue of a patentable "mechanical process" is an implementation of an algorithm in software. That is, RSA should have been awarded a patent, not on an algorithm for public key encryption, but on the piece of software that they wrote.
The patenting of algorithms veers very close to the patenting of ideas or laws of nature. The quicksort algorithm (to take a bland example) is no less a pure idea than Pythagoras's theorem or Newton's axioms of motion. That this is not clear to you and every programmer in the nation is a testament to the sorry state of CS education in America.
Algorithm patents are a crock. Patents are a legal mechanism to protect the invention of machines, not ideas; a patent specifically cannot cover (a) processes and (b) mathematical formulae, among other things. An algorithm is both a process and a mathematical formula, so it cannot be covered by a patent.
The fact that algorithm patents have been awarded by the US Patent Office is the result of money and business interests winning out over the letter of the law.
That article is from the Unix-haters handbook. Sorry, but taking the advice of people who hate Unix on a fundamental level on how to improve it seems kind of stupid to me.
Errr, the book has an "anti-forward" by Dennis Ritchie. Not exactly someone who hates Unix on a fundamental level. I think the book is more about playfully taking Unix to task for all its ugliness than suggesting that it be abandoned. When you think about it, all operating systems are evil, and Unix is really just the least evil operating system of them all.
It would take YEARS to replace X....YEARS! It has a decade and a half thus far to build it, how are you going to replace such a thing over night???
This argument is specious. Unix has been around since 1970. Yet Linux matured into a viable alternative to commercial Unices (SCO, for example) a mere 5 or 6 years after it was born.
The time it takes to duplicate or surpass the functionality of a system bears little relationship to the age of the system.
maybe 10 years from now it will have surpassed the X of today. But then were is X going to be, and were WOULD it have been had those people added some input and made X better?
Another specious argument. The GNOME/GTK people could have decided to make, say, an extended version of FWVM/Lesstif. However, they didn't: they decided to write something better from scratch. I think most people would agree that RedHat 6 demonstrates that they made the right decision. If GNOME isn't completely up to spec yet, it soon will be.
OTOH, I believe X is here to stay, for the same reason that the x86 instruction set is here to stay: momentum. That doesn't mean that good hackers everywhere can't have hopes and dreams about creating and using something more technically elegant. Eventually, the next-generation window system may even take over, just as Merced/McKinley and its successors may eventually make the x86 a thing of the past.
Saying that some instances can be solved in linear time is meaningless anyway... linear describes the growth of complexity when compared to the size of the dataset - when all you have is a series of points then talking about its complexity is impossible.
I believe he meant to say some subsets (special cases) of the problem can be solved in linear time, which is no big news anyway. For example, the TS problem is easy to solve in linear time in the special case that the graph is a circle.
The question is moot anyway, because the notion that the computer solves the TS problem in "linear time" is correct but deceptive. In Fundamental Algorithms, all CS majors are taught to think of the Theta(N) (order of growth) as the "running time" of an algorithm; they then forget that "running time" is a metaphor for a number of computations. A more correct term for Theta(N) would be "increase in computational resources as input size grows".
A DNA computer uses the chemical and structural properties of DNA to perform an exponential number of calculations in parallel. Thus, it is not computing a linear solution to the Traveling Salesman problem, but merely throwing vastly more computational resources at it. The former is an algorithms problem; the latter is an engineering problem.
(BTW: I suspect that the amount of DNA you need does, in fact, increase exponentially with the data set size but in general this is not a consideration since you can put an insane quantity of DNA in a vat.)
Err, part of the point of KT's essay was that his hack was undetectable even with the source code. Once you rebuild the compiler once with the infected source, it's undetectable and virtually unremovable unless you can get a hold of binaries that are verifiably "pure".
Strictly speaking, of course, you don't have to accept a precompiled compiler. I took a course once with Robert Dewar, a legendary professor at NYU who told us a story about bootstrapping a computer from scratch-- no assembler, no display driver, no disk drive, nothing but a power switch and a BIOS that could accept raw machine-language hex input from the keyboard to execute. First he wrote a display driver, then he wrote a driver for the tape drive, and finally he wrote an assembler, all in machine language. After that things got considerably easier (ha).
The point being, there is always the possibility of bootstrapping yourself up if you really need to. Anyway, I imagine that it's somewhat more difficult to embed a KT-type "trust" virus inside an assembler than a compiler, given that the assembler runs at such a low semantic level. Compilers used to be written in assembly, and they can be so written again.
Superscalar x86 architectures have been around since the first Pentium, which could also theoretically do 3 instructions per clock cycle (in practice it almost never does). But superscalar does not mean that cracking an rc5 key, let alone several, in a single clock is plausible.
Let's do the math. Given that overclocked Celeron-464 will give you about 1.3 Kkeys/sec:
Given the small working set of rc5, memory latency and cache effects are probably negligible, so I believe this figure is CPU-limited.
People who are suggesting that the E2K cracks one key per clock cycle are being utterly ridiculous. A "crack rc5" instruction would have to carry out the equivalent of 360,000 P2 instructions. A VLIW/EPIC architecture, like a RISC architecture, depends upon fairly elementary individual instructions, even during vector processing (floating point ops are an exception, but are not relevant since AFAIK rc5 uses integer instructions exclusively). A "crack rc5" instruction would royally fubar the pipeline.
BTW the above figure is attained using the MMX/bitslice rc5 core, which is explicitly optimized for the P2 architecture's MMX instructions. True, the E2K has a different architecture than a Celeron. However, if E2k were cracking keys, it would be using the x86 client. It is inconceivable that the E2K could execute the equivalent of hundreds of thousands of P2 instructions in a single clock.
Of course, there are other reasons to believe that this is a hoax, but the technical reasons alone are sufficient to dismiss it out of hand. That Russian team is getting a pretty good keyrate; too bad they had to dress it up in lies.
Isn't it amazing that Trasmeta, without any thing, has most people here believers.
While E2K, on the same boat, with evidence, has most people here yell fraud?
What an idiotic thing to say. First of all, these E2K rc5 stats are not evidence. Team Slashdot could change its name tomorrow to Team McKinley and claim to be cracking all its keys on a single McKinley chip, but only an idiot would believe us, for many reasons, chief among them being that McKinley does not exist in silicon.
Elbrus's website has no press release endorsing these people, and you can bet a company as loudmouthed as Elbrus would be shouting from the rooftops if they had a working piece of silicon that cracked keys at that rate.
Second, as someone already noted, Transmeta has made no real claims about processor performance. Even if they were to make such claims, I would not believe them until I saw a machine that I could boot up and use for real applications. Most sensible people here (the silent majority) would not believe them either.
Slashdot Mirror
no more obscure textfiles in obscure places on your hardrive, no more .blablabla files in your homedirectory.
/etc/something. As for user-specific settings, where else would they go but some .something/ directory in the user's home?
This doesn't make any sense. The XML would have to be stored somewhere. My guess is in
Plain ASCII files with fixed syntax are obsolete. The revolutionary thing about XML is not it's syntax, not the way it stores stuff but the fact that you can define extensible syntax structures with it and that you can use generic software to read and write to it.
Such "generic software" already exists for flat ASCII text files. It is called emacs, vi, perl, sed, awk, grep, diff . . . the list goes on and on.
In fact I have an idea that may be shocking for hardcore UNIX guys (stop reading if you want to sleep tonight): why not replace the syntax of programming languages like C and Java with XML equivalents.
This isn't that shocking a suggestion, since it's been done. Those who have programmed ColdFusion Server's CFML language, to take one example, already know that XML-based programming languages tend to have heavy, verbose, and annoying syntax because you have to enclose everything in angle brackets.
One feature of markup languages like XML and HTML is that anything not enclosed in angle brackets is a string literal. This is good when you want to mark up content, but annoying for general-purpose programming. How much of the average program consists of string literals?
I know that c++ syntax is more complex than Java syntax (one of the reason why you don't find so much tools like javadoc for c++).
The reason there is no javadoc for C++ is cultural: Bjarne Stroustrup did not decide that there should be a way to automatically generate documentation from code, and Arnold Gosling did. The task of parsing special comments, which is what javadoc uses to generate its output, is pretty trivial and would not be hard to do for C++.
~k.lee
A filesystem may look nice from the outside and have lots of great features, but when something goes wrong and the settings for your favorite daemon are in a corrupt filesystem what are you going to do?
Restore from backups of course. This is easy for a filesystem because filesystem interactions are standardized, and hence many tools are available to do periodic filesystem backups of all kinds. Furthermore, since every scripting tool understands the filesystem, it is also easy to write any kind of customized backup scheme of your own.
A relational database, on the other hand, *especially* if it has capabilities beyond those of a filesystem (transaction processing, record locking, rollback and recovery), tends to require that you use some special application-specific backup utility. This is a big loss for data as simple as configuration files, though for, say, financial records it's worth it.
~k.lee
Space and speed are cheap, especially given the negligible cycles required to parse config files.
Part of the Unix philosophy is that the pervasiveness of text is considered a feature, not a bug. Text is a good interface for many reasons. Three of the most important ones are:
- It is easy for a human who knows what (s)he is doing to hand-edit text. This becomes very important in cases like config file corruption or broken configuration tools.
- Text editors are well-understood and mature, and almost never broken: emacs, vi, etc.
- Most existing Unix tools are very good at working with text, making it easy to write scripts to automatically process anything made of text.
I don't know why everyone is so opposed to copying the Windows Registry idea. Granted, you can edit XML with a text editor, but if every Linux distribution which used a "registry" or configuration came with command-line and GUI tools to edit it, and reasonable precautions were made for redundancy and backups to protect the database integrity, who could object?Q: What is the purpose of a registry?
A: To provide a unified heirarchical view of configuration data and an API for accessing that data.
A heirarchical view of configuration data is provided by the Linux filesystem. An API for accessing that data is provided by stdlib.c.
Adding a binary database gives us exactly zero advantages over merely (a) standardizing the configuration file heirarchy under
Registries in and of themselves are not a bad idea. However, we don't need an opaque binary file coupled with a superfluous API in order to have a registry: we can implement one just fine using only the existing filesystem, text, and existing libraries. It would have all the features that you outline above.
~k.lee
I find it interesting that someone with enough know-how to co-create the computer, Brutus.1, would have such a limited mindset. My dog doesn't have a human body, but I'm reasonably sure that it's conscious.
This isn't a limited mindset at all. Douglas Coupland speculates in Microserfs that the peripheral nervous system functions as a peripheral memory storage device. In that case, part of that which makes up your mind might be stored in your body: peripheral memory. Such peripheral memory might in fact function in a very different way than central memory.
Anyway, what evidence of consciousness does your dog display? Consciousness implies self-consciousness, which implies a capacity for reasoning about oneself. No dog that I've ever met is really capable of any such thing: for the most part they're idiots.
~k.lee
Obviously algorithms are subject to patents.
This was not obvious, as a previous poster noted, until court decisions in the past few decades ruled that it was.
In any case, I am perfectly aware that patents have been awarded on purely mathematical processes. My assertion was that this should never have been possible, and constitutes a betrayal of the original intent (as well as court precedent) regarding patents. Which would have been clear had you thought for half a second before replying.
It's true that my opinion doesn't matter, mostly because I don't have a lot of money with which to influence the government. But I'm still entitled to my opinion.
It's not the math - it's not the process that's patented - it's the utility arising from the math and process that's patented.
This is one of the silliest things I have ever read. "Utility" is a vague, abstract economic quantity and cannot be patented. Specific inventions are patented. Utility is what people gain from these inventions, and the idea is that some of this utility should funnel back, in the from of money, to those inventors. But it is not utility that is patented. Lots of people generate nonpatentable utility all day long by, for example, cutting up meat.
BTW: I was mistaken about the processes thing. This link explains the different kinds of patents. Processes can be patented. Oops.
However, the original intention was to allow inventors to patent specifically mechanical (i.e., physical) processes. The US patent office site writes:
Interpretations of the statute by the courts have defined the limits of the field of subject matter which can be patented, thus it has been held that the laws of nature, physical phenomena and abstract ideas are not patentable subject matter.
-- http://www.uspto.gov/web/ offices/pac/doc/general/what.htm
Many people, myself included, assert that an algorithm, as an abstract mathematical process, is much more like an idea than a machine or a technique for manufacturing doughnuts. A closer software analogue of a patentable "mechanical process" is an implementation of an algorithm in software. That is, RSA should have been awarded a patent, not on an algorithm for public key encryption, but on the piece of software that they wrote.
The patenting of algorithms veers very close to the patenting of ideas or laws of nature. The quicksort algorithm (to take a bland example) is no less a pure idea than Pythagoras's theorem or Newton's axioms of motion. That this is not clear to you and every programmer in the nation is a testament to the sorry state of CS education in America.
~k.lee
Algorithm patents are a crock. Patents are a legal mechanism to protect the invention of machines, not ideas; a patent specifically cannot cover (a) processes and (b) mathematical formulae, among other things. An algorithm is both a process and a mathematical formula, so it cannot be covered by a patent.
The fact that algorithm patents have been awarded by the US Patent Office is the result of money and business interests winning out over the letter of the law.
~k.lee
mirror ahoy.
Bringing this post up further.
That article is from the Unix-haters handbook. Sorry, but taking the advice of people who hate Unix on a fundamental level on how to improve it seems kind of stupid to me.
Errr, the book has an "anti-forward" by Dennis Ritchie. Not exactly someone who hates Unix on a fundamental level. I think the book is more about playfully taking Unix to task for all its ugliness than suggesting that it be abandoned. When you think about it, all operating systems are evil, and Unix is really just the least evil operating system of them all.
~k.lee
It would take YEARS to replace X....YEARS! It has a decade and a half thus far to build it, how are you going to replace such a thing over night???
This argument is specious. Unix has been around since 1970. Yet Linux matured into a viable alternative to commercial Unices (SCO, for example) a mere 5 or 6 years after it was born.
The time it takes to duplicate or surpass the functionality of a system bears little relationship to the age of the system.
maybe 10 years from now it will have surpassed the X of today. But then were is X going to be, and were WOULD it have been had those people added some input and made X better?
Another specious argument. The GNOME/GTK people could have decided to make, say, an extended version of FWVM/Lesstif. However, they didn't: they decided to write something better from scratch. I think most people would agree that RedHat 6 demonstrates that they made the right decision. If GNOME isn't completely up to spec yet, it soon will be.
OTOH, I believe X is here to stay, for the same reason that the x86 instruction set is here to stay: momentum. That doesn't mean that good hackers everywhere can't have hopes and dreams about creating and using something more technically elegant. Eventually, the next-generation window system may even take over, just as Merced/McKinley and its successors may eventually make the x86 a thing of the past.
~k.lee
Saying that some instances can be solved in linear time is meaningless anyway... linear describes the growth of complexity when compared to the size of the dataset - when all you have is a series of points then talking about its complexity is impossible.
I believe he meant to say some subsets (special cases) of the problem can be solved in linear time, which is no big news anyway. For example, the TS problem is easy to solve in linear time in the special case that the graph is a circle.
The question is moot anyway, because the notion that the computer solves the TS problem in "linear time" is correct but deceptive. In Fundamental Algorithms, all CS majors are taught to think of the Theta(N) (order of growth) as the "running time" of an algorithm; they then forget that "running time" is a metaphor for a number of computations. A more correct term for Theta(N) would be "increase in computational resources as input size grows".
A DNA computer uses the chemical and structural properties of DNA to perform an exponential number of calculations in parallel. Thus, it is not computing a linear solution to the Traveling Salesman problem, but merely throwing vastly more computational resources at it. The former is an algorithms problem; the latter is an engineering problem.
(BTW: I suspect that the amount of DNA you need does, in fact, increase exponentially with the data set size but in general this is not a consideration since you can put an insane quantity of DNA in a vat.)
~k.lee
Err, part of the point of KT's essay was that his hack was undetectable even with the source code. Once you rebuild the compiler once with the infected source, it's undetectable and virtually unremovable unless you can get a hold of binaries that are verifiably "pure".
Strictly speaking, of course, you don't have to accept a precompiled compiler. I took a course once with Robert Dewar, a legendary professor at NYU who told us a story about bootstrapping a computer from scratch-- no assembler, no display driver, no disk drive, nothing but a power switch and a BIOS that could accept raw machine-language hex input from the keyboard to execute. First he wrote a display driver, then he wrote a driver for the tape drive, and finally he wrote an assembler, all in machine language. After that things got considerably easier (ha).
The point being, there is always the possibility of bootstrapping yourself up if you really need to. Anyway, I imagine that it's somewhat more difficult to embed a KT-type "trust" virus inside an assembler than a compiler, given that the assembler runs at such a low semantic level. Compilers used to be written in assembly, and they can be so written again.
~k.lee
Superscalar x86 architectures have been around since the first Pentium, which could also theoretically do 3 instructions per clock cycle (in practice it almost never does). But superscalar does not mean that cracking an rc5 key, let alone several, in a single clock is plausible.
Let's do the math. Given that overclocked Celeron-464 will give you about 1.3 Kkeys/sec:
(4.64*10^8) / (1.3*10^3) =~ 3.57 * 10^5 clocks/key
Given the small working set of rc5, memory latency and cache effects are probably negligible, so I believe this figure is CPU-limited.
People who are suggesting that the E2K cracks one key per clock cycle are being utterly ridiculous. A "crack rc5" instruction would have to carry out the equivalent of 360,000 P2 instructions. A VLIW/EPIC architecture, like a RISC architecture, depends upon fairly elementary individual instructions, even during vector processing (floating point ops are an exception, but are not relevant since AFAIK rc5 uses integer instructions exclusively). A "crack rc5" instruction would royally fubar the pipeline.
BTW the above figure is attained using the MMX/bitslice rc5 core, which is explicitly optimized for the P2 architecture's MMX instructions. True, the E2K has a different architecture than a Celeron. However, if E2k were cracking keys, it would be using the x86 client. It is inconceivable that the E2K could execute the equivalent of hundreds of thousands of P2 instructions in a single clock.
Of course, there are other reasons to believe that this is a hoax, but the technical reasons alone are sufficient to dismiss it out of hand. That Russian team is getting a pretty good keyrate; too bad they had to dress it up in lies.
~k.lee
Isn't it amazing that Trasmeta, without any thing, has most people here believers.
While E2K, on the same boat, with evidence, has most people here yell fraud?
What an idiotic thing to say. First of all, these E2K rc5 stats are not evidence. Team Slashdot could change its name tomorrow to Team McKinley and claim to be cracking all its keys on a single McKinley chip, but only an idiot would believe us, for many reasons, chief among them being that McKinley does not exist in silicon.
Elbrus's website has no press release endorsing these people, and you can bet a company as loudmouthed as Elbrus would be shouting from the rooftops if they had a working piece of silicon that cracked keys at that rate.
Second, as someone already noted, Transmeta has made no real claims about processor performance. Even if they were to make such claims, I would not believe them until I saw a machine that I could boot up and use for real applications. Most sensible people here (the silent majority) would not believe them either.
~k.lee