Linked by Thom Holwerda on Tue 13th Mar 2018 01:10 UTC, submitted by judgen
PC-BSD

TrueOS, formerly PC-BSD, has a desktop environment called Lumina. It's getting a big overhaul for Lumina 2.0, and this short interview gives some more details about what's coming.

With Lumina Desktop 2.0 we will finally achieve our long-term goal of turning Lumina into a complete, end-to-end management system for the graphical session and removing all the current runtime dependencies from Lumina 1.x (Fluxbox, xscreensaver, compton/xcompmgr). The functionality from those utilities is now provided by Lumina Desktop itself.

[...]

The entire graphical interface has been written in QML in order to fully-utilize hardware-based GPU acceleration with OpenGL while the backend logic and management systems are still written entirely in C++. This results in blazing fast performance on the backend systems (myriad multi-threaded C++ objects) as well as a smooth and responsive graphical interface with all the bells and whistles (drag and drop, compositing, shading, etc).

Order by: Score:
massively bloated
by unclefester on Tue 13th Mar 2018 01:44 UTC
unclefester
Member since:
2007-01-13

It is just as slow and bloated as Windows 10. The App Cafe defeats the primary strength of BSD - the ports.

Recommended Requirements

64-bit processor
4 GB of RAM
20 - 30 GB of free hard drive space on a primary partition for a graphical desktop installation.
Network card
Sound card
3D-accelerated video card

https://www.trueos.org/handbook/introducing.html

All we really need is a polished desktop BSD with a very simple installation process.

Reply Score: 2

RE: massively bloated
by Flatland_Spider on Tue 13th Mar 2018 03:09 UTC in reply to "massively bloated"
Flatland_Spider Member since:
2006-09-01

Egh. PC-BSD never played nicely with ports. My PC-BSD installs usually ended up being incredibly broken because of adding ports.

Don't get me wrong. Ports with a build server are why I really like FreeBSD on servers, but the binary packages have gotten much better in the last decade.

I'm going to go out on a limb and say most of those requirements are due to running ZFS as the default FS. 20-30GB of disk space is right inline with Fedora Workstation install needs, by the way. I can be squeezed into a smaller space, but long term, it's going to need about 40GB.

3D acceleration is just the bar these days for GUIs.

OpenBSD is nice. Clean, tight, minimalist.

Reply Score: 5

RE: massively bloated
by Moonbuzz on Tue 13th Mar 2018 07:34 UTC in reply to "massively bloated"
Moonbuzz Member since:
2005-07-09

It is just as slow and bloated as Windows 10. The App Cafe defeats the primary strength of BSD - the ports.


TrueOS, as the name hints, is yet another case of a nice idea - Beginner-friendly-desktop-directed FreeBSD - becoming a Silicon Valley mess. Once the money entered the scene, it's goodbye good ideas and hello crap wrapped in the most ridiculous brand name in tech history.

You can see the same line of thinking in Canonical with their "Unity on Mir" which has now, a few dozens of millions of dollars down the drain later, became "Gnome on Wayland".

Reply Score: 4

RE[2]: massively bloated
by r_a_trip on Fri 16th Mar 2018 08:59 UTC in reply to "RE: massively bloated"
r_a_trip Member since:
2005-07-06

You can see the same line of thinking in Canonical with their "Unity on Mir" which has now, a few dozens of millions of dollars down the drain later, became "Gnome on Wayland".


The Mir and Unity situation is not quite as dire. Mir will end up a Wayland compositor (like many of us predicted back then). Unity 8 lives on in community projects and might even deliver a feature complete desktop.

Reply Score: 3

PC-BSD / TrueOS and Ports
by DrJohnnyFever on Tue 13th Mar 2018 04:15 UTC
DrJohnnyFever
Member since:
2012-03-07

In current versions of TrueOS everything is implemented using packages in the back end (even the base system is packaged) the old PBIs are dead. When you install something with AppCafe it installs the relevant packages (there is a cli for everything as well). The primary reason for the fairly steep system requirements are due to root-on-ZFS.

Reply Score: 2

Whoa
by Poseidon on Tue 13th Mar 2018 06:04 UTC
Poseidon
Member since:
2009-10-31

I've been out of the loop on the PC-BSD for a long time I guess. Last time I used it, it came with KDE and was a install/user friendly alternative to Desktop-BSD while trying to overhaul the file-system.

Need to give this version a shot.

As for the requirements, it's almost for sure due to 64-bit system operation, you don't want to be memory starved while running the OS and apps. You could probably get by on less memory, but the system will start thrashing when it fills up the memory while multitasking.

Reply Score: 1

