7 ms·

Sta.li: Static Linux

150 points by Xyzodiac 13y ago

vezzy-fnord 13y ago
It's an admirable initiative, but I'm pretty sure that at this point sta.li has been in the "design phase" for years. It's vaporware. I'd love to be proven wrong, though.
- T-A 13y ago
  Can't help you with that, latest download is from 2009: http://dl.suckless.org/stali/ http://dl.suckless.org/stali/
- plorkyeran 13y ago
  © 2006-2013 for something still not released certainly isn't promising. Glancing at the git logs (http://git.suckless.org/?s=idle http://git.suckless.org/?s=idle) there is some ongoing work, so the project isn't totally dead at least.
  - herokusaki 13y ago
    Can you compile the world with static linking on Gentoo Linux or any of the BSDs? If so, that could serve as a substitute.
- eekee 13y ago
  the maintainer was busy with work for quite a while, so it might pick up now he's not. i don't care too much myself though, linux has become little more than a web browser platform for me, and i'm sure sta.li would struggle to provide that.
chj 13y ago
"The reason why dynamic linking has been invented was not to decrease the general executable sizes or to save memory consumption, or to speed up the exec() -- but to allow changing code during runtime -- and that's the real purpose of dynamic linking, we shouldn't forget that." Not sure about "changing code during runtime", but one of the great benefits of dynamic-link libraries are for writing plugins. And I don't think it would take much time for an app to look up its own plugin folder.
julie1 13y ago
I was dreaming of it, and knew that no matter how much it was itching I could never scratch it. Thanks
matiasb 13y ago
Sounds good, what about Golang based tools? (considering the default static binary generation)
- _ak 13y ago
  Ever since uriel died, the suckless project doesn't really appreciate Go anymore.
  - eekee 13y ago
    many people in uriel's cat-v community don't either. part of the problem is go's community and its web focus. the other part is cat-v is now focused on a plan 9 fork, and go solves problems which don't come up much on plan 9, or which are already largely solved.
khc 13y ago
From the FAQ: "Also a security issue with dynamically linked libraries are executables with the suid flag. A user can easily run dynamic library code using LD_PRELOAD in conjunction with some trivial program like ping. Using a static executable with the suid flag eliminates this problem completely." Have the authors actually tried this? Using LD_PRELOAD with suid programs won't work.
- CUViper 13y ago
  Right - at least with glibc, ld.so unsets most LD_* variables and more for both setuid and setgid programs. Grep for UNSECURE_ENVVARS in glibc source to get the whole list and see how it's used. I'd be very surprised if any other libc implementation didn't do the same.
vinkelhake 13y ago
On binary sizes: > Linking a stripped hello world program with glibc results in 600kb. Linking it with uclibc in about 7kb. That's nice for uclibc, but we're typically linking dynamically. The comparison should be between dynamically and statically linked binaries. A stripped and dynamically linked hello world results in a 6kb program on my machine (glibc). There's also a lot of handwaving on memory usage in the FAQ.
- mdwrigh2 13y ago
  > A stripped and dynamically linked hello world results in a 6kb program on my machine (glibc). Is that the proportional size (binary size + glibc size / number of things using glibc), or just the size of the binary?
  - vinkelhake 13y ago
    It's the size of the binary. I don't understand what you mean by proportional size. If we add more functionality to the hello world program, the dynamically linked version should increase in size slower than the statically linked.
    - mdwrigh2 13y ago
      The point of proportional size is to account for the size of glibc, which has to be on disk and in memory and so incurs a cost that isn't accounted for by just looking at the size of the binaries that link against it, by dividing glibc's size by the number of applications that use it. When examining memory usage on Linux systems, one of the common measurement metrics is the Proportional Set Size (PSS), which essentially is what I was asking about (but for on-disk size, rather than just in-memory): http://lwn.net/Articles/230975/ http://lwn.net/Articles/230975/
