The problem with Sather is that it could be mistaken for being a dead language, and isn't something that many people are well-familiar with.
That's not the only problem; the other critical issue is that of Foreign Function Interface. Perl presently offers the opportunity to connect in libraries with C interface plumbing, which requires that the implementation language be fairly deeply compatible with C.
That being said, if there was a good compiled Scheme or Lisp with a bunch of back ends (arguably, the way to do this would be a Scheme front end for GCC), this would in fact represent a fast option. It is a longstanding fallacy that "Lisps are Interpreted." That may have been true 20 years ago, and was particularly true with David Betz's XLisp, but isn't a truthful statement.
The stability of C++ has been perpetually around the corner for some time now. It has assortedly suffered from:
There not being a normative standard.
That became untrue a year or so ago, when the ANSI C++ committee released the "final" standard.
There not being a good free compiler.
G++ only fairly recently has started to be both "reliable," "correct," and "nearly completely conformant to standard."
The gyrations between GCC and EGCS, which has recently become GCC, did not help.
Interoperability of LIBC++ versions has not been real good.
The claim is that there shouldn't need to be Yet Another Noninteroperable Version of the GCC libc++ library; I'm inclined to wait six months and see...
What this adds up to is that C++ on Linux has had some fairly severe handicaps. Several are no longer in effect; we'll see if this allows C++ to "get up and walk."
(My personal suspicion is that there may continue to be some LIBC++ gyrations for a while...)
I tend to agree on the "burial" notion, although there might be some use to having Softway's software to help build BackOffice facilities that can interoperate with UNIX so as to lure people to install NT/BackOffice in UNIX environments... (Feel free to change names of products as needed to express Where Microsoft Wants You To Think They're Going This Week... )
It doesn't make that much sense to consider this to be a "64-bit-related" deal; the issues of making NT (or W2K) code "64-bit-clean" are likely to have more to do with having considerable bits of test harness to validate that they work with big values than anything else, what with the major architectural differences.
As for competition immunity, we can go back to the days of the Roman Empire and see the ebb and flow of the growth and destruction of empires that people thought would stand. The more arrogant they get, the bigger the fall when they do fall.
I think that the "in practice" that turned out badly has been the price wars between Intel, AMD, and Cyrix.
Two years ago, there was room for some serious profits on CPUs as they were the most expensive component in a computer system.
That has changed such that the most expensive component is commonly the hard disk, followed (with MSFT software) the OS, with CPU in third or fourth place.
With that change, this leaves Transmeta without the viable "IA-32 market" they may have expected to have.
Based on the droppage in pricing, it is not clear that there is room to get vast decreases in pricing.
Of course, considering that Transmeta is fabless, and doesn't directly have a sales organization for CPUs, the goal might have been to construct technology to allow building cheaper IA-32 chips, and then license it to AMD or Intel or Cyrix.
I'm not sure any of them are necessarily interested to the tune of $Billions...
I suspect that the task of bundling it up will take a couple of days, more if it's a challenge to get through to the web site...
This doesn't sound like it's a "MPL" release, which is really too bad...
I'm sure with you on the "sure would be nice to have a CHANGELOG " thing. I'll be happy to wait a few days and see if the release is truly an improvement, or if it has any critical bugs that flaw the release.
My take on this was that there would be part of a CPU devoted to this "multi-tasking." After all, in order for the communications to take place really quickly, it all needs to be on one chip.
You do, however, show an interesting notion; if the patented matters reveal a "protocol" for allowing this emulation, it may make it plausible to have multiple "little processors" doing work, and getting to change Real Memory when it makes sense to commit the work.
It would certainly be neat if this were amenable to putting a bunch of "little processors" working together. The communications takes place at a much lower level than Beowulf; it may even be at a lower level than is done with SMP.
The latest patent surely looks related to the other patents previously awarded...
The basic idea for all of the patents has been to provide mechanisms to allow one to:
Create a new CPU that uses one instruction set;
That CPU is emulating the instruction set of some other CPU ( Oh, Say, Perhaps IA-32... );
The patent provides for some scheme whereby instructions are run in some sort of "emulation mode," where they try to execute in a sort of abeyance...
The system then seeks to detect situations where the emulation starts going astray, and provides mechanisms for "coping with this error."
The various patents have involved that mechanism for coping with the errors, with an attempt to construct ways of quickly working around them.
This parallels the notion of Lagrangian Relaxation, where you take a problem, with various restrictions, and relax those restrictions. In exploring the solution space, the system will find solutions that aren't in the feasible solution space of the (unrelaxed) problem.
In the case of Lagrangian Relaxation, the way of coping with that is to associate values with the objective function that penalize infeasible solutions, thus encouraging the system to head towards feasible solutions.
In the case of Patent 5958061, the "relaxation" is that the system performs the emulated instructions, modifying a temporary memory store, and rolling back when it hits cases where the preliminary emulation results in errors on the host processor.
Patent 5832205 concentrated, in contrast, on the apparatus to detect a failure of speculation.
As was mentioned in the article by the developers, it's not Nvidia that decides how fast to ``clock'' the chips, it is the OEM's that build the boards.
More importantly, a fixation on clock speed is quite silly, as it is merely one of the factors in how fast a system is. I'm rather more impressed if they produce a faster product that doesn't have as fast a clockspeed.
Furthermore, keeping the clock speed down has other merits such as that it likely reduces the need for cooling, as well as diminishing the likelihood of the chips being stressed into generating EMI.
(Entertaining rumor has it that 900MHz systems that are likely coming in the next year may interfere with the 900MHz band used by recent digital cordless phones...)
There was a review a month or so ago in Computer Shopper for the Kryotech model that is "merely" equipped with a souped-up K6-III.
I agree with you that it seems to be a "cool idea" looking for some sort of clue in order to actually be valuable.
It's doing IDE I/O, which means it's not going to be a "barn-burner" from an I/O perspective; all that it really has is a CPU that will doubtless be outmatched by whatever comes out a year from now, with the serious cost of having to pay for a really serious cooling system.
The market sector I'd see it being "hot" in would be that of computer graphics. That is a sector where the priority is forcibly on CPU power.
I think I'd want to use a high end graphics card ($300+) and 256MB of RAM to let the machine really shine.
I didn't see the previous model (K6-III) as being terribly viable; the Athlon feels "less overpriced," but still somewhat pricey for relatively little value.
The merit may come next year when faster Athlon CPUs can get their speed doubled, thereby providing some more massive performance enhancements. Speeding up one CPU may be of little value, but doubling the speed of an SMP box to provide a couple "Gigahertz" worth of power may well be worth $1K for the cooling system...
The only way that this feature gets to communicate with the bad guy on the other side is if the software is written to do so.
Details on precisely what instructions are involved would presumably be necessary; if one is running Linux, then actually using the instructions requires that someone convinces you to install software compiled with the "Evil Privacy-Killing Instructions."
This will fall high on the list of Things Ulrich Drepper Won't Add to GLIBC; it is equally likely to represent Instructions Unlikely To Be Added To the GCC Code Generator.
Note that this furthermore represents Instructions That Aren't on PPC which would encourage the purchase of PPC-based systems or Alpha-based systems...
(He spelled "moot" right! Obviously not clueless...)
Yes, indeed, it would be a monumental effort to get everything in /etc rewritten to use a set of XML-based data files.
The big deal is not merely that of getting something working, but also to ensure that a robust system results. As you say, "what if... it is corrupted or incorrect?" The XML standard provides no guidance here, and there are liable to be three answers, not one, which will muddy the waters further.
Yes, there is great merit to making sure that there is indeed a text form, and, preferably, having it be the official form.
If there is a lot of data, as might be the case for things like mail routing tables, there is also merit to having a random access mechanism so that the data doesn't have to either be stored in memory or parsed repeatedly.
This is one of the merits of the CDB system; it provides a "binary" form that is rabidly fast but which also can be rewritten from scratch with exceeding rapidity.
Approach that supports both needs:
When the program that uses the file starts, it "compiles" the text form into binary form.
When the user signals via SIGHUP, the program "recompiles."
If the program detects, via date stamps, that the files are out-of-sync (ala "make"), it "recompiles."
The two merit to CDB in this regard are that:
CDB is really, really, really fast.
I once "compiled" a file into hashed form, and got about a million keys inserted in 17s on my PPro box.
CDB does not permit rewriting the DB, as it uses perfect hashing.
There is no temptation to change the binary form, as you can't modify what has already been written out to it.
This means that the text form stays as the true data source.
Noticing that the system needs to "recompile" is the one "problem issue" here; it is not exacerbated by this approach as it would be equally true for a purely text-oriented scheme.
In terms of validation, the killer questions are two:
When, precisely, do you require well-formedness?
What do you do if the data is not well-formed?
If this isn't defined, one of the valid options is for us to attach an electrode to your chair and electrocute you:-).
Why not
write some integration code to (say) connect Linuxconf to XML so that it could manipulate any XML file?
That is an interesting idea; two problems:
XML is just a data format.
The tools presently available are generally parsers, and have nothing to do with the grotty work of file locking and error detection/correction.
libPropList is a format that exists now, and is already used for configuring programs like WindowMaker.
As such, it would represent a useful inclusion into Linuxconf.
At some future time, when there is actually some useful configuration information managed in an XML repository, and when there is a scheme not only to read, but also to reliably write, XML, it would then prove to be a useful inclusion.
Until there is something of comparable functionality to libPropList for both read and reliable write, I'll remain skeptical of the usefulness of XML for storage of configuration information.
The merit of using XML would be that there are a whole host of XML parsers out there, as well as a whole lot of hype.
However. It is not all fine and dandy.
The "configuration problem" has not one issue, but several:
The proliferation of "little languages" as formats.
XML represents Yet Another Format; it is of value if it pushes out some of the existing formats. If it merely augments the population with another, there is no win here.
Result: Ambiguous. XML might provide value.
The Serialization/Locking Problem.
The issue here is that you need to ensure that the configuration is written out correctly.
This may require writing out the new config to a new file, validating that it is readable and correct. (Oops, made a mistake updating /etc/inet.d. Now the system won't reboot...)
There is merit to having a "database form" ala IronDoc where the physical representation is a database system, which provides a somewhat different persistence model than the typical text file.
(Before people start proposing that I be shot, I tend to favor the notion of, if using a binary format, synchronizing it carefully with a text format.)
The merit of a "databased" scheme, which should provide a separate database for each facility, is that updates can be implemented "instantly" without needing to rewrite a whole file, and without a need to parse the file. Note that even in a situation where XML is used as an interchange format, there is still merit to storing the "tree" in database form. David McCusker, author of IronDoc and architect of the (regrettably failed) "Bento" database system that was part of OpenDoc, suggests this very use for IronDoc.
For those that feel religious about using text files, a system like libPropList still has merit over the "let's do something with XML" idea since it has, already debugged, the locking, parsing, and config-file-rewriting code that let's use XML, it's k001 doesn't inherently provide.
In short, deciding to use XML merely establishes a format; it does not resolve that:
Updates are managed well
The output from a particular program that manipulates a config file actually produces valid XML
Federating Configuration.
Michael Stonebraker (of fame with such developments as Ingres and Postgres) has most recently founded a company called Cohera based on the Mariposa Distributed Database Management System. This tool allows many databases to work together to process queries.
The "obvious" implication of this with this thread is that a valuable thing to be able to do is to join together many "databases" that are configuration repositories, and provide a central way of getting at the data.
The critical thing that is necessary is for configuration repositories to provide some sort of "metadata" so that they, in effect, publicize their existence.
A "federation" tool like Linuxconf, Ganymede, or such, can then be used to join together the metadata and manage it all together.
Unlike the situation with the infamous Windows Registry, this doesn't force all the configuration data into one fragile binary DB; it allows the data to stay wherever it was concluded that it should reside.
The critical factor here is not that data files all have a common format; it is that there be some way of translating their data into a common format.
XML has a lot to offer here in terms of providing a central "presentation" format. It could offer more if tools were available to make this a two-way street, where updates done to the central XML could be pushed back to the individual configuration data repositories.
However. If someone writes some integration code to (say) connect Linuxconf to libPropList so that it could directly manipulate libPropList files, that would also represent a movement in the right direction.
Conclusion: XML may have value to offer in confederating config information.
That has to come along with a whole lot of coding effort to build robust configuration data repositories that may or may not use XML.
There was a technology transfer that has recently become productized in the form of the EV7 "bus protocol" that DEC created for Alpha, and which Athlon now brings to IA-32.
It is entirely possible that the "talk" could have been a corrupted understanding of this transfer.
I'm sure AMD is happy enough to see some extra business come their way that isn't solely predicated on head-to-head battle with Intel.
It would be rather neat if this resulted in there being a third-party source for PPC motherboards, as that is a Critical Resource.
It looks like the AMD involvement hasn't led to cheap Alpha motherboards, which means that it's not time to replace my Multia/UDB yet; probably the same for you, too...
Those that hold copyright (or copyleft!) are the ones that have the moral right and the moral obligation to defend (such as it needs defense) the code that they wrote.
I would add considerably to your wager; I'm quite sure that most of the flamebait comes from people capable only of writing flamebait.
After all, if they had the reasoning abilities to write code that would work, they'd probably write better flamebait...
The article doesn't contain the official Linus Torvalds Core Hacker List.
I suggest you reread the article.
The only quote in that article that claims to involve Linus' words says:
There's a fairly ad hoc round table of people I trust. - Linus Torvalds
The authors of the article indicate (but do not quote him directly) that
Torvalds insists any attempt to list his core confidants will be incomplete and will likely offend someone.
What this says is that Linus listed nobody as ``core confidants.''
Not Alan Cox, not Stephen Tweedy, not Donald Becker, not Ted T'so, not anybody.
Apparently Scott Berinato decided that since Linus declined to provide a list, and despite the fact that Linus indicated that such a list would be likely to be offend people (as well as to confuse anyone that doesn't read carefully to realize that this isn't Linus' list ), he decided to make up his own list.
The three people you named (plus some unnamed developer in Hungary) is the Scott Berinato's List of People He Guesses Might Be Amongst Linus Torvalds' Confidants.
It is not the Official List of Linus' Kernel Confidants.
It's not me that looks silly when you draw conclusions based on some guesses made by some writer at Ziff Davis...
I would tend to discount the article you cite somewhat as it has a natural bias as it is written specifically from a perspective of looking at Red Hat. They mention three Red Hat contractors and "someone from Hungary," decidedly an incomplete list.
The VA Ubergeeks are responsible more for "userland" stuff, although:
Zubkoff is responsible for quite a number of SCSI drivers that are in the kernel.
Ted T'so is responsible for lots of all around stuff including taking over ext2 from Remy, architecture of Kerberos, /dev/random, amongst other kernel stuff.
H.J. Lu was responsible for libc5, and is heavily involved with GLIBC, NFS, and Bintools. That's not largely in the kernel, but the kernel is pretty useless without a way for "userland" to get at it...
The main big kernel thing that it appears VA has been working on lately is IA-64 support; that won't be visible until Intel releases product.
The real point I'd make is that you are merely questioning one point that I'd made, and really just quibbling over "who's got more kernel hackers," which is merely quibbling over the strength of one of four points.
It is an entertaining enough thought that the company is just around to "create hype," IPO to ``big bucks,'' and then have the principals walk away.
This would doubtless do a good job of popping the ``Internet Bubble,'' and could result in an overall market bloodbatch as people re-examined the non-existent value of other enterprises that have seen bloated valuations due to peoples' miscomprehension of the use of "e-Business."
It would, however, be rather less fun for the principal participants, as it would be a downright fraud to issue an IPO to a thus-worthless company and then walk away with a bundle of dollars.
The above interpretation of matters also would not survive the scrutiny required by an IPO. See RHAT 424B1 Filing and S1.
I'm still biased towards the material I wrote way back when on Transmeta; it seems nearer accurate than anything publicized before or since...
This enterprise sounds very much like an attempt to cash in on the RHAT excitement; if RHAT turned some "wunderkids" into paper billionaires, then surely LinuxOne can do the same, right?
The thing is, nobody had ever heard of LinuxOne before, and unlike RHAT, the company lacks:
Known Developers
Known Redistributors
Channels that know to sell product for them
Any other forcible reasons for anyone in the Linux community at large to consider them faintly worthy of trust.
It wouldn't be a bad thing if they succeeded at selling a few shares to the abjectly clueless; the resultant publicity would have the effect of injecting a degree of sanity hopefully without injuring any of the more credible enterprises out there.
This is in the same vein as the notion that Linus actually means that he is seeking World Domination.
Probably stronger than the way the "ROTC Dude" at the end of the movie Animal House declared ``All is well! All is well!''; it's more in that vein than most others.
Of course, what puts some truth to the matter is that Bruce Perens is actually the author of some software included in "Corel Linux," and thereby a person potentially being infringed against. Copyright infringment is not, legally, an "offense" against "communities," it is against the holders of copyright...
The really important point is that taxation of capital gains is deferred until the security is actually sold.
That means that you don't pay any tax (generally speaking) until you sell the stock. And a dollar of tax deferred represents some portion of a dollar of tax that is avoided.
The rate of taxation on the gain doesn't matter nearly as much as the fact that it is deferred.
It might sound like a neat idea to force stock to be revalued annually, thereby crystallizing gains (and losses) for them to be taxed.
On the (by some theories) upside, that would, by now, have forced Bill Gates to both pay a whopping big tax bill of on the order of many $BILLions of dollars as well as to sell off the vast majority of his holdings of MSFT (in order to pay the Tax Bill).
The "Bill Gates" scenario display ways in which it is not so good; it effectively represents the government grabbing, as if it were income, parts of any sort of "increase in value" of an enterprise.
Another disadvantage is that "continuous revaluation" requires having a department that are constantly attaching values to things. There are lots of opportunities for horrid Unanticipated Consequences.
Slashdot Mirror
My point was not to detail the "splintering" but to indicate that it took place, and represents cause for the lack of stability of C++ on Linux.
I certainly agree that the now-much-better implementation results from the EGCS efforts.
That's not the only problem; the other critical issue is that of Foreign Function Interface. Perl presently offers the opportunity to connect in libraries with C interface plumbing, which requires that the implementation language be fairly deeply compatible with C.
That being said, if there was a good compiled Scheme or Lisp with a bunch of back ends (arguably, the way to do this would be a Scheme front end for GCC), this would in fact represent a fast option. It is a longstanding fallacy that "Lisps are Interpreted." That may have been true 20 years ago, and was particularly true with David Betz's XLisp, but isn't a truthful statement.
- There not being a normative standard.
- There not being a good free compiler.
- Interoperability of LIBC++ versions has not been real good.
What this adds up to is that C++ on Linux has had some fairly severe handicaps. Several are no longer in effect; we'll see if this allows C++ to "get up and walk."That became untrue a year or so ago, when the ANSI C++ committee released the "final" standard.
G++ only fairly recently has started to be both "reliable," "correct," and "nearly completely conformant to standard."
The gyrations between GCC and EGCS, which has recently become GCC, did not help.
The claim is that there shouldn't need to be Yet Another Noninteroperable Version of the GCC libc++ library; I'm inclined to wait six months and see...
(My personal suspicion is that there may continue to be some LIBC++ gyrations for a while...)
It doesn't make that much sense to consider this to be a "64-bit-related" deal; the issues of making NT (or W2K) code "64-bit-clean" are likely to have more to do with having considerable bits of test harness to validate that they work with big values than anything else, what with the major architectural differences.
As for competition immunity, we can go back to the days of the Roman Empire and see the ebb and flow of the growth and destruction of empires that people thought would stand. The more arrogant they get, the bigger the fall when they do fall.
Two years ago, there was room for some serious profits on CPUs as they were the most expensive component in a computer system.
That has changed such that the most expensive component is commonly the hard disk, followed (with MSFT software) the OS, with CPU in third or fourth place.
With that change, this leaves Transmeta without the viable "IA-32 market" they may have expected to have.
Based on the droppage in pricing, it is not clear that there is room to get vast decreases in pricing.
Of course, considering that Transmeta is fabless, and doesn't directly have a sales organization for CPUs, the goal might have been to construct technology to allow building cheaper IA-32 chips, and then license it to AMD or Intel or Cyrix.
I'm not sure any of them are necessarily interested to the tune of $Billions...
This doesn't sound like it's a "MPL" release, which is really too bad...
I'm sure with you on the "sure would be nice to have a CHANGELOG " thing. I'll be happy to wait a few days and see if the release is truly an improvement, or if it has any critical bugs that flaw the release.
You do, however, show an interesting notion; if the patented matters reveal a "protocol" for allowing this emulation, it may make it plausible to have multiple "little processors" doing work, and getting to change Real Memory when it makes sense to commit the work.
It would certainly be neat if this were amenable to putting a bunch of "little processors" working together. The communications takes place at a much lower level than Beowulf; it may even be at a lower level than is done with SMP.
The basic idea for all of the patents has been to provide mechanisms to allow one to:
- Create a new CPU that uses one instruction set;
- That CPU is emulating the instruction set of some other CPU ( Oh, Say, Perhaps IA-32... );
- The patent provides for some scheme whereby instructions are run in some sort of "emulation mode," where they try to execute in a sort of abeyance...
- The system then seeks to detect situations where the emulation starts going astray, and provides mechanisms for "coping with this error."
The various patents have involved that mechanism for coping with the errors, with an attempt to construct ways of quickly working around them.This parallels the notion of Lagrangian Relaxation, where you take a problem, with various restrictions, and relax those restrictions. In exploring the solution space, the system will find solutions that aren't in the feasible solution space of the (unrelaxed) problem.
In the case of Lagrangian Relaxation, the way of coping with that is to associate values with the objective function that penalize infeasible solutions, thus encouraging the system to head towards feasible solutions.
In the case of Patent 5958061, the "relaxation" is that the system performs the emulated instructions, modifying a temporary memory store, and rolling back when it hits cases where the preliminary emulation results in errors on the host processor.
Patent 5832205 concentrated, in contrast, on the apparatus to detect a failure of speculation.
More importantly, a fixation on clock speed is quite silly, as it is merely one of the factors in how fast a system is. I'm rather more impressed if they produce a faster product that doesn't have as fast a clockspeed.
Furthermore, keeping the clock speed down has other merits such as that it likely reduces the need for cooling, as well as diminishing the likelihood of the chips being stressed into generating EMI.
(Entertaining rumor has it that 900MHz systems that are likely coming in the next year may interfere with the 900MHz band used by recent digital cordless phones...)
I agree with you that it seems to be a "cool idea" looking for some sort of clue in order to actually be valuable.
It's doing IDE I/O, which means it's not going to be a "barn-burner" from an I/O perspective; all that it really has is a CPU that will doubtless be outmatched by whatever comes out a year from now, with the serious cost of having to pay for a really serious cooling system.
The market sector I'd see it being "hot" in would be that of computer graphics. That is a sector where the priority is forcibly on CPU power.
I think I'd want to use a high end graphics card ($300+) and 256MB of RAM to let the machine really shine.
I didn't see the previous model (K6-III) as being terribly viable; the Athlon feels "less overpriced," but still somewhat pricey for relatively little value.
The merit may come next year when faster Athlon CPUs can get their speed doubled, thereby providing some more massive performance enhancements. Speeding up one CPU may be of little value, but doubling the speed of an SMP box to provide a couple "Gigahertz" worth of power may well be worth $1K for the cooling system...
The ``abundance of paper'' phenomenon may be successfully "analyzed" via the economic perspectives of supply, demand, cost, and value.
Consider:
This means that the cost of wasting some paper is low.
The net result is that it's cheap to generate piles of paper, and computers have made it easier and increasingly efficient to do so.
Details on precisely what instructions are involved would presumably be necessary; if one is running Linux, then actually using the instructions requires that someone convinces you to install software compiled with the "Evil Privacy-Killing Instructions."
This will fall high on the list of Things Ulrich Drepper Won't Add to GLIBC; it is equally likely to represent Instructions Unlikely To Be Added To the GCC Code Generator.
Note that this furthermore represents Instructions That Aren't on PPC which would encourage the purchase of PPC-based systems or Alpha-based systems...
Yes, indeed, it would be a monumental effort to get everything in /etc rewritten to use a set of XML-based data files.
The big deal is not merely that of getting something working, but also to ensure that a robust system results. As you say, "what if ... it is corrupted or incorrect?" The XML standard provides no guidance here, and there are liable to be three answers, not one, which will muddy the waters further.
If there is a lot of data, as might be the case for things like mail routing tables, there is also merit to having a random access mechanism so that the data doesn't have to either be stored in memory or parsed repeatedly.
This is one of the merits of the CDB system; it provides a "binary" form that is rabidly fast but which also can be rewritten from scratch with exceeding rapidity.
Approach that supports both needs:
The two merit to CDB in this regard are that:
I once "compiled" a file into hashed form, and got about a million keys inserted in 17s on my PPro box.
There is no temptation to change the binary form, as you can't modify what has already been written out to it.
This means that the text form stays as the true data source.
Noticing that the system needs to "recompile" is the one "problem issue" here; it is not exacerbated by this approach as it would be equally true for a purely text-oriented scheme.
Are there some that do reliable write, e.g. with file locking, backups, and automated backout if it encounters errors?
If this isn't defined, one of the valid options is for us to attach an electrode to your chair and electrocute you :-).
Why not
That is an interesting idea; two problems:
The tools presently available are generally parsers, and have nothing to do with the grotty work of file locking and error detection/correction.
As such, it would represent a useful inclusion into Linuxconf.
At some future time, when there is actually some useful configuration information managed in an XML repository, and when there is a scheme not only to read, but also to reliably write, XML, it would then prove to be a useful inclusion.
Until there is something of comparable functionality to libPropList for both read and reliable write, I'll remain skeptical of the usefulness of XML for storage of configuration information.
However. It is not all fine and dandy.
The "configuration problem" has not one issue, but several:
XML represents Yet Another Format; it is of value if it pushes out some of the existing formats. If it merely augments the population with another, there is no win here.
Result: Ambiguous. XML might provide value.
The issue here is that you need to ensure that the configuration is written out correctly.
This may require writing out the new config to a new file, validating that it is readable and correct. (Oops, made a mistake updating /etc/inet.d. Now the system won't reboot...)
There is merit to having a "database form" ala IronDoc where the physical representation is a database system, which provides a somewhat different persistence model than the typical text file.
(Before people start proposing that I be shot, I tend to favor the notion of, if using a binary format, synchronizing it carefully with a text format.)
The merit of a "databased" scheme, which should provide a separate database for each facility, is that updates can be implemented "instantly" without needing to rewrite a whole file, and without a need to parse the file. Note that even in a situation where XML is used as an interchange format, there is still merit to storing the "tree" in database form. David McCusker, author of IronDoc and architect of the (regrettably failed) "Bento" database system that was part of OpenDoc, suggests this very use for IronDoc.
For those that feel religious about using text files, a system like libPropList still has merit over the "let's do something with XML" idea since it has, already debugged, the locking, parsing, and config-file-rewriting code that let's use XML, it's k001 doesn't inherently provide.
In short, deciding to use XML merely establishes a format; it does not resolve that:
Michael Stonebraker (of fame with such developments as Ingres and Postgres) has most recently founded a company called Cohera based on the Mariposa Distributed Database Management System. This tool allows many databases to work together to process queries.
The "obvious" implication of this with this thread is that a valuable thing to be able to do is to join together many "databases" that are configuration repositories, and provide a central way of getting at the data.
The critical thing that is necessary is for configuration repositories to provide some sort of "metadata" so that they, in effect, publicize their existence.
A "federation" tool like Linuxconf, Ganymede, or such, can then be used to join together the metadata and manage it all together.
Unlike the situation with the infamous Windows Registry, this doesn't force all the configuration data into one fragile binary DB; it allows the data to stay wherever it was concluded that it should reside.
The critical factor here is not that data files all have a common format; it is that there be some way of translating their data into a common format.
XML has a lot to offer here in terms of providing a central "presentation" format. It could offer more if tools were available to make this a two-way street, where updates done to the central XML could be pushed back to the individual configuration data repositories.
However. If someone writes some integration code to (say) connect Linuxconf to libPropList so that it could directly manipulate libPropList files, that would also represent a movement in the right direction.
Conclusion: XML may have value to offer in confederating config information.
That has to come along with a whole lot of coding effort to build robust configuration data repositories that may or may not use XML.
It is entirely possible that the "talk" could have been a corrupted understanding of this transfer.
I'm sure AMD is happy enough to see some extra business come their way that isn't solely predicated on head-to-head battle with Intel.
It would be rather neat if this resulted in there being a third-party source for PPC motherboards, as that is a Critical Resource.
It looks like the AMD involvement hasn't led to cheap Alpha motherboards, which means that it's not time to replace my Multia/UDB yet; probably the same for you, too...
I would add considerably to your wager; I'm quite sure that most of the flamebait comes from people capable only of writing flamebait.
After all, if they had the reasoning abilities to write code that would work, they'd probably write better flamebait...
I suggest you reread the article.
The only quote in that article that claims to involve Linus' words says:
The authors of the article indicate (but do not quote him directly) that
What this says is that Linus listed nobody as ``core confidants.''
Not Alan Cox, not Stephen Tweedy, not Donald Becker, not Ted T'so, not anybody.
Apparently Scott Berinato decided that since Linus declined to provide a list, and despite the fact that Linus indicated that such a list would be likely to be offend people (as well as to confuse anyone that doesn't read carefully to realize that this isn't Linus' list ), he decided to make up his own list.
The three people you named (plus some unnamed developer in Hungary) is the Scott Berinato's List of People He Guesses Might Be Amongst Linus Torvalds' Confidants.
It is not the Official List of Linus' Kernel Confidants.
It's not me that looks silly when you draw conclusions based on some guesses made by some writer at Ziff Davis...
I would tend to discount the article you cite somewhat as it has a natural bias as it is written specifically from a perspective of looking at Red Hat. They mention three Red Hat contractors and "someone from Hungary," decidedly an incomplete list.
The VA Ubergeeks are responsible more for "userland" stuff, although:
Zubkoff is responsible for quite a number of SCSI drivers that are in the kernel.
Ted T'so is responsible for lots of all around stuff including taking over ext2 from Remy, architecture of Kerberos, /dev/random, amongst other kernel stuff.
H.J. Lu was responsible for libc5, and is heavily involved with GLIBC, NFS, and Bintools. That's not largely in the kernel, but the kernel is pretty useless without a way for "userland" to get at it...
The main big kernel thing that it appears VA has been working on lately is IA-64 support; that won't be visible until Intel releases product.
The real point I'd make is that you are merely questioning one point that I'd made, and really just quibbling over "who's got more kernel hackers," which is merely quibbling over the strength of one of four points.
This would doubtless do a good job of popping the ``Internet Bubble,'' and could result in an overall market bloodbatch as people re-examined the non-existent value of other enterprises that have seen bloated valuations due to peoples' miscomprehension of the use of "e-Business."
It would, however, be rather less fun for the principal participants, as it would be a downright fraud to issue an IPO to a thus-worthless company and then walk away with a bundle of dollars.
The above interpretation of matters also would not survive the scrutiny required by an IPO. See RHAT 424B1 Filing and S1.
I'm still biased towards the material I wrote way back when on Transmeta; it seems nearer accurate than anything publicized before or since...
This enterprise sounds very much like an attempt to cash in on the RHAT excitement; if RHAT turned some "wunderkids" into paper billionaires, then surely LinuxOne can do the same, right?
The thing is, nobody had ever heard of LinuxOne before, and unlike RHAT, the company lacks:
It wouldn't be a bad thing if they succeeded at selling a few shares to the abjectly clueless; the resultant publicity would have the effect of injecting a degree of sanity hopefully without injuring any of the more credible enterprises out there.
Probably stronger than the way the "ROTC Dude" at the end of the movie Animal House declared ``All is well! All is well!''; it's more in that vein than most others.
Of course, what puts some truth to the matter is that Bruce Perens is actually the author of some software included in "Corel Linux," and thereby a person potentially being infringed against. Copyright infringment is not, legally, an "offense" against "communities," it is against the holders of copyright...
That means that you don't pay any tax (generally speaking) until you sell the stock. And a dollar of tax deferred represents some portion of a dollar of tax that is avoided.
The rate of taxation on the gain doesn't matter nearly as much as the fact that it is deferred.
It might sound like a neat idea to force stock to be revalued annually, thereby crystallizing gains (and losses) for them to be taxed.
On the (by some theories) upside, that would, by now, have forced Bill Gates to both pay a whopping big tax bill of on the order of many $BILLions of dollars as well as to sell off the vast majority of his holdings of MSFT (in order to pay the Tax Bill).
The "Bill Gates" scenario display ways in which it is not so good; it effectively represents the government grabbing, as if it were income, parts of any sort of "increase in value" of an enterprise.
Another disadvantage is that "continuous revaluation" requires having a department that are constantly attaching values to things. There are lots of opportunities for horrid Unanticipated Consequences.