Yes; Organisation du traité de l'Atlantique nord

To be fair, nix would probably be a lot more intuitive if commands were in black speech instead

cope and seethe, transphobe

The IP seems to be in Norway, vaguely around Oslo, and owned by TerraHost. IANAL but I assume this means Lemmygrad could be taken down by either the hosting provider or Norwegian/EEA law. Someone more knowledgeable can probably answer how likely this is, but my guess is "not very".

As for your other question, no matter where this was hosted, the government of said country could probably take it down if it so wanted. All clearnet domains are under jurisdiction of either a national government (for .ml, this would be Mali) or ICANN, and physical servers obviously can be raided.

I do, however, doubt the Norwegian government cares enough about some marxists on the internet to go through the process of judicial approval for seizure of the servers, and the folks in Mali definitely have more pressing matters right now.

Nieuw-Amsterdam komt terug, het is slechts een kwestie van tijd

Love how you just assume I'm from the west. I'm eastern european, my family is also, and we lived through everything - and I've yet to meet someone other than western investors and young kids who thinks things are good/better now

I'm deeply sorry that we don't like supporting the oppression of marginalized groups here

Glad to have been informative :D and good luck on your laptop hunt

That's correct, mea culpa; I've only seriously worked with qcom so entirely forgot that's a thing. I'll update my comment, thanks!

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~~ ACPI is also usable on ARM but Qualcomm refuses to implement it, 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.