My "production stuff":
- https://github.com/festivus-es/festivus - public holidays calendars for Spanish cities
- https://github.com/remote-es/remotes - companies hiring in Spain for remote positions
Usable WIPs:
- https://alexpdp7.github.io/selfhostwatch/ - track self-hosting package updates (such as YunoHost)
- https://github.com/alexpdp7/ubpkg/ - package manager for "upstream binaries"
- https://github.com/alexpdp7/termflux - Miniflux terminal client
GMail sent the second Copilot email to spam.
(Yes, I need to get off both GitHub *AND* GMail.)
Github telling me that I can now use Copilot is a reminder that you, yes you the free software developers with a project on Github, are the one preventing me to delete my account.
Seriously. Get your public projects out of Github.
https://developers.googleblog.com/en/celebrating-flutters-production-era/
So I rarely do anything that would make sense to do on Flutter, but I'm surprised by how little I hear about it. Dart has a few surprises. Also, the article says:
> In the Apple AppStore it has grown ... to nearly 30% of all tracked free apps in 2024!
Most likely, most of those free apps are not good, so we don't know how much Flutter is used for *good* apps.
https://sfba.social/@drahardja/113672539568958321
leads to:
https://papers.ssrn.com/sol3/papers.cfm?abstract_id=4757876
> We study the return to office (RTO) policies ... Consistent with the model's predictions, we find that office rents in the firm's headquarters city determine RTO policy ... Finally, we find no significant stock market reaction to policy announcements.
Hello I wrote a thing about how Android made a good privacy improvement and in the process apparently made key attestation far less useful for certain use cases https://mjg59.dreamwidth.org/70630.html
When it comes to non-free firmware I think there's two reasonable positions - treat it like non-free code running on a remote system (suboptimal, outside the scope of current free software priorities) or treat it like software running on the primary CPU (all code on the local system should be free software, no matter where it's running). I think the FSF's position is unreasonable: https://mjg59.dreamwidth.org/70895.html
Soylent Green is people
https://survey.stackoverflow.co/2024/technology/#1-operating-system
27.7% of professional developers use Ubuntu as their "primary operating system for work". (Plus a few other Linux are there.) I don't really trust the survey (how can primary choices total more than 100%, and how WSL and Cygwin are there?), but if it's remotely close to reality, that "Linux is not viable for work"...
(Better data welcome.)
The way that "ChatGPT outputs libel about person X" was solved by adding a kill switch for his specific name doesn't really suggest these AI engineers have much influence over what their models are saying.
Once you're terminally online for a while you realize how much of online discourse is driven by a handful of terminally online people. After you scratch the surface of some "The X community thinks Y" statement, it turns out Y is just the opinion of two guys named John and Mike that are very prolific on some forum, have had a blog for 25 years, and last looked at X in 2012.
Russell Coker's blog is one of the remaining gems from the golden era where following blogs was *the* way to be updated. I still follow it through Planet Debian, which was another *AWESOME* concept that is becoming lost to the mists of time.
The latest link roundup is quite nice. I wasn't aware Nvidia was also on the RISC-V train. I'm not holding my breath, but I'm kinda eager to see if RISC-V shakes things significantly in a couple of years.
Sooo Ars, after correcting the original deeply flawed, pure clickbait article, has now doubled down with new info about how "Bootkitty" is actually used.
TL;DR: I was right about Bootkitty only being useful at all for UEFI Secure Boot systems. Turns out there's a separate component that exploits LogoFAIL, a year-old UEFI vulnerability discovered by researchers, to enroll Bootkitty's key into UEFI Secure Boot, which then bypasses the need for user consent for the new bootloader.
So, to recap:
There is no new vulnerability here. This is not a zero-day.
Everything in this proof-of-concept attack is just putting things we already knew were possible together.
Bootkitty is still just PoC level and useless on real production systems, since it still works only on a single Ubuntu kernel.
Bootkitty is still not a real bootkit, just a component that's part of enabling the Secure Boot bypass, and trivial to remove and detect.
This whole thing is still not persistent in any way in firmware, and trivial to remove. The LogoFAIL exploit is also stored on disk, not anywhere in firmware.
This is not a remote exploit, or a local user exploit. You need root to install it, there is no extra OS-level exploit chain anywhere to be seen.
The only news here is that someone decided to use LogoFAIL, which again was discovered a year ago, to create the capability of installing a traditional, old school kernel rootkit on UEFI Secure Boot systems without user consent on reboot. Which, again, is obviously possible when you have something like LogoFAIL. And you still need root access to install any of this.
To reiterate, this only matters if your threat model is an attacker might get root on my system, but they won't be able to install a kernel-level rootkit because I use Secure Boot, oh and also I didn't bother to patch LogoFAIL. Note that under this model an attacker can still install user-level rootkits anyway, so it's... certainly an interesting model. Also note that under this model an attacker can also just install any old known-vulnerable-to-something distro kernel (there is no revocation for those) and then exploit it to add the rootkit on every boot, achieving the same result of a module rootkit on a Secure Boot system without any of the LogoFAIL or Bootkitty nonsense. You could even just kexec into a backdoored newer kernel that way.
So, cute and interesting, yes. Still a PoC and a nothingburger for the security world. If you rely on UEFI Secure Boot's guarantees and you haven't patched LogoFAIL one year later, that's on you.
And if you take the Secure Boot stuff seriously you should probably get an Apple Silicon Mac anyway, because UEFI Secure Boot is Swiss cheese with a massive attack surface and stuff like LogoFAIL is bound to keep happening.
Edit: Aaaand it indeed was a student project.
Honestly, we are currently out of ideas on how to restore access to Codeberg.org.
We are fighting with extreme traffic and high load for several hours now, we have done the typical procedure to identify and block misbehaving AI crawlers.
However, we are currently having a hard time figuring out details about the ongoing high traffic situation.
Pet peeve: do not create a repo on GitHub (or your favorite forge) until you have at least a README with a "why". (I normally wait until I have a small usable piece of code, even if it has no UI and needs to be used as a library or through a REPL.)
Or, well, do... I can always fantasize :D
(To me, GitHub is more of a social network :D)
just found out someone is building an independent JS-supporting terminal web browser in a memory-safe language: https://git.sr.ht/~bptato/chawan/
looks promising because so far all the other independent browsers other than Firefox are stuck using C or C++, which like ... have we learned nothing?
but also there's completely unhinged stuff like https://git.sr.ht/~bptato/chawan/tree/master/doc/localcgi.md (and I haven't thought about it enough to figure out whether "unhinged" is a compliment or not yet)
"If it's free you are the product" is up there with "you know Google once said 'don't be evil'" in the list of vapid clichés in 'critical' tech writing. Open software is free. Are users of any given open source system the product? Not really, eh? How about readers of free books and articles? Yeah, just stop repeating that. Being free isn't the problem. The business model of the entity offering the good is the problem.
I made a thing. Please do not hesitate to point me in the direction of more forms to fill. https://wtf-8.xn--stpie-k0a81a.com
Preparing to help to work with Java to someone that uses Pop!_OS and Visual Studio Code. The Pop!_Shop offers by default Visual Studio Code as a Flatpak. The Flatpak does not seem to provide reasonable instructions to install the JDK in a Flatpak situation. I revert and install Visual Studio Code through their official website, which offers a .deb package (which in my experience is easier). The integrated package installer hangs indefinitely installing the package.
Around 2000, my university provided web hosting for students. This was static web hosting, of course. I wanted my website, and setting it up using HTML was too tedious. So I decided to create my website using PHP, run wget --mirror to scrape it, and upload it to the static web hosting service.
(I don't think that was a novel idea even back then.)
My current personal project is implemented with Django and I run with Kubernetes. This project scraps data and stores it in a PostgreSQL database.
OK, I think I have most of the YunoHost catalogue "scraped"; I have the version history of the applications on YunoHost, and the matching Git tag history for the related repos. Daily scraping should get this updated.
Next step is to set up publishing of the data for use by others, and some static website for easy browsing of this information.
Just added jj support to my package manager ( https://github.com/alexpdp7/ubpkg ).
It took me a long time to finally switch from Subversion to Git. But once I did, I never looked back. It will likely take me another very long time to switch to jj, but installing it is a first step :-p
I have some doubts about jj's governance, but I'm crossing my fingers the situation improves.
Perhaps it's time to use this last hour before dinner to fool around with making a Visidata video. I learned it has interesting JSON support recently.