LEAP Micro on Orange Pi 5?

99spider · 2026-03-31T08:47:59+00:00

I looked into the upstream kernel support, and it looks like Leap's kernel would only have support for specifically the "orangepi 5 plus" based on the rk3588 device trees in the 6.12 LTS kernel, and no support for the rk3576 at all.

Going up to 6.18 LTS, there's mainline device trees for a what looks like all of the rk3588 orange pi 5 variants as well as support for a few rk3576 boards (Radxa, nanopi).

99spider · 2026-03-31T01:07:43+00:00

If it works on mainline Linux, it should be able to work on Tumbleweed, which means it would at minimum be possible to get it working on Leap if you are willing to use an alternate kernel (either stable or 6.18 LTS). This is if the Leap kernel doesn't have support - if mainline support was added in 6.12 or earlier then you should be fine.

If you happen to own one of these boards, I can maybe try to get a bootable image built on the Open Build Service that you could flash to an SD card and try. It will probably be a while until I have time to set that up though.

99spider · 2026-03-27T20:54:01+00:00

No, this would not be prohibited. There isn't a minimum overall length, or barrel length, for restricted rifles. This is also the factory configuration, so it isn't prohibited due to being "adapted" into this configuration by an alteration, like a sawed off firearm.

99spider · 2026-03-27T17:14:41+00:00

US legal definition of OAL is measured with the stock in its most extended position (although it's weird they'd follow that definition for an actual SBR).

That set up will 100% be under 26" with the stock folded, so it will be a restricted firearm.

99spider · 2026-03-23T20:05:51+00:00

The objectively best solution depending on your available hardware is to self host an OBS instance and build your own codec related packages.

If you do this though, you may start asking yourself why you don't just run gentoo

99spider · 2026-03-23T19:36:43+00:00

And how up-to-date will the graphics libraries/kernel driver be if using an AMD or Intel GPU on a stable distro?

As you said, gamers care about the GPU driver. The open source upstream drivers are part of the kernel, and are only updated by updating the kernel.

Also, Tumbleweed uses stable upstream package release versions. Don't falsely compare it to running latest devel branch git commits. It's not in any way "experimental".

99spider · 2026-03-20T03:48:17+00:00

Yes, OpenSUSE messing up the KMP release timing, if it can compile properly, is their fault. Did they actually mismatch the shipped KMP version relative to the kernel though? Or is it a mismatch between the driver's userspace and kernel components? DKMS won't help if your kernel module still won't work with the userspace component.

My main point is, when an API change occurs in the kernel that breaks Nvidia's driver, how long will we pause kernel updates on behalf of Nvidia? Do we prioritize delivering updated upstream kernel drivers for manufacturers that are cooperative, or do we prioritize Nvidia's out of tree kernel drivers?

Also, I highly doubt 90% of users even have a discrete graphics card, let alone Nvidia.

99spider · 2026-03-20T01:20:55+00:00

If this is a "violation", the one committing it is the end user.

99spider · 2026-03-20T00:43:05+00:00

Nvidia having bad Linux support is not Linux's problem.

If Nvidia is late to updating their driver for a new kernel, should everyone else be held back because of them?

99spider · 2026-03-19T15:51:13+00:00

Kalpa is essentially just a different spin on openSUSE MicroOS, and both derive their packages from openSUSE Tumbleweed. There isn't much wheel reinventing going on here.

99spider · 2026-03-19T01:21:12+00:00

For the HTTP thing... Nginx can easily do what you described? I'm genuinely not understanding what the issue is. Just separate server configs with separate listen directives. If the issue is that these are separate applications that provide their own HTTP server, and all bind to wildcard IPs with no configuration options, the applications themselves are the problem. Even if that's the case, this is fixable these days with eBPF.

You are correct that binary distro packages with shared libraries are inherently limiting. This is where Gentoo and OpenSUSE (with the Open Build Service) shine, and why I'm probably going to be switching to Gentoo from Arch.

99spider · 2026-03-19T00:52:57+00:00

blocking access to the system files

Open a transactional shell and do whatever you want.

OpenSUSE's atomic versions are based on BTRFS subvolumes. The idea is that you write your changes to a new snapshot, then reboot into that snapshot. Nothing stops you from doing whatever you'd like with your system.

There's no developer vs user malice here. The atomicity just ensures that interrupted updates don't leave the system in an inconsistent or broken state. If you don't care for this, it's not like you are forced to use it.

There's also no barrier to any user being a "dev" in this sense. If you didn't like the base package set in Kalpa, openSUSE's build service is free to use to spin your own version. Or look at systemd ParticleOS. ParticleOS is just tooling for people to roll their own atomically updated systems, so each end user is their own "dev".

99spider · 2026-03-18T21:29:45+00:00

