takluyver

In addition to what other people have said, the terminal interface is cross-platform and very stable, so TUIs need little or no maintenance to keep working.

Certainly the app ecosystem was part of the challenge, and Microsoft spent a fair bit of effort trying to both encourage developers to make apps, and filling obvious gaps (like Youtube) itself. If their resources, retail connections and brand recognition weren't enough, it's hard to imagine that anyone else stands much chance until conditions change drastically.

And to underscore the scale of that challenge, Microsoft couldn't make Windows Phone a significant competitor to Android & iOS.

The XZ utils backdoor made it into Debian repositories undetected, although it was caught before it was in a stable version.

Debian repositories are quite secure, but also pretty limited in scope and extremely slow to update. In practice, basically everyone (I'm sure there are a few counterexamples) using a Linux distro uses it as a base and runs extra software from less tightly controlled sources: Docker hub, PyPI, npm, crates, Flathub etc. It's far easier for attackers to target those, but their openness also means there's a lot of useful stuff there that's not in Debian.

Holding up Debian as a model for security is one step up from the old joke about securing your computer by turning it off and unplugging it. It's true, but it's not really interesting.

If you get 'verified' by Google and sign your app, sideloading shouldn't change. That means money and ID checks, or a free 'hobbyist' carve out if you have <20 users.

If you don't want to play their game, sideloading will get substantially harder.

There's going to be a lot of people who don't have a laptop/desktop handy right now - because they're out of the house, because it's unplugged in a cupboard, or because they borrow it from a friend or use an internet cafe when they need that. So a requirement to use that and connect your phone to it is effectively similar to the 24 hr waiting period: time to think, time to mention it to a friend who's heard about this scam before. This is why phones are such an attractive target in the first place.

Huh, indeed. I still can't find much information about this, but this page is very informative: https://jwodder.github.io/kbits/posts/term-fgbg/

They can? Is this a recent thing? I remember wanting to detect the background colour years ago, and not finding any way to do it.

Also, power users are the ones who will find and change the setting - that's pretty much what being a power user means. Picking defaults that work for novices makes sense, even if that's slightly more inconvenient for me.

I think this whole discussion is based on an assumption that changing the default is part of an agenda to get rid of middle-click-paste entirely. I don't think it is.

Not unlike Firefox, Gnome has a lot of hidden options which aren't exposed in the regular settings UI. There has been an option to control 'primary paste' for 9 years, and it's exposed in Gnome tweaks. There's no obvious reason that changing the default means the option will be removed entirely.

A web page with Javascript can see & send off something you paste into a text box as soon as it appears. So if you accidentally paste some confidential information, like a password, that's a security hole even if you notice and delete it straight away. This happens even for totally innocent reasons, like search-as-you-type.

Ctrl-C/Ctrl-V copy and paste is not such a big issue because far more people are familiar with it, and it requires more deliberate actions on both sides (copying and pasting). So you're less likely to accidentally copy something around that you didn't mean to.

There's nothing particularly wrong with it, but developing a browser engine and keeping up with new web standards is quite a bit of work. And web developers won't all test on a browser with 2-3% market share, so there's more risk of sites not rendering quite right because the engine is different.

That analogy doesn't really work, though: Mozilla's goal is not specifically to fight against online advertising. Ad-blocking is connected to their goals, definitely, but they clearly have to make compromises, and I'm not that surprised that they'd think about that one.

I doubt AI agents are going to greatly accelerate the development of something as big and complex as Servo. It seems more realistic that Firefox would be built around either Blink (from Chromium) or Webkit to lean on Google/Apple.

I agree with all the people saying it would drive a lot of the remaining users away, and I hope they don't do it. But I'm not remotely surprised that they considered following what their biggest competitor (Chrome) already did.

> starting from near total market domination

That's not really accurate: Firefox peaked somewhere around 30% market share back when IE was dominant, and then Chrome took over the top spot within a few years of launching.

FWIW, I think there's just no good move for Mozilla. They're competing against 3 of the biggest companies in the world who can cross-subsidise browser development as a loss-leader, and can push their own browsers as the defaults on their respective platforms. The most obvious way to make money from a browser - harvesting user data - is largely unavailable to them.

My understanding is that all the big AI companies are currently offering services at a loss, doing the classic Silicon Valley playbook of burning investor cache to get big, and then hope to make a profit later. So any service you depend on could crash out of the race, and if one emerges as a victorious monopoly and you rely on them, they can charge you almost whatever they like.

To my mind, the 'only just started' argument is wearing off. It's software, it moves fast anyway, and all the giants of the tech world have been feverishly throwing money at AI for the last couple of years. I don't buy that we're still just at the beginning of some huge exponential improvement.

I'm sure they would love to. They've been trying to make their own app store (Galaxy Store) a thing for over a decade. But cutting ties with Google would mean no Google Apps and no Google Play Store, and that would probably be catastrophic for them.

> we give up on the tools that companies use. UX, user research, graphic design, marketing and similar roles are pretty absent from these communities

Some of the bigger open source communities, like GNOME, do some amount of these things. But I think very few people are excited enough about user studies or marketing to do them as a hobby, unlike writing code. It's hard to see how you could beat Google/Apple/Microsoft at their own game like this without a lot of money. Red Hat is probably the biggest company that might be interested in this, but still about 2 orders of magnitude smaller than the giants.

The grants to the 'University of Georgia Research Foundation'?

OK, I accept that as a possible reason why it might be written there even if it has no weight. But it still seems very likely that it's easier to terminate a grant - and harder for the PSF to argue against that - than to actually prosecute DEI work and prove in court that it's illegal.

And if someone at the NSF decides to terminate the grant & 'recover all funds', does the dispute over the contract involve the same burden of proof and rights to appeal as a federal discrimation case?

Someone wrote it into the grant agreement. It's a fair bet that they think that has some effect beyond what the law already achieves.

The requirements the GP is describing are to avoid using certain words. It's not fraudulent to describe the same work without using the banned words.

It's not a renewal, it's their first application for government funding, and they turned it down without accepting the terms. This is all quite clear in the blog post.

If it has zero weight, why would the grant agreement specifically highlight it? I would guess it's much easier to enforce a particular interpretation of the law via a grant agreement than having to argue it in court.

Small correction: the restriction would only affect the PSF for the 2 years the grant runs. That's still more than bad enough when 'diverse' is in the mission statement, and of course they might well apply for other grants, but in principle it can't be applied 'at any point'.

I would imagine it is much easier to enforce as part of a grant agreement that organisations have signed. Especially if the law is either not really a law (yet), or it might be invalidated by a court on free speech grounds. There's probably a reason someone wrote it into the grant agreement, and that they're declaring DEI stands for something other than the familiar Diversity, Equity & Inclusion.

They could add a developer option to bypass the new restriction, but as far as I know they haven't said they'll do that, and I don't see any reason why they would. The adb bypass is probably good enough for actual developers.

Apps can certainly detect if a phone is rooted and refuse to work, like with a custom ROM. It's up to the developer what they care about, but this is not unusual. There are ways to try to trick the check into passing, but it sounds like the kind of thing that might break on any update.

The current blog post does appear to say that you don't need to be verified to install and run apps with adb.

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.