dyanaraps

Thanks, I'm glad you find it useful!

Useless use of `cat`. :)

    wc -l file

    wc -l < file

It uses `kitty` terminal's built in support for images. [0][1]

[0] https://sw.kovidgoyal.net/kitty/graphics-protocol.html [1] https://github.com/o2sh/onefetch/blob/master/src/image_backe...

Note: iTerm2 also has its own image display protocol and for something more generic there is Sixel or w3mimgdisplay (from w3m).

It's completely blank (tested in Firefox and Chromium).

This is how I avoid this issue entirely:

    <link href=data:, rel=icon>

This is something I started working on a couple of days ago, I hope you enjoy it!

Not exactly a 1:1 replacement though:

This program requires access to /dev/uinput. This usually requires root permissions.

Source: https://github.com/ReimuNotMoe/ydotool#runtime

Edit: I'll also add that only 5~ commands have been implemented so far in ydotool.

We have quite a few patches in use too.

https://github.com/kisslinux/repo/search?l=Diff

I'll fix this, thanks for letting me know.

Nothing stops a user from packaging and installing these things in KISS, they just aren't included by default.

I envision KISS as a minimal base in which you extend to suit your needs and not something you need to cut to size.

As I state in the Philosophy; "it's easier to add things to a system than it is to remove them".

A user has actually gone ahead and done this! \[1\] They run KISS with systemd, pam, dbus, pulseaudio, glibc, chrome etc etc.

\[1\] https://github.com/fanboimsft/kissD

Yeah, I spent a lot of time ensuring the website would load quickly and I do away with a lot of "optional" cruft.

There's no Javascript full stop, no stylesheets (all CSS is embedded in each page) and every page load is a single web request (with the exception of the screenshots page).

Even the SVG logo is embedded in the pages!

Writing it this way also causes each page to be self contained, a download of the HTML page includes all of the CSS, logo and information so it can easily be saved and viewed locally. :)

The only remark I have regarding code quality is that the word splitting warning is disabled for the entirety of kiss: I would have disabled it on a per-occurence basis.

There are 8 occurrences of word splitting in the source, each and every one is intentional.

I also enable all lint errors when working on the package manager itself (to catch any unintentional word splitting which may slip through my fingers).

The ideal goal is to reduce the word splitting count to zero though! :)

(I'll go ahead and make the change you're suggesting until I do remove all word splitting).

Thanks!

Thanks. :)

You don't need to install another Linux distribution beforehand, you just need to boot another distribution's live-iso to partition disks and download/unpack KISS.

This is simpler on my side as I don't have to compile and package a heavy kernel, generate an initramfs, build a squashfs and finally package it into an ISO image.

On the user side this enables more flexibility too. You can use a live-iso offering a GUI for "easier" partitioning or an iso in which you _know_ includes the firmware you need for the installation process etc.

The download for KISS is only a 45MB~ tarball and the installation is just unpacking it to your newly partitioned disk at `/`!

This also allows for the same installation tarball to double as a working chroot in existing systems. In my eyes, this method is simpler all round.

That's awesome. Glad you're enjoying it.

Thanks :)

You can download the installation tarball, extract it to a directory and use 'chroot' to start tinkering with it. The installation tarball doubles as a working 'chroot' image. :)

https://github.com/kisslinux/repo/releases/tag/1.1.3

Thanks :)

That'd be really nice and it is something I've thought about, the issue is figuring out the _right_ way to do it. Self publishing or perhaps a publisher of programming books?

I can see now that there's a clear interest in a release in physical form. I'll start seriously looking into it. :)

Thanks :)

I'll look into also putting the book on Amazon or another "ebook" website. I chose leanpub as it _is_ for books like this but if it does cause issues for people I'll explore my options on other platforms.

Thanks for letting me know and apologies for the inconvenience.

[OT] Hi Dylan! Just discovered your project - KISS. I respect you a lot for what you write, and you've been an inspiration at times.

Thanks, I appreciate it! :)

Did you just decide one day that you have to write a distribution from scratch?

Pretty much. I'd been distro hopping for some time and wasn't happy with any of the choices in front of me.

I wanted something that could run without `dbus`, `glibc`, `systemd`, `wayland`, `polkit`, `elogind`, etc etc and none of the other distributions could provide this.

Even Gentoo through their arms in the air when Firefox 69 broke the `--disable-dbus` configure flag (and added a mandatory dependency on `dbus`).

