PeterWhittaker

I shall employ this to recast the why of my work-swearing: I am not swearing at or about the idiot who wrote this code (note: sometimes the idiot is me), I am swearing to increase my productivity/focus as I pickOneOrMoreFromList("refactor", "accept", "work with", "work around") this code.

Thank you! You may have reduced my stress.

Interesting. While I do appreciate that it runs on i386, I have to question its being aimed at students - or at least students of anything other than the history of computing. i386 implies BIOS, AFAIK, and requires pre-x86_64 assembler, which is only partially transferable to modern CPUs.

Oh, for sure, one would learn an awful lot working with those technologies, but as soon as one wished to work on more modern systems, one would have to forgot all of the former and all the ugly of the latter.

This isn't really a criticism, more an expression of puzzlement. Normally, I'm a pretty good contrarian, but I don't get it.

True, there was this Finn who did this some time ago and it worked out pretty well, but I still don't get why anyone would start with i386 and BIOS.

We absolutely do not and never have.

bash associative arrays are fantastic, I've made heavy use of them, but be warned that there have been several memory leaks in the implementation. (Sorry, no version notes, once we realized this, we rewrote a key component in C.)

IIRC, the latest bash addresses all of these, but that doesn't help too much if you are stuck with an older, stable OS, e.g., RHEL 7 or 8; even 9 likely has a few remaining.

These leaks become an issue if you have a long running bash script with frequent adds and updates. The update leak can be mitigated somewhat by calling unset, e.g., unset a[b], before updating, but only partially (again, apologies, no notes, just the memory of the discovery and the need to drop bash).

I'd agree with the idea that bash wasn't the best choice for this purpose in the first place, but there was history and other technical debt involved.

The weather thing is interesting: Ottawa, e.g., gets 3/10. I've lived in the area since 1990 and, other than a week or two in the summer and a similar span in the winter, love the weather here.

Sure, not for everyone, but perhaps the page needs to allow the user to enter their preferred weather.

I'm 59 and doing the most technical and hands-on work of my life.

