8 ms·

( Also discussed previously at https://news.ycombinator.com/item?id=8819085 https://news.ycombinator.com/item?id=8819085 and https://news.ycombinator.com/item?i

by JdeBP 10y ago

( Also discussed previously at https://news.ycombinator.com/item?id=8819085 https://news.ycombinator.com/item?id=8819085 and https://news.ycombinator.com/item?id=7261559 https://news.ycombinator.com/item?id=7261559 ) Interesting points: * http://sta.li/filesystem http://sta.li/filesystem -- Everything not obviously covered by a fairly simplified hierarchy is put into /sucks , without fixing the problem of /etc still being a grab-bag miscellany. * http://sta.li/filesystem http://sta.li/filesystem -- /dev being for devices is a "Linux assumption". * http://sta.li/filesystem http://sta.li/filesystem -- There is no /usr/local . * http://sta.li/filesystem http://sta.li/filesystem -- /.git goes unmentioned. (-: * http://sta.li/filesystem http://sta.li/filesystem -- Half a decade ago, it was claimed that it has no /lib . This is contradicted here. * http://dwm.suckless.org/ http://dwm.suckless.org/ -- "Because dwm is customized through editing its source code, it’s pointless to make binary packages of it. This keeps its userbase small and elitist. No novices asking stupid questions." * http://sta.li/installation http://sta.li/installation -- Installation uses HTTP to fetch a boot volume image. * http://sta.li/installation http://sta.li/installation -- The actual installation steps of the doco are "TODO". * http://sta.li/technologies http://sta.li/technologies -- The Korn shell is the default. * http://sta.li/technologies http://sta.li/technologies -- uses Gerrit Pape's runit, tinydyndns, and socklog * Commentators a few years ago assumed no kernel modules or initrd. There isn't "official" word on this, however. * Nor is there official word on PAM, which logically falls foul of a no dynamic linking philosophy too.

striking 10y ago
> The actual installation steps of the doco are "TODO". Building a kernel and such can be done like this: http://sta.li/build http://sta.li/build I assume that's how that part of installation works. They could have documented that more nicely, though... (Also, I use dwm. It works out of the box, using it on a stock Arch system is as simple as compiling, installing, and adding it to .xinitrc. And configuration has been made extremely simple also. It's not obvious at all, but it works for the particular niche I fit into.)
startling 10y ago
> Installation uses HTTP to fetch a boot volume image. This is a problem with all of the suckless software and it, well, sucks.
- ghshephard 10y ago
  What's wrong with HTTP? I think the OpenBSD team made it clear that HTTPS does nothing for security (At least the integrity portion) of downloading stuff (which is why signify is a thing). By explicitly using a non-secure channel for transport you make it explicit that integrity must come from some other channel.
  - creshal 10y ago
    Except… There is no other channel. Suckless doesn't sign their releases, nor the image download. Nor is anything in git signed. Integrity, schmintegrity ¯\_(ツ)_/¯
    - qplex 10y ago
      The other channel: read the source code yourself before compiling. This actually possible with most suckless projects since they are just a couple of hundred lines of C...
      - dTal 10y ago
        Are you familiar with the Underhanded C Contest? It's possible to maliciously tamper with C code such that you definitely wouldn't spot it with a cursory glance over, and possibly even with careful study.
        geocar 10y ago
        Counterpoint: most underhanded C successes look like incompetence instead of malice, but still look "wrong"
INTPenis 10y ago
>* http://sta.li/filesystem http://sta.li/filesystem -- /.git goes unmentioned. (-: This was an important point to me. I've never used suckless software but one of the first concerns I had with stali was upgrading. Apparently initiating an upgrade is simple using git but what happens if an upgrade fails due to its size? I assume we're upgrading the entire system over git, and in this case that means many very large binary files. I'm of the philosophy that no security measure will get rid of the need to contiunally patch and upgrade your software.
onli 10y ago
> http://dwm.suckless.org/ http://dwm.suckless.org/ -- "Because dwm is customized through editing its source code, it’s pointless to make binary packages of it. This keeps its userbase small and elitist. No novices asking stupid questions." The worst thing about that attitude is that the suckless programs I tried are full of bugs and usability problems. I actually liked the idea of building simplified core programs, without the bloat and bc stuff of the environment around them, and thus opted to use st with a multiplexer. But if the result is that one has a terminal where you can't copy stuff properly because it does not handle linebreaks, or where you can't use ssh properly because the moment you scroll all text gets distorted, that is not excellence, it's just bad. And if they had more users they maybe would find those bugs, and get the help they seem to need. And the whole "we are cool, we configure in source code" is just lazy. It's not like they gain anything from that, the spared lines of code pale in comparison to the effort needed to organize the configuration at distro level.
- creshal 10y ago
  Also, st with a multiplexer (any multiplexer) has much more code complexity than any decent modern terminal. And less features. Way to go, suckless.
- jstimpfle 10y ago
  > And the whole "we are cool, we configure in source code" is just lazy. Right. A little config file parsing library does not harm (and can be just copied into the project) but goes a long way for user experience. Look at icewm, one of my favourite software projects. Yes, it's written in 60K lines of C++, but it's rock solid, fast and flexible. The configuration mechanism is powerful and an example of "no bullshit" design.
  - onli 10y ago
    I just wish icewm had a more active project. I reported a bug and never got feedback, it also was never fixed. But yes, apart from that it is a great WM, and especially the configuration is what makes it great. My choice as well.
- 10y ago

by JdeBP 10y ago

striking 10y ago

> The actual installation steps of the doco are "TODO". Building a kernel and such can be done like this: http://sta.li/build http://sta.li/build I assume that's how that part of installation works. They could have documented that more nicely, though... (Also, I use dwm. It works out of the box, using it on a stock Arch system is as simple as compiling, installing, and adding it to .xinitrc. And configuration has been made extremely simple also. It's not obvious at all, but it works for the particular niche I fit into.)

startling 10y ago

> Installation uses HTTP to fetch a boot volume image. This is a problem with all of the suckless software and it, well, sucks.

ghshephard 10y ago
What's wrong with HTTP? I think the OpenBSD team made it clear that HTTPS does nothing for security (At least the integrity portion) of downloading stuff (which is why signify is a thing). By explicitly using a non-secure channel for transport you make it explicit that integrity must come from some other channel.
- creshal 10y ago
  Except… There is no other channel. Suckless doesn't sign their releases, nor the image download. Nor is anything in git signed. Integrity, schmintegrity ¯\_(ツ)_/¯
  - qplex 10y ago
    The other channel: read the source code yourself before compiling. This actually possible with most suckless projects since they are just a couple of hundred lines of C...
    - dTal 10y ago
      Are you familiar with the Underhanded C Contest? It's possible to maliciously tamper with C code such that you definitely wouldn't spot it with a cursory glance over, and possibly even with careful study.
      - geocar 10y ago
        Counterpoint: most underhanded C successes look like incompetence instead of malice, but still look "wrong"

INTPenis 10y ago

>* http://sta.li/filesystem http://sta.li/filesystem -- /.git goes unmentioned. (-: This was an important point to me. I've never used suckless software but one of the first concerns I had with stali was upgrading. Apparently initiating an upgrade is simple using git but what happens if an upgrade fails due to its size? I assume we're upgrading the entire system over git, and in this case that means many very large binary files. I'm of the philosophy that no security measure will get rid of the need to contiunally patch and upgrade your software.

onli 10y ago

> http://dwm.suckless.org/ http://dwm.suckless.org/ -- "Because dwm is customized through editing its source code, it’s pointless to make binary packages of it. This keeps its userbase small and elitist. No novices asking stupid questions." The worst thing about that attitude is that the suckless programs I tried are full of bugs and usability problems. I actually liked the idea of building simplified core programs, without the bloat and bc stuff of the environment around them, and thus opted to use st with a multiplexer. But if the result is that one has a terminal where you can't copy stuff properly because it does not handle linebreaks, or where you can't use ssh properly because the moment you scroll all text gets distorted, that is not excellence, it's just bad. And if they had more users they maybe would find those bugs, and get the help they seem to need. And the whole "we are cool, we configure in source code" is just lazy. It's not like they gain anything from that, the spared lines of code pale in comparison to the effort needed to organize the configuration at distro level.

creshal 10y ago
Also, st with a multiplexer (any multiplexer) has much more code complexity than any decent modern terminal. And less features. Way to go, suckless.
jstimpfle 10y ago
> And the whole "we are cool, we configure in source code" is just lazy. Right. A little config file parsing library does not harm (and can be just copied into the project) but goes a long way for user experience. Look at icewm, one of my favourite software projects. Yes, it's written in 60K lines of C++, but it's rock solid, fast and flexible. The configuration mechanism is powerful and an example of "no bullshit" design.
- onli 10y ago
  I just wish icewm had a more active project. I reported a bug and never got feedback, it also was never fixed. But yes, apart from that it is a great WM, and especially the configuration is what makes it great. My choice as well.
10y ago