fch42

Anger is a great motivator in the mid-term yet self-destructive in the long term.

To begin, it motivates - "show 'em!" way. You gain the energy to prove yourself, to excel-over-others, you may feel the thrill of winning while seeing someone else loose. To aim for this gives you drive and makes you "work harder" - after all, you have some sort of goal.

Long-term though, you only discover that such "wins" (from spite) are rather hollow; the dopamine rush diminishes every time and you either need to "win bigger" or grind down others even harder in order to feel anything about it. Pursue this and eventually you'll just get angry with yourself and your powerlessness to retain this anger-fueled energy that once felt so energising. This is where it becomes self-destructive; you'll wail at the world how unfair it is to you because it's responsible for all this inadequacy, rage, powerlessness that you feel unable to retaliate for. Basically, no "win" of yours could be big enough, no loss of others great enough, for you to feel content again.

It's a lot better for the mind to work towards a goal - feel better - than be angry against something/-one. Keep anger focused. Don't burn out.

only European but if your choice is binary, you can only make it that way.

Some Americans may well vote for the rightwing candidate because they want to stick it to the left (or whoever the "anti" would be).

Personally, I don't think that alone makes a majority in that binary choice; in Europe, it would mostly end up in the vote for a minor "ultra" party. And less-"anti" conservative voters have other options.

