dexen
Joined 17 years ago
Joined 17 years ago
>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.
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.
All in all a very enjoyable post.
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
Yep, that is piracy indeed, even if done under the figleaf of "privateering".
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 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.
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 :-)
df -h ~
8½
return -ENOCOMPREHEND;