rlpb

So you're insinuating that importing from China automatically means poor quality? I don't believe that's true, especially for large companies who are able to manage the supply chain (as, AIUI, doing business with China famously requires).

I think you need to address that to validate your original comment. Otherwise there's no justification for your claim.

> It's the greed at topest level.

You say this as if it's some deviant behaviour that needs correcting.

But greed is normal and expected in a free market economy. Suppliers are expected to seek to reduce their costs and maximise their profits.

> It needs to be fast-updating for shared multi-user docs, like Google Docs/Sheets or Word/Excel 365.

In my experience, Google Docs has this, but realtime collaboration with Word is unusable. Which is interesting, because that means a huge number of existing Office 365 users have yet to experience it.

I wonder if there's an opportunity there.

Is "we promise not to enforce" legally binding I wonder, in which case it is de-facto a license? IANAL but it's an interesting concept.

Everything inside Debian is fine. That's most of the ecosystem apart from the very new stuff that isn't mature enough yet. Usually the reason something notable stays out if Debian long term is when that thing has such bad dependency hygiene that it cannot easily be brought up to standard.

Debian manages perfectly well without.

And then how would this be any different in practice from dynamic linking?

This would only work if you use dynamic linking. Updating dependencies in a statically built distribution would have no effect.

Imagine a fully statically linked version of Debian. What happens when there’s a security update in a commonly used library? Am I supposed to redownload a rebuild of basically the entire distro every time this happens, or else what?

> I genuinely cannot understand why anyone would buy a car or a bed or a fridge that requires a subscription.

There's a huge car finance market where people do exactly that. How much they pay a finance company monthly vs. how much they pay the manufacturer monthly makes little difference to them. It's all about the monthly fee and what they get in return for it.

> And all of this has to be done in a way that will hold up in court, therefore snail mail.

This needs to change. Snail mail is no longer reliable. Letters often get delayed by weeks or go missing altogether, but the law still assumes that justice is being done by it being sufficient to assume that a letter that was posted has been received within a few days. It's no longer true.

It’s your choice of course, but in the messaging world of gatekeepers and walled gardens, I think AGPL makes the most sense. It’s a key tool we’re going to need if we want to be successful at having a federated network.

Additionally, landlords don't benefit from the higher prices (ie. market rate rent) either, since that also pushes house prices up. A landlord entering the market has a higher capital cost that absorbs the higher rental return, such that typically rental yield remains about the same (at slightly higher that the cost of capital that covers their increased risk compared to a more stable investment).

Those who benefit are those who own housing at the time of market rate increases. That's just regular investment return and the risk/reward can be directly compared to any other form of investment. Current owner occupiers and current landlords benefit at the time of every increase (even if their capital gains are not immediately realised). And then every household, whether they are owner occupiers or tenants, have to pay in the form of higher capital expense. Landlords simply pass the higher rent through to pay for their higher capital expenses.

> That doesn't take an LLM to accomplish, I don't think. After all, a car has a limited number of functions. It should be mostly a matter of broadening the voice recognition dictionary and expanding the fixed logic to deal with that breadth.

I think the most effective way to get this accurate and effective is to give an LLM the user’s voice prompt and current context and ask to convert the user’s request into an API call. The user wouldn’t be chatting with the LLM directly.

The point is that it doesn’t require a static dictionary to already have your exact phrasing and will just work with plain English.

The problem is in remembering the voice commands. I could never do it. Word the command slightly “wrong” and it won’t work at all (at least not in my 2014 VW).

I’m optimistic that the latest progress in AI will fix this when the technology matures in cars. I reckon this is still a decade away though.

There is a limit. The cost of electricity required is bounded by the value of the reward (block reward plus transaction fees). The value of the reward is bounded too, since the "import" of electricity into the Bitcoin economy is inflationary.

> could only be used to exploit a fraction

If anything this is a even a good thing, since it means that each individual vulnerability an attacker finds is less valuable to them.

There's no reason to hold the parents culpable. It would be up to the device manufacturer to ensure that this isn't possible on a system that has parental controls enabled. This is already a solved problem - see how MDM solutions do it, and see Apple's ban on alternative browsers.

It's not even necessary to block parents from giving their children Linux desktops or whatever. It'll largely solve the problem if parents are merely expected to enable parental controls on devices that have the capability.

> Even the idea of prosecuting parents for allowing their child to access 'information,' no matter what that information is, just sounds like asking for 1984-style insanity.

