Does Desktop have a future on BSD?

May I kindly ask for your approvement to go back on topic? Thank you for your generosity.
Show stoppers:
  • Bluetooth (OOTB)
  • WLAN/WiFi beyond 54 Mbit/s
  • suspend/resume does not work reliable: e.g. my external audio plug gets no signal after resume (*)
  • automagic hardware detection with kernel & userland drivers attachment is incomplete
  • FreeBSD@ARM not mature (tablets & StupidPhones are mostly ARM)
  • EDIT2 all that gaming stuff
  • younameit?
I.e., I can't install the almighty yea free BeaSD on my buddy's or sister's laptop, neither on my mother's tablet.
EDIT * maybe I did not understand the bug fixing methodology well enough, but IMHO it could be improved: see e.g. my periodic weekly tells me for several weeks now:
Code: 
Checking for out of date packages:
anacron-2.3_7 succeeds index (index has 2.3_6)
see PR 253567
 
Does Linux have that? I know that with CentOS, for MTP on a system with dwm/openbox, I have to manually mount my phone with simple-mtpfs, though maybe Gnome and friends do it automatically. With FreeBSD, jmtpfs works well, with a single simple command, (or two commands, depending upon whether fuse is loaded).

This is personal preference, but I don't want automounting of such devices and prefer to do it manually. Also, on my phone, if I connect it to the computer, I have to manually specify on the phone (a Pixel), that I want to allow file transfer, which I think is a good thing.
 
Zirias said:
Anything other than buzzwords here?

Which actual problem does it solve?
Click to expand...

beanpole said:
There were actually a few reasons we moved to OpenRC for TrueOS:
1) Speed (as mentioned) - OpenRC is a (nearly) drop-in replacement for the current FreeBSD RC system, but since it is written in C instead of tons of shell scripts you get massive performance improvements (even without parallelization enabled)
2) Reliability: OpenRC is *very* reliable at managing/reporting the state of your services at any given time. With the FreeBSD RC system ~50%+ of the running services are nearly unmanagable (return errors when you run `service <name> status`, cannot be reliably started/restarted/stopped due to the "unknown" state of the current service, etc..)
3) Persistence: OpenRC has a couple built-in supervisor systems for watching/managing services:
`start-stop-daemon` is the standard start/stop supervisor which reports states such as starting, started, running, stopped, crashed, and I am sure a couple more as well.
`supervise-daemon` is a superviser for critical services which should "always" be running - in addition to the start-stop-daemon, this has built-in crash handling for critical services and will automatically restart them as needed. This is worlds better than running additional layers of shell scripts and backdoor daemons (such as the daemontools mentioned previously) to try and "fix" things in the current RC system.
4) The history/license: OpenRC was created by a NetBSD developer and distributed under a two-clause BSD license. While it was adopted and "battle-tested" in a few Linux distros such as Gentoo, there are no real "Linux-isms" in it (we just had to clean up the Makefiles to work with the BSD make instead of the GNU make). If you look at the current `rc.d` system in FreeBSD, it had a similar history where it was developed on/by a NetBSD developer and FreeBSD adopted it later on. This move to OpenRC is just seems like the next logical evolution of the current FreeBSD RC system and continues the path set in motion previously by the FreeBSD project.


These are number of additional niceties that we have discovered after the switch to OpenRC on TrueOS - they were not part of the initial reasons for the move, but they definitely solidify our position that OpenRC was the right way to go, but I want to mention one of the big ones:
**Per-device management**
If you list all the current services you will see things like "network","network.em0", "network.wlan0", and more. These "network.<device>" services can be started/stopped/restarted individually *without* touching any other network devices and helping to ensure stable network connectivity on servers and such even when making configuration changes to particular devices. This is a ton better than the old way of completely tearing down and rebuilding the networking stack just because you wanted to change a static IP on one device.
This actually continues with other non-networking services as well (such as `moused`), so you can manage/restart particular devices on-demand rather.

