Nia

It’s complicated.

ARM system initialization doesn’t happen the same way as on x86 (the instruction set your computer is probably using unless you’re on a phone/tablet). On x86, once the CPU is initialized, it can inform the Linux kernel of what hardware is installed and how to talk to it through a protocol called ACPI. Thus, for Linux to work on a system, it must only support the CPU and some necessary hardware (e.g. I doubt you’ll have a usable system if USB, graphics, audio, and networking are unsupported, but otherwise it’s fine).

ARM functions quite differently; ACPI doesn’t exist, so instead the Linux kernel has to already know what hardware is installed and where through a configuration file called a device tree blob - basically weird JSON. Therefore it’s not enough that Linux supports the Snapdragon 7c (it does) - there must also be a builtin device tree config for your specific device. There likely is one; a simple way to check would be to look here for your device’s name (the Snapdragon 7c’s codename is SC7180, so the file you’re looking for would be sc7180-$vendor-$model.dts). If there isn’t and you’re willing to get moderately deep in the weeds, you can write your own device tree source file and load it into the kernel (assuming you have at least a rudimentary familiarity with programming, this is doable with a little dedication).

As for your other questions, you don’t need to worry too much about instruction set and architecture - being ARM will limit what software can run, but emulation is sort of okay too. It will, however, be far more power-efficient than a 6th gen Intel i3 if that’s what you care about - and gut instinct says faster.

It really depends on your usecase, though. If your budget is limited enough that these are serious options, I’d honestly recommend finding a decent second-hand laptop running something a bit better and more recent - but if you run mostly open-source software, don’t care about gaming at all, and are willing to get a little deeper than the average hobbyist for some extra battery life, the ARM laptop might be interesting.

Nobody asked

Good point and I absolutely should have mentioned this in my original comment, but I do think there is a risk here worth mentioning. A lot of guides for installing some arbitrary piece of software on Manjaro (or, to be fair, any Arch-based distro) will boil down to installing some package from the AUR, and the average Manjaro user is probably less tech-savvy than the average Arch user. Also, the pamac warning dialog only warns against packages not compiling or being buggy, not against malicious ones, and as far as I know - though it’s been a while since I used pamac - it doesn’t allow you to inspect the PKGBUILD at install-time, whereas most CLI AUR helpers e.g. paru which I use require it and require manual signoff every time said build script changes.

As an entirely unscientific test, I googled “manjaro enable aur” and checked the first 5 results to see if there’s any warnings (I figured this is a relatively common query from Manjaro users?) and only 2 even mentioned the risk of malicious packages, with the top result not mentioning any risks whatsoever, not even breakage or bugginess. I’m sure there are many resources that do make this clear, but I doubt the average Manjaro user will see them.

This is arguably an issue on most Arch-based distros with a pretty installer, though it seems Manjaro is particularly vulnerable since it’s marketed as a beginner-friendly distro despite all of these footguns.

Edit: at the risk of crucifixion, this is also why I usually direct newcomers towards using flatpaks wherever possible instead of using 3rd party repositories unless said repositories come directly from the developers of said (trusted) package. Briefly looking over the Manjaro docs, it seems like enabling flatpaks is actually harder than enabling AUR packages as it requires installing a compat plugin (whereas AUR support appears to just be a settings change). Maybe there’s an option during the installer to enable it, but I couldn’t find a mention, and this might also push users towards the less-secure and unsandboxed AUR.

No worries, it confused me too and I had to double-check ^^

I don’t think Manjaro made Asahi, that seems like poor phrasing. Manjaro has tried to get into the ARM scene for sure (and royally messed up), but Asahi is a completely independent project, directly based on Arch ARM.

There’s a lot of reasons people hate on Manjaro, though generally they boil down to instability - despite being on a slower schedule than Arch, a lot of people report worse breakage; their main “testing” is just being a week behind Arch without actually testing much.

Crucially, this can break things when mixing in AUR packages since those are shared w/ Arch and so anything in there that’s precompiled against the Arch version of relevant libraries might just break.

It also has considerably deficient security policies, such as the GUI installer pamac allowing unsuspecting users to trivially install unvetted packages from the AUR without even a clear indication they may be dangerous, and they forgot to update their SSL certificates twice edit: five times (see https://lemmy.ml/comment/1343440), asking users to manually overwrite them as a “fix”.

Unrelated to desktop, I’ve also noticed Manjaro staff are quite hostile and unpleasant to work with; I’m involved in a project that works on Linux on mobile devices, and Manjaro’s mobile team has been less than the most pleasant. This is a personal gripe for sure and unrelated to the distro itself, but if I’m going to take a dump on Manjaro I’ll do it all the way.

As for your other question; you can simply copy the sway config file from the Manjaro install. Either mount the ISO and search there, or if it needs to be installed to populate the sway config, just install in a VM and copy it from there. Necessary packages should be relatively easy to find by just reading the errors sway spits out and googling them.