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

nprofile1qqsqtzndzpk9ueceqzxwfkelvnyydjh5nyjjy73e2v7392zxlw4jrmspz3mhxue69uhhyetvv9ujuerpd46hxtnfduqs6amnwvaz7tmwdaejumr0dsqrs7nk

Publishing to

relay.damus.io

nos.lol

Author Public Key

npub1qk9x6yrvten3jqyvundn7exggm90fxf9yfarj5eaz25yd7aty8hqe9azpx

Show more details

Last Notes

2024-09-05 14:38:38 UTC

- reply

The email is legit, it's just addressed to another email address. You can legitimately receive this email from PayPal addressed to you.

2024-09-05 10:49:04 UTC

Heh, just got an interesting scam email. It's a payment request from paypal.com for something random that has nothing to do with me.
It's a legitimate email, the body links all go to the right place, the sender is service@paypal.com. It passed all DKIM checks and antispam checks.
The trick? It's not addressed to me. They got PayPal to send a legitimate payment request to a special address which then forwarded the email to me, through Outlook/Microsoft servers before reaching mine (so they have good reputation too).
When you click the payment link, you get a legitimate PayPal login and payment request with this little tagline:
> We'll link fake@address.com to your PayPal account when you log in.
So not only do they not check that the email that the request was sent to is the actual account owner, they will "helpfully" link it in and consider this action as equivalent to an email address ownership confirmation! What are the implications of this? Who knows! Maybe it means they could issue password resets via that address then?
Scary, though I guess not unsurprising security fail from PayPal.

2024-08-26 09:03:00 UTC

- reply

Because the SuperSpeed lanes don't pass through the Type C chip, they connect directly to the PHY. The Type C chip only deals with the power control, CC lines, and muxing sideband signals.
It is possible to externally mux the lanes and have the Type C controller control that mux, but that would be expensive and redundant, since if you have a unified PHY for USB with dual lane support swapping lanes in silicon is basically free (and better for signal integrity). So nobody uses an external mux if they can help it for full spec controllers.

2024-08-26 08:59:23 UTC

- reply

I used to use it (on x86) to run a dev/ops environment for an event VM cluster at home. We'd take backups from production VM servers and VMs after closing and I'd run them in one VM per physical server, with the same IP connectivity setup as prod so it would just work. Then I could work on things at home and dump them back on prod next time.
It was all running from a single USB SSD and set up in a way that I could USB boot it on any machine, so it also served as an emergency backup environment. If everything went wrong, we could boot it on a random laptop and continue minimum service from that.
The nested VMs definitely had *some* perf impact but it wasn't a showstopper.

2024-08-26 08:43:03 UTC

- reply

Because typically the USB Type C controller and the USB Host Controller are two completely separate chips and pieces of hardware with no ability to communicate with each other directly since they have completely different goals and implementation details.
So it's up to the host driver to query the Type C controller for orientation status and tell the Host Controller/PHY how to set up its lane muxes to match.
Yes this is the bane of people writing Linux drivers like us, it means we have to coordinate across something like 5 Linux driver subsystems to make all of this worok.

2024-08-26 08:37:49 UTC

- reply

I'm all for Signal and E2EE and distributed systems and all that, but... Telegram is, by far, the least-bullshit most-fun messenger I've ever used. Everything just seems to work, it's lean, has native open source client apps, a big pile of features *that are cohesively integrated* and *work*, API/bot support, useful stuff like automatic translation (premium feature, but that's understandable since translation APIs aren't free), etc.
Other platforms would do well to learn from it.

2024-08-26 08:33:57 UTC

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-25 20:02:12 UTC

- reply

It's hardware for the USB 2 pins (they are just connected through usually). It's software for the USB 3 pins (lanes swap around).
So cheap noncompliant Chinese stuff without a mux for the USB 3 lanes ends up enumerating as USB 2 High Speed in one orientation and USB 3 SuperSpeed in the other.

2024-08-18 15:51:03 UTC

- reply

If it does not hold up in court, that's the "does not work" part of my argument.

2024-08-18 15:42:41 UTC

- reply

