We.Love.Privacy.Club

www.uninformativ.de

Saw this on Mastodon:

https://racingbunny.com/@mookie/114718466149264471

18 rules of Software Engineering

You will regret complexity when on-call

Stop falling in love with your own code

Everything is a trade-off. There’s no “best” 3. Every line of code you write is a liability 4. Document your decisions and designs

Everyone hates code they didn’t write

Don’t use unnecessary dependencies

Coding standards prevent arguments

Write meaningful commit messages

Don’t ever stop learning new things

Code reviews spread knowledge

Always build for maintainability

Ask for help when you’re stuck

Fix root causes, not symptoms

Software is never completed

Estimates are not promises

Ship early, iterate often

Keep. It. Simple.

Solid list, even though 14 is up for debate in my opinion: Software can be completed. You have a use case / problem, you solve that problem, done. Your software is completed now. There might still be bugs and they should be fixed – but this doesn’t “add” to the program. Don’t use “software is never done” as an excuse to keep adding and adding stuff to your code.

⤋ Read More

movq

www.uninformativ.de

Sat, Jun 21 5:44PM (45w ago)

Okay, here’s a thing I like about Rust: Returning things as Option and error handling. (Or the more complex Result, but it’s easier to explain with Option.)

fn mydiv(num: f64, denom: f64) -> Option<f64> {
    // (Let’s ignore precision issues for a second.)
    if denom == 0.0 {
        return None;
    } else {
        return Some(num / denom);
    }
}

fn main() {
    // Explicit, verbose version:
    let num: f64 = 123.0;
    let denom: f64 = 456.0;
    let wrapped_res = mydiv(num, denom);
    if wrapped_res.is_some() {
        println!("Unwrapped result: {}", wrapped_res.unwrap());
    }

    // Shorter version using "if let":
    if let Some(res) = mydiv(123.0, 456.0) {
        println!("Here’s a result: {}", res);
    }

    if let Some(res) = mydiv(123.0, 0.0) {
        println!("Huh, we divided by zero? This never happens. {}", res);
    }
}

You can’t divide by zero, so the function returns an “error” in that case. (Option isn’t really used for errors, IIUC, but the basic idea is the same for Result.)

Option is an enum. It can have the value Some or None. In the case of Some, you can attach additional data to the enum. In this case, we are attaching a floating point value.

The caller then has to decide: Is the value None or Some? Did the function succeed or not? If it is Some, the caller can do .unwrap() on this enum to get the inner value (the floating point value). If you do .unwrap() on a None value, the program will panic and die.

The if let version using destructuring is much shorter and, once you got used to it, actually quite nice.

Now the trick is that you must somehow handle these two cases. You must either call something like .unwrap() or do destructuring or something, otherwise you can’t access the attached value at all. As I understand it, it is impossible to just completely ignore error cases. And the compiler enforces it.

(In case of Result, the compiler would warn you if you ignore the return value entirely. So something like doing write() and then ignoring the return value would be caught as well.)

⤋ Read More

movq

www.uninformativ.de

Sat, Jun 21 2:43PM (45w ago)

We really are bouncing back and forth between flat UIs and beveled UIs. I mean, this is what old X11 programs looked like:

Image

Good luck figuring out which of these UI elements are click-able – unless you examine every pixel on the screen.

⤋ Read More

movq

www.uninformativ.de

Thu, Jun 19 3:05AM (46w ago)

↳ In-reply-to » Fuck me sideways, Rust is so hard. Will we ever be friends?

@prologic@twtxt.net I’m trying to call some libc functions (because the Rust stdlib does not have an equivalent for getpeername(), for example, so I don’t have a choice), so I have to do some FFI stuff and deal with raw pointers and all that, which is very gnarly in Rust – because you’re not supposed to do this. Things like that are trivial in C or even Assembler, but I have not yet understood what Rust does under the hood. How and when does it allocate or free memory … is the pointer that I get even still valid by the time I do the libc call? Stuff like that.

I hope that I eventually learn this over time … but I get slapped in the face at every step. It’s very frustrating and I’m always this 🤏 close to giving up (only to try again a year later).

Oh, yeah, yeah, I guess I could “just” use some 3rd party library for this. socket2 gets mentioned a lot in this context. But I don’t want to. I literally need one getpeername() call during the lifetime of my program, I don’t even do the socket(), bind(), listen(), accept() dance, I already have a fully functional file descriptor. Using a library for that is total overkill and I’d rather do it myself. (And look at the version number: 0.5.10. The library is 6 years old but they’re still saying: “Nah, we’re not 1.0 yet, we reserve the right to make breaking changes with every new release.” So many Rust libs are still unstable …)

… and I could go on and on and on … 🤣

⤋ Read More

movq

www.uninformativ.de

Tue, Jun 17 4:28AM (46w ago)

OpenBSD has the wonderful pledge() and unveil() syscalls:

https://www.youtube.com/watch?v=bXO6nelFt-E

Not only are they super useful (the program itself can drop privileges – like, it can initialize itself, read some files, whatever, and then tell the kernel that it will never do anything like that again; if it does, e.g. by being exploited through a bug, it gets killed by the kernel), but they are also extremely easy to use.

Imagine a server program with a connected socket in file descriptor 0. Before reading any data from the client, the program can do this:

unveil("/var/www/whatever", "r");
unveil(NULL, NULL);
pledge("stdio rpath", NULL);

Done. It’s now limited to reading files from that directory, communicating with the existing socket, stuff like that. But it cannot ever read any other files or exec() into something else.

I can’t wait for the day when we have something like this on Linux. There have been some attempts, but it’s not that easy. And it’s certainly not mainstream, yet.

I need to have a closer look at Linux’s Landlock soon (“soon”), but this is considerably more complicated than pledge()/unveil():

https://landlock.io/

⤋ Read More

jcolag

john.colagioia.net

Mon, Jun 16 9:50PM (46w ago)

On my blog: Developer Diary, Day of the African Child https://john.colagioia.net/blog/2025/06/16/african-child.html #programming #project #devjournal

⤋ Read More

movq

www.uninformativ.de

Sun, Jun 15 3:41PM (46w ago)

So I was using this function in Rust:

https://doc.rust-lang.org/std/path/struct.Path.html#method.display

Note the little 1.0.0 in the top right corner, which means that this function has been “stable since Rust version 1.0.0”. We’re at 1.87 now, so we’re good.

Then I compiled my program on OpenBSD with Rust 1.86, i.e. just one version behind, but well ahead of 1.0.0.

The compiler said that I was using an unstable library feature.

Turns out, that function internally uses this:

https://doc.rust-lang.org/std/ffi/struct.OsStr.html#method.display

And that is only available since Rust 1.87.

How was I supposed to know this? 🤨🫩

⤋ Read More

cncf

feeds.twtxt.net

Tue, Jun 10 11:00AM (47w ago)

CNCF Kubestronaut Program Momentum Highlights Asia’s Role in Growing Cloud Native Talent
Upcoming Kubestronaut celebrations in China and Japan to honor global program growth Hong Kong, China– 10 June, 2025 – The Cloud Native Computing Foundation® (CNCF®), which builds sustainable ecosystems for cloud native software, today announced continued… ⌘ Read more

⤋ Read More

Searching We.Love.Privacy.Club