Bring ARM into the fold?

samcday · 2024-03-30 09:33:15

skunark wrote:

I personally would prefer all "archtypes" under one roof with a common build system as I assume this would be the most efficient for the volunteer effort, but maybe it's significantly more complex than I can understand and shouldn't have added to this thread..

You might be interested in this then: https://gitlab.archlinux.org/archlinux/ … equests/32

EDIT: I searched for "RFC" and didn't see any results, but I realize now solskogen linked it earlier and FluxBB contracted the link. Oops!

Last edited by samcday (2024-03-30 10:21:24)

samcday · 2024-03-30 10:26:22

ugjka wrote:

Perhaps it will be considered when more and more ARM laptops/desktops appear on the market that can be actually be used as daily drivers for the work people actually do. Right now i don't see the point for these little critter devices that hang dangling by the USB charger wire with some USB stick with sole purpose of hosting some mystery Samba share on the LAN

It's worth noting that there's a *massive* number of aarch64 devices that could in fact be running Arch Linux today: mobile phones and tablets. The postmarketOS project has been humming along for the last few years and nowadays has made a *lot* of progress in getting mainline kernel running on a lot of devices. Look at this list: https://wiki.postmarketos.org/wiki/Devices

In particular, the msm8916 devices from the 2015 era have great mainline support. I'm working on porting ALARM to these devices: https://github.com/samcday/archlinux-msm8916/.... There is also Kupfer doing the same with a broader scope: https://kupfer.gitlab.io/

I have a Samsung Galaxy A5 sitting next to me right now that is running ALARM with kernel 6.8.2. It's running Phosh with full 3D acceleration (Mesa Freedreno) support. The modem works. It has full wifi + bluetooth support. This is *not* some shrimpy USB stick samba share device or a Raspbi running Pi-hole

Last edited by samcday (2024-03-30 10:26:59)

bschnei · 2024-04-01 01:09:55

graysky wrote:

ArchARM is still updated/maintained.

This is not true for parts of the project. I specifically pointed out the very old kernel for an officially supported device. So either the device is not actually supported and the website is not updated/maintained, or it is but the kernel is not updated/maintained. The state of the Arch Linux ARM Forum also speaks volumes. Sure, application packages and a few kernels are indeed well maintained, but it doesn't help the discussion to imply everything is just fine/nothing to see here when that is demonstrably not the case.

A distribution is clearly much more than application packages. David Runge did a great job in the RFC of explaining the problem:

Anyone creating a new Arch Linux port today is required to make an effort to setup infrastructure similar to archweb, dbscripts, part of devtools, source hosting for PKGBUILDs, etc.

