POSIX does not mean Unix. Many other operating systems have POSIX interfaces including Microsoft's NT and it's descendants. It's just an agreed specification of a userspace API. If you actually read the webpages whose links you post you would have realized this. On the Wikipedia POSIX page is a rather comprehensive list of "Fully POSIX-compliant" operating systems.
You are confusing QNX with OS X. It is OS X that is BSD layered on a microkernel. Follow the link in your post and actually read about Neutrino. You will realize it is vastly different from what you thought.
First a few generalizations. QNX scales well, especially from desktop class machines downwards. The monolithic Unixes scale well, especially from from 386 class machines upwards. Linux uses some rather interesting techniques to scale better than conventional Unix does in the downward direction.
Now, OS X has both a microkernel and a monolithic kernel. It implements most operating system services in the monolithic layer. This means it loses the primary benefits posited by a microkernel design while possibly incurring the "defects" of both approaches. It is not a microkernel design, it is an operating system that has a microkernel. The guys at NeXT were not interested in the lower layers of their operating system, they were focused almost entirely on the user space (and especially GUI) experience, and they nailed a good part of what they set out to do.
The GUI of OS X is very well done for a desktop GUI but it is not directly transferable to the embedded market. What is transferable, however, is the UI design skills that Apple has. That is why the iPod is such a great device, not because of OS X.
QNX and friends are a very different kettle of fish. They run things like networking, filesystems and display managers as "user processes" and have a tiny microkernel core. Licensees can easily exclude (or not load) whatever modules they don't need and run with the basic minimum.
As I recall OS X consists of the monolithic BSD atop of a microkernel and the networking, filesystems and display are all in the BSD layer. It's not comparable to QNX and I would not draw any conclusions from the success of some proper microkernel designs in embedded usage.
Operating system that consists of BSD layered on top of a microkernel, whose only compelling feature is its rather excellent UI, wants to compete in embedded space.
This is the same embedded market where constrained resources make extra layering in the kernel a no-no and the aforementioned UI is irrelevant.
Report the bug to the bugzilla or Launchpad. It would be useful if you also specified which variables are being misentered into the config file.
If you do this, in a clear manner, the bug will likely be fixed by an Ubuntite(sp?) or upstreamed and fixed by the inimitable Jody of Gnome/Gnumeric fame.
Of course, if you choose not to report the bug.....
One other thing to note is that the network has a "memory" too. Mobile networks have a configurable limit of how many messages they will hold waiting for a phone number (and how long they will hold them).
This has been a noted problem by many GSM providers. There are regular "message storms" around holidays ("Happy New Year" messages are the worst, think New York Times Square area) and major news/sporting events.
What many GSM providers now do is build a parallel messaging network that takes the text messages off the GSM control channel and distributes them, dropping back into the main GSM network at the nearest node to the recepient. In effect any jamming then only affects the node you are connected to (or just the nodes leading to the jump-off to the messaging network).
So yeah, it's true. It's also known and being worked around.
We all love to pour scorn (or other suitable liquid) on Floridians, but I just have to point out that Oxford was a university *before the colonies rebelled*
"Europe. Yeah, Europe. Where the history comes from."
I was a poor coder working in a country with unreliable power and a company that didn't have UPS's set up. Occasional power glitches would reboot my development station and force me to sit through the loooong fsck times (a long fsck'ing wait).
When Reiser3 came out with SuSE Linux, I was estatic. It felt somewhat faster for my usage patterns and my long fsck times were gone.
After a while I noticed that occasionally when resuming my interrupted work, blocks from one file I had open at the time would get stuck in the middle of another file. Code that was working before would fail at compile time with horrible screenfuls of bizarre errors.
This was okay, because it was pretty obvious what had broken and the time recovered from fsck could be used to restore the file from an older copy.
That was until I had a file that came very close to compiling. The chunk interchanged was such that the compiler was complaining about an undeclared function (missing header file problem in C). I almost "fixed" this automatically, when I realised that the function should not have existed in that file !!
I was suddenly worried about the state of the entire codebase, not just the section I was working on. What had changed, when and why were no longer questions I could answer with confidence. So I switched back to ext2 (and later to ext3).
When working on a difficult problem there are some things I need to have high levels of confidence in, and these include my OS and filesystem.
There are some issues. The first that comes to mind is when you incrementally make changes to different sections of a file.
Copy-on-write applied to a filesystem can ensure that logically sequential blocks end up scattered all over the disk. In memory it doesn't matter as much but on disks this can kill your IO rates.
At the rate disk sizes are growing it's way less complicated to waste disk space.
Now, I can see how a gasoline fuel cell could prove more effective than one that runs off of water/hydrogen/ methanol. Pound-for-pound, gasoline produces far more energy than hydrogen, and is more cost effective than methanol.
"Pound-for-pound" ??
Are you sure you don't mean "Litre-for-litre-at-room-temperature-pressurized-t o-atmospheric-at-sea-level"?
Hydrogen compresses significantly with ease. This gives it a "Pound-for-pound" greater than most fuels.
>Plus, I find it easier to rally behind the bad
>rendering of a cartoonish gecko than to rally
>behind a hat. (I mean, if we're talking kewl
>logos....)
Not a gecko, a chameleon.
SuSe's big problem now is how to make a cuddly chameleon plush toy (is this possible)
Slashdot Mirror
Not sure what the typical mass of a star is meant to be...
However, using Sol (and our solar system) as an example,
anything within an order of magnitude will no longer be a planet.
I think you need at least two orders of magnitude difference
for a "well defined" orbit.
(end of pointless information, now returning to your regular Slasdot)
POSIX does not mean Unix. Many other operating systems have POSIX interfaces including Microsoft's NT and it's descendants. It's just an agreed specification of a userspace API. If you actually read the webpages whose links you post you would have realized this. On the Wikipedia POSIX page is a rather comprehensive list of "Fully POSIX-compliant" operating systems.
...
Oh, and one last thing
Gotcha !!
You are confusing QNX with OS X. It is OS X that is BSD layered on a microkernel. Follow the link in your post and actually read about Neutrino. You will realize it is vastly different from what you thought.
First a few generalizations. QNX scales well, especially from desktop class machines downwards. The monolithic Unixes scale well, especially from from 386 class machines upwards. Linux uses some rather interesting techniques to scale better than conventional Unix does in the downward direction.
Now, OS X has both a microkernel and a monolithic kernel. It implements most operating system services in the monolithic layer. This means it loses the primary benefits posited by a microkernel design while possibly incurring the "defects" of both approaches. It is not a microkernel design, it is an operating system that has a microkernel. The guys at NeXT were not interested in the lower layers of their operating system, they were focused almost entirely on the user space (and especially GUI) experience, and they nailed a good part of what they set out to do.
The GUI of OS X is very well done for a desktop GUI but it is not directly transferable to the embedded market. What is transferable, however, is the UI design skills that Apple has. That is why the iPod is such a great device, not because of OS X.
QNX and friends are a very different kettle of fish. They run things like networking, filesystems and display managers as "user processes" and have a tiny microkernel core. Licensees can easily exclude (or not load) whatever modules they don't need and run with the basic minimum.
As I recall OS X consists of the monolithic BSD atop of a microkernel and the networking, filesystems and display are all in the BSD layer. It's not comparable to QNX and I would not draw any conclusions from the success of some proper microkernel designs in embedded usage.
It's not just that sentence that is vague, it's the whole article.
The article also reads like a press release, instead of the inside scoop AppleInsider would like us to believe it is.
I mean, who else but marketing would write:
industry leading integrated model and software advantage
So much verbiage, such little content.
Operating system that consists of BSD layered on top of a microkernel, whose only compelling feature is its rather excellent UI, wants to compete in embedded space.
This is the same embedded market where constrained resources make extra layering in the kernel a no-no and the aforementioned UI is irrelevant.
If this is true, colour me stupefied.
Report the bug to the bugzilla or Launchpad. It would be useful if you also specified which variables are being misentered into the config file.
.....
If you do this, in a clear manner, the bug will likely be fixed by an Ubuntite(sp?) or upstreamed and fixed by the inimitable Jody of Gnome/Gnumeric fame.
Of course, if you choose not to report the bug
One other thing to note is that the network has a "memory" too. Mobile networks have a configurable limit of how many messages they will hold waiting for a phone number (and how long they will hold them).
This has been a noted problem by many GSM providers. There are regular "message storms" around holidays ("Happy New Year" messages are the worst, think New York Times Square area) and major news/sporting events.
What many GSM providers now do is build a parallel messaging network that takes the text messages off the GSM control channel and distributes them, dropping back into the main GSM network at the nearest node to the recepient. In effect any jamming then only affects the node you are connected to (or just the nodes leading to the jump-off to the messaging network).
So yeah, it's true. It's also known and being worked around.
Miami University in Oxford, Ohio (Amusing ...)
We all love to pour scorn (or other suitable liquid) on Floridians, but I just have to point out that
Oxford was a university *before the colonies rebelled*
"Europe. Yeah, Europe. Where the history comes from."
Entirely true story.
I was a poor coder working in a country with unreliable power and a company that didn't have UPS's set up. Occasional power glitches would reboot my development station and force me to sit through the loooong fsck times (a long fsck'ing wait).
When Reiser3 came out with SuSE Linux, I was estatic. It felt somewhat faster for my usage patterns and my long fsck times were gone.
After a while I noticed that occasionally when resuming my interrupted work, blocks from one file I had open at the time would get stuck in the middle of another file. Code that was working before would fail at compile time with horrible screenfuls of bizarre errors.
This was okay, because it was pretty obvious what had broken and the time recovered from fsck could be used to restore the file from an older copy.
That was until I had a file that came very close to compiling. The chunk interchanged was such that the compiler was complaining about an undeclared function (missing header file problem in C). I almost "fixed" this automatically, when I realised that the function should not have existed in that file !!
I was suddenly worried about the state of the entire codebase, not just the section I was working on. What had changed, when and why were no longer questions I could answer with confidence. So I switched back to ext2 (and later to ext3).
When working on a difficult problem there are some things I need to have high levels of confidence in, and these include my OS and filesystem.
PS: This is one of the major reasons I run Linux.
There are some issues. The first that comes to mind is when you incrementally make changes to different sections of a file.
Copy-on-write applied to a filesystem can ensure that logically sequential blocks end up scattered all over the disk. In memory it doesn't matter as much but on disks this can kill your IO rates.
At the rate disk sizes are growing it's way less complicated to waste disk space.
Now, I can see how a gasoline fuel cell could prove more effective than one that runs off of water/hydrogen/ methanol. Pound-for-pound, gasoline produces far more energy than hydrogen, and is more cost effective than methanol.
t o-atmospheric-at-sea-level"?
Hydrogen compresses significantly with ease. This gives it a "Pound-for-pound" greater than most fuels.
"Pound-for-pound" ??
Are you sure you don't mean "Litre-for-litre-at-room-temperature-pressurized-
>Plus, I find it easier to rally behind the bad
>rendering of a cartoonish gecko than to rally
>behind a hat. (I mean, if we're talking kewl
>logos....)
Not a gecko, a chameleon.
SuSe's big problem now is how to make a cuddly chameleon plush toy (is this possible)
> #pragma is evil - anything after ....
What about the following, surely it's good ?
#pragma once