andwur

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.

Likely referring to Android's Play Integrity/hardware attestation API (good explainer from GrapheneOS [1]) that is practically used to restrict what devices/brands/Android builds an app will allow itself to be run on.

[1] https://grapheneos.org/articles/attestation-compatibility-gu...

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.

Looking at just the `grit` executable, 58 of the top 200 largest file->resulting code sources are from clap-rs' derive functionality i.e. it's the command-line parsing. The #1 largest is, surprisingly, merge_trees[1] which comes in at 183kiB final binary size. There isn't so much code in that file that it seems reasonable, so it's potentially one of the derives in use (Debug being a common culprit for bloat) that's blowing it out. After those outliers it starts to level out quickly.

Splitting it by crate: `grit` is 13.6MiB, `grit_lib` is 4.8MiB and then it's `std`, `rustls` and `regex_automata` that are the next largest. So as pure library you could hopefully shave off quite a bit of that 25MiB.

[1] https://github.com/gitbutlerapp/grit/blob/main/grit-lib/src/...

The problem in isolation isn't new as such, but I think there's a combination of new factors to differentiate it:

1) the speed at which AI-generated codebases grow is far in excess of what human developers can achieve. What took years to accumulate in the past can be produced in a few days/weeks.

2) past large codebases that end up in a similar state would often see a mixture of developer talent. So while you might have a few developers who produce dross, there will also be a few who can pull it back together. You start to see threads of sanity appear, and from that the potential to refactor further, rather than the uniform spaghetti monster that's near unassailable from every direction that we're now getting from the pure-AI projects.

3) external perception differs. AI has been pitched, sadly by sales, influencers and shills rather than experts in the field, to business leaders as the solution to all development problems. When you present this issue to stakeholders you're then immediately put on the defensive, e.g. it's initially viewed as negativity for the sake of negativity. With past technical debt discussions, outside of a few key parties (too often the person responsible for overseeing said debt developing), I've found that it's relatively straight forward to explain technical debt, the need to refactor and maintain systems as a going concern. For the technically disinclined it's easy to draw parallels with building maintenance: you don't expect to build an office and then never spend another cent, it takes continued investment and maintenance to keep it safe, clean, functional and compliant. The difficulty again with the AI projects here I think comes back to the accelerated timeline, as you're inevitably going to be saying months after it's created that it probably needs to be burnt to the ground in lieu of the far greater task of refactoring it. As opposed to a legacy project that has been going for years or decades, where it's a far more palatable concept to take drastic action.

The AI pundits often seem to apply the logic that code output is directly proportional to revenue and/or profit, and as such it follows that an AI usage increase leads to more code which leads to more revenue.

I don't believe this aligns with the reality of any major company, unless your business is in the literal sense "selling code" your revenue and profit is tangential to the quantity of code you produce. Google is a good example of this: most of their revenue and profit comes from their ad network, which is disconnected from their development productivity and instead heavily reliant on network effects and time in market. If I was a new competitor with infinite AI funds to throw at whatever problem I choose, I can't simply capture their market by developing an exact copy of Google's ad platform. In the same way, Google can't substantially grow their ad network by coding "more" or "better", they still need more customers and consumers to interact with their network to see any increase in revenue.

So it doesn't directly follow that a productivity increase will inherently follow an AI usage increase.

Sadly that only works when all parties agree on the "clearly" part. They will lose, but only if you can endure years of squabbling in court and have unlimited funds for your legal team to prove that the aforementioned clearly really is clear. More likely they'll bleed you dry and force a settlement with an NDA bolt on. For a company like MS, pissing a few million down the drain on making life hell for litigants turns into a sound investment: no one looks at it and thinks "I want what they're having". This is where you would ideally have a government-backed consumer rights agency step in and take up the battle.

That's an oversimplification. Asset vs liability isn't a binary state but a superposition. An asset can carry liabilities.

Your asset might generate $10k a month in revenue, but at the same time may have a high chance of needing a $100k investment in upgrades and repairs to remain productive.

It's about denial of labour leading to denial of broader competition, rather than a true intent to build a competing product. If you were actually to follow through with building the product you would need a lot more than just engineers to roll out a successful product, effectively an entire company is needed, which would spread the company focus out and the lead to investor questions about your focus and commitment. Then if it's an unproven idea there's significant risk in going to market etc etc.

Cheaper to just lock up the talent and burn the wages. Bit of a ding to your books, big ding to your competitor's capability.

In saying that, it's a terrible practice. Massive waste of time, opportunity, talent and money.

This is quite a claim without any evidence to substantiate it. LLMs are nondeterministic models, whose behaviour is reliant on training data, model architecture and context (both in the general and domain specific sense).

There is absolutely no guarantee llm1(MD) == llm2(MD), by design. With the current batch you need to explicitly constrain a number of parameters, far more than simply the prompt, to get identical output from the _same_ model, let alone another model that has varied training data and/or architecture.

