fch42

Somehow, this sounds quite appealing.

I'm waiting for the dystopian SciFi novel now where earth's last survivors blast the escape route through that cloud of satellite rubbish for their Starship (TM), by use of an array of those.

One can always dream.

> > [ on ARM ] > Hiring data (both open jobs as well as LinkedIn) show otherwise. Their design presence in UK and US is similar in size, and the India one is not far behind.

If you're saying here that ARM is a company with a large and near-even (by headcount) presence in three countries (and much more distributed overall), then I agree with you fully.

Else, what was your point again ? You said in your first post that a majority of ARM (based on what metric?) comes off Austin, and that is not true by your own later words.

Anyway, I also agree we should be proud of the work done by companies such as (for example) ASML or ARM. Irrespective of where that happens, to be honest.

Final assembly != "entirely manufactured". Cymer brings the EUV lightsource, Zeiss the optics, ASML the mechanics and metrology. Commercial EUV Lithography system(s) aren't "a single parent's baby" even if there is now only a single supplier.

ARM IP ? I gather in Cambridge/UK they'd disagree with you. Even if in classical English stiff upper lip style they may say it less brashly (but not less harshly) than a Texan.

This World is rather intertwined. Maybe more than we like or even more than is good for us. But all of us will loose if we strive to kill cooperation or trade "across borders".

"Ignition" was already mentioned. It has quite a few "anecdotes" about T-Stoff (then German term for 85%+ pure H2O2).

It sure can be smashed up like a piggybank.

While Ammonia generation "involves just nitrogen and hydrogen", the crux is that it requires high temperature. Haber-Bosch doesn't do at ambient - something like 800°C IIRC. And the heating for such is done by burning something (coal decades ago, gas now).

For many "ordinary" chemicals, the so-called process temperature is the challenge with carbon-free. Not dissimilar from steel or aluminium making (melt the ore first before reducing it).

It's uneconomical only where little used. The conundrum for suburbs is not to put bus lines or trams in, but to get people to switch. Once/where widely used, these services pay for themselves. But an empty bus costs more to run than one single-occupant SUV, that's true. And it can never match the "convenience".

If you mean "eat or get eaten", then there's a few early red flags that the pursuit of growth and decarbonisation concurrently may well lead us back to that idea. There's a strong correlation in politics worldwide of extreme xenophobia with climate change denial, and growth-focus with "others pollute more than us".

If you think "carbon budget" then it's compelling to grow yours at the expense of others.

As a child aged five, I broke through the ice and fell into a pond that had frozen over. The Kindergarten teacher was both alert and quick thinking enough to get me out fast. I never remembered more of the event that a) I wore a velvety-black-colored coat made from corduroy and b) that I woke up in the ambulance soggy wet as was the teacher next to me.

The rest of that event - why I walked away from the group, whether I was called back or just lucky, or even what I thought or felt when I went into the water - all gone. Can't remember. Only that afterwards, it felt odd how panicy mum was, and that she immediately insisted on swimming lessons.

So when I was five, this was an experience like "any" - How was I supposed to understand that I had a close brush with death, or what that even meant ?

(I wish your daughter a long and happy life, and may neither her nor anyone have to experience the feelings that you did, or my mum)

Elon Musk burning down an X Datacenter would have a real Roman Emperor Nero vibe to it.

You don't want either alpha or beta in your kidneys, not even for a test. The radiation could cause cancer.

the stack (or stacks, for multithreaded processes) is not a "section" as far as executable file formats are concerned. It is amazingly hard at compile time to "know" that a specific pointer is on any stack.

Also ... the lifetime issue here doesn't preclude the use of stack-based variables. A "local" variable of main() is "as good as" a global/static to pretty much all parts of the program.

Caution: I'm a C programmer "by history" and therefore I see "C Interfaces" as that and don't always / immediately view them through the rust lens of ownership...

Reading the article (nice troubleshooting story!), my summary, as a C programmer, is that the "C Interface" here "takes ownership". Given C cannot express this properly, a pointer is passed - and the called function "simply" makes the assumption that from hence-on, what was given to it will remain.

