takluyver

I'm guessing Windows gets a pass because you can still fairly easily bypass the signature check - it's effectively a warning rather than a hard block. It sounds like for (mainstream) Android, the only workaround will be to plug it into a PC and use adb there to install an unsigned app, which is considerably harder. Installing a custom ROM will presumably get around it too, but that's tough, and various government and banking apps etc tend to refuse to run because of attestation.

Apple is of course locked down, but that's not news. The anger is because Android was the better option on this dimension.

The umbrella organisation signing apps is not impossible, as far as I know. But it would need to be pretty cautious, because if Google revokes its registration, that could block all the apps it has signed at once.

It's hard to see how you could get the necessary level of careful code review with just volunteer effort. But I suspect that most developers who don't want to register with Google are also unlikely to pay money to a third party to work around this.

The implied context for that is that whatever information you have in the apps should be kept in sync between devices and between people. Classic desktop applications are more like offline-only. Web 2.0 traded that approach for data living on a server, so it stays in sync because there's only one source of truth, but you can only edit it when online.

'Offline-first' is trying to combine the benefits of both approaches.

I think governments funding software development could be a useful counterweight in an industry dominated by a few giant corporations, similar to how lots of countries have state funded media alongside commercial options.

But the EU forking Android is not a remotely realistic starting point. How do you persuade manufacturers to use it? Would Google license its proprietary apps to run on it? How will the small team of devs cope with whatever changes are coming in hardware next year? Forking Android is easy, making your fork a viable alternative is almost impossible.

In theory the EU could throw its weight around and demand that Google & OEMs work with 'EUdroid' if they want to sell phones in Europe. But that would be a massive political fight, much bigger than funding a few developers.

And those apps get developed only if there are enough users. Catch 22.

Microsoft didn't manage to make Windows Phone a viable competitor against Android & iOS, and they're about an order of magnitude bigger than any Linux-focused company. I hope the conditions shift and an open phone OS can take off, but I don't know what would enable it.

People definitely care about applications they use a lot, and MS Office is a big one - even if LibreOffice would work just as well for many use cases, people are hesitant to give up what they know works.

The OS does make some difference, but I think that if all the same applications were available, a lot of people could switch without much difficulty. In some ways going from Windows to Linux might be easier than Windows to Mac, because many Linux distros are happy enough to conform to UI conventions that are familiar from Windows.

AppImage is, in fairness, a clever idea. But it's also yet another option. It only solves the mess of competing formats if it wins, if it becomes the normal way to publish user-facing software on Linux.

This is absolutely not a solution. It more or less works for a few big widely used applications like Firefox & Libreoffice, but more niche applications can't realistically get someone in every major Linux distro interested in packaging them. And if someone does take an interest once, there's no guarantee they stay interested to package updates. Distro maintainers need to be highly trusted (give or take AUR), so it's not easy to add many more of them.

On top of that, some of the biggest Linux distros will only release application updates with their own OS releases, on a cadence of months or years. Software developers expect to be able to deliver updates in hours to days (at least in the consumer space - highly regulated things like banking are different).

There are good reasons why RedHat and Canonical, the companies behind some of the biggest Linux distros, are pushing app distribution systems (Flatpak & Snap) which aim to be cross-distro and have upstream developers directly involved in packaging. There are absolutely downsides to this approach as well, but it would be nice if we could stop pretending that traditional distro packaging is a marvellous system.

> As for religious wars over init systems, desktop environments and package managers, competition is making the options stronger, not weaker.

Competition can definitely improve things, but it's not universally positive. In particular, endless competition in parts of the operating system makes it hard to build anything on top of them. E.g. if you want to distribute an application for Linux, do you build a Flatpak, or a Snap? Or take a more traditionalist approach and make RPMs, DEBs, etc.? You either pick your favourite and leave out a large fraction of Linux users who disagree, or you have to do more than one of these. This is definitely a drag on the ecosystem.

I agree that most users don't care about the OS, though.

Definitely, yes. That's a prime example of how corporate friendly open source has been massively successful. By contrast, the first entry on the FSF's high priority projects page is a free phone operating system. They point to Replicant, an Android fork that... does not look particularly active.

