BlueEyedOS, an effort to ressurect the BeOS APIs and experience under Linux and X11, switches to the LGPL license from closed source in order to attract more developers.
BlueEyedOS Switches to LGPL
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
I must say this is some news, I really thought it was dead, must say I was almost right. Let’s hope it will continue, not only for BeOS, but also for linux.
I’m also curious if they think switching to the .6 kernel is a good thingie
Eugenia, they switched to the LGPL from something, right? Maybe you didn’t put it in the writeup because it’s not in the article?
So, Were they GPL? BSD? Proprietary? Artistic-with-goofy-extensions-and-deletions? Someone who knows should fill us in.
Maybe it would be nice to know how widget rendering was implemented if it used native X or OpenGL?
http://www.blueeyedos.com/project/license.html
“The source code is owned by the BlueEyedOS development team. You are not allowed to reuse or modify it in any way. If you want to improve or modify the source code you must do it as an accepted member of the BlueEyedOS project.”
Let’s hope someone can port it to FreeBSD, I always want to see BlueEyedOS to be mature and be better than other DE.
They should work together with Cosmoe to produce the native app server. As far as I know that is what Cosmoe dose.
Should i view BlueEyedOS as a DE (more or less like GNOME and KDE), or as an OS (like BEOS)?
BlueEyedOS, BeFree, Cosmoe etc, noble efforts, I guess developers can choose to do whatever they wish, scratch whichever itch etc, but frankly, 95% of the BeOS community is behind OBOS. And all those Linux wheenies who claim OBOS should have been GPL, well here’s BlueEyedOS which is exactly what you want, so now take the foot out of your mouth and join that project.
What, you’re still here? Then stop crying about OBOS choosing a MIT licence.
Maybe the reason because you have trouble distinguishing a DE from an OS, is that the frontier between both doesn’t really exist?
Way to go, my good fellow. Someone should call it like they see it! We’ll see now if the GPL weenies will put up (we all know that they’ll not shut up 😉 ).
… but frankly I believe most devs prefer the free license choice of OBOS namely MIT. On the other hand, B.E OS is stuck with the Linux kernel so it might be wise to choose a similar restrictive license which matches kernel (almost anyway).
Will be interesting to see how this might progress…
I think that BlueEyedOS idea is more smart and tangible than OBOS. Using a linux kernel and X means have hundreds of device drivers. And for those who say that linux is not responsive there are realtime and preemptive extensions for it.
I think that this project is more important to linux than BeOS fans. BeOS as operating system is DEAD but some of its ideas can be used as improvements of mature operating systems like linux and BSDs. I think that B.E.O.S should be used as a power desktop of linux OS, not as a BeOS clone.
I hope this will help the linux community. It’s the best of both worlds, the linux kernel, the beos APIs and focus on usability.
because they are one entire OS. sure, it will be harder to get drivers and stuff, but all the open source drivers out there were made from something. they can start making native drivers from Linux and XF86 using the info that those driver makers used in order to talk to the hardware.
add to that, I think OBOS will publish the specs for an OBEbox that will run the OS flawlessly.
after that they should work on expanding he driver library beginning with the core needs of main stream desktops and work their way outward to the more exotic.
When i see all these “let’s bring beos back to life!”-projects i can’t help thinking about gnustep.
There is a pattern to all this:
1. Ex apple executive starts company
2. Company does innovative software that is praised by everyone that has used it.
3. Software gets marginalized despite its technical superiority.
4. As a result, Company goes belly-up.
5. A couple of fans decides to reimplement it (as open source).
6. Time passes.
7. It takes more time than they expected.
8. More time passes, and innovative features from Company’s product is included in competing products.
9. Once innovative software is now obsolete.
I guess #10 should be “open source clone implemented” but i’ve yet to see that happen. I think we’re at #9 for openstep and somewhere between #7-#8 for BeOS.
openstep is now cocoa in apple osx and gnustep tries to integrate some of cocoa’s new features in openbeos.
i think gnustep/linux distribution (like simplygnustep) is a much better idea than beos on top of linux, but i wish them success and to release the stuff under the LGPL is really a nice step forward…
Wow. Looks like Cosmoe, BeFree, and BlueEyedOS have an awful lot in common.
Perhaps all three could merge and really do something great.
I’d like to see an OSNews article/interview where Bill Hayden, Pier Luigi Fiorini, and Guillaume Maillard all talk about the possibilities of joining the three projects into one (Personally, I like the name (and logo for) Cosmoe
).
Guillaume has (on the B.E.OS website) already taken the first step and graciously said:
We switch to a LGPL license (and pass the “leadership” to someone else if needed). All I really want is to be able to boot under B.E.OS v1 (and not v0.34.65a), I don’t care about leadership.
This could really go somewhere.
…kernel is unimportant. I don’t care if it runs on top of Linux, NewOS, BSD, etc. I just want my BeOS back!
Cosmoe, BeFree, and B.E.O.S. need to join forces, and they could have something usable within a decent timeframe. That might buy us some time while OBOS matures to a usable state.
Otherwise, we’re step #10 – obsolete.
Well, BeOS has pretty much all I need in terms of drivers, audigy/live sound drivers, nvidia drivers (for all nvidia cards) which are 2d accelerated, and it is also open source! Also we have Radeon drivers.
Pretty much the only thing I wish we had support for is more printers. And a few more network devices.
BlueEyedOS’s Xfree86 is extremely fast and smooth, we should merge this into main branch for X.
I think, this is an very good idea. 🙂
Thgat was the advantage of BeFree. It do something similar to BlueEyedOS, but was (and is) GPL/LGPL. But now BlueEyedOS use the LGPL, too.
Good decision
I still think both approaches pure & Linux based are a good idea. If both existed right now, I’d probably use OBOS mostly.
I still have to use Linux down the road & I dred the install problems, maintainance & learning curve. If BeOS API did exist on Linux, we would still have to deal with other API kits QT, GTK, Tcl etc as most everything I would use on Linux will never be written in BeAPI. The same really applies to Windows.
Now if OpenTracker could just be ported to Linux & or Windows, much of my desire for BeOS+Linux would be satisfied, trading the larger no of apps against the full richness of BeOS exp and few apps. And surely a port of one large app is far less work than creating the entire OS & GUI. I know, I know, there are some issue that Axel has described in OT places, but he could probably address those.
I like the idea of openbeos but will they have a usable os in the next two years….
Speaking of cosmoe it uses linux kernel an some of atheos
but i am not sure about the other projects joining forces
The main thing here is to get a updated version of beos
i realize zeta is out there is it really that much better?
I have tried beos personal edition it never liked my video
i will not go out get another video card just to run it
i will openbeos an the other the best.
It means little to me at this pointr and will continue to until it has reached the maturity to where I can slap a cd into my machine have a nice greahical instraller gteet me there and install it and run my favorite apps like I can with BeOS R5 or Linux Mandrake or QNX or whatever,it would be way nice to run BeOS apps in a Linux environment but will they be as easy to install as in BeOS?And I’m not talking about dashboard stuff like pulse,I mean full fledged BeOS apps like XRS,PersonalStudio,ArtPaint,Refraction,Rack747,3DmiX,the BeOS SoundRecorder,GobeProductive,on and on….Stuff like this is what I miss in Linux
If I just wanted a BeOS looking skin they had that in Enlightenment years ago,in fact it was what made me look into BeOS in the first place,and it was so much more friendly and nicer than Linux I stayed there.,
All these BeOS replacement schemes seem to be a long ways from being ready for prime time and IMO they are in the same category as SkyOS and AtheOS or whatever they call it these days .Actually Sky OS looks fairly mature but I have yet to get it to run on anything I own.
all I can say is keep up the goood work guys and I’ll keep posted,and when you get it to the point where a self-taught shadetree geek like myself can use it ,I’ll be here,’Till then I will continue to comb ebay for old hardware to run R5 on!
This is great news, I hope I can help. I was at odds with both OpenBEOS and BleuEyed. OpenBEOS was totally open but is re-creating technology from ’98 ignoring alot of progress made in past five years while BlueEyed was using all the advantages of current technology but totally closed off. It made it so I didn’t want to participate in either project. Now, with BlueEyed decision, I hope I can make some contributions.
“e-creating technology from ’98 ignoring alot of progress made in past five years while BlueEyed was using all the advantages of current technology”
Ahh, so smart notice.
But why not to say that BlueEyed i using technology from 1990 if not from 1970?
Sure, it was re-creation from scratch (linux) and it evolved a lot.
But remember, something which was invented in first half of 90-s (BeOS) is still a bit reacher in concepts and ideas than something which is based on ideas from end of 60-s. Isn’t so?
And remember, that OBOS has it’s own implementation, so this “advance” you noticed in linux (long sequence of patches and hacks) is not so good example. Lot of those things linux tries to reach in desperacy at moment, already were in BeOS in 1998, and OBOS may rather improve those advances.
But why not to say that BlueEyed is using technology from 1990 if not from 1970?
Good point, but I think that what you’re talking about here are ideas. I guess, what I meant by “technology” was basically hardware support. I apologize for using the blanket term of “technology”. Also, BlueEyed is using the Linux Kernel, but not re-implementing a whole *UNIX* system. I believe BlueEyed is using the advantages of the Linux Kernel such as a large support base, a large development base, corporate backing, many eyes on security, etc. while will still be starting at /boot.
But remember, something which was invented in first half of 90-s (BeOS) is still a bit reacher in concepts and ideas than something which is based on ideas from end of 60-s. Isn’t so?
I agree whole heartedly. I think it goes back to me using a blanket term. The whole reason I love BeOS was because of all the ideas (a nod to your good point) that it brought, the C++ API, the incredible file-system, the translation and other kits, actual MIME…so yes: it is so. Also, don’t forget that one of the original BeOS’s goals was to be fully POSIX compliant, which has ideas influenced by *UNIX* and was created in 1986, so there seems to be a few legacy ideas floating around the original BeOS too.
What I took exception with in the OpenBEOS project was hard-lined goal of binary compatible, no more, no less. While everyone will have an opinion on it’s usefullness I think a good example is the single-user-ness(?) of BeOS. Almost every OS has the idea of multiple end-users and I would say people expect that feature in any modern OS. With the idea of recreating BeOS as it was, I felt the OpenBEOS team was passing up a prime opportunity to fix or add ideas (and/or technology) that are prevalent today. How difficult will it be to implement the idea of multiple users into the system after the fact as opposed to right now? (I don’t know btw, rhetorical ?) I think OpenBEOS will make a ton of progress but I just hope they aren’t playing catch-up all the time and never get the chance to “grow” BeOS to what it everyone knows it can become.
I think you took me as a Linux zealot, not true at all: OS X user with BeOS MAX on my AMD XP/NVidia box.
So far, binary compatability has cost us next to nothing. Really. A few hours getting the includes right. *IF* the time comes when we realize that it will be some huge amount of work to support it, we will reconsider the decision. It is a “try it and see”.
You go on from binary compatability to talk about single vs multi-user. That has little to do with the BC decision and a lot more to do with the “implement R5 first” policy. It may be that you are more concerned about that.
Let’s take two scenarios:
1) We do what we have planned – start with R1, then make R2 and R3 and R4 and so on. Let us assume for the sake of argument that no functionality is REMOVED from R1 when we create R2 and so on. That means that work(R2) = work(R1) + work (R2 features) + work (integrating into existing OS)
2) We sit down and plan out every feature that we will want for our release, RPrime. This would be equivalent to, say, R3. That means that it is:
work(RPrime) = work(R1) + work(R2 features) + work (R3 features)
So we have saved the integration work. Good for us! 🙂
But, what have we lost?
First of all, we would most likely be a lot further from a release. In fact, past experience would lead us to believe ( http://www.aros.org ) that we would not have a single line of code written as we argued about critical features. Secondly, we would probably not have binary compatability. Which means that the already “too small” list of software would be a lot shorter. Third, when we did start coding, we wouldn’t have the completed spec written for us like we do now.
There have been some decisions and some methods in OBOS that I regret. Keeping the feature list roughly equal to R1 is NOT one of them. Time and time again, it has proven itself as a key to making the project run well. If you are inclined to help out now, come R2 time, you will have lots of opportunity to have a say in what goes into R2.
Thanks for clearing some of my misconceptions up. I guess I picked multi-user as a cherry, it was too trivial to make any real argumentive (is that even a word?) impact. Good luck with the project. I hope my above posts didn’t come off as non-supportive, but just different.