Supposing you mistag something in /etc/sendmail.xml , this could mean that Sendmail could no longer run.
There is a benefit that XML buys you, which is that you could build a generic configuration tool that doesn't intimately know any individual DTD, but which does know how to:
Turn an XML document into a browsable tree on screen, and
Accept modifications and write them out as validated XML (sans DTD)
But as you say, there would need to be many DTDs, which really just shoves the problems around a bit. It doesn't clean them up; it's more like using a dirty rag to clean a window, so that the dirt is getting redistributed to different parts of the window...
The big problem would be in getting all the applications to change to use an XML parser.
I don't think it's likely to be ready for another year at best, and I think they need to step back and consider having a language formally made to represent tax rules rather than informally layering javascript and GLADE together in an XML file, but it's "under way."
The initial priority has been to get the GUI working and sufficiently featureful.
Now that that is working fairly well, it starts to make sense to try to automate the creation of transactions, which includes:
Scheduling transactions automagically
Loading transactions from QIF files
Loading transactions from OFX files
Surprisingly, a critical issue with all three of these things is that of creating a suitable user interface.
In particular, with QIF and OFX input, there needs to be a user interface to control the translation from the data file's set of accounts to those that the user has set up in GnuCash.
I've written a pretty slick QIF parser; deployment of that has been blocked due to the need to have a front end to let the user decide which account to use in GnuCash. The same will be true for OFX files.
Note that some financial institutions generate OFX/QIF files that omit entirely the account, thereby requiring that you manually set up a destination account for the expense.
The odd part is that I studied it in (high?) school, in Canada, and there was no comment made about the "Canadianness" of the story.
Frankly, I'm going to have to look back at the book to verify just where it is that it makes a sufficiently clear reference to Labrador to indicate that that is where it was placed...
Mind you, in it being written in 1955, Labrador had only been a part of Canada for six years, which means that it was too early for there to be any long term understanding of the notion of the region being part of Canada.
I'm not sure if an understanding of the actual culture of Newfoundland is, or is not, relevant to the story. Rather interesting if it is, as that's a rather obscure place, not terribly well-known, in many ways.
I think I'd read the story in rather different light if that be the case...
Unfortunately, people seem to see there being two ways of managing system configuration:
There's the UNIX Way
Where Real Men use vi to manually edit all the text files.
There's the Windows Registry Way
Where Modern Administrators point'n'drool their way through menus, searching for the configuration.
These are the commonly-perceived stereotypes, and, too often, represent peoples' attitudes, whether pro or con.
Unfortunately, by focusing on this particular dichotomy, people miss the mark, in that neither approach is particularly manageable. Moreover, by thinking they are the only alternatives, people miss the directions for true improvement.
There's a place for having a centralized "registry" of access methods to access configuration information.
It may be true that:
"Lumping configuration data, security data, kernel tuning parameters, etc. into one monstrous fragile binary data structure is really dumb." -- David F. Skoll
That doesn't mean that there wouldn't be value to building up a hierarchical "tree" that knows how to look up configuration information. The data can sit where it is now; the "tree" is useful for providng the administrator with a comprehensive way of getting at it.
Automation means You don't have to touch it again.
Configuration work that the system does for you is the true labour savings; if the system cleans up after itself, and I don't have to do it, that is an automated system.
I'm glad to drop in an extra cfengine rule into /etc/cfengine and have the system do more work for me.
The correct fork to take is not to have 'friendlier versions of Linuxconf;' it is to have more tools like cfengine that represent more permanent solutions to configuration problems.
I've seen a couple outages this year on the SPARC cluster that I help support, mostly relating to I/O problems. (Disks and controllers "going bad.")
My suspicion is that IA-64 is going to have less impact on server configuration than one might expect, certainly less than the "Gartner cheerleading" used to indicate. After all, on servers, the important thing is not the CPU, but rather the combination of I/O subsystems, whether:
RAM, or
Disk
I could readily see "workstations" getting "killed off," what with PC's getting more and more powerful.
But the big deal for anything higher-end is the buses, and not merely the CPUs, which makes the bluster about CPUs pretty moot...
You really shouldn't be generating gnumeric files like that - the file format may change - probably to one based on libefs (binary) or, maybe, Microsoft structured storage, if the short names can be worked around(MS SS only lets you have 32 byte names for streams).
I bounced the question over to the Gnumeric mailing list last night, and the response was that it seemed wiser to generate "plain old" XML.
I'm going to be indignant for a moment; I'm going to bounce a note over to the relevant mailing list to try to get a more authoritative statement on the matter...
If the intent is for the only way to create GNOME application documents is via Bonobo automation, this BADLY breaks the UNIX principle of "Data, not Behaviour."
It is a reasonable idea to expect to be able to use text processing tools to generate documents. The notion that the "correct way" is "through bonobo automation" is roughly equivalent to the notion that we need to embed GNOME closure generators into every development tool, and that seems to me to be a desparately terrible idea.
If we're embedding 40MB videos into spreadsheets, I suppose it may be appropriate to enforce a "it's gonna be binary" rule, but it seems to me that that restricts GNOME to being a useful framework for managing complex porn web sites.
One matter that is not mentioned as an evaluation criterion is that of what data format is used.
I don't think it is possible to overestimate the importance of the issue of data formats, at least not in the context of looking at word processors. If you want your document to be usable five years from now, it is ludicrously unacceptable to use whatever "document embedding" scheme MSFT uses this year.
The format has several notable effects:
If it is "text-based," this may mean that you can email documents without worrying about special encodings.
Note that the spreadsheet XESS promotes this as a "selling feature."
(Others may say, uuencode is your friend. )
If it is text-based, this means that you may be able to modify the document using other tools than the word processor.
That's useful for debugging, solving problems, modifying the document when you move it over to a laptop that doesn't have the word processor installed and have to use vi.
If the format is based on some normative standard, this means that you can expect to be able to create documents using external tools.
For instance, if the program uses an XML-based format, it becomes reasonable to write a Perl, Python, or Scheme.
Example-of-the-week: I've been working on generating spreadsheet files for use with Gnumeric. The plan is to write Scheme scripts that pull data out of GnuCash, and generate reports. I haven't gotten to the "extraction" part, but have generated some pretty slick demo spreadsheets.
Someone in a law (or para-law) office might want to create a document template scheme where they run a K001 GUIed program that asks for names and sundry fields, and then generates legal documents. Given a sufficiently "open" format, that's pretty practical.
I believe that KWord uses XML as its native data format, with a disclosed DTD. ApplixWare uses a tagged text format that looks a fair bit like SGML. AbiWord uses XML. StarOffice and WordPerfect use not-particularly-readable binary formats; WordPerfect's formats have historically been disclosed, but writing programs to generate it is a NonTrivial Task, whereas StarOffice's format appears to be a big unknown.
Using formats where there's at least some visible ASCII text seems to me to be the only reasonable way to go. I'll remain a bit skeptical of XML; just 'cause it's buzzword-compliant doesn't mean that the DTD will be in use in the long term...
If they send a kernel patch, and do a decent job of it, they can get a line in /var/log/messages as well as in the boot-up process when running on any ABIT motherboard, on any distribution.
By creating their own distribution, this is decidedly fragmentary, and insane.
I wish that I were incredulous at this; after seeing what LinuxOne has to offer, I'm not...
... Because that allows them to divide and conquer based on what they have analysis tools for.
Remember that those O'Reilly books have considerable structure in common; they are all of similar form factors, which means that you can readily drop them onto a single shelf and expect them to fit nicely. If they had varying shapes, sizes, and bindings, this wouldn't work out nearly so well, as they'd need to (for instance) come up with a customized kind of book binding for each book.
If your docs are written using LaTeX, they have no way of automatically integrating it into a single comprehensive document.
If your docs are written using whichever DTD they favor today, it is a relatively straightforward task to integrate this together.
Thus, there are actually two classes of documents:
Documents using the SGML DTD that they favor, and
Those that don't, for which an important priority will be to figure out if the documentation is, based on its format, going to be useful to you.
What the world needs is for the LDP to complete the transition from qwertz to DocBook, publicize this vigorously, and thereby attract people to make some incremental improvements to the documentation.
A cool approach might be to build something like a WikiWikiClone that can collect up improvements made online, and turn them into linear presentations. I suggest this because the Wiki mechanism is very much oriented towards the approach of improve a page here or there a bit.
Quite seriously, if it's to be useful, it should hardly be characterized as "Just A File Manager."
Consider:
By characterizing what they're working on (whether there's a bit of inaccuracy or not) as a "desktop," this implies that it's intended to become a pretty all-encompassing interface.
When it starts getting "smart" enough that applications can get embedded into it, it's no longer as much a "file manager" as it is a document manager.
And that is where it starts to get interesting.
The thing about Linux, as it is today, that is kind of scary to people that need to think of computers as "appliances," is that it doesn't have a unified way of treating things as "documents."
A "document manager" that lets you make sure that stuff doesn't get lost due to it falling into a directory that you didn't know you needed to look at is going to be the killer app of the next decade.
I agree that Explorer is quite horrifying; I look at it as the "machine gun" of computing.
People tend to be horrified at this analogy, but its ability to accidentally destroy files quite analagous to the notion of walking around the office carrying an M-60 with finger on trigger. You slip up a bit, and "Oops! I accidentally shot up 15 cubicles and killed 8 coworkers."
If these guys can do some good HCI work, perhaps taking some of the better concepts from OS/2 and NeXTstep, and actually create a usable and powerful "document manager," this seems to me to be quite a worthy task.
The thing that we need to know is whether or not Transmeta is going to implement an emulator for MMIX.
This would doubtless be crucial for Volumes 4-6 of TAOCP, and the availability of real hardware for this would strike fear into the hearts of graduate students in computer science the whole world over...
What they're building is effectively an "all encompassing file manager," called Nautilus.
There's no particular reason for this to represent a "duplication of effort," at least from the standpoint of the GNOME project. After all, they needed a better file manager. GMC has not been all that satisfactory.
What their application amounts to is one that unifies files and remote objects (via HTTP/FTP) together, and lets methods be invoked on them.
By using the Bonobo interface, they can pull in all sorts of GNOME objects. That's certainly not duplication.
It may be duplicative if you're a developer working on the Kconq file manager for KDE that has similar scope; it's not duplicative within the context of GNOME.
I'd say that this is the most important component to have some serious HCI people take a look at; that's the only hope of it being usable to the "Bubba" users. (No offense intended to other than Presidents of the United States:-)...)
It's important that this get HCI attention in that if it succeeds, Nautilus would become the front-end for a whole lot of users to get at "system stuff."
All of the above comments are entirely flameworthy, although if we headed back to 1993, they all would be arguments having
some merit.
Unfortunately for the BSD folk, and fortunately for those that have appreciated the outgrowth of Linux, technical considerations were not the only issue. There was this "minor" matter of the USL lawsuit.
As it turns out, with Linux, as well as with Firewire, technology is not the only issue; licensing constraints figure prominently. Extremely prominently.
People were scared off of *BSD, whether rightly or wrongly, by the fear of the effects of the lawsuit.
And it appears that Apple is doing a good number on the adoption of Firewire, perhaps, simply, by their existence. After all, after the discontinuance of Newton, and the fun of "What variation of NeXTstep will we stop selling today?" it appears unwise to trust too much to the good graces of Apple.
Actually, what I'd find more interesting would be the idea of hooking up a whole pile of Serial ATA interfaces.
After all, with only 4 wires (or maybe 8, with grounds and the likes) instead of ATA's on-the-order-of-50, you can have a good half dozen "S-ATA" interfaces in the same amount of room.
And that means that rather than having a dozen devices sharing the bandwidth of one bus, you can have them be pretty independent. Rather than 100MB/s, that gives us 600 MB/s.
I don't realistically expect this to happen, but it would be pretty slick if it did.
Looking forward in the "ten year perspective," a natural development would be to move towards greater asynchronicity at the bus level, and what looks more asynchronous:
Having one 72 pin parallel bus for "super-fast SCSI" that grabs some DMA? or
Having 36 serial buses, one-per-drive, with two wires apiece, each buffering requests both to the disk as well as to DMA?
I frankly think the latter is a slicker idea, in the long run...
The C comes in when make all doesn't work out perfectly. Which happens all too often.
Then you start having to search for the #include files that the program expected to find. Which establishes that you have to install (say) a new version of ncurses or some such thing.
It may not be a full-scale porting effort, but it does require, if you want any hope of troubleshooting, being reasonably comfortable with the tool set used for C development.
If you decide to install Balsa, which pulls in big chunks of GNOME, that may be a bit distressing. It's hardly hidden. And if you actually want to install Balsa, you've little choice in the matter.
You can either say,
Oops. I guess I didn't want to install all that much stuff
and back out, or
Pretty big, but I guess I'll have to live with that.
There's no "Oh well, I'll install bits of it that won't work" (at least not without some explicit effort!)
Remember that in the in the "Windows World" it also wouldn't be a 300k email package. It would be a 20MB email package that includes every library that could conceivably be necessary.
And you'd have to worry that the email client might come with some older DLLs that will overwrite ones you're using for something else, thereby toasting other applications on your system.
I don't see any realistic way around the consideration that Systems Integration Is Messy.
Whether we talk about DPKG, RPM, or BSD Ports, it's a given that the process of getting packages integrated into a particular distribution is a somewhat messy process. In all cases, there is some form of patch that gets applied to indicate precisely how they are to get installed.
It is getting increasingly common for Debian packagers ( e.g. - the human being that builds the patches required to integrate the package in with Debian) to have some degree of involvement with the "upstream" production of the original, authoritative source code tree.
When this happens, it is not unusual for there to be a ./debian subdirectory containing the "Debian-relevant" patches, and I've also seen ./SPECS directories with RPM .spec files. In cooperative development efforts, this is the point at which important cooperation takes place, as this means that there is some thought to systems integration in the original source code tree, which will make the job easier for everyone else.
It's not likely that the level of effort will actually diminish to zero, but if it becomes largely automated, and the human effort can be widely distributed, that makes the task not too herculean.
Debian doesn't impose a requirement that you watch out (much) for dependancies; it does all the things that you mention, verifying dependancies, and requesting any extra packages that are required to satisfy the dependancies.
No "go off and find dependancy foo, and ask to download it"
No "go off and run ./configure; make install "
The "glibc-foo" issue is a given so long as there is a mixture of packages compiled with varying versions of GLIBC.
Of course, with Debian, it amounts to "Oops - you don't have the GLIBC that I need. I'll add the right library to the list of packages that I'll be downloading for you."
By the way, dselect will, after it finishes downloading all the packages you needed into /var/cache/apt/archive , and installing them, ask you nicely, Do you want to erase the installed.deb files? to which the answer, for the average user, is probably always going to be Yes.
The right thing to do is to create front ends to dpkg and rpm.
It would be a downright awful idea to create an InstallShield Package Installer tool that forcibly requires user intervention. The folks at TiVO have taken an interesting approach; they offer to do a system upgrade every day and this requires no user intervention.
After all, the only thing easier than moving from CLI-based utilities to X-based utilities is to move to cron-based utilities that don't require that the user do anything at all.
The Debian folk have been working on improved front ends for quite some time, and prototypes for the dselect replacement pop up occasionally.
Similar is true for RPM; if you actually look, you'll find tools that are actively being worked on.
But I'd still argue that if, as you say,
The average computer user simply can't handle the command line, let alone compiling things or even extracting files from a tarball.
then the right answer is not to throw a GUI in front of it, it is rather to schedule a process that automatically grabs packages and installs them without there even being a GUI involved.
Slashdot Mirror
Supposing you mistag something in /etc/sendmail.xml , this could mean that Sendmail could no longer run.
There is a benefit that XML buys you, which is that you could build a generic configuration tool that doesn't intimately know any individual DTD, but which does know how to:
- Turn an XML document into a browsable tree on screen, and
- Accept modifications and write them out as validated XML (sans DTD)
But as you say, there would need to be many DTDs, which really just shoves the problems around a bit. It doesn't clean them up; it's more like using a dirty rag to clean a window, so that the dirt is getting redistributed to different parts of the window...The big problem would be in getting all the applications to change to use an XML parser.
I don't think it's likely to be ready for another year at best, and I think they need to step back and consider having a language formally made to represent tax rules rather than informally layering javascript and GLADE together in an XML file, but it's "under way."
Now that that is working fairly well, it starts to make sense to try to automate the creation of transactions, which includes:
Surprisingly, a critical issue with all three of these things is that of creating a suitable user interface.
In particular, with QIF and OFX input, there needs to be a user interface to control the translation from the data file's set of accounts to those that the user has set up in GnuCash.
I've written a pretty slick QIF parser; deployment of that has been blocked due to the need to have a front end to let the user decide which account to use in GnuCash. The same will be true for OFX files.
Note that some financial institutions generate OFX/QIF files that omit entirely the account, thereby requiring that you manually set up a destination account for the expense.
The development of GnuCash has been pretty regular, with some minor improvements taking place almost every day.
(Aside: I've got a bunch of changes to the reporting code that I'm testing now, and preparing to commit...)
It is likely that there will continue to be lots of minor releases, in much the same way that Linux has a new experimental release every week.
Frankly, I'm going to have to look back at the book to verify just where it is that it makes a sufficiently clear reference to Labrador to indicate that that is where it was placed...
Mind you, in it being written in 1955, Labrador had only been a part of Canada for six years, which means that it was too early for there to be any long term understanding of the notion of the region being part of Canada.
I'm not sure if an understanding of the actual culture of Newfoundland is, or is not, relevant to the story. Rather interesting if it is, as that's a rather obscure place, not terribly well-known, in many ways.
I think I'd read the story in rather different light if that be the case...
Where Real Men use vi to manually edit all the text files.
Where Modern Administrators point'n'drool their way through menus, searching for the configuration.
These are the commonly-perceived stereotypes, and, too often, represent peoples' attitudes, whether pro or con.
Unfortunately, by focusing on this particular dichotomy, people miss the mark, in that neither approach is particularly manageable. Moreover, by thinking they are the only alternatives, people miss the directions for true improvement.
- There's a place for having a centralized "registry" of access methods to access configuration information.
- Automation means You don't have to touch it again.
The correct fork to take is not to have 'friendlier versions of Linuxconf;' it is to have more tools like cfengine that represent more permanent solutions to configuration problems.It may be true that:
That doesn't mean that there wouldn't be value to building up a hierarchical "tree" that knows how to look up configuration information. The data can sit where it is now; the "tree" is useful for providng the administrator with a comprehensive way of getting at it.
Configuration work that the system does for you is the true labour savings; if the system cleans up after itself, and I don't have to do it, that is an automated system.
I'm glad to drop in an extra cfengine rule into /etc/cfengine and have the system do more work for me.
My suspicion is that IA-64 is going to have less impact on server configuration than one might expect, certainly less than the "Gartner cheerleading" used to indicate. After all, on servers, the important thing is not the CPU, but rather the combination of I/O subsystems, whether:
I could readily see "workstations" getting "killed off," what with PC's getting more and more powerful.
But the big deal for anything higher-end is the buses, and not merely the CPUs, which makes the bluster about CPUs pretty moot...
If the intent is for the only way to create GNOME application documents is via Bonobo automation, this BADLY breaks the UNIX principle of "Data, not Behaviour."
It is a reasonable idea to expect to be able to use text processing tools to generate documents. The notion that the "correct way" is "through bonobo automation" is roughly equivalent to the notion that we need to embed GNOME closure generators into every development tool, and that seems to me to be a desparately terrible idea.
If we're embedding 40MB videos into spreadsheets, I suppose it may be appropriate to enforce a "it's gonna be binary" rule, but it seems to me that that restricts GNOME to being a useful framework for managing complex porn web sites.
I don't think it is possible to overestimate the importance of the issue of data formats, at least not in the context of looking at word processors. If you want your document to be usable five years from now, it is ludicrously unacceptable to use whatever "document embedding" scheme MSFT uses this year.
The format has several notable effects:
- If it is "text-based," this may mean that you can email documents without worrying about special encodings.
- If it is text-based, this means that you may be able to modify the document using other tools than the word processor.
- If the format is based on some normative standard, this means that you can expect to be able to create documents using external tools.
I believe that KWord uses XML as its native data format, with a disclosed DTD. ApplixWare uses a tagged text format that looks a fair bit like SGML. AbiWord uses XML. StarOffice and WordPerfect use not-particularly-readable binary formats; WordPerfect's formats have historically been disclosed, but writing programs to generate it is a NonTrivial Task, whereas StarOffice's format appears to be a big unknown.Note that the spreadsheet XESS promotes this as a "selling feature."
(Others may say, uuencode is your friend. )
That's useful for debugging, solving problems, modifying the document when you move it over to a laptop that doesn't have the word processor installed and have to use vi.
For instance, if the program uses an XML-based format, it becomes reasonable to write a Perl, Python, or Scheme.
Example-of-the-week: I've been working on generating spreadsheet files for use with Gnumeric. The plan is to write Scheme scripts that pull data out of GnuCash, and generate reports. I haven't gotten to the "extraction" part, but have generated some pretty slick demo spreadsheets.
Someone in a law (or para-law) office might want to create a document template scheme where they run a K001 GUIed program that asks for names and sundry fields, and then generates legal documents. Given a sufficiently "open" format, that's pretty practical.
Using formats where there's at least some visible ASCII text seems to me to be the only reasonable way to go. I'll remain a bit skeptical of XML; just 'cause it's buzzword-compliant doesn't mean that the DTD will be in use in the long term...
By creating their own distribution, this is decidedly fragmentary, and insane.
I wish that I were incredulous at this; after seeing what LinuxOne has to offer, I'm not...
Remember that those O'Reilly books have considerable structure in common; they are all of similar form factors, which means that you can readily drop them onto a single shelf and expect them to fit nicely. If they had varying shapes, sizes, and bindings, this wouldn't work out nearly so well, as they'd need to (for instance) come up with a customized kind of book binding for each book.
If your docs are written using LaTeX, they have no way of automatically integrating it into a single comprehensive document.
If your docs are written using whichever DTD they favor today, it is a relatively straightforward task to integrate this together.
Thus, there are actually two classes of documents:
The non-existent security of MS-DOS caused an utter lack of security to proliferate around the world.
Whether black helicopters were involved or not is a whole other question...
A cool approach might be to build something like a WikiWikiClone that can collect up improvements made online, and turn them into linear presentations. I suggest this because the Wiki mechanism is very much oriented towards the approach of improve a page here or there a bit.
Quite seriously, if it's to be useful, it should hardly be characterized as "Just A File Manager."
Consider:
And that is where it starts to get interesting.
The thing about Linux, as it is today, that is kind of scary to people that need to think of computers as "appliances," is that it doesn't have a unified way of treating things as "documents."
A "document manager" that lets you make sure that stuff doesn't get lost due to it falling into a directory that you didn't know you needed to look at is going to be the killer app of the next decade.
I agree that Explorer is quite horrifying; I look at it as the "machine gun" of computing.
People tend to be horrified at this analogy, but its ability to accidentally destroy files quite analagous to the notion of walking around the office carrying an M-60 with finger on trigger. You slip up a bit, and "Oops! I accidentally shot up 15 cubicles and killed 8 coworkers."
If these guys can do some good HCI work, perhaps taking some of the better concepts from OS/2 and NeXTstep, and actually create a usable and powerful "document manager," this seems to me to be quite a worthy task.
This would doubtless be crucial for Volumes 4-6 of TAOCP, and the availability of real hardware for this would strike fear into the hearts of graduate students in computer science the whole world over...
There's no particular reason for this to represent a "duplication of effort," at least from the standpoint of the GNOME project. After all, they needed a better file manager. GMC has not been all that satisfactory.
What their application amounts to is one that unifies files and remote objects (via HTTP/FTP) together, and lets methods be invoked on them.
By using the Bonobo interface, they can pull in all sorts of GNOME objects. That's certainly not duplication.
It may be duplicative if you're a developer working on the Kconq file manager for KDE that has similar scope; it's not duplicative within the context of GNOME.
I'd say that this is the most important component to have some serious HCI people take a look at; that's the only hope of it being usable to the "Bubba" users. (No offense intended to other than Presidents of the United States :-) ...)
It's important that this get HCI attention in that if it succeeds, Nautilus would become the front-end for a whole lot of users to get at "system stuff."
Unfortunately for the BSD folk, and fortunately for those that have appreciated the outgrowth of Linux, technical considerations were not the only issue. There was this "minor" matter of the USL lawsuit.
As it turns out, with Linux, as well as with Firewire, technology is not the only issue; licensing constraints figure prominently. Extremely prominently.
People were scared off of *BSD, whether rightly or wrongly, by the fear of the effects of the lawsuit.
And it appears that Apple is doing a good number on the adoption of Firewire, perhaps, simply, by their existence. After all, after the discontinuance of Newton, and the fun of "What variation of NeXTstep will we stop selling today?" it appears unwise to trust too much to the good graces of Apple.
After all, with only 4 wires (or maybe 8, with grounds and the likes) instead of ATA's on-the-order-of-50, you can have a good half dozen "S-ATA" interfaces in the same amount of room.
And that means that rather than having a dozen devices sharing the bandwidth of one bus, you can have them be pretty independent. Rather than 100MB/s, that gives us 600 MB/s.
I don't realistically expect this to happen, but it would be pretty slick if it did.
Looking forward in the "ten year perspective," a natural development would be to move towards greater asynchronicity at the bus level, and what looks more asynchronous:
- Having one 72 pin parallel bus for "super-fast SCSI" that grabs some DMA? or
- Having 36 serial buses, one-per-drive, with two wires apiece, each buffering requests both to the disk as well as to DMA?
I frankly think the latter is a slicker idea, in the long run...Then you start having to search for the #include files that the program expected to find. Which establishes that you have to install (say) a new version of ncurses or some such thing.
It may not be a full-scale porting effort, but it does require, if you want any hope of troubleshooting, being reasonably comfortable with the tool set used for C development.
Obviously you can "overcommit."
What could we propose as an alternative?
If you decide to install Balsa, which pulls in big chunks of GNOME, that may be a bit distressing. It's hardly hidden. And if you actually want to install Balsa, you've little choice in the matter.
You can either say,
- Oops. I guess I didn't want to install all that much stuff
- Pretty big, but I guess I'll have to live with that.
There's no "Oh well, I'll install bits of it that won't work" (at least not without some explicit effort!)and back out, or
Remember that in the in the "Windows World" it also wouldn't be a 300k email package. It would be a 20MB email package that includes every library that could conceivably be necessary.
And you'd have to worry that the email client might come with some older DLLs that will overwrite ones you're using for something else, thereby toasting other applications on your system.
I don't see any realistic way around the consideration that Systems Integration Is Messy.
Whether we talk about DPKG, RPM, or BSD Ports, it's a given that the process of getting packages integrated into a particular distribution is a somewhat messy process. In all cases, there is some form of patch that gets applied to indicate precisely how they are to get installed.
It is getting increasingly common for Debian packagers ( e.g. - the human being that builds the patches required to integrate the package in with Debian) to have some degree of involvement with the "upstream" production of the original, authoritative source code tree.
When this happens, it is not unusual for there to be a ./debian subdirectory containing the "Debian-relevant" patches, and I've also seen ./SPECS directories with RPM .spec files. In cooperative development efforts, this is the point at which important cooperation takes place, as this means that there is some thought to systems integration in the original source code tree, which will make the job easier for everyone else.
It's not likely that the level of effort will actually diminish to zero, but if it becomes largely automated, and the human effort can be widely distributed, that makes the task not too herculean.
Of course, with Debian, it amounts to "Oops - you don't have the GLIBC that I need. I'll add the right library to the list of packages that I'll be downloading for you."
By the way, dselect will, after it finishes downloading all the packages you needed into /var/cache/apt/archive , and installing them, ask you nicely, Do you want to erase the installed .deb files? to which the answer, for the average user, is probably always going to be Yes.
It would be a downright awful idea to create an InstallShield Package Installer tool that forcibly requires user intervention. The folks at TiVO have taken an interesting approach; they offer to do a system upgrade every day and this requires no user intervention.
After all, the only thing easier than moving from CLI-based utilities to X-based utilities is to move to cron-based utilities that don't require that the user do anything at all.
The Debian folk have been working on improved front ends for quite some time, and prototypes for the dselect replacement pop up occasionally.
Similar is true for RPM; if you actually look, you'll find tools that are actively being worked on.
But I'd still argue that if, as you say,
then the right answer is not to throw a GUI in front of it, it is rather to schedule a process that automatically grabs packages and installs them without there even being a GUI involved.