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.
Wish it was the documented way to do that step in the manual.
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
though with that said, i will say that k8s is taking over the world and bsds are going to be left in the dust for my use-case, non-(appliance, embedded, IoT) applications.
Is FreeBSD ever going to be hip and trendy? Probably not, it's not 1994 anymore. But, I don't need a hip amd trendy OS, I need an OS that provides a stable base for me to work upon and supports enough hardware that I can chose decent parts. As a bonus, I've found it easy enough to muck with the internals when it has benefited me or my employer.
It reminds me that in my hometown, opening a communal door of a condo from your flat is called "pulling", because people used to pull a cord to do it when electricity "didn't exist". Nobody has had to pull a cord to open a door in probably 80 years, but everyone there still says "I'll pull it".
I'd pick up FreeBSD in a heartbeat if I knew that the investment in learning the platform would help me be productive in production. But like you said, it's not 1994 anymore and modern deployment and maintenance of an application stack is docker and k8s. A trend where the OS is abstracted away as much as possible. So why invest in FreeBSD? Okay, so maybe it's a nice OS for appliances; though so is Linux and I can continue to leverage my knowledge.
At home I run an appliance and thought I'd deploy FreeBSD on it to run my storage server. I was really excited to deploy ZFS, the BSD killer app. The justification for this getting more difficult to make since ZFS on Linux is production ready.
I want to use FreeBSD. I don't care that it's not mainstream. The unfortunate issue is that it's falling behind in my use-case, by a lot and that's a bummer.
I can only tell you, whatever scary differences you expect between Linux and FreeBSD are probably no more than between any two Linux distros with different packaging systems.
Ten years ago, fresh out of a failed stint at university, I applied for a junior position at a Linux shop. Would nowadays probably be called junior system engineer or so. The night before the interview, I read around a bit in Stevens' TCP/IP Illustrated as well as Design and Implementation of BSD (to calm my nerves). I told them honestly, I had maybe 15 lifetime minutes on a Linux shell. But I started with FreeBSD4.4 and had by then already 8'ish years of experience on general *nix administration.
I'm still there. Pivoted around and upward a couple of times internally. But I still run FreeBSD on my workstation to get things done. And we're still fundamentally a Linux shop.
But the root cause of my career is a friend at university handing me a FreeBSD 4.4 CD. It is a tremendous system if you want to learn about the services a kernel offers to its userland. If you care to make the dive, it not only tells you the what and how, but the why and all the compromises that had to be made along the way. And that understanding is universal.
FreeBSD may be well known as a solid production platform. It's true strength is as the foundation for not only a lifetime of learning, but a lifetime of understanding.
Boot on Linux laptop now looks like:
- power on
- wait for recovery shell
- `zpool import -a`
In all my years I have never observed this on FreeBSD and... as I have said, I expect from FreeBSD to be rock solid and it never dissapointed.
ZoL? I wouldn't be running it on my linux servers for a while. The basic mistakes that they are doing are not something that apriciate from file system that is meant to be as reliable as possible.
The process of booting up looked like hit power button wait for desktop to show up. The "basic mistakes they are doing" are completely a function of your distro not having a way to easily set this up and you not knowing how to use it correctly. As far as I know the only distro that supports zfs on root via its installer is at
You might try it in a virtual machine.
Also, me and hundreds of other people have been booting off of ZFS on Linux for years. Your issue is most likely in your distro's initramfs setup or you must have botched the initramfs config yourself. If you're just used to FreeBSD, just stick to commenting about FreeBSD without maligning other operating systems.
That's an initramfs bug; the initramfs scripts are not actually supplied by the ZoL project. You should file a bug report against your distro's initramfs package.
I've been using this as a server backup solution for over a year, I assure you zol snapshots work, including access via the .zfs directory.
What do you mean by this? I’m using ZoL and snapshots seem to be working fine.
This is imho, the killer feature of zfs, maybe matching only by VMS or DragonflyBSD hammer filesystems. They were/are both better at it (`undo`!) but zfs comes closely.
And it is broken for months now.
This guy speaks without knowing.
I just tried going in my .zfs/snapshot on my CentOS 7 system running kernel 3.10 and ZoL 0.8.3 and it's working. I can list snapshots and cat file off a snapshot.
what the actual f*?
tag name v3.10 (bc1b510b8979ecc322f8d930dde56658967b7355)
tag date 2013-06-30 15:13:42 -0700
By now the CentOS 7 kernel is probably closer to mainline 4.x and 5.x than the original 3.10
otherwise you're just talking about stuff (zfs on gnu/linux) you know little about.
if you use zfs on freebsd then good for you, but that doesn't mean you can spread disinformation about zfs-on-linux.
btw: freebsd dropped its own implementation of zfs and is rebasing onto zfs-on-linux (from 2018: https://lists.freebsd.org/pipermail/freebsd-fs/2018-December...). that's how good zfs-on-linux is.
Are you absolutely sure this isn’t something you’ve misconfigured yourself?
For what it’s worth, I do prefer FreeBSD over Linux but not not for any reasons relating to ZFS.
$ cat /saspool/debian/master-buster/.zfs/snapshot/ci/etc/issue
Debian GNU/Linux 10 \n \l
(Yes my "tank" is named "pool"; /saspool/debian/master-buster is a template for my containers, "ci" is one of the containers.)
sudo zpool --version
Linux xxx 5.6.0-2-amd64 #1 SMP Debian 5.6.14-1 (2020-05-23) x86_64 GNU/Linux
Are you using a distro supplied zfs (potentially old) or rolling something more bleeding edge?
root> zpool --version
root> ll /.zfs/snapshot
drwxrwxrwx 2 root root 2 jun 15 08:48 ./
drwxrwxrwx 1 root root 0 jun 10 07:53 ../
root> cat /etc/yum.repos.d/zfs.repo
name=ZFS on Linux for Fedora $releasever
name=ZFS on Linux for Fedora $releasever - Source
But nevermind, this is something that was working since zfs as root was brought into FreeBSD (and we are talking about FreeBSD not ZoL), never had issues about it.
one is really piece of s*, full of beginner mistakes, lasigna/spaghetti/ravioli mixed in horrible way, done in java, wasting resources like olympic games. But with polished webui, full of colors, nice icons etc.
Second one, c++, with kernel module for linux, driver for windows, really nice and clean code (I was surprised). Not really nice webui but it did do the job well. Passed the benchmarks with flying colors, almost once faster than the first project.
At the end: the first one was a bestseller. There is no technical reason to be better selling, they both were doing the same task, from technical perspective, the second one was far better. Benchmarks, way of doing its work. Just far better. But the worse product with better "colors" won.
Marketing, marketing, marketing. The pestilence of our time and probably the Dark Ages of technology. I doubt I will see the Renaissance.
> A trend where the OS is abstracted away as much as possible.
It seems like you're asking about following trends.
Having said that, we use OS to run things. I feel FreeBSD is lacking there, and despite being incredible, that incredibility seems less attractive. Its hard enough to write things that work correctly in different Linux environments, I'm not sure how much more work would it be in FreeBSD land (hardware drivers, software outside Portage repo, and support) -- specially considering a lot of software is written with Linux (or Win/macOS depending what we are talking about) support first in mind, and anything else is more or less a "checklist" thing.
So from a user perspective, it comes down to -- do I want to spend time tackling software/configuration issues that I'm very likely have if I run this on FreeBSD vs. should I run in a slightly less cleaner OS that just works 99.99% of the time.
And for server deployments, cloud and language runtimes make the underlying OS kind of meaningless, other than for those doing low level performance optimizations.
I am missing an updated version of "The Design and Implementation of the FreeBSD Operating System", though.
I have nothing against linux.
But for mission critical tasks I will choose FreeBSD. I have seen too many times linux distributions (Linus is sane - distributions decisions on the other hand are making me scratch my head just too often) pulling "Crazy Ivan" and I really dislike it.
For FreeBSD I know I wont encounter any nasty suprises and I consider it paramount. And once you encounter some jewels like setfib (https://www.unix.com/man-page/freebsd/1/SETFIB/) you just fall in love <3
> Bruce Evans <bde@FreeBSD.org>
> 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.
"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."
There is some value in suggesting adjacent areas for future work, if authors have time and interest, but BDE went well beyond that.
I think Bruce should be admired for his demonstrated desire to improve FreeBSD, and for his great attention to detail. But I would not like anyone to emulate his code review emails.
Write K&R C and compile to 16-bit for 8086 or 3086.
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.
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.
( edit: referring to https://lists.freebsd.org/pipermail/freebsd-announce/2015-Fe...)
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.
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.
The difference between inittab and the scripts controlling the startup routines are minimal. A person in 2005 could grasp the difference between BSD and Linux init scripts in about an hour.
As for hating systemd, that battle is lost, my friend. There's really no point in even engaging any discussion about it beyond this paragraph. No one is looking to write shell scripts for init in 2020 when there are systemd service files that are simple configs. It's provided by the distro, that's why it's adoptable. No one in the right mind trusts open source project devs to maintain compatibility in even minor version variations, that's why there's a booming container business. Tools that the distro provides work, tools from third parties are on borrowed time until they break, so yes systemd is the only viable up-monitoring solution.
For those following along, and just realizing that RNCTX's opinions are at best ill-informed and ill-founded and who want to learn from a better source, FreeBSD has quite informative manual entries for init(8) and rc(8). You can read about Mewburn rc, as used on FreeBSD, in the doco that is hyperlinked at http://jdebp.uk./FGA/system-5-rc-problems.html . And you can learn what replaced the actual AT&T Unix System 5 init/rc, before Linux even existed at http://jdebp.uk./FGA/unix-service-access-facility.html , http://jdebp.uk./FGA/inittab-getty-is-history.html , and http://jdebp.uk./FGA/run-levels-are-history.html . You can even read how systemd is the very third-party restarter that RNCTX doesn't want dæmons to have in Lennart Poettering's own words at http://0pointer.de/blog/projects/systemd.html .
Nobody wants to replace a simple init system with something with 1.5 million lines of code like systemd. For crying out loud, it’s 2020.
First, there's the error of the false dichotomy that the only two options that exist are van Smoorenburg rc and systemd. That's certainly not true for FreeBSD, which is the headlined topic, and not true on Linux operating systems, either. The Uselessd Guy famously called this false dichotomy out years ago. Moreover, in the Debian Hoo-Hah the choice was primarily amongst OpenRC, Upstart, and systemd; van Smoorenburc rc was acknowledged by all as not even in the running in practical terms, even though it formally was.
Second, FreeBSD has Mewburn rc, and one really cannot apply the same critique to it as to the van Smoorenburg rc for Minix+Linux, in discussions pro or discusssions con. The scripts are vastly different in structure. (Ironically, it is little known that Debian people have local modifications to van Smoorenburg rc, from 2014 back in the time of the Hoo-Hah, that make huge changes to van Smoorenburg rc scripts on Debian, making them structured much more along the lines of how Mewburn rc and OpenRC structure rc scripts.) In Mewburn rc, scripts actually do not mostly consist of generic boilerplate. The generic parts are not in the scripts in the first place, but in a common shell script function library.
I suppose it depends on how you mean that, but I probably disagree; when Greg KH can say, "My tolerance for ZFS is pretty non-existant" , and Torvalds says, "Don't use ZFS. It's that simple. It was always more of a buzzword than anything else, I feel... [the] benchmarks I've seen do not make ZFS look all that great. And as far as I can tell, it has no real maintenance behind it any more..." , we've gone well beyond "they just can't merge it because of licensing" and into "[political] opposition".
> It's not like you're going to convince Oracle to relicence it.
I've always wondered at this, actually; why doesn't Oracle relicense it? BTRFS, AFAIK, was started at Oracle but basically flopped; why on earth do they not simply bring over the far-superior ZFS codebase to replace it? They can't possibly be trying to protect Solaris the way Sun did; they've killed off >90% of the Solaris team  and AFAIK have made exactly zero effort to sell Solaris for years now. Why wouldn't they get ZFS upstreamed into Linux and make it a core feature of OEL (or whatever they were using BTRFS for)?
Honestly, I would assume because Oracle's response to anything charitable or nice is "fuck you"
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.
But from experience of using it extensively in my softwares I can report that it has some warts on FreeBSD. A very quick précis:
* It has problems if one wants to combine NOTE_TRACK, NOTE_FORK, and NOTE_EXIT in EVFILT_PROC, because it returns one event for both a forked child and an exited child, which both try to store different things in the single "data" field of the event.
* Quite a few of the pollable device drivers in FreeBSD are not kevent() enabled. So it mysteriously fails to work with a whole bunch of I/O devices, where (confusingly for diagnosis) polling does. kevent() is not universally usable.
* One might think, from reading the various operating system's manual pages, that only NetBSD and MacOS have EVFILT_FS. In fact, FreeBSD kevent() also has EVFILT_FS. It's just entirely undocumented.
"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
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
Not everybody is running after the last shiny feature. I don't mean that in a condescending way: there is room for all approaches.
Also note that backporting may be unfeasible in some cases I’m guessing because changes to latest llvm/clang may be under the new unacceptable license. Openbsd might need to make their own modifications.
I’m not making a value judgement whether it was good or not to not accept new llvm license. Just making an observation that this is going to be a drag on the project.
> 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.
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).
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.
When it comes to shell script programming, the obvious mechanism has already existed in FreeBSD for quite a while now. It's vis (vis(1), unvis(1), vis(3)). I have an alternative to ps that vis-encodes the fields in its output, and from experience most and possibly all of the well-known and widely-documented (by Greg Wooledge and others) pitfalls that are warned about do indeed go away with simple application of vis encoding.
It does the same on Linux-based operating systems, too, although one has to go and get an unvis tool from somewhere. Yes, the code to read the process table on Linux in the first place does indeed involve decoding human-readable strings from stat files into machine form. (-:
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.
With a stable GPU, the desktop experience is more or less identical to Linux, IMO. (I've been using Linux desktop since the mid 2000s and FreeBSD desktop since mid 2010s.)
My understanding is that the core issue is a lack of support for the linux sandboxing syscalls that chromium (the basis for electron) uses.
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.
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.
Sorry, but OpenBSD and FreeBSD are very different operating systems, it's not just "different distros" like in the Linux world
Whatever you tried in OpenBSD has most likely no relation to FreeBSD
Speaking of the things you mentioned, I personally would expect suspend/resume to just work out of the box in the latest OpenBSD, but not necessary in FreeBSD (it was never a priority for the developers).
You also don't need wpa_supplicant in OpenBSD (unlike FreeBSD), ifconfig should be enough in most cases.
For the battery life, you certainly gonna need some tuning, as it's not a config priority by default, but generally (on mainstream hardware) you should be able to reach at least 80%-sh battery life comparing to Linux in OpenBSD, and comparable to Linux in FreeBSD
Editing wpa_supplicant.conf is rather user-unfriendly, but it's literally a four line copy/paste followed by adjusting two lines of config file; I suppose nobody could be bothered.
join foo wpakey bar
Yeah, see, that's unacceptable to me in a laptop.
I have a small pcengines apu2 running openbsd but I don't enjoy tinkering with it. I find it cumbersome and unwieldy. The documentation seems to be mostly "complete" but it's definitely geared at someone who already has an in-depth understanding of openbsd, and lots of fundamentals are left unsaid, which makes it difficult to learn what the "proper" way to do something is. I end up with a patchwork of hacks and it's very unsatisfying.
It took me quite a long time to figure out how to get wireguard working on that box, for instance, whereas on linux and mac it "just works" pretty much out of the box.
I think you missed the last clause here:
> > comparable to Linux in FreeBSD
Getting freebsd to the level of Linux only after significant tinkering just isn't a good ux. For my personal machine that's unacceptable.
ifconfig $IFACE join $ESSID wpakey $PASS
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
That would be a fun name for the BSD answer to nixos...
Ah, on re-read of the OP comment, it's "wifi issues and freezing", two different problems they had. Have never seen either from GNOME though.
Or just a sane floating one like Fluxbox. Taskbar, systray, window merging by title, Zukitre themes to match the GTK ones and dead simple to setup, with no XML such as the "other one".
This should be a criminal offence
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?
Is that... actually the version number? I thought KDE just used a 3-part version number (major.minor.maintenance or something).
Package names only get longer as you add more layers of maintainers. (For example, package-XubuntuY or package+YYYYmmdd-n was common on Ubuntu, who needed their versions to fit "between" given Debian versions.)
It works, they used to have issues with DHCP services, but that would have been linux too. It seems to be resolved now.
Have to know where to find the AMIs though.  Amazon doesn't make this as easy as they might.
What would you like to see changed?
While we're here: As I implied, I recently got FreeBSD up and running from one of your AMIs. (I was just playing around, not doing anything serious, and I don't know FreeBSD well at all, my experience is with Linux.) Thanks for your work here. I encountered two issues though:
1. It took a long time for the instance to boot up and for port 22 to open. Roughly 14 minutes. This is with a t3a.small instance.
2. I was unable to confirm the SSH public key of the instance. The EC2 custom is for it to be written to the system log, which is viewable from within the EC2 web dashboard, but FreeBSD didn't appear to do this. (This can take a few minutes on Ubuntu and Amazon Linux 2, for whatever reason, but it works eventually.)
Also, and perhaps it's just me that trips over this, but I'd find it helpful if it were made more explicit that the correct username is 'ec2-user'.
I haven't tried out the ARM64 AMIs but it's great you're providing AMIs for both architectures. Amazon seem pretty serious about their ARM instance-types.
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.
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.
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.
You might disagree, but not every software deserves support, they're not playing nice to non-systemd enabled and non-linux operating systems.
FreeBSD is the BSD that supports KDE
or thats how it's been explained to me. So if you want Gnome you should try OpenBSD.
Avoid this. It's as superficial and wrong as classifying people into blondes, brunettes, and redheads. It's not how the BSDs differentiate.
FreeBSD supports KDE, Gnome, i3 and and and.... OpenBSD or FreeBSD don't have a preferred DE, next time check for your self and don't believe in 'explanation's' from some douche-bag.
Gnome is updated to 22.214.171.124, while KDE is on the stale 3.5.10 in OpenBSD
In FreeBSD Gnome is updated to 3.28.2, while KDE is on 126.96.36.199.04.2
The Gnome on FreeBSD is 2 years stale, and KDE on OpenBSD is about 12.