dexen (u/dexen) - Readit News

dexen commented on IPv6 Adoption in 2026 netmeister.org/blog/ipv6-... · Posted by u/zdw

dexen · 21 days ago

Gonna re-post my 2023 comment on IPv6:

>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

dexen commented on The April Fools joke that might have got me fired oldvcr.blogspot.com/2025/... · Posted by u/goldenskye

dexen · a year ago

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.

dexen commented on Some programming language ideas jerf.org/iri/post/2025/pr... · Posted by u/todsacerdoti

dexen · a year ago

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.

All in all a very enjoyable post.

dexen commented on Don’t look down on print debugging blog.startifact.com/posts... · Posted by u/todsacerdoti

molf · a year ago

To be fair though: printing also will likely impact timing and can change concurrent behaviour as well.

Still agree that print debugging is more useful in such situations (and I prefer it in general).

dexen · a year ago

>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

dexen commented on Google Drive Blackout in Italy After Another Major Anti-Piracy Blunder torrentfreak.com/google-d... · Posted by u/gslin

dexen · a year ago

>government getting private property snatched in transit by extending letters of marque to ISPs

Yep, that is piracy indeed, even if done under the figleaf of "privateering".

dexen commented on C++ String Conversion: Exploring std:from_chars in C++17 to C++26 cppstories.com/2018/12/fr... · Posted by u/jandeboevrie

userbinator · a year ago

Wasn’t the old stuff good enough? Why do we need new methods? In short: because from_chars is low-level, and offers the best possible performance.

That sounds like marketing BS, especially when most likely these functions just call into or are implemented nearly identically to the old C functions which are already going to "offers the best possible performance".

I did some benchmarks, and the new routines are blazing fast![...]around 4.5x faster than stoi, 2.2x faster than atoi and almost 50x faster than istringstream

Are you sure that wasn't because the compiler decided to optimise away the function directly? I can believe it being faster than istringstream, since that has a ton of additional overhead.

After all, the source is here if you want to look into the horse's mouth:

https://raw.githubusercontent.com/gcc-mirror/gcc/master/libs...

Not surprisingly, under all those layers of abstraction-hell, there's just a regular accumulation loop.

dexen · a year ago

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.

dexen commented on Thoughts on Debugging catskull.net/thoughts-on-... · Posted by u/todsacerdoti

vardump · a year ago

From the article:

  Here’s my one simple rule for debugging:
  
  Reproduce the issue.

Unless it's one of those cursed things installed at the customer thousands of miles away that never happens back in the lab.

Some things can be incredibly hard to debug and can depend on the craziest of things you'd never even consider possible. Like a thunderstorm causing voltage spikes that very subtly damage the equipment causing subtle failures a few months later. Sometimes that "software bug" turns out to be hardware in weird ways. Or issues like https://web.mit.edu/jemorris/humor/500-miles – every person who's debugging weird issues should read that.

Once you can actually reproduce the issue, you've often done 80-99+% of the work already.

dexen · a year ago

>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.

dexen commented on Exploring pre-1990 versions of wc(1) (2023) sigwait.org/~alex/blog/20... · Posted by u/henry_flower

dexen · a year ago

The brevity carried over to Plan 9. Re-posting my older comment (https://news.ycombinator.com/item?id=4023385):

http://en.wikipedia.org/wiki/Plan_9_from_Bell_Labs follows the Unix philosophy. A lot of legacy has been shed. I can count 13 options to ls, 11 options to sed and just 5 to sed.

The standard Plan 9 shell, Rc, is described in mere ~500 lines of manpage, while Bash takes whooping ~5400 lines.

Oh, and there is no `dll hell' in P9 :-)

dexen commented on How Deep Can Humans Go? mcgill.ca/oss/article/stu... · Posted by u/bookofjoe

itishappy · 2 years ago

> It is a problem caused by Scuba, and the fact that Scuba does what it is supposed to, extend the time you can spend underwater, is what causes the bends.

To expand on this a bit (pun intended), freediving after SCUBA is extremely dangerous, and this even includes shallow stuff like snorkeling. SCUBA adds dissolved gas to your blood, but once it's there decompression from any source puts you at risk for the bends. Repeated dives will have additional safety limits imposed due to the residual gas, which is managed by a complicated series of dive tables or a modern dive computer.

https://www.naui.org/resources/dive-tables-review/

dexen · 2 years ago

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.

dexen commented on Trainwreck Design j3s.sh/thought/trainwreck... · Posted by u/j3s

dexen · 2 years ago

Author states "i feel disrespected in my own ~home.". And funnily enough "~" is exactly what he's looking for:

    df -h ~