I don't think Stallman is an effective spokesperson or campaigner for his own cause, though. Corporate-friendly open source has got enormously popular, to the point where the biggest open source collaboration platform, Github, is owned by Microsoft. Stallman is not troubling them. It's his own side he's driving to irrelevance.

There are so many ways one could work around this (apparent) limitation. Liberty software, unbound software, modifiable software. Go all in on libre rather than putting it in an awkward 'free/libre' combo - languages borrow words from each other all the time. Swap the order round and talk about software freedom, or digital freedom. Make a portmanteau like libreware...

I'm not especially good at this, and obviously 'free software' has the benefit of a few decades history among the people who actually know it. But almost anything seems better than a phrase which has a very obvious meaning that's not the one you meant, and the consequent need for fussy little explanations. Especially when most Free Software is also free software.

That seems to be looking at tracking and data collection libraries, though, for things like advertising and crash reporting. I don't see any mention of the kind of 'network sharing' libraries that this article is about. Have I missed it?

I wonder if part of the "no big deal" view comes from the difference between tech companies as they're most visible now - 'move fast and break things' - versus all the other industries that rely on computers.

It's easy to imagine a lot of tech companies today taking a 'fix on failure' approach, because they're built on the idea that you deploy changes quickly, so they can accept a higher risk of faults. It's harder to make changes in banks, airlines & power stations, thus they're more risk averse, and far more likely to invest resources in the kind of effort the author describes to find & fix issues in advance.

Conda package recipes have a preprocessor using "selectors" in comments to conditionally exclude certain lines in a YAML file. Not that this is particularly more ugly than other YAML DSLs, but it has been used.

As I understand it, the point of these attestations is that you can see what goes into a build on GitHub - if you look at the recorded commit on the recorded repo, you can be confident that the packages are made from that (unless your threat model is GitHub itself doing a supply chain attack). And the flip side of that is that if attestations become the norm, it's harder to slip malicious code into a package without it being noticed.

That's not everything, but it is a pretty big step. I don't love the way it reinforces dependence on a few big platforms, but I also don't have a great alternative to suggest.

The 2FA requirement doesn't need a smartphone. You can generate the same one time passwords on a laptop. I know Bitwarden has this functionality, and there are other apps out there if that's not your cup of tea. Sorry that you feel pressured, but it is significantly easier to express a dependency on a package if it's on PyPI than a download on your own site.

If there is time for someone to work on local uploads, a good starting point would be a nicer workflow for uploading with 2FA. At present you either have to store a long lived token somewhere to use for many uploads, and risk that it is stolen, or fiddle about creating & then removing a token to use for each release.

I believe you that token uploads will continue to be possible, but it seems likely that in a couple of years trusted publishing & attestations will be effectively required for all but the tiniest project. You'll get issues and PRs to publish this way, and either you accept them, or you have to repeatedly justify what you've got against security.

And maybe that's a good thing? I'm not against security, and supply chain attacks are real. But it's still kind of sad that the amazing machines we all own are more and more just portals to the 'trusted' corporate clouds. And I think there are things that could be done to improve security with local uploads, but all the effort seems to go into the cloud path.

I think there's been some concern that people compare the speed of Firefox with a bunch of random extensions against Chrome with none. I wonder if the 'refresh' is an attempt to get away from that at the point where someone might be giving Firefox another chance.

I don't remember if the refresh offer appeared back in the xul days, when there was much more scope for extensions to hurt the experience.

> after a decade I still can't do what I can do on a closed source thing that came free with my computer

I don't know the specifics, but there's a good chance that your issue is ultimately because Nvidia wants to keep stuff closed, and Linux is not their main market - at least for actual graphics, I guess these days it's a big market for GPU computing. So it's the interface between closed and open source that's giving you grief.

> I’m arguing for truth in advertising and labeling, so that counterfeit, fake, and adulterated products are eliminated from the market.

It's not a counterfeit, fake or adulterated product, though. It's balsamic vinegar, as almost everyone uses the term, and as the law, even in Italy, allows. If you want the extra special & expensive kind, you can look for 'Traditional balsamic vinegar' and the PDO logo that goes with it.

