TrueOS: anyone using it on a laptop?

Trihexagonal
The TrueOS community forums are very different from here: there tends to be a very low tolerance for outright BS and/or trollish comments. You just happened to join in on a thread where one of those people was being called out by the community. Your remarks were quite civil, and if you make your own threads/tickets about any issue(s) that you experienced, your questions will be answered or responded to in the same tone that you use.

No hard feelings.
 
For those who are impatient and don't want to wait Lumina to flourish, but still want an out-of-the-box experience. Would you be open to a GNOME 3 or KDE spin of TrueOS, shipped?
There is already a collaboration ongoing to accomplish this exact thing. I can't say any more at the moment since it is not my place to make this announcement, but stay tuned to FreeBSD news sites for a full announcement.
 
Oko : Go ahead and propose it to the bsdnow guys, they know I am always game for something like that. Just note that I restrict myself to TrueOS matters: FreeNAS and other derivative projects are outside my realm of responsibilities
 
  • Thanks
Reactions: Oko
Dear beanpole,

I seem to have agitated you much.
My experience with PC-BSD/TrueOS on laptop was so devastating that I think that it deserves to be told. People should know what expects them imho. This is neither OT nor "hijacking".

And the case of the so-much-praised "TrueOS update system" which under the hoods is apparently still mostly is the infamous pc-updatemanager from PC-BSD...
And then the fact that anytime a buggy 12-CURRENT commit can have the consequence that TrueOS users cannot work with their computers.

This will damage every of them who has no back up system (i.e. other than TrueOS) he/she can work...
Imho these things have much to do with responsibility and ethics.

I compared that to the Ford Pinto case.
GM back then was criticized heavily because they calculated in the victims, as it was cheaper to pay compensations than to fix the problem which caused many people getting burned alive.

Isn't the parallel obvious?
As Oko put it correctly, so many users got burned.
Do you really think that the comparison with the Ford Pinto tank fires engineering scandal is inappropriate?

OT:
Anyway, beanpole posted a link to a TrueOS forum discussion thread.
I'll share a very funny post I found there:
TrueOS is for TrueBelievers. Until another religion comes along, TureOS is the religion here. So, let’s play, prey and hope for the best in TrueOS.

Yo’ll have Happy and Merry Holy’days
slight_smile.png


Peace/A’men

Happy Christmas to all you guys, no matter from what sect! :)
 
Not all free and open-source projects are ugly, because, thanks to God and GTK developers, Qt is not the only one toolkit in the *nix world.
There are a lot of projects which looks nice and IMO even much better than Windows (which UI is unusable and is a total crap IMO, all versions)
or even MacOS, which IMO is not so "beautiful", just a proprietary stuff with some bright colors, using colored title bar buttons,
and if you like it, this can be easily emulated in many WM-s, many DE-s can be much more nice when using some theming.
Reading this, I realize that there's nothing I can say or do to convince someone holding a belief like this otherwise. If that's what you truly believe, you are probably most at home on a terminal shell. You are someone able to set up their full desktop system from scratch and feel that this is the best way to do things. You are also not the intended target audience for something like macOS. Which makes you part of the problem why open source OSs will never, ever, in a million years become usable by the average user. This kind of mindset keeps artists, designers and psychologists away from most open source projects because frankly, when you are about to donate your time, you don't want to have to debate a bunch of developers about the need for something to be the way you propose. It's frustrating to have to explain everything from zero. You expect cooperation and recognition of your skills, just like every developer does. And when the reply to a structural UI suggestion is "works for me, we should focus on technical issues", you leave for an area where you can effect progressive change and your training and experience is actually valued.

