xani_

I always wished the throttle to be linked to slip sensor on wheels, say push back throttle a bit more when the wheels start slipping and not just wonders why WOT doesn't accelerate as fast as usual all while ECU is pulling power because of slip

We had users complain about migrating to MS Teams as the text part of it is almost entirely a piece of shit that every competitor does orders of magnitude better but management said "fuck it, we're migrating regardless", throwing oh-so-great arguments like "our customers also use it"

Only if you're extremely dishonest in comparisions.

Checklists at its core is just a list of common/required actions grouped in a list to don't forget during routine tasks. There is nothing limiting here, it is just a tool to aid repetitive/rare/complex tasks.

That's also easier way to design it in Factorio. When I was playing with Space exploration mod that's precisely what I did, the base sent "shopping list" and the provider sent stuff on that shopping list

> 1) Robust system design involves identifying the parts of your system that are mission-critical and always monitoring them. NASA missions have great automation and a 24/7-staffed mission control.

You should alert on critical parts but you should monitor anything and everything you can. It might be critical in finding out why system broke later on. Easier said than done for hardware but easy for software

The buggy behaviour of A caused buggy behaviour of B that caused buggy behaviour of C, just so happened to align enough to "look like it is working".

Double fuckup if the thing is backups and your data is gone. Reason why we check not only "does the backup job finished" but also "does the size looks right", because backup with 0 files still returns OK...

Eh, that heavily depends on language. Some have better tooling to get most of the typical errors out before the compile.

That being said I'm always suspicious and start to fiddle with them if I see test + code pass on first time

> For example, cars have "fail open" brakes but have independent cylinders so that it is relatively hard to have all four wheels fail at the same time (older cars had single master cylinders) - and one of the tradeoffs is that people want cars to get going immediately and not wait for brake cylinders to "charge up".

And emergency brake that's wholly separate circuit.

That's why in our monitoring we used nagios scheme + 1 (0 for invalid, 1 for ok, 2 for warning, 3 for crit, 4 for unknown)

Hell, some SUV low beams are already obnoxious at night...

Finally use for those massive screens used as dash

> Largely because we have a long inversion of how government should act. It should have never needed "approval" in the first place, government should have to seek to ban a product, innovation, etc based on their own creditable evidence the thing is dangerous.

Uh, no. There should be a well defined standard of what light need (light area of this and that size or at least this or that brightness) and can't (low beams blinding oncoming traffic etc.) do, then let market work within those limits. The regulation should have actual research behind it. Pretty sure that's how it works in EU.

Then if for some reason behavior of lights on the market causes problem, the standard should be revised, not ban random products for breaking rules that haven't existed when they were created (aside from extreme cases I guess)

> A whole lotta flickering is what would have happened. This literally became the paradigm for the patent office of what a trash invention that shouldn't be given a patent looked like.

and they started issuing patents for dumb shit regardless of that

> You may find it interesting the NHTSA is pushing for breathalizers in cars starting in 2026.

Yeah, another idiocy. They aren't reliable and need constant calibration, good luck driving a car full of drunks as designated driver...

Also interesting piece about why US was stuck in decades of same light design because of more stupid regulations

https://www.youtube.com/watch?v=c2J91UG6Fn8

Oh, oh, do orange turn signals next!

> The reason why it's easy to match Copilot results back to the original source is that the users are starting with prompts that match their public code, deliberately to cause prompt regurgitation.

The reason doesn't really matter...

And it does FFT in realtime too

I remember Dota2 (video game) did this, people fake reporting had less reports and they counted for less, while people that were consistently reported players that got punished got more reporting power. Only one report per match "counted" too so a group of player couldn't gang on reports on one player.

Of course that could be abused as well,but you'd have to make a group of people that first got the good rating then reported same people and that would be significantly harder

As facebook shows you can, and get away with it.

How's that compared to sshfs (wth cache/kernel_cache enabled) ? I've used it few times where I had need to dev like that and it was generally just fine for just editing a file, where performance tanked was doing a lot of file I/O at once (say updating git repo)

> That is not to say that formal verification takes 5x the work. You also have to write your source-code in such a way that it is ammenable to being formally verified, which makes it more difficult to write, and limits what you can reasonably do.

Also hire significantly more skilled people. Write formal verification on job requirement and the pool of candidates will shrink massively.

Explains why it is so rare really. "Spend 5-10x on developers to have some bugs not happen" is not a great sell.

Kinda why I'm not a fan of cloud, same black box problem.

> As someone who thrives on tracking down rare but annoying bugs in a debugger,

As someone that is cursed to inevitably find some obscure bug the second I start using some piece of software I'm happy I'm not the only one

> I wrote an article this past year that talks about silent bugs that slowly eat resources and collectively can be very expensive in terms of wasted time and energy

"Using JS for backend is ecoterrorism" lmao

> Here's a good trick I picked up for discussing contentious things - if you're ever tempted to dish out a sick burn, try to rephrase the point into a genuine question. Then the other person will have to walk through the logic of it, and if it turns out there is a real logic to their side of things, you don't get your ego bruised, cause you just asked a genuine question.

And if it doesn't they can figure it out and have a way to fuck off without losing face too much

Eh, not really. Main advantage of terminal stuff is near-zero dependency and working over SSH, if in addition to that it's pretty (in "more readable" way), why not ?

Web UI in comparison is always sluggish, usually required extra login method (instead of just sshing into client, or having CLI client with credentials saved) and in modern days require hundreds of megabytes of deps to even make the JS to run it

We use it as early alert to give more RAM. Just like a gig of swap per server regardless of RAM size.

> The only concrete answer to "why have swap if I have enough RAM" is "well, if you run out of RAM..."

Linux with swap available can swap out never used pages (say a part of library that never gets called) and use freed memory to cache disk IO. We see that on every server that has enough data to fill the remaining RAM with page cache. But you only need like a gig of swap to take advantage of it.

Once you swap a lot out and you get back some free memory linux will swap it back in on demand, which means a lot of micro-lag moments once apps start accessing now-in-swap things.

Linux assumes it's better to have not-used thing in swap while RAM is used for IO caching, that's why you see this behaviour, there is (AFAIK) no mechanism to go "okay, we have few gigs free, let's bring stuff from swap back".

Reboot-less method is to add new LV with swap and swapoff the old one but that's more PITA than restart...

Wrong direction. Bumping swappiness up means OS will make it more likely to keep more pages in cache, setting it to higher value makes OS treat it more like RAM and that's usually slow and jittery