- khc 13y ago
  > There's also a lot of handwaving on memory usage in the FAQ. Totally. Reading the FAQ reminded me of https://xkcd.com/386/ https://xkcd.com/386/
- 13y ago
davidp 13y ago
I'm puzzled by the idea of a system being leaner/faster with n copies of a library in physical RAM rather than 1 copy mapped via VMM into whatever process wants it. IIRC this was the main point of shared libraries, not pluggability or changing code during runtime. Am I missing something?
- mcot2 13y ago
  Maybe if we didn't have gigabytes of RAM these days. I quite like the idea of static linking. It makes software packaging and distribution very very easy and it has some security benefits. Go's build system is a good example of this. This project seems to be dead.
  - girvo 13y ago
    It's the distribution and packaging parts that I love about it. Also might help with cross-platform distribution as well; While dynamic linking does have advantages, I get really frustrated when an old application won't run on a new kernel due to requiring old libraries that simply can't be installed. Static linking fixes that, and it's why anything I try and write is statically linked for the most part!
    - nicolast 13y ago
      Ever looked at Nix and NixOS?
  - weland 13y ago
    I have mixed feelings about the security gains. On one hand, you eliminate one attack vector since you take ldd out of the equation. On the other hand, you depend on packagers who distribute their programs to rebuild and relink them every time a security issue creeps up a library they link with. I'm not sure I like that, and I don't have the free time I had in high school when compiling everything by hand seemed really fucking cool.
- cgh 13y ago
  Static linking doesn't necessarily link the entire library, unless the entire thing compiles to a single .o file. Linkers are smart enough to only link in the object files needed by the program. So assuming you are only linking in well-designed libraries, I guess it's possible that statically-linked software will be smaller since it will leave out the stuff you aren't using.
ChuckMcM 13y ago
Ah kids, they crack me up! Lot of fun reading that, I looked around briefly but couldn't find my email archive from Sun, but I was in the kernel group when folks got the idea that "Gee if you shared the text segment of libraries, that would give you more memory for your buffer cache or user pages!" One of the guys in my group re-wrote the linker to scan through and realign text segments so that the maximum number of read-only pages (and thus shareable) could be allocated. And of course code that had static buffers and what not (go look at the 4.1BSD code, they were everywhere). It made my Sun 3/75 which had, wait for it 32 Megabytes of RAM (yes, less than the L2 cache in some machines these days) run quite a bit faster. Took a long time to get right too. Shared libraries gave you three distinct advantages, one you cut down on the working set size, two you cut down on file load time, and three it became possible to "interpose" on the library and run two versions of the library at the same time for backwards compatibility. Building a static system might be fun but for a 64 bit system, building one where libraries were fixed in the address space in flash or something might actually be even better.
- Lerc 13y ago
  I think the real advantage to static linking is that it forces developers to fully acknowledge the resources they are using. Programs using shared libraries allow a degree of avoiding blame. It's difficult to judge the real impact of things, it rests upon assumptions about how much the library is shared, while putting pressure on the library to be serve more masters and to become more generalized increasing overall size. It's not a simple equation. It would be at least interesting to get data on all-static systems as well as compare static linked memory usage vs shared library on an individual basis.
  - pjmlp 13y ago
    You still have the same issues about blame with libraries, static linking them won't solve it.
    - abc_lisper 13y ago
      Yeah, but the dev will know at compile time what those problems are.
cgh 13y ago
I enjoyed this from their description of their dwm window manager, which took me back to the general state of Linux circa 1999: "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. There are some distributions that provide binary packages though."
- GFK_of_xmaspast 13y ago
  I don't miss the general state of linux circa 1999 one bit.
  - hnisnotreddit 13y ago
    I, for one, miss spending 10 hours fully compiling GNOME 0.99.8 and Englightenment 0.15 from CVS every week on my Pentium 133 running Linux Mandrake. Over the past 17 or so years I've been using linux full-time, I've experienced 3 or 4 of the "sweet spots", or times where using linux was superior to everything else on the market. GNOME 1.x with Enlightenment 0.15 (vs Win98) was the second one (the first, I'm told, was E DR0.13 with CmdrTaco's task managing app and Hand of God theme vs Win95). I believe we are currently at the end of another sweet spot with KDE 4.x being put out to pasture, as it completely destroys the UX of Windows 7/8 and Mountain Lion. But don't knock the state of linux circa 1999. Sure, you had to ensure your sound cards had OSS drivers, and Winmodems sucked, but it was a superior experience to Win9x even back then.
