Slashdot Mirror

If what you're really doing are transactions, this is fine. Build up sets of updates that are themselves transactions.

Keep in mind that the web server is not the back office; the data should get pushed over to the "heavy duty SQL box" when it comes time to do the accounting for either money or for inventory.

Consider the MySQL database to be an "embedded" database system, intended to support just the web application. Make that robust, and leave the "heavy production environment" stuff for the other server.

After all, you don't want customers outside to be directly hitting your master database, do you? I don't spell that "security."

• Were you planning to support one language? Or multiple languages?

  If the only language is C++, then your project will be rejected because some people prefer to use C, Objective C, Scheme, Perl, Python, and Eiffel.

  If you plan to use many languages, then you probably have ONE choice for a structure on which to build this, namely ILU (Inter Language Unification). Unfortunately, that leaves you with a set of data structures that are to some extent a "lowest common denominator" of the things supported by all of the languages.

• Is what you want supported already by CPAN or by www.python.org ?
• By the way, if you wanted the facility to be network-distributable, then you definitely want to use ILU or some other CORBA variation.

In effect, the only choice for the sort of "componentizing" that you're describing is some variation on CORBA. You probably need to get a copy of the Henning/Vinoski book on CORBA, and to start writing chunks of IDL to represent all the sorts of interfaces that you want to be able to have "published."

Unfortunately, there's still an impedance problem, as:

• There are wide variations in performance between ORBs as well as between components that can communicate "real directly" via memory as they're running in the same process as compared to components that may communicate hundreds of times more slowly because they reside on separate hosts.
• Components may be implemented in ways that vary considerably, and which may require significant configuration effort to get their service running.

I will not be so excited about any hardware support that winds up being "Corel Only."

