6 ms·

>Some important packages are now distributed only through their non-freedom-respecting package system Wait, why is Ubuntu's package manager "not freedom respec

>Some important packages are now distributed only through their non-freedom-respecting package system Wait, why is Ubuntu's package manager "not freedom respecting" but dpkg is? I thought snap was licensed under GPLv3. >It should be illegal to sell a computer that doesn't let users install software of their own from source code. Agreed, but this is such a low bar that even iOS meets it. Apple has never attempted to restrict users' ability to compile and run source code. In fact, for almost a decade now the automatic signing in Xcode will sign and provision your compiled code, even if you didn't have a verified and paid-up developer account. The App Store rules about not executing code outside the app bundle also have exceptions specifically for apps that let users load apps from source. The whole debate people are having about sideloading is specifically about distributing binaries; not source - Apple's security model is that you don't get to do that unless they can review your app. While I would much rather have an iPad that Apple just lets me unlock and accept the risk of doing so, and I do not oppose sideloading... I must point out that much of the people asking for sideloading are proprietary software vendors and not users. Being as vehemently opposed to proprietary software as RMS is means that he's actually on Apple's side of that debate, even though Apple is "the enemy" so to speak. The comments about Macs being more locked down I don't entirely understand. Apple's bent over backwards to keep a working owner override on Macs, both for the operating system as a whole and individual apps. If you want to run an untrusted binary[0], you right click the app bundle, accept the risk, and continue on with your day. If you want to run a third-party OS, there's a process to do that. Apple even engineered cryptographic verification of the owner account so that, instead of just "turning off Secure Boot" like on PC, you actually sign the new kernel you want to run with your owner key and still have some level of verification that the kernel hasn't been changed behind your back. This is basically "everything the FSF wanted for Secure Boot a decade ago", with the only downside being that it requires a locked-down boot chain in order to provide security guarantees. >Well, first of all, I don't think there's anything bad about playing a game. Unless the game is non-free — then it's bad for you, if you play it. Ehhhheheh... Modern game design has basically turned a lot of games into microtransaction pumps. This is a more complicated issue than just "proprietary bad", because proprietary games used to be far less harmful than they are now. You used to just be able to buy a game and enjoy it, despite it being chained to standard no-touchy copyright terms. Yes, you were running non-free software, but the usual proprietary harms did not apply as they did for other kinds of software. Now they do: games are constantly making excessive time or money demands before you can actually have fun with it and their developers are employing all sorts of psychological tricks to get people to overspend in them. [0] I do want to point out that codesigning and notarization on macOS was a lot easier to set up than a lot of people have made it out to be.

josephcsible 5y ago
> Wait, why is Ubuntu's package manager "not freedom respecting" but dpkg is? I thought snap was licensed under GPLv3. The Snap server is what's closed-source. > I must point out that much of the people asking for sideloading are proprietary software vendors and not users. I know I'm just one data point, but I'm a user who wants sideloading. > Being as vehemently opposed to proprietary software as RMS is means that he's actually on Apple's side of that debate, even though Apple is "the enemy" so to speak. No he isn't. He's always in favor of users being in full control of their own devices, even if that control allows them to install proprietary software onto them. > The comments about Macs being more locked down I don't entirely understand. Apple's bent over backwards to keep a working owner override on Macs They're slowly boiling the frog, like with removal of kexts. I'd bet money that within 10 years, you won't be able to disable SIP on the newest Macs anymore. > with the only downside being that it requires a locked-down boot chain Aside from that, Mrs. Lincoln, how did you enjoy the play?
- kmeisthax 5y ago
  Not having third-party Snap servers is unfortunate, and something we probably should be forking Snap to add support for. Still, calling it "not freedom respecting" seems a little hyperbolic given that the actual part that runs on your computer is very much FOSS. It's not any different from, say, reading a website whose server software is unreleased, but whose client-side JS is all Free Software. As for sideloading... yes, I want it too. But the only thing that really gives me is the ability to run some emulation and virtualization tools Apple refuses to sign for reasons ranging from unfortunate to stupid. Epic Games did not sue Apple for my right to run old Nintendo games on my iPad. In fact, the videogame industry has been very explicit that users should not be allowed under any circumstances to format-shift games they own, and Epic has done nothing to indicate that they are less consumer-hostile than their peers. They also said they'd accept a two-tiered system where they got their Epic App Store but users still couldn't sideload. So, as much as Tim Sweeney is ideologically motivated to support user freedoms, Epic Games is still pushing their lawsuit from the perspective of a proprietary software vendor, just one that's willing to go rogue. You're right about RMS not being on the "same side" as Apple, and I misspoke. It's more like this is a three-sided fight between users (FSF, EFF, etc), proprietary developers (Epic), and platforms (Apple/Google). My point is that if you are extremely opposed to proprietary software in any form and for any reason whatsoever, then Apple's argument against sideloading is actually more reasonable, because it's the enemy eating itself. However, if you are at least slightly tolerant of proprietary software, then the argument Epic makes of Apple being anticompetitive makes a lot more sense. I'm still not convinced that Apple's end goal is to make the Mac just be an iPad with a mouse and keyboard. The whole owner override thing I mentioned above took a lot of time and effort, just so they could boil the secure boot frog less. It would have been far easier for them to just say "no, we're only allowing macOS to live in EL2". Nobody was expecting them to allow this, and Hector Martin still has to occasionally field questions of "why are you working on this when Apple is just going to block it" when they haven't for several years now. Furthermore, Apple's designer brainworms have insisted upon not converging their platforms in any way that would make having the same security policy make sense. >Aside from that, Mrs. Lincoln, how did you enjoy the play? There really isn't another way to implement this while providing the same security guarantees for Free operating systems. The part that actually checks to make sure the code you're running was owner-signed needs to be both immutable from the perspective of malware and updatable in case of security bugs. You don't want this burned into a ROM chip since it's extra attack surface, even though that technically satisfies some weird exception the FSF made decades ago for the proprietary ROM BIOS in IBM-compatibles. The only complaint I have about the way Apple did this is that they really should Free their boot chain code and have verifiable builds for it. However, there are very few, if any machines that actually have a Free boot chain. And the only harm a proprietary boot chain can do to Free Software is to refuse to load a Free OS. So as long as the boot chain allows us to do that, the crusade for a Free BIOS seems more of an academic or research concern than anything else. [0] You're supposed to be able to enroll new secure boot keys, but AFAIK this isn't really ever done.