This assumes an absolutist approach to enforcement, which I did not advocate and is not a fundamental part of my proposed solution. In any case, the law already has to make a subjective decision in non-technology areas. It would be no different here. Courts would be able to consider the surrounding context, and over time set precedents for what does and does not cross the bar in a way that society considers acceptable.

> 1) Given that it just says you're a "child", how does that work across jurisdictions where the adult age may not be 18?

So namespace it then. "I'm a child as defined by the $country_code government". It's no more of a challenge than what identity-based age verification already needs to do.

> 2) It seems like it could be abused by fingerprinters, ad services, and even hostile websites that want to show inappropriate content to children.

This is still strictly better than identify-based age verification. Hostile or illegal sites can already do this anyway. Adding a single boolean flag which a large proportion of users are expected to have set isn't adding any significant fingerprinting information.

> I am a Russian proxy site, I make requests for you without the header. I serve you the content because I don't care about following American laws.

That's no different to a law mandating identification-based age verification though. A site in a different jurisdiction can ignore that just the same.

I'd be OK with an "I am a child" header mandated by law to be respected by service providers (eg. "adult sites" must not permit a client setting the header to proceed). On the client side, mandate that consumer devices that might reasonably be expected to be used by children (every smartphone, tablet, smart TV, etc) have parental controls that set the header. Leave it to parents to set the controls. Perhaps even hold parents culpable for not doing so, as a minimum supervision requirement, just as one may hold parents culpable for neglecting their children in other ways.

Forcing providers to divine the age of the user, or requiring an adult's identity to verify that they are not a child, is backwards, for all the reasons pointed out. But that's not the only way to "protect the children". Relying on a very minimal level of parental supervision of device use should be fine; we already expect far more than that in non-technology areas.

I don't see how MTBF is connected to obsoletion. My razors don't last long either. I buy replacement razors as required. But the model of razor I use doesn't obsolete.

> those gpu's will be obsolete in 5 years, but will the newer be enough better as to be worth replacing them is an open question

Doesn't one follow from the other? If newer GPUs aren't worth an upgrade, then surely the old ones aren't obsolete by definition.

Debian does not excuse security compromises by saying "oh nobody uses that far corner of our repository anyway".

You need to explain how one is supposed to distinguish and exclude "namespaces pretty much nobody uses" when writing code in this ecosystem. My understanding is that a typical Node developer pretty much has no control over what gets pulled in if they want to get anything done at all. If that's the case, then you don't have an argument. If a developer genuinely has no control, then the point is moot.

> I'd say that a forked, LTS apache2 (just an example) on a 15 year old LTS is likely used by 17 people and someone's dog.

Likewise, the number of black hats searching for vulnerabilities in these versions is probably zero, since there isn't a deployment base worth farming.

Unless you're facing something targeted at you that an adversary is going to go to huge expense to try to find fresh vulnerabilities specifically in the stack you're using, you're probably fine.

I agree with your sentiment that no known vulnerabilities doesn't mean no vulnerabilities, but my point is that the risk scales down with the deployment numbers as well.

And always keeping up with the newest thing can be more dangerous in this regard: new vulnerabilities are being introduced all the time, so your total exposure window could well be larger.

Theoretically it would hold its value and there would be a secondary market. Then she'd pay for the upgrade and not an entirely new machine. I wonder if that's the case for Miele.

It was always possible to create these kinds of images. Only you needed to be (or find) a highly skilled yet unscrupulous artist to do it, which didn't happen in practice. Now AI has commoditised this. It's not going to go away.

Regulating services can only go so far because as long as general purpose computing exists people will eventually be able to perform all of these abuses locally.

I think the only solution that will work in practice is to go after the abusers based on their intent. Going after technology providers is never going to work because the technology is fundamentally general purpose. Wherever the line is drawn, it will always be possible for abusers to take it and specialise it for abuse locally.

Edit: to be clear, I can't think of a legitimate use for this service and it sounds like their behaviour is abusive and they should be shut down. But that won't stop the abuse because sooner or later abusers won't need a service to carry out this abuse. They'll be able to use a generic tool to do it locally instead.

> Don't assume your laptop will work.

Agreed. Note though that the Ubuntu live installer has a "Try" mode that gives you a nearly normal desktop experience without installing, and is an effective test environment to discover what will work and what won't. Wifi, graphics and suspend are worth trying out this way.