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.

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.

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.

I joke, but this is surely what would eventuate.

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.

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

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?

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.

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.

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

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.

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.

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/...

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.

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.

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.