The train wrecks that are WM themes may cater to the "hacker type" personality quite well but are in no way something a regular user would choose given the commercial alternatives. And no, users are not stupid or easily blinded by "some bright colors" or "colored title bar buttons". They recognize what helps them achieve their goals the best. As do you.
Some of your statements are fairly correct, but you get me wrong, I wrote nothing about creating
"full desktop system from scratch ", this is pure conjecture on your part, I wrote that many WM-s or DE-s,
like Xfce or Mate for example, can be easily customized, by changing its theme and configuration, and this
can be easily done using its settings, by ticking some options and downloading desired theme from
www.gnome-look.org, for example. And even a very "average user" is able to do this.
 
I respectfully have to notice that you don't know much about the chemistry of various BSD groups. Otherwise you would not be asking that question. Let me give you thumbs up. HAMMER 1,2 or or any other major peace of code written by Matt Dillon will never run on FreeBSD, FreeBSD will never default to LibreSSL and OpenSSH release will always be several releases behind with "backward compatibility" patches which introduce security vulnerabilities. PF will continue to rotten and it will never be updated.

I think that, in some time from now, we will see LibreSSL in the base, and I think as HAMMER2 will be finished, there may be a chance that we will se it in FreeBSD, keep in mind that DragonflyBSD is a FreeBSD fork which should make porting easier. FreeBSD project also quite often ports available portions of good software into base. I would like to see DMA (DragonflyBSD Mail Agent) instead of Sendmail.

There is also other initiative - HardenedBSD - which follows the principles of OpenBSD, seems like a good direction for me, especially that You get all the features of FreeBSD and some of the OpenBSD security.
 
vermaden I would be very interested in getting ASLR, and Hammer2 into TrueOS. At this point I would not want to attempt a 3 way merge but if there were small enough changesets to bring those features I want them. Assuming the changes are not too invasive like launchd was with mach.
 
Oko Actually OpenRC is my fault. I spearheaded that effort, I did a large part of the work, and convinced the others.

What is the short version of your sales pitch for this? I've literally never seen an easier-to-use init system than BSD's rc.

It was largely my idea to make TrueOS a rolling release, and I had to do a lot of convincing to make it happen.
That's somewhat understandable, but as someone else mentioned you may have been better off opting for an MFC approach. I don't do the work, and don't know how difficult it would be, so I won't criticize this choice.

Even the idea to use the name we owned "TrueOS" I pushed for. No one else wanted to go that direction.

Since you mention this.... I never really thought it was a very appealing or marketable name. But whatever, in my opinion that's not a major concern. The most important thing is defining a benefit and making sure you deliver on it.
 
The main difference between OS X and a "primitive" UNIX system like FreeBSD are: the use of launchd instead of rc.d scripts, PLISTS instead plain text files, and most importantly the lack of modern file system on OS X. However the last one should be fixed soon as soon as OS X completely transition to Apple File System (APFS)

I've always found your comments interesting and entertaining, I like the no-BS and blunt tone of them. :beer:

If FreeBSD and Mac OS are so similar, why can't FreeBSD easily adopt many of the desktop benefits of OS X? I've always genuinely been curious about this.

I don't do OS design, so I'm very ignorant of these things. But other than the flags used in some utilities like `ps` and `ls` I don't see many similarities between FreeBSD and OS X. Even the hierarchy on Mac is a lot different - and weird.
 
(Sorry for brainstorming, tl;dr)

If FreeBSD and Mac OS are so similar, why can't FreeBSD easily adopt many of the desktop benefits of OS X? I've always genuinely been curious about this.
The thing is that FreeBSD does *not* put its users into a corset, does not define itself by its desktop, but by its core.
People choose FreeBSD not because of "its desktop", but for other reasons.

Both main desktop principles - Apple's strict and Microsoft's loose "desktop discipline" - are perfectly supported on FreeBSD in the way of Gnome and KDE.

The only problem is the seamless lack of the integration of FreeBSD to these desktops - all those system-dependent things, mostly of administrative nature.
To most "normal" people a computer OS is "good" when:

  • common computer handling skills are sufficient to set up a working system. That is, no need to edit config files, and by no means ever the need to use something esoteric the guys call "console" or "terminal".
  • the desktop is seamless. All things match the look+feel and the design guidelines of the preferred OS. No "patchwork" impression.
  • no essential things of nowadays personal computers are missing, like Bluetooth, reliable suspend+resume (to RAM as well as to disk)
  • the most common hardware is supported in a timely manner

