I was a kid without any PC anywhere in 40miles around me, had no idea that SCSI had to be terminated or anything. I don't remember any jumpers on the drive, though.
My first guess was debouncing. They assume that the switches are worn out, deeply weathered, and cheaply made. Each press will cause the signal to oscillate and they're taking their sweet time to register it.
When the device is new this is an absurd amount of time to wait. As the device degrades over 10, 20 years, that programming will keep it working the same. Awful the entire time, yes, but the same as the day it was new.
I was late for a train at my local station and the parking machine was taking ages to respond to keypresses. I could see the training pulling up to the platform and I was still stuck entering the second digit of seven. In my shameful frustration I hit the machine fairly hard. While the button presses might take a while to register, the anti-tamper alarm has really low latency and is also quite loud.
You need to find the right person to complain to. Here we are sympathetic, but can't do anything.
The right person is the other riders on the train - but the hard part is to frame this such that they join you on a march to the the agency that owns that machines to complain. I wish you the best of luck figuring out how to do that (I don't know how to do it - and if I did there are might higher priority things that need to be fixed).
Well it was six years ago, I work from home now and take the train once a quarter, and they've augmented the machines with app parking now so I have nothing to complain about anymore :)
Debouncing would be smart, sure. But sometimes, these sorts of embedded machines are weirder than that.
At Kroger-brand gas stations near me, I get to interact with the buttons on gas pumps to select options and enter a loyalty ID.
Those buttons have visible feedback on a screen, and also audible feedback consisting of a loud beep. And there's always delays between button press and feedback.
Some combination of debounce and wear might explain that easily enough.
Except... the delay between pushing a button and getting feedback is variable by seemingly-random amounts. The delay also consistently increases if a person on the other side of the pump island is also pushing buttons to do their own thing.
It's maddening. Push button, wait indeterminate time for beep, and repeat for something like 12 or 13 button presses -- and wait longer if someone else is also using the machine.
I can't rationally explain any of that variability with debounce.
Or perhaps the original programmers skipped the class on concurrency 25 years ago, and nobody has subsequently bothered to pay anyone to update that part of the software.
One time I decided to test whether these grocery story loyalty card XX cents off per gallon transactions were properly isolated, when my wife and I were both filling up vehicles at the same gas station at the same time. We both got the $0.50 discount per gallon with no problem. I'm sure there are lots of creative ways you can exploit the poor design of these things.
Yeah. Just like another engineer. When you tell another engineer to build you a feature, it's improbable they'll do it they way that you consider "right."
This sounds a lot like the old arguments around using compilers vs hand-writing asm. But now you can tell the LLM how you want to implement the changes you want. This will become more and more relevant as we try to maintain the code it generates.
But, for right now, another thing Claude's great at is answering questions about the codebase. It'll do the analysis and bring up reports for you. You can use that information to guide the instructions for changes, or just to help you be more productive.
I don't understand this comparison. An EV's battery cooling system is a cooling system. Regen braking isn't more complicated than an alternator.
The rest, yeah. The chemical stacks in the batteries are expensive, and dealer markup was a problem (now they're 47-56k new). But the energy costs! $7-12 for a fill-up on home power overnight instead of $75-85 at the gas station.
And maintenance. So little maintenance. For local non-towing fleets these would save a lot.
Only if you have a home or some other super convenient always available spot. I don't and EVs are non-existing to me for another decade at least, simply too much hassle even if ignoring all other downsides (I don't buy new but mildly used for 25-30% of price of new which for ICE means 95% of the car, I do sometimes family 1500km drives like another one in 2 days - PITA with overcrowded electric cars, in cold which is normal here they become fraction of their capacity and drain battery continuously when parked and so on).
Its future but its coming/will come at very different time for various folks
> Regen braking isn't more complicated than an alternator.
Either disingenuous or ill-informed. one is ~1KW for a few seconds a day, the other is > 100KW of power for dozens of seconds, multiple dozens of times a day. completely engineering
No they won't. DoD is small compared to the rest of the software market. You get better quality and lower cost with COTS than with custom solutions, unless you spend a crapton. The labor market for software's no different.
Everyone likes to crap on C++ because it's (a) popular and (b) tries to make everyone happy with a ton of different paradigms built-in. But you can program nearly any system with it more scalably than anything else.
In my experience people criticize C++ for its safety problems. Safety is more important in certain areas than in others. I’m not convinced that you get better quality with C++ than with Ada
Go was built because C++ does not scale. Anybody that's ever used a source based distro knows that if you're installing/building a large C++ codebase, better forget your PC for the day because you will not be using it. Rust also applies here, but at least multiplatform support is easier, so I don't fault it for slow build times
Go was created because Rob Pike hates C++, notice Plan 9 and Inferno don't have C++ compilers, even though C++ was born on UNIX at Bell Labs.
As for compilation times, yes that is an issue, they could have switched to Java as other Google departments were doing, with some JNI if needed.
As sidenote, Kubernetes was started in Java and only switching to Go after some Go folks joined the team and advocated for the rewrite, see related FOSDEM talk.
A lot of people hate C++, that doesn't grant you the ability to make a language, however very few have the opportunity to create a new language out of free time provided by said language taking too long to compile.
I do not know why they did not go with java, I imagine building a java competitor (limbo) and then being forced to use it is kind of demeaning. but again, this would all be conjecture.
C/C++ basically demand that codebases be large. And we hear all the time about software troubles written in these languages. Finding reports of this are almost endless.
I think people who write complex applications in more sane languages end up not having to write millions of lines of code that no one actually understands. The sane languages are more concise and don't require massive hurdles to try and bake in saftey into the codebase. Safety is baked into the language itself.
Very few people have a problem with just paying for cosmetics in a game. The main issue here is that it's gambling for cosmetics, rather than straightforwardly purchasing specific items.
Most people do have an issue with it, because every game that's replaced loot boxes with discrete cosmetics purchases has to then massively increase the price of them. For 20 bucks in Overwatch 1, you got (afaik) 10 loot boxes which all had 4 random items. In Overwatch 2 20 bucks barely gets you single good skin.
It's very much a grass is greener type of situation in my experience, having been part of communities of both types of games.
Slowly getting their stuff independent of wintel gives a lot of flexibility. And the big gaming market's on phones / tablets. A steam controller could find itself paired to an iPad running steam in a year or two.
The only play I see here is a legitimate Valve console to take on XBOX and Sony. Plus Arm on a Steam Deck would improve the battery life considerably (assuming they are able to integrate with some powerful GPU solution).
Microsoft's a competitor. And they have a reputation for being the first ally to stab you in the back (e.g. SGI / DirectX). You don't want to depend or trust them when they like the market you're in.
> way for the community to fight this is to keep finding holes in the app until they stop trying to put one on
I'm not familiar with Indian activist tradition. But if we look at other countries where this happened, the technical attacks didn't work. It had to be done through policy, instead.
Yeah this is the wrong audience for this argument, but it has merit. An app like this can be both a massive government power grab and useful to protect many, many people who are vulnerable to fraud.
The number of my relatives that will just believe whatever someone tells them on the phone is terrifying.
reply