I usually go for gnome regardless of distribution. I have old laptop that i use to try distributions occasionally.
Same hardware, same desktop, same encrypted drive, same BTRFS choice, different responsiveness at times.
Systems heavy on flatpak tend to be noticeably slower.
I had sluggish experience with SUSE. Updates were slow. Installation was very slow.
Starting apps was not as snappy.
Promise of snapshots was great, but not unique.
Overall slower than my regular distro experience killed it for me.
I simply asked myself: will it bug me every time I use the laptop? The answer was yes, and decided to end it.
Installer is a big part.
2nd biggest part is how system is configured.
Debian is not afraid to create its own version of default configuration. Take some mail software as example.
Arch on the other hand is most likely just going to ship original application configuration.
Debian might be nice and easy, until configuration change is necessary. Suddenly, original application documentation doesn’t apply. Debian documentation may be obsolete or absent. And that is the beginning of reading all of the configuration files. Normally, it is not a problem until something like email system configuration is necessary.
That’s when Arch philosophy of making fewest changes to software comes to shine. Original documentation usually works and applies well.
Years ago major upgrades and to lesser degree even minor upgrades made me to give up trying to keep installation running. I don’t even remember if it was Red Hat or Debian.
Eventually I realized, that I like running newest version of Desktop and I ran into cases of getting frustrated with lack of newer versions, which had fixes for issues I ran into. Then I realized that best wiki was not a snapshot distribution.
In the end I tried rolling distribution and remain happy for years.
Debian or derived distribution is easiest to get google help for and it is the simplest choice for me, when running on the cloud.
Although, Alpine is pushing through containers quite forcefully.
KDE was far less stable for me compared to Gnome. In the end, my patience with KDE lasted for 1 week.
KDE is more exiting and familiar, but it had no tangible advantage in the end for me.
If you read comments to the original article, it is far from new idea and some farmers have used for a long time.
I originally meant solution described here:
https://blog.cloudflare.com/using-go-as-a-scripting-language-in-linux/
It called narrative control.
If you think that ActivityPub universe is somehow not biased, not controlled by bots with specific political agenda, that’s your wake up call.
hardlink
Most underrated tool that is frequently installed on your system. It recognizes BTRFS. Be aware that there are multiple versions of it in the wild.
It is unattended.
With requirements like yours, just use RUST itself.
GO language can be used as scripting language on Linux.
I imagine the same approach can be used with RUST.
They don’t want Boeing even for free.
I am surprised that most reliable and more importantly desktop environment independent solution is not as popular here.
I use it with iOS. Owlfiles app supports samba, but I am sure there are others.
I don’t get the question.
I usually use vscode to work with files. It has excellent remote editing over ssh. For example, I have large private collection of markdown notes that is kept on remote server.
At work I deal with large GO project that targets Docker images and my setup is:
My workflow is to start Debian WSL and forget about terminal. Start vscode on windows, connect to Debian over ssh, open project directory. Work on project without ever leaving editor, use built in terminal in vscode. Fish runs inside vscode. Editor is primary. Fish is secondary and it excels at recalling history.
Use each tool for what it was designed. No terminal will ever match my productivity in vscode. Vscode has all the fuzzy search built-in.
I used to use vim for heavy coding, but abandoned that route 20 years ago. I am still able to use vim for quick short changes in config files, but anything serious is handled with visual studio code over ssh.
Primary vim scenario:
sudo vim /etc/config-file-name
Vscode 1st approach is a modern day version of emacs approach Or vim with plugins. Only difference is vscode is actually low effort to get started on new machine, low learning curve, low maintenance effort unless you have sunken months into your terminal editor and refuse to abandon your investment.
Fish is all I need for daily CLI. It is zero customization effort for me. Spend your time on productive side, not fzf your shell history.
https://fishshell.com/docs/current/tutorial.html
Keep bash as default root shell and just start fish manually when using root. It is for cases when linux panics on boot.
Those hoops exist to identify you.
2FA will not keep you anonymous.
Compromised app will share your every detail.
My ASUS laptop runs Linux well. It was around $800 5 years ago, when I bought it.
I am still using it.
There’s so much incompetent advice here.
CPU is fine.
Linux is booting and tries to connect to TPM (trusted platform module).
It has nothing to do with graphics card. Fact it is booting means CPU is most likely likely unaffected.
TPM is most likely fried.
Linux can run without TPM. Plenty of old boards were shipped with TPM socket, but without TPM itself.
Best option is get manual for your motherboard and pull out that TPM.
Any passwords stored there are lost, if you used it.
If TPM is fine, then board pathway to it may be damaged. If that’s the case and you really need it, then board replacement is your option. But that’s only after good TPM was tried.
That’s naive.
US gave the order.
Someone explained it to me this way:
If knife is a newest feature, then
Any snapshot distribution by definition is on bleeding edge.
Any rolling release is by definition on the cutting edge.