A FreeBSD 10 Desktop How-To(cooltrainer.org)
cooltrainer.org
A FreeBSD 10 Desktop How-To
https://cooltrainer.org/a-freebsd-desktop-howto/
181 comments
I use Arch because of this: Having been an Ubuntu user, and watched my system break every 6 months Because Reasons, I despise magic: I want to know what my system is doing, because when it breaks, I'm the guy that's got to fix it.
Arch has been consistently more breaky for me than Ubuntu. It is fashionable to bash Ubuntu but I have found it quite polished as long as you don't try to color outside the lines.
I have used FreeBSD on the desktop since 1996. I am not a system guru. I have never used an install guide. I only ever used the guided installer and just let it run. It has always just worked. But there is also nothing to be gained by using FreeBSD...because coloring inside the lines on FreeBSD means using their polished tools to manage your system. I never ended up exploring my system much because I never had to...sysinstall did it for me.
Indeed in the late 90s when Linux distros were immature, I recommended FreeBSD to people who wanted a "just works" approach that let them continue to be as systems-stupid as me.
I see Ubuntu as the best current manifestation of what FreeBSD always was for me...the quickest, friendliest path to get a unix-like OS on your computer with lots of good defaults and hand-holding.
I have used FreeBSD on the desktop since 1996. I am not a system guru. I have never used an install guide. I only ever used the guided installer and just let it run. It has always just worked. But there is also nothing to be gained by using FreeBSD...because coloring inside the lines on FreeBSD means using their polished tools to manage your system. I never ended up exploring my system much because I never had to...sysinstall did it for me.
Indeed in the late 90s when Linux distros were immature, I recommended FreeBSD to people who wanted a "just works" approach that let them continue to be as systems-stupid as me.
I see Ubuntu as the best current manifestation of what FreeBSD always was for me...the quickest, friendliest path to get a unix-like OS on your computer with lots of good defaults and hand-holding.
I might be lucky but my current installations of Arch are very bug-free. (except for a could bugs in the software, but I just report those to the upstream developers and they get fixed) I remember the last time my system broke, it was when they merged /bin and /usr/bin. I then proceeded to read the news posting wrong and break my system. Then it was up to me to fix it and it took about an hour.
On my other computer I correctly followed the post and had no issues.
https://www.archlinux.org/news/binaries-move-to-usrbin-requi...
I use the gnome offline updates with no fear, just whenever I turn off my computer I check the "Install Updates" options when it is available. It is all beautifully seamless.
On my other computer I correctly followed the post and had no issues.
https://www.archlinux.org/news/binaries-move-to-usrbin-requi...
I use the gnome offline updates with no fear, just whenever I turn off my computer I check the "Install Updates" options when it is available. It is all beautifully seamless.
Yeah, Ubuntu was never like that for me: every 6 months my system would break in a new and exciting way, and I couldn't fix it. But that's just me. FBSD is a bit more like Arch with a nicer installer, IMHO: minimal, text-based, highly configurable, and well-documented.
Nitpick: Arch mimics FreeBSD.
Or rather, mimics CRUX, which imitated BSD-style init scripts.
Or rather, mimics CRUX, which imitated BSD-style init scripts.
True.
Although Arch uses systemd now by default, which is bad. I've replaced it with OpenRC. http://systemd-free.org has instructions if you want to do it yourself.
Although Arch uses systemd now by default, which is bad. I've replaced it with OpenRC. http://systemd-free.org has instructions if you want to do it yourself.
Last month I installed OpenBSD on my laptop, and was frustrated with its boot time.
I'm using an SSD. Debian 8 with KDE boots up in a matter of seconds. OpenBSD on the other hand needed at least 20 seconds to boot up.
I had done some research at the time, and came to the conclusion that it was systemd that allowed Linux to boot up so fast.
What is your experience with OpenRC?
I had done some research at the time, and came to the conclusion that it was systemd that allowed Linux to boot up so fast.
What is your experience with OpenRC?
IIRC, OpenRC supports parallel boot. s6 and runit definitely do. And none of those are Linux specific. In fact, there have been projects to run them on BSD.
Anyways, you don't need systemd for a fast boot.
Anyways, you don't need systemd for a fast boot.
Why do you care about boot time? I boot my laptop maybe 6 times per year or so, probably even less. I wouldn't care if it took even longer...
I guess you're probably right, I usually boot up just once in the morning. The truth is, being a performance freak, I expected OpenBSD to fly on my current hardware.
After much tweaking and struggle I couldn't get the DBus working, hence couldn't install GNOME.
i3wm as my window manager and manual configuration of everything especially the wireless connection were too spartan for me. So I switched back to Debian 8 + KDE.
After much tweaking and struggle I couldn't get the DBus working, hence couldn't install GNOME.
i3wm as my window manager and manual configuration of everything especially the wireless connection were too spartan for me. So I switched back to Debian 8 + KDE.
I use i3 regularly, but I don't use wifi much. Honestly though, using netbsd with wpa or wpa2 doesn't look too hard, and you can write a script to automate the worst of it. It's by no means the horror that is iw/iwconfig and wpa_supplicant (insert ritual chants of horror and disgust).
hmm does suspend not work for you? OpenBSD is quite laptop friendly, more so than the other BSDs I'd say. If you're booting every morning then I can understand it being a bit annoying.
OpenBSD is probably the worst when it comes to overall performance of all the BSDs, and Linux.
OpenBSD is probably the worst when it comes to overall performance of all the BSDs, and Linux.
During the day I suspend my laptop, but at night I power it off, out of habit I guess.
And I have this superstition that if I leave my laptop plugged-in to any sort of cable at night, it might get hacked while I'm sleeping.
I'll try suspending the next time I install OpenBSD.
And I have this superstition that if I leave my laptop plugged-in to any sort of cable at night, it might get hacked while I'm sleeping.
I'll try suspending the next time I install OpenBSD.
And I want the middle piece, full magic is fine but a detailed manual with all the magical relations identified and tools to inspect areas where the magic is having issues.
Yeah, that's impossible. Because then you don't have magic, you have the same nonmagicality of Arch, but with none of the simplicity, so you have to learn even more complex, distro-specific tooling. It's the worst of both worlds.
I still wonder why Canonical promotes non-LTS versions as stable releases. They are not. LTSes are and you only have to update once every two years, or 3-5 years if you wait for your current release to be EOL'ed.
Non-LTS releases are really just development snapshots to give you a sneak-peek of features coming in the next LTS.
At my company we used to upgrade our workstations with each and every Ubuntu release. It was a mess. As soon as we started to jump between LTS versions, every problem vanished. And upgrades are almost painless. We have a rock solid stable base and we can upgrade select packages through PPAs.
Non-LTS releases are really just development snapshots to give you a sneak-peek of features coming in the next LTS.
At my company we used to upgrade our workstations with each and every Ubuntu release. It was a mess. As soon as we started to jump between LTS versions, every problem vanished. And upgrades are almost painless. We have a rock solid stable base and we can upgrade select packages through PPAs.
The stability of non-LTS releases is comparable to somewhere in-between testing and unstable in Debian, despite of what Canonical wants everyone to believe.
Debian Testing doesn't break your machine every few months.
Well, that's nice.
I think this is what always turns me off from using Linux on the desktop as my main. With Arch do you feel you have a better sense of why things break when they do? Tempted to try it out because of things like what you said.
I've been using arch for about 3 years and I think that things break just as often (actually, probably more often) and you're generally not left with a better sense of what the root cause is. Sure, you have less software installed, but you're also usually running bleeding-edge versions of everything and things are noticeably less stable.
I do think that from an educational standpoint, arch linux is a good OS to use, as you will probably get a lot more comfortable with the linux environment. This is largely out of necessity as you will spend a great deal of time setting up and fixing your system.
If you have the time to debug the various components of your system, it can be quite fun and educational to use, but if you're interested in getting work done I cannot recommend arch linux at all.
I do think that from an educational standpoint, arch linux is a good OS to use, as you will probably get a lot more comfortable with the linux environment. This is largely out of necessity as you will spend a great deal of time setting up and fixing your system.
If you have the time to debug the various components of your system, it can be quite fun and educational to use, but if you're interested in getting work done I cannot recommend arch linux at all.
Huh, it seems people's experience varies a lot. I've been using Arch as my primary OS at work and home for something like 4 years now. It's been quite stable and low maintenance. It has broken a 3 or 4 times, but my Windows install that I play games on has broken more times than that.
Yeah, that's been my experience as well. I tried ubuntu first, and that broke every 6 months. Finally, a kernel upgrade rendered my system unusable, and I switched to Fedora once it was fixed. Fedora didn't break as much, but it still broke. Finally, I switched to Arch. I've been able to fix any breakage, and my system's been fine ever since.
Isn't it strange in 2016 that its considered ok to break at all?
No. Software breaks. The question is when, and if it's fixable. With Arch, I find the answers are "soon" and "yes".
Aaaaugh! I meant "not so soon." Arch breaks infrequently for me.
I liked the first response better.
I find it plenty usable for work. And because you're usually hand-writing the configs, it's much easier to root-cause than ubuntu. And it doesn't break every 6 months.
I've never used Arch, although I've considered it. I was a Gentoo user for many years, and went through some breakage here and there. I finally went to Ubuntu and friends because it was cutting edge enough without the breakage that I've always experienced with cutting edge stuff. Even with the breakage from Gentoo, it was always much better than Windows, although windows has gotten much better since the Win95 days. I hardly have problems with Ubuntu, and I use mostly Xubuntu on my laptops.
Arch is all about user control. They have a fantastic package manager, the AUR (a user-supplied source build repo) the ABS (an official source build repo, akin to ports), and you can install yaourt (which can automate installation and updates from the AUR).
But by far Arch's best asset is the Wiki. The Arch Wiki is a godsend: a large repository of documentation on just about everything you'd want to do, complete with instructions for the most common cases. Want to do a basic install? Go look. Want to configure pulseaudio (why you would, I don't know)? It's right there. Want to encrypt your disk? pick your poison, and get to it. X? Check. 3d cards? AMD or Nvidia, proprietary or open, if there's hangups, we'll tell you how to fix it. Games? From steam to just about anything else, there's documentation for getting then running.
There's a reason many arch users will tell you to RTFM if you have a question. But if you've done that already, the forums are quite helpful.
The only snag is that systemd is installed by default. However, like everything, the wiki has docs on how to switcg to another system, like sysvinit or openrc. Even more luckily, some very kind Arch users have gone above and beyond that, and created a repo with most of the openrc initscripts, and forks of necessary packages that are without systemd. These instructions are better, and can be found at http://systemd-free.org, under 'installation' and 'configuration'.
But by far Arch's best asset is the Wiki. The Arch Wiki is a godsend: a large repository of documentation on just about everything you'd want to do, complete with instructions for the most common cases. Want to do a basic install? Go look. Want to configure pulseaudio (why you would, I don't know)? It's right there. Want to encrypt your disk? pick your poison, and get to it. X? Check. 3d cards? AMD or Nvidia, proprietary or open, if there's hangups, we'll tell you how to fix it. Games? From steam to just about anything else, there's documentation for getting then running.
There's a reason many arch users will tell you to RTFM if you have a question. But if you've done that already, the forums are quite helpful.
The only snag is that systemd is installed by default. However, like everything, the wiki has docs on how to switcg to another system, like sysvinit or openrc. Even more luckily, some very kind Arch users have gone above and beyond that, and created a repo with most of the openrc initscripts, and forks of necessary packages that are without systemd. These instructions are better, and can be found at http://systemd-free.org, under 'installation' and 'configuration'.
So a tinkering person who has in the past used Slackware (at the end it looked like a bastardized Linux From Scratch), *BSD and after much meandering settled on a minimal Debian desktop, but still uses Mint at work, should probably feel at home, you say?
Yeah. Arch borrows heavily from the BSDs. It even used to use their init system. Nowadays, OpenRC is the way to go if you don't want to deal with systemd.
Might try OpenRC just as well. I've always liked the NetBSD rcorder-based startup, and OpenRC reminds me of it in some ways. But to be fair, I'm not in a hurry to replace sysv-rc.
IIRC the FBSD init is derived from NetBSD, though diverged since early 2000's. There's a FSBD project to integrate OpenRC, and it's pretty far along. I think the objective is to replace the current init system with the more modern and flexible one.
So, do you still use sysv-rc on your Debian/Mint? I've been trying to hold on to System-V on a Debian for what, about 2 years?, but some bugs found their way in after all and I gave up. Don't like the fact at all, installed OpenBSD wherever Nvidia is not involved and FreeBSD where it is, but still booting Debian from time to time.
I left Mint (17.X, the MATE spin) with whatever default rc the Mint guys chose. Upstart, I guess. My efforts go into customising my home system to my liking and these days my tastes are simple: Sawfish+dmenu or CDE, when I feel nostalgic.
I'm now writing on a Debian… er… something… system. That version which tried to force systemd down my throat. I switched back to sysv-rc right after the update. What bugs are you referring to?
Hopefully the possibility to switch rc will remain in future (I hear Gnome these days depends on systemd, WTF), otherwise I'll have to look for something else once again. Arch, probably. Or Slack + pkgsrc. Or I'll go back to NetBSD.
I'm now writing on a Debian… er… something… system. That version which tried to force systemd down my throat. I switched back to sysv-rc right after the update. What bugs are you referring to?
Hopefully the possibility to switch rc will remain in future (I hear Gnome these days depends on systemd, WTF), otherwise I'll have to look for something else once again. Arch, probably. Or Slack + pkgsrc. Or I'll go back to NetBSD.
Suspend, for one, stopped working for me with sysv-rc. The fact that it's an 8 years old testing/sid mix could contribute.
I found that simple tastes make for an easy switch to... anything (for values of 'anything' not including lunatic fast-moving all-eating godzilla-sized init monsters obviously). My poison is some tiling wm (xmonad or spectrwm work best) + dmenu. A single config file is all you need (my spectrwm config is 4 lines long).
As for a system to switch to Slack seems to be one of the last Linux strongholds. Arch (like Debian) needs tweaking to switch from systemd. There are also those Devuan guys... We'll see what future holds.
I found that simple tastes make for an easy switch to... anything (for values of 'anything' not including lunatic fast-moving all-eating godzilla-sized init monsters obviously). My poison is some tiling wm (xmonad or spectrwm work best) + dmenu. A single config file is all you need (my spectrwm config is 4 lines long).
As for a system to switch to Slack seems to be one of the last Linux strongholds. Arch (like Debian) needs tweaking to switch from systemd. There are also those Devuan guys... We'll see what future holds.
Strange, suspend/hibernate with uswsusp works like a charm for me. For the first time since kernel 2.6, too. The only bug which occasionally bites me is that after several suspend/resume cycles the screen randomly blanks for a while and then restores its previous state. Killing X doesn't help, it's the same in the console. Only a reboot fixes it. I suspect the Intel BT driver.
http://systemd-free.org provide painless instructions for the switch on Arch.
Have you tried i3wm? It's my wm of choice, it's tiling and it uses dmenu by default. How does it stack up against spectrwm/xmonad?
Have you tried i3wm? It's my wm of choice, it's tiling and it uses dmenu by default. How does it stack up against spectrwm/xmonad?
No, I haven't, at least recently. I switched to tiling about 7 years ago, tried a range of WMs (dwm, ratpoison), stuck with awesomewm for several months, but as it was changing to Lua-based configuration with too much of a flux, I left it for xmonad. Two things that immediately struck a chord with me were multi-monitor support and sane keyboard shortcuts. This post¹ may add something for you.
I learned of spectrwm only recently, it clones xmonad's UI, but is more practical (written in C, ini-style configuration vs Haskell code, doesn't need GHC installed). Painless switch for an xmonad user.
¹ https://www.acehack.org/posts/2015-09-19-i3.html
I learned of spectrwm only recently, it clones xmonad's UI, but is more practical (written in C, ini-style configuration vs Haskell code, doesn't need GHC installed). Painless switch for an xmonad user.
¹ https://www.acehack.org/posts/2015-09-19-i3.html
[deleted]
Sysv is just kinda... yuck. There's a reason that there's a desire to replace it, and it's not just the desire for proper process supervision. It's a really ugly system. OpenRC is a lot better, but rc.d wins on simplicity.
Agree on yuckity :) But 'simple' is a big thing. 'Familiar', too.
Minit, busybox init, s6, and rc.d are all simpler. Familiarity, on the other hand...
There's always Antergos which is essentially Arch + magic (installer + scripted updates). It just works with little configuration. Problem with Arch or any rolling release is you will download a gigantic amount of updates every day it felt like I was rolling dice with my system stability everytime.
> With Arch do you feel you have a better sense of why things break when they do?
Yes
Yes
Because Arch makes you do everything, the answer to why it broke is always you.
There was an unofficial motto to that effect at one time.
There was an unofficial motto to that effect at one time.
Except when it's not, and the answer is the maintainers [1].
[1] https://bugs.archlinux.org/index.php?do=details&task_id=5051... (hit this myself a couple days ago)
[1] https://bugs.archlinux.org/index.php?do=details&task_id=5051... (hit this myself a couple days ago)
Nowadays, the reason why it broke is either you, or Systemd. But the reason why your system has systemd is that you didn't uninstall it.
Your system might have also broken because you didn't read the RSS feed, which warns of potentially breaking changes.
When in doubt, blame yourself. Or Alan.
Your system might have also broken because you didn't read the RSS feed, which warns of potentially breaking changes.
When in doubt, blame yourself. Or Alan.
I use Manjaro and my system just doesn't break. I've been in if for the better part of this year and ice not had to fix anything outside of a GUI.
I would make the exact opposite argument.
I set things up the way I want them many years ago, and because everything's a text file, my configs have followed me across many machines and OS installs by just copying some files.
With more "magical" desktops like Gnome, developers like to change things every 6 months, and then I've got to mess around with the settings to try and not have it disrupt my workflow. And as soon as bring a new machine up I'm spending half a day mousing through menus and trying to remember all the things I set last time.
I like FreeBSD with a minimal desktop precisely because I've got more important things to be doing than messing around with settings. Yeah, the work is front-loaded, but the payoff is that I spend years not even thinking about the desktop or the OS.
I set things up the way I want them many years ago, and because everything's a text file, my configs have followed me across many machines and OS installs by just copying some files.
With more "magical" desktops like Gnome, developers like to change things every 6 months, and then I've got to mess around with the settings to try and not have it disrupt my workflow. And as soon as bring a new machine up I'm spending half a day mousing through menus and trying to remember all the things I set last time.
I like FreeBSD with a minimal desktop precisely because I've got more important things to be doing than messing around with settings. Yeah, the work is front-loaded, but the payoff is that I spend years not even thinking about the desktop or the OS.
I hear this so often; it seems as though there should be a way to do this automatically.
If I recall correctly although gnome uses a binary config file format not terribly unlike the windows registry there is a way to export and then import it.
Even so I don't think this is 100% proof against things changing then again the same CAN be true of text configuration files.
Even so I don't think this is 100% proof against things changing then again the same CAN be true of text configuration files.
If you don't want to touch any config files, you can get PC-BSD.
Setting up FreeBSD is easier than, say, Arch Linux. The OS install is a menu based "next, next, next" process like in Debian. Installing a desktop environment… honestly I can't imagine how it CAN be difficult. `pacman -S xfce`, `pkg install xfce`, same thing everywhere.
Setting up FreeBSD is easier than, say, Arch Linux. The OS install is a menu based "next, next, next" process like in Debian. Installing a desktop environment… honestly I can't imagine how it CAN be difficult. `pacman -S xfce`, `pkg install xfce`, same thing everywhere.
PCBSD is great, unfortunately it lacks better support for functional keyboards and screen brightness controls on laptops, but it's great anyway. I prefer it over ArchLinux.
You have missed my point.
Comparing with Arch and saying it is easier - well, gee, sure - not a particularly high bar to clear! The same about installing the desktop using a package manager.
If you have to actually do any of that, you have lost already, at least as far as a productive desktop is concerned. My point is not that it is hard to do but that you shouldn't have to do it in the first place!
Desktop OS should come with a working desktop out of the box - many desktop Linux distros actually give you a choice during the install and preconfigure one of the major ones for you.
BSDs make excellent servers and there this simplicity and Unix-like approach to running things are a large benefit. Modern Linux distros tend to be way too complex and "black-box" like in this regard. However, having to go through all this to run a desktop is an unnecessary masochism for people who have way too much time on their hands, IMO.
Comparing with Arch and saying it is easier - well, gee, sure - not a particularly high bar to clear! The same about installing the desktop using a package manager.
If you have to actually do any of that, you have lost already, at least as far as a productive desktop is concerned. My point is not that it is hard to do but that you shouldn't have to do it in the first place!
Desktop OS should come with a working desktop out of the box - many desktop Linux distros actually give you a choice during the install and preconfigure one of the major ones for you.
BSDs make excellent servers and there this simplicity and Unix-like approach to running things are a large benefit. Modern Linux distros tend to be way too complex and "black-box" like in this regard. However, having to go through all this to run a desktop is an unnecessary masochism for people who have way too much time on their hands, IMO.
Well, everyone has different "productivity" needs. I'm productive when everything is customized for, uh, productivity. When my config files aren't overwritten by package managers and the settings aren't replaced at runtime by some-settings-daemon that I never wanted.
You must be that mythical Hacker News commenter who's proud of using default settings everywhere and not customizing anything :D
Anyway, setting up any BSD, or Arch, or even Gentoo doesn't really take "way too much time", come on.
You must be that mythical Hacker News commenter who's proud of using default settings everywhere and not customizing anything :D
Anyway, setting up any BSD, or Arch, or even Gentoo doesn't really take "way too much time", come on.
Agreed. And FreeBSD's installer has been "next, next, next" as you say, since the 90s.
Our receptionist installed it herself on both her work and home computers in 1997. Next, next, next, done.
Our receptionist installed it herself on both her work and home computers in 1997. Next, next, next, done.
Arch used to have an installer like that, but they dumped it in favor of the current boot-into-heavily-customized-live-environment-that's-nothing-like-the-default-installation-and-install-pseudo-manually-by-running-these-shell-scripts-in-the-proper-order-and-hopefully-you-memorized-the-handbook “installer”. I can't prove it, but I suspect they did that sheerly out of elitism, to keep the newbs out.
> Desktop OS should come with a working desktop out of the box ...
You are responding to a comment that explicitly mentioned PC-BSD by name. I strongly suggest looking up what PC-BSD is.
You are responding to a comment that explicitly mentioned PC-BSD by name. I strongly suggest looking up what PC-BSD is.
That's why, after having used Redhat, SuSE, FreeBSD, Gentoo and Ubuntu over the course of 10 years, I switched to Mac/OSX. Everything just works.
If you want preconfigured FreeBSD try PCBSD/TrueOS.
I don't fully agree with this.
I remember installing red hat from a bunch of floppies around 1997. Tinkering, etc. But it certainly didn't let me understand what was going on with the machine. I got a much better grasp of linux many years later when internet came around and well... started doing useful things with the machine instead of configure a VGA Xorg whatever file to display the desktop (and then what? play mp3 ?).
I remember installing red hat from a bunch of floppies around 1997. Tinkering, etc. But it certainly didn't let me understand what was going on with the machine. I got a much better grasp of linux many years later when internet came around and well... started doing useful things with the machine instead of configure a VGA Xorg whatever file to display the desktop (and then what? play mp3 ?).
Don't be ridiculous, Linux [1] is not better at this. Maybe out of the box experience is a bit nicer, but it's not generally just usable after that. Want a properly working network? Guess what - network manager is the problem, you have to disable it and configure network interfaces manually with config files and everything. Or want vim as a default editor - good luck with config files, "update-alternatives" shell magic is the only way to change it. Want to disable avahi, mlocate and other annoying stuff? Dig deep into configs and .overrides and magic chmods (hud-service). Locales are of course incorrect by default too. And it's not even close to everything, far from it. That's why I have like a 500 line shell script to automate configuration after installation.
The only way to make it better is to recognize the problem and make a new distribution with a decent well thought out package and configuration manager.
[1] I'm talking about desktop Ubuntu of course.
The only way to make it better is to recognize the problem and make a new distribution with a decent well thought out package and configuration manager.
[1] I'm talking about desktop Ubuntu of course.
I think you listed many things that require links to bugs or some specific descriptions. Otherwise the post just looks like FUD. Network manager works for usual configs. Update alternatives existed for years, but most apps respect setting $EDITOR. Most services can be simply disabled without overrides. Etc.
Sure, there may be issues. But both the list and mentioned solutions seem extraordinary.
Sure, there may be issues. But both the list and mentioned solutions seem extraordinary.
That's what Linux on desktop is always about. First contact, and it all looks fine. But then, you want a certain application installed and use it or whatever and things start getting haywire (from user experience perspective). Within half an hour of fresh install you're on some obscure old and closed topics on forums or IRC begging for help, etc. Once it works it's great, but that's how it is.
I use MacOS on my laptop, Windows 8.1 on main workstation and Fedora 24 / XFCE on another workstation daily. Each and every OS has some things I wish the other OS would have and i can't decide which one is 'the best'. There's no such thing.
I'd say the closest thing to an ideal situation (for me) would be a Fedora OS with MacOS-like opaqueness to configurations and upgrade, Adobe, Games, and Office applications from Windows (they work better on Windows) and preview (spacebar and app) from MacOS in it. At that point I wouldn't even care if, at its core, it would be Linux or BSD or NT.
I use MacOS on my laptop, Windows 8.1 on main workstation and Fedora 24 / XFCE on another workstation daily. Each and every OS has some things I wish the other OS would have and i can't decide which one is 'the best'. There's no such thing.
I'd say the closest thing to an ideal situation (for me) would be a Fedora OS with MacOS-like opaqueness to configurations and upgrade, Adobe, Games, and Office applications from Windows (they work better on Windows) and preview (spacebar and app) from MacOS in it. At that point I wouldn't even care if, at its core, it would be Linux or BSD or NT.
Chrome OS will get close to this once it gets Android app support.
Microsoft supports Office apps for Android as a first-class port.
Chrome OS is "opaque"...there are very few knobs to turn.
Games will be covered as long as you mean mobile games.
Microsoft supports Office apps for Android as a first-class port.
Chrome OS is "opaque"...there are very few knobs to turn.
Games will be covered as long as you mean mobile games.
I am also using F22/XFCE setup from past 2 years - Stable !
I agree with Virapter if we're talking Ubuntu or Mint. The experience hasn't been nearly as bad as you describe despite me using several versions, several distro's of each (eg Lubuntu etc), and on 2 different machines. There was often at least one or two problems like you described that would be a no-go for layperson trying Linux. I Googled them, saw relevant steps, and problem went away. Shit works now. Sometimes not even one of those, esp on Mint.
My main gripe is whats broken varies distro to distro. It's rarely the same. So, I have to have guidelines or scripts on a per-distro basis to deal with their issues. You'd think in 2016 that there'd be reference sheets on properly integrating various components so this doesn't happen. And people would've used them. One or other apparently isn't true.
My main gripe is whats broken varies distro to distro. It's rarely the same. So, I have to have guidelines or scripts on a per-distro basis to deal with their issues. You'd think in 2016 that there'd be reference sheets on properly integrating various components so this doesn't happen. And people would've used them. One or other apparently isn't true.
I had to deal even with the manual xorg in the past, because wacom tablet didn't work properly and was pretty much useless in the "default" mode, with wrong button bindings and wrong things enabled, that interfered with each other. But xorg is too hard and too fragile, so I eventually found a way to at least make it not interfere and gave up. Accepted the "default" mode, putting only couple of "xinput set-prop ..." lines into .xsessionrc.
It's always been a constant battle with ubuntu for me. I lost that battle, automated configuration to satisfy ubuntu and don't bother anymore, mostly by avoiding ubuntu ways as much as possible.
It's always been a constant battle with ubuntu for me. I lost that battle, automated configuration to satisfy ubuntu and don't bother anymore, mostly by avoiding ubuntu ways as much as possible.
I've had a Dell Latitude notebook with Ubuntu 14.04 preinstalled and guess what? The wireless network card worked fine by default. I've also had no networking issues while running Fedora 24 on it.
You really should try a decent desktop Linux. For example, Arch. It just works out of the wiki. All those problems are because Ubuntu tries very hard to be smarter than user. Obviously it fails. You don't need to disable fancy configuration and autodetection tools if they are not present in the first place.
[deleted]
>>[1] I'm talking about desktop Ubuntu of course.
Sadly, following the (un)guidelines set by the redhat/gnome dictatorship (aka, systemd) and their grand quest to please the desktop users, Debian also seems to have become, more or less, the freaking Ubuntu.
I will be happy if I am wrong.
Sadly, following the (un)guidelines set by the redhat/gnome dictatorship (aka, systemd) and their grand quest to please the desktop users, Debian also seems to have become, more or less, the freaking Ubuntu.
I will be happy if I am wrong.
I'm a big user of FreeBSD on the server (in production) and came across a link to this a while back in a forum post and decided to run through it just to see how accurate it is (there are a LOT of out-of-date FreeBSD "how-to" articles out there. "n00bs" are often referred at this one and, if you follow it, you will generally end up with a working system.
There are a few things that could be improved, however.
I would recommend not blindly copying the sysctl values provided. Many of them were already set higher by default on my test system. By copy/pasting the suggested values, I was actually lowering the values (maxfiles, shared memory settings, etc.).
Another big one was device permissions. For a single-user machine, they're probably okay. If another person will ever have access to your machine, however, you're probably granting them way too many permissions.
In short, if you're just wanting to bring up a FreeBSD desktop to play around with, this will probably get you there. You might also consider PC-BSD [0], which takes of all the hard work for you.
Once you're up and running, head over to the FreeBSD Forums if you encounter any issues.
Welcome to FreeBSD!
[0]: http://pcbsd.org
[1]: https://forums.freebsd.org/
There are a few things that could be improved, however.
I would recommend not blindly copying the sysctl values provided. Many of them were already set higher by default on my test system. By copy/pasting the suggested values, I was actually lowering the values (maxfiles, shared memory settings, etc.).
Another big one was device permissions. For a single-user machine, they're probably okay. If another person will ever have access to your machine, however, you're probably granting them way too many permissions.
In short, if you're just wanting to bring up a FreeBSD desktop to play around with, this will probably get you there. You might also consider PC-BSD [0], which takes of all the hard work for you.
Once you're up and running, head over to the FreeBSD Forums if you encounter any issues.
Welcome to FreeBSD!
[0]: http://pcbsd.org
[1]: https://forums.freebsd.org/
Are there similar guides for those of us wanting to try a dual-boot setup between PC-/FreeBSD and Windows? I remember not finding any straightforward guides more than a year ago when I decided to move away from Windows. I'm on a Linux distro now, but if I can find a suitable guide, I will try it (probably on a VM first).
I don't know. But it shouldn't be too hard. Just install FBSD after windows, and find some instructions for booting windows from boot0/booteasy, the freebsd bootloader, or take the easy way out and get grub2 from the package repository, and follow the instructions for setting that up, followed by the instructions for dual booting windows and linux, with any obvious modifications.
PC-BSD is now called "TrueOS Desktop," FWIW.
FreeBSD is amazing, but it suffers from one big problem: the number of people using it is so small that many things that are easy to accomplish on Linux and other operating systems prove incredibly inconvenient or impossible on FreeBSD because no one has bothered to do them before.
This is best explained with an example. Say you want to install TensorFlow with CUDA 7.5 and cuDNN v4 support, which is necessary for training large neural nets.
Here's how you do it on, say, Ubuntu:
This is best explained with an example. Say you want to install TensorFlow with CUDA 7.5 and cuDNN v4 support, which is necessary for training large neural nets.
Here's how you do it on, say, Ubuntu:
sudo pip3 install --upgrade [Official TensorFlow URL]
https://ecc-comp.blogspot.com/2016/06/tensorflow-on-freebsd.html
Isn't the problem that that CUDA for FreeBSD does not exist in the first place?
Nvidia can't be bothered to port it.
[deleted]
What about using CUDA with bhyve with "PCI-E passthrough"? It should work near native speed. This was suggested here: https://news.ycombinator.com/item?id=10767172
Compared to Linux distributions for me the most interesting difference of FreeBSD isn't the license or somewhat exclusive features like dtrace/ZFS. It is the release model which separates the "stable/LTS" base and the rolling 3rd party software.
In (for example) Debian stable I have a very reliable system but any annoying bugs in end user software will remain for the next several years. But going to a rolling release distro could result in unexpected troubleshooting sessions while I actually had to be productive instead.
So there are drawbacks of going to a full rolling or a full stable distro and imho the FreeBSD model is the best balance between both extremes. Why isn't there a Linux distro like this?
In (for example) Debian stable I have a very reliable system but any annoying bugs in end user software will remain for the next several years. But going to a rolling release distro could result in unexpected troubleshooting sessions while I actually had to be productive instead.
So there are drawbacks of going to a full rolling or a full stable distro and imho the FreeBSD model is the best balance between both extremes. Why isn't there a Linux distro like this?
openSUSE is IMO relatively close to that, due to their superior packaging system (it's best one I know).
So if you use normal release (not tumbleweed) you are fixed to the package versions when suse was released, but you can go to OBS[1] where you can obtain latest version of software. Their 3sat dependency solver makes sure that dependencies are resolved correctly. Another interesting thing is that they group package upgrades into patches, with description and other details. You can for example issue zypper patch --have <cve> and instead everything that resolved specific vulnerability. I also love zypper ps showing which processes need to be restarted after the upgrade.
[1] http://software.opensuse.org which is like github for packages (it supports other distros as well) most packages are there in latest versions.
So if you use normal release (not tumbleweed) you are fixed to the package versions when suse was released, but you can go to OBS[1] where you can obtain latest version of software. Their 3sat dependency solver makes sure that dependencies are resolved correctly. Another interesting thing is that they group package upgrades into patches, with description and other details. You can for example issue zypper patch --have <cve> and instead everything that resolved specific vulnerability. I also love zypper ps showing which processes need to be restarted after the upgrade.
[1] http://software.opensuse.org which is like github for packages (it supports other distros as well) most packages are there in latest versions.
The wonderful thing about OBS is you can branch a package, make modifications to your personal version, and add that new repo as a source for zypper to pull from, incredibly easily. PPA's and Launchpad are orders of magnitude more complicated to do the same task.
>> Why isn't there a Linux distro like this?
Debian stable is that distro in my case.
I agree that you shouldn't have to put up with an annoying bug or missing functionality until the next stable release; that's what the backports[1] system is meant to address. And when you cannot find what you're looking for in the backports repository, making your own is relatively simple[2].
The way I see it, the FreeBSD ethos is perfectly applicable in Linux land. It just requires a little bit of extra discipline on our part.
[1] https://backports.debian.org
[2] https://wiki.debian.org/SimpleBackportCreation
Debian stable is that distro in my case.
I agree that you shouldn't have to put up with an annoying bug or missing functionality until the next stable release; that's what the backports[1] system is meant to address. And when you cannot find what you're looking for in the backports repository, making your own is relatively simple[2].
The way I see it, the FreeBSD ethos is perfectly applicable in Linux land. It just requires a little bit of extra discipline on our part.
[1] https://backports.debian.org
[2] https://wiki.debian.org/SimpleBackportCreation
Other package collections are available for Linux e.g. pkgsrc, Nix, the Linux port of Homebrew, ...
The BSD model is somewhat challenging for porters (maintainers of the 3rd party software). Making sure the software compiles on three different FreeBSD releases (old-stable, stable, development branch) is much more work than the usual Linux 1:1 model.
But on Linux you also have to check against RHEL/CentOS 6, 7, and some fresh distro. It's also quite a lot of effort.
The package repositories for CentOS 6 and 7 (and Fedora 23, 24, rawhide) are all distinct; each release is a git branch in a given package's repository. Whereas on FreeBSD, the head ports tree is shared between FreeBSD 9, 10, 11, and CURRENT. It's a distinction that makes a difference.
Arch based distributions are rolling systems. It's all a manner of the package manager not the OS
Author here. There will be an update to this page soon that talks about FreeBSD 11, dual booting, laptops (Mac EFI weirdness, lagg for lan/wlan failover), updates to some out of date sections like the fonts and manually configuring X. To its credit the reason it's out of date is that I haven't had to think about my computer at all since 10.0 aside from updating my packages and freebsd-update-ing to new point releases twice a year.
I for one am grateful to NVidia for providing a FreeBSD driver to this day. Their dedication to providing support for UNIX systems is admirable.
I was curious to know what FreeBSD versions NVidia supports, and I cannot believe it's 7.3 to 10-CURRENT. This makes me believe they will quickly follow up with 11-CURRENT. This is very cool in terms of FreeBSD's kernel API.
http://us.download.nvidia.com/XFree86/FreeBSD-x86/367.44/REA...
We know that the likes of Pixar or LANL use NVidia on Linux, for them to take Linux seriously, but is there information who the important FreeBSD and Solaris customers are? Is it The Weather Channel's FreeBSD IntelliStar system that motivates NVidia to support it? And what about Solaris?
I mean, I want to believe NVidia supports FreeBSD and Solaris because they already support X11, but these are three different kernel drivers. With a business like NVidia, which isn't supporting open source graphics stacks like AMD or Intel are, I have to ask myself what the commercial motivators are.
http://us.download.nvidia.com/XFree86/FreeBSD-x86/367.44/REA...
We know that the likes of Pixar or LANL use NVidia on Linux, for them to take Linux seriously, but is there information who the important FreeBSD and Solaris customers are? Is it The Weather Channel's FreeBSD IntelliStar system that motivates NVidia to support it? And what about Solaris?
I mean, I want to believe NVidia supports FreeBSD and Solaris because they already support X11, but these are three different kernel drivers. With a business like NVidia, which isn't supporting open source graphics stacks like AMD or Intel are, I have to ask myself what the commercial motivators are.
As an ex-Unix kernel developer, I always thought FreeBSD and OpenBSD were just more comfortable environments for me than Linux. However, the desktop experience, and especially getting X to work well with my hardware (multiple monitors and graphics cards for example) eventually won me over and I simply try to find a Linux distro that supports my hardware best.
I agree with qwertyulop924 who points out its nice being able to understand the system's configuration. Now though, I'm with johnchristopher, manually configuring Xorg is where I reach my limit and just want it to be magically done for me.
I agree with qwertyulop924 who points out its nice being able to understand the system's configuration. Now though, I'm with johnchristopher, manually configuring Xorg is where I reach my limit and just want it to be magically done for me.
I haven't needed to configure X on OpenBSD at least five years now. The X server does that automatically, just like on Linux. For the record, I haven't needed to on FreeBSD either, but I've run that much more sporadically, so take that with a grain of salt.
My impression was that Xorg has obviated the need for manual configuration in all but the most extreme cases. Multiple monitors are easy with xrandr, but I'm not sure how multiple graphics cards will work.
My impression was that Xorg has obviated the need for manual configuration in all but the most extreme cases. Multiple monitors are easy with xrandr, but I'm not sure how multiple graphics cards will work.
Yes, I've heard that things are much better now. I switched my desktops, not servers, to Linux years ago.
My two cents: this is all nice and fun if your purpose when using a computer is learning about computers, but you don't do any actual work.
When you stop "messing" and need to do actual work, you are going to really appreciate a system with sane defaults (graphic environment working out of the box, drivers pre-installed, plug&play and audio stuff that just work) that can work predictably.
Of course, no system is immune to stupidity: yes, even on Ubuntu you must be aware of what are you doing and what consequences it will have.
For me, avoiding third-parties repository and going from LTS to LTS solves 95% of the problems, and in exchange I have a stable desktop machine that works all the day, everyday.
I have been messing around with Slackware, FreeBSD, Gentoo and NetBSD in the past and I am now a happy Xubuntu (and ubuntu-server) user.
When you stop "messing" and need to do actual work, you are going to really appreciate a system with sane defaults (graphic environment working out of the box, drivers pre-installed, plug&play and audio stuff that just work) that can work predictably.
Of course, no system is immune to stupidity: yes, even on Ubuntu you must be aware of what are you doing and what consequences it will have.
For me, avoiding third-parties repository and going from LTS to LTS solves 95% of the problems, and in exchange I have a stable desktop machine that works all the day, everyday.
I have been messing around with Slackware, FreeBSD, Gentoo and NetBSD in the past and I am now a happy Xubuntu (and ubuntu-server) user.
I never got far with FreeBSD on the desktop because every time I thought I would give it a try I ended up just thinking Linux is easier to use and my Mac is already basically the same thing but pre-configured, so it's a pretty expensive hobby unless you have a lot time or just really like playing with the details of your operating system. I agree there are philosophical reasons you might prefer FreeBSD to other operating systems. Anyway, my favorite part of that blog post is this:
# Handle Unicode on removable media libiconv_load="YES" libmchain_load="YES" cd9660_iconv_load="YES" msdosfs_iconv_load="YES"
# Handle Unicode on removable media libiconv_load="YES" libmchain_load="YES" cd9660_iconv_load="YES" msdosfs_iconv_load="YES"
"Linux is easier to use" heh. Well I mean Ubuntu is easy to use, sure. Until you want to change things, then it gets in your way.
Every time I try Linux, nothing makes sense to me. Why is there a weird, unfriendly `ip` command instead of `ifconfig`. Why is systemd doing the "* Waiting for some bullshit … [∞ seconds]" thing on shutdown instead of killing everything. Why does the bootloader (which is now part of the systemd project, of course) use EFI variables instead of just putting itself at /EFI/BOOT/BOOTX64.EFI. Why is there so much crap exposed as mounted filesystems. Why is there no separation between the base system and user packages (/usr/local).
Modern GNU/systemd/Linux just doesn't feel right.
Every time I try Linux, nothing makes sense to me. Why is there a weird, unfriendly `ip` command instead of `ifconfig`. Why is systemd doing the "* Waiting for some bullshit … [∞ seconds]" thing on shutdown instead of killing everything. Why does the bootloader (which is now part of the systemd project, of course) use EFI variables instead of just putting itself at /EFI/BOOT/BOOTX64.EFI. Why is there so much crap exposed as mounted filesystems. Why is there no separation between the base system and user packages (/usr/local).
Modern GNU/systemd/Linux just doesn't feel right.
> unfriendly `ip` command instead of `ifconfig`
Ifconfig had been deprecated for what... over 5 years now? It's a bit different, but if you need it often, you'll either learn in a few days or can just use an ifconfig-compatible wrapper. There are projects that do that already.
The kernel moved to rtnetlink and ifconfig simply doesn't work the same way. Interface labels vs multiple IPs is just one very visible difference.
Ifconfig had been deprecated for what... over 5 years now? It's a bit different, but if you need it often, you'll either learn in a few days or can just use an ifconfig-compatible wrapper. There are projects that do that already.
The kernel moved to rtnetlink and ifconfig simply doesn't work the same way. Interface labels vs multiple IPs is just one very visible difference.
Well, that's why I run OpenRC. And GRUB.
ip over ifconfig doesn't bother me that much: they were both confusing and ill-documented in their Linux incarnations, IMHO. The mounted crap I think is kinda nice for system introspection, although BSD and Solaris users have been known to disagree.
As for everything in /usr/bin (and my stuff in ~/bin and /usr/local/bin), I think this was a good idea for Linux (but not the BSDs) to do: On Linux, there is no real separation between /usr/bin and /bin in any case (/usr/local/bin is another matter, but it's separate on my system. I think /sbin should have been kept separate as well, but I'm untangling that particular knot: I could do it, but it'd be a mess).
So yeah, systemd is the devil, but the rest I kinda like.
ip over ifconfig doesn't bother me that much: they were both confusing and ill-documented in their Linux incarnations, IMHO. The mounted crap I think is kinda nice for system introspection, although BSD and Solaris users have been known to disagree.
As for everything in /usr/bin (and my stuff in ~/bin and /usr/local/bin), I think this was a good idea for Linux (but not the BSDs) to do: On Linux, there is no real separation between /usr/bin and /bin in any case (/usr/local/bin is another matter, but it's separate on my system. I think /sbin should have been kept separate as well, but I'm untangling that particular knot: I could do it, but it'd be a mess).
So yeah, systemd is the devil, but the rest I kinda like.
> Why does the bootloader use EFI variables
Because that's the right way to do it (for non-removable discs), and the way that you mention is the wrong way to do it.
* https://jdebp.eu./FGA/efi-boot-process.html
Because that's the right way to do it (for non-removable discs), and the way that you mention is the wrong way to do it.
* https://jdebp.eu./FGA/efi-boot-process.html
> Why is systemd doing the "* Waiting for some bullshit … [∞ seconds]" thing on shutdown instead of killing everything.
Systemd is now just killing everything if you log out or try to shut down the system, which caused a lot of people to run amok over that, too.
Systemd is now just killing everything if you log out or try to shut down the system, which caused a lot of people to run amok over that, too.
Because it was an awful, awful, idea, and is almost never what you want.
The whole thing with /efi/boot/bootx64.efi and EFI variables just tripped me up yesterday too. I still have no idea if I need to copy my kernel over to bootx64.efi for it to boot.
Killing everything on shutdown doesn't seem like a good idea. Programs should be able to shut down cleanly.
Your data isn't safe unless every program can handle being randomly killed. The power can always go out.
Now, once all your programs can be immediately killed, why would you ever not want to do that?
Now, once all your programs can be immediately killed, why would you ever not want to do that?
Isn't it better to neatly close up remote connections instead of leaving them hanging to time out? I'm thinking of web servers and database clients.
The kernel should close all your TCP connections properly when you die, so it should all be good. Mostly you need to autosave files every so often.
Basically, because a lot of data isn't safe and only manages to seem safe on average because the power is very reliable and data loss becomes an occasional race condition. :-)
They're sent SIGTERM via kill(1), then a short sleep, then any stragglers get SIGKILL. The idea is to clean up any non-responsive processes, or programs that intentionally ignore SIGTERM.
Note that kill(1) just sends an arbitrary signal to whatever process(es), it doesn't have to be SIGKILL.
Note that kill(1) just sends an arbitrary signal to whatever process(es), it doesn't have to be SIGKILL.
Yeah I know how the old init systems work. I also know that the newer ones all try to keep track of which services they're starting so they can shut them down in the right order and wait until they're finished.
> Why does the bootloader (which is now part of the systemd project, of course)…
Please say you're joking. This is frightening.
Please say you're joking. This is frightening.
https://news.ycombinator.com/item?id=8984400
You're late. (-:
You're late. (-:
> GNOME 3, available on Linux since 3.0 in the spring of 2011, is finally available in the official FreeBSD tree as of November 2014. The three and a half year delay is thanks to the upstream GNOME project’s years-long fight against any operating system that doesn’t have a penguin for a mascot. It took several years and a vastly waning userbase, then suddenly they care about portability again. Sure, okay. Either way, it’s here and you can install it from x11/gnome3.
Well thats interesting...
Well thats interesting...
GNOME3 is also in a fight against any linux system that doesn't use systemd.
Gnome3 is in a fight againt anybody who doesn't just want to look at the pretty colors. It really doesn't do anything right.
And even if you don't use GNOME3, Gtk3 is now required by Firefox, including Firefox gtk3 bugs, which will be fixed in Firefox. Most importantly the many regressions of Gtk3 itself. Gtk3 was a good refactoring to support Wayland and HiDPI, but it's not stable or fast yet for everyone, like Gtk2 has been. I accept the fact when gtk devs argue that gtk2 has many architectural bugs, but day to day as a user I don't notice them, and I very much prefer the old file dialog, for instance.
Gtk3 may be faster in theory due to GPU acceleration as a possibility, but when Gtk 3.20 for a split second shows a black rectangle for each new dialog while it's opening, I have a hard time taking their gpu acceleration argument seriously.
I tried building Firefox 48 with gtk2, but it crashed in the file dialog, while the gtk3 build is slower and introduces gui regressions (yes, I've reported the gtk3 bugs). Right now I cannot move past Firefox ESR with gtk2, and I hope I can still use Firefox next year.
What I'm saying is that GNOME3's stack (especially Gtk3) doesn't seem to work outside GNOME3 as compatibly as Gtk2 does, and it may be what's intended, if past communication from the GNOME dev team is any indication.
Gtk3 may be faster in theory due to GPU acceleration as a possibility, but when Gtk 3.20 for a split second shows a black rectangle for each new dialog while it's opening, I have a hard time taking their gpu acceleration argument seriously.
I tried building Firefox 48 with gtk2, but it crashed in the file dialog, while the gtk3 build is slower and introduces gui regressions (yes, I've reported the gtk3 bugs). Right now I cannot move past Firefox ESR with gtk2, and I hope I can still use Firefox next year.
What I'm saying is that GNOME3's stack (especially Gtk3) doesn't seem to work outside GNOME3 as compatibly as Gtk2 does, and it may be what's intended, if past communication from the GNOME dev team is any indication.
It made me so sad when Firefox switched over to GTK3, and now I'm stuck with their foolish attempt at improving the file browser. For whatever reason by default it tries (and fails) to open a network connection, and they broke the ability to navigate through the filesystem using just the keyboard.
> foolish attempt at improving the file browser.
https://bugzilla.mozilla.org/show_bug.cgi?id=1267863
https://bugzilla.mozilla.org/show_bug.cgi?id=635044
I predict that someone will get fed up enough to revive the Firefox Qt port, since Qt doesn't break as much between releases, and it doesn't conflict with Mozilla's plans to drop GTK2 support. The memory overhead of Qt is absorbed within a modern browser's memory needs.
https://bugzilla.mozilla.org/show_bug.cgi?id=1267863
https://bugzilla.mozilla.org/show_bug.cgi?id=635044
I predict that someone will get fed up enough to revive the Firefox Qt port, since Qt doesn't break as much between releases, and it doesn't conflict with Mozilla's plans to drop GTK2 support. The memory overhead of Qt is absorbed within a modern browser's memory needs.
An up-to-date QT FireFox port would make me so happy :)
The GNOME dev team is where people go when they can't put in work in systemd. The days when it was good are long gone.
GTK3 drags in way too much of gnome for comfort, but I don't want to drop all GTK3 apps, so I have to put up with it.
GTK3 drags in way too much of gnome for comfort, but I don't want to drop all GTK3 apps, so I have to put up with it.
Actually, if you build GTK3 yourself, it doesn't need anything more than a current default GTK2 distro package does, but you'll lose features like colord support. My experience is with Gentoo USE flags, but I believe FreeBSD ports has options for packages that do the same and are the original inspiration for USE flags, so one should be able to use a lean GTK3 and GTK2 on FreeBSD.
When GTK3 and even Qt5 go user-unfriendly and dev-unfriendly ways, it's no wonder there's many immediate mode ui library projects that are popular or actively developed Haskell FLTK bindings.
When GTK3 and even Qt5 go user-unfriendly and dev-unfriendly ways, it's no wonder there's many immediate mode ui library projects that are popular or actively developed Haskell FLTK bindings.
GTK3 does not drag any gnome stuff??!? It wouldn't even be possible, that would be a circular dependency.
https://www.freshports.org/x11-toolkits/gtk30 It's "lean" by default, you can't even make it "not lean".
They're big, but I wouldn't call them "user-unfriendly and dev-unfriendly". QML/QtQuick is the best GUI development thing ever.
P.S. I was building Firefox from ports for a while, just to get GTK3 support earlier than they turned it on by default :-P
https://www.freshports.org/x11-toolkits/gtk30 It's "lean" by default, you can't even make it "not lean".
They're big, but I wouldn't call them "user-unfriendly and dev-unfriendly". QML/QtQuick is the best GUI development thing ever.
P.S. I was building Firefox from ports for a while, just to get GTK3 support earlier than they turned it on by default :-P
My point is that a lean build of GTK3 doesn't require more than GTK2 right now does. In the port linked to, libepoxy and libcolord can be avoided. And when you do that, it's down to what GTK2 depends on in its default build config on most Linux distros. If you could disable ATK, you could shave off some more, but GTK3 doesn't build without ATK.
And my point is that libepoxy and libcolord aren't "dragging in way too much of gnome" :)
Qt5's base memory overhead is big (minimum 25MB for the simples hello world window you can create). The modularization of Qt5 is a good idea, but it also makes use on Linux distros a pain, because it's too many modules, like the mess some Linux distros create when they split core Perl into a gazillion packages.
Just use Tk. Or wx. They're both well supported, cross platform, and if you use ttk, you can even have your app look good. And native.
For WM, I use i3. If you don't mind tiled, I'd highly reccomend it. It's great, the docs are great, and the config file is easy to understand, so after the base setup, you don't have to worry about it.
XFCE, TWM and sawfish are pretty cool, if you're not into tiled.
For WM, I use i3. If you don't mind tiled, I'd highly reccomend it. It's great, the docs are great, and the config file is easy to understand, so after the base setup, you don't have to worry about it.
XFCE, TWM and sawfish are pretty cool, if you're not into tiled.
> Just use Tk. Or wx.
Yes, Tk just works for gui and is underappreciated.
wx's default backend is gtk (2 or 3) and they have an experimental Qt5 backend now, which is unsurprising given GTK3's state. So wx doesn't help, unless you can make the Qt backend work (Qt5 is so modular that it's often a pain).
Yes, Tk just works for gui and is underappreciated.
wx's default backend is gtk (2 or 3) and they have an experimental Qt5 backend now, which is unsurprising given GTK3's state. So wx doesn't help, unless you can make the Qt backend work (Qt5 is so modular that it's often a pain).
Tk is pretty and lean but I never felt comfortable using it in C code. A native C toolkit would be nice.
iup? It's uglier than Tk though.
Gnome 3 came default on one of the Debian disks I installed a year ago. That was when I stopped using Debian.
This is a great intro, it seems it hasn't been updated in a couple of years (last history update is 12/26/14 (or 26/12/14 :-)) but it shows pretty clearly all the steps to turn your FreeBSD install into a desktop environment hosting OS.
Now I just want a company/org that will in conjunction with a decent machine setup. Basically I want Sun Microsystems back where they have some great hardware engineers put together a desktop system, and great software engineers that can put together a well integrated and desktop environment.
Now I just want a company/org that will in conjunction with a decent machine setup. Basically I want Sun Microsystems back where they have some great hardware engineers put together a desktop system, and great software engineers that can put together a well integrated and desktop environment.
And if you want to use an external usb disk that's shared with FreeBSD, you can use https://www.freshports.org/sysutils/fusefs-lkl/ to fuse-mount with the original linux kernel filesystem code. Once lkl is updated to 4.7 or 4.8, ext4's encryption support should allow a shared, external usb drive that work with Linux and FreeBSD, but I don't know if lkl will also support the keyring on FreeBSD.
I don't love magic - arch is on my desk, but I do love videogames, so as much as I thing the BSDs are Really Cool, they're not going on my desktop until they can run steam reliably through the emulation layer (and maybe not even then: I remember the days of WINE).
Now a laptop or ARM chip, on the other hand...
Now a laptop or ARM chip, on the other hand...
Yeah, but how well can I trust that all my games will work? I don't know. I might boot it off a second disk or something, to check...
If you want to enjoy the benefits of a FreeBSD desktop without all the hassle of making it to just work, take PC-BSD for a spin.
http://pcbsd.org
http://pcbsd.org
Awesome, thanks for posting. Been a while since I wanted to try any BSD but never got my hands around it. Might just put in into VM and play around. Just like I started with Linux.
There is Gentoo/FreeBSD project[1] too, to provide portage tree on top of FreeBSD system.
[1] https://wiki.gentoo.org/wiki/Gentoo_FreeBSD
[1] https://wiki.gentoo.org/wiki/Gentoo_FreeBSD
I can't wait to see this guys face when he finds out that Jordan Hubbard wants to implement something very much like systemd in a future version of freebsd.
Not OP, but it depends. If they take the good bits (simple unit files, process monitoring), and ignore the bad bits (trying to do everyone else's job, sinister plans for world domination, no fun at parties), than I'd be cool with it.
heck, just stick process monitoring into the rc.d model. You'll get the Best of systemd. Especially if you don't take the Rest of systemd.
heck, just stick process monitoring into the rc.d model. You'll get the Best of systemd. Especially if you don't take the Rest of systemd.
Sometimes I run end user-ish stuff under /usr/ports/sysutils/py-supervisor and sometimes under the rc system.
The features of supervisord are very nice, the simple config, the password protected web interface for semi-sysadmin users to access and restart their memory leaking Java processes. Basically what you list as killer features.
On the other hand its not ready for prime time as a /bin/init replacement, I don't NEED the features they're just nice, and the only thing more annoying than having to learn all the peculiarities and bugs and workarounds and syntax of one init system, is having to learn two init systems.
I can imagine a world where freebsd base uses rc and "Everything in ports and pkg-ng uses supervisord". I'm not sure if I like it or dislike it, but it is at least imaginable.
In my infinite spare time I was writing a compiler that translates supervisord.conf files into shell RC files. Most of the time its pretty simple.
The features of supervisord are very nice, the simple config, the password protected web interface for semi-sysadmin users to access and restart their memory leaking Java processes. Basically what you list as killer features.
On the other hand its not ready for prime time as a /bin/init replacement, I don't NEED the features they're just nice, and the only thing more annoying than having to learn all the peculiarities and bugs and workarounds and syntax of one init system, is having to learn two init systems.
I can imagine a world where freebsd base uses rc and "Everything in ports and pkg-ng uses supervisord". I'm not sure if I like it or dislike it, but it is at least imaginable.
In my infinite spare time I was writing a compiler that translates supervisord.conf files into shell RC files. Most of the time its pretty simple.
Yeah, that's what I mean. I'd be pretty happy if FreeBSD picked up s6, or something else in the daemontools family, if it really wants to go in that direction.
Frankly, even SMF would be better. For all its faults, its still got a good idea of its place: It's an init system, no more, no less.
Here is a list of things I would be concerned about my init system doing: anything other than being a good init system. By coincedence, that's exactly what systemd does.
Frankly, even SMF would be better. For all its faults, its still got a good idea of its place: It's an init system, no more, no less.
Here is a list of things I would be concerned about my init system doing: anything other than being a good init system. By coincedence, that's exactly what systemd does.
No, something like launchd, but without the XML: https://github.com/mheily/jobd — and that's great.
The goal of systemd was to eliminate the differences between Linux distributions. FreeBSD doesn't have that problem, it's not a standalone kernel, it's developed as a whole base system.
Ironically, this means that systemd is the most BSD-like thing that ever happened to Linux userspace. As in, everything developed together. If only it was better quality and not overcomplicated…
The goal of systemd was to eliminate the differences between Linux distributions. FreeBSD doesn't have that problem, it's not a standalone kernel, it's developed as a whole base system.
Ironically, this means that systemd is the most BSD-like thing that ever happened to Linux userspace. As in, everything developed together. If only it was better quality and not overcomplicated…
No, actually launchd: https://github.com/NextBSD/NextBSD :-). XML isn't required; plists can be JSON or UCL or whatever.
I strongly doubt that a 'systemd like' in FreeBSD would have quite the same issues. I still wouldn't see the point of fancier startup/shutdown dependencies or process supervision because I run FreeBSD on hardware that doesn't change while running with daemons that don't crash; but I imagine it wouldn't include: a DNS resolver, but broken; an ntp client, but broken; a login daemon, but broken; etc. I also would expect the rc.d scripts to be kept, because the service scripts are simple (rc.subr is a bit complex).
The "service scripts are simple" belief is not borne out by the reality, as I reported in https://news.ycombinator.com/item?id=10357589
As you can see, one doesn't actually need to keep all of the rc.d scripts. I manage well without any of them, in fact, including running desktop GUIs on PC-BSD under service management.
logind is a much misunderstood part of systemd. It is somewhat difficult to state that it is "broken", given that there really isn't a spec for it to be compared against for conformance, and it is largely the only implementation in existence. It's what Ian Sutton reported as being the most difficult part of SystemBSD, as noted in https://news.ycombinator.com/item?id=10176275 and as I said beforehand in http://jdebp.eu./FGA/debian-systemd-packaging-hoo-hah.html#s...
There are a few things about it that can be stated to be wrong, though, inasmuch as they interfere with the operation of the services that service management is supposed to be managing. The limits on the number of threads that database services and suchlike can run are a largely unreported problem, for more on which see https://news.ycombinator.com/item?id=11675129
And as I pointed out in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=825394#221 the problem that did reach the news is something that one fixes properly by correcting the incorrect behaviour of logind.
Personally, for resolving proxy DNS service and content DNS service I use modified versions of Bernstein's dnscache and tinydns. The modification involves my own well-known, and years-old, patches; and making dnscache and tinydns capable of receiving their listening sockets as already-open file descriptors, via the LISTEN_FDS protocol, making it possible to integrate them with UCSPI-style tools that open the sockets for them.
As you can see, one doesn't actually need to keep all of the rc.d scripts. I manage well without any of them, in fact, including running desktop GUIs on PC-BSD under service management.
logind is a much misunderstood part of systemd. It is somewhat difficult to state that it is "broken", given that there really isn't a spec for it to be compared against for conformance, and it is largely the only implementation in existence. It's what Ian Sutton reported as being the most difficult part of SystemBSD, as noted in https://news.ycombinator.com/item?id=10176275 and as I said beforehand in http://jdebp.eu./FGA/debian-systemd-packaging-hoo-hah.html#s...
There are a few things about it that can be stated to be wrong, though, inasmuch as they interfere with the operation of the services that service management is supposed to be managing. The limits on the number of threads that database services and suchlike can run are a largely unreported problem, for more on which see https://news.ycombinator.com/item?id=11675129
And as I pointed out in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=825394#221 the problem that did reach the news is something that one fixes properly by correcting the incorrect behaviour of logind.
Personally, for resolving proxy DNS service and content DNS service I use modified versions of Bernstein's dnscache and tinydns. The modification involves my own well-known, and years-old, patches; and making dnscache and tinydns capable of receiving their listening sockets as already-open file descriptors, via the LISTEN_FDS protocol, making it possible to integrate them with UCSPI-style tools that open the sockets for them.
Given that bluetooth is complex, I'm not surprised it has a complex rc.d script. In any case, I feel these scripts are less complex than the equivalent scripts in Debian init.d; removing a lot of the argument for a 'simplification'. For example inetd on my FreeBSD box is a 20 line rc file, and openbsd-inetd is an 85 line init.d file (much of which is using start-stop-daemon for common cases). I don't have bluetooth installed on Debian to compare.
> And as I pointed out in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=825394#221 the problem that did reach the news is something that one fixes properly by correcting the incorrect behaviour of logind.
I was referring to this problem with systemd-logind, as I had forgotten about the earlier one: https://news.ycombinator.com/item?id=12333775
> And as I pointed out in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=825394#221 the problem that did reach the news is something that one fixes properly by correcting the incorrect behaviour of logind.
I was referring to this problem with systemd-logind, as I had forgotten about the earlier one: https://news.ycombinator.com/item?id=12333775
Jordan Hubbard is a very small voice in a very large chorus of people running FreeBSD. My money is on a new kind of init system coming to FreeBSD, but it not being anywhere near as controversial as systemd.
Jordan Hubbard hasn't actually committed anything in years. He does like to suggest FreeBSD adopt mach and launchd. That has seen some push back (people don't want mach IPC and people seem to think XML is required for launchd plists—it isn't).
Matt Macy already did a port of both pieces; they're ready and sitting in the NextBSD repository: https://github.com/NextBSD/NextBSD .
Matt Macy already did a port of both pieces; they're ready and sitting in the NextBSD repository: https://github.com/NextBSD/NextBSD .
I would love to trial on a Macbook Pro 15 Retina that I've got available, anyone has experience with this sort of hardware setup?
I've been running FreeBSD servers for several years now and have previously tried to use FreeBSD on the desktop as well. Recently, I bought a laptop and put FreeBSD 11.0 with a graphical desktop on it. This is my one and only laptop I use currently. The laptop is a Lenovo ThinkPad T520 with 8GB RAM and a 120GB SSD in place of the original spinning disk and four gigs of RAM. The T520 was released in 2011.
It works pretty nicely, except that the battery discharges from 100% down to where the laptop shuts down in just 1 hour (pretty much on the second), and also, suspend doesn't work of course. I also have not found out how to get the Fn-buttons to work for screen brightness and such. Also, audio over Bluetooth does not appear to be supported in FreeBSD 11.0, so I can't use my wireless headphones.
Things that do work include:
- The fingerprint reader, thanks to security/fprintd and the security/fprint_demo tool.
- Webcam using cuse4bsd compiled from upstream source and multimedia/pwcview. The cuse4bsd in the ports collection does not work with my camera. pwcview supports up to vga (640x480) resolution and 30 fps, and this works using my camera. Not sure what the real max resolution and frame rate of the webcam is supposed to be but this is good enough for me.
- Hardware accelerated 3d graphics using the proprietary binary driver by Nvidia.
- The most important GUI applications I need all work, including but not limited to; rxvt-unicode, Mozilla Firefox, Chromium, LibreOffice Writer, Blender, Inkscape and VirtualBox.
- External monitors connected to the DisplayPort.
- Built-in WiFi.
- The SD-card reader.
- Speakers, as well as the audio jack. Using audio/pavucontrol, I can play from multiple sources to different destinations at the same time.
There are some parts of the hardware that I have not yet tested, including the built-in 3G modem, because I do not currently have a subscription with a data plan. (My cell phone is not a smart phone, I use an iPod touch on WiFi instead and get almost the same experience I would with an iPhone.) I have also not yet tested audio over DisplayPort as far as I can remember.
Currently, Blender can not be found in the binary packages provided by FreeBSD, even though it is in the ports tree, but that's no biggie since I'm building all the packages myself using Poudriere anyway, because I have some options which I want set differently from what they are set to for the packages in the official repositories.
I intend to figure out how to get suspend working and how to get acceptable battery life eventually. I think most of the bits of what is needed have already been written, and it's mostly a matter of finding out where these things are and how to enable them.
In order to have an environment that I can easily modify and recreate, I forked the FreeBSD source tree and ports tree on GitHub, and I made an additional repository detailing my configuration.
Here is a screenshot I took of my laptop yesterday: https://raw.githubusercontent.com/eriknstr/ThinkPad-FreeBSD-...
It works pretty nicely, except that the battery discharges from 100% down to where the laptop shuts down in just 1 hour (pretty much on the second), and also, suspend doesn't work of course. I also have not found out how to get the Fn-buttons to work for screen brightness and such. Also, audio over Bluetooth does not appear to be supported in FreeBSD 11.0, so I can't use my wireless headphones.
Things that do work include:
- The fingerprint reader, thanks to security/fprintd and the security/fprint_demo tool.
- Webcam using cuse4bsd compiled from upstream source and multimedia/pwcview. The cuse4bsd in the ports collection does not work with my camera. pwcview supports up to vga (640x480) resolution and 30 fps, and this works using my camera. Not sure what the real max resolution and frame rate of the webcam is supposed to be but this is good enough for me.
- Hardware accelerated 3d graphics using the proprietary binary driver by Nvidia.
- The most important GUI applications I need all work, including but not limited to; rxvt-unicode, Mozilla Firefox, Chromium, LibreOffice Writer, Blender, Inkscape and VirtualBox.
- External monitors connected to the DisplayPort.
- Built-in WiFi.
- The SD-card reader.
- Speakers, as well as the audio jack. Using audio/pavucontrol, I can play from multiple sources to different destinations at the same time.
There are some parts of the hardware that I have not yet tested, including the built-in 3G modem, because I do not currently have a subscription with a data plan. (My cell phone is not a smart phone, I use an iPod touch on WiFi instead and get almost the same experience I would with an iPhone.) I have also not yet tested audio over DisplayPort as far as I can remember.
Currently, Blender can not be found in the binary packages provided by FreeBSD, even though it is in the ports tree, but that's no biggie since I'm building all the packages myself using Poudriere anyway, because I have some options which I want set differently from what they are set to for the packages in the official repositories.
I intend to figure out how to get suspend working and how to get acceptable battery life eventually. I think most of the bits of what is needed have already been written, and it's mostly a matter of finding out where these things are and how to enable them.
In order to have an environment that I can easily modify and recreate, I forked the FreeBSD source tree and ports tree on GitHub, and I made an additional repository detailing my configuration.
Here is a screenshot I took of my laptop yesterday: https://raw.githubusercontent.com/eriknstr/ThinkPad-FreeBSD-...
On a newer ThinkPad — X240 (Haswell), battery life under FreeBSD -CURRENT is close to 9 hours. Doesn't resume from suspend though. But yours should! I know people got suspend/resume working on 20 and 30 ThinkPads.
Here's my post about the laptop: https://unrelenting.technology/articles/freebsd-on-the-think... — not fully up to date though: I'm using ZFS only now, with boot environments (no GRUB required, it's fully integrated into the FreeBSD EFI loader), and powerd++ https://github.com/lonkamikaze/powerdxx
Brightness works great with Intel graphics. I haven't been able to adjust brightness using the nvidia driver (on an iMac)
Here's my post about the laptop: https://unrelenting.technology/articles/freebsd-on-the-think... — not fully up to date though: I'm using ZFS only now, with boot environments (no GRUB required, it's fully integrated into the FreeBSD EFI loader), and powerd++ https://github.com/lonkamikaze/powerdxx
Brightness works great with Intel graphics. I haven't been able to adjust brightness using the nvidia driver (on an iMac)
Thanks for your blog post. I'm going to try the power management things you did for your laptop and see how they work for my model.
I too use root on ZFS. Boot environments and using powerd++ are things I've been meaning to but have not yet got around to.
I too use root on ZFS. Boot environments and using powerd++ are things I've been meaning to but have not yet got around to.
Honestly I'm not seeing any improvement from powerd++, normal powerd worked fine for this dual-core + HT processor.
I would recommend OpenBSD for laptops. I'm not sure why, but my machine under FreeBSD had similar power issues and enabling apmd did nothing to resolve them.
I installed OpenBSD because someone said it supports think pads better and they were absolutely right, my machine is cool, quiet and the battery lasts ages. OpenBSD also requires X11 to be installed for ports to work, so maybe it is designed more for desktop use?
For reference I'm using a Lenovo Thinkpad x201s
I installed OpenBSD because someone said it supports think pads better and they were absolutely right, my machine is cool, quiet and the battery lasts ages. OpenBSD also requires X11 to be installed for ports to work, so maybe it is designed more for desktop use?
For reference I'm using a Lenovo Thinkpad x201s
But will the FreeBSD Nvidia driver work in OpenBSD?
No.
They make their driver for Solaris though :D
They make their driver for Solaris though :D
The OpenBSD developers dogfood the OS on their own laptops (mostly Thinkpads). I'd imagine that's one big reason why it works so well. In contrast, I've heard (but have not verified) that many FreeBSD devs do much of their work on macOS, and ssh to or virtualize FreeBSD.
the screen shots look amazing but I'm so involved with ubuntu at this point. should I really try FreeBSD because I really gain something ubuntu doesn't offer me?
For some people the problem is that Ubuntu offers too much. For some it offers the wrong thing (systemd craze, for a start). Actually, if you're being involved with Ubuntu in a good way, learning things, trying out new concepts, I would say stay with the course. But try *BSD by all means, some time in the future :)
> really gain something ubuntu doesn't offer me?
Native ZFS!
Native ZFS!
Thanks, It Was Helpful
Someday I might go back to FreeBSD.
The time I have spent doing things like
Notice, by the way, how easy and intuitive plain text configs done right are.
Each time I see systemd processes in some ps output I feel nothing but despair and disgust.
The time I have spent doing things like
apt-get remove unity* libqt5*
Notice, by the way, how easy and intuitive plain text configs done right are.
Each time I see systemd processes in some ps output I feel nothing but despair and disgust.
Pretty ridiculous how much work this is, when you can also go to a shop buy a pc with windows or a mac and everything works directly after booting the machine.
You say that as if microsoft hasnt gotten a perfect 3/3 for releasing at least one autoinstalling patch per month that breaks peoples stuff in the last three months.
Not saying I'd want to walk my grandma through a freebsd setup, but it's hardly without merit. There's a lot to be said for controlling your own computer.
Not saying I'd want to walk my grandma through a freebsd setup, but it's hardly without merit. There's a lot to be said for controlling your own computer.
Well yes it will work after booting, but you usually want your computer to do a bit more than boot.
No machine works perfectly after booting, as the machine is just an instrument to do some WORK. It is the nature of the work that means I have to change the instrument from time to time. FreeBSD, being an open system with a detailed manual allows me to change the machine easily and in a determined manner.
I still haven't figured out how to change many fundamental things on Windows, as it is designed to keep these options hidden from the user.
There are trade-offs for each system. For users who want the power of doing the things how they want to [within limits], FreeBSD is great. If you just want to play Counter-Strike after installing it, well, you can buy another machine for doing that.
No machine works perfectly after booting, as the machine is just an instrument to do some WORK. It is the nature of the work that means I have to change the instrument from time to time. FreeBSD, being an open system with a detailed manual allows me to change the machine easily and in a determined manner.
I still haven't figured out how to change many fundamental things on Windows, as it is designed to keep these options hidden from the user.
There are trade-offs for each system. For users who want the power of doing the things how they want to [within limits], FreeBSD is great. If you just want to play Counter-Strike after installing it, well, you can buy another machine for doing that.
If you bought a computer with an os preinstalled, of course everything works on first boot. I haven't seen a lot of computers for sale with FreeBSD preinstalled though.
The last time I bought a computer with an OS preinstalled [a couple months ago], it threw all sorts of popups at me, flashed command prompts at me, doing all sorts of nasty stuff while stealing focus from the programs I was trying to use. And it couldn't find or install any OS updates. Hours and hours of scanning, and nothing would happen. Hours and hours spent googling, trying to manually install updates that supposedly fix the problem but cannot be installed...
I wouldn't say everything worked.
I wouldn't say everything worked.
I do get that some people prefer things this way (I used too when I was a student and had plenty of time to spend on tinkering - heck I have installed Slackware from floppies in 1995) and it certainly lets you understand what is going on your machine in minute detail, but a desktop machine is a tool for the most people - they need to get work done, and don't want to have to mess with the OS to get even basic stuff like networking or desktop running.
I think I will stay with my Mageia on my machines ...