> Apptainer is for running cli applications in immutable, rootless containers.
What's the appeal of using this over unshare + chroot to a mounted tarball with a tmpfs union mount where needed? Saner default configuration? Saner interface to cgroups?
Apptainer, like the vast majority of container solutions for Linux, take advantage of Linux namespaces. Which is a lot more robust and flexible then simple chroot.
In Linux (docker, podman, lxc, apptainer, etc) containers are produced by combining underlying Linux features in different way. All of them use Linux namespaces.
When using docker/podman/apptainer you can pick and choose when and how to use namespaces. Like I can use just use the 'mount' namespace to create a unique view of file systems, but not use the 'process', 'networking', and 'user' namespaces so that the container shares all of those things with the host OS.
For example when using podman the default is to use the networking namespace so it gets its own IP address. When you are using rootless (unprivileged) mode it will use "usermode network" in the form of slirp4netns. This is good enough for most things, but it is limited and slow.
Well I can turn that off. So that applications running in a podman container share the networking with the host OS. I do this for things like 'syncthing' so that the container version of that runs with the same performance as non-containered services without having to require special permissions for setting up rootful network (ie: macvlans or linux bridges with veth devices, etc)
)
By default apptainer just uses mount and user namespaces. But it can take advantage of more Linux isolation features if you want it to.
So the process ids, networking, and the rest of it is shared with the host OS.
The mount namespace is like chroot on steroids. It is relatively trivial to break out of chroot jails. In fact it can happen accidentally.
And it makes it easier to take adavantage of container image formats (like apptainer's SIF or more traditional OCI containers)
This is Linux's approach as opposed to the BSD one of BSD Jails were the traditional limited Chroot feature was enhanced to make it robust.
I'm aware of all of this, it might not be clear if you've not used it directly yourself, but unshare(1) is your shell interface to namespaces. You still need to use a chroot if you want the namespace to look like a normal system. Just try it without chrooting:
unshare --mount -- /bin/bash
> It is relatively trivial to break out of chroot jails. In fact it can happen accidentally.
Usability, for one. I know how to `apptainer run ...`. I don't know how to do what you're describing, and I'd say I'm more Linux savvy than most HPC users.
Engineers like to work from the bottom up because nature isn't made out of straight lines and regularity. Breaking things apart into abstractions works to a certain point, then the natural irregularity of reality steps in and you need to be able to react to that and adjust your foundation. So yes, fundamentally it is about thermodynamic knock-on-effects of handling things from the top-down.
Messing around with lisp and smalltalk environments is fun. But the moment you have to stick your hand beneath the surface, you can very quickly end up in someone else's overengineering hell. Most serious GNU Emacs users shudder at the thought of hitting Doom Emacs with a wrench until it suits their tastes. It's universally agreed that building your Emacs environment up from the defaults is fundamentally a wiser choice. Now realize that a full Lisp operating system is several orders of magnitude more complex than Doom Emacs, and most things you're going to program emacs to do are absolutely trivial in comparison to most industrial-grade application logic.
> That's simply a reality, just as weavers saw massive layoffs in the wake of the automated loom, or scribes lost work after the printing press, or human calculators became pointless after high-precision calculators became commonplace.
See, this is the kind of conception of a programmer I find completely befuddling. Programming isn't like those jobs at all. There's a reason people who are overly attached to code and see their job as "writing code" are pejoratively called "code monkeys." Did CAD kill the engineer? No. It didn't. The idea is ridiculous.
I'm sure you understand the analogy was about automation and reduction in workforce, and that each of these professions have both commonalities and differences. You should assume good faith and interpret comments on Hacker News in the best reasonable light.
> There's a reason people who are overly attached to code and see their job as "writing code" are pejoratively called "code monkeys."
Strange. My experience is that "code monkeys" don't give a crap about the quality of their code or its impact with regards to the product, which is why they remain programmers and don't move on to roles which incorporate management or product responsibilities. Actually, the people who are "overly attached to code" tend to be computer scientists who are deeply interested in computation and its expression.
> Did CAD kill the engineer? No. It didn't. The idea is ridiculous.
Of course not. It led to a reduction in draftsmen, as now draftsmen can work more quickly and engineers can take on work that used to be done by draftsmen. The US Bureau of Labor Statistics states[0]:
Expected employment decreases will be driven by the use of computer-aided design (CAD) and building information modeling (BIM) technologies. These technologies increase drafter productivity and allow engineers and architects to perform many tasks that used to be done by drafters.
Similarly, the other professions I mentioned were absorbed into higher-level professions. It has been stated many times that the future focus of software engineers will be less about programming and more about product design and management.
I saw this a decade ago at the start of my professional career and from the start have been product and design focused, using code as a tool to get things done. That is not to say that I don't care deeply about computer science, I find coding and product development to each be incredibly creatively rewarding, and I find that a comprehensive understanding of each unlocks an entirely new way to see and act on the world.
My father in law was a draftsman. Lost his job when the defense industry contracted in the '90s. When he was looking for a new job everything required CAD which he had no experience in (he also had a learning disability, it made learning CAD hard).
He couldn't land a job that paid more than minimum wage after that.
Wow, that's a sad story. It really sucks to spend your life mastering a craft and suddenly find it obsolete and your best years behind you. My heart goes out to your father.
This is a phenomenon that seems to be experienced more and more frequently as the industrial revolution continues... The craft of drafting goes back to 2000 B.C.[0] and while techniques and requirements gradually changed over thousands of years, the digital revolution suddenly changed a ton of things all at once in drafting and many other crafts. This created a literacy gap many never recovered from.
I wonder if we'll see a similar split here with engineers and developers regarding agentic and LLM literacy.
> Actually, the people who are "overly attached to code" tend to be computer scientists who are deeply interested in computation and its expression.
What academics are you rubbing shoulders with? Every single computer scientist I have ever met has projects where every increment in the major version goes like:
"I was really happy with my experimental kernel, but then I thought it might be nice to have hotpatching, so I abandoned the old codebase and started over from scratch."
The more novel and cutting edge the work you do is, the more harmful legacy code becomes.
"I saw this a decade ago at the start of my professional career and from the start have been product and design focused"
I have similar view of the future as you do. But I'm just curious what the quoted text here means in practice. Did you go into product management instead of software engineer for example?
Purity has nothing to do with functional programming.
> It is also not a list based language, but a tree based one.
It's not called Trep, it's called Lisp. Yes, you can represent trees as lists embedded in lists, and the cons cell allows that thanks to type recursion. But it's still based around lists. Trees don't allow cycles, lists formed from ordered pairs do. Every single piece of literature written by McCarthy talks about lists[1].
> The fundamental point of lisps is that you can manipulate the abstract syntax tree directly
Macros weren't introduced until 1963[2]. They might be the reason you use a Lisp, and they may have become synonymous with Lisp after 1.5, but they are not a "fundamental point" of Lisp. The fundamental point was always about lambda calculus[1].
From even before Lisp was implemented for the first time, MacCarthy envisioned it as a langauge for symbolic processing: manipulating representations of formulas, exhibiting nesting. So yes, it was actually tree processing, using lists.
When Lisp was implemented for the first time, the evaluation semantics was already expressed as operations on a tree.
Datalog is simpler, not turing complete , and IIRC uses forward chaining which has knock-on effects in its performance and memory characteristics. Huge search spaces that a trivial in Prolog are impossible to represent in Datalog because it eats too much memory.
Datalog is a commuter car with a CVT. Prolog is an F1 car. Basically, it's not about improvement. It's about lobotomizing Prolog into something people won't blow their legs off with. Something that's also much easier to implement and embed in another application (though Prologs can be very easy to embed.)
If you're used to Prolog, you'll mostly just find Datalog to be claustrophobic. No call/3? No term/goal expansion? Datalog is basically designed to pull out the LCD featureset of Prolog for use as an interactive database search.
It's easier to write fast Datalog code but the ceiling is also way lower. Prolog can be written in a way to allow for concurrency, but that's an intermediate level task that requires understanding of your implementation. Guarded Horn Clauses and their derived languages[2] were developed to formalize some of that, but Japanese advancements over Prolog are extremely esoteric. Prolog performance really depends on the programmer and the implementation being used and where it's being used. Prolog, like a Lisp, can be used to generate native machine code from a DSL at compile-time.
If you understand how the underlying implementation of your Prolog works, and how to write code with the grain of your implementation, it's absolutely "fast enough". Unfortunately, that requires years of writing Prolog code with a single implementation. There's a lot of work on optimizing[3][4] prolog compilers out there, as well as some proprietary examples[5].
Is light slow? Or is the human perception of time just scaled down as a result of our rapid metabolism and infinitesimality? People historically mistake plants for being inanimate things with no reactivity, that they are far more simple and stupid than they truly are. Outside of a few exotic examples, plants simply operate on a wider timescale that's basically imperceptible without careful and particular observation. It becomes much more apparent how alive plants are when we observe them in a time-lapse. Now realize that plants are still relatively short-lived. The absolute oldest ones only go back to the early neolithic, that's only 14000 years or so. 1000 years is a long time for humans, but probably not for the trees where a single one can live 10x that.
From the hypothetical perspective of a star, with a lifespan measured in billions upon billions of years, the entire ecoscape of the world changes in a blink. From the sun's perspective, MENA was green just a very short while ago. Hell, Pangea wasn't that long ago. At this timescale, continental drift would be as apparent as the movement of boats are to humans. Anything that's working at the cosmic scale where the seemingly low speed of light sounds exhausting is most definitely working at this stellar perspective at the minimum. 14000 years of travel might as well be the equivalent of a 10 minute commute to the store.
Light is comparatively and objectively slow in comparison to the distances that exist. Andromeda is 1M light years from us. From that perspective, 300k kph is oddly slow actually. I love the passion that you're brining to the table though. It reminded me of the blue giant stars whose lifespans can be as short as tens of millions of years, more often hundreds though. For billions upon billions, I suppose that would be white and brown dwarfs. Although, if we could orbit black holes and harness the energy of gravity, then we're really talking long time scales. Cracking the aging problem would allow us to think in very long timescales. But I do wonder whether the human psyche could handle such long lifespans.
This leaves out the time component. Who's to say that a year is long? A galaxy a million light years away takes a million years to reach... and maybe that's a short amount of time, to the right observer.
Light could only go to Andromeda and back 1000 times before the sun burns out. That's not very many times IMO. On the scale of galaxies, light is slow relative to any timescale relevant to large objects.
Tangentially, I've long wondered about sci fi like Star Trek. Namely, even with FTL, how large can your interplanetary alliance be? How far away can the parliament be? Over what distances can you defend against common enemies? Trade? Culturally exchange ideas?
I have had similar thoughts as well. Assuming FTL isn’t possible, at some point it wouldn’t make sense to have a cohesive system. Say, there’s an outpost that is 30 years away by the fastest spacecraft.
There's a great video is saw. In 30 minutes it goes through the entire lifespan of the universe.
Even after all the stars die, the white dwarfs will continue to glow. And after eons, the last black holes will evaporate. The point is that the age of stars is only a tiny fraction of the lifetime of the universe. Maybe the speed of light makes sense at that scale.
But... I'm not happy with that theory. In a relatively short amount of time the expansion of the universe will increase faster then the speed of light. Which means it will be impossible to ever get information from the other side of the universe.
I find it very unreasonable that the universe imposes a speed limit on everything and then completely ignores it.
In addition to the insight, it reminded me to water a plant at a desk I no longer use. The plant's been with me through quite a bit and I have been neglecting it recently as I no longer see it regularly.
For very philosophical writings about this, read "Last and First Men" and "Star Maker" by Olaf Stapledon. Written in the 1930's, these describe on a very expansive scale the history of, respectively, humanity and the universe. Very mind bending.
yeah light _is_ actually pretty slow and we hit that in networking and optics pretty often if iirc.
like not even on a human level, universally even on a grand scale the speed of light is almost torturously slow, there’s nothing philosophical about it
Chances are that only a species who, through one way or another, has become very uninterested in warfare could have advanced to the point where they would be able to run such a simulation, otherwise they'd have ended their own existence with their shiny toys before long.
War only occurs if you have in the literal sense retarded elements in your advanced species and is nonsensical from an outside POV. A species this advanced would have fixed such shortcomings in itself long ago.
So no, I don't think they'd necessarily be very interested in watching primitive species go to war with primitive weapons.
For all we know the simulation of this universe is happening in their equivalent of an overengineered snow globe, us being an artifact nobody has noticed and that nobody would find particularly interesting if they did notice.
> Is light slow? Or is the human perception of time just scaled down as a result of our rapid metabolism and infinitesimality?
It's slow for humans to explore the cosmos.
"Slow" is meaningless without a frame of reference, and "humans" seems like a good frame of reference, since it's us -- and not plants or stars -- who are writing on HN to discuss this.
Because it's us, humans discussing this in HN, the frame of reference is implied and it's not necessary to spell it out.
That’s one of the answers to how you could go to the stars: go sloooooow as in slow down your cognition and metabolism so the trip doesn’t take long.
Ents could fly to the stars no problem.
Makes me wonder if there might not be a bunch of star faring “slow life” out there that we don’t notice for the same reason a hummingbird doesn’t notice trees growing.
Such an interesting perspective! It would be nice to see evolution sped up as well, or any process that seems unchanging for less than a few thousands of years.
At the moment humans only live ~90 years which is a blip in cosmic terms, but shortly we should be able to merge with AI and live for billions of years and visit stars.
Can someone who uses FreeBSD fill me in on the niche that it fills in the Unix space? Why not use OpenBSD or NetBSD, which are far simpler and coherent? If the answer is support for stuff like ZFS, Nvidia drivers, ELF, etc. why not Linux? I'm well aware of the problems with GNU, but do you have problems even with something like Musl Void?
I'm genuinely actually curious. FreeBSD exists in kind of a shadow realm for me where I've never been quite able to pin down the soul that keeps it chugging, but I know it exists somewhere in there.
I have worked for financial services companies that used FreeBSD both in EC2 and on the metal in data centers (self managed).
The two features we used all the time were zfs and jails.
Each service ran in its own jail for isolation. One (not even beefy) server could run all the services which was insanely cost efficient.
A cloud migration was undertaken at some point to have a hybrid setup, using a mix of Linux (k8s) and FreeBSD, and costs skyrocketed. It’s a trade off because in the data center we had to buy and replace our own disks, react to fires taking place, being only in one country etc.
AWS gives you multi region, and tons of good stuff, and that has a price.
ZFS was not leveraged that much but it saved our beacon once when a table in the production database was accidentally dropped and we could instantly rollback to the previous zfs snapshot (there was a tiny bit of data loss as a result but this did not matter too much for this application - uptime was more important). ZFS was also used for backups I believe.
A few times I used dtrace in production to troubleshoot.
When we introduced Linux to our fleet of FreeBSD servers, every team picked a different distro organically so it was a bit of a zoo. With FreeBSD on the server you only have the one variant.
I still use and like both, but I must say I really like that FreeBSD is a kernel+OS integrated together.
It really makes sense to think of different Linux distros as different operating systems. At the very least, the ones from different "families".
There are a lot of differences between Debian and RHEL. Suse, Alpine, Void, or Chimera Linux are completely different again. In some ways, they are almost as different from each other as FreeBSD is from them.
Compared to that "zoo", using FreeBSD everywhere is far more cohesive. But if you use RHEL, Alma, Rocky, and even Fedora, things are still going to feel pretty consistent. Or Debian, LMDE, and Kali. I am not advocating an ecosystem.
> Can someone who uses FreeBSD fill me in on the niche that it fills in the Unix space? Why not use OpenBSD or NetBSD, which are far simpler and coherent? If the answer is support for stuff like ZFS, Nvidia drivers, ELF, etc. why not Linux?
My experience with FreeBSD is that it provides a nice balance of the concerns OpenBSD and NetBSD specifically address. Historically, FreeBSD prioritized Intel CPU's (where NetBSD had greater portability) and had solid security (where OpenBSD had more of a focus on it).
The FreeBSD ZFS support really is a game changer. I believe Nvidia only recently has had native FreeBSD drivers - for a long time FreeBSD's kernel Linux support was required.
> I'm genuinely actually curious. FreeBSD exists in kind of a shadow realm for me where I've never been quite able to pin down the soul that keeps it chugging, but I know it exists somewhere in there.
Again, for me, FreeBSD has proven to be a nice blend of the features other BSD's provide as well as being incredibly stable on the h/w platforms I tend to use.
I figured the goldilocks metric might factor in. Are you dealing with non-x86 platforms? I've always been disappointed by the ARM experience on Linux. It always feels second-class.
FreeBSD is throughput oriented in a way that OpenBSD certainly isn't, and I don't think NetBSD is either (although, I haven't really looked, I feel like NetBSD competes on portability and doesn't spend a lot of time making sure networking throughput is high).
All of the BSDs tend to have a lot less churn, for better and worse; so IMHO, they make a nicer platform to integrate on.
If you want a high profile example, look at what Netflix CDN does.
Could you do that work with Linux? Probably --- but nobody who does is talking about it as much.
This kind of high throughput service has been a FreeBSD niche since forever too. Walnut Creek CDROM, Inc ran what was reportedly the world's busiest ftp site, ftp.cdrom.com on FreeBSD in the early days of the internet.
Yahoo ran on FreeBSD (I worked there 2004-2011) WhatsApp ran on FreeBSD (I worked there 2011-2019) Both were leaving FreeBSD when I left, but sadly, I didn't leave to work somewhere else with FreeBSD :p
Also checkout DragonflyBSD. They, at least at one time, where gunning for the HPC use case.I don't keep up with it enough to know the current state today, to know if they are still hard charging in that direction since they forked from FreeBSD years and years ago.
> As to why not Linux? I don't want Linux. It's too bogged down by corporate interests.
This is a rather funny statement because at various points, high level execs at Apple Computer (and on another occasion Sun Micro) invited Linus Torvalds out to lunch and pitched teaming up together to take on Microsoft. Linus turned them down.
Then a little bit later Jordan Hubbard announces FreeBSD would be the UNIX layer of OS X.
> Then a little bit later Jordan Hubbard announces FreeBSD would be the UNIX layer of OS X.
But it's not. It's NeXTStep. They took a little bit of userland but that's about it. A lot of it is not even freebsd-specific like zsh and bash (the ancient version apple ships)
I wonder if more was planned at first. Similar to when Jonathan Schwartz proudly announced ZFS being part of macOS but it only ever made it to a beta and was removed again.
Only if you very carefully select hardware to match, and I mean very carefully because the range of supported hardware is smaller than Linux. I've tried to install FreeBSD on my laptop recently after a long hiatus and was unpleasantly surprised that, apparently, even Intel wireless chipsets have rather poor support.
My impression is that FreeBSD is Apple's shadow in FOSS, they hold a lot of soft power over it. I know the kernels are different and obviously only part of the userspace is the same, but is FreeBSD actually far enough away from Apple to say it's not bogged down by corporate interests? I don't imagine it's the same as Linux at all, but it exists in a non-trivial way, no?
It's not. Apple (or rather NeXT) took some of the userland for macOS but it's not contributing back and it doesn't have much influence. It's more like a fork a long time ago.
A few companies do. Skype and Netflix did but hardly use it now (at least Skype left it, not sure about Netflix but I never hear about it from bsd devs). Ix systems and netgate do but they're tiny.. No, it's not influenced in a trivial way and certainly not by apple.
This is a huge difference to Linux where the vast majority of kernel commits come from big tech and have nothing to do with things end users care about. Also there's nothing in the FreeBSD world like the Linux Foundation which is basically a corporate lobby group.
> but it's not contributing back and it doesn't have much influence.
I understand the former. But with how Apple operates, it's really hard to believe they'd pull downstream from something they don't have some kind of soft power over. They do still pull downstream AFAIK? Maybe that's changed?
>Ix systems
I did some reading and saw a FreeBSD contributor ended up going to Apple until 2013 before he founded this company.
https://www.ixsystems.com/clients/
Apple is listed here. Six degrees of separation and all, but probably not a coincidence.
Nothing wrong with that, business is a social structure. This is how they work. We make and keep friends, even if only professionally. Backchannels are where real deals are made.
But this to me is not nothing. No corporate influence means there's a lot of nice things you don't get. You just can't afford the manpower. It looks more like 9 Front than a BSD that has some serious billion-dollar problems under its belt.
That sounds harsh, not a judgement. Just very deep skepticism of the assertion of no influence. I'm realizing there's not a lot that can be done to sway that intentionally.
> This is a huge difference to Linux
This I'm well aware of. I just like having a perspective across the fence. These days they're starting to get a little too aggressive for my tastes. FreeBSD seems fine in comparison.
> But with how Apple operates, it's really hard to believe they'd pull downstream from something they don't have some kind of soft power over. They do still pull downstream AFAIK? Maybe that's changed?
Apple doesn't merge often. They basically haven't merged kernel tcp since 2002. When I started using OSX in 2011, they hadn't merged userland for several years, and when I stopped in 2019, they had only merged once.
They famously stopped picking up bash when upstream changed the license, and most of the FreeBSD userland doesn't change that frequently, so most things you wouldn't notice a difference. cal(1) started highlighting the current day at some point, tar probably grew new compresion arguments, etc.
Apple certainly was a major contributor/driving force/etc of LLVM for a while, not sure if they still are? And LLVM was adopted by FreeBSD, so maybe that's where this idea is coming from?
> And LLVM was adopted by FreeBSD, so maybe that's where this idea is coming from?
Partially, but after seeing the Jordan Hubbard connection, there's a lot of layers to this. May have reinforced my biases, but it's definitely non-trivial according to my hippie-tier anarchist baseline. Oops. Worst case scenario of answering your own question.
But your reply does give me actually contradicting evidence. It wouldn't surprise me that distance has grown to the point of total atrophy, given the general trajectory Apple has been on since 2012 or so. This is why I ask these questions, because the people on the ground give the most informative answers.
As Ptahhotep advises circa ~2300BCE:
> Fine words are more sought after than greenstone, but can be found with the women at the grindstone.
> May have reinforced my biases, but it's definitely non-trivial according to my hippie-tier anarchist baseline.
The definition of 'trivial' would come into play yes. I would only consider it non-trivial if a commercial party can (and does) influence the direction of development. I don't think Apple does so. Even Netflix. In the Linux world there's billions of investment and many contributors are directly employed by big business. The waters are much murkier there.
Again, I'm not saying it's a bad thing. It's just not something I want which is one of the reasons I picked FreeBSD. Other reasons were the great ports collection, the division between OS and apps (you can have rolling apps but a stable OS), the traditionalism (only change things if it's really needed) and the single main flavour of the OS which makes support much easier. Also the excellent documentation.
> No corporate influence means there's a lot of nice things you don't get.
Yes that is the flipside. But I don't mind that. If you choose your hardware carefully it works fine.
Note that this is not too different from using Windows or Mac. Your hardware is also chosen carefully to work with those, just not by you but by the vendor. With FreeBSD you're more involved with the nuts & bolts and this is exactly what I want. I don't want my OS to be a black box I don't understand.
They use it and influence its development. You can search freebsd git repo, you'll see Netflix all over it for many years Including 2025. They've added many large features across the code base.
> My impression is that FreeBSD is Apple's shadow in FOSS, they hold a lot of soft power over it.
Apple has no influence over the FreeBSD project.
> I know the kernels are different and obviously only part of the userspace is the same, but is FreeBSD actually far enough away from Apple to say it's not bogged down by corporate interests?
Yes.
OS-X (now macOS) is based on XNU[0], which itself has roots in the Mach[1] microkernel. The Unix user-space programs distributed with OS-X/macOS are those found in FreeBSD distributions AFAIK. This is also conformant with FreeBSD licenses for same.
So there is no "soft power" Apple has over FreeBSD. And FreeBSD is not "Apple's shadow in FOSS".
> I don't imagine it's the same as Linux at all, but it exists in a non-trivial way, no?
No. It does not.
EDIT: Just in case you'd like to verify any of the above yourself, see here[2].
I'm not sure where you're getting the "Apple holds soft power over FreeBSD" thing from. Netflix is probably at the top of the list given all their performance and stability work -- and, you know, the fact they push a large chunk of all Internet traffic using FreeBSD -- and NetApp and Juniper are somewhere up there, but I'm not convinced Apple would even be in the top 10.
> I'm not sure where you're getting the "Apple holds soft power over FreeBSD" thing from.
The only thing I've ever heard from FreeBSD-land, not paying attention to users, but the maintainers and the tools. Apple comes up. In the same manner that RedHat and others come up for Linux. How to explain? It's an abstract pattern. Transparent, understandable.
I mentioned somewhere about the connection through ix systems. And honestly to project, if I was a maintainer of something used between Netflix and Apple, I'd prioritize Apple. Apple has outlived IBM. If you know your history, you know how serious that is. If you've got authority over something as large as FreeBSD? Yeah, you don't ignore that kind of actual power especially when it's personal. Like I say, all based on guesses. But some things are hard to mistake.
Apple did very important work making LLVM happen, but that was a long time ago. At this point there are lots of companies involved in that project.
As far as "power" is concerned... speaking as release engineer, I don't give special treatment to anyone; nor have I even been asked to. If anyone has a special relationship it's Netflix but if anything that's the opposite way around: "Can you please throw 10% of all Internet traffic at this TCP stack patch and let us know if anything breaks" is a thing. They're incredibly helpful with Q/A.
Consider me convinced. Like I say, it was never anything but empirical skepticism. Neither for or against until sufficient evidence has been collected, as painful as that can be. Thank you for your work on scrypt.
Just to give another data point. LLVM is a good example. Where FreeBSD and Apple may still interface quiet a bit, and this isn't exclusive to FreeBSD, I think Apple is still a primary contributor/maintainer of CUPS and a few other systems like that.
I know some maintainers of the userland and apple never comes up. Most maintainers have no commercial ties to anyone so they don't really care abour corporate influence anyway. They just maintain the software because they like using it. This is exactly the kind of thing I like, in Linux there are too many companies putting money into it because they want to make money back (usually not from normal users but from cloud instances, steering the project in a direction away from its grassroots origins).
I'm sure if Apple wants something it would be considered but there would be a strong validation of "what's in it for us" on the freebsd side. There's also some pretty bad experiences with corporate influence and this is reviewed a lot more independently since the netgate wireguard disaster. https://arstechnica.com/gadgets/2021/03/buffer-overruns-lice...
Unlike in the Linux world where RedHat and canonical are so embedded due to most of the devs working for them that there will be a lot less questions. And not just those two, also companies like Huawei are heavy kernel contributors.
I'm not saying it's bad to have such commercial influence. But it's not what I want for the OS I run.
First, FreeBSD is probably the most common BSD you'd run into. Definitely has the largest user base. And of course, large user base, more developers, and usually more ports maintainers. Not always true, but true most of the time. FreeBSD has also usually focused on the server case, so a lot of the improvements are improvements where servers will see the most benefit. That sorta explains the, why FreeBSD over OpenBSD and NetBSD. I personally prefer NetBSD, but there is a solid argument for FreeBSD.
Why FreeBSD over Linux? To me, I would say it depends on what sort of engineering model you think works best. Linux is great, but it is essentially a giant orgy of a lot of independent projects that luckily work together to create a linux-based operating system. The kernel team is different from the gnu team that works on gnu libc and gnu core utils. Even with Rust core utils becoming a thing, it's still a separate team. Linux doesn't have a true notion of a 'base' system like the BSDs do. Each of the BSDs provide a 'true base' system. That means pretty much all of the code (maybe a few exceptions), but the core hot code on a freshly installed FreeBSD operating system is all owned and maintained by the FreeBSD team (this applies to NetBSD and OpenBSD and DragonflyBSD). This is the libc, the kernel, the user land utilities, basic programs and even some advanced ones (like OpenBSD's httpd or firewalls), and even the boot loaders! So it provides some sort of coherence to the platform that just isn't on linux.
Linux, and I use that a lot to, is really an amazing anomaly in software. That in the most minimal distribution, you really have tons of software from teams that may have little to no interaction with each other, can some how all be compiled together to work.
Addition: Wanted to make an addition to the difference in engineering decisions. The BSDs in general make clear distinctions between what is provided by the system and what is from third parties. An example of this is reading through some of the file system hierarchy stuff in FreeBSD. Yes, Linux technically has a file system hierarchy and things are supposed to have a designated place, but it's much more Wild West on linux. FreeBSD and the FreeBSD community generally conform to the standards defined in `hier` pretty well.
For me, who's daily driven FreeBSD in the past, and switched back to it again recently. FreeBSD serves as a refuge from systemd, and the only BSD that is a fairly drop in replacement for linux in terms of software compatibility, as well as the only game in BSD town in terms of support for modern hardware.(though it does significantly lag Linux in this regard still, so YMMV).
As to why I use it over the various systemd free linux distros? Well, there's a couple things. First lot of those distros, like Artix linux say, actually have smaller communities than FreeBSD(I'm guesstimating based on the activity level in their irc channels). The Linux community might be much, much larger than the FreeBSD community, but it's also extremely fragmented.
triggerwarning, hyperbole incoming. Don't bother correcting me, it's a polemic, not a scientific paper
Secondly, for someone like me, who's been using various unix like OSes for two decades, FreeBSD is just a nice, batteries included, well integrated system. Things like jails, Dtrace, ZFS, Bhyve, pf etc. All being in the base install means they're just better integrated with the kernel, and eachother. Most of those things exist for linux, or have equivalents, but they're not all part of the same project. Obviously Dtrace and ZFS originated in Solaris, but they've been made first-class citizens. There's a harmony to FreeBSD that Linux distros lack. Documentation is also very good, all accessible via manpages(no GNU INFO...). And, as I mentioned briefly before. It doesn't have a lot of the cruft that's been added to linux distros over the years(though some of it is available in ports if you want it). In FreeBSD, my experience is actually useful. Things I remember how to do from 5 years ago, 10 years ago, 15 years ago, still work. If I'm on some modern, plug and play linux distro, I have no idea what's going on under the hood any more. All I know is it's not what was going on 5 years ago, which isn't what was going on 10 years ago, which isn't what was going on 15 years ago. The amount of pointless churn going on in the linux space is ridiculous. When I started using linux, what I loved about it was that it was transparent. I could change anything. The system was easy to understand. Yes, it was janky, but it was understandable jank, whereas Windows was janky in an opaque way. 20 years later, Linux is still janky, but nothing is understandable, at least not to my greybeard brain. Systemd takes over a new daemon every distro upgrade. DNS resolving now involves 4 different daemons with 15 different configuration files, there's two display protocols, both broken in different ways, /etc is full of long files written in strange, alien languages, and every file has its own bespoke language. There seems to be 54 different ways to make any change to your system, and all of them are somehow unsatisfactory in a unique way. I just can't, anymore. Enough already.
The mains issues with Linux is it’s just the kernel, and anything is developed in their corner without taking account of the rest. Also, I tend to think the Linux folk in general seem to want to reinvent the wheel every 6 months, where FreeBSD and BSD in general have tendency to make things better from previous work in comparison
Yes I know, but maybe my initial message wasn’t clear enough.
But for me the fact Linux is just the kernel doesn’t make the previous criticisms invalid. The first concerning the development of the different components in sort of echo chamber where no one seem to communicate with each other is directly taken from the Linux Kernel philosophy, the maintainer have expressed in multiple time they don’t care what happen outside of the kernel, in contrast with FreeBSD developers for example
The second point is more towards distribution I admit
To make my long-winded point more concretely, the core diference is really just that there are "so many" Linux developers.
Linus has a pretty firm hand on the tiller of Linux evolution. I counter "don't care what happen outside of the kernel" with his many, many public "never, ever break userland" rants. And many kernel devs and maintainers are employees of companies like Intel, Red Hat, Google, IBM, and AMD that absolutely care about coordinating kernel dev with the bigger picture.
Something like 250 devs contribute to FreeBSD each year. For just the Linux kernel, the number is closer to 5000. There are just way more people working on way more stuff. It is not a surprise to see a more significant halo of chaos around Linux. Coordinating the Linux kernel is herding cats and, even when everybody eventually lines up, there are going to be periods where it seems like everybody is talking past each other.
And while the Linux kernel does have a "release early, release often" mantra, it also touts "trust but verify" and has a strong meritocracy and hierarchy. So I am not sure "no one seem to communicate with each other" is fair. Not just anybody can drop whatever they want into Linux. We also need to remember that shipping the Linux kernel is not the same as shipping a Linux distro (operating system). Actual Linux distros bring kernel versions in according to the philosophy of the distro. Many are very stable and conservative. Others are a whole lot less so (but that is users choice).
Isn't this more telling though? that with vastly less developers they've built a system comparable to linux? This is what happens when you have direction.
"The mains issues with Linux is it’s just the kernel, and anything is developed in their corner without taking account of the rest."
I hear this a lot when people talk about FreeBSD but I am not sure about it.
A LOT of the core Linux ecosystem comes from Red Hat developers for example. If I look at RHEL as an operating system, they have a definite vision for the OS, they take a long-term view, and they invest in development to get it there. My guess is that Red Hat alone employs more devs than work on FreeBSD.
Red Hat contributes heavily to the kernel, the core C library (glibc), the userland (GNU utils), the system supervisor (systemd), the compiler (GCC), the desktop environment (GNOME), the GUI framework (Wayland now, Mesa, etc), the sound system (pipewire), the hypervisor system (KVM, libvirt), and the container system (podman and Flatpak). Red Hat heavily influences the direction of all this stuff with a common vision and they work to implement it as a cohesive expression in their distro. This is a broader swath of what makes the operating system than FreeBSD considers its scope and it is all built to work together.
If you use RHEL, you know it is very stable (static). When Red Hat makes changes, they tell you about them years in advance.
I honestly do not think you can say that FreeBSD is more cohesively developed or better documented than RHEL. FreeBSD arguably has less control over key aspects of the OS than Red Hat does.
I am not advocating for Red Hat here by the way. I am not even a RHEL user. I use Chimera Linux which rejects quite a lot of the Red Hat vision including SystemD and pretty much the whole GNU system (userland, glibc, gcc).
My point is that Red Hat is truly a maker of their own destiny and their distro reflects their vision. They want to move to SystemD. They introduced DRM and KMS instead of the traditional Xorg driver model. They want to move to Wayland. They have heavily embraced the OCI container model. It is all part of their vision and design.
Pragmatically, FreeBSD has to create tools like Linuxulator. FreeBSD is adding support for OCI containers. FreeBSD is adding Wayland support and, as popular desktop environments abandon X11, may have to move to Wayland as the preferred display server. Even the FreeBSD utils have added many options over the years to be compatible with the userland that Red Hat developed. Was 'ls --color=auto' a FreeBSD design? In other words, the Red Hat agenda drives the evolution of FreeBSD (but not much the other way around).
So sure, FreeBSD is more stable and cohesive than the universe of Linux distros. But even BSD has fragmentation. GhostBSD is close to FreeBSD but not quite and would be more different if they had more devs. DragonFly BSD certainly has its own agenda (and again, is held back more by bandwidth than solidarity). The free-for-all in the Linux world is an expression of its size and collective innovation. But how much of this you want as a user is up to you. As many have said, you don't use "Linux", you use a Linux distro.
Again, my main distro is Chimera Linux. The whole point of the name is that it pulls together things never designed to work together (including the FreeBSD userland on Linux). And yet, the Chimera Linux dev team has a very strong vision of what they want their OS to look like and they work very hard to build that into a cohesive implementation. This includes keeping the system and the code small and understandable. It is a goal that you can sanely build the entire system from the ground up. That is why Chimera uses a BSD userland and does not use SystemD. But while they want to keep things simple, they also want "modern" features.
They choose components that fit their vision. Where changes are required, they make them. Where they deem good options not to exist, they invent them (eg. Turnstile, cports). As a user, I get that "solid, cohesive, well-designed, intentional, and heavily curated" experience that FreeBSD users talk about. More to the comment above, Chimera reeks of "looking to preserve tradition while striving to make things better". Of course, it is also still a niche distro with a tiny community (at this point). As somebody said above, FreeBSD may be a better choice for this and other reasons. But Chimera Linux is still Linux and that has its advantages. The box I am typing on uses bcachefs and Distrobox. For me, it is perfect.
Anyway, I apologies for the length. When you talk about FreeBSD vs "Linux", you really have to choose a specific Linux distro for the comparison to be meaningful. Depending on which one you pick, the statements made by @MrArthegnor may or may not hold. At least, that is my view.
I both agree and disagree with comments about Linux choas and churn. That is true of the overall ecosystem of course. But any given Linux distro can be thought of as its own operating system.
You can choose a Linux distro that reflects your own preferences in terms of pace of innovation. Sure Arch has 100 package updates a day and 30 ways to do everything. However, RHEL (or its compatibles) is not that way. You can go 10 years without changing your config files. Precisely because there are so many distros with so many different curated experiences, you can find a Linux distro that matches your own preferences.
And yet all Linux distros give you the hardware support and things like the OCI ecosystem that only the Linux kernel can provide.
Given the above, I wonder sometimes why you would choose FreeBSD over a Linux distro. But your statement that FreeBSD has more users than many Linux distros is a good one. It is also true that, while distros like Arch or Debian have more software in their repos than FreeBSD, the FreeBSD ports collection has a much larger selection than most distro repos. So, overall, FreeBSD does achieve a nice balance. So, that makes sense to me.
reading too deeply into it, it's basically an interjection. it doesn't refer to any meaningful facet of objective reality, it only exists according to the socio-political hallucinations of americans. doesn't matter if it's said positively or negatively, it's just a virtue signal long devoid of meaning. a bird's mating dance, if you will, but for burger-eaters.
you mean the plane plagued with software development issues[1][2]?
even ignoring the obnoxious yellow journalism, i'm not sure it's a shining beacon of best practices. or that replacing one ancient language with an even more ancient language is "moving forwards."
particularly when the language you're replacing was explicitly designed for your domain, and the language you're replacing it with is an entropic event horizon from which no coherent thoughtform can escape.
Dis is probably the closest, followed by the smalltalk VMs. It depends on what you mean by "like the BEAM". The VM itself isn't that special, it's really the whole OTP on top of BEAM that makes Erlang good at what it does.
What's the appeal of using this over unshare + chroot to a mounted tarball with a tmpfs union mount where needed? Saner default configuration? Saner interface to cgroups?