Take snapshot. If problem occurs, manually change boot label to use snapshot label.
Take snapshot. If problem occurs, manually change boot label to use snapshot label.
BTRFS is zero effort on root, because it is included in kernel. ZFS on root is extra effort at least on Arch, due to licensing restrictions.
Dedicated gaming machine or dual boot is a way to go.
I played steam on Arch and one update of OS and game stops working.
Despite claims, Windows gets better outcomes. I played a lot of World of Tanks Blitz and the same hardware on Linux was significantly lower graphics quality and FPS compared to Windows.
Windows is better for gaming than Linux.
With Linux you have to be ready to play only what works.
Great illustration.
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.
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.
I originally meant solution described here:
https://blog.cloudflare.com/using-go-as-a-scripting-language-in-linux/
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.
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.
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.
When i tried it 6 months ago I didn’t like how UI apps took more time to start. Then I realized it is all flatpak or similar. Package management was slow. Installation process took very long time. I assume it tried to auto detect my hardware.
And went back to Arch.
SUSE Feature set is the best.
Preference order is: Fast IO like SSD and mirror RAID, then RAM size, then core count and then core speed.
This is not RUST specific.