bcrl

I fail to understand why anyone would believe that it's possible to create a system that remains secure when an attacker has physical access to the hardware. It's the security version of snake oil. All the ever increasing complexity does is buy time.

By that line of reasoning, no feature could ever be merged in a filesystem. You simply cannot prove complex code has no bugs. Testing increases confidence that code may be stable, but that isn't a certainty as there's no guarantee that testing exercises all possible conditions. I know as code I've written that stood up to a lot of testing has resulted in data loss when a series of very complex conditions aligned to trigger a corner case.

Bugs are a fact of life. Bug fixes are a fact of life. Sometimes those bugs will cause data loss. Adding code in and -rc to support data recovery when a bug caused data loss to occur is a good thing for users. Portraying it as a bad thing is the worst kind of bike shedding.

Until Intel spins out their fabs into a separate entity, I don't think there is sufficient internal motivation to focus on the culture changes required to win and keep foundry customers. The rot of being a virtual monopoly for so long is simply too deeply engrained. Just as AMD spun out Global Foundries back in 2009 to survive, so must Intel.

Some of us are still using mutt!

Because distributions don't ship Kent's kernel tree, and they're not going to. Distributions like Fedora ship as close to mainline as possible these days because of the pain experienced from shipping a heavily patched kernel in the past. Release cycles are upwards of 3 months for Linus' tree. With that kind of lengthy release cycle, for an experimental codebase which is undergoing rapid stabilization it was the right call: you don't want old code to linger around longer than necessary when they're predominantly bug fixes that successfully pass regression tests. The choice should be with the maintainer.

Experimental does not mean "should be blocked from receiving timely updates" last I checked.

You have made a huge assumption that I have a steady income. I do not. I am currently in the middle of a fight with pole owners trying to get my company to survive having been denied timely access to poles for fully engineered permits. Loss over the last 7 years from delayed and denied access is in the millions. I could have settled things for hundreds of thousands, but there's no way to do that. I had to stop paying myself a paltry $25/hour to live off of last year when a creditor started squeezing as hard as possible.

Building FTTP networks is not expensive. It's the bullshit surrounding obtaining permission to install the fibre that is expensive.

That said, all software developers have a choice as to what they work on by the employer and teams that they sign up with. Just because you're employed to do something does not mean that you're obligated to go ahead with breaking the law.

Real engineers are required to take ethics courses in university, and they cannot willfully ignore actions that are unethical without risking the loss of their license. I think that software developers need ethical training more than ever given the direction of the industry.

That's not something I can agree with.

Take image generation trained on a bunch of copyrighted photographs and artwork. What is the intent behind creating such a tool?

Yes, there is a stage where the software developer is building the software to do this purely operating on a "this is a cool hack" kind of mentality, but the point at which you make it available to other people, especially for payment, is when the liability becomes real.

Having worked on open source software for most of my life, I have always had to be aware of the issues surrounding copyright. That other software developers will write software and use copyright to proect it while ignoring the copyrights of others is deeply concerning. Copyright of software is no more or less important than copyrights applied to images and artwork.

Engineers are liable for their mistakes. At some point the same mechanisms may well need to be applied to software.

No, it is not. bcachefs needs to have all the code for error recover in the kernel as it needs to be available when a storage device fails in any of a myriad of ways.

Maintaining a piece of code that needs to run in both user space and the kernel is messy and time consuming. You end up running into issues where dependencies require the porting of gobs of infrastructure from the kernel into userspace. That's easy for some thing, very hard for others. There's a better place to spend those resource: by stabilizing bcachefs in the kernel where it belongs.

Other people have tried and failed at this before, and I'm sure that someone will try the same thing again in the future and relearn the same lesson. I know as business requirements for a former employer resulted in such a beast. Other people thought they could just run their userspace code in the kernel, but they didn't know about limits on kernel stack size, they didn't know about contexts where blocking vs non-blocking behaviour is required or how that interacted with softirqs. Please, just don't do this or advocate for it.

As I pointed out elsewhere, there was another -rc release put out shortly after that effectively added back in a feature that was removed 10 releases back. Granted, it was only a small thing, but it shows that there is nuance in application of the rule.

Rule 1: don't assume malice.

Filesystems like ext2/3/4 have their recovery tools in userland. Most of the recovery features in bcachefs are in the kernel. As a result, it is inevitable that at some point there was and will be a need to push a new feature into a stable release for the purpose of data recovery.

Over the long term the number of cases where such a response is needed will decrease as expected.

Do you really want to live in a world where data losses in stable releases is considered Okay?

This is the world that software developers are building. At what point do they become accountable for the resulting mess?

A feature that was put in place to allow users encountering the bug to recover their data. It's not as black and white as you are portraying.

That's why mosh exists, as it is purpose built for terminals over high latency / high packet loss links.

I feel like we lost the battle for any semblance of hope in matters of security when the URL bar blurred everything into search. There is simply no way to ensure that the browser does what one expects anymore.

This is why IX like Torix lock down switch ports to a single MAC address and limited protocols (ARP, IPv4, IPv6). It's a bit of a pain when first setting up peering, but it reduces the exposure for all those connected to the IX. The reliability track record clearly demonstrates how worthwhile the strategy is.

Back in the late 1990s I worked on firmware for a dual PRI ISDN card that used an i960, and was quite impressed with its performance. Register windows made interrupts surprisingly performant. The hardest part of that project was fixing a stability issue caused by buggy logic in one of the CPLDs for bus arbitration between the i960, HDLC controllers and the PCI bridge. After fixing every firmware bug I could find, the issue simply had to be hardware. Once I had a few stress tests with the same firmware running on the older ISA version of the board and a borrowed logic probe, it was easy to prove the issue and come up with a fix. It was an OEM board that we were thankfully able to do the product stabilization work ourselves once the vendor realized they weren't going to get it done themselves any time soon.

