Hector Martin

https://social.treehouse.systems/@marcan

If it ain't broke, I'll fix it! · he/him

I'm porting Linux to Apple Silicon Macs at Asahi Linux.

GitHub Sponsors: http://github.com/sponsors/marcan
Patreon: http://patreon.com/marcan
Asahi Linux: https://asahilinux.org

Public Key

npub1qk9x6yrvten3jqyvundn7exggm90fxf9yfarj5eaz25yd7aty8hqe9azpx

NIP-05 Address

marcan_at_social.treehouse.systems@momostr.pink

Profile Code

nprofile1qqsqtzndzpk9ueceqzxwfkelvnyydjh5nyjjy73e2v7392zxlw4jrms49wx7e

Author Public Key

npub1qk9x6yrvten3jqyvundn7exggm90fxf9yfarj5eaz25yd7aty8hqe9azpx

Show more details

Last Notes

2024-08-26 08:33:57

Say what you want about Telegram, but it has one of the best data export/backup features I've ever seen.
Fully client-driven, with real-time progress display (and even the ability to manually skip large file downloads on-the-fly).
The output is a bunch of plain HTML pages with just 200 lines of pure JS (no frameworks) for some minor interactivity features, that loads instantly and looks roughly like the Telegram client itself, easy to browse and search.
The JSON is one big blob with all the same data in a trivial format. The text encoding is interesting: Telegram supports rich text, but instead of in-line HTML-style markup, in the JSON it's encoded as JSON objects representing the different spans of text with different format. Very clean.
https://cache.treehouse.systems/media_attachments/files/113/027/359/054/213/816/original/32984911e6073d9e.png
https://cache.treehouse.systems/media_attachments/files/113/027/393/114/175/783/original/069c0737571b021b.png

2024-08-18 12:56:01

- reply

No, the AGPL has a different problem. The FSF has been misleading everyone into *believing* it has an anti-SaaS usage restriction, but it doesn't.
What it does have is an anti-SaaS *modification* restriction, which bites people a very different way. It is indeed a pure copyright license, but also nonfree due to this fact.
It is entirely safe to install and run AGPL software as-is as an end user, and you don't need to take any steps to offer source code to anyone. However, it is extremely difficult to modify AGPL software and abide by the terms of its license. ~All Linux distributions shipping AGPL software are *themselves* in violation (not their users) if they have any AGPL packages they apply patches to without a source offer URL/mechanism update (or creation, if it does not exist already). This happens in practice extremely often.
More detail here: https://social.treehouse.systems/@marcan/112973100810673010

2024-08-18 12:52:27

- reply

Because that's not how copyright works. You seem to wish it worked that way, maybe it would make some sense for it to work that way under limited situations. But it doesn't.
We're arguing in circles here, so unless you bring some evidence that your completely unconventional interpretation of copyright law actually has prior court interpretation art, I'm just going to stop replying now.
BTW, I don't "defend" SaaS. I merely assert that protecting against SaaS requires going outside the Free Software Definition. I fully endorse people who want to ban SaaS usage without source offers. They just can't call their software Free Software by conventional definitions.

2024-08-17 13:45:15

- reply

Worth noting: At Asahi, we do sometimes volunteer to help upstream projects with issues that affect our platform. We do this at our own discretion, often prioritizing projects we ship as the reference experience (which for Fedora Asahi Remix is KDE Plasma and the rest of the ecosystem stack it depends on, plus stock apps etc). We don't do this for every possible platform-related bug, only issues where we feel we can contribute a meaningful fix as outsiders. Sometimes we just file bugs upstream and let the upstream developers fix things themselves.
We don't have the bandwidth to literally help fix every platform-related issue, it would consume all of our time.
So us not fixing bugs for Vaxry and Hyprland is not unique, e.g. I also don't personally debug issues in GNOME either, I'd tell them to talk to the relevant fd.o folks for help. I don't know all the subtle details of kmsro/gbm/Wayland interaction myself, there are people much better equipped to handle those questions than me.
Vaxry getting himself banned from fd.o is his own problem though.

2024-08-05 19:05:05

- reply

Unencrypted should work, presumably WEP too (but nobody tests that so who knows). Not sure about WPA1.

2024-07-29 18:57:28

I've just been told that Apple are transitioning to cleartext iBoot images. We already knew there wasn't anything naughty in iBoot (decryption keys had been published for some systems/versions, plus it's tiny anyway and doesn't have space for networking stacks or anything like that) but this means that, going forward, the entire AP (main CPU) boot chain for Apple Silicon machines is cleartext, as well as SMC and other aux firmware that was inside iBoot for practical reasons.
The only remaining encrypted component is SEPOS, but it's optional and we don't even load it yet for Asahi Linux. All other system firmware other than iBoot and the embedded SMC/PMU blobs was already plaintext.
That means that there is no place left for evil backdoors to hide in the set of mutable Apple Silicon firmware. All updates Apple publishes going forward can be audited for any weirdness. 🥳
(In practice this doesn't really change much for the already-excellent privacy posture of Apple Silicon systems running Asahi, which have always been way ahead of anything x86 since there's no Intel ME or AMD PSP equivalent full-system-access backdoor capable CPU, but it helps dispel some remaining paranoid hypotheticals about what Apple could potentially do, even if already very unlikely.)