- anon4 13y ago
  I used to run dwm back when I had a machine with just 256MB RAM. The source code is very clean and if you just want to edit some keybindings or the colourscheme, etc. it's so well structured, it's pretty much like editing a config file. It also compiles in no time at all.
  - agumonkey 13y ago
    I wonder if this was how people felt about C in early days. ASM was the low level frailty, and C the oh-so-clean one-make-away world to create, extend, modify your system.
ch215 13y ago
The developer, Anselm Garbe, gave a talk about Stali (among other things) at last year's Suckless conference... http://www.youtube.com/watch?v=Zu9Qm9bNMUU http://www.youtube.com/watch?v=Zu9Qm9bNMUU I'm not qualified to comment on Stali itself but, more generally, I can't recommend Suckless software highly enough. Since I switched to Linux a few years back I've found myself using more and more of their programs--DWM, Dmenu, ST, Tabbed, Slock and Surf. Before, I'd hop from one window manager, terminal or browser to another but, for me, Suckless programs just tend to stick because of the minimal philosophy.
anon35 13y ago
Static linking also relative in a discussion about coupling and OS dependencies : http://unix.stackexchange.com/a/38914/17683 http://unix.stackexchange.com/a/38914/17683
mrich 13y ago
They missed a chance to call a project 'Stalin'.
- exDM69 13y ago
  Perhaps because they had the opportunity to use the sta.li domain and/or avoid confusion with the Stalin Scheme compilers?
- nathell 13y ago
  That name is already taken: http://en.wikipedia.org/wiki/Stalin_(Scheme_implementation) http://en.wikipedia.org/wiki/Stalin_(Scheme_implementation)
kev009 13y ago
In case it's not obvious: if you static link to a library, say libpng, and a vuln hits, every binary that linked to libpng potentially needs to be rebuilt and distributed. If the OS has rigid dependency tracking (maybe source distros like Gentoo, or a cryptographically tracked binary distribution like freebsd-update), maybe you can live with that. So there's some trade off of "dll hell" for binary hell, and perhaps some other security advantages to dynamic libs. IMHO shared libraries are pretty well understood now days and static linking should be avoided unless you have a very good reason.
- ksk 13y ago
  There are already ways to mitigate that. One example would be to use mandatory access control to 'host' the library in a separate process which is stripped off of all unnecessary rights/privileges.
- qznc 13y ago
  That vuln problem works the other way round as well. When a new libpng vulnerability is introduced all executables using the shared library are affected, while static-lib users with an older version are fine.
  - danieldk 13y ago
    But in general, all binaries in a distribution are compiled against the same version of a library, namely the one that is distributed with it. I don't see that changing in a distribution that was fully statically linked. Even in the unlikely case where binaries are statically linked against different versions of a library. You'd still have to check against which version each binary is compiled. Of course, you also gain in security, since all kind of library preloading attacks are not possible anymore.
- default_name 13y ago
  Many applications started shipping with all neccessary libraries, that's like taking disadvantages of static and dynamic linking combined. At least they can adhere to GPL...
jbb555 13y ago
With the use of link time code generation too, this could be better than expected perhaps?
paulannesley 13y ago
MONDAY, FEBRUARY 1, 2010 Stali: http://wayback.archive.org/web/20110727064007/http://elevenislouder.blogspot.com/2010/02/stali.html http://wayback.archive.org/web/20110727064007/http://eleveni...
prewett 13y ago
Building Gentoo with USE=static might be a good way to experiment without have to build an entire new distribution. Try one with the flag, one without, do the same operations in each and watch the memory usage and time to completion.
- benjamincburns 13y ago
  Took the words right out of my mouth. Though I think to do this well you'd need to go old school and do a fully bootstrapped (formerly "stage 1") install.