I instead spent the hours patching `dbus` out of Firefox 69 and that's how I ship it in KISS. https://github.com/kisslinux/repo/blob/master/extra/firefox/...

What was the thought process

Start from zero and build piece by piece questioning each step along the way. Is this needed? Are there alternatives? Can we do this in a "simpler" way? Step away, come back to it later and ask "was this right?", "can we trim back the fat?".

This repeated until things were effectively "done".

and how complicated is it actually

No piece of software seems to list its (mandatory) dependencies properly so it was a trial and error of figuring out _exactly_ what each piece of software needs.

Looking at other distributions themselves wasn't much help as they list a lot of "optional" dependencies as "required".

There's also no (or very little) documentation online for how to write a package manager or Linux distribution from scratch.

It's been a tedious but rewarding process thus far. I'm talking to you from KISS right now! It feels good to turn on my laptop and be running a distribution I created from scratch. :)

Also, I'd like to contribute if there's a chance.

Go for it! In terms of contribution there's bug reporting, fixing documentation, adding missing packages, fixing bugs in existing packages etc.

Hop on IRC (#kisslinux @ freenode.net) if you'd like to chat. :)

Do you believe bash / POSIX shells actually follow KISS principles?

POSIX `sh` yes. `bash` less so but I'd still lean more towards a yes.

Ultimately though, it depends on how we define "simple". Both `bash` (2.6MB) and POSIX `sh` shells (`dash` (232KB), `ash` (1.2MB (busybox)), etc) are tiny in size if we compare them to Python (137MB) or Perl (44MB).

(Numbers taken from my system using `du` on each file which belongs to each shell/language.)

If we define "simple" to language features then I think the shells come out on top again (especially POSIX `sh`).

If we define "simple" as ease of use (without shooting yourself in the foot) then I'd agree with you and say that the shell loses here.

There's a time and place for using any tool (in production) but I find it fun to push the shell beyond what is thought possible in my personal projects. :)

That's a very very very old GitHub avatar of mine, I wonder why Telegram hasn't pulled a later one.

Thanks!

You can add me to those interested in a pure POSIX shell bible.

I've started working on it here: https://github.com/dylanaraps/pure-sh-bible

are there any bashisms that are truly essential and you don't want to live without?

The only thing I'd say I miss when writing POSIX `sh` is arrays.

I work around this by using 'set -- 1 2 3 4' to mimic an array using the argument list. The limitation here though is that you're limited to one "array" at a time.

The other alternative I make use of is to use "string lists" (list="1 2 3 4") with word splitting.

This can be made safe if the following is correct:

- Globbing is disabled.

- You control the input data and can safely make assumptions (no spaces or new lines in elements).

While it's something that'd be nice to have, there are ways to work around it.

EDIT: One more thing would be "${var:0:1}" to grab individual characters from strings (or ranges of characters from strings).

Have you read Bash Pitfalls[1]?

I've read pretty much everything I could get my hands on regarding the shell (including the mentioned link) and I still love it.

Do you write truly correct Bash/POSIX code?

If we define correct as passing shellcheck, avoiding all pitfalls and maintaining compatibility (POSIX sh not bash), then yes, I like to think so. :)

Do you still love it?

Oh yeah! I've been writing a ton of POSIX sh as of late. My latest project being a Linux distribution: https://getkiss.org/

(hello from Firefox in KISS!)

I've started working on it here: https://github.com/dylanaraps/pure-sh-bible

I've started working on it here: https://github.com/dylanaraps/pure-sh-bible

Off the top of my head, a few notable things I've learned:

- Safely working with "string lists" (list="el el el el").

    - Filtering out duplicate items.

    - Reversing the list.

    - etc.

- Using `set -- el el el` to create an "array" (only one array at a time!).

- `read -r` is still powerful in POSIX `sh` for getting data out of files. `while read -r` even more so.

- POSIX `sh` has `set -e` and friends so you can exit on errors etc.

- Ternary operators still exist for arithmetic (`$(($# > 0 ? 1 : 0))`).

- Each POSIX `sh` shell has a set of quirks you need to account for. What works in one POSIX `sh` shell may not in another. (I found a set of differences between `ash`/`dash` in my testing).

POSIX `sh` is a very simple language compared to `bash` and all of its extensions so there won't be as many snippets but there's some gold to be found.