Axel, Bruno and the rest of the company in the OpenBFS team, have completed the development of OpenBFS, the open source equivelant of Be’s popular 64-bit journaling file system. OpenBFS currently runs on BeOS 5, awaiting the further evolution of the OpenBeOS/NewOS kernel in order to start a back port. The team reports that while the filesystem clone is not very well tested yet, it is already seems pretty stable and it beats in performance the original BFS.
OpenBFS Development Completed
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
Nice done guys..
OpenBFS is finished? Whoo-hoo! They’ve yet to list it on the OpenBeOS website or show links where I can download the binary version to install, but…
This is so utterly cool!
Now, um… what are the MIDI and Game Kit Teams doing again and/or when will they EVER get started? 🙂
Jared
I don’t know if anybody has noticed, but journaling filesystems abound. Is there any real need to reinvent the wheel? I know, you’re trying to make a clone of BeOS, to forever preserve it as it was at the time of its demise. For that you’ll need the filesystem. But here’s a thought — make it portable. That’s right, portable. A lot of modern operating systems have VFS capabilities, so why not take the next logical step? Do whatever it takes to make the filesystem OS-independant, and then write VFS drivers also for Windows and Linux to start. That would be a good and useful thing to do!
Iv’e just re-instated my BeOS partition so I’ll look forward to testing this….as soon as I get over some basic setup problems.
Who says it’s isn’t portable? The code is there
Only thing you should do is extend other os’es / programs to be able to use any advanced features like live queries. Otherwise it’s just another 64-bit journaling filesystem.
“[…] the open source equivelant of Be’s popular 64-bit journaling file system.”
Do You know what does “open source” mean? If some linux/windows/whatever ppl will want BFS support they can try to port it. Why the hell OBOS Team should port it? They are OBOS Team, not Windoze Team ;]
Besides not every OS can support live queries IIC.
It’s strange how some ppl can act. You spit on any other OS, including BeOS, than You want OpenBeOS Team to make BFS drivers for You….
Wasn’t it once reported on Osnews, or maybe even Benews, that the current Windows FS does have something like live quiries, only it’s not currently activated..?
It was on BeNews. The feature is activated, it is used by Windows Explorer extensively, it is just that it is not fully documented so not many developers know how to create new attributes or query the existed ones…
As for BFS ported to Linux is not exactly doable, because of the FSIL. The Linux kernel works differently than the BeOS one and it would require major engineering to change things internally and make it work. Also, there is the issue of the Live Queries. You need to change the Linux kernel to support Live Queries and that means a big fat patch for the Linux kernel itself, things that Linus is not always happy accepting. Simple queries would be able to be done with the help of octals, but for Live Queries, it is another story.
And at the end of the day, Linux has XFS. XFS can be seen the closest relative to BFS, architecture and philosophy-wise. And even XFS had to “cut” features – found on IRIX’s XFS – for the Linux version, because the Linux kernel did not support them. So, as long you got XFS, you don’t really need BFS. XFS is a great filesystem and it is even more advanced at places than BFS today.
Stupid is as stupid does, Shard. If your goal was for me to believe that you’re an asshole, then you succeeded. FYI some people actually do “play well with others”. Also FYI the topic is OpenBFS.
This is great. Such feat in such little time. Great work people. Well done.
Thanks for the info! While I see your point, I fear that you are missing mine. Right now there are many different filesystems out there, but they tend to be quite parochial. What I’m suggesting is that filesystem developers expand their scope to include support for operating systems other than the ones that each tends to covet.
Let’s face it, there is no holy grail of operating systems. Different applications have different needs. So the feudalistic approach serves no purpose; it only alienates potential allies. Rather than attack all people who don’t recognize their product as the OS, OS designers could learn some humility and understand that they are not gods. Once that is done, they could let the market decide what features are useful, and vice versa. If these features could be broken out, like the filesystem, then the developer’s wwork could be put to better use, beyond what was originally intended.
At the very least, providing drivers so that other operating systems can create, modify and delete files without causing any damage to the filesystem is enough. Having this basic functionality in dual-boot environments can only help BeOS by making it easier to use it in the real world.
Speed, you are asking for a filesystem that is “easily and fully portable”. It is like asking for a kernel that can be ported to… other operating systems. As you can see, there is a bit of a logic problem here. It does not make much sense, even if it is kinda doable. XFS had to leave a lot behind in order to fit itself inside the Linux kernel. A filesystem is even better when it is made for the kernel that it was designed for. Because a filesystem and its kernel have a very close relationship. Asking that filesystem to be generic in order to be portable, it is going to lose a lot of its strengths. As XFS did.
This OBOS project is moving so quickly! They’ll have a complete replacement for BeOS5 by the end of the year at this rate.
Although I wish they’d announce the new name sooner rather than later.
Perhaps Speed meant having enough of BFS to allow other OS to install & mount the BFS partitions for basic file R/W!
And, does OBOS expect that basic fat32 & ntfs support will be in the full OBOS release or will ntfs support likely be read only again. I can understand the difficulties with ntfs since some of it’s feature set seems hardly used even on Windows (multiple forks etc).
Congrats anyway to the team!!
The word “complete” is FAR too strong of a word to be using here. Though most functionality is there, it has gone through NO stress testing and I’m sure even Bruno and Axel aren’t yet confident enough with it to replace the original BFS.
So please, don’t go run out and try to test this. There will be no official binaries made available as this is not ready for public use. I’m sure the OpenBFS team will be fixing bugs and improving this code until the day R1 ships
JJ has got the idea! How hard is it to produce drivers for other popular operating systems that you’re likely to find in a multiboot situation, so you can copy files between them?
In the long run, it would be nice to see more full-featured drivers. Sorry Eugenia, but I just don’t buy the “relationship” stuff. Filesystem drivers are typically implemented in kernel code, so what? Maybe certain features wouldn’t be appropriate for certain operating systems. That might be an OS shortcoming, or it might be indicative of obsessive feature creep in the filesystem. Modularizing things would be a good way to sort it out, IMHO.
It’s way more important, in my humble opinion, to be able to write to an NTFS partition than to be able to read from BFS partitions under Windows. Which one do you actually want to use – Window or BFS?! I don’t know if this is going to be doable, but I’d rather waste someone’s time with that than porting BFS read-drivers to any other OS.
This is great news…
Now, for those adventurous people to start testing it to death… (kdl, here we go!)
Perhaps after a fine toothed testing phase, BGA and crew can focus some of their energies on other kits? They’re a great team, with lots of skill and experience.
Way to go guys!
It’s way more important, in my humble opinion, to be able to write to an NTFS partition than to be able to read from BFS partitions under Windows.
There are two major problems with that:
1. NTFS changes regularly, to thwart interoperability with other operating systems. We don’t have any control over Microsoft’s actions, but the OpenBFS developers do have control over their code. Would you rather try to move a pebble or a boulder?
2. Windows is just one of several OSes that might be on a PC these days. Making interoperability everybody else’s problem alienates users, and has not once forced the “800 lb gorilla” vendors to beat a path to the little guy’s door.
Like I said, a simple R/W driver for at least Windows and Linux would build a lot of goodwill, and plant the seeds for future code maintenance by other developers. IMHO it would be a win-win situation.
This would do amazing things for my mp3 collection
ATM they are stuck on a fat32 so i can use them from both OS’s
I agree that basic support on other OS’s is a great idea, however, whether it is worth having the limited resources spent on it is another matter.
Already done. I use it. Check it out on BeShare, vbfs.zip I think it’s called. I could not enable writing though, and it had som problems. (It did not do any damage to any partion though).
Yes, there are read-only drivers, and that’s the problem. Read-only doesn’t allow you to do much. While it’s better than nothing, it’s more of a tease than a help. Hence my call for the developers of the filesystem to include R/W drivers for other operating systems.
Finally the revolution has begun! =) well not really but this is really cool… btw anyone know where I could download a AMD Athlon XP ready .iso image with BeOS?!?
/Sinclair
I don’t know if anybody has noticed, but journaling filesystems abound. Is there any real need to reinvent the wheel? I know, you’re trying to make a clone of BeOS, to forever preserve it as it was at the time of its demise. For that you’ll need the filesystem. But here’s a thought — make it portable. That’s right, portable. A lot of modern operating systems have VFS capabilities, so why not take the next logical step? Do whatever it takes to make the filesystem OS-independant, and then write VFS drivers also for Windows and Linux to start. That would be a good and useful thing to do!
OpenBFS is the only database journalling file system available to public. Really, reinventing the wheel? May I remind you that for most of GNU’s early life was reinventing it’s filesystem and other tools… And it seems you are using it.
First of all, thanks for the kind words from most of you. I would like to point that you all should be congratulating Axel Doerfler, an amazing developer and responsible for like 99.9% of all the coding done in OpenBFS. Without him, OpenBFS *WOULD NOT* be where it is now.
Anyway, moving on, when we say that OpenBFS is complete we actually mean it is feature complete. Right now it is a full implementation of a multithread 64 bit filesystem that supports extended attributes, node monitoring, live queries and filesystem indices. It has been written in C++ and contrary to what is expected, it is half of the size of the original BFS. There are still testing to be done and bugs to be found and fixed, but right now you can consider the code beta quality.
Considering performance, it is indeed faster than BFS in every single test we could come up with. File deletion, for instance, is up to 3 times faster while streaming of big files to/from the HD is up to 10% faster (all numbers taken from personal experimentation. YMMV).
About Portability. What you gusy should keep in mind that the objecctive was to recreate the BFS from scratch. It would not make sense to get it to work with Windows or Linux simply because we would not be able to implement all the stuff needed. Also, we are part of the OpenBeOS project and this is our focus. Not to mention that we decided to do it in C++ so it is clearer and easier to maintain, but also it pratically makes it impossible to port to other platforms (and, again, this is not what we set up to do).
Anyway, here is some stuff for you guys to check:
http://www.openbeos.org
http://www.bug-br.org.br/openbfs
-Bruno
Looks like OpenBeOS will be up and running in no time.
The top priority now is to get the OpenBeOS kernel (that is a fork from the NewOS one) to boot from an HD. To do that we need:
1 – PCI bus manager.
2 – IDE/SCSI support (Done, must be ported to the new kernel).
3 – VM/Cache (Partially complete. Being worked on).
4 – VFS layer (Partially complete. Being worked on).
6 – Filesystem (Done, must be ported to the new kernel).
If you think you can give a hand with some of the stuff above and want to help, join us.
-Bruno
Bruno, thanks for at least considering the idea. I understand the project goals and the difficulties involved in doing so. But necessity (or at least desire) is the mother of invention, so maybe some enterprising individual will take a stab at it one day. In the meantime, best wishes and good luck!
And we will be willing to help such project. BFS (and now OpenBFS) is too good to restricted to a single platform.
-Bruno
this is really amazing, but …
Can I download it somewhere without CVS and Compile and so on?
just got company. Alex, one of the new Be gurus.
There’s a rumor going that kernel development is gonna speed up now
You can find the images for AthlonXP here (along with instructions): http://wiki.bebits.com/page/InstallingOnAthlonXPorMP
Ok, we are not *THAT* confident yet, so we won’t be providing binaries right now. In fact, we can only do that when you can safelly replace the bfs add-on by our obfs add-on and fro that to happen some minor stuff must be done (like implementing uncached access to files, needed by the swap file and disk images). Juts be a bit patient or get someone else to build a copy for you.
-Bruno
And even XFS had to “cut” features – found on IRIX’s XFS – for the Linux version, because the Linux kernel did not support them.
Out of curiosity, what are the significant feature differences between Linux XFS and IRIX XFS? Unless you know something I don’t, the only ones I can think of is that Linux XFS only supports filesystems where the block size is the same as the page size and the lack of GRIO support.
DMAPI is there, EA support is there, realtime subvolume support is there and ACL support is there.
It’s way more important, in my humble opinion, to be able to write to an NTFS partition than to be able to read from BFS partitions under Windows.
Well, on my system, I need a FAT partition for BootMagic, so, not being able to have write to NTFS does not matter, and, I don’t boot into windows enough, any way. Just create a FAT partition. Then, linux/windows/beos/skyos/etc. can all read it.
Nice! nuff said.
“JJ has got the idea! How hard is it to produce drivers for other popular operating systems that you’re likely to find in a multiboot situation, so you can copy files between them?”
So what you are trying to say is that BeOS in the first place is likely to be seen in a multi-boot environment..? *lol*… good one… cannot think of when I have seen a BeOS within the last 12 month outside my casa…
Congrats to the OpenBFS team! Good job!
I’m just curious, were your speed tests run on an Intel or AMD proccessor? Does the OpenBFS driver use more or less CPU time to achieve the increased speed?
Just wondering,
Randal Clark
2 Speed
experimental and unfinished BFS driver for Win 9*/ME HAS write support. It is turned off by default, because it wasn’t tested sufficiantly and also seems unpolished, as whole vbfs
I have to agree with both pts Adam & Speed made here even if they are opposing!!
If OSs are somewhat equal in market share, you basically import or borrow or write apps, drivers, stuff from other OS systems to your fav system to grow your base. So in this case import the ntfs, fat32 & other fs. Mac & Linux developers can afford to do this since their groups are big enough to cover many projects.
But when your OS is tiny compared to the others, you do the exact opposite, you infect other OSs with basic versions of your best apps, drivers, apis etc so they in effect become an extended part of your OS.
So since BeOS is tiny compared to Windows, Speed is right on with those 2 pts about ntfs being a hostile fs to import so if a writeable BFS can be built for Windows, it should be done if possible by the BeOS community (but not right now).
Now it doesn’t need to be done today or anytime soon, but once the R1 release is done & developers have some time, then is the time. Also once the source is really solid, other developers who are familiar with the drivers, apis for other OSs will be able to use the friendly OBOS source with help to get those ports done.
I know it feels strange to say that in order to grow an OS you export some of its best parts, but that is the path of least resistance & besides, there would be no opposition! And ofcourse you get to use parts of OBOS on other OSs but the exp will be better when you get back home to OBOS!
Now for the really big idea.
How to break out of the chicken & egg conundrum.
What happens when R1 is out, the same is now true for the apps, why would anybody write a BeOS app and forgo the $ they could have made by sticking to MFC, C#, Cocoa, Qt etc. Well I would suggest that the OBOS community infect Windows with a set of libs that contains the BeOS api, just like Gobe already did, only Gobe did it with out Be help, they also essentially recreated an independant BeOS sans OS.
Now a boat load of developers inluding myself could create Windows (maybe Linux/Mac) apps & get a BeOS version & be pretty sure of Windows revenue providing the app is good. With out other OS ports, I can’t see myself writing a BeOS app no matter how good it is. This kind of puts the OBOS team in more of the same situation as Trolltech or KDE but with an OS thrown in to boot (double entendre).
This discussion has been going on at comp.sys.be.misc or
http://groups.google.com/groups?hl=en&lr=&group=comp.sys.be.misc
nuf said
Let’s move on guys. Maintain the fine job.
Good Luck!!!
While it may be that Speed and I are “arguing” our points here, the simple fact is that we’re both making non-mutually exclusive points. I agree, a read/write driver for OpenBFS under Windows would definitely be a great thing, but personally, I don’t want to use Windows. One machine I have has Windows XP RAIDed over a few drives, and the other is dedicated to the BeOS (actually, it’s running Woody right now, and before that, Red Hat…but it SHOULD be BeOS.) I don’t really care much about getting to BeOS files under Windows, I want to be able to get to my Windows files under BeOS. That would be the first part of my true and complete conversion back to the BeOS!
Most of the original tests were done in Axel’s computer that I guess is an AMD Athlon. Anyway, OpenBFS has no processor specific optimizations so it should not matter anyway. My tests were done on a PIII machine and I got virtually the same relative values.
The CPU time used was virtually the same as BFS. Same for the memory footprint (tough it is not exactly easy to determine in a definitive way).
-Bruno
It’s way more important, in my humble opinion, to be able to write to an NTFS partition than to be able to read from BFS partitions under Windows.
I think this is completely backward, and one of the things that Be got just completely wrong. Sure, but are important–if I’m dual-booting (Be’s strategy, remember), it’s rather likely I’ll need to access my Windows drive at some point.
It’s pretty unreasonable to expect most people to be able to use the BeOS for 100% of their needs. So look at, for example, your MP3 collection. Too big (and too much a pain) to have two copies lying around; one for the BeOS and one for Windows. No problem, you say, just throw them on a FAT32 partition. And, of course, that’s what I (and many other BeOS users) was forced to do. But look at what I lost when doing that.
Sure, I could access and play my MP3s. But I had no attribute support, so I couldn’t use any of the BeOS’ spiffy features like viewing the Artist name in the Tracker, building queries, use BIYS, or any of that stuff. Heck, I couldn’t even have Tracker remember the window positions! Obviously, if I could keep the MP3s on a BFS partition and read/write it from Windows, I could enjoy all of these great capabilities but still be able to use the MP3s in Windows, where the capabilities don’t exist.
In other words, because I couldn’t completely divorce myself from Windows, and because I couldn’t read/write BFS drives from Windows, all the nifty features that the BeOS provides over Windows regarding files became completely worthless to me. That’s not a very good situation for dual-booters. People go on and on about some of the BeOS’ great filesystem abilities without stopping to think that the vast majority of users probably couldn’t even use them. And that’s such a shame.
Well I would suggest that the OBOS community infect Windows with a set of libs that contains the BeOS api, just like Gobe already did, only Gobe did it with out Be help, they also essentially recreated an independant BeOS sans OS.
This is already being done.
http://homepage.ntlworld.com/nathaniel.cross/
Bloody fantastic, what can I say!!!!
Just to give everyone a heads up, that although it is now feature complete that it is still Beta or Alpha quality code that had not been completely tested. A few days ago I built OpenBFS from the CVS to test it out myself, as I knew it was getting close to being complete, and by simply mounting a BFS partition I lost everything that was on it. So as always with Beta software – back up everything
Axel & Bruno – I’ll get the latest version of CVS now that you’re at this point and see if I can reacreate the error, and send you my results.
> Out of curiosity, what are the significant feature differences between Linux XFS and IRIX XFS?
Live Queries. Also, the Linux environment does not endorse the use of attributes the way BeOS did.
But WinBe is GPL, limiting it to just GPL apps. Also for commersial apps the native look and feel is very important.
Better than nothing at least for free use, but if true, another gpl virus…
So what is the position of the OBOS team, surely if OBOS helps out WinBE with code from the API kits, the WinBe libs should follow same license as OBOS. If WinBe stalls because of this, then the OBOS or another $friendly non gpl team should take over once R1 is done!
While the new OBFS driver may be feature complete that doesn’t mean that it is out of beta testing yet. From what it sounds like no one has done much testing on this latest code at all. While there may not be any more major changes to the code there will be some small changes in the code in order to fix some bugs that will likely have to be fixed before R1.
That’s exactly why we do not provide binary snapshots yet. As soon as we are more confident about the code, then we will release a beta version in binary form. Of course we still need people to try it out even in the state it is now, but we recommend using a spare partition instead of a production one. Ate least we can guarantee OpenBFS can not and will not do any damage to any other partition/diskimage besides the one that was mounted using it as the filesystem.
-Bruno
But WinBe is GPL, limiting it to just GPL apps. Also for commersial apps the native look and feel is very important.
It’s exactly this kind of stupid assumption and ignorance that often stands in the way of the GPL in the commercial world.
Just because WinBe is GPL, doesn’t mean applications that use WinBe have to be GPL. Moron, do you believe that every single application that runs on linux is GPL? Of course not!
All it means is that if they (the developers) choose to distribute WinBe with their product, they must also distribute the source code of WinBe. If they make any enhancements to WinBe – in which case all they would need to do is return improvements to the WinBe development team.
The problem with free speech is that encourages ignorant speech.
<quote>It’s exactly this kind of stupid assumption and ignorance that often stands in the way of the GPL in the commercial world.
Just because WinBe is GPL, doesn’t mean applications that use WinBe have to be GPL. Moron, do you believe that every single application that runs on linux is GPL? Of course not!
All it means is that if they (the developers) choose to distribute WinBe with their product, they must also distribute the source code of WinBe. If they make any enhancements to WinBe – in which case all they would need to do is return improvements to the WinBe development team.
</quote>
this would be correct if winbe was under lgpl, but it isnt, its under gpl. this means that any application that links to it either statically or dynamically, or uses some of its source code must also be distributed under the gpl. if you dont believe me then take the gpl quiz (its on either gnu.org or fsf.org)
i should also add that non gpl linux applications are linked against an lgpl library, not a gpl-ed library. this is specifically to allow non gpl applications and drivers to make it to the linux platform.
I am no expert on GPL, but on the WinBe site it implies the WinBe project expects to get access to source code from OBOS (which is MIT license) to save itself some leg work, so why isn’t WinBe under same license as OBOS?
I am no expert on GPL, but on the WinBe site it implies the WinBe project expects to get access to source code from OBOS (which is MIT license) to save itself some leg work, so why isn’t WinBe under same license as OBOS?
It doesn’t have to. The MIT license allows anyone to use obos source code in any other project, be it MIT/GPL/Closed Source or whatever.
this would be correct if winbe was under lgpl, but it isnt, its under gpl. this means that any application that links to it either statically or dynamically, or uses some of its source code must also be distributed under the gpl. if you dont believe me then take the gpl quiz (its on either gnu.org or fsf.org)
Wrong, wrong, and wrong again.
The LGPL means you can include the said application as part of your product and not have to distribute the code or identify it. But you still have to return any changes you make to the LGPL code.
If the code is GPL you *can* distribute it *with* your product, but not as part of your product. And you also have to offer to distribute the code of the GPL application. But just because your own product uses a GPL application does *not* mean your product has to be GPL itself.
What you are trying to tell me is that if I write a product using the GNOME API then it has to be GPL as known is a GPL product. That is just sooooo wrong.
I took the quiz on the GPL and only got 1 wrong. 😮
‘known’ was meant to be ‘GNOME’… I was typing faster than I can think I guess.
This is great news! I’m glad to see OpenBeOS progressing so quickly! Openbfs outperform’s r5’s bfs!! Isn’t the new networking stack also outperforming r5’s? This is going to be one fast OS.
My two biggest complaints I had about the original BeOS is that it wasn’t open source and that it wasn’t multiuser, well, my main problem is solved. Well, also lack of apps, though I think that will begin to change quickly with obos r1.
Multiuser isn’t as much of an issue but it seems what is often hailed on osnews as one of the greatest desktop OS’s of all time, OS X, is multiuser so who knows, maybe that lead will eventually be followed and I’ll even get my 2nd wish as well.
Binary compatability is an interesting issue since much of BeOS is written in C++ and now gcc 3.1 is out so does this mean we’ll have C++ libs built with gcc 2 AND 3 for a while for the sake of binary compatability or what?
I was worried this project might not get anywhere fortunately it seems to be doing just the opposite, getting somewhere and REALLY fast.
Oh ya, I just wanted to say, there are starting to be way too many trolls frequenting this site, get over yourself.
Live Queries. Also, the Linux environment does not endorse the use of attributes the way BeOS did.
No, you said there were significant differences between IRIX XFS and Linux XFS.
What are they?
If the code is GPL you *can* distribute it *with* your product, but not as part of your product. And you also have to offer to distribute the code of the GPL application. But just because your own product uses a GPL application does *not* mean your product has to be GPL itself.
Actually you are “wrong, wrong, and wrong again”. Because when the application runs it includes the WinBe library the application must be released under the GPL also. This is exactly what is meant by the “viral” properties of the GPL!
For all you GPL history buffs LGPL has not always stood for Lesser General Public License, but actually originally stood for Library, because it allowed developers of proprietary programs to link to the libraries. They switched to “Lesser” in order to encourage library development over the GPL to create an advantage to GPL developers. What is that advantage? That non GPL developers can’t use GPL libraries.
So it’s right there in the licenses and in the history. If you still don’t believe it read through the GPL FAQs it’s right in there.
I have communicated with Nathaniel author of WinBe, the discussion over license may be moot, since in his own words he says,
“To be honest this is an interesting hobby for me but would require a higher level of time commitment than I’m able to give to turn into a full project.”
He does say on the his site that he requests some help, but it has not yet produced much response since he was not aware of the world knowing about WinBe.
Inspite of that, I still think this is probably the best way for OBOS to get more apps, sharing both apps & $ with Windows, but I hope the project can come to fruition perhaps under the wing of the OBOS team & a different license.
What you are trying to tell me is that if I write a product using the GNOME API then it has to be GPL as known is a GPL product. That is just sooooo wrong.
Actually, GNOME libraries (GTK+ etc.) are in LGPL. LGPL is the same as GPL except that non-GPL compliant licensed software can be statically and/’or dynamically linked with it.
To say your code MUST BE GPL because you mix it with GPL’ed code is wrong.
I believe you code must be under some sort of compatable license, this includes but is not limited to BSD licensed code and that lax MIT license that the OBOS developers seem to be using.
GPL code must never be distributed binary only, since MIT and BSD style licenses are open source anyway, there’s no problem with this. Doesn’t the Linux kernel borrow some IDE driver code from FreeBSD?
…then will you believe [url=http://plug.linux.org.au/~leonb/wide-open-source-debate.html]this guy[/irl]? Or any other GPL expert?
“The GPL does not require that software using other GPLed software be GPLed, only the parts that include the GPLed source. For example, if you use a GPLed web browser to power your encyclopaedia application (perhaps you added proprietary plugins, perhaps you used it as-is), there is no requirement to GPL the whole product. There is a requirement that you make the source to the browser available with your product, and if you modified the browser then complete source for the modified version must be made available instead.”
Apologies for messing up the link. “Preview” button is a glaring omission.
I’m the author of the winBe package mentioned above. I haven’t actually announced the project yet but a few people have found my website (Googled I guess) so I guess I may as well start talking about it.
I’m using the GPL license because lots of other stuff does. I don’t know, or much care, about licenses. I just want to give the source away and force anyone who modifies it to re-contribute their changes. I think GPL is OK for this.
As JJ says above, I don’t have the time to put into this project – if you’re a talented C++ programmer and want to help out then please get in touch.
Nathaniel ([email protected])
Charlie, read the GPL and the FAQ, don’t believe everything you read on the internet.
With GPL you CAN NOT
1. Link (staticaly or dynamicaly) GPL libs from properitary(or with uncompartable open source license) apps.
2. Link (staticaly or dynamicaly) properitary libs from GPL apps. There is an exception to this clause for libs normaly distributed with the major OS components or when you (the copyright holder of the GPL app) give a special exception to the GPL to allow linking to this library.
With GPL you CAN
1. Execute GPL apps from properitary apps. Execute!=Link.
With LGPL you CAN
1. Link dynamicaly LGPL libs from properitary apps.
2. Link staticaly LGPL libs from properitary apps, provided that you supply the OBJ files for the properitary app so that users can relink it with newer/modified versions of the LGPL library.
3. Use properitary libs from the LGPL app/library.
Charlie, read the GPL and the FAQ, don’t believe everything you read on the internet.
With GPL you CAN NOT
1. Link (staticaly or dynamicaly) GPL libs from properitary(or with uncompartable open source license) apps.
2. Link (staticaly or dynamicaly) properitary libs from GPL apps. There is an exception to this clause for libs normaly distributed with the major OS components or when you (the copyright holder of the GPL app) give a special exception to the GPL to allow linking to this library.
With GPL you CAN
1. Execute GPL apps from properitary apps. Execute!=Link.
With LGPL you CAN
1. Link dynamicaly LGPL libs from properitary apps.
2. Link staticaly LGPL libs from properitary apps, provided that you supply the OBJ files for the properitary app so that users can relink it with newer/modified versions of the LGPL library.
3. Use properitary libs from the LGPL app/library.
Geleto,
Sorry, but just because RMS now claims that dynamically linking against GPLed libraries makes an application a derivative work, doesn’t mean that’s so.
In truth, the GPL says nothing about dynamic linking. What it does say is that any application that is the derivative work of a GPLed application (or library) must also be GPLed.
Just remember:
dynamic linking != derivative work
Adam
I couldn’t have said it better myself.
> In truth, the GPL says nothing about dynamic linking.
Let me quote the GPL:
“This General Public License does not permit incorporating your program into proprietary programs. If your program is a subroutine library, you may consider it more useful to permit linking proprietary applications with the library. If this is what you want to do, use the GNU Library General Public License instead of this License.”
Interesting… It still says nothing about dynamic linking.
Dynamic linking is not “incorporating your program into proprietary programs.” Statically linking, on the other hand, is.
Please use these webpage as starting point.
http://wiki.bebits.com/page/ProgrammingInfo
I would also hope that the time Eugenia and few other individuals spends on this forum by explaing things over and over (to the people who dont do research) would be safed for better use.
Please practice using Wiki when you Have to explain yourself and use forums for “Quick and Dirty” answers and point to the precise explanations in Wiki.
Maybe Eugenia could setup/or link to the Wiki that discusses Cross Platform Development that would be usefull for Linux/BSD programmers also (and not just to BeOS addicts;)
My 5 cents
I know it’s late, but to anyone still curious…direct from SGI – the differences between XFS Linux and XFS IRIX:
For XFS Linux 1.0, the filesystem blocksize is limited to the size of a memory page.
The interface with the kernel (system calls) for Access Control Lists (ACLs) and Extended Attributes (EAs) is different in XFS/Linux compared with IRIX. However, the user level libraries for both ACLs and EAs are exactly the same in Linux and IRIX. Thus ACL or EA application code can be exactly the same.
Unwritten extents are not supported in XFS Linux 1.0.
Linux XFS filesystems are limited to 2 Terabytes in size due to limitations in the Linux block device I/O layers.
The maximum accessible file offset of a Linux XFS file is 16 Terabytes on 4K page size and 64 Terabytes on 16K page size.
Linux xfsdump/xfsrestore does not support:
multiple tape devices using multiple -f options
new IRIX 6.5.12 dump option, -z (prune large files)
DMAPI related options of -a and -D
Linux xfsdump/xfsrestore does, however, have the added capabilites of unrestricted use of the -b option for blocksize specification and remote dumping/restoring between Linux and IRIX hosts.
IRIX XFS filesystems support user and project quotas. Linux XFS filesystems support user and group quotas.
Under IRIX, external logs are specified using a volume manager, XLV or XVM. Under Linux, external logs can be specified with extensions to the -l option of mkfs.
The quotactl(2) system call interface differs between IRIX and Linux, and the Linux quota tools differ in a number of ways to their IRIX counterparts
Linux XFS does not support realtime subvolumes or Guaranteed-Rate I/O (GRIO).
The mkfs command in Linux XFS uses the Version 2 directory format by default.
Linux XFS supports mounting by label and mounting by uuid.
The xlv volume manager is not available with Linux XFS. Volume support in Linux XFS is through standard Linux volume managers lvm and md.