- default_name 13y ago
  It's not that easy. Many libraries can't be statically linked, some programs will break if it will be statically linked. It is impossible to link statically with glibc. Even if it would be possible it's pointless. You will need another lean libc, like musl. Than go figure list of bugs found by musl: http://wiki.musl-libc.org/wiki/Bugs_found_by_musl http://wiki.musl-libc.org/wiki/Bugs_found_by_musl
  - justincormack 13y ago
    There is an experimental Musl gentoo stage I think now.
oofabz 13y ago
The group behind Sta.li also makes a great terminal emulator. It is notable for supporting font antialiasing without depending on the large GTK or QT libraries - it uses Xft directly. And it is much smaller than even xterm or rxvt. http://st.suckless.org/ http://st.suckless.org/
default_name 13y ago
It's not meant to be just another Linux distribution. It will be whole new system with Linux kernel at the core. It will be more in line with BSDs. That's why static linking will make sense. Your updates are just rsync away. As I see it suckless.org community prefers 'linking' in form of shell scripts or communication via pipes, ideally via system's VFS. You will get lean and minimalistic base system. If something will not share same ideals it will not be in the base system (like glib[c]?, bash, Firefox). It is possible that dynamic linking will be allowed in /emul chroot as stated in 'Filesystem' page. I see sta.li as rock solid minimalistic base system, which you can use on it's own (how I belive many suckless.org folks will use it) or as a base system, that you can build upon. Even more than that, you will be able to use sta.li components in generic distributions with ease, because of static linking. Go-lang is in my opinion next step for Bell Labs folks in lean development for the masses. Don't take this too literally ;) Plan 9 [1] was first step, but people did not want whole new system. Inferno [2] was next one, but VM system was too much also. Go allows to use some of Plan 9 features in edible form for the masses. Without requirement to install specific system or VM to run your programs. That to some extent is what makes sta.li's ideals similar to go-lang's. Development of sta.li is at slow pace, but many experiments are under development [3]. Probably some of them will be included in sta.li. Most probably sta.li will include X11, but we are seeing some developments with Wayland [4]. [1] - http://en.wikipedia.org/wiki/Plan_9_from_Bell_Labs http://en.wikipedia.org/wiki/Plan_9_from_Bell_Labs [2] - http://en.wikipedia.org/wiki/Inferno_%28operating_system%29 http://en.wikipedia.org/wiki/Inferno_%28operating_system%29 [3] - https://github.com/henrysher/sinit https://github.com/henrysher/sinit - http://galos.no-ip.org/sdhcp http://galos.no-ip.org/sdhcp - http://git.suckless.org/dmc/ http://git.suckless.org/dmc/ [4] - https://github.com/michaelforney/swc https://github.com/michaelforney/swc
ommunist 13y ago
For this kind of thing Stal.in is a better domain name.
nathell 13y ago
One useful set of gcc flags to consider when building a statically-linkable library/executable and aiming to reduce executable size is -Os -ffunction-sections -fdata-sections -Wl,-gc-sections. This causes gcc to put each function in a separate section in the resulting object file, and the -gc-sections option makes ld strip the sections that are not reachable by calls from main (basically a tree-shaker).
mrottenkolber 13y ago
I like what the guys are doing and would love to try it out, but frankly the page didn't change much for the last two years and all the discussion of strategy isn't worth much without a working distribution with which you can experiment. Furthermore I suspect the scope of stali will be so narrow that I will never be able to run say a CL implementation on it. Pretty much the same as Plan9, I love the design but it's practically useless for me. :(
Ziomislaw 13y ago
Stali currently does not exist, but there are others statically linked distros out there, ie. http://starchlinux.org/ http://starchlinux.org/

