Yeah, this is probably going to sound like a truism, but to avoid shitty Scrum, you need to resist management trying to alter the processes, but you should absolutely tweak the processes to account for the needs of the devs.

Basically, yet another reporting meeting does not help deliver the software faster. But more (or less) meetings for devs to sync what they’re working on, that can help, depending on your team’s specific needs.

At its core, SystemD coordinates and launches all the services in your operating system. So, it is essential for the boot process, but also does scheduling, meaning you could run a backup script every night with it, for example.

That’s the simple answer. But in truth, SystemD is often criticized for doing too much, so it’s hard to describe what it really does. For example, you can also manage network interfaces via SystemD.

Kind of the goal of SystemD is to provide common plumbing which works the same across distros, so that when you configure your services or network interfaces etc. on Ubuntu, it works the same as on openSUSE or Arch or whatever.

Gotta love Linux newbies talking about their first experiences and they’ve already tried 3 distros that I have barely on my radar. A few months in, I hardly knew what SystemD was and this guy’s already on a distro that explicitly removes it.

If you prepare an installation USB stick, so-called “Live-USB”, and select in the BIOS that it should boot from that, then you can test-drive Linux before you install it.

There is more details involved, like you may need to turn off Secure Boot in the BIOS, but yeah, point is, you don’t have to commit to Linux to try it.

I’m guessing, you mean this then: https://github.com/edc/bass

But well, I was rather thinking of when it’s using Bash-scripting-syntax to combine multiple commands.
Like, maybe there’s a for-loop in there. You just can’t paste that directly into Fish and have it work. Granted, you should probably put that into a script file, even if you’re using Bash, but yeah, just temporarily launching bash is also an option.

I have that occasionally when I want to copy a complex bash command from somewhere. But yeah, I can then just run bash, run the command in there and then exit back out of there.

It still gives you basically no advantage compared to just making your terminal emulator launch fish by default. And well, it does give you the major disadvantage that scripts without shebang will fail.

To me, it genuinely makes a huge difference that I don’t have to manually press Ctrl+R for history search. Because 9 times out of 10, I accept a history suggestion from Fish where I did not think about whether it would be in my history.

This includes really mundane commands, like cd some/deeply/nested/path/. You would not believe, how often I want to cd into the same directory.
But I’ve also had it where I started typing a complicated docker run command and Fish suggests the exact command I want to write, because apparently I already ran that exact command months ago and simply forgot.

Yeah, my current software project at work was basically half a year of feature development and since then, we’ve purely tried to get it into the real world, which meant evaluating use-cases to see where it falls flat and what needs stabilizing, as well as figuring out people’s needs and how our software can assist with that, then setting up a demo and hoping they find money somewhere…

My problem was that “Albert Heijn” is a dude’s name. It does not exactly scream “we’re talking about a real physical building”.

For all I knew, the impossible problem we’re solving could’ve been on a mathematical plane, named after mathematician Albert Heijn. “Sweeping” just as well can be used in an abstract sense.

Obviously, I did think of physically sweeping a physical floor first and foremost, but especially with the rest of the blog post being so entirely abstract, I had doubts on that for far too long, which did not make it easier to understand.

Probably could’ve mentioned at some point in that whole article that Albert Heijn is a supermarket chain: https://en.wikipedia.org/wiki/Albert_Heijn

In many cases, you don’t need an equivalent to finally, because the cleanup is automatically handled via the Drop trait, which runs cleanup code when the object is freed from memory (similar to “destructors” in some other languages).
Because of Rust’s whole ownership thingamabob, it’s generally entirely deterministic when this code will run (at the closing brace for the scope in which the object is defined, unless you pass that object outside of that scope).

In other cases, you don’t need a finally, because nothing forces you to bubble up errors instantly. You can make a call which fails, store the error in a variable, run your cleanup steps and then return the error at the end of you function.

Sometimes, however, you do want to bubble up errors right away (via ? or early return), typically so you can group them together and handle them all the same.
In that case, you can run the cleanup code in the calling function. If you don’t to want to make it the responsibility of the caller, then pull out a small function within your function, so that you become the caller of that small function and can do the cleanup steps at the end of your function, while you do the bubbling within the smaller function.
There’s also ways to make that less invasive via closures (which also serve as a boundary to which you can bubble errors), but those are somewhat complex in Rust, due to the whole ownership thingamabob.

I will say, I do sometimes feel like Rust could use a better way to handle doing something before the error bubbles up. But generally speaking, I don’t feel like a finally is missing.

You can use the anyhow crate for something quite similar to exceptions: https://crates.io/crates/anyhow

In terms of how it actually fits into Rust, you want to use anyhow for application code. If you’re writing a library, then anyhow is a no-go, because users cannot match on different error classes with it. (Much like you would want custom exception classes, so that users can catch them in different catch branches and handle them differently.)

Every so often, you will also need matchable error classes within your application code, then you would have to replace anyhow with a custom error type there, too, of course.

I will also say, IMHO it is fine to use anyhow even while you’re learning Rust. It is so easy that you kind of skip learning error handling, which you will need to learn at some point, but you can still do that when you actually need it.

I’m guessing, those people are worried that it will be removed. It’s already somewhat on the line since Wayland started replacing X11, because individual desktop environments can now decide to implement it or not.

Ah, I think, I know what you mean, that the format is supposed to be written with foolish oversimplifications that are borderline incorrect, whereas “secured by TLS” just sounds like a normal statement from an expert…

It’s mainly just a nicely polished app with rather many optional features and settings.

But well, at the end of the day, it does still just show a list of 6-digit-numbers, so it’s not revolutionarily different either…

I’m guessing that was supposed to be “secured by a thin layer of TLS”…

Yeah, have not heard about any of these problems before this post…

Back in 2010, the OpenOffice devs had to abandon that name for trademark reasons¹, so they renamed to LibreOffice and continued developing under that name.

OpenOffice theoretically also still exists, but it’s hardly getting updates. Unless you specifically like software from 2010 (including some security vulnerabilities, I believe), you want to use LibreOffice.

¹) The OpenOffice trademark was owned by Sun Microsystems, which got bought by Oracle. Oracle has a very bad reputation, so the devs did not care to wait around for Oracle to fuck everything up.

We deployed a client software in a Docker container on Windows 10. It could not connect to the backend, even though we saw SYN packages originating from it.
So, we ran WireShark on the Windows host and saw that the SYN-ACK packages from the backend were arriving there, too, but no ACK came through to complete the TCP handshake.

Eventually, we rolled out a network debugging container on that Windows host and then could see in the tcpdump, that the SYN-ACK packages, which arrived on the Windows host, just did not show up in the container. Hyper-V or something was quietly dropping them.

Other network connections were working fine, just the SYN-ACK from our backend triggered this.