To point it out for folks unfamiliar with Rust, I consider this comment borderline misinformation.
I don’t know in what world the Rust compiler is considered unreliable. In my experience, it is one of the most reliable toolchains across all programming languages.
The Rust compiler is slow, because it does so many more checks than the C compiler, which is what these devs want. This is also barely relevant while actually developing, because then incremental compilation kicks in, which makes subsequent builds rather quick.
And Rust binaries are primarily larger than C binaries, because it does not use dynamic linking of dependencies. In the kernel, you cannot use dynamic linking anyways, because you need a running kernel to have a filesystem from which to dynamically load these.

Linus has also declared Rust as basically inevitable before, since more and more kernel maintainers retire and not many young devs learn C anymore, at least not to a proficiency where you can handle kernel development.

You mean Gitea? Forgejo is a fork from it, maintained by a non-profit, so preferrable to most folks.

At $DAYJOB, we’re currently setting up basically a way to bridge an interface over the internet, so it transports everything that enters on an interface across the aether. Well, and you already guessed it, I accidentally configured it for eth0 and couldn’t SSH in anymore.

Where it becomes fun, is that I actually was at work. I was setting it up on two raspis, which were connected to a router, everything placed right next to me. So, I figured, I’d just hook up another Ethernet cable, pick out the IP from the router’s management interface and SSH in that way.
Except I couldn’t reach the management interface anymore. Nothing in that network would respond.

Eventually, I saw that the router’s activity lights were blinking like Christmas decoration. I’m guessing, I had built a loop and therefore something akin to a broadcast storm was overloading the router. Thankfully, the solution was then relatively straightforward, in that I had to unplug one of the raspis, SSH in via the second port, nuke our configuration and then repeat for the other raspi.

They are working on a new touch keyboard: https://invent.kde.org/plasma/plasma-keyboard
But yeah, no idea when it’ll be ready.

(Other than things like locked down smart phone bootloaders, but that’s got nothing to do with the FOSS part of this discussion.)

See, I disagree on that. If I know something I could (help to) build will only ever be used by a few folks and can never help most people, then my motivation is significantly lowered. Well, unless I’m truly just scratching my own itch, but even then I might choose to not scratch my itch, because I’d rather quit using the platform, if possible.

And then, yeah, what the other person said about financing.

For Android, there are various small efforts in terms of forks, with the biggest being LineageOS. There are even some commercial efforts, like /e/OS. I think, Huawei also wanted to do a fork or something. No idea what happened with that.
But yeah, none of these efforts are hard forks, which can change more than superficial stuff. And it’s not for a lack of desire, but because it’s just such a ridiculous uphill battle to try to get anything noteworthy changed. Many times, LineageOS (and its predecessor CyanogenMod) had some cool features, which they later had to scrap, because they needed to follow what Google was doing and their features wouldn’t work with that anymore. If they would’ve seen any chance of a hard fork working out, they probably would’ve tried to go that route.

Personally, I’m at the point where I try to only use community-developed software. I’ve seen it too often that even projects which are nominally open-source start becoming cunts…

Android, Chromium.

The problem is that:

1. Google puts in more development power than anyone else. Any forks we’ve seen so far are only really soft forks, as in they only apply a few patches on top of what Google puts out, rather than taking the project in a new direction, because you’d be behind pretty quickly.
2. These projects establish platforms that have shitty decisions baked in. For example, the Android dev tooling has Google ads/tracking as one of the built-in UI components, which is why even if you patch the OS, the apps will still be shitty. To actually change this stuff, you’d need a majority of users to switch to your fork and stay there for a few years.
3. Partially, it’s only financially viable for Google to develop these projects, because they have those Android ads or benefit from a web with less tracking protection. This makes it extremely unlikely for any other organization to be able to splurge a similar amount of money, which brings us back to a fork just being unlikely.

And so long as a fork is unlikely, Google can do shitfuckery quite similar to proprietary projects.

Puppy Linux is what I usually see recommended for such low specs. It’s also available with a Debian base.

https://puppylinux-woof-ce.github.io/

