> There's really no excuse for the library not having simple case conversion functions that operate on strings in-place.
Could not agree more. Any time I touch a C I want to scoop my brain out of my ear. So many simple unbelievably common operations have fifty "best" ways to do them, when they should have one happy path 99% of usecases require baked in. Nobody should ever have to seriously consider something as ridiculous as "is tolower addressable?".
Considering we're looking at an adversarial nation state (famously full of script kiddies) which is absolutely hell-bent and motivated to tackle their drone problem, and not once has that state or its script kiddies commandeered a single drone - nevermind a fleet of them - (nor are the script kiddies even remotely in range?) I don't see this being a problem now or in the near future.
It isn't a problem until it is one, and the it can be a huge problem. I don't know anyone who was ever made to look foolish saying 'it is improbable, but let's prepare for it anyway' whereas plenty of graves are filled with people who said 'that will never happen'.
Sadly generals, or at least the high command, tend to fight the last war, and tend to be fairly conservative.
WW2 was a classic example. Every nation except the US still had bolt-action rifles as the standard infantry weapon, on the belief that giving every infantryman semi-auto was a waste of ammo/too expensive/too heavy on logistics. Also motorization was not appreciated until late in the war, even in the German army - which despite all the attention devoted to the panzer/panzergrenadier divisions, was maybe 20% motorized at its peak. Mostly their soldiers marched from place to place, or used rail.
There is kinda a reason for this, that there are counter examples were new tech wasn't all it was hyped to be. And until something is battle tested, its hard to say how it would perform. Like early in the Vietnam war, US infantrymen may have been better off with the old M1 garand, because early models of the M16 tended to jam in combat conditions.
> anyone who was ever made to look foolish saying[...]
These are common throwaway sayings people with no concept of resources and an overly active aversion to risk often use.
The reality of the situation is that nobody cares to invest in some insanely expensive and vulnerable platform to hijack drones, because 1. it will probably get taken out by a drone 2. it would cost orders of magnitude more than all of the drones and personnel it would take out.
Furthermore, nobody would care to truly protect against such a counter, because the drones cost absolutely nothing.
Saying "it's improbable but let's prepare anyway" isn't how the real world works. Look around you - the world is absolutely filled to the brim with problems, even ones quite probable, even ones inevitable, that nobody can or is willing to spare the resources to deal with. As a general rule, preparing for the improbable is a poor path to success, and worse still is preparing for the improbable, where the improbable event doesn't even impact you in any serious way.
Also, ofc you don't hear about those people. Nobody is reporting on the non-event or the people who prepared for the non-event. Pure selection bias.
You are telling me that the US has made plans for invading or defending against every scenario imaginable[1], but they wouldn't bother considering the 'our drones are being hijacked and used against us' scenario? Just because you are overly confident doesn't make caution an extreme position.
Did you read that article? That drone was electronically taken out of the sky and rendered useless, it was not commandeered and used against the US.
Where did I claim nobody's ever taken out a drone with ewar? Plus this action presumably took an entire squadron with extremely powerful ewar apparatus - a complete waste of time on an 800e drone that will be replaced before the one you've dropped even hits the ground.
This is a fun idea. I always do this currently with some non-core dependencies like black, linters, or dependencies I controll the versioning of. I can't imagine I'd use this on libraries that provide real functionality in prod code though. If you have an incident popping off and you find out your dependency resolution goblin has reared its little head at the same time, bad day ahead.
You can always replicate the precise configuration running on the server. I assume the software passed all tests before being deployed with those same exact versions.
These issues crop up in dependencies more than your code. Then you have to vendor one of the deps and edit it (and hopefully ship that back upstream and hope the maintainer will merge it).
New hire checklist repo that the hire forks and works through.
guru is excellent too imo. docs can be set to expire which serves well if you actually want to update them regularly, or just give a marker for readers to be a bit cautious about the validity of the content.
Another counter example is when the thing you are recording literally _is_ the natural key. Phone numbers are a good example of this. There is no situation in which some data entry error will break a number. That is the creation of a new distinct (possibly) broken number. A phone number doesn't care about any externality in the world. It is what it is.
dabeaz's async talks are imo the most important things you can consume to understand events loops and async, followed closely by njsmith's analysis and criticism of different methods of async invocation and call structures: https://vorpus.org/blog/notes-on-structured-concurrency-or-g...
There's nothing really wrong with this on one level. Your event loop doesn't even have to loop, it can just start by running your main and end when that ends. Imagine starting a server which has a while true loop that waits over a socket, and on some shutdown condition or interrupt ends, ending the program. No busy waiting, no messing with sleeps or sockets from the event loops perspective. Run until complete vs run forever.
Better off, if making some toy loop, to not bother with the forever case.
Could not agree more. Any time I touch a C I want to scoop my brain out of my ear. So many simple unbelievably common operations have fifty "best" ways to do them, when they should have one happy path 99% of usecases require baked in. Nobody should ever have to seriously consider something as ridiculous as "is tolower addressable?".
reply