This are just a few possibly very important aspects important to "normal" users.
We can learn a lot from Apple.
Much of MacOS stuff is powered by scripts hidden behind a seamlessly-integrated frontend UI.

Thus I ask myself, could it be a good idea to make a framework of system administration scripts designed for communication with a GUI frontend, like Apple did for their own use?
So that there is some sort of "API" that assists integrators to seamlessly add this stuff into desktops like Gnome, KDE etc.
An advantage of such an "API" would be that the integrators are *not* required to have deep system knowledge of every component of FreeBSD, which bars many people willing to volunteer from doing so.

Couldn't this be a sensible approach that could make integration of FreeBSD *much* easier?

Let me explain why I am thinking about these things so much.
I am currently working on a jail manager that is actually easy to use, both for beginners and professionals.
As a consequence of this I am implementing the interactive part of my utility in a manner that can be integrated easily into all those environments.
And this means that I had to include thoughts about the UI from the beginning, for those users who prefer not to use the command line.

A simple approach into the direction of frontend-independent system administration has already been done by the dialog (1) utility which is been used by many installers.
So it has been very simple to add a graphic installer to FreeBSD - they just added a graphical based frontend to the text-based one, without having to make much work on the backend side.
This way they needed not to write another full installer, but just quickly added an empty frontend GUI shell.

Ideally the integration would be that easy that integrators have not to do much more than creating dialogs with the actual desktop framework's (Qt, Gtk,...) dialog editors and do all the fine-tuning so that the UX is smooth, and just attach that to the scripts that do the actual work.

Currently there is much redundant work in this area.
Every single of these separated "desktop building" groups (Mate/GhostBSD, Lumina/TrueOS,...) repeats this big effort again and again.
This kind of having-to-reinvent-wheels-integration approach thus has a divisive and weakening effect on the BSD community.

Thus I believe it might be worth thinking about how this kind of redundant work could be avoided, achieving the goal of making seamlessly integrating FreeBSD into KDE, Gnome and all these DMs much easier.

But how can we achieve that this is actually BSD compatible?
Meaning that the possibility to do manual (or scripted) configuration editing does not get blocked by interactive configuration utilities that do not respect changes done to them by others (scripts, admins)?
Apple solves this problem by making the config files XML (thanks herrbischoff for hinting at that). This way they can be edited manually too. However, this breaks much things and it is probably no much joy to edit such files.
So the correct solution would be to have a sort of parsing-lexing interface utility library so that interactive utilities can easily make changes without clobbering the config files more than necessary.

Thus I am thinking about how the situation would be, if there exist:
  • parsing-lexing routines for handling the most common types of config files (i.e. read the config into a data structure, write back changes into the config file respecting its formatting)
  • script/API interfaced interactive configuration utilities that are easily integrable into different GUI frameworks
I ask myself: Would then be so much motivation (maybe even the need?) for integrators to fork to make a separate distro just to support a single DE, instead of staying in the FreeBSD project and just working on integrating the respective DE's?
 
And regarding the problem of brand-new hardware support:

What about making a repo for CURRENT device drivers that STABLE/RELEASE users can use?


It would make MUCH difference if I can run RELEASE and take only one or two drivers from CURRENT that are missing in RELEASE!
Because, I then could run a practically stable system, the risk would be limited to the driver component...

Is this possible?
 
What is the short version of your sales pitch for this? I've literally never seen an easier-to-use init system than BSD's rc.

Off the top of my head BSD licensed, written in a compiled language, dependency caching, service supervision, simplification of init scripts, parallel boot, better documented, and less invasive than other options. There is more to it of course if you factor in dhcpcd but I will save that discussion for a future Q&A as proposed instead of hijacking this thread too much.
 
