Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The BeOS file system, an OS geek retrospective

arstechnica.com

Post reply on HN
Print view View original

21–30 of 52 posts

Re: The BeOS file system, an OS geek retrospective

#21

Post by fanf2 »

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 :-/

Re: The BeOS file system, an OS geek retrospective

#22

Post by m_eiman »

jacobush wrote: post #20
jacobolus wrote: post #13

Earlier quoted context omitted.

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/

Maybe that is why macOS has a similar way to access files by ID instead of by path? The .vol directory: http://www.westwind.com/reference/os-x/invisibles.html

I think that's a legacy from MacOS Classic, where there was a way of keeping a handle to a file that was independent of the file's name (so you'd still point at the same file even if it was renamed).

Re: The BeOS file system, an OS geek retrospective

#23

Post by fredoralive »

codezero wrote: post #7
pbreit wrote: post #3

Why would BeOS not be open source at this point?

Bought by Palm, then HP, then ??? I guess, try to navigate that corporate IP nightmare.

I think BeOS went Palm -> PalmSource -> Access (the embedded web browser people).

Re: The BeOS file system, an OS geek retrospective

#24

Post by johannes1234321 »

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 review of old contracts and code while serving no business (besides marketing to a niche of nerds)

Re: The BeOS file system, an OS geek retrospective

#25

Post by sureaboutthis »

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 :-/

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

Re: The BeOS file system, an OS geek retrospective

#26

Post by memsom »

pbreit wrote: post #3

Why would BeOS not be open source at this point?

The source code, with all the stuff removed that was licensed or probably violated some patent or GPL restrictions would be pretty useless.

It also suffers greatly from the lack of engineers working on it - as in some parts have a lot of comments, some nothing what so ever. Some parts look very well done, some parts less so.

Back in the day, I saw the code (those leaks were real) and one zip was able to fully compile (and this is where the PowerPC version of post R5.03 came from, I used to have it compiling on my old BeBox - long gone now) and the other was a much later version, but the zip was corrupt and half the files were garbled.

DISCLAIMER: No I don't have the code anymore, not that I would never share it if I did, and no, I have never worked for or contributed to the Haiku Project.

Re: The BeOS file system, an OS geek retrospective

#27

Post by AnIdiotOnTheNet »

zmix wrote: post #16
alain94040 wrote: post #9

Earlier quoted context omitted.

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

I want a new Desktop. Let's talk ;-)

Same here, but not Linux Desktop Distro #301, which is pretty much all anyone wants to make.

Re: The BeOS file system, an OS geek retrospective

#28

Post by memsom »

m_eiman wrote: post #22
jacobush wrote: post #20

Earlier quoted context omitted.

Maybe that is why macOS has a similar way to access files by ID instead of by path? The .vol directory: http://www.westwind.com/reference/os-x/invisibles.html

I think that's a legacy from MacOS Classic, where there was a way of keeping a handle to a file that was independent of the file's name (so you'd still point at the same file even if it was renamed).

You might find the file handle stuff comes from the fact that a lot of the Be employees were originally Mac developers at the start, and quite possibly because they wanted to support some of the features that were in the OFS (original File System, the Database like file system BeOS originally shipped with right up to the AA/PR1 releases. DR8.x definitely had the old file system.)

Re: The BeOS file system, an OS geek retrospective

#30

Post by therealmarv »

udkyo wrote: post #12

BeOS was delicious all around and it's a crying shame it didn't take off. It really felt like the Amiga's spiritual successor to me.

Heard of the story that BeOS nearly became the OS X for Mac?

https://9to5mac.com/2011/11/11/gassee-thank-god-apple-chose-...

Post reply on HN