Indeed, it would be precisely as silly as the idea of merging apt-get with dpkg.
What would be useful would be to build a version of apt-get that could use RPM as the packaging tool instead of dpkg. Which is something people are working on...
I'm afraid that what you're looking for isn't likely to be readily supported by any of these schemes any time soon.
The first problem you describe essentially requires that you have an RPM or dpkg database that is prepopulated with all the information from all packages out there in "packageland."
It might be a reasonable thing to try to extract such information from some place like RPMFind.net ; but the essence of the matter is that you need to have all the packages available for query, which is not likely to be the case on your PC at home if you're using APT to get at packages remotely.
As for the second problem, of "recursiveness," there's both a touch of inherent danger, and an answer with APT.
The danger part is that a recursive install probably isn't what you want. Two packages might depend on one another, and this would naturally lead to a loop where neither dependancy could be satisfied.
The flip side is that apt does do pretty much the "right thing." It recursively looks up the dependancies in order to generate a full list of packages to install, and then essentially tries to install in parallel.
The parallel aspect of this resolves most of the problems you suggest.
In effect, the problem is that RPM could use a "helper" rather like APT in order to cleanly satisfy dependancies for a clean install of software.
It's not that RPM is "broken;" it's that it really needs that "soul mate/life partner.":-)
Contrary to what others may have suggested, "apt" maintains no such database associating files with packages.
apt's purpose is quite directed, namely to track the associations of inter-package dependancies.
It leaves the task of tracking specific files to a completely separate piece of software called dpkg. Or, if you use the "beta" version of apt-get, the database of files installed would be maintained by RPM.
So, supposing you want to know what files are associated with the Netscape package titled netscape-communicator, you might use the commands:
dpkg -L netscape-communicator
or
rpm -ql netscape-communicator
depending on what packaging tool you prefer to use. Note that neither of those commands involve apt in any way, shape, or form.
If your feelings are so brittle that what I wrote felt like an attack, then you probably should run, not walk away from trying to get code integrated into the "official" kernel, as the normal course of discussions involves vastly stronger wording than I ever use...
That's probably a good thought; this is pretty much where Bitkeeper came from, as seen if you visit Why Bitkeeper?
The
current Linux development model has some problems and Linus needs tools to help solve those
problems. Without a decent distributed source management system, all of the merging and tracking
work falls on Linus' shoulders and that is getting to be way too much for any one person, even
someone like Linus. The goal of the Bitkeeper effort is to provide tools that help the Linux kernel
effort, and more specifically, help Linus.
Unfortunately, it has sat in "ready Real Soon Now" status for a long time now. I'd hazard the guess that a bunch of developers are feeling rebellious about the fact that it is not free software.
By the way, the "let's set up a CVS repository" idea has the conspicuous demerit at "send the patch to Linus time" that it is still going to take a lot of effort to make sure that the patches that get sent on to Linus are reasonably perspicuous. You're still left with the dilemma that:
If you send him each and every patch, that represents a huge number of patches to evaluate, and if they're tiny and keep changing all the time as developers experiment things, it is certainly not a perspicuous set of changes.
If you send him patches periodically, they'll bulk up, hopefully meaning that some of the little changes that go back and forth as people experiment before resolving to Regis' "Final Answer" will fold together.
But this will tend to "bulk up" into something that involves a horde of changes, which again will not be terribly perspicuous.
If you wait longer between times that updates get released to Linus, the deltas will get bigger and bigger, and become just too big and unperspicuous to get applied to the "official" kernel.
This is certainly spelled "dilemma," as all the alternatives are pretty poor...
Specifically, support for vCard aka iCard servers and vCalendar aka iCalendar.
This already provides a set of protocols and data formats standardized under the auspices of the IETF . There's an XML encoding under way as well as an OMG committee working on CORBA IDL.
There are already applications that know how to use these protocols/formats, including the GNOME and KDE calendar programs.
Build a "calendar server" that knows how to store appointments for a horde of users, and a "vCard" server that can accept address info for hordes of users, and use the existing standards to try to build in further sorts of useful interactions.
This would make the existing tools vastly more useful. It doesn't fundamentally matter whether this involves XML, CORBA, MySQL, or LDAP; those are all implementation details that can probably vary a whole lot without breaking the fundamental idea, which is to build standards-compliant servers.
That was the whole point to defining these calendaring and scheduling and address standards, namely to provide a standard way of doing the sorts of things that Microsoft built proprietary interfaces into Outlook for.
If the PPC people are offering Linus huge patches that change lots of non-PPC-specific code and interact scarily with the little patches coming in from other groups, then what's he to do?
He can choose to:
Take the PPC patches as gospel, and throw away everyone else's contributions,
Go through a whole lot of work breaking the PPC patches down into bite-sized components, or
Tell the PPC developers to turn the PPC patches into bite-sized components themselves, and ignore the huge patches that he hasn't time to integrate in.
In effect, he's going with "option 3" here, and that's not an outrageous outcome. The LinuxPPC folk may not like this outcome, but it's neither new, capricious, nor is it discriminatory. Alpha has suffered from much the same issue...
If Christopher Browne and
hneilson@accessweb.com desire to
be seen as having a shred of intellectual integrity they will
access my web-pages, read "The Question" therein found, and
proclaim that they now understand that they MUST answer such
question with a "NO!". Will we then be left to wonder if their
"NO!" is a meaningful "NO!" or the lengthy and meaningless
bleetings of fearful and acquiescent sheep / toads / whatever? -- D. Lavigne
It's missing the time the "tax protestor" wrote an extremely off-colour poem the guy wrote about me.
One of these days, I should put together a "bot" from which I'd grab a bunch of postings by these sorts of folk, build a sort of "parse tree," and then run a random number generator through it to generate pseudo-postings by them... 'Twould be entirely entertaining...
Serious SSD's may be "bowel-quiveringly expensive;" they just aren't something that you're likely to want to install on a small desktop box.
There are applications out there where $60K is a small price to pay to increase performance rather a lot, and $60K starts looking small when you start pricing Sun E10000 servers and such.
The big value to SSD comes in when you've got one of those situations of heavy database updates where eliminating latency time is a big win. If throwing on a $60K SSD allows downgrading from a $1.5M server to a $1.1M server, that was evidently a very good buy...
A CF memory card system that doesn't allow you to hit it hard with vast numbers of updates just doesn't compare. And it's still hardly cheap; there aren't $60K units, but there aren't 8GB CF memory cards, either...
Yes, rm -rf * is a bad security penetration. And someone who dies of starvation due to a bad worm is every bit as dead as someone who succumbs to Lassa fever.
The worm is still not so pervasive as a virus that resides in virtually every cell of the body.
Worms aren't as bad as viruses, whether in the "Animal Kingdom" or in the (actually remarkably good) analogies of the "Computer Kingdom."
Remember that a virus is much tinier, more pervasive, and more invasive than a worm.
We see such viruses as Ebola and Lassa that are tremendously fatal. The same is not so true for the worms that likely only live in the GI tract.
Once invaded by a virus, there is very little that can be done, whether in biological or computer systems; it can potentially get anywhere in the system, and readily be impractical to stamp out. There is no cure to Ebola, for instance.
In contrast, while worms may cause serious problems, by being largely restricted to the GI tract, and by being vastly larger, they are much more amenable to being flushed out.
My conclusion would be that viruses are quite a lot worse than worms...
The problem is that Processors are only the start
on
Open-Source Processors
·
· Score: 3
In order to have a usable system, you also need:
A motherboard
More people might be using PPC, MIPS, or StrongARM if there were inexpensive motherboards; the fact that there aren't should give the observer cause to say "Hmmm..."
BIOS
Support for standard buses like PCI, USB, ATA, and such (I2O? Firewire? DIMMS? EV6?)
... Which may be a wrench in the works of attempting motherboard implementation, if using the specs requires paying royalties or signing NDAs
Obviously NVidia video drivers that only get compiled for IA-32 won't work on the "Custom CPU 5000."
I'm not sure just how far this issue extends...
The point is that it's not good enough to have a slick new CPU design; you need a system around it to take advantage of it, or, quite frankly, just to allow it to function.
Those that were prepared to "roll their own MIPS variant" to build some highly customized embedded system may find this a quite acceptable scenario. But anybody thinking that this leads to having VA Linux Systems selling F-CPU-based systems any time soon is severely delusional...
Installing the latest RPM or DEB packages, doing a bit of config work via rsh, and being able to scale to 64 way by putting 64 boxes in the rackmount unit, or
Designing a motherboard that integrates together 64 CPUs?
SMP certainly provides the benefit of very fast communication between CPUs, so if processing is strongly dependent on that, SMP wins.
But it is most certainly a lot more expensive to scale it up. The vendors may sell 2-way and 4-way SMP motherboards for not overly princely sums, but moving on to higher multiples guarantees pretty monstrous prices, because you're simultaneously mandating:
Small production runs, compared to the teeming hordes of single CPU motherboards, and
Sitting at the bleeding edge, because nobody wants a souped up version of a CPU that was "state of the art," LAST YEAR.
Kernel compiles aren't liable to benefit all that much from parallelism, moving forward; consider that
with a Pentium III or Athlon, it doesn't take long to recompile Linux even from scratch. It's just getting to be less and less an issue.
As for benefiting from other forms of parallelism, it is entirely likely that the toolsets surrounding Beowulf and PVM will improve over time to make it easier to manage doing "clustered tasks" in much the same way that we have progressed from having rather primitive "package management" tools to having stuff like AutoRPM, apt-get , and BSD Ports.
Regarding price: yes, it's bloody expensive. It's expensive for good reason: the first step toward learning how to invest is to realize that you're going to have to spend money on learning.
Methinks the good reason for it being expensive is, instead, that the author wants to make a bunch of money from it.
The road that your contention leads down is one that leads uncomfortably near to:
Paying big bucks to get your engrams audited, and
Paying big bucks to take MLM courses
There may well be well and worthy merits to this game, and it may even be worth the $200. Please just don't use "you need to learn to pay for courses" as the apologia for the pricing...
There are two sorts of systems that this discussion identifies:
Embedded special purpose systems
Such as an "address book," an "email system," a "web browser," a "word processor" and such.
There do exist appliances of these various sorts.
General purpose computer systems
Unix is the "granddaddy" of this sort of thing; with the "duct tape" of scripting languages, you can readily hook together a Unix box to do a vast assortment of different sorts of stuff.
There is a place for both approaches to computing, and the growth of PDAs may be suggestive of a way of "melding" them in a useful way.
PDAs like the PalmComputing platform provide somewhat "dumbed down" interfaces, and are nevertheless useful. Due to limited screen, memory, and storage, they are largely kept to more "appliance-like" applications.
The long term might well move towards having homes that use a paradigm somewhat reminiscent of this, with a "server" in a back room that provides Internet access, storage of documents, and a repository for "scheduled stuff." It would be entirely sensible for this to be something like a Unix box.
There would then be "satellite" systems around the house, including:
PDAs to provide access to the data you want to carry around. Calendars, address books, perhaps MP3s, portable books,...
There might be several "workstations" around, with larger screens, keyboards, mice, and the likes.
These would be well-suited to "document processing."
"Family" room (or "bachelor's den":-)) would logically have a large screen, speakers, and controllers, with "appliances" suited to displaying/playing audio and video recordings and supporting interaction [e.g. - video games].
The "Killer App" in the kitchen would be a touchsensitive PDA stuck to the refrigerator that would primarily display a combination of ToDo lists [groceries, anyone?] and calendar information.
A telephone with integrated address book and calendar would doubtless be a good thing.
Virtually all of these could be implemented as "general purpose computers," but you're then left with the job of having to manage all the computer systems.
It would be rather more attractive for most of these to instead be "appliances" that connect to a central "home server."
Various of them make more sense if you integrate a PDA into the appliance, and have a wireless local connection so that they can get at the data on a local server.
I would think it a slick idea to have a PDA running Linux, but that doesn't mean that I want to use a stylus to write in cd ~/addressbook; grep -i browne * | grep -i david | phonehome to dial my brother's phone number. The merit of running Linux would be that of having a well-understood robust portable platform for the developer. Given those things, to make life easy for developers, I'd be more than happy to have hardware where I press a couple of buttons to search for names in an address book.
I would think it a suboptimal thing to just use a bunch of completely independent appliances, as with "MailStations" and such; the step forward is to have the appliances, and have a way for them to interoperate usefully with a "home server."
Even with ReiserFS, there is some overhead of space and time involved in managing files. Each file has a directory entry and an inode or two; while ReiserFS may unambiguously improve the time efficiency, that does not result in the space overhead falling to zero. At the very least, you've got, for each file:
struct o_stat {
o_dev_t st_dev;
o_ino_t st_ino;
o_mode_t st_mode;
o_nlink_t st_nlink;
o_uid_t st_uid;
o_gid_t st_gid;
o_dev_t st_rdev;
off_t st_size;
time_t st_atime;
time_t st_mtime;
time_t st_ctime;
};
which adds up to around 48 bytes, and add to that the size of the directory entry that attaches to the inode.
It's not forcibly "ludicrously big," but it's space overhead nonetheless.
As for "flaming," it's somewhat unfortunate that Dan
basically doesn't care what anyone else thinks.
If he tried to find some places for agreement, his software would probably get used more. Some of it's really very neat, cdb and the microscopic DNS server being particular examples...
The fact that he comes from a pretty strongly "pure math" background means that he comes up with substantially different ideas than most people. The PM factor adds in two particularly useful things:
He thinks about the notion of proving correct behaviour;
He looks to the "kernel" of the ideas, and implements "mathematically small" systems that are easier to verify to be correct than much of the rubbish that others produce.
No, I don't; a quick web search actually picks up a number of Qmail-related packages that apparently now use the GPL, so it may be that his opinion changed.
It used to be that qmail was only allowed to be distributed in source code form, and the CDB database system (it's a cool thing well worth looking at) used a license that was somewhat incompatible with the GPL. There seemed to be some rancor to the effect that the GPL wasn't a "free" license; seemingly an independent recreation of the "BSD bigot" approach to software licensing.
There was a discussion on this back last October on comp.os.linux.development" under the subject Should I Pay Linuxgruven $2500 for a Job. It's out at Deja.com if you wish to refer back to it...
The conclusion was that the policy that people were reporting then, which sure sounds like what we're hearing here, seemed pretty fishy.
At the time, I figured that they were a little company that was trying just a little too hard to grow a little too fast; the evidence neither supports:
The thesis that they're a pure "pyramid scam" nor
The thesis that they're tremendously credible.
Perhaps the most cogent comment was thus:
Real companies pay for your training, and then, if you are good, expand your pay, benefits, bonus, etc. to keep you. What you have here is either a scam, or at the very least, a great big red flag that the company is run like crap.... -- Ken Sodemann
The crucial technical differences between mbox and Maildir are that:
By keeping all the data in one file, mbox should use disk space more efficiently as there will be no overhead for directory or inode entries.
This may be important on a big mail server where inodes or disk space may wind up being scarce commodities.
By keeping all the data in one file, mbox keeps all the eggs in "one basket;" there is correspondingly less risk of corruption with Maildir .
Since the mbox format is a longstanding "tradition," there are lots of libraries that work with it. There are fewer to manipulate Maildir .
There are then nontechnial issues.
The creator of Maildir , Dan Bernstein, is a, um, "somewhat prickly character." Take a look at his criticisms of Postfix for some mild material. Comparative discussions of Postfix and qmail have resulted in extremely inflammatory discussions. And Bernstein's attitudes towards the GPL seem similarly "inflammatory." This appears to have put some people off his software, whether rightly or wrongly.
Personally, I use Postfix as my MTA, and push messages through Maildir as interim step to pushing them into MH, which is only a fairly small step removed from Maildir...
Certainly a common intent of "shadow" is that of something dark and malevolent, and the association of "darkness" with colour resonates with the American experience with race relations. There is probably some usage of the word "shadow" in the American South that is explicitly racist, and those of us that are not "literarily intimate" with the American South don't even perceive that to be a relevant intent.
I don't think that came out of anything racial; the reason for the malevolence is that people prefer to hide what is evil, and a good way of doing that is to keep it in darkness, rather than keeping it "well-lit." In that context, the word "shadow" is immensely appropriate.
Neither of those contexts appear terribly relevant to either of Card's "Shadow" books; the other meaning of "shadow" comes in that the shadow is some sort of pale imitation, an "inverse reflection" from something real, that lurks near that "real thing." That set of characteristics apply quite well to Bean in these books. He "lurks" near the Wiggins brothers, and is something of an "imitation" of them.
Different parts of one's "personal economy" will vary considerably in cost between countries; you have to consider:
Cost of food
Cost of rent
Cost of furniture, home electronics, clothing
Cost of transportation
Tax burdens
By and large, the US is a place where "home electronics" and computers are pretty cheap, as is transportation.
That correspondingly results in heightened expectations, most blatantly expressed in the form of the much-maligned SUVs.
Moving to Japan would force massive "lifestyle" changes, as a house of the size typical here in Texas would be unheard of in Tokyo, and it would just not be sensible to drive around in a pickup truck in Tokyo either!
Those two "broad" strokes (house, truck) show that what you'd have in another country might be quite substantially different.
In a city with massive subway system, like Paris, it would be eminently reasonable to not even consider having a car; the standards for fashion, food, and working hours are different enough to make facile measures like "dollars per hour" quite insensible.
A comparison probably has to integrate together a budget for all the "personal economic sectors" listed above. In effect, you have to plan to change your lifestyle, and estimate what the results are liable to be.
The "publish or perish" cycle whereby SuSE and RHAT and friends regularly produce new releases in order to get some cash flow from CD sales still applies here.
After all, if the paychecks of the LinuxPPC folk depend, to great extent, on CD sales, then it is in their interests for there to be some degree of "churn." Frankly, your phrasing of:
They have to sell distros and support to pay the workers, so they need to get a product out the door.
applies pretty much just as much to LinuxPPC, "the nonprofit" as it does to RHAT et al.
Consider it stipulated that the factor of third party shareholders deciding they want an extra million in sales goes away; that doesn't make the factor go away altogether.
In contrast, the would-be counterexample you cite, Debian, can "afford" to have rare new releases because a new release doesn't affect their finances at all because they don't directly sell CDs. That's not the same scenario that LinuxPPC has.
If the patent was filed in the US, then it affects use in the United States.
That's enough to build some talking points:
If the patent wasn't filed (and accepted) in, say, England, then people in England are free to use the process. A US patent does not affect British use.
If the patent was filed in Jamaica, and not anywhere else, then it's liable to be "fair game" for free use everywhere else.
And you know the entertaining part? If the "indexing patent" turns out to be effective in court, search engines are liable to move web sites to offshore locations (Seahaven?:-)) where the offending patents do not apply.
The point he makes is that a non-profit organization isn't attractive as an 'investment' to people interested in speculating on changes in price of the stock.
There is no "stock," no opportunity for those kinds of gains, and hence a whole host of things that occur in "public" corporations have no reason to occur:
The incentive to gleefully over-sell the upcoming products because the market will price up the stock isn't there.
The incentive to gratuitously increase sales in order to get stock price to shoot up isn't there.
The notion of "buying them up" in order to strip out crucial assets isn't there.
A non-profit that isn't purchasable just isn't an attractive target for a number of such strategies that are generally oriented to for-profit public corporations.
That's not to say that the move to non-profit is an unalloyed benefit; a different set of "political" issues raise their ugly heads in non-profit organizations.:-(
Slashdot Mirror
What would be useful would be to build a version of apt-get that could use RPM as the packaging tool instead of dpkg. Which is something people are working on...
The first problem you describe essentially requires that you have an RPM or dpkg database that is prepopulated with all the information from all packages out there in "packageland."
It might be a reasonable thing to try to extract such information from some place like RPMFind.net ; but the essence of the matter is that you need to have all the packages available for query, which is not likely to be the case on your PC at home if you're using APT to get at packages remotely.
As for the second problem, of "recursiveness," there's both a touch of inherent danger, and an answer with APT.
The parallel aspect of this resolves most of the problems you suggest.
In effect, the problem is that RPM could use a "helper" rather like APT in order to cleanly satisfy dependancies for a clean install of software.
It's not that RPM is "broken;" it's that it really needs that "soul mate/life partner." :-)
apt's purpose is quite directed, namely to track the associations of inter-package dependancies.
It leaves the task of tracking specific files to a completely separate piece of software called dpkg. Or, if you use the "beta" version of apt-get, the database of files installed would be maintained by RPM.
So, supposing you want to know what files are associated with the Netscape package titled netscape-communicator, you might use the commands:
dpkg -L netscape-communicator
or
rpm -ql netscape-communicator
depending on what packaging tool you prefer to use. Note that neither of those commands involve apt in any way, shape, or form.
At which point AES would get renamed PES, the Previous Encryption Standard
Where if you don't "FES" up to what your key is, they'll have at you with rubber pipes...
If your feelings are so brittle that what I wrote felt like an attack, then you probably should run, not walk away from trying to get code integrated into the "official" kernel, as the normal course of discussions involves vastly stronger wording than I ever use...
Unfortunately, it has sat in "ready Real Soon Now" status for a long time now. I'd hazard the guess that a bunch of developers are feeling rebellious about the fact that it is not free software.
By the way, the "let's set up a CVS repository" idea has the conspicuous demerit at "send the patch to Linus time" that it is still going to take a lot of effort to make sure that the patches that get sent on to Linus are reasonably perspicuous. You're still left with the dilemma that:
But this will tend to "bulk up" into something that involves a horde of changes, which again will not be terribly perspicuous.
This is certainly spelled "dilemma," as all the alternatives are pretty poor...
This already provides a set of protocols and data formats standardized under the auspices of the IETF . There's an XML encoding under way as well as an OMG committee working on CORBA IDL.
There are already applications that know how to use these protocols/formats, including the GNOME and KDE calendar programs.
Build a "calendar server" that knows how to store appointments for a horde of users, and a "vCard" server that can accept address info for hordes of users, and use the existing standards to try to build in further sorts of useful interactions.
This would make the existing tools vastly more useful. It doesn't fundamentally matter whether this involves XML, CORBA, MySQL, or LDAP; those are all implementation details that can probably vary a whole lot without breaking the fundamental idea, which is to build standards-compliant servers.
That was the whole point to defining these calendaring and scheduling and address standards, namely to provide a standard way of doing the sorts of things that Microsoft built proprietary interfaces into Outlook for.
He can choose to:
- Take the PPC patches as gospel, and throw away everyone else's contributions,
- Go through a whole lot of work breaking the PPC patches down into bite-sized components, or
- Tell the PPC developers to turn the PPC patches into bite-sized components themselves, and ignore the huge patches that he hasn't time to integrate in.
In effect, he's going with "option 3" here, and that's not an outrageous outcome. The LinuxPPC folk may not like this outcome, but it's neither new, capricious, nor is it discriminatory. Alpha has suffered from much the same issue...They also have the scary poetry of Daniel Lavigne
It's missing the time the "tax protestor" wrote an extremely off-colour poem the guy wrote about me.
One of these days, I should put together a "bot" from which I'd grab a bunch of postings by these sorts of folk, build a sort of "parse tree," and then run a random number generator through it to generate pseudo-postings by them... 'Twould be entirely entertaining...
There are applications out there where $60K is a small price to pay to increase performance rather a lot, and $60K starts looking small when you start pricing Sun E10000 servers and such.
The big value to SSD comes in when you've got one of those situations of heavy database updates where eliminating latency time is a big win. If throwing on a $60K SSD allows downgrading from a $1.5M server to a $1.1M server, that was evidently a very good buy...
A CF memory card system that doesn't allow you to hit it hard with vast numbers of updates just doesn't compare. And it's still hardly cheap; there aren't $60K units, but there aren't 8GB CF memory cards, either...
The worm is still not so pervasive as a virus that resides in virtually every cell of the body.
Remember that a virus is much tinier, more pervasive, and more invasive than a worm.
We see such viruses as Ebola and Lassa that are tremendously fatal. The same is not so true for the worms that likely only live in the GI tract.
Once invaded by a virus, there is very little that can be done, whether in biological or computer systems; it can potentially get anywhere in the system, and readily be impractical to stamp out. There is no cure to Ebola, for instance.
In contrast, while worms may cause serious problems, by being largely restricted to the GI tract, and by being vastly larger, they are much more amenable to being flushed out.
My conclusion would be that viruses are quite a lot worse than worms...
More people might be using PPC, MIPS, or StrongARM if there were inexpensive motherboards; the fact that there aren't should give the observer cause to say "Hmmm..."
I'm not sure just how far this issue extends...
The point is that it's not good enough to have a slick new CPU design; you need a system around it to take advantage of it, or, quite frankly, just to allow it to function.
Those that were prepared to "roll their own MIPS variant" to build some highly customized embedded system may find this a quite acceptable scenario. But anybody thinking that this leads to having VA Linux Systems selling F-CPU-based systems any time soon is severely delusional...
- Installing the latest RPM or DEB packages, doing a bit of config work via rsh, and being able to scale to 64 way by putting 64 boxes in the rackmount unit, or
- Designing a motherboard that integrates together 64 CPUs?
SMP certainly provides the benefit of very fast communication between CPUs, so if processing is strongly dependent on that, SMP wins.But it is most certainly a lot more expensive to scale it up. The vendors may sell 2-way and 4-way SMP motherboards for not overly princely sums, but moving on to higher multiples guarantees pretty monstrous prices, because you're simultaneously mandating:
- Small production runs, compared to the teeming hordes of single CPU motherboards, and
- Sitting at the bleeding edge, because nobody wants a souped up version of a CPU that was "state of the art," LAST YEAR.
Kernel compiles aren't liable to benefit all that much from parallelism, moving forward; consider that with a Pentium III or Athlon, it doesn't take long to recompile Linux even from scratch. It's just getting to be less and less an issue.As for benefiting from other forms of parallelism, it is entirely likely that the toolsets surrounding Beowulf and PVM will improve over time to make it easier to manage doing "clustered tasks" in much the same way that we have progressed from having rather primitive "package management" tools to having stuff like AutoRPM, apt-get , and BSD Ports.
The road that your contention leads down is one that leads uncomfortably near to:
- Paying big bucks to get your engrams audited, and
- Paying big bucks to take MLM courses
There may well be well and worthy merits to this game, and it may even be worth the $200. Please just don't use "you need to learn to pay for courses" as the apologia for the pricing...- Embedded special purpose systems
- General purpose computer systems
There is a place for both approaches to computing, and the growth of PDAs may be suggestive of a way of "melding" them in a useful way.Such as an "address book," an "email system," a "web browser," a "word processor" and such.
There do exist appliances of these various sorts.
Unix is the "granddaddy" of this sort of thing; with the "duct tape" of scripting languages, you can readily hook together a Unix box to do a vast assortment of different sorts of stuff.
PDAs like the PalmComputing platform provide somewhat "dumbed down" interfaces, and are nevertheless useful. Due to limited screen, memory, and storage, they are largely kept to more "appliance-like" applications.
The long term might well move towards having homes that use a paradigm somewhat reminiscent of this, with a "server" in a back room that provides Internet access, storage of documents, and a repository for "scheduled stuff." It would be entirely sensible for this to be something like a Unix box.
There would then be "satellite" systems around the house, including:
These would be well-suited to "document processing."
Virtually all of these could be implemented as "general purpose computers," but you're then left with the job of having to manage all the computer systems.
It would be rather more attractive for most of these to instead be "appliances" that connect to a central "home server."
Various of them make more sense if you integrate a PDA into the appliance, and have a wireless local connection so that they can get at the data on a local server.
I would think it a slick idea to have a PDA running Linux, but that doesn't mean that I want to use a stylus to write in cd ~/addressbook; grep -i browne * | grep -i david | phonehome to dial my brother's phone number. The merit of running Linux would be that of having a well-understood robust portable platform for the developer. Given those things, to make life easy for developers, I'd be more than happy to have hardware where I press a couple of buttons to search for names in an address book.
I would think it a suboptimal thing to just use a bunch of completely independent appliances, as with "MailStations" and such; the step forward is to have the appliances, and have a way for them to interoperate usefully with a "home server."
o_dev_t st_dev;
o_ino_t st_ino;
o_mode_t st_mode;
o_nlink_t st_nlink;
o_uid_t st_uid;
o_gid_t st_gid;
o_dev_t st_rdev;
off_t st_size;
time_t st_atime;
time_t st_mtime;
time_t st_ctime;
};
which adds up to around 48 bytes, and add to that the size of the directory entry that attaches to the inode.
It's not forcibly "ludicrously big," but it's space overhead nonetheless.
As for "flaming," it's somewhat unfortunate that Dan
If he tried to find some places for agreement, his software would probably get used more. Some of it's really very neat, cdb and the microscopic DNS server being particular examples...
The fact that he comes from a pretty strongly "pure math" background means that he comes up with substantially different ideas than most people. The PM factor adds in two particularly useful things:
It used to be that qmail was only allowed to be distributed in source code form, and the CDB database system (it's a cool thing well worth looking at) used a license that was somewhat incompatible with the GPL. There seemed to be some rancor to the effect that the GPL wasn't a "free" license; seemingly an independent recreation of the "BSD bigot" approach to software licensing.
The conclusion was that the policy that people were reporting then, which sure sounds like what we're hearing here, seemed pretty fishy.
At the time, I figured that they were a little company that was trying just a little too hard to grow a little too fast; the evidence neither supports:
Perhaps the most cogent comment was thus:
This may be important on a big mail server where inodes or disk space may wind up being scarce commodities.
There are then nontechnial issues.
The creator of Maildir , Dan Bernstein, is a, um, "somewhat prickly character." Take a look at his criticisms of Postfix for some mild material. Comparative discussions of Postfix and qmail have resulted in extremely inflammatory discussions. And Bernstein's attitudes towards the GPL seem similarly "inflammatory." This appears to have put some people off his software, whether rightly or wrongly.
Personally, I use Postfix as my MTA, and push messages through Maildir as interim step to pushing them into MH, which is only a fairly small step removed from Maildir...
I don't think that came out of anything racial; the reason for the malevolence is that people prefer to hide what is evil, and a good way of doing that is to keep it in darkness, rather than keeping it "well-lit." In that context, the word "shadow" is immensely appropriate.
Neither of those contexts appear terribly relevant to either of Card's "Shadow" books; the other meaning of "shadow" comes in that the shadow is some sort of pale imitation, an "inverse reflection" from something real, that lurks near that "real thing." That set of characteristics apply quite well to Bean in these books. He "lurks" near the Wiggins brothers, and is something of an "imitation" of them.
- Cost of food
- Cost of rent
- Cost of furniture, home electronics, clothing
- Cost of transportation
- Tax burdens
By and large, the US is a place where "home electronics" and computers are pretty cheap, as is transportation.That correspondingly results in heightened expectations, most blatantly expressed in the form of the much-maligned SUVs.
Moving to Japan would force massive "lifestyle" changes, as a house of the size typical here in Texas would be unheard of in Tokyo, and it would just not be sensible to drive around in a pickup truck in Tokyo either!
Those two "broad" strokes (house, truck) show that what you'd have in another country might be quite substantially different.
In a city with massive subway system, like Paris, it would be eminently reasonable to not even consider having a car; the standards for fashion, food, and working hours are different enough to make facile measures like "dollars per hour" quite insensible.
A comparison probably has to integrate together a budget for all the "personal economic sectors" listed above. In effect, you have to plan to change your lifestyle, and estimate what the results are liable to be.
After all, if the paychecks of the LinuxPPC folk depend, to great extent, on CD sales, then it is in their interests for there to be some degree of "churn." Frankly, your phrasing of:
applies pretty much just as much to LinuxPPC, "the nonprofit" as it does to RHAT et al.Consider it stipulated that the factor of third party shareholders deciding they want an extra million in sales goes away; that doesn't make the factor go away altogether.
In contrast, the would-be counterexample you cite, Debian, can "afford" to have rare new releases because a new release doesn't affect their finances at all because they don't directly sell CDs. That's not the same scenario that LinuxPPC has.
That's enough to build some talking points:
And you know the entertaining part? If the "indexing patent" turns out to be effective in court, search engines are liable to move web sites to offshore locations (Seahaven? :-)) where the offending patents do not apply.
The point he makes is that a non-profit organization isn't attractive as an 'investment' to people interested in speculating on changes in price of the stock.
There is no "stock," no opportunity for those kinds of gains, and hence a whole host of things that occur in "public" corporations have no reason to occur:
A non-profit that isn't purchasable just isn't an attractive target for a number of such strategies that are generally oriented to for-profit public corporations.
That's not to say that the move to non-profit is an unalloyed benefit; a different set of "political" issues raise their ugly heads in non-profit organizations. :-(