Guess BSD is not dying anymore ?
I’m not a big fan of the idea but I do respect people for putting the effort and trying. That said, I think this will end up as a dis-service.
The big benefit the BSD’s have over Linux is a coherent development of both the kernel, userland and the porting infrastructure. This project essentially throws that away. More than that it’s piggy back ridding on an establish brand (Ubuntu - are they allowed to use the name?) which by many is considered ‘just works / entry level’ distro to Linux. I am concerned that people outside of the BSD community will see this as the default and preferred way to venture into the BSD land. Obviously archBSD existed before but let’s say people considering running that would far less likely be the people getting the wrong impressions of the ecosystem (also the brand visibility of Ubuntu makes a HUGE difference).
Personally I am an OpenBSD person but I would prefer for new comers to land on PC-BSD rather than on UbuntuBSD. The former at least represents what one can expect from the other BSD’s as a coherent platform. The numbers are worrying though 2,867 downloads past week for UbuntuBSD is not a drop in the ocean.
Ubuntu - are they allowed to use the name?
They absolutely are not, unless they’re working with Canonical. Canonical are usually very protective of their trademarks.
I totally agree. I think we need less dilution in the UNIX distribution landscape, not more.
It is unfortunate that the only way to get a GNU/Linux-like system without SystemD is to replace the kernel with that of FreeBSD. But a user-friendly GNU/Linux-like system without SystemD is a great idea and I’m glad someone is doing it.
PC-BSD was an idea I liked the sound of but I never saw it get any traction and I haven’t heard anyone talking about how it approaches package management. Apt is pretty much the gold standard in that regard, so an apt-based BSD sounds like a great idea.
This is simply not true. Gentoo supports openrc. And the founder’s new derivative called Funtoo does not even support systemd at all. Debian supports various different init systems. And I’m sure that more distributions than these three offer various inits. I’m not at all a fan of systemd either, and I’m happy that these choices are enough for a simple frood like me.
This is simply not true. Gentoo supports openrc. And the founder’s new derivative called Funtoo does not even support systemd at all. Debian supports various different init systems.
Debian does not have first-class support for anything other than SystemD. More concretely packages for the likes of e.g. Gnome hard-depend on SystemD.
I don’t know enough about the Gentoo/Funtoo situation - are they fully committed to keeping everything running on non-SystemD? What do they do about Gnome, patch it?
(It’s kind of dumb if the only way to get Gnome to build without SystemD is to build it against the FreeBSD kernel, but if that’s what it takes…)
I don’t know, I’m staying away from Gnome exactly because of the hard dependencies and push for systemd. Maybe the situation regarding systemd is even worse than I thought.. I recant.
Jessie has explicit first-class support for sysvinit. It’s not the default configuration, but is 100% supported and changes that broke it were considered RC-buggy leading up to the freeze.
Granted, this is not likely to continue to be the case for Stretch.
BSD’s have their own ports infrastructure. PC-BSD is using the FreeBSD ports system with a custom made AppCafe which should provide absolutely zero issues for newcomers. Obviously it’s less likely for you to find a downloadable package online for any random piece of software. Why do you think package management on BSD’s is lacking?
Ports always felt fragile to me. The “make config / make install” model is tedious, particularly when it blocks an install with an ncurses dialogue (gentoo’s global USE flags are a much better model); rebuilding after a compatibility-breaking library upgrade is tedious (portupgrade -fr never seems to catch everything, the perl-after-upgrade script only seems to rebuild perl modules (and that unreliably) and not other things that link against perl). I didn’t like the base system/ports split, or the multiple different ways of keeping everything up to date. I could never get pkg_cutleaves to do what I expected (and it seems to require keeping a list of what you’ve deliberately installed), and so I’m never quite sure I don’t have obsolete former dependencies hanging around on my system.
Point taken. I only use OpenBSD and your experience doesn’t match what we do:
They still are making the same mistake that Ubuntu and many many others before have made: desktop environments and kernels are fine, it’s the apps that suck (if they exist at all for a given category). Any new Canonical wannabe aspiring to create a free OS for human beings should invest inordinate amount of effort into building a coherent stack of APIs for desktop programming and hire a lot of UX people to force end-user apps into being useful.
Projects like UbuntuBSD and Debian/kFreeBSD undo the efforts of the FreeBSD Foundation to remove GPL code from base. I’d much rather efforts be spent fulfilling the Foundation’s goals than opposing them.
It doesn’t undo anything - FreeBSD still exists. Personally I’m more interested in technical merit (perhaps even under DFSG-like licensing requirements), and I think a FreeBSD kernel and ZFS with the GNU userland is probably the best system going (right now I run FreeBSD but I use the GNU tools under aliases and I miss Linux package management).
How are they doing their threading? I’ve heard Debian GNU/kFreeBSD was always hobbled by trying to use glibc and would have been much better off building against FreeBSD libc.
What is a better effort depends largely on what You consider a worthy goal. Myself, I am a big fan of the GPL, and as such, any effort to remove GPLed software is something I would not find worthy of doing - quite the contrary. Thus, I applaud efforts such as Debian GNU/kFreeBSD and ubuntuBSD, because they allow me to work with the FreeBSD kernel, in an environment I am familiar with.
Something to be aware of is that it is usually under the guise of “Desktop support” that a lot of questionable decisions were made on Linux (cough systemd, pulseaudio cough) seem to have been made.
Both aren’t nearly as bad as the anti-systemd crowd portraits them. With systemd, my only issue is memory usage, that I’d like to be smaller for example when running multiple boxes/containers. But otherwise they have improved my user experience over sysvinit.
[Comment removed by author]
Running OpenBSD-current is a pretty painless way to have a rolling BSD and works really way as a desktop for laptops. If you want a quick overview on how that looks you can take a look at my blog post.
Roughly with OpenBSD you can have a rolling system (following -current with snapshots) or a Debian style long term release (by just installing -release/-stable and following errata patches). Snapshots work great for desktops, releases work great for servers (many people also opt in for m:tier provided packages).
I assume most other BSD’s have a similar setup (release/current).
Funny thing is that most WiFi drivers first arrived on OpenBSD :)
Obviously it’s an issue if you happen to have an unsupported wifi chip but getting a USB dongle is not a terrible thing. Nvidia gfx card support is another beast though, if you only have an nvidia card that would be a larger issue at least for OpenBSD.
Note that the nvidia drivers work great on FreeBSD if that’s an option for your use case.
So running OpenBSD is for subhumans? :(
Or super humans, or… :)
The OpenBSD installer is inhumane, frankly.
It’s IMHO the best installer. Absolutely no bullshit, and you can automate most of it by just mashing the enter button and accepting sane defalts.
May I ask what’s wrong with the installer? That’s literally the nicest and quickest system installer I encountered.
I found it asked scarily-phrased unclear questions and required you to manually edit the disklabel during the install with very little guidance on what to do. Maybe it’s got better.
I’ll agree disklabel editing is a bit hairy, but you don’t have to do that - it’ll give you a sane default adjusted to the size of your disk.
You must have tried it ages ago? :) Which questions do you find unclear? There is an auto partitioning scheme but the manual process is also very simple and well documented.