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