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.
Or just cast the pointer to uint##_t and use be##toh and htobe## from <endian.h>? I think this is making a mountain out of a mole hill. I've spent tons of time doing wire (de)serialization in C for network protocols and endian swaps are far from the most pressing issue I see. The big problem imo is the unsafe practices around buffer handling allowing buffer over runs.
Refresh, as in transitioning from one image to another on the display. Partial refresh as in not running the waveform on pixels that don't change color, which dramatically reduces the visual noise for the user. The problem with partial refreshes is the accumulated errors on pixels, and the effects of updating a pixel on the neighboring pixels. The longer you go between full refreshes, the more ghosted cruft you end up with on screen.
There is a waveform that specifically maintains image quality over many partial refreshes. (Interestingly it only works for black text on white backgrounds, and not the other way around, though I'd hope they would have fixed that by now.) It required quite a bit of pre-processing before you slam the frame buffers into the hardware. That logic came to us as a pre-baked kernel module from our hardware vendor, and EIH did not want us to know what was in it, though it wasn't too hard for us to figure out what it did.
And, to some extent, you can just say screw them, I'm making my own waveforms. However, a junk waveform can damage the display if they aren't correctly built to prevent static charge build up. Also, each batch of displays comes out different enough that EIH provides slightly tuned versions of the waveform on a per batch basis. I'm not sure how well the open source model will work when people don't have equivalent hardware. If someone is tuning the waveforms for their panel, that may not work for all users.
The static build up is interesting. I've seen pictures return to the display minutes after it was cleared to white because the charge built up on the display was still affecting the pigments. Never seen a display break due to it, but it was described to us as a theoretical possibility if a waveform wasn't roughly balanced in its actions.
Do I get my nerd cred now? Have I satisfied you, all knowing hacker news poster?
From what I've seen working on an e-reader, a big problem for any open source e ink product is the things EIH wants to keep secret about their displays. If you want to use the nice partial refresh waveform, the open source aspect of this is going to run face first into secrecy requirements. The company selling you the display controller may be willing to build you an out of tree kernel module, and you can totally figure out what it does, but it won't be open source at that point.
Heh, a popular consumer electronics product a room mate worked on shipped an update that used example.com as a connectivity test. Apparently they were on pace to rack up $20k/month in server costs. At least their user agent made it obvious who to contact.
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.