150 points by Xyzodiac 13y ago

It's an admirable initiative, but I'm pretty sure that at this point sta.li has been in the "design phase" for years. It's vaporware. I'd love to be proven wrong, though.

T-A 13y ago
Can't help you with that, latest download is from 2009: http://dl.suckless.org/stali/ http://dl.suckless.org/stali/
plorkyeran 13y ago
© 2006-2013 for something still not released certainly isn't promising. Glancing at the git logs (http://git.suckless.org/?s=idle http://git.suckless.org/?s=idle) there is some ongoing work, so the project isn't totally dead at least.
- herokusaki 13y ago
  Can you compile the world with static linking on Gentoo Linux or any of the BSDs? If so, that could serve as a substitute.
eekee 13y ago
the maintainer was busy with work for quite a while, so it might pick up now he's not. i don't care too much myself though, linux has become little more than a web browser platform for me, and i'm sure sta.li would struggle to provide that.

chj 13y ago

"The reason why dynamic linking has been invented was not to decrease the general executable sizes or to save memory consumption, or to speed up the exec() -- but to allow changing code during runtime -- and that's the real purpose of dynamic linking, we shouldn't forget that." Not sure about "changing code during runtime", but one of the great benefits of dynamic-link libraries are for writing plugins. And I don't think it would take much time for an app to look up its own plugin folder.

julie1 13y ago

I was dreaming of it, and knew that no matter how much it was itching I could never scratch it. Thanks

matiasb 13y ago

Sounds good, what about Golang based tools? (considering the default static binary generation)

_ak 13y ago
Ever since uriel died, the suckless project doesn't really appreciate Go anymore.
- eekee 13y ago
  many people in uriel's cat-v community don't either. part of the problem is go's community and its web focus. the other part is cat-v is now focused on a plan 9 fork, and go solves problems which don't come up much on plan 9, or which are already largely solved.

khc 13y ago

From the FAQ: "Also a security issue with dynamically linked libraries are executables with the suid flag. A user can easily run dynamic library code using LD_PRELOAD in conjunction with some trivial program like ping. Using a static executable with the suid flag eliminates this problem completely." Have the authors actually tried this? Using LD_PRELOAD with suid programs won't work.

CUViper 13y ago
Right - at least with glibc, ld.so unsets most LD_* variables and more for both setuid and setgid programs. Grep for UNSECURE_ENVVARS in glibc source to get the whole list and see how it's used. I'd be very surprised if any other libc implementation didn't do the same.

vinkelhake 13y ago

On binary sizes: > Linking a stripped hello world program with glibc results in 600kb. Linking it with uclibc in about 7kb. That's nice for uclibc, but we're typically linking dynamically. The comparison should be between dynamically and statically linked binaries. A stripped and dynamically linked hello world results in a 6kb program on my machine (glibc). There's also a lot of handwaving on memory usage in the FAQ.

mdwrigh2 13y ago
> A stripped and dynamically linked hello world results in a 6kb program on my machine (glibc). Is that the proportional size (binary size + glibc size / number of things using glibc), or just the size of the binary?
- vinkelhake 13y ago
  It's the size of the binary. I don't understand what you mean by proportional size. If we add more functionality to the hello world program, the dynamically linked version should increase in size slower than the statically linked.
  - mdwrigh2 13y ago
    The point of proportional size is to account for the size of glibc, which has to be on disk and in memory and so incurs a cost that isn't accounted for by just looking at the size of the binaries that link against it, by dividing glibc's size by the number of applications that use it. When examining memory usage on Linux systems, one of the common measurement metrics is the Proportional Set Size (PSS), which essentially is what I was asking about (but for on-disk size, rather than just in-memory): http://lwn.net/Articles/230975/ http://lwn.net/Articles/230975/
