BeOS: The Alternate Universe's Mac OS X • Hacker News Board

Re: BeOS: The Alternate Universe's Mac OS X

#211

Post by MisterTea » Thu, Jan 09, 2020, 9:02 PM UTC

statico wrote: post #201

One of my favorite anecdotes about BeOS was that it had a CPU usage meter[1], and on the CPU meter there were on/off switches for each core. If you had two cores and turned one off, your computer would run at half speed. If you turned both off, your computer would crash. Someone once told me that this was filed as a bug against the OS and the response was "Works As Intended" and that it was the expected behavior. (Th…

The CPU monitor program was called Pulse and early versions allowed you to turn all the processors off and crash the machine. I think it was fixed in 3.something or 4.0.

The 8-way PIII Xeon was a Compaq someone tested BeOS on before it went into production. I Remember it being posted on some BeOS news site. There should be another screenshot or two with 25 avi files playing and a crap load of CPU hungry programs running at once. Impressive feat circa 2000. Edit: browse the screenshot directory for the other two. Amazing they survived time, internet, bit rot and my memory: http://birdhouse.org/beos/8way/

The BeOS scheduler prioritized the GUI and media programs so you could load the machine down to 100% and the GUI never stuttered and windows could be smoothly moved, maximized and minimized at 100% CPU. Rather, your programs would stutter. And everything was given a fair chance at CPU time.

Very nice design and the OS was built from the ground up for multimedia and threading for SMP. It was a real nice attempt at building a next generation desktop OS. Had no security even though it had basic POSIX compatibility and a bash shell. Security bits meant nothing.

Re: BeOS: The Alternate Universe's Mac OS X

#212

Post by rafaelvasco » Thu, Jan 09, 2020, 9:02 PM UTC

amatecha wrote: post #142

rwmj wrote: post #52

Haiku is really good. Would recommend anyone to try it out in a VM (I had it running on my actual laptop for a short time, but unfortunately my job pretty much requires me to run Linux so it couldn't stay). Haiku has a really responsive UI with a 90s look so you can actually tell what is a button.

Oh man, I really do miss the days of actual coherent UI that is clearly "readable". The trend of flat UI drives me crazy. So much wasted cognitive effort just to make sense of something on-screen.

Feel the same. Clean UI doesn't have to be flat. That said , "semi-flat" interfaces can look really good.

Re: BeOS: The Alternate Universe's Mac OS X

#213

Post by rasz » Thu, Jan 09, 2020, 9:05 PM UTC

tialaramex wrote: post #170

rusk wrote: post #164

Earlier quoted context omitted.

Also Amiga didn’t have hardware floating point whereas DX series of PCs in the 90s did. Essential for all those tricky 3D calculations and texture maps.

No. Hardware floating point was _Quake_ Quake has software full 3D which runs appallingly if you can't do fast FP, it's targeting the new Pentium CPUs which all have fast FPUs onboard, it runs OK on a fast 486DX but it flies on a cheap Pentium. Doom is just integer calculations, it's fixed point math.

Duke3D Build engine did use FPU for slopes :O http://fabiensanglard.net/duke3d/build_engine_internals.php Luckily you already needed at least DX2-66 to play the game comfortably so not many people stumbled onto this.

Re: BeOS: The Alternate Universe's Mac OS X

#214

Post by anthk » Thu, Jan 09, 2020, 9:09 PM UTC

rusk wrote: post #135

all2 wrote: post #65

Earlier quoted context omitted.

That's curious to me. Doom is specifically not 3D. Was it a publishing issue (that Doom and co weren't produced for the Amiga), or a power issue, or something else?

Doom didnt use polygons but it very much was 3D in any practical sense of the term.

No, it was "distorted" 2D, like cardboards put in perspective. Not 3D.

Re: BeOS: The Alternate Universe's Mac OS X

#215

Post by T-hawk » Thu, Jan 09, 2020, 9:13 PM UTC

all2 wrote: post #65

rusk wrote: post #16

Earlier quoted context omitted.

Remember when the Amiga bouncing ball demo was impressive? Ironically 3D graphics ended up being the Amiga's specific achilles heel once Doom and co came on the scene.

That's curious to me. Doom is specifically not 3D. Was it a publishing issue (that Doom and co weren't produced for the Amiga), or a power issue, or something else?

