Right to repair is unrelated.

That movement is mainly about requiring manufacturers supply to consumers and independent repairers the same repair parts, access to information, and tools such as diagnostic programs used by their authorized manufacturer repairers.

Right to repair does not have anything to do with making a device continue to run after termination by the manufacturer of availability of cloud services or an app they designed the device to depend upon.

Right to repair has also been co-opted by the large manufacturers and their lobbyists by getting major concessions written into the right to repair laws that essentially make them useless. For example Apple won't have to supply their individual specialized chips on a module, and they can make it available only as an entire assembly for order which will cost more than the phone.

They can still avoid supplying necessary tools to calibrate a new lid angle sensor for "security reasons".

Essentially: Right to repair was a great idea, but it has essentially failed because it has been co-opted and rendered ineffective, and it did not apply to this particular issue in the first place. For these reasons you need a new movement on this issue that you could think of as proximate to Right to repair, but it's still out of the scope of what Right to repair proposals have sought to accomplish.

We need a Stop killing electronics movement to complement the stop killing games movement. Concerning the design of electronics that cannot be operated at some random time in the future when the manufacturer decides to shut down their cloud servers.

In this case, if you've connected them via HomeKit then they'll carry on working without issue.

Unless you need to rebuild your home network or factory reset the device for some reason to troubleshoot it, Then it will be bricked.
The unit also effectively lost its resell value as the new owner won't be able to set it up on their new Homekit network.

I see.. Well this is unlikely to affect installs of Ubuntu then, unless you actually install it as a graphical desktop environment. Containerizing Chromium may be a very smart decision for them; however.. the program is a huge security risk, since it interacts with untrusted websites and likely has 0day vulnerabilities yet to be discovered. Sandboxing Chromium's file access to a container could help mitigate some potential exploits.

I just have no need, since there are several other perfectly robust solutions, and snapd or whatever they call it is late to the party. QEMU-KVM with a separate virtual machine window for each of my Chromium sessions. plus Qubes OS.

There's another problem in that the Smithsonian owns the Discovery now, and their bill "requires the director" of this Private institution to not only work with NASA to plan a move of the shuttle, But also to Transfer title ownership. In other words an eminent domain takings. The US Constitution has this thing called the 5th amendment which requires that just compensation: Fair market value be paid for such a taking.

How much money will the US government be required to pay the Smithsonian as "Fair market value" for the Discovery in order to conduct this taking? I'm pretty sure 85$ Million doesn't cover it. I would guestimate they need to pay out $3 Billion at a bare minimum not including all the costs for logistics in order to actually perform the move.

It'd take a lot more than the $85 million in the bill just to re-commission one of these.

They were decommed, And probably no longer maintained nor owned by the US government. How much to buy back the remains of those aircraft just to try and rebuild them? They might be better off contracting Boeing to build a new shuttle carrier at this point.

Nothing. The budget reconciliation process allows them to congress to set aside money for things, And corrupt politicians can never pass up the opportunity to propose some money be set aside for pet projects in their district - helps them stand for re-election.. See guys? I got the shuttle to be moved back to our district; you should vote for me so I can get more special stuff for you.

There really isn't a reason why it can't be cut apart and crudely welded back together

Yes there is. That would destroy the authenticity of the artifact completely from a preservation perspective; it would no longer be the Discovery intact. That is tantamount to cutting up the Mona Lisa and pasting it back together. And the trust that owns the shuttle should never agree to it. Congress can go f*** themselves.

The worst ones we get in Texas are a "blue alert" because a cop stubbed his toe--a 12 hour drive away.

Fortunately you don't have to turn off all alerts, and I don't--but most are useless. Even the Amber and 'clear' alerts are useless, often for places several hours away. Maybe state-wide ones work fine in Rhode Island, but not in Texas.

They won't (and can't) take legal action against you for doing that, and they will honour all their contracts with you regardless. They won't do anything to you at all. They will just decline to do any new business with you in future.

I have a novel proposition for you then.. How about you mirror RPMs and SRPMs privately. And when the SRPMs finally get redistributed publicly it will be by a 3rd party several distribution hops away from any of the companies that hold the support agreements. There will thus be no record regarding which Redhat customer caused the SRPMs to get redistributed.

And if I understand this new program.. You can get it for free now, so there can be thousands of people signing up for it and downloading RHEL and the RPM packages and SRPMs, and it will never be clearly exactly which customer or customers is redistributing it.

In their Opinion they comply with the GPL, because you are not legally prevented from redistributing the SRPMs.

They have a Policy that they will retaliate against you distributing SRPMs by terminating your contract and access to download software from them.

Are you sure snaps are "unavoidable"? I've got many Ubuntu servers and have yet to use a single snap.

Debian is my current choice, and has been for a decade, but ANY distro can be coopted.

I would say Debian cannot be "coopted". They may decide to make changes at the core that you don't like, but they're not going to turn into a product with enterprise entitlements.

10 minutes is probably a little bit low given how complicated and how messy enterprise software is but you're looking at maybe one Sprint to add this.

Probably true, but What I am saying is that additional time beyond the 10-minutes does not belong as part of the cost of compliance That is the cost of Automating the rest of the cancellation process within a company's automation framework. The FTC does not mandate you integrate the cancellation though. For all they care the Cancel button can automatically spit out a printout at HQ Which is to be processed in the same exact way that the company would process a Letter written by the customer formally voiding their subscription contract and terminating the company's rights to provide and bill them for service.

From a compliance perspective: You are done as soon as you have caused the ability to create a written record which must be processed by the business to cancel service.

The cost of actually performing the cancellation of service to comply with that customer order after that record/order is produced is Not part of the cost of compliance. Also the cost of lost revenue is NOT part of the compliance cost. The revenue is lost because the customer wishes to cancel, and not due to compliance with a rule.

That is part of the cost of cancelling a subscription when ordered, or Upon receiving any kind of notice in writing from the customer terminating/withdrawing from their agreement; Which companies are legally required to do before the FTC rule ever went into affect.

Or, even better idea, they could have put overheat protection in the Switch 2 in the first place.

BOTH the Switch and Switch 2 have an overheat protection sensor. If the console gets too hot it will immediately drop into sleep mode. It's probably not enough, because running too hot over time is bad, even while technically not overheating.

Many people are already having problems with their Switch 2 overheating in both modes; whether docked or handheld. This notion of 3rd party docks creating such a problem is unfounded I would say. Because the first-party dock already has the problem. The only thing a 3rd party could do is possibly embarass the crap out of Nintendo by including better cooling and/or success unofficial warranty-voiding mods to the Switch2 to improve cooling thus outcompeting them on additional sales of official hardware.

Um - on a geek site I would expect that readers would be familiar with the huge role copper plays in the grid. If you don't know this, jfgi.