>It is gradually becoming acceptable to dismiss IPv6 and suggest searching for a modern, practically minded alternative. Important first step in untangling the mess.
>Naturally opinions vary as to what exactly would constitute modern. Common complaint is the significant mixing of OSI layers, in particular application level concerns like significant baggage of encryption & authentication. And then there's my pet peeve of BSD Sockets API incompatibility which was introduced accidentally.
I think that's an incredibly silly take. Any new protocol would first have to be implemented by all the routing dbd switching vendors. It would probably have a 3rd mutually incompatible addressing scheme, because yes IPv4s limited addresses space is still a problem there are countries that depend on v6s expanded address space to have sufficient connectivity (Particularly in APNIC).
Switching out the fundamental addressing protocol of the Internet is hard. You have to herd the cats of the hundreds of thousands of operators, device, operating system, and application vendors, and as long as the old protocol still works, no one has a strong incentive to switch. But they have a big distinctive of missing out on customers, or having to figure out the new protocol.
Any IPvNG is going to run face first into the same incentive problems that v6 has.
At my old uni there were a couple public terminals running DOS, most of the time sitting idle at the prompt. It was bespoke kiosk cabinets only exposing keyboard and screen. One April Fool's I had the bright idea to change PROMPT to something along the lines of "This terminal out of service." - and to increase the confusion, also to change PATH to a non-existent directory, so that most commands wouldn't work and instead flash "Bad command or file name.".
For a couple minutes observed people coming up to a terminal, trying a few things, and stepping away in frustration.
I sure hope administration did restart the terminals overnight to return regular function; normal users were unable to access the power & reset controls.
In which Jerf longs for PHP.
Every single point has been in, and actively used, for a long while.
The __call() & friends is particularly nifty - simple mental model, broad applicability, in practice used sparingly to great effect.
>printing also will likely impact timing and can change concurrent behaviour as well.
I've had a bug like that and the intuitive way to handle it turned out to be entirely sufficient.
The bug (deep in networking stack, linux kernel on embedded device) was timing sensitive enough that printk() introduced unsuitable shifts.
Instead I appended single-character traces into pre-allocated ring buffer memory. The overhead was down to one memory read and two memory writes, plus associated TLB misses if any; not even a function call. Very little infra was needed, and the naive, intuitive implementation sufficed.
An unrelated process would read the ring buffer (exposed as /proc/ file) at opportune time and hand over to the developer.
tl;dr know which steps introduce significant processing, timing delays, or synchronization events and push them out of critical path
>I appended (...) traces into (...) memory. (...) An unrelated process would read (...) at opportune time and hand over to the developer.
I did something similar to debug concurrent treatments in Java, that allows to accumulate log statements in thread-local or instance-local collections and then publish them with possibly just a lazySet():
For sake of example: a "locale-aware" number conversion routine would be the worst possible choice for parsing incoming network traffic. Beyond the performance concerns, there's the significant semantic difference in number formatting across cultures. Different conventions of decimal or thousands coma easily leading to subtle data errors or even security concerns.
Lastly, having a simple and narrowly specified conversion routines allows one to create a small sub-set of C++ standard library fit for constrained environments like embedded systems.
I get that. However then they should name the function and put highly visible disclaimers in the documentation. Something like "from_ascii" instead of "from_chars". Also the documentation, including this blog post should be very clear that this function is only suitable for parsing machine to machine communications and should never be used for human input data. There is clearly a place for this type of function, however this blog post miscommunicates this in a potentially harmful way. When I read the post I presumed that this was a replacement for atoi() even though it had a confusing "non-locale" bullet point.
>Unless it's one of those cursed things installed at the customer thousands of miles away that never happens back in the lab.
I had a bug like that in my previous (telcom embedded dev) career. Ended up driving to the customer premises (luckily mere 200km), working two weeks on collecting traces for the repro, and a day on the patch. Once I figured out how to trace the repro, the rest was trivial - the bug was glaringly obvious in the trace. Which in hindsight means I didn't really need to drive there at all, I merely needed to properly implement tracing the repro, and send the built artifact to the customer.
The problem would have been trivially solved if I had sufficient experience with tracing, or found a colleague with sufficient experience. However this one time the experience was bought & paid for with the trip.
> Which in hindsight means I didn't really need to drive there at all, I merely needed to properly implement tracing the repro, and send the built artifact to the customer.
In the alternate reality where you chose not to drive there, you'd now be complaining how it took 3 weeks to troubleshoot with the customer and how you should have really driven there instead.
To further expand upon this, quickly ascending to high altitude (flying airplane or balloon) after diving is also dangerous, for the very same reason. Pilots are trained to wait out at least 24 hours after a dive, or at least 12 hours if the dive didn't require decompression steps.
>It is gradually becoming acceptable to dismiss IPv6 and suggest searching for a modern, practically minded alternative. Important first step in untangling the mess.
>Naturally opinions vary as to what exactly would constitute modern. Common complaint is the significant mixing of OSI layers, in particular application level concerns like significant baggage of encryption & authentication. And then there's my pet peeve of BSD Sockets API incompatibility which was introduced accidentally.
https://news.ycombinator.com/item?id=37119627
reply