That's somewhat understandable, but as someone else mentioned you may have been better off opting for an MFC approach. I don't do the work, and don't know how difficult it would be, so I won't criticize this choice.

lonestar To respond to your comment, and answer similar question from Snurg if it were that simple that is what we would have done for sure. Take for example drm-next-kmod. It is in ports right? Yet it doesn't run on anything older than 12-CURRENT. Why is that? In order to run it many other kernel changes including linuxkpi have to be used. Yes it would be possible to MFC kernel changes but that would entail even more manpower. Also my experience trying to get wireless drivers backported for several 10.x releases in a row was disappointing. I would rather have gone that route for sure. I would rather TrueOS not have to exist at all, and there were an official FreeBSD desktop team that I could just be a part of. But at this stage I am more interested in TrueOS.
 
It would make MUCH difference if I can run RELEASE and take only one or two drivers from CURRENT that are missing in RELEASE!
Because, I then could run a practically stable system, the risk would be limited to the driver component...
The risk, is always here.
 
This makes me feel uncanny, to be honest.
systemd is a main reason why I do not use Linux anymore.
Snurg In a branch I have support to toggle between rc.d, and openrc. As is it works but requires some changes to pc-updatemanager. However if pkg-base gets support for etcupdate (one of the reasons we need pc-updatemanager) then I won't need to touch pc-updatemanager. Which is kind of why I held off as I have heard that was coming. Anyways I am going to give this thread a rest. I am happy to also participate in a future Q&A to field further questions.
 
vermaden I would be very interested in getting ASLR, and Hammer2 into TrueOS. At this point I would not want to attempt a 3 way merge but if there were small enough changesets to bring those features I want them. Assuming the changes are not too invasive like launchd was with mach.
I would say You are 1/3 there, as FreeBSD has ASR (not ASLR), You can have 2/3 with HardenedBSD which has ASLR (not ASR), but currently there is not 3/3 with HAMMER2 also onboard ;) From what I recall HAMMER2 is not even finished.
 
Yes, I tried TrueOS on a laptop.

It is far inferior to FreeBSD in almost all aspects. Yes, it boots quicker than PC-BSD used to. But at least PC-BSD worked a little better.

The laptop that I do most of my stuff on is a 32 bit laptop I run FreeBSD 11 on. Works pretty flawless, no issues at all. The laptop I tried TrueOS on is a 64 bit laptop with 3 gigs of ram and an intel card. Again FreeBSD 11 works wonderfully on it with no issue.

TrueOS is buggy regardless of laptop issues. There are frequent posts of having to switch to an old boot environment because some update makes the system unbootable. Not all services start(avahi and others) and some start intermitantly. Openrc effectively made many programs not work at all until they get around to making them work with openrc.

Older intel cards(like my laptop) only work with VESA unless you manually do a work around. And after you did that work around the driver they have installed alters the colors of any QT apps so the colors are off.

Not on my laptop, but frequent slugginess of the system, even locking up the mouse(possibly caused by Lumina copying every single application you install to the desktop). And on that system it is currently in the state where you just get a black screen with the X-windows mouse cursor after PCDM login, and it stays like that forever. The sysadm software install program that the run on boot-up is buggy. Sometimes crashes, sometimes shows no apps, sometimes crashes in the middle of a software install so that the install keeps going but you have no idea on the progress or errors. Lumina is buggy and has far fewer features than other windows managers. Environments other that Lumina often times need work to get working if you can get them working at all.

Sleep did not work on my laptop. Sleep worked on FreeBSD 11 and after I replaced TrueOS with FreeBSD 12, sleep also worked on FreeBSD 12. FreeBSD 12 ran so much smoother than TrueOS.

I use ZFS on my FreeBSD laptops, and don't have any issues. It is nice TrueOS allows you to install to install ZFS on a partition without having to know much, however it didn't take me too long to learn how to do it with normal FreeBSD. Yes, they allow you to automatically install a gui, but again that is pretty easy to do on normal FreeBSD. In my view TrueOS isn't really usable as anything but a test system. I tried PC-BSD awihle ago and like others found it slow and no real reason to use it. In my view TrueOS is much worse.
 
