I've ctrl+f nanobsd but found no entires. Nanobsd is a set of build scripts from the FreeBSD source code that allows you to create a very minimal barebones operating system image. I think its mainly used for FreeBSD derivatives.
In the last year, I have started to think that the internet was a mistake.
My theory was 'the death of the internet'. Once everyone has been scammed, once everyone has been hacked and stripped naked in public, when there are more lies than truths, when you are the tool and the computer uses you, when everything has been sold and you have nothing: then you would say, this was a mistake.
Actually, I don't know much about the history of the internet. The Sony stuff is before my time. Now you mention this, perhaps the idea that the internet was designed to be beneficial was actually a total lie.
The Internet was a project to build resilient military communications during the Cold War. It was designed so that in case Russia would nuke the USA, the USA would still be able to nuke Russia, and all its other targets. This was not going to help people.
You're right. The people working there now have had plenty of time to learn about these egregious crimes and implement better policy so that they don't repeat the crimes of their predecessors... Right?
Japanese companies have always been heavy enforcers of IP, at least since the 1980s. For example, IIRC, they're one of the top filers of patents. Sanrio makes more money globally on their characters than Disney does. And Japan pushes for stronger international IP enforcement systems than even the US.
Japan is just quiet about it. Sony is no aberration.
Okay hear me out. People are complaining about unpatcheable IOT device and thats indeed concerning. But can’t we use the bad keys to generate seemingly value certificates that can be used to jailbreak these devices?
At last, russians got better at installing wiretaps. Reminds me of the old joke that goes "How do you know there is a soviet made bug installed in your home?
Yeah this is absolutely possible, and while they are a few good opportunities like this, it also means that someone else can decrypt all of your traffic in the same way.
I really hope someone manages to root the Google Home speakers. Been waiting for ages to be able to repurpose them for Home Assistant integration!
EDIT: just whipped up a quick hacking session with DeepSeek and, indeed, Google hasn't updated the cert chain yet on these devices, I am sniffing everything with MITM! Let's see if I can put that to use and gain root. At the very least, a mock endpoint server is possible now for use with Home Assistant.
When I was working with Linux based kiosks and PoS systems I had a good share of issues with the Microsoft MVP signature use of .local on their forests. Back then their training material recommended .local for Active Directory services.
Specifically, either a registered name or a subdomain of a registered name reserved for this purpose, because the A records for the apex should or must — I don't remember which, but it's definitely the default configuration — point to the domain controllers, and you probably don't want to host your public web site on the same addresses as your DCs (or for that matter, your internal and public records necessarily hosted on the same server).
Historically (20+ years ago), some Microsoft documentation suggested .local as an example of an unregistered domain that could be used for this purpose, which was problematic when .local was subsequently reserved for multicast DNS.
Meanwhile, I watched a very prominent Microsoft consultancy shop install a client's ActiveDirectory as <nameoforganization>.ad. You know, the country of Andorra? That has an actual real ccTLD?
I just bought mysefl a '.casa' domain, got wildcard cert for it from lets encrypt and haven't bothered with any of these. Downside, if internet goes down resolver stops, but thats why I have local NS mirror and all DNS queries go through my resolver.
Another downside is that some devices these days use their own encrypted DNS resolver and fall back to local DNS only for non-public TLDs. Not sure if that will continue working then as expected if your internet connection goes down.
I've been bitten by this with my home router which uses <device>.fritz.box when somebody registered fritz.box.
You can buy a cheap domain to make sure no one else uses it and just roll it on your lan. Throw some DNS ACME challenges and you have valid certificates too.
I do it for the LE certificate. But "cheap" is subjective. Domain registration and management should not be as expensive as it is. Nothing the registrar or registry does could be worth $8/10/200 a year with guaranteed 5-10% price increases every year. It is a grift.
BCacheFS is the best Linux filesystem now that storage costs a premium.
You can mix devices of different sizes and types on bcachefs. You can have foreground and background devices to balance performance and also different compression settings for foreground and background transactions.
You can set replicas=N to the individual file or directory on bcachefs. For example files you can just re-download or re-build. Likewise you can set a higher number of copies to important files.
If you have "refine until it's perfect and don't screw with things you don't understand" thoroughly ingrained, along with the dangers of overconfidence, you'll do fine with AI.
Not everyone gets it though, that's for sure.
And, if you want to know if it's mature, I'd trust the user reports over the one liners :)
I've been using ZFS on my Linux servers for years and have pretty good experience with it. I've not been following Linux development too much. Is bcachefs usable/stable/reliable enough to replace it?
It's not as battle-tested like ZFS with 15+ years of field usage, but it's good enough for me and other users.
There's a NAS appliance called NASty and it shares publicly usage stats: https://nasty-telemetry.pages.dev/
Those numbers are NASty alone. There are more users on other systems.
15+ years of ZFS code is also often said as being a nearly unmanageable pile of mess, supposedly to the point that there’s some of the code that maintainers are afraid of touching, and with plenty of unresolved weird bugs (which I experienced myself with data loss).
Sometimes starting fresh with one coherent codebase and all features design baked in from the start might be better.
It takes 10+ years for any storage engine to iron out all the wrinkles, get it to a state where it's both fast enough, and you can trust it to not lose data. It's stupid to throw it away once it reaches that point.
People keep saying it takes 10 years, but that presupposes methods that never improve. Why would we keep doing the same thing over and over again? Wouldn't be much point in that.
That might be the best thing happened to the project since now development can happen at its own pace without the clicky bait influencers.
In fact they delivered the erasure coding for parity raid back in march this year.
The thing is that as soon as you seriously give a chance to Bcachefs you see how good it is. I can only tell you that mixing different device tiers and having a per-file/directory replication setting is a god send specially in these times where storage costs more than gold.
> The thing is that as soon as you seriously give a chance to Bcachefs you see how good it is.
I'm pretty sure Bcachefs is amazing and better than Btrfs. I also think Zfs is amazing and better than Btrfs. Even so, I still use Btrfs because I know it is guaranteed to always be present on any Linux without any effort on my part.
> That might be the best thing happened to the project since now development can happen at its own pace without the clicky bait influencers.
A better approach might have been to just paused mainline merging instead of forcing being kicked out?
Eg "Hey Linus, Bcachefs is still in early development and I need to merge changes in a pace that is not compatible with Linux development process. So I'm going to pause for a while now and once it reaches maintenance status I will focus on submitting patches in a healthy pace that you can digest".
btrfs has one critical issue they don't fix: it blocks access to fs for minutes if you remove large files. I am not sure how this is acceptable for prod grade fs..
> it blocks access to fs for minutes if you remove large files.
How large is large? I've deleted files with sizes of tens to hundreds of GBs and not seen that, and can probably whip up a test with a single-digit TB file if motivated.
Do you perhaps have 'discard=sync' in your mount options, or are using a kernel earlier than 6.2, which is the version -according to the docs- where async discard became the default?
> How large is large? I've deleted files with sizes of tens to hundreds of GBs and not seen that, and can probably whip up a test with a single-digit TB file if motivated.
for 1TB compressed (probably 5tb uncompressed) it is reproducable 100% reliably for me.
I made a ~3TB btrfs FS and mounted it with 'force-compress', put 5TB of zeros on it (which compressed down to like 160GB), and did a delete along with some concurrent operations on that same FS. Based on what I saw, btrfs doesn't "block access for minutes" while a large delete is in progress, but access to the volume that has the delete in progress is dreadfully slow. I used vim to create a new file in the mountpoint and saw that write delays were between ten and twenty seconds. Really bad, but still functional. Not at all blocked.
Someone in that Reddit discussion that you linked to says that all btrfs filesystems hang during an extremely large delete. This is not what happens for me. The only btrfs FS made slow was the one that had the ongoing delete. I have four other btrfs filesystems mounted and they're all just fine, whether or not they're on the same physical disk that has the ongoing delete. space_cache is v2 on all of my btrfs filesystems.
On my system, it looks like an events_unbound kworker was eating 100% of a single CPU while the big delete was in progress. No other kernel threads seemed to be consistently occupied.
For fun, I re-ran the thing I document below when mounted without compression, and then with an uncompressable file when mounted with non-forced compression. I had to reduce the size of the file to 2TB for both scenarios, but omitting compression writes out like 10x the data to disk, so it still seems like a fair test.
I'm not going to the trouble to provide a transcript for those two runs, but both when mounted without compression enabled and when an uncompressable file was written to a compression-not-forced volume, I saw absolutely no delays in filesystem operations while I was deleting that 2TB file. FWIW, putting 2TB of /dev/zero on that compression-not-forced volume and deleting it behaved the same as it did on a 'force-compress' mount.
Whatever is causing the dreadful slowness is directly linked to transparent compression, rather than being something you get when you run btrfs in all configurations. "Why run btrfs if not for transparent compression?" you might ask. I would answer: "Snapshots and reflinks, and yes, I know that XFS has reflinks too.".
A lightly-edited terminal transcript follows for if you want to double-check my work up to the end of the 'force-compress' run.
bcachefs on Arch is a bit better supported, we have the distro package maintainer in the bcachefs IRC channel, and I've never lagged on mainline support like ZFS has.
Actual distro support, and doing it right with people actually communicating with each other, has always been a priority for the project.
> I still use Btrfs because I know it is guaranteed to always be present on any Linux without any effort on my part.
I used to think that about ReiserFS, too. It was in the mainline kernel, development was snappy, and it solved some performance problems. I used it all over the place.
But I had once expected ReiserFS to be permanent, especially since this Hans Raiser dude who was driving the ship seemed to be sharp AF, and this seemed doubly-true when his filesystem got mainlined.
But it was not permanent. It did not last forever.
This idea of permanence, or rather the lack of it, was the whole of the point that I was responding to and also trying to impress upon.
At the end of the day: We do not know the future. Things can change.
I've outlived this one high-performance Linux filesystem in my life that I was using. This does not in any way mean that I will be the last to outlive other Linux filesystems.
This sounds like FUD, do you have any references? Genuinely asking. I follow LWN reporting religiously, which in turn follows Fedora development (and associated drama) closely, and haven't seen anything said in this direction. Just had a quick look on LWN and Fedora development resources, and nothing came up.
This is what I read here and elsewhere bunch of times, which is why I said "supposedly". A quick search did not reveal any meaningful proof, though. I'll ask next time I hear someone say this.
unlikely. reference please. btrfs was the default filesystem on fedora installs last time i checked. to remove it they would have to first change that, then give it a few years before even considering removing it from the kernel. redhat could remove it because it was never default and never recommended.
This is what I read here and elsewhere bunch of times, which is why I said "supposedly". A quick search did not reveal any meaningful proof, though. I'll ask next time I hear someone say this.
I think in a perfect world they should had put someone in between to mediate and curate patches while providing DKMS for urgent patches.
As for BTRFS I think its also pretty good. Its just that I have the impression its development is guided by the needs of its sponsors and sadly for us META doesn't need RAID5.
A lot of things were tried, people did try to mediate.
The particularly galling thing though was when I finally started looking - post split - comparing bcachefs PRs to other subsystems and especially XFS - I was being more conservative with what I considered a critical bugfix.
There was never a clear statement on what the issue was. What you guys got in public was about as much as I got.
All I can say is - going fast when you're stabilizing and getting bugfixes out the door is what you can and should be doing when you've invested in test coverage, test automation, keeping the codebase clean and asserted, and building up a community that works well together on testing and shaking things out.
bcachefs was already working at its own pace prior to being accepted in the kernel. It could have continued doing so for years until it was really "ready".
Instead it got kicked out because Kent constantly ignored the kernel's contribution rules and is unlikely it will ever be accepted back into the kernel.
I'd really appreciate it if we could drop the FUD over contribution rules. There are no such rules, it is explicitly Linus's way or the highway, and I already replied to that elsewhere.
And it went in when it did because Redhat was pushing for it and claiming to be supportive - but that never materialized. They wanted to get something for free without investing, or putting in the absolute bare minimum.
A _lot_ of people were saying publicly and privately "dear god yes we need something better than btrfs" - but no one from the existing kernel community was interested in stepping up.
Community's still growing, though. A lot of people have gotten active in making sure bcachefs actually works well for people end to end, and there's a hell of a lot more to shipping a filesystem than just writing kernel code.
You can't let Reddit guide your technical decisions.
The FS was marked experimental, so there is no urgency in fixing bugs or providing features in a certain cycle. Everyone using it knows what they got themselves into. You can still provide the DKMS module for faster fixes and features for anyone who wants to use BCacheFS more seriously for the time that the upstreaming process takes, but eventually it would have all been on mainline.
Asahi is taking a similar approach where they have their downstream kernel and push things upstream once they are mature.
That means the upstream kernel is not useful for running on that hardware now, but things are moving there eventually.
Press releases are sadly like that. Fujitsu's main page has it in the first line:
> FUJITSU-MONAKA is a Next-Gen Arm-based processor, set for release in 2027, designed to address the challenges of next-generation data centers with its unmatched performance and power efficiency.
I've dabbled in both Garage and RustFS. Both are good but IMO flawed.
Garage is good but has weird tooling and a terrible searchable term. You'll receive lots of garage doors and electrical gate results when searching for issues with it.
The biggest problem with Garage is the metadata on an sqlite. If you have a single file and that sqlite corrupts then all your data is unaddressable and treated as pile of anonymous blocks. If you have multiple servers you can rebuild the metadata but if you have only one server you REALLY need to make sure that file is backed up.
So if you use S3 as a backup you have to keep a backup of your backup.
RustFS is closer to Minio, but I hate the way they log stuff. They basically use journald as a metric database dumping json formatted lines about library calls and how long they took. Its hard to make sense of those logs. Its the kind of log not meant to be human readable but to render on a dashboard.
Why not just publish these as a prometheus endpoint?
Also high CPU usage for no reason. I also noticed RustFS constantly trashing disk and keeping 10% CPU usage while looping some health check I have no idea how to disable (I've tried RUSTFS_SCANNER_ENABLED=false and others with no results). And of course lots of json metrics on journald.
I personally prefer garage because my backup box sit at my office and I like not needing to listen to HDD sounds all day every day while Rustfs loops its health check.
https://docs.freebsd.org/en/articles/nanobsd/
reply