(And I disagree with that argument and would love to see it work in front of a judge, which I've yet to see.)

2024-08-18 15:33:02 UTC

- reply

And the point is that's not true. If you write a document with Microsoft Word and export it as PDF, Microsoft doesn't own copyright over your document, only you do. This is extremely well established, and the SaaS use case does not change it.

2024-08-18 15:28:46 UTC

- reply

Yes, but that doesn't matter, that's just an encoding. What is copyrighted is 1) the resulting sequence of notes from playing the sheet music (this is what survives when you play it), and 2) the specific sheet music in terms of layout on the page/etc (this just relates to the sheet music itself, e.g. photocopying it or re-transcribing it one to one).

2024-08-18 15:21:19 UTC

- reply

Uh, no. *Music itself* is copyrighted. The notes. Playing music isn't "executing" sheet music in the software sense, it is *interpreting* sheet music where the output (your performance) continues to contain the same notes, which are copyrighted. Melodies are explicitly copyrightable.
The software equivalent would be running the server app under an execution tracer that streams back every instruction executed to the user, but that's again not how SaaS works.

2024-08-18 15:05:28 UTC

- reply

Can you please cite legal precedent for this interpretation?
When you "transmit" a "work" you are transmitted *what is copyrighted*. What is copyrighted is the work itself. This is what happens when you, say, show a movie to an audience. The audience perceives *the copyrighted work itself*.
When you "make available" software to the public you are *not* transmitting the copyrighted work itself. You are making available the *result* of *executing* the copyrighted work itself.
You can violate copyright by filming a movie in a theater. You cannot violate copyright by reproducing the output of a query to a SaaS service (at least not the software's copyright anyway, the data could be separately copyrighted).
This distinction is evidently legally relevant and it is irresponsible to dismiss it and claim it does not exist.

2024-08-18 11:50:56 UTC

One of the *fundamental* qualities of FOSS is that FOSS licenses are *purely copyright licenses*. What this means is that their terms apply solely when software is copied or modified, which are actions which are controlled by copyright law, but *not* when you merely use the software yourself.
This is a well-understood concept. The FSF [explains this](https://www.gnu.org/licenses/gpl-faq.en.html#ClickThrough ) in the context of the GPL. @npub16uv…lz0y also [wrote about this](https://flameeyes.blog/2020/03/23/the-gpl-is-not-an-eula/ ) (hi, I found your relevant blog post first this time! :P).
This has *significant* implications, it's not just a curiosity. A license that imposes conditions on mere *usage* requires some form of click-through setup. Not having that would cause those usage terms to be thrown out by most courts, as there is no way for the user to be informed of the EULA and their obligations under it. You cannot agree to what you are unaware of.
This is a *critical* legal distinction, because these EULA terms work *outside* of the framework of copyright law. Copyright law itself requires no click-through EULA: you can violate copyright law even if you are unaware of the terms and conditions, and it is the distributor's or editor's responsibility to comply with all appropriate licensing and copyright requirements when engaging in those actions. But mere *usage* of software that you have lawfully obtained does not invoke copyright law (modulo technicalities about "running software being a copy to RAM", but that's a whole separate [can of worms](https://open.mitchellhamline.edu/cgi/viewcontent.cgi?article=1037&context=cybaris ) with conflicting legal precedent, and the practical fact that if mere RAM copies are in fact copyright infringement then all of us would be committing copyright infringement every day, all day, in a huge number of situations).
Put simply: a piece of software entirely devoid of a license agreement can be hosted on the creator's website, and the default protections of copyright law apply. You are not allowed to redistribute it, but you are allowed to download it and run it for your own personal usage.
This distinction is encoded in the policies of many distribution FOSS projects, like Linux distributions. For example, [Fedora only allows FOSS licenses](https://docs.fedoraproject.org/en-US/legal/license-approval/ ), and Gentoo [accepts all "FREE"] licenses by default(https://gitweb.gentoo.org/repo/gentoo.git/tree/profiles/license_groups). This is representative of a very important point: neither of those distributions requires you to read or accept any of those licenses. The assumption is that anything considered "free" is purely a copyright license and that you, as a user, can just go and install distro packages and not read any licenses and be perfectly fine, and nothing you do short of redistributing the software itself could possibly violate them.
But now we have a problem. Notice how both the Fedora and Gentoo allowed license lists include the EUPL. But the EUPL Article 5, if interpreted literally and assuming no other license conditions override it, imposes restrictions on mere usage: it is an EULA. If you download and use EUPL software, and then run it on a server, then the license *requires* you to ensure that users of your server are offered the complete and correct source code to the software running on your server.
But how are you, as a user, supposed to know that? If you install software on Fedora or Gentoo the normal way, the system doesn't even tell you what license the software is distributed under, much less ask you to accept its terms. It's not supposed to be necessary, because FOSS licenses are supposed to be licenses and not EULAs.
Now, since there is no license prompt, if a user were to actually do this, things get really weird. Let's say you run Gentoo or Fedora, install an EUPL package, and run it on a server without ensuring there is a source offer to its users, particularly in cases where the server action does not distribute the code itself (this gets messy with webapps with HTML/JS/CSS, so let's assume this is a simple database server). Now you are violating Article 5 of the EUPL... but you never agreed to said license terms, so courts are highly unlikely to find you liable for it.
So who is liable? Are the distros? Is it a distro's job to ensure that end-user relevant license agreement terms are shown to users of its packaged software? Nobody knows... but then we reach the logical conclusion: either the EUPL is toothless because it is being treated as a non-EULA and users aren't being required to agree to its terms... or distributions themselves are in violation by not ensuring it is displayed to users.
Linux distros might want to think twice about OSI's idea of FOSS licenses and whether they really want to carry software licensed under licenses with clear usage restrictions, regardless of what OSI says is free or not.
Or perhaps the EUPL just doesn't protect against SaaS in practice, regardless of what its authors may claim.

2024-08-17 19:51:18 UTC

Someone had me look at the EUPL as a license that is supposedly free and OSI certified and closes the SaaS loophole and... IANAL but I don't like what I see.
https://social.treehouse.systems/@marcan/112979037685332699
I firmly believe it is not possible for a license to be both Free Software (specifically, respecting Freedom Zero: The freedom to run the program as you wish, for any purpose) and close the SaaS loophole at the same time.
Either you interpret the EUPL such that it closes the SaaS loophole, or you interpret it such that it upholds Freedom Zero. You can't have both.
Unfortunately, Freedom Zero is absent from the OSI definition of free software, which allows the EUPL to be OSI certified. This is a glaring omission from the Open Source Definition, as it quite literally allows EULAs (you can attach a requirement that all users pay a usage fee to a license and, if you read carefully, that doesn't violate any of the OSI OSD requirements!).
TL;DR either the EUPL is just another FOSS license that doesn't close the SaaS loophole, or it is a nonfree EULA. You can't have your cake and eat it too, regardless of what OSI says.

2024-08-17 11:09:20 UTC

- reply

No, if the GPU driver is not linked in a way that would subject the network side of the software to the AGPL terms, there is absolutely *nothing* that would stop someone from using and modifying an AGPL GPU driver and deploying it in conjunction with a network service and not offering source. The license is very, very clear that Section 13 only applies modification and cases where the AGPLed software itself is capable of network interaction.

2024-08-17 10:35:55 UTC

- reply

Unfortunately the preamble is not legal text and means nothing, it's just a way for the FSF to distract from their horrible hack and further muddy the interpretation.

2024-08-17 10:08:31 UTC

- reply

I dunno, nobody seems to have trouble joining and having a good time as long as they aren't an edgelord who supports harassing minorities and *checks notes* genocide.
https://fosstodon.org/@drewdevault/111363547103465966

2024-08-17 09:23:08 UTC

- reply

That interpretation flies in the face of the parenthetical immediately after:
> (if your version supports such interaction)
Which makes it crystal clear that this is about support and capability, not actual usage.

2024-08-17 09:09:25 UTC

Apparently the new Hyprland compositor backend breaks
on Asahi (and probably also every other kmsro system and system with interesting buffer format restrictions, like Mali/Qualcomm/etc).
The author isn't sure what they're doing wrong. Of course, the solution is for them to talk to the Freeresktop/Mesa/DRM community, which is where all the knowledgeable people about all these subtleties are...
Oh wait 🙃
Getting banned from the Linux Graphics community: not recommended if you want to be writing a Wayland compositor.
Either way, this isn't an Asahi problem, so please don't file bugs with us.

2024-08-05 19:05:05 UTC

- reply

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

2024-07-29 13:09:33 UTC

- 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 UTC

- 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 UTC

- 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 UTC

- 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:19:31 UTC

- 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 UTC

- 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 15:54:30 UTC

- 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 UTC

- 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 13:17:51 UTC

- 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 12:53:04 UTC

- 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 UTC

- 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-22 00:43:36 UTC

- 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 UTC

- reply

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

2024-07-20 14:36:39 UTC

- 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 UTC

- 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:18 UTC

- 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 UTC

- 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 UTC

- 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 UTC

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 UTC

- 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:44:11 UTC

- 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 UTC

- 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 UTC

- 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 UTC

- 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:10:00 UTC

- 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 UTC

- 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 UTC

- 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 UTC

- 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 10:56:35 UTC

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 12:52:52 UTC

- 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 UTC

- 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 UTC

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 04:40:09 UTC

- 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:05:21 UTC

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 14:47:23 UTC

- 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 12:19:44 UTC

- 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 UTC

- 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 UTC

- 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 UTC

- 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 UTC

- 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 02:46:18 UTC

- reply

Yes.

2024-07-15 01:56:06 UTC

- reply

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

2024-07-15 01:49:43 UTC

- 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 UTC

- 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:26:25 UTC

- 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 UTC

- 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 UTC

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:14:27 UTC

- 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:22:47 UTC

- 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 UTC

- 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 UTC

- 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 UTC

- 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 UTC

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:32:37 UTC

- 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 UTC

- 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 UTC

- 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 13:15:08 UTC

- 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.

2024-07-09 11:31:32 UTC

- reply

We also don't have UEFI variable support since that is also currently impractical on platforms that don't have arbitrary firmware-owned storage like ours, because even though this problem has bit people many times already nobody has bothered to standardize any mechanism for storing variables in OS-owned storage 🙃

2024-07-09 10:47:12 UTC

- reply

There is no firmware (in the sense of UEFI). u-boot is the first component that provides something you might call "firmware" in the sense of a platform you run other code on (its UEFI environment). That's why we use it.
m1n1 itself has NVMe block support and a FAT32 driver which it uses to load its second stage and u-boot, but it does not export itself as any kind of API like UEFI.

2024-07-09 10:41:58 UTC

- reply

See my reply here. Nvram exists but we have no interest in messing with it for Linux. Its purpose is to store machine-global data and Apple is the only entity that defines how it is used. We long ago considered and discarded the idea of using it for e.g. our own EFI variable storage. Too big a can of worms.
This is one of those things where I put on my project lead and person-with-a-reputation-for-not-bricking-machines hat on and say we are absolutely not going in this direction.
https://social.treehouse.systems/@marcan/112756100417976263

2024-07-09 06:46:00 UTC

- reply

Other than the PMU counter, all usable storage is just NVMe. If you want to make state changes from Linux it has to be by writing to files in the ESP (or equivalent).

2024-07-09 04:56:59 UTC

- reply

We have U-Boot UEFI so if you can at least have some indirection at the EFI layer to select a kernel and do the "last known good booting" logic that would be good enough. We're not married to GRUB, any reasonable UEFI loader approach should work.
We just don't have EFI variable storage so you can't do it with the regular UEFI boot config, it has to be another layer (right now). The only storage available for EFI vars is NVMe, so there is no way to have EFI runtime services that allow variable access, i.e. if you enable EFI var support in U-Boot then you need Linux to understand its var storage format file and write to it directly, since there's no way to provide post-ExitServices runtime variable services.
The platform *does* have a boot failure counter in the PMU (currently reset by the Linux driver unconditionally), which at 5 (IIRC) triggers Apple's boot recovery (useless to us). So you could check for, like, 3 or 4 and boot a different kernel in that case. But then you still need some logic somewhere to implement that (and probably a tweak to the Linux driver to not reset it automatically, but rather wait for a userspace signal).
(We also have the whole thing with multiple ESPs for multiple installs and a device tree property to identify it, but that's platform-specific logic you would have to add anyway)

2024-07-09 04:44:07 UTC

- reply

I replied about that here: https://social.treehouse.systems/@marcan/112754677717402013
TL;DR it's a big can of worms and creates ABI between different kernels.

2024-07-09 04:42:37 UTC

- reply

Unclear if we can hack around things for very specific cases such as this. NVMe is one of the peripherals that *can* be brought back to a shutdown state cleanly (of course, since the regular bootloader chain has to be able to use it) but I'm not sure how plausible/reliable it is to clean up after an *abrupt* crash that doesn't do a clean shutdown.
You would have to use a kdump kernel that is very minimal and doesn't include any drivers for other complex hardware (display, GPU, etc.) since all that would be in an unrecoverable state.
Then we have the whole CPUs initialized using spin tables that don't work with kexec() problem.
So basically, it *might* be possible but someone would have to spend a bunch of time making that precise use case work, because it's not trivial.

2024-07-09 04:37:23 UTC

- reply

The amount of shared firmware/kernel state is very high for some devices. It includes things like page tables and memory mappings. It's not *impossible* but it's not easy, and it would essentially create an "ABI" that future kernels have to abide by to allow kexec()ing into them. I'm not sure if we want to jump into that can of worms.

2024-07-09 03:02:19 UTC

So Red Hat is doing another "replace the bootloader with Linux" thing...
Reminder that not all platforms support or, ineeed, *can* support kexec() sanely at all. Like ours. kexec() requires the ability to reset all peripheral state and that is *impossible* on Apple Silicon because firmware is loaded by earlier boot stages and cannot be re-loaded later to the reset state without a full system reboot.
https://pretalx.com/devconf-cz-2024/talk/W3AVCT/

2024-07-06 01:05:39 UTC

- reply

It doesn't have all the system libraries in the dyld cache. We have to ship libffi for this reason (to make the installer work in recoveryOS). So you do have to be a bit careful.

2024-07-05 11:09:16 UTC

- reply

I would rather keep the Python and use PyQt or something :P

2024-07-05 09:51:22 UTC

We know the Asahi Linux install process is mildly awkward, with the multiple reboots and power button hold dance, plus having to set Asahi as default boot unconditionally. It's like this due to platform requirements.
Please don't open issues and waste our time asking whether it can be improved. We are already using all the tricks in the book to make it as painless as possible.
If you think you can do better, then implent a proof of concept, test it, and submit a PR. We'll gladly merge it if there are things we missed that can make the process easier.
But unless you can do that, please don't just open bugs on GitHub. Chances are whatever idea you have was already considered and can't fundamentally work, or is too dangerous/awkward to be worth implementing.

2024-07-02 07:49:12 UTC

OpenSSH CVE-2024-6387 mitigation (on Fedora):echo 'OPTIONS=-e' | sudo tee -a /etc/sysconfig/sshd && sudo systemctl restart sshd
I have no idea why Qualys didn't mention this. The only non-async-safe function called by the vulnerable signal handler is syslog(). So just turn off syslog and log to stderr. On systemd distros, this still ends up in the journal anyway, so you lose nothing.
I confirmed that the message at the root of the issue is logged to stderr and not syslog with this option:<code>[pid 638194] --- SIGALRM {si_signo=SIGALRM, si_code=SI_KERNEL} --- [pid 638194] getpgid(0) = 638194 [pid 638194] getpid() = 638194 [pid 638194] rt_sigaction(SIGTERM, {sa_handler=SIG_IGN, sa_mask=~[RTMIN RT_1], sa_flags=SA_RESTART}, {sa_handler=SIG_DFL, sa_mask=~[KILL STOP RTMIN RT_1], sa_flags=SA_RESTART}, 8) = 0 [pid 638194] kill(0, SIGTERM) = 0 [pid 638194] getpid() = 638194 [pid 638194] write(2, "Timeout before authentication for 192.168.21.10 port 37734\r\n", 60) = 60 [pid 638194] exit_group(1) = ? [pid 638194] +++ exited with 1 +++ </code>

2024-06-11 07:14:02 UTC

- reply

No, they beat us at that but barely... but only on M3 apparently? Linux NV support isn't fully upstream yet but it's been *developed and tested* on M2 so I have no idea what's up with that.

2024-06-11 07:05:38 UTC

Apparently Apple just announced hardware-accelrated GIC support for Apple Silicon virtualization. Asahi Linux has had that feature for over two years now. Glad they caught up supporting features of their own hardware! 😁

2024-05-28 05:15:53 UTC

So I just pushed a kernel fix for Asahi Linux to (hopefully) fix random kernel panics.
The fix? Increase kernel stacks to 32K.
We were running out of stack. It turns out that when you have zram enabled and are running out of physical RAM, a memory allocation can trigger a ridiculous call-chain through zram and back into the allocator. This, combined with one or two large-ish stack frames in our GPU driver (2-3K), was simply overflowing the kernel stack.
Here's the thing though: If we were hitting this with simple GPU stuff (which, yes, has a few large stack frames because Rust, but it's a shallow call stack and all it's doing is a regular memory allocation to trigger the rest all the way into the overflow) I *guarantee* there are kernel call paths that would also run out of stack, today, in upstream kernels with zram (i.e. vanilla Fedora setups).
I'm honestly baffled that, in this day and age, 1) people still think 16K is acceptable, and 2) we still haven't figured out dynamically sized Linux kernel stacks. If we're so close to the edge that a couple KB of extra stack from Rust nonsense causes kernel panics, you're definitely going over the edge with long-tail corner cases of complex subsystem layering *already* and people's machines are definitely crashing already, just perhaps less often.
I know there was talk of dynamic kernel stacks recently, and one of the issues was that implementing it is hard on x86 due to a series of bad decisions made many years ago including the x86 double-fault model and the fact that in x86 the CPU implicitly uses the stack on faults. Of course, none of this is a problem for ARM64, so maybe we should just implement it here first and let the x86 people figure something out for their architecture on their own ;).
But on the other hand, why not increase stacks to 32K? ARM64 got bumped to 16K in *2013*, over 10 years ago. Minimum RAM size has at *least* doubled since then, so it stands to reason that doubling the kernel stack size is entirely acceptable. Consider a typical GUI app with ~30 threads: With 32K stacks, that's less than 1MB of RAM, and any random GUI app is already going to use many times more than that in graphics surfaces.
Of course, the hyperscalers will complain because they run services that spawn a billion threads (hi Java) and they like to multiply the RAM usage increase by the size of their fleet to justify their opinions (even though all of this is inherently relative anyway). But the hyperscalers are running custom kernels anyway, so they can crank the size down to 16K if they really want to (or 8K, I heard Google still uses that).

2024-05-23 10:39:26 UTC

Just had another argument about curl|sh, so I'm going to say this top level for future reference.
The way we use curl|sh is as secure, or more secure, than traditional distro distribution mechanisms (e.g. ISO images with hashes or PGP signatures) for 99.9% of users. If you think otherwise, you don't understand the threat models involved, and you're wrong.
If you are in the 0.1% that actually cross-references PGP keys against multiple sources, exchanges keys in person, and that kind of thing, then you could indeed actually benefit from a more secure distribution mechanism. You're also, unfortunately, not a significant enough fraction of our user base for us to spend time catering to your increased security demands, that we could instead be spending improving security for everyone (such as by working on SEP support for hardware-backed crypto operations, or figuring out how to actually offer FDE reasonably in our installer).
And if you're not, but curl|sh still gives you the ick even though you have no solid arguments against it (you don't, trust me, none of you do, I've had this argument too many times already), that's a you problem.

2024-05-13 09:15:05 UTC

PSA: If you need to bring controlled medications into Japan, *this* is the page you should be looking at:
https://www.ncd.mhlw.go.jp/en/application2.html
Tooting this because there is a lot of misinformation and outdated information out there, and that page is kind of hard to find.
TL;DR psychotropics like lorazepam are okay up to a maximum total amount, without any documentation. Concerta/Ritalin is considered a psychotropic and likewise is perfectly okay up to a maximum without any docs (or more with docs/permission). Vyvanse is also allowed but considered a stimulant and requires special permission for any quantity. Adderall is banned and highly illegal, don't even think about that one.