FreeBSD is an amazing operating system
unixsheikh.com
unixsheikh.com
I mean I also did a lot of chores around the house and was the responsible IT repair guy of the house but I thought that's a pretty good deal for being housed, fed and clothed for 20 years.
I think generally kids can benefit and grow a lot from being treated and talked to like responsible adults sometimes, and not as if they were useless small people that have to be constantly supervised.
I'm so thankful, honestly. I finally can have my VPSs without feeling like I'm dumb or I need to devote so much time and effort to sysadmin skills that I don't have nor I enjoy.
I still use Xubuntu in my laptop and Windows in my desktop, because of the lack of drivers and because they work out of the box (well, almost with Xubuntu), but still, for some reason I really feel confortable with FreeBSD, and this is coming from someone who just wants to spin DBs, sites, and cron scripts, and I don't have enough knowledge to appreciate jails and so many other things that other people likes about FreeBSD.
So guys, thank you.
Yeah, it's almost like developing the OS as a singular entity instead of a kernel with random bits tacked-on has some advantages...
Please if you are trying to use freebsd TRY jails (to shorten tldr, use iocage). They are just great :)
And dont go desktop. Just isnt worth it. Not enough people troubling with gfx support. Keep it as it is. Server.
There’s FreeBSD in almost every data centre. But it’s at a level most application developers just never see. Many infrastructure elements - from storage heads, to core routers, to enterprise application and security appliances - have chosen FreeBSD as the high quality, reliable, consistent, and liberally licensed base for their control plane software.
The point being, this is where FreeBSD has the greatest influence and adoption: as a platform, not the product, and not at all obvious even to those that thereby rely upon it.
That being said, yes it works great as the instance OS in EC2 and as a die-hard acolyte since 2.1-RELEASE you’ll pry my production application jails from my cold dead hands
And since FreeBSD is not GPL-licensed, it has exactly zero relevance as it means that no "lambda person" can use it, write code against it, etc... without paying the 2500$ of a devkit.
Sony could write their proprietary drivers for any OS - just look at nvidia which uses the same driver with just a microscopic shim across linux and windows.
Nintendo do use some code from the FreeBSD kernel in the network / sockets stack though - https://switchbrew.org/wiki/Sockets_services
Although FreeBSD looks cleaner and more consistent than Linux, it's not really clear why should one use it over Linux.
I hope the team will define strategic goals and try to develop some competitive advantage, even if it means focusing only on certain niches in the beginning. E.g. encouraging development of the OS modules in a safe language like Rust would probably lead to more stable system less vulnerable to exploits, and make it a more attractive choice for mission-critical deployments.
I guess a good desktop experience has the same utility to the freebsd ecosystem.
I wish they didn't have to. I wish the open source community would rethink the desktop experience from the ground up so that we can have truly portable desktop environments that speak a common API. Everything is so tightly coupled to the platform and a spaghetti mess of packages and tools that I don't think it can be achieved any way else.
Apple has vertical integration of their OS, so they don't have to worry about supporting the world. But the state of things in open source land right now is a complete disaster. X vs Wayland, compositors? desktop environments? window managers?
For instance, check out the Manjaro doc on switching desktop environments: https://wiki.manjaro.org/index.php/Install_Desktop_Environme...
Why is this such a nightmare? There is an entire section called "The Risks of Using Multiple DEs".
There are 'two steps' for switching to XFCE:
1. Install a basic XFCE environment,
sudo pacman -S xfce4-gtk3 xfce4-goodies xfce4-terminal network-manager-applet xfce4-notifyd-gtk3 xfce4-whiskermenu-plugin-gtk3 tumbler engrampa
sudo pacman -S lightdm lightdm-gtk-greeter lightdm-gtk-greeter-settings && sudo systemctl enable lightdm.service --force
Anyway I got no suggestions on how to improve this -- rant over. I just wish that we'd settle on a really rock solid abstraction and then get back to work rethinking and rebuilding UIs in Linux/BSD. Without vertical integration and/or monetary incentives I do not see this ever happening.
The real issue is that you have all those choices, but none of them are as fully featured without caveat as a similar DE for Mac or Windows. And there's the separation between window manager, desktop environment and display manager which is very confusing.
> X vs Wayland, compositors? desktop environments? window managers?
Nothing on this list, besides desktop environments, are things the user ever has to think about, unless they go out of their way to.
It seems you haven’t tried to use Ubuntu as a desktop, especially not outside of command line. I didn’t care about anything on the list but had to make decisions often because, from my point of view, the GUI applications providing basic functionality just didn’t work. The answer was many times “it’s because it’s Wayland” or compositor or whatever. Horrible experience, when I've used (just an example) gpart for years, it worked, then install a new version of Ubuntu and it doesn't. Then I investigate why, because Wayland. And I really never wanted to care about Wayland and compositor. Then I want to record a screen interaction. Should be easy. Again... doesn't work, investigate... "it's because it doesn't on the new compositor whatever"... Etc.
I suspect that those who develop GUI on Linux don't use themselves what they produce, as a lot of GUI is often unusable, or, even worse, was usable once and then completely degrades, even with newer... compositors, or even some other kind of "improvement."
I'd agree with that. I'd go so far as to say most GUI developers on Linux may never have actually used a GUI in their lives and rely on second-hand descriptions of how they work. Basic drag and drop often doesn't work, clipboards are all over the place, window behavior is super inconsistent... at least PulseAudio, for all its many faults, finally solved the sound server problem.
2) Gparted doesn't work, because it wants to run as root. You should use an application, that runs only minimal, necessary parts as root, and the UI runs with your user's capabilities.
3) Wayland compositors do not provide unrestricted access to to composed display for very good reasons. They do provide an access through controlled API. That controlled API didn't stabilize into unified one among different compositors yet, so for screen recording you have to use compositor-specific utility for now. In Gnome-Wayland/Ubuntu, you have one available by default.
So yes, when you clean up the capabilities over time, the old stuff will break. But without breaking it, you cannot develop your system. Apple also breaks compatibility will old apps, even more than most Linux distros.
Did you try it? Often, you cannot run even programs built in 2009 on Windows 10.
> Well, I can usually run GUI programs written for Windows in 1995 on Linux without recompilation.
You can run 1995 Linux binaries in Linux, provided a) you have the libraries they were linked against, b) they don't use direct hardware access ala svgalib c) they are not in a.out format, which was recently removed, due to nobody using it anymore.
Yeah, I actually do it all the time. There are some programs that don't work, particularly games, but for the most part it works fine.
> You can run 1995 Linux binaries in Linux, provided a) you have the libraries they were linked against
Including glibc, and take care to jump through the appropriate hoops to ensure the linker can find them because chances are they aren't in your repo.
I'm typing this on Ubuntu.
> The answer was many times “it’s because it’s Wayland”
I don't know how that is an answer you've come across as a solution on Ubuntu, because Ubuntu does not use Wayland unless you go out of your way to use Wayland.
> Horrible experience, when I've used (just an example) gpart for years, it worked, then install a new version of Ubuntu and it doesn't. Then I investigate why, because Wayland
I've used gparted for more than a decade and never ran into an issue with it. Not sure why you have a problem with Wayland when Ubuntu doesn't ship with Wayland support.
> And I really never wanted to care about Wayland and compositor.
If you were using Ubuntu, you never had to care about Wayland, unless you inflicted that problem upon yourself by going out of your way to use Wayland.
> I suspect that those who develop GUI on Linux don't use themselves what they produce, as a lot of GUI is often unusable, or, even worse, was usable once and then completely degrades, even with newer... compositors, or even some other kind of "improvement."
I respectfully disagree.
Every distribution does it their own way. The correct comparison of FreeBSD is not Linux; it is a Linux distribution such as for example Ubuntu, Manjaro, Arch, Debian, ...
These distributions each have a relevant market share, making the comparison fair.
Sure, there's overlap. If you want an OS which does it differently, consider having a look at NixOS.
> For instance, check out the Manjaro doc on switching desktop environments [...]
> There are 'two steps' for switching to XFCE:
> sudo pacman
> [...]
You're not supposed to execute commands which you don't understand. You're not supposed to execute sudo commands which you don't understand. Manjaro is supposed to be a user-friendly Arch version, so that is at odds with using CLI if you ask me.
I agree with you about the monetary incentive. Thus far, it does not appear anyone has succeeded, apart from Apple with iOS which is based on macOS which is based on FreeBSD. Jolla's Sailfish is struggling. Librem 5 with Purism's PureOS is delayed. Perhaps PinePhone?
They depend on too many moving pieces underneath them, and then there is the community hate how bloated they are, and how wonderful it is to reduce the experience to the twm days.
I am worried that if FreeBSD completely ditches the desktop side completely, it will become one of the OSes that the next generation of developers would not even encounter unless it happens to be used at their jobs.
The BSDs were in legal problems back then, plus with their license, many of its users never contribute anything back.
Except for SGI and NeXT, there was hardly any desktop culture on UNIX land.
https://www.wired.com/2016/08/linux-took-web-now-taking-worl...
I would use BSD if the server usage is more friendlier but right now, o don't see any benefit than using them for zfs.
Stability has a value all of its own. Back when I used Linux, every couple of years my system would get broken and I'd have to spend a couple of days fixing it. And often the commands for doing that would have changed since last time. Now I use FreeBSD and what I've got working stays working.
Is the nVidia driver still available for FreeBSD?
Many years ago I used to run the Linux binary of RtCW on FreeBSD using the emulation layer. Worked like a charm and the FPS was even slightly higher.
In terms of non-nvidia, a few years ago the port of the Intel driver was badly out of date and a recent laptop would be stuck on vesa. But that issue has been fixed as far as I can tell.
This is how things bitrot and driver support fades.
Lest we despair, macOS was based on FreeBSD. Also, lest we become overly enthusiastic, macOS is about the only successful desktop based on FreeBSD (apologies to y’all Dragonfly folks).
I wish there was more diversity in this regard but I think it’s an unfortunate instance of collateral damage of the GPL vs permissive licensing wars.
Writing something like 'MacOS is based on FreeBSD' implies a situation more like Sony's OrbisOS, which isn't the case with MacOS.
Can you share some source of your statement?
https://en.wikipedia.org/wiki/Darwin_(operating_system)
There's probably very little commonality left nowadays though. However, if you go back to the earlier days (Panther, Tiger, Leopard) and look at the release notes of Mac OS at the time, and the release notes of the contemporary FreeBSD version of the time, you'll see very similar text: I remember word-for-word paragraphs about things like NFS fixes in both.
It won't be that many years before I imagine we'll start seeing people asking to cite how the next forms of ChromeOS or Android were related to Linux.
And to clarify my example, Fuchsia is set to be a Linux-less functional rebuild of Android, but it'd be a bit myopic to point out that "there's no Linux in Fuchsia". It's like saying there's no Steve Jobs in any Apple products created after his death. Less perhaps, but not none.
But it probably makes the developers feel better by dogfooding their own OS instead of using another one but we have enough virtualization that one can run server OS on top of their most productive desktop OS.
This is coming from someone who use FreeBSD on daily laptop and weekend desktop. I would just not pick FreeBSD at work for anything other than my personal-work VM.
Rust is not an answer. There is zero kernel development support from both rust and freebsd side. I know that because I'm working on KPI for both as well as multiple userspace library wrappers.
> What I failed to realize back then was that FreeBSD was (and it still is) designed as a complete multi-purpose operating system meant to be setup and tuned according to specific use cases.
IMO, if it needs to be manually tuned, that's a bug, not a feature. (And I'm speaking as a FreeBSD developer on that.)
> FreeBSD sets the kernel and the base system apart from third party packages. This is unique to FreeBSD and none of the other BSDs do that.
Um, nope, this is how all of the BSDs do it.
> FreeBSD is installed only with the features you enable and nothing is running that you don't know about.
sendmail, cron, and ntpd run out of the box, to name a few.
> The FreeBSD code is meticulously maintained and very well documented.
Not really (especially in random drivers) and usually not (in the code, anyway). We have pretty decent manual pages.
> The FreeBSD rc system that reads this file understands dependencies between services and it can automatically launch them in parallel, or wait until one is finished before starting the things that it needs.
The parallelism part is not true.
> I believe it is important to understand that FreeBSD is not like a GNU/Linux distribution.
Not really true? In a lot of ways FreeBSD is like a GNU/Linux distribution; it just happens to bundle the equivalent of coreutils, binutils, gcc, etc with the kernel.
> FreeBSD is an operating system made by developers who are also system administrators.
Definitely not true (or at least, in no respect different than the developers of the broader Linux ecosystem).
> A Linux distribution is a collection of tools written by different groups of people, often with conflicting interests and priorities.
This is true! Especially for core bits of the system, like glibc and the kernel.
> A Linux distribution needs ..., additional third party software, the X Window System, a window manager, and a desktop environment, and it then needs to combine these different components into the resulting distribution.
This is of course no different than FreeBSD's ports system; we face the same integration challenges as Linux distributions.
> there are no conflicting interests in the [FreeBSD] project
Ha. ha. ha.
Maybe not so true today, but back when Linux first started, one of the main differences between Linux and FreeBSD was that BSD was written mostly by coders who worked as professional sysadmins, and Linux was written by coders who were mostly software engineers.
That's why Linux had all the new features, and BSD had all the stability. Because sysadmins cared about stability more than features.
It's sort of why their respective philosophies diverged.
I know because I spent a lot of time in the late 90s with the core committers who had been working on BSD since the 70s and 80s at Berkeley. They were all sysadmins.
Unrelated, I find it surprising that any major operating system these days need rebooting because "every third day or so otherwise the performance degraded a lot". Or maybe they just didn't increase the sysctl var kern.full_performance_days high enough ;)
I don't think I've had much system failure / panics either.
My guesses would be a memory leak somewhere, some yucky disk controller bug I didn't run into, or possibly the TCP LAST_ACK state accumulation https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=25986
This has since been fixed, although it did take an annoyingly long time; but before it was fixed, you could address it by tuning socket buffers to be smaller --- it seemed to be less likely for clients to disappear with unacked data, but also, when they did, it wasn't as noticeable.
Most things are tuned pretty well by autotuning these days though. If your work is more I/O limited than CPU limited though, tuning is more likely to be useful.
There are tons of knobs and I don't set or know anything about any of them in particular, sorry.
> Unrelated, I find it surprising that any major operating system these days need rebooting because "every third day or so otherwise the performance degraded a lot".
Me too. I assumed the author was talking about some (awful) historic bug rather than an ongoing issue they're having. Kinda sounds like a kernel memory leak, but it could be anything.
>This is true! Especially for core bits of the system, like glibc and the kernel.
Come on, of course this is blatantly false. There is plenty of politics. I've experienced it first hand. FreeBSD developers are most definitively driven by some agenda other than the selfless "the common good".
>> there are no conflicting interests in the [FreeBSD] project
> Ha. ha. ha.
My point exactly !
My understanding, and let me know if I'm totally wrong, is that most glibc developers are not Linux kernel developers, and that most kernel developers are not glibc developers.
In FreeBSD, I think there's more crossover of developers working on both userspace and kernel components. The monorepo design helps foster that (again, subjective, IMO).
Also, there is de-facto no competition, short of a hard fork, in the software shipped. You can't just "switch to uclibc" if an embedded platform has memory constraint.
FreeBSD has strong backwards compatibility at the shared library level, across all versions. Support for BSD 4.3 (as in, 1986, pre-FreeBSD) compatibility is slowly being phased out in 2019. Grep around for COMPAT_FREEBSD, for example. This compatibility (for existing stable releases) is by and large maintained in the development branch.
FreeBSD's also got a Linux syscall emulation layer, which implements (some of) the Linux kernel's (stable) ABI.
> The general answer in these case "rebuild", but it completely ignores binary-only software which exists in the real world and which is to a large extend completely ignored by commiters. At some point, you want to spend CPU cycle on something else than "rebuilding world".
That really isn't true. The point of the stable/ branches is the kernel KBI is stable for the lifetime of the branch.
> Also, there is de-facto no competition, short of a hard fork, in the software shipped.
Sure. But you can implement a patch and advocate for it against the existing implementation? Also, there is a lot of support for installing alternatives from ports. Doesn't seem that major of a gap.
I'm a former NetBSD developer, I left when I got fed up to re-invent the wheel. I spent many years after that supporting a commercial special purpose FreeBSD-basde distribution, and I got a fair share of conflicts on mailing list again "the old guard" (Warner & co) over various subsystem, and had to go as far as calling off an incompetent kernel committer working for Intel at the time. All my grief from ~10 years ago is publicly available in the mailing-list archives.
> FreeBSD's also got a Linux syscall emulation layer, which implements (some of) the Linux kernel's (stable) ABI.
IIRC, it is mostly vestigial, unless it has been going though a major updates in the past 10 years.
> That really isn't true. The point of the stable/ branches is the kernel KBI is stable for the lifetime of the branch.
Branch lifetime is irrelevant. Linux makes backward compatibility an utmost paradigm. I'm sure a 2.4 era binary will still work on 5.4, nearly 15 years later.
> Sure. But you can implement a patch and advocate for it against the existing implementation?
Unless you are a committer, the chance of getting ANY significant patch in is pretty much nil. As I mentioned previously, mailing list are NOT for discussing any significant changes, this is done behind the scene in private by a de-facto pseudo-"committee". The development process is closed to a few elites, generally small group of committers ruling over code sections. By the time any patch is ready, its author drops a +5000,-5000 lines turd^Wdiff that is utterly impossible to review. For lack of a better word, BSD are not remotely close to being open to outsiders. I know this by experience.
Why then is it that i'm locked to the kernel versions required by the binary blobs from proprietary vendors in the embedded space? Be it smartphones, home/SOHO routers, and so on.
Are they doing it wrong? Am I?
My ISP provided CPE runs Kernel 2.6.32.61 right now. Not to mention the crap uncounted Android devices (not mine, in the world out there) are running.
He also explicitly states that there has never and will never be a guarantee of kernel module binary compatibility.
I agree, it's amazing, and I love admining it.
The only reason reddit wasn't on BSD was because of lack of package support and then when we moved to AWS, lack of BSD support in AWS. Although that's since been fixed, thanks in large part to CPercival, creator of TarSnap, yay!
The way it is set up just makes so much more sense to me, and tweaking the kernel is just so much easier.
Also the focus on stability over supporting the latest technologies is a big plus for business servers.
Those people didn't answer to anyone, they were just paid to work on the OS. Yahoo! made heavy use of FreeBSD at the time (almost 20 years ago, now) so it was decided that since we were using this free software so extensively that it would be good to give back to that community.
I wish this notion that giving a small amount of resources to open source projects that have saved your company millions of dollars per year was more common than it is. I don't know of any large company that does what Yahoo! did back then.
I work for a large company now, and as far as anyone I've asked can tell, we give exactly nothing to any of the hundreds or possibly thousands of open source projects we use daily, and it does not put a good feeling in my stomach.
Unlike Yahoo, we are accountable to Netflix's business goals of increasing our streaming customer's Quality of Experience while still maintaining or reducing the cost to deliver content. Frequently those goals align nicely with FreeBSD's goals, and we have contributed a great deal (async sendfile, kTLS, unmapped mbufs, epoch stabilization, NUMA work, RACK TCP, BBR TCP, TCP pacing, and tons of stuff I'm forgetting).
Oh that's good to hear. Reading Brendan Gregg's blog [1] I got the impression that Netflix had switched to Linux.
I've spent the last couple of weeks trying to build a reasonable HiDPI desktop environment on a variety of open source platforms and nothing has the level of fit and finish I am looking for. So far I have been happiest with Elementary OS and their treatments to Gnome... but it preturbs me that getting a new rig setup is so fickle and unrepeatable. You can spend hours tweaking shit and experimenting with no reasonable way to save your changes to be applied later to a clean install or even a different platform. I wish I could check my entire configuration into git.
Would love if the hackers here would share their FreeBSD (or any Nix) desktop environment configuration (including window manager etc...)
My environment is
- Hyper-V on windows laptop
- FreeBSD 12.1 as guest (zfs)
- FreeBSD packages I use for devel (installed simply with its standard 'pkg add') are: InteliJC, vscode, openjdk11, postgres12-server, node12, tmux
- Desktop env is: xrdp (to allow remote desktop into the VM), wmaker (window manager and wmakerconf to config it), qterminal or lilyterm
So I just use Remote Desktop from windows host, into FreeBSD VM using XRDP and just run like that.
I connect using 24 or 32 bit depth (via RDP protocol) and tend to run Darkish/pastel colors themes in Visual Code and IntelliJ.
---
I know this is not an ideal setup, but lack of support for mobile dev (android at least) prevents me from using FreeBSD directly on hardware...
When Running on native hardware, without VM, I tend to use Pop! Linux because of how beautiful it looks, on HiDPI or regular screens, and it is relatively easy for me to use, as somehow that window manager setup does not get in my way
I also usually install emacs 27 or 28, but those require a binary package download from
https://freebsd.pkgs.org/12/freebsd-ports-latest-i386/ghub-e...
Use Emacs rarely these days, because of its lackluster support for JavaScript+Flow tooling.
I would much rather use Emacs for everything.. but right now I just use it to write status reports (org mode)…
Some DE:s are ostensibly nice and polished, but my feeling is that they mainly provide a soft landing for Windows and Mac dropouts. There's always a few spots where the thin veneer starts peeling and, given you know how to operate it, you'll soon find yourself back in the terminal anyway.
Any special reason you're on unstable?
It's a lot easier than it sounds once you do it, but you do have to take some time surmounting the initial barrier to entry, which is mostly reading.
Remember, if you can click on it, it's probably just a wrapper around a documented utility that does the actual work. And if you can do basic webdev like HTML and CSS, you can customize your desktop through its configs.
I have used a primer from here: https://cooltrainer.org/a-freebsd-desktop-howto/
in effect i have what i think you want, which is a way to bootstrap a new desktop/laptop based on a script (read: from a flash drive with minimal setup). however it is not as clean as what i see Nix offers. but, i don't have to worry about some "release" completely goofying up my setup. so it is nicely stable and deterministic to that extent.
Since then I built several more generations of file server, all running FreeBSD and all absolutely rock solid. They all typically had a 3-5 year service life, with uptimes of 1-2 years at a time. Each of them were only replaced for capacity reasons, with the previous generation server typically serving as a backup target for the next one.
Around 2002, broadcast and cable TV was still a thing, and rudimentary PVRs were becoming available but were pricey with few features. So I decided to build my own.
I started with Linux, thinking that it would provide better hardware compatibility, but stability issues soon drove me back to FreeBSD, and I managed to create a very complete FreeBSD based PVR solution, complete with remote control, automatic program scheduling, multiple simultaneous recording and viewing streams, auto DVD ripping and very intuitive remote (web) and onscreen user interfaces. That thing ran rock solid for 10 years, until replaced by Netflix.
I guess the point I am trying to make is that I fully agree with the author. FreeBSD is in a different league than many other operating systems in terms of capability and stability, while being surprisingly compatible with a lot of hardware.
Added a second hard drive (just put it in your Linux PC first and run a command to format it)
Bought an ethernet adapter and ran a command to install the driver. It had an FTP server so I could just type "get Friends-10-21-1999.mpg" and have the unencrypted file on my computer. It also had a web server to schedule recordings or act as a remote control.
Never had an issue with it.
FreeBSD on the Linux kernel would be a lot of work and at the end of the day, I'm not quite sure Linux needs a BSD licensed ifconfig, etc?
If FreeBSD wanted to use Linux video drivers, that could be useful, but there would need to be a stable interface between the kernel and the driver, and that interface would need to make sense for FreeBSD. Stable kernel apis is an anti-goal for Linux, so that's a non-starter; I wonder if Windows drivers could be more amenable, ala NDISWrapper; but that would also be a lot of effort, and if there were effort for FreeBSD video work, I'd imagine the intel drivers would get ported faster.
I bought that same book, installed it on a system, struggled like hell and went through it cover to cover. It was my "daily driver" for probably 5-6 years after that. The experience got me a job at an ISP running FreeBSD and later I started a web hosting business with FreeBSD backing.
I love it and love how easy and simple it is, but I too had to stray into Linux because that's where the crowd went. Hardware and software availability are key factors. I also think they should drop the focus on Desktop and go towards servers.
I've never administered servers that were as painless as those old BSD boxes. There is so much value in things that "just work" and documentation that's accurate. Yes there's a learning curve but it pays off exponentially.
Linux is being plagued by too many choices and too much change. RTFM doesn't do you a lot of good when it's out of date. It's only my decades of experience that help me figure things out when problems arise, I'd hate to be a beginner with Linux now. While Linux on the server is pretty tame the desktop world is out of control. I would like to see the FreeBSD folks just focus on making it the server/container host of choice.
Everything was very easy much like Debian maybe to get going. There's over 10,000 ports most are in package form at any time. Sometimes the build process fails and a package goes away for a short time, but you can always install it via ports.
My biggest gripe is and always will be the fact I can't use my spotify account on my FreeBSD desktop. I don't see this ever changing though. What I have done is gone back to relying on my local music collection a bit more again. I also bluetooth stream spotify from my phone to my receiver, but I'm lazy, hate phones, and don't generally like to do this.
It also has easiest operating system upgrade path out there that I have experienced. Just freebsd-update, reboot, done.
Jails are great, but they need work to be a bit more modern at this point. Docker has kinda showed some type of image repository is a nice feature. I'm not sure we'll see this right away, but BastilleBSD is working on some nice jails based solutions. Based off of FreeBSD, i'm pretty excited to possibly use this in the future.
For the record it is currently over 38,000:
Having said that however, I absolutely loved the FreeBSD books by Marshall Kirk McKusick. The red hardcover Design and Implementation of FreeBSD book was my go-to bathroom reading for well over a year. I also was lucky enough to attend viewings of VHS recordings from his operating systems class featuring FreeBSD. Those tapes were something like $1k/tape if memory serves, a friend's employer bought the entire set and would host group viewings on weekends. Such great memories from those times, McKusick was humorous and never missed an opportunity to take jabs at emacs while explaining how paging and swap worked, poor little vi being paged out because someone started emacs, etc.
There's a lot to love about FreeBSD, I hope it continues to exist and can attract enough new talent to thrive in the future.
I knew that to really achieve my ambitions, I'd need a way to store 50-100TB of data with high resilience and well-managed replication. Until I discovered FreeBSD and ZFS, I simply considered that kind of thing outside the realm of affordability and practicality.
But please know, fellow readers - it is affordable and it is practical. FreeBSD makes it so.
FreeBSD itself was a pleasure and I wish I could use it more. I've not found a linux distribution I've found quite as nice.
With that being said, on laptops Linux and macOS are my Unix-based operating systems of choice because of increased hardware support, although on older laptops I do have success with FreeBSD. But if I need a Unix-based operating system for a desktop, a server, or a VM, my first choice is FreeBSD unless the software I need specifically requires Linux.
I always work entirely in RAM. Everything is mounted tmpfs. Occasionally I accidentally exceed the amount of RAM I have available. Some file grows too large.
One of the things I always liked about BSD was how well it handled this situation.^1 It had no lasting effect on the operation of the OS. The only things affected were running applications that needed write space. Thus all I had to worry about were the running daemons I use that are continuously writing to logs. The OS would otherwise continue to function.
Whereas when I run out of space in a tmpfs-mounted directory in Ubuntu, I get filesystem errors. I cannot simply remove the excessively large file, and expect to continue to work indefinitely. I get I/O errors. I am eventually forced to reboot. Obviously I am not well-versed on Linux but as far as I can tell so far, this is a known problem.
1. This was NetBSD but I assume that FreeBSD and OpenBSD would be no different.
Anyways, there are Linux distros who specialize in this use case, and have sane and proven defaults tuned for that. Sometimes they seem a little bit 'ghettoish', but one can remove anything which is unnecessary, add needed stuff, even remaster in RAM and then rewrite that to another boot media. Or being lazy and just using an overlay to the stock image.
[1] https://antixlinux.com/ for instance works very well.
[2] http://grml.org/ is another Debian based one, altough a little bit lagging behind nowadays.
But many others also. [3] https://en.wikipedia.org/wiki/List_of_Linux_distributions_th...
Ubuntu is not a good starting point for that use case.
* Like carefully unplugging the SCSI controller from the running system, while it had no other available mass storage, watching the console being flooded with messages akin to 'Arrgh! I'm dying! Where is my...?', carefully reinserting the controller into the PCI-slot without causing shorts, console turning back to normal. And switching back to the running X as if nothing had happened. (And no file system damage in spite of having soft updates on UFS active, and running tasks with many open files)
Amazing.
But maybe it's not yet ready for prime time. Fedora was about to add EarlyOOM in the 32 release, but they'll probably defer this until at least 33:
https://www.phoronix.com/scan.php?page=news_item&px=Fedora-F...
Not to mention the absence of systemd and its overly-complex solution to non-problems.
FBSD-er since '98.
(FreeBSD user since 2.0.5 - 1995)
That said, a bunch of FreeBSD userland code and utilities were ported over to make the OS POSIX-ish.
It's probably easiest to think of a Mac as an amalgam of many different influences and operating behaviors, as opposed to a direct descendant of any one particular lineage.
[0] https://en.wikipedia.org/wiki/Darwin_%28operating_system%29
https://github.com/apple/darwin-xnu/tree/master/bsd
Also, more recently they imported pf from OpenBSD:
https://github.com/apple/darwin-xnu/blob/master/bsd/net/pf.c
Or do you mean that they have recently taken more code from other BSDs than FreeBSD?
The POSIX network stack for example, is now deprecated, and one must use Network.framework for the more up to date features,
"Introducing Network.framework: A modern alternative to Sockets"
https://developer.apple.com/videos/play/wwdc2018/715/
"Optimizing Your App for Today’s Internet"
https://developer.apple.com/videos/play/wwdc2018/714/
Likewise the long term roadmap introduced in Catalina plans to turn macOS into a micro-kernel, by moving all kernel extensions into userspace drivers.
They still have a lot of userland BSD parts. Including the very broken grep from FreeBSD (which is fixed in FreeBSD now IIRC):
$ echo "abcdef" | /usr/bin/grep -o "^..."
abc
def
The macOS kernel is derived from what Apple chooses to release as XNU, which is Mach-ish.
There may be confusion due to the fact that Apple used to publish a Darwin iso that you could boot on their ppc machines, but that's been a long time and OSX is still Darwin. If you run uname on a mac it will tell you that it's Darwin.
Userland tools tend to be the BSD ones with BSD style arguments. e.g. BSD du vs GNU du, GNU requires size suffixes in uppercase, BSD takes lowercase. MacOS tends to include the more useful GNU tools though, like grep. Find is still BSD, and the missing GNU extensions occasionally causes grief.
SIGINFO is preserved. On BSD, pressing Ctrl+t in the terminal will print process status. Some processes add extra info, but it always gives at least CPU load and running time. This is a distinctly BSD feature.
jails were/are common in the webhosting and gaming industries, and nowdays they can be managed with infrastructure-as-code tools like ansible or puppet. when backed by zfs, they can be made to behave very similarly to docker containers.
with the demise of docker the company and the fractured ecosystem of competing container runtimes, specifications, kernel compatibility issues, and management tools, jails are worth testing out. iocage is one way to start managing them.
Most of the container use-cases that aren’t layers work fine under jails. But it’s a more primitive tool, definitely not as user friendly.
Neither one of them was delivering usable experience.
UnionFS is broken and not recommended to use. ZFS snapshots aren't layers. FreeBSD has loosely coupled tools to make something like docker, but nothing remotely close to full docker is available atm.
I'm pretty sure that with unionfs you could get layer-ish equivalent for most use cases. Not going to question that it wouldn't be user friendly though
OpenBSD actively goes the extra mile in creating new security mitigations and ideas and the developers have always raised the difficulty of finding a 0day in the default install of OpenBSD. They are the creators of OpenSSH, kASLR, pledge(), W^X, etc and some of them are also the maintainers of LibreSSL.
You can still 'think' OpenBSD is more secure than FreeBSD, but I know it is still more secure.
Iridium works, html5 video works, so do the videos under MPV. I've heard succesful stories from OpenBSD users with Vulkan under MESA. Even amdgpu works, but the -current release is better for that.
PPSSPP and some C# gaming works; so does N64, NES, SNES, PSX and even maybe DC emulation. A PS2 emulation is WIP, and it's not PCSX2. Then there is Dolphin, Nethack, ScummVM, lots of source ports...
You have LibreOffice if you want, among a lot of known ports https://openports.pl such as Python3, R, Node, and so on. No Netflix, but maybe with fake mobile UA's under Chromium you can override the DRM.
CWM+XClock+Xlock as my "DE". I don't need more.
I run quite a lot of stuff on OpenBSD and it works for the most part fine. Sure if you are running Netflix or something at mega scale it probably won't be any good, but it works quite well for a lot of hosting scenarios.
I can make a pretty decent desktop OS as well.
That’s the power of freebsd. Not security.
Meanwhile Walnut Creek cd-rom was setting bandwidth and uptime records with a P6-200 running FreeBSD as their ftp server
I used to be all-in for GPL, but GPL is an ideology. Just like with philosophies/ideologies, one exclusively is never true enough for reality. There's absolutely nothing wrong with the BSD licensing: it allows multiple views on the world to co-exist, unlike GPL.
Since I'm a person with a job, run serious things and has a deadline, I use linux.
On servers, Linux seems to work. Maybe it's not as good as bsd in some cases, but I don't know those cases; and Linux has thus far worked.
Where bsd has worked for me is on macOS. I think that's a bit less about bsd and more about desktop/UI decisions dating back to the Steve Jobs days (idiosyncrasies aside). But I have doubts about how much the underlying OS had to do with the experience at the UI level.
Whether a bsd or linux, the desktop story is terrible compared to macOS. Even Windows has some advantage if certain app dependencies are considered. As a developer (who must still also perform some business tasks), macOS is the best option. Linux desktops are almost as good, with some big exceptions. BSD desktops might perhaps be on par with Linux, but they will fail on some of the development requirements.
I know competition is good for innovation, but at some point I would like to see the highly fragmented OSS desktop efforts consolidate. At this point, long after Jobs's death, macOS has fallen greatly in terms of quality and usability; so surpassing it isn't _that_ hard. Windows still doesn't, but I doubt it ever will. In fact, Windows has increased significantly as a development platform while still remaining horrible from a desktop user perspective. macOS has slipped. Linux has gained only slightly. BSD, who knows... but it cannot have improved more than Linux. Whether Linux or BSD, there's plenty of achievable gains to make if motivated OSS folks would consolidate more.
Mac is a great consumer os, but it is horrible for business and continuity. They will unpredictably remove features and pull support. Just recently, apple removed support for 32 bit applications, thrre are many games and other software that have stopped working with this upgrade. They have no maintainer, in some cases companies that have produced them are gone, actual developer might have kicked the bucket. Sure, you get a sleek product.
Compare this to Windows, where you can still run 16 bit software, and i have a game released in the 1999 that still works! Microsoft supports 3 parallel UI's: WinForms, WPF and UWP. That's why the system is bloated and looks a bit like a mess.
But that's also why I can write and application that solves a problem, and be confident that it will function for a decade or more without my involvement.
Working software should not rot without a team of developers behind it, constantly sprinting just to keep up with a platform moving out from under them.
You can see this most clearly in IoT space, where every year a few services are shut down, turning thousands of perfectly functional devices into useless paperweights.
Back to your comment at hand, I largely agree, I am a bit sick of the million options avaliable in linux for every given task, I wish they was more emphasis on getting the whole shebang to work together well and refining existing solutions, rather than creating yet take on a familiar problem.
I think there is this idea that Linux can't or won't achieve what BSD has but after being a sysadmin for years in Linux systems running behind pfSense I can say that this is all a rose colored vision of a time gone by from people who had the misfortune to learn Unix before linux. They are both full of silly paradigms and pitfalls, inconsistency and sometimes even order but in equal parts if you actually understand them and how they are built. The only difference I see at 20 years at it is one of them has hardware, software, and documentation for any contingency even if it's lackluster and the other is freeBSD. I admire the nostalgia but its gotten old...I would go so far as to say for pure practicality that I can do anything on Linux I can do on BSD but Im not nieve enough to claim the opposite.
Why is that so impossible? Konqueror had a tiny fraction of the contributors that Mozilla had, but since it was better designed it was still able to get ahead, and now almost everyone is using a Konqueror-derived rendering engine. If they had "consolidated" with Mozilla we would have missed out on that.
Right now, FreeBSD does a lot of things better than Linux. ZFS is better than anything Linux can offer. Jails are still ahead of Linux containers. OSSv4 is still nicer than ALSA. FreeBSD ifconfig is still nicer than whatever you have to use to configure your wifi this week. I'm not going to switch to a worse OS, and I'm not sure why you'd expect anyone else to.
Why are jails better and if so why did they lose to containers?
Why is OSS better when alsa could probably interface with one of those talking fish on the wall if you ask it nicely.
Why is ZFS any better than the Linux implementation if freeBSD is backporting the Linux version now.
Why is ifconfig better than network manager when there are no drivers for half the chipsets anyway.
Linux is practical, and I think hate for it comes from BSD users frustrated that they dont want to learn how another kernel works but I share none of the problems BSD users often claim. Your hangup is on a distro or a filesystem but never the actual Linux kernel which it seems to me nobody bothers to learn before trashing anyway.
They're better because they have actual security/isolation engineering. They lost because all people care about is having some kind of backend for orchestration systems that's capable of running Python. Even on Linux you can find all sorts of technical arguments about one form of container being better than another, but no-one actually cares beyond "does kubernetes use it as a backend? y/n".
> Why is OSS better when alsa could probably interface with one of those talking fish on the wall if you ask it nicely.
It offers a proper unixy API where you just have bytestream interfaces that you write to. You can use ordinary command line tools rather than needing a bunch of specialised programs.
> Why is ZFS any better than the Linux implementation if freeBSD is backporting the Linux version now.
There are more maintainers for ZFS on Linux - which should tell you something about how much better ZFS is than any Linux-native filesystem. The ZfsOnLinux codebase is fine, and if the licensing issues were ever resolved then one of the biggest reasons to use FreeBSD would go away.
> Why is ifconfig better than network manager when there are no drivers for half the chipsets anyway.
Because it works the way you'd expect, and stuff that works continues to work. E.g. fun story: Linux can't connect to my work VPN, because there's no way to pass a one time passcode through to a VPN login. Even though I've got the same version of OpenVPN installed on both FreeBSD and Linux, which has support for one time passcodes, on Linux that gets lost somewhere in the tightly-coupled layers in between that are necessary to have a network connection there.
> Linux is practical, and I think hate for it comes from BSD users frustrated that they dont want to learn how another kernel works but I share none of the problems BSD users often claim. Your hangup is on a distro or a filesystem but never the actual Linux kernel which it seems to me nobody bothers to learn before trashing anyway.
ZFS support is a kernel licensing issue. Jails are something that would require kernel-level support. Beyond that "Linux" is a pretty standard synecdoche for the whole OS; if there were reputable non-systemd/networkmanager/wayland distributions that would solve some of my problems, sure, but there aren't (I looked at installing Devuan but it seems to have already collapsed).
I suspect that you are missing whatever the gui ovpn plugin uses for askpass (should be in the log, complaining). Try starting the vpn from cli ('nmcli connection up $conname'); nmcli is pretty good at asking for info it needs, without the 'tightly-coupled layers' getting into its way.
It looks like Ubuntu has offered ZFS since 16.04.
Until your competitor leverages outlier technologies to outcompete you. That's basically what Paul Graham did in the nineties :)