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

Stali: A new static Linux distribution

sta.li

Post reply on HN
Print view View original

221–230 of 233 posts

Re: Stali: A new static Linux distribution

#221

Post by artificial »

ex_amazon_sde wrote: post #101
paulddraper wrote: post #28

I really like the idea of static linking. Then I think about how I'd patch the next inevitable openssl bug. Then I don't like it as much.

Most Linux distributions are not going to have enough hardware to rebuild large fractions of their packages when a vulnerability is found in a popular library in a reasonable time. Also, many users will be unhappy to download gigabytes of updates when this happens instead of few megs. (Not every organization runs an internal mirror and not every user sits on a 1GBit pipe) This would lead to very slow security updates…

Chrome makes use of binary patching. Just the deltas are sent. Originally they used bsdiff and ended up implementing their own (superior) version. https://blog.chromium.org/2009/07/smaller-is-faster-and-safe...

Re: Stali: A new static Linux distribution

#222

Post by ackalker »

Annatar wrote: post #103
4ad wrote: post #90

Earlier quoted context omitted.

It's a complete fallacy that every program that needs crypto needs to link to crypto libraries. Look at how Plan 9 does it, where everything is statically linked, but it's other processes which do crypto. Replace only one binary, and the crypto is fixed for all binaries.

shared object libraries are exactly that, a special case of an ELF executable. Special, in the sense that they are not directly executable by users on the command line, other than that, there is no difference (as regular ELF executables can be compiled as re-entrant, position independent code just like shared object libraries).

Interesting fact: while not all shared object files are executable (or rather: do something interesting other than dump core), some most definitely are: try executing libc someday: $ /usr/lib/libc.so.6

See http://stackoverflow.com/questions/1449987/building-a-so-tha... for more information.

Re: Stali: A new static Linux distribution

#223

Post by JdeBP »

72deluxe wrote: post #176
yrro wrote: post #155

Earlier quoted context omitted.

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/

This hasn't seen an airing in a while, because it became accepted wisdom years ago. You're encouraging a bad design that the world has learned better than to employ.

* http://jdebp.eu./FGA/dont-put-your-dll-in-the-system32-direc...

Re: Stali: A new static Linux distribution

#224

Post by creshal »

geocar wrote: post #204
dTal wrote: post #171

Earlier quoted context omitted.

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.

Counterpoint: most underhanded C successes look like incompetence instead of malice, but still look "wrong"

…to someone who spends a lot of time writing C code.

Re: Stali: A new static Linux distribution

#225

Post by khattam »

sctb wrote: post #201
khattam wrote: post #30

Earlier quoted context omitted.

How can any human being be worse than Hillary Clinton?

You can't comment like this here. We ban accounts that continue to violate the guidelines this way. https://news.ycombinator.com/newsguidelines.html

Oh, I didn't drink the liberal koolaid. Feel free to ban my account.

Re: Stali: A new static Linux distribution

#226

Post by joonoro »

morganvachon wrote: post #193
joonoro wrote: post #164

Earlier quoted context omitted.

Out of curiosity, what were you using to measure the speed of the various operating systems you mentioned?

For CLI stuff (compiling, file operations etc) it's the time command, for video decode/encode it's built into ffmpeg, and for graphical stuff it's mostly subjective. There's honestly not a ton of difference on most of the CLI stuff since the hardware is the same, but it is measurable. As for the DE, let's just say that Xfce under Slackware and OpenBSD is quick and peppy while Xfce under Debian-based distros is anythi…

>There's honestly not a ton of difference on most of the CLI stuff since the hardware is the same, but it is measurable.

This is what I was after. I can't imagine ffmpeg running slower just because of systemd or unity. But yeah, if you're running on a 2010 netbook I wouldn't be surprised if it ran better under Xfce.

Re: Stali: A new static Linux distribution

#227

Post by startling »

qplex wrote: post #133
creshal wrote: post #115

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

The stali source includes, among other things:

* a full checkout of libressl: http://git.sta.li/src/tree/lib/libressl

* a full checkout of expat: http://git.sta.li/src/tree/lib/expat

* two full /bins: http://git.sta.li/rootfs-x86_64/tree/bin http://git.sta.li/rootfs-pi/tree/bin

Re: Stali: A new static Linux distribution

#228

Post by startling »

josteink wrote: post #94
startling wrote: post #56

Earlier quoted context omitted.

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

> > Installation uses HTTP to fetch a boot volume image. > This is a problem with all of the suckless software and it, well, sucks. If you serve things over HTTP its easier to daisy-chain it in a PXE -> iPXE kind of setup. HTTPS is not supported by most boot-ROMs. Keep your boot-image server on site and local and HTTP isn't a real world issue.

1) dl.sta.li is not on my site, and probably not on yours.

2) That's still suboptimal. You're giving each host on your LAN the ability to interfere with any newly-provisioned server. This is a perfect and hard-to-detect way for an attacker to pivot from "RCE on some random webapp" to "advanced persistent threat".

Re: Stali: A new static Linux distribution

#229

Post by qplex »

startling wrote: post #227
qplex wrote: post #133

Earlier quoted context omitted.

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

The stali source includes, among other things: * a full checkout of libressl: http://git.sta.li/src/tree/lib/libressl * a full checkout of expat: http://git.sta.li/src/tree/lib/expat * two full /bins: http://git.sta.li/rootfs-x86_64/tree/bin http://git.sta.li/rootfs-pi/tree/bin

Emphasis on "most suckless projects".

The point was that you can verify the integrity by reading the source code. The actual limits to this depend on many things.

Re: Stali: A new static Linux distribution

#230

Post by infinity0 »

ericbb wrote: post #191
infinity0 wrote: post #91

Earlier quoted context omitted.

How do I get it to do that? $ cat test.c #include int main() { printf("Hello, World!\n"); } $ gcc -o test1 test.c && ls -lgG test1 -rwxr-xr-x 1 6712 Sep 28 10:24 test1* $ gcc -static -o test1 test.c && ls -lgG test1 -rwxr-xr-x 1 800904 Sep 28 10:24 test1*

I always use dynamic linking but I thought it'd be fun to try making a small, static hello-world. The following assumes x86-64 Linux (and is a total hack that "works for me" NO WARRANTY!). $ cat test.c static int sys_write(int fd, const void *buf, unsigned long n) { asm("mov $1,%rax; syscall"); } static void sys_exit(int status) { asm("mov $60,%rax; syscall"); } void _start(void) { char s[] = "Hello, World\n"; int r…

No, the parent said "the linker can throw the unnecessary parts away". There is plenty of stuff in libc that my simple "Hello World" program doesn't use, yet gcc does not throw those parts away.

Theoretically I can see that it's possible, I just wonder how to actually do this in practise.

Post reply on HN