But at the same time, nothing specific was asked in the prompt, so the boring result may arguably be what is the most aligned with the original request. Personally, I wouldn't want a model to add fuss to something while I never asked for it.
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.
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.
Not something I'd want to do with my filesystem though. ZFS is different story it it isn't on the root fs because it might be packaged by the distribution.
also tricks to make it easy to convert a root FS to ZFS now that Ubuntu Server 24.04 added native root-on-zfs support: https://github.com/pirate/zfsify
Or a partially completed song, asking for the next note. I’m not sure if you’re joking, but using it for space constrained next token generation within a grammar sounds like a really neat use case.
All they're saying to the other players is: let's lock it down and slice up the market between us.
Claiming Skynet is just around the corner is a great way to get the public to believe only these huge companies can harness AI, and how all open-source models should be outlawed.
There are no open source models, at least not useful ones. Open weight is not the same as open source. Open weight models are still just inscrutable binary blobs that you can (theoretically) run on your own computer instead of through a SAAS web app. The open weight model labs don't even provide a high level catalog or any description whatsoever about what went into the training data.
This is not open source and we really should stop conflating the two things.
I never understood why any of the smartness had to be built into the TV in the first place. Sure, it's useful for the first year, and then the seriously underpowered hardware they installed into it will have trouble with just about anything.
I bought a Philips Ambilight OLED TV probably over 8 years now. Brilliant tv, great quality, I still see no reason to replace it at all. But its built in AndroidTV is garbage.
Because it’s extremely profitable for them to serve ads and sell PI. Kind of like how the airline industry makes more money off credit card shenanigans than actual plane tickets.
Not relevant to the discussion but to your comment, Freakonomics Radio claimed "airline industry makes more money off credit card shenanigans" was not true
> I never understood why any of the smartness had to be built into the TV in the first place.
Because technology got ever more complex. A TV of yore? That thing operated on (relatively) simple physics alone, at the cost of requiring an absurd amount of broadcast infrastructure to make sure a TV signal could be received across the country.
Modern TVs however... digital modulation schemes with a lot of signal processing wizardry allow TV reception with far less broadcast towers and far better quality. You got satellites and with these a myriad of control schemes (DiSEqC, Unicable, ...). You got Pay-TV that requires decryption. You got HDMI CEC to allow your TV to remote control your DVD player.
And all of that complexity requires firmware which means it can have bugs which means you need a firmware update capability and when you're at that point you can just go and slap something Linux on it and get all the apps for streaming services.
It did. We are currently on the fourth or more reinvention of capitalism. It's like ethernet - every time networking technology changes, the new one is called the same thing as the old one. The current fiber-optic switched Ethernet has absolutely nothing in common with the original vampire-tapped coax with media attachment units clamped onto the cable and a serial-port-looking AUI interface running down from the ceiling to the computer. Same for capitalism.
> Capitalism cannot survive when products last a lifetime.
This is totally backwards; capitalism would do fine in such an environment (in the same way that evolution does fine in an environment where organisms live more than just a few seconds; the whole reason we have the notion of a "lifetime" is that our germ line comes from a long line of ancestral DNA that made organisms that outlasted their competition.)
Individual companies might have to hustle to innovate or die, but that too is good for capitalism.
Both capitalism and evolution depend on the fact that over time, on average, less fit organisms/organizations are displaced by better alternatives. You may not like that, but down-voting anyone who points it out doesn't make it any less true.
I use MCPs all the time, but just like in your case: they're my own MCP servers.
They do exactly what I want and how I want it. They expose just the information and the features I want the LLM to have. And just like in your case, it combines multiple sources of information into 1 response.
It is a bit weird. As someone from Belgium (we also use our own variety of Azerty) you are very frequently reminded that you're on a weird keyboard. At least for someone who games, you wouldn't make ZQSD the default. It's the first thing you do in every game, change WASD to ZQSD
Another Belgian here, the first thing I did when I started working is switch to International English keyboards. Some employers wanted me to use local keyboards but I always managed to convince them to let me get another one in the end.
reply