Live data from Hacker News

Stali: A new static Linux distribution

sta.li

171–180 of 233 posts

Re: Stali: A new static Linux distribution

#171
post #133

Earlier quoted context omitted.

Except… There is no other channel. Suckless doesn't sign their releases, nor the image download. Nor is anything in git signed. Integrity, schmintegrity ¯\_(ツ)_/¯

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...

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.

Re: Stali: A new static Linux distribution

#172
post #3

I still don't understand why systemd sucks

That's a loaded question, and I'm only qualified to answer from my perspective and experience. My biggest gripe with it has always been that it is alpha-quality software, even today, that has a central role in an otherwise mature OS ecosystem. It has been widely adopted (some would say forced or tricked into adoption by a few distros) and therefore all the major Linux distributions are now running at an alpha level w…

When Linux came along in the mid-90s, most commercial Unixes had left behind the Unix philosophy, with their own integrated, object oriented desktop environments and sophisticated administration tools. Only Xenix, the engine that powered many an auto shop's rinky-dink five-user database setup, stuck with the model of text terminals and CLI administration with simple tools.

Of course Linux took off, and it sort of reset everything back to stone knives and bearskins. But systemd itself is modelled on Solaris SMF, which is world-class industrial grade service management for large server deployments.

Appeals to the "Unix Philosophy" are the province of reactionary greybeards. Unix philosophy means nothing in the modern era.

Re: Stali: A new static Linux distribution

#173

Earlier quoted context omitted.

Yep but now instead of fetching 1 updated library, you depend on everybody and their cat to rebuild their binaries and publish updated versions.

Not really, I depend on my distro to push updated packages that I will update. And I also hope that my distro pushes me binary diffs so that it's going to be very fast. The point is: in the context of a Linux distro, it's not true that you need dynamic linking to be able to do security patches effectively. What users do is to run the package manager to update the system; the package manager can provide updates to sta…

Is it practical to make diffs of recompiled binaries? Don't you need to compile to position independent code? Or otherwise make sure that most of the code's position does not change when some statically linked library changes?

Re: Stali: A new static Linux distribution

#174
post #165
post #53

Earlier quoted context omitted.

Google Go and Rust promote it. However, deploying web services is different than Linux distro.

The problem here is that the choice is one extreme or the other, never the happy medium. The extremes are statically linked everything and dynamically linked everything. Bryan Cantrill deplores this part of the design of Go. He decries the fact that rather than sitting on top of a HLL-function-call binary interface, with the portability layer being HLL function calls like read(), write(), close(), socket(), execve(),…

Bryan would have to elaborate an awful lot on the evilness of using system calls to make that a more general argument. (we're not supposed to use the kernel now for some reason?) It looks like it was just kind of a pain in the ass for the Joyent guys because of what they were doing specifically, which was pretty specialized.

(there's a mean and almost clinically insane blog post about Go by one of the other Joyent guys, who retired a week or two after writing it, which also doesn't shed much light but is funnier. You've got to wonder what their deal is with the Go guys, exactly...)

Re: Stali: A new static Linux distribution

#175
> "Follow the suckless philosophy"

I used to love the idea of the suckless philosophy, until I forked `st` to make it work on OS X by removing globals and by separating the terminal emulator logic from the X11 logic, and asked[1] on the mailing list if they'd be interested in merging my changes. The responses I got made me never want to use any suckless software ever again.

[1] http://lists.suckless.org/dev/1408/23366.html

Re: Stali: A new static Linux distribution

#176
post #155

Earlier quoted context omitted.

Windows? Have you ever heard of DLLs?

My Windows system currently has 21 copies of zlib1.dll on it, each shipped by a different program. While I have no doubt that Windows programmers have heard of DLLs, they clearly haven't grasped the idea of shared libraries.

The problem in that case is developers not putting their DLLs in a system directory! Windows will use WinSXS to avoid problems with different versions (DLL hell).

Once loaded into memory, DLLs save loading the same code twice. See http://www.ksyash.com/2011/01/dll-internals/

Re: Stali: A new static Linux distribution

#177
post #133

Earlier quoted context omitted.

Except… There is no other channel. Suckless doesn't sign their releases, nor the image download. Nor is anything in git signed. Integrity, schmintegrity ¯\_(ツ)_/¯

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...

Ignoring the fact that this implies you have to be a programmer that knows how to read C to verify the integrity of the downloads, and that the lines of code in C often correlates directly to complexity of the solution being expressed, this also assumes that an attack vector would be something obvious upon reading the code, and not hidden as a subtle bug which is hard to spot.

Re: Stali: A new static Linux distribution

#178
post #149
post #24

Shocked that it takes a fringe project to be promoting static linking and cleaning up the filesystem. Would love to hear the linux grandfathers chime in...

You should rather be shocked that the Linux world still believes that it is anywhere near this century when it comes to modernizing the filesystem hierarchy. * NeXTSTEP had ~/Apps, /LocalLibrary, /LocalApps, and so forth back in the early 1990s. * The "/usr merge" first happened in AT&T Unix System 5 Release 4. SunOS 5 (a.k.a. Solaris 2) introduced it a few years after NeXTSTEP introduced its directory hierarchy. AIX…

Gobolinux is another Linux distro that ditches the FHS: http://gobolinux.org/

Re: Stali: A new static Linux distribution

#179

Earlier quoted context omitted.

Not really, I depend on my distro to push updated packages that I will update. And I also hope that my distro pushes me binary diffs so that it's going to be very fast. The point is: in the context of a Linux distro, it's not true that you need dynamic linking to be able to do security patches effectively. What users do is to run the package manager to update the system; the package manager can provide updates to sta…

Is it practical to make diffs of recompiled binaries? Don't you need to compile to position independent code? Or otherwise make sure that most of the code's position does not change when some statically linked library changes?

Slightly different comparison, but I remember some google project to do this for shipping updates a while ago. Must have been for android, but I can't remember.

Re: Stali: A new static Linux distribution

#180
post #97

Earlier quoted context omitted.

> 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…

> 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" d…

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.
Post reply on HN