Why hasn't that already happened, then? It's not like the market force in question are new.

Top 10 US states by manufacturing jobs:

1. California (D)
2. Texas (R)
3. Ohio (R)
4. Illinois (D)
5. Michigan (split)
6. Pennsylvania (split)
7. New York (D)
8. Indiana (R)
9. Wisconsin (split)
10. North Carolina (split)

The R / D / split designations above describe the current state government, "split" meaning that control is divided between the parties. So of the top 10, three are Republican-controlled, three are Democrat-controlled and four are divided (though the Michigan split is a very recent phenomenon; Michigan has been quite blue for a long time).

The pattern that I see is that the blue states generate most of the new ideas and products and manufacturing naturally springs up around them, then over time manufacturing of now-established products gets moved to red states for the reasons you pointed out. This is an ongoing process that keeps the manufacturing output relatively balanced over time -- but keeps the blue states richer and maintains their dominant position in US GDP.

Also, it's worth noting that the federal minimum wage is irrelevant these days; market prices have risen above it. Even in low-income states unskilled jobs pay more than the federal minimum wage. (To me, this isn't an argument that the minimum wage needs to be raised, it's an argument that it should be abolished and that we should trust the labor market to set wages.)

Do you also not know how percentages work?

I'm surprised many others mentioned Newsblur, that's what I use as well. But I don't use the Newsblur app or website, but rather the Reeder Classic app (the newer Reeder version is subscription-based, which I avoid at his point).

Reeder Classic is nothing really special, except maybe for its 'bionic reading' support. Despite the pompous name, I actually love 'bionic reading', which essentially is method to add bolding to some letters in words, which greatly helps and speeds reading (especially those long Slashdot summaries). See what it looks like here: https://bionic-reading.com/ . Hope this is useful to some of you :-)

It might show my age, but RSS still works for me. (A) Easy to get only the summary or details from the original source if I want to, and (B) managing which RSS items are dismissed or kept for a later deeper dive is very efficient. Works great in my case.

If I'm understanding the article correctly, the conference room window mitigation wouldn't work against this. It doesn't rely on vibrations of the windows. Instead, you'd just need a piece of paper inside the room, lit by ordinary lamps. As long as the light reflecting off the paper could pass through the windows unmodified (i.e. the windows provide clear visibility) the white noise vibrations of the windows would have no effect.

On the other hand, lightweight curtains that blocked the view through the window would stop this technique, but probably wouldn't significantly reduce what was detectable from a laser bounced off the windows (assuming no white noise).

I think we're talking past one another. I'll try to be clearer.

Sure, but that's not the point. The point is that Android does prevent most users from using anything other than Play. Not by actually blocking them from using other app stores but by simply not offering the option. And that's a good thing, because most users have no idea how to decide whether or not something is safe.

