Kiss – A Linux distribution with a focus on “less is more”
getkiss.org
getkiss.org
Go install windows and be happy in your mono culture world, but don't shit on other peoples creativity and effort.
I'm not making a value judgment as to whether or not I should know how to compile source code and running this on top of another Linux and so fort, but I can intuit my way through installing Debian or Manjaro or Arch Linux or knoppix or any other distro that provides a binary ISO.
It seems like this is simple in terms of 'lightweight for linux pros', not simple as in 'intuitive for users to use'.
I'm not sure that's a bad thing, just pointing out that I am unable to try this with my current skill level
> A user without prior knowledge may see this distribution as the exact opposite.
It's simple in the terms of that an experienced person can easily understand how it works in many details. Not that an unexperienced person could use it easily. It's like a Ford T. Simple to build and repair for an old school mechanic. Probably not user friendly for the average driver today.
That's a common problem with declaring things "simple", and not only for Linux distros.
What's simple in implementation (lightweight and straight to the point) may not be simple for an uninitiated user.
How do you launch a wayland server and how do you forward "display" (ssh -X or -Y) to launch a remote application ?
I am lacking a proper analogy here, but it isn't because something is old, and most people are accustomed to its quirks, that it is simple... Maybe Apache, PHP, or even IPv6 would be a better comparison? IPv6 is likely a very good analogy here.
Now, Xorg's "security" model is well understood, just like its security issues. xorg.conf itself is a configuration nightmare. You might be able to launch the X server with a simple command line, but that's just hiding complexity behind a command. I can do the same with sway.
Wayland is quite modular itself. You can probably use namespaces to restrict one app's access to the clipboard, if that's not a feature the compositor supports, for instance.
For network "transparency" under wayland, which is an argument X proponents often cling to (it has its merits, but was counterproductive for most apps), it is a matter of serializing the protocol+image data (that's normally sent trough shared memory), and deserializing it at the other end. That's basically what waypipe [0] is doing, trough Unix sockets. So Wayland can be used remotely over anything that supports Unix sockets, thanks to waypipe, that plays the role of a compositor proxy.
A lot more things are possible due to Wayland being properly specified. The first and most important being multiple, interoperable implementations. Just like the TCP or HTTP stack. That is a Good Thing™ in my opinion. Zero-copy is also simpler to achieve, as another example.
I am sorry if I sound condescending about network transparency for instance. But that was pointed out for so long, and it is even written in Wayland's FAQ. The only reason it was that slow to materialize is Wayland's slow adoption. Which might be in part due to people complaining about stuff like network transparency without understanding it, and making themselves impervious to reasoning, while actually undermining efforts to bootstrap the ecosystem.
> How do you launch a wayland server
A compositor that displays stuff that applications send it? Well, you just execute it. Then that compositor decides to merge that stuff together, or pick some of it, and displays it where it wants: waypipe sends it to a socket, traditional wayland compositors can render on a connected screen trough the DRI kernel interface, others such as sway can even pass the rendered data to an X server or wayland compositor.
> thanks to a single environment variable (DISPLAY)
Use WAYLAND_DISPLAY to specify a Unix socket, if supported[1]. I'll admit that I am a bit in a learning phase, so I don't yet understand everything about the various subtleties (I couldn't use that to start an app from one TTY on another).
So, this distro sounds interesting on paper, but I can't really justify this choice of their, and I am probably not going to use it unless their revise their position. Wayland really needs a bit of forced adoption, like IPv6, if we want to have nice things.
[0]: https://gitlab.freedesktop.org/mstoeckl/waypipe
[1]: https://wayland.freedesktop.org/docs/html/ch04.html#sect-Pro...
Also for all practical purposes with Wayland you also need XWayland, which means that you get X anyway (especially considering that a lot of simple stuff will rely on X functionality). So might as well stick with X itself and get rid of Wayland as it doesn't provide anything of real value.
(Speaking as someone who just switched to Sway two weeks ago.)
In comparison, Windows Vista introduced a perfectly functional compositor with brand new driver model at about the same time and I can't think of any significant functionality it lost in the process, while I can name many significant improvements.
Hardware acceleration for 2D operations (GDI)
You cannot completely remove X anyway, so using Wayland inevitably introduces much compatibility headache. Just sticking with X is the simples and KISS way to get GUI for now.
If it's by some ways a Rorschach case (doubt it), then it fails again as a logo, which should be clear and concise and aligned with the product. If no such alignment can be done graphically, then a text oriented logo would be far better.
I've been doing branding for a big part of my life, consider taking the suggestions from the other commentators as well in revising the logo if this is to be a serious endeavor; think of the various cultures and settings this would be seen.
The only part I find questionable is the use of tools written in shell. Shell is a very difficult language to understand and use correctly. To the credit of the author, he is aware of this and the code is linted using shellcheck. Still, I wonder if it wouldn't have been a better idea to write the utilities using Python or Lua or even (gasp) C! (Or Rust, or Go or ... Just pick one that isn't completely esoteric and isn't Perl, then stick to it.)
Python is far too much overhead for something as simple as firing shell (!!) commands and dumping new files in a tar archive.
And also, shell is extensible in the most simple way: you just write a program name, and boom, it runs.
Shell is simple, stable (remember the debacle of Python 2->3?), safe (no pointers, etc.), readable (compiling can even introduce issues), and dangerous only if you do it seriously wrong[0].
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.
[0] https://github.com/valvesoftware/steam-for-linux/issues/3671
PS: the most secure open-source OS out there has a package manager written in perl, with priv-sep (https://github.com/openbsd/src/tree/master/usr.sbin/pkg_add).
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).
[1] - https://github.com/koalaman/shellcheck
[2] - https://www.shellcheck.net/
ShellCheck is in many of the distro package repositories already.
Edit: that's a yes. Because apparently that isn't obvious to some folks around here
I think there is a strong arguement for objectifying, but still think it's more "sexual" than "objectifying", and definitely those two way more than it's "sexist".
Sexism is discrimination based on sex. Discrimination is different treatment based on a characteristic.
[1]https://www.theatlantic.com/notes/all/2016/10/the-sexism-of-...
First is that the woman's pose derives from images of 'feeble' femininity (e.g. old Marilyn Monroe films; sexy, innocent, willing). I don't think there's any need to hark back to such absurd stereotypes.
Second, it assumes my preferred aesthetic isn't, for example, big bearded men. They are equally capable of giving or blowing a kiss. The logo could have been more generic, if it was appealing to the intimate.
Third, I don't really like sexualised or intimate imagery mixed with productivity tools. It's jarring and distracting.
At the end of the day, it's just a logo, though it made me switch off.
Yes, it's a stereotype, but not an arbitrary one - and no less absurd than a bearded man blowing a kiss.
Or maybe it's just a silly logo that's not worth deconstructing.
[1] https://thewondrous.com/wp-content/uploads/2013/12/Pinup-Art...
Note also how there is black below it as it wraps around to the back. If all that black space were her right arm, it would have a bump in the middle, and she would hold it in a very awkward position with the hand wrapping around to her back below her left arm. Seems less likely to me.
The black below is her arm from the elbow to the hand. The hand is just at the bottom right of the image with the line going in a /| shape right below the elbow of the left (right as we see it) arm. The tip is the fingers. They look a bit too long but i think it is mainly due to the line width.
The anatomy could have been better (the neck is a bit too long, the left shoulder is a bit too rotated, the left upper arm is a bit too short) and a couple of lines are too long that can be distracting, but overall it is very obvious to me that this is a pose with a tilted head, right arm on stomach and below breasts touching the side/back, left arm rotated a bit forward, on top of second arm with a slight angle in the elbow.
I mean, it could be a bikini but it also could be a dress like in all the images i linked at. There is not enough detail to say one way or another, the only hint is that the image is inspired by 40s pinup posters and at least from a Google Images search one or two had girls wear just a bra or bikini. All others use full clothes and dresses.
[1] https://muscleheaded.files.wordpress.com/2015/11/frahm.jpg
[2] https://www.ebay.com/itm/1940s-Pin-Up-Girl-Glamour-Shot-Pict...
This logo has nothing to do with Linux, nor with kissing (you can't even see lips because the face is cut off to put the cleavage in the focus). It's only about transporting and reinforcing the idea that one of the main roles of women in society is to be something pretty for men to look at. Always, everywhere, without any context. Oh, and you know what's prettier that a nerdy woman with glasses and a hoodie? A woman wearing a bikini! Because we can.
And it does not have to! Look at the logo of other distributions, what do they have to do with Linux, other than being the logo of a Linux distribution? Sigh.
> It's only about transporting and reinforcing the idea that one of the main roles of women in society is to be something pretty for men to look at.
No, this is only what YOU BELIEVE it means. I did not think about that at all, it is just your own interpretation (that may be shared with other people). You see what you want to see, it does not make it so.
They all have to do with the name of the distribution: Red Hat has a red hat, Alpine has the Alps, Ubuntu (a term having to do with solidarity) has people holding hands.
Kiss doesn't have a logo that shows kissing or lips. It has disembodied boobs.
Again: If Kiss had a stove as its logo, or diapers, or a half empty box of chocolates, someone would post here "that's a strange logo for something called Kiss", and you would probably more likely upvote them than bother to argue against them. Only sexualized women are always considered appropriate by some people, completely without any context.
Plus, KISS is an abbreviation, it does not refer to the word "kiss".
> someone would post here "that's a strange logo", and you would probably more likely upvote them than bother to argue against them.
No, I would just ignore them, and I am not interested in arguing about taste either.
> You are making my point for me: Objectification of women has a special protected status in society.
Holy shit... OK. I hope you do realize that you came to this conclusion by a false assumption, see above. I am only reacting to your statements, if defending it is a side-effect, so be it, I do not give a damn. But you thinking that it has to do with "objectification of women" is quite a tell of YOUR BELIEFS, not mine. It is what you see, it is your interpretation, it has nothing to do with me. I will not respond to any of your future comments.
Saving you some time in The Gimp, you can look at the logo on the Microsoft Github page, where the colors are inverted compared to the website: https://github.com/kisslinux/
https://lists.freebsd.org/pipermail/freebsd-chat/2011-Novemb...
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. :)
I'm not a language hipster, I don't care what language you write something in as long as it fits the purpose well, and shell can certainly do that here. However, some uses of shell in the package manager are non-obvious, and that will make it more difficult for people to troubleshoot or maintain this code.
@OP: I imagine you've examined Slackware's pkgtools? (https://slackware.osuosl.org/slackware-12.1/source/a/pkgtool...) They're written in shell too, and have been in use since 1994. I wish they would get a bit more updated to do things like read metadata (especially for Slackbuilds) and handle build dependencies, but I always found them pretty easy to understand and modify to my needs. Later I threw together some scripts to automate the most common configure/make/make install/packaging steps (https://github.com/psypete/public-bin/tree/public-bin/src/sl...). My scripting experience was, let's say... "limited". :)
I ended up making a couple thousand packages from tarballs. What that taught me was that actually managing build dependencies, and the complications of layering different software into the same file tree, was a lot more weird than it seemed. So depending on people's intentions with this distro, it may end up being a lot more complicated for them to manage than they think.
I had idea about installing a local Prometheus agent, cockpit and other modern administration tools, but it could'nt match all the features of Gnome 3. Especially, I couldn't find a webtool to manage hardware, such as Wifi, keyboard configuration, display, mouse, etc. Also, a very good, fast, and stable web terminal isnt easy to find
EDIT: Maybe XPenology can run the DSM web interface on a desktop OS?
EDIT 2: Most of KDE Plasma (well, the QML parts at least) will probably run through the WebGL streaming QPA. Likewise using Broadway for Gnome GTK3 apps.
If at some point we can run classical Gnome apps in the Browser, I guess it could be a solution. I would prefer to have only one "way" of presenting information, based on web standards.
Furthermore, for a web based terminal, thanks to https://xtermjs.org/, terminal.js and friends, there are plenty of products available nowadays. Maybe this helps for starting a web search.
I aslo tried ajenti.org but same issue, I couldn't even manage wifi with it.
I will maybe make something myself. Maybe something that can take any linux tools in input and make a primitive web interface for it as output automatically.
Of course, similar as to when configuring a router, don't lock out yourself from the wifi-connected machine ;-)
I like the idea of Google Chrome OS, but I would like to be free to chose the web browser I want.
To me that's an argument for why you'd want to do less in the browser, not more.
> I prefer to have everything done in the web browser rather than having another complex graphic framework running in parallel.
Do you have any technical reason you want that? Because a terminal interface, for example, is going to be much more efficient in terms of resource usage if it's implemented natively rather than in a webview.
FWIW, personally i like it (though i'd put a frame around it to emphasize the pinup poster girl style) and find it more artistic than most meaningless abstract shapes other projects use.
A pair of tits isn't "artistic".
Is there something that the Kiss distro achieves that Arch doesn't?
One concern I would have though is that it seems their package manager does not currently have any way to include patches to packages (or if it does, it's not mentioned in the documentation). This can make it hard to port things if they require even minor tweaks to build properly.
https://getkiss.org/pages/package-system/ mentions patches. There is a section on patches alone with an example.
I used to like Xubuntu, but this was like a decade ago at this point.
Design choices:
* Rolling release
* Custom package manager: XBPS with binary package repository. It's pretty darn good IMHO.
* Minimal init process: runit
* LibreSSL (vs OpenSSL)
* User can choose standard library: Glibc or musl
* Prefer dash over bash in system scripts
You get the drift. The biggest change to a user is probably the use of XBPS as a package manager. The repository of pre-compiled binaries is pretty extensive, and the package definition scripts are dead simple. The entire collection of package definitions is in a repo on GitHub, so sharing your package definitions is also quite painless.
Their IRC channel on freenode (#voidlinux) is also pretty active with lots of knowledgeable and helpful people.
After that, you’re basically in arch land, which is an excellent no-frills stripped back experience, with an unrivaled user-created package repository. Seriously, every time I have to install something on Ubuntu it drives me crazy to have to use whatever out-dated stuff they have in the repos, or to go hunting for a PPA. With arch it’s one command to install almost anything (assuming you’re using pikaur or the like for installing from the arch user repository).
I am often surprised at what’s available on AUR — my most recent discovery being a current version of dwarf fortress, which is kind of a huge pain to get working on Linux.
While regular Ubuntu switched back and forth between Gnome→Unity→Gnome, my Xubuntu install looks and works pretty much the same, except with less bugs than before, and even some new features that don't get in your way (e.g. better hidpi/color management support). At the same time you have first-class access to Debian packages, so you don't have to feel left out in that way.
It’s not a great choice for desktops, but as a server it’s pretty cool.
Unfortunately I can't see a reason to use this over Alpine Linux, which is also quite simple and minimal and has been around for a while and works fantastically well.
Even though I've been using Linux (Ubuntu) as my daily driver for the past several years, I really son't know too much about it such as how to ask the right question about desktop manager(?). The install instructions look detailed enough that I could probably figure it out. I will bookmark this, because I want to buy a laptop, amd it might be interesting to try to build/install this as an experiment first.
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.
So the project is an arbitrary reduction of scope and then writing the implementation just for that scope.
Imho, the issue is not that the solutions are complex but the problems we (assume we) need to solve are. Just making simple solutions that ignore the bigger problems underneath do not really help in the end.
That doesn't make the original system any simpler or more complex.
Here's two examples of how distros patching software has been helpful for me.
1) SquirrelMail (abandoned) patched to work with PHP 7.3 thanks to FreeBSD contribs
2) Abiword patch builds in the AUR that fix a broken default install.
I'd rather see that useful changes are merged upstream, or projects are forked. If this had happened, you wouldn't even need to patch, and this would save an enormous amount of manpower that is wasted on trivialities.
- Debian and *buntu - Red Hat - Fedora - Suse
All of them use systemd. All use X11 or wayland. All package gnome. All DEs, WMs etc. are available on all these distros.
Smaller distros can reuse whatever is available for that distros, see for example chrome or skype.
But regardless, I agree, fragmentation isn't really a problem. It would be very rare indeed for some software to only work on some distro but not another. And if this was the case, you could probably change it with enough work (swap out libc or whatever).
https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=googl...
Google only packages chrome as .deb and .rpm, but you can still get it on other distros anyways.
EDIT: source - been doing Linux for corporates, big and small since 1999.
The main problem with Linux adoption isn't choice - every beginner can easily find out a reasonable distro for starting out - but motivation to do the switch in the first place. Almost nobody is used to Linux and doesn't know a reason to try it. Even limiting the choice to one single distro isn't going to change that.
People's computers are like their cars we like to customize and mod them because it's cool and remember, you own it so it gives a sense of pride.
There was a glimmer of hope at the start when the focus was on just getting the full free software stack working. But then it went back to making near-exact copies of the most trivial parts of it.
Why nobody ever copies the hard parts?
Some criticism about the site: What a horrible layout. I zoomed out to 25% (the furthest you can go) and the text is still to big.
> A distribution being “simple” has many different interpretations. It may mean simple to use, simple to develop or simple in its implementation. Further, the phrase “simple to use” may differ from person to person. > > Users with prior knowledge of Linux and basic programming skills will find this distribution simple in all three examples given above. A user without prior knowledge may see this distribution as the exact opposite.
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.
No, seriously. Why would I choose this over Alpine? Or, given the failure modes of Alpine as a container image, why would I even choose Alpine? Everything in this space is absolute shite.
ITT counseled in favor of using containers based on ubuntu or centos.
I haven't done huge amounts of container work, but my light outings with Alpine have been fine. Maybe load and internationalization expose more personality in musl, or these concerns pertain to issues that have been fixed.
It's something to keep in mind when assessing risk.
[1] https://www.pythonpodcast.com/docker-python-production-episo...
This was in container-world, so... a bit bizarre. It's very possible that I did something wrong or bizarre, but... that's of no consequence. Ubuntu/Debian works.
Alpine's been fine though for other uses, Go and Node apps for instance.
I had a lot of issues in the past with alpine due to lack of "community" and docs around some problems, as well as musl causing issues with all sorts of nodejs build tools (bower, yarn).
Why is that such a bad thing? I'm not generally a big fan of shell scripts but this one looks particularly readable and documented: https://github.com/kisslinux/kiss/blob/master/kiss
I don't know, but I also don't know if this woman is smiling because they cut off her head to get more breast in frame.
What do you mean? Apparently it is. Many people here had no idea what it was supposed to be, and many people had a different interpretation of what it is.
> That logo makes it a non-starter in any organization I've seen in the last decade.
Lots of people feel that tech culture leans toward the objectification of women, so we're less inclined to use projects that use overtly sexual language or imagery.
For example, read the first paragraph of the Julia language community standards: https://julialang.org/community/standards/
No thanks
Distributions mainly require infrastructure, packaging, and distro specific software like package management.
Many distros are quite derivative and represent largely Linux set up as the author desires.
You see a lot of these because they are easy to make they also suck near zero resources from the broader pool of resources because they are stuck packaging their own software and the skills needed to make them wouldn't translate directly into improving system components anyway.
More complex efforts which are the minority are the way people explore possible paths forward. Many are already increasingly converging on common patterns that make it easier to focus on the things that are truly important to that project.
Complaining about a diversity of options seems poorly thought out when discussing a platform that exists only because others desired more options.
Hell if we all standardized on redhat we might well be trading 10% more progress for 99% fewer options.