Debian on everything (well except the router is on OpenWrt).

First installed Debian more than 25 years ago. Tried some other stuff, Debian is still best for me.

There should not be a space between the entries in $PATH, just :. Plus, this is syntactically wrong: export allows to set multiple variables separated by space, like export A=a B=b. You’re essentially doing export A=a B which makes it ignore the B part as it is nonsensical.

Also path should contain directories, and /usr/sbin/grub-install/grub-install isn’t a directory. In fact it almost certainly does not exist at all.

Path should contain at least /usr/bin. That’s why no command works, they’re all in /usr/bin. The shell looks through all the directories in $PATH (separated by :) to find commands.

Good and informative article.

Maybe? It’ll almost certainly be worse (or not work at all maybe) than on Windows.

Oh that’s pretty cool! I does seem like a shame to not have something like that on Linux.

Seems like a good and useful workflow for sure. Don’t know if something equivalent exists, maybe it doesn’t.

I’d personally use find for this, but it is a command line tool, and while I have memorized some of the more common options (directories-only would be -type d for example), I’d have to look at the manpage for more advances options. It’s not hard exactly but it’s not easy-to-use GUI software for sure.

I guess because that adds extra complexity that isn’t inherently necessary and can be added on top, plus it eats resources. You’ll spend the cycles either way basically, at least this way it’s optional. I don’t bother with a file indexer because with SSDs nowadays, find is pretty fast, and how often do you search for files anyway?

Linux has APIs to get notified on file system events (fanotify, inotify) which would allow such a service to update itself whenever files are created/delete immediately, but locate is way older than that, from the 80s. I think popular DEs have something like that.

There’s also ways to search for specific files that come with packages (e.g. dpkg -S), because the package manager already maintains an index of files that were installed by it, so you can use that for most stuff outside /home.

locate uses an index you need to update using updatedb before it is able to find anything.

updatedb may run periodically because of a cron job, but the index is probably missing right after installing it manually.

That “U=xxx” is the IMAP UID, which is a unique identifier that message has in the IMAP mailbox. mbsync adds that to the filename just so it can track which (local) message corresponds to what message on the IMAP server.

When moving a message from one mailbox (folder) to another, this UID changes, because it’s per-mailbox only. If you read the manpage for mbsync, it says explicitly that the MUA should strip the U=xxx when moving between maildirs, so the behavior of aerc here is correct.

In order to get to the bottom of this, you’d probably have to enable the debug output of mbsync and look at exactly what IMAP commands it sends to Gmail, then decipher the relevant command(s) by looking at the RFC, and then decide whether it’s Gmail or mbsync’s fault this gets lost. You could also contact the mbsync devs with this I guess.

I found someone complaining about the same issue, without getting a reply, 7 years ago, except that person was using mutt: https://stackoverflow.com/questions/52218254/isync-mbsync-on-gmail-marks-mail-as-new-after-move-to-another-folder

That doesn’t help you obviously but from this we might guess it’s probably not aerc’s fault.

The “seen” flag should be represented by an “S” in the filename of the mail (see Maildir spec).

You could probably observe filename changes using:

fsnotifywait -m $YOUR_MAILDIR -r -e move -e create -e delete

While that is running in your terminal, move a mail using aerc, and see if aerc correctly preserves the “S” flag in the filename.

First, check if you can login, with your new user, on the Linux console (i.e. Ctrl-Alt-F1 through F7). If you can, the username change probably went through correctly. Report back if you cannot login via console or you get warnings/errors.

Your login session does automatically terminate if the session process for Cinnamon exits, booting you back to GDM (or whatever login manager you have). So probably the Cinnamon session process, started by GDM, craps out for some reason. The reason is probably, I suspect, that it cannot access or cannot find some file it wants to open.

Check ~/.xsession-errors, it might tell you what went wrong.

Also check the permissions of your home folder, the files in your home folder, and check if you correctly set up the symbolic link from /home/olduser to /home/newuser as the guide suggests.

It’s like the old Debian but with newer software.

I guess the wayland stuff works ok now. That wasn’t quite ready for the mainstream in the last release.

I recommend anyone to do a backup (I haven’t always and it bit me). However, if you create separate /home partition you can keep that between re-installs, even re-installs of different distros. And you can also share the same home partition between multiple OSs you might have installed at the same time.

Sharing /home between distros can cause issues though: If one distro’s $SOFTWARE is newer that the other distro’s, they will still share the same dotfile configuration, and while most software is designed to deal with older configuration/database/etc files, older software many times cannot deal with newer files.

Because people here accuse Poettering of being an asshole: I’ve read some of his blogposts and seen some talks of his and him doing Q&A: He answered professionally, did his best to answer truthfully, did acknowledge when he didn’t know something. No rants, no opining on things he didn’t know about, no taking questions in bad faith.

As far as I can tell all the people declaring him some kind of asshole are full of shit.

The tokens can be worth different amounts. There can be 1 ¢ tokens, 10 ¢ tokens, 1 € euro tokens, 10 € tokens, whatever. Your wallet app will, when withdrawing, generate various tokens worth different amounts.

