Your implications seem themselves intended to spread the Fear, Uncertainty, and Doubt that you seem to be accusing others of.
GNOME and KDE can both run on top of X simultaneously, as well as Motif, FVWM, Tk, and others. They can coexist.
Are you trying to imply that there should be no attempt to build higher level infrastructures than Xlib?
If you have no such infrastructure, then everybody is left reinventing the same wheels, over and over again, in much the way that there is a host of graphics libraries for X.
And if you do have some such infrastructure, then you'll have to choose between "library sets.
If you're concerned about interoperability, then work on interoperable protocols.
Set up common document formats; note that both are using XML and SGML, and notably are using DocBook for managing the documentation. Improve the Docbook tools, and you help both.
Set up services that can be usable for BOTH. Both GNOME and KDE, for instance, have calendar programs that use common data storage formats; a "killer app" would be to create a calendar server that could allow multi-user access to schedules, and allow management of common resources.
But instead, you have to take a focus that assumes that they are mutually exclusive, when reality is that They are not exclusive.
No, StarOffice is not free. It belongs to Sun Microsystems, and some license fees are waived at their suffrance.
And, in any case, how does Star Office resolve the "window manager and GUI classes" issue taht you seem focused on? It doesn't; it merely places control over the selection of such into Sun's hands.
I certainly don't disagree but that you need some pretty serious design and testing, and some serious brains butting the ideas around, when working on applications where Blue Screen of Death could be an all too literal result.
Consider:
"Attitude adjuster has crashed at altitude 2500m above sea level, estimated time to airplane crash, 14s. Retry, Abort, Cancel?
"Meltdown under way, graphite fire in reactor core causing current temperature of 4500K... Kernel OOPS!
"Your pacemaker has crashed. Cancel or Save ???
"Space shuttle off course; collision course with Sun imminent, and we're not talking Ultra Enterprise Server here.
(Although, with relative velocity vectors of a goodly number of Km/s, a little Sun 3/60 could probably do a good number...)
I have not the Real Time skills to deal with that; the absolutism of the comments were what offended me.
Consider that:
Hospitals run accounting systems, and pay staff, mandating a payroll system (which is a pathological example of a "Real Time" system, as it involves time granularities measured in days rather than in milliseconds) just like any other sizable organization;
Hospitals do a whole lot of record tracking, where "low grade" automation can be quite useful;
They have telephones, elevators, HVAC, security, and all sorts of other such "soft real time" applications where they can pull technologies off the shelf.
RT is not the only issue; free software has considerable things to offer in the non-hard-RT areas.
The first computer consulting job I had, coming out of a school that was not MIT took me, straight off, to a medical laboratory, writing software to control transmission of patient test results between lab sites.
None of the people at that lab were MIT grads; none that I knew of were EE grads.
In other words, I don't believe you. You're making up a story you want to believe.
This seems to me to be a dangerous step towards academia moving towards copyrighting learning, which would be an extremely distressing outcome.
I've been to SAP training where they required signing a form of nondisclosure agrement, which I found disquieting; for public educational institutions to do this seems to me to be grounds for termination of public funding.
The "fabled" adult game of yesteryear was Interlude, which might theoretically be accessible at TRS-80 Revived Pages.
It was advertised in good 'ol 80 Microcomputing with nothing more "explicit" than a attractive woman with subtly suggestive cleavage. (None of the "WWF World Class Implant" thing games selleers use these days...)
The last Hofstadter work that I read was Creative Analogies and Fluid Concepts, and that was in 1996.
Mapping emulated instructions onto the "true" instructions on the processor that's doing the emulating is nicely representative of the notion of "isomorphism." Whatever compiler tools are involved will need to provide some sort of one-to-one mapping of sets of IA-32 instructions onto sets of "Transmeta Chip" instructions; if that is not an isomorphism, I don't know what is.
The notion that Mozilla is a massive waste of "open source resources" is decidedly silly; consider:
What other open source project would you expect Netscape Communications Corp (or AOL) to be involved with?
The fact that it has taken a whopping long time for the (marginally usable) M10 release to arrive is not a clear example of failure; the project has had to labour under several significant constraints:
This left gaping holes in the source code tree, things that had to be reimplemented.
Mozilla has essentially been rearchitected.
What with the above gaping holes, and other things that had grown into being ill-designed, it made huge sense to rebuild a whole lot of the functionality from scratch.
If a version that is of "production quality" is released in the next 4 months, which is not inconceivable, that essentially means that Mozilla has been recreated in two years, which is certainly not a monumental failure.
They're using old technology. There are connections to Europe.
Perhaps this is actually an End of Days scenario; they plan to make an announcement that will help Imminnetize the Eschaton (sp? I've not read the RAW trilogy in quite some time).
On the one hand, the Red Herring article does have the merit of naming six members of the board of directors, which hasn't happened to date. (Most of the "Hype" articles never figure out that David Ditzel is head of the operation...)
On the other hand, they continue to get themselves confused as to the merits of the processor design that "falls out of the patent list."
"Well, it won't be about PCs."
Even though Transmeta's patents indicate that its chips are x86 compatible, it isn't a given that it will join the bloody desktop PC battle.
But laptops aren't that different. And Intel keeps on increasing transistor counts on CPUs, whilst prices don't rise (much), which means that the simple passage of time combined with Moore's law will push them into the "bloody" battle eventually.
And it appears that the media don't grasp the notion of isomorphism:
In other words, Transmeta's chip could translate instruction sets -- the machine-language instructions that a processor understands -- into its own native code. Theoretically, such a chip could run software that's designed to run on just about any kind of chip architecture -- for example, Intel's x86 family of processors.
If a "Transmeta 400" can sit in a box beside my desk and execute IA-32 instructions, then it is isomorphic to the Pentium Pro that sits in a box beside my desk and executes IA-32 instructions.
In effect, they're basically the same. Even if Transmeta has some slick new ways of getting those IA-32 instructions to be executed, the fact that they're doing the same thing undercuts the argument that they're somehow different.
The way there might be a GPLed Motif might be via improving Lesstif into providing Motif 2.1 functionality. That doesn't seem believable in the sort term, so I'm inclined instead to consider:
Motif isn't part of the kernel, and thus doesn't "have" to be GPLed.
That is not consistent with the the sorts of things RHAT has been releasing, though.
Perhaps RHAT has been talking with the Open Group, and may have permission to release a GPLed release of Real Motif.
Other countries that have highly developed information systems, such as Canada, the UK, Germany, France,... are likely in a similar position to the United States. Some exposures, to be sure, but also some significant competence to cope with it.
The places that are more likely to have problems are "Developing" nations in Africa and Asia, as they lack the expertise to grapple with the bugs.
On the other hand, those "underprepared" nations are simultaneously new to automation, and may have relatively few truly critical automated systems. If they have to move back to pen and paper, it's not that huge a leap, as computing was new anyways.
Note as well that multinational companies have contributed to Y2K infrastructures in many such places; after all, if Nike can't get shoes shipped out of Thailand, they can't sell them to US consumers. That makes it worthwhile for Nike to invest in the Thai infrastructure. (Names picked arbitrarily... I don't know if Nike has many factories in Thailand...)
There are systems that would "blow up" if remediation work wasn't done; the famed "billions of lines" of COBOL code, for instance.
You may not see any of this on UNIX systems where the "problem date" is in 2038; that does not diminish that there are huge quantities of "bespoke" applications, custom software written for this department or that within companies, where the code has stayed running far longer than it was designed for.
Massive power grid failure seems unlikely; ditto for banks falling apart altogether as well as for the nukes.
There may be some problems in third world nations where they may have gotten some old System 34/36 systems shipped in, that will burn up on Jan 1st, but if they're just barely automated, stepping back to non-computerized methods isn't liable to be that much of a problem.
I am a bit less worried about the "people" problem.
There have been fewer religious "millennial paranoia" movements than I expected (and I was anticipating there to be some. ). Yes, there are crackpots. But they've been remarkably quiet.
The serious crackpots are going to all load up with guns, and head to a deserted spot in Montana.
Supposing thousands of crazed lunatics head, heavily armed, to Montana next month. What's likely to happen? They're liable to accidentally shoot each other. This might make next year's Darwin Awards as one of the dumbest things of 1999.
I agree with Yourdon's assessment that New York City is liable to be a bad place to be on New Year's Eve; if you put vast numbers of partiers wanting to hold "the blowout of the millennium" in one spot, problems are a given.
Aside: The URL that you gave to the legislation has indeed already expired; someone ought to determine something more precise that invokes the CGI query mechanism. My first draft doesn't quite work; perhaps someone else can suggest better...
Thank you very much for referencing the real legislation; this is a vastly superior thing to discuss than mere commentaries on journalistic commentaries.
It appears to me that there may need to be a clearer "Opt Out" mechanism; aside from that, the fact that the bill expects that parties
should be permitted to determine the appropriate authentication technologies and implementation models for their transactions
implies (as does other parts of the wording) that both parties to a transaction need to be involved in this determination.
There perhaps needs to be some allowance for there being a period of time during which people don't fully understand the implications of this, and some coherent method for repudiation of such agreement, perhaps modelled after the manner in which consumers are permitted to reject certain sorts of transactions from door-to-door salescritters if cancellation is done in some specified period of time...
The problem that may be a quite legitimate cause to reject the bill is if the bill merely requires using "hopefully secure signatures," but does not require that secure protocols be used for transmission.
For instance, if an "end of warrantee" notice is made legally binding merely because the company sending it used digital signatures, this is tremendously wrong, as it provides no mandate that said signature actually come to me, the one holding the product they're trying to end-of-life.
In order for this to work, there needs to be some equivalent to a "two phase commit;" the signature is not valid until I respond back, indicating by sending a digitally signed response that signs their signature that I have received it.
This sort of protocol is something banks doing transfers will doubtless be willing enough to set up; in order for it to be usable with consumers, some proxy that is able to manage the "sign-and-send-back" part is needed. The Post Office might be a good candidate; they have the infrastructure for not-dissimilar verification of receipt of mail that comes when you send something "registered."
If the legislation doesn't offer such "secure protocols," then I would agree that it is a real bad idea. Of course, I don't know this; all that we are seeing is highly-predigested evaluations...
Note that it is quite possible that a particular bill might have wording that would make it downright harmful even though it may provide legal support for our favorite technology.
On the one hand, the US President has consistently opposed legislation to promote the public use of stronger cryptographic tools. Based on that, one might be led to assume that opposition to digital signatures might be based on that opposition to public access to cryptography.
On the other hand, there may be something about the bill in question that actually is bad.
On the gripping hand, it could be worthwhile to have validation of the legality of signatures "set" cryptographically, even if this has some intermediate side-effect that is "bad for consumers."
Does anybody have the actual text of the bill? It's rather difficult to evaluate the merits of completely-pre-digested press releases...
Oops. I set: (setq enable-local-variables T)... and someone set up a mail message that deleted my home directory tree...
The above is, seriously, the big potential security hole in GNU Emacs. It is documented as such, in the documentation, and users are given suitable warning not to do so...
It seems reasonably likely that the only way to make "executable email" safe is the implementation of some sort of capabilities-based system that can strictly lock down what particular programs are permitted to do. Of course, as we learn more about capabilities, it is also likely that its powers of protection will prove quite finite...
The "grab bag" of candidates is interesting enough; I'm a bit surprised that they misspelled Jim Blandy.
Should I take it that the argument behind naming Bill Gates as a candidate is something like:
By producing software of such questionable reputation, and rapacious licensing terms, Bill Gates has done more to encourage people to consider free software than any other purveyor of proprietary software.
I don't expect him to win, but this outcome does offer incredibly entertaining opportunities for the awards dinner.
I'm sure they'd be eating cream pies at that dinner...
If you're running a server in order to run Domino, you're likely going to be installing a fresh server.
It is not overly onerous to install one of the named distributions in order to run it; what is overly onerous is the bureaucracy that would be involved in validating that Domino works in all sorts of possibly oddball configurations.
You know, and I know, that if the configuration is generic enough that Domino will run happily on RHAT and Caldera's distributions, it is highly likely that it will also run on other distributions.
Let IBM have their bureaucratic nightmares, and be happy with them.
Those customers that want straight answers on what IBM is willing to support will be happy with the present answers. And those of us that know better will be able to cope with the rather less mundane state of reality...
Yes, I certainly agree that ReiserFS intends to be a DBMS of sorts; you can use a filesystem to do so where:
A directory can represent a table
Each file in that directory is a record in the table
An "index directory" can contain symbolic links to the records
Things can hierarchicalize as needed
One goal of ReiserFS is to make this practical even for small records by providing ways of efficiently storing hordes of tiny files.
But that's a separate issue; that requires that someone create something like a ReiserSQL, a database server that maps SQL queries onto file requests on a filesystem.
The journalling issue discussed in the top level posting implicitly regards journalling as being important for conventional RDBMSes like Oracle, Sybase, DB/2, PostgreSQL, where the model you are suggesting (and which probably is not too unlike what I outline above) does not apply.
I've got a partition that has been running ReiserFS for quite some time now.
As for the possibility of forking, that was intended as a way of raising funding to support the free version. Now that SuSE is funding ReiserFS, it is rather less likely that Hans Reiser will be feeling the need to bang on Sun's door looking for money.
The hype may have been about XFS, but note that no code for XFS has been publicly released. And note that ReiserFS has been under active development since at least July 1997, which means that while silly people that watch fads may have been off hyping XFS, ReiserFS is hardly new and hardly surprising.
Note, all of these developments in filesystems move us towards having a choice of filesystems, and the ability to tune systems for one kind of behaviour or another. None are likely to supplant ext2 for our root partitions any time soon, in much the same way that commercial UNIXes' "advanced" filesystems have not largely supplanted "traditional UFS" for root partitions.
You haven't seen a release; based on the discussions at ALS involving the developers, it would be surprising to see a "beta" before the end of 1999.
A "beta" is not production code, and doesn't include integration into the "regular" kernel. I would be entirely unsurprised to hear that this hasn't yet occurred by the middle of next year.
I've got a filesystem that has been using ReiserFS for probably 6-8 months now, and Hans has been working on it since at least July 1997.
"Who was first" isn't all that important; it should be noted that there is considerable communication between the development groups, and there are conscious efforts ongoing to make sure they build facilities that will be useful across the board:
The ReiserFS folks have been doing BTree "stuff," and intend to provide some code that should be usable by anyone wanting to do B-Trees at the kernel level, whether that be with ReiserFS, ext3, "ext4," or (and this has been explicitly mentioned) SGI's XFS.
Considerable discussion has taken place in trying to coordinate needed modifications to kernel code in terms of:
VFS
Buffer management
Cache management
It often enough turns out that what one group needs another finds that they also need.
Slashdot Mirror
If you have no such infrastructure, then everybody is left reinventing the same wheels, over and over again, in much the way that there is a host of graphics libraries for X.
And if you do have some such infrastructure, then you'll have to choose between "library sets.
Set up common document formats; note that both are using XML and SGML, and notably are using DocBook for managing the documentation. Improve the Docbook tools, and you help both.
Set up services that can be usable for BOTH. Both GNOME and KDE, for instance, have calendar programs that use common data storage formats; a "killer app" would be to create a calendar server that could allow multi-user access to schedules, and allow management of common resources.
But instead, you have to take a focus that assumes that they are mutually exclusive, when reality is that They are not exclusive.
And, in any case, how does Star Office resolve the "window manager and GUI classes" issue taht you seem focused on? It doesn't; it merely places control over the selection of such into Sun's hands.
Consider:
(Although, with relative velocity vectors of a goodly number of Km/s, a little Sun 3/60 could probably do a good number...)
I have not the Real Time skills to deal with that; the absolutism of the comments were what offended me.
Consider that:
RT is not the only issue; free software has considerable things to offer in the non-hard-RT areas.
None of the people at that lab were MIT grads; none that I knew of were EE grads.
In other words, I don't believe you. You're making up a story you want to believe.
I've been to SAP training where they required signing a form of nondisclosure agrement, which I found disquieting; for public educational institutions to do this seems to me to be grounds for termination of public funding.
It was advertised in good 'ol 80 Microcomputing with nothing more "explicit" than a attractive woman with subtly suggestive cleavage. (None of the "WWF World Class Implant" thing games selleers use these days...)
None of these have really gone anywhere in terms of influencing Java deployment.
The only way they would have been important is if:
Mapping emulated instructions onto the "true" instructions on the processor that's doing the emulating is nicely representative of the notion of "isomorphism." Whatever compiler tools are involved will need to provide some sort of one-to-one mapping of sets of IA-32 instructions onto sets of "Transmeta Chip" instructions; if that is not an isomorphism, I don't know what is.
What other open source project would you expect Netscape Communications Corp (or AOL) to be involved with?
The fact that it has taken a whopping long time for the (marginally usable) M10 release to arrive is not a clear example of failure; the project has had to labour under several significant constraints:
This left gaping holes in the source code tree, things that had to be reimplemented.
What with the above gaping holes, and other things that had grown into being ill-designed, it made huge sense to rebuild a whole lot of the functionality from scratch.
If a version that is of "production quality" is released in the next 4 months, which is not inconceivable, that essentially means that Mozilla has been recreated in two years, which is certainly not a monumental failure.
Maybe they have been waiting for MSFT to have a bit of slippage, with the intent to pounce at that point.
(Although Paul Allen, investor, also holds lots of MSFT stock, and thus would get hurt by this... Not too plausible...)
They're using old technology. There are connections to Europe.
Perhaps this is actually an End of Days scenario; they plan to make an announcement that will help Imminnetize the Eschaton (sp? I've not read the RAW trilogy in quite some time).
On the other hand, they continue to get themselves confused as to the merits of the processor design that "falls out of the patent list."
But laptops aren't that different. And Intel keeps on increasing transistor counts on CPUs, whilst prices don't rise (much), which means that the simple passage of time combined with Moore's law will push them into the "bloody" battle eventually.
If a "Transmeta 400" can sit in a box beside my desk and execute IA-32 instructions, then it is isomorphic to the Pentium Pro that sits in a box beside my desk and executes IA-32 instructions.
In effect, they're basically the same. Even if Transmeta has some slick new ways of getting those IA-32 instructions to be executed, the fact that they're doing the same thing undercuts the argument that they're somehow different.
- Motif isn't part of the kernel, and thus doesn't "have" to be GPLed.
- Perhaps RHAT has been talking with the Open Group, and may have permission to release a GPLed release of Real Motif.
- Perhaps the press release is somehow wrong.
There's really no compelling answer here...That is not consistent with the the sorts of things RHAT has been releasing, though.
Also a bit "out there" as theories go...
Journalists never make mistakes, though, right?
The places that are more likely to have problems are "Developing" nations in Africa and Asia, as they lack the expertise to grapple with the bugs.
On the other hand, those "underprepared" nations are simultaneously new to automation, and may have relatively few truly critical automated systems. If they have to move back to pen and paper, it's not that huge a leap, as computing was new anyways.
Note as well that multinational companies have contributed to Y2K infrastructures in many such places; after all, if Nike can't get shoes shipped out of Thailand, they can't sell them to US consumers. That makes it worthwhile for Nike to invest in the Thai infrastructure. (Names picked arbitrarily... I don't know if Nike has many factories in Thailand...)
You may not see any of this on UNIX systems where the "problem date" is in 2038; that does not diminish that there are huge quantities of "bespoke" applications, custom software written for this department or that within companies, where the code has stayed running far longer than it was designed for.
Linux may not have much of a ``Y2K problem;'' there are a whole lot of database-oriented and COBOL-oriented applications that do, or (hopefully by this point) did.
There may be some problems in third world nations where they may have gotten some old System 34/36 systems shipped in, that will burn up on Jan 1st, but if they're just barely automated, stepping back to non-computerized methods isn't liable to be that much of a problem.
I am a bit less worried about the "people" problem.
Ed Yourdon says so :-).
Supposing thousands of crazed lunatics head, heavily armed, to Montana next month. What's likely to happen? They're liable to accidentally shoot each other. This might make next year's Darwin Awards as one of the dumbest things of 1999.
Thank you very much for referencing the real legislation; this is a vastly superior thing to discuss than mere commentaries on journalistic commentaries.
It appears to me that there may need to be a clearer "Opt Out" mechanism; aside from that, the fact that the bill expects that parties
implies (as does other parts of the wording) that both parties to a transaction need to be involved in this determination.There perhaps needs to be some allowance for there being a period of time during which people don't fully understand the implications of this, and some coherent method for repudiation of such agreement, perhaps modelled after the manner in which consumers are permitted to reject certain sorts of transactions from door-to-door salescritters if cancellation is done in some specified period of time...
For instance, if an "end of warrantee" notice is made legally binding merely because the company sending it used digital signatures, this is tremendously wrong, as it provides no mandate that said signature actually come to me, the one holding the product they're trying to end-of-life.
In order for this to work, there needs to be some equivalent to a "two phase commit;" the signature is not valid until I respond back, indicating by sending a digitally signed response that signs their signature that I have received it.
This sort of protocol is something banks doing transfers will doubtless be willing enough to set up; in order for it to be usable with consumers, some proxy that is able to manage the "sign-and-send-back" part is needed. The Post Office might be a good candidate; they have the infrastructure for not-dissimilar verification of receipt of mail that comes when you send something "registered."
If the legislation doesn't offer such "secure protocols," then I would agree that it is a real bad idea. Of course, I don't know this; all that we are seeing is highly-predigested evaluations...
Note that it is quite possible that a particular bill might have wording that would make it downright harmful even though it may provide legal support for our favorite technology.
On the one hand, the US President has consistently opposed legislation to promote the public use of stronger cryptographic tools. Based on that, one might be led to assume that opposition to digital signatures might be based on that opposition to public access to cryptography.
On the other hand, there may be something about the bill in question that actually is bad.
On the gripping hand, it could be worthwhile to have validation of the legality of signatures "set" cryptographically, even if this has some intermediate side-effect that is "bad for consumers."
Does anybody have the actual text of the bill? It's rather difficult to evaluate the merits of completely-pre-digested press releases...
The above is, seriously, the big potential security hole in GNU Emacs. It is documented as such, in the documentation, and users are given suitable warning not to do so...
It seems reasonably likely that the only way to make "executable email" safe is the implementation of some sort of capabilities-based system that can strictly lock down what particular programs are permitted to do. Of course, as we learn more about capabilities, it is also likely that its powers of protection will prove quite finite...
Should I take it that the argument behind naming Bill Gates as a candidate is something like:
I don't expect him to win, but this outcome does offer incredibly entertaining opportunities for the awards dinner.
I'm sure they'd be eating cream pies at that dinner...
They have to be able to have a service offering.
If you're running a server in order to run Domino, you're likely going to be installing a fresh server.
It is not overly onerous to install one of the named distributions in order to run it; what is overly onerous is the bureaucracy that would be involved in validating that Domino works in all sorts of possibly oddball configurations.
You know, and I know, that if the configuration is generic enough that Domino will run happily on RHAT and Caldera's distributions, it is highly likely that it will also run on other distributions.
Let IBM have their bureaucratic nightmares, and be happy with them.
Those customers that want straight answers on what IBM is willing to support will be happy with the present answers. And those of us that know better will be able to cope with the rather less mundane state of reality...
One goal of ReiserFS is to make this practical even for small records by providing ways of efficiently storing hordes of tiny files.
But that's a separate issue; that requires that someone create something like a ReiserSQL, a database server that maps SQL queries onto file requests on a filesystem.
The journalling issue discussed in the top level posting implicitly regards journalling as being important for conventional RDBMSes like Oracle, Sybase, DB/2, PostgreSQL, where the model you are suggesting (and which probably is not too unlike what I outline above) does not apply.
That bottleneck is not resolved by changes to filesystem functionality.
This means that ReiserFS does not fix the problem; this means that XFS does not fix the problem.
At present, your choices for resolving the 2GB file size limit are two:
As for the possibility of forking, that was intended as a way of raising funding to support the free version. Now that SuSE is funding ReiserFS, it is rather less likely that Hans Reiser will be feeling the need to bang on Sun's door looking for money.
The hype may have been about XFS, but note that no code for XFS has been publicly released. And note that ReiserFS has been under active development since at least July 1997, which means that while silly people that watch fads may have been off hyping XFS, ReiserFS is hardly new and hardly surprising.
Note, all of these developments in filesystems move us towards having a choice of filesystems, and the ability to tune systems for one kind of behaviour or another. None are likely to supplant ext2 for our root partitions any time soon, in much the same way that commercial UNIXes' "advanced" filesystems have not largely supplanted "traditional UFS" for root partitions.
Plus ca change, plus ca reste meme.
You haven't seen a release; based on the discussions at ALS involving the developers, it would be surprising to see a "beta" before the end of 1999.
A "beta" is not production code, and doesn't include integration into the "regular" kernel. I would be entirely unsurprised to hear that this hasn't yet occurred by the middle of next year.
Not likely any time soon..."Who was first" isn't all that important; it should be noted that there is considerable communication between the development groups, and there are conscious efforts ongoing to make sure they build facilities that will be useful across the board:
- VFS
- Buffer management
- Cache management
It often enough turns out that what one group needs another finds that they also need.