2024-07-29 16:31:35

- reply

Easier? Only sometimes, not that often. Access tracing gets directly at the hardware and skips dealing with multiple layers of abstraction and irrelevant details in the driver. Plus it allows you to experimentally figure out features that the original driver does not exercise, once you get a good mental model of the hardware.
The problem with just reading the code is that you need to have the mental discipline to not copy. Lots of people don't, and I've seen this go horribly wrong with other projects. It turns out that the people who are capable of abstracting out the hardware in their head to a degree that they won't infringe with their implementation, *also* are good at interpreting hardware traces and skipping reading the code altogether. The people who think reading the code is much easier turn out to just be... copying, on purpose or not.
In the end, I find the only times I really find reading code easier is when you'd wind up with the ~same code with access tracing, just done slower. This usually means initialization sequences and stuff like that, which boil down to a pile of dumb register writes (which isn't copyrightable either if it's a sequence the hardware requires to function properly). E.g. there are some hard coded "mask and set bits" tables in Apple's drivers, particularly things like pulling bits out of calibrarion fuses and into PHY registers, and no matter how you slice it those would turn out to be identical if reverse engineered purely black box. It just takes longer since you have to use injected test patterns to identify all the field offsets and widths across multiple virtual boots, and you'd come up with the same table that's in Apple's driver anyway.
So when a new chip comes out with new fuse offsets, it's easier to just throw the driver in Ghidra and pull out the table than spend hours reverse engineering the same table experimentally.
But other than boring stuff like that, no, I often find hardware tracing more efficient than reverse engineering drivers.

2024-07-29 13:09:33

- reply

Neither of your two arguments are considering the fact that copyright has nothing to do about *process*, it has to do about *works*. Just because a *process* exists that is technically similar to another *process* that produces a derivative work doesn't mean that the former also does, because it's noth about process similarity, it's about the nature of the work.
We're clearly getting nowhere with this conversation so I will not be replying further, as you don't seem to be listening and you're applying bogus arguments of *technical* similarity to a *legal* question.

2024-07-29 11:29:40

- reply

Verilog being copyrightable does not imply that a netlist compiled from verilog is copyrightable. Again, just because X was constructed from a copyrighted work doesn't mean X itself is copyrighted.
For example, I can take the size of a Verilog file in bytes and that number is not copyrightable, even if the Verilog source code it is the size of is.
Copyright isn't a magical thing that makes any process with an input of copyrightable X and an output of Y cause Y to be copyrightable and a derivative work of X. You first have to show that Y is copyrightable all on its own (contains copyrightable expression).

2024-07-29 10:29:21

- reply