As "semantics" this (the need to pass an "owned" piece of data to a function) isn't unusual irrespective of the programming language. Just in case of Rust, this is explicit in the interface (if the func takes a non-ref arg, or a shared smart ref of sorts), while in C ... this can lead to errors of the observed kind. I haven't looked whether any of the sources or docs of libmodem say "this pointer must be either global/static or malloc'ed (and the caller shall not free it)".

A rust wrapper for this could / should possibly "leak a reference" here; Something that prevents the initialisation object from being dropped. yea, accepted, needs "nasty hacks" whether static lifetime, Pin, manual drops, explicit Arc leaks, ... possible though.

It'd be nice if libmodem were stricter about such ownership, agreed, and then a rust wrapper could take advantage. Takes time to evolve; is there a bug report / enhancement request out there for this in libmodem ?

It's rather fascinating to find that in the case of M87*, the black hole and its accretion disk are counterrotating. A rotating black hole has a giant amount of angular momentum, and that has "accreted" onto it during its formation and lifetime; even if born from many mergers, and gone through billions of years of accretion, the current angular momentum / spin of M87* says that overall, what came together to form it all rotated largely in the same direction. The fact that M87*'s jet is straight also means the black hole can't have wobbled much in its (more recent) history.

So why did the accretion flip ? How often does this happen ? How big is the influence of accretion (say, at high rates / eddington limit) on the black hole's angular momentum over time ? How long can such a counterrotating condition persist ? How common are cases where, say, the jet direction of a active black hole changed massively (or even reversed), indicating a "major flip" event for the black hole's spin ?

(many questions just curious)

The current working directory is kernel state. getcwd() is a system call. This doesn't compare.

The problem (with get/set/putenv as they are) was isn't the non-use of a mutex. It's the "meaning" of the pointer returned to by getenv(). It returns a char*. Nevermind the persistance of that value - you can work around that by deliberately leaking memory - but it's writeable. Whether it's a good idea to do so ... well. But simply locking "inside" these funcs doesn't solve all the / your issues.

"mutating" there involves the need to (re)allocate memory. To do so in a signal handler is hard ... because memory allocators are, while threadsafe, not async-signal-safe. You can't make a hard problem easy by asserting dependence on another (unsolved) hard problem.

Btw, you can _also_ substitute libc's setenv/getenv/putenv with your own (locking) implementations, courtesy preload and all the funky features of ELF symbol resolution. Actually easy. But impossible if you link against static code using it (go ... away). Hmm. easy ? impossible ? damn this grey world. Gimme some color.

I had to smirk at the sarcasm (intended or no). I merely included "processes modifying their env" amongst all these historical warts. I consider doing so as inevitably necessary as append writes, the advantages of which you aptly described. That's my opinion, underpinned by the history of those interfaces. I hope we can agree that the breakage is by-and-large in an (old, historical) interface that allows braindead usage, not in either the implementor or the user ?

Indeed, and from my point of view, that's perfectly ok.

Obviously not, but _threading_ primitives are not the subject of this post at all. Declared-as Non-threadsafe interfaces are. And of course one (as is happening here) one can argue whether all "system runtimes" shall be threadsafe. Right now though, they are not, and agreed/sanctioned standards don't require them to be. Again (also as happening here) opinions may differ whether changes-to-make-threadsafe would be bugfixes, enhancements, or (require) new interfaces. I have expressed my views on this. Happy to agree to disagree, though.

In short, no - because environment variables are userland state only, you can't interact with them using system calls, the kernel doesn't keep a "canonical" copy of them on behalf of the process. So the "environment" is part of libc, and "libc's way" of interacting with it at runtime "is the way".