If people are selling regular balsamic vinegar as PDO 'Traditional balsamic vinegar', I'd agree with you. But I don't think that's happening on a significant scale.

> Any other vinegar product that uses blends of grape must and wine vinegar... isn't really in the spirit of balsamic vinegar. To sell such a blend and labeling it as balsamic vinegar feels like selling blended whisky as single malt whisky.

It can absolutely be described as balsamic vinegar, though. Even the protected (PGI) name 'balsamic vinegar of Modena' is a blend with wine vinegar. Only the PDO term 'traditional balsamic vinegar' forbids this.

It's interesting to know that there's a special kind of balsamic vinegar that I've probably never tasted. But even if that's amazing, I still enjoy the balsamic vinegar I can get in the supermarket, and that's what almost everyone means when they say 'balsamic vinegar'. Insisting that almost everyone using the term is misusing it feels like a weird form of elitism.

The BBC article especially is conflating two kinds of 'fake'.

The balsamic vinegar most of us buy is not the super expensive 'Traditional balsamic vinegar', which is what they're describing aging in barrels for 12 years. It may still be 'balsamic vinegar of Modena', which is a protected term but with much less strict requirements, and consequently much cheaper. And 'balsamic vinegar' without qualifiers is not protected at all, as far as I know. It seems like a stretch to call these fakes.

Either protected term can fetch a better price than generic 'balsamic vinegar', so someone will have a go at faking some paperwork to make their product more valuable. The Guardian article describes one such case that was caught (in 2019), but doesn't say much about how prevalent this is.

Flathub does allow the 'build' to download and unpack a pre-built tarball. This is obviously not as convenient as directly uploading it, but some of those enthusiastic users might be happy to get the manifest set up for you, and then updating for new versions should be simple.

(And sorry about the pushy ones. I hope they're few and far between.)

That makes sense. But I think that's a money problem, not a technology problem - if the money was sloshing around desktop applications, I think we'd get a lot of locked down desktop applications tracking us. We kind of have that on mobile, indeed. Sometimes there are nice community built alternatives, but not that often.

Ironically, that decision to run Javascript without a prompt was probably a huge step forward for the security of most users. The 'do you trust this' model of security doesn't work well in practice once you can download programs from the internet - there's too much stuff you need to or want to trust to get on with things, and even if it's not actively malicious, it may be vulnerable.

Because Javascript can run in the browser without the assumption that you completely trust it, browser developers have put a load of work into restricting what it can do, even within the browser. Of course, sometimes there are holes in the sandbox - nothing is perfect - but I think it's vastly better than giving any program you decide to run complete access to your computer.

(Better for the majority, that is. If you're truly paranoid and have enough time, explicitly deciding what to trust can be better. But I think that's <1% of people - certainly not including me.)

> It doesn't (need to) get packaged by a distribution until a program using it is packaged.

I think this is a key difference in approach. In languages with their own packaging systems, you routinely package libraries before there are programs using them. Publishing them on Crates/PyPI/npm/whatever is the bare minimum if you expect anyone to use them!

The number of tiny dependencies can go too far - I don't think I need to mention left-pad. But the difficulty of using dependencies in C/C++, and the results of reinventing stuff, vendoring, or using kitchen-sink dependencies like Qt, don't seem optimal either. There must be a happy medium somewhere.

Users install from there, so long as they're using Linux, a Debian or Red Hat based distro, and have sudo access. As you say, not such a nice answer.

For certain kinds of software, this approach is getting more viable, thanks to containers. In some contexts, you can tell everyone to run your software in a container with a specific Linux distro inside. But that software is often distributed as container images directly, rather than distro packages to be used in containers.

In fairness, there are standardised protocols for a lot of these things already, even if they're not all part of one giant meta-protocol. Cameras in particular have mostly appeared as a folder full of files, with no need for special drivers, for something like 20 years.

There's definitely no need to invoke a conspiracy for the lack of 'one protocol to rule them all'. It's often hard agreeing on a standard even for a relatively limited topic - trying to agree on one for all electronic communications for all devices is probably impossible.