61–70 of 99 posts
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.
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…
I remember, but these days the parallel to working set size (depending on the app) is fitting things in cache, or at least cache-awareness -- which some people aim for, but is largely an ignored issue. Page thrashing versus cache thrashing. An issue both back then and today is potentially that dynamic linkage often ends up using an indirection table, unlike static linkage with simple fixups, which then adds at least…
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.
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
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).
They missed a chance to call a project 'Stalin'.
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."
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.
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…
that one paragraph... if i were you i'd be wishing i could edit that comment! you most certainly do not "cut down on file load time." the linking process is a complex task, especially if it's to be performed with any efficiency. i remember when starting a large dynamically linked executable was a glacial process on linux, far slower than the time necessary to read the entire executable from disk. no sensible system l…
I'm no kernel hacker, but doesn't that make the GP argument better?
It would be almost like static linking?
If code is compiled against a shared lib which always will be at the same address in virtual memory, a linking setup could be cached. (And redone if there is a new version of the library, of course.)
(I realize that caching this symbol table won't be a totally trivial change.)
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. :(
Earlier quoted context omitted.
that one paragraph... if i were you i'd be wishing i could edit that comment! you most certainly do not "cut down on file load time." the linking process is a complex task, especially if it's to be performed with any efficiency. i remember when starting a large dynamically linked executable was a glacial process on linux, far slower than the time necessary to read the entire executable from disk. no sensible system l…
>>the linking process is a complex task, especially if it's to be performed with any efficiency. I'm no kernel hacker, but doesn't that make the GP argument better? It would be almost like static linking? If code is compiled against a shared lib which always will be at the same address in virtual memory, a linking setup could be cached. (And redone if there is a new version of the library, of course.) (I realize that…
Nope. Dynamic linking is done each time the program is loaded - the kernel calls out to the dynamic linker to open shared libraries, resolve symbols, create jump tables & the like. Static linking is done once (at compile/link time). When you execute a statically compiled library, the kernel just loads the text, data & bss into memory and more or less starts executing main(). Much, much simpler, although you lose the ability to do things like ASLR.