Prefabricated boards with attached motors, sensors, and often WiFi? Rip that out for robot guts. Screw the Raspberry Pis, arduinos, and whatnot.

Unless you have a use for the waste heat, you're better off with systems with better performance-per-watt. These are usually low wattage chips, but they can't do much math-wise.

You could do that too, but if the SHA3 is not deemed sufficient protection, then we are
screwed anyway. Embedded devices might choose to ignore the SHA2 to save on
compute resources.

Well, if x509 has simply allowed for multiple signatures, we could just put both SHA2 and SHA3 signatures on the certs, and consumers of the certs could move towards supporting SHA3 as their security requirements dictate, ignoring the SHA2 signatures when they have a SHA3 signature available to them.

But as with everything PKI related, the people making the calls have some blind spots when it comes to making things forward compatible or even particularly maintainable. It's as if they've never had to a day of PKI gruntwork in their life.

Well
you
can
go buy
a
500x65000
resolution
monitor
then.

Yes. Because those are different constructs. Live with the fact that both are useful.

And having a hash makes ==/=! run in constant time most of the time. And then you could also add an indicator for encoding. And some flags for the garbage collector or if not that at least a COW flag. And then suddenly you find you're using more than a cache line for just one variable in a critical code section even when you're pabsolutely sure the string can only contain "TRUE" or "FALSE". And that is part of why my applications seem to run slower and slower every year despite my hardware being upgraded.

Personally I prefer functions to use parens. Like in math. It makes sense visually and keeps things organized. Are you allergic to the shift key or something, or do you just enjoy the mental challenge of parsing things in your head. You'd seriously prefer this:

thingA thingB thingC,4,7,thingD thingE

to this:

thingA(thingB(thingC(4,7)),thingD(thingE))

?

For which one do you have to consult the documentation, if even extant, to figure out the arity of things?

Then use a struct with pointer and length. Use the right tool for the right job. ZTSs are for things that utilize the efficiency of knowing nothing is sending you strings longer than you can handle efficiently and can take advantage of not having to worry about syncing a length counter in RAM. If you use the functions that use ZTSs for multimegabyte content that you need to find the length of frequently, you're using them wrong.

As crotchety as C is, at least they realized that a toolbox full of nothing but powered hammerdrivers is less than fully useful.

(If only they had handled endianness better. Or at all.)

Only half. The other half is "and still get screwed over."

The cert authorities as a whole, following NIST recommendations, decided to not just stop issuing 1024 certs, but also to revoke their 1024 root certs, so anything checking CRLs would just break. Months before the actual deadline. They could have just let those certs run out on schedule, but that wasn't good enough for NIST. Moreso, they could have only sold them such that they ran out on schedule (we were sold a 5-year 1024bit cert in 2009 when the deadline had been set at EOY 2011 since 2005). After an extension by NIST from EOY2011 to EOY2013, made in 2011, the number of certs issued with expiry times much past the deadline was likely pretty small (so in case the NIST estimate of when someone would have the compute power to crack our cert was off by 6 months, we had to swap it out a year early distracting us in the middle of more important things.) Anyone concerned enough to worry that an obscene amount of CPU power would be dedicated to compromising their particular cert would have changed them voluntarily, and even the laggards would have likely made it under the wire before any serious attack on their crypto infrastructure. Finally, lots of people use these certs in internal settings where the crypto isn't the sole security and the real value of the cert isn't crypto but the fact that users don't have to install a site-owned PKI CA root certificate to get the "annoying popups" to stop.

Sooo... it was fortunate that almost nothing was checking CRLs during all that, though as a general state of affairs that also needs to be fixed.

Oh sure, the CAs offered free bridge certs to "make up" for the whole thing. Not good enough. They should have comped an extra year on for free or something. Since they didn't there should have been class action suit to make them pay for the hassle.

People need to quit breaking shit on a whim.

...and an understanding of shell scripting including obscure parts you normally don't use on the CLI ...and familiarity with many commandline utilities. ...and understanding how your package manager handles upgrades that touch the init scripts ...and eventually figuring out why half of the setup of facility FOO is in 51-pre-FOO and the other half is in 99-post-FOO ...and then figuring out that you could get away to moving that to 50-pre-foo so it gets run before 51-pre-bar, 49-pre-FOO won't work ...and the options to your system's start-stop-daemon or equivalent ...and how to get all the stuff called from the init script to belch debug info on demand, if that's even supported.

While personally I think all of the above is still preferable to memorizing what exactly things like RestartPreventExitStatus and ReloadPropagatedFrom mean, and being able to remember their names when you need to use them, it's a difference of margins not a giant difference.

Well, actually I wouldn't say I'm an advocate more than I just recognize that's it's got enough good points and enough traction that it'll be part of my life in the future whether I end up liking it or not.

You do have to put a fraction of the time you did in 30+ years of learning your way around SYSV systems into actually learning systemd in order to expect the same level of proficiency. Someone who hadn't your experience would find SYSV just as confusing; if you don't think so you are underestimating your level of learnedness..

That said, yes, the biggest problem with systemd is the large volume of non-mneumonic, inconsistent identifiers that were obviously chosen in a caffeine-induced fit of megalomania, and the fragmentation of the source between internal code and config files. However, even more traditional systems have started to similarly fragment things, what with things like udev rules smattered around in share/lib directories and not just under /etc anymore and distro scripting frameworks likewise.

Those who think systemd is "dumbed down" after listening to an advocates "it's easy" sales pitch, or because it tries to squash everything into the (yes, incorrigibly stupid) flat sectional config file fomat could not be more mistaken, however. It is actually just trying to improve total system modularity and break some longstanding unnecessary interactions. Some of that it is doing in sophisticated ways, and some of that it is screweing up in some pretty stupid ways. It's now been turned loose on the world and will have to be tamed; it is not just going away because there will be plenty of people who learn to use it effecitively.

Good. It can use the benefits of Linux without having to cripple itself to conform to portability abstractions.

Way to much blood sweat and tears have been spilled at the portability altar.

I have to kind of agree to that point. I'd give it maybe BETA, but definitely the burden seems to now be on the community while the eventual credit will juice the egos of the originators as they move on to piss on other trees. I think systemd has potential to be a significant improvement as the larger community gets into it, debugs the things the core team left untested, undoes some of the crap decisions, and eventually forces democracy into the development process through a process of acrimonious forking and distro foot dragging on versions. The SYSV systems that have been at the heart of distros are not more capable/maintainable, they are just more mature. The fact that there was some consideration given to alternative viewpoints (like not wanting your service controlled by dbus) makes it less evil than it's made out to be by some, and it does address more modern concerns that were not around when SYSV set some things in stone.

If the community has enough patience to get systemd up to snuff I'll just learn to live with the crappy ArbitraryVariableNames and INI-format flat grammars that fail to hide necessary complexity behind HeirarchicyInArbitraryVariableNames.

Not even "math" so much as arithmetic. Not that it isn't a rational approach, minus said flaws in the source data.

Well, to argue semantics if we learned how to regrow a lost arm, we'd have "reversed" amputation even though we can never restore all the lost opportunities to scratch one's ass.

But your general point that people should not expect the alzheimer's patient to necessarily start to remember everything they have forgotten is well taken.

I'd give the word choice a 'B' in that they could have done better but reasonably intelligent people will understand what is meant.