Scrub for bcachefs

Posted May 26, 2025 7:43 UTC (Mon) by jmalcolm (subscriber, #8876)
Parent article: The 6.15 kernel has been released

Looking forward to scrub in bcachefs.

Also nice to see support for the Apple T2 chip as I have a couple of devices with that in them.

Scrub for bcachefs

Posted May 26, 2025 10:46 UTC (Mon) by ballombe (subscriber, #9523) [Link] (7 responses)

It is kinda nostalgic to see devices being supported Linux two years after being discontinued!

Scrub for bcachefs

Posted May 27, 2025 12:50 UTC (Tue) by parametricpoly (subscriber, #143903) [Link] (6 responses)

There is healthily growing hostility towards open hardware specifications and open source code among the vendors.

Scrub for bcachefs

Posted May 27, 2025 13:46 UTC (Tue) by pizza (subscriber, #46) [Link] (5 responses)

> There is healthily growing hostility towards open hardware specifications and open source code among the vendors.

I'm dealing with a spec right now that *mandates* that it (and implementations) be kept confidential.

because $reasons

Scrub for bcachefs

Posted May 27, 2025 15:51 UTC (Tue) by hmh (subscriber, #3838) [Link] (4 responses)

Chances are it is potentially violating patents, or it is unsafe as all heck. Likely both.

Scrub for bcachefs

Posted May 27, 2025 22:07 UTC (Tue) by NYKevin (subscriber, #129325) [Link] (2 responses)

Unfortunately, this is or was a common pattern for anything with a radio transmitter in it. The usual argument goes like this:

1. We have a radio, so we must comply with FCC (or local equivalent) regulations.
2. The FCC (or local equivalent) says that our radio must do X or must not do Y.
3. It is physically possible for our radio to violate those rules.
4. Therefore, we must prevent users from doing anything with our radio unless we're sure it would comply with the rules.

As a non-lawyer, I'm not well positioned to assess whether that is a valid legal concern (there are at least ~200 jurisdictions in the world that might plausibly have different answers to that question). But in an ideal regime, (4) would look more like the following:

4. Therefore, we must clearly warn users that tampering with the radio may cause them to violate the rules, and get them to agree that we will not be held responsible for any violation of the rules caused by the user's modifications, even if our software or firmware contributed to the violation in some way.

Scrub for bcachefs

Posted May 28, 2025 7:04 UTC (Wed) by johill (subscriber, #25196) [Link]

Also non-lawyer here, and really just going by what I've been told, which almost certainly is a very specific (local) interpretation, but:

It's not necessarily the biggest concern to prevent users from _intentionally_ doing such things on their individual devices assuming it would be difficult and/or obvious enough. You must, at least to some extent, also prevent said device users from being harmed by e.g. random exploit code running on their machines, and prevent anyone from being able to break things at scale. Understandably, the FCC cares less about a single user finding a way around limitations than a "script kiddie" breaking the regulations on millions of machines in some automated fashion, possibly even harming users in the process or even with the intent of doing so.

Taking this argument face value, I'd think that at that point you basically end up needing some kind of obvious switch like ChromeOS laptops have for their developer mode, but that's clearly not feasible for a random embedded radio (say WiFi or 5G modem.) I suppose it _might_ be doable for certain classes of expensive devices, but I'd think the extra development effort never pays off.

Scrub for bcachefs

Posted May 28, 2025 8:47 UTC (Wed) by farnz (subscriber, #17727) [Link]

For the US specifically, under the current rules, most radio transmitters will only be restricted by 47 CFR 15.12, which does match your version of 4, with the exception of U-NII devices, which have extra restrictions in 47 CFR 15.407(i).

However, historically the FCC took the position that unless a modification that breached the rules needed significant enough skill with a soldering iron that you could have built an equivalent device yourself (e.g. adding a transistor to the RF path or replacing a soldered down IC), they'd change the rules to retroactively prohibit any devices that were being modified to breach the rules. There's still remnants of this in the rules today; for example, 47 CFR 97.317 is intended to make it very hard to sell an amateur amplifier for 10m that can be easily modified for use with CB.

Scrub for bcachefs

Posted May 27, 2025 23:11 UTC (Tue) by pizza (subscriber, #46) [Link]

> Chances are it is potentially violating patents, or it is unsafe as all heck. Likely both.

Neither; it's the old standby of a combination of "security" and "if we allow modifications we potentially become [strictly] liable under numerous federal laws"

Scrub for bcachefs

Posted May 26, 2025 10:47 UTC (Mon) by kragil (guest, #34373) [Link] (1 responses)

So you have still hope that bcachefs will go anywhere? I've lost that quite recently tbh.

Scrub for bcachefs

Posted May 26, 2025 16:08 UTC (Mon) by koverstreet (✭ supporter ✭, #4296) [Link]

Why? :)

People forget that filesystems are massive projects, these things do take awhile.

But it's been steadily coming along.