Using those tokens will be somewhat like paying in cash at a store that does not return any change. You gotta pay the exact amount. In order to facilitate that, you’d withdraw tokens worth only small amounts. There wouldn’t be like be any 50 € tokens in practice. If you wanted to withdraw 50 €, you’d get 1000 1 ¢ tokens, 100 10 ¢ tokens, and the rest 1 € tokens or something like that, to make sure you always have the exact amount ready to pay for anything.

I looked at this a looong time ago, but the basic idea is that the tokens (equivalent to cash coins/banknotes) are generated on the end user’s device, through some public-key cryptographic back-and-forth protocol. The issuer (bank/central bank/payment provider) does not see these tokens (they’re only on the end users device), but can verify that they’re legit (i.e. issued by them) somehow.

You can take one of these tokens to them, and deposit it in an account. They won’t know who it’s from but they know it was legitimately issued by them. Depositing a token is also supposed to be the only way of figuring out if it is a legit token, the bank will not tell you if a token is legit unless you deposit it.

When someone pays with these tokens in a shop, the shop will want to immediately (during checkout) deposit them, to make sure they’re legit, and also to make sure the token hasn’t been double spent. A shop that doesn’t do that makes itself vulnerable to fraud. This means shops will have a hard time hiding their revenue (to dodge taxes) compared to cash.

If someone you trust gives you a token (birthday money from your grandma, say), you don’t have to immediately deposit said token, since presumably you trust your grandma to not give you fake or double-spent tokens. Since you trust you grandma, there is no need to deposit the token and involve the bank, and that transfer would be untraceable (it’s literally just copying a number from her phone to yours).

The idea is that shop owners would have a hard time dodging taxes without opening themselves up to fraudsters using fake tokens, while the customer cannot be identified. You’d also be able to exchange tokens with family and friends in a way that isn’t traceable, as long as you trust them to not screw you over.

Yeah no problem. I’d like to point out that this puts a hole in your firewall. If you have something exposed via udp, and an attacker knows about your --sport rule or figures this out, they can connect to it just by setting their source port to 5353. You can check what’s listening on udp with ss -lun or sudo ss -lunp (for process info).

Also, I have looked up what @Eideen@lemmy.world said about dig not supporting mdns and I think they are correct. With mdns, because of the multicast nature, you can get replies from multiple computers, and that’s a pretty big difference to regular dns. How could it even reliably know it has gotten all the replies or if it should wait for more? It just sort of happens to work correctly if you get a single reply.

Also, and I also looked this up, mdns lookups will to go through avahi-daemon on regular glibc distros. The libnss-mdns plugin description for glibc says this:

nss-mdns tries to contact a running avahi-daemon for resolving host names and addresses and making use of its superior record cacheing. If Avahi is not available at lookup time, the lookups will fail.

As I said, I’m not sure about that.

Still, dig won’t be listening on port 5353 for the answer, it’ll open some random port, so the firewall rule for 5353 will not apply. And the conntrack rule, is my guess, also doesn’t apply, because what I think the conntrack module does is:

• Remembers about the outgoing connection (i.e. when dig sends its udp packet out): source port, destination IP and port
• Check incoming packets against this info, and lets them through if they appear to be an answer

Since the outgoing packet is going to multicast, and the incoming packet (I suspect) is coming from the IP of the machine that answers (a different IP therefore), conntrack wouldn’t be able to figure that out. The answer doesn’t match the outgoing packet that dig sends. Since this is just a hunch, I would try to confirm this by looking at the traffic in e.g. wireshark.

My hunch on what’s going on: Dig opens up a different udp port (it has to, there would be avahi-daemon listening on 5353). So it sends out to the multicast address on 5353, but the answer comes back from the actual IP of whoever is answering, to whatever port dig is listening on, and the connection tracking is not smart enough to figure out this should be let through?

You should look at the traffic with wireshark.

Also maybe that’s fine in practice? Do applications actually run their own mDNS queries? Maybe it all goes through avahi-daemon? That uses port 5353 so that would get an answer if it did the mDNS query instead of dig. But I’m not sure how this works, so that’s just a guess.

There’s some wrong things in this article, and a thing worth mentioning.

Half-Life (and its mods like Counter-Strike) had Linux server versions, and a lot of dedicated servers ran on Linux, which I think is worth mentioning when talking about the history.

Steam wasn’t well received at first, people didn’t like that there was now this special launcher/downloader you had to use. Mind you they moved their old games onto Steam, so it’s not like you knew about this when you bought it. Also there weren’t any games on there except Half-Life and related titles, like HL mods that got their own release.

Contrary to what the article claims, MacOS does not support some outdated version of DirectX, it does not and never has supported DirectX at all. DirectX was only ever supported on Windows and XBox.

DirectX also was not well received at first. Here’s an old article from gamedev.net (2002):

What later became known as DirectX 1.0 ended up not being very widely accepted. It was buggy, slow, badly structured, and overly complex.

Of course, Microsoft wasn’t about to just give up. They kept working at it, asking the community for ways to improve it. The first truly viable version of DirectX was DirectX 3.0. A few years later, they released DirectX 5 (skipping 4 entirely), which was the first truly useful version. Incremental improvements were made with version 6. Then came DirectX 7.0.

DirectX 7 was the first one to actually be embraced by game developers. It worked well, making game programming reasonably easy, and a lot of people liked the interface.