I think perhaps the confusion here is because you and I are looking at this from different directions. You seem to be looking at it from the perspective of what you or I might want to choose. I'm looking at it from the perspective of an engineer whose job is to keep 3B users safe, most of whom have no idea how to make judgments about what is safe and what isn't. Keeping them within the fenced garden (it's a low fence, but still a fence) allows them to do what they want without taking much risk. The fact that the fence is easily stepped over preserves the freedom of more clueful and/or adventurous users to take greater risks. I think this has been a good balance.

I'm pretty sure that the ability to allow unknown sources is required by the Android compliance definition document, and that a manufacturer who disables it is not allowed to call their device Android, or to pre-install the Google apps or Play.

Until Epic decides that they want their store to be able to install and update as seamlessly as Play can, and gets a court to order that. Still, your point is valid, there is still some friction for other stores. Is it enough? I guess we'll find out. Will it be allowed to remain? I guess we'll find that out, too.

goo.gl links are a significant abuse vector, so Google has to maintain a non-trivial team to monitor and mitigate the abuse. I'll bet there are several full-time employees working on that, and that the total annual cost is seven figures.

Even if it weren't an abuse vector, the nature of Google's internal development processes mean that no service can be left completely unstaffed. The environment and libraries are constantly evolving, and all the services require constant attention to prevent bit rot. A fraction of one engineer would probably be enough for something like goo.gl if it weren't abused, but that's still six figures per year, not pennies.

This isn't true for the vast majority of Android users. To a first approximation, all Android users are using devices that have "unknown sources" disabled, so they can only get stuff from Play. Of course, it's trivial to find out how to enable unknown sources and install stuff from other places and I'd expect that nearly all slashdotters who use Android have at least experimented with that, even if they don't use f-droid or whatever on a regular basis. But slashdotters are not remotely a good representative sample of Android users.

If you're talking about desktop/laptop software, sure... but most Android users don't use a desktop or a laptop and are accustomed to expecting that anything they can install is safe. And even among those who do use a non-mobile device, people expect mobile devices to be safer, because they are. This court ruling may change that, to some degree. The result will probably be good for Apple, since Android insecurity will drive people to the safety of Apple's walled garden.

Delegating security decisions to users is the best way to ensure that users have no security. I'm all for enabling users who understand what they're doing to make their own choices and are willing to accept the consequences, but the vast, vast majority don't understand security or the consequences of their security decisions, especially not in the face of clever attackers who are quite good at making malware appear completely innocuous. Even a knowledgeable security professional can't reliably distinguish malware from a legitimate app, not without deep and very specific expertise, and not always even then, and you think your grandma can?

There are three billion Android devices in the world; it's used by approximately 1/3 of all people living, and they put a lot of very important information about themselves in their devices. Android platform security decisions have enormous consequences. Android has gradually gotten more opinionated about user security because we've found time and again that if you ask users, they don't understand the implications and they make bad choices.

Many people think that the existence of unlockable bootloaders and the developer options are bad choices and suggest that we should push the Android ecosystem into the Apple model of closed, locked-down hardware and a closed app ecosystem. I disagree, and I've worked hard to make sure that the ability of people to run the software they want on the hardware they own is not restricted. For example, I have regular meetings with the leaders of various Android ROMs, including Lineage, Graphene, Calyx, etc., to help them navigate the security hardware changes that we make. This isn't something I do because my management tells me to, it's something I do on my own because I think it's important.

User freedom is deeply important to me... and so is user security, but these things are in tension. To a first approximation, increasing one decreases the other. IMO, Android has struck the right balance. By default, devices are locked down and software comes from a controlled source, but users who know what they're doing have the right and ability to remove the restrictions (mostly; low-level firmware is locked down -- I would like to see Android gain a "dev screw" capability like ChromeOS to completely open it up in a safe way). This court ruling seems likely to upset that balance in a direction that endangers users who don't know what they're doing -- and it doesn't provide any additional capabilities to users who do. It's all risk, no benefit.

Try a web search for my username and "Android". Or look for "swillden" in the AOSP codebase and commit logs. Seriously, why would you imply that I'm lying when it's extremely easy to verify? And if you think that I made up a /. username to match some rando Android engineer, look at my /. UID. I've been on /. since before Android even existed.

You have an odd definition of "subsidize".

The phrase is "script kiddies", meaning young guys who know how to execute a script but don't understand how it works.

"Script kitties" is a funny visual, though. Thanks for that :-)

Very, very unlikely -- the resources required to do good malware detection at any sort of scale are enormous -- but also irrelevant. The issue isn't what the best app store does, it's what the worst does. Users who would choose an app store because it does extremely good vetting are users who would be careful what they install regardless of how careful their store is. It's the users who aren't cautious that will be harmed by Google being required to give them access to many app stores.

In this case I think the Play store's "captiveness" is beneficial to the consumer in one important way: Google does a much better job of policing the Play store for malware than most third party app stores do. The extra hoops that users have to jump through to use third party stores do keep most users "captive", but they also keep them fairly safe. The fact that users can easily turn on the ability to sideload other apps or app stores, though, means that they're not really captive. I think this is the right level of friction, though obviously the courts disagreed.

Unless Play can find a way to effectively police malware on third party app stores (which will be hard) they're now going to be required to distribute through Google Play, I predict that this will be pretty bad for Android users. Play could try to put warnings on third party app stores and leave it up to the user to decide, but the courts may not allow that, and it's not really a good solution anyway because when given a choice between security and something they want right now, nearly all users ignore security. I think there needs to be a little more friction than clicking through a warning.

This court ruling is really good for Android malware authors and somewhat good for Epic, but I think it's a net negative for Android users. I hope I'm wrong!

(Disclosure: I work for Google, on Android Platform Security, but not on the anti-malware team. I do below-the-OS security stuff.)

No no, you just need the software from Ariane V that thought the rocket was going backwards.

Good for you, I guess.

Well... I'm a Staff SWE at Google with >35 years of professional software development experience, and my code running in the core OS of 3B devices. By the standards of most people, I'm a skilled, experienced and highly productive programmer. Maybe your standards are higher.

Oh, one more suggestion (because I just did it in the other window): Do ask the LLM to make code modifications for you. Suppose you're changing a method signature in a somewhat-complex way such that you can't just search & replace, or let the IDE refactoring tool do it. Tell the LLM to find and fix all calls. Often you can be that vague, too "Find and fix all calls to my_func()". Sometimes you have to specify more precisely... but always start by telling the LLM to do it the same way you'd tell a human junior engineer, rather than working harder to spell it out precisely.

Oh, one more yet :-): "git add ." before every command to the LLM so you can "git diff" to see exactly what it changed. This is useful even if the AI integration into your IDE highlights the changes.