khc 13y ago
> There's also a lot of handwaving on memory usage in the FAQ. Totally. Reading the FAQ reminded me of https://xkcd.com/386/ https://xkcd.com/386/
13y ago

davidp 13y ago

I'm puzzled by the idea of a system being leaner/faster with n copies of a library in physical RAM rather than 1 copy mapped via VMM into whatever process wants it. IIRC this was the main point of shared libraries, not pluggability or changing code during runtime. Am I missing something?

mcot2 13y ago
Maybe if we didn't have gigabytes of RAM these days. I quite like the idea of static linking. It makes software packaging and distribution very very easy and it has some security benefits. Go's build system is a good example of this. This project seems to be dead.
- girvo 13y ago
  It's the distribution and packaging parts that I love about it. Also might help with cross-platform distribution as well; While dynamic linking does have advantages, I get really frustrated when an old application won't run on a new kernel due to requiring old libraries that simply can't be installed. Static linking fixes that, and it's why anything I try and write is statically linked for the most part!
  - nicolast 13y ago
    Ever looked at Nix and NixOS?
- weland 13y ago
  I have mixed feelings about the security gains. On one hand, you eliminate one attack vector since you take ldd out of the equation. On the other hand, you depend on packagers who distribute their programs to rebuild and relink them every time a security issue creeps up a library they link with. I'm not sure I like that, and I don't have the free time I had in high school when compiling everything by hand seemed really fucking cool.
cgh 13y ago
Static linking doesn't necessarily link the entire library, unless the entire thing compiles to a single .o file. Linkers are smart enough to only link in the object files needed by the program. So assuming you are only linking in well-designed libraries, I guess it's possible that statically-linked software will be smaller since it will leave out the stuff you aren't using.

ChuckMcM 13y ago

Ah kids, they crack me up! Lot of fun reading that, I looked around briefly but couldn't find my email archive from Sun, but I was in the kernel group when folks got the idea that "Gee if you shared the text segment of libraries, that would give you more memory for your buffer cache or user pages!" One of the guys in my group re-wrote the linker to scan through and realign text segments so that the maximum number of read-only pages (and thus shareable) could be allocated. And of course code that had static buffers and what not (go look at the 4.1BSD code, they were everywhere). It made my Sun 3/75 which had, wait for it 32 Megabytes of RAM (yes, less than the L2 cache in some machines these days) run quite a bit faster. Took a long time to get right too. Shared libraries gave you three distinct advantages, one you cut down on the working set size, two you cut down on file load time, and three it became possible to "interpose" on the library and run two versions of the library at the same time for backwards compatibility. Building a static system might be fun but for a 64 bit system, building one where libraries were fixed in the address space in flash or something might actually be even better.

Lerc 13y ago
I think the real advantage to static linking is that it forces developers to fully acknowledge the resources they are using. Programs using shared libraries allow a degree of avoiding blame. It's difficult to judge the real impact of things, it rests upon assumptions about how much the library is shared, while putting pressure on the library to be serve more masters and to become more generalized increasing overall size. It's not a simple equation. It would be at least interesting to get data on all-static systems as well as compare static linked memory usage vs shared library on an individual basis.
- pjmlp 13y ago
  You still have the same issues about blame with libraries, static linking them won't solve it.
  - abc_lisper 13y ago
    Yeah, but the dev will know at compile time what those problems are.

cgh 13y ago

I enjoyed this from their description of their dwm window manager, which took me back to the general state of Linux circa 1999: "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. There are some distributions that provide binary packages though."

GFK_of_xmaspast 13y ago
I don't miss the general state of linux circa 1999 one bit.
- hnisnotreddit 13y ago
  I, for one, miss spending 10 hours fully compiling GNOME 0.99.8 and Englightenment 0.15 from CVS every week on my Pentium 133 running Linux Mandrake. Over the past 17 or so years I've been using linux full-time, I've experienced 3 or 4 of the "sweet spots", or times where using linux was superior to everything else on the market. GNOME 1.x with Enlightenment 0.15 (vs Win98) was the second one (the first, I'm told, was E DR0.13 with CmdrTaco's task managing app and Hand of God theme vs Win95). I believe we are currently at the end of another sweet spot with KDE 4.x being put out to pasture, as it completely destroys the UX of Windows 7/8 and Mountain Lion. But don't knock the state of linux circa 1999. Sure, you had to ensure your sound cards had OSS drivers, and Winmodems sucked, but it was a superior experience to Win9x even back then.