I have used PC-BSD for almost 1.5 years on my laptop until some time recently.
The most terrible problems I had with PC-BSD were caused by their "pc-updatemanager" that runs every night on PC-BSD.

I got:
-damaged grub blocks
-destroyed boot environments
-zfs filesystem filled up 100%, 0 byte left (a very bad situation on zfs because in this case you cannot use rm anymore, it fails due to insufficient space)

These kinds of damages are not trivial to fix, partially even need physical access to the computer to use an emergency boot medium.
Thus, if TrueOS still contains that "pc-updatemanager", I won't recommend anybody to use it for production.

Using PCBSD or TrueOS might save a few hours to install/configure because of its preconfiguration.
But in the end it has cost me much more time, due to the need to fix these things listed above.

Yes, I had hit-and-miss experiences with the OS, probably due to it's using CURRENT. OTOH, if you want to run CURRENT and don't want to build your own desktop, it's the easiest way to do that if it works. I guess it's not exactly CURRENT, but instead snapshots which are vetted to some extent. And yes - the pc-updatemanager occasionally wants to overturn the boat. I was disabling it (pretty easy to do) - but on the newer proxied machine the manager isn't savvy enough to get out of the box, so it is causing no problems.
 
Well, just to add something... :D
I use GhostBSD (11.1) on my laptop... with MATE and I like it! It´s stable and you could update via "pkg update".
So if you got spare time, you should give it a try... :)
Cheers!
 
I have been thinking a while.
Today's desktops involve much more than programmers.
Today artists and psychologists are the actual "leaders" in desktop shaping.

I was watching Ken Moore's talk at KnoxBUG recently and a lot of the infrastructural design choices make sense (API based, portability, etc), but he overlooks the user experience, and what the experience should look like.

Respectfully, I believe more user involvement would be beneficial in smoothing out the desktop experience with TrueOS.

The few things I found over a couple days didn't take any special skills, just normal use of a desktop as someone who uses a FreeBSD desktop on a daily basis.
 
Well, just to add something... :D
I use GhostBSD (11.1) on my laptop... with MATE and I like it! It´s stable and you could update via "pkg update".
So if you got spare time, you should give it a try... :)
Cheers!
I will 2nd this. When I tried GhostBSD I also liked how it did. I didn't really find any bugs with it. Everything got installed at once. It is basically FreeBSD with everything installed, plus you get a nice gui network thing in your taskbar.

The reason I left them is they stopped support for 32 bit and at the time it didn't support ZFS in a partition.

They plan to base their next distribution off of TrueOS, but might also have another version off of FreeBSD as well. The current GhostBSD is nice and I could recommend that to anyone.
 
While you, guys, from TrueOS, are trying to do something,
FreeBSD will never become a good desktop OS,
while its developers use MacOS. Also it is
a very bad marketing strategy, to say
that you're "FreeBSD kernel developer, but I use MacOS..." (Apple™ payed (or paying) some money to this guy?).
You're advertising MacOS then, an operating system for housewives, with a lot of adware,
like Windows, and not FreeBSD. You're literally saying that FreeBSD is a crap for desktop usage,
and while the position of some members of FreeBSD team is like this,
FreeBSD will never become more popular and more usable
on a desktops, than GNU/Linux (and its non-systemd variants),
because while some of its desktop features are very poor (like suspend-resume and some GPU support)
some people will never start to use it on their desktops,
when they'll see that FBSD developers are MacOS fans...
Young "future system administrators and developers" will start to use GNU/Linux,
of course they'll never switch to FBSD, when they'll grow up (this is why Android uses Linux kernel, and not BSD).
And any TrueOS or GhostBSD projects will never help to change this.
Unfortunately it is the realities of our day (IMO).
 
Back
Top