I hope this helps to clear up some of the talk about *why* we moved to OpenRC for TrueOS. My personal hope is that we are "battle-testing" it for FreeBSD right now on TrueOS and that we can help spearhead this for including it in FreeBSD for version 13+ or something.
Click to expand...
 
Speed? Well, if you boot your system all day long…

Then you have two points about "supervising" services, including the horrible idea of automatic restarts on crashes. Don't complain later if a service shreds your data. Any other form of supervision is not the scope of rc, and can easily be integrated if needed.

Then, why is the license relevant for something you don't need in the first place? The point about network interfaces is just uninformed, the netif service handles them separately.
 
"My personal hope is that we are "battle-testing" it for FreeBSD right now on TrueOS and that we can help spearhead this for including it in FreeBSD for version 13+ or something."

The post was from 2017. The link in OP's post "Improving TrueOS: OpenRC" leads to"

Open Letter to the TrueOS Community
TrueOS Discontinuation
*snip*
I can’t explain just how much we appreciate you all being loyal fans of TrueOS and PC-BSD in the past.
Click to expand...

I have many times.
 
I'd like to add a current & a recent example where IMHO a more modern init system would help:
  • Since it's last update, my net/vnstat does not start the daemon vnstatd(8) reliable anymore (occasionally, I have to manually restart it). Of course that's very likely an error in it's service(8) script, but maybe a system driven by simple configuration data would be more robust? Shell scripts are error-prone per se ...
  • Recently I managed to screw up my ndispatch(3) name services, thereby killing the syslogd(8). I did not notice that syslogd(8) is not running for quite a while, because I have not yet set up a monitor. The point is: monitoring could be closely tied to the init system; it doesn't have to & can be completely independent. But if the init(8) system provided it OOTB, that would be an enhancement IMHO.
 
I object both of these arguments.
  • Have a look at the init script in question: It's simple and just uses the (proven) mewburn rc library. The only thing it adds is some custom preparation, which you'd probably need with any init system, so, you'd script it. Either the problem is around there, or it's a problem with the daemon itself, neither of these would be solved by a different init system.
  • Monitoring is definitely useful, but should never be integrated in init itself. The whole userspace depends on init (e.g. it inherits any orphaned process); if it has bugs, your whole system is affected. So, an init-system delivering monitoring in a sane way would make it optional and implement it in a separate tool. Then, what's the advantage as opposed to just installing a standalone tool?
 
Beastie7 said:
OpenRC. Long overdue. init/rc.d is getting a little long in the tooth for an increasingly dynamic/asynchronous world.
Click to expand...
No thanks. Used it for years on Gentoo, and it's progressively getting worse. The original developer abandoned the project and the current maintainer is a systemd fanboi.

Check out the idiocy that is Opentmpfiles. That's right, a whole language and interpreter written in shell to create files and directories! All the in the name of systemd compliance.

The tmpfiles step takes several minutes on my last remaining Gentoo server because it scales poorly with the number of modules that exist in your /lib/modules hierarchy. Yes, just the number that exist in that hierarchy, even if they're not loaded. Fast is one thing Openrc is definitely not.
Beastie7 said:
And before all the greybeards throw a hissy fit; it was conceived by a NetBSD developer. It's safe.
Click to expand...
He was a Gentoo developer when he developed Openrc. He abandoned Openrc and Gentoo and found a home in the Netbsd project.
 
darkoverlordofdata said:
I'm not trying to compare BSD to Linux - in fact they are almost identical. But these issues were the issues Linux had 10 years go. Maybe worse, or I would still be using Windows......
Click to expand...
No comments from a guy with only 2 posts in the forum, no experience on BSD....
Enjoy yourself in Windows forums....
darkoverlordofdata said:
the attitude of the BSD developers which can be summarize as "it's a server, why are you trying to use it for your desktop?".
Click to expand...
this is a joke, isn't it?
darkoverlordofdata said:
I think desktop BSD will be little more than a toy.
Click to expand...
BSD is not a"toy"...........this forum isn't "toy" either.....
Stop being annoyed. It's really easy just drop into this forum, say bad things about BSD and run away...
good luck, pal!
 
