Notices by Leah Rowe is not a Rowebot (libreleah@mas.to), page 3

@ariadne yeah i got confused since it interfaces with systemd. oh well. i edited the post. the rest of it is still valid. netplan sucks.

Fun fact: I hate netplan.

https://netplan.io/

I hate it so much, that I've *deleted* it on the new VPS that I've set up, a Debian VM. I reverted it to the good old fashioned ifupdown.

/etc/network/ ftw

I otherwise mostly love systemd, except when I need to do anything networking-related in it.

I hate netplan just because although it's very powerful and flexible, it's completely over-engineered and often gets in my way for simple network configuration.

My stupid Leah Brain hates change.

@TheyCallMeHacked yeah those can be looked at.

i just set this up today, currently doing something else (setting up a network)

Here are just a few of the issues in FreeBSD, off the top of my head:

* Differences in glibc versus FreeBSD's libc; easy enough to work around, and many packages already have patches in ports for example.

* FreeBSD has GNU Make as "gmake" - I'll have to symlink this in a temporary directory in PATH at build time (many of Libreboot's sub-projects heavily rely on *GNU* Make)

* Probably have to bootstrap some sort of GCC thing, unless FreeBSD's GNU toolchains are any good.

* Other unknown bugs!

Got a new project on, no ETA for completion but it is this: I want to be able to fully compile all of LIbreboot, even an entire release, *on FreeBSD*.

Libreboot's build system, called "lbmk" (Libreboot MaKe) is currently *Linux-only*, due to various idiosyncrasies.

I've set up a dedicated machine for this purpose; a Librebooted Dell OptiPlex 9020 SFF with i7-4790k, 16GB RAM, and a cheap 1TB SSD that I put in it. I'll be porting lbmk over to FreeBSD.

I've got SSH, so I can work on it remotely.

For some reason today I had this song in my head: https://www.youtube.com/watch?v=OYB1rbL8EHo

I wonder why????

@tlaurion@infosec.exchange @mkukri FYI to anyone reading this thread, I boosted a few of the posts to let people know of it.

I've decided to block Thierry for the time being. I don't need this nonsense on my feed every day.

He can engage with me again in the future when he's willing to show a bit more respect. Issues of his are exactly that - his issues. Not mine.

I deal with Libreboot issues. I have respect for Heads - and I won't tell Heads what to do. Heads must not tell Libreboot what to do either!

@tlaurion @mkukri I understand your concerns.

As I said, the patches will be upstreamed when @mkukri gets round to it. He has specifically told me that this is not high priority for him. I've told you this repeatedly.

I'm representing him, because he told me he didn't want to get involved on social media.

Please stop repeating demands - and yes, if other people have problems, that's not Libreboot's problem.

Please stop making a fuss. The answer is *no* - we will do it on our time, not yours.

@tlaurion @mkukri @leah I won't deal with you for the time being. You come to the IRC spamming lists of demands for things we're doing wrong - wrong for you.

When you're ready to approach me with respect, I will happily talk to you.

You actual technical assessment is correct: the T480 patchset *does* actually contain a lot of hacks. It will be fixed.

But you wanted Mate and I to do it all *right now*. We do things on our time, not yours. You have to respect other people's time.

@tlaurion @mkukri And how dare you suggest that we don't care? You wrote: "On planet earth, community effort continues since they care more than upstream, patching patchset."

In the context, you identified Libreboot as the upstream for the T480 patch, since it's not merged in coreboot proper, yet, so Libreboot is the reference work.

Your assertions are are correct - but your attitude stinks. You act like you own us. You do not.

Don't make demands and don't insult us - perhaps send us patches!

@tlaurion @mkukri Now, I *am* going to fix this myself when I merge the coreboot trees together. I currently do T480 in its own separated coreboot tree within Libreboot.

I'm planning a new release in April, with the coreboot revisions updated and merged together.

I will fix up the patch myself, to address the issues you've identified, *for Libreboot, not you* - or, if Mate feels like it by then, use upstream. But I won't pressure Mate to upstream the patch sooner. He'll do it when he wants to.

@tlaurion @mkukri

