Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Kiss Linux – A distribution with a focus on less is more

k1ss.org

Post reply on HN
Print view View original

81–90 of 145 posts

Re: Kiss Linux – A distribution with a focus on less is more

#81

Post by chriswarbo »

edraferi wrote: post #52
microtonal wrote: post #33

Earlier quoted context omitted.

That's too much of a simplification. In NixOS you still have global configuration files, such as /etc/fstab . However, they are symlinks to Nix store paths that are associated with the current generation. $ realpath /etc/fstab /nix/store/06k708q78zxw8922rrrc8mmp5gbin4am-etc-fstab However, NixOS installations can also end up accumulating configuration and state files that stick around when they are not defined declara…

I’m just getting started with Nix, with the explicit goal of making my entire system defined in a private , remote git repo. I want to be able to rapidly re-provision my entire user environment on a new machine, including applications, preferences, etc. For the moment I’m doing this on MacOS with the nix package manager. I’ll eventually move to NixOS. I tried to run NixOS in VirtualBox, but couldn’t get screen resizi…

> I think I’m supposed to write a custom Nix derivation for ZSH that includes any and all customizations.

Nix supports lots of approaches, with a varying degree of "buy in". I wouldn't say you're "supposed" to do one thing or another, although some things would definitely be non-Pareto-optimal (i.e. you could achieve all the same benefits with fewer downsides).

In the case of .zprofile, I would consider any of the following to be reasonable:

- A normal config file sitting on your machine, edited as needed, not version controlled.

- A symlink to a git repo of configs/dotfiles (this is what I do)

- Directly version-controlling your home dir in some way

- Writing the config content as a string in a Nix file, and having Nix put it in place upon rebuild (I do this with files in /etc)

- Having a Nix 'activation script' which copies/symlinks config files into place (this is what I do, to automate symlinking things to my dotfiles repo)

- Wrapping/overriding the package such that it always loads the desired config (e.g. by replacing the binary with a wrapper which prepends a "use this config" flag).

--

The following has nothing to do with your question, but I felt like ranting about a tangentially-related topic; it's not directed at you ;)

I often see "extremism" when Nix is brought up; e.g. if someone wants help managing non-Python dependencies of their Python app, and someone recommends trying Nix, it's often dismissed along the lines of "I don't have time to throw away my whole setup and start over with the Nix way of doing things, even if were better". The thing is, using Nix can actually be as simple as:

    (import  {}).runCommand "my-app" {} ''
      Put any arbitrary bash commands here
    ''
I often treat Nix like "Make, but with snapshots". Nix 2.0 turned on 'sandboxing' by default, but if you turn that off you can do what you like: add '/usr/bin' to the PATH, 'wget' some arbitrary binaries into '/var', etc. You won't get the benefits of deterministic builds, rollbacks, concurrent versions, etc. but those don't matter if the prior method didn't have them either. Projects like Nixpkgs, and the experimental things people write about on their blogs, aren't the only way to do things; you don't have to throw the baby out with the bathwater.

Re: Kiss Linux – A distribution with a focus on less is more

#82

Post by enriquto »

skookum-skuad wrote: post #58
danielscrubs wrote: post #13

I loved the idea (git everything!) until I read this: "How do I remove a package and all of its dependencies? [...] The package manager does not do recursive dependency removal on removal of a package. This error-prone automation will not be added to the package manager. "

Yuck. The only way out of dependency hell is to disallow it by allowing multiple versions/different configurations of side-by-side packages and GCing non-leaf packages. This pattern of "only one global package for everything" is failure. Too often, naïve designers will just cut things because they just don't understand them or copy & paste because they don't understand what failures exist and what solutions do/altern…

> The only way out of dependency hell is to disallow it by allowing multiple versions/different configurations of side-by-side packages (...)

Another elegant way, for a more civilized time, is to simply disallow dependencies. If none of your packages has any dependencies, then no dependency hell is ever possible. This is possible and easy with static executables (for binary packages), and by embedding the interpreter of packages written in scripting languages.

Re: Kiss Linux – A distribution with a focus on less is more

#83

Post by ragnese »

Kototama wrote: post #30
rwnspace wrote: post #29

Earlier quoted context omitted.

Could you explain more re: bugs? Dylan Araps sort of specialises in well-written (ba)sh and iirc uses shellcheck meticulously. I ask not to be combative in case you're just making a casual joke - more I'd like understand how bugs might creep in to (ba)sh code - even if say, one follows shellcheck and is as competent as Dylan.