Jose said:
No thanks. Used it for years on Gentoo, and it's progressively getting worse. The original developer abandoned the project and the current maintainer is a systemd fanboi.

Check out the idiocy that is Opentmpfiles. That's right, a whole language and interpreter written in shell to create files and directories! All the in the name of systemd compliance.

The tmpfiles step takes several minutes on my last remaining Gentoo server because it scales poorly with the number of modules that exist in your /lib/modules hierarchy. Yes, just the number that exist in that hierarchy, even if they're not loaded. Fast is one thing Openrc is definitely not.

He was a Gentoo developer when he developed Openrc. He abandoned Openrc and Gentoo and found a home in the Netbsd project.
Click to expand...

That's interesting. Because I didn't see any of these issues brought up in either the 2018 Developer Summit, various mailing list threads, and the code review submission in phabricator. It sounds like your 'concerns' are more mechanism than implementation, which I'm sure is trivial to remove/refactor.
 
Thank you Jose for that bit of information.
This should be sufficient to quote when anybody comes mentioning OpenRC.
While I like the idea of doing particular things with tools that are more efficient, I do not like any bad influence from L*x.
And that shell-based interpreter... that's the crown of all.

Back to topic:
Mjölnir said:
Show stoppers:
  • suspend/resume does not work reliable: e.g. my external audio plug gets no signal after resume (*)
Click to expand...

The Wiki suspend/resume page is old, lot of obsolete, misleading/distracting info and much of the necessary content missing, marked as "TBD".

Furthermore, I haven't yet seen any efforts to collect hardware data regarding the completeness of their drivers.
Many drivers don't (correctly) implement the SaveStatus (before sleeping/powering off) and RestoreStatus functionalities, others work fine.

Thus, it would imho be very valuable to have hardware lists that show whether this works, and possible flaws, like when resume only works partially (say, sound works except some line input, etc).
Such information is not collected in the various BSD hardware databases, but could be very helpful to find/choose hardware that is known not to cause suspend/resume issues.

What could be the best approach to collect such information?
I guess forums, wiki and mailing list.

What would be needed to collect, for example, for sound devices?
pciconf info, product (embedded in laptop/mobo or separate PCI card?), NID maps?, driver/version used, ...?

*brainstorm*
 
Answering questions from the topic title... Meh.

I've installed freebsd 13 on my ThinkPad t460 and... And it still has almost all problems which was before and which make freebsd almost unusable on desktop.
I love freebsd for its simplicity and laconic. I don't mind to spend some time to learn and manually tweaking. But everything has a limit.

I don't want to write driver for acpi which works bad (acpi hotkeys don't work, crashing on cover closing, etc).
I don't want to pin my audio devices to get just internal microphone and headphones jack work. It's nightmare.
I don't want get randomly malfunctions of WiFi on boot.
I don't want to live without ac WiFi.
And so on.

Do not misunderstand me. I like freebsd as I said before. I have to use Debian on on laptop because... Because it just works. Despite of strange systemD and awful pulse audio which I hate.

Sorry for the excessive emotionality.
 
boombim said:
Answering questions from the topic title... Meh.

I've installed freebsd 13 on my ThinkPad t460 and... And it still has almost all problems which was before and which make freebsd almost unusable on desktop.
I love freebsd for its simplicity and laconic. I don't mind to spend some time to learn and manually tweaking. But everything has a limit.

I don't want to write driver for acpi which works bad (acpi hotkeys don't work, crashing on cover closing, etc).
I don't want to pin my audio devices to get just internal microphone and headphones jack work. It's nightmare.
I don't want get randomly malfunctions of WiFi on boot.
I don't want to live without ac WiFi.
And so on.

