I hate to take issue with a well-spoken posting, but journalling is not of primary usefulness for helping support High Availability RDBMS systems.
The main effect of journalling, the thing that is really important about it, is that it guarantees that metadata updates are kept consistent. That is, journalling is primarily supportive of making sure that filenames, directory structures, permissions, and such are kept consistent even when moderately catastrophic things happen.
This is a really good thing when supporting file serving activities, as that indeed tends to involve lots of manipulations of files as users shift them around.
I've been on the ReiserFS mailing list since '97; have been running a personal news spool on a small ReiserFS partition for probably 6 months. I can't tell for sure if the journalling now available is metadata-only, or if it also journals normal data updates. It looks rather more like metadata-only, which is useful for file-server work, but not so much for RDBMSes.
Databases behave in quite different ways from file servers in terms of the way they do file access.
If you look at most RDBMSes, they create a few files, and do lots of manipulations on top of them. Informix SE is a counterexample, basically using Informix C-ISAM underneath, but is unusual in that regard. If you look at the database partitions, you get one of two things:
Partitions containing a few very large files.
Note that for these, the metadata is very static which means that journalling of metadata is of relatively little importance.
Partitions containing no filesystem, but rather raw data being managed by the RDBMS.
Don't just believe me; I am not the ultimate authority on this. Transaction Processing : Concepts and Techniques is a rather definitive reference; it discusses methods of managing transactions in the context of database management systems, and goes into considerable detail discussing transaction logging, which bears striking (and not merely coincidental) resemblance to journalling.
The critical point here is that it is the database manager that wants to manage the logging/journalling; Oracle and Sybase and IBM and Informix will be loathe to pass on responsibility for this to Hans Reiser, wonderful guy though he is.
Conclusions
Sorry, I have to disagree with you on ReiserFS being of fundamental importance to those doing serious database work.
What will be of fundamental importance will be when Stephen Tweedy's Raw Device Support gets integrated into the "production" kernels. That is what Oracle is looking for (consider: Oracle has pumped some funds into RHAT, and RHAT is paying Stephen Tweedie... Could there be some connection?)
Journalling IS important for sorts of applications that manipulate lots of files, which includes things like dynamic web serving and file serving.
Even if this isn't such a boon to those doing serious RDBMS work, it can still be a boon to lots of other folks...
It's not evident whether this is helped or hindered by having proxy servers in between you and remote sites...
There most certainly are cases where it is very nice to have something like Junkbuster= and/or Squid in between me and remote places, as both can help keep things a bit more anonymous.
I'm looking forward to cable modems being more ubiquitous; this will mandate having personal firewall machines, and this will encourage the development of little easily-managed boxes to help with such.
Little Linux boxes would be perfect candidates for this sort of thing; a minimal distribution that has some proxying software, and something like Linuxconf or COAS that can be configured remotely through a secure connection (e.g. SSL) would be a killer app.
The Linux community has not yet had a "Pearl Harbour" or any equivalent thereof.
While the diminishing of confidence that would result from a "serious bad occurrance" would not be particularly good, this would have the merit of encouraging people to look past your "false pretences."
A LinuxOne gone bad situation, where, in looking at the documentation, their business case is half-baked, is not going to seriously undermine the ability of Corel to keep trading on NASDAQ and the TSE. After all, they do have a big gold building on Carling Avenue, unlike LinuxOne.
The thing that is really peculiar about the LinuxOne IPO, and it is the thing that is likely to hurt them most, is the consideration that they haven't been able to get an underwriter of any sort, and particularly not a credible one. They're selling stock directly, and the comparison could be drawn that you can go out back to the truck in the parking lot and buy some stock. This has more parallels to the guy in a van driving down Bronson Avenue that says, We've got some extra car speakers. You want some? than it does to a sale through Goldman Sachs & Co.
So no, I'm not terribly worried about this; anyone with a little skepticism about finances will take this IPO with at least some of the "grains of salt" that it deserves...
Is there anything you would like to say to further justify this comment? Both rpm and dpkg are, after all, GPL'd.
Ask Ean @ Novare; I believe he's known as "Special Advisor" for SPI.
There's a hot bed of Debian folk here in Dallas; probably a year and a half ago this was something of a hot topic, and Ean and I held somewhat varying positions, I being "less paranoid," and not a Debian participant, and he being "more paranoid," and heavily involved with Debian.
But do you want this functionality in the DATABASE
on
E-commerce and Linux
·
· Score: 2
MySQL is indeed not a particularly potent "relational" database, with focus on relational; it is, instead, a fairly thin veneer of SQL layered on top of a functionally-pedestrian but nonetheless fast B-tree database system.
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."
Regardless of anything else that you do, make sure users aren't initiating direct accesses to Access.
If there are a lot of Access-based tools that are being used to "massage" the data internally, that is arguably not wonderful; what is crucial is that this not be used for the online copy.
You probably should consider using something like MySQL for handling the online data access for the web server; it would be entirely appropriate to build a process that synchronizes the online data with what's in your "back office" systems. This synchronization can add substantially to the overall robustness of your systems, as this can allow you to detect both:
Discrepancies that might happen on the "Web Server" side, and
Discrepancies that might happen on the "Back Office" side.
The online system that the public has access to doesn't need to have access to all the accounting information that the back office needs, and by clearly separating them, you can strengthen the security and robustness of both.
It might be useful to build some abstractions behind the scenes like message queues like IBM's MQSeries, on which Microsoft's MSMQ is based); a free tool that is commercially used that does this sort of thing is Isect.
"I am very happy to see Corel taking this step into the Open Source world and cooperating with non-commercial organizations such as Debian and KDE," said Wichert Akkerman, Debian's project leader. "By combining Debian's strengths, which include having a large number of developers, a very open development model and a public bug tracking system, with the experience Corel has with making office and desktop products, I think we will be able to produce an outstanding system with the best of both worlds."
If you were not previously aware, Corel HAS been involved with development efforts on Linux for quite some time.
Take a look at the files underneath. There is a Packages file that uses the same format as a Debian Packages file, as a whole lot of files ending with ".deb"
"I am very happy to see Corel taking this step into the Open Source world and cooperating with non-commercial organizations such as Debian and KDE," said Wichert Akkerman, Debian's project leader. "By combining Debian's strengths, which include having a large number of developers, a very open development model and a public bug tracking system, with the experience Corel has with making office and desktop products, I think we will be able to produce an outstanding system with the best of both worlds."
The people that do mass copying of this sort of stuff are likely to be unaffected.
After all, they're the ones buying a "Control Free" DVD burner for $50,000 so they can build a "Pirate DVD Factory" in Malaysia.
They're not making a piddling couple of copies of Phantom Menace; they're making 20,000 copies.
It is likely that this "Commercial Piracy" is of considerably greater importance than anything that would occur from consumers burning their own DVD...
There is an RT-Linux "extension" that allows functions that require RT capabilities to be run at higher priority than the Linux kernel itself. That of course means that the critical functions cannot depend on the parts of the application running on Linux; you split your application into:
Services that require RT service levels, and thus run at a higher level than any Linux code.
Services that do not require RT guarantees that may thus run as Linux processes.
It's probably fair to say that things like eCos, RTEMS, VX-Works, and QNX should not worry too much about Linux; if the application involves life-and-death control issues, I'd rather prefer to use one of those. In critical cases, the maker of an embedded system will have source code access, whatever the cost.
But there is certainly room for Linux to crowd out lower grade things like WinCE in less critical "Soft RT" applications where the cost of the solution is a critical factor.
Any time you take a code base of (several MB of code) and start a separate edition, this has considerable cost.
The cost is in retrofitting changes that go into one tree into the other tree.
Thus, if there turns out to be a Lineo Fork , the folks at Lineo will find that they either:
Pay a bunch of programmers to track what's going into the Torvalds Branch and merge that into the Lineo Fork, or
Risk that useful stuff will go into the Torvalds Branch that either never makes it into Lineo Fork or that has to be independently reimplemented in order to do so.
For instance, if they fork, and ext3 and XFS filesystems are introduced in the Torvalds Branch , it may be as costly (in terms of programmers' time) to introduce those into an independent fork as it was to implement them in the first place.
The folks building embedded systems may not care right now about IP6 or USB or k001 journalled filesystems; if they branch out now, when the support for such things is tentative, it may wind up being difficult-to-impossible to take the code that emerges a year from now and add it in then.
The overall point here is not that Forking is bad and evil and must never happen, Bad! Bad! Bad! The point is rather more like Forking results in there being substantial costs attached to synchronizing the functionality of the varying versions. Forking is EXPENSIVE which can be rather bad.
Linux may be free of charge, but development of code is most definitely not free of cost. And code forks are perhaps the ultimate example of this.
Some good ideas here; it is definitely important not to build components so that they will be heavily dependent on one "Desktop Environment" or another.
The example that I keep citing (and nobody has ever done anything to bring to fruition) is that of the calendaring systems. GNOME and KDE both have calendar programs that "grok" the iCalendar specification, but only partially. In particular, iCalendar was designed to allow "Calendar clients" to connect to a "Calendar server" that could provide schedule information for multiple users.
What they should do is to define a CORBA interface to talk to a Calendar server; by having common IDL that would be free of ties to any GUI there could be one implementation of a Calendar server that both the GNOME and KDE clients would talk to.
This is much same idea as the notion that any sort of web browser can talk to an HTTP server.
Don't be so sure that KDE has "dissed" CORBA as dramatically as you're thinking; what they have concluded is that running raw GUI calls through CORBA to implement compound documents is quite ridiculously inefficient. Note that the GNOME guys have largely concluded the same thing. (ORBit appears more efficient than MICO, so GNOME may get away with doing more with CORBA than KDE can...)
The point is that CORBA has enough overhead involved that you don't want to be shipping around tens of thousands of CORBA calls per second.
On the other hand, using CORBA to request:
... That a text editor be invoked to edit a file,
... That a document, specified as a tree, be submitted to a printer,
... That a bundle of configuration data be retrieved
all represent areas where there's large enough "granularity" that CORBA can be useful.
This idea is pretty cool. Unfortunately, it has several problems:
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 remember back in high school the "hot new thing" being that since silicon was going to be too slow, computers would Real Soon Now be based on light rather than electricity, and we'd be doing switching based on diamonds rather than transistors.
This made it sufficiently into public consciousness that Michael Crichton's book, Congo, had this as the "plot point" behind the search for "uniquely pure" diamonds.
19 years have now passed since the book was written; computers are not yet based on diamonds.
Thinking back only to 1998, IBM announced that PPC chips that used a copper-based production technique would provide massive performance increases; it is not clear that this is yet being deployed in present PPC systems.
I suspect that "single molecule" memory elements are more than 3-5 years away.
Re:Converting to Debian from Red Hat?
on
Debian Freezing
·
· Score: 2
I took a look at this last week with intent to turn a "partly RHAT 5.0, 5.1, and other stuff" box into a Debian system.
Unfortunately, the process is fairly dependent on some particular packages (notably libg++ ) and it looks like it is a distinctly nontrivial process to make this work in practice.
The second problem that you'll hit is that you'll wind up with a whole lot of "cruft," library-like stuff hiding here and there larding up your filesystem.
My inclination would be, instead, to:
Do a backup of /etc
Make sure that /home and /usr/local are on suitable partitions such that they will survive the transition unscathed.
Nuke out /usr , /var , and / by doing an installation from scratch of Debian. Do not format or automagically mount /home or /usr/local ; that can wait 'til after the system is semi-working.
I took a look at the portions of networking config that I wanted to keep working from old OS to new OS; I set up cfengine rules that I tested on the old RHAT install before installing fresh to manage this.
At this point, the box happens to be running RHAT 6.1; there is a good likelihood that I'll set up some even "smarter" cfengine rules than I have now and run the box through a few distributions just for the sake of regaining familiarity before letting it settle down with Debian.
There's not a precise equivalent to Kickstart; what I would do, if I wanted 13 identical boxes, would be:
Pick one box as a "master," and install everything that you want installed on it.
I would mount my Debian CD on a separate box and download via HTTP; this has the result of pushing all the packages that got installed into /var/cache/apt/archives
Then, add /var/cache/apt/archives to /etc/exports so that it gets exported to other machines that want it.
Install the "base" Debian stuff (about 6 floppies worth of stuff) on those other machines.
Copy over some base networking files ( e.g. - /etc/hosts , /etc/fstab and such) and drop them into place so that each machine has some basic common configuration.
I would tend to want to use cfengine for this; I have yet to get it configured to distribute files itself, which is something it claims to be able to do...
Inserting extra needed lines in config files like /etc/fstab is the sort of thing that cfengine is ideal for...
Mount the relevant filesystems on the remote machines, and then have them install via: # dpkg -i/mnt/common-apt-cache/*.deb
This gets all the machines to have the "common" stuff.
It would make a lot of sense to either build a .deb package containing any common config scripts/files or provide a common NFS-mounted "export" directory like the "apt package archive" as a conduit to push stuff to the remote boxes.
Set up a cron job on each box that (let's say) runs a script in /mnt/common-config/ that installs any .deb files in /mnt/common-apt-cache/ that are less than a day old (or check against what's installed).
I would most definitely try to implement this using cfengine as it's designed to do this sort of thing...
This is definitely no harder to automate on Debian than it is on RPM-based distributions, and could actually be easier as you could set up a local "package archive" for the whole set of packages and use apt-get hitting a local server rather than a remote one to keep all of the packages up-to-date with what you want on them.
Look at cfengine; the Usenix journal ;login has had a series on it recently; it is really powerful.
Your observation that "consumer piracy" is likely to be insignificant is very well noted.
The thing is, the commercially significant piracy that takes place under the DVD regime is likely to be, as it is now, a result of "mass piracy" on the part of folks in the "gray market."
Unfortunately, they will benefit from the cheapness of producing DVDs, and while it may become more expensive to become a "commercial DVD pirate" than it is to become a "commercial VHS pirate," that goes along with the benefits of:
Cheaper media and labour costs, and when you're doing something illegal, it's doubtless preferable to have fewer low-paid lackeys that could turn on you, and
Perfect digital copies rather than the present Analog-to-fuzzier-analog VHS results.
If the big sellers of DVDs can maintain rigid control over the manufacturers of DVD mastering units, that might make it hard to "clone" DVDs from masters.
Unfortunately, that's liable to have the same flaws as DAT did. With DAT, there were special codes encoded into tape headers that would let the units forbid copying. That was part of why DAT never took off.
It's a good thing if changes that come in from Corel et al head upstream so that they as much as possible become part of Debian proper.
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:-) )
The system was using a published crypto scheme using "mere" 40 bit keys.
40 bits is fairly breakable, and since key transmission is a critical problem in building crypto systems, and DVD systems often represent embedded systems, they have a few keys vulnerable to brute-force attacks.
There is no question but that DVD encryption would be quite vulnerable to brute force attacks.
This story displays that protocol problems represent a major vulnerability.
It appears that the result of this "exploit" is that the decryption keys for all DVDs have been exposed as a result of them being accidentally published.
This is the sort of thing that organizations like the NSA reportedly are acutely sensitive to when they are trying to crack systems.
In order to keep such systems secure, it is absolutely necessary to be extremely careful with how critical data like encryption keys are dealt with. Apparently these keys were released to people upon whom it was not carefully enough impressed that they needed to be "billions-of-dollars-riding-on-this" worth of careful.
In particular, since these policies have been designed with a view to being amenable to automation, this means that Debian makes a very good base on which to construct customized distributions where much of the maintenance can be automated. This is why there are so many ports, both to diverse architectures (ARM, MIPS, SPARC) as well as to build on some particular infrastructures ( Beowulf ) and even other operating systems ( Hurd ).
The other effect of all this is that creating a variation on Debian doesn't mandate creating a whole huge amount of testing infrastructure, as is necessary to "fork" variations on distributions like Red Hat, where there is not a clear path to get patches back upstream; a Debian "fork" can more reasonably use the existing infrastructure.
It looks like the Corel, Storm, and other such variations on Debian largely involve taking Debian,
Replacing the initial installation tools with cool new ones, which doesn't disturb the rest of the distribution, and
Adding some special packages, which again doesn't forcibly disturb the rest of the distribution.
Due to its ability to multiplex together package sources using apt-get, Debian looks to be a better candidate for this sort of "customization" than just about any other.
LinuxOne is showing the results of public investment far more quickly than other lesser enterprises.
In order for RHAT to start talking about developing further software, they had to get hundreds of millions of dollars invested, and waste considerable time planning.
In contrast, LinuxOne has moved rapidly to deploy the results of the $250 that they raised.
They have clearly achieved their goal of unchallenged availability of applications and platform support, which no other IP has been able to accomplish.
Slashdot Mirror
The main effect of journalling, the thing that is really important about it, is that it guarantees that metadata updates are kept consistent. That is, journalling is primarily supportive of making sure that filenames, directory structures, permissions, and such are kept consistent even when moderately catastrophic things happen.
This is a really good thing when supporting file serving activities, as that indeed tends to involve lots of manipulations of files as users shift them around.
I've been on the ReiserFS mailing list since '97; have been running a personal news spool on a small ReiserFS partition for probably 6 months. I can't tell for sure if the journalling now available is metadata-only, or if it also journals normal data updates. It looks rather more like metadata-only, which is useful for file-server work, but not so much for RDBMSes.
Databases behave in quite different ways from file servers in terms of the way they do file access.
If you look at most RDBMSes, they create a few files, and do lots of manipulations on top of them. Informix SE is a counterexample, basically using Informix C-ISAM underneath, but is unusual in that regard. If you look at the database partitions, you get one of two things:
Note that for these, the metadata is very static which means that journalling of metadata is of relatively little importance.
Don't just believe me; I am not the ultimate authority on this. Transaction Processing : Concepts and Techniques is a rather definitive reference; it discusses methods of managing transactions in the context of database management systems, and goes into considerable detail discussing transaction logging, which bears striking (and not merely coincidental) resemblance to journalling.
The critical point here is that it is the database manager that wants to manage the logging/journalling; Oracle and Sybase and IBM and Informix will be loathe to pass on responsibility for this to Hans Reiser, wonderful guy though he is.
Conclusions
What will be of fundamental importance will be when Stephen Tweedy's Raw Device Support gets integrated into the "production" kernels. That is what Oracle is looking for (consider: Oracle has pumped some funds into RHAT, and RHAT is paying Stephen Tweedie... Could there be some connection?)
Even if this isn't such a boon to those doing serious RDBMS work, it can still be a boon to lots of other folks...
There most certainly are cases where it is very nice to have something like Junkbuster= and/or Squid in between me and remote places, as both can help keep things a bit more anonymous.
I'm looking forward to cable modems being more ubiquitous; this will mandate having personal firewall machines, and this will encourage the development of little easily-managed boxes to help with such.
Little Linux boxes would be perfect candidates for this sort of thing; a minimal distribution that has some proxying software, and something like Linuxconf or COAS that can be configured remotely through a secure connection (e.g. SSL) would be a killer app.
That could, of course, display bias on my part :-).
While the diminishing of confidence that would result from a "serious bad occurrance" would not be particularly good, this would have the merit of encouraging people to look past your "false pretences."
A LinuxOne gone bad situation, where, in looking at the documentation, their business case is half-baked, is not going to seriously undermine the ability of Corel to keep trading on NASDAQ and the TSE. After all, they do have a big gold building on Carling Avenue, unlike LinuxOne.
The thing that is really peculiar about the LinuxOne IPO, and it is the thing that is likely to hurt them most, is the consideration that they haven't been able to get an underwriter of any sort, and particularly not a credible one. They're selling stock directly, and the comparison could be drawn that you can go out back to the truck in the parking lot and buy some stock. This has more parallels to the guy in a van driving down Bronson Avenue that says, We've got some extra car speakers. You want some? than it does to a sale through Goldman Sachs & Co.
So no, I'm not terribly worried about this; anyone with a little skepticism about finances will take this IPO with at least some of the "grains of salt" that it deserves...
Ask Ean @ Novare; I believe he's known as "Special Advisor" for SPI.
There's a hot bed of Debian folk here in Dallas; probably a year and a half ago this was something of a hot topic, and Ean and I held somewhat varying positions, I being "less paranoid," and not a Debian participant, and he being "more paranoid," and heavily involved with Debian.
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."
If there are a lot of Access-based tools that are being used to "massage" the data internally, that is arguably not wonderful; what is crucial is that this not be used for the online copy.
You probably should consider using something like MySQL for handling the online data access for the web server; it would be entirely appropriate to build a process that synchronizes the online data with what's in your "back office" systems. This synchronization can add substantially to the overall robustness of your systems, as this can allow you to detect both:
- Discrepancies that might happen on the "Web Server" side, and
- Discrepancies that might happen on the "Back Office" side.
The online system that the public has access to doesn't need to have access to all the accounting information that the back office needs, and by clearly separating them, you can strengthen the security and robustness of both.It might be useful to build some abstractions behind the scenes like message queues like IBM's MQSeries, on which Microsoft's MSMQ is based); a free tool that is commercially used that does this sort of thing is Isect .
See: Corel's Contributions to the Wine Project
That's Debian, not anything else.
Note that this is a longstanding well known fact. See the April 21 Strategic Alliance Between Corel, KDE and Debian announcement.
After all, they're the ones buying a "Control Free" DVD burner for $50,000 so they can build a "Pirate DVD Factory" in Malaysia.
They're not making a piddling couple of copies of Phantom Menace; they're making 20,000 copies.
It is likely that this "Commercial Piracy" is of considerably greater importance than anything that would occur from consumers burning their own DVD...
It's probably fair to say that things like eCos, RTEMS, VX-Works, and QNX should not worry too much about Linux; if the application involves life-and-death control issues, I'd rather prefer to use one of those. In critical cases, the maker of an embedded system will have source code access, whatever the cost.
But there is certainly room for Linux to crowd out lower grade things like WinCE in less critical "Soft RT" applications where the cost of the solution is a critical factor.
The cost is in retrofitting changes that go into one tree into the other tree.
Thus, if there turns out to be a Lineo Fork , the folks at Lineo will find that they either:
For instance, if they fork, and ext3 and XFS filesystems are introduced in the Torvalds Branch , it may be as costly (in terms of programmers' time) to introduce those into an independent fork as it was to implement them in the first place.
The folks building embedded systems may not care right now about IP6 or USB or k001 journalled filesystems; if they branch out now, when the support for such things is tentative, it may wind up being difficult-to-impossible to take the code that emerges a year from now and add it in then.
The overall point here is not that Forking is bad and evil and must never happen, Bad! Bad! Bad! The point is rather more like Forking results in there being substantial costs attached to synchronizing the functionality of the varying versions. Forking is EXPENSIVE which can be rather bad.
Linux may be free of charge, but development of code is most definitely not free of cost. And code forks are perhaps the ultimate example of this.
The example that I keep citing (and nobody has ever done anything to bring to fruition) is that of the calendaring systems. GNOME and KDE both have calendar programs that "grok" the iCalendar specification, but only partially. In particular, iCalendar was designed to allow "Calendar clients" to connect to a "Calendar server" that could provide schedule information for multiple users.
What they should do is to define a CORBA interface to talk to a Calendar server; by having common IDL that would be free of ties to any GUI there could be one implementation of a Calendar server that both the GNOME and KDE clients would talk to.
This is much same idea as the notion that any sort of web browser can talk to an HTTP server.
Don't be so sure that KDE has "dissed" CORBA as dramatically as you're thinking; what they have concluded is that running raw GUI calls through CORBA to implement compound documents is quite ridiculously inefficient. Note that the GNOME guys have largely concluded the same thing. (ORBit appears more efficient than MICO, so GNOME may get away with doing more with CORBA than KDE can...)
The point is that CORBA has enough overhead involved that you don't want to be shipping around tens of thousands of CORBA calls per second.
On the other hand, using CORBA to request:
... That a text editor be invoked to edit a file, ... That a document, specified as a tree, be submitted to a printer, ... That a bundle of configuration data be retrieved
all represent areas where there's large enough "granularity" that CORBA can be useful.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.
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:
This made it sufficiently into public consciousness that Michael Crichton's book, Congo, had this as the "plot point" behind the search for "uniquely pure" diamonds.
19 years have now passed since the book was written; computers are not yet based on diamonds.
Thinking back only to 1998, IBM announced that PPC chips that used a copper-based production technique would provide massive performance increases; it is not clear that this is yet being deployed in present PPC systems.
I suspect that "single molecule" memory elements are more than 3-5 years away.
I took a look at this last week with intent to turn a "partly RHAT 5.0, 5.1, and other stuff" box into a Debian system.
Unfortunately, the process is fairly dependent on some particular packages (notably libg++ ) and it looks like it is a distinctly nontrivial process to make this work in practice.
The second problem that you'll hit is that you'll wind up with a whole lot of "cruft," library-like stuff hiding here and there larding up your filesystem.
My inclination would be, instead, to:
At this point, the box happens to be running RHAT 6.1; there is a good likelihood that I'll set up some even "smarter" cfengine rules than I have now and run the box through a few distributions just for the sake of regaining familiarity before letting it settle down with Debian.
There's not a precise equivalent to Kickstart; what I would do, if I wanted 13 identical boxes, would be:
- Pick one box as a "master," and install everything that you want installed on it.
- Then, add
/var/cache/apt/archives to /etc/exports so that it gets exported to other machines that want it. - Install the "base" Debian stuff (about 6 floppies worth of stuff) on those other machines.
- Copy over some base networking files ( e.g. -
/etc/hosts , /etc/fstab and such) and drop them into place so that each machine has some basic common configuration. - Mount the relevant filesystems on the remote machines, and then have them install via: # dpkg -i
/mnt/common-apt-cache/*.deb - It would make a lot of sense to either build a
.deb package containing any common config scripts/files or provide a common NFS-mounted "export" directory like the "apt package archive" as a conduit to push stuff to the remote boxes. - Set up a cron job on each box that (let's say) runs a script in
/mnt/common-config/ that installs any .deb files in /mnt/common-apt-cache/ that are less than a day old (or check against what's installed).
This is definitely no harder to automate on Debian than it is on RPM-based distributions, and could actually be easier as you could set up a local "package archive" for the whole set of packages and use apt-get hitting a local server rather than a remote one to keep all of the packages up-to-date with what you want on them.I would mount my Debian CD on a separate box and download via HTTP; this has the result of pushing all the packages that got installed into /var/cache/apt/archives
I would tend to want to use cfengine for this; I have yet to get it configured to distribute files itself, which is something it claims to be able to do...
Inserting extra needed lines in config files like /etc/fstab is the sort of thing that cfengine is ideal for...
This gets all the machines to have the "common" stuff.
I would most definitely try to implement this using cfengine as it's designed to do this sort of thing...
Look at cfengine; the Usenix journal ;login has had a series on it recently; it is really powerful.
Your observation that "consumer piracy" is likely to be insignificant is very well noted.
The thing is, the commercially significant piracy that takes place under the DVD regime is likely to be, as it is now, a result of "mass piracy" on the part of folks in the "gray market."
Unfortunately, they will benefit from the cheapness of producing DVDs, and while it may become more expensive to become a "commercial DVD pirate" than it is to become a "commercial VHS pirate," that goes along with the benefits of:
If the big sellers of DVDs can maintain rigid control over the manufacturers of DVD mastering units, that might make it hard to "clone" DVDs from masters.
Unfortunately, that's liable to have the same flaws as DAT did. With DAT, there were special codes encoded into tape headers that would let the units forbid copying. That was part of why DAT never took off.
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 :-) )
40 bits is fairly breakable, and since key transmission is a critical problem in building crypto systems, and DVD systems often represent embedded systems, they have a few keys vulnerable to brute-force attacks.
There is no question but that DVD encryption would be quite vulnerable to brute force attacks.
It appears that the result of this "exploit" is that the decryption keys for all DVDs have been exposed as a result of them being accidentally published.
This is the sort of thing that organizations like the NSA reportedly are acutely sensitive to when they are trying to crack systems.
In order to keep such systems secure, it is absolutely necessary to be extremely careful with how critical data like encryption keys are dealt with. Apparently these keys were released to people upon whom it was not carefully enough impressed that they needed to be "billions-of-dollars-riding-on-this" worth of careful.
Oops.
That has some (arguable) merits in and of itself; see Clueless users are bad for Debian.
On the other hand, the fact that Debian provides a public Bug Tracking System, and provides some published Distribution Construction Policy that includes Packaging methods/policies means that there is considerably more useful structure than RPM provides.
In particular, since these policies have been designed with a view to being amenable to automation, this means that Debian makes a very good base on which to construct customized distributions where much of the maintenance can be automated. This is why there are so many ports, both to diverse architectures (ARM, MIPS, SPARC) as well as to build on some particular infrastructures ( Beowulf ) and even other operating systems ( Hurd ).
The other effect of all this is that creating a variation on Debian doesn't mandate creating a whole huge amount of testing infrastructure, as is necessary to "fork" variations on distributions like Red Hat, where there is not a clear path to get patches back upstream; a Debian "fork" can more reasonably use the existing infrastructure.
It looks like the Corel, Storm, and other such variations on Debian largely involve taking Debian,
Due to its ability to multiplex together package sources using apt-get, Debian looks to be a better candidate for this sort of "customization" than just about any other.
If the gas tank "goes off," this will ruin your day, whether you're at an altitude of 5 feet or 50,000 feet...
In order for RHAT to start talking about developing further software, they had to get hundreds of millions of dollars invested, and waste considerable time planning.
In contrast, LinuxOne has moved rapidly to deploy the results of the $250 that they raised.
They have clearly achieved their goal of unchallenged availability of applications and platform support, which no other IP has been able to accomplish.
It's entertaining that nobody has brought up Java, The Language of The Internet, as an option... for a while, that was all anyone could think of.
Until that time, I'm quite happy using the so mature they're dead cheap technology of CD-ROMs.