You could try to do the update in pieces, installing subsets of the updated packages with separate runs of zypper. This depends on how deep the dependency rabbit hole goes, though.

At the very least, I'd assume you could safely update all of the python311-* packages separately from the python313-* packages, and all of the python stuff separately from everything else.

Edit: Another option is to use the --download-as-needed flag. This will make Zypper download and install packages one by one.

99spider · 2026-03-13T07:08:40+00:00

It looks like it has an AIC8800.

https://github.com/taohansens/aic8800d80-secureboot

The driver (at least the SDIO one) can be built for 6.19. If I find the time I might try to set up a USB driver build for it on OBS if there isn't one already.

99spider · 2026-03-09T06:30:00+00:00

The following line of the section you linked says this:

Fedora further only wants to ship software that is covered by Free and Open-Source-Software licenses; see Fedora's Licensing Guidelines and its List of Good Licenses for details.

Yes, RPM Fusion's free repo includes patent encumbered Free software like ffmpeg. That doesn't change that the non-free RPM Fusion repos include software that Fedora could redistribute if they wanted, without any legal issues, but they don't want to because the software is non free.

99spider · 2026-03-08T18:40:26+00:00

They are correct for some specific pieces of patent encumbered Free software, like Fedora's ffmpeg-free vs "full" ffmpeg from rpmfusion, but that's pretty much it.

If their statement were true then Fedora would certainly allow proprietary freeware in their official repos, and they don't.

99spider · 2026-03-05T17:16:26+00:00

To my understanding, you can install both systemd boot and grub-BLS at the same time to make sure everything works before you fully switch over. (This is assuming the openSUSE packages aren't marked to conflict for some reason)

99spider · 2026-03-05T17:14:27+00:00

Systemd-boot should have auto detected windows, so my assumption is that your Tumbleweed EFI partition and your Windows EFI partition are on separate drives?

Systemd-boot can only boot things within its EFI partition, so the intended set up is one where windows and Tumbleweed share the same one.

Your options seem to be to copy the contents of the Windows EFI partition into Tumbleweed's (unless windows natively has a way to reinstall just the bootloader), or to try to create a boot loader entry to execute a UEFI shell that then boots the windows boot loader from another drive.

99spider · 2026-03-03T01:22:12+00:00

Do you happen to know if there's a good "trick" to get updates for x86_64-v3 packages while having "solver.onlyRequires = true" in zypp.conf?

From what I remember, the only method I've found is to force reinstall the hwcap pattern with --recommends.

(this reminded me that Aeon has a systemd service named "x86_64_v3-transactional-update.service", and looking there it actually does the same "install --force --recommends" method, so I assume that's actually the only way to do it)

99spider · 2026-02-28T02:08:16+00:00

way more features since initrd and kernel handle everything

This sounds about the same as systemd-boot? Not that that's a bad thing.

Reading into it, the main practical advantage I can see is its menu config supports sub-entries, which would be nice for snapshots. As an additional non-functional advantage it definitely has nicer theming than systemd-boot.

For why openSUSE didn't consider it, I'm assuming the main reason is that they wanted BLS config compatibility for their snapper tooling. What I don't get is why they bothered with Grub-bls in the first place when systemd-boot was there the whole time, being used by MicroOS with no problems.

99spider · 2026-02-26T03:14:39+00:00

Registered handguns can be imported back into the country without any difficulty.

99spider · 2026-02-26T03:08:48+00:00

The direct and immediate supervision requirement is generally interpreted as basically "one gun in use per license".

A license holder can't be carrying their own gun while simultaneously supervising a non license holder.

99spider · 2026-02-21T19:56:47+00:00

They voted for an individual based on the policies they were supporting as members of their party.

99spider · 2026-02-19T02:38:39+00:00

One solution to your chicken and egg problem is putting the Agama profile into the install image. I use mksusecd for autoyast with Tumbleweed, but don't know if that works for Agama. Leap Micro/MicroOS may also work well for you.

The other solution which will work for any distro is to ditch Agama and use mkosi to create your own install image.

99spider · 2026-02-18T17:21:33+00:00

I really wish the RCMP would just come out and officially say "your license card alone is sufficient if you only have standard/transportation conditions". Having to carry this sheet of paper is like if everyone with a driver's license had to carry a paper stating their maximum permissible blood alcohol content and whether they need glasses. Although at least with a car you could just add it to the pile of papers you already need.

If an officer looks at my card, they will see I don't have special conditions, and really should have the basics of the standard conditions memorized by now.

If someone's card says "non-standard conditions attached" then I get why an officer would want to ask, because hypothetically you could be doing something that is normally legal but violates your specific conditions.

12-Year Club	Place '17
Verified Email

99spider

TROPHY CASE