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

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

nobius.org

Post reply on HN
Print view View original

11–18 of 18 posts

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

#11

Post by teacup50 »

yebyen wrote: post #10
tqh wrote: post #5

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. Fo…

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.

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

#12

Post by donarb »

mtrn wrote: post #6
rr56 wrote: post #4

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...

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

#14

Post by yebyen »

teacup50 wrote: post #11
yebyen wrote: post #10

Earlier quoted context omitted.

+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. Fo…

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.

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

#15

Post by teacup50 »

yebyen wrote: post #14
teacup50 wrote: post #11

Earlier quoted context omitted.

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 skel…

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.

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

#16

Post by wcummings »

teacup50 wrote: post #15
yebyen wrote: post #14

Earlier quoted context omitted.

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 skel…

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…

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

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

#17

Post by teacup50 »

wcummings wrote: post #16
teacup50 wrote: post #15

Earlier quoted context omitted.

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…

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.

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

#18

Post by yebyen »

teacup50 wrote: post #17
wcummings wrote: post #16

Earlier quoted context omitted.

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.
Post reply on HN