When I was 40, I was a few years into my consulting gig, and that went very well for a long time (I'm a cybersecurity guy with a strong ICAM and PKI background, located in the Ottawa area, so there was plenty of work with government clients.)

But I was starting to tire of the consulting grind and found I was doing a lot of the same-old-same-old in most contracts (TRAs, PIAs, audits, etc., and, after incidents, explaining to senior management how recommendations made 6-12 months previously might have prevented or at least greatly mitigated said incident).

I was fortunate: 6ish years ago, I was winding down a couple of contracts through a friend's company and he needed someone to fill a gap and knew I had downtime, so I started a contract with him, 90+% WFH. Every few months we'd chat about where he was taking his company and about what the future product teams would need (he'd bid successfully on a pair of unrelated PoC-to-product contracts, one hardware, one software, and was looking to take things to the next level).

Long story short, 5.5 years ago I retired my shingle and returned to full time "wage slavery" (tongue firmly in cheek), almost 100% WFH. My initial role was to work with customers, fill gaps, learn fast, build fast, and move on, and our plan was to move me into a business-development-slash-product-management role, which appealed to me because of two previous contracts that had a lot of that (he'd worked on one of those and knew what I brought to the table).

You know that old saw about life being what happens when you are making other plans? Yeah, that happened :->

My title now is Director, Special Projects, but what that really means is "our customers think this is critical, no one has any idea how to do it, make it happen". It's more a senior/staff engineering position in some ways, mostly systems programming, the levels getting progressively lower (my Christmas holiday reading has been the excellent Mara Bos book on Rust Atomics).

I'm far more technical now than ever before, entirely hands-on, and it's fantastic. It helps tremendously that I work with a great team, people I've known for years, but hadn't worked directly with until now, and that our boss, my friend, understands how complex is what we are doing and how we need regular breaks and downtime; at the same time, the entire team knows how important are revenue and deadlines.

My advice, if I have any, and it all comes with a strong dose of YMMV, is two-fold:

One, it will be OK. You will be OK.

40 isn't the end, nor is 50, and I doubt 60 will be either. I'm pretty sure I'm going to spend the time around my 65th year working on ABE and data filtering in FPGAs, but that's just a guess. :->

Two, work your network.

Talk to your friends and colleagues, ask who's doing what, what the gaps are, where they think they are going, and what they might need. You have skills, others need them, do NOT under any circumstances undervalue or dismiss them.

I won't advise or even suggest consulting, because it isn't for everyone, and the kinds of contracts that, IMHO, at least, best allow you to explore the space and build a better network, are, by their nature, stressful: short term, possibly requiring travel, and sometimes spread out such that when one ends you don't know when the next will begin. But if you are OK with a certain degree of churn, uncertainty, and repetition, then it might be something to consider.

Regardless of how and where you go, remember Advice One: It will be OK, you will be OK, 40 isn't the end.

Up anywhere from 6 (well, poop) to 8 (yes!). Wander into kitchen, turn on coffee maker, take out mouth guard, swap out yesterday's cup for a clean one, make sure cup is right side up, hit the double espresso sequence (paying close attention because the x2 button is too close to the power button for my stunned, spastic, uncaffeinated mind and fingers), pee, take coffee and phone to garage, smoke as little as possible, head to living room, finish coffee while playing word games (dordle, wordle, the mini, zorse, octordle, hurdle), check HN, various news sites, poop, have first breakfast, greet dog of joy, wipe him down, feed him, walk him (20 minutes if I have meetings or other reasons to get home sooner, an hour or more otherwise, unless it is so cold he cuts it short (anything under -15C and the odds of that are even; -30C and might turn around at the end of the driveway)), have second breakfast.

Now the day can begin.

You're deliberately wasting our time.

Hardly. I just thought it was a great write up.

Not Newton's Dome, Norton's: https://en.m.wikipedia.org/wiki/Norton%27s_dome

Not on Norton's Dome: it is the classic example of indeterminism in classical mechanics.

While QM is sufficient for indeterminism, it is not necessary, as this example shows.

Even in classical mechanics, physics is weirder than our intuition allows.

Perhaps because the article is specifically about the buffered f*() calls in stdio, and not the system calls?

Though, as I offer that thought, the divergence between C and the system calls is definitely curious.

Not if the original author stills holds the copyright, which is likely the case: the GPL does NOT remove your copyright, and in fact depends upon it.

Agreed, cf other comments below. My impression is that that is what this person hopes for and that they think that somehow the GPL prevents others from using this code commercially, which it manifestly does not. (Such use would be subject to the GPL, of course.)

Not quite: once you GPL something, while you retain copyright and can licence it in other ways, the GPL itself forbids you from restricting what others can do with it if they take it under the GPL; the one thing they cannot do is change its licence, but you cannot prevent them from selling it, e.g. The FSF are very, very clear on this.

I believe you're right, that was my conclusion as well. I'm not sure that that will accomplish what they hoped.

To continue my original example, I could, in theory, take this code, ensure that it works with arbitrary independent pseudo-services, create my own such services, under a proprietary licence, and distribute the whole as an aggregate, which is permitted by the GPL.

The author likely seeks to provide commercial licensing for those interested in integrating their pseudo-services as libraries, which would require either that they be GPLd or that the original code be licensed in some other way.

I hope the author achieves the success they hope for without the licensing and legal hell they may have set themselves up for. It can be a great disappointment to have one's work turned into someone else's success by a someone or someones with more legal and licence cunning than one's self.

(Note: that ain't me, I've just seen that exact scenario playout more than a fair few times....)

Interesting concept, am curious how this withstands community review and analysis.

Bit puzzled though, by the statement made immediately after stating that it is GPL2: For commercial, legitimate applications, please contact the author for the appropriate licensing arrangements.

Since the GPL2 doesn't permit restricting what others do with GPLd software, I don't think this statement is doing what the author hopes; they might want to consult a lawyer.

(IANAL, etc., but there is nothing in there to prevent me, e.g., from building a business out of this, charging gazillions, and keeping it all for myself, provided I make the source available to my customers.)

I confess I largely stopped paying attention after the "as a kid, it was easy" comment.

As a kid, having playmates was easyish but having friends was tricky. As an ND intellectual multilingual round peg in a town of unilingual anti-everything square holes, I had acquaintances but no good friends until high school, one or two then, none in uni, though there were sufficient like-minded people that it mattered less, and, from then until 10 years ago, at most one or two.

In late 2014 I bought a Jeep and joined a hardcore offroad group (rocks, not mud). They are the most diverse group I've ever hung with, and I have half a dozen people I would consider close friends and rather more who would drop everything and drive 50km in a snow storm if I needed help.

I lucked out. But to say it was ever easy is misaligned with my experience.

You're resurrecting memories from the mists of time, but I seem to remember a common design pattern back in the day for cases like this was to have a persistent lightweight parent that would fork a processing child that could then request the parent perform fork-and-exec operations.

But it's been a while....

But Linux doesn't clone the entire address space: it copies the page table, RO: if the child attempts to write, then it uses COW.

So if fork/clone is followed immediately by exec/execve/etc., there is minimal copying.

The first part - that the Rust borrow checker and overall memory model ensures thread/async safety - is true. I cannot speak to the second part - that other systems don't have this assurance.

1000 years. Essentially 'static

What is the criteria for inclusion in the list? I ask because of interesting omissions, such as Ottawa, capital of Canada, population over 1M; Fredericton, capital of NB (NB's most populous city is included, but not the capital)....

Just curious.

Great summary of the motivation: A large fraction of the flaws in software development are due to programmers not fully understanding all the possible states their code may execute in. In a multithreaded environment, the lack of understanding and the resulting problems are greatly amplified, almost to the point of panic if you are paying attention. Programming in a functional style makes the state presented to your code explicit, which makes it much easier to reason about, and, in a completely pure system, makes thread race conditions impossible.

That is prescient, clear, and worthy of great reflection.

I'm not particularly surprised: they planned 5 missions, all short in time and distance. Since every gram has to be accounted for (how many grams of fuel to a gram of sensor to Mars?), my guess is they equipped it with the bare minimum sensor package for the 5, and hoped maybe to get a few more missions in.

My speculation is that the next one will have a host of sensors, given how much more likely double digit missions of greater length now seems.

Apologies, my reference to python was unclear: I was referring to the python module system and the strength and depth of community contributions, not to the syntax and semantics of the language.

In both cases, the communities do so much good work that often someone else has at least a partial solution to problème-du-jour, so it can be relatively easy to get at least a prototype or PoC, and learn from it, and sometimes one gets a complete solution to at least part of the problem.

Well, it's nice on this side of the line.

There is no party line, and there is no tone. There are over 30 years of experience with C, not all of it pleasant, though most of it productive, and, comparatively speaking, amazing recent experiences with Rust. I do have to shift my thinking from how I would solve problems in C, because the memory management paradigm is so different, but, thanks in part to deep dives into scoping in other languages in pursuit of pernicious bugs, once I make that shift, problems are easier to solve in Rust: The language and the compiler, hand in glove, do a lot of the work for you.

You can carp all you like, and that is all it is, carping, not criticism, we'll just happily work along getting a lot done in less time.

We don't have a lot of place for religion in my industry, and safe, performant low level code is everything. Writing and debugging such code in Rust is just easier and faster than in C.

Two years ago I was casually learning Rust by night while by day I was extending a scheduler I had previously written in C. I kept wishing I could switch, because I kept having to handcraft in C things I would have gotten for nearly free in Rust.

Now, we're designing the Rust replacement for that C program, and it is taking all my will power not to start coding it: that job falls to someone else, and I am wistful about it. Not because I am going to miss the C code, but because it would just be so much fun to do in Rust.

If you say so. Considering that you can define the basics of a memory and thread safety for free JSON parser in a single enum in Rust, and derive a lot of utility functions, where C would take a lot more code, and the code would be riskier, well, I'm just going to keep enjoying working in the language. It has a lovely balance of power and conciseness.

There is a huge learning curve to Rust, one that I am still climbing, but I haven't been as excited learning and working with a new language since 1987 when I learned C afters years of working with Pascal, Fortran, and a number of procedural job control systems.

In the years since, I've written large complex programs and systems in C, JS, bash, and PowrShell, and so far Rust feels like my new forever home, my defauly go to.

I'm glad of this, because my industry is heading to memory-safe, compiled languages, and the others I've experienced don't work for me. It's aesthetic, mostly, I guess, but Rust just makes sense.

Sure, we can do those things in C, but they are easier and faster to do in Rust, and safer, largely because of Rust's enums (algebraic data types, not as simplistic as C's) and traits, and because of crates: a lot can be done in Rust by gluing together a few well maintained crates.

The only language that comes close, AFAICT, is python.

Add the fact that Rust's memory safety brings thread safety for free (once you've grokked Rust's memory management model) and yiu get quickly written type safe memory safe thread safe high perfomance code.