I'm seeing people who _used to be_ like that losing that understanding without realizing it's happening - they have a superficial idea of what the code is doing, enough to feel like they understand it, but the change is apparent when watching them handle something unexpected.
That's certainly what I expect to happen. LLMs will ruin your software if you don't hand-hold them, but it'll take time for that to happen. And until that does happen, businesses hell bent on using them won't have anything to push them into realizing what a mistake it was to use them.
1. "Nonsense, if it was a code-quality issue from the AI stuff, we'd have seen problems sooner, like in the first few months or a year. Oh, sure, some engineers complained, but that was just an adjustment period because they stopped once we told them we didn't care and mandated that they up-skill into the new AI-centric workflow future."
2. "The bold new AI initiative I put into place can't possibly be wrong, this failure is on the engineers who were responsible for overseeing its operation. This is supremely disappointing because we made their jobs so easy, they no longer have to write code, just review several dozens of pages per day with unremitting paranoid vigilance and attention to detail."
This, plus anyone responsible dodging that as soon as possible via job hopping. Harder to do in the current job market but internal transfers are still available, most of the time.
I was pretty early in the LLM stuff and I got called out on using it back in the day, because I showed the exact symptoms we see now, but as soon as management jumped on the train all the coworkers did a 180 and I alt tabbed out into a different department thinking it would change something... well it didn't :'D
I guess it will take some years till we are sane again or not...
I revisit it to see if the promises are unbroken now from time to time with every other update and these days it doesn't look so good. It is non deterministic all the way down.
If you're going to put the graphics and NIC into separate VMs, surely the secure screen can be another of those semi-privileged VMs rather than part of dom0
Apps built with a toolkit which ships its own filepicker will immediately attempt to enumerate directories in `/`, `/home`, and probably a few other places.
Apps with a config file will often try to read `~/.config/myapp` and also `~/.myapp/config` and maybe one or two other places.
If it's technically.implemented uniformely without thought of user access patterns, then yes it's a bad idea causing friction and frustration.
If I drag&drop a file in an app or it's icon, or by right click. The permission would be implicit.
For configuration files they could be part of allow rules, since they are so common if they follow the XDG specification.
For saving files, flatpak apps could be allowed to save anywhere in the users home sub-directories (not home top-level) as long as it doesn't overwrite any existing file. There are downloads, public, documents pictures, videos, that are barely used by default.
There is plenty of room for better desktop based integration, while of course lacking funding and care for users (thinking of particular devs in this case).
Currently it's a mishmash of separately using flatseal (and equivalents) and having your fingers crossed if you're likely to exfiltrate or not your data.
I'm assuming that the config scenario can be re-routed so the app thinks its opening that file but instead gets routed to different ones transparently.
If the file picker enumerates N different directories immediately (which aren't the active one) that causes a problem yes. I guess allowing enumeration access _anywhere_ (but not file read access) isn't a necessarily a problem.
The list of files that such app would try to access by default on initial startup would be finite and well defined. So, a Flatpak package of such app should already, if done "properly", (I'm just imagining here, not an expert) include allowed access to those paths by default.
If browsers extended `srcset` with support for HTTP Range requests, we could use a progressive-encoded jpg (xl or not) file as the source for multiple detail levels.
A device with a small screen would request the first 10kb of the image, while one with a medium screen might fetch 40kb.
The big advantage of that - for sites with many images - is a much better cache hit-rate for a given CDN spend.
Additionally, if you've already fetched a small version of an image and then want to view a bigger version, you've already got partial content downloaded & can fetch only the rest of the file.
I don't think this is going to work out. With the way progressive loading works in JXL, you don't really hit "good looking" points aside from at DC resolution.
Just being able to get 1/2, 1/4 or 1/8th of the image resolution would already cover most of the srcset use case and the results are good enough for many existing image decoders to already use this optimization for the decoding if not the network part.
EV's have 100% reduction of NOx/tailpipe VOCs, 100% reduction in soot/tailpipe particulates, 70% reduction in brake pad dust (due to regenerative braking), in exchange for 25% increase in tire wear.
Vehicles are capped at emissions of 3mg/mile of particulates and 30mg/mile of VOC's. Something like 1-2mg of tire material actually becomes airborne PM10 particles every mile (and only about 10% of that for PM2.5 particles).
So, EV's really do a great job reducing emissions from 35mg/mile to <2mg/mile (PM10) or even <0.1mg/mile for PM2.5. A 95%-99.8% reduction in air pollution near highways would seem absolutely fantastic for me and my children!
> EV's have 100% reduction of NOx/tailpipe VOCs, 100% reduction in soot/tailpipe particulates, 70% reduction in brake pad dust (due to regenerative braking), in exchange for 25% increase in tire wear.
I replaced the tires on my Tesla model 3 at 74,000 km and they still had tread above the indicator bars. I'm now at 140,000 km and the tires look great, the back ones look like they're only about halfway done. I might be an outlier but my previous Subaru needed tires every 50,000 to 60,000 km.
Needless to say, the brake pads have never been touched and when I saw the left front one at around 110,000 to 120,000 to patch that tire, it looked like it was just installed. The regen braking almost completely eliminated the brake pad or rotor as a wear item.
Yeah, aren’t the EV tyre’s compounded differently in some way to account for the extra weight?
If the weight on each wheel is greater I’d have assumed the tyre would need to be harder, for the same performance.
I would have assumed that would counter the otherwise additional wear, but I keep hearing EV tyre pollution is higher and yet everyone who owns one has always said they aren’t changing tyres an more than they did on their combustion cars.
Given that tires have a range of warranties from 40,000 miles to 80,000 miles ... it's possible that the tires are wearing 25% faster but the consumers aren't noticing because it's still around the normal 40k-80k mile range.
No matter the warranty - I still notice when I replace them.
And the warranty requires proof of periodic rotation. If the tires are wearing evenly, as is the likely case for a new vehicle, then rotation costs significantly more than the pro-rated rebate.
One might similarly note the awe-inspiring destructive power demonstrated by tanker trucks of fuel catching fire and causing interstate bridges to collapse.
You're speculating about something that hasn't happened, using something that doesn't exist; no body is driving batteries large enough to destroy a bridge about.
They are driving liquid fuel tankers that can do that around regularly.
Also consider that as battery tech improves new chemistries lower the risk of fire even more. E.g. sodium batteries are very stable right now and solid state will improve that further. There's no way you can make petrol less flammable.
You're going to have to face facts, battery powered vehicles are safer than petrol powered one.
Consider that every single human being on the planet carries around a lithium battery in their pocket, at a large percentage of those batteries have experienced such damage that would destroy the glass screen on those devices, and yet people are not bursting into flames regularly, and even the defective batteries that Samsung distributed for a while only made events extremely rare.
I've seen a few senior developers who weren't great programmers, but could communicate effectively, manage up and down, etc. So long as they were willing to defer to others on harder technical topics, they usually made pretty good team leads when/if promoted.
reply