• 1 Post
  • 12 Comments
Joined 5 years ago
cake
Cake day: April 10th, 2020

help-circle
  • All of these distros strive to solve the problem with having multiple versions of libraries and programs coexisting without conflicts, but Gobo took a different approach. What Gobo doesn’t do is the declarative system configuration. In Nix you don’t need to worry about breaking your system because you can easily restore the previous version of your config. In traditional distros you would need to set up package manager hooks to make snapshots and create snapshots manually every time before changing something in /etc


  • When switching from Windows, it was very confusing to me, that program files where all over the place. It was before (almost) every distro switched to the /usr directory, so it was even worse than it is now. Even now, when I understand more about Linux than before, I still prefer the Windows way.

    I think that this hierarchy is nice for people moving from Windows, but experienced enough that they could understand the docs and tweak the OS.

    I was actually surprised that this distro was designed with more experienced people in mind, I thought it was for beginners.








    • Fish. Much, much saner defaults.
    • I am writing #!/usr/bin/env sh for dead simple scripts, so they will be a tiny bit more portable and run a tiny bit faster. The lack of arrays causes too much pain in longer scripts. I would love to use Fish, but it lacks a strict mode.
    • No, why would I?
    • I used to share all my dotfiles, scripts included, but I was too afraid that I would publish some secrets someday, so I stopped doing that. For synchronizing commands, aliases and other stuff between computers I use Chezmoi.
    • To use Fish instead of fighting with start up time of Zsh with hundreds of plugins
    • Always use the so-called “strict mode” in Bash, that is, the set -euo pipefail line. It will make Bash error on non-zero exit code, undefined variables and non-zero exit codes in commands in pipe. Also, always use shellcheck. It’s extremely easy to make a mistake in Bash. If you want to check the single command exit code manually, just wrap it in set +e and set -e.
    • Consider writing your scripts in Python. Like Bash, it also has some warts, but is multiplatform and easy to read. I have a snippet which contains some boilerplate like a main function definition with ArgumentParser instantiated. Then at the end of the script the main function is called wrapped in try … except KeyboardInterrupt: exit(130) which should be a default behavior.
    • Absolutely not a bad practice. If you need to use them on a remote server and can’t remember what they stand for, you can always execute type some_command. Oh, and read about abbreviations in Fish. It always expands the abbreviation, so you see what you execute.




  • Well, I wouldn’t really say that it’s used as a Windows replacement at the company I’m working at, because all the business stuff is still being done using Windows, but almost all developers are using Linux. I was even allowed to replace Ubuntu with Arch, because I was annoyed by outdated packages. Because of the higher freedom, I can even tolerate the slightly smaller pay rate and benefits that I could earn elsewhere.

    We are mostly working on EDA tooling.