Crashing
by nicubunu on Tue 13th Mar 2018 07:12 UTC
nicubunu
Member since:
2014-01-08

I would not feel comfortable with the idea that any script or tool crash will crash your entire desktop. I see it is labeled as a security "feature", but to me it looks like very user unfriendly.

Reply Score: 3

RE: Crashing
by Delgarde on Tue 13th Mar 2018 10:06 UTC in reply to "Crashing"
Delgarde Member since:
2008-08-19

I would not feel comfortable with the idea that any script or tool crash will crash your entire desktop. I see it is labeled as a security "feature", but to me it looks like very user unfriendly.


Yes, that was my reaction too. Running the entire desktop in a single (multi-threaded) process does have some advantages for performance and memory efficiency, but it sounds like a nightmare for reliability... any bug anywhere in that code has the ability to crash the entire user session. There's a reason why the big desktops favour multi-process models, where potential problems can be isolated...

Plus, the entire thing is multi-threaded C++... and while I concede that it's possible to write good multi-threaded C++ code, it's damned hard to get right. There's a reason the Mozilla guys looked at the idea of better exploiting multi-threading in their C++ codebase, and decided that the first step was to design a new language to do it in...

Reply Score: 2

RE: Crashing
by DrJohnnyFever on Tue 13th Mar 2018 17:15 UTC in reply to "Crashing"
DrJohnnyFever Member since:
2012-03-07

Would you rather have your desktop environment crash and restart or have a component crash and have things break in unexpected and unpredictable ways with little indication as to why?

Crash big and crash now.

Linux bug_on vs warn_on is the same discussion.

Reply Score: 2

RE[2]: Crashing
by darknexus on Tue 13th Mar 2018 18:56 UTC in reply to "RE: Crashing"
darknexus Member since:
2008-07-15

Crash a little. At least that gives me time to save and clean up. If you really think crashing big is preferable, clearly you've not been employed in any serious capacity.

Reply Score: 3

RE[3]: Crashing
by DrJohnnyFever on Tue 13th Mar 2018 20:02 UTC in reply to "RE[2]: Crashing"
DrJohnnyFever Member since:
2012-03-07

The general idea is to avoid having to crash at all, which is beyond the scope of this discussion. If you want to debate what is more likely to crash to begin with, FreeBSD or ex. Ubuntu I know what I'll bet on.

But if something is broken you want it to fail. If something crashes little you'll never get it fixed. If you want to build reliable systems you need to kill them when they break so you can examine the corpse.

See Bryan Cantrill's talk 'Zebras all the way down' at Uptime 2017 on YouTube.

For the record I'm currently employed and have to deal with software that partially fails all the time. Clearly you aren't a developer or an admin that actually has to fix crap when it breaks.

Reply Score: 0

RE[4]: Crashing
by nicubunu on Tue 13th Mar 2018 20:50 UTC in reply to "RE[3]: Crashing"
nicubunu Member since:
2014-01-08

I am an end user working as a freelancer with photography, graphics, DTP and web stuff on a Linux desktop. Stability wise is a little better than Win 3.x, but not by much.

Reply Score: 3

RE[4]: Crashing
by FlyingJester on Wed 14th Mar 2018 21:09 UTC in reply to "RE[3]: Crashing"
FlyingJester Member since:
2016-05-11

This is known as "fail fast", and it's a strong methodology even outside native programming.

There is a difference from being error tolerant (not crashing when you read a corrupt file), and accepting errors (allowing unexpected results from internal operations). The risk of not immediately halting when an unexpected internal error occurs is that data may be corrupted, security may be compromised, and the defect may become much harder to detect. This is as opposed to intentionally crashing (or halting with an invariant), which signals the first moment an issue was detected, and assumes that since an invariant is not accurate, no action is viable.

As an example, if you detect memory corruption in a file manager, you should NOT try to save any partially copied files, meta data, etc. You should just crash, or you should halt without any further action. The worst case scenario would be that there was an out-of-bounds array write of a user's password (or private keys), and it is now in the meta data or copied file buffer as plain text, and saving the data out would place it on the filesystem.

Reply Score: 2

RE[5]: Crashing
by ssokolow on Thu 15th Mar 2018 02:53 UTC in reply to "RE[4]: Crashing"
ssokolow Member since:
2010-01-21

Yes, but if you can use interprocess isolation to keep things separate, then you can limit what has to fail to maintain safety and integrity.

Reply Score: 3

v RE[6]: Crashing
by DrJohnnyFever on Thu 15th Mar 2018 18:53 UTC in reply to "RE[5]: Crashing"
RE[7]: Crashing
by FlyingJester on Thu 15th Mar 2018 20:53 UTC in reply to "RE[6]: Crashing"
FlyingJester Member since:
2016-05-11

