Practical File System Design with the Be File System (1999) [pdf] | Hacker News Reader

Practical File System Design with the Be File System (1999) [pdf]

nobius.org

If you want to look at a reimplementation of Be File System, here is Haiku's version: https://github.com/haiku/haiku/tree/master/src/add-ons/kerne...

+1 for Haiku. I am not a regular user but I listen to the developer list traffic and admiring hopefully; they are often fighting off the "one troll" that antagonizes the list, or of course bikeshedding about when and whether to have the next release, or if they should try and promote the nightlies more instead, since there hasn't been a release since Alpha4 (2012) and substantial progress has been made since then.

For anyone who is not in the know about the BeOS revival OS and its current events, I assure you that Haiku is not dead ;)

The recent addition of package management with recipes and a ports tree breathes new life to the single-user desktop OS. Two factors that get repeated by the list-complainers: 1) people that hardcoded some path in their software product back in BeOS R4/R5 days that needs to change now because package management (this one either comes from the developers of said product, or the users, and you can never tell which unless they follow up with a ticket or a fix)

2) Hardware support is very good, until you get to modern wireless chipsets, 64-bit computers, or USB3. A lot of this comes from drivers ported over from FreeBSD, which will lag behind by a version or two. So there is a potential that it will get better, but still unlikely you are going to be able to run Haiku on bare metal of your brand new brand name laptop from the store with Blah-Next-EFI-SecureBoot Thing and Windows 10 (or realistically, new computer you bought in a store even today.) The progress is going to lag behind a bit because there's obviously non-zero effort required in porting new releases of any kind of upstream components.

Wooo OT -- but how often does an even tangentially related to Haiku post get to the front page? I regret nothing.

Haiku lost its project founder and lost its way -- it has been captured by people whose day jobs are -- literally -- Linux kernel development.

Instead of shipping BeOS R5 and no more, which was the project's goal since inception, they're bolting on Linuxisms like package management and in the process getting completely lost in the weeds.

The stated goal of R1 Final has always been complete binary compatibility with BeOS R5, but seriously that was years ago. Package management is far from "a linux-ism" -- you are hard pressed to find a modern operating system that does not have any infrastructural support for taking candy from upstream.

Proprietary OS is going to push the app store, by converse the free OS is still going to scale well because the skeleton crew of volunteers can still keep all the supported binary software up to date with security and modernization updates (not necessarily related to Haiku) for the masses who will not compile it for themselves.

You may have some insight that I do not regarding project leadership but I respectfully disagree that package management is not just "lost in the weeds." Haiku would not be advancing or at all survivable as a general-purpose OS without it.

HaikuPorts/HaikuDepot/pkgman is really slick.

Package management is what you need when you have a huge tree of unstable dependencies that have to be updated in lock-step.

Proprietary OS don't have that, which is why:

1) They can support stable binary-only commercial software, and

2) They do not need or benefit from Linux-style package management.

BeOS R5 had the stable APIs necessary to achieve a stable OS without Linux style package management. The shift away from that has also involved a shift away from the idea that the OS should ship ABI-stable libraries.

Linux-style package management isn't an appropriate tier-one feature for a modern stable desktop OS.

Even if users don't need "Linux-style" package management, developers definitely do.

Only for "Linux-style" software, and it need not be built into the base system.

In fact, it should not -- if having a stable system on which binary software can be shipped is important, a built-in supported Linux-style dependency management system will undermine that goal entirely.

I don't get "linux-style." It's not linux-style, it's "built-on-free-software" style. The other style is "I paid someone to do it" style. That's not really a style, it's just polar opposites.

This is a classic, although over my head in a lot of ways. I've had it on my bookshelf for years. BeFS with it's awesome metadata capabilities is what spotlight should have been.

I think that Dominic works at Apple?

I wanted to take a break (A month or so) from my current project to learn a bit about file systems. I've played with Xv6s filesystem before and am interested in reading about bfs, fossil and related arch and modern ideas in general. Any resources would be really appreciated.

A classic on the UNIX filesystem would be Chapter 4, INTERNAL REPRESENTATION OF FILES, from: Maurice Bach, Design of the UNIX operating system, 1986. It's quite short, about 25 pages.

I believe there is an online version available.

http://www.tenox.net/docs/the_design_of_the_unix_operating_s...

That's a great book. Far from state of the art these days, but still very inspiring for beginners.

I took a lot ideas from it, while designing some in-house DB solution 10 years ago.

Do you happen to know of more modern resources?

well… I think it makes sense to look at ZFS and BtrFS.

http://www.eall.com.br/hp/Solaris/ZFS%20Internals.pdf is a nice start. Not as comprehensive as BeFS book, but still

This was the textbook in my file systems class a couple years ago. Great book that really does a good job of explaining how file systems work.

Reply on news.ycombinator.com