Yeah, Python requires a “runtime” program, which interprets the Python code and then translates it into native machine code to actually execute it. Because Rust is compiled directly to native machine code by the developer, you don’t need a runtime program on your PC to run Rust programs.

This is also one of the biggest reasons why Rust can be used for kernel development. You cannot rely on a runtime program for developing a kernel, since launching a program requires a kernel to already be up and running.

Hmm, I don’t have experience with hosting Forgejo, but my intuition tells me that because it has relatively many features, that its administration is more involved than if you only host a Git Server.

You could then use a static site generator to turn your MD-files into a webpage. Personally, I have a (still very small) knowledge base webpage using mdBook, mostly because I was already familiar with it, but it’s also pretty simple to setup and has a built-in search.

I’ve got basically the bspwm workflow, but on KDE.

So, bspwm has tiling of windows and doesn’t want you to minimize (nowadays, it actually has a minimize-feature, but back when I last used it, it didn’t). As a result, if a window is open, it is visible on some workspace. If you want to hide windows, put them on a different workspace.
I like that workflow, because while it probably seems complex when you first hear about it, it actually simplifies things. When you’re looking for a window, you don’t have to check all the workspaces and minimized windows and behind other windows.

KDE adds to that, in that I can have a workspace overview in my panel, so where I can see all workspaces with the windows that are visible on them (which with this workflow is all windows on that workspace). I like to call it my minimap.
It makes the workflow a lot easier to use, but it also allows me to group workspaces by location. So, if I’m working on a topic, I often have a Firefox window on one workspace, my text editor on the workspace below and then a terminal on the workspace below that. If I then realize, I need to quickly look up something for a related topic, I’ll open up a new Firefox window two workspaces below that (leaving an empty workspace as separator). If I do something completely different, I might leave a whole bunch of empty workspaces in between. Or, well, KDE actually allows grouping workspaces with a feature called “Activities”, so I’ll often switch Activities.

I find that works a lot better for multi-tasking than the traditional Windows workflow of one window per application, with all kinds of different topics mixed into all kinds of ungrouped windows. If I switch between topics, I just go to the right location on my minimap and I’ve all the topic-related information in the windows that are there.

Oh, so LibreOffice is actually a fork of OpenOffice, meaning back in 2010, the devs copied the code from OpenOffice and have been developing it further from there. So, it’s like your parents just got upgraded to the newest edition of the office suite they were using. A lot of it should still be familiar to them.

Basically, the devs had to change the name for legal/political reasons. In all other ways, LibreOffice is the continuation of OpenOffice.

OpenOffice

Most Linux distros come with LibreOffice pre-installed. That’s what you want. OpenOffice pretty much stopped being developed in 2010 and the developers moved over to LibreOffice.

Nope, I’m glad to share.

I personalized it from the “Gruvbox Rainbow” preset from here: https://starship.rs/presets/
So, you might prefer that, if you’re not, well, me.

You will need to set up a NerdFont, like the Starship installation guide says.

Here’s my configuration:

"$schema" = 'https://starship.rs/config-schema.json'

format = """
[$status](bg:color_red fg:color_fg0)\
[](fg:color_red bg:color_orange)\
[$cmd_duration](bg:color_orange fg:color_fg0)\
[](fg:color_orange bg:color_yellow)\
[$time](bg:color_yellow fg:color_fg0)\
[](fg:color_yellow)\
$line_break\
[$directory](bg:color_aqua fg:color_fg0)\
[](fg:color_aqua bg:color_blue)\
[$git_branch\
$git_status](bg:color_blue fg:color_fg0)\
[](fg:color_blue bg:color_bg3)\
[$c\
$rust\
$golang\
$nodejs\
$php\
$java\
$kotlin\
$haskell\
$python\
$docker_context](bg:color_bg3 fg:color_fg0)\
[](fg:color_bg3)\
$line_break\
$line_break"""

palette = 'gruvbox_dark'

[palettes.gruvbox_dark]
color_fg0 = '#ffffff'
color_bg1 = '#3c3836'
color_bg3 = '#665c54'
color_blue = '#458588'
color_aqua = '#689d6a'
color_green = '#98971a'
color_orange = '#d65d0e'
color_purple = '#b16286'
color_red = '#cc241d'
color_yellow = '#d79921'