Do not misunderstand me. I like freebsd as I said before. I have to use Debian on on laptop because... Because it just works. Despite of strange systemD and awful pulse audio which I hate.

Sorry for the excessive emotionality.
Click to expand...
I sympathise, but, if you really "like freebsd", then take the time to note down the issues and post a bug report.
All the moaning in the world on this forum will not get the attention of the developers (apologies, you aren't moaning but others do).
If you post the bug report, maybe no one will look at it, but there's more of a chance someone will. It's 10 minutes of your time.

Citing a recent discussion on a forum option for freebsd-current, one to help people file bug reports would be a welcome addition instead.
 
Snurg said:
Thank you Jose for that bit of information.
This should be sufficient to quote when anybody comes mentioning OpenRC.
While I like the idea of doing particular things with tools that are more efficient, I do not like any bad influence from L*x.
And that shell-based interpreter... that's the crown of all.

Back to topic:


The Wiki suspend/resume page is old, lot of obsolete, misleading/distracting info and much of the necessary content missing, marked as "TBD".

Furthermore, I haven't yet seen any efforts to collect hardware data regarding the completeness of their drivers.
Many drivers don't (correctly) implement the SaveStatus (before sleeping/powering off) and RestoreStatus functionalities, others work fine.

Thus, it would imho be very valuable to have hardware lists that show whether this works, and possible flaws, like when resume only works partially (say, sound works except some line input, etc).
Such information is not collected in the various BSD hardware databases, but could be very helpful to find/choose hardware that is known not to cause suspend/resume issues.

What could be the best approach to collect such information?
I guess forums, wiki and mailing list.

What would be needed to collect, for example, for sound devices?
pciconf info, product (embedded in laptop/mobo or separate PCI card?), NID maps?, driver/version used, ...?

*brainstorm*
Click to expand...
To cut a long story short...
You don't need a database, you just need to file a bug report and add your hardware characteristics to it if they don't work.
Then, if changes are made, volunteering to test will make the effort worthwhile.
Just my thoughts.
 
mark_j said:
You don't need a database, you just need to file a bug report and add your hardware characteristics to it if they don't work.
Then, if changes are made, volunteering to test will make the effort worthwhile.
Click to expand...
As I understand the problem with sound chips, it is usually the OEM NID wiring that makes things difficult when it deviates from the reference implementation. Laptops are particularly evil in this regard.
So, without actual NID info not all things (inputs, outputs) can work. Without the NID table data, there is little the driver developers can do to add support for a particular sound card configuration.

Due to the multitude of sound cards, most of them crappy consumer grade stuff, it is virtually impossible to cover all cases.
So I'd think it would make more sense to support only a small set of sound devices, but support these well.
So a list of these (and the deviating OEMs to avoid) could make things much easier and avoid user frustration.

BTW, I like your idea of making sort of HOW TO for writing usable bug reports, depending on the hardware they are about.
So developers do not need to ask again and again for the things they need, instead get them in the first place.
 
scottro said:
Does Linux have that? I know that with CentOS, for MTP on a system with dwm/openbox, I have to manually mount my phone with simple-mtpfs, though maybe Gnome and friends do it automatically. With FreeBSD, jmtpfs works well, with a single simple command, (or two commands, depending upon whether fuse is loaded).
Click to expand...
There is a kio slave for MTP devices in devel/kio-extras that should enable KDE applications to access MTP devices and I guess there is similar support in gvfs. Problem is, as of now the detection of MTP devices does not work, probably due to the downfall of HAL, so basically it's of no use right now.

As for jmtpfs, works well is debatable. I had tested it on several occasions, first it was working, then it was not for no apparent reason, now it is working again but showed some strange behaviour (occasional crashes when listing directory contents, file permissions show up all wrong).

scottro said:
This is personal preference, but I don't want automounting of such devices and prefer to do it manually. Also, on my phone, if I connect it to the computer, I have to manually specify on the phone (a Pixel), that I want to allow file transfer, which I think is a good thing.
Click to expand...
Yes you have to set the USB mode to 'file transfer' before it can be accessed via MTP. There's also a default USB mode, so you could set it to always use file transfer mode, but personally I would consider that a security risk. Technically there is nothing to mount as an MTP device is not a direct-access block device, MTP is a file based protocol more like FTP, so automounting is not the right term. However, what a normal desktop user would expect (and rightfully so) is to plug in the device, open the file manager and be able to work with the device without having to issue commands in a shell before and after working with the device. As it is now on KDE, such devices do not even show up in it's device notifier, so integration is basically zilch.
 
mark_j said:
I sympathise, but, if you really "like freebsd", then take the time to note down the issues and post a bug report.
All the moaning in the world on this forum will not get the attention of the developers (apologies, you aren't moaning but others do).
If you post the bug report, maybe no one will look at it, but there's more of a chance someone will. It's 10 minutes of your time.

Citing a recent discussion on a forum option for freebsd-current, one to help people file bug reports would be a welcome addition instead.
Click to expand...
I did. For example I've sent bug report about acpi hotkeys to the `freebsd-acpi` mailing list.
And I get response. Person suggest me to prepare script...

Anyway do you really guess freebsd team dunno about acpi issues or WiFi issues or sound output issues? Of course they know. Just looks like desktop (or laptop, ok) is not their primary goal. I saw some roadmaps about improving WiFi stack and audio driver. So team know about everything. Maybe lack of resources. I don't know.
 
My two cents: FreeBSD fullfills my Desktop requirements to 100% - on the "big machine" at home as well as on my small netbook. Of course, setting up a netbook with FreeBSD the way I like it means a lot more work to do than with some other operating systems (… hm … maybe Windows would rob me much more time - and no-one says it's not for the desktop - so that's not an argument at all); That belongs to the circumstance that a) not anything is enabled by default (what means: an admin has to do some homework, but has full control over what's going on right from the start), and b) the desired applications are third party and mostly "as is" from the upstream. But that's what I like about FreeBSD - two of the reasons why I use it: As a desktop!

Stuff like "suspend to disk" I would never use - I want a clean boot when I'm using my computers, and a full poweroff when I'm done with my work. And things like "magical new icons" on my desktop f.e. when a USB disk is plugged in are IMO a design failure for a multi user OS: Why the hell does that mean that the user with display XY should have access to it? But as always: Sacrifices are gladly made on the altar of comfort without thinking about their price.

And what discussions about "init systems" have to do anything with desktop usage will always be a miracle to me: My understanding of "desktop users and their desktops" tells me they never get in touch with such stuff; And the often named "faster boot" argument is history with todays desktop hardware: If the boot takes 15 or 16 seconds no-one notices, the longest time of the boot process the manufacture of the mainboard catches before hitting my boot drive (so the most potential for optimizations are IMO outside any OS).

Not FreeBSD specific, but always named for the open source scene at all "why it sucks for the desktop": Hardware support. Well, over the last 25 years I had none hardware that didn't worked - even when setting up systems for others on their choice of hardware. So, where's the problem? The hardware support is great!

MTP? I only see geeks wanting their phones to be connected to their computers, that's not an opener for the desktop. But as "MTP" is named here…: I wouldn't claim any OS to support MTP, but Google to activate mass storage via USB again (what was their interest to pay their developers for disabling it since Android 5? before it was present…) - I would think everyone would suggest USB mass storage as self-evident on a smartphone. But hey, let's blame others not to take part in not giving full control of their own data. Having control of my data is another reason for FreeBSD on my dektop.

The average desktop users hates the command line (requires knowledge and has no modern touch). That's why it is not for the masses: You won't get far avoiding it. But IMO "not for the masses" is something complete different than "no future for the desktop", there's no "either or".
 
You must log in or register to reply here.
Back
Top