Yes, and then it would possibly be copyrightable (but nothing would stop someone from extracting the netlist and doing their own design that's not derivative as far as copyright is concerned)

2024-07-29 10:18:48

- reply

There is rather deep understanding of what can and can't be copied in creative circles. Sure, unintentional copying can and does happen, but people usually make an active effort not to. This is partially thanks to the feedback loop that if you make something overly reminiscent of a particular original, it will *remind* you of that original.
In specific disciplines there is an understanding of what is a "technique" and can be learned, and what is actually an original creation and can't. As an example in music, chord progressions, musical styles, and song structures are in the public commons while melodies are not. As a musician I know full well that I can take inspiration from popular chord progressions or specific songs using them, but I can't just rip off a melody (minor references aside, and in that case it's usually very clear when something is just a homage and not an integral part of your creation) and call it original. But I *can* make a cover version and that comes with its own copyright rules. I also know that there is meaning beyond these rules, e.g. if I make a song with very similar instrumentation and structure and chord progressions to another song, but a different melody then it would be interpreted as a style parody (and the lines are a bit grey here if I try to pass it off as original, but then parody rights are their own concept).
AI just doesn't know about any of that. It's a dumb linear algebra machine that just learns patterns and associations in its training data and has zero concept of copyright, morals, common sense, or creative convention.

2024-07-29 09:23:11

- reply

We do not break any security measures to make Asahi Linux work. Running third party OSes is a vendor-implemented and supported feature.

2024-07-29 09:19:31

- reply

The part that you're missing is that something can only be a "derivative work" if it itself is copyrightable. There is a general understanding that software binaries are copyrightable, and this has obviously been tested in court. ASIC netlists are not the same. *If* they are copyrightable *then* yes, as a derivative work of the source, they'd be copyright the author of the source. The question is whether they're copyrightable or not.
You can't assert that something is copyrightable because it is a derivative work, that's backwards. You have to establish that it's copyrightable first, then you can say it's a derivative work.

2024-07-28 17:10:03

- reply

I'm talking about PCB netlists. I'm not sure that ASIC netlists are protectable at all (like mask works are), I'd love to see a citation for that if you have one.
As for FPGAs, that's a corner case in between software and hardware, and I wouldn't bet on legal decisions going either way or even being consistent.

2024-07-28 16:00:49

- reply

Anyone can put a copyright line on anything. That doesn't mean the law agrees it's copyrightable.

2024-07-28 15:54:30

- reply

There's some wiggle room there, you might have a claim if some of the decisions are purely artistic... but I wouldn't want to be a person trying to argue this in front of a judge against a cloner.

2024-07-28 15:50:02

- reply

There's a Taiwan case that held that the literal circuit layout *may* be protected but (effectively) not the netlist (and in this case it wasn't a 1:1 copy, so was deemed not infringing):
https://www.lexology.com/library/detail.aspx?g=ecbb24af-4a0a-4971-9022-2edfeac253eb
You may find similar opinions elsewhere. As far as I know it is very well established that mere netlists are not copyrightable. Look into guitar pedals and other audio equipment for many examples of people copying each other with impunity. Direct copying of a PCB layout 1:1 is more contested, but easily avoidable in practice by just doing your own layout with the same netlist.

2024-07-28 15:17:54

- reply

Artistic elements of a PCB design are copyrightable (e.g. if you just import an image into a layout for purely visual purposes). As for making the *functional PCB layout* itself artistic... IANAL but my guess is yes, that makes it copyrightable. However, only the artistic aspect; you could reverse engineer the netlist and make your own alternative layout and that would be fine.

2024-07-28 15:10:57

- reply

Amusingly, yes. Once you turn a PCB into an artistic work that goes beyond its original functional purpose, it's copyrightable.

2024-07-28 15:09:48

- reply

You can copyright the catalog itself, but not the facts. Nobody can hold the copyright on the truth, so anyone is free to create an equivalent catalog. Anything else would be madness.
But again, this has nothing to do with AI nor with my original post. We're conflating wildly different things here.

2024-07-28 13:17:51

- reply

You keep using the word "copyright" to talk about patents. You can't do that. The ideas in patents aren't copyrighted. They're patented. They are different things.
The question the whole AI/ML debacle revolves around is whether the "training" process erases copyright status. IMO it does not, because that also doesn't work for humans - you can memorize a book (which is nothing but "training" your neural circuitry) and write it out again and the result is still copyright infringement. The reason why humans can produce creative works that aren't infringing as a result of training themselves on copyrighted input is that we have the ability to reason about what elements are copyrightable and what elements aren't, and we train at a much higher level of reasoning and abstraction than state of the art GenAI.
Until AI becomes able to do that, there is a strong argument to be made that AI output is a derivative work of the training data. We also have a definition of copyright that requires "fixing" into a medium and human brains don't count, so memorizing something by itself is OK as long as you don't reproduce it. That doesn't apply to ML weights, which are "fixed" in the storage medium, making the model itself infringing.
And none of this has anything to do with my original post, because it's all about things that *are* copyrightable to begin with, and hardware isn't (nor facts in general), and patents aren't the same, and conflating them is meaningless.

2024-07-28 13:03:19

- reply

I believe the general principle that functional works are not copyrightable is relatively widespread, but it's very hard to find decent sources for copyright nuance for non-US countries so this is not legal advice etc etc.

2024-07-28 12:53:04

- reply

You're confusing patents and copyright. They are different things. Patented hardware can be freely discussed. The whole *point* of patents is that you agree to *disclose* an invention in exchange for limited protection (20 years). You can talk about patents and patented hardware all you want, you just can't go manufacture your own without a license.

2024-07-28 12:25:57

- reply

AI is trained on copyrightable information, and state of the art AI has no ability to discern between creative/copyrightable information and not. It's not the same at all.

2024-07-28 11:26:21

Facts about hardware are not copyrightable.
People tend to ascribe magical properties to copyright, as if any kind of information whatsoever is copyrightable. That's not how it works.
Copyright is intended to protect *creative* works. Hardware devices are not considered creative devices, they are functional. They are protected by patent rights, not copyright – and patent right only protect the ability to reproduce the device, not describe it.
This means that [PCB layouts are not copyrightable](https://law.stackexchange.com/questions/59690/may-i-show-a-printed-circuit-board-of-a-device-on-the-internet ). By extension, nor are circuit netlists (i.e. the "information" within a circuit schematic). (Yes, this has interesting implications for open source hardware! You can attach licenses all you want to OSHW, but they only protect the actual source design files - anyone can just copy the functional design manually and manufacture copies and ignore the license, as long as they change the name to not run into trademark issues/etc., any firmware notwithstanding)
IC masks *are* protected under a [very explicit law](https://www.bitlaw.com/copyright/maskwork.html ) in the US. They weren't before that. By extension, nothing else about the chip design other than possibly firmware is copyrightable.
If you go and make an x86 clone or an unlicensed ARM core, Intel and ARM won't go after you for copyright violation. They will go after you for **patent infringement**, because the ISAs are patented.
This is why projects like Asahi Linux can exist. If somehow just *knowing* how hardware works were a potential copyright violation, none of this would be possible.
What this means is: it is *entirely* legitimate to inspect things like vendor tools and software to *learn things about the hardware*, and then transfer that knowledge over to FOSS. You *may* run into license/EULA issues depending on what you *do* with the source data specifically (think: "no reverse engineering" type provisions), but as far as the *knowledge* contained within is concerned, that is not copyrightable, and the manufacturer has no copyright claim over the resulting FOSS.
This includes copying register names. I have an actual lawyer's opinion on that (via @npub17s4…d965). I tend to rewrite vendor register names more often than not anyway because often they are terrible, but I'm not legally required to.
The reason why we don't just go and throw vendor drivers into Ghidra and decompile all day, besides the EULA implications for the person doing it, is that the *code* is copyrightable and it can become a legal liability if you end up writing *code* that drives the hardware the same way, including in aspects that are deemed creative and copyrightable. This is why we have things like the clean-room approach and why we prefer things like hardware access tracing over decompilation.
But stuff like register names and pure facts about the hardware like that? Totally fair game.
Fun fact: Vendor documentation, like the ARM Architecture Reference Manual, has no copyright release for this stuff in the license. If register names were copyrightable, then anyone who was ever read ARM docs and copied and pasted a reg name into their code would be infringing copyright. They aren't, because this stuff isn't copyrightable.

2024-07-22 10:50:54

- reply

It's not an s-video (Mini DIN 4 pin) connector, it's different. The keyword is "Kycon", though you can find cheaper clone connectors on AliExpress. You can grab a pair and make your own cable instead of butchering two original ones :)

2024-07-22 00:43:36

- reply

A longer cable with different characteristics *can* in theory result in a change in the sound for the remote (right) speaker (due to different resistance, which can combine with voice coil impedance to produce frequency-dependent effects), but how much I can't say. Probably not much in practice.
I do have a pair I run with a home-built longer cable and it's fine though. If you do that, just make sure you use nice and beefy 4-pole speaker cable to minimize the effect of the extra length.

2024-07-20 23:59:37

- reply

Several people have requested this and it would actually not be hard to implementfor systems with CPU capacity info ;)

2024-07-20 23:58:09

- reply

I wrote a Bitcoin miner for shits and giggles. Wasn't particularly useful since real GPUs were already winning that game, but it was about as fast as an actual high end current-gen CPU at the time (long after the PS3 launched) which was still impressive.

2024-07-20 23:55:05

- reply

ALARM Is not maintained to production distro standards. The maintainer team is basically one person with not enough time.

2024-07-20 15:12:44

- reply

> Sounds as argument against big kernel and in favor more isolated drivers, and against "hyper-privileged" software in general...
Which is what macOS did, and why this can't happen on the macOS version of crowdstrike (it uses userspace drivers).
Linux has similar mechanisms, but can't discourage kernel drivers by policy like macOS did since it's not as tightly controlled, so CrowdStrike on Linux still uses a kernel driver even though it could choose not to, because they suck.
> Kernel could unlock all mutexes on process death (and even if process leaked mutexes lock without crash), same way as file handles freed even if you use kill command on process....
No. If a mutex is locked then there is no guarantee that the data protected by it is in a consistent state. You can't just "unlock all mutexes", then you just get data corruption which is worse than the partial deadlocks. Mutexes are low-level constructs. The whole point/job of the kernel is to keep track of resources in a safe manner so this can be done for userspace handles like file descriptors. The buck stops somewhere and within the kernel it is impossible to do this because at the end of the day there has to be *some* code in charge of atomicity/consistency for resource state and *that* code itself cannot be freely interruptible.
> At userspace it resembles how nodejs domains used to intercept error to prevent ungraceful process crash.
... and this works because Javascript is a high-level, memory-safe language. You can't do this with C.

2024-07-20 14:59:13

- reply

THAT BSOD was caused by a driver *crashing*, not a driver *returning an error code*, which is a very different thing because a crash is uncontrolled and cannot be safely handled, while an error code return *is* a safe and controlled condition.
Linux actually tries to prevent a full system panic, and only terminates the current process if the context is a user process. If you're lucky that means the machine keeps working as normal, if the crash didn't corrupt memory. More often than not, even in that case, the faulty driver had some mutexes locked and your system will slowly deadlock into oblivion as other processes try to lock the same mutex. There is no reasonable way around this. This is why uncontrolled crashes are bad and error returns are not.

2024-07-20 14:52:41

- reply

Huh? No OS crashes when a driver returns an error, be it from the init function or a callback. It doesn't propage to "exit of process", it propagates to the driver management layer and then the operation fails, be it an access or a driver init.
On Windows that's a little exclamation mark on the device in Device Manager or similar, or a service error code, or whatever.

2024-07-20 14:36:39

- reply

DRM isn't really an excuse, you can end to end test just like a user system and having a staged deployment mechanism to allow for testing internally before pushing to production is tangential to any DRM.

2024-07-20 14:34:33

- reply

Yes it is. Again, you can statically forbid panic, and (safe) Rust already forbids unsafe memory accesses. Therefore, it is impossible to (memory error) BSOD regardless of how you handle user input in the general case. The language forces you to handle the bad input gracefully somehow (typically by returning and propagating an error).
About the worst you can do is infinite loop (but no language can protect against that because it equates to solving the halting problem).

2024-07-20 14:26:57

- reply

Just the OpenPGP applet, it's all standard and relatively well documented stuff.

2024-07-20 14:26:18

- reply

As far as I know, some people have reported that the problem file was (at least sometimes) all NULs. I think there was one unverified comment claiming to be from someone from CrowdStrike that claimed it was a postpro/distribution issue.

2024-07-20 14:21:02

- reply

There's no mention of an indexed array. Rust guarantees that nothing can be NULL at compile time. If you need to have optional values then you have to use Option<T> and the compiler forces you to choose how to handle the lack of value.
Array/slice indexing with [] *can* panic (which is still a BSOD but at least guaranteed not an exploit) but it is possible to ban that in the compiler/linter and enforce the use of the .get() method which returns an Option<T>, and such policy would be a good idea for critical kernel code. You can set up a Rust build such that it is *impossible* for any operation to panic, e.g. by making the panic symbol undefined so the project fails to link if it is referenced. This even bans things like unchecked integer division by a non-constant (since div by zero is a panic). All of the panicking operations would have non-panicking versions that you use instead.

2024-07-20 14:10:22

- reply

Like come on, back when I still maintained the little Arch Linux ARM repo for Asahi stuff I had a better process than this. Sure I was doing local builds, but I signed them (with a YubiKey requiring physical touch) and tested them in my local repo before syncing to the CDN.

2024-07-20 14:05:39

One story going around is that the CrowdStrike fail was a file corrupted during postprocessing, between internal testing and the update CDN.
That implies an epic process or design failure. One of the following has to be true
- They don't sign updates
- They do sign updates, but only after internal testing, and never test the final signed files in a production-equivalent setup (bonus: if this is true, their prod signing process is probably automated and not carefully controlled, and could be abused by an insider)
- They do sign updates, but the parsing code that runs *before* signature verification is not carefully audited and has bugs that BSOD on malformed input.
Any one of those is completely unacceptable for a security product.

2024-07-20 10:50:59

- reply

If your memory safe driver returns error 9000 from the initialization routine, your system does not BSOD. That's the whole damn point. Memory safe (and well designed) languages like Rust force you to think about error handling. Yes there is panic, but it is possible to forbid panic by policy/compiler options and truly force all code to use error handling for every possible corner case, and then your code *provably* cannot BSOD the system.

2024-07-20 10:47:47

- reply

My point is that you *can* do those things in Rust and you *can't* in C.
The actual crash here was a NULL deref. That is one of the most classic footguns of memory-unsafe languages (not just those, also others like Java for some reason). In Rust there are no NULLs, only explicit Option<T>s, which *force* you consider the case of there being no value. Yes, you can still just turn it into "panic if no value" but making it an explicit *decision* that the programmer has to make means it's a lot less likely to happen by accident, and it also means you can outright ban that choice by policy and technical means.

2024-07-20 10:44:11

- reply

Broken input data that caused a NULL pointer dereference. Which is a memory safety problem. NULL pointer dereferences are impossible in safe Rust code.

2024-07-20 07:55:27

- reply

The argument is that using a memory safe language would be a *requirement* to be *able* to avoid this class of problems, as evidenced by decades of memory safety bugs. Yes you can write crap code in any language, but it's plainly obvious to everyone who isn't in denial about the state of software engineering that approximately nobody can write correct and memory-safe complex code in memory-unsafe languages.

2024-07-20 02:23:42

- reply

It is completely trivial to deny constructs that can panic in Rust and force people not to use them, which is the point here.

2024-07-20 02:20:09

- reply

It is trivial to set up a Rust build to make panic a compile time error, forcing you to use primitives that don't do that and to handle the errors gracefully.

2024-07-20 02:18:49

- reply

Current rumors is it was broken in a post-processing step, so it might have been signed internally after that, they just never tested the actual final blob that was distributed.

2024-07-20 02:16:36

- reply

No, it's two completely different people.

2024-07-20 02:10:00

- reply

Lots of ARM platforms support 16K pages, but nobody actually *runs* with that configuration except the Raspberry Pi 5 (by choice) and us (by necessity because the IOMMU hardware is hard coded to 16K and Linux can't deal with IOMMU pages > CPU pages without intrusive patches).

2024-07-19 12:24:22

- reply

At least with a memory-safe language someone had to make an *active decision* to reliably crash (making this something solvable by policy, e.g. ban such constructs in the linter), as opposed to no decision at all (which is impossible to protect against or have processes that forbid, once you're using a memory unsafe language).

2024-07-19 12:22:15

- reply

A memory-safe language would force you to make an active *choice* to crash, which at least gives you a chance to, you know, not do that and instead just bypass the update or fail gracefully.
Yes, it is still possible to write crap code for memory-safe languages, but you generally have to do that much more on purpose.

2024-07-19 11:23:43

- reply

The language matters because segfaulting on invalid input only happens in memory unsafe languages. On a memory safe language you generally have to make a conscious decision about how to handle errors and unexpected situations.

2024-07-19 11:07:41

- reply

I think you mean Brad Spengler.

2024-07-19 11:04:48

- reply

Reminds me of gr"let's crash on integer overflows that aren't a security bug, and then ship poorly reviewed 'security' patches that create one such overflow by incorrectly using an unsigned type for a signed quantity, thus creating a local kernel panic DoS that anyone can trigger with a shell one-liner, also we don't count DoSes as CVEs so don't bother responsibly disclosing this but we're going to flame you on Twitter and embarrass ourselves so bad we end up deleting our Twitter account but at least we banned your dynamic IP address from our website and forum, take that!!!!!"security.
(Yes, this really happened after I crashed my grsecurity kernel Gentoo box years ago by pasting too much text into a terminal, then tweeted a repro. I stopped using grsecurity after that.)

2024-07-19 10:56:35

Ah yes, let's ship a kernel driver that parses update files that are pushed globally simultaneously to millions of users without progressive staging, and lets write it in a memory unsafe language so it crashes if an update is malformed, and let's have no automated boot recovery mechanism to disable things after a few failed boots. What could possibly go wrong?
🤦‍♂️

2024-07-18 15:28:41

- reply

Isn't that... most interfaces including the aforementioned Solo?

2024-07-18 13:00:51

- reply

Lots of machines machines *can* run 16K kernels these days, just nobody but us and rPi5 (and maybe some Android work recently) actually *does*.
E.g. Cortex-A53 supports all three architectural page sizes.

2024-07-18 12:56:50

- reply

Since they're a downstream tree like us too, they probably also have their own configs they iterate on instead of testing defconfig (which is why we didn't notice until someone tried an Asahi build with a defconfig-derived config recently).

2024-07-18 12:52:52

- reply

Apparently this is in the ARM defconfig now. So if you do a defconfig on upstream kernels and just flip the page size to 16K (making no other changes), you end up with a broken kernel build.
Yup, definitely nobody tests 16K pages.

2024-07-18 12:32:29

- reply

We only just noticed so there is no fix anywhere as far as I can tell. Kind of impressive that this survived two kernel releases. Just goes on to show that the user base of 16K Linux kernels is approximately O(us) (and rpi 5, but they don't have upstream support for anything yet on that soc afaik).

2024-07-18 12:24:44

PSA for packagers and other ARM distros: Linux v6.9 added support for CONFIG_ARM64_PA_BITS_52 with 4K and 16K page sizes (LPA2). Do not enable this with 16K page size kernel builds, as this combination is completely broken upstream for machines without LPA2 support (you will get random oopses, even though that's supposed to work and fall back gracefully to 47-bit addresses).
Kind of silly that nobody upstream tested this code with 16K pages, as FEAT_LPA2 is all about 4K and 16K page systems specifically, but oh well. C'est la vie.

2024-07-18 05:13:43

- reply

The Focusrite Scarlett Solo is only $100 and has balanced outputs ;)
(The trick is not to search for a "DAC", which is an audiophile term, but rather for an "interface" which is the professional term.)

2024-07-18 04:40:09

- reply

😂
Cables are obviously not subject the $150 rule. My recommendation for cables and passive accessories and the like is "whatever the store brand of your local professional music/audio store is". In Japan I quite like the Classic Pro series from SoundHouse and also cables and adapters from TOMOCA.

2024-07-18 04:36:01

- reply

Nope, but TL;DR is my preference is Focusrite for interfaces, iLoud for monitors, Audio-Technica for mics and headphones.

2024-07-18 04:27:58

- reply

$150 is more in range of a nice condenser for doing nice vocal recordings, if you just need a dynamic indeed you can go lower (sometimes much lower :))

2024-07-18 04:05:21

Seeing some audio equipment discourse and I stand by this rule of thumb: You should be spending $150 on each piece of audio equipment (unless you and knowledgeable enough to know you *need* something fancier).
$150 microphone, $150 interface, $150 headphones, $300 for a pair of monitor speakers.
Sure there's going to be better stuff and cheaper stuff out there, but I find $150 is the inflection point where you're getting actual professional quality without hitting quickly diminishing returns and worse bang per buck.
(This is not to say you have to spend that much, if you're on a budget you can absolutely go with less. But if you can afford this range and are new to this and wondering if you should be spending more, don't.)

2024-07-17 23:30:34

- reply

That is literally exactly what we're doing with the announcement at the top of this thread. Multiple people pointed us toward that solution since almost a year ago, and we finally got around to finishing the integration.

2024-07-17 14:47:23

- reply

The point is that there isn't one "identifier" for compatibility purposes and we don't want to create one. This isn't an nvidia situation where we will have ongoing versioning. So there is no single identifier that whoever wants to roll out the GL driver extensions would be able to use.
On top of that, putting Flatpak changes to autodetermine this stuff upstream or in official Fedora packages makes no sense, because the whole Remix is a Remix for exactly this reason and we keep the UAPI-related things in downstream COPRs for this reason. Therefore, the only option we'd have left is to fork and overlay Flatpak to add Asahi-specific logic in the Remix... and no, sorry, we aren't opening that can of worms, that's way worse than what we're doing now shipping host extensions. We're trying to *reduce* our forked packages, not add to them.
The current solution works for most users/cases, I fail to see how it's a "dead end", and it keeps our workload to a minimum (we just need to bump the Mesa tag name in two more places when we do releases). If and when it "explodes" we can talk about doing it another way.
How the extensions are packaged aside, if you do have a better approach to the actual Mesa build than flatpak-builder, we'd be happy to hear that. But we have no plans to change how we actually ship the extension packaged right now.

2024-07-16 13:11:26

- reply

This is released now as host.

2024-07-16 12:19:44

- reply

Apparently the way it works is that the order is ignored, extensions are sorted in alphabetical order (!), and unmanaged extensions are loaded first.
I had tested `host` installed managed, and that didn't work because d < h. `host` installed as unmanaged does work.
But since it does merge all extensions together, not just the first one found, it means we get file soup with all the pluggable driver config files, and things like one Mesa for OpenCL and another for OpenGL.
In other words, this is poorly thought out enough that I expect fireworks in weird corner cases, and presumably we're the first to try shipping a host mesa like this for real (AIUI until now people only really used this for explicit overrides to a single driver aka mesa-git, and for the nvidia stuff which is its own thing anyway and not mesa so doesn't really conflict with anything).
But yeah, the best we can do is just call ourselves `host` and, if we run into conflicts with stuff that `default` dumps in, start putting in overrides or making sure we build enough things to overlay everything from it. Sigh.

2024-07-16 03:54:00

- reply

The logic in the code is that FLATPAK_GL_DRIVERS overrides everything, so you have to explicitly specify host and default.

2024-07-16 02:17:30

- reply

No, because default takes priority over host, breaking us instead if installed. I already tested that.
What we need to do is just set the env var to asahi:default:host probably (to keep the original 2 entries as fallback).

2024-07-15 21:08:39

- reply

Yeah, this is definitely *not* the way to go. It's a bad idea to teach Flatpak itself about a concept which is *deliberately* temporary and not upstream anywhere. It's not upstream for a reason. This isn't like Nvidia who make a point of never having a stable UABI ever.
I would NAK such a change in Flatpak (for whatever that's worth) and would not ship this solution in our distro, it's policy-wise absolutely the way to go. Shipping extensions in the downstream distro, which already ships the unstable Mesa and can control release cadence makes a lot more sense.
An example of how this breaks down: sometimes there are kernel *bugfixes* that are required for a new Mesa driver to work, but do not break the UABI or increment the version. We are in the process of releasing one such Mesa fix right now, after we just released the kernel it requires. Flatpak cannot control for such dependencies related to bug fixes, potentially breaking everyone whose distro still has an older kernel.

2024-07-15 20:59:21

- reply

Is that fixable by specifying a fallback of the "default" GL driver in the env var? It would be helpful if you could test that.

2024-07-15 06:50:28

- reply

No, I mean, that's not a thing. Gadget hardware is not the same as host hardware. You cannot load gadget drivers on 99% of x86 systems, the ports are host only (except for maybe debug mode, but that's a special case). The standard xHCI spec is purely host.
Gadget hardware is only common in embedded systems (including Apple Silicon Macs, but there only on Type C ports of course).

2024-07-15 02:48:28

- reply

Gadget mode is not supported over Type A (at least not by standard). Systems with Type A ports that can be forced to gadget mode in a non-standard way are few and far in between. Standard xHCI host controllers do not support gadget mode, you need dedicated gadget hardware.
But I don't really see where gadget mode fits into any of this? We're talking about normal host mode usage of Type A ports at 10Gbps.

2024-07-15 02:46:18

- reply

Yes.

2024-07-15 02:45:30

- reply

Native Type C ports with the internal TB/USB controller support 10 Gbps on all Apple Silicon machines and are advertised as such.

2024-07-15 01:56:06

- reply

iPhones and iPads do not have external USB controllers nor Type A ports at all.

2024-07-15 01:49:43

- reply

It's a x1 3.0 link at 8 GT/s < 10Gbps, so yes, it's very slightly bottlenecked... (quick throughput test with an SSD, I get around 85% of the throughput I do on the native Type C ports)
... but then they're lying about the *Type C* ports on the machines with those being capable of 10Gb/s! It's the same exact controller with the same exact PCIe bottleneck.

2024-07-15 01:43:26

- reply

? That's never going to work between two Type A host ports which are host-only mode.
Again, plain vanilla USB3 A to C cables (or A to B for that matter) work just fine at Gen2 10Gbps between a capable host Type A port and a capable device. That's how I got the dmesg log in my original post.

2024-07-15 01:40:39

- reply

E-markers are also used for data and are required for 20Gbps USB3 and TB3/4 operation. That's why I'm saying that if 10G USB3 operation required special cables, they'd have made it require an emarker, which they didn't.
https://www.reddit.com/r/UsbCHardware/comments/13j0gev/do_usbc_to_usbc_cables_need_an_emarker_chip_to/jkdbi7n/

2024-07-15 01:26:25

- reply

There is no e-marking or anything like that for this. The cables are the same, and the spec is designed to work with the same cables. If 10Gbps required special/certified cables for some reason it would have been limited to Type C only with e-markers, which it isn't.

2024-07-15 01:19:41

- reply

Yes of course, it's the same as Type C. Gen 1x2 uses both lanes of Type C at 5Gbps each (so, can't work over Type A) but Gen 2x1 uses one lane at 10Gbps and therefore works just fine over Type A.

