>
to some extent, slower has become meaningless. Monolithic vs. Micro has become beyond/.
Yet one is bound to question why go for the extra complication of Mach if simple BSD is faster and no less flexible or safe than the Mach and BSD combination in Mac OS X.
And in several situations one really wants that extra performance, memory, robustness and simplicity a, well, faster, leaner, more robust and simpler design gets.
>
bsd is very, very useful
No one ever argued to the contrary.
>
Solaris whho needs it?
Anyone who needs more than two processors and can't go GNU/Linux.
While Mac OS X is useful - people do useful things with it -, how useful is a kernel which is slower but not more flexible or safe than a monolithic one? The whole idea of microkernels was flexibility and safety.
When one talks a microkernel, that's not a complete kernel. It is the basics of a kernel, one needs to add servers to that in order to get an OS kernel.
In Mac OS X, there is only one server: BSD. And it is mixed in a monolithic kernel with Mach.
Contrast that with the Hurd which has Mach (or L4) plus several servers, or the other BSDs that have no microkernels.
>
the migration isn't just to Unix. It's also migration to MySQL
That pretty much explains it.
>
coming from TPF, coded in assembly language for 4Kword pages, and a hierarchical database, that might seem pretty advanced
Yes, but TPF was rock-solid, while MySQL is a disaster.
Yes, it is good enough if you don't value your data and availability. But this is not the way to run a business - nor any kinda organisation.
Ultimately, the problem may not even have been MySQL itself, even if MySQL has been behind quite some site failures - Slashdot itself, Fastmail and so on -; but it probably have something to do that the kinda person that chooses MySQL over, say, PostgreSQL is also bound to make many other stupid tech decisions.
>
I'm really interested, by the way, to speak with some people who are deep (at least above their knees) in OWL and RDF. Planning on making a study at intelligent databases
You touched the point: there is no such thing as an intelligent database. And what people really want with the 'semantic web' is a mix of a well-structured database - even if they think they don't need it, due to widespread mumbo-jumbo such as 'unstructured data' - and richly marked-up documents.
In the end, the data problem comes down to two basic components: a sane general data model, of which there is precisely one - the Relational -, but the industry has spent the last 30 years trying very hard to avoid spending the effort and planning to implement it right; and shared schemas, which the industry has been misimplementing in XML, which is not fit for data.
Gnome Storage should be a step in the right direction, and it gets it right by not reinventing the wheel, just using PostgreSQL as its database engine.
This way we can test the waters without messing with the kernel. When the concept is tried, we can decide if we make PostgreSQL a required part of a GNU/Linux system, or a Hurd translator, or whatever.
>
But it's also a mistake to think that all you'll eventually need or want needs to be designed in right now.
That's why translators.
>
It's also a mistake to put things at a more deeper layer than they need to be.
For example, in the case of the Hurd?...
>
I'm pretty darned sure I've seen smaller implementations. Certainly, application compatibility for them isn't perfect -- but it's certainly Good Enough.
Really? So why aren't there everywhere?
Go ahead and create you own, say, Debian- or Gentoo-based distro with them. See how much you can run. Report back...
>
You yourself point out that the quick-and-dirty but real solution is often the one that wins in the market
Yet if we desire nothing better... well, we'll never get nothing better.
>
Why, again, hasn't the HURD been kicked out the door with POSIX support only?
I just told you. Is this a rhetoric question or are you just being tiresome?
BTW the Hurd is ready - it has one or two important limitations, and the move to L4 is underway, that's why the GNU Project isn't pushing it yet.
>
the amount of time it's taken for the HURD to become release-ready demonstrates its overambition.
Overambition? I don't think so. We really need to start planning to go from POSIX to something functional like Lisp; we really need multiple-servers microkernels. The problem with the Hurd is that it has hit problems with the Mach when (1) free software wasn't nearly as pop as today and (2) Linux became a quick and dirty but real alternative. Just like with SQL as a quick and dirty alternative to relational, the Hurd will take its time but will eventually emerge as something far superior.
>
Weren't you the one talking a while about all the Nifty Features that the HURD has and is working on that the other microkernel-based OSes don't have?
For what I have seen, VSTa has pretty much the same design of the Hurd, with something like translators and all.
It is a common mistake to think you have something faster just because you haven't yet designed in all you'll eventually need or want. Witness MySQL vs PostgreSQL.
>
the simple abstractions provided by VSTa and its libc
With such a simple libc, will VSTa have the application compatibility necessary to gain critical mass?
Sure the GNU libc is huge. But that's POSIX, and that's where the Hurd will bridge us from.
>
a kernel that fills one niche well will have people working hard to apply it to others -- see Linux being used in embedded space, even though that's far from its native environment.
And where, as you said, its not quite sane.
>
Will it be "designed with the same ultimate goals as the HURD"? Absolutely not. Will it be good enough, and (more likely to be) finished in a sane amount of time? Yes.
AFAIU, the Hurd is much farther along. It runs X, it networks. And interest in it grows as more and more people realise Linux is not quite the final answer. Maybe I was too lazy, but from what I've seen in VSTa's pages, it is little more than a standalone embedded toy system now.
>
I don't understand why microkernel people keeps saying that macrokernels are a unmainteinable mess. Modularity does NOT depend on being microkernel or not.
You probably only looked at single-server half-baked microkernels, like MkLinux, OSF/1, NeXTStep (Mac OS X, Darwin), MS WNT and the like. Take a look at the real stuff, like the Hurd or VSTa.
>
I can only conclude that this issue hits a few people at worst
Yet it is real, and has been ignored. It doesn't matter it is a corner issue, it exists and reflects a quality problem. That it has gone an year without resolution, even with multiple reports, is an issue. If you need a huge number of reports to get attention, I can only conclude Linux has grown too complext to be manageable, so you just prove my point.
In MS Windows, the userbase is so huge MS can't deal intelligently with such corner cases. In Unix, licenses are so expensive users get the attention to solve such cases - and even so sometimes it is just complex, witness Sun loosing eBay's account. And in Linux - well, perhaps it is too complex and that is why such corner cases get lost in the noise.
>
If there are such
terrible problems, then why am I not seeing them
on the Linux kernel mailing list?
First, most problems are reported not on linux-kernel but on lists specific to the subsystems. Take a look at this last year's archives on linux-lvm, linux-raid and linux-ext3 or something the like.
Second, me and others who reported them have been ignored, so we gave up reporting and insisting.
Slashdot Mirror
Yet one is bound to question why go for the extra complication of Mach if simple BSD is faster and no less flexible or safe than the Mach and BSD combination in Mac OS X.
And in several situations one really wants that extra performance, memory, robustness and simplicity a, well, faster, leaner, more robust and simpler design gets.
No one ever argued to the contrary.
Anyone who needs more than two processors and can't go GNU/Linux.
While Mac OS X is useful - people do useful things with it -, how useful is a kernel which is slower but not more flexible or safe than a monolithic one? The whole idea of microkernels was flexibility and safety.
That is not quite what the article said, nor the reality.
There are lots of other open or de facto standards besides POSIX that an OS can conform to, and Solaris does conform to several.
For example, LDAP is an open standard, SMTP and TCP/IP are de facto ones.
Even if you define the MS W16 API as once a 'proprietary standard', Sun's WABI conformed to it.
True, Sun loves to add proprietary apps. But those apps don't necessarily change the OS itself.
Not.
When one talks a microkernel, that's not a complete kernel. It is the basics of a kernel, one needs to add servers to that in order to get an OS kernel.
In Mac OS X, there is only one server: BSD. And it is mixed in a monolithic kernel with Mach.
Contrast that with the Hurd which has Mach (or L4) plus several servers, or the other BSDs that have no microkernels.
And they are meaningless.
There are two application of the 'open' term in Informatics.
Open systems conform to open standards. Solaris is an open operating system.
Open source, well, you know, Solaris ain't an open source OS.
Yet Gnome is rapidly approaching.
They are both BSDs.
Not true. The Mac OS X is a monolithic, perverse mix of the BSD kernel and the Mach microkernel.
Not yet. Slony II is planned to.
Now what I really crave for are UPDATEABLE MATERIALIZED VIEWS.
Jasmine is not to be missed. It was yet another of those aberrations, an OORDBMS - or in other words, a contradiction in terms.
While current Ingres also violates the relational model by grafting SQL misfeatures even to its QUEL flavour, it perhaps could be made sane.
We had something the like in Brazil. We threw it out together with the last military dictatorship.
Funny about how the guy speaks only about RPM-based distros, and then his demo is based on Debian!
That pretty much explains it.
Yes, but TPF was rock-solid, while MySQL is a disaster.
Yes, it is good enough if you don't value your data and availability. But this is not the way to run a business - nor any kinda organisation.
Ultimately, the problem may not even have been MySQL itself, even if MySQL has been behind quite some site failures - Slashdot itself, Fastmail and so on -; but it probably have something to do that the kinda person that chooses MySQL over, say, PostgreSQL is also bound to make many other stupid tech decisions.
You touched the point: there is no such thing as an intelligent database. And what people really want with the 'semantic web' is a mix of a well-structured database - even if they think they don't need it, due to widespread mumbo-jumbo such as 'unstructured data' - and richly marked-up documents.
In the end, the data problem comes down to two basic components: a sane general data model, of which there is precisely one - the Relational -, but the industry has spent the last 30 years trying very hard to avoid spending the effort and planning to implement it right; and shared schemas, which the industry has been misimplementing in XML, which is not fit for data.
There are plenty of ways to prevent this. The simpler, obviously, is to implement the directory struture in the database.
Gnome Storage should be a step in the right direction, and it gets it right by not reinventing the wheel, just using PostgreSQL as its database engine.
This way we can test the waters without messing with the kernel. When the concept is tried, we can decide if we make PostgreSQL a required part of a GNU/Linux system, or a Hurd translator, or whatever.
That's why translators.
For example, in the case of the Hurd?...
Really? So why aren't there everywhere?
Go ahead and create you own, say, Debian- or Gentoo-based distro with them. See how much you can run. Report back...
Yet if we desire nothing better... well, we'll never get nothing better.
I just told you. Is this a rhetoric question or are you just being tiresome?
BTW the Hurd is ready - it has one or two important limitations, and the move to L4 is underway, that's why the GNU Project isn't pushing it yet.
Overambition? I don't think so. We really need to start planning to go from POSIX to something functional like Lisp; we really need multiple-servers microkernels. The problem with the Hurd is that it has hit problems with the Mach when (1) free software wasn't nearly as pop as today and (2) Linux became a quick and dirty but real alternative. Just like with SQL as a quick and dirty alternative to relational, the Hurd will take its time but will eventually emerge as something far superior.
For what I have seen, VSTa has pretty much the same design of the Hurd, with something like translators and all.
It is a common mistake to think you have something faster just because you haven't yet designed in all you'll eventually need or want. Witness MySQL vs PostgreSQL.
With such a simple libc, will VSTa have the application compatibility necessary to gain critical mass?
Sure the GNU libc is huge. But that's POSIX, and that's where the Hurd will bridge us from.
How is it saner?
How it is less ambitious? Won't it be less useful then? Will it be a replacement for Linux as the Hurd is to be?
A proprietary port is not that useful... I wonder what was the goal of it.
In the whole, yes; but each module is more self-contained, thus the risk of changes is significantly lesser, and debugging gets easier.
In the long run it is. And that's what the Hurd is for.
And where, as you said, its not quite sane.
AFAIU, the Hurd is much farther along. It runs X, it networks. And interest in it grows as more and more people realise Linux is not quite the final answer. Maybe I was too lazy, but from what I've seen in VSTa's pages, it is little more than a standalone embedded toy system now.
And thats exactly what happens if you own a contract support with Sun.
But anyway, Sun will have problems too, as in their loss of the eBay account. Monolithic kernels doing POSIX are just too complex.
Not always. 2.4 + LVM + RAID5 + ext3 works. 2.6 not.
You probably only looked at single-server half-baked microkernels, like MkLinux, OSF/1, NeXTStep (Mac OS X, Darwin), MS WNT and the like. Take a look at the real stuff, like the Hurd or VSTa.
Yet it is real, and has been ignored. It doesn't matter it is a corner issue, it exists and reflects a quality problem. That it has gone an year without resolution, even with multiple reports, is an issue. If you need a huge number of reports to get attention, I can only conclude Linux has grown too complext to be manageable, so you just prove my point.
In MS Windows, the userbase is so huge MS can't deal intelligently with such corner cases. In Unix, licenses are so expensive users get the attention to solve such cases - and even so sometimes it is just complex, witness Sun loosing eBay's account. And in Linux - well, perhaps it is too complex and that is why such corner cases get lost in the noise.
But was it designed with the same ultimate goals as the Hurd, or will it have to change beyond any recognition to reach there?
First, most problems are reported not on linux-kernel but on lists specific to the subsystems. Take a look at this last year's archives on linux-lvm, linux-raid and linux-ext3 or something the like.
Second, me and others who reported them have been ignored, so we gave up reporting and insisting.