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.
IP based bans have long been obsolete imo. These days a combination of google captcha tracking and phone number verification is mostly used. A few things like IRC and 4chan still do IP bans which is painfully obvious when you notice you are randomly banned depending on what CG-NAT handed you at the time.
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.
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.
This misses the point. The aim is not to take out Starlink. The aim is to take out the people using Starlink on the assumption that some of them at least are involved in the coordination of the defence of Ukraine. Using Starlink, or any other satellite uplink in an active warzone is essentially painting a target on your back. Doing so may very well be worth it if you are involved in the coordination of the defence of your nation, but its probably not if you're using it to read HN.
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.
I think we're talking at cross purposes. I (and presumably Musk) am talking about the Russian's targeting the starlink receivers / satellite dishes. These are (theoretucally at least) detectable using the same type of radio triangulation techniques used since WWII. Using one of these puts you in danger of attack if you are somewhere near it. And by attack I mean having a missile launched at you, being shelled, or having men with guns turn up on your doorstep. Hacking is not required.
Presumably if starlink users are accessing services over the internet, starlink has to peer with other ISPs somewhere. So the assumption is if you can fill up all the pipes where SpaceX peers to other networks, then Starlink is cut off from the internet.
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.