That has very little to do with the DE.

Reply Score: 2

RE[7]: Crashing
by zima on Thu 15th Mar 2018 22:38 UTC in reply to "RE[6]: Crashing"
zima Member since:
2005-07-06

That's good in theory.

Your "general idea is to avoid having to crash at all" is also good in theory...

Reply Score: 4

RE[2]: Crashing
by nicubunu on Tue 13th Mar 2018 20:43 UTC in reply to "RE: Crashing"
nicubunu Member since:
2014-01-08

Considering a desktop is something where you do work, I pretty much want not to lose data. A big crash usually brings data loss.

Reply Score: 4

RE[3]: Crashing
by DrJohnnyFever on Tue 13th Mar 2018 22:00 UTC in reply to "RE[2]: Crashing"
DrJohnnyFever Member since:
2012-03-07

Like I said before the goal is to not crash at all. A little crash is likely to cause you to loose the data you're working on. A little crash could cause you to loose data you're working on and potentially persist unnoticed causing you to loose data without you realizing it. This is why Unix (including Linux) has panic. It could try to march on but it's dangerous.

Reply Score: 1

RE[4]: Crashing
by acobar on Wed 14th Mar 2018 00:00 UTC in reply to "RE[3]: Crashing"
acobar Member since:
2005-11-15

Wishful thinking much? Reality check: list one really useful application that is not overlay complex and that does not crash eventually. MS Word, MS Excel, IDE(s), Autocad (common Autodesk, make it at least runable on Linux, even if only under Wine!), Matlab, just to name few. To any user, it is way preferable to be able to save his work and restart the offending application than it is to point fingers to particular application developers and scream "Fix your mess or I will not use this piece of garbage anymore!".

It is a fact that as applications grow, the ones that have no option but to grow to accommodate new features as they evolve, will see new bugs introduce while some old are shredded.

Unless your needs are really trivial, you better have a chance to save that fck work you have been doing at closing hours where every minute counts.

And I'm not even talking about from where the fateful error crawled from: OS, hardware, driver?

Really, reality should trump wishes, always.

Reply Score: 3

v RE[5]: Crashing
by DrJohnnyFever on Wed 14th Mar 2018 07:00 UTC in reply to "RE[4]: Crashing"
RE[4]: Crashing
by nicubunu on Wed 14th Mar 2018 06:30 UTC in reply to "RE[3]: Crashing"
nicubunu Member since:
2014-01-08

All desktops have the goal to not crash at all, but all of them crash sometime.
In a desktop workflow is preferable to lose *some* of your data than lose *all* of your data.

Reply Score: 3

RE[4]: Crashing
by Delgarde on Wed 14th Mar 2018 06:45 UTC in reply to "RE[3]: Crashing"
Delgarde Member since:
2008-08-19

Like I said before the goal is to not crash at all. A little crash is likely to cause you to loose the data you're working on. A little crash could cause you to loose data you're working on and potentially persist unnoticed causing you to loose data without you realizing it. This is why Unix (including Linux) has panic. It could try to march on but it's dangerous.


Well yes, the goal is to never crash. But if the choices are a) one bug takes out the entire desktop and losing all unsaved work, vs b) one bug causes some small component of the desktop to crash and restart without affecting anything else, guess which one I prefer?

Reply Score: 3

Lumina
by jessesmith on Tue 13th Mar 2018 13:58 UTC
jessesmith
Member since:
2010-03-11

Almost all the comments so far are about PC-BSD/TrueOS rather than Lumina, so I want to toss in some of my experience with the desktop. One thing I like about Lumina is it's very portable - minimal dependencies allow it to run on almost any UNIX-like platform, including odd systems like GNU/kFreeBSD.

I ran Lumina for a little over a year, with various window managers (the default Fluxbox and Kwin mostly). It's light, it doesn't have many features, but is pleasantly flexible. Almost everything can be moved, resized or rethemed.

My only serious concern, riding the desktop from about version 0.8 through to 1.3, was that each update introduced a lot of changes. It was still a growing project and each new release relied on new packages, changed the look or location of items. It meant rapid progress, but also some re-learning if you were staying on the cutting edge.

