Not necessarily! I always run ln -s '/usr/bin/$EDITOR' $(which $EDITOR) after a fresh install, so I have a valid executable on the path called $EDITOR.

Of course, then I have to make sure to add export EDITOR=\$EDITOR to my .bashrc. (Obviously.)

I haven’t done too much work with WASM myself, but when I did, the only languages I saw recommended were Rust, C++, or TinyGo. From what I’ve heard, Rust and C++ are smoother than TinyGo. Garbage collected languages usually aren’t great choices for compiling to wasm because wasm doesn’t have any native garbage collection support. That limits your selection down a lot.

But another option you may want to consider is Nim. As I understand, it compiles to C, so any C->Wasm compiler should theoretically work for you as well. I did a quick search and wasn’t able to find any great resources on how to do this, but you might get a bit more lucky. Good luck!

You’re probably right. I think COBOL development is one of the cases where the crazier stories are the ones that bubble to the top. The regular scene is probably more mundane.

I do think there are a few advantages to learning COBOL over C++. COBOL seems to be much stickier - companies that use it seem much more hesitant to replace it than a lot of the companies that use C++, and as a result, they will probably get more desperate. And while there’s definitely a lot more C++ out there than COBOL, I have to imagine that the number of people under 50 that use COBOL is probably tiny, while C++ still has a very large userbase. On the other hand, consulting depends a lot on your portfolio, references, and past accomplishments, and nobody’s going to pay 1k EUR/USD/etc. per hour (exaggerating, obviously) if you don’t have any credentials. It takes time to build that up.

Ultimately, I do think you’re pretty spot on, but we’ll have to see. This is more just a fantasy I tell myself to make it seem like retirement is closer than it probably is…

I fantasize about being one of those extremely well-paid Cobol consultants when I reach the later stages of my career. Hoping that I can earn a full year’s salary in 3-4 months and take the rest of the time off as a semi-retirement. It would be easier said than done, but it’s a dream that helps me get through the days when I get sick of the daily grind.

It was always obvious to me that as long as I was using closed source software that any day could come when the vendor would screw me over. In fact, it could have been running it with bundles and bundles of spyware already and I had no way of knowing it. So I pledged to start using open source software only, to make sure that wouldn’t happen. First, I migrated all my desktop applications to open source alternatives. Then I finally made the switch.

I don’t have any suggestions, but this is incredibly impressive. I haven’t heard of jmp.chat before, but it sounds like you can create multiple identities using different phone numbers - is that correct?

If so, that sounds amazing. I really hate how the modern world is trying to force people into a singular identity online, and the way that they’re using phone numbers to do it. This sounds like it could be a pretty decent method to avoid that.

it always got marginally better at best, and then it got worse again

But why? I think it’s because Russians just don’t exhibit a lot of civic engagement. When you see the kinds of things Putin did to get into power, do you think any of those actions would slide in any other well-functioning liberal democracies? Just look at how Ukraine responded during Euromaidan. You just don’t see that kind of engagement happening in Russian society.

So why does it keep getting worse again? Unfortunately, it’s because they let it.

This is very interesting! Things like this make me wish programmers would give functional^W declarative programming more of a chance. I’ve long fantasized about being able to write programs as declarative code that the computer can optimize automatically without human intervention. When you implement your program in more restrictive (ie. stateless) paradigms, you can more easily reason about the code, and thereby make it easier to optimize or run in different environments.

SQL is a great example of this - when you look at some of the optimizations that servers like PostgreSQL can do under the hood, this is because the language inherently limits what you can do so the actual system executing your instructions can do different things with it for better performance and reliability. Things like this are what make query optimizers possible, and it’s really fascinating if you actually read carefully what query analyzers report (beyond just checking whether your indices are being used or not).

Beautiful chart. Thanks for sharing!

+1, I would recommend neovim with lazyvim. The documentation is excellent, and it’s very easy to set up.

https://www.lazyvim.org/installation

What exactly is it that people obsess over? The desktop environment and terminal customisation? Setting up NetworkManager with nmcli? Using Vim to edit a .conf file?

Welcome to the crowd! Eventually, you realize that an operating system is just an operating system: something you use to get work done, and the less you notice it, the better it’s doing its job. The pride of setting it all up mostly ends very shortly after you’re done. At that point, you realize that pretty much all distros are the same, give or take.

