The OpenBFS team is proud to announce that a new version of OpenBFS (Beta 6) is available for download. This new version features a fix for the dreaded “Vnode already exists with a different cookie” problem, a fix for live queries, a fix for searching on non-indexed attributes and lots of other small corrections and additions. BeOSJournal features a mini-interview with BGA. Update: Here are part 2 and part 3 of David Reid’s editorials.
Can it be used to replace the one found in the free BeOS download?
The BFS is really flying There should be one last beta and, then, we should release v1.0 final, fantastic.
Yes, Open BFS can replace the BeOS BFS.
The Glass Elevator list. It’s mentioned on DarkWyrm’s site but it’s not on google.
Beware, this binary won’t run on Dano/EXP. You will need to recompile the binary for use with Dano.
http://glasselevator.sourceforge.net/
is this what you mean? or just the mailing list
which you can find on the site…
I was looking for the mailing list. Thanks!
I got into Beos at the same time as Linux. Good to see the different Beos projects working on some sort future for this great os.
Can OpenBFS be ported to other OSs, like Windows XP. That would be great, because I could then access my BeOS drive partitions from within windows.
No, it can’t. Not on Windows which is pretty tied to NTFS for special features and multi-user. Linux could do, but with a considerable porting work (again, BFS would need to add features as well, as Linux also needs multiuser).
Eugenia, which multi-user features does the BFS not support atm? I thought is was pretty much ready to go multi-user, but I could be wrong. Just curious since I don’t know much about that stuff.
However, it seems unlikely to me that you’d have to add extra features to port the BFS to other OS:s. Both Linux and Win NT can read/write FAT32 right? And it’s pretty much as featureless as an FS can be
>Both Linux and Win NT can read/write FAT32 right?
What that has to do with an FS port? I am talking about a FS port, not an FS *addon* port. There is a difference. There is already an FS addon port for Linux that allows Linux to read BeOS partitions. What I was talking was about porting the FS to Linux FOR Linux, the same way SGI did with XFS and IBM with JFS.
A FS *addon* port is exactly what CaptainN would like to have (and I’d be interested, too). And the answer is of course, Yes. It is very possible. OpenBFS is completely open source, MIT-licensed, no strings attached. Find a willing Windows programmer (it probably will cost you also a shipload of money) and off you go.
If you meant if it’s the plan/job of the OBOS devs… Nope.
Kudos to the OBOS team for another major update for OBFS!!!
Axel D is the king!!!
OBOS moving quicker and quicker to D-Day
Rock on OpenBeOS!!!
Eugenia, I think Captain mention driver support. E.g. browsing BFS partitions via Windows Explorer. Not using BFS to run Windows on.
Rain, BeOS isn’t multiuser – how can BFS be multiuser? Maybe OpenBFS, but I doubt BFS is multiuser. It support stuff like encryption though.
> Eugenia, which multi-user features does the BFS not support atm?
hi rain
I’m not totally up to speed, but i think modern multi-user FS require Access Control Lists or the like. Although BFS is fresh with the unix access flags (ie chmod) stylez, ACL technology is not part of BFS.
more?
Unix old skool permissions: read, write, execute
For three sets of user: owner, group, others
If we want to customise a JoeUser’s access rights, we have to chuck him in the file’s group, and set the group permissions with chmod. (not so) clearly, everyone in group who is not the owner is subject only to the group permissions.
It would be much nicer to dole out access rights on a per user basis – thats where ACL comes in (or not, for BFS)
@Eugenia:
Adding ACL should be a piece of cake once the metadata infrastructure is in place. In fact one of the most important usages of the NTFS metadata is just that: managing ACLs.
I have been a huge BeOS fan. Nowadays I use Linux and WinXP, but I still miss the features from the BFS. Especially KDE is such a nice modern framework, but it could really benefit from some decent infrastructure such as live queries, metadata etc. As of now, KDE has to work with some really primitive infrastructure such as flat files without metadata and no efficient way to get notified for file system changes…
KDE on top of OpenBFS would really rock!
KDE on top of OpenBFS is possible if you port KDE to BeOS. It shouldn’t be too difficult, since Qt was once ported to BeOS as well as a simple version of Konqueror. If a team was motivated to do it, KDE would be on BeOS (and hence, on OpenBFS) sooner than you think.
The real issue is that BeOS doesn’t need KDE. Why bother when they have an excellent GUI environment to start with, and the BeAPI is on par with Qt.
Was QT really ported? If you mean Proctons port it used small parts of the QT api to run Konqueror. His port was based on the AtheOS port. Proctons port compiled just fine, but it didnt render on the Screen, if someone is intrested Iam sure that you can have his sources, he was so close but yet so far away =)
Anyway, there is a WindowsXP BFS readonly driver at http://www.bebits.ru I once got it, but never tried it. I heard that it is buggy, but its worth a try ( backup your system before you try ) ( both of them ).
bebits.ru seemes down at the moment!
Good luck!
/Konrad
There’s a Linux BeFS driver as well, actually. It’s read=only, with (I believe) experimental write support. I use it; works great.
i wish apple would do something with the mac os X file system and create somthing like this or at least improve their current UFS ( if anything just add softupdates)
jon
>KDE on top of OpenBFS is possible if you port KDE to BeOS. It
>shouldn’t be too difficult, since Qt was once ported to BeOS
>as well as a simple version of Konqueror. If a team was
>motivated to do it, KDE would be on BeOS (and hence, on
>OpenBFS) sooner than you think.
>
But the point would be to enhance Qt and KDE so that you can use the enhanced features of the BFS, such as fast change notification and live queries. The problem is that the KDE team will not do something like this since these features would only be available when using a BFS variant.
>The real issue is that BeOS doesn’t need KDE. Why bother
>when they have an excellent GUI environment to start with,
>and the BeAPI is on par with Qt.
>
I disagree. I have written some programs for BeOS back when they were still alive, and it does have some problems. It has no layout management, and while having one thread per window might seem like a good idea, it is not.
Multithreading comes with its own set of very hard (as in hard to reproduce, hard to find, hard to fix) bugs. I think it is a very bad Idea to use multithreading when you do not have to. Multithreading should be handled by the system in a transparent way, for example using non-blocking, asynchronous IO calls. All modern toolkits such as .NET and Qt use this mechanism to encapsulate the messy multithreading stuff.
And correct me if I am wrong, But I think the Be API had no support whatsoever for layout management and GUI theming. That is just unacceptable today.
I think the best thing about BeOS was the low level stuff such as the file system.
Ghm….
I think that BFS IS Multiuser….
Weren’t there things like baron [root]
some priveleges… etc. .. ?
Like in Linux….
Root – Baron
and l’users
It has encryption….
>And correct me if I am wrong, But I think the Be API had
>no support whatsoever for layout management and GUI
>theming. That is just unacceptable today.
True, no layout management in the API. There is liblayout which adds some of this functionality.
GUI Theming – If you mean OS-wide theming, some small bits can be done with BeTheme, zeta will add much more functionality to this, and OBOS is also adding some appearance preference stuff to do a similar thing, AFAIK. If you mean app skinning – the lack of a “skinning culture” on BeOS makes it the most consistent OS I have ever used.
> having one thread per window might seem like a good idea,
> it is not.
Multithreading does make programming harder, admittedly. And the forced multithreading BeOS does for multiple windows can be quite annoying (especially for ports). However, without that the OS would simply not be as smooth. I can still make windows XP stutter on my XP 2400+ system, whereas making Be unresponsive on my old K6/2 is much harder.
ps: Well done to the OBOS team, good to see more progress being made.
Simon
Yes it is, it supports uid/gid pairs and Unix-style permissions.
And of course, using attributes it should be quite easy to add ACL support.
Congratulations OpenBFS team.
It seems strange to think that something as low level and “unseen” like a file system can have such an impact on the usability of a desktop operating system. In the case of BeOS its legendary responsiveness and cohesive feel owe a great deal to the BFS. Tracker depends quite heavily on node monitoring, live queries, live indexing, and attributes all to make the OS feel alive. You can really tell the difference when you use BeOS and then go to another OS like Windows or Linux where the connection between the file system and user interface are passive. This, IMHO, is one of the reasons why Linux is simply hard to use for people, since they cannot determine the state of the file system from looking at the GUI. In Windows you have to hit the F5 key to update the ‘out-of-sync’ view of the files in Explorer. BeOS does not suffer from these problems because of its file system, and the close relation is has with the Vnade layer in the kernel. Using BFS would certainly bring Linux MUCH closer to a usable system, but this is considerable work since the Linux VFS does not support the 50+ operations in the BFS. If you examing the Linux VFS you can really see that its designed as a fast trasaction-oriented OS for server use based on UNIX principles. However, this does not mean that BFS could not be ported to Linux, and this would certainly bring it closer to being usable as a desktop OS… just a thought.
Actually, if you visit http://www.beunited.org you will see several projects that are in the process of trying this =)
-S
the real barrier to creating a windows BFS filesystem driver is the cost of entry. a liscense for the requried software costs about $900. for a driver that will not be commercially viable, that’s a pretty high cost for hobby developers.
http://www.microsoft.com/whdc/ddk/ifskit/
http://www.microsoft.com/whdc/ddk/IFSkit/xpsp1orderfaq.mspx
Windows you have to hit the F5 key to update the ‘out-of-sync’ view of the files in Explorer.
That’s news to me. Please explain.
thats great………….but ive been all over their website and cant find a download
uhm… you must not be looking very hard. click on the “download/testing” link and then the version you want.
a listing of all versions: http://www.bug-br.org.br/openbfs/index.phtml?section=testing
direct link to current version: http://www.bug-br.org.br/openbfs/openbfs-1.0b6.zip
all this work being done really makes me happy. i can’t wait to get my BeOS system setup again. yay! :^D
Qt was never properly ported to BeOS. It was based on a X emulator on BeOS and was extremely slow, in addition to being extremely buggy, inconsistent with BeOS, amongst others. Meanwhile, even if a Qt port to OBOS is possible, I don’t see why you need to do it – unless OBOS don’t plan to extend BeAPI (which is stupid). It is far easier, IMHO, to replicate KDE feature-for-feature than porting it and Qt.
I can use mine non multiuser fat16 file system with windows 2000 with no problems at all.
I’m talking about a partition where Windows it self is not installed on.
So I don’t understand the bla bla about multi user file systems and WinNT.
oh i was on the openbeos site…..i think http://www.bug-br.org might be blocked on my network
This team is realy great(BFS) but every time I see a headline “OpenBFS gets even better…” I get frustrated (althought less and less) about the fact that I almost never see any news about the OpenBeOS kernel. I even wonder if the developers have any reason to develop this kernel. Damn, I hope OpenBeOS still has the will to do what it set out to do… cause the kernel is really holding things back; it needs to be functional so that the whole OBOS team can show something – with servers running on top of it…
“In Windows you have to hit the F5 key to update the ‘out-of-sync’ view of the files in Explorer. ”
Actually it’s wrong, as Windows do support a live update like BeOS. If for exemple I do a search of files bigger than 10Mb I recieve a list. If I let that windows open and create a new 10Mb+ file, it will automatically be added in the window (same thing if you delete a file in this list, it will be automatically removed).
Overall Explorer do support well to automatic update. But for some reasons, once in a while a F5.
“Overall Explorer do support well to automatic update. But for some reasons, once in a while a F5.
”
Sorry the corect phrase is :
Overall Explorer do support well automatic updates. But for some reasons, once in a while a F5 is needed, caused by some glitch.
Actually I tested this on Win2K and deleting, moving, and even modifications made from command.com seem to stay “in-sync” with the file system between Explorer windows. However, Win95 suffered from this and there are some cases where even Win2K will not be in sync. Heck, if you look Wind2K still has the “Refresh” menu item which goes to show that the operating system and file system are not always going to be consistent (otherwise they would remove this menu item).
However, that was not really my point. The point I was trying to make was that something as low level as the design and functionality of a file system can have a tremendous impact on the usability of an operating system for users. BeOS was the only OS that made the GUI of the OS feel “solid” and “consistent” on x86. Only the MacOS, for all its problems, was able to provide the kind of seemless experience to users. On the MacOS you never felt that what you did and what the OS showed you were not the same. You never saw two copies of the same window showing two views of a directory, since there was only one, and this made users connect the concept of a window to a location in the file system in a more consistent way.
Windows, with its multiple views of the same thing, makes this feeling go away, and confuses users by showing the same thing in two places. This breaks the icon-to-file metaphor by doing something that is not possible in real life, i.e. having the same thing appear in two places at the same time. Even BeOS does this, but at least in BeOS you never have to use a “Refresh” command to make sure that your looking at the file system the way it really is. In Windows you still have to wonder, and that lack of trust in the OS will always make Windows a less usable design.
IMHO
I remember a long time back Axel saying there would be support for mem mapped files some time. Is that still in the plan?
That would greatly simplify my efforts with resize & retry code.
What applications are you using on your windows machines? I see the annoying out of sync issue in winodws explorer all the time.
Try this
Install winzip
right click on a zip file and select the extract here option – this results in the zip file’s contents being expanded into the very same directory.
Now, look and see if the explorer winodw notices that new files have been added to the directory. Wait for a while. Click into another directory and then come back…
I dare you to desribe a reasonable reason why the winodw does not update its contents. I think I’m daring you to an impossible task, but please go ahead and try.
I know for sure that Windows explorer don’t update the dir-tree, so I have to do refresh every time I create or copy a folder…
BFS has everything needed for multi-user, just there is no enforcement mechanism enabled / installed.
Each file has Owner / User attributes seperate, and the system can use them. Robinhood uses these multi-user attributes for permission granting for file uploading (password requested if remote user is not same as local user, some of you may hae noticed).
So, no more about that, okay?
–The loon (busy, sorry folks on BeShare)