Standing a safe distance away, flanked by their union rep robots who refused to let their members go to work in such dangerous conditions.

Unfortunately we can't force them to go in either. They threatened to pull the entire humanoid robot workforce if we try...

On a more serious note however, I'm surprised there aren't off-the-shelf remotely operated rigs for assisting with this sort of situation: highly flammable/explosive chemicals under pressurised containment that need relief.

They may as well have just said: Company institutes an OKR that the IT division must spend over $1000/day/developer (fictious number). Company is surprised when IT division is costing far more than it did before. Company increases this to $1500/day/developer to build a system to identify why this has happened.

I feel like vibe coding is less of an issue than vibe leadership at this point, and vibe leadership has nothing inherently to do with AI. These people are getting a vague feeling in their giblets, and then chasing it to the illogical conclusion no matter the cost or outcome.

Protected from _what_ and _who_, exactly?

Are we protecting the owner of the vehicle from fully accessing the vehicle that they own? On my 2011 car I can hook into the OBDB port under the dash and have full access to everything but the alarm system (requires its a separate programmer), and it's safe: drivetrain modifications require the engine to be powered off to apply.

Or is it theft we're protecting everyone from? The main (technological) cause of which lately has been the one-CANbus-to-rule-them-all idiocy that has taken over car makers, including putting the alarm and locking systems on the same unmoderated, unauthenticated CAN bus as everything else in the car. So a quick light pop and you're able to talk to every system in the car. We're back to solving a problem that didn't need to exist in the first place, if car makers had just thought this through before rolling it out to everything.

The correct solution here is to not further restrict the personal freedom of property owners but instead to stop designing and building systems that require stupid, and somehow always dystopian, solutions to even more stupid problems.

Oh just wait, the AI phone service on their side will be more than happy to complete your device attestation key challenge by touch tone. We have to make sure you are still you after all!

But in all seriousness, many services are making it difficult through to impossible to communicate outside of their web or app platforms. Call centres are expensive and messy, and it's now apparently acceptable as a society to treat customers/clients/whatever as adversaries so they can get away with making it hard to communicate with them.

That's dependent on the credit laws of the country in question though. In Australia you have it both ways, you cannot unreasonably discriminate (e.g. race, gender etc) but at the same time you are forbidden from issuing credit to applicants who cannot meet the affordability requirements of said credit. E.g. issuing a loan to a customer who provably cannot afford it is a breach of the NCC, and the company is held responsible for this. As a credit provider you must make reasonable enquiries into a customer's financial position, failing to do this is a breach. You must also be able to explain and justify the decision to issue credit if challenged by the civil regulator (AFCA - who are granted significant power in addressing this), on the basis of a customer complaint, and they most certainly do not accept "human said no but the computer then said yes" without hard facts such as proven positive income flow (pay slips, bank statements), known expenses, liabilities and reliable credit history.

It's a different jamming scenario however. Starlink is comparatively centralised, and reliant on both terrestrial (ground stations) and satellite communication. While the terminals themselves are sparse and widely distributed, the backbone infrastructure is far less so. It's possible to target the satellites, ground stations and critical service dependencies (e.g. GPS) rather than needing to target the hundred of thousands/millions of terminals directly.

The mesh networks are dealing with, by definition, a sparse and widely distributed set of devices which are independently configured and controlled, and in their current widely available form are only dealing with terrestrial communication. Without that point of centralisation you would need to focus on targetted regional jamming, as from a practical standpoint you cannot perform wideband RF jamming over an entire country - signal jammers don't scale that well, and geographic features come into play. As an example you might effectively block mesh networks from operating reliably in a given city, but if people were to move outside of that area then the mesh would operate again. Geography is both a strength and a weakness here: a mountain range will impede direct communication with someone on the other side, but it will also have the same effect on jammers which will vastly increase the cost to deploy them in a ubiquitous fashion.

From personal experience that usually results in the person on the attack opening two additional issues: 1) the original issue recreated, maybe with a childish flourish added e.g. "because we're apparently in the DPKR for this project" 2) a new issue claiming baseless censorship and attacking the maintainer(s) motivation and governance

A variation on this is the above plus they get a hoard of friends/wellwishers/bots etc to raise more issues claiming censorship and it devolves into a massive ad hominem flame war, doxxing, death threats and the usual rubbish that ruin a good thing.

Sounds like a new remit for the NRO. Park a billion dollar satellite over an area to keep an eye out for petty vandalism. Then the sheriffs office can team up with Space Force: papers will be served immediately by LEO MIRV deployment, which may also count as execution depending on visibility and aim on the day.

/s - but it wouldn't surprise me at the rate things are going.

Ownership of paintball guns is regulated under the state-level firearms act in most (all?) states and territories.

You can use them under the direct supervision of the licensed owner, but it's still quite restrictive. If you were to take one and shoot at cameras on the street it would vandalism plus firearms offences, most of which start at inversion of innocence, massive fines and move pretty quickly into prison time.