This happened to my father while I was around during the beginning of the COVID lock down. He searched for an Apple support number and was served a targeted ad for a phishing site. Because of the change in search a few years prior, ads now look very much like search results compared to the obvious visual distinction back in the Don't-Be-Evil days. The ad was sufficiently targeted that it only showed up on his device for the search -- nobody else would see it.

Ephemeral ads are not a good thing.

At what point does Know Your Customer kick in for ads?

The P4's main problem wasn't so much the 30 stage pipeline. It was the fact that the CPU went off into la-la land for 4000+ cycles when replays occurred. The trigger could be anything as simple as a misaligned load or microcode for an 8 byte rep ; movs or a page fault. As a result, the performance of the design was very fragile and too sensitive to extremely small changes in code and data layout, in large part because of how the features to support high clock speeds all fit together. Performance tuning could often get substantial improvements for complex code paths, but the optimizations were frequently useless for other microarchitectures that didn't have the same glass jaws.

Hyperthreading was much less of a concern given that threading of software was only ramping up for mainstream x86.

ext4 has its own issues usually more in terms of scalability. XFS is trustworthy without the glass jaws ext4 has all over the place. Ah, the joy of taking 80 seconds to write out an 8MB file to disk after a fresh mount....

I am disappointed that the top voted comments are so supportive towards yet more generation of AI slop. Sites like this are making accurate search results by people for real world products that exist harder to get in front of the eyeballs that are looking for them. Sure, you might get a few minutes of lolz, but the misinformation seeps into search engines and then product reviews. It's the toxic waste that keeps on giving limited only by the cost of token streams.

Kinetic UPSes can fit in that niche. They're not exactly expensive to build, nor is there any new technology that needs to be developed. Like many power grid improvements the constraining factors are will and money.

Err, that's expected of every submission to a maintainer of the Linux kernel. If one doesn't do that, maintainers are going to notice eventually and stop trusting the patches sent by a person with such a poor reputation.

Newer coherent optical transceivers don't need physical dispersion compensation as they just do it in digital signal processing instead. That is the magic of ever increasing rates of computation at lower power expenditure.

Even if a pole is taken out by a drunk driver that does not mean the cables are going to be severed. I've seen plenty of times when poles had to be replaced, but the communications cables remained undamaged in place due to the strength and tension of the supporting strand.

The bigger issue over the last 5 years in the area where my company operates is the number of dump trucks that leave the bed up. Given the weight of dump truck it is easy for them to pull down multiple poles when they catch the cables, although perhaps they are drunk drivers...

When MIT ran the first massive online course, 6002x, I found out that MIT 6002x was the electronics course I had wished for back when I was in high school. The high school electronics courses I took only touched upon analysis of the simplest of circuits, and there wasn't a lot of explanation of how the different kinds of transistors (NPN, PNP, MOSFETs..) are modeled.

But oh how much workload the 6002x course was... I needed 10-15 hours per week for all the reading, problems and labs, and doing that while working full time and commuting 2 hours a day was a grueling pace to survive!

Too expensive where I live. Rocks, hills and trees: the natural enemies of buried fibre and wireless networks. One of my competitors took 6 months to bury a cable in granite that would've been a 5 day aerial job.

In telecommunications construction we are taught to make ample use of the "hammer test" when working on and around poles. The difference in sound between a good pole, a marginal pole and a completely rotten pole is quite significant.

Read the following commit log:

    Pull btrfs fixes from David Sterba:
     "Several zoned mode fixes, mount option printing fixups, folio state
      handling fixes and one log replay fix.
    
       - zoned mode:
           - zone activation and finish fixes
           - block group reservation fixes
    
       - mount option fixes:
           - bring back printing of mount options with key=value that got
             accidentally dropped during mount option parsing in 6.8
           - fix inverse logic or typos when printing nodatasum/nodatacow
    
       - folio status fixes:
           - writeback fixes in zoned mode
           - properly reset dirty/writeback if submission fails
           - properly handle TOWRITE xarray mark/tag
    
       - do not set mtime/ctime to current time when unlinking for log
         replay"

Sounds like they added a feature back in that was removed 10 major releases ago. Why is that not considered a feature? By this logic that btrfs merge request should have been rejected.

The "feature" label is messy. If the "feature" means that a user doesn't lose their data in a filesystem, is it really a "feature" or is it a bug fix? It's very much shades of grey.

What a lot of people are missing here is that bcachefs has a lot of test cases for regressions that are run as part of Kent's continuous integration infrastructure. A lot of Linux filesystems do not have this kind of easy regression testing, in part because this kind of testing is easiest when you do it as part of development, but very difficult to achieve any scale of coverage if it's done after the fact. The older the code is in Linux, the more likely it is that it tends to get coverage via the stress tests and intregration tests that various folks run on kernel releases. But such tests are not regression tests for data structures, I/O failures, corrupted data...

So much of what is going on is bikeshedding the process of submitting changes. It would be far more productive for people to look at the process Kent follows during development, and to then make educated comments about the code that arises from that process.

Good developers know the value of tests. Great developers know that improving your test coverage with every bit of new development means you can develop faster over the long run by not getting bogged down by silent regressions.

Edit: I do have to shout out to the XFS folks. xfstests is a huge contributor to the improvement of Linux filesystems over the last few decades.