Can I remove sudo from Arch?
The New York market is closing, with Frankfurter memes taking over, going bullish on brainrot.
Consider a key pair, consisting of two brutally large numbers, but otherwise pretty much identical. Magical math exists that makes it so that if you math your data with one of these brutally large numbers, you get the original data back only if you math it with the other large number. That's basically it.
Now we slap convention onto this, and keep one of the paired, large numbers a secret, and call it our private key, the other number is disseminated and called the public key for that reason.
Now everyone can math data with your public key, so that only the paired private key, which only you know, can de-math it. This is encryption/decryption.
Signing is very similar, but now you use your private key, which only you know, to math a digest of your data, and all the world can de-math this correctly only with your public key, thus proving it was indeed your private key used to math the data in the first place, and by extension attribute the signature to your public key identity. Your private key is never known to anyone but you, which is an essential difference to "classical" symmetric encryption with a shared secret.
You may realize how easily a code signature can become a liability, if you fail to keep your private key secret for any reason. You can be trivially impersonated, with basically no chance of recourse or deniability with an SSH key, while you can at least invalidate a GPG key publicly and mark it as "stolen" that way. This is potentially very important, if there's any legal meaning attached to your signature, and if not, why bother with code signing in the first place, if "trust me bro" is well enough.
FOR NO REASON!!?! 🔥 🔥 That "barista" 🫤 deliberately spelled the name of my 😍 daughter 🥰 Brettly wrong on the cup, and did not appreciate her 🦄 uniqueness AT ALL when I demanded them to correct their stupid mistake! The nerve of some people! 🤯
A study on 6 (six!) people? That's not a study, that's less than I get asking around during any lunch break. [this is worthless! meme] Wonderful trolling of some unpleasant cow-orkers, though, chapeau!
Crusty, cynical folks, entirely unlike and unrelated to myself, could be tempted to name it the Beginning of Eternal October for Linux.
That's listed in the makedepends array of the PKGBUILD, like here.
You might want to look into the query options -d in combination with -t for pacman's -Q, to list packages installed as dependencies, but "Restrict or filter output to print only packages neither required nor optionally required by any currently installed package."
Bonus cleanup pro-tip: alias pacorphans='sudo pacman -Qtdq | sudo pacman -Rns -' as explained in the wiki, mentioning makedepends in particular.
yeah i tried looking up what that would even be a symbol of and how that, historically, could be justified, and found absolutely nothing. not even in their “yo, tha’s anti-semitic” claim.
I remember propaganda "caricatures" of jewish octopi ensnaring the world, promoting the myth of a jewish conspiracy to take over the world. Seeing how this conspiracy theory is somehow still going strong, I'm not surprised how sufficiently simple-minded, or ill-willed, actors pick up on the connotation, and interpret it within bounds of their very finite understanding of the world. Or twisting confabulated connotations in a weird, whataboutistic way to somehow.. critique? others as antisemitic, since they've been labeled as such themselves all the time, and can only see and use it as a content-deprived slur anymore to silence and attack their perceived enemies.
Well, either way, antisemitic octopi were a thing in Nazi Germany propaganda. Poor cephalopods.
Probably molly-guard.
I did not need this to hit so hard right now. Time to start a new therapeutic rye sourdough.
Wise decision! Best of luck for when you give it another try, with fresh eyes and a clear mind, and enjoy your XP gain dopamine on the way.
Yeah, that's normal, intended, and does not prevent general lookups taking the global DNS first. Do you see an issue with this?
I gave this setup a try real quick, to make sure I'm not overlooking something, with dnsmasq for testing on 127.0.0.1:9053:
text
[gyroplast@e15g4 ~]$ dnsmasq --listen-address=127.0.0.1 --port=9053 --address=/testme.localnet/127.42.0.69 --no-daemon --no-hosts --no-poll --log-queries
dnsmasq: started, version 2.90 cachesize 150
dnsmasq: compile time options: IPv6 GNU-getopt DBus no-UBus i18n IDN2 DHCP DHCPv6 no-Lua TFTP conntrack ipset nftset auth cryptohash DNSSEC loop-detect inotify dumpfile
dnsmasq: warning: no upstream servers configured
dnsmasq: cleared cache
When triggering a query on that test record, f. ex. with ping -c1 testme.localnet, you'll see it's directed to the dnsmasq instance and working as intended:
text
dnsmasq: query[A] testme.localnet from 127.0.0.1
dnsmasq: config testme.localnet is 127.42.0.69
dnsmasq: query[AAAA] testme.localnet from 127.0.0.1
dnsmasq: config error is REFUSED (EDE: not ready)
dnsmasq: query[AAAA] testme.localnet from 127.0.0.1
dnsmasq: config error is REFUSED (EDE: not ready)
The DNS setup with systemd-resolved is pretty confusing, and outright contradicts many, MANY previously correct instructions of how to set your /etc/resolv.conf. I'm not surprised if it is giving you a headache right now, but all I can say is to diligently work through its configuration, and understand how systemd-resolved is supposed to work. From experience, make sure your tests are sound and representative, or you'll continue looking for errors in your setup despite everything actually working just fine, maybe because you missed a reload or had a typo or misunderstanding in your wireshark filter.
In the same vein, make sure your DNS listening on :9053 is really working as intended, otherwise you can bark up the wrong tree all day long. Debug logging is your friend, and more accessible and less error prone than tcpdump/wireshark.
You'll figure it out from here, I'm sure.
I ran the command with sudo and got the error.
Yes, that's why I said don't do that. It's a common, non-intuitive interaction with sudo and shell redirections. Don't stress over it, I shouldn't have done it all that fancy in the first place.
Regarding your problem: Your setup is likely inconsistent now due to your experiments and previous setup attempts. HOLD THE REINSTALL, learn to fix it, it's not that complex.
First off: you're not running in the recommended "stub mode" where /etc/resolv.conf is symlinked to /run/systemd/resolve/stub-resolv.conf, and where the configuration you did is actually actively used. Fix that first. Have some docs. This is my stub /etc/resolv.conf, for example, so you know what to look for, roughly:
[root@e15g4 gyroplast]# cat /etc/resolv.conf
# This is /run/systemd/resolve/stub-resolv.conf managed by man:systemd-resolved(8).
# [...]
nameserver 127.0.0.53
options edns0 trust-ad
search fritz.box
Don't create that file with these contents manually. Read the docs, follow the instructions, don't ruin your day.
Assert you have no lingering, conflicting setup in the /etc/systemd/resolved.conf main config. The default file is effectively empty / commented out, to allow for automatic system updates without conflicts. You could reinstall the package to get the original file back if you're unsure.
Make sure the systemd-resolved.service is enabled and started: systemctl enable --now systemd-resolved.service
You might want to install systemd-resolvconf as well if you commit to a systemd-resolved setup, for maximum compatibility.
Make use of resolvectl status to verify the status:
Global
Protocols: +LLMNR +mDNS -DNSOverTLS DNSSEC=no/unsupported
resolv.conf mode: stub
Current DNS Server: 127.0.0.1:9053
DNS Servers: 127.0.0.1:9053
Fallback DNS Servers: 1.1.1.1#cloudflare-dns.com 9.9.9.9#dns.quad9.net 8.8.8.8#dns.google
2606:4700:4700::1111#cloudflare-dns.com 2620:fe::9#dns.quad9.net 2001:4860:4860::8888#dns.google
[...]
`
If that's still not what is expected, crank up debugging and check the logs of the service to see if for some reason your config file isn't loaded due to a typo somewhere, or if it's loaded, any other reason that may override your settings later. It's practically guaranteed there's an inconsistency left somewhere, and reading the debug log points you at the actual problem.
It's worth fixing this in that way. With stub mode, you gain a lot of flexibility in your setup, and it works well in tandem with NetworkManager, DHCP, VPNs, and libvirt/qemu networking. You have to make sure you're not inadvertently setting up some broken "hybrid" of old-school /etc/resolv.conf manual config and systemd-resolved, this will drive you mad, and it's a pain to diagnose. Read that wiki page, do not intermingle with crap you pick up on stackoverflow or AI bullshit, and you'll end up with a DNS config that actually works like magic.
Don't slap a sudo in front where it doesn't belong. Run this as root, or the shell redirection will fail. Or just create that file with these contents in any other way you like and feel comfortable with, it's not a magic incantation you have to use verbatim, after all.
DNS is a resolved.conf only setting. systemd docs are comprehensive and help navigating what to put where, no need to throw shit at the wall and see what sticks. :)
man resolved.conf:
OPTIONS
The following options are available in the [Resolve] section:
DNS=
A space-separated list of IPv4 and IPv6 addresses to use as system DNS servers. Each address can optionally
take a port number separated with ":", a network interface name or index separated with "%", and a Server
Name Indication (SNI) separated with "#". When IPv6 address is specified with a port number, then the
address must be in the square brackets. That is, the acceptable full formats are
"111.222.333.444:9953%ifname#example.com" for IPv4 and "[1111:2222::3333]:9953%ifname#example.com" for IPv6.
DNS requests are sent to one of the listed DNS servers in parallel to suitable per-link DNS servers acquired
from systemd-networkd.service(8) or set at runtime by external applications. For compatibility reasons, if
this setting is not specified, the DNS servers listed in /etc/resolv.conf are used instead, if that file
exists and any servers are configured in it. This setting defaults to the empty list.
Added in version 213.
TL;DR: Create a drop-in for resolved and put the DNS= line there, with colon separating the port. Reload the config of the service to activate.
install -o0 -g0 -dm755 /etc/systemd/resolved.conf.d
install -o0 -g0 -m644 <(cat <<EOF
[Resolve]
DNS=127.0.0.1:9053
EOF
) /etc/systemd/resolved.conf.d/90-dns_port.conf
cat /etc/systemd/resolved.conf.d/90-dns_port.conf
[Resolve]
DNS=127.0.0.1:9053
systemctl reload systemd-resolved
"Cash or credit?" "Arch, btw."
You can open up many avenues of feeding yourself "well enough" if you reconsider your definition of a meal, and consider actual cooking/food prep to be an option.
Cheap and storage-friendly ingredients off the top of head are potatoes, rice, (dried) pasta, flour, cheese, eggs (no need for refrigeration, just don't wash off the protective layer), onions, garlic, tofu, and many hardier vegetables like broccoli, cauliflower, tomatoes, zucchini, carrots, and up to a point even iceberg salad, cucumbers, mushrooms (keep dry and airy if fresh, they dry out), as well as various pickles as snacks, if you're so inclined. With onions, potatoes, and eggs alone you can stuff your face for weeks without repeating a single dish. :)
I keep (vegan) crème fraîche, soy/rice/almond/oat drinks, and "cooking cream" around for weeks unrefrigerated as great milk and cream substitutes, but the milk-based products have a solid shelf life as well as long as they're unopened. This is perfectly viable for various creamy sauces or dips, and for cereals as a snack or breakfast option. With a nice oil or butter and a few seasonings you can whip up a surprising amount of simple meals, starting with classic pasta with a tomato sauce of your liking, to the typical trifecta of "carbs, meat, and veggies with optional sauce" that passes for an actual meal. You can easily build almost any kind of sauce you wish from stable ingredients to go with whatever, too.
There's a good bunch of great thai curry pastes around that go well with a handful of veggies and rice, and keep cooking effort to a minimum. If I'm particularly lazy, I boil a pot of potatoes and eat those straight with sour cream. Leftovers are due for the chippy treatment in a pan with onions and eggs, or just eaten cold as a snack with salt or leftover dip. Same goes for rice, the amount of stuff people throw atop their rice to chase it down is astonishing. Lao Gan Ma chili crisp is great, a straight sweet chili sauce works in a pinch, and if you're into chinese cooking anyway, you can throw almost anything in a pan, fry it up, and toss it to your rice with a generic "brown sauce" deal.
The biggest issue I see is fresh meat, though. That's quickly a serious hazard when kept at room temp, so I'd suggest to try reducing your meat intake as long as you're unable to store it properly, and otherwise cook the same day you buy. Truth be told, a lot of the vegan meat substitutes are surprisingly good by now, even though they're highly processed garbage and pretty expensive for what they are, but they keep unrefrigerated much longer and safer than the real deal. Don't expect a good steak, but anything "chicken" is nigh indistinguishable, IMHO.
All the other things do keep "fresh enough" at least for a couple of days, but you'll need to consider what you buy and when you are able to cook beforehand so things don't spoil, especially if you cannot buy fresh groceries more often than weekly for any reason.
TL;DR: For a generic meal, combine potatoes, rice, or pasta with a vegetable of your least distrust, optionally fresh meat if available, and a decent sauce. In a pinch, sauce + anything also works just fine, and sometimes even without sauce. Just don't take pictures for Insta when horking down a bowl of pasta with ketchup, we've all been there.
Delete the existing file /usr/share/icons/bloom/icon-theme.cache, install the package normally without forcing, and don't sweat it. That cache can (and should automatically) be recreated afterwards with gtk4-update-icon-cache /usr/share/icons/bloom, but it's strictly not critical.
The previous version of the package did not include this file, lending credibility to the assumption of a packaging mistake, as does the existence of an issue for that problem already.
Just fix this nag yourself as described, and expect this to be fixed by the packager eventually.
What kind of soulless psychopath leaves a window of this size unmaximized is the real question here. Also, a horizontal scrollbar in the main section, able to scroll maybe 8 pixels total to see some more of the glorious empty padding, could have been a nice touch as a consequence of the "unintended" window size.
In principle, yes, although the optional
base-develgroup depends onsudo, as do hundreds of AUR packages, and yet other projects you install tend to just assume you have asudobinary around. Removing sudo will not break your system, but lead to well-deserved anger towards people not declaring their dependencies. :)If you're ready to deal with the occasional application or script croaking, and subsequently fixing it, you should be fine removing sudo. I would personally consider building a dummy package replacing sudo, including a simple run0 wrapper at
/usr/bin/sudo, to have a clean and transparent replacement.