execve(2) and friends allow you to specify a new processes's environment variables. How Java may choose to expose that I don't know. Assuming they do, that is all a shell needs. You do not strictly need to call setenv(3) to change a variable that gets evaluated with $, etc. You do need to pass the modified environment to a child process.
1) java shell starts
2) read getenv into a java hashmap
3) evaluate shell input - any sets update the hashmap, any gets read from the hashmap
4) when you get to a point where you need to exec a process you use the hashmap to pass envvars into process builder - which is going to call execvpe for you.
So yeah you definitely could (there'd be other reasons why java wouldn't be a good choice).
TBH reading that folks were calling setenv before an exec to propagate env vars to a child made me sad. I would guess that other use cases were leveraging environ as a poor man's global variable - which is also unfortunate.
Over the years it has gotten simpler to have a certain level of production-value. This has a few effects:
- The reaction of many to something simple[1] becomes "oh it must be fly-by-night"
- It is more likely someone close to the project who can and will enjoy making something slick-looking
- B2B companies have had reasonably slick marketing for at least a decade, and there's always been a desire for many open projects to look like they can "play with the big boys"
EWD comes up as a dissenter for Algol-68, and the longer my career as a software developer the more I disagree with him on anything that isn't pure math.
The appellation is in some part due to his custom of writing monographs for himself titled EWD-n[1]. They are a fascinating mix of deep mathematical and philosophical insight and curmudgeonly reflective essaying.
Yeah, if EWD had had his way, very little software would ever have been written. I think his insistence on proving the correctness of imperative programs is understandable but entirely wrong headed. The sheer amount of insight needed to get through the working day would be unattainable by most and unsustainable for all but a few.
Really just a piece of wire? I would have thought that there would be too much noise to pick up WWVB without a somewhat more selective antenna (loopstick maybe?)
Yes, depends of course on distance, aerial layout and on the decoding technique. Anything over a few hundred miles needs amplification/attention to aerial resonance etc, simply mixing (multiplying) the received signal wth a sine wave close to the same frequency results in a quite audible signal (strength varies throughout the day though).
Used to be easy to pick up Loran signals in the same way (esp. with untuned aerials) but they're all turned off now.
Depending on where it is in the product lifecycle, I've seen this extreme pushback against fixing symptomless bugs.
I was working on a project where someone thought to turn on tools for catching malloc errors (use past the end of allocated buffer, use after free &c.). The team that did this found bugs in their own code, of course, but also many from other teams.
I was there in the room as people went item-by-item litigating whether or not each bug should be fixed. Things like "sure this is use-after-free, but it's used immediately after the free and because of the struct offset, it can't corrupt the heap linked-list, so we won't fix it"
> These days I can't even use pidgin for xmpp, because the omemo plugin is too wonky. Now someone I'm sure will say I'm just holding it wrong and that may be so.. but I doesn't work for me despite trying for a reasonable amount of time to get it working.
The libpurple (library behind Pidgin) support for xmpp is quite mediocre so it's not that you're holding it wrong.
Dino is great on Linux. There's an unofficial windows build that might or might not work. If it doesn't, then Gajim is "fine." Conversations is great on Android. I think Monal is the current best on iPhone, but I don't own an iPhone.
And the need for the existence of the above paragraph is, IMO, a big part of why XMPP isn't used. Nobody knows which clients to use, and the experience if you use an out-of-date client is terrible (seriously, emojis don't work between Psi (which is still listed on xmpp.org as a client, and was a great client 15 years ago) and Dino.
We evaluated some options at work for self-hosted chat about a decade ago. XMPP lost out due to the lack of a good iPhone client. Not sure if things are any better now.
There are now a lot of XMPP extensions to fit the mobile messaging use case better (usage of push notifications instead of a persistent TCP connection etc.), and at least two clients using them: ChatSecure (although the push server seems to be broken currently) and Monal.
Due to the lack of anyone to chat with on XMPP, I can't really speak to the day-to-day usability unfortunately...
The camp fire was caused by a failed hook on lines where similar hooks showed extreme wear-and-tear, despite PG&E claiming to have inspected them recently. It's not like we just decided to say it was PG&E's fault; their inspections were clearly missing important deferred maintenance.
If the fire had been caused by someone without the funds to pay for damages (e.g. a homeless encampment (Day Fire) or college students improperly extinguishing an illegal bonfire (Tea fire)), then there might be criminal charges, but insurance companies will be on the hook.
So some random person lost their job because they didn’t actually do the inspection and now everybody in northern CA pays higher rates. Do you see what you did there? Who do you think won here?
People will not start doing proper inspections until you punish the individual harshly, instead of the company.
reply