In the US though, as someone with conservative values and views, one always has to choose ... do I want to vote with everyone else who votes for "my" camp including the stick-it-tos (because there's only one option "on my side"), do I not vote, or do I even vote against what feels closer to me because the stick-it-tos vote for them as well, and/or their head on the ticket is clearly one of the stick-it-tos ?

Am I glad I needn't make that choice. And am I sad what kind of asocial extremes are encouraged by the binary, winner-takes-all US political system.

QUIC has TLS built into it, and also (http) streams, and a few other such goodies (say, masque - tunneling). It definitely "fills the hole" between L4..L7. Or smashes the layers, if you prefer.

Cloudflare "splits" their reverse proxies functionally into different processes; TLS termination may happen in a different process from WAF, or cache access, or origin fetch. I'm sure other large CDNs do similar things.

As others have said, "processing layers" in contemporary network service architecture don't align that well with OSI layers anymore, though.

(forgot to say, German would know "Ich war Tennis spielen ..." as much as "Ich habe Tennis gespielt ..."; the first one would be considered imperfect passive, and yes I would agree perfect passive, "Ich bin Tennis spielen gewesen ..." would be unusual to say. The english form, "I have been playing tennis ..." is common though. As is "I have played tennis", and yes I'd agree the two aren't interchangeable)

I defer to you for that, simply because I'm a native speaker of German and "only" long-term fluid in English. I don't entirely grasp the difference between the two - other than "phrasing" (and on that level it exists in both), and would be likely to use them interchangeably. In both German and English.

Slightly off-topic, but for the Frankish/French/German evolution, this is usually considered a "marker": https://en.m.wikipedia.org/wiki/Oaths_of_Strasbourg

I'm not sure if any such "foundational" documents exist for English.

With respect to past tense, a "common" thing in english appears to be that the imperfect of a verb is the same word as the past particilpe of that verb. So "played" can be the imperfect tense itself, or the participle of perfect tense in "have played".

In German, this doesn't happen. Imperfect tense is often formed by using a "-te" ending to the verb (so "spiel(en)" -> "spielte"), while the past participle prepends "ge-" and appends "t" or "en" (so "gespielt" - (I have) "played"). The form "... was playing" would also exist, "... war spielen", and again with a difference how the infinitive is formed (-ing vs. -en).

To me, grammar of temporal forms in English is more Romance-language than German language. The fact that English lost any form of case, and most of gender, is neither German nor Romance though.

I sometimes used to joke with English friends that the language is the least common denominator of all the people overrunning the Island in the last 3000 years. Use a bit of everything, leave all the hard stuff out, and write it in a nonphonetic way like Irish.

I follow, yet I disagree that "first priority" must always be a reproducer. There are a lot of conditions that can be rootcaused clearly from diagnostics; say, Linux kernel code deadlocks can exhibit as two different (in their stacks) repeatedly shown "task stuck for more than ... seconds" messages; the remainder follows from the code (to see the abba-lock-ordering violation). There's a certain fetishisation of reproducers not unlike the fetishisation of build-time testing - to denigrate a bug because "you can't reproduce it" or "if it doesn't show in the tests it needn't be changed". Personally, that mindset irks me. Fortunately, most developers are happy to learn more about their code any which way. And debugging, tracing, monitoring is cool in itself.

It's unfortunate that during "professional development" we collectively appear to unlearn saying "no". Or, more widely, learn to avoid using simple direct language. It's not limited to scientists :-(

I have a similar experience from waaaaay back (now near 30 years). We had a water leak in the basement of the institute of physics. Nothing terribly major, ran for a few hours shorted power downstairs eventually (that's how it was found). Once fixed, pumped out, all that remained was a musty smell for a few days.

Except four days later network connection failed in the building. Tracing the cabling eventually lead us to the basement; some under-stairs / slightly below floor level comms cabinet, empty other than the building's outbound router. 48V Telco, no mains connect, had sat under"water" (well some rather murky stuff) for almost a week and done well. Once we got it washed (with clear water) and dried, it continued fine (till replacement a few weeks after). We were a little amazed, to be honest, physicists or no. Brave device, that.

the github commit's "conversations" log for the commit has a few notes you need to log in for to view. But then, the maintainer who merged said "it's just a few constants". Which is fair enough.

I think this would more belong into clippy; it'd be easier extensible then, and less "magic". But I'm just a 0xf001 who's intentions are 0x900d ... please don't let me 0xbe misunderst0x0d.

And now I can't unrememeber and feel totally compelled to a) translate them and b) use them in my code somewhere. Cannot help but think this is a deliberate pun, to get cynic's imagination going ... did they do this to poke fun at the PC brigade asking for it, or were they actually seriously believing it would make users look the other way ? Either option is funny.

(practically, used only "F0015601D" ... as IPv6 link-local address. No, wasn't a honeypot service)

maybe not Cadmium.

Mercury is, though, https://en.m.wikipedia.org/wiki/Merbromin - and on the "paints & coatings" side, orange-red and anti-rust often enough used mercury salts as well. Rarely these days, fortunately.

In some ways, it's nice GaN "won" for blue LEDs. CdTe / CdSe would literally have been "twice bad".

Not only that; but also, by virtue of the "promo pool" being the "losers" in this theory, it subclasses them without saying so (into at least three types - losers that will avoid promotion at almost all cost, losers that seek promotion through "hard work" and loosers that trick their promotion through sociopathic scheming). This is basically what I meant ... at the very very minimum, the "unafflicted losers" that don't care about the game are missing.

(agree - looks like reality is more complex)

I love reading the "things I won't work with" series ... a shame it's no longer being added to.

Just curious: why did Derek Lowe stop writing these ?

A lot of these "organisational models" treat organisational behaviour as a kind of game; you can get ahead by exploiting game masters' mistakes, by cheating, or possibly by knowing and playing the rules really well. And just like poker, there's always a supply of those who believe in luck and just go all-in with no plan.

While I get that "as such", and therefore can follow a classification sociopath/clueless/loser, what is always missing in such models are the people who don't care to play. Those who go to the casino for free food and drinks in order to watch the show, but not to take a stake of their own. Are they "losers" because if you don't bet you can't win ? All of those who play, though, actually want these spectators - after all, winning if there's noone looking, is that a win?

Personally, I think you have this "fourth column" in all organisations. They take their paycheck and deliver something of what's asked for, but else don't care; what they see as "success" is not related to organisational structure or behaviour at all. With all the focus on "success" and "promotion" (or, opposite, "losers"), I wonder how much the theorists are missing. The non-voters can be the majority, you know ...

DTrace and eBPF are "not so different" in the sense that dtrace programs / hooks are also a form of low-level code / instruction set that the kernel (dtrace driver) validates at load. It's an "internal" artifact of dtrace though, https://github.com/illumos/illumos-gate/blob/master/usr/src/... and to my knowledge, nothing like a clang/gcc "dtrace target" exists to translate more-or-less arbitrary higher-level language "to low-level dtrace".

The additional flexibility eBPF gets from this is amazing really. While dtrace is a more-targeted (and for its intended usecases, in some situations still superior to eBPF) but also less-general tool.

(citrus vs. stone fruit ...)

thanks for those refs!

you're right ... "rusty" memory there. You made me check the sources ... it uses libproc but not libdtrace.

(can I be forgiven since I haven't really touched anything Solaris-ish for near 15 years ?)

You have rather high expectations towards the supervisor there ... maybe you were one of the "unlucky" ones who had a genius supervisor ...

There aren't that many people in the world who write bootloader code daily for a living, an even smaller subset of those would ever have done one entirely from scratch (vs. just board-porting U-Boot), and even of those, the likelihood of someone having done a secureboot capable one wouldn't be high. Assuming you have such a person as a thesis advisor is a huge stretch ...

That said though, a thesis is (or should be) a learning exercise. Even a complete fail (to achieve the "initial" objective) can make a great thesis if new knowledge - even negative proofs, "this isn't possible because ..." - come out of it. It's just my opinion maybe, but a graduate should never be taught "fake it till you make it"; rather, describe and document failures thoroughly, explain the observations, highlight and justify the parts that work or are breakthroughs. That can make a much better readable and much more useful thesis than one that skims over one-time lucky else nonreproducible results and delivers uncommented sources that fail to compile for anyone but the original author. In that sense, I would argue that a good thesis advisor will focus on the scientific process, documentary evidence, clarity of experimental setups and tests/checks/benchmarks performed, not whether the outcome would be "great enough" to pitch as a founder to VCs.

You can only grow the stack automatically if you "prereserve" the virtual address space for it. Then it becomes just a question of "committing" the memory at time of need. Default options to mmap() should actually give you this (the OS finds/fills the pages for you on first pagefault), but Solaris/Linux differ on overcommit behaviour.

To "grow" a stack at runtime, if the virtual address space to just add mappings in the "right" place is unavailable (already used for something else, say), it means a stack switch. That isn't entirely impossible. But if done anywhere else but in the "base thread initialisation" (as seen in that example) it becomes complicated and hazardous. It's more like "coroutines" then, your current function "spawns" a func on a new callstack and on return, undoes that and cleans up. One can imagine things like thread-local signal handlers to "simulate" this transparently but that would become more of a piece of programming performance art. If there ever were an "unbelievable unix underbelly programming contest" (UUUPC) stuff like that might well make it.

yes, truss has been based on / implemented in terms of dtrace since Solaris 10.

(dtrace userland is a library; you can, if you so choose, write your own tooling there. The command is "just a wrapper", a lot of similarities to bpftrace on Linux)

Man this brings back so many memories :-)

Definitely a fun read. Debugging crashes has, in the last decade or so, become something a bit like a "lost art". Noone looks at coredumps in the cloud ...

I don't want to outdo you on Solaris debugging (plenty of old-time Solaris folks at Oxide who are totally capable to show how to get things like open files and their contents from a coredump, or how to configure the system to include those should it not be there ... etc ... etc ... Solaris has the best coredumps for all that's worth ...).

A note on the fix side of things though, while adding pthread_get_attr_np() for stack location/size gives Solaris the Linux interface, it already has its own for those - pthread_attr_getstack{size,addt}(), see https://docs.oracle.com/cd/E19455-01/806-5257/6je9h032l/inde... - I happen to remember this because I used this decades ago somewhere in the Solaris name lookup code to choose at runtime between using alloca() and malloc() ... don't ask. Those were different times.

and Cloudflare links to Cloudflare, https://www.cloudflare.com/en-gb/trust-hub/reporting-abuse/

Apocryphally saying "they all suck at this but Cloudflare sucks most" is just moaning. Any free/near-free hosting or caching service can be used to distribute malware. Mail services have been used to push malware for decades, and while many of them filter content, that's a cat&mouse game a determined malactor will occasionally win.

Are they really "so much worse" than anyone else ?

(ex-CF so pillory me for ex-cusing my ex-employer; as said, to me, "all cooks use water")

They should act (on malware et al.) when people report it, https://www.cloudflare.com/en-gb/trust-hub/reporting-abuse/

That said, they're also using the "utility argument" - just as your phone provider won't screen you at every call you make, your electricity provider won't lock your supply until you authenticate use for non-nefarious purposes , your ISP won't content-filter, Cloudflare also says they won't police per-use other than when under explicit legal mandate (court injunctions). That's fair enough, at least to me.

There is value way beyond the immediate service given in a human to human interaction; we're social animals after all and tend to derive a form of pleasure out of "being with others". In the same sense that granny went praying the rosaries Saturday evening before mass, because that also got her the coffee and cake with her friends ahead of that, and the chats afterwards. Just like the person at the till chatting with the cashier, the person talking to the surgery's receptionist (and not just about booking in the doc), or the talk with the pharmacist about how and when best to take the prescription medicine (and since we meet monthly for that anyway ... give me the gossip and the events in town as well) - this used to happen because, quite frankly, "efficient" communication and "efficient" human to human interaction is not what we seek. It'd be rude.

And that's where the whole chatbot, AI or no, thing falls a little. No matter how smarmy or even actually helpful that chat thing is, it doesn't shake my hand, won't do me favours, probably not take me to the shops after work, and ask me whether I need help or why I look sad. Nor complement me on my eyes.

I don't know; at least in me, the herd animal roars loudly enough that I feel unvalued whenever I am forced to interact non-physically. The distance can be felt. And to me, that is not a "protective distance" but an "excluding" one. Makes me more lonely.

You "anything it wants" folks really annoy me a little.

If the compiler can, compile-time, detect that code is prone to memory corruption, it can warn the developer.

If it can't detect it at compile time, will and shall it add some sort of magic signal handler heuristic to determine whether a segfault occurred due to a runtime-provable specific instance of memory corruption and hence format your harddrive, while for runtime-indeterminable kinds it'd rather fry cpu core seven preemptively ? But that behaviour changes in the next version to blink sos on the network cable leds ?

I mean, it were cool if compilers used their "freedom" here to output nagging messages "the mem-safe UB brigade told you so, told you so, told you so ...". The fact they don't tells me, at least, that compiler developers follow Postel's law - be strict at what you emit but lenient at what you process. They're reasonable people. Not some sort of crusader out there to get you in the most excruciatingly painful ways. Undefined behaviour isn't unreasonable behaviour.

"real" (large) C/C++ programs get much of their complexity from the fact that it's hundred of "sources" (both compiled and libraries) that sometimes, or even often, share global state and at best use a form of "opportunistic sharing". Global variables are (deliberately, and justifiedly-so) hard in rust, but (too) trivial in C/C++, cross-references / pointer chains / multi-references likewise. And once you enter threading, it becomes even harder to output "good" rust code - you'd have to prove func() is called from threaded code and should in rust best take Arc<> or some such instead of a pointer.

It'll be great for "pure" functions. For the grimey parts of the world, funcs taking pointer args and returning pointers, for things that access and modify global data without locks, for threaded code with implicit (and undocumented) locking, the tool would add most value. If it can. Even only by saying "this code looks grimey. here's why. A bit of FFI will also be thrown in because it links against 100 libraries. I suggest changes along those lines ... use one of the 2000000 hint flags to pick-your-evil".

With you, except for the conclusion "[ the tool ] will do the bulk of source code conversions, with a really smart human coming behind to validate".

The director orders the use of the tool when the dev team got downsized (and the two most-seniors left for greener pastures just after that). Validation is in the "extensive" tests anyway, we have those, right, so the new intern shall have a look, make it all work (fudge the tests where possible and remove the persistently failing ones as they've probably been always broken). The salesman said it comes from the DOA or DOD or something. If the spooks can do it so can we.