The most fun I've had with strace was debugging a 3-process deadlock. An snmp daemon was blocked waiting for a cli child process to finish, the cli was waiting for a response to a message on a socket it had open with a routing protocol daemon, which was waiting for a response from the snmp daemon.
It is also a great way to figure out why programs without useful debug output die. Ie. after a program opens and reads a config file it doesn't like, it starts cleaning up and exits.
The doubling of J as a means of striding across the array also gives me some concern. While it is cache related, it is cache related for sneaky reasons. J is going to end up, in binary, with a ton of 0s at the end after being doubled over and over. After 6 iterations after each reset, the position within the cache line is guaranteed to be 0. Using the standard 32K of L1 D$ would be 512x64 byte lines. Assuming 8-way associative (decently common as far as I know) means these 512 lines are organized into 64 set indexes, each with 8 lines. So after the next 6 post-reset iterations you are guaranteed to only be hitting the 0th index into the cache, effectively reducing the L1 cache size to 8 lines.
(edit: Not the 0th index, but the same index as the base of the array.)
The important part is it safely allows you to pass references or other objects with lifetimes to those threads. (Or at least lets the compiler know so you can avoid having to write unsafe things yourself.)
This happened to be useful for something I was doing at work where the wrapper for a native C library expressed the required lifetimes of the library constructs using lifetimes. (Eg. You must set up Foo before Bar, and Foo must outlive Bar. It was OK to pass Bar and use it from multiple threads, but it had a lifetime attached. Using scoped threads we can satisfy the compiler's lifetime checker, since it knows even though we gave Bar to many threads, none of them outlive Foo.)
The big issue with v6 is you don't know what every ISP is doing with their IP space. The current RIPE recommendation is to delegate somewhere between a /48 to a /56 to every customer. Some ISPs might only delegate a 64, and perhaps typical home wifi setup may only use a single /64. For data aggregation maybe the error is ok, but I've wondered about what IP banning/filtering looks like for v6. Assume everyone gets a /64 and most cats will have 256 lives, and sometimes 16384. Assume everyone has anything larger than a 64, and you may block 255+ other people with the intended target.
Neat. I had made something similar for work a while back, but as a LD_PRELOAD library that intercepted calls to malloc and friends. It would add extra space to every allocation so it could add a pointer at the end that would point into a leaf node of a call graph backtrace tree it maintained. Each node in the tree had lifetime allocated/freed block counts and bytes by code site. The cool part about it was that it barely affected the performance of the application.
It made its own socket and thread to listen on it. It would just dump a snapshot of tree to anything that connected. I also had some tooling that would let you diff two snapshots, since it was helpful to see if particular stimuli cause persistent extra allocations. While finding the largest outstanding delta between allocated and free bytes was great for finding leaks, sorting by lifetime count of blocks allocated was also fun. I remember some little puzzle game I enjoyed playing at the time would allocate and free tens of thousands of blocks as you dragged a line around for a second.
There was a tricky chicken and egg problems with LD_PRELOAD wrapping one of the allocation functions, because it was used internally by dlsym, which I was using to retrieve pointers to the proper function implementations. (calloc if I recall correctly.) I hacked around it by making my library allocate bytes out of a static char array for the calloc call that would happen while dlsym-ing for calloc. Debugging this was a nightmare, since it would break so early in the process's lifetime that GDB breakpoints weren't functioning. Tracking in a second process seems like a way simpler idea, and probably doesn't have too much of an impact on performance.
I don't like the idea of using caps lock frequently as a modifier. To me a frequently used modifier should either be on a thumb or on the opposite hand.
I recently started trying to learn a one handed layout to give my injured right wrist some rest and have been reasonably happy with the space bar doing double duty. (Tap is space and hold is flip.) Though this isn't something that most keyboards can be configured to do.
So far I'd say the flip style is OKish to learn, but I'm still at a tiny fraction of my normal speed. It will take a lot of dedicated practice for me to be anywhere near as fast.
> "all observable behaviors of your system will be depended on by somebody"
Ugh, a former team I was on had that to the extreme. We were customizing open source software for internal use. A lot of operators had (over years) developed scripts that would just SSH in and use a CLI to interact with the software, using regex to parse output. We once thought we were safe adding a new line to the output rather than modifying an existing output line. Nope, someone somewhere used a multi-line regex.
Kicking everyone's automation out of the shells of those boxes was a multi-year project that is, as far as I know, still ongoing.
It depends on the context. Not every bgp speaker needs the full internet table and frequent route changes. If you use the network to balance traffic across servers, you just need a bgp speaker on a server to inject a few routes for the ip addresses it will handle. In that case a good api outweighs performance.
Eh, I think of the menu of options, taking out Starlink in Europe with a DDOS has a high probability of providing value for Russia and is safer to execute compared with the theoretical attack of getting locations out of a starlink ground station. Even if they managed to gain access to the ground stations, they would then need to wade through a proprietary stack and hope that what they have access to actually has useful location data. SpaceX apparently operates on cells that are "5 miles in radius" hexagons, though people on reddit claim to get service up to 15 miles away from home. In any case, I could see a world where the ground station only knew what one of those cells a person was in, and the whole exercise of breaking into a ground station would have been for nothing.
IMO the motivated state wouldn't go through the trouble to attack sites physically when they could just DDOS spacex's public IPs. It isn't like their IP address blocks are a secret, and it wouldn't be that hard to narrow it down to the ones that route to Europe.
I'm curious, what everyone considers far enough in the future for your code. Eg. are you willing to write code that puts nanoseconds in a 64 but number? That is "only" 584 years after epoch. Would you consider that ok?
Anyone with typescript code that references the non-optional field will get type errors if it is made optional. Though stuffing the string with the v6 subnet wouldn't be the worst thing in the world. Any code that is blindly using it expecting v4 addresses will already be broken if a v6 only subnet is passed in.
I wonder how long it will take for CDK to support this stuff. I'm not sure how they will back themselves out of the corner of subnets having a required ipv4 CIDR property.
BGP is spoken between networks. There are a lesser known "IGP" protocols stitching together the insides of those networks. IS-IS and OSPF being the most notable. Though the nature of the beast is that when you screw up BGP everyone sees it, and when you screw up your IGP it could just look like servers or load balancers having a bad day. Though if a telco messes them up everyone notices.
It is also a great way to figure out why programs without useful debug output die. Ie. after a program opens and reads a config file it doesn't like, it starts cleaning up and exits.