SpaceCadet

SpaceCadet, 1 year ago

Mental note: have to migrate my gitea instance over to forgejo.

SpaceCadet, 1 year ago

The worst part is to change some things it adds like an extra 4 clicks to the old method.

And then at the final click, it takes you to that control panel screen anyway lol

SpaceCadet, 1 year ago

That’s what I do. I do have a small VM that is linked to it in a keepalived cluster with a synchronized configuration that can takeover in case the rpi croaks or in case of a reboot, so that my network doesn’t completely die when the rpi is temporarily offline. A lot of services depend on proper DNS resolution being available.

SpaceCadet, 1 year ago

For me gravity sync was too heavy and cumbersome. It always failed at copying over the gravity sqlite3 db file consistently because of my slow rpi2 and sd card, a known issue apparently.

I wrote my own script to keep the most important things for me in sync: the DHCP leases, DHCP reservations and local DNS records and CNAMES. It’s basically just rsync-ing a couple of files. As for the blocklists: I just manually keep them the same on both piholes, but that’s not a big deal because it’s mostly static information. My major concern was the pihole bringing DHCP and DNS resolution down on my network if it should fail.

Now with keepalived and my sync script that I run hourly, I can just reboot or temporarily shutdown pihole1 and then pihole2 automatically takes over DNS duties until pihole1 is back. DHCP failover still has to be done manually, but it’s just a matter of ticking the box to enable the server on pihole2, and all the leases and reservations will be carried over.

SpaceCadet, 1 year ago

DNS-over-HTTPS

You can also do that with running cloudflared or unbound on your pihole.

SpaceCadet, 1 year ago

The official image jellyfin/jellyfin tracks unstable

Huh? That doesn’t appear to be the case. jellyfin/jellyfin:latest, which is what they tell you to use in the installation instructions. gives me 10.8.13 which appears to be the latest stable release.

There are newer and unstable versions available in dockerhub as well, but latest doesn’t give you those. After all latest is just a tag with no special meaning of itself, it doesn’t necessarly give you the most recent build.

SpaceCadet, 1 year ago

This reaction wants to redefine adulthood as post 25

It’s even more than that, it wants to make adulthood some kind of sliding window where the age of the older partner defines how “adult” and “capable of making decisions” we see the younger partner, and the older a person gets the more people at the lower end of the age range get excluded for them from this fictional adulthood. For example: 60 and 30 would also be seen as inappropriate.

Now it’s perfectly normal for younger people not to find much older people attractive or suitable to have a relationship with and vice versa, and they may even find the idea repulsive, but this is still a personal preference. It’s probably even the preference of the majority of people, but that does not mean we should take away the agency of adults to choose their partners when they have a different, non-conforming preference. At that point it has nothing to do anymore with protecting vulnerable people from predators, but about imposing your own preferences and dating standards on other people, and you’re quite right in calling it out for the neo-puritanical and conservative thinking that it is.

SpaceCadet, 1 year ago

I believe there’s one in France too.

SpaceCadet, 1 year ago

Heh the comparison also holds if you use 10=Windows 7 and 11=Windows 8

Or 10=Windows 98 and 11=Windows ME

SpaceCadet, 1 year ago (edited 1 year ago)

You’re good. That’s the latest image, it’s just the confusing Debian version scheme where the package version is not the same as the kernel version. Debian package version 6.1.0-17 = kernel version 6.1.69-1

See:

<span style="color:#323232;">$ uname -a
</span><span style="color:#323232;">Linux debian12 6.1.0-17-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.69-1 (2023-12-30) x86_64 GNU/Linux
</span>

And:

<span style="color:#323232;">$ dpkg-query --list linux-image-6.1.0-17-amd64
</span><span style="color:#323232;">Desired=Unknown/Install/Remove/Purge/Hold
</span><span style="color:#323232;">| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
</span><span style="color:#323232;">|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
</span><span style="color:#323232;">||/ Name                       Version      Architecture Description
</span><span style="color:#323232;">+++-==========================-============-============-=================================
</span><span style="color:#323232;">ii  linux-image-6.1.0-17-amd64 6.1.69-1     amd64        Linux 6.1 for 64-bit PCs (signed)
</span>

SpaceCadet, 1 year ago

uBlock can do much more refined and targeted blocking than a pihole because it has access to the entire page that is being served and can selectively filter elements. The pihole only has access to the DNS name, and DNS blocking is a rather crude tool to block ads that can be defeated by serving the ads from the same domain.

For example: a pihole doesn’t work for blocking YouTube ads, because they come from the same domain.

SpaceCadet, 1 year ago

That’s what I said yes.

SpaceCadet, 1 year ago (edited 1 year ago)

Realistically it’s not super dangerous, and no you probably don’t have a virus just from browsing a few tech support sites, but you do eliminate your last line of defense when you run software as root. As you know, root can read/change/delete anything on your system whereas regular users are generally restricted to their own data. So if there is a security problem in the software, it’s made worse by the fact that you were running it as root.

