You'd think removing friction on the software side for someone who already bought their hardware would be in their interest. Especially for students and hobbyists, who will want use what they already know once they enter the industry.
Why care about continuous sync? When I was in small robotics startup we had a separate motor controller driving each axis. A customers complained that the precision was getting worse after running for a few days non-stop. Guess what? Each axis had its own CPU clock based timer defining how long a segment should take. The difference is negligible but it accumulates over time. It was no issue for other customers who had a pause somewhere in their motion.
Why nanoseconds though? Usually a sub-microsecond sync is good enough. I can only think of some specialized phase measurements, really, like when you need to know from which direction a radio signal is coming based on timing of two antennas.
Happened to me twice (a decade ago, though) that I had some niche project (one a serial terminal, another a laser cutter firmware) that was on github with users left but the maintainer long gone.
I was able to pull the graph and collect patches and bugfixes from forks, like from a fablab somewhere using the same hardware, pushing to their fork with all their other location-specific stuff. In one case I discovered like four different forks with a different fix for the same problem.
Now you could argue the "social" part wasn't working if people fixed the same issue multiple times without knowing about each other. But at least github made it possible for me to collect everything there is, review and merge it into my own repo, and then drop a comment at the original issue tracker. (Which would have gone 404 had it been self-hosted, or with registrations closed due to spam.) In both cases I eventually got feedback from other people who found my branch and used it.
I know some European "automatic scribe" projects of the government sector. Their IT buys a physical GPU server hosted locally. Pretty sure it wouldn't be accepted otherwise (or maybe I'm just naive, but it sure is a topic they care about). The software stack is mostly open source, I think. It sure as hell doesn't talk to a big American cloud provider. (Well, the transcription service doesn't. Who knows what they do with the automated transcript. Probably the same thing they did with the manual transcript.)
Well said. There is a social context, there is a process and a struggle that can be more important than the result. It is sad to reduce art to the final product, or to approach it with an industrial mindset: maximizing commercial value while minimizing effort.
My doctor probably thinks we software developers do a very narrow job. And she is kind of right, we always turn up with those back problems from sitting too much, or RSI or whatever. While doctors have all those medical specializations and different roles and employers.
If it can go online, I'd prefer to use an android work (or user) profile with only auth apps in it, and nothing else.
As a separate device, it should be offline always IMO, and perhaps the size of a passkey. Or one of those banking devices with a display that show an authenticated text saying what you are confirming.
You'd think removing friction on the software side for someone who already bought their hardware would be in their interest. Especially for students and hobbyists, who will want use what they already know once they enter the industry.
reply