The second version of BeFree has been released today. This is the first pre-0.2 version with a new design, which consists of some system calls for the Linux kernel instead of a user-space daemon. It is beta quality and may have bugs.The release notes are here. BeFree recently abandoned its FreeBSD-centric platform for the Linux one.
BeFree 0.1.1 Released
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
is this similar to cosmoe?
Yes. Similar to Cosmoe, and a bit similar to BlueEyedOS too. But it seems to start from the bottom up (system calls, kernel changes) instead of the up down as B.E.O.S and Cosmoe do (they start with the toolkit).
Well, they are going to use OpenBeOS’s stuff, but with the different kernel. More info can be found at http://lists.berlios.de/pipermail/befree-devel/2003-July/000018.htm… ..
Anyway, it’s pretty bummer that he has dropped FreeBSD support. But, I hope someone is willing to take over and help to work on FreeBSD support with BeFree.
How many BeOS clone attempts are there now? Six? Really, the developement is so fragmented with so few programmers, it will be a wonder if any of them ever produce anything useful.
oh well i dont think ill use this OS. it’s linux based, so whats the point. using linux cos it’s easier, isnt always a good decision. sure they want to have something bootable now so they can show off, but in the longrun, i think only the developers will end up running it.
Yes. Similar to Cosmoe, and a bit similar to BlueEyedOS too. But it seems to start from the bottom up (system calls, kernel changes) instead of the up down as B.E.O.S and Cosmoe do (they start with the toolkit).
The approach of BeFree is nothing more that the Cosmoe and B.E.OS one. Every project had to start with the low level stuff, ie the KernelKit in order to start develop and test the high level parts (InterfaceKit, ApplicationKit).
Some months ago, there were clearly 3 different path:
– the B.E.OS one: rewrite everything from scratch on top of the linux kernel and tweaked use of XFree86
– the Cosmoe one: port the AtheOS system on the linux kernel and directFB
– the BeFree approach: use OpenBeOS code, rewrite the lowest part of the BeOS API on top of the FreeBSD kernel and use XFree86.
Today it’s a bit different, Cosmoe switched from directFB to SDL/XFree86 and is starting a complete rewrite of Cosmoe in order to reuse OpenBeOS stuffs.
BeFree switched to linux… and B.E.OS still making progress.
Who talked about fragmentation? I would say ‘technical convergence’
Regards,
Guillaume
It’s kind of off-point here… How’s your process on BlueEyedOS so far, Guillaume? 😉
Although I had big problems on Linux/BeOS hybrids, I have recently realised that some distros (especially Knoppix) have a lot of BeOS like approaches (a lot of autodetection tools, fast install, optimisationm for speed…).
It would be great if the efforts would collaborate even more closely and maybe introduce Linux kernel patches for LiveQueries (that could be used by both OpenBFS and XFS), and publicly announce this impotant thing to Linux dev community… that would bring extra interests into this efforts.
On the other side someone has to do a lot of cleaninng up and tweaking to get BeOS speed and simplicity closer to the Linux/BeOS hybrid.
Anyway congrat. to developers that finally re-use each other’s code and change strategies to work closer on common code!
Some months ago, there were clearly 3 different path:
– the B.E.OS one: rewrite everything from scratch on top of the linux kernel and tweaked use of XFree86
– the Cosmoe one: port the AtheOS system on the linux kernel and directFB
– the BeFree approach: use OpenBeOS code, rewrite the lowest part of the BeOS API on top of the FreeBSD kernel and use XFree86.
Ahem it is not true.
Some months ago (2, I guess) BeFree didnt’t use OpenBeOS code (I will take some OBOS code for the high level stuff) and it ran on FreeBSD and Linux and I never said that I want to use XFree.
Sounds like what I think.
Stay tuned because this week-end I will show you a new thing that I hope poeple will like.
“With a BSD license my work can be stolen by someone, this problem doesn’t exist with GPL and LGPL”
After all it happens SO often in practice.
As soon as anyone gets wind of the SDK LGPL and its ambiguous wording, dont expect a ton of retail apps for this.
The irony is most corporate software is developed and used solely in house, so this doesn’t even affect them. It does stop cottage-industry(home-based) software shops from making that EVIL profit however.
The GPL lunacy marches on.
To be clear, BeFree is a little different than the other OSBOS clones, and certainly different than the regular Desktop Linux clones approach.
First, Desktop Linux is based on X (XFree86 for the most part). BeFree will not be based on this, rather it will use a low level frame buffer based rendering engine for desktop graphics making the windowing system of the desktop *much* faster than X. In BeOS-speak this is the app_server.
Second, BeFree will use OpenBeFS as the root file system to boot Linux. This is *very* important since it completely seperates the Desktop Linux implementations from BeFree. OBFS is needed for running live queries, indexing, attibutes, and the basic 20 second boot times enjoyed by BeOS partly due to the journalling. What this means is that the Linux vfs layer is in need of some changes to support functions it knows nothing about at this time. A *collaborative* project between several OSBOS (see http://www.beunited.org) projects are in the process of developing these changes for the 2.6 kernel, including BeFree.
Third, BeFree will run OpenTracker. To do this it must have OpenBeFS and the kernel, app, app_server, interface, and other kits. These will be ported from OpenBeOS. Tracker provides a truely seamless experience for the end user. This will make Linux a really usable Desktop system.
Finally, there is still the problem of what to do with all the apps that need to be ported to the BeOS API. There are two solutions I can see, 1) port Qt to BeFree and allow apps like KOffice, KHTML etc to run under the Be-ish look. 2) Port the all these apps to the BeAPI, which is what http://www.beunited.org is trying to do.
So that is what BeFree is trying to do. Hope this helps.
>Stay tuned because this week-end I will show you a new thing that I hope poeple will like.
What is it? What is it? …
Keep up the good work!
1) port Qt to BeFree and allow apps like KOffice, KHTML etc to run under the Be-ish look.
It is not easy to do.
BeFree really needs KHTML, so a WebCore porting is needed (if YellowTab will release its work as Open Source, BeFree will use the YellowTab port, otherwise I will work on a new port) but KOffice is another thing.