You are right though that Firefox does still have its own protections - it’s probably one of the most hardened pieces of software on your computer exactly because it connects to the whole wide internet - and those protections are not negated by running as root. However if those protections fail, the attacker has the keys to the kingdom rather than just a sizable chunk of the kingdom.

To put that in perspective though, if there is a Firefox exploit and a hacker gets access to your regular user account, that’s already pretty bad in itself. Even if you run as a regular unprivileged user they would still have have access to things like: your personal documents, your ssh keys, your Firefox profile with your browsing history, your session cookies and your saved passwords, your e-mail, your paypal account, your banking information, …

As root, they could obviously do even more like damage like reading all users’ data, installing a keylogger or screengrabber, installing a rootkit to make themselves undetectable, but for most regular users most of the damage is already done when their own account is compromised.

So when these discussions come up, I always have to think about this XKCD comic:

https://imgs.xkcd.com/comics/authorization_2x.png

SpaceCadet, 1 year ago

I agree that at some point you have to be able to ditch technical debt, but you still should be able to do more or less the same things with the new system as with the old system and that’s currently still not the case.

The problem is that the architecture of Wayland and the organization around it themselves impose limitations that have a chilling effect on development for it. One issue is that Wayland has been deliberately left very slim, leaving a lot of complexity and implementation details up to the compositor. A compositor can be seen as something that approaches the size and complexity of an entire X display server. This means that if someone wants to create a window manager, they have to implement a whole compositor first. So instead of writing window manager code, which is what the developer is probably the most interested in, they are spending most of their time implementing the compositor.

Naturally this also leads to a lot of duplication of effort. For example: GNOME, KDE and the window managers that have implemented a wayland version each have their own compositor that by and large does the same thing.

Another issue is the standardization of the protocols and interfaces that the different compositors use, or lack thereof. There is a steering group containing the major stakeholders that votes on proposed extensions, but good proposals often get shot down because the major stakeholders can’t agree on it and sometimes ego or principles gets in the way. And then you have cases where one compositor just goes their own way and implements something regardless of what the others do.

For example, as a result of this there’s still no standard screen capture API, so if you want to do things like screenshots, remote desktop, desktop streaming, … whether or not you can do that, and with which tool, depends on the compositor you use. Another example: they’re currently still bickering over whether or not an application should be allowed to place windows with absolute coordinates, and how that should be implemented. We’re currently 15 years after initial release of Wayland…

In my opinion, this is all completely backwards. Both in an organizational and technical sense way too much has been left up to the individual compositors that should have been a core part of Wayland itself.

Unfortunately, it’s all too late to fix this. We’re 15 years into Wayland development, and the flawed architecture has been set in stone. Wayland isn’t going to go away soon either, too many parties are invested in it. So for me the reasonable thing to do is to wait and stick with X11 until the dust settles and something emerges on the other side that is better than what I currently have.

SpaceCadet, 1 year ago (edited 1 year ago)

I know wlroots exists. It’s a library that helps you implement a compositor (i.e. does some of the heavy lifting), but at the end of the day the window manager developer is still implementing a compositor and is responsible for maintaining his compositor.

The mere fact that wlroots, and other efforts like louvre, are necessary at all actually prove my point that it was an idiotic design to push everything off into “compositors”.

SpaceCadet, 1 year ago

nowadays egrep is not recommended to use. grep -E is a more portable synonim

Not directed at you personally, but this is the kind of pointless pedantry from upstream developers that grinds my gears.

Like, I’ve used egrep for 25 years. I don’t know of a still relevant Unix variant in existence that doesn’t have the egrep command. But suddenly now, when any other Unix variant but Linux is all but extinct, and all your shell scripts are probably full of bashisms and Linuxisms anyway, now there is somehow a portability problem, and they deem it necessary to print out a warning whenever I dare to run egrep instead of grep -E? C’mon now … If anything, they have just made it less portable by spitting out spurious warnings where there weren’t any before.

SpaceCadet, 1 year ago (edited 1 year ago)

GNU grep, the most widespread implementation, does not include egrep, fgrep and rgrep for years. Distributions (not all, but many) provide shell scripts that simply run grep with corresponding option for backward compatibility. You can learn this from official documentation.

It seems you need to read the official documentation yourself. While it’s new information to me that egrep is no longer a symlink, as it used to be a couple of years ago, but a shell script wrapper to grep -E instead, the egrep command is to this day still provided by upstream GNU grep and is installed by default if you run ./configure; make; make install from source. So it is not a backward compatibility hack provided by the distribution.

You can check for yourself. Download the source from ftp.gnu.org/gnu/grep/grep-3.11.tar.gz, unpack and look for src/egrep.sh or line 1756 of src/Makefile. Apparently the change from symlink to shell script was done in 2014, and the deprecation warning was added only last year.

In any case, my larger point is that the depreciation of egrep was a pointless and arbitrary decision that does not benefit users, especially not veterans like myself who have become accustomed to its presence. I don’t mind change, but let’s be honest, most people are not in the habit of checking the minutiae of every little command line utility they use, so a change like this violates the principle of least surprise. It’s one thing if things are changed with a good reason and the users do not only suffer the inconvenience of the change but get to reap the benefits of it as well, but so far I haven’t found any justification for it yet, nor can I think of any.

