aebletrae [she/her]

Ah, Enhanced, the folks that brought us interrogation.

If you had a book which had on its Contents page:

Chapter 1 . . . . . . . . . . page 1

and you crossed it out, then wrote:

Chapter 1 . . . . . . . . . . page 1

Chapter 2 . . . . . . . . . . page 50

someone looking for Chapter 1 is still going to find all the text in the right place (as long as it was less than 50 pages).

Changing the partitition table is like changing the Contents page; it doesn't mess with the rest of the data. And if the new table points to the same place it did before, the data can still be found.

That said, if the filesystem still thinks it's 1TB, you may end up with future problems unless you resize it to fit the reduced partition.

Uh, the XiBucks, obviously.

Look, I get it. Hexbear is a demanding place to be. It expects you to not be a complete asshole almost all the time. You're regularly tested on knowledge of an emoji system so complex, it's been known to make London cab drivers cry. If you unthinkingly parrot talking points, you'll be pounced on with annoying facts and aggressive reasonable concern for the value of other people. And if you emit the slightest Hitler particle, you'll be outright banned. How authoritarian! Honesty, sometimes I wonder why I signed up, never mind stay around.

But then I remember that the folks there are a deeply caring lot, who see the problems in the world and actually want to do something about it—even though the goal often seems barely possible—and, in spite of everything, retain a sense of humour and try to make improvements for each other, even if, for now at least, it can only be a :meow-hug:.

Oh, and the XiBucks, of course. Some of us even get roubles, too!

I don't see them in the app, so not yet, I guess.

I think the assumption is not that adblockers alter the user agent info, but that they also block other resources, so StatCounter won't see those users at all, leading to under-reporting.

The end of "Cogenitor", where Archer blames Trip for the death of Charles.

For someone seemingly so eager to try out new distros, I'm surprised you haven't mentioned virtual machines. If the vibes are off, it's a whole lot less disruptive to find out that way.

Your experience with drivers won't be quite the same as a bare-metal installation, but checking out software shouldn't be a problem.

"Instance" seems too jargon-y to me as well, and "proxy" is even worse. "Server" and "host" are probably a little more familiar, but are still technical language.

Confusion doesn't stem from individual words; people need explanations and examples, but, as an alternative to "instance", if you want to extend the "communities" metaphor, then "society" as a cluster of communities is a natural option, particularly since it relates to the widely understood concept of social media. Since most people using the Internet also know what a web "site" is, you could use the sibilant linguistic association to help cement the notion:—

Each society has its own web site, such as:

• aussie.zone, where the communities relate to Australia;
• programming.dev, where the communities discuss software development;
• and lemmy.film, where the communites are about movies.

You can choose which society you want to join, although some will ask you to fill out an application. Most societies have connections to others, meaning that you can discuss things with people who are part of different societies. Often, you'll recognise them by their username saying that they're at (@) another site. Not all societies get along with one another, so which one you join will also affect who you can talk with.

Each society has its own rules it expects you to follow, whether you are a member of that society or just visiting.

This kind of language seems more intuitive to me anyway, although when I've tried describing instances and federation before now, I've likened instances to countries:—

You choose somewhere to live (and you can move later if you want). If there's a cross-border agreement, then you can send messages back and forth between people in each place.

but this has also meant stressing that your instance "country" doesn't have to match where you physically live, so a more general term probably would have been more useful.

You wrote this ten minutes after being reminded that "consent" by children is nonsense, in what is still the most approved comment.

If you want to be a successful troll, you are going to have to learn to be less obvious. If you want to discuss topics in good faith, you are going to have to learn that this "just asking questions" approach makes you look like a troll.

Take a look at Engineering Mathematics by KA Stroud. It has a step-by-step approach with worked examples that might be useful to you. Even if you don't like the structure, it'll at least give you a comprehensive list of topics.

Admittedly, I have much less experience with i3, so I fired up a virtual machine with Debian 11.6 and installed i3 (along with lightdm) and was able to recreate the problem of .profile not being executed when logging in, so this isn't unique to your particular setup. Great!

Fortunately, this combination does execute commands in ~/.xsessionrc, so I added:—

. $HOME/.profile

to that file, then logged out and back in again. That did the trick for me, with the commands in .profile then successfully modifying the PATH variable (and writing additional lines to the execution log files), so I suggest you try creating/modifying .xsessionrc in the same way.

But those kinds of initialisations belong in .profile (or, if you're using a weird desktop environment, its own configuration file), particularly if you want .desktop files to work. (In .bashrc, PATH will grow longer in each subshell, which shouldn't cause problems but is wasteful.)

So, what desktop environment (GNOME, KDE, Cinnamon, etc.) are you using?

.profile is executed by login shells for the benefit of it and its subshells, and by DEs like Cinnamon for the benefit of .desktop launchers at login.

So, have you logged out and back in again since adding these lines to .profile?

And of course, the .profile has to be executed properly for its configuration to take effect, so it`s useful to know if the problem is with those specific lines, or the file as a whole.

Add:—

date >> ~/profile-execution-log-top.txt
echo $PATH >> ~/profile-execution-log-top.txt

to the top of .profile, and:—

date >> ~/profile-execution-log-end.txt
echo $PATH >> ~/profile-execution-log-end.txt

to the bottom of .profile (use alternative paths as you see fit) to monitor that activity. You can test this by sourcing .profile but the real test is logging out and in again. Look at the time when you do this so you can correlate each action with each timestamp in the log files. If .profile is executed to completion, you should have two files with matching timestamps but different PATHs. If you don't have a matching timestamp in the "end" log file, there's a problem mid-execution. If neither file is being updated, .profile isn't being executed at all.

Are other lines in .profile being executed, or is the whole file ignored? Have you logged out and in again since adding these lines?

The output here lets us know that systemd is running the service file and starting the script just fine. The echoed GPU temperature is making it to the journal, but the gpuTemp variable isn't being updated (staying at 0) because of a problem executing nvidia-settings. Specifically, it wants a display: "The control display is undefined".

You could add a line to the service file:—

Environment = DISPLAY=:0

Although if echo DISPLAY in your terminal gives you a different value, use that. There's a possibility that that will just push one error further down the line, but it's something to try.

Alternatively/additionally, you could try changing the User= line to your own username to see if it picks up the environment your manual executions work with.

You aren't the only one to run into problems trying to automate nvidia-settings. You might end up needing to track down an Xauthority file or use the display manager's initialisation options.

Helping one another out is invisibilized, not rare. A good chunk of what I know comes from other people taking the time to explain why something works the way it does and how you can see that for yourself. The rest is from curiosity, experimentation, and hammering away at something until it fits. It's not professionally specialized knowledge.

If it works when run manually, but fails via systemd, then you should post your service file.

Since .bashrc is executed for all non-login shells, it shouldn't really source .profile, which is only meant for login shells, and might trigger expensive activity. (.profile might source .bashrc, but that`s fine.)