This shouldn't be mistaken for an anti-IPv6 post. There's also some steps you have to go through to enable IPv6 on your VPS networks, and there's still stuff like GitHub not handling IPv6. So, much as we need to migrate, we still have to support IPv4 connectivity for the foreseeable future.
> and there's still stuff like GitHub not handling IPv6.
And virtually everything inside of AWS still requires IPv4 so even if you have zero need to reach out to WAN, if you need any number of private AWS endpoints, you're going to be allocating some ipv4 blocks to your VPC :(.
Sure that one’s case, though you might be able to give out a host instead of IP to others to whitelist. Then you just set a low TTL and update the DNS record.
You might want to clarify that the document you're linking to does NOT have the words "Biden-Harris FTC" in it, but simply that the action was taken by that Administration's FTC. In fact, the article doesn't mention Biden or Harris in any capacity.
The salient point is that "Trump-Vance" is being stamped on everything in an effort to build the Admin's brand.
My immediate reaction to the title was "Bezos must not have written a large enough check to the library fund" or whatever else the orange man wants funded. yeah yeah, Bezos isn't in charge blah blah. Someone from the smile logo didn't write a check.
Yeah, these things are silly and I don't even know the audience for them. I remember seeing a lot of local infrastructure projects around with the attribution "President Biden BBB Infrastructure Bill." Does anyone really care? Politics have become really stupid.
It's a very "Thank You Dear Leader" of our current regime. Also look at them wanting huge picture of him in Washington on various buildings much like Mao/Stalin/Ayatollah etc always liked
Looks interesting, but few comments on the forum & even a negative vote count ATM. Format kinda looks "old school" in terms of defining records, but I guess that can be a positive in some circumstances?
I would say it is a niche solution that solves a specific problem.
Modern data sources increasingly lean towards and produce nested and deeply nested semi-structured datasets (i.e. JSON) that are heavily denormalised and rely on organisation-wide entity ID's rather than system-generated referential integrity ID's (PK and FK ID's). That is a reason why modern data warehouse products (e.g. Redshift) have added extensive support for the nested data processing – because it neither makes sense to flatten/un-nest the nested data nor is it easy to do anyway.
This is a fairly common problem. Data is often transferred between information systems in denormalized form (tables with hundreds of columns - attributes). In the data warehouse, they are normalized (data duplication in tables is excluded by using references to reference tables) to make it easier to perform complex analytical queries to the data. Usually, they are normalized to 3NF and very rarely to 6NF, since there is still no convenient tool for 6NF (see my DSL: https://medium.com/@sergeyprokhorenko777/dsl-for-bitemporal-... ). And then the data is again denormalized in data marts to generate reports for external users. All these cycles of normalization - denormalization - normalization - denormalization are very expensive for IT departments. Therefore, I had an idea to transfer data between information systems directly in normalized form, so that nothing else would have to be normalized. The prototypes were the Anchor Modeling and (to a much lesser extent) Data Vault methodologies.
If I were you though, I'd consider if I'd get more traction with an open source extension of Iceberg format that supports row based reporting and indexes for a unified open source HTAP ecosystem.
Looks like a lot of small ISPs have been procrastinating about getting their robocalling mitigation/compliance policies implemented, and didn't think the FCC was serious about the “Final Warning”. They'll get their stuff fixed eventualy.
I think OP is expecting that to be the outcome, given the roughly 2/3rds "Kent is (insert insinuation)" vs the 1/3rd "your stuff works, please stick around".
I worked for a guy that was looking forward to this work five years ago for a business product need. I'm glad to see it's made some headway in that time, but I have to wonder what it'd take to salvage the introduction of it to the Linux public at large. How do you even reset this mess?
I think nothing will happen, and Linus himself will eventually be whipped into place. Kent has come a long way in terms of communications, and all this talk about preserving sacrament of "collaborative community of kernel dev" reads real rich. The fact of the matter: bcachefs is the only modern + reliable filesystem in Linux right now. To throw it out—is madness, frankly. git rm -rf would be a show of weakness... basically telling everybody that they don't care about technical merit anymore. But really nothing will happen because Linus will eventually get whipped into place. The software is too good for this petty trickery to take place.
If the filesystem corrupts data, it has to be fixed at the maintainer's discretion. This is what the users want. Tough luck it makes Linus' life harder! Not to mention that he's allowed btrfs to run unchecked for so long. Kent put it nice, actually, kernel work is not about pleasing egos of top guys; it's about delivering software for users:
> "Work as service to others" is something I think worth thinking about. We're not supposed to be in this for ourselves; I don't write code to stroke my own ego, I do it to be useful. I honestly can't even remember the last time I wrote code purely for enjoyment, or worked on a project because it was what I wanted to work on. My life consists of writing code base on what's needed; to fix a bug, to incorporate a good idea someone else had, to smooth something over to make someone else's life easier down the line. Very rarely does it come from my own vision. My feelings are entirely secondary to the work I do.
> If the filesystem corrupts data, it has to be fixed at the maintainer's discretion. This is what the users want. Tough luck it makes Linus' life harder!
Where do you get this idea? Lots of Linux users want lots of things - a big part of the reason Linux is so successful is because they don't get what they want, and the project instead focuses on stable development and release cycles. Many users want Linux to break userspace in this or that case. Do you think Linus should do that, because it's what the users want?
And lets not forget we're talking about an experimental filesystem. If you decide to use one of those, it's not asking too much of you to compile your own kernel.
Funny, because "don't break userspace" is one of the principles I've been citing.
Things always degenerate when it turns into power struggles and people are going "No, I decide!".
"Make sure thinks work" is the underlying principle, and it's based on that that the code should have been, and was merged.
But then the personality conflicts and power struggles came out, and there's no need for that.
- You don't go overriding a subsystem maintainer without a clear justification; if the patch in question has a good reason for being there and can't affect the rest of the kernel, there's a really high bar to clear. This has been an issue for the XFS folks in the past.
- We have to be able to have technical and policy discussions without it degenerating into "I don't trust you and you need therapy". That's just childish. The private discussions got really ugly on this one.
And, regarding bcachefs still being marked as experimental: I'm being much more conservative with the experimental label than btrfs or ext4 were. Your data is safer on bcachefs than btrfs, today: you're not going to lose a filesystem, repair is thorough and robust and complete.
You may still hit hiccups, which is why the experimental label is there, but robust and complete repair and rock solid multi device have been reason enough for a lot of people to switch already.
> And, regarding bcachefs still being marked as experimental: I'm being much more conservative with the experimental label than btrfs or ext4 were. Your data is safer on bcachefs than btrfs, today: you're not going to lose a filesystem, repair is thorough and robust and complete.
> You may still hit hiccups, which is why the experimental label is there, but robust and complete repair and rock solid multi device have been reason enough for a lot of people to switch already.
It doesn't matter how conservative you are being, it's _still_ marked as experimental. That simply means there's no great pressing need to get a new feature into the next possible release - users can either compile their own kernels, or wait if they aren't able to. They decided to use an experimental file system.
You're making life much harder for these users by causing bcachefs to be thrown out of the kernel. No matter how you twist and turn it, you're responsible for "breaking userspace" in this case. I have no interest in trying to convince you - I've seen people much better at explaining things than I can try to do so, and I've seen you ignore each and every one of them.
Maybe the FS was upstreamed too soon, causing your development velocity and the high expectations you have for your end users to be at odd with the well entrenched workflows of Linux maintainers.
In any case as a Linux user, I want to thank you for your work and for your code which taught me a lot.
I hope it didn’t take too much of a toll on you.
Let’s hope that with the recent stabilization, the maintenance will be easier.
Well, being upstream has not been a rosy experience, so that'd be an easy judgement to make in hindsight.
But consider: ext4 was done entirely in tree, and btrfs was upstreamed much, much earlier and took a lot longer to stabilize.
So compared to historical precedent, we already upstreamed much later. e.g. we upstreamed long, long after we stopped making breaking changes in the on disk format (that was the point where btrfs removed the experimental label!)
If we're saying even that is too soon, then we're saying that bcachefs shouldn't have been upstreamed until it was perfect. But, no one was ever going to fund developing a filesystem from scratch all the way to completion and perfection completely out of tree. That's far too much uncertainty, and that kind of money simply isn't being thrown around in the Linux filesystem world.
Asking a filesystem to only be merged when it's completely done and perfect is saying "we want all the benefit and none of the pain", and it's just fundamentally unrealistic.
The whole point of Linux is community based development, and that's how I've been developing bcachefs. I don't have a big engineering team - but what I do have is a large community of people doing very good QA work that I work with closely, on a daily basis. People show up from anywhere with bugs, I ask them to join the IRC channel, and we start working together and it goes from there; a lot of people see us doing productive work and stick around and find ways to help out.
If that no longer works within the development model of the Linux kernel... oi vey.
> The whole point of Linux is community based development
You contradict yourself too much. You ignore feedback about not working well with others, and whenever someone wants to contribute, you shut them down by claiming you're the expert. This makes it seem like you're more focused on attracting investment than on actual collaboration.
Maybe then you should have considered this file system as truly experimental and expected your end users to make frequent backups. And advertise it as such. You could also have some kind of dkms bleeding edge module for your users to test fixes before they reach the kernel.
This way you wouldn’t be so preoccupied about getting code as fast as possible in the kernel.
No, a lot of bcachefs users are explicitly using it because of data loss, and they needed something more reliable; that's bcachefs's main reason for existing.
Besides that, if you want to make anything truly reliable, you have to prioritize reliability at every step in the process of building it. That means actively supporting it, getting feedback and making sure it's working well, and you can't do that without shipping bugfixes.
Having to ship a DKMS module just so users can get the latest bugfixes would be nutso - that's just not how things are done.
Some distributions do release hotfixes before they reach mainline kernel.
If you expect end users to compile Linus’ kernel head, why couldn’t they compile your branch though ? They get timely fixes.
This is not a case of 2 equal entities failing to find a compromise.
One is both technically more valid and has the simple right to set the terms and processes regardless of other opinions, the other is neither. All failure to function is on Kent, not on any "struggle".
Well, he already lost T'so, and I recall he's pretty high-up on the command chain. This appears to not be about technical merit anymore, vs existing as a "co-worker" with other kernel peers.
I've got in-laws that use 12yo Macs; would not surprise me in the least if a lot of older folks were still using whatever box from Best Buy or a relative they got in the late 00s.
Shoutout to Hacker News for having IPv6 support!