You are only "in fact stealing power" if the land does not "in fact" belong to you.
On the other hand, if you own the land, it is entirely possible that what you're 'stealing' is the current that someone volunteered to put over your property. Which might not be stealing at all.
First glance... They must be insane. That can't possibly work.
Second glance... Maybe it can work... If it does, it's certainly immune to buffer exploits in wu-ftpd.
Third glance... Seems like a slick idea. It sure would entertain portscanners when there are no ports there to get at.
Fourth glance. Unfortunately, I can't use it on my firewall, as I need pppoe running.
The interesting lesson, though, "kiddies," is that there are some interesting games to be played if you look at init with a view to rearchitecting how it works.
Typically, init is a program that starts some services, starts up some gettys , and then we can log in and do the traditional Unix stuff that we usually don't think much about.
In this case, the system essentially runs init-less.
Another approach would be to build a highly customized init that doesn't run the whole of user space, but rather just runs a few firewall-related programs.
Mount a filesystem;
Run an IP-chain loader;
Perhaps run pppoe ;
Unmount the filesystem, maybe.
And you have something smaller that doesn't work quite as hard getting things going, but leaves pppoe around to do a little bit of work.
Other approaches could be taken to build quite different things:
CLienUX (possibly not capitalized quite rightly) is a system where libc does on-the-fly path rewriting to support accessing some standard pathnames (/usr,/usr/bin) on a system with an exceedingly nonstandard set of naming conventions.
Throw in that shell scripts in Bash are deprecated; it is considered preferable to have your programs written in Forth.
One might create a Lisp Machine running atop Linux by having init be a master Lisp process that takes over the system. Throw in a helper process or two (X, maybe, and SSH) and you've got something with a userspace just a mite different from what people are accustomed to...
It sure would be nice to be able to do major hackery with the data formats, and have an easy in-place upgrade; unfortunately, this comes with two big costs:
It takes a lot of work to do this, which will seem pointless to many when "dump/re-import" is already there and works;
More importantly, debugging this, across umpteen platforms, possible variations on how folks compiled it, and moves between minor version numbers that may differ more or less than you'd expect is really a lot of work.
The unavailability of a "Ext2-to-ReiserFS" translator, or Ext2-to-JFS or Ext2-to-XFS occurs for much the same reason, albeit with the further challenge that the "upgrade" would somewhat more resemble a "MySQL-format-to-PostgreSQL-format" conversion:-).
The apparent "problem" with Gnome that he's trying to solve is that some huge portion of Evolution consists of memory management code.
(That apparently explains why when I request an install from Ximian.com, apt-get reports that the one package of evolution is going to consume something around 110MB of disk space...)
Miguel would kind of like to move over to Java as an application development language; it's a not-horrifically-badly-designed language, and has the merit of garbage collection and some "syntactic sugar" to support OO classes and exceptions...
Unfortunately, the design of Java is such that it nicely interoperates with, well, Java, and um, Java, and, um, not too much else. (Unless you jump into FFI stuff that's always terribly fiddly, and leaps you back into writing constructors and destructors in C for the interface code...)
The "JVM" thing offers some portability, but Java suffers from the huge problem that all the Kool Stuff in J2EE and Swing and such that you'd like to use is, well, only marginally less encumbered by Sun licenses than .NET services will be by Microsoft licenses.
Count the number of major Java apps that are installed by default in your favorite Linux distribution. That number is usually zero, as you get to choose between:
Deploying stuff using the "toy" APIs of Java 1.0 that are really creaky, but available "libre and gratis," or
Paying some huge license fee to Sun to allow you to include the Cool New Java APIs on the CD.
C++ is Not Miguel's Favorite Language
And it really wouldn't do anything to solve the problems at hand, as it still mandates spending lots of time writing constructors and destructors. Plus there's no quasi-standard ABI, so that you'll be recompiling incessantly.
And then there's the KDE problem where library loading takes quite a bit of time because of resolution of virtual methods...
But I think the real reason for "no C++" is simply that Miguel doesn't much like C++.
So Miguel wants something a tad more dynamic than C/C++, particularly vis-a-vis memory management. I find it a little disappointing that he didn't take a serious look at some of the mature languages already out there.
GNU Ada is a whopping lot more mature than G++, for instance, and would offer some "software engineering" merits.
There are a good set of Eiffel compilers, and that combines OO with GC as well as the "Design by Contract" thing that Miguel has consciously tipped his hat to.
Modula 3 is another "unsung language;" OO plus GC plus well-defined threading, even.
If he's looking for a better language in which to build more stuff like Evolution, I'd think these three to be eminently plausible Good Alternatives to designing a new Virtual Machine environment along with a whole set of compilers.
The standard that SCO, Solaris, and *BSD can probably all conform to.
Windows NT.
With its POSIX subsystem.
OS/400
With its POSIX subsystem
Mac OS/X
With BSD underneath.
I suppose Tandem may not be emulating a flavor of Unix, but who's got one of those at home?
PalmOS isn't a Unix-like system, but it's getting pretty long in the tooth, and isn't a tremendously viable platform for arch anyways.
It's not outrageous to suggest that Unix has effectively "won" the mind-share war.
FTP is there. It's there on all sorts of systems. It was sufficient to get it working.
I'm sure that down the road it would be a very slick thing to the rsync protocols for data transfer between sites, as implemented in rsync and Unison. That would provide all sorts of ooey-gooey- encrypted, compressed goodness to help network connections be used more efficiently.
The file transfer protocol isn't nearly as important as how it deals with versioning, logging, and thie likes, to be sure...
Debian doesn't have to change package managers in order to comply with LSB.
For that matter, FreeBSD could comply with LSB without either:
Using a Linux kernel
Look at the standard; it specifies nothing about what OS kernel you are using.
Using RPMs instead of pkgs and Ports
Again, look at the standard. The set of package names to be managed by RPM, which runs on FreeBSD, is intentionally completely disjoint from any set of package names being managed "natively" by the distribution.
Careful reading of the standard shows that there is no requirement to be running Linux in order to conform with the standard. You could conceivably run some other kernel, like those from FreeBSD, NetBSD, Sun, SCO/Caldera. I'll bet it's at least theoretically possible that Windows NT with the "Unix emulation environment" could be made LSB-compliant.
Look for the section entitled Kernel Requirements.
You won't find one. There isn't one.
This actually has a really entertaining implication, namely that despite saying "Linux" a lot, the standard hasn't anything forcibly to do with Linux.
I'm fairly sure that the FreeBSD folks are likely to be able to take this standard and make some changes to conform their "Linux compatibility" subsystem with it.
I'll bet that SCO (A division of Caldera) could take this standard and make SCO UNIX, with some layering of GLIBC, compatible with it.
Ditto for BSDi, AIX, HP/UX, and Solaris. I'd almost bet anything Sun will do some work to get Solaris "conformant," at least looking ahead to Solaris/IA-64
It would be quite the shock if Microsoft were to throw some effort into their "Linux Emulation Environment" (it exists; I don't recall the name...) to make it "LSB-Conformant."
The notion that this standard has much of anything to do with the Linux kernel is desparately ignorant of a reading of the standard.
Were you to read the standard, you might be able to figure out answers to these and other meaningful questions.
The ans
wer is, by the way, that it doesn't affect Debian in any meaningful way.
The standard does
not require that Debian drop its own packaging scheme.
The standard does not mandate the use of RPM packaging within the distribution.
Read the standard; it's not particularly painful to read.
A much more entertaining thing is to think about how this might affect folks using FreeBSD It is entirely possible that this standard allows FreeBSD, which is conspicuously not Linux as well as not based on RPM packaging, to nonetheless become a nicely "compliant" Linux Standard Base platform.
Heck, Microsoft might be able to modify the "Unix Emulation" environment they have running on Windows NT (it's sold as something; I don't recall the name...) become compliant with LSB
This wouldn't be any stranger than when Microsoft made Windows NT a "POSIX" platform, or when IBM got OS/390 certified as a Branded Unix (tm)
The notion that this creates some massive problem for Debian is just plain ignorant, and when the article links to the publicly-available-on-the-web standard, being so ignorant is quite inexcuable.
Those who read the standards might have a clue
on
Linux Standard Base 1.1
·
· Score: 4, Informative
Debian packages do not HAVE TO BE.RPM.
If you were to actually read the standards document, the requirement is:
Distributions must provide a mechanism for installing applications in this packaging format with some restrictions listed below. [2]
And if you were to look for note [2] you would find that it reads:
[2] The distribution itself may use a different packaging format for its own packages, and of course it may use any available mechanism for installing the LSB-conformant packages.
The point of LSB is to allow third party applications to be portable across distributions. That does not mandate anything about how a distribution chooses to package the Linux kernel, GLIBC, or much of anything else that it itself chooses to package.
Indeed, nothing mandates that an LSB-compliant distribution even has its own packaging scheme. A distribution could have all the components required by LSB in all the right spots, and just plain put them there. No "packages;" just files.
The notion that switching to rpms would be "rather easy" demonstrates considerable ignorance.
There is a sizable set of tools used in the construction of Debian that are tightly tied to .deb packages.
apt is only the start of the "advanced" aspect of package management; what's far more critical are the set of development tools, like lintian, debscripts, jablicator, deb-make, deb-helper, equivs, dpkg-dev, apt-move, and such.
Eliminating all of that would be like telling the Linux kernel developers that they have to stop using C, and write Linux in assembly language.
It's not simply apt-get that "eliminates the dependancy hunt;": in order for the set of packages to be kept coherent, so they're not merely a jumble of RPMs of dubious provenance strewn across the Internet, you need the development tools.
To move Debian to RPMs would require rewriting all those tools for RPM use. There's merit to such an idea; if there were coherent tools for dealing with the development of a complete RPM-based distribution, you'd doubtless get better stability. But that's a big task, and your non-recognition of the issue doesn't make it go away...
If everybody can throw their patch at the SCM, that increases the rate at which "crap" can be thrown at the kernel.
This does nothing to help those that take on the task of seeing which "bits of crap" should stick, and which should be dropped on the floor.
I don't see that SCM automation does too much more than accelerate the rate at which crap gets thrown at the kernel.
As for the JVM-like thing, it seems unlikely to me that this would be fundamentally helpful. You would see performance really sucking, because DSP-like stuff (like image processing, audio processing, GUI rendering) massively benefits from being compiled for a specific architecture.
There may be some merits to such an idea, they are on the "minor" side.
If people submit crap into CVS (or Subversion, or Aegis, or SCCS, or CSSC, or RCS, or whatever fabled system may be out there), what you've got is crap in the kernel.
Automated tools have merits, but one demerit is that they make it easier for people to submit a thousand bad
patches per day
The wonderful relevant quote, from Mitch Radcliffe:
Computers
let you make more mistakes faster than any other
invention in human history, with the possible exception of handguns
and tequila.
Any would-be fork has to put a lot more thought into the political processes than into the technicalities of which version management software to use, otherwise you're arming the teeming masses with tequila and handguns, and that's hardly going to lead to reliable kernels:-).
Early Intel Xeon systems were pretty pricey, and early IA64 systems probably aren't exactly "cheap."
$3900 is a mite high, but high prices are not particularly surprising when something is being sold in its initial "units of 1 board to early implementors."
It obviously won't get wildly popular until they can get pricing a bit more competitive with the hardware emitted by Apple, but it's a little early to say that this will never happen.
MAI may be able to maintain a viable commercial business without prices ever falling to $100/unit, by the way...
If what they have released to the public domain is just the binaries, then that's all that's "public domain."
If they have not released source code, and didn't license the binaries under some arrangement that gives you the right to demand source code (have we ever heard of a license like that???), then what they have done with the binaries has nothing to do with the accessibility of source code.
Ob-DesqView reference: It was a pretty neat system; at the time I used it, OS/2 was an alternative that was, for my purposes, preferable since it actually actively resisted crashes, which was important when coding fairly wildly-pointered C code...
The last release that I saw was not as stable as the second-last release, which was unfortunate. That might have been Microsoft playing their Windows isn't done until Foo crashes, consistently games....
The results do not involve
geometric mean performance on multiple kernels compiled through it reached 47% improvement over GCC.
The testing didn't involve compiling kernels at all.
The 47% performance improvements were on a numerically intense benchmark program.
This helps users of PPC, Alpha, and StrongARM exactly how?
The preferences of the article's authors is pretty clear:
"Nonetheless, the magnitude of the performance differential in numerically intense applications is such that only the most dramatic sort of improvement in the long-awaited version 3 of the GNU C/C++ compiler will stay the hammer that drives a stake through the fibrillating heart of the aging technology behind the GNU C compiler. May it rest in peace."
These are not the words of objective observers, and such comments strike me as being quite irresponsible.
I wrote the chapters in PLP on CORBA, and found, when I went through it, there were some tpyos that I was pretty sure I had not introduced. (There was one place where it looks like someone rewrote some material; didn't read like something I'd write...)
There were indeed some deadline issues, which makes it difficult to generate a flawless product.
This is going to be a problem with any situation where there is urgency in getting the book pushed out. Donald Knuth may have the "clout" to get Addison Wesley to wait for him to be happy with the results; that is definitely not going to be the case for these sorts of books with garish red covers.
(The web link given doesn't seem to work; maybe something's down?)
At any rate, it's not obvious just what the results of taking over RHAT would be. There are ample possibilities for both good and ill, from many perspectives:
Having a Really, Really, Really Big Company can lend either credibility or be very injurious.
On the one hand, "If AOL/TW thinks there's something to it..." but then if they do something silly, credibility can get badly hurt.
Control of spending policies moves from one group of folks responsible primarily to their investors to another group of folks responsible primarily to their investors.
Enter a new set of "policy controllers." Again, this can be good or bad.
AOL bought Netscape, and then, on the one hand, seems to have left the Mozilla project alone to continue developing, but on the other hand are bundling Internet Exploder with CDs to customers.
Ambiguous again.
One interesting effect, regardless, is that a bunch of people that invested in RHAT will get some pretty substantial value out of it. If things go bad, Debian is still there, and we might see some made-rich hackers get into new involvements. Hopefully a little more computing-related than jwz's DNA Lounge, but that's not to be a flame of jwz...
If the result is that AOL/RHAT "craters," there's always Debian, Slackware, Mandrake, SuSE, and the BSDs still around...
Sure, the usual "context switch" ignorance
on
Xfree86 4.2.0 Out
·
· Score: 2
And if I am running multiple processes, each with their own context, that each expect to have access to the screen, how are you proposing that they manage the process of sharing access?
After all, if I'm running:
Mozilla,
OpenOffice,
A couple terminal sessions,
A clock,
An "applet" that displays weather reports, and
An applet that does some cool animation,
A stock ticker,
A list of Slashdot articles,
how is it that you would think that all of these would concurrently make their relevant updates to what's on the screen...
WITHOUT A WHOLE WHACK OF CONTEXT SWITCHES?!?!?!?!
The notion that context switches are some inherent evil that must be expunged seems typically to be an evidence that the writer needs to get severely thrashed with several clue sticks.
Having too many context switches would obviously be a Bad Thing. But the notion that the separation of client and server is synonymous with "too many context switches" is just silly.
Consider the oft-commended alternative, NeXTStep, with its Display Postscript. In its architecture, applications use a client library to connect to a server process that runs the Postscript interpreter that they call the NX agent. The classic criticism of the NeXT architecture is that the PS implementation is typically single-threaded, thus meaning that you can get a pile of extra latency when other processes might be trying to get a context switch in edge-wise, but are BLOCKED.
It's one thing to make informed criticism of X, but to claim that things are bad about it that would be just as true of alternative architectures just demonstrates ignorance.
Anyone who doesn't believe this, feel free to go off and run GNUMail , the GNUStep mail application. Watch what processes it connects to. If X was replaced by a "direct DPS atop framebuffer," the client/server connections would NOT GO AWAY.
No, I downloaded a copy about six months ago; probably ought to toss it onto my latest "TODO" list.
It's not something that will be of vast interest for applications just yet; if it enters "ordinary kernels" in 2.5.something, that's certainly a good step towards it.
The Really Cool thing to use this sort of thing for would be to have user-space filesystem drivers, and mount things under (let's say) $HOME/mnt/
A DBM file could become a directory hierarchy, accessible only to the process that mounted it.
You might do a "loopback encryption" that would only be accessible to processes that are children of the login shell that was used to mount (oh, say) SSH passwords or the GPG keys.
Right now, cfs (encrypted) mounts are publicly available, albeit not being terribly visible. The namespace equivalent would not allow public access at all...
X provides a protocol for applications to communicate with the screen.
Contrary to popular belief, it doesn't force huge gobs of "evil network transparency" in; that pretty much comes for free.
After all, there MUST be an IPC system involved, unless we were to transform it all into some sort of "cooperative multitasking" system with only one process (think: MS Windows, where if any bit of any application breaks, you have to reboot).
As soon as you have IPC, extending that to allow network transparency is pretty easy, and focusing on how "expensive" this is is just silly.
When you start with such huge misconceptions, that undermines the value of the whole discussion.
Slashdot Mirror
You are only "in fact stealing power" if the land does not "in fact" belong to you.
On the other hand, if you own the land, it is entirely possible that what you're 'stealing' is the current that someone volunteered to put over your property. Which might not be stealing at all.
The interesting lesson, though, "kiddies," is that there are some interesting games to be played if you look at init with a view to rearchitecting how it works.
Typically, init is a program that starts some services, starts up some gettys , and then we can log in and do the traditional Unix stuff that we usually don't think much about.
In this case, the system essentially runs init-less.
Another approach would be to build a highly customized init that doesn't run the whole of user space, but rather just runs a few firewall-related programs.
- Mount a filesystem;
- Run an IP-chain loader;
- Perhaps run pppoe ;
- Unmount the filesystem, maybe.
And you have something smaller that doesn't work quite as hard getting things going, but leaves pppoe around to do a little bit of work.Other approaches could be taken to build quite different things:
Throw in that shell scripts in Bash are deprecated; it is considered preferable to have your programs written in Forth.
The unavailability of a "Ext2-to-ReiserFS" translator, or Ext2-to-JFS or Ext2-to-XFS occurs for much the same reason, albeit with the further challenge that the "upgrade" would somewhat more resemble a "MySQL-format-to-PostgreSQL-format" conversion :-).
(That apparently explains why when I request an install from Ximian.com, apt-get reports that the one package of evolution is going to consume something around 110MB of disk space...)
Unfortunately, the design of Java is such that it nicely interoperates with, well, Java, and um, Java, and, um, not too much else. (Unless you jump into FFI stuff that's always terribly fiddly, and leaps you back into writing constructors and destructors in C for the interface code...)
The "JVM" thing offers some portability, but Java suffers from the huge problem that all the Kool Stuff in J2EE and Swing and such that you'd like to use is, well, only marginally less encumbered by Sun licenses than .NET services will be by Microsoft licenses.
Count the number of major Java apps that are installed by default in your favorite Linux distribution. That number is usually zero, as you get to choose between:
And it really wouldn't do anything to solve the problems at hand, as it still mandates spending lots of time writing constructors and destructors. Plus there's no quasi-standard ABI, so that you'll be recompiling incessantly.
And then there's the KDE problem where library loading takes quite a bit of time because of resolution of virtual methods...
But I think the real reason for "no C++" is simply that Miguel doesn't much like C++.
So Miguel wants something a tad more dynamic than C/C++, particularly vis-a-vis memory management. I find it a little disappointing that he didn't take a serious look at some of the mature languages already out there.
- GNU Ada is a whopping lot more mature than G++, for instance, and would offer some "software engineering" merits.
- There are a good set of Eiffel compilers, and that combines OO with GC as well as the "Design by Contract" thing that Miguel has consciously tipped his hat to.
- Modula 3 is another "unsung language;" OO plus GC plus well-defined threading, even.
If he's looking for a better language in which to build more stuff like Evolution, I'd think these three to be eminently plausible Good Alternatives to designing a new Virtual Machine environment along with a whole set of compilers.It is conceivable that the book is nearly ready at least to release to O'Reilly, and I gather that they intend to make it somewhat freely available...
The standard that SCO, Solaris, and *BSD can probably all conform to.
With its POSIX subsystem.
With its POSIX subsystem
With BSD underneath.
I suppose Tandem may not be emulating a flavor of Unix, but who's got one of those at home? PalmOS isn't a Unix-like system, but it's getting pretty long in the tooth, and isn't a tremendously viable platform for arch anyways.
It's not outrageous to suggest that Unix has effectively "won" the mind-share war.
I'm sure that down the road it would be a very slick thing to the rsync protocols for data transfer between sites, as implemented in rsync and Unison. That would provide all sorts of ooey-gooey- encrypted, compressed goodness to help network connections be used more efficiently.
The file transfer protocol isn't nearly as important as how it deals with versioning, logging, and thie likes, to be sure...
For that matter, FreeBSD could comply with LSB without either:
Look at the standard; it specifies nothing about what OS kernel you are using.
Again, look at the standard. The set of package names to be managed by RPM, which runs on FreeBSD, is intentionally completely disjoint from any set of package names being managed "natively" by the distribution.
Careful reading of the standard shows that there is no requirement to be running Linux in order to conform with the standard. You could conceivably run some other kernel, like those from FreeBSD, NetBSD, Sun, SCO/Caldera. I'll bet it's at least theoretically possible that Windows NT with the "Unix emulation environment" could be made LSB-compliant.
You won't find one. There isn't one.
This actually has a really entertaining implication, namely that despite saying "Linux" a lot, the standard hasn't anything forcibly to do with Linux.
The notion that this standard has much of anything to do with the Linux kernel is desparately ignorant of a reading of the standard.
The ans wer is, by the way, that it doesn't affect Debian in any meaningful way.
Read the standard; it's not particularly painful to read.
A much more entertaining thing is to think about how this might affect folks using FreeBSD It is entirely possible that this standard allows FreeBSD, which is conspicuously not Linux as well as not based on RPM packaging, to nonetheless become a nicely "compliant" Linux Standard Base platform.
Heck, Microsoft might be able to modify the "Unix Emulation" environment they have running on Windows NT (it's sold as something; I don't recall the name...) become compliant with LSB
This wouldn't be any stranger than when Microsoft made Windows NT a "POSIX" platform, or when IBM got OS/390 certified as a Branded Unix (tm)
The notion that this creates some massive problem for Debian is just plain ignorant, and when the article links to the publicly-available-on-the-web standard, being so ignorant is quite inexcuable.
If you were to actually read the standards document, the requirement is:
Distributions must provide a mechanism for installing applications in this packaging format with some restrictions listed below. [2]
And if you were to look for note [2] you would find that it reads:
[2] The distribution itself may use a different packaging format for its own packages, and of course it may use any available mechanism for installing the LSB-conformant packages.
The point of LSB is to allow third party applications to be portable across distributions. That does not mandate anything about how a distribution chooses to package the Linux kernel, GLIBC, or much of anything else that it itself chooses to package.
Indeed, nothing mandates that an LSB-compliant distribution even has its own packaging scheme. A distribution could have all the components required by LSB in all the right spots, and just plain put them there. No "packages;" just files.
There is a sizable set of tools used in the construction of Debian that are tightly tied to .deb packages.
apt is only the start of the "advanced" aspect of package management; what's far more critical are the set of development tools, like lintian, debscripts, jablicator, deb-make, deb-helper, equivs, dpkg-dev, apt-move, and such.
Eliminating all of that would be like telling the Linux kernel developers that they have to stop using C, and write Linux in assembly language.
It's not simply apt-get that "eliminates the dependancy hunt;": in order for the set of packages to be kept coherent, so they're not merely a jumble of RPMs of dubious provenance strewn across the Internet, you need the development tools.
To move Debian to RPMs would require rewriting all those tools for RPM use. There's merit to such an idea; if there were coherent tools for dealing with the development of a complete RPM-based distribution, you'd doubtless get better stability. But that's a big task, and your non-recognition of the issue doesn't make it go away...
This does nothing to help those that take on the task of seeing which "bits of crap" should stick, and which should be dropped on the floor.
I don't see that SCM automation does too much more than accelerate the rate at which crap gets thrown at the kernel.
As for the JVM-like thing, it seems unlikely to me that this would be fundamentally helpful. You would see performance really sucking, because DSP-like stuff (like image processing, audio processing, GUI rendering) massively benefits from being compiled for a specific architecture.
If people submit crap into CVS (or Subversion, or Aegis, or SCCS, or CSSC, or RCS, or whatever fabled system may be out there), what you've got is crap in the kernel.
Automated tools have merits, but one demerit is that they make it easier for people to submit a thousand bad
patches per day
The wonderful relevant quote, from Mitch Radcliffe:
Computers
let you make more mistakes faster than any other
invention in human history, with the possible exception of handguns
and tequila.
Any would-be fork has to put a lot more thought into the political processes than into the technicalities of which version management software to use, otherwise you're arming the teeming masses with tequila and handguns, and that's hardly going to lead to reliable kernels :-).
$3900 is a mite high, but high prices are not particularly surprising when something is being sold in its initial "units of 1 board to early implementors."
It obviously won't get wildly popular until they can get pricing a bit more competitive with the hardware emitted by Apple, but it's a little early to say that this will never happen.
MAI may be able to maintain a viable commercial business without prices ever falling to $100/unit, by the way...
If they have not released source code, and didn't license the binaries under some arrangement that gives you the right to demand source code (have we ever heard of a license like that???), then what they have done with the binaries has nothing to do with the accessibility of source code.
Ob-DesqView reference: It was a pretty neat system; at the time I used it, OS/2 was an alternative that was, for my purposes, preferable since it actually actively resisted crashes, which was important when coding fairly wildly-pointered C code...
The last release that I saw was not as stable as the second-last release, which was unfortunate. That might have been Microsoft playing their Windows isn't done until Foo crashes, consistently games....
You might find Alpha and StrongARM on the Intel list...
geometric mean performance on multiple kernels compiled through it reached 47% improvement over GCC.
The testing didn't involve compiling kernels at all.
The 47% performance improvements were on a numerically intense benchmark program.
The preferences of the article's authors is pretty clear:
"Nonetheless, the magnitude of the performance differential in numerically intense applications is such that only the most dramatic sort of improvement in the long-awaited version 3 of the GNU C/C++ compiler will stay the hammer that drives a stake through the fibrillating heart of the aging technology behind the GNU C compiler. May it rest in peace."
These are not the words of objective observers, and such comments strike me as being quite irresponsible.
There were indeed some deadline issues, which makes it difficult to generate a flawless product.
This is going to be a problem with any situation where there is urgency in getting the book pushed out. Donald Knuth may have the "clout" to get Addison Wesley to wait for him to be happy with the results; that is definitely not going to be the case for these sorts of books with garish red covers.
At any rate, it's not obvious just what the results of taking over RHAT would be. There are ample possibilities for both good and ill, from many perspectives:
On the one hand, "If AOL/TW thinks there's something to it..." but then if they do something silly, credibility can get badly hurt.
Enter a new set of "policy controllers." Again, this can be good or bad.
Ambiguous again.
One interesting effect, regardless, is that a bunch of people that invested in RHAT will get some pretty substantial value out of it. If things go bad, Debian is still there, and we might see some made-rich hackers get into new involvements. Hopefully a little more computing-related than jwz's DNA Lounge, but that's not to be a flame of jwz...
If the result is that AOL/RHAT "craters," there's always Debian, Slackware, Mandrake, SuSE, and the BSDs still around...
After all, if I'm running:
how is it that you would think that all of these would concurrently make their relevant updates to what's on the screen...
WITHOUT A WHOLE WHACK OF CONTEXT SWITCHES?!?!?!?!
The notion that context switches are some inherent evil that must be expunged seems typically to be an evidence that the writer needs to get severely thrashed with several clue sticks.
Having too many context switches would obviously be a Bad Thing. But the notion that the separation of client and server is synonymous with "too many context switches" is just silly.
Consider the oft-commended alternative, NeXTStep, with its Display Postscript. In its architecture, applications use a client library to connect to a server process that runs the Postscript interpreter that they call the NX agent. The classic criticism of the NeXT architecture is that the PS implementation is typically single-threaded, thus meaning that you can get a pile of extra latency when other processes might be trying to get a context switch in edge-wise, but are BLOCKED.
It's one thing to make informed criticism of X, but to claim that things are bad about it that would be just as true of alternative architectures just demonstrates ignorance.
Anyone who doesn't believe this, feel free to go off and run GNUMail , the GNUStep mail application. Watch what processes it connects to. If X was replaced by a "direct DPS atop framebuffer," the client/server connections would NOT GO AWAY.
Possibly it might get called X?
The misunderstandings of how X works on systems today seem pretty rife...
It's not something that will be of vast interest for applications just yet; if it enters "ordinary kernels" in 2.5.something, that's certainly a good step towards it.
The Really Cool thing to use this sort of thing for would be to have user-space filesystem drivers, and mount things under (let's say) $HOME/mnt/
I should toy with it soon...
Just wait for Linux 2.5... Alex Viro had a namespace patch nearly a year ago, and other proposals have come along too...
Contrary to popular belief, it doesn't force huge gobs of "evil network transparency" in; that pretty much comes for free.
After all, there MUST be an IPC system involved, unless we were to transform it all into some sort of "cooperative multitasking" system with only one process (think: MS Windows, where if any bit of any application breaks, you have to reboot).
As soon as you have IPC, extending that to allow network transparency is pretty easy, and focusing on how "expensive" this is is just silly.
When you start with such huge misconceptions, that undermines the value of the whole discussion.