From the syscall interface point of view ... you pass the initial env of a process when you exec(), and the kernel copies that to (userland) memory of the new process. The fact "default initialisation" can copy from the environment of the exec()'ing parent, or the fact that the kernel can "read" a process' env (see /proc/<PID>/environ) doesn't change this; the kernel needn't be "accommodating" all the possible and impossible ways how a user application may want to interact with that state there, if you mess-too-much with it, you get garbage. Sooo ... the portability wart is setenv(), because as far as the system is concerned... your "initial" env is passed to you when exec() is called, and any modification thereafter is your concern, your problem, but foremost, your choice. And choices come with taking responsibility for the ones you make.

That is basically "what it means" if an interface is non-MT: you can call this no-problem if you know you're singlethreaded, and if you're not, find your own way to serialize (meaning: have your own locking prinitive you acquire/release where you make calls to these functions).

One could "dream of" a func that tells libc "acquire/drop this mutex of mine around get/set/putenv calls" but that'd simply move the problem - because the nifty "frameworks" would do that (independently of each other, we're sovereign and entitled frameworks around here) and race each other's state nonetheless.

+1 on the "horrible idea" part.

Thing is, the (history of the) UNIX APIs - call'em "libc" if you like - is littered with the undead corpses of horrible ideas. Who thought that having global file write offsets are great ? Append-only writes ? Global working directories ? The ability to write the password db via putpwent() ? Modifying your own envp or argv ? Why have a horribly-scaling hack like fcntl-based file locking even in the standard ?

"Today", were one to start from scratch, the userspace API of even unix-ish operating systems would be done much differently. After all, systems designers and implementors are intelligent people and learn, and there's 50y+ of history to learn from. But the warts are there, and sometimes, there to "program around" them.

That (managing the env "from the outside) is and always has been the "supposed" way of using it.

Modifying _your own_ environment _at runtime_ is not. The corresponding functions - setenv/getenv - and state - envp/environ - have in the UNIX standards "always" (since threads exist, really) been marked non-MT. "way back when" people were happy to accept that stated restrictions on use don't make bugs. Today, general sense of overentitlement makes (some) people say "but since whatever-trickery can remove this restriction... you're wrong and I'm entitled to my bugfix". I agree the damage is done, though.

The "cross platform" way of setting the environment is to set it "from outside" of the program - meaning, through the executor, whether that's the shell or the container runtime or even the kernel commandline if you insist to rewrite init in rust/go/zig/... It can be as-easy-as spawning your process via "env -i VAR1=... ... myprogram ..." - and given this also clears the dangers of env-insertion exploits, it's good practice.

(the argument that the horses have long bolted with respect to "just do the right think ok?!" here holds some water. I'm of the generation though where people on the internet could still tell each other they were wrong, and I assert that here; you're wrong if you believe a non-threadsafe unix interface is a bug. No matter what kind of restrictions around its use that means. You're still wrong if you assume the existence of such restrictions is a bug)

You needn't go "hacky" for this; constructors for global/static variables are called before main(). But then, the underlaying linker support is usually "trivially exposed" (using the constructor attribute in gcc/clang, say).

This (obviously?) isn't "110%" perfect as the order of the constructor calls for several such objects may not be well-defined, and were they to create threads (who am I to suggest being reasonable ...) you end up with chicken-egg situations again.

Visiting Billingsgate will teach you that quite a few restaurant folks (and quite a few "normal people") shop there, in addition to (smaller) fish traders.

Smithfield, at least to me, always had a different vibe; more pro-to-pro/business-to-business, but also they deliver or commission to pre order there; different from Billingsgate.

There's only so and so much you can practice in front of a mirror. Tell yourself a thousand times "I won't panic in a social setting" and you've made zero progress.

Expose yourself to a social setting twice, panic the first time immediately, panic the second time only an hour into the occasion, and you have made progress.

Being affected by social anxiety myself, I wouldn't say there's a "cure". But one can learn to get used to the panic, can learn to "grade" it from unjustified and harmless to "it's better to leave now". Keep doing it, try different settings. It's not really worse than learning to walk. The first steps are wobbly, you cry when you fall, but you get better at it over time.

You got me there. Were this a social setting, that yell would have triggered my interest sufficiently to chase after you for an extended conversation. Resistance is futexile.