I'm curious to see how the new, unified stack works out. One complaint I had with Lumina in the past was I didn't like the way the underlying Fluxbox WM does some things, and swapping in an alternative window manager would break short-cut keys or other little features. Having the desktop be the window manager will (I'm hoping) fix all the little problems which came up with communication between the desktop and the window manager.

Reply Score: 5

ZFS?
by grat on Tue 13th Mar 2018 17:11 UTC
grat
Member since:
2006-02-02

I thought ZFS still required ECC memory?

Reply Score: 3

RE: ZFS?
by DrJohnnyFever on Tue 13th Mar 2018 17:19 UTC in reply to "ZFS?"
DrJohnnyFever Member since:
2012-03-07

Requires is a strong word. It works without it but you loose some of the advantages of the checksumming. The general consensus from the ZFS developers is that zfs without ecc ram is not any worse than any other fs without ecc ram.

Reply Score: 3

RE[2]: ZFS?
by judgen on Tue 13th Mar 2018 19:41 UTC in reply to "RE: ZFS?"
judgen Member since:
2006-07-12

The XFS developers claim that XFS beats EXT and ZFS out of the water if neither has ECC.

Reply Score: 1

RE[3]: ZFS?
by DrJohnnyFever on Tue 13th Mar 2018 19:56 UTC in reply to "RE[2]: ZFS?"
DrJohnnyFever Member since:
2012-03-07

In what respect?

Reply Score: 2

RE[2]: ZFS?
by grat on Wed 14th Mar 2018 16:06 UTC in reply to "RE: ZFS?"
grat Member since:
2006-02-02

Except according to a fairly well-regarded blog post by Louwrentius (and I admit it's a dated article):

File systems such as NTFS, EXT4, etc have (data recovery) tools that may allow you to rescue your files when things go bad due to bad memory. ZFS does not have such tools, if the pool is corrupt, all data must be considered lost, there is no option for recovery.

So the impact of bad memory can be more devastating on a system with ZFS than on a system with NTFS, EXT4, XFS, etcetera.

Reply Score: 3

RE[3]: ZFS?
by DrJohnnyFever on Wed 14th Mar 2018 18:06 UTC in reply to "RE[2]: ZFS?"
DrJohnnyFever Member since:
2012-03-07

Comparing ZFS to ext4 with fsck is not even close to apples for apples. ZFS has more comprehensive error correction than fsck built in, constantly working. It doesn't just handle superblocks and metadata either, it also checks and heals the data itself which fack does not do.

Fact of the matter is, with ZFS you're massively more likely to notice data errors due to memory corruption immediately whereas with ext4 and xfs you'll find out some day when you try to use the data. ext4 will gladly read back corrupt data and give it to you, it's oblivious. ZFS is going to tell you, it checks every block.

The idea that you're going to trash your zpool completely because of memory errors is so unlikely as to be irrelevant when comparing to ext4. Ext4 is going to hose your data way before ZFS does due to bad ram.

I would say it would be like saying you shouldn't wear a seatbelt (zfs) because there's a 0.02% chance it'll make it hard to escape a burning car. Okay, but the 99.98% of the time it's going to save your life.

Reply Score: 1

RE: ZFS?
by jessesmith on Tue 13th Mar 2018 20:07 UTC in reply to "ZFS?"
jessesmith Member since:
2010-03-11

ZFS has never required ECC memory. It's just a nice bonus to have if you want to use internal checksums. Using ZFS without ECC is just like using every other file system without ECC.

Reply Score: 5

Comment by ssokolow
by ssokolow on Wed 14th Mar 2018 02:33 UTC
ssokolow
Member since:
2010-01-21

I leave my desktop logged in for weeks on end. This would be anathema to me, given that every process on my desktop has crashed, frozen, deadlocked, or livelocked (same outward symptoms as a deadlock, but with a CPU core pegged at 100%) on me at some point or other and I'm very glad that, 99% of the time, the crash is in neither /usr/bin/X nor whichever session manager I happened to be using at the time. (ksmserver, lxsession, etc.)

Heck, it's for that reason that I'll be very cautious about moving to Wayland. I want to wait for KWin (SSD or DWD forever) and my apps to incorporate some variation on Enlightenment's compositor crash recovery protocol and I want to verify the claim in one of Martin Flöser's previous blog posts that KWin is now notable for the work put into it to improve code quality and broaden automated testing.

When (not if) something like KWin or Openbox or Plasma or LXpanel or PCManFM or any other desktop component that isn't the X server or the session manager dies, the session manager restarts it and I continue working.

Edited 2018-03-14 02:34 UTC

Reply Score: 3

Reliability
by DrJohnnyFever on Fri 16th Mar 2018 00:49 UTC
DrJohnnyFever
Member since:
2012-03-07

No we don't want ZFS and FreeBSD, I don't like the fact that Lumina 2.0 will actually crash if tries reading another processes memory. What I really want is Systemd and Btrfs which doesn't work properly to begin with. Throws the champagne out with the cork.

Reply Score: 0