Linux has more than a few things that go in its favor, at least for the time being. The idea of open-source software is an amazing one. The fact that Linux isn't much of a commercialized operating system, and you can accomplish day-to-day tasks without too many hassles is an advantage in itself.
Um, dude, Mac OS X has a proprietary GUI... but it's ALSO running on an open source operating system. It runs the same amazing open source software as Linux, including the compiler and your X11 and Gnome and KDE desktop apps (if you want tham). It's got some shortcomings on the server, because of the overhead of Mach messages and threads, but that's not its focus. On the desktop it's got every advantage that Linux has, as well as having all the proprietary and commercial software that came along from the classic Mac OS.
And no matter what Linux does between now and 2007, no matter what new cool things are created for it, those things will also be options for Mac OS X.
And Mac OS X is well past questions like "can it replace Windows": the real debate now is "can Windows catch up".
OS X is not designed as a server OS. It's better at it than OS 9 because it's based on a timesharing OS rather than a gaggle of accidental hacks as classic Mac OS was, but that's not what the majority of the past 15 years of development at NeXT and Apple have been dedicated to.
But since it *is* based on the same timesharing OS as Linux is (don't give me a hard time about Linux not being real UNIX, or what GNU stands for, or source-code-Unix versus Trademark-Unix, Linux is a perfectly good implementation of UNIX and it does a reasonable job at it) it doesn't really matter whether you use Linux or FreeBSD or Solaris or Darwin or Mac OS X on your servers, a Mac OS desktop is a great accompaniment to them.
When you borrow a book from a library, you don't expect to get a mint condition copy, so "borrowing" a book from a store has a direct impact on the next customer or on the store, but it has the same impact on the author as borrowing it from the library or a friend or buying it from a used book store.
This direct effect doesn't apply for software, since software's all digital... it doesn't get stained or shopworn or slobbered on by pets.
By the way, a friend of mine once told me they'd used this same technique to "borrow" a videocamera for a wedding, and my reaction was the same as yours. The argument that the store didn't lose anything because they would shrinkwrap it and sell it as new didn't help me feel any better about the whole practice.
I find it hard to imagine a way in which the BSD community can claim credit for MacOS X.
You don't consider McKusick and the rest of the folks who developed the BSD kernel code that NeXT used in NeXTstep as "part of the BSD community"? I mean, OK, I can see you having a hissy-cow about Apple hiring Jordan instead of Chris or someone from the NetBSD team, but I think of BSD as going back further than Net/2 or 4.4-Lite.
And in any case, there's more than just the FreeBSD userland in Darwin. There's an awful lot of kernel code as well, since NeXTstep was originally based on the AT&T-tainted codebase and I'm sure they replaced that code as they transitioned from NeXTstep to OS X. Otherwise, how did they release it as open source?
The same rationalization is floated at all the warez and P2P sites, and it just doesn't hold water. The network effect may be real (up-front loss in sales yields free advertising and subsequent monetary transaction), but it is neither as large or as desirable as they make it out to be.
Personally, I see the network effect as a cost of piracy to the market as a whole, rather than a benefit or otherwise to the company whose software is being pirated. Where it is a benefit, it generally hurts the industry by reducing competition. Why buy a copy of Star Office for half the price of Microsoft Office when you can get Microsoft Office for "free"? The network effect is a powerful tool for turning a majority position into a monopoly one by plucking the low hanging fruit that might have otherwise allowed a competitor to grow.
There are definitely cases where the network effect is real, and piracy of Mac OS X may be that rarest of cases where it might actually benefit the market by reducing the value of a monopoly created by the network effect, but that benefit is far less than the cost of its role in creating the monopoly in the first place, and any pirate who claims it's a "justification" for his piracy is playing someone for a fool... himself, most likely.
My wife brought up an interesting point last night. She was talking about a friend who buys books from the store, reads them and returns them. I was pretty indignant about this, and felt it was highly amoral. However, it occurred to me that it's very similar to software piracy, which I don't frown upon the same way. Anybody have any thoughts on this?
Both are amoral, and I don't approve of either. However, I would like you to replace the phrase "buys books from the store" with "borrows books from the library" and see how that might change things...
OpenFirmware/EFI - I'm hoping for OpenFirmware, but ANYTHING other than the standard old BIOS.
Apple has already stated that they will not be using Openfirmware. They will be using Intel's chipset and they may well use a conventional BIOS. In any case, it doesn't matter: we already have the source code to the second stage bootloader in the OpenDarwin source tree. This approach could be used to (for example) keep Windows off Macs, or alongside a certificate repository maintained by the trusted chipset to keep you from running a cracked Mac OS X kernel to sniff DRM-related traffic going to iTunes (or the DVD player, or other DRM-aware application), or to keep iTunes DRM from working on a cracked kernel at all, but it can do little to keep Mac OS X off Wintel clones.
Signed Kernel - I wouldn't be suprised to see Apple use some kind of integrety check on the kernel during boot.
We already have the source code to the Darwin release corresponding to 10.4.1. People have already replaced components in Mac OS X with modified versions of the corresponding components in Darwin to get Mac OS X running on unsupported Apple and Mac clone hardware. It is unlikely that the kernel could be used this way. Any such check would be more likely in the upper layers of the OS, Quartz and Aqua, long after boot.
There's no reason to bother with VMware or Sheepshaver or MOL/MOM except as a diagnostic tool for figuring how to crack the copy protection. Once cracked, the OS could be run on any hardware for which drivers exist.
The only thing in the story that is attributable to Apple is the same statement that has been widely misquoted since last Monday, that Apple would not "enable" running Mac OS X on non-Apple hardware.
But Apple has stated that it would prevent users from installing OS X on non-Mac hardware.
The video clip I saw said that Apple would not enable Mac OS X to run on non-Mac hardware. This is the only statement I've seen or heard so far. This story does not present any new statement from Apple, nor even any statement at all, and it also says:
An Apple spokeswoman declined to comment for this story, saying that the company it is not yet ready to reveal product specifications.
Thus we do not know anything more about Apple's plans than we did last Monday.
A spokeswoman for the TPG confirmed to vnunet.com that there is nothing preventing Apple from implementing the module.
This is obviously true, but we already knew that hardware copy protection in OS X is an option for Apple, so this is still not news.
I would not be at all surprised if Apple did have some plans along these lines, but there's nothing in this story to support the headline "Security Chip to limit OS X to Macs" or "Apple to Lock OSXi to Apple Hardware".
No, I'm not kidding. I was running NT4, Rhapsody, and BeOS on a Pentium with 16M.
Microsoft Office needed lipisuction even then, and there's lots of other similarly hoggy apps on Windows, and the BeOS application base is much smaller and tighter. But just running Tracker in 16M was enough to send BeOS thrashing while Windows NT 4, the contemporary IE and Netscape, and other small (back then, they weren't so big, you know) applications ran well, and even Office degraded more gracefully.
16M now is ridiculously small, yes. Back then I was using spare 386/20s and 486/33s running FreeBSD in 5-8M as routers, DNS servers, webservers, and the like. In that time and place, BeOS was a hog.
Re:BeOS _is_ a member of the UNIX family.
on
Zeta Goes Gold
·
· Score: 1
all BeOS has is the good ol' bash shell and an almost-compatible POSIX layer (hey, where's your mmap for example, why is fork broken??)
You don't need mmap to be a member of the Unix family, unless you want to take the position that vanilla System III, Version 7, and all previous versions of Unix were not members of the Unix family.
You don't even need a standard fork() to be a member of the Unix family. A lot of early Unix implementations only had a spawn() mechanism or something similar to vfork()... even Bell Labs did at least one of those.
Same with multi-user capabilities. There's lots of embedded systems, even with genuine Unix code in them, that never come up to multiuser mode.
To say BeOS is in the Unix family would be like saying windows with cygwin is part of the unix family.
Um, I already addressed that when I talked about the POSIX subsystem and Interix. Cygwin and Interix are "hosted Unix" or "Unix family" implementations like Eunice, Phoenix, and the Software Tools virtual OS. They are independent subsystems where the hosting operating system does not depend on them to run. BeOS is not like that.
And it doesn't matter what Be's goal was, any more than it matters whether GNU stands for "Gnu's Not Unix" or a big hairy animal. "The Unix family" is a practical definition based on what an OS does and how it behaves, not what it was designed to do or how it's implemented or what other capabilities are available alongside the traditional Unix ones.
If an operating system implements and requires the Unix environment, then you can assume that sufficiently portable Unix software will always be able to run on it, that Unix software will be able to examine and manipulate it, that porting a typical Unix application to it is is a matter of tweaking rather than re-implementing.
It doesn't mean that an application that uses Linux or BSD or System V enhancements to Unix will work easily... but that's already true even within the "Trademark Unix" and "Source code UNIX" lineages. It's only the fact that so many Unix family systems these days incorporate BSD and System V enhancements like mmap and semop and support the latest GCC that causes confusion.
No, it's not POSIX. But for someone used to a variety of Unix systems it's well within the variations that exist elsewhere.
Yeah, but the BSD that's on it is the mutant survivor of a Mach 3 collision.
So? That's not visible to applications from userland unless they're deliberately doing unportable things... who cares how the kernel's implemented, as long as the APIs are there? If the differences between BSD and Linux don't bother you, then surely the smaller difference between FreeBSD and Darwin can't matter.
Re:Long time BeOS expert...
on
Zeta Goes Gold
·
· Score: 1
Most of the IP of BeOS has made its way into OSX or Linux via folks contributions or jobs. Spotlight is basically BFS graphed into the HFS.
Neither of these sentences are meaningful. First, the architecture of Linux and BeOS are radically different, all that I can imagine it borrowing from BeOS are userland and application components. Second, Spotlight is the exact opposite of BeFS: it can metadata and other material provided by applications through its API, but it mostly indexes the contents of files and its store is NOT in HFS or dependant on HFS: what it mostly uses HFS for is avoiding hierarchy traversals to find changed files. It's more like "locate" on steroids.
Re:Long time BeOS expert...
on
Zeta Goes Gold
·
· Score: 1
my point is they could have stlll had a proprietary user space with all the drivers that linux offers [...]
I don't think that it's the userspace that's the interesting or important bit of BeOS.
This is like some of the "new Amiga OS" schemes based on Linux... what made AmigaOS interesting and useful is not something that you can get from emulating the userland on top of a different kind of kernel. Which is why I'm glad that the latest "new Amiga" is based on a reimplementation of the Amiga Exec, and why I'm glad that Haiku is not just another Linux or BSD kernel with a GUI on top.
Just what does Zeta have?
on
Zeta Goes Gold
·
· Score: 1
Just what is Zeta basing their OS on? Is it just a licensed version of the released BeOS binaries and their own code, or do they actually have Be source code? I've never quite found a straight answer on their site.
Re:Do you still have to program it with C++?
on
Zeta Goes Gold
·
· Score: 1
That's certainly part of the problem with BeOS for me, for sure. Though while I'm happier with Objective C I'd still rather there was a less language-dependent API for OS X and Quartz than Cocoa, other than Carbon. I'm glad Carbon is there, as an option, but it originated as a Mac OS compatibility layer.
Re:BeOS _is_ a member of the UNIX family.
on
Zeta Goes Gold
·
· Score: 1
BeOS is not Unix, never was Unix, and never will be Unix
Now I'm pretty sure that I said "BeOS is a member of the UNIX family of operating systems", not "BeOS is UNIX", but I could be mistaken. Maybe it was off in another parallel universe or something.
it just happens to provide a POSIX compatibility layer and a bunch of ported command-line tools
It's is much more than that. BeOS boots like UNIX, it UNIX shell scripts and the UNIX API to launch services and utilities, it uses a UNIX process hierarchy to handle the interrelationships between processes, it presents a UNIX file hierarchy with a single root and a uniform view of files, and it uses all these things to manage its own operation. Pull these APIs and this environment out of the system, and it wouldn't boot, it wouldn't run, there really wouldn't be a BeOS left. This is quite different from a "POSIX compatibility layer" like the Windows NT POSIX subsystem or Interix.
But internally, it's quite different.
That's an implementation detail. Really.
It doesn't matter whether the "open" system call is implemented by passing a message to the file server process, by passing a message to the bsd subsystem, by a call to libc_emulator, by context switch to the kernel and a lookup on a system call table, or by handing a piece of paper with the name of the file on to the demon-king. The Unix API is what defines a Unix environment, no matter how that API is implemented, and an OS is a member of the Unix family of operating systems if that environment is part of its foundation.
You think? I don't know if the lessons have really been learned yet. Look at Google's market cap lately?
Re:For the Nth time, can someone explain the jargo
on
Zeta Goes Gold
·
· Score: 1
With Linux today I...
Stop right there. If your standard of comparison for media is Linux, any operating system will look good.:)
Ever wonder why there are 1000 amateur video players for BeOS? It's dead easy to do.
Same reason there's 1000 amateur video players for Mac OS X. It ships with a component for doing video. I wouldn't call it a "Media OS" on that account... I was hoping for something deeper (like, say, real-time scheduling or at least something inherent in the OS itself).
Re:What's the compelling reason to switch?
on
Zeta Goes Gold
·
· Score: 1
BeOS feels smoother and more responsive than any other system we've tried
It's a damn shame that BeOS didn't overlap more of the operating systems of the '80s, so it could have been compared fairly against them. The most powerful hardware I ever used AmigaOS or OS/9 (Microware, not Apple) on was maybe ten times slower than the slowest hardware I ever ran BeOS on, and while BeOS was a bit more responsive than either it's impossible to separate what part the OS and what part the hardware had in that experience.
BeOS _is_ a member of the UNIX family.
on
Zeta Goes Gold
·
· Score: 1
It's not free/Unix/OSX/real.
I don't know about this. BeOS is a very comfortable and familiar environment for a UNIX user, with a very complete and very "native" UNIX API that's not just something slapped on the side like (say) Interix is on Windows NT. I would happily consider BeOS a member of the UNIX family of operating systems.
For the Nth time, can someone explain the jargon?
on
Zeta Goes Gold
·
· Score: 1
2. It brings extreme multimedia capabilities to the x86-based PC.
I've used BeOS on and off for years. I used to have a box running 5.03 in my game/media room, just because I wanted to see how this "Media OS" fit in.
Frankly, I couldn't see anything in it that made it a "Media OS". It didn't run faster or handle video better than NT4 or Windows 2000 on the same hardware, and I had to add RAM to the box that had been running NT4 to make BeOS happy.
The only "Media OS" feature seems to be the ability to tag media with metadata in the filesystem, which is a dubious practice in the first place (unless you abandon all other operating systems, you have to duplicate the metadata anyway), and it doesn't seem specifically relevant to "media" over other kinds of data.
3. It features a heavily multithreaded microkernel
It features a multithreaded kernel with an internal API based on passing C++ objects around, anyway. Does that make it a microkernel? I don't know: most of the systems I see touted as "microkernels", like Mach, don't seem to be anything like the real-time message-passing kernels I'm used to from my work in the control-systems industry. The most microkernel-like OS I've seen on a personal computer actually predated the academic use of the term and wasn't ever described as one by the vendor.:)
If someone who is more intimately familiar with BeOS can comment on these points I'd appreciate it.
Finally an OS for x86 thats fast and resource efficient!
Fast, maybe... it never struck me as being anything exceptional. Resource-efficient? Well, for a mid-'90s OS it's pretty hefty... both NT4 and NeXTstep/Rhapsody were happy on systems small enough to make BeOS swap its little heart out.
Slashdot Mirror
Linux has more than a few things that go in its favor, at least for the time being. The idea of open-source software is an amazing one. The fact that Linux isn't much of a commercialized operating system, and you can accomplish day-to-day tasks without too many hassles is an advantage in itself.
Um, dude, Mac OS X has a proprietary GUI... but it's ALSO running on an open source operating system. It runs the same amazing open source software as Linux, including the compiler and your X11 and Gnome and KDE desktop apps (if you want tham). It's got some shortcomings on the server, because of the overhead of Mach messages and threads, but that's not its focus. On the desktop it's got every advantage that Linux has, as well as having all the proprietary and commercial software that came along from the classic Mac OS.
And no matter what Linux does between now and 2007, no matter what new cool things are created for it, those things will also be options for Mac OS X.
And Mac OS X is well past questions like "can it replace Windows": the real debate now is "can Windows catch up".
OS X is not designed as a server OS. It's better at it than OS 9 because it's based on a timesharing OS rather than a gaggle of accidental hacks as classic Mac OS was, but that's not what the majority of the past 15 years of development at NeXT and Apple have been dedicated to.
But since it *is* based on the same timesharing OS as Linux is (don't give me a hard time about Linux not being real UNIX, or what GNU stands for, or source-code-Unix versus Trademark-Unix, Linux is a perfectly good implementation of UNIX and it does a reasonable job at it) it doesn't really matter whether you use Linux or FreeBSD or Solaris or Darwin or Mac OS X on your servers, a Mac OS desktop is a great accompaniment to them.
"They won't allow OS X to run on just about any PC"
:)
In the video I saw he said "enable", not "allow".
I don't know if this distinction is important but it does seem like a less "aggressive" term.
What were you getting at exactly?
When you borrow a book from a library, you don't expect to get a mint condition copy, so "borrowing" a book from a store has a direct impact on the next customer or on the store, but it has the same impact on the author as borrowing it from the library or a friend or buying it from a used book store.
This direct effect doesn't apply for software, since software's all digital... it doesn't get stained or shopworn or slobbered on by pets.
By the way, a friend of mine once told me they'd used this same technique to "borrow" a videocamera for a wedding, and my reaction was the same as yours. The argument that the store didn't lose anything because they would shrinkwrap it and sell it as new didn't help me feel any better about the whole practice.
I find it hard to imagine a way in which the BSD community can claim credit for MacOS X.
You don't consider McKusick and the rest of the folks who developed the BSD kernel code that NeXT used in NeXTstep as "part of the BSD community"? I mean, OK, I can see you having a hissy-cow about Apple hiring Jordan instead of Chris or someone from the NetBSD team, but I think of BSD as going back further than Net/2 or 4.4-Lite.
And in any case, there's more than just the FreeBSD userland in Darwin. There's an awful lot of kernel code as well, since NeXTstep was originally based on the AT&T-tainted codebase and I'm sure they replaced that code as they transitioned from NeXTstep to OS X. Otherwise, how did they release it as open source?
The same rationalization is floated at all the warez and P2P sites, and it just doesn't hold water. The network effect may be real (up-front loss in sales yields free advertising and subsequent monetary transaction), but it is neither as large or as desirable as they make it out to be.
Personally, I see the network effect as a cost of piracy to the market as a whole, rather than a benefit or otherwise to the company whose software is being pirated. Where it is a benefit, it generally hurts the industry by reducing competition. Why buy a copy of Star Office for half the price of Microsoft Office when you can get Microsoft Office for "free"? The network effect is a powerful tool for turning a majority position into a monopoly one by plucking the low hanging fruit that might have otherwise allowed a competitor to grow.
There are definitely cases where the network effect is real, and piracy of Mac OS X may be that rarest of cases where it might actually benefit the market by reducing the value of a monopoly created by the network effect, but that benefit is far less than the cost of its role in creating the monopoly in the first place, and any pirate who claims it's a "justification" for his piracy is playing someone for a fool... himself, most likely.
My wife brought up an interesting point last night. She was talking about a friend who buys books from the store, reads them and returns them. I was pretty indignant about this, and felt it was highly amoral. However, it occurred to me that it's very similar to software piracy, which I don't frown upon the same way. Anybody have any thoughts on this?
Both are amoral, and I don't approve of either. However, I would like you to replace the phrase "buys books from the store" with "borrows books from the library" and see how that might change things...
OpenFirmware/EFI - I'm hoping for OpenFirmware, but ANYTHING other than the standard old BIOS.
Apple has already stated that they will not be using Openfirmware. They will be using Intel's chipset and they may well use a conventional BIOS. In any case, it doesn't matter: we already have the source code to the second stage bootloader in the OpenDarwin source tree. This approach could be used to (for example) keep Windows off Macs, or alongside a certificate repository maintained by the trusted chipset to keep you from running a cracked Mac OS X kernel to sniff DRM-related traffic going to iTunes (or the DVD player, or other DRM-aware application), or to keep iTunes DRM from working on a cracked kernel at all, but it can do little to keep Mac OS X off Wintel clones.
Signed Kernel - I wouldn't be suprised to see Apple use some kind of integrety check on the kernel during boot.
We already have the source code to the Darwin release corresponding to 10.4.1. People have already replaced components in Mac OS X with modified versions of the corresponding components in Darwin to get Mac OS X running on unsupported Apple and Mac clone hardware. It is unlikely that the kernel could be used this way. Any such check would be more likely in the upper layers of the OS, Quartz and Aqua, long after boot.
There's no reason to bother with VMware or Sheepshaver or MOL/MOM except as a diagnostic tool for figuring how to crack the copy protection. Once cracked, the OS could be run on any hardware for which drivers exist.
The only thing in the story that is attributable to Apple is the same statement that has been widely misquoted since last Monday, that Apple would not "enable" running Mac OS X on non-Apple hardware.
Here's the actual facts:
But Apple has stated that it would prevent users from installing OS X on non-Mac hardware.
The video clip I saw said that Apple would not enable Mac OS X to run on non-Mac hardware. This is the only statement I've seen or heard so far. This story does not present any new statement from Apple, nor even any statement at all, and it also says:
An Apple spokeswoman declined to comment for this story, saying that the company it is not yet ready to reveal product specifications.
Thus we do not know anything more about Apple's plans than we did last Monday.
A spokeswoman for the TPG confirmed to vnunet.com that there is nothing preventing Apple from implementing the module.
This is obviously true, but we already knew that hardware copy protection in OS X is an option for Apple, so this is still not news.
I would not be at all surprised if Apple did have some plans along these lines, but there's nothing in this story to support the headline "Security Chip to limit OS X to Macs" or "Apple to Lock OSXi to Apple Hardware".
No, I'm not kidding. I was running NT4, Rhapsody, and BeOS on a Pentium with 16M.
Microsoft Office needed lipisuction even then, and there's lots of other similarly hoggy apps on Windows, and the BeOS application base is much smaller and tighter. But just running Tracker in 16M was enough to send BeOS thrashing while Windows NT 4, the contemporary IE and Netscape, and other small (back then, they weren't so big, you know) applications ran well, and even Office degraded more gracefully.
16M now is ridiculously small, yes. Back then I was using spare 386/20s and 486/33s running FreeBSD in 5-8M as routers, DNS servers, webservers, and the like. In that time and place, BeOS was a hog.
You win.
all BeOS has is the good ol' bash shell and an almost-compatible POSIX layer (hey, where's your mmap for example, why is fork broken??)
You don't need mmap to be a member of the Unix family, unless you want to take the position that vanilla System III, Version 7, and all previous versions of Unix were not members of the Unix family.
You don't even need a standard fork() to be a member of the Unix family. A lot of early Unix implementations only had a spawn() mechanism or something similar to vfork()... even Bell Labs did at least one of those.
Same with multi-user capabilities. There's lots of embedded systems, even with genuine Unix code in them, that never come up to multiuser mode.
To say BeOS is in the Unix family would be like saying windows with cygwin is part of the unix family.
Um, I already addressed that when I talked about the POSIX subsystem and Interix. Cygwin and Interix are "hosted Unix" or "Unix family" implementations like Eunice, Phoenix, and the Software Tools virtual OS. They are independent subsystems where the hosting operating system does not depend on them to run. BeOS is not like that.
And it doesn't matter what Be's goal was, any more than it matters whether GNU stands for "Gnu's Not Unix" or a big hairy animal. "The Unix family" is a practical definition based on what an OS does and how it behaves, not what it was designed to do or how it's implemented or what other capabilities are available alongside the traditional Unix ones.
If an operating system implements and requires the Unix environment, then you can assume that sufficiently portable Unix software will always be able to run on it, that Unix software will be able to examine and manipulate it, that porting a typical Unix application to it is is a matter of tweaking rather than re-implementing.
It doesn't mean that an application that uses Linux or BSD or System V enhancements to Unix will work easily... but that's already true even within the "Trademark Unix" and "Source code UNIX" lineages. It's only the fact that so many Unix family systems these days incorporate BSD and System V enhancements like mmap and semop and support the latest GCC that causes confusion.
No, it's not POSIX. But for someone used to a variety of Unix systems it's well within the variations that exist elsewhere.
Yeah, but the BSD that's on it is the mutant survivor of a Mach 3 collision.
So? That's not visible to applications from userland unless they're deliberately doing unportable things... who cares how the kernel's implemented, as long as the APIs are there? If the differences between BSD and Linux don't bother you, then surely the smaller difference between FreeBSD and Darwin can't matter.
Most of the IP of BeOS has made its way into OSX or Linux via folks contributions or jobs. Spotlight is basically BFS graphed into the HFS.
Neither of these sentences are meaningful. First, the architecture of Linux and BeOS are radically different, all that I can imagine it borrowing from BeOS are userland and application components. Second, Spotlight is the exact opposite of BeFS: it can metadata and other material provided by applications through its API, but it mostly indexes the contents of files and its store is NOT in HFS or dependant on HFS: what it mostly uses HFS for is avoiding hierarchy traversals to find changed files. It's more like "locate" on steroids.
my point is they could have stlll had a proprietary user space with all the drivers that linux offers [...]
I don't think that it's the userspace that's the interesting or important bit of BeOS.
This is like some of the "new Amiga OS" schemes based on Linux... what made AmigaOS interesting and useful is not something that you can get from emulating the userland on top of a different kind of kernel. Which is why I'm glad that the latest "new Amiga" is based on a reimplementation of the Amiga Exec, and why I'm glad that Haiku is not just another Linux or BSD kernel with a GUI on top.
Just what is Zeta basing their OS on? Is it just a licensed version of the released BeOS binaries and their own code, or do they actually have Be source code? I've never quite found a straight answer on their site.
That's certainly part of the problem with BeOS for me, for sure. Though while I'm happier with Objective C I'd still rather there was a less language-dependent API for OS X and Quartz than Cocoa, other than Carbon. I'm glad Carbon is there, as an option, but it originated as a Mac OS compatibility layer.
BeOS is not Unix, never was Unix, and never will be Unix
Now I'm pretty sure that I said "BeOS is a member of the UNIX family of operating systems", not "BeOS is UNIX", but I could be mistaken. Maybe it was off in another parallel universe or something.
it just happens to provide a POSIX compatibility layer and a bunch of ported command-line tools
It's is much more than that. BeOS boots like UNIX, it UNIX shell scripts and the UNIX API to launch services and utilities, it uses a UNIX process hierarchy to handle the interrelationships between processes, it presents a UNIX file hierarchy with a single root and a uniform view of files, and it uses all these things to manage its own operation. Pull these APIs and this environment out of the system, and it wouldn't boot, it wouldn't run, there really wouldn't be a BeOS left. This is quite different from a "POSIX compatibility layer" like the Windows NT POSIX subsystem or Interix.
But internally, it's quite different.
That's an implementation detail. Really.
It doesn't matter whether the "open" system call is implemented by passing a message to the file server process, by passing a message to the bsd subsystem, by a call to libc_emulator, by context switch to the kernel and a lookup on a system call table, or by handing a piece of paper with the name of the file on to the demon-king. The Unix API is what defines a Unix environment, no matter how that API is implemented, and an OS is a member of the Unix family of operating systems if that environment is part of its foundation.
You think? I don't know if the lessons have really been learned yet. Look at Google's market cap lately?
With Linux today I ...
:)
Stop right there. If your standard of comparison for media is Linux, any operating system will look good.
Ever wonder why there are 1000 amateur video players for BeOS? It's dead easy to do.
Same reason there's 1000 amateur video players for Mac OS X. It ships with a component for doing video. I wouldn't call it a "Media OS" on that account... I was hoping for something deeper (like, say, real-time scheduling or at least something inherent in the OS itself).
BeOS feels smoother and more responsive than any other system we've tried
It's a damn shame that BeOS didn't overlap more of the operating systems of the '80s, so it could have been compared fairly against them. The most powerful hardware I ever used AmigaOS or OS/9 (Microware, not Apple) on was maybe ten times slower than the slowest hardware I ever ran BeOS on, and while BeOS was a bit more responsive than either it's impossible to separate what part the OS and what part the hardware had in that experience.
It's not free/Unix/OSX/real.
I don't know about this. BeOS is a very comfortable and familiar environment for a UNIX user, with a very complete and very "native" UNIX API that's not just something slapped on the side like (say) Interix is on Windows NT. I would happily consider BeOS a member of the UNIX family of operating systems.
2. It brings extreme multimedia capabilities to the x86-based PC.
:)
I've used BeOS on and off for years. I used to have a box running 5.03 in my game/media room, just because I wanted to see how this "Media OS" fit in.
Frankly, I couldn't see anything in it that made it a "Media OS". It didn't run faster or handle video better than NT4 or Windows 2000 on the same hardware, and I had to add RAM to the box that had been running NT4 to make BeOS happy.
The only "Media OS" feature seems to be the ability to tag media with metadata in the filesystem, which is a dubious practice in the first place (unless you abandon all other operating systems, you have to duplicate the metadata anyway), and it doesn't seem specifically relevant to "media" over other kinds of data.
3. It features a heavily multithreaded microkernel
It features a multithreaded kernel with an internal API based on passing C++ objects around, anyway. Does that make it a microkernel? I don't know: most of the systems I see touted as "microkernels", like Mach, don't seem to be anything like the real-time message-passing kernels I'm used to from my work in the control-systems industry. The most microkernel-like OS I've seen on a personal computer actually predated the academic use of the term and wasn't ever described as one by the vendor.
If someone who is more intimately familiar with BeOS can comment on these points I'd appreciate it.
Finally an OS for x86 thats fast and resource efficient!
Fast, maybe... it never struck me as being anything exceptional. Resource-efficient? Well, for a mid-'90s OS it's pretty hefty... both NT4 and NeXTstep/Rhapsody were happy on systems small enough to make BeOS swap its little heart out.