anon4 13y ago
I used to run dwm back when I had a machine with just 256MB RAM. The source code is very clean and if you just want to edit some keybindings or the colourscheme, etc. it's so well structured, it's pretty much like editing a config file. It also compiles in no time at all.
- agumonkey 13y ago
  I wonder if this was how people felt about C in early days. ASM was the low level frailty, and C the oh-so-clean one-make-away world to create, extend, modify your system.

ch215 13y ago

The developer, Anselm Garbe, gave a talk about Stali (among other things) at last year's Suckless conference... http://www.youtube.com/watch?v=Zu9Qm9bNMUU http://www.youtube.com/watch?v=Zu9Qm9bNMUU I'm not qualified to comment on Stali itself but, more generally, I can't recommend Suckless software highly enough. Since I switched to Linux a few years back I've found myself using more and more of their programs--DWM, Dmenu, ST, Tabbed, Slock and Surf. Before, I'd hop from one window manager, terminal or browser to another but, for me, Suckless programs just tend to stick because of the minimal philosophy.

anon35 13y ago

Static linking also relative in a discussion about coupling and OS dependencies : http://unix.stackexchange.com/a/38914/17683 http://unix.stackexchange.com/a/38914/17683

mrich 13y ago

They missed a chance to call a project 'Stalin'.

exDM69 13y ago
Perhaps because they had the opportunity to use the sta.li domain and/or avoid confusion with the Stalin Scheme compilers?
nathell 13y ago
That name is already taken: http://en.wikipedia.org/wiki/Stalin_(Scheme_implementation) http://en.wikipedia.org/wiki/Stalin_(Scheme_implementation)

kev009 13y ago

In case it's not obvious: if you static link to a library, say libpng, and a vuln hits, every binary that linked to libpng potentially needs to be rebuilt and distributed. If the OS has rigid dependency tracking (maybe source distros like Gentoo, or a cryptographically tracked binary distribution like freebsd-update), maybe you can live with that. So there's some trade off of "dll hell" for binary hell, and perhaps some other security advantages to dynamic libs. IMHO shared libraries are pretty well understood now days and static linking should be avoided unless you have a very good reason.

ksk 13y ago
There are already ways to mitigate that. One example would be to use mandatory access control to 'host' the library in a separate process which is stripped off of all unnecessary rights/privileges.
qznc 13y ago
That vuln problem works the other way round as well. When a new libpng vulnerability is introduced all executables using the shared library are affected, while static-lib users with an older version are fine.
- danieldk 13y ago
  But in general, all binaries in a distribution are compiled against the same version of a library, namely the one that is distributed with it. I don't see that changing in a distribution that was fully statically linked. Even in the unlikely case where binaries are statically linked against different versions of a library. You'd still have to check against which version each binary is compiled. Of course, you also gain in security, since all kind of library preloading attacks are not possible anymore.
default_name 13y ago
Many applications started shipping with all neccessary libraries, that's like taking disadvantages of static and dynamic linking combined. At least they can adhere to GPL...

jbb555 13y ago

With the use of link time code generation too, this could be better than expected perhaps?

paulannesley 13y ago

MONDAY, FEBRUARY 1, 2010 Stali: http://wayback.archive.org/web/20110727064007/http://elevenislouder.blogspot.com/2010/02/stali.html http://wayback.archive.org/web/20110727064007/http://eleveni...

prewett 13y ago