So the "why don't you just fork it?" category of arguments are misguided and not constructive. Sure, the PKGBUILDs are open source and can be forked, but what good does that accomplish for the community without documentation, forum/discussion, build servers, package mirrors, etc? I.e. resources that seem to be under the exclusive control of the project lead (please correct me if I'm wrong).

graysky wrote:

The project founder and lead developer doesn't have as much free time as he would like.

I mean, you are just describing...people But it's not reasonable to expect empathy when you don't communicate. Can you clarify why the lead cannot or will not respond to his situation by engaging with the community he built? In other words, why drive potential solutions to the problem away? There appears to be at least a few capable people willing to help, but it doesn't seem like help is actually wanted. Again, please correct any misunderstandings here because it answers this question:

Trilby wrote:

Okay, then what's stopping you from stepping in and doing so?

I brought the old kernel noted above up-to-date, but what should I do with it now? Submit a PR that, if merged, will mean devices that upgrade won't boot unless they also bring their bootloader up-to-date and reconfigure u-boot? Where should the announcement go that a package will introduce a change that breaks your system so much so that you need to flash new firmware? Or I could submit a PR for yet another device-specific kernel and give users options to migrate? Where would documentation for that go? On the Arch Linux ARM Wiki that hasn't seen a commit in two years? I don't know, but I do know I'm not going to build an entirely new website, wiki, forum, build infrastructure, etc. just so I can share the work I've done to bring one kernel up to date on one device with the community.

So while I agree with your perspective, I don't get the sense that most of the people here are asking for handouts or to dump work on others, etc. Or at least, I'm not. I think the proposed Arch Linux Ports more or less addresses the primary challenge the Arch Linux ARM community is facing: one person in control of the infrastructure who can't/won't communicate while critical parts of the project decay. I think the requirement for EFI boot support in particular is very important as it should largely eliminate device-specific kernel and u-boot configuration packages. But it could also mean that a lot of devices currently supported by Arch Linux ARM wouldn't be supported by Arch Linux Ports. At least, in the case of Marvell Armada 37xx SoC devices, they wouldn't be supported without the work I've done on the bootloader.

solskogen · 2024-04-01 07:19:53

bschnei wrote:

So while I agree with your perspective, I don't get the sense that most of the people here are asking for handouts or to dump work on others, etc. Or at least, I'm not. I think the proposed Arch Linux Ports more or less addresses the primary challenge the Arch Linux ARM community is facing: one person in control of the infrastructure who can't/won't communicate while critical parts of the project decay. I think the requirement for EFI boot support in particular is very important as it should largely eliminate device-specific kernel and u-boot configuration packages. But it could also mean that a lot of devices currently supported by Arch Linux ARM wouldn't be supported by Arch Linux Ports. At least, in the case of Marvell Armada 37xx SoC devices, they wouldn't be supported without the work I've done on the bootloader.

It will also throw the most used ARM board (the Raspberry Pi) under the bus.

bschnei · 2024-04-01 16:33:55

solskogen wrote:

It will also throw the most used ARM board (the Raspberry Pi) under the bus.

Sorry, I mispoke. In the RFC, David used the word UEFI as a "baseline" but left open the potential to support non-UEFI devices provided they are documented. I started a thread there and samcday has jumped in too. If you have something to contribute to the discussion, I'd share it there. I don't get the sense that the intention is to shut non-UEFI devices out entirely, but there are legitimate questions about how to support them that don't have straightforward answers. To Trilby's point, simply "moving/folding in" something that isn't working right elsewhere won't solve all of the challenges and could exacerbate some of them.

I have a Pi Zero W that I ran Arch ARM on for a while. One day I tried to update it only to find out that 32-bit ARM was no longer supported. So it runs Raspberry Pi OS. Disappointing? Sure, but not a death sentence for the device. I'm not very familiar with the Pi family of devices in general, but if you can get a relatively modern version of U-Boot running on it. Then you've got enough of the UEFI standard to make supporting the device at scale very easy for any distribution.

Now, whether or not users should be expected to flash their bootloader in order to be able to use your distribution is debatable. But at least when it comes to ARM as an architecture, the communities seem to be populated with users more comfortable with those kinds of operations (e.g. lots of headless devices). Which, IMHO, also makes it a good candidate architecture in terms of cultural fit for Arch Linux.

solskogen · 2024-04-01 17:19:57

Oh, that's great. I really like the way Arch Linux ARM (and the Raspberry Pi OS) boots On the Pi's, since it doesn't require u-boot. U-boot is just another layer that can (and have) break that makes the device unbootable :-)

samcday · 2024-04-01 21:11:34

bschnei wrote:

So the "why don't you just fork it?" category of arguments are misguided and not constructive.

Thanks for taking the time to write a well-reasoned retort on this topic. I agree with everything you said. It drives me nuts when people say that because I find it quite adversarial and argumentative in a way that helps exactly nobody.

I also agree with your analysis on the situation with ALARM maintainer (is it okay if we just say "Kevin"? Not to call this person out in some weird way, but they *are* the lead maintainer for ALARM...). I feel so conflicted on the whole matter because, on the one hand, I'm extraordinarily grateful to this person's efforts. For all its limitations/warts, I've managed to go a long way with ALARM. It's not "true" Arch upstream in many weird ways (like how about mkosi is version 22 in upstream, but version 14 from May 2023 in ALARM... argh!), but it's the best Arch we currently got in the ARM world, and for me it beats the alternatives in many cases.

But on the other hand, I'm so frustrated by how far ALARM goes, and then just suddenly .. stops. If there was even just a *little* bit more effort to open up a community (how about a Matrix/IRC room?) it could be so much more!

I keep thinking about the fact that Asahi Linux started out on ALARM. I can't help but wonder if they'd still be based on it today rather than Fedora, if ALARM was closer to Arch upstream. After all, Valve made it *to market* on top of Arch...

asoliverez-col · 2024-04-03 12:03:46

Trilby wrote:

asoliverez-col wrote:
Are there any concrete steps that should happen to have ARM accepted into main Archlinux?
There can't be concrete steps to achieving a goal if the goal itself isn't even defined in concrete terms. What do you mean by being "accepted into main Archlinux"? That's a meaningless phrase.
As in my first comment here, this sounds like you want the existing arch linux developers to take over all the work that the archlinuxARM developers are allegedly failing to do well. But how could this happen? Distro devs are volunteers. I'm quite sure they are all aware of ArchARM, and if they wanted to volunteer to help out with ARM they'd be doing so already, right?
So, what, we tell these volunteers that they're now "required" to start doing a bunch of work they have no interest in? Take a moment to think about what that would do.
And if pawning off all the work that is (again allegedly) not being done well by the existing ArchARM team onto the existing Arch Linux team is not what you mean by being "accepted", then please define what it is you'd actually want.

Having ARM (or other architectures) in the same infra helps reduce the duplication of work. Most of the issues will be common to all archs, and then specific issues can be looked at by the specialty arch maintainers. It's not that special, other distros do it well, with x86 usually being the best maintained and other archs having varying levels of support.

Maybe the way to start is open a poll? Would there be interest from current maintainers? Do we need to find 14000 ARM package maintainers before even discussing whether ARM is feasible to do within the same infrastructure as Archlinux?

Some people have expressed interest in contributing here instead of in ALARM, maybe there's enough power to start a mini project? Would it be acceptable to only have the Core repository ported to ARM, and work through extra over time and as interest grows on it?

I think there are many possible ways forward. I'd like to continue the discussion without any assumptions that I'm demanding anything from current maintainers or trying to throw work over the fence without concern for people's time or desires.

marcan · 2024-04-11 21:35:07

samcday wrote:

I keep thinking about the fact that Asahi Linux started out on ALARM. I can't help but wonder if they'd still be based on it today rather than Fedora, if ALARM was closer to Arch upstream. After all, Valve made it *to market* on top of Arch...

There are two separate factors here. First, Fedora is the current flagship *because* Fedora maintainers signed up to work directly with us and upstream our work. The Arch ARM release was a purely downstream project.

The second question is why the Arch ARM port was essentially dropped as unmaintained. The answer is twofold: First, Kevin was somewhat responsive when the project started (before the first release) and we even floated the idea of giving me or other Asahi folks commit access to help with maintainership. However, later when we tried to actually upstream our changes we were met with passive-aggressiveness. Our PRs were ignored due to minor issues, instead of pointing out what those issues were. There was never any follow-up engagement to make Apple Macs a first-class platform for Arch ARM, but quite the opposite.

Second, Arch ARM itself is not maintained to a suitable quality standard. Packages/builds randomly break or have missing dependencies. I've seen QtWebEngine builds that were outright broken (missing files), breaking KDE. Another one was when a Firefox update had build issues with WebRTC, and Arch ARM's response was just to... disable WebRTC. That's just not acceptable for a distro that wants to take itself seriously (users: "why did video conferencing stop working on Asahi?"). Never mind the years-out-of-date toolchain/glibc (this blocks Widevine support), broken qemu that couldn't even be installed (no VMs!), etc. I could go on. Arch ARM may be good enough for hobbyist use on a Raspberry Pi, but it's not up to par for being a desktop/server distro that people actually rely on not to break randomly and with no real timelines for being fixed.

Our quality standard for Asahi Linux today to become one of the default installer options is a distro that has first-class ARM64 support, which upstreams our major packages officially (no pure downstream forks), and where the team responsible can work with upstream to get ARM or Apple-specific bugs fixed within a reasonable timeframe (i.e. it's not acceptable for a major package update that breaks on the platform to remain unfixed for weeks, and yes this does happen on smaller platforms like this one since developers often don't test on them).

I understand that Kevin does not have as much time as he wants to work on the project, and I do not fault him for the slipping quality as a result. However, it is his responsibility to work with the community to find people to help, and he hasn't been doing a good job on that front.

Last edited by marcan (2024-04-11 21:43:57)

samcday · 2024-04-14 16:08:57

Thanks for the highly valuable insight marcan!

Considering the proposition that is being put forth upstream in RFC0032, and noting the fact that the merry band of Asaheroes were literally pitching the idea of participating in the package/distro maintenance activities, I really do think that in an alternate reality where RFC0032 was accepted and already in place back in early 2021, we could all be bragging that "I run Arch btw and so do all my Mac hipster friends"

(by the way, we were discussing the ALARM topic in #archlinux:archlinux.org yesterday and someone linked to your post on the Fediverse from last year)

Anyways, this might be a good time to let folks know that I've been bootstrapping the armch64 project over the last few days. Let's give an ARM64 port another try, and do things a little differently so that it shapes up (hopefully!) to be a healthier, more stable, and more complete port.

Right now it's still bootstrapping and not ready to take for a spin yet (unless you really like bleedingly sharp edges). But hopefully we'll have something ready for wider consumption in the next few days.

The plan is to kinda pick up where ALARM has seemingly left off. The org README I linked touches on the main points, but let me restate them here too.

* Develop entirely in the open.
* Stay as close to upstream as possible: use all their tooling, infra, development practices, and of course PKGBUILDs. Participate in upstream decision-making. Contribute changes back upstream.
* Ensure we can accept any and all contributions: from downstream distros like DanctNIX/the-next-Asahi to single-line drive-by contributions from individuals.
* Actively recruit and encourage potential contributors/maintainers.
* Exist for exactly as long as we need to, until we can onboard to the upstream Arch Ports initiative, when it is ready.

That's why the "armch64" name is so stupid: you should only be annoyed by the silly moniker for a while, until you're transitioned to good old upstream Arch.

If you're interested in getting involved, please do so! Discuss here, ping me on Matrix (@sam:samcday.com), or email me (me@samcday.com). There's a few hundred million ARM64 devices that have been yeeted into the marketplace over the last decade or so, let's get Arch running on more of them.

(and hey, I'm sure marcan will be pleased to know that as part of the initial bootstrapping we're starting with the toolchain! Here's a GCC13 package fresh out of the oven )

Last edited by samcday (2024-04-15 16:01:04)

marcan · 2024-04-15 03:17:51

Thank you for doing this. We still regularly get folks asking about an Arch port

For the Asahi packages (somewhat outdated, but see PRs for some contribution attempts I haven't had a chance to look at) feel free to fork/inherit the PKGBUILDs if you're interested. Ideally everything except perhaps kernel/mesa/uboot packages should be upstreamed (depending on policies/etc). See also the Fedora side for a bunch of stuff that's not there yet. From my POV I'd love it for some folks to effectively take over the Asahi port, and since this would presumably be a new thing without a direct upgrade path from ALARM, that also means there's no need to worry about handing off package signing keys/infra stuff and whatnot. In other words, this turns the Arch effort into something like the Fedora and Ubuntu efforts where the major packages/infra are upstream (or, in this case, "armch64" considered as upstream at least).

Once the whole thing is stable enough and with active maintainership I'd be happy to reinstate the Arch images in the asahilinux.org installer. We now have the ability to fetch images from third party hosts, so you get to figure out the infra yourself; the build scripts I used for Arch ARM are here for reference and in my case it was all built/synced to the mirrors manually, but I'm sure it can be done better and/or integrated into the upstream image builds (since I was basing off of Arch ARM rootfs tarballs anyway) .

Last edited by marcan (2024-04-15 03:19:28)

samcday · 2024-04-15 16:09:57

Actually, as the project progressed further and I started interacting more with upstream, I think I've discovered why ALARM is the way it is - it's much more in line with upstream than folks may fully appreciate Sadly many of the folks I encountered upstream are quite unfriendly, and often times just outright rude

I think that whoever ends up trying to pick up the work of porting Arch to non-x86 architectures is going to need to ensure they have the right mix of skills. It won't just be technical challenges, you'll need to have a thick skin (much thicker than mine evidently is, at least!) and be ready for lots of pointlessly unpleasant + passive-aggressive interactions.

As for me, all I want is a solid ARM64 distro that is ideally consistent with my daily driver. So I guess it's time to kick the tires on Fedora again, I hear it's pretty good for at least some ARM64 machines

Last edited by samcday (2024-04-15 16:12:42)

marcan · 2024-04-15 21:00:29

Well, that's unfortunate... I've had better interactions with upstream Arch folks than with ALARM, but I guess that's not everyone

Fedora *is* pretty nice though, definitely recommended for ARM64 if you're not particular about other aspects of the distro choice. I was a Gentoo+Arch person before the Fedora folks signing up to the Asahi project made me jump ship, but now that I'm here I'm really liking the infra, community, tooling, and general vibe of the distro. It's a lot closer to rolling-release than I expected (the stable versions, not even rawhide) and the release cadence is fast enough that I don't mind waiting a few months for those major package updates that do get held back to the next release. Fedora also seems to have a lot more overlap between its package maintainers and upstream (no doubt in part because becoming a package maintainer is pretty easy) which helps with things. I suspect all my future x86 installs will also be Fedora unless I have a really good reason to pick something else, going forward.

Last edited by marcan (2024-04-15 21:01:59)

samcday · 2024-04-16 05:51:32

That's good to hear. I've played with Silverblue a handful of times, and my homelab nodes have been happily running CoreOS for a while now.

Yesterday I made a concerted effort to do the switch, so now my daily driver is on Silverblue properly. I still find rpm-ostree to be one of those "it sounds better on paper" things, but I've been following it for a few years now and I've definitely observed it steadily improving so, I'm optimistic.

I actually started working on some Fedora packaging a month ago, before I decided to jump into trying to package aarch64 on Arch. COPR is very nice indeed.

Alas the first thing I started with for packaging in Fedora was the device-specific kernel I needed for the devices I'm working on porting. And uh ... gosh. Compare the couple of hundred lines of kernel PKGBUILD to ARK .... yikes! But to be fair I *did* manage to get something cooking on COPR (I used the Asahi git history and changes to ARK as reference!)

I also noticed that, since I don't have a powerful AArch64 machine right now and was doing mkosi builds and such from qemu-user-static, DNF + RPM scriptlets are *significantly* slower under qemu than Pacman + PKGBUILD install scripts are.

So of course there's always tradeoffs on these things. Though it's good hear you specifically note that you're liking the "general vibe". That's quite important to me personally, once all the boring technical stuff has been weighed and considered!

I'll see you around in the Fedora communities sometime, perhaps Probably also going to pick up a used M1 for aarch64 development porpoises so - thanks in advance for all the amazing work you and the homies have done so far in Asahi.

Last edited by samcday (2024-04-16 10:04:41)

uavvyse · 2024-05-05 14:04:10

Exploration tracks:

https://gitlab.com/kupfer

https://github.com/dreemurrs-embedded/Pine64-Arch
https://forum.pine64.org/forumdisplay.php?fid=159
https://t.me/archmobile

https://github.com/manjaro-pinephone

- https://bbs.archlinux.org/viewtopic.php … 8#p2168158

Last edited by uavvyse (2024-05-05 14:17:07)

pohl5434 · 2024-07-01 19:07:33

After reading this thread, I feel pain in my heart about the direction Arch Linux and Arch Linux ARM are heading.

With the release of the Snapdragon X Elite, Windows laptops are transitioning fast into the ARM architecture, like Apple already did a couple of years ago with the M-series of processors. Data centers and cloud service providers have long switched to ARM due the better power efficiency and cost savings. Mobile phone have for the majority of devices always been on ARM for the very same reason. And light gaming is nowadays also possible on ARM devices, although I would say that gamer are probably the last user group left who will still use x86 CPUs in the near future as power consumption is not so much of an issue in this use case.

With that said, I strongly feel that Arch Linux and Arch Linux ARM as one community should focus more on the development of ARM than continuing of putting most of the resources into X86. And the division into two separate projects, as it stands today, is hampering widespread adoption of both Arch Linux and Arch Linux ARM. I'd love to buy a new Microsoft Surface Laptop 7 with a Snapdragon Elite - of course not to run Windows ARM but Arch as my daily driver. But can I with the trust that it will support Arch once the necessary kernel patches have been released by Qualcomm? I've switched to Arch about 6 years ago and use both a X86 laptop and a couple of ARM SBCs as my main devices at home. I love the simplicity and the philosophy behind Arch - it lets me run software the way the author intended it to be without much change. A stark contrast to Ubuntu, Debian and RHEL and the like.

I would be very sad if Arch's popularity is going to decline further because of the lack of direction and consensus within the core team of developers. I'd love to contribute, but I have no experience and knowledge how to setup an entire toolchain for the release of a linux distribution or H/W resources to do so. I've published a couple of (not so popular) packages to the AUR of software I have written myself - but that is barely scratching the surface of what is needed now to make Arch one distribution capable of supporting multi architectures. That at least would be my very personal wish for Arch.

Last edited by pohl5434 (2024-07-01 19:09:28)

ewaller · 2024-07-01 19:25:46

Somehow, the whole notion of bringing Archlinux ARM "into the fold" sounds somewhat imperialistic to me.

Trilby · 2024-07-01 19:38:07

We will add archARMs biological and technological distinctiveness to our own. Their culture will adapt to service us. Resistance is futile.

Allan · 2024-07-01 23:02:31

We have had an RFC approved that outlines the process for getting a new architecture to be official, but there has been no-one step up and start the process for any new architecture. It is as if no-one is really that interested in doing the work needed.

ugjka · 2024-07-03 02:40:55

Allan wrote:

We have had an RFC approved that outlines the process for getting a new architecture to be official, but there has been no-one step up and start the process for any new architecture. It is as if no-one is really that interested in doing the work needed.

Perhaps when the new SnapdraggonX laptops start popping up in dev's laps someone will step up!

pohl5434 · 2024-07-03 17:57:19

Trilby wrote:

We will add archARMs biological and technological distinctiveness to our own. Their culture will adapt to service us. Resistance is futile.

Or the opposite way round. I don't think that x86-64 will have any significance in 5-10 years. Then Arch Linux will be the small brother of Arch Linux ARM if it still exists by then.

bschnei · 2024-07-04 18:40:59

Allan wrote:

We have had an RFC approved that outlines the process for getting a new architecture to be official, but there has been no-one step up and start the process for any new architecture. It is as if no-one is really that interested in doing the work needed.

The RFC says another RFC is needed before work can start. So perhaps you are right and nobody is interested in drafting an RFC. Another guess is nobody knows what would be required in such an RFC.

This very thread has been acting as an unofficial RFC for ARM and just look at how that is going. It has been shown repeatedly in this thread that there are people actively trying to keep Arch Linux running on their ARM devices despite all of the headwinds they are facing with the Arch Linux ARM project. And yet it seems the default assumption is that everyone is lazy/uninterested or looking for handouts. If that is an indication of what the experience here will be like, why would anyone even attempt an RFC or ask for help putting one together?

One of the stated motivations in the Ports RFC is "to develop and foster expertise". How can we expect to accomplish that if we write-off entire communities as freeloaders? The stated motivation suggests to me that when we do find people who show any initiative/interest, that we would ask/encourage them to take on greater responsibility and provide them with some guidance; not imply they are lazy/uninterested because they haven't written some RFC.

I also want to call out (again) the particular challenges we have with ARM due to the existence of the Arch Linux ARM project. I could be mistaken, but it doesn't seem sensible for anyone to be spending any time at all on an RFC for ARM until someone decides what can and should be done with the work and community that already exists for this architecture. If we are going to start over from scratch with ARM here, then why would that project continue to be allowed to use the Arch Linux name? As noted already several times here, that project seems to be under the exclusive control of someone unwilling/unable to communicate with their community.

I suspect the sensible and polite thing to do would be for whomever allowed kmihelich to use the Arch Linux name to reach out and see if he is willing and able to be a part of the RFC process. If what graysky claims is true, kmihelich should be ecstatic that he won't have to maintain a lot of separate infrastructure anymore. I would think kmihelich and graysky would want to be the main contributors to the RFC process here. But if they can't/won't, then it is very clear the Arch Linux ARM project doesn't actually want to be associated with Arch Linux and nobody should have any issues with that project ceasing to use the Arch Linux name. Once that is resolved, the scope of the work required will be much clearer.

I suppose you can consider that proposal the first draft of the RFC for ARM. Happy to move to a mailing list or submit an MR for it on RFCs if that is what makes sense.

unsignedzero · 2024-08-01 05:31:06

ugjka wrote:

Allan wrote:
We have had an RFC approved that outlines the process for getting a new architecture to be official, but there has been no-one step up and start the process for any new architecture. It is as if no-one is really that interested in doing the work needed.
Perhaps when the new SnapdraggonX laptops start popping up in dev's laps someone will step up!

Are there currently any NUC like ARM-based systems like the Minisforum one, example 790 Pro that are small, mostly complete (missing just storage and memory) box experience for a few hundred? I feel that this could be easier for peoples' wallets to stomach when they want more power than a Pi but don't need it as their daily driver as with a proper laptop or tower. It may also be a better dev box in between everything?

I would love to see more support for ARM with Arch Linux with new developments on the horizon. Was the original Arch Linux ARM project created by a completely separate team blessed by the x86 crew?

BluePyTheDeer_ · 2024-08-04 20:10:10

I know this will go nowhere but I would love to see Arch running on a Raspberry Pi

solskogen · 2024-08-05 10:27:27

You can run Arch Linux ARM on a Raspberry Pi

Arch Linux

#26 2024-03-30 09:33:15

Re: Bring ARM into the fold?

#27 2024-03-30 10:26:22

Re: Bring ARM into the fold?

#28 2024-04-01 01:09:55

Re: Bring ARM into the fold?

#29 2024-04-01 07:19:53

Re: Bring ARM into the fold?

#30 2024-04-01 16:33:55

Re: Bring ARM into the fold?

#31 2024-04-01 17:19:57

Re: Bring ARM into the fold?

#32 2024-04-01 21:11:34

Re: Bring ARM into the fold?

#33 2024-04-03 12:03:46

Re: Bring ARM into the fold?

#34 2024-04-11 21:35:07

Re: Bring ARM into the fold?

#35 2024-04-14 16:08:57

Re: Bring ARM into the fold?

#36 2024-04-15 03:17:51

Re: Bring ARM into the fold?

#37 2024-04-15 16:09:57

Re: Bring ARM into the fold?

#38 2024-04-15 21:00:29

Re: Bring ARM into the fold?

#39 2024-04-16 05:51:32

Re: Bring ARM into the fold?

#40 2024-05-05 14:04:10

Re: Bring ARM into the fold?

#41 2024-07-01 19:07:33

Re: Bring ARM into the fold?

#42 2024-07-01 19:25:46

Re: Bring ARM into the fold?

#43 2024-07-01 19:38:07

Re: Bring ARM into the fold?

#44 2024-07-01 23:02:31

Re: Bring ARM into the fold?

#45 2024-07-03 02:40:55

Re: Bring ARM into the fold?

#46 2024-07-03 17:57:19

Re: Bring ARM into the fold?

#47 2024-07-04 18:40:59

Re: Bring ARM into the fold?

#48 2024-08-01 05:31:06

Re: Bring ARM into the fold?

#49 2024-08-04 20:10:10

Re: Bring ARM into the fold?

#50 2024-08-05 10:27:27

Re: Bring ARM into the fold?

Board footer