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

[email protected]

Profile Code

nprofile1qqsqtzndzpk9ueceqzxwfkelvnyydjh5nyjjy73e2v7392zxlw4jrmspqqlk4l5e

Publishing to

Author Public Key

npub1qk9x6yrvten3jqyvundn7exggm90fxf9yfarj5eaz25yd7aty8hqe9azpx

Show more details

Last Notes

2024-09-05 22:57:03 CEST

- reply

That's correct.
I did forward the email to them, no idea if they'll care though.

2024-09-05 16:59:32 CEST

- reply

It's actually how PayPal payment requests work, I just tested it. It seems they take the recipient email, cut it off at the TLD, use the left part as "name" and the right part as "surname". There's a suspicious space there. It's PayPal doing all this, I tested it myself.

2024-09-05 16:42:32 CEST

- reply

It is a legitimate email sent by paypal.com to an email address, just not my email address. The payment request in and of itself is illegitimate, but real and actually processed through paypal.com

2024-09-05 16:38:38 CEST

- 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 12:57:25 CEST

- reply

My email client displays To: [email protected] of course, but that's easy to miss.
The email body also starts with Hello, [email protected]... in tiny barely readable grey-on white text. 🤦‍♂️

2024-09-05 12:55:05 CEST

- reply

I had that happen with Venmo, I still have no way to get rid of it.

2024-09-05 12:54:41 CEST

- reply