Doom's 3Dness or lack thereof only mattered to programmers. Players didn't care, to them Doom looked entirely 3D.

Re: BeOS: The Alternate Universe's Mac OS X

#216

Post by rasz » Thu, Jan 09, 2020, 9:14 PM UTC

drewfish wrote: post #173

AtlasBarfed wrote: post #125

Earlier quoted context omitted.

Ok, so this is the big BeOS thing I've heard. What technically enabled this on such limited hardware? Was there lack of security/containerization/sandboxing that made os call much faster and context switches better?

I think it was their thread/process scheduler. It had a section of priorities which got hard realtime scheduling, then lower priority stuff got more "traditional" scheduling. (Alas, I don't know too much about thread/process scheduling so the details elude me.) That way the playback threads (and also other UI threads such as the window system) got the timeslices they needed.

Isnt giving near real time priority scheduling to audio/video how Windows handles things those days? I think I read that somewhere last week under Linux kernel scheduler behaviour response discussion.

Re: BeOS: The Alternate Universe's Mac OS X

#217

Post by slim » Thu, Jan 09, 2020, 9:14 PM UTC

microtonal wrote: post #124

anthk wrote: post #55

Earlier quoted context omitted.

Linux could do that in 2001 just fine, and without crashing like Windows. XV was amazing. So was MPlayer.

High definition playback is still not as smooth as it could be in browsers on Linux (or if your CPU is fast enough, it will drain your battery more quickly), because most browsers only have experimental support for video acceleration. https://wiki.archlinux.org/index.php/Hardware_video_accelera...

I found Wayland more capable than xwindows in this regard

Re: BeOS: The Alternate Universe's Mac OS X

#218

Post by anyfoo » Thu, Jan 09, 2020, 9:16 PM UTC

asveikau wrote: post #90

AnIdiotOnTheNet wrote: post #47

Earlier quoted context omitted.

Security from what? Do user accounts really provide much benefit in the personal computing space? Where the median user count is 1? Neither OS had the kind of security that is really useful today for this usecase, which is per-application.

But a bunch of the methods we have for securing, say, mobile phones, grew out of user accounts. Personally I don't know Android innards deeply, but when I was trying to backup and restore a rooted phone I did notice that every app's files have a different owner uid/gid and the apps typically won't launch without that set up correctly. So it would seem they implemented per-app separation in this instance by having a u…

Then you'd maybe get something like iOS, where the POSIX uid practically does not matter at all, and the strong security and separation is provided by other mechanisms like entitlements...

Someone else pointed out that BeOS allegedly had "quality and security" problems in general (I myself have no idea), so that may indeed have led to problems down the line, whereas BSD was pretty solid. But I agree with the OP and don't think POSIX security in particular is much of a factor today.

Re: BeOS: The Alternate Universe's Mac OS X

#219

Post by rasz » Thu, Jan 09, 2020, 9:18 PM UTC

anthk wrote: post #214

rusk wrote: post #135

Earlier quoted context omitted.

Doom didnt use polygons but it very much was 3D in any practical sense of the term.

No, it was "distorted" 2D, like cardboards put in perspective. Not 3D.

No free look meant no perspective distortions in Doom.

Re: BeOS: The Alternate Universe's Mac OS X

#220

Post by anyfoo » Thu, Jan 09, 2020, 9:18 PM UTC

terminaljunkid wrote: post #107

AnIdiotOnTheNet wrote: post #47

Earlier quoted context omitted.

Security from what? Do user accounts really provide much benefit in the personal computing space? Where the median user count is 1? Neither OS had the kind of security that is really useful today for this usecase, which is per-application.

Yes, in short - users & groups serve as a rudimentary implementation of capabilities. Best example is Android. But there's more to it. Separating admin user from non admin user always has advantages and I do it even on Windows.

Best counter example to their point is iOS, though, where POSIX permissions don't play much of a role in securing the system and separation applications.