Notices by Sergey Bugaev (bugaevc@floss.social)

@lanodan yes, but actually no. Git does a lot of file access (naturally), both in the working tree and inside .git, and doing it sequentially is going to be dog slow over sshfs. You either need to run a backend (e.g. git CLI) on the remote, so it can run its logic there and only send the useful output (e.g. the list of modified files) over the network, or have some latency-aware Git implementation that would access all the files concurrently.

And yeah good point about the toolchain too.

@lanodan okay yeah, remote dev is a good point. So potentially this would be better if more UIs for Git supported remote repos over SSH or something?

Do you use Git CLI, despite there being a large variety of UI apps for Git? (So do I!)

Why is that? What are they all missing? What would make a Git UI app work for you?

Is it "not exposing important Git concepts"? (which ones?) "Dumbing things down"? (how?)

peel was born out of my frustration trying to write idiomatic :gtk: in gtkmm.

I felt that, while gtkmm was indeed letting me use GTK in a way that felt very C++'y, it was severely limiting what I could do, and was making my widgets feel extremely third-class, compared to the C-written ones in GTK proper — I went into some more details about this in the talk.

And yet C++ so clearly had useful language features like closures and smart pointers and class syntax that could be used to significantly clean up the C GObject code.

So I had these various ideas about how it could be possible to do things better in various aspects compared to gtkmm, to make use of C++ language features while not introducing any limitations or runtime overhead.

Perhaps we could do custom classes like this. Perhaps something like this could be done for signals. Perhaps we could have a RefPtr that actually managed GObject reference count.

But these ideas, they were largely theoretical (I'd spend some time prototyping them in Godbolt at best), and while they were covering various aspects, they were not connected to one another, they were just bits and pieces, and a larger picture was missing.

It took a lot of design work to combine them into one cohesive vision, and to actually implement things, and make them work good enough in practice, to the point where peel could actually supplant gtkmm.

But this now exists and works, and it turned out better than I could dream of.

@domi what I always found weird is that Java doesn't use ELF for its object file format (like Guile does for instance), given both has ties to Sun.

@fale what about accessibility?

What systems developers want:

🤷 algebraic data types
🤷 trait-based generics
🤷 Hindley–Milner type system
❌ npm-style package ecosystem
❌ language-specific build system

✅ shared libraries, dynamic linking
✅ stable, well-defined ABI
✅ precise control over symbols (exports, versioning, visibility, relocations)
✅ seamless FFI with C and C++

(time for another rust shitpost 🙃)

When packaging and using an app, I don't particularly care whether the developer had access to "associated type constructors" or "unboxed closures" or "if-let chains" when they were writing the app.

I do care if the build takes 30 minutes instead of 30 seconds, if the binary sizes are 10x of what's expected and reasonable, if the app vendors and bundles an ungodly number of random libraries with questionable origins & supply chains.

Replaced OpenRC with systemd, now my phone no longer boots

👌

this-is-fine.service

$ pldd 93455
93455: /usr/bin/sshd
linux-vdso.so.1
/lib64/libcrypto.so.3
/lib64/libz.so.1
/lib64/libc.so.6
/lib64/ld-linux-x86-64.so.2

look ma, no libsystemd, no libxz (and yet Type=notify).

@brooke "worse eff ess"

"zero-knowledge proof" is what happens when I manage to prove a statement in Lean by repeatedly applying standard tactics without having any actual understanding of the problem domain

@JCWasmx86 addauth

@lanodan @Conan_Kudo and F42 is not even in beta yet, so it makes sense

friendship ended with Agda, now Lean is my best friend

@mjg59 I'm sure you do understand remote attestation 🙂 (a huge lot better than I do anyway)

But your recent post doesn't mention it, and instead takes apart a weird argument that it's the TPM itself which does the decoding (rather than releasing the secret material that is then used for key negotiation / decoding). Whereas I was indeed expecting you to explain how this is tied in with remote attestation, and how evil (or not?) that is, and why FSF is wrong about that, if they are.

@mjg59 thanks

1. Is it just a matter of time before media streaming starts to require remote attestation via TPM? Or are there fundamental reasons for why the companies don't actually want that? It seems attractive to verify & require that the device runs a stock non-jailbroken version of iOS for example.