Consider that most of the critical pieces of software (things like GCC, GLIBC, Perl, SAMBA, Linux Kernel come to mind) involve Dipping Into The Same Source Code Stream. Thus, while distributions may pick different versions of these components, the differences are not persistent since the next releases will pick a later version from the same stream of development.
The main place where differences between Linux distributions are persistent are with regard to two things:
Installation tools
... In the case of "initialization" stuff, the custom tools built by Caldera versus RHAT versus SuSE versus... may be permanently different, but this is relatively uninteresting since you only run this stuff once.
System Management tools
This is arguably a matter for more concern.
Tools include rpm/dpkg, and the recent proliferation of distributions based on Debian is results in RPM no longer being quite as "worshipped" as it used to be.
I regard the increase in interest in Debian-based distributions as a good thing since Debian has more automated tools for managing and validating validity of packages, which is an area where RPM had "gotten pretty stuck" for a long time.
Aside from package management, there is then "system management," with tools like COAS and Linuxconf, where different distributions are promoting different tools. (And I'd put in a plug for the OS-independent tool cfengine that's good for lots of purposes...)
There's some fragmentation, but my old essay Linux and Decentralized Development has the thesis that the net results are positive. I haven't seen compelling evidence to the contrary yet.
It's fair enough to say that RHAT is caring $1 worth on this particular "product." Two cynical views leap out:
That's not very much caring
Although if there turn out to be $30 RMS Linux boxes on store shelves, this probably means that RHAT is contributing about 10% of their revenues, which suggests that the small percentage is more meaningful than the 3.3% figure would imply.
In other words, $1 may be all that it's safe to contribute on a $30 "product."
If RHAT expects to get some goodwill from the community for that $1, then a $1 contribution does not forcibly represent that they care about the FSF; it merely represents that they care to get some goodwill.
There's also some "flip side" considerations:
If you look at old copies of the GNU's Bulletin, you'll see that Red Hat used to have a similar policy on sales of the $29.95 "Red Hat Power Tools" package.
It strikes me as a good thing that after the "product line redesign" of the last six months, they have chosen to redeploy the "FSF contribution" in a way that makes it more obvious that it is such.
I don't have a big problem with them not giving the FSF a lot of money.
Money isn't the most valuable thing that one can contribute to free software; the most valuable thing is in fact free software.
And the RHAT sponsorship of GNOME development as well as XFree86 (via Precision Insight) thus represents substantial contributions of software.
It's not obvious that the FSF has a greater ability to effectively transform dollars into useful software.
I'm quite certain that RHAT spent considerably more money last year on developers producing free software than the (publicly available, if you ask them) amount the FSF spent on "program expenses" (that is the category where "transforming money into software" lies).
The long and short of this all is that:
If your goal is to contribute to the FSF, it is manifestly obvious that it will be vastly more efficient to send the FSF money directly.
There is ample room for some cynicism, although to view things solely through a cynical eye seems to be at least a bit unfair.
It's entertaining enough to see that they're promoting Yet Another Protocol that will, of course, mandate, on top of this, Yet Another API.
The purported reason for SOAP to be a "good thing" is that it's a way of layering a messaging model atop HTTP; of course, if this was truly their interest, honesty would require admission that it is possible to layer IIOP/GIOP atop HTTP, with ILU as the most obvious manifestation of an implementation of this.
The problem with SOAP is that it pushes you back towards defining messages, rather than protocol, as IDL provides.
My suspicion is that the real purpose is to get people to build messaging systems using XML. That is not, in and of itself, a bad thing; I'd much rather see people building asynchronous messaging systems where messages are represented in XML rather than in some less-well-known format. (And, plug, plug, use Isect as the transport mechanism...)
If you're wanting to build a reliable system using that "SOAPed" XML, Wouldn't it be better to transport that XML around using MSMQ with reliability guaranteed using a TP Monitor like MTS?
How much would you want to bet that reliability of the MSFT tools would be deliberately limited so as to encourage widespread use of MSMQ/MTS?
An appropriate multiplexing in the Model/View/Controller paradigm would be to take the selected material and validate against a regex to guess (the "model" part) if it is:
A URL
A mailto: URL
An email address
A pathname (ala the Common Lisp notion of pathname, namely a structured object that represents a filename)
A MIME object dropped onto the clipboard
Then, if there is ambiguity, make sure that whatever we "think" the object is happens to be accessible in that expected form.
Notably, if it's a file reference, validate against /etc/magic to determine whether the method we think we're going to apply to it is actually appropriate to what's in the file.
A "controller" part would be the provision of control to select the method by which the object is to be viewed. Which leads naturally to the "view" portion of the paradigm...
If you have sizable documents (such as PDFs) that multiple users will often be hitting, Squid will most definitely be of great assistance.
I would still tend to expect that 500MB would be enough for most purposes; even with some fairly large PDF's involved, that's quite a lot of space, and I would find it somewhat surprising for there to be an "active set" of commonly-hit stuff that would amount to more than that.
(Trying to stay at least a little on the main topic...) I'm not sure if Squid is installed by default on Cobalt Qubes; I kind of suspect not. I doubt it would be a problem to get it compiled and running...
I have heard reports that putting a Squid proxy in front of Apache can improve performance over just plain hitting Apache, as this allows Squid to provide more efficient (possibly in-RAM) access paths to web pages that remain static...
The first thing for you to look at, run, don't walk, is Squid.
Squid is a full-featured, free cacheing web proxy that is most certainly what you want to look at. It is available in RPM and DEB pre-packaged form.
You might also want to look into filtering web proxies that might be what users set up to "hit," to do things like filtering out cookies and/or annoying banner ads. (Not the Slashdot ones, of course!). The "standard" one to mention is Junkbuster but there are other possibly more sophisticated ones as listed at HTTP Links.
I'd hazard the guess that you'd be able to get most of the web cacheing benefits from a 386 box with 8MB of RAM and 500MB of disk; moving up to 14.4GB isn't likely to increase performance vastly over that...
Running Linux fits in as a reference intended to feed your curiosity moreso than to figure out how to administer the system.
It provides introductory information on a whole lot of different sorts of software, particularly including development tools and applications. It only provides a "taste" of each, but nonetheless does provide enough detail to accomplish something useful, as well as how to get at more detail if you care to make more serious use of the facility.
The purposes of the books are pretty complementary; Running Linux does not forcibly obsolete UNIX in a Nutshell or Essential System Administration;
Running Linux is particularly useful for assessing answers to the question:
Unfortunately, these little machines are just a little too little to run Linux on and have a useful toolset.
In order to support having bloated things like Perl or Python, you need to have probably 20-30MB of storage available, and more realistically somewhat more in order to supply space for both system memory as well as some filesystem space.
This probably dictates waiting a year for WinCE to bloat further so that LinCE can have adequate hardware to run on.
It they want to be respected, they will have to contribute something in that is worthy of respect.
The most critical thing that can be contributed is working code. There are an assortment of other things that could be useful.
And if they don't contribute anything, then they will have to continue to remain "underrespected."
It's entirely likely that they will remain thus, which transforms their complaints into whining. Actions result in reactions; if their actions don't merit respect, then they won't get respect.
I have a feeling that actually getting a $2000 Sun Ultra 5 system may be as challenging as getting a $400 "PC."
I started pricing an Ultra 5 system on their "online buying" system, and as soon as I added the base-model CPU to the base system, this brought the price from $2550 to about $3700.
And this didn't actually include a monitor...
I would be vastly more interested to hear that someone was offering inexpensive ( e.g. - priced under $500) motherboards.
Net Express offers SPARC mobos for as "little" as $1510.
Cycle CC and Opus SPARCard represent possible alternatives, but when they don't publicize pricing, that usually suggests that you don't want to know...
You note that O'Reilly's book, Running Linux, was what was a ``godsend'' to you. That's a book from a decidedly technical publisher.
I don't have a whole lot of trust in the Thick Tomes that publishers like Sybex, Que, SAMS, and, yes, Macmillan, put onto shelves. They tend to be rushed to market, made as thick and garish as possible, with the result that quality suffers.
Your criticisms of "What's Hard About Linux" represent things likely to be solved by organizations contributing to the development of tools like Linuxconf or COAS.
Macmillan isn't contributing to those sorts of developments, which means that they're effectively not part of the solution. This doesn't necessarily make them "bad people," but it does mean that they are not in much of a position to claim that they are helping substantively.
Unfortunately, Macmillan is suffering from two or three "negative factors." Consider:
They are a major vendor of Get A Thick Book Onto Shelves As Fast As Possible books.
Unfortunately, while that strategy does get books onto bookstore shelves quickly, quality suffers just a tad...
What useful software have they contributed to the community?
They may be giving some funding to the Mandrake/Linux folks, but they haven't sponsored the development of X servers like Red Hat or SuSE, and it appears that they generally don't actually produce any free software themselves.
Have they contributed funds or other resources to organizations like the FSF, The XFree86 Project, Software In The Public Interest, or other such?
Unfortunately for their "level of respect," the "quality of product" matter results in some "negative respect points," and there isn't any other source of "positive points" that they are using to earn back respect.
None of these things are the "fault" of anyone other than the management of Macmillan, as they represent their policy decisions of what to do and what not to do. It appears that their priorities are largely economic; to get "respect" they would have to modify those priorities as well as their actual behaviour.
I don't feel sorry for them in this; they have made their bed, and will have to sleep in it...
I'd guesstimate that the cost of CDE is on the (binary) order of $150/seat; this could readily vary between $80 and $200 based on how the terms are interpreted.
On 10 million Linux users, the mass adoption of CDE would result in a Linux distribution having $0 in licensing fees for Linux, and something around $150 for CDE/Motif licensing fees.
Much griping took place over the relatively low licensing fees The Open Group tried to apply to X11R6.4.
Tremendous flaming has taken place over the licensing of Qt, where deployment is royalty-free, but developer licenses could cost as much as about $1500.
I can't imagine the flame wars that would come out of trying to cope with the per-user package licensing fees that are associated with CDE.
If KDE and GNOME are "divisive," CDE is not "inclusive." It is, instead, exclusive.
The GUI architectures are, indeed, quite different in what they do. That suggests that having the same GUI code is not terribly realistic.
There are, however, ample other opportunities for other aspects of interoperability that generally have merit.
Data formats
Many UNIX applications have traditionally used data formats as a mechanism for interoperability. Many applications know how to read things like mail and news spools, which provides interoperability.
GNOME and KDE both make fairly extensive use of XML, which may, with some cooperation on DTDs, provide opportunities to interoperate in a cooperative manner.
Protocols
One of the traditional strengths of UNIX has been the use of common sorts of protocols. The IETF has been involved in defining common protocols for things like news and mail that allow diverse mail and news servers/clients to interoperate. And just look at how many web server implementations there are out there...
GNOME and KDE both include CORBA implementations that represent a well-defined, intentionally-interoperable way of defining protocols for client/server applications.
The use of this approach requires splitting applications into "client/front end" portions, which may be GUI-specific, and "server side" portions, which should be designed to be altogether independent of the GUI.
In effect, people should be doing design efforts to build useful "services" that are entirely GUI-independent; that will provide code that will be usable with both GNOME and KDE.
If they were really trying to have an Internet-oriented name, they probably should have called this an eChip or eCPU to go along with eCommerce, eBusiness, and other such "stuff."
The fact that it sounds somewhat like some obscure sort of "rare earth" metal is likely good for Intel; they can have some e1eete k001 commercials involving glowing metallic substances, not unlike one of Nokia's latest that shows off a chrome-bright cell phone rather than those boring old black ones. Itanium can provide us the burning chrome approach...
This also provides a natural progression towards jokes involving the Hacker's Dictionary definition for "Chrome" which caused great hilarity when Microsoft announced Microsoft Chrome which not only conformed to the "useless but pretty" definition of Chrome, but actually used the same word to describe it. In effect, Itanium is Really Fancy Chrome!
It's a nice bonus that the name leaves it to minor modifications of a scatalogical nature so as to allow Further Jokes. If the chip is rectangular, the next PPC commercial will doubtless show off a burned-up shrivelled-up, brown Itanium chip, leaving any comparisons to other materials to be filled in by the viewer...
If true, this would be a larger problem than you are implying, because it undercuts the whole notion of using crypto-based authentication and privacy within the banking system.
The Internet is only the latest place where cryptographic systems are being used to implement security; DES has been used for years to secure ATMs, and the present availability of DES-cracking schemes establishes that that is undercut by available technologies.
If "quantum computing" were to undercut Internet-based crypto schemes, it would undercut all of the presently constituted cryptographic distributed banking protocols, which would be Quite A Bad Thing, irrespective of your rejoicing or lack thereof...
Firstly, it doesn't address just what is supposed to be "broken" in 12 microseconds. I'm not sure that one would be able to decrypt a message of meaningful size with the private key in that period of time.
Secondly, there's a real mixture of "apparent reality" and "future fiction."
It doesn't make sense for both of the following to be true:
"It claims it has developed a hand-held device that can break the code in 12 microseconds."
"While quantum computers may be some time off..."
The one claim suggest that there is an actual implementation; the other suggests that implementation is still off in the future.
Thirdly, it does not appear to address the consideration that a huge amount of the security of these systems come not simply in the "cool algorithms" being used, but from the careful use of protocols. Recognizing actual information within a message requires analysis of the protocol, and that's something that cryptanalysis does not, in and of itself, address.
RSA-512 may not be of vast strength; the article still does not strike me as believable.
(Aside: I was in a bookstore yesterday and saw Yet Another Book on Codes. Bible Codes, as it happens, but there has been, of late, an increase in the number of books on Real Crypto on bookstore shelves. I can generally evaluate the quality of the book by a 5 second riffle through the pages; if I don't notice large numbers of mathematical equations, I consider that the book is ludicrously worthless. In the case of Bible Codes, large numbers of equations would indicate Probably Serious But Still Worthless... )
You're quite right that there's relatively little merit to further souping-up the CPU to the point of having something that will "melt itself through the motherboard;" that's only of merit if the CPU was the bottleneck.
That actually also implies that SMP is also of relatively little merit for the same situations, as SMP is also a solution to the CPU Bottleneck problem.
What has more merit is the notion of trying to let system components be increasingly independent of the CPU. Things like:
A fast UART with a big buffer, maybe 256 bytes
(Some may think I jest... Check out the buffering specs on a 16450 versus 16550...)
IDE/SCSI with decently large tagged command buffers, to allow disk I/O to be suitably asyncrhonous.
Battery-backed RAM, preferably with a SIMM/DIMM slot that allows the user to add arbitrary quantities.
This would be useful in providing a way to make journalled filesystems (of which two have recently made beta releases for Linux, namely ext2 and Reiserfs) both faster and more reliable, as they could have the metadata journals written out initially to this "relatively reliable cache" rather than having it vulnerable in ordinary RAM.
1MB of battery-backed RAM would be enough for Stephen Tweedy's ext3 implementation; doubtless other uses could be imagined for larger quantities...
It is an attractive enough consideration that video cards have been turning into subsystems of their own considerable power.
The increasing availability of video cards with 32MB and more of RAM implies that there's some work being pushed off to the video card.
Extra coprocessors on the video card can't be too horrible an idea, and is consistent with things like Monster 3D boards that provide coprocessors to the "main" video card...
On the other hand, there's one notable fallacy here, which is that there is merit to moving to a system working with 128 bit memory space sizes. This is silly from at least three perspectives:
This is why the only systems that presently support more than 4GB of RAM on Linux are UltraSPARCs,
There is apparently a way to support a 64 bit data bus through a longer connector slot, but that does not make for a 128 bit extension.
It has only been recently that the 2GB addressing limitations of 32 bit systems have become restrictive sufficiently easily as to make it necessary to look at 64 bits. And 64 bits allows you to reference Rather A Lot Of Memory Space.
Based on the rates of growth in the past, it seems reasonable to expect that 64 bit addressing will be adequate for all but highly unusual applications for the next ten to fifteen years.
And even then, it is reasonably likely that by that time, technology may have progressed back to using some of the memory segmentation technologies of the '60s ala MULTICS to obviate the need for linear growth of adddress space.
2^63 is approximately 4 billion billion, which is a very large value. A move to 128 bits squares that again, which provides an even more atrociously large space.
Increasing bus sizes generally doesn't increase performance.
By moving to 128 bit addressing, the complexity of the memory addressing circuitry increases, as do the minimum amounts of memory that are likely to get addressed for instructions. This means that programs get bigger even if they do no more than they would on a 32 bit architecture.
Oracle is exceedingly Open To Your Buying Product From Them.
Oracle salescritters are also extremely open to the idea of you adopting functionality that will forcibly tie you to buying future software from them.
It unfortunately is quite tempting to "buy in" to using software that ties you to spending a whole lot more money on Oracle software. And this is why Larry Ellison is a billionaire...
For info on OLAP, I've written up link/definition information elsewhere in the thread.
As for "PHB," that is the acronym that Scott Adams, famed for the comic strip Dilbert coined to describe the Pointy Haired Boss. Usually used to describe someone who is completely devoid of practical knowledge but who is "in charge."
It's always useful to present some definitions when using a TLA or other acronym that everyone is not expected to be familiar with...
OLAP usually stands for On Line Analytical Processing. (Footnote: the OLAP Council website claims to intend to provide common definitions, but do not actually provide a definition for OLAP...)
On-Line Analytical Processing (OLAP) is a category of software technology that enables analysts, managers and executives to gain insight into data through fast, consistent, interactive access to a wide variety of possible views of information that has been transformed from raw data to reflect the real dimensionality of the enterprise as understood by the user.
OLAP is pretty strongly associated with the common buzzword, "Data Warehousing."
More precisely, what it is about is the notion of taking the data created by an online transaction processing system, and collecting this into a big database that you then want to do "analysis" on.
The point here is that the analysts that are looking for patterns need to have a separate copy, as the things they do may hit a DB server hard, and are probably not friendly to the transaction-oriented operations of "Entering Invoices," "Processing Sales," "Paying Bills," and such.
SAS is pretty big on OLAP, as they have been building powerful statistical software for many years now.
Apple has popularized the notion of "computers as Art/Industrial Design," where the computer is designed to look attractive, as opposed to being more purely functional.
It may represent a movement towards "computer as appliance," although the complexity of running a computer still largely prevents it being truly treated as such.
I've said it before; all sorts of vendors have come up with nifty new CPUs over the years, but without a source of economical motherboards, people can't build systems.
The slowness of release of Athlon-based systems appears to be related to, surprise, surprise, a dearth of availability of motherboards. I wouldn't want to be accusative of Intel for formenting this, but I'm sure they're very grateful at the inability of AMD to sell massive quantities of Athlon chips...
Every time a new CPU comes out, the real insight comes from looking to the motherboards...
If they want to be considered credible, I'd think they'd want to at least have a footnote somewhere indicating where someone that is interested in it might find additional technical information such as:
Just who their developers are
What the general software base is
( e.g. - "Based on Red Hat Linux, with our additional tools," "Based on Debian, Plus Our Stuff,"...)
What kernel they're running
And whatever other information would be important to allow other people to know how to expect to support it.
It may not matter to the Naive New User That Is Trying It Out, but it sure would be useful for me to know such details if that Naive New User happens to come to me for help.
This may not be in their interests if they planned to provide paid support contracts, but that's not consistent with the ``Best Effort Support'' that the site indicates that they intend to offer...
Slashdot Mirror
The main place where differences between Linux distributions are persistent are with regard to two things:
This is arguably a matter for more concern.
Tools include rpm/dpkg, and the recent proliferation of distributions based on Debian is results in RPM no longer being quite as "worshipped" as it used to be.
I regard the increase in interest in Debian-based distributions as a good thing since Debian has more automated tools for managing and validating validity of packages, which is an area where RPM had "gotten pretty stuck" for a long time.
Aside from package management, there is then "system management," with tools like COAS and Linuxconf, where different distributions are promoting different tools. (And I'd put in a plug for the OS-independent tool cfengine that's good for lots of purposes...)
There's some fragmentation, but my old essay Linux and Decentralized Development has the thesis that the net results are positive. I haven't seen compelling evidence to the contrary yet.
- That's not very much caring
- If RHAT expects to get some goodwill from the community for that $1, then a $1 contribution does not forcibly represent that they care about the FSF; it merely represents that they care to get some goodwill.
There's also some "flip side" considerations:Although if there turn out to be $30 RMS Linux boxes on store shelves, this probably means that RHAT is contributing about 10% of their revenues, which suggests that the small percentage is more meaningful than the 3.3% figure would imply.
In other words, $1 may be all that it's safe to contribute on a $30 "product."
It strikes me as a good thing that after the "product line redesign" of the last six months, they have chosen to redeploy the "FSF contribution" in a way that makes it more obvious that it is such.
Money isn't the most valuable thing that one can contribute to free software; the most valuable thing is in fact free software.
And the RHAT sponsorship of GNOME development as well as XFree86 (via Precision Insight) thus represents substantial contributions of software.
I'm quite certain that RHAT spent considerably more money last year on developers producing free software than the (publicly available, if you ask them) amount the FSF spent on "program expenses" (that is the category where "transforming money into software" lies).
The long and short of this all is that:
The purported reason for SOAP to be a "good thing" is that it's a way of layering a messaging model atop HTTP; of course, if this was truly their interest, honesty would require admission that it is possible to layer IIOP/GIOP atop HTTP, with ILU as the most obvious manifestation of an implementation of this.
The problem with SOAP is that it pushes you back towards defining messages, rather than protocol, as IDL provides.
My suspicion is that the real purpose is to get people to build messaging systems using XML. That is not, in and of itself, a bad thing; I'd much rather see people building asynchronous messaging systems where messages are represented in XML rather than in some less-well-known format. (And, plug, plug, use Isect as the transport mechanism...)
If you're wanting to build a reliable system using that "SOAPed" XML, Wouldn't it be better to transport that XML around using MSMQ with reliability guaranteed using a TP Monitor like MTS?
How much would you want to bet that reliability of the MSFT tools would be deliberately limited so as to encourage widespread use of MSMQ/MTS?
- A URL
- A mailto: URL
- An email address
- A pathname (ala the Common Lisp notion of pathname, namely a structured object that represents a filename)
- A MIME object dropped onto the clipboard
Then, if there is ambiguity, make sure that whatever we "think" the object is happens to be accessible in that expected form.Notably, if it's a file reference, validate against /etc/magic to determine whether the method we think we're going to apply to it is actually appropriate to what's in the file.
A "controller" part would be the provision of control to select the method by which the object is to be viewed. Which leads naturally to the "view" portion of the paradigm...
I would still tend to expect that 500MB would be enough for most purposes; even with some fairly large PDF's involved, that's quite a lot of space, and I would find it somewhat surprising for there to be an "active set" of commonly-hit stuff that would amount to more than that.
(Trying to stay at least a little on the main topic...) I'm not sure if Squid is installed by default on Cobalt Qubes; I kind of suspect not. I doubt it would be a problem to get it compiled and running...
I have heard reports that putting a Squid proxy in front of Apache can improve performance over just plain hitting Apache, as this allows Squid to provide more efficient (possibly in-RAM) access paths to web pages that remain static...
Squid is a full-featured, free cacheing web proxy that is most certainly what you want to look at. It is available in RPM and DEB pre-packaged form.
You might also want to look into filtering web proxies that might be what users set up to "hit," to do things like filtering out cookies and/or annoying banner ads. (Not the Slashdot ones, of course!). The "standard" one to mention is Junkbuster but there are other possibly more sophisticated ones as listed at HTTP Links.
I'd hazard the guess that you'd be able to get most of the web cacheing benefits from a 386 box with 8MB of RAM and 500MB of disk; moving up to 14.4GB isn't likely to increase performance vastly over that...
It provides introductory information on a whole lot of different sorts of software, particularly including development tools and applications. It only provides a "taste" of each, but nonetheless does provide enough detail to accomplish something useful, as well as how to get at more detail if you care to make more serious use of the facility.
The purposes of the books are pretty complementary; Running Linux does not forcibly obsolete UNIX in a Nutshell or Essential System Administration;
Running Linux is particularly useful for assessing answers to the question:
In order to support having bloated things like Perl or Python, you need to have probably 20-30MB of storage available, and more realistically somewhat more in order to supply space for both system memory as well as some filesystem space.
This probably dictates waiting a year for WinCE to bloat further so that LinCE can have adequate hardware to run on.
Smileys all around, of course...
The most critical thing that can be contributed is working code. There are an assortment of other things that could be useful.
And if they don't contribute anything, then they will have to continue to remain "underrespected."
It's entirely likely that they will remain thus, which transforms their complaints into whining. Actions result in reactions; if their actions don't merit respect, then they won't get respect.
I started pricing an Ultra 5 system on their "online buying" system, and as soon as I added the base-model CPU to the base system, this brought the price from $2550 to about $3700.
And this didn't actually include a monitor...
I would be vastly more interested to hear that someone was offering inexpensive ( e.g. - priced under $500) motherboards.
Net Express offers SPARC mobos for as "little" as $1510.
Cycle CC and Opus SPARCard represent possible alternatives, but when they don't publicize pricing, that usually suggests that you don't want to know...
I don't have a whole lot of trust in the Thick Tomes that publishers like Sybex, Que, SAMS, and, yes, Macmillan, put onto shelves. They tend to be rushed to market, made as thick and garish as possible, with the result that quality suffers.
Your criticisms of "What's Hard About Linux" represent things likely to be solved by organizations contributing to the development of tools like Linuxconf or COAS.
Macmillan isn't contributing to those sorts of developments, which means that they're effectively not part of the solution. This doesn't necessarily make them "bad people," but it does mean that they are not in much of a position to claim that they are helping substantively.
Unfortunately, while that strategy does get books onto bookstore shelves quickly, quality suffers just a tad...
They may be giving some funding to the Mandrake/Linux folks, but they haven't sponsored the development of X servers like Red Hat or SuSE, and it appears that they generally don't actually produce any free software themselves.
Unfortunately for their "level of respect," the "quality of product" matter results in some "negative respect points," and there isn't any other source of "positive points" that they are using to earn back respect.
None of these things are the "fault" of anyone other than the management of Macmillan, as they represent their policy decisions of what to do and what not to do. It appears that their priorities are largely economic; to get "respect" they would have to modify those priorities as well as their actual behaviour.
I don't feel sorry for them in this; they have made their bed, and will have to sleep in it...
Look at CDE Price List and Motif Price List.
I'd guesstimate that the cost of CDE is on the (binary) order of $150/seat; this could readily vary between $80 and $200 based on how the terms are interpreted.
On 10 million Linux users, the mass adoption of CDE would result in a Linux distribution having $0 in licensing fees for Linux, and something around $150 for CDE/Motif licensing fees.
I can't imagine the flame wars that would come out of trying to cope with the per-user package licensing fees that are associated with CDE.
If KDE and GNOME are "divisive," CDE is not "inclusive." It is, instead, exclusive.
There are, however, ample other opportunities for other aspects of interoperability that generally have merit.
Many UNIX applications have traditionally used data formats as a mechanism for interoperability. Many applications know how to read things like mail and news spools, which provides interoperability.
GNOME and KDE both make fairly extensive use of XML, which may, with some cooperation on DTDs, provide opportunities to interoperate in a cooperative manner.
One of the traditional strengths of UNIX has been the use of common sorts of protocols. The IETF has been involved in defining common protocols for things like news and mail that allow diverse mail and news servers/clients to interoperate. And just look at how many web server implementations there are out there...
GNOME and KDE both include CORBA implementations that represent a well-defined, intentionally-interoperable way of defining protocols for client/server applications.
The use of this approach requires splitting applications into "client/front end" portions, which may be GUI-specific, and "server side" portions, which should be designed to be altogether independent of the GUI.
In effect, people should be doing design efforts to build useful "services" that are entirely GUI-independent; that will provide code that will be usable with both GNOME and KDE.
The fact that it sounds somewhat like some obscure sort of "rare earth" metal is likely good for Intel; they can have some e1eete k001 commercials involving glowing metallic substances, not unlike one of Nokia's latest that shows off a chrome-bright cell phone rather than those boring old black ones. Itanium can provide us the burning chrome approach...
This also provides a natural progression towards jokes involving the Hacker's Dictionary definition for "Chrome" which caused great hilarity when Microsoft announced Microsoft Chrome which not only conformed to the "useless but pretty" definition of Chrome, but actually used the same word to describe it. In effect, Itanium is Really Fancy Chrome!
It's a nice bonus that the name leaves it to minor modifications of a scatalogical nature so as to allow Further Jokes. If the chip is rectangular, the next PPC commercial will doubtless show off a burned-up shrivelled-up, brown Itanium chip, leaving any comparisons to other materials to be filled in by the viewer...
The Internet is only the latest place where cryptographic systems are being used to implement security; DES has been used for years to secure ATMs, and the present availability of DES-cracking schemes establishes that that is undercut by available technologies.
If "quantum computing" were to undercut Internet-based crypto schemes, it would undercut all of the presently constituted cryptographic distributed banking protocols, which would be Quite A Bad Thing, irrespective of your rejoicing or lack thereof...
Firstly, it doesn't address just what is supposed to be "broken" in 12 microseconds. I'm not sure that one would be able to decrypt a message of meaningful size with the private key in that period of time.
Secondly, there's a real mixture of "apparent reality" and "future fiction."
It doesn't make sense for both of the following to be true:
The one claim suggest that there is an actual implementation; the other suggests that implementation is still off in the future.
Thirdly, it does not appear to address the consideration that a huge amount of the security of these systems come not simply in the "cool algorithms" being used, but from the careful use of protocols. Recognizing actual information within a message requires analysis of the protocol, and that's something that cryptanalysis does not, in and of itself, address.
RSA-512 may not be of vast strength; the article still does not strike me as believable.
(Aside: I was in a bookstore yesterday and saw Yet Another Book on Codes. Bible Codes, as it happens, but there has been, of late, an increase in the number of books on Real Crypto on bookstore shelves. I can generally evaluate the quality of the book by a 5 second riffle through the pages; if I don't notice large numbers of mathematical equations, I consider that the book is ludicrously worthless. In the case of Bible Codes, large numbers of equations would indicate Probably Serious But Still Worthless... )
That actually also implies that SMP is also of relatively little merit for the same situations, as SMP is also a solution to the CPU Bottleneck problem.
What has more merit is the notion of trying to let system components be increasingly independent of the CPU. Things like:
(Some may think I jest... Check out the buffering specs on a 16450 versus 16550...)
This would be useful in providing a way to make journalled filesystems (of which two have recently made beta releases for Linux, namely ext2 and Reiserfs) both faster and more reliable, as they could have the metadata journals written out initially to this "relatively reliable cache" rather than having it vulnerable in ordinary RAM.
1MB of battery-backed RAM would be enough for Stephen Tweedy's ext3 implementation; doubtless other uses could be imagined for larger quantities...
The increasing availability of video cards with 32MB and more of RAM implies that there's some work being pushed off to the video card.
Extra coprocessors on the video card can't be too horrible an idea, and is consistent with things like Monster 3D boards that provide coprocessors to the "main" video card...
On the other hand, there's one notable fallacy here, which is that there is merit to moving to a system working with 128 bit memory space sizes. This is silly from at least three perspectives:
This is why the only systems that presently support more than 4GB of RAM on Linux are UltraSPARCs,
There is apparently a way to support a 64 bit data bus through a longer connector slot, but that does not make for a 128 bit extension.
Based on the rates of growth in the past, it seems reasonable to expect that 64 bit addressing will be adequate for all but highly unusual applications for the next ten to fifteen years.
And even then, it is reasonably likely that by that time, technology may have progressed back to using some of the memory segmentation technologies of the '60s ala MULTICS to obviate the need for linear growth of adddress space.
2^63 is approximately 4 billion billion, which is a very large value. A move to 128 bits squares that again, which provides an even more atrociously large space.
By moving to 128 bit addressing, the complexity of the memory addressing circuitry increases, as do the minimum amounts of memory that are likely to get addressed for instructions. This means that programs get bigger even if they do no more than they would on a 32 bit architecture.
Oracle salescritters are also extremely open to the idea of you adopting functionality that will forcibly tie you to buying future software from them.
It unfortunately is quite tempting to "buy in" to using software that ties you to spending a whole lot more money on Oracle software. And this is why Larry Ellison is a billionaire...
As for "PHB," that is the acronym that Scott Adams, famed for the comic strip Dilbert coined to describe the Pointy Haired Boss. Usually used to describe someone who is completely devoid of practical knowledge but who is "in charge."
OLAP usually stands for On Line Analytical Processing. (Footnote: the OLAP Council website claims to intend to provide common definitions, but do not actually provide a definition for OLAP...)
Datamation describes it thus:
OLAP is pretty strongly associated with the common buzzword, "Data Warehousing."
More precisely, what it is about is the notion of taking the data created by an online transaction processing system, and collecting this into a big database that you then want to do "analysis" on.
The point here is that the analysts that are looking for patterns need to have a separate copy, as the things they do may hit a DB server hard, and are probably not friendly to the transaction-oriented operations of "Entering Invoices," "Processing Sales," "Paying Bills," and such.
SAS is pretty big on OLAP, as they have been building powerful statistical software for many years now.
Apple has popularized the notion of "computers as Art/Industrial Design," where the computer is designed to look attractive, as opposed to being more purely functional.
It may represent a movement towards "computer as appliance," although the complexity of running a computer still largely prevents it being truly treated as such.
The slowness of release of Athlon-based systems appears to be related to, surprise, surprise, a dearth of availability of motherboards. I wouldn't want to be accusative of Intel for formenting this, but I'm sure they're very grateful at the inability of AMD to sell massive quantities of Athlon chips...
Every time a new CPU comes out, the real insight comes from looking to the motherboards...
I can just imagine guidance counsellors noticing that Little Johnny is taking interest in something that is, um, apparently related to weapons...
( e.g. - "Based on Red Hat Linux, with our additional tools," "Based on Debian, Plus Our Stuff," ...)
And whatever other information would be important to allow other people to know how to expect to support it.
It may not matter to the Naive New User That Is Trying It Out, but it sure would be useful for me to know such details if that Naive New User happens to come to me for help.
This may not be in their interests if they planned to provide paid support contracts, but that's not consistent with the ``Best Effort Support'' that the site indicates that they intend to offer...