Linked by Thom Holwerda on Thu 24th Apr 2014 23:06 UTC, submitted by sheokand
PC-BSD

The PC-BSD project is developing its own desktop environment from scratch! The ultimate plan is for Lumina to become a full-featured, open-source desktop environment that may ultimately replace KDE as its default desktop environment.

A Phoronix reader, Ryan Bram, wrote in to share word on this new desktop environment being developed by the PC-BSD crew, the popular desktop-focused derivative of FreeBSD. This new desktop is called Lumina and is being developed as a home-grown desktop environment catered toward this BSD operating system.

While it's obviously cool, I wonder if it's a wise idea to undertake such a huge endeavour. I honestly doubt PC-BSD has the developers, testers, and users required for creating, maintaining, and improving an entire desktop environment.

Thread beginning with comment 587550
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE: Hawaii?
by r_a_trip on Fri 25th Apr 2014 11:44 UTC in reply to "Hawaii?"
r_a_trip
Member since:
2005-07-06

Does any of the BSD's have the required kernel infrastructure to support Wayland and systemd? As that is what Maui is targeting.

The way things are developing, the BSD's may become the standard bearers for SysV init, X window system and the continued availability of an X based desktop environment. I think that is a good thing. Disclaimer: I'm a Linux desktop user.

Reply Parent Score: 5

RE[2]: Hawaii?
by tidux on Fri 25th Apr 2014 16:49 in reply to "RE: Hawaii?"
tidux Member since:
2011-08-13

>BSDs

>SysV init

Dumbass, BSD has NEVER used SysV init, even when it still came from Berkeley. They use their own BSD style init, which is simpler but still shell based.

As for the Wayland port, OpenBSD was considering some preliminary work for it as part of a GSoC 2014 idea.

Reply Parent Score: -1

RE[3]: Hawaii?
by Doc Pain on Sat 26th Apr 2014 01:11 in reply to "RE[2]: Hawaii?"
Doc Pain Member since:
2006-10-08

BSD has NEVER used SysV init, even when it still came from Berkeley. They use their own BSD style init, which is simpler but still shell based.


FreeBSD has moved from rc to rc.d, beginning somewhere in v5, if I remember correctly. In rc style init system, /etc/rc will execute other scripts like rc.local, rc.network, rc.firewall, rc.foo, rc.bla and so on. A comparable initialization mechanism has been used in System III if my memory serves me right. The newer rc.d system uses shell scripts located in the /etc/rc.d directory which contain keywords in order to have rc determine the correct order (PROVIDE and REQUIRE). Those scripts act according to parameters like "start" and "stop", they can be used in combination with the "service" command.

However, FreeBSD can emulate SysV init (see "man init" for details) when called as a user process, for example "init 1" or "init c".

Reply Parent Score: 4

RE[3]: Hawaii?
by Soulbender on Sat 26th Apr 2014 08:16 in reply to "RE[2]: Hawaii?"
Soulbender Member since:
2005-08-18

They use their own BSD style init, which is simpler but still shell based.


Each BSD actually has it's own init style and all of them gloriously are free of the idiotic runlevels.

Reply Parent Score: 3

RE[2]: Hawaii?
by demetrioussharpe on Sat 26th Apr 2014 03:47 in reply to "RE: Hawaii?"
demetrioussharpe Member since:
2009-01-09

Does any of the BSD's have the required kernel infrastructure to support Wayland and systemd? As that is what Maui is targeting.


Since those projects will continuously evolve with the Linux kernel & constantly change as the Linux kernel interfaces change, there's no way for the BSDs to have the required kernel infrastructure. Linux has, historically, changed infrastructures as fast as infants' diapers are changed. Really, it's not a matter of having the infrastructure, it's more-so of stabilizing the interface to the infrastructure. The BSD systems don't change interfaces & infrastructure on a dime. They also don't expect to have to continuously change their software for the sole purpose of an API change. Engineer a solution, then add it; rather than patch a problem & spending the next 2 decades engineering solutions for the problems that the patches cause.

Reply Parent Score: 3