andwur

Or just the good old quality of life update where they forgot the <= v1.0.5 hardware used inverted sensor output, while >= v1.0.6 was non-inverting. "but we have lots of unit tests!"

Their marketing worked well here, most Tesla drivers I know have commented that they will never need to service their car. At least, they do until they wear their tyres to the point they disintegrate while driving. A mechanically illiterate public coupled with effective marketing is a dangerous combo when they're flying around in 2 tonne boxes still filled with wear parts.

Add in the suite of novel attachments of the prefix "cyber" to further muddy the water. The cyberfence will deter the cybertheives from accessing the cybercloud cybersuite we have just cybersold you (down the river on).

Competence isn't widely valued, obedience and sales figures are. Which wouldn't be so problematic if evolution could run its course and eliminate incompetence naturally, but that's now hard to see coming to pass when we have towering circular supply chains that feed on it.

Is this not a bias towards the status quo, conflating two entirely distinct problems?

We have problem A: receiving timely updates for life threatening events has not been implemented, or poorly.

Then we have problem B: social media companies have monetised engagement, without any guardrails to avoid detrimental effects, and continue to push to maximise this.

Just because the status quo involves a high speed, low latency, flood of unverified information via social media, which tangentially solves problem A in cherry-picked examples, does not mean it has to always be the case. This same proposed solution is also rife for abuse, in the same way a legitimate early warning can be sent out it can just as easily be used to spread hoax events.

Would it not make more sense to actually solve problem A, e.g. get the police to pull their finger out and use the emergency broadcast service available in just about every phone on the planet, and treat problem B as its own distinct issue? By conflating the two I don't see how we will ever solve either problem in any effective manner. By doing so we're essentially agreeing to a world where our best case scenario is the narrow intersection of A & B, while the rest of the time we're left with the full outer join of the two problems - bad access to verified emergency updates and a flood of engagement-bait crap on social media.

To be clear, I do not agree with how this legislation is being put forward nor with how it is proposed to be controlled. This is layman's legislation at its worst for a highly technical subject, and even in a more charitable light I struggle to see it as anything but a distraction and power grab rolled into one, with little likelihood of solving the problem at hand.

Oh sorry, you picked "AWS Backup" but you actually needed to use "Backup AWS" to solve that problem. Perhaps hop on a call with our sales engineering and cost magnification teams to guide you to a better, more solutioned, tomorrow?

Good workaround! It's just sad that to achieve the previous behavior we now need to burn significantly more compute, and in turn energy, and with far worse performance and an inverted UX.

The most frustrating part is that they have all of the data, and oodles of compute, available to surface the same very functional experience they originally offered, but they would prefer the image of being visionaries rather than the reality of being useful.

And for the illogical conclusion: buy factory equipment to make just the butts to minimise your running costs and limit supply chain dependency.

I joke, but this is surely what would eventuate.

I too have run into this problem on a number of devices. The client's supported codec/media format detection logic appears to be extremely pessimistic. To the point that the mere existence of certain audio track formats and subtitles can trigger transcoding, even when said tracks/subtitles aren't actively used. The same files played via MPV on a file share, i.e. no transcoding possible, play without issue.

I've tried tweaking both the clients and server to be less pessimistic, i.e. see if the active media elements are supported, but even then it really fights it. I think the best approach would be rewrite the clients to adopt a (try || transcode) strategy rather than (guess || transcode), but that looked to be a major piece of work.

How are the economics of this idea meant to be viable? The proposed business model is to park hundreds of millions to billion dollars of satellites in orbit, plus the costs to maintain and operate them, to meet the goal of selective area illumination and solar power. Ignoring the issue of cloud cover, which still seems to be an impediment. That's going to need to directly compete with terrestrial energy storage technology, e.g. batteries, and... general lighting. Both of which are well established, diversified and reliable market segments with vastly cheaper MWh costs compared to beaming a small amount of light down using a satellite.

This strikes me as another hand-waved scifi/fantasy inspired investment, where everyone is so caught up in proving they can achieve this (spoiler: this is obviously possible) that no one has stopped to ask does that achievement lead to a real benefit outside of VC wealth transference?

What if your licensed component is non-trivial, e.g. provides critical features so that omission renders the service entirely non-functional? These laws would need to cater for that scenario, as skimming over that detail and allowing stripped releases would either mean:

1) companies get to release broken, incomplete source under the banner of commercial licensing restrictions.

2) truly upstanding companies (/s) will use this as a loophole to block the majority of their source as commercially licensed by stuffing it all under related companies and licensing it back to themselves. e.g. Company A selling game licenses majority of source (say, the entire server platform) from Company B -> Company B can't be compelled to release their engine because they aren't selling the game.

#1 would be an annoyance through to major challenge depending on the scale, #2 seems a more likely outcome for the major players as they can afford to play that sort of game and get away with it.

To be clear, I think this law should be implemented. However it would be pointless to pretend that licensing constraints won't add significant complexity, and many inventive pathways to highly evasive yet technically compliant outcomes.

> Like....what licencing issues? After the game is "dead" and the parent company doesn't want to support it anymore, we could easily release the source code or even just the executables for the servers.

I can't speak to the parent's stance, but more generally this would be referring to IP licensing and patent encumbrance. I've worked on a number of large systems where non-trivial parts of the codebase were licensed from external parties with distribution restrictions in place. Even the executable versions would be problematic as the contracts go to great lengths to lock it down to strictly company XYZ may modify and use the IP, but nothing else regardless of the form or means of distribution.

Releasing said systems as-is would require either relicensing to allow distribution (very costly and potentially impossible if the vendor declines), or replacing that functionality with a cleanroom implementation. Which is both costly, time consuming and difficult. You may also run into further issues there if the contract forbids cloning functionality, or even worse: if there is patent encumbrance you have to go back to the relicensing option.

Unfortunately that's non-DAC copper cabling life it seems. They build them to work at the rated speed at the maximum rated distance (on the transceiver, not the spec) and none of them appear to link train to reduce the power output over shorter runs.

If you use a DAC they usually run cool, and optical is even cooler.

Could do with a difficulty setting that includes when you inherit someone else's log pile, someone who really enjoyed making every cut on a new and more inventive angle than the last.

Normally a wedge is used to split the wood, but it also doubles as a wedge to be wedged underneath just so you can get the log to stand up.

Also, Y sections (ycombinator mode?). 40 hits later and you might have a nice pile of woodchips, very rarely will it actually split in any clean way.

Vastly different target market and/or features there. Mercedes are chasing maximum power density, minimum weight for high performance deployments, with seemingly little concern for cost or supply chain.

Renault is going after the consumer market with these motors, where minimising cost and maximising availability is more important than pushing past 95% efficiency or cramming a 700kW power output in a motor that is small and light enough to fit inside of a wheel hub.