(Of course, there's some components of Buy Canadian! in both Corel and StormLinux, at which point may enter certain aspects of nationalistic fervor :-) )

Actually, to my knowledge there are a bunch of open-source accounting systems for Linux/*nix. Some of them can import Quicken files. Don't know about GnuCash specifically, though. There's a general summary here for those interested.

Unfortunately, you lose some abilities:

• The ability to change a script "on the fly" whilst debugging, and have the change automagically deployed. With C++, you have to make and then go through whatever installation process is required to deploy the change.
• Scripting languages like Perl and Python provide built-in operators for doing all sorts of text manipulations.

  With web applications, what you're largely manipulating is text, which means that having the language oriented to that is extremely valuable. Furthermore, since there are powerful, well-optimized operators built-in to these languages, the interpreter disadvantage is significantly diminished.

Unfortunately, you lose some abilities:

• The ability to change a script "on the fly" whilst debugging, and have the change automagically deployed. With C++, you have to make and then go through whatever installation process is required to deploy the change.
• Scripting languages like Perl and Python provide built-in operators for doing all sorts of text manipulations.

  With web applications, what you're largely manipulating is text, which means that having the language oriented to that is extremely valuable. Furthermore, since there are powerful, well-optimized operators built-in to these languages, the interpreter disadvantage is significantly diminished.

Some are rather particular to formats used in mainframe applications, but some sure look like they'd represent common practice, things any programmer worth his salary should be able to recreate...

• US5758336: Date format and date conversion procedure using a packed binary format
• US5668989: Two-digit hybrid radix year numbers for year 2000 and beyond
• US5630118: System and method for modifying and operating a computer system to perform date operations on date fields spanning centuries
• US5761668: Method and apparatus for converting computer software and databases for the year 2000
• US5644762: Method and apparatus for recording and reading date data having coexisting formats
• US5737735: Method and apparatus for recording and reading date data having coexisting formats
• US5600836: System and method for processing date-dependent information which spans one or two centuries

• Some have suggested that RHAT should dump money onto Debian.

  This begs the question of whether the Debian folk would find this to be of any value... For the most part, Debian doesn't consume money. If they suddenly had $8M to throw around, this would enter "monied politics" that could have pretty shattering effects.

  And, in any case, why would anyone consider it appropriate for RHAT to need to sponsor a project that is quite directly competitive?

• It would be quite appropriate for RHAT to bounce some money to the FSF.

  The FSF actually has offices, budget, and some experience in hiring programming staff. Which makes it a more sensible idea, in some ways, to throw "ludicrous amounts of money" at the FSF than it would have been for Debian.

  But even still, $8M is on the order of 30 times the recent amounts of annual funding of the FSF.

  Again, dumping $8M on the FSF would be not unlike pouring a truckload of chocolate syrup onto an ice cream sundae. Interesting to see, but likely rather messy and even wasteful.

• Similar could be said for big "dumps" onto XFree86, LaTeX3, Linux International, PostgreSQL and other nonprofit orgs.

I'd rather see RHAT hire a bunch of people and build software that is released under free licenses, with CVS archives to allow external contributions as well. The costs will be as "tasty" a tax writeoff as anything else; the benefits include that if they regard the results as valuable, perhaps others will find them similarly valuable.

Strange, how that sounds a whole lot like RHAD Labs...

In some respects, I'm just as glad that I don't have a vote, as the choice between the options of "I claim I didn't inhale!", "I will not answer whether or not I used coke," and "I'll bodyslam my honorable opponents!" doesn't admit a clearly reasonable choice.

Based on that and on local "fun and games," I'm not particularly surprised that the voter turnout for Dallas' last election was, for a city of nearly a million people, what I used to consider poor turnouts for elections of school board trustees back in Ottawa...

The problem isn't merely of ignorance; apathy can arise when it's not clear that the vote cast will be of any useful value...

In some respects, I'm just as glad that I don't have a vote, as the choice between the options of "I claim I didn't inhale!", "I will not answer whether or not I used coke," and "I'll bodyslam my honorable opponents!" doesn't admit a clearly reasonable choice.

Based on that and on local "fun and games," I'm not particularly surprised that the voter turnout for Dallas' last election was, for a city of nearly a million people, what I used to consider poor turnouts for elections of school board trustees back in Ottawa...

The problem isn't merely of ignorance; apathy can arise when it's not clear that the vote cast will be of any useful value...

As far as I'm concerned (and I have a sizable essay to this argument ), the more organizations trying to do cool stuff the better.

It would be nice to see some funds get "thrown" at organizations like the FSF, SPI, XFree86, and so forth. Unfortunately, "throwing" money at them doesn't forcibly accomplish useful things. It is a joke that "Mathematicians are nature's way of turning coffee into theorems."

Frankly, I'd rather see RHAT take the simpler tack of hiring more programmers to write software that gets GPLed. Note that that happens to be just as much of a "tax break" as a contribution to a charitable organization.

The merit of having a separate organization may be the goodwill that results from having what may appear to be a bit more independent organization.

Alternatively, they may (and this is a bit of a reach, I'll admit) be founding an organization so that they can encourage others to contribute to it.

Consider: I'm not in the market for a "fully supported $80 RH Linux boxed set." But I might be game to help contribute to development efforts. If RHAT spins some/all of the development effort out to a separate organization, that may encourage people like me to contribute to that.

This could be a step towards transforming RHAT, the commercial organization, into the service organization that represents where IPO documentation has indicated that their revenues were expected to come from in the long term.

They roll development into a "charitable" organization, which:

• Makes them look good,
• Separates it from the profit-oriented activities,
• Perhaps pulls in some of its own revenue stream.

Perhaps I'm being dramatically overoptimistic here; it's still possible that this be quite a good thing.

But the only way there will be a "death of MSFT" is via the Death of a Million Paper Cuts that involve not a single "killing" blow, but rather a whole array of tiny, relatively independent injuries that add up.

Other comments have suggested that a more logical step would be to push for Linux pre-installed on (say) Seagate hard drives.

Put all of these things together:

• Some copies getting deployed via bundling with motherboards
• Some copies getting deployed via bundling with disk drives
• Some copies getting deployed via being preinstalled by one of the fifty-odd Linux VARS

And the point is not to "beat Microsoft;" that would merely be a convenient sideeffect of doing useful things with Linux.

The key to making EROS useful to people running Linux would be to build a "GNU System" atop EROS, parallelling building a "GNU System" atop the Linux kernel.

If we stuck with this attitude from the beginning, we'd still be using JCL and COBOL for everything. It's a new system, how about new tools?

And if we want to accomplish anything with the new system any time soon, what are we to do?

UNIX has been remarkably persistent over the year as a useful environment for prototyping.

If there's nothing in common between EROS and Linux, and, in particular, if there are practically no tools available for EROS, there's going to be little merit to making a leap over to EROS.

The point here is that there are two particularly relevant outcomes:

• EROS starts from scratch, having no tools with which users would already have any familiarity.

  That makes for a challenging transition, and, for a would-be newcomer, they may say

  This EROS system isn't even as functional as Linux. Why should I consider using it?

• EROS provides some familiar UNIX tools, thus gaining a rich development environment, which makes it a more attractive transition.

Since EROS is different, it is obviously appropriate to add new tools in support of that. That is not synonymous with the contention that

We ought to throw away absolutely everything that we've found useful up until now.

The key to making EROS useful to people running Linux would be to build a "GNU System" atop EROS, parallelling building a "GNU System" atop the Linux kernel.

(Note that I usually call "systems based on the Linux kernel" by the moniker Linux; the use of the RMS term happens to be usefully descriptive here; I'm not trying to do any politically-motivated Newsspeak here.)

I would tend to think that the Debian folks would be the most prepared to create an overall system atop EROS, as they have both

• A set of automated tools for constructing and (to some extent) validating sets of packages, and
• Some experience trying to fit Debian to a non-Linux kernel, namely Hurd

The major alternative that, based on the deployment of predecessor systems like KeyKOS, is likely to take place quite a bit, is that EROS might instead be largely used to construct "somewhat embedded systems" rather than the general purpose system that comes from installing the typical Linux distribution.

This might include:

• Building a really secure little web server package
• Building a really secure little file server package
• Building a really secure network firewall system
• Building a really secure Network Computer
• Building a secure and fast database server

  Which would parallel what Oracle has been working on with the "Raw Iron" Oracle 8i Appliance

I'd kind of like to see both approaches, as that is the most likely way for EROS to become more widely used.

The key to making EROS useful to people running Linux would be to build a "GNU System" atop EROS, parallelling building a "GNU System" atop the Linux kernel.

(Note that I usually call "systems based on the Linux kernel" by the moniker Linux; the use of the RMS term happens to be usefully descriptive here; I'm not trying to do any politically-motivated Newsspeak here.)

I would tend to think that the Debian folks would be the most prepared to create an overall system atop EROS, as they have both

• A set of automated tools for constructing and (to some extent) validating sets of packages, and
• Some experience trying to fit Debian to a non-Linux kernel, namely Hurd

The major alternative that, based on the deployment of predecessor systems like KeyKOS, is likely to take place quite a bit, is that EROS might instead be largely used to construct "somewhat embedded systems" rather than the general purpose system that comes from installing the typical Linux distribution.

This might include:

• Building a really secure little web server package
• Building a really secure little file server package
• Building a really secure network firewall system
• Building a really secure Network Computer
• Building a secure and fast database server

  Which would parallel what Oracle has been working on with the "Raw Iron" Oracle 8i Appliance

I'd kind of like to see both approaches, as that is the most likely way for EROS to become more widely used.

The key to making EROS useful to people running Linux would be to build a "GNU System" atop EROS, parallelling building a "GNU System" atop the Linux kernel.

(Note that I usually call "systems based on the Linux kernel" by the moniker Linux; the use of the RMS term happens to be usefully descriptive here; I'm not trying to do any politically-motivated Newsspeak here.)

I would tend to think that the Debian folks would be the most prepared to create an overall system atop EROS, as they have both

• A set of automated tools for constructing and (to some extent) validating sets of packages, and
• Some experience trying to fit Debian to a non-Linux kernel, namely Hurd

The major alternative that, based on the deployment of predecessor systems like KeyKOS, is likely to take place quite a bit, is that EROS might instead be largely used to construct "somewhat embedded systems" rather than the general purpose system that comes from installing the typical Linux distribution.

This might include:

• Building a really secure little web server package
• Building a really secure little file server package
• Building a really secure network firewall system
• Building a really secure Network Computer
• Building a secure and fast database server

  Which would parallel what Oracle has been working on with the "Raw Iron" Oracle 8i Appliance

I'd kind of like to see both approaches, as that is the most likely way for EROS to become more widely used.

Much of this has been because everyone was planning to build StrongARM-based systems where they knew the CPU cost only $25, failing to realize that the only way to get costs down was to have mass production of StrongARM motherboards and other components.

Net result: They hadn't yet generated quantities of product, so price wasn't down to an economical level to allow it to be cheap enough for anyone to even consider.

The sort of model that they need to follow is similar to that of the Nintendo 64/Sony PlayStation game systems; those units are getting sold these days for around $100-$150, and probably are sold at around cost. Several years ago, there was an April Fools Article on Linux on Nintendo 64; I've had a more serious assessment of this for a couple years now.

Down to details...

Way back when, everyone thought that they should be using "cheaper" StrongARM (or perhaps MIPS or PPC) chips that were greatly cheaper than the Intel stuff. The fact that you're left custom-building motherboards was the "kiss of death" to cheapness.

Now that prices of IA-32 chips have fallen through the floor, an Intel Celeron or AMD K6 may be economical enough.

The big deal is to have a compact IA-32 motherboard with integrated video, perhaps sound, and integrated Ethernet, along with some FlashRAM in lieu of a hard drive.

If there's a Taiwanese vendor selling such motherboards for $50 in quantity, add in $40 for CPUs, $15 for a plastic case, $40 for a stick of RAM, and $5 for power supply, and you've got a $150 internal cost.

That only leaves $50 for the costs of pushing the box through retail channels, which seems low. Of course, as with Nintendo 64 and Sony Playstation, the real money comes in selling software, and it will certainly be in Ellison's interests to have both service and software offerings for these boxes so as to extract more than $200 from the average user of them...

• Pentium optimization
• Trying to support C++
• FORTRAN
• Pascal
• Ada
• Special forms of optimizations (IBM Haifa stuff, for instance)

The net result of the forks were that you could have a compiler that covers one purpose, but not necessarily more than one.

I do support of some R/3 code where our local group has "forked" from the standard stuff SAP AG provides; it is a bear of a job to just handle the parallel changes when we do minor "Legal Change Patch" upgrades. We've got a sizable project team in support of a major version number upgrade; the stuff that we have forked will represent a big chunk of the grief that results in that year long project.

I would consider a substantial fork of the Linux kernel to be a significantly Bad Thing.

Note that if it forks, the Turbo version may have a hard time supporting code written for the non-Turbo version. Major things that are likely forthcoming include:

• New filesystem support, including LVMs, ext3, Reiserfs, SGI's XFS
• New devices such as network cards, SCSI host adaptors, USB devices
• Further support for 64 bit architectures, and support for 64 bit structures on 32 bit architectures ( e.g. - solving such issues as the 2038 Problem and the 2GB File Size Limit Problem and the 2GB Process Size Limit and such)

Coming up with an alternative to Lotus Notes seems to be one of the classic "failed projects;" several attempts have come and gone where groups have brainstormed and not been able to come up with a clear definition of something they could actually implement.

Several are listed at Text Management Projects for Linux, including Gather (aka PINN, aka Sumatra, aka Mediator), Yoga, Citadel, Casbah. Zope is probably somewhat comparable. Some of these are downright failed; others are merely somewhat late.

The problem is that Lotus Notes can be looked at in several ways:

• As a glorified email/news messaging system, which knows how to replicate messages from server to server, and filter using ACLs and strong crypto.
• As a database application platform integrating a DB engine and scripting tools.
• As a distributed replicating non-relational database management system.
• As a distributed document management system.

These are all useful perspectives; unfortunately people see it different ways, and when you put together enough people to have a project team, there are enough perspectives to make the project definition so vague as to be a non-starter.

Coming up with an alternative to Lotus Notes seems to be one of the classic "failed projects;" several attempts have come and gone where groups have brainstormed and not been able to come up with a clear definition of something they could actually implement.

Several are listed at Text Management Projects for Linux, including Gather (aka PINN, aka Sumatra, aka Mediator), Yoga, Citadel, Casbah. Zope is probably somewhat comparable. Some of these are downright failed; others are merely somewhat late.

The problem is that Lotus Notes can be looked at in several ways:

• As a glorified email/news messaging system, which knows how to replicate messages from server to server, and filter using ACLs and strong crypto.
• As a database application platform integrating a DB engine and scripting tools.
• As a distributed replicating non-relational database management system.
• As a distributed document management system.

These are all useful perspectives; unfortunately people see it different ways, and when you put together enough people to have a project team, there are enough perspectives to make the project definition so vague as to be a non-starter.

• Java

  There seems to have been something of a "trainwreck" with respect to Java. There are lots of "nearly done" Java environments out there, including Kaffe, GCJ, Jikes, "Blackdown," and likely others.

  Unfortunately, none are truly useful without some combination of classes (ala GNU Classpath) and some combination of AWT/Swing. And that has been rather less rapidly forthcoming in the "reasonably free form" that is necessary in order for it to be ubiquitous enough for people to really use it to deploy applications, or to use it as a layer on which to build further infrastructure like EJB.

  Is anybody near to deploying a complete "libre" Java for Linux?

• System Config Tools

  There's Linuxconf. There's COAS. There's cfengine. And Ganymede (tho it needs Java; see above...) and bunches of other system config tools one one degree of incompleteness or another.

  Big, expensive things like UniCentre are also getting ported, although they're not likely of great interest on the home front.

  Is there any intent to try to have some useful protocols to allow intercommunications of some of these systems, or to perhaps pick an existing one rather than recreating the wheel?

• Testing/Standards

  There has been some lipservice about Linux Standard Base (LSB), but it is not evident that anyone has either deployed substantially changed systems as a result of attempting to conform to some common guidelines, nor to actually provide ways of conforming systems to standards.

  There are lots of tools out there to run systems through automated test suites; that is apparently one of the major tasks of one ACLs for Linux project. In other contexts, we find ANSI Common LISP Conformance Tests. The folks at Cygnus run EGCS through testing, and provide EGCS Test Suite Results. Greg is being used to validate that GnuStep conforms to its documentation.

  ... And every "dot zero" release of Red Hat Linux fills many with fear as it tends to at least appear undertested.

  And then there's the Extreme Programming approach (particularly associated with Smalltalk) where one of the core requirements is of Continuous Integration Tests that are integrated in with the development process.

  But it is, often enough, not clear that people are depending in much more than merely the notion that Because it's Open Source, naturally bags of people will want to spend their weekends testing my code.

  We badly need to have some regression tests so that some testing takes place as distributions are constructed. Debian does some of this with dpkg-related tools; it is highly unfortunate that similar tools have not cropped up around RPM.

  Question: What are you doing to help contribute to the public body of test suite code?

• Making copies "is piracy."
• Using a copy in a jurisdiction in which it has not been licensed to be used "is piracy."

The consideration that using crypto, and patented crypto, at that, permits constructing protocols similar to Circuit City's (now cancelled) DIVX scheme is gravy...

Of course, I stand more in the pedantic camp that prefer to use words in the ways they were designed. Thomas Bushnell wrote it well:

The word ``piracy'' refers to seizing ships on the high seas, where normal social mechanisms of common defense are unavailable, and killing or kidnapping the sailors on board, and then stealing the ships and the goods they carry.

Piracy is an act a fair bit worse than robbing banks - more is stolen and many more people die.

Incurring civil penalties for copying software is nowhere near as bad as all that, and using the word ``piracy'' attempts to stir people up into a frenzy of horror.

This, I think, is a bad thing to do

In short, it seems to me that the SPA has "hijacked" (hee, hee) the use of the word piracy in much the same way that the term hacker gets used and abused in the media.

I have no problem agreeing that there will be a point in time at which it will prove necessary to start coding; the point is that there are portions of the system where it is downright invaluable to have purely declarative definitions, which means that you've got a set of code on which you can unleash analysis tools that don't need to worry about the Turing-completeness of a full-scale language like Perl, PL/SQL, or Java.

It would be, for instance, a very interesting idea to compose ER diagrams using a diagramming tool like Dia. Dia generates output in the form of XML.

The really cool next step would be to take that XML and use it to generate the DDL code to generate the relevant tables, so that the diagrams represent not only instructive diagrams for communicating information about the design, but actually the code to define the declarative parts of the system.

(Note: ERWIN has the ability to do this sort of thing, permitting one to both generate table definition code from the diagram as well as to generate a diagram based on SQL DDL code...)

The main place where differences between Linux distributions are persistent are with regard to two things:

1. 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.

2. 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.

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?

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?

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...

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.

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.

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.

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.

However. It is not all fine and dandy.

The "configuration problem" has not one issue, but several:

• The proliferation of "little languages" as formats.

  XML represents Yet Another Format; it is of value if it pushes out some of the existing formats. If it merely augments the population with another, there is no win here.

  Result: Ambiguous. XML might provide value.

• The Serialization/Locking Problem.

  The issue here is that you need to ensure that the configuration is written out correctly.

  This may require writing out the new config to a new file, validating that it is readable and correct. (Oops, made a mistake updating /etc/inet.d. Now the system won't reboot...)

  There is merit to having a "database form" ala IronDoc where the physical representation is a database system, which provides a somewhat different persistence model than the typical text file.

  (Before people start proposing that I be shot, I tend to favor the notion of, if using a binary format, synchronizing it carefully with a text format.)

  The merit of a "databased" scheme, which should provide a separate database for each facility, is that updates can be implemented "instantly" without needing to rewrite a whole file, and without a need to parse the file. Note that even in a situation where XML is used as an interchange format, there is still merit to storing the "tree" in database form. David McCusker, author of IronDoc and architect of the (regrettably failed) "Bento" database system that was part of OpenDoc, suggests this very use for IronDoc.

  For those that feel religious about using text files, a system like libPropList still has merit over the "let's do something with XML" idea since it has, already debugged, the locking, parsing, and config-file-rewriting code that let's use XML, it's k001 doesn't inherently provide.

  In short, deciding to use XML merely establishes a format; it does not resolve that:

  • Updates are managed well
  • The output from a particular program that manipulates a config file actually produces valid XML
• Federating Configuration.

  Michael Stonebraker (of fame with such developments as Ingres and Postgres) has most recently founded a company called Cohera based on the Mariposa Distributed Database Management System. This tool allows many databases to work together to process queries.

  The "obvious" implication of this with this thread is that a valuable thing to be able to do is to join together many "databases" that are configuration repositories, and provide a central way of getting at the data.

  The critical thing that is necessary is for configuration repositories to provide some sort of "metadata" so that they, in effect, publicize their existence.

  A "federation" tool like Linuxconf, Ganymede, or such, can then be used to join together the metadata and manage it all together.

  Unlike the situation with the infamous Windows Registry, this doesn't force all the configuration data into one fragile binary DB; it allows the data to stay wherever it was concluded that it should reside.

  The critical factor here is not that data files all have a common format; it is that there be some way of translating their data into a common format.

  XML has a lot to offer here in terms of providing a central "presentation" format. It could offer more if tools were available to make this a two-way street, where updates done to the central XML could be pushed back to the individual configuration data repositories.

  However. If someone writes some integration code to (say) connect Linuxconf to libPropList so that it could directly manipulate libPropList files, that would also represent a movement in the right direction.

Conclusion: XML may have value to offer in confederating config information.

That has to come along with a whole lot of coding effort to build robust configuration data repositories that may or may not use XML.

It is entirely possible that the "talk" could have been a corrupted understanding of this transfer.

I'm sure AMD is happy enough to see some extra business come their way that isn't solely predicated on head-to-head battle with Intel.

It would be rather neat if this resulted in there being a third-party source for PPC motherboards, as that is a Critical Resource.

It looks like the AMD involvement hasn't led to cheap Alpha motherboards, which means that it's not time to replace my Multia/UDB yet; probably the same for you, too...

This would doubtless do a good job of popping the ``Internet Bubble,'' and could result in an overall market bloodbatch as people re-examined the non-existent value of other enterprises that have seen bloated valuations due to peoples' miscomprehension of the use of "e-Business."

It would, however, be rather less fun for the principal participants, as it would be a downright fraud to issue an IPO to a thus-worthless company and then walk away with a bundle of dollars.

The above interpretation of matters also would not survive the scrutiny required by an IPO. See RHAT 424B1 Filing and S1.

I'm still biased towards the material I wrote way back when on Transmeta; it seems nearer accurate than anything publicized before or since...

The wastage of numbers via ineffective use of exchanges does indeed suggest another vector via which "name space" may vapor away. The only good news is that cell phones and pagers are likely to "pack in" more effectively as they are not forced into a tiny geographic zone as would be the case for a local exchange.

The merely makes the "crunch" happen quicker; as the numbers of phone numbers per person grow, the population of needed numbers is still growing pretty rapidly.

The issue is not, in this case, one where there is a sudden date when everything breaks (as with Y2K, but rather something more like a ``brown-out'' where it becomes increasingly difficult to manage systems, and where new subscribers cannot be admitted, which will hit some geographic areas before others...

It may result in businesses moving to ``economically depressed'' areas where there are exchanges with space free :-).

Thus, while it would be neat to have a whole lot of those "little applications," if it's Rather Difficult to write them, they may not be as little as you'd think/hope.

The document CORBA and You alludes to this somewhat indirectly, indicating that

Keep interface exposition at a high level. Not only does exposing low-level interfaces cause increased dependence upon the internal organization of a software system, but it also means you have to put more code into exporting your interfaces, introducing the risk for more bugs and increasing bloat.

The difference between an ``embedded processor'' and a ``general purpose processor'' is as much marketing as anything else

At one point, the StrongARM was being strongly promoted as a Network Computer (aka ``X-Terminal'') device. Note the announcement of 1997 of the Digital Network Appliance Design.

And note that it is the processor used in the Rebel/Sidewinder that Corel Computers used to hawk.

The point of all of this is that the CPU is clearly not so ``embedded'' that it would be inherently useless in a ``desktop'' role.

It ought to have been possible to build motherboards integrating a CPU, video chipset, and Ethernet that could retail for less than $150, and this could have brought us $300 computers a year or so ago, and provided slick little boxes to velcro to the sides of 17" monitors.

If I could have bought a StrongARM motherboard for $100, I probably would have built a machine by now.

But no motherboard leads to no systems. Note that exactly the same reasoning may be used with MIPS...

• The Ancient Past

  In the beginning, Berlin was a project started by some Assembly-Language "uberhackers" that really disliked X, who had the notion that they could somehow write a windowing system that would be so fast that it would somehow displace X.

  In that "distant past," there was much unfriendly flaming, and there were "dueling web pages" between myself and some Berlin folk. My page has since evolved into On the Thesis that X is Big/Bloated/Obsolete and Should Be Replaced, which is rather less "anti-Berlin" now.

  Acrimony arose over a generally "uncooperative" attitude; the designers were quite prepared to eschew CPU architecture portability, only to ever run on IA-32, quite prepared to eschew networking support, never to be able to display apps remotely, and quite prepared to ignore any and all existing GUI APIs, requiring that all-new apps be deployed.

  The original grouping of designers largely evaporated; they seemed to get the beginnings of a font renderer working, but apparently little else.

  I get the impression that there was some politicking along with the GGI Project that was involved in the "staff turnover;" 'tis not completely clear...

• Berlin: The New Generation

  A largely new generation of folks came along, bringing a somewhat more cooperative spirit, and an interest in being hugely "buzzword-compliant," between "being 3D-compliant" via OpenGL, network transparent via CORBA, and by the same token, as architecture independent as C++ and GGI get you, and language-independent (sort of) via UNICODE.

  I had a nice chat with Graydon Hoare last year in Atlanta; they hadn't gotten too far, but certainly had a more useful attitude.

  In particular, they are now not presenting the former, laughable, message that "X is Dead, And Berlin Is About To Replace It."

• My Take on Why They Haven't Progressed Quicker

  After about 3 years, you'd expect there to at least be a text editor or something available. At this point, they're fairly happy to now have some apps that can display widgets that show that there's some working code.

  I would suggest that they are still labouring under some significant handicaps as compared to some of the alternatives, and am skeptical that there is a good likelihood of success:

  • They can't attract effort to produce applications until they have a functioning environment, but can't get a functioning environment without considerably more effort.

    This is a vicious circle; it's hard to attract developers to a system that doesn't work yet, and other projects like GNOME and KDE, as they do function today are vastly more attractive, as well as being vastly less risky propositions.

    This effect is vastly magnified when you consider that commercial enterprises are investing considerable effort in X-based efforts.

    The high probability of failure completely discourages commercial investment of time/effort/money.

  • Unlike other projects that represent improvements alongside of X, Berlin depends on a whole lot of components getting developed. This magnifies risks further.

    The fact that the GGI project developed a library to allow GGI apps to run atop X means that at least that forcible dependency has been cut, but there's still just too many things that need to work for Berlin to work.

    Contrast this with GNUstep, which, it seems to me, has a strategy more likely to succeed.

  • GNUstep is based on an API that is known to be technically and economically viable, namely OPENSTEP.
  • GNUstep requires one "partially unavailable" component, namely the still-being-developed Display Ghostscript substrate.

    It is thus based on the use of a substrate that is feasibly run on X, but which, unlike Motif, doesn't force vast amounts of X dependancies onto programs, it would be conceivable for X to be replaced, eventually, by Display GhostScript Running On Something Else. (Similar is actually true for some of the major "X" GUI toolkits like Tk, GTK, Qt, and FLTK, which all can run on things other than X...)

Good News Even If The Big Project Fails

• There may be components that are of value.

  For instance, they may wind up producing a font rendering engine that could be useful elsewhere.

• The learning about how to use CORBA to build a graphical environment may help steer other projects towards good/feasible ideas, and away from infeasible directions.
• There may be some useful IDL definitions.
• Some of what appears valuable in Berlin is the recasting of Fresco ideas.

  It is arguable that the adoption of Motif (with sundry ugly implementationness as well as proprietariness) over Fresco is part of what has set back progress in X development for a goodly five or so years. (I'd argue that...)

• The Ancient Past

  In the beginning, Berlin was a project started by some Assembly-Language "uberhackers" that really disliked X, who had the notion that they could somehow write a windowing system that would be so fast that it would somehow displace X.

  In that "distant past," there was much unfriendly flaming, and there were "dueling web pages" between myself and some Berlin folk. My page has since evolved into On the Thesis that X is Big/Bloated/Obsolete and Should Be Replaced, which is rather less "anti-Berlin" now.

  Acrimony arose over a generally "uncooperative" attitude; the designers were quite prepared to eschew CPU architecture portability, only to ever run on IA-32, quite prepared to eschew networking support, never to be able to display apps remotely, and quite prepared to ignore any and all existing GUI APIs, requiring that all-new apps be deployed.

  The original grouping of designers largely evaporated; they seemed to get the beginnings of a font renderer working, but apparently little else.

  I get the impression that there was some politicking along with the GGI Project that was involved in the "staff turnover;" 'tis not completely clear...

• Berlin: The New Generation

  A largely new generation of folks came along, bringing a somewhat more cooperative spirit, and an interest in being hugely "buzzword-compliant," between "being 3D-compliant" via OpenGL, network transparent via CORBA, and by the same token, as architecture independent as C++ and GGI get you, and language-independent (sort of) via UNICODE.

  I had a nice chat with Graydon Hoare last year in Atlanta; they hadn't gotten too far, but certainly had a more useful attitude.

  In particular, they are now not presenting the former, laughable, message that "X is Dead, And Berlin Is About To Replace It."

• My Take on Why They Haven't Progressed Quicker

  After about 3 years, you'd expect there to at least be a text editor or something available. At this point, they're fairly happy to now have some apps that can display widgets that show that there's some working code.

  I would suggest that they are still labouring under some significant handicaps as compared to some of the alternatives, and am skeptical that there is a good likelihood of success:

  • They can't attract effort to produce applications until they have a functioning environment, but can't get a functioning environment without considerably more effort.

    This is a vicious circle; it's hard to attract developers to a system that doesn't work yet, and other projects like GNOME and KDE, as they do function today are vastly more attractive, as well as being vastly less risky propositions.

    This effect is vastly magnified when you consider that commercial enterprises are investing considerable effort in X-based efforts.

    The high probability of failure completely discourages commercial investment of time/effort/money.

  • Unlike other projects that represent improvements alongside of X, Berlin depends on a whole lot of components getting developed. This magnifies risks further.

    The fact that the GGI project developed a library to allow GGI apps to run atop X means that at least that forcible dependency has been cut, but there's still just too many things that need to work for Berlin to work.

    Contrast this with GNUstep, which, it seems to me, has a strategy more likely to succeed.

  • GNUstep is based on an API that is known to be technically and economically viable, namely OPENSTEP.
  • GNUstep requires one "partially unavailable" component, namely the still-being-developed Display Ghostscript substrate.

    It is thus based on the use of a substrate that is feasibly run on X, but which, unlike Motif, doesn't force vast amounts of X dependancies onto programs, it would be conceivable for X to be replaced, eventually, by Display GhostScript Running On Something Else. (Similar is actually true for some of the major "X" GUI toolkits like Tk, GTK, Qt, and FLTK, which all can run on things other than X...)

Good News Even If The Big Project Fails

• There may be components that are of value.

  For instance, they may wind up producing a font rendering engine that could be useful elsewhere.

• The learning about how to use CORBA to build a graphical environment may help steer other projects towards good/feasible ideas, and away from infeasible directions.
• There may be some useful IDL definitions.
• Some of what appears valuable in Berlin is the recasting of Fresco ideas.

  It is arguable that the adoption of Motif (with sundry ugly implementationness as well as proprietariness) over Fresco is part of what has set back progress in X development for a goodly five or so years. (I'd argue that...)

In particular, he notes that

When we write programs that "learn," it turns out that we do and they don't.

This goes along nicely with Douglas Hofstadter in his book ``Creative Analogies and Fluid Concepts'' where he outlines areas that are critical to language translation that happen to be real tough to even think about algorithms to process.

Hofstadter asks the question: ``What is the Chicago of Russia?'' which does not admit unambiguous results. I have parallelled this somewhat with the question What is the Moscow of New York? which has too many potentially valid answers for comfort.

I think "Star Trek Computing" is about as near as "Star Trek Economics," which is to say, no way soon.

There are certainly things to be learned; it's mostly humans that are doing the learning, not the computers...

In the interests of having some clue of what was going on, I did some research that is collected up at My Page On Transmeta.

I took a look at all the "open source" (in the sense of the term as used by the intelligence community) information that I could find via the Internet.

The author of the "Times Digital Edition" sent me email asking about how/why I collected that material...

All I have to say is that people have gotten material of vastly lower quality published in newsstand magazines...

(Ask yourself why Arthur C. Clarke named the movie "2001: A Space Odyssey" if you're not sure of this...)

People will hold "new millennium" parties, "new millennium riots," release "new millennium" models of both automobiles and soft drinks, because they were looking for an excuse to do so.

This is true whether they're religious extremists, political extremists, marketing droids, or people that just want to party.

The juxtaposition of a Whole Lot of Zeroes happens to provide a cover for there being an excuse.

Take it further than that and you'll get dumb results.

Whether you're concerned about Y2K from a technical perspective, or have religious concerns about Y2K.

(Ask yourself why Arthur C. Clarke named the movie "2001: A Space Odyssey" if you're not sure of this...)

People will hold "new millennium" parties, "new millennium riots," release "new millennium" models of both automobiles and soft drinks, because they were looking for an excuse to do so.

This is true whether they're religious extremists, political extremists, marketing droids, or people that just want to party.

The juxtaposition of a Whole Lot of Zeroes happens to provide a cover for there being an excuse.

Take it further than that and you'll get dumb results.

Whether you're concerned about Y2K from a technical perspective, or have religious concerns about Y2K.

Probably the top site for information on business applications for Linux is:

http://www.hex.net/~cbbrowne/finances.ht ml

I think #2 lists almost everything mentioned thus far and includes the simple things up to the big boys with lots of modules. It needs more work, as AppGen gets no description while others get more reasonable detail.