That said, there are always moments that make you realize that your OS is amazing. When you’re faced with a new and difficult task that you don’t know how to achieve, then you look at your distro’s documentation and solve it in a few elegant steps. And I’m not an Arch user, but that’s when the Arch wiki will really be your friend, as well as all the other resources that Arch has for its users. I can’t think of examples of these kinds of moments because they’re so rare, but those are the moments that feel great and really make you appreciate your OS.

One for every current ~0.5% market share!

“Ukraine’s decision fundamentally threatens the security of supply in Hungary,” the country’s Foreign Minister Péter Szijjártó said Monday

Oh my God!!! I can’t possibly imagine them being concerned about anything more serious than that right now!!!

I’m not sure what you mean when suggesting Linux is a singular implementation around which features are exclusively designed. There’s all kinds of software that runs on all kinds of different OSes. Userspace applications, for example, can take advantage of POSIX compatibility to ensure that they run on all platforms (Linux, BSDs, even Windows).

Does systemd have any similar sort of compatibility guarantee? Can I run systemd-whateverd on BSD? Can I run systemd itself on BSD? I’m pretty sure most other init systems support at least one other OS if not more. Would the maintainers even support merging patches that do this? What about musl?

Thanks for letting me know. That sounds promising, so I’ll give it a shot!

Thanks, I’m using yt-dlp too. I was a bit sloppy while writing the post and updated it to make it clear that I’m also using yt-dlp

I am also a Void user, but will agree that the installation process can be very difficult, especially if you want to set up encryption in ways the standard installer does not support. You have to install it into a chroot (which I believe is how Debian was installed 20+ years ago).

That said, it is a great learning process and really helps you appreciate how awesome xbps is as a package manager!

I believe you’re thinking of Gentoo. But it seems that you can get precompiled kernels in Gentoo these days.

+1. systemd is something the Linux ecosystem really needs, but its execution is abysmal. We should be designing around standards so the best product can win. We should not be designing around singular implementations that could make it easy for Red Hat to execute a EEE strategy to consolidate Linux on the workstation.

I can’t wait till a crowdstrike-like flaw is exposed in systemd so we can all see how terrible^W wonderful monocultures can be.

The full write-up can be found here and should be fairly readable for users of this forum.

Some quotes that I thought were interesting:

With a heap corruption as a primitive, two FILE structures malloc()ated in the heap, and 21 fixed bits in the glibc’s addresses, we believe that this signal handler race condition is exploitable on amd64 (probably not in ~6-8 hours, but hopefully in less than a week). Only time will tell.

So 64-bit systems seem to be a bit more resistant to this it seems? But I can’t be completely sure given how much I’ve read about this yet.

This vulnerability is exploitable remotely on glibc-based Linux systems, where syslog() itself calls async-signal-unsafe functions (for example, malloc() and free()): an unauthenticated remote code execution as root, because it affects sshd’s privileged code, which is not sandboxed and runs with full privileges. We have not investigated any other libc or operating system; but OpenBSD is notably not vulnerable, because its SIGALRM handler calls syslog_r(), an async-signal-safer version of syslog() that was invented by OpenBSD in 2001.

It seems that non glibc-based systems also could be vulnerable, but they have not yet tried to demonstrate it yet (or have tried and not been successful).

And OpenBSD wins again it seems.

I would vote for docker as well. The last time I had to inherit a system that ran on virtual machines, it was quite a pain to figure out how the software was installed, what was where in the file system, and where all the configuration was coming from. Replicating that setup took months of preparation.

By contrast, with Docker, all your setup is documented. The commands that were used to install our software into the virtual machines and were long gone are present right there in the Docker file. And building the code? An even bigger win for Docker. In the VM project, the build environment for the C++ portion of our codebase was configured by about a dozen environment variables, none of which were documented. If it were built in Docker, all the necessary environment variables would have been right there in the build environment. Not to mention the build commands themselves would be there too, whereas with VMs, we would often have developers build locally and then copy it into the VM, which was terrible for reproducibility and onboarding new developers.

That said, this all comes down to execution - a well-managed VM system can easily be much better than a poorly managed Docker system. But in general, I feel that Docker tends to be easier to work with than a VM. While Docker is far from flawless, there are a lot more things that can make life harder with VMs, at least from my experience.