2024-07-15 01:15:53

TIL Apple apparently advertises the Type A ports on Mac Minis and Mac Studios as 5 Gb/s even though they actually support USB 3.1 Gen2x1 10 Gb/s on everything except the original M1 Mac Mini 🙃 usb 2-1: new SuperSpeed Plus Gen 2x1 USB device number 2 using xhci_hcd

2024-07-15 00:18:32

- reply

box64 does not support Windows software on Asahi directly due to page size issues (it's only usable for 64-bit Linux software). FEX can run 32-bit software though (including Windows stuff on Wine/Proton), but needs a VM to fix the page size mismatch. We're working on it.

2024-07-15 00:14:27

- reply

If it's one of those portable displays with both Type C and HDMI, I think you can just use both? Type C should still provide power, just not video (though of course, 2 cables is more annoying than one...)

2024-07-14 18:26:39

- reply

Note: that guide is out of date, don't attempt to follow it. Actually don't attempt to follow any guide for this until we ship it to end users properly please.

2024-07-14 18:24:23

- reply

Not on ARM64 systems, and Flatpak itself doesn't have GPU support even for ARM64 flatpaks, though I'm literally fixing that today.

2024-07-14 18:22:47

- reply

Steam and Steam games are x86 apps and require a huge pile of voodoo magic including microVMs to make work on ARM64 systems. We're working on it (@npub1cxq…6wtz has been testing it) but it's far from ready to ship to end users right now.
Good news is once it *is* ready we fully intend to beat Apple/macOS at it, because we actually have standards-conformant graphics drivers and they don't :)

2024-07-14 18:20:26

- reply

Not supported yet, sorry. Probably soon though. It's listed as not supported on our hardware status table:
https://asahilinux.org/fedora/
HDMI does work though, if you have that (for machines with HDMI ports, not converters).

2024-07-14 18:16:10

- reply

USB3 is known to be kind of dodgy requiring replugs sometimes. @npub1jzz…687j is on it and it's a known bug. Type C stuff is... quite an adventure to fully support properly and reliably, because it requires getting 6+ kernel subsystems coordinating with each other correctly (Type C PD, PHY, USB, DP, TB, PCIe).
There's also the tangential problem of the U-Boot USB stack being rather... questionable, but that rather manifests as hangs on boot if you have an unlucky USB device connected.

2024-07-14 09:43:48

- reply

Por norma general no, pero comprueba si el dispositivo se conecta como High Speed (USB2.0) o SuperSpeed (USB3.0) (se ve en el log del kernel). Si por algun lío del driver USB lo reconoce como HS, entonces iría más lento.
Así probando, con un disco USB3.0 Gen2 de alto rendimiento no tengo problema copiando a 900MB-1GB/s en ambas direcciones con Asahi (que es el límite de la conexión).
En general las tareas de I/O son mas *rápidas* en Linux que en macOS (porque Linux tiene un subsystema de I/O y sistema de ficheros mucho más optimizado), aunque eso se nota más con muchos archivos pequeños que con pocos archivos grandes.

2024-07-14 07:38:04

Every now and then people ask about installing Asahi Linux to external storage. This is not supported for various reasons, including some bugs and lack of testing, but most of them can/will be fixed.
However, there is one major component missing for us to officially enable real external installs: a Rust implementation of an xHCI USB driver stack and USB mass storage (and basic hub support). We need this so m1n1 stage 1 can load m1n1 stage 2 from USB, allowing us to take advantage of Apple's "fake external install" flow and avoiding any repartitioning of the internal disk entirely, while otherwise keeping our boot chain the same as for internal storage without sacrificing upgradability or usability.
So if you want to see Asahi installable to external USB disks, that's where we could use some help :-)

2024-07-10 11:34:54

- reply

Maybe but on iPhones it's even more dead these days, since XNU sets and locks many security-related registers that cannot be reset without a reboot.

2024-07-10 11:32:37

- reply

We don't have UEFI variable support right now, so there is no such thing as multiple EFI boot options on our platform. You always get the removable media default EFI boot filename.
By password resets I mean booting with init=/bin/sh and running passwd.
> For mode advanced recovery procedures use a recovery partition like on Windows PC.
Mac recoveryOS cannot mount Linux filesystems, and setting up a whole separate OS container just for recovery purposes is overkill and impractical for multiple reasons. We are looking into some kind of VM setup to run Linux recovery in macOS/recoveryOS, but as you can imagine it's not something trivial to build and deploy.
Point being, there are good reasons to use a standard bootloader and it's not something you can just throw away without spending a lot of engineering time building tooling to replace it.

2024-07-09 17:59:43

- reply

Bootloaders are important for boot recovery, e.g. from a broken kernel/initramfs install or to do password resets or tweak kernel params to work around boot issues.

2024-07-09 17:52:15

- reply

Aaaand of course that doesn't handle multiple ESPs properly.
If someone had pinged me about this I'd have told them to stuff the PARTUUID in `RTStorageVolatile`. Just having the filename and no reference to the ESP is... quite dumb given the existence of removable storage that can have an ESP, without even going into multi-ESP systems like ours. But it looks like that got merged into U-Boot already :(.

2024-07-09 17:29:27

- reply

Aha. Looks like it only affects EOL versions of Fedora though, so the `-e` mitigation still applies to current versions. I'll update the post.

2024-07-09 13:15:08

- reply

Good to know someone's finally working on this... but yeah, until that userspace component exists (and ideally it should be something pretty standard if this is going to get any traction) it's not very useful.