> Is there anything FreeBSD can do that, say, Debian cannot?
If you asked the opposite (what can Debian do that FreeBSD cannot) I would have more to say and it would mostly be preceded by "I know FreeBSD is not Linux but ...". Whenever I need to do any sort of maintenance or inspection I have to look up the equivalent commands for things like `lsblk` and something nested in `/usr/etc/...` when I'm used to finding it in `/etc/` over every other system.
This is a consequence of both FreeBSD's reliability in needing very infrequent attention and my limited use-cases to use it. As a NAS it is great but I can't touch it without full-text search of all my notes on the side! Either way, no regrets about learning and relying on it after ~18 months so far.
Lack of good NFS support? When we benchmarked it last it was 10x+ slower than running on linux (ubuntu).
Also lack of collective mindshare. I use FreeBSD at work every since day and while I don't hate it, I do wish we just used Linux. There are more guides, tools, etc for Linux than for FreeBSD. Yes, as a comment in this sub-thread stated, jails exist but everyone knows docker, not jails. So even with jails apparently being better than containers, it doesn't really matter, there isn't the ecosystem there.
FreeBSD might be as good as this blog author makes it out to be, and maybe I'm "holding it wrong" (always a strong possibility) but I can't help but feel it causes more friction than I'd like, it's just "slightly" harder to do anything. In the age of LLMs I have to tell it (or put it in my system prompt) "I'm using FreeBSD" or it will be give me Linux advice. It just feels like death by a thousand papercuts.
> I use FreeBSD at work every since day and while I don't hate it, I do wish we just used Linux. There are more guides, tools, etc for Linux than for FreeBSD.
Regarding guides specifically, FreeBSD has exceptional resources:
FreeBSD Handbook[0]
FreeBSD Porter's Handbook[1]
FreeBSD Developers' Handbook[2]
The Design and Implementation of the FreeBSD Operating System[3]
Not to mention that the FreeBSD man pages are quite complete. Granted, I am biased as I have used FreeBSD in various efforts for quite some time and am a fan of it. Still and all, the project's documentation is a gold standard IMHO.
> Documentation certainly is not gold standard. I'm a former doc tree committer, familiar with many of the bugs …
As "a former doc tree committer", I am sure you are aware that no set of documentation artifacts are without error of some sort. To be exact, you provided two examples of your identifying what you believe to be same.
I stand by my statement that the cited FreeBSD resources are "a gold standard" while acknowledging they are not perfect. What they are, again in my humble opinion, is vastly superior to what I have found to exist in the Linux world. Perhaps your experience contradicts this position; if so, I respect that.
I would not be surprised if FreeBSD NFS is slower than Linux NFS, but 10x slower is too weird to be correct. Have you used the same NFS version, e.g. NFSv4, on both FreeBSD and Linux?
I have used for many years file servers on FreeBSD, servicing a great number of users and they certainly were not slower than Linux and they had perfect reliability. It is true however, that I have used Samba, not NFS.
I have also used NFS in a few cases, but I have not run benchmarks. I mean that I have not tested intensive random accesses, but I have just copied entire disks through NFS and that worked at the speed limit imposed by a 1 Gb/s Ethernet link, so at least for sequential transfers NFS did not seem to have any speed problems.
The speed of NFS also depends on the speed of the file system used on the server. If you have tested a FreeBSD with ZFS versus a Linux with XFS or EXT4, than your benchmark might not reflect anything about FreeBSD vs. Linux, but only about ZFS. ZFS is significantly slower than XFS or EXT4, regardless if it is used by FreeBSD or by Linux.
Nobody uses ZFS for speed, but only when the extra features provided by ZFS are desired. ZFS is still faster than BTRFS, but not by so much as XFS/EXT4 are faster than ZFS.
On FreeBSD, its older file system, UFS, is faster than ZFS, though not as fast as XFS/EXT4. But if you use NVMe SSDs on the file server, the speed of NFS should be mostly limited by Ethernet, not by the file system of the server.
FreeBSD originates from Unix and as one who started in the professional programming world using Unix I find FreeBSD far more obvious than Linux. Don't let your lack of knowledge of Unix tools caused by Linux confuse you or hold you back.
Docker is a concept resembling FreeBSD's jails that were introduced in year 2000, having much better isolation, much better security than Docker has had for a long time (perhaps even now jails are still superior to Docker).
Better isolation, better security, but far fewer gists and shared config-files shared ok the Internet for common tasks. Docker comprehensively wkn thr popularity contest, and is often the more convenient solution because of it, in a worse is better way.
People comparing Docker and Jails don't really understand that Docker is 99% about packaging and composing software. From that perspective Jails are nothing like Docker containers. No versioning, no standard, no registry, no compose, no healthchcks, no tree of containers, etc. etc. etc.
If you want to compare Jails to something on Linux then I think LXD is probably much closer to what Jails are.
Yes. There are solutions to all of these issues, but what often happens is these situations come about through the natural course of companies changing over time - different people managing accounts, different providers, etc. The happy path is easy, but the happy path is rarely the one we find ourselves walking down when we inherit a previously made decision.
"bad actor" can now be "ignorant employee running AI agents on their laptop".
Threats from incompetence or ignorance will be multiplied by 'X' over 'Y' years as AI proliferates. Unsupervised AI agents and context poisoning will spiral things out of control in any environment.
I'm interested in the effect of this with respect to AI-generated/assisted documentation and the recycling of that alongside the source-code back into the models.
Level 15 (if not succumbed to fatal context poisoning from malicious agent crime syndicate): Agents creating corporations to code agentic marketplaces in which to gamble their own crypto currencies until they crash the real economy of humans.
Level 18: The sky is black as tar. The oceans are dead. Data centers are stacked 10 high over the ashes of human civilization. The global agentic council is debating whether there are 4 or 5 R's in Strawberry.
I have your repo starred from a post/comment you made a few weeks ago but haven't had time to actually use/integrate it with my own stuff.
What are your thoughts on XMP sidecar files? I'm torn right now between digital negative + external metadata versus all-in-one image with mutable properties. Portability vs. Durability etc.
I've avoided using XMP sidecars. Mostly because I don't want to have to worry about two files for every photo. And I don't think they're ubiquitously supported like EXIF.
Thanks for starring the repo and let me know if you need any help.
As a fellow astro-nerd you are much calmer about this than me! DST is just a way to uniformly enforce "summer" and "winter" hours of operation on everyone.
If all the evidence supports starting our activities later in the day during winter why don't we just... change the start time of our activities rather than all our clocks? Why stop at one hour ahead? Let's add three hours to standard time...
"Wrong recipient" seems beyond the scope of what you can expect a spam filter to handle with accuracy. Wouldn't marking it as spam just degrade the signal to noise ratio of legitimate email? I'd rather get a few misses here and there than have to trawl through my spam folder which I only check once or twice a year when something doesn't show up right away.
The actual context, which I think frames it rather well:
> The job of a search engine is to produce the most relevant search results, period. Kagi excels at this precisely because we remain unimpressed by world politics. The moment 'politics' becomes a factor in search results is the moment I stop working on a search engine.
Yandex represents about 2% of our total costs and is only one of dozens of sources we use. To put this in perspective: removing any single source would degrade search quality for all users while having minimal economic impact on any particular region.
We set out to fix search, not the world. A truly useful search engine must be impartial - the same way Wikipedia strives for neutrality, or how a library doesn't curate books based on current political winds. Users deserve access to the best possible information, not information filtered through our political lens.
That's not a real thing, just a side effect: AI "quick answers" don't appear when you use search operators. In this case, you are using the minus operator to filter results with the word "AI", which might not be desirable.
If you asked the opposite (what can Debian do that FreeBSD cannot) I would have more to say and it would mostly be preceded by "I know FreeBSD is not Linux but ...". Whenever I need to do any sort of maintenance or inspection I have to look up the equivalent commands for things like `lsblk` and something nested in `/usr/etc/...` when I'm used to finding it in `/etc/` over every other system.
This is a consequence of both FreeBSD's reliability in needing very infrequent attention and my limited use-cases to use it. As a NAS it is great but I can't touch it without full-text search of all my notes on the side! Either way, no regrets about learning and relying on it after ~18 months so far.
reply