The BeOS file system, an OS geek retrospective • Hacker News Board

Re: The BeOS file system, an OS geek retrospective

#31

Post by jccalhoun » Fri, Jul 06, 2018, 12:56 PM UTC

johannes1234321 wrote: post #24

pbreit wrote: post #3

Why would BeOS not be open source at this point?

Because the incentives for going through with that are low. Most likely it contains some parts of third-party code under non-ooen license (i.e. in device drivers, but not only) and maybe some subsystems were licensed in some form of exclusive form to others. Also they might want to double check that code not by "accident" looks like somebody else (i.e. the ext2 code might be inspired by Linux's) This all leads to rev…

Basically this.

Access owns it. Even though they aren't doing anything with it, if they just released the code they would probably open themselves up to lawsuits over possible 3rd party code. So they would have to pay someone to go over the code to take out 3rd party stuff. That would take money for which there is no tangible benefit to them so they won't do it.

Re: The BeOS file system, an OS geek retrospective

#32

Post by snvzz » Fri, Jul 06, 2018, 1:00 PM UTC

silisili wrote: post #8

pbreit wrote: post #6

Earlier quoted context omitted.

My understanding is that there is not much BeOS in Haiku. "The only BeOS code that has made it into Haiku are Tracker and the Deskbar (the file manager and the equivalent of the start menu/taskbar, respectively)."

Understood...but then what is Haiku. I stil remember when r5 was released...an unheard of OS. As a tech geek I installed it and was blown away. Especially the media capabilities...two streams playing at once. That OS was way ahead of its time, and a shameful demise. I was excited about Haiku until I saw how far behind it was. And I mean absolutely 0 disrespect to its authors... but today it seems like an attempt to k…

>seems like an attempt to keep stable

No. They rewrote the whole thing (minus the deskbar/launcher). If it looks to you that they're just keeping the old system stable, that'd mean haiku has been very successful in recreating it as open source.

They're close to 1.0beta1, which is defined as feature-complete for 1.0. It's after they do get 1.0 that they plan on really taking the system's design forward.

Not that it doesn't already have a few fundamental improvements, such as the integrated kernel debugger, the support for newer architectures or the package manager.

Re: The BeOS file system, an OS geek retrospective

#33

Post by exikyut » Fri, Jul 06, 2018, 2:33 PM UTC

Theodores wrote: post #18

sohkamyung wrote: post #2

It's a reprint of an article from 2010, so perhaps (2010) should be added to the HN title, in case people are expecting to read something new about BeOS in 2018.

Which is typical of the product and the era. BeOS was like those Transmeta Crusoe CPUs, Segways and other products that gave journalists something to write about even if adoption was not going to happen. The circus aspect of the media wanting to write something (as they have pages to fill and eyeballs to feed) must be quite costly to small companies wanting to get a legit product out there. I can still remember the n…

I find it sad this is being downvoted. I think this rings true.

Perhaps too true?

HN has its bents and focuses, but it's at least more conversationally balanced than reddit (perhaps https://news.ycombinator.com/item?id=15965536 partially explains some of the reasons why). The news media is of course pure bias and content/distribution/agenda masquerading as fact-based objectivity (eg, https://youtu.be/hWLjYJ4BzvI).

Where else can I look for... the kind of apolitical, discussion-focused information sharing that eg used to happen on blogs circa 2007, but in discussion community form, and within a community framework that is bias-resistant?

Re: The BeOS file system, an OS geek retrospective

#34

Post by axaxs » Fri, Jul 06, 2018, 2:52 PM UTC

alain94040 wrote: post #9

silisili wrote: post #8

Earlier quoted context omitted.

Understood...but then what is Haiku. I stil remember when r5 was released...an unheard of OS. As a tech geek I installed it and was blown away. Especially the media capabilities...two streams playing at once. That OS was way ahead of its time, and a shameful demise. I was excited about Haiku until I saw how far behind it was. And I mean absolutely 0 disrespect to its authors... but today it seems like an attempt to k…

What would blow you away today? I’m always curious to know what to build next.

A truly convergent desktop. And I don't even know the details to explain what I would like, I probably wouldn't even know until I used it. I do know Android for Desktop is not it, though. Being able to throw apps from my phone to my pc to my tv would be nice too, and not so clunky as casting.

Re: The BeOS file system, an OS geek retrospective

#35

Post by S3raph » Fri, Jul 06, 2018, 3:09 PM UTC

I still remember running the r5 release on my Pentium III 450Mhz..never had such a lagfree and fast multimedia experience on any OS.. ZERO lag.. it's performance was amazing.. unfortunately it's lack of hardware support and multiuser made it problematic to use it as a daily driver. Even Beos Zeta (commercial version based on r5) did not really improve the situation.

Re: The BeOS file system, an OS geek retrospective

#36

Post by cpeterso » Fri, Jul 06, 2018, 3:36 PM UTC

A fun BeOS story from the 1999 Be Newsletter:

https://www.haiku-os.org/legacy-docs/benewsletter/Issue4-22....

A Testing Fairy Tale

Two test engineers were in a crunch. The floppy drive they were currently testing would work all day while they ran a variety of stress tests, but the exact same tests would run for only eight hours at night. After a few days of double-checking the hardware, the testing procedure, and the recording devices, they decided to stay the night and watch what happened. For eight hours they stared at the floppy drive and drank espresso. The long dark night slowly turned into day and the sun shone in the window. The angled sunlight triggered the write-protection mechanism, which caused a write failure. A new casing was designed and the problem was solved. Who knew?

Re: The BeOS file system, an OS geek retrospective

#37

Post by dman » Fri, Jul 06, 2018, 4:01 PM UTC

sureaboutthis wrote: post #25

fanf2 wrote: post #21

Earlier quoted context omitted.

4.4BSD systems on all architectures had 64 bit off_t since the early 1990s. It’s a crying shame that Linux didn’t copy more good ideas from the BSDs :-/

It's a crying shame we aren't using BSD more, period.

Some of us are.

Re: The BeOS file system, an OS geek retrospective

#38

Post by peatmoss » Fri, Jul 06, 2018, 4:05 PM UTC

fanf2 wrote: post #21

tialaramex wrote: post #11

Most important thing wrong with this article is that it keeps talking about BeFS having a "64-bit address space". That's not so at all. BeOS has the equivalent of the POSIX O_LARGEFILE permanently enabled. Historically 32-bit Unix systems assumed files were no larger than 2^31 bytes for the purposes of random access, and a feature labelled O_LARGEFILE says that your program wants 64-bit offset values instead so you c…

4.4BSD systems on all architectures had 64 bit off_t since the early 1990s. It’s a crying shame that Linux didn’t copy more good ideas from the BSDs :-/

Not that I'd want a return to the vendor wars per se, but I feel like the 90s were an interesting time for Free *nixen in part because there were so many competing alternatives to draw inspiration from.

A great deal of mindshare has been eaten up by Linux. And Linux has largely "grown up" and has incorporated many ideas (and in some cases code) from the commercial Unixes. But I do wonder how many people are out there who have broad perspective and ability to push things forward at the OS level.

Also, back in the 90s I feel like systems programming was cooler and had more cachet. Even if people weren't actively writing code for their OS of choice, the icons of programming were the folks working on the guts. Nowadays, I think the cool stuff is all happening pretty far up the stack, and that there are relatively few people working on the substrate.

That's just my impression though. I'd be delighted for someone to look at kernel and system contributions to Linux, IllumOS, and the BSDs and convince me that there is sustainable mindshare to go around, and that all these OSes have a bright future.

Re: The BeOS file system, an OS geek retrospective

#39

Post by peatmoss » Fri, Jul 06, 2018, 4:14 PM UTC

jacobolus wrote: post #13

gigatexal wrote: post #10

Having never played with BeOS but dabbled with Haiku — the richness of the BeOS filesystem would have won me over in a heart beat. Imagine if Microsoft bought them and then actually shipped a proper reFS that had the same richness? Or if Apple had — meh, Apple should have just paid Oracle the license fees and licensed ZFS. Or co-opted openZFS (not sure if that’s possible either, legally).

Apple hired the author of BeFS to work for them. He has worked on Spotlight, Time Machine, Apple's file systems, etc. http://www.nobius.org/dbg/

The one thing that I never saw make the leap from BeOS to other operating systems in a meaningful way was the "an application is a thin wrapper around a directory of metadata-enriched files" model that BeOS did.

I think the mail application and the media player were largely built this way because Be needed to build a handful of demonstration applications quickly and cheaply. On the other hand, I remember thinking how nice it was that email and multimedia behaved like the file browser with all its search and filtering features.

iTunes always felt like the exact antithesis of the BeOS model. It was a heavyweight application that had its own interaction model and idiosyncrasies. It might as well have been its own OS by comparison.

Re: The BeOS file system, an OS geek retrospective

#40

Post by [deleted] » Fri, Jul 06, 2018, 4:38 PM UTC

fanf2 wrote: post #21

tialaramex wrote: post #11

Most important thing wrong with this article is that it keeps talking about BeFS having a "64-bit address space". That's not so at all. BeOS has the equivalent of the POSIX O_LARGEFILE permanently enabled. Historically 32-bit Unix systems assumed files were no larger than 2^31 bytes for the purposes of random access, and a feature labelled O_LARGEFILE says that your program wants 64-bit offset values instead so you c…

4.4BSD systems on all architectures had 64 bit off_t since the early 1990s. It’s a crying shame that Linux didn’t copy more good ideas from the BSDs :-/

[deleted]