The envelope sender after the redirect ends up being a microsoft-hosted address, so that passes SPF on my end. I guess this is all "working as intended" since forwarding emails is supposed to work (otherwise mailing lists wouldn't work).

2024-09-05 12:49:04 CEST

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 [email protected]. 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 [email protected] 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-29 19:28:01 CEST

- reply

I got around to testing this and no, edge palmdet still sucks on Apple trackpads. Even with the fixed trackpad dimensions, at least on 16" models, it causes noticeable deadzone behavior on the left/right/top and stuff like touches being completely ignored if they come in from those edges and move towards the center slowly enough. That's not acceptable.
@npub1ysq…xd3s can you test libinput with this reverted?
https://gitlab.freedesktop.org/libinput/libinput/-/commit/4a8b5e6ec445b507fc0b1ef9842a60bf13c58772
If it fixes your issues then we need to file a bug on libinput to make edge palmdet less aggressive so it can be enabled again. If it doesn't then libinput needs some other algorithm or tweak to help palmdet for the tap-to-click case on Apple.

2024-08-26 19:27:11 CEST

- reply

Note that this is *not* an attempt to praise all of Telegram and in particular any specific behaviors of the underlying company and developers.
I'm just saying the UX is by far the best I've used, nothing more.

2024-08-26 19:23:08 CEST

- reply

Signal does E2EE as well as it can be done, but due to its laser focus on E2EE it misses out on functionality that is not practical to build with E2EE.
Matrix is precisely an example of trying to E2EE everything while having more features and ending up with a mess as a result.
And yeah the Signal desktop client is... rather questionable. Telegram is way better.

2024-08-26 11:03:00 CEST

- 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 10:59:23 CEST

- 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 10:43:03 CEST

- 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 10:39:48 CEST

- reply

Yup. Definitely the Electron thing.

2024-08-26 10:37:49 CEST

- 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 10:33:57 CEST

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 18:04:01 CEST

- reply

This might only happen on non-ProMotion displays, we haven't tested ProMotion ones. Totally possible that they aren't affected since they have a very different backlight control system.
So I guess the exact opposite of last time when they broke ProMotion only.

2024-08-25 13:33:40 CEST

- reply

We disabled the palm rejection code in libinput for Apple trackpads because it was making some machines completely unusable due to (I think) trackpad size mismatches. I *think* this is fixed now but someone needs to test it and see if it can be re-enabled again.

2024-08-25 12:30:45 CEST

Pro tip: If you send me an email advocating for bigotry to try to change how I run my projects, all you're going to do is earn yourself an entry in my killfile. 👋

2024-08-20 11:50:58 CEST

- reply

If the software itself is being illegally distributed/modified and you are aware of that fact, I'm pretty sure you can get in trouble for that.

2024-08-20 11:41:59 CEST

I should spend more time writing documentation...
https://social.treehouse.systems/users/AsahiLinux/statuses/112990528901633785

2024-08-20 11:40:40 CEST

- reply

Licenses cannot prevent you from using a product if you are unaware of the license. I can burn a CD with some music I made, put a license file in some raw empty space on a data partition that says you can't listen to it, give it to you. If I try to sue you because you listened to it, the courts are going to laugh me out the door because there was no way you could have known of the existence of the license.
This is the purpose of click-through EULAs. Without them, there is no way for the user to be aware of the usage restrictions. Indeed some of their terms may not be enforceable in some jurisdictions, but that is a different question. The point is that if it's not a click-through EULA and you can't prove the end-user must be aware of the license, *none* of it is enforceable.

2024-08-19 22:03:47 CEST

- reply

You still need a click-through for that interpretation to work. It would be preposterous for a usage contract/license to be enforceable if the person using the software never got to see it.
But automatic copyright protection *is* universal, and governed by the Berne Convention for the Protection of Literary and Artistic Works.
So ultimately whether a license is a contract or not is irrelevant here. Copyright / "author's rights" / whatever your jurisdiction calls it is automatic. Usage restrictions are not, and are not enforceable if the license/contract is not actually presented to or visible to the user.

2024-08-19 17:16:52 CEST

- reply

The endgame here is to have a thing in the Asahi Installer that can boot an existing install under qemu on macOS, or a rescue image, so you can fix (most) boot issues. If that is using text console passthrough (stdio) it should be accessible via the host macOS.
Then we can mostly just ignore the a11y story for our boot chain since it's largely hidden anyway. Though identifying what a problem is could be a challenge, but there's no practical solution for that inline (no, we're not adding a whole audio engine and screen reader into m1n1/u-boot...). It would make more sense to set up some kind of "breadcrumb" system that logs to a file or NVMe partition something that you can then inspect from macOS (bonus points for using the macOS kernel dump format and triggering the macOS error report dialog directly lol).

2024-08-19 11:22:43 CEST

- reply

Lol HP.
https://social.treehouse.systems/@marcan/112987950943153077

2024-08-19 11:22:15 CEST

- reply

This has nothing to do with the distro. The firmware isn't even initializing the USB drive.

2024-08-19 11:21:50 CEST

- reply

So it didn't work in UEFI CSM (Hybrid) mode. Then I tried UEFI non-CSM mode, which did work, but of course broke the existing Windows install that is using legacy boot.
Then I went back to UEFI CSM mode and it works now (????)
And then I toggled some BIOS settings and it stopped working, even putting them back didn't help. I had to go back to non-CSM mode to make it work again, and then again it stuck in CSM mode.
x86 world, are you doing OK?
(This is an HP laptop FWIW)

2024-08-19 11:02:45 CEST

Trying to boot Fedora on a boring old x86 laptop... so I used Fedora Media Writer to write the image to USB, then hit F9 for boot options.
The drive doesn't show up as a boot option.
BIOS is set to legacy mode, no secure boot, nothing. It just doesn't even try to read from the USB drive.
I guess installing Asahi on Macs is officially easier than installing Linux on PCs... at least some PCs, anyway.

2024-08-18 18:20:26 CEST

- reply

And at the end of the day this devolves to: no low-funding individual ever benefited or will benefit from the AGPL/EUPL since they won't be able to litigate it in practice. It only causes pain and confusion. The major people benefiting from these licenses are the "AGPL+CLA+commercial version" VC-backed leeches who get to claim their product is FOSS when they have all the power and hold all the cards.

2024-08-18 18:17:59 CEST

- reply

My point is that if these licenses weren't considered FOSS, this gambit wouldn't work because CLA or not, those companies wouldn't be able to offer "free software" that none of their competitors can actually fork/deploy/use on ~equal footing and build a competing commercial product out of. They'd have to use a nonfree source-available license (and not get any of the brownie points and FOSS contributions) or accept that by using a FOSS license, anyone else can fork their code and deploy their own proprietary variant SaaS, losing the "commercial version" exclusivity.

2024-08-18 18:05:49 CEST

- reply

1) The reality is that licenses like the AGPL (and potentially the EUPL, though it's not that popular yet) are being abused by enterprises that want to appear hip and FOSS-friendly by releasing their CLA'd to hell product under license terms that they are not subject to (as the copyright owners) while offering a "commercial" version where they make all the money, and the onerous terms of these licenses make it easy for them to go after third-party usage or stifle real FOSS forks, essentially creating a "source available" product that masquerades as FOSS and even leeches on the FOSS community by accepting CLA'd contributions.
2) A lot of AGPL and EUPL software is not actually a network service, and some companies ban such licenses across the board (for good reason), despite them offering nothing to that class of software. So then they just devolve into "fuck large corps" licenses without any actual benefit to the FOSS-iness of the software itself, and that can backfire and end up pushing away contributors.

2024-08-18 17:51:03 CEST

- reply

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

2024-08-18 17:49:06 CEST

- reply

Where do you even draw the line? How much of the software functionality has to be "controllable" by the user for it to be "distributing"? How much do you have to "wrap" it for it to stop counting?

2024-08-18 17:45:39 CEST

- reply

Again, would love to see any *EU* precedent for this working like this.
But even then, if this indeed is a EU-only interpretation, that would be valuable information to share with people (i.e. EUPL does not protect against SaaS anywhere outside Europe).

2024-08-18 17:42:41 CEST

- 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 17:40:00 CEST

- reply

Most SaaS *end-users* interact with, yes. But a huge part of the AGPL/EUPL/etc debacle concerns backend serving technologies that don't do that.

2024-08-18 17:37:50 CEST

- reply

I mentioned that in a follow-up reply to OP. The specific case of web apps is a can of worms that is legally above my head and I will not make any comments about it, I'll leave that one to the lawyers. The HTML/CSS/JS themselves are definitely copyrightable; how that interacts with copyright law when a webapp is hosted in terms of obligations by the hoster, I have no idea.

2024-08-18 17:33:02 CEST

- 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 17:31:25 CEST

- reply

You're looking at this the wrong way. How much sheet music resembles code doesn't matter. The point is that **music**, as in **a melody, a sequence of musical notes**, is copyrightable. Playing sheet music results in... music. "Playing" a computer program doesn't result in anything copyrightable (in general).

2024-08-18 17:28:46 CEST

- 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 17:26:42 CEST

- reply

I know that, I just want to see actual evidence that an actual judge has used this interpretation somewhere, regardless of whether the legal system considers it precedent for future cases.

2024-08-18 17:21:19 CEST

- 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 17:12:17 CEST

- reply

Some people are replying that "communication to the public" is a copyright concept that applies to SaaS usage of software.
I have yet to see any legal citations or precedent that this is the case.
Copyright law concerns *works*. It does not concern *running programs*, it concerns the *programs themselves*. All the restrictions on *running programs* come from EULA clauses, if any.
When you "perform" a song for the public, the public perceives a version of the copyrighted work (the song), which could then be recorded again (fixated) and become a derivative work.
When you "communicate" a movie by showing it in a theater, the public perceives the original work (the movie), which could be filmed again (hello ts rips), and become a copy of the work.
When you host some software as SaaS, the public does **not** perceive the original work (the software source/binary), only the results of its execution. Copying or fixating the data returned from the SaaS service does **not** result in a derivate work or copy of the original work, and is not protected by copyright.
There is a very big fundamental difference here, and if any judge anywhere has decided it's inconsequential and SaaS is "performing" or "communicating" software I'm all ears.
But until someone comes up with some serious citations for this, I'm going to say it's complete bunk, because denying the difference here is nonsensical.

2024-08-18 17:05:28 CEST

- 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 16:37:31 CEST

- reply

Indeed it "could be argued", but as far as I know it hasn't been argued, and it is a very difficult thing to argue. "Public performance" of a copyrighted musical work implies transmitting that work over the air to an audience: the work itself is transmitted. Hosting a service doesn't do that.

2024-08-18 14:56:01 CEST

- 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 14:03:31 CEST

- reply

That's not how copyright law works. It is widely accepted that while computer programs are copyrighted, that copyright does not extend to their input and output. Otherwise Microsoft could claim copyright over your Word documents. For a network server, the network connection is the input and output. Nothing about a program being a server magically transforms the act of running it into "distribution". As far as I know there is absolutely zero legal precedent for that, and it would cause a major change in how we interpret copyright, with wide-ranging effects on the whole industry.

2024-08-18 13:59:57 CEST

- reply

I'm aware, and my point is that if that is true, the EUPL is a non-free EULA. It's one or the other.
Given how clumsily worded the EUPL is on this front, I'm not particularly trusting of its authors, TBH.
Further reading on why this is a huge mess: https://social.treehouse.systems/@marcan/112982874941526943

2024-08-18 13:50:56 CEST

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 22:23:16 CEST

- reply

Right. But what you can't do is put a term in the license that all users, or all distributors downstream, must pay you.

2024-08-17 22:07:34 CEST

- reply

No, that's a distribution fee, not a usage fee.

2024-08-17 21:51:18 CEST

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 21:35:04 CEST

- reply

I don't buy the EUPL claims. The whole "SaaS" fix seems to be based on this convoluted set of definitions:
- Article 3 requires source offer for "providing" the work. It specifically calls out Executable Code, but SaaS usage does not in fact "provide" executable code.
- Article 2 allows "communicating to the public", but it is unclear how this somehow qualifies as "providing" the work unconditionally.
- Article 1 defines "communication" as, among other things "providing access to its essential
functionalities at the disposal of any other natural or legal person".
- Finally, Article 5 does somewhat tie this together with "When distributing or communicating copies of the Work, the Licensee will provide a machine-readable copy of the Source Code or indicate a repository where this Source will be easily and freely available for as long as the Licensee continues to distribute or communicate the Work.". This might be enough to do the job, but it also becomes a restriction on *usage* since "communicating" is defined to include a subset of usage.
In addition, Article 2 allows you to "use the Work in any circumstance and for all usage", and I fail to see how that doesn't cover SaaS usage.
This whole thing is a flimsy contradicting mess as far as closing the SaaS hole goes, I wouldn't bet my code on it. Thankfully, unlike the AGPL, at least it isn't a compliance nightmare for mere contributors.
I do not believe it is legally possible to properly close the SaaS loophole and remain OSI compliant. If the Article 5 wording is legally sound and does that, this license should have never been OSI certified either as it becomes an EULA. You can't just redefine terms to include what is considered "usage" in common parlance and then claim you aren't restricting "usage" because you called it something else. If Article 5 is solid, it imposes a restriction on mere *users* (someone who doesn't modify the Work still has to ensure a source offer exists and is accurate if they install it and serve it), which makes the license into an EULA and decidedly not OSI compliant.

2024-08-17 16:42:04 CEST

- reply

If it's not a network server/app, just don't. Use GPL (or something else).
If you want it to be genuinely FOSS, you have to give up the dream of closing the SaaS loophole. In that case, again GPL/etc.
If you still want to close the SaaS loophole and are willing to be non-FOSS (because closing the SaaS loophole properly and without stupid tricks requires that) then you'll have to choose one of the stronger, non-OSI licenses on that front. I'm not particularly well versed in the available options though.

2024-08-17 15:45:15 CEST

- 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-17 15:20:04 CEST

- reply

The aforementioned Hyprland author believes that everyone should be welcome in his community, even if they are literally Adolf Hitler, as long as they don't talk politics there.
So yeah.

2024-08-17 13:09:20 CEST

- 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 12:43:00 CEST

- reply

"Likely available separately" sounds like a pretty flimsy premise to base your entire license's raison d'etre on. There are many ways a work could have been conveyed to person B without at the same time making it publicly available to all users of person B's service.

2024-08-17 12:35:55 CEST

- 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 11:23:08 CEST

- 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 11:09:25 CEST

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-17 10:33:55 CEST

- reply

You are arguing against the intent of the people who *wrote* the AGPL, by perpetuating the myth that the AGPL restricts usage.
Seriously, go read up on the history of the AGPL. What I said is correct, the intent, and how it was written, because *the whole thing is a legal hack to avoid having to restrict usage because that would make it nonfree*.
The AGPL clause in question very carefully talks only about modification and even explicitly calls out "support" for network access. It doesn't matter how the software is deployed. The clause is very clearly, explicitly, and deliberately a restriction on modification only regarding the functionality of the software, and has zero bearing on usage, because it takes effect when the software is *modified* only well before it has a chance to be deployed or used in any way.
People just don't want to believe it is because indeed it is a ridiculous way to do this. But the FSF is ridiculous like that.

2024-08-16 20:45:54 CEST

- reply

The restriction applies as long as it can *potentially* be used over a network, that is, as long as it has network features (e.g. is a server or web app).
You can indeed remove such features and make it purely local-only and ignore that license term then, but that's not typically very useful.

2024-08-10 15:51:47 CEST

LB: Big cons (especially hacker cons) going increasingly downhill and ending up out of touch with their values is unfortunately more common than not.
I stopped going to CCC partially because it got too large and they started making and enforcing rules like "no lasers without a German license" and "no soldering except in the designated soldering area".

2024-05-28 07:15:53 CEST

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-22 13:00:12 CEST

So I've had this USB controller dying bug for months. The repro was "move data from USB disks for days". The symptoms were IOMMU faults. I thought we had some horrible heisenbug in our platform code.
I finally found a reliable repro today so I started poking around.
In xhci-ring.c `/* FIXME stream case, several stopped rings */`
Gee, thanks, I love it when months-long anxiety over a bug ends up on a FIXME in the code. As far as I can tell, when USB streams are involved and stuff gets canceled, only one stream's TDs get canceled, leaving the others to still be processed by the HCD with DMA pointers now pointing to nowhere 🤦‍♂️