This came up on the lkml recently. Cheap multi-Opteron systems are often set up to have a single bank of memory rather than two, and are actually uniform. More expensive ones have the two banks, although you can generally make them uniform with a BIOS setting (which is occasionally the default).
It makes a lot of sense to have a standard parser which will give an AST for a language (or a class of languages, if given a DTD-equivalent for the language). On the other hand, producing XML for it just means you have to reparse the XML. A better idea is to have something which acts like an XML parser except that it takes in a programming language instead of actual XML.
I keep expecting this to show up in Java. I mean, there's a Java parser that javac uses, and it is used separately by javadoc, and even exports some of the content for use in javadoc extensions, but you still can't call it to just parse a file for you. It's much harder in C because the preprocessor and the parser don't use the same tokens, meaning that the parser's view of the code may have little in common with the programmer's view (while the preprocessor's view, which matches the programmer's view, isn't very useful).
"Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title." (USC 35 101)
Chemicals are essentially mentioned explicitly in the law as an invention patentable. Of course, a new DNA sequence isn't really a new composition of matter, although most things you can do with DNA involve the production of chemicals which might be new.
The article mentions SiteFinder, but before that VeriSign was sent fraudulent email to owners of domains registered through other registrars, and just this weekend they transferred panix.com (registered through a different registrar) to a hijacker. Considering the way the seem to have blown off both the rightful owner of the domain and law enforcement, I think it would be appropriate to take into account the possibility that VeriSign will be convicted of computer crimes and banned from computers by court order within the period of this contract when deciding whether to give it to them.
To make the point that this is still important, I've recently been using a web app that uses the name of the program as the title of every page, and it is therefore very difficult to return to a page you were at before.
I can't come up with any nice Windows apps. Sure, there are necessary Windows apps (for some people, at least), but I can't think of any that most users don't hate. "Nice" apps are for the Mac (as opposed to "powerful" ones for Linux, and "critical" ones for Windows).
No, although hopefully this will foster communication between the two projects. There are a number of things which could use an efficient in-kernel implementation, such as case-insensitive name lookup (it's generally agreed that case-insensitive filesystems are broken, but Samba needs to provide this nonetheless and Wine would like it as well). There was eventually a productive discussion, and Linus (IIRC) came up with a clever idea once it was clear that this was necessary (and once the desired behavior for the odd cases was specified).
Depends somewhat on whether those suits would have been avoided by caution. After getting hit with IP lawsuits that you couldn't have avoided, one is more likely to decide to ignore legal issues, particularly in the case of patents, where being cautious may triple your legal liability without reducing your risk substantially.
Last I heard, LSB was requiring a version of gcc's C++ ABI that the gcc people said was broken and was being replaced. Due the scheduling desires, LSB 2.0 (IIRC) was released with the broken one, because a stable version of gcc which supported the new one wasn't ready yet. Did this ever get cleared up, or is it still broken?
The problem with getting ISO involves now is that not everything is completely correct at this point. Of course, it's not like people generally exactly follow ISO standards, either, so it may be just as well.
The people who are uploading things as they download them plausibly qualify for common carrier status. There's no way you could accuse BayTSP of wrong-doing if they don't know what it is they're getting and sending. And they're only downloading it in the first place because they don't know what it is and are trying to determine this. That's why they're more interested in going after the torrents rather than the users; most users, once they have the files and could determine what they are stop uploading them.
Three ideas, in order of increasing significance and increasing difficulty:
Stop using bad DTDs. There seems to be a DTD style in which you avoid using attributes and instead add a whole lot of tags containing text. Any element with a content type of CDATA should be an attribute on its parent, which improves the readability of documents and lets you use ID/IDREF to automatically check stuff. Once you get rid of the complete cruft, it's not nearly so bad.
Now that everything other than HTML is generally valid XML, it's possible to get rid of a lot of the verbosity of XML, too. A new XML could make all close tags "</", since the name of the element you're closing is predetermined and there's nothing permitted after a slash other than a >. The > could be dropped from empty tags, too. If you know that your DTD will be available and not change during the life of the document, you could use numeric references in open tags to refer to the indexed child element type of the type of the element you're in, and numeric references for the indexed attribute of the element it's on. If you then drop the spaces after close quotes, you've basically removed all of the superfluous size of XML without using a binary format, as well as making string comparisons unnecessary in the parser.
Of course, you could document it as if it were binary. An open tag is indicated with an 0x3C, followed by the index of the element type plus 0x30 (for indices under 0xA). A close tag is (big-endian) 0x3C2F. A non-close tag is an open tag if it ends with an 0x3E and an empty tag if it ends with an 0x2F. Attribute indices are followed with an 0x3D. And so forth.
I use the vanilla sources, except that I apply security patches individually to them. You don't actually have to wait for Linus to pick up a patch, apply it to his tree, and release the next version to get the patch. For that matter, security issues are generally in code which hasn't been touched for a long time, so the patches tend to apply to a lot of different versions (although you sometimes have to find that section of code and change it yourself if the line numbers have changed sufficiently drastically). If you can find the patch and positive commentary from somebody who would know if it's right, it doesn't matter if whoever maintains the tree you normally use is on vacation or something and hasn't applied it.
I'd guess that having people distracting you at random moments will damage your ability to focus and add to the number of things you're always listening for, increasing your cognitive load. The effects of the transmission are unlikely to be significant compared to the effects of the interface.
Sure, you should expect that your conversation with the person at the other end will be heard by some total stranger (in addition to the total stranger you're talking with). But it's not entirely clear that sound from your end goes anywhere while you're on hold. People tend to assume that, since there are no operators available to take your call there aren't any other people around listening to you. So they turn on the speaker phone and go about their business while they wait. Really, phones ought to have a mode where you have the handset hung up, it plays out the speaker, and has no microphone (but you can press buttons for touch-tone sounds, or pick up the handset).
Again, that's no different from 2.4, with the exception that Marcelo is good at picking the ones that work to call 2.4.x, and Linus isn't nearly so good at picking 2.6.x that work.
With respect to needing to switch versions to a kernel that is different in unexpected ways, it's exactly the same if you're running a 2.4 kernel.
There are actually improvements with 2.6: the distros have been invited to take over 2.6.x.y series, so that if they're going to be backporting patches, they can contribute this effort back to the community. In 2.4, the distros carry so many patches that you'd have an easier time backporting from the latest 2.4 vanilla kernel than from a distro kernel with the same nominal version. They have so many patches because they feel the need to add functionality in their stable series.
Also, Alan Cox is maintaining a tree of "really stable" kernels, where he takes only bugfixes from the current work and adds them to the base version he's using. I haven't determined if he's planning to continue 2.6.9-ac indefinitely, or if he's going to only release 2.6.10-ac kernels once he judges 2.6.10-ac to be sufficiently tested.
The real issue is that Linus is currently in charge of releasing the stable versions. He's really good at identifying what should go into the stable series, from the perspective of guiding development, but he doesn't have the discipline to identify a completely-working version and call that 2.6.x. My prediction is that, in accordance with the ManagementStyle document, he will eventually decide that people complain about his release descisions, and therefore he should get somebody else (probably Alan Cox) to do that.
As for development causing security problems, there has yet to be a 2.6 security hole in code that was added during 2.6. In general, new code is checked for all known patterns of bugs (almost all security holes fall into some pattern) and bad practices before being accepted. On occasion, a bug is found which is part of a new pattern, and future code with the same sort of bug will be caught, but existing code with that bug is not necessarily identified. This means that bugs are generally in code that hasn't been changed in a long time, not code which has been changed recently. In fact, there have often been bugs found in old versions which had already been eliminated unknowingly from new versions by people writing replacement code using improved techniques.
For example, the recent hole was in code written ten years ago to facilitate the switch from a.out to ELF. The hole was a race condition due to changes made several years ago in the requirements of common code.
Code is primarily a work of functionality. Regardless of the fundamental beauty of the design, if it doesn't solve your problem, it is useless to you. Music, art, level designs, and so forth are works of content. They do not solve problems but more frequently pose problems for the user to solve, and offer entertainment through the challenge of working them out; or they simply contribute to the user's enjoyment of the experience.
You're also making the usual mistake of thinking that RMS ever has anything to say about the exchange of money. He talks almost exclusively about the granted ability to do things, not the cost of doing them. This is a common mistake because of the term "Free Software" for what is intended to be liberating (not liberated) software, which suggests no-cost as the only thing it could mean literally.
In any case, asking for the right to modify works of content is, in general, foolish. It doesn't make sense to say that, for instance, the Aeneid is unsuitable for you to read due to Aeneas founding Rome at the end and demanding the right to modify it such that he ends up defying fate and getting back together with Dido. Certainly you could write such a work if you wanted to, but you would no longer be simply a reader of the book you're reading and you wouldn't be reading the Aeneid (and, were you then to write a paper about your version as if it were the original, it would not be well received).
For that matter, there are other possibilities than works of functionality and works of content, and they are licensed suitably for their intended purposes. For example, RFCs, generally considered the most "Free" standardization documents, do not permit modification by anyone and translation only with permission. It would be completely useless to write a modified version of RFC822, license it to permit further modification, produce a MTA which uses your changes, and claim compliance. Even the original authors do not modify RFCs; instead they write new RFCs which reference and obsolete the earlier ones.
Clearly the terms under which a work, even a "Free" work, is licensed must take into account the way the user is to interact with the work. Software is different from the content of games, and therefore can meaningfully be licensed differently.
On the other hand, I think that there are areas in which content shades into functionality. For example, a browser will probably come with a set of icons designed for utility (which doesn't preclude art, but which does have a metric of success for the user). For a game, perhaps, it should be permitted to replace the text of menu items with different text while keeping the background the same, since the functionality of the game may be impaired by the menus being in the wrong language or misleading.
In fact, the GFDL is not what I consider a Free license. But the fact remains that there are some things that don't matter for a work of content that matter for a work of functionality, and vice versa. So, while the GFDL is not a suitable license for properly Free works, the GPL doesn't really make sense for such things, either. Probably the best license for such things is Creative Commons Attribution-ShareAlike license, which is essentially the GPL for works of content.
Different portions of the package are intended for use in different ways. It doesn't make much sense to license a work based on content, rather than on functionality, under the (L)GPL; this is the point of the GFDL. The software freedoms don't really make sense for the documentation.
The GPL and LGPL differ essentially on whether the thing as a whole is intended to be used by itself or plugged into arbitrary other programs. The BSD license is preferrable for things where the code encourages free standards, so the author would benefit from, say, AutoCAD copying it verbatim into their products (which would then be able to exchange files, perhaps).
It's more like having different insurance policies for your car and for your house. Some things are similar, but you're not worried about people stealing your house or the pipes in your car freezing. The differences in the intended use of the item lead to differences in what the owner wants.
Is Windows XP even intended to be secure against a legitimate user of the system who hasn't been granted Administrator access? (I actually don't know; I haven't encountered a system set up for this, but I haven't used a system where it would make sense for the intended function)
(Conversely, I have seen only a few Linux machines set up to have remote users who can run arbitrary code as themselves but who don't have root access, but all of the Linux machines I've seen are designed to be secure against such users. It does mean that an attacker who compromises an unpriviledged service can't cause quite so much damage so easily, but most of these machines don't have unpriviledged services which actually belong, either. The real benefit is that an attacker who tricks a user into executing some code is less likely to be able to compromise the system such that it can't be safely cleaned up with legitimate root access.)
Slashdot Mirror
This came up on the lkml recently. Cheap multi-Opteron systems are often set up to have a single bank of memory rather than two, and are actually uniform. More expensive ones have the two banks, although you can generally make them uniform with a BIOS setting (which is occasionally the default).
It makes a lot of sense to have a standard parser which will give an AST for a language (or a class of languages, if given a DTD-equivalent for the language). On the other hand, producing XML for it just means you have to reparse the XML. A better idea is to have something which acts like an XML parser except that it takes in a programming language instead of actual XML.
I keep expecting this to show up in Java. I mean, there's a Java parser that javac uses, and it is used separately by javadoc, and even exports some of the content for use in javadoc extensions, but you still can't call it to just parse a file for you. It's much harder in C because the preprocessor and the parser don't use the same tokens, meaning that the parser's view of the code may have little in common with the programmer's view (while the preprocessor's view, which matches the programmer's view, isn't very useful).
"Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title." (USC 35 101)
Chemicals are essentially mentioned explicitly in the law as an invention patentable. Of course, a new DNA sequence isn't really a new composition of matter, although most things you can do with DNA involve the production of chemicals which might be new.
The article mentions SiteFinder, but before that VeriSign was sent fraudulent email to owners of domains registered through other registrars, and just this weekend they transferred panix.com (registered through a different registrar) to a hijacker. Considering the way the seem to have blown off both the rightful owner of the domain and law enforcement, I think it would be appropriate to take into account the possibility that VeriSign will be convicted of computer crimes and banned from computers by court order within the period of this contract when deciding whether to give it to them.
To make the point that this is still important, I've recently been using a web app that uses the name of the program as the title of every page, and it is therefore very difficult to return to a page you were at before.
I can't come up with any nice Windows apps. Sure, there are necessary Windows apps (for some people, at least), but I can't think of any that most users don't hate. "Nice" apps are for the Mac (as opposed to "powerful" ones for Linux, and "critical" ones for Windows).
No, although hopefully this will foster communication between the two projects. There are a number of things which could use an efficient in-kernel implementation, such as case-insensitive name lookup (it's generally agreed that case-insensitive filesystems are broken, but Samba needs to provide this nonetheless and Wine would like it as well). There was eventually a productive discussion, and Linus (IIRC) came up with a clever idea once it was clear that this was necessary (and once the desired behavior for the odd cases was specified).
Depends somewhat on whether those suits would have been avoided by caution. After getting hit with IP lawsuits that you couldn't have avoided, one is more likely to decide to ignore legal issues, particularly in the case of patents, where being cautious may triple your legal liability without reducing your risk substantially.
Last I heard, LSB was requiring a version of gcc's C++ ABI that the gcc people said was broken and was being replaced. Due the scheduling desires, LSB 2.0 (IIRC) was released with the broken one, because a stable version of gcc which supported the new one wasn't ready yet. Did this ever get cleared up, or is it still broken?
The problem with getting ISO involves now is that not everything is completely correct at this point. Of course, it's not like people generally exactly follow ISO standards, either, so it may be just as well.
The people who are uploading things as they download them plausibly qualify for common carrier status. There's no way you could accuse BayTSP of wrong-doing if they don't know what it is they're getting and sending. And they're only downloading it in the first place because they don't know what it is and are trying to determine this. That's why they're more interested in going after the torrents rather than the users; most users, once they have the files and could determine what they are stop uploading them.
Three ideas, in order of increasing significance and increasing difficulty:
Stop using bad DTDs. There seems to be a DTD style in which you avoid using attributes and instead add a whole lot of tags containing text. Any element with a content type of CDATA should be an attribute on its parent, which improves the readability of documents and lets you use ID/IDREF to automatically check stuff. Once you get rid of the complete cruft, it's not nearly so bad.
Now that everything other than HTML is generally valid XML, it's possible to get rid of a lot of the verbosity of XML, too. A new XML could make all close tags "</", since the name of the element you're closing is predetermined and there's nothing permitted after a slash other than a >. The > could be dropped from empty tags, too. If you know that your DTD will be available and not change during the life of the document, you could use numeric references in open tags to refer to the indexed child element type of the type of the element you're in, and numeric references for the indexed attribute of the element it's on. If you then drop the spaces after close quotes, you've basically removed all of the superfluous size of XML without using a binary format, as well as making string comparisons unnecessary in the parser.
Of course, you could document it as if it were binary. An open tag is indicated with an 0x3C, followed by the index of the element type plus 0x30 (for indices under 0xA). A close tag is (big-endian) 0x3C2F. A non-close tag is an open tag if it ends with an 0x3E and an empty tag if it ends with an 0x2F. Attribute indices are followed with an 0x3D. And so forth.
It's part of the HTTP 1.1 standard from 1997 ("Content-Encoding: gzip"), so it probably is.
I use the vanilla sources, except that I apply security patches individually to them. You don't actually have to wait for Linus to pick up a patch, apply it to his tree, and release the next version to get the patch. For that matter, security issues are generally in code which hasn't been touched for a long time, so the patches tend to apply to a lot of different versions (although you sometimes have to find that section of code and change it yourself if the line numbers have changed sufficiently drastically). If you can find the patch and positive commentary from somebody who would know if it's right, it doesn't matter if whoever maintains the tree you normally use is on vacation or something and hasn't applied it.
The second paragraph of this item from November is my favorite line from 2004.
Drat! The newspaper guy scooped me by an hour and a half!
3:14. Click Submit
I'd guess that having people distracting you at random moments will damage your ability to focus and add to the number of things you're always listening for, increasing your cognitive load. The effects of the transmission are unlikely to be significant compared to the effects of the interface.
Sure, you should expect that your conversation with the person at the other end will be heard by some total stranger (in addition to the total stranger you're talking with). But it's not entirely clear that sound from your end goes anywhere while you're on hold. People tend to assume that, since there are no operators available to take your call there aren't any other people around listening to you. So they turn on the speaker phone and go about their business while they wait. Really, phones ought to have a mode where you have the handset hung up, it plays out the speaker, and has no microphone (but you can press buttons for touch-tone sounds, or pick up the handset).
I always wondered what those businessmen were doing in the second secret level in Doom 2. Now it's all clear...
Again, that's no different from 2.4, with the exception that Marcelo is good at picking the ones that work to call 2.4.x, and Linus isn't nearly so good at picking 2.6.x that work.
With respect to needing to switch versions to a kernel that is different in unexpected ways, it's exactly the same if you're running a 2.4 kernel.
There are actually improvements with 2.6: the distros have been invited to take over 2.6.x.y series, so that if they're going to be backporting patches, they can contribute this effort back to the community. In 2.4, the distros carry so many patches that you'd have an easier time backporting from the latest 2.4 vanilla kernel than from a distro kernel with the same nominal version. They have so many patches because they feel the need to add functionality in their stable series.
Also, Alan Cox is maintaining a tree of "really stable" kernels, where he takes only bugfixes from the current work and adds them to the base version he's using. I haven't determined if he's planning to continue 2.6.9-ac indefinitely, or if he's going to only release 2.6.10-ac kernels once he judges 2.6.10-ac to be sufficiently tested.
The real issue is that Linus is currently in charge of releasing the stable versions. He's really good at identifying what should go into the stable series, from the perspective of guiding development, but he doesn't have the discipline to identify a completely-working version and call that 2.6.x. My prediction is that, in accordance with the ManagementStyle document, he will eventually decide that people complain about his release descisions, and therefore he should get somebody else (probably Alan Cox) to do that.
As for development causing security problems, there has yet to be a 2.6 security hole in code that was added during 2.6. In general, new code is checked for all known patterns of bugs (almost all security holes fall into some pattern) and bad practices before being accepted. On occasion, a bug is found which is part of a new pattern, and future code with the same sort of bug will be caught, but existing code with that bug is not necessarily identified. This means that bugs are generally in code that hasn't been changed in a long time, not code which has been changed recently. In fact, there have often been bugs found in old versions which had already been eliminated unknowingly from new versions by people writing replacement code using improved techniques.
For example, the recent hole was in code written ten years ago to facilitate the switch from a.out to ELF. The hole was a race condition due to changes made several years ago in the requirements of common code.
Code is primarily a work of functionality. Regardless of the fundamental beauty of the design, if it doesn't solve your problem, it is useless to you. Music, art, level designs, and so forth are works of content. They do not solve problems but more frequently pose problems for the user to solve, and offer entertainment through the challenge of working them out; or they simply contribute to the user's enjoyment of the experience.
You're also making the usual mistake of thinking that RMS ever has anything to say about the exchange of money. He talks almost exclusively about the granted ability to do things, not the cost of doing them. This is a common mistake because of the term "Free Software" for what is intended to be liberating (not liberated) software, which suggests no-cost as the only thing it could mean literally.
In any case, asking for the right to modify works of content is, in general, foolish. It doesn't make sense to say that, for instance, the Aeneid is unsuitable for you to read due to Aeneas founding Rome at the end and demanding the right to modify it such that he ends up defying fate and getting back together with Dido. Certainly you could write such a work if you wanted to, but you would no longer be simply a reader of the book you're reading and you wouldn't be reading the Aeneid (and, were you then to write a paper about your version as if it were the original, it would not be well received).
For that matter, there are other possibilities than works of functionality and works of content, and they are licensed suitably for their intended purposes. For example, RFCs, generally considered the most "Free" standardization documents, do not permit modification by anyone and translation only with permission. It would be completely useless to write a modified version of RFC822, license it to permit further modification, produce a MTA which uses your changes, and claim compliance. Even the original authors do not modify RFCs; instead they write new RFCs which reference and obsolete the earlier ones.
Clearly the terms under which a work, even a "Free" work, is licensed must take into account the way the user is to interact with the work. Software is different from the content of games, and therefore can meaningfully be licensed differently.
On the other hand, I think that there are areas in which content shades into functionality. For example, a browser will probably come with a set of icons designed for utility (which doesn't preclude art, but which does have a metric of success for the user). For a game, perhaps, it should be permitted to replace the text of menu items with different text while keeping the background the same, since the functionality of the game may be impaired by the menus being in the wrong language or misleading.
In fact, the GFDL is not what I consider a Free license. But the fact remains that there are some things that don't matter for a work of content that matter for a work of functionality, and vice versa. So, while the GFDL is not a suitable license for properly Free works, the GPL doesn't really make sense for such things, either. Probably the best license for such things is Creative Commons Attribution-ShareAlike license, which is essentially the GPL for works of content.
Different portions of the package are intended for use in different ways. It doesn't make much sense to license a work based on content, rather than on functionality, under the (L)GPL; this is the point of the GFDL. The software freedoms don't really make sense for the documentation.
The GPL and LGPL differ essentially on whether the thing as a whole is intended to be used by itself or plugged into arbitrary other programs. The BSD license is preferrable for things where the code encourages free standards, so the author would benefit from, say, AutoCAD copying it verbatim into their products (which would then be able to exchange files, perhaps).
It's more like having different insurance policies for your car and for your house. Some things are similar, but you're not worried about people stealing your house or the pipes in your car freezing. The differences in the intended use of the item lead to differences in what the owner wants.
Is Windows XP even intended to be secure against a legitimate user of the system who hasn't been granted Administrator access? (I actually don't know; I haven't encountered a system set up for this, but I haven't used a system where it would make sense for the intended function)
(Conversely, I have seen only a few Linux machines set up to have remote users who can run arbitrary code as themselves but who don't have root access, but all of the Linux machines I've seen are designed to be secure against such users. It does mean that an attacker who compromises an unpriviledged service can't cause quite so much damage so easily, but most of these machines don't have unpriviledged services which actually belong, either. The real benefit is that an attacker who tricks a user into executing some code is less likely to be able to compromise the system such that it can't be safely cleaned up with legitimate root access.)
Now: patch for 2.6.10. Latest 2.4 release candidate fixes it.