Building Gentoo with USE=static might be a good way to experiment without have to build an entire new distribution. Try one with the flag, one without, do the same operations in each and watch the memory usage and time to completion.

benjamincburns 13y ago
Took the words right out of my mouth. Though I think to do this well you'd need to go old school and do a fully bootstrapped (formerly "stage 1") install.
default_name 13y ago
It's not that easy. Many libraries can't be statically linked, some programs will break if it will be statically linked. It is impossible to link statically with glibc. Even if it would be possible it's pointless. You will need another lean libc, like musl. Than go figure list of bugs found by musl: http://wiki.musl-libc.org/wiki/Bugs_found_by_musl http://wiki.musl-libc.org/wiki/Bugs_found_by_musl
- justincormack 13y ago
  There is an experimental Musl gentoo stage I think now.

oofabz 13y ago

The group behind Sta.li also makes a great terminal emulator. It is notable for supporting font antialiasing without depending on the large GTK or QT libraries - it uses Xft directly. And it is much smaller than even xterm or rxvt. http://st.suckless.org/ http://st.suckless.org/

default_name 13y ago

It's not meant to be just another Linux distribution. It will be whole new system with Linux kernel at the core. It will be more in line with BSDs. That's why static linking will make sense. Your updates are just rsync away. As I see it suckless.org community prefers 'linking' in form of shell scripts or communication via pipes, ideally via system's VFS. You will get lean and minimalistic base system. If something will not share same ideals it will not be in the base system (like glib[c]?, bash, Firefox). It is possible that dynamic linking will be allowed in /emul chroot as stated in 'Filesystem' page. I see sta.li as rock solid minimalistic base system, which you can use on it's own (how I belive many suckless.org folks will use it) or as a base system, that you can build upon. Even more than that, you will be able to use sta.li components in generic distributions with ease, because of static linking. Go-lang is in my opinion next step for Bell Labs folks in lean development for the masses. Don't take this too literally ;) Plan 9 [1] was first step, but people did not want whole new system. Inferno [2] was next one, but VM system was too much also. Go allows to use some of Plan 9 features in edible form for the masses. Without requirement to install specific system or VM to run your programs. That to some extent is what makes sta.li's ideals similar to go-lang's. Development of sta.li is at slow pace, but many experiments are under development [3]. Probably some of them will be included in sta.li. Most probably sta.li will include X11, but we are seeing some developments with Wayland [4]. [1] - http://en.wikipedia.org/wiki/Plan_9_from_Bell_Labs http://en.wikipedia.org/wiki/Plan_9_from_Bell_Labs [2] - http://en.wikipedia.org/wiki/Inferno_%28operating_system%29 http://en.wikipedia.org/wiki/Inferno_%28operating_system%29 [3] - https://github.com/henrysher/sinit https://github.com/henrysher/sinit - http://galos.no-ip.org/sdhcp http://galos.no-ip.org/sdhcp - http://git.suckless.org/dmc/ http://git.suckless.org/dmc/ [4] - https://github.com/michaelforney/swc https://github.com/michaelforney/swc

ommunist 13y ago

For this kind of thing Stal.in is a better domain name.

nathell 13y ago

One useful set of gcc flags to consider when building a statically-linkable library/executable and aiming to reduce executable size is -Os -ffunction-sections -fdata-sections -Wl,-gc-sections. This causes gcc to put each function in a separate section in the resulting object file, and the -gc-sections option makes ld strip the sections that are not reachable by calls from main (basically a tree-shaker).

mrottenkolber 13y ago

I like what the guys are doing and would love to try it out, but frankly the page didn't change much for the last two years and all the discussion of strategy isn't worth much without a working distribution with which you can experiment. Furthermore I suspect the scope of stali will be so narrow that I will never be able to run say a CL implementation on it. Pretty much the same as Plan9, I love the design but it's practically useless for me. :(

Ziomislaw 13y ago

Stali currently does not exist, but there are others statically linked distros out there, ie. http://starchlinux.org/ http://starchlinux.org/