FreeBSD is a tremendous project. I've used it since the 4.x days, first for work (web/mail/database hosting, at the time) and then for personal projects.
I have a 2000-era desktop PC as a personal server that I had left collect dust until very recently after switching to Macs for daily work long ago. It was running 6.1 and I hadn't booted it in a few months shy of ten years. I booted it right up, and in an afternoon proceeded to, in small stages, update it to the latest 12.1 release, which I am running with great stability now, including live repartitioning and better use of the available disk space after going into single-user admin mode. "Recent" improvements that I've been appreciating have been a smaller/more dense console font, easier wireless configuration (it has an Atheros-based PCI wifi card), and easier and more clear package and ports management. AND it still runs fast.
I will just use this oportunity to thank FreeBSD team (from kernel to ports maintainers) for their work on project and give my thanks in advance for anyone who joins it.
It was magnificent server for last 10+ years and I have never trembled before doing a major upgrade.
If you dont hear this enough: please keep on working your great work, maybe you are not the most used OS, but you have all my love <3 <3 <3
If anyone else is wondering like me who Bruce Evans is:
> Bruce Evans <[email protected]>
> Bruce is the Style Police-Meister. When you do a commit that could have been done better, Bruce will be there to tell you. Be thankful that someone is. Bruce is also very knowledgeable on the various standards applicable to FreeBSD.
Seems he had an approach to reviews worthy of emulation:
"Code reviews from Bruce came in three flavours, "mild", "brucified" and "brucifiction", but they were never personal: It was always only about the code, the mistakes, the sloppy thinking, the missing historical context, the ambiguous standards - and the style(9) transgressions."
I think the idea of having a long term support release for 5 years was great [1].
FreeBSD 11 has been around for some years now, getting an update to which 11.3-RELEASE can be upgraded with minimal hassle is a major plus for FreeBSD.
I too used FreeBSD for many things between 4x and 10.x, but have made the switch to Ubuntu in the past couple of years.
Things I miss:
1) Jails without having to have a hypervisor system, Linux doesn't really have anything comparably as easy to use particularly with the iocage project managing the jails.
2) ZFS out of the box supported at at lower level than modules and user tools. ZoL has come a ways but Linux's political opposition to it is always going to be a weight around its neck.
FWIW I am using a ZFS pool that has never been wiped/recreated since FreeBSD 8. It was created on that OS and has been migrated between Linux/BSD twice over a span of 11 to 12 years.
Things I don't miss:
1) The lack of file/directory monitoring libs and third party applications because, honestly, kqueue sucks.
2) While simple SysV init was simple 15 years ago systemd has come a long way. I hate to admit it, but systemd is the better way at this point because I like having my daemons restart themselves without third party monitors.
3) Brain drain is real, it seems the last time I used FreeBSD that port maintainers are running thin and I don't have a suggestion for how to attract more of them. For many years FreeBSD's package/port system was the best in the world (yes, better than the Linux alternatives like apt and rpm too). I think pkgng's rollout was bungled, though, and while it may be better now it seems to have a lingering cost in port maintainers.
It's highly misleading to state that one will not miss "simple System V init" from FreeBSD, because it is a falsehood by implication.
One of the things that characterizes the BSDs is that they never had AT&T System 5 init, nor the van Smoorenburg clone thereof for Minix+Linux. It's one of the things that the BSD side of the universe resisted from the AT&T side of the universe back in the 1980s. FreeBSD has BSD init, a rather different beast to AT&T init, and Mewburn rc, which is very different to van Smoorenburg rc (although the post-2014 revisions on Debian make van Smoorenburg rc come closer) on Linux.
And it's equally misleading to talk about liking your dæmons restarting themselves, because that's untrue too. systemd is the very third party monitor, externally monitoring and restarting the dæmon programs so that they do not have to restart themselves, that you claim to want to do without.
I didn't think there was any political opposition to ZoL other than the fact that its licence is incompatible with the GPL, and outside of a complete clean room rewrite, there's really nothing anyone can do about it. It's not like you're going to convince Oracle to relicence it.
I admit to not being as familiar with Jails as I'd like, but systemd-nspawn seems to cover much of this use-case on the Linux side. I've used it in a few different scenarios and found it very easy and intuitive to set up. Easier and simpler than VZ for kernel-based VMs for sure.
FreeBSD is a delight to run, I use an old AMD build to host Plex, PiHole and some other services in bhyve VMs. Keep a copy of Absolute FreeBSD around for physical reference just like the 90s.
During quarantine I decided to set up some networking equipment with FreeBSD whereas historically I’d have used Linux. Wow! What an improvement! Everything is so much cleaner, easier, faster to set up. I don’t have to screw around as much to make it boot and install on headless hardware. I can boot off a ZFS root volume. Networking is simple and clear to configure. Documentation is great. I don’t think I’ll use Linux again in the future when setting up a server, if I can avoid it.
What kind of networking equipment? I'm thinking of ditching pfsense and going bare freebsd or pfsense for my home router box and a few more anecdotes of similar projects would be nice to hear.
"FreeBSD 11.4-RELEASE Announcement
[...]
Some of the highlights:
The clang, llvm, lld, lldb, and compiler-rt utilities as
well as libc++ have been updated to upstream version
10.0.0.
[...]"
I found this interesting. Seems like FreeBSD is more pragmatic than OpenBSD. They are using the latest and greatest llvm/clang series.
For license related reasons OpenBSD is stuck on an older version of gcc. I understand that OpenBSD has now _also_ become stuck on an older clang/llvm due to license changes there too.
In the long run, not upgrading the compiler is going to hurt OpenBSD a lot, I think. A lot of mitigations are now built in the compiler and languages (e.g. C++) are accumulating features at quite a fast pace.
I was wondering if users of OpenBSD have thoughts on the above. Do you think its a bit deal? What is the solution? How does OpenBSD not get left behind as a platform?
Or is this older clang/llvm issue only relevant for the core system and pkgs would have latest clang/llvm?
This seems like a good place to ask. I saw this comment[1] few weeks back
> This is one of the superior aspects of FreeBSD: no parsing of human-readable strings to get back machine-readable information about the process table. It's available directly in machine-readable form via sysctl().
And started wondering how deep does that go in (Free)BSD? Is all info available in neat strucured format programmatically, or are there other places where you'd need to do Linux-like parsing of special files? Is there some good reading material of this aspect of the system?
I hope this isn't too inflammatory Linux vs BSD question, I did not intend value judgement on either approach.
> And started wondering how deep does that go in (Free)BSD? Is all info available in neat strucured format programmatically,
In short: not exactly, but it's somewhat better than Linux. Sysctls are a commonly used, structured tree of mostly integers. The thing Linux does where procfs/sysfs are a bunch of unstructured text files? FreeBSD mostly doesn't do that.
Here are some sort of off-hand exceptions or oddball things that might be less desirable:
1. To get the disk/partition topology, there is a sysctl that spits out an XML graph: kern.geom.confxml. So that's sort of text parsing, but it's got a well-defined grammar that many libraries exist to parse already.
2. Some sysctls just dump opaque kernel ABI binary structures. These are machine parseable by C programs as long as they were compiled with the same headers as the kernel; parsing in non-C or across ABIs is less good. If these interfaces need to be portable, they are usually exported in a more portable way by libc or another base system C library.
> or are there other places where you'd need to do Linux-like parsing of special files?
The only special filesystem you need in FreeBSD is devfs (/dev), and it is populated by devices (or directories containing devices, symlinks to other devices, etc). So if a device exposes an interface that is arbitrary text, sure, you could have something like the Linux situation. But that is atypical. You absolutely do not need /proc or /sys; I don't have either on my desktop FreeBSD workstation.
The common convention is to use ioctls instead. Ioctls are a pretty lax type system, but the FreeBSD ones do embed the size of the structure in the identity of the ioctl, so you have at least a slight guarantee of noticing ABI changes and being able to provide backwards compatibility.
> Is there some good reading material of this aspect of the system?
The canonical book here is FreeBSD: Design and Implementation, 2nd Edition. It's not super recent, but many of the underlying design principles are accurate. Many of the subsystems described function in basically the same way today. I would also plug Joe Kong's FreeBSD Device Drivers if you're interested in writing device drivers specifically (full disclosure: he is a friend).
I think this comes from the different development model. Passing machine-readable stuff instead of parsing strings is convenient, but requires cooperation between parties, usually the kernel and the userspace. In FreeBSD it's trivial: I can change the kernel, userspace, and documentation all in a single commit. In Linux it's much more involved - you never know which userspace version is going to interface with whatever you've tinkered with; people who put together distributions are separate from actual developers of various parts etc.
As a long time user, this feels like something that's true but not. The userland tools to dump kernel information (ps, ifconfig, etc) get back binary data from the kernel, not human readable strings, so it's true, but other programs that might need that information would often be expected to call the same tools and then parse the human readable forms until the recent inclusion of libxo can provide machine readable outputs. libxo was added in FreeBSD 11.0, and I'm not sure how far it's been implemented; when I was still managing a large fleet of FreeBSD machines, we had a bunch of 10.x, so it didn't makes sense to update our scripts to use libxo.
There's an enormous amount of stuff available via sysctl(). It is essentially a huge, hierarchically extensible, system call API that passes (usually, but not always) machine-readable data to programs. The sysctl(3) manual page has a lot of stuff, but it doesn't cover anywhere near everything.
All of the transmit/receive statistics for the second Ethernet interface on one of my machines are various numeric values under dev.bge.1.stats , for example.
The machine-readable process table record structure is given as a C language structure, struct kinfo_proc, in the <sys/user.h> header.
I was porting a diagnostic command the other day, which displayed SMT status for the IBM power processor - written by a programmer at IBM. It was essentially a directory walk strncmp loop over /proc. The overwhelming sadness compelled me to spend a day of trying to figure out how far back I could trace direct evidence proving the existence of _SC_NPROCESSORS_CONF. Unfortunately I couldn't find the source code for SVR4.0MP, only references in interface manuals.
After a year of trying Ubuntu as my at home dev machine, I'm going back to FreeBSD. FreeBSD is much more of a pain during initial setup, but then it just works. Where as my laptop with Ubuntu has the most finicky Wifi and freezes way too often, and I didnt have these problems with FreeBSD on the same hardware.
I love FreeBSD. Been using it in a server context for going on 20 years now.
Trying to use it on a desktop takes me back to, well, trying to use Linux on the desktop 20 years ago.
Recently started shopping different distros because I’m not comfortable with the direction Ubuntu is going and rather than upgrade my 18.04 when it’s EOL’d, I’m looking at just hopping to something else for my work laptop.
Took hours to get X working with my laptop’s graphics card (though most resources I found online said it wouldn’t work at all, so that was a nice bonus). Not “get accelerated graphics working” just “get X to start”.
Spent another couple hours screwing around trying to get the trackpad working. And not just “get it working to my liking” but get it working at all. Turns out it’s entirely not supported as a lot of modern laptops uses a I2C connection rather than USB/PS2/etc, and there’s just no driver support for that. Never did get that resolved.
A lot of desktop apps that I use are either unavailable or require a lot of dicking around to use at all. There is no Slack desktop client. You cannot run Docker natively, and instead I ended up setting up a Debian guest OS under bhyve, which harkens back to how Docker is run on Windows/OSX and all the caveats that entails.
You’ll pry my FreeBSD servers from my cold dead hands, but it’s certainly not my go-to for a desktop OS.
If you decide you need Linux due to drivers or whatever, I'd recommend giving Arch a try. Arch has a reputation of having a learning curve, but it's no worse than the FreeBSD and like the BSDs it has excellent documentation. In my experience, Arch has been very stable with few surprises, especially if you avoid unnecessarily complicated software like GNOME. I can't say the same for Ubuntu or Fedora.
If you're able to get your drivers and all working with FreeBSD then good for you! FreeBSD is awesome and I'm always happy to come across it.
I personally feel sad when people state (indirectly) that Linux is NOK because their Ubuntu didn't work well :(
Ubuntu is probably the only Linux distro which I hate => I admit that it's a bit a mixed situation (Ubuntu seems to be a kind of "lighthouse" for the Linux world), but in the end I personally think that it's a pity that it acts as representative of the Linux distros.
I'm currently using Gentoo & Mint & Arch (depends on the usage), and in the past I liked as well at least Fedora and CentOS (not using them since a long time), but I never liked Ubuntu.
Do you actually get working wifi, suspend/resume and acceptable battery life under BSD?
Last time I tried (open)BSD, none of those things worked acceptably. The recommended way to connect to wifi was to manually edit wpa_supplicant.conf and battery life was a solid hour less than under linux.
I feel like BSD is a great "laptop OS" if you're the kind of user that leaves their thinkpad plugged in all the time, essentially using it as a small-form factor desktop.
I've been mulling over a decision to add a dedicated server for my postgres usage in my home server cluster. Ideally I'd like something rock solid stability and that doesn't require a lot of maintenance, and FreeBSD is definitely a candidate. Low resource usage, fast networking, and native ZFS are great benefits.
Does anybody here run postgres on FreeBSD? Any gotchas to look out for? Is performance comparable to linux? Anything to look out for when using NVMe flash drives?
It's a shame the popular VPS providers, like Linode and DigitalOcean, don't support easy installations of FreeBSD (and other BSDs). Does anyone know of trustworthy hosting solutions that make things easy?
I changed the OS of my NAS a few weeks ago (from "Gentoo Linux" to "Linux Mint") to FreeBSD (mainly to have a "better ZFS" - I read only later that apparently both Linux & BSD ZFS are being merged?) and the installation and configuration has been very smooth (currently up and stable with e.g. Xfce, gkrellm => just a simple NAS).
I miss only the "nmon" utility but apparently it's possible to "port" almost any Linux program automatically to FreeBSD Linux apps => I might have a look at that.
Recently, a certain unmentionable trend in Linux system software makes me really want to try FreeBSD again.
What’s the state of the art for unprivileged containers? I’m very keen on containers that look very similar to the host OS as they make excellent environments for teaching pupils about the OS, especially if the container host can fake them into being “root” in their container.
Part of the security premise of FreeBSD Jails is that jailed root cannot escape. So, jails are a lighter-weight container which satisfies that need. They can (and often do) look very similar to the host OS.
I think the gold standard here is hypervisors, and if you want to go that route, Bhyve is satisfactory for many workloads. But jails should be somewhat lighter overhead.
BSD threads are similar to PHP threads. Most comments are speaking judgementally about the overall quality of the product rather than the post itself, though in the case of BSD the judgment is overwhelmingly positive rather than negative.
Looks like a nice release. I'd be curious to hear from people who are using FreeBSD on the server, their stories of how it works out especially vis-a-vis working with newer developers who may lack depth in their Unix background.
[+] [-] incanus77|5 years ago|reply
I have a 2000-era desktop PC as a personal server that I had left collect dust until very recently after switching to Macs for daily work long ago. It was running 6.1 and I hadn't booted it in a few months shy of ten years. I booted it right up, and in an afternoon proceeded to, in small stages, update it to the latest 12.1 release, which I am running with great stability now, including live repartitioning and better use of the available disk space after going into single-user admin mode. "Recent" improvements that I've been appreciating have been a smaller/more dense console font, easier wireless configuration (it has an Atheros-based PCI wifi card), and easier and more clear package and ports management. AND it still runs fast.
[+] [-] hpkuarg|5 years ago|reply
[+] [-] stiray|5 years ago|reply
It was magnificent server for last 10+ years and I have never trembled before doing a major upgrade.
If you dont hear this enough: please keep on working your great work, maybe you are not the most used OS, but you have all my love <3 <3 <3
[+] [-] sedatk|5 years ago|reply
> Bruce Evans <[email protected]> > Bruce is the Style Police-Meister. When you do a commit that could have been done better, Bruce will be there to tell you. Be thankful that someone is. Bruce is also very knowledgeable on the various standards applicable to FreeBSD.
https://www.freebsd.org/doc/en_US.ISO8859-1/articles/committ...
[+] [-] fipar|5 years ago|reply
"Code reviews from Bruce came in three flavours, "mild", "brucified" and "brucifiction", but they were never personal: It was always only about the code, the mistakes, the sloppy thinking, the missing historical context, the ambiguous standards - and the style(9) transgressions."
Source: https://www.freebsd.org/doc/en_US.ISO8859-1/articles/contrib...
[+] [-] pwdisswordfish2|5 years ago|reply
Write K&R C and compile to 16-bit for 8086 or 3086.
https://github.com/lkundrak/dev86
In the early days of Linux, bcc was used in building the kernel.
bcc used to be required for ELKS.
bcc is still used today, e.g., in compiling VirtualBox.
http://web.archive.org/web/20200427081559/https://www.virtua...
[+] [-] markjdb|5 years ago|reply
[+] [-] unknown|5 years ago|reply
[deleted]
[+] [-] aduitsis|5 years ago|reply
FreeBSD 11 has been around for some years now, getting an update to which 11.3-RELEASE can be upgraded with minimal hassle is a major plus for FreeBSD.
([1] edit: referring to https://lists.freebsd.org/pipermail/freebsd-announce/2015-Fe...)
[+] [-] cperciva|5 years ago|reply
[+] [-] RNCTX|5 years ago|reply
Things I miss:
1) Jails without having to have a hypervisor system, Linux doesn't really have anything comparably as easy to use particularly with the iocage project managing the jails.
2) ZFS out of the box supported at at lower level than modules and user tools. ZoL has come a ways but Linux's political opposition to it is always going to be a weight around its neck.
FWIW I am using a ZFS pool that has never been wiped/recreated since FreeBSD 8. It was created on that OS and has been migrated between Linux/BSD twice over a span of 11 to 12 years.
Things I don't miss:
1) The lack of file/directory monitoring libs and third party applications because, honestly, kqueue sucks.
2) While simple SysV init was simple 15 years ago systemd has come a long way. I hate to admit it, but systemd is the better way at this point because I like having my daemons restart themselves without third party monitors.
3) Brain drain is real, it seems the last time I used FreeBSD that port maintainers are running thin and I don't have a suggestion for how to attract more of them. For many years FreeBSD's package/port system was the best in the world (yes, better than the Linux alternatives like apt and rpm too). I think pkgng's rollout was bungled, though, and while it may be better now it seems to have a lingering cost in port maintainers.
[+] [-] JdeBP|5 years ago|reply
One of the things that characterizes the BSDs is that they never had AT&T System 5 init, nor the van Smoorenburg clone thereof for Minix+Linux. It's one of the things that the BSD side of the universe resisted from the AT&T side of the universe back in the 1980s. FreeBSD has BSD init, a rather different beast to AT&T init, and Mewburn rc, which is very different to van Smoorenburg rc (although the post-2014 revisions on Debian make van Smoorenburg rc come closer) on Linux.
And it's equally misleading to talk about liking your dæmons restarting themselves, because that's untrue too. systemd is the very third party monitor, externally monitoring and restarting the dæmon programs so that they do not have to restart themselves, that you claim to want to do without.
[+] [-] xxpor|5 years ago|reply
[+] [-] Grimm665|5 years ago|reply
[+] [-] stiray|5 years ago|reply
Just for anyone else: jails had NEVER had anything to do with hypervisor, it is a kernel level isolation, actually far more complete than cgroups.
[+] [-] butterisgood|5 years ago|reply
[+] [-] 12bits|5 years ago|reply
[+] [-] centimeter|5 years ago|reply
[+] [-] efxhoy|5 years ago|reply
[+] [-] sidkshatriya|5 years ago|reply
For license related reasons OpenBSD is stuck on an older version of gcc. I understand that OpenBSD has now _also_ become stuck on an older clang/llvm due to license changes there too.
In the long run, not upgrading the compiler is going to hurt OpenBSD a lot, I think. A lot of mitigations are now built in the compiler and languages (e.g. C++) are accumulating features at quite a fast pace.
I was wondering if users of OpenBSD have thoughts on the above. Do you think its a bit deal? What is the solution? How does OpenBSD not get left behind as a platform?
Or is this older clang/llvm issue only relevant for the core system and pkgs would have latest clang/llvm?
P.S. It seems llvm on pkgs is still 8.0.x https://github.com/openbsd/ports/tree/master/devel/llvm
[+] [-] zokier|5 years ago|reply
> This is one of the superior aspects of FreeBSD: no parsing of human-readable strings to get back machine-readable information about the process table. It's available directly in machine-readable form via sysctl().
And started wondering how deep does that go in (Free)BSD? Is all info available in neat strucured format programmatically, or are there other places where you'd need to do Linux-like parsing of special files? Is there some good reading material of this aspect of the system?
I hope this isn't too inflammatory Linux vs BSD question, I did not intend value judgement on either approach.
[1] https://news.ycombinator.com/item?id=23425867
[+] [-] loeg|5 years ago|reply
In short: not exactly, but it's somewhat better than Linux. Sysctls are a commonly used, structured tree of mostly integers. The thing Linux does where procfs/sysfs are a bunch of unstructured text files? FreeBSD mostly doesn't do that.
Here are some sort of off-hand exceptions or oddball things that might be less desirable:
1. To get the disk/partition topology, there is a sysctl that spits out an XML graph: kern.geom.confxml. So that's sort of text parsing, but it's got a well-defined grammar that many libraries exist to parse already.
2. Some sysctls just dump opaque kernel ABI binary structures. These are machine parseable by C programs as long as they were compiled with the same headers as the kernel; parsing in non-C or across ABIs is less good. If these interfaces need to be portable, they are usually exported in a more portable way by libc or another base system C library.
> or are there other places where you'd need to do Linux-like parsing of special files?
The only special filesystem you need in FreeBSD is devfs (/dev), and it is populated by devices (or directories containing devices, symlinks to other devices, etc). So if a device exposes an interface that is arbitrary text, sure, you could have something like the Linux situation. But that is atypical. You absolutely do not need /proc or /sys; I don't have either on my desktop FreeBSD workstation.
The common convention is to use ioctls instead. Ioctls are a pretty lax type system, but the FreeBSD ones do embed the size of the structure in the identity of the ioctl, so you have at least a slight guarantee of noticing ABI changes and being able to provide backwards compatibility.
> Is there some good reading material of this aspect of the system?
The canonical book here is FreeBSD: Design and Implementation, 2nd Edition. It's not super recent, but many of the underlying design principles are accurate. Many of the subsystems described function in basically the same way today. I would also plug Joe Kong's FreeBSD Device Drivers if you're interested in writing device drivers specifically (full disclosure: he is a friend).
[+] [-] trasz|5 years ago|reply
[+] [-] toast0|5 years ago|reply
[+] [-] JdeBP|5 years ago|reply
All of the transmit/receive statistics for the second Ethernet interface on one of my machines are various numeric values under dev.bge.1.stats , for example.
The machine-readable process table record structure is given as a C language structure, struct kinfo_proc, in the <sys/user.h> header.
[+] [-] tal8d|5 years ago|reply
[+] [-] yjftsjthsd-h|5 years ago|reply
[+] [-] 2trill2spill|5 years ago|reply
[+] [-] nucleardog|5 years ago|reply
Trying to use it on a desktop takes me back to, well, trying to use Linux on the desktop 20 years ago.
Recently started shopping different distros because I’m not comfortable with the direction Ubuntu is going and rather than upgrade my 18.04 when it’s EOL’d, I’m looking at just hopping to something else for my work laptop.
Took hours to get X working with my laptop’s graphics card (though most resources I found online said it wouldn’t work at all, so that was a nice bonus). Not “get accelerated graphics working” just “get X to start”.
Spent another couple hours screwing around trying to get the trackpad working. And not just “get it working to my liking” but get it working at all. Turns out it’s entirely not supported as a lot of modern laptops uses a I2C connection rather than USB/PS2/etc, and there’s just no driver support for that. Never did get that resolved.
A lot of desktop apps that I use are either unavailable or require a lot of dicking around to use at all. There is no Slack desktop client. You cannot run Docker natively, and instead I ended up setting up a Debian guest OS under bhyve, which harkens back to how Docker is run on Windows/OSX and all the caveats that entails.
You’ll pry my FreeBSD servers from my cold dead hands, but it’s certainly not my go-to for a desktop OS.
[+] [-] loudmax|5 years ago|reply
If you're able to get your drivers and all working with FreeBSD then good for you! FreeBSD is awesome and I'm always happy to come across it.
[+] [-] zepearl|5 years ago|reply
I personally feel sad when people state (indirectly) that Linux is NOK because their Ubuntu didn't work well :(
Ubuntu is probably the only Linux distro which I hate => I admit that it's a bit a mixed situation (Ubuntu seems to be a kind of "lighthouse" for the Linux world), but in the end I personally think that it's a pity that it acts as representative of the Linux distros.
I'm currently using Gentoo & Mint & Arch (depends on the usage), and in the past I liked as well at least Fedora and CentOS (not using them since a long time), but I never liked Ubuntu.
[+] [-] na85|5 years ago|reply
Last time I tried (open)BSD, none of those things worked acceptably. The recommended way to connect to wifi was to manually edit wpa_supplicant.conf and battery life was a solid hour less than under linux.
I feel like BSD is a great "laptop OS" if you're the kind of user that leaves their thinkpad plugged in all the time, essentially using it as a small-form factor desktop.
Maybe it's better nowadays.
[+] [-] forinti|5 years ago|reply
It might be my lack of experience with BSD, but I got the impression that it is very hard to get a previous version of a package with BSD.
edit: corrected the name NomadBSD
[+] [-] zelly|5 years ago|reply
[+] [-] darksaints|5 years ago|reply
Does anybody here run postgres on FreeBSD? Any gotchas to look out for? Is performance comparable to linux? Anything to look out for when using NVMe flash drives?
[+] [-] AbacusAvenger|5 years ago|reply
Is that... actually the version number? I thought KDE just used a 3-part version number (major.minor.maintenance or something).
[+] [-] vmsp|5 years ago|reply
[+] [-] vogon_laureate|5 years ago|reply
[+] [-] dijit|5 years ago|reply
It works, they used to have issues with DHCP services, but that would have been linux too. It seems to be resolved now.
[+] [-] trasz|5 years ago|reply
[+] [-] octotoad|5 years ago|reply
[+] [-] blueblob|5 years ago|reply
[+] [-] zepearl|5 years ago|reply
I miss only the "nmon" utility but apparently it's possible to "port" almost any Linux program automatically to FreeBSD Linux apps => I might have a look at that.
[+] [-] gorgoiler|5 years ago|reply
What’s the state of the art for unprivileged containers? I’m very keen on containers that look very similar to the host OS as they make excellent environments for teaching pupils about the OS, especially if the container host can fake them into being “root” in their container.
[+] [-] loeg|5 years ago|reply
I think the gold standard here is hypervisors, and if you want to go that route, Bhyve is satisfactory for many workloads. But jails should be somewhat lighter overhead.
[+] [-] zomg|5 years ago|reply
[+] [-] unknown|5 years ago|reply
[deleted]
[+] [-] colordrops|5 years ago|reply
[+] [-] iso-8859-1|5 years ago|reply
[+] [-] jrumbut|5 years ago|reply