I'm working on a small project on the history of built-in "app stores". My hypothesis is that this idea actually originates from distros like . That was my personal experience of it. I started using computers in 1981 and have used DOS, Apple ][, C64, OS/2, GEM, Windows, MacOS, NeXTSTEP, MacOSX, Solaris, AIX, IRIX, OpenBSD, FreeBSD, and many distros starting with Slackware. I know the history of Debian, iOS, and Android well. Anyone have any other examples I might have missed?

Just migrated my and key setup to a new . This only took about 8 hours whereas when I last did this in 2015, it took much longer. I guess this is a sign of process! But these things are still too painful. At least now, the software just works right out of .

Anyone procuring hardware with public funding, like for schools, should be aware that the expiration date on that hardware is artificially created by since they maintain their firmware as incompatible with other standards. Given a properly structured firmware, any old device would run or other just fine. The team operates in public and has done a good job of releasing their source, but the bad structure remains.

@elly and @domi outline how has structured their firmware to make it incompatible with the standard methods of booting an OS. So even though it is open source and upstreams their changes, lots of key functionality like audio, USB ports, etc does not work when booting any other OS (e.g. GNU/Linux or even Windows). This serves to lock the hardware to , and thereby generate lots of e-waste when Google drops support for hardware which supports.

Show thread

I'm happy to see more attention given to freeing hardware. They already are built on free software, so with some focused attention on supporting them well with distros like , the number of good GNU/Linux laptops can be greatly expanded. should be as well understood as other BIOS things. Thanks to @elly and @domi for your talk: media.ccc.de/v/37c3-11929-turn

When organizations that use maintain the packages they use in Debian, the whole ecosystem gains. The more organizations that do that, the more efficient the whole ecosystem becomes for all users. Here's a recent example from :

f-droid.org/2023/10/10/f-droid

I'm a Debian Developer, I'm happy to help get organizations working in this way. Reach out if you're interested!

Perhaps the most difficult case ever for packagers: They do all the things that make packaging a nightmare:

* Build the tool with itself
* Circular dependencies: Gradle needs to build which needs Gradle to build...
* Depend on snapshots to build releases, but then they don't keep a way to reproduce the snapshot releases github.com/gradle/gradle/issue
* Java-style bundling of all dependencies
* Hidden proprietary depends github.com/gradle/gradle/issue

thanks ebourg for keeping on!

The vulnerability CVE-2023-4863 demonstrates a huge advantage of the "distro" approach of shipping software, like pushes so hard to deliver. We see a mad scramble for many software vendors to ship with the patched version of . In the distro model, the patch is shipped in the single lib package, then all of the software automatically uses the safe version. This leads to shorter times to get fixes to users with much less work overall.

So I just worked through trying to make bookworm do hibernation with encrypted swap and . Looks like is fine with using a swap file from an encrypted partition, but now the requirement is apparently that the swap is signed to prevent modification. I stuck what I know here wiki.debian.org/Hibernation#UE

It used to be pretty easy to build a local copy of the developer docs. It was quite nice because it was super fast to navigate. I even made a package for the offline version. broke that back in Android 6.0 or so.

Show thread

Project maintains their tools in , giving them a base platform delivered with and the rest of the Debian users get a better maintained Debian.

blog.torproject.org/built-with

I'd like to have something that automatically convert links to the preserving version in the browser. Like play links in , etc. There seems to be things like but for me the question is which one to trust, is maintained, works well enough, etc. Once I find a tool that I think it generally applicable, then I work to get it into so its easy for others to make this decision. Is there a browser extension for this that is worth getting into Debian?

After using /#macOS from 1994-2012, I reached the same conclusion as Ken Thompson: "I've become more and more depressed, and what is doing to something that should allow you to work is just atrocious... And I have come, within the last month or two, to say, even though I've invested, you know, a zillion years in Apple — I'm throwing it away. And I'm going to Linux. To in particular." youtube.com/watch?v=kaandEt_pK

As a , I'd like to say: Welcome!

Just tagged v2.2.1 of fdroidserver tools package, and uploaded it to pypi.org, , and our PPA. This version has passed autopkgtest in Debian/bookworm, so it looks like it should make it into bookworm without further work tracker.debian.org/pkg/fdroids

was almost mentioned at : one key point was that mobile operating systems in 2008 were in a race to get developers. and were tiny newcomers with no developers. The idea from app stores came from free software and hackers. APT started in the 90s, was on iOS when was still saying web apps were the only way. And of course, used as a key strategy to get interested in their platform.

Started syncing work on the package between and , bookworm's libsmali-java provides an update over Kali's own smali package, but there is still a bit more to be done. Hoping this is the start of more cooperation!

Just uploaded to the key inspection tools 2.7.0 and the latest from git, ahead of 2.5.2. All sorts of tools like and more rely on these for inspecting Android APK files.

Just uploaded v3.4.0 to . It is an easy way to get started with analyzing APK files to see what is in them.

and require signature verification, and is built on top of 's APK signing. This improves things a lot but does not mean they are immune. Debian and F-Droid repos can still override packages lower priority repos. It could make sense to have a "no overrides allowed" setting, but that would restrict useful features. Maybe F-Droid could implement "no new signing keys when overriding" rule by default, I wonder how much that would break what people are doing now? 2/2

Show thread

I'm sad to say that my new still needs non-free firmware blobs for working WiFi, Bluetooth, audio, and power management. Now will include those in the installer. Are we losing this fight? At least the graphics driver is and included in upstream Linux, that is progress. I specifically avoided for that purpose.

How are others feeling on the firmware blob fight?

Show more
image/svg+xml Librem Chat image/svg+xml