So if there is a portability problem with using egrep now, it’s a self-inflicted portability problem that they caused by deprecating egrep in the first place.

Also, my scripts are not full of bashisms, gnuisms, linuxisms and other -isms, I try to keep them portable unless it is really necessary to use some unportable command or syntax.

Good for you. Do you want a cookie or something?

SpaceCadet, 1 year ago (edited 1 year ago)

You are strawmanning, and your links are not countering any point I made. I never disputed the depreciation as fact, and I never recommended that beginners should use egrep over grep -E

I disputed your claims that the egrep command has just been a distro hack all these years, when in fact GNU to this day still distributes egrep through its source tarballs and only very recently started to warn about it through the wrapper script. And again, the only “portability problem” here is the fact that they deprecated it in the first place, i.e. a self-inflicted one.

Then as a Linux and Unix veteran I gave my subjective opinion by lamenting and criticizing the fact that this depreciation happened, and how changes like this always feel like unnecessary pedantry to me. Yes it’s an expression of frustration, but I am allowed to feel frustrated about it. I don’t need people like you invalidating how I feel about breaking changes in software that I use daily.

SpaceCadet, 1 year ago (edited 1 year ago)

Well he wrote it like he wanted to be applauded for it or something.

I also find the irony of your comment extremely funny … although that’s probably lost on you.

Later, dude.

SpaceCadet, 1 year ago

Besides, if anyone tries to boot any other OS which is not mine, the keys are erased.

There are forensic tools that can capture the contents of RAM, and so access your decrypted LUKS encryption key.

I guess it depends on who you are protecting against, but if for example law enforcement wants evidence against you for what they think is a serious enough crime, they just may go through the trouble to do it.

SpaceCadet, 1 year ago (edited 1 year ago)

they cannot access the data from software because it is blocked by login screen

The system may still be vulnerable to over the network exploits. So for example, if the system is running sshd, and a couple of months from now a root exploit is found (à la heartbleed), the attacker may get inside.

It’s somewhat of a long shot, but it’s still a much larger attack surface than butting your head against a LUKS encrypted drive that’s at rest.

they cannot access the data from hardware because it is protected by FDE.

RAM is not protected by FDE. There are (obviously non-trivial) ways to dump the RAM of a running system (Cold Boot attacks, and other forensic tools exist). So if the attacker is dedicated enough, there are ways.

One of the misconceptions I had before is that I assumed that the disk will be decrypted when you enter the LUKS password. This is not true, the password is loaded into the ram, and only decrypts necessary parts to RAM. All the data on the disk is never decrypted, even when you are working in your OS.

Hah! That would be impractical :) Imagine having to decrypt your entire 32TB drive array everytime you booted your computer.

SpaceCadet, 1 year ago

I’m pretty sure that it’s not hardware related

Random segfaulting is not something that “just happens” because of an OS misconfiguration, then if the same problem happens on Arch as well as on a clean EndeavourOS live image it convinces me that it is in fact hardware related somehow. As you have already replaced the RAM, my guess is CPU or motherboard issue.

Zen2/B450 is a widely used and well supported configuration on Linux that you normally shouldn’t have issues with, but Zen2 CPUs are rather notorious for having fragile memory controllers, and sometimes dodgy AGESA firmware releases that can cause issues on some CPUs. I used to have a 3600X myself that started crashing at idle around a particular firmware release of my motherboard, and it was fixed by a subsequent release.

BTW the fact that it doesn’t happen on Debian doesn’t necessarily mean that Arch is the culprit. It could just be that Debian is not triggering the fault because of different, perhaps more conservative, compiler optimizations.

As a last ditch effort, you could try resetting your entire UEFI (bios) settings to default, preferably by pulling the CMOS battery.

BTW, is it only GUI applications that are segfaulting? Or other programs as well? Do you have an old spare GPU you can test with?

SpaceCadet, 1 year ago (edited 1 year ago)

I ditched Ubuntu LTS for my homelab virtual machines around 20.04 when they started to push snaps, netplan and cloud-init, meaning I would have to spend a significant amount of effort redoing my bootstrap scripts for no good reason and learning skills that are only applicable in the Ubuntu ecosystem. I went with debian stable instead, and was left wondering why I hadn’t done that sooner. It’s like Ubuntu without all the weirdness.

SpaceCadet, 1 year ago

The trouble is that my workload doesn’t decrease with an amount equivalent to the outage time. I still have the same tasks to accomplish, so if the network is down for half a day, it just means I have half a day less to get my work done and meet my deadlines.

SpaceCadet, 1 year ago

Who made Red Hat the arbiter of when xorg should end?

I mean, sure they’re a major Linux vendor but their market is servers with hardly any foothold in the desktop market. It would be more interesting to see how long Debian, Ubuntu or Arch will keep xorg alive.