[status]
disabled = false
symbol = ""
format = ' $symbol $status '

[username]
format = ' $user '

[directory]
format = " $path "
truncation_length = 3
truncation_symbol = "…/"

[directory.substitutions]
"Documents" = "󰈙 "
"Downloads" = " "
"Music" = "󰝚 "
"Pictures" = " "
"Projects" = "󰲋 "

[git_branch]
symbol = ""
format = ' $symbol $branch '

[git_status]
style = "bg:color_aqua"
format = '$all_status$ahead_behind '

[nodejs]
symbol = ""
format = ' $symbol $version '

[c]
symbol = " "
format = ' $symbol $version '

[rust]
symbol = ""
format = ' $symbol $version '

[golang]
symbol = ""
format = ' $symbol $version '

[php]
symbol = ""
format = ' $symbol $version '

[java]
symbol = " "
format = ' $symbol $version '

[kotlin]
symbol = ""
format = ' $symbol $version '

[haskell]
symbol = ""
format = ' $symbol $version '

[python]
symbol = ""
format = ' $symbol $version '

[cmd_duration]
format = ' 󱦟 $duration '

[time]
disabled = false
time_format = "%R"
format = '  $time '

[line_break]
disabled = false

It automatically suggests commands, you’ve run before, if you start typing the first letters, like so:

You can also press the Up-Arrow at any point to show other commands from your history which contain the text that you just typed.

So, it is similar to Ctrl+R in Bash, but easier to use and you don’t have to actively think about it.

Oh, when you’re coding something in a Git repo and you realize that you need to make a different change before you continue coding (e.g. switch to a branch, pull newest changes, or just create a separate smaller commit for part of your change), then you can run git stash push to put away your current changes, then make your other change, and then run git stash pop to bring your ongoing changes back. I recommend reading git stash --help, if you want to use it.

Sometimes, though, you might end up just taking it into a different direction altogether or simply forget that you had something stashed. That’s when that indicator comes in handy. Because while you can have multiple things stashed, I do find it’s best not to keep them around for too long. If you do want to keep them for longer, then you can always create a branch and commit it as WIP onto there, so that you can push it onto a remote repo.

Yep, here’s my Starship prompt, for example:

So, I have it configured to show:

• the exit code of the last command (if it’s non-zero),
• the duration of the last command (if it’s longer than 2 seconds),
• the time (when the last command ended),
• the current directory,
• the current Git branch, and it also shows some Git status information, for example the $ means I have something stashed,
• and finally the technology in use in a repository/directory, so in this case that repo uses Rust and the compiler version is 1.83.

Well, I’m talking about my team members at my dayjob. I’m a software engineer.

But it’s also a lot less explicit than what you’re probably imagining. It’s rather that we have a meeting and realize that a problem re-occurred which we thought we solved months ago. So, then everyone starts collectively scratching their head and somewhat rhetoric questions might be thrown into the room, i.e. “Oh man, do you still remember how we did that?”.

Then I might start typing the command how I think it would probably begin, often with the intention of then putting --help at the end to try to jump-start my memory. And then that’s where Fish often jumps in and tells me that I’m apparently typing the exact beginning letters of the command that we used a few months ago.
Sometimes this even happens when I have no recollection that I ran a given command before, and someone’s just generally asking how to do a certain task…

I just set Fish as the shell that my terminal emulator should launch. The actual default/system shell can stay Bash. And then, yeah, if you put Bash into the shebang, all the scripts will run with it, and you can just execute bash in your Fish shell at any point to drop into a Bash shell.

Occasionally, I’ll realize some syntax discrepancy where I’ve kind of learned it the Fish way, but because I’m only using Fish interactively, there’s really not a ton of syntax that I’m interacting with.

And yeah, ultimately I find it well worth it. In particular the history-based auto-suggestions are really useful. People will ask me what that command was again and I’ll start typing into my shell and it just pulls out exactly what I wanted in quite a lot of cases.