I can't seem to find the bug in the bug database right now, but there was a bug filed against cp on BeOS for not copying attributes. The DTS response was that since cp is an old shell program, making all sorts of wacky BeOS specific changes was undesireable. (or something like that:) They also pointed out the BeOS specific utils like copyattr, rmattr, et al.
I recall someone from Be mentioning scientific apps as another type of app that could benifit from the 'media' aspects of the OS. Database applications on the other hand are boring.:)(IMHO of course)
"The Homebrew Computer Club quickly formed in Silicon Valley. Bill Gates and Paul Allen dropped what they were doing and moved down to Albuquerque to be part of the action."
What was so hot about Albequerque? Oh why does it matter... whats so hot about Redmond?
Specifically, the BeOS GUI was written with the assumption that there is a single display device, always on the local machine, that has a frame buffer that can be directly accessed in memory space. This is fine for a single-monitor desktop machine, but will present problems if they try to support multi-monitor systems or remote terminals.
Well, not quite. It's may not be as pretty on multiple monitors or remote displays, but it's possible. The direct window API just maps framebuffer into your address space and tells you where not to draw. With multiple monitors you would just have to move the window from monitor to monitor all at once (kinda kludgy). With remote display you would run into the same nasty copy-fest that Xshm has to deal with.
partitioing: As far as partitioning of user and system data? It has that too. In the root directory you have the/beos directory and the/home directory, plus a bunch of fluff directorys filled with demos,symlinks,and devtools./beos is the system directory, and you aren't supposed to touch it./home belongs to the user and you can do whatever the hell you like with it within reason (deleting your/config directory generally being a bad idea).
You probably see a lack of security in BeOS because these rules aren't strictly enforced right now.
A problem that might make a port unfeasible on Linux is scheduler latencies.
The BeOS scheduler currently has a quantum of 1 ms, with a maximum of 3 ms available in a timeslice (correct me if I'm wrong). So a realtime priority thread could theoretically awake within a few ms of when it needs to run. This is important if you're listening to input from a turntable
On Linux, if I have been told correctly, the scheduler quantum is 10 ms. (again, I could be wrong) Not exactly optimized for quasi-realtime.
OS X is _not_ based on A/UX. It's based on NeXTSTEP. Having run both A/UX and NeXTSTEP (on black hardware), I can tell you that they have very little in common. (other than both being unices) A/UX is a pile of crap, NeXTSTEP is nifty.
Woohoo, now I can get my BOSC intake from more than one site....
BTW Rob, should you get anything resembling spare time in the next couple years, could you change that to "BeOS Central" rather than "BEOSCentral"? I'm such a pedant.
I think he was saying that the new libGL might depend on some other component like the app_server that would make it incompatible with the R4 app_server.
If that was true, then people would still be unable to run the app if they didn't have R4.1
Did that make sense? *rereads* Yeah.
It's not like libGL is so monolithic that it doesn't depend on other components that may have undergone _significant_ changes. Be can do this with the app_server protocol, for instance, because the interface is through a library and completely transparent to developers
Now, anytime some stupid-ass license/ideolgy/whogivesafuck flamewar comes up, you should be able to end it with a hearty "Shut the f$%^ up and get back to work!".
Seriously, though. Since when does developing software need to involve politics? Do you think normal people really give a rats ass? I'd wager no.
Slashdot Mirror
I can't seem to find the bug in the bug database right now, but there was a bug filed against cp on BeOS for not copying attributes. The DTS response was that since cp is an old shell program, making all sorts of wacky BeOS specific changes was undesireable. (or something like that :) They also pointed out the BeOS specific utils like copyattr, rmattr, et al.
I recall someone from Be mentioning scientific apps as another type of app that could benifit from the 'media' aspects of the OS. Database applications on the other hand are boring. :)(IMHO of course)
"The Homebrew Computer Club quickly formed in Silicon Valley. Bill Gates and Paul Allen dropped what they were doing and moved down to Albuquerque to be part of the action."
What was so hot about Albequerque? Oh why does it matter... whats so hot about Redmond?
Specifically, the BeOS GUI was written with the assumption that there is a single display device, always on the local machine, that has a frame buffer that can be directly accessed in memory space. This is fine for a single-monitor desktop machine, but will present problems if they try to support multi-monitor systems or remote terminals.
Well, not quite. It's may not be as pretty on multiple monitors or remote displays, but it's possible. The direct window API just maps framebuffer into your address space and tells you where not to draw. With multiple monitors you would just have to move the window from monitor to monitor all at once (kinda kludgy). With remote display you would run into the same nasty copy-fest that Xshm has to deal with.
security:
/beos directory and the /home directory, plus a bunch of fluff directorys filled with demos,symlinks,and devtools. /beos is the system directory, and you aren't supposed to touch it. /home belongs to the user and you can do whatever the hell you like with it within reason (deleting your /config directory generally being a bad idea).
It has modes bits just like unix.
partitioing:
As far as partitioning of user and system data? It has that too. In the root directory you have the
You probably see a lack of security in BeOS because these rules aren't strictly enforced right now.
Hmm, the sarcasm in the BeDope comments is almost to the point of being offensive.
I stand corrected then.
:)
How does this affect other applications though? Any worse than on BeOS? (since you have experience there as well
A problem that might make a port unfeasible on Linux is scheduler latencies.
The BeOS scheduler currently has a quantum of 1 ms, with a maximum of 3 ms available in a timeslice (correct me if I'm wrong). So a realtime priority thread could theoretically awake within a few ms of when it needs to run. This is important if you're listening to input from a turntable
On Linux, if I have been told correctly, the scheduler quantum is 10 ms. (again, I could be wrong) Not exactly optimized for quasi-realtime.
OS X is _not_ based on A/UX. It's based on NeXTSTEP. Having run both A/UX and NeXTSTEP (on black hardware), I can tell you that they have very little in common. (other than both being unices) A/UX is a pile of crap, NeXTSTEP is nifty.
Woohoo, now I can get my BOSC intake from more than one site....
BTW Rob, should you get anything resembling spare time in the next couple years, could you change that to "BeOS Central" rather than "BEOSCentral"? I'm such a pedant.
I think he was saying that the new libGL might depend on some other component like the app_server that would make it incompatible with the R4 app_server.
If that was true, then people would still be unable to run the app if they didn't have R4.1
Did that make sense? *rereads* Yeah.
It's not like libGL is so monolithic that it doesn't depend on other components that may have undergone _significant_ changes. Be can do this with the app_server protocol, for instance, because the interface is through a library and completely transparent to developers
Speed would be te biggest reason to use BeOS as opposed to a unix/X11 combo. X is just too much of a pig to hold a candle to BeOS.
Hell, the kernel is in great shape, maybe someone should write a fast gui rather than continue to pile code on top of X.
Intel's cpus are acceptable? Excuse me?
Only because I can't think of anything else off the top of my head that might let you do multi-monitor w/ win95.
I run R4 on a setup _very_ similar to the one you describe.
P2 266
FireGL 1000 pro (agp)
Generic S3
Win98
Currently I'm not using the FireGL 1000, but win98 thinks it's monitor #2. BeOS sees the supported card just fine.
I've got an extra copy on videotape (vhs).
Still in the wrapper and everything...
BeOS left the "developers only" scene in July of '97.
"... That will give us all 10% raises.."
Or something along those lines... Of course I got that from The Simpsons.
Makes me feel a little better 'bout the whole intel thing.
... hope we don't get slashdotted... Eh, what am I worried about? I'm pretty sure Dreamhost is /. effect tolerant...
Here's a new OSS mantra : "Shut up and code!".
Now, anytime some stupid-ass license/ideolgy/whogivesafuck flamewar comes up, you should be able to end it with a hearty "Shut the f$%^ up and get back to work!".
Seriously, though. Since when does developing software need to involve politics? Do you think normal people really give a rats ass? I'd wager no.
I'm done ranting....
-prok
No, wait! Lets make a list of lists!
Personally I think the whole KDE/Gnome thing is bullshit. People are throwing away effort on code that still has X underneath.
mmmmOrbital. I think it's time for some orbital. Thanks for reminding me :)
Well, google is my new found friend, and I was actually looking for something that would allow me to put a slot 1 cpu into a socket 8 mobo.
Where do you get them and how much do they cost?
Isn't that what traps are for? I'm not entirely clear on linux's usage of traps, but I thought you could use them for stuff like syscalls