I saw that after posting. It's not a critic of Dylan's work, more a critic of how difficult it is to write good bash code. Your comment on shellcheck and Dylan expertise just confirm it. It's like C, you could write safe C but it's very difficult. I wish there was a language with the ubiquity of Bash but modern and safe.

Honestly, PHP is a decent scripting language. It's pretty fast with text processing and you can choose to play fast-and-loose or go in a more type-checked direction.

It's basically my least favorite language for "real" programs, but I think it could find a niche for scripting in the middle of the spectrum between (ba)sh and python.

Re: Kiss Linux – A distribution with a focus on less is more

#84

Post by CameronNemo »

nerdponx wrote: post #31
pampa wrote: post #18

Earlier quoted context omitted.

This might seem like a limitation. But you can provide a base system with a toolchain & xorg with known dependencies and a limited set of packages (like a BSD base system). Then for every big and complex app clone that base system and build the app in a chroot/sandbox or container. That way you get the app and dont pollute the base system and uninstalling is just rm -rf On every distro uninstalling packages never rea…

Apt autoremove seems to do a pretty decent job.

especially when you pass --purge

Re: Kiss Linux – A distribution with a focus on less is more

#85

Post by catern »

enriquto wrote: post #82
skookum-skuad wrote: post #58

Earlier quoted context omitted.

Yuck. The only way out of dependency hell is to disallow it by allowing multiple versions/different configurations of side-by-side packages and GCing non-leaf packages. This pattern of "only one global package for everything" is failure. Too often, naïve designers will just cut things because they just don't understand them or copy & paste because they don't understand what failures exist and what solutions do/altern…

> The only way out of dependency hell is to disallow it by allowing multiple versions/different configurations of side-by-side packages (...) Another elegant way, for a more civilized time, is to simply disallow dependencies. If none of your packages has any dependencies, then no dependency hell is ever possible. This is possible and easy with static executables (for binary packages), and by embedding the interpreter…

Static binaries still have dependencies, they just embed them all into one file. That's not generically possible - as the most trivial example, consider a bash script which runs other executables. If you're trying to solve this problem, you need to actually solve it for all real cases; otherwise your solution breaks down and you're back where you started, in dependency hell.

Re: Kiss Linux – A distribution with a focus on less is more

#86

Post by efiecho »

letientai299 wrote: post #43

* Based on musl libc, busybox and the Linux kernel. As some one who is working on Go ecosystem, this drops my interesting immediately. Using musl libs means a lot of tools can't be used on this OS unless we install the glibc.

In the past I have developed in Go on musl systems without problems, so unless something has changed, this should still not be a problem at all.

Re: Kiss Linux – A distribution with a focus on less is more

#87

Post by arghwhat »

norswap wrote: post #77
arghwhat wrote: post #61

1000 lines of shell is about 900 lines too many for "simple".

As opposed to? This just sounds like dumb shell hate. I personally would have used another language, but shell ain't that hard if you have some experience with it, and are using shellcheck as the author does. The config formats of the distro are optimized for command line tools, and writing the package manager in shell seems like a good way to ensure that this is indeed the case - basic dogfooding.

As opposed to programming languages with constructs that allow proper code hygiene. That implies an actual type system, a usable standard library, etc.

Shell is great for scripting usage of other programs, far better than other programming languages. That's what it's made for, after all. It's the only thing it's made for.

Re: Kiss Linux – A distribution with a focus on less is more

#88

Post by arghwhat »

jedahan wrote: post #68
arghwhat wrote: post #61

1000 lines of shell is about 900 lines too many for "simple".

Compared to any other package manager source I've dug into, I haven't found simpler.

If you're comparing line counts remember that this one is vastly incomplete in comparison.

Re: Kiss Linux – A distribution with a focus on less is more

#89

Post by stutonk »

goldenkey wrote: post #72
stutonk wrote: post #48

Earlier quoted context omitted.

Linux, at least, has rename(1) where you can just use the same syntax as Windows ren.

I know about that utility -- still not shell though. The fact that you need a utility to make such a simple task readable is pointing to the shell language lacking.

By your own logic, your own UNIX solution to the file renaming problem is "not shell" since it uses the mv "utility". Or do you mean rename is not POSIX? The shell language certainly is lacking for almost anything beyond its original purpose of gluing together pipelines/graphs of UNIX commands; it's a largely unintentional DSL from the time before many modern notions of language ergonomics had become established. The point is, there is an array of solutions to reduce the nuisance of having to deal with the language equivalent of a stone knife such as programs like rename or actual general-purpose scripting languages. Sure, you can cut most things with a stone knife with enough time and effort but why would you if you have a bunch of sharp, metal knives within easy reach?
Post reply on HN