Some weeks ago we hosted an interesting interview with Guillaume Maillard regarding the BlueOS effort to ‘save’ the BeOS by using a modified Linux kernel as its basis. The team has just released a new screenshot based on the BlueOS GUI, running under the BeOS app_server for the moment instead of under XFree. However, a preliminary BeOS-alike app_server for XFree, is already on their CVS.
Screenshot from BlueOS New GUI
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
Hmm… very nice looking screenshot
even… WOW! 
Will it be skinnable? Or could i change colors like in BeOS? (that “Change title” button’s color isn’t nice ;])
Hey, I’m glad things go so well for BlueOS and OpenBeos. Let’s just hope BeUnited gets a sourcelicense for BeOS too. I’m gonna use em all
Viva BeOS.
This looks good! I just hope that we also get the core parts of BeOS here (filesystem, multimedia etc), because the GUI itself wont do much good… Nice anyway though!
Is the text antialiased there? Doesn’t look like it to me.. what toolkit do they use? Or are they reimplementing the BeOS GUI? Very nice, anyway 🙂
I like what I see… are they going to share their work with the OpenBeOS camp as well for a UI type standard… or are we going to get the GNOME -vs- KDE rendition again?!
Good stuff though… keep up the great work guys!
Yes, it is antialiased, it’s running under BeOS as they said. Under X I don’t know.
Very nice screenshot! I really like the scroll bars…
How about a mod to BeOS5 so I can have those pretty scroll bars?
Flipside
I’ve posted some scepticism(sp) before regarding attempting a Linux based BeOS clone, but if BlueOS runs as much like BeOS as it looks, we won’t even have to worry about what Palm does.
how will blue os be liscensed? some source code will have to be released as they are modifying the linux kernel, but in the download page, it says “Source code and documents of conception restricted to members of the team.”
will the source be released at a later date? or will this be another closed-source project where former beos users are again left with nothing when the developer goes under?
The project is not under GPL, parts which use GPL are in GPL (like the kernel), the rest is “restricted” to members of the team to avoid useless “forks” and reuse in commercial products.
To sum up, you don’t have to pay to use/distribute BlueOS (or develop on it).
But about the source code: you are only allowed to help us to improve the “beast”
This UI shot looks fantastic!
Please, Please, Please don’t be one of those projects where people start to lose interest and everything just fades away.
The screenshot looks extremely smooth, indeed. Kudos.
it IS BeOS!
Wha’t the big hoopla here, really? This is still BeOS, although not as nice looking as the original UI.
Bah.
I have just one comment…if you intend to design make sure you have excellent knowledge in the field of GUI usability. I realise this is a initial screenshot and from my professional viewpoint, as I am a GUI designer for applications I have noted some issues.
A word of advice- start planning the usability aspect of your dialogs and GUI soon. While you are working on functionality .
Otherwise looks ‘interesting’
Looks nice so far…and I totally agree with gui-designer, think about what you’re doing. Now is the right point to think about usability, once you made big mistakes there you’ll have a very hard time fixing it.
This looks very impressive and promising!
Keep up the great work BlueOS team, you look like you have alot of potential and are making steady progress.
“The project is not under GPL, parts which use GPL are in GPL (like the kernel), the rest is “restricted” to members of the team to avoid useless “forks” and reuse in commercial products. ”
Not trying to start a fight or anything, but is this legal? Wouldn’t the code have to be LGPL for what you’re doing?
No.
actually the linux kernel is covered by a slightly modified gpl liscense. non-gpl code is allowed to link to it in normal operating system functions. but most other gpl software retains the full restriction against linking by non-gpl programs.
x has its own liscense, so there is no conflict there.
the blue os team afaik is not required to release source code until they release their software. even then they only have to release what is required. there is nothing illegal about creating a closed-source package around a modified linux kernel as long as the source for the kernel modifications are released.
that being said, i would rather the blue os team release full source code, but there is nothing illegal so far.
Please don’t make the same mistake as Be and make this product closed source. In today’s marketplace the only way for an alternative OS to compete is through an Open Source project. There are many OSs (like NetBSD), that despite relatively small userbases, are thriving nonetheless. This is because they allow the user community to participate to improve the OS itself. All this stuff about forking and commercial use it utter bullshit. Linux has been GPL for almost a decade now, and no-one has yet seriously forked the kernel (SGI’s XFS tree doesn’t count, since it tracks the kernel to within a couple of hours and is being prepped for inclusion in 2.5) Even SGI and IBM, who could easily fork the kernel with their resources, have tried to stay as true to the development model as possible. It doesn’t have to be GPL, just open source. Otherwise, we’ll just have another dead BeOS on our hands.
BlueOS is not as closed as you said:
“about the source code: you are only allowed to help us to improve the “beast” “. Not clear?
It allows the user community to participate to improve the OS itself but not in a “wild” way…
Stop searching issues where there are not and make something to not “have another dead BeOS”. Thanks.
It allows the user community to participate to improve the OS itself but not in a “wild” way…
>>>>>>>
What “wild” way? Can anybody seriously claim that *BSD’s OSS development is “wild?” Besides, its the “wild” devlopment of Linux that made it as great a kernel as it is today! Having a closed OpenSource license is almost as bad as having a closed source license. First, you can’t use any of tons of useful code present in GPL software. You want to take some useful code from AtheOS? Tough. Can’t do it. Then there is the whole issue with using the Linux kernel in a non-GPL OS. First, you aren’t going to get any help at ALL from the kernel developers. They simply don’t deal with people who do non-GPL stuff with their kernel. You should see how bad closed-source driver get flamed whenever they submit anything to the kernel mailing list. They even have a thing in the kernel driver API that requires you to state the license of a kernel module. If the kernel crashes (anywhere, not just in the module) and the license isn’t GPL, users are told not to contact the kernel mailing list, but to bother the developer of the non-GPL’ed code. Also, you have RMS on your back about “stealing” GPL’ed work. Then there is the constant worry of GPL infringement hanging in the air. Then there are all of the people who won’t contribute to the project because it is not GPL’ed. I’m the last person who would normally be complaining about licenses. I think the Linux people are way too sensitive about legal issues. Still, BlueOS would be using millions of lines of Free UNIX code (Linux, XFree) and its going to have to play by the rules of the OSS (read: GPL) community.
Nice, but UI was never BeOS’ finer points, and the look & feel of BeOS is getting a bit tired. There are more modern looking UI’s out there, even OS X. I’d like to see something a bit more forward-looking; just my opinion.
Steve
You must be joking right? I love BeOS UI. Some things could need a little polish, but it is a very good start IMO. If you prefer OS X UI use it, or write one like it for BeOS.
One of the best things in BeOS UI is right click on a window tab to send window to back
One thing I took away from a speech by Lawrence Lessig is that giving up control and throwing code out there into the wilderness, without control, is a very good thing. The Internet was developed to be peer to peer network. Unlike a controlled process the owners of the network couldn’t shut down what they didn’t like, or what didn’t make sense to them (business or otherwise). This decision allowed innovation. It allowed innovation to happen in ways that the creators could not have imagined (or permitted).
While I wish you all the best in your project, and you can choose whatever licence you wish, I don’t find it trusting in me or others. I don’t see what you’re hiding from. I believe you should change your policy and trust your audience.
BTW, some examples of how the “wild” nature of Linux can be helpful:
1) The new virtual memory manager. The official mandate of the Linux developers during 2.4 was to work on Rik Van Reil’s BSD-style VM. It simply didn’t work very well. Andrea Arcangeli, however, wrote his own version of the VM. When Linus saw that it was better, he went ahead and switched VMs. This really would have been very difficult to do under a more closed model.
2) Low-latency, preemptive patches. A lot of people on the kernel devel team didn’t think that making the kernel preemptive would be a good thing. They thought it would kill latency. If Montevista and Robert Love hadn’t come along and introduced their own patches to the kernel, Linux’s latency problems might never have been solved (at least not for a long time). In a closed development model, where the developers have an official “vision” of the progress of the code, such offshoot projects are hard to maintain and develop.
3) Bug fixes. Take a look at the kernel mailing list sometimes. *Tons* of different people submit patches to Linus to fix bugs in the source. In a closed model, most of these people would not have access to the source, and the resulting product would be much buggier. Also, it enables users to fix their own bugs. I remember when the USB joystick driver came out for BeOS, it didn’t work with my Sidewinder Precision Pro. Since the driver was open source, however, I was able to quickly fix to so I could use my joystick. It was a quick hack and probably broke the driver for all the other joysticks, but it allowed me to use the thing until the official fix came out nearly a month later. In a closed development model, such things just aren’t possible.
An open development model doesn’t mean that the project goes in random directions. To this day, there is only one Linux kernel (the -ac and -aa series are largely testing trees), the one blessed by Linus himself. He is the sole decision maker with respects to what is included in the kernel and what is not. There is a vision behind Linux’s development, and despite its very open development model, that vision is adhered to. Even this new VM split seems to have been resolved in a manner keeping with the project’s vision. There is a lot of experiments going on constantly, but the resulting product is surprisingly coherent and unified.
Rayiner Hashem:
Nothing in BlueOS prevents you to:
1) improve a part of the OS
2) find other way to solve an alredy solved problem
3) to fix bugs
Just join the team!
———————————-
Without control/management the project only forks into parallel development and
discussion.
Just imagine how many versions of BButton without a line written for the app_server we would have if there was no “control”???
Computer science is not Jungle
The GPL showed hundreds of time its limitations, hundreds of differents libraries, window manager, web/irc clients, …. sorry the list is too long, but they are ALL doing the same things…nothing is finished.
Could you say that a Linux distribution has the same level of maturity that a closed OS ???? If yes, forget all I wrote…
<blockquote>Just imagine how many versions of BButton without a line written for the app_server we would have if there was no “control”??? </blockquote>
contradicts…
<blockquote>2) [nothing stopping you from] find other way to solve an alredy solved problem </blockquote>
Computer science — ha! Software development benefits from an open process where I can choose. I cannot take your software in a direction you don’t permit – which is fine – but make it clear that this is so.
I’m really starting to hate (really pure HATE) linux and it’s followers. Why? Because of that stupid OpenSource war they like so much. I’m not saying OpenSource is bad or good. I just think that everyone has right to choose what is “the best” for his/her project. It’s THEIR OWN project so stop this stupid war.
> > Just imagine how many versions of BButton without a line written for
> > the app_server we would have if there was no “control”???
> contradicts…
Surely not! dozens of different and not finished implementation of BButton are purely useless and a big a mess. Imagine BeOS if all buttons were different!
Simply confusing and unfriendly!
[tips: you need an app_server to use a BButton… ]
>> 2) [nothing stopping you from] find other way to solve an alredy solved problem
> I cannot take your software in a direction you don’t permit – which is fine – but make it clear that this is so.
I have already written more than 3 times, that all is permitted if you do not use the source for commercial use and if you are helping us to improve/code BlueOS.
Shard : OpenSource war is really stupid, but don’t think that people who wrote/are writing major things for Linux/*BSD (kernel, xfree ,apache…) are stupid [they are often against the GPL …]
I’m not in war but in source code
I’m not saying they’re stupid ;] They’re smarter than me – they write OS
It’s just irritating – those comments about Open Source each time new project has not full open source/gpl license. If someone writes some code it’s his/her decision which license to use. Not gpl fanatics. If BlueOS doesn’t want to give source to everyone in the world that’s ok. If BlueOS will be GPL that’s ok. If BlueOS will be as close as it only can be – that’s ok. If someone doesn’t like it – write your own code and shut up.
error: irritating = annoying. sorry for my english
<blockquote>I just think that everyone has right to choose what is “the best” for his/her project. It’s THEIR OWN project so stop this stupid war. […] If BlueOS will be GPL that’s ok. If BlueOS will be as close as it only can be – that’s ok. If someone doesn’t like it – write your own code and shut up. </blockquote>Please don’t be angry. I said I was accepting of their choice – however I question it. Fact is however that I am not permitted by BlueOS to resolve a problem in a way that I see fit. They say “Surely not! dozens of different and not finished implementation of BButton are purely useless and a big a mess.” but what if I retain the UI but make a more efficient API? You see that choice as pointless – I see it as safety. Your software could not develop if branches or duplication of effort weren’t allowed.
I trust in evolution. It appears that you do not.
I suspect what they’re trying to get across is that BlueOS wants a development model closer to FreeBSD’s than what Linux’s is perceived to be. Essentially, the source code *is* completely open, but only members of the OS development team have commit access to its CVS tree. If you’re someone on the outside you may still make changes, but they’re not going to be official unless someone official commits them, or you convince the development team to make you a member.
Of course, this “thousands of forks” myth is, well, a myth. To the best of my knowledge, there aren’t thousands of button classes in GTK+, either, and despite being quite brazenly open source, there is still only one Linux kernel. I said “what Linux’s [development model] is perceived to be” rather than “what Linux’s is” because in practice, Linux’s seems to work very much like the FreeBSD one, except even MORE centralized: changes to Linux still, by and large, have to be vetted by one person to be official.
It doesn’t honestly sound to me like BlueOS is any more “closed” than Linux or FreeBSD is, despite what both sides seem to be arguing. With the exception of a handful of major splits people love to bring up when they’re trying to argue that there’s a danger of fragmentation when things are “too open,” open source projects don’t fragment–there’s still just one source tree and generally one or two leaders are charge of it. (In the major splits I can think of, in fact, the fragmentation happened because of conflicts in the project leadership. XEmacs couldn’t have existed if GNU Emacs wasn’t open source, but it *wouldn’t* have existed if the programmers at Lucid hadn’t decided it was impossible to work with Richard Stallman.) And, if someone who isn’t on the BlueOS development team comes up with a new wonderful way of doing something and writes code to do it, I’m sure that code could be vetted by a development team member and added to the project. Just like the new Linux VM cited previously.
“I trust in evolution. It appears that you do not.”
Yeah, sure – i’m in stagnation, i’m not thinking at all (or bright enough) just because i think that everyone has right to his/her code ;]
Evolution has many ways.
You are right about our model of development !
The biggest danger is the fragmentation of the curremt team in case of conflict because we are not 200 developers, just 40… by using a GPL or BSD licence you just give the opportunity for people to not solve conflict and fork/explose
To see the chaos (ie forks) in the linux world, just open 20 differents applications and count how many different button or menu style you see.
Maybe 4,5 or 6? There is too much of different UI toolkits, and not an “official” or THE toolkit. UI is one of the things the most “forked” because it’s easy/funny to code. A kernel is something else…
The last example I saw of useless “rebuilt of the wheel” is CVS graphical client!
There are about 10 projects, after hours of install/configuration of all this apps, I was affraid to see that only 2 could be called usable, not really finished or mature by usable. If all developer joined to 1 project, the “ultimate” CVS client would be online for a while…
Well, a certain level of “wheel rebuilding” will go on no matter what. It might not go on in your development team, but if the project takes off–particularly something like an operating system–people *are* going to be out there developing all sorts of “I can do the same thing better than you” applications for it, probably up to and including system components. Look at how many IRC clients BeOS had.
I’m not completely sure that if everyone joined together to make one great CVS client that we’d have actually ended *up* with one great CVS client. If you get two good chefs in a kitchen you might get a better meal than either one alone, but if you get fifteen chefs in the same kitchen, even if all of them are pretty good, you’re probably more likely to get a food fight than a gourmet meal. It may actually be better to have a dozen CVS clients get started and let them “fight it out” for survival–the chances are the one that’s still around in a year is going to end up being something good. And, maybe a few other ones will hang on because they do specific things well. You can see that in Unix mail clients: there’s literally dozens of them, but there’s only two or three that most people ever actually use.
<blockquote>To see the chaos (ie forks) in the linux world, just open 20 differents applications and count how many different button or menu style you see.</blockquote>And you’re making another one because you think you know what’s best. The fact is that you’re right – you do know what’s best. And your choice is what’s best for you. But it may not be best for me and you’re removing my option.<blockquote>Maybe 4,5 or 6? There is too much of different UI toolkits, and not an “official” or THE toolkit. UI is one of the things the most “forked” because it’s easy/funny to code. A kernel is something else… </blockquote>Um, it seems you’re tripping on your own words there. Take BlueOs and you’ve got a desktop that intends to have no duplication and one toolkit. The same goes for KDE or Gnome. What fragmenting do you see here? That they can run other environments? If KDE locked out GTK applications you’d get the same effect. Please explicitly describe the fragmentation you see.
ps. I like any new project. I like the look of BlueOS. Good luck!
I think that it is proper that the BlueOS keep their vital code to themselves until they have a proper release… at that point, considering a GPL or other Free Software license would be more appropriate. After all, what good is the source when it doesn’t build anything?
Linus did not release the source globally from day one, he started small. How many new projects are actually successful? Look at the whole mess round Freedows and such OSes. Forking and fragmentation of a project before it has even established a single project spells doom. Let BlueOS at least reach release 0.9 before pestering them!
Even better, join them. They seem to be asking for more developers. Linus kept his initial releases to a few core developers, and over time that core grew. NetBSD already had 386BSD to start from, they weren’t starting from scratch, so their situation is different. The concern over premature forking is most definately valid. The earliest versions of Linux didn’t have a VM system, it was a request from another user. So Linus wrote one. Rick, Andreas and all of the others waited until Linus had something in place before suggesting improvements. Let BlueOS at least form their OS infrastructure before trying to change it.
I wish the best of luck to the team. My main hope is that BlueOS can do two things:
1. Show that Linux is not an OS; Distributions of Linux to date are all Reimplementations of the standard GNU system, and as such should give more credit. Debian is correct when they call their system Debian GNU/Linux. All of the other GNU distributions are leaving out the credit. If BlueOS is successful, it will clearly be a distinct Operating System despite being based aroud the Linux kernel. Hence BlueOS will be the only OS I am aware of that can be correct and not call itself a GNU system.
2. Contribute significantly to the development of BeOS common subsystems so that FreeBeOS has a better chance; Being based on the Linux kernel will mean that there are still many BeOS advantages that aren’t achievable without significant development of the Linux kernel.
There are many organizations with more power pulling Linux development in contrary directions. If BlueOS shows that All of BeOS functionality can be encompassed within the Linux kernel’s constraints, then that is great! I will support BlueOS to my fullest extent. I feel that this scenario is possible, but very unlikely. Hans Reiser also has his own ideas on where ReiserFS should go, and from what I’ve read on LKML archives, they dont seem consistent with the BeOS vision. Linus did make many improvements on the VFS system that would prove most helpful, but I don’t think that ReiserFS is the answer. Ideally write support for BeFS would be completed, as there was at least read support already in Linux at one point. If BlueOS could smooth the BeFS capabilities into the recent VFS abilities, then a good deal of BeOS capability would be feasible.
Hey, if BlueOS is capable of sufficiently threading the display interface, with file attribute support, and a feasible translator system, then perhaps BlueOS could supercede FreeBeOS after all! The only disadvantage would be lack of binary compatability. As unfortunate as that would be, it would be no worse than the migration from BeOS R3 to R4 on Intel. Now I know that this is all unrealistic… but if you guys can do it, please… Go For It!
The UI was to me one of BeOS’ finest points. The shiftable tabs was an obvious improvement that No other system I know of has. Win 98, Mac OS classic and Amiga UIs were all available as an easter egg, but the only reason I found for them was to play tricks on friends unfamiliar with the BeOS. None match the elegant functionality of Be’s tabs.
As for Mac OS X, I hope you aren’t referring to that dock abomination. I’d have been happier to see them integrate the trashcan into the standard Apple Menu bar somewhere. The apple menu bar was functional and non intrusive, much more efficient than their current mess. It serves more as an advertisement than a tool AFAI can tell.
If you mean that you like the shiny candy buttons, then that would be trivial to implement as another “skin” as was the Win 98 or MacOS window borders. While they may look prettier, how are they an improvement over Win 98 or Mac Classic window borders? The transparency can also be pretty, but its usefulness is very limited. If it is that important, perhaps they can steal the functionality from Enlightenmentment since they are using X11. Do you have any other examples of modern looking UIs?
I never liked the Apple Menu post-System 6, or the Dock. I find something like Drop Drawers or Now Menus much easier to use.
As for transparency, true transparency can be very useful. Check out WindowShade X which can make any window semitransparent. It’s ideal for looking at the contends of what’s behind a window.
Enlightenment uses fake transparency BTW.