josephcsible 5y ago

> Wait, why is Ubuntu's package manager "not freedom respecting" but dpkg is? I thought snap was licensed under GPLv3. The Snap server is what's closed-source. > I must point out that much of the people asking for sideloading are proprietary software vendors and not users. I know I'm just one data point, but I'm a user who wants sideloading. > Being as vehemently opposed to proprietary software as RMS is means that he's actually on Apple's side of that debate, even though Apple is "the enemy" so to speak. No he isn't. He's always in favor of users being in full control of their own devices, even if that control allows them to install proprietary software onto them. > The comments about Macs being more locked down I don't entirely understand. Apple's bent over backwards to keep a working owner override on Macs They're slowly boiling the frog, like with removal of kexts. I'd bet money that within 10 years, you won't be able to disable SIP on the newest Macs anymore. > with the only downside being that it requires a locked-down boot chain Aside from that, Mrs. Lincoln, how did you enjoy the play?

kmeisthax 5y ago
Not having third-party Snap servers is unfortunate, and something we probably should be forking Snap to add support for. Still, calling it "not freedom respecting" seems a little hyperbolic given that the actual part that runs on your computer is very much FOSS. It's not any different from, say, reading a website whose server software is unreleased, but whose client-side JS is all Free Software. As for sideloading... yes, I want it too. But the only thing that really gives me is the ability to run some emulation and virtualization tools Apple refuses to sign for reasons ranging from unfortunate to stupid. Epic Games did not sue Apple for my right to run old Nintendo games on my iPad. In fact, the videogame industry has been very explicit that users should not be allowed under any circumstances to format-shift games they own, and Epic has done nothing to indicate that they are less consumer-hostile than their peers. They also said they'd accept a two-tiered system where they got their Epic App Store but users still couldn't sideload. So, as much as Tim Sweeney is ideologically motivated to support user freedoms, Epic Games is still pushing their lawsuit from the perspective of a proprietary software vendor, just one that's willing to go rogue. You're right about RMS not being on the "same side" as Apple, and I misspoke. It's more like this is a three-sided fight between users (FSF, EFF, etc), proprietary developers (Epic), and platforms (Apple/Google). My point is that if you are extremely opposed to proprietary software in any form and for any reason whatsoever, then Apple's argument against sideloading is actually more reasonable, because it's the enemy eating itself. However, if you are at least slightly tolerant of proprietary software, then the argument Epic makes of Apple being anticompetitive makes a lot more sense. I'm still not convinced that Apple's end goal is to make the Mac just be an iPad with a mouse and keyboard. The whole owner override thing I mentioned above took a lot of time and effort, just so they could boil the secure boot frog less. It would have been far easier for them to just say "no, we're only allowing macOS to live in EL2". Nobody was expecting them to allow this, and Hector Martin still has to occasionally field questions of "why are you working on this when Apple is just going to block it" when they haven't for several years now. Furthermore, Apple's designer brainworms have insisted upon not converging their platforms in any way that would make having the same security policy make sense. >Aside from that, Mrs. Lincoln, how did you enjoy the play? There really isn't another way to implement this while providing the same security guarantees for Free operating systems. The part that actually checks to make sure the code you're running was owner-signed needs to be both immutable from the perspective of malware and updatable in case of security bugs. You don't want this burned into a ROM chip since it's extra attack surface, even though that technically satisfies some weird exception the FSF made decades ago for the proprietary ROM BIOS in IBM-compatibles. The only complaint I have about the way Apple did this is that they really should Free their boot chain code and have verifiable builds for it. However, there are very few, if any machines that actually have a Free boot chain. And the only harm a proprietary boot chain can do to Free Software is to refuse to load a Free OS. So as long as the boot chain allows us to do that, the crusade for a Free BIOS seems more of an academic or research concern than anything else. [0] You're supposed to be able to enroll new secure boot keys, but AFAIK this isn't really ever done.