I don't want to keep being pestered about this, so let me tell you what you did wrong:

You told us what to do, on your terms, and on your schedule, being overly demanding and crass.

You could have asked politely, succinctly - and we will have politely declined. We have other priorities at present.

Alternatively, you could do as we suggest, and patch this in Heads for now. You wanted to avoid the effort, and have us do your job for you?

Show some damn respect, next time.

@tlaurion @mkukri Yes, it appears to be roughly what I and Mate were telling you to do. This is what you will have to do for now, until Mate finishes upstreaming the T480 patch.

We don't need to do anything ourselves at present; we will do our own things on our own time.

I annoyed mkukri on IRC when I asked him to prioritise this, going along from what you demanded - yes, demanded. You made such a fuss over it repeatedly, rather than doing it yourself. Demanding we do things on your schedule.

PSA: LetsEncrypt is shutting down its OCSP server during 2025:

https://letsencrypt.org/2024/12/05/ending-ocsp/

This is due to security issues with OCSP; read the article . The preference now is to use CRLs, for checking revocations.

If you passed OCSP Must Staple and/or your web server needs valid OCSP, you should reconfigure accordingly; make OCSP optional or turn it off, in your httpd, and revoke+renew your certs if you passed --must-staple in certbot.

I already done it on my sites (I was using OSCP Must Staple).

@tlaurion I'm watching the video now, that you've listed. I will say though, I probably won't work on Heads myself - I understand yoru design, but I'm not a fan of it, I prefer lbmk's design. I have my own little planet where everything is perfect for me. Here is what I said on irc earlier:

18:30 <leah> Planet Libreboot
18:31 <leah> Heads developers get diplomatic visas to enter Planet Libreboot
18:31 <leah> but it is Libreboot's planet, not theirs.
18:31 <leah> they can have their own planet

@tlaurion @mkukri non-coreboot projects can also specify xtree! For example, when we build u-boot, we build it using crossgcc. xtree causes this to occur:

export CROSS_COMPILE=src/coreboot/TREE/util/crossgcc/blablabla.

crossgcc is compiled, in that coreboot tree, auto-downloading it.

I'm planning to do a Linux payload and it will also use the "xtree" design. See xtree here:

https://libreboot.org/docs/maintain/

i'll fork stali linux's build system to do initramfs - they bootstrap their own toolchain too

@tlaurion @mkukri By the way, lbmk also re-use crossgcc vesrions when possible. In a target.cfg file for a given board, the "xtree" variable shall specify that the crossgcc from another coreboot tree is used, a symbollic link is created, replacing it; for example, tree2 can specify xtree=tree1, and only tree1 will compile crossgcc.

you and I have the same problems. the difference is my extremely Leah approach.

Heads and Libreboot otherwise use the same design concepts, in their build systems.

@tlaurion @mkukri By the way, regarding build artifacts, Nicholas Chin who contributes to Libreboot, has been working on coreboot's build system to integrate fixdep, which can aid in build speed - and Libreboot forces use of ccache for example, per coreboot tree. I do have work underway by these and also my own efforts, to improve the efficiency of the build process, in the context of re-using build artifacts but not at the expense of code quality. Lbmk is a clean design. Simplicity is priority.

@tlaurion @mkukri "Please fix your patchset upstream."

I'm lenient with you, because I like heads, but it's arrogant to assume you can tell other projects what to do.

This is the other aspect to my "Libreboot First" mentalitiy - I do Libreboot, and I don't bother anyone. Most of the patching Libreboot does is things that are already being mainlined. Some of Libreboot's hacks aren't applicable to upstream, e.g. the patch you mentioned in your T480 PR about Libreboot disabling FSP compression.

@tlaurion @mkukri Anyway, I'm not touching this until Mate does. He told me on IRC earlier that he'll do the upstreaming when he gets round to it - we're not going to rush it just for Heads.

I did ask Mate to prioritise upstreaming though - and that's what he told me.

Yes, your point is well taken, Re build artiffacts. Libreboot's lbmk design is the opposite, as you correctly identify: it builds clean, per board.

This is slower and lbmk uses more disk space, but I priorite clean code in lbmk.