I would like to see "static" USE flag in Gentoo for all packages with ability to statically link whole system. Also profiles or env with other libc's would be nice. Dunno why they need to crate new distribution instead of expanding ones that are already there.
Static Linux
51–60 of 61 posts
Re: Static Linux
#52Cool idea. Not enough people seem aware of executable packers like UPX http://upx.sourceforge.net/ though. These are excellent tools to keep the size down when using large static binaries. By compressing the file on disk and decompressing in memory you often wind up with a smaller and sometimes even faster loading (depending on disk IO speed vs decompression speed) package. I got a static Qt binary from 4 MB down to…
Ah, and pklite pro and lzexe from the olden days for winDOwS shit once upon a time. Though the goal should be generating less code. Link in fewer dependencies, reduce features, DRY up duplicate logic and cut LoC. Also compile with -DNDEBUG -O2 -g- and whatever LTO switches are available for whole program optimization if you're statically linking everything together. Also be sure to include static dependencies of othe…
Crunchgen [1] does that static compile, merge and symbol rename trick for you
[1] http://netbsd.gw.com/cgi-bin/man-cgi?crunchgen++NetBSD-curre...
Re: Static Linux
#53Earlier quoted context omitted.
And that feature disparity includes security updates. If a library is updated with a security fix, you'll need to update everything that uses that library to get the fix, rather than just the shared dynamic library.
The tools for updating security fixes should be applicable for the applications just as easily as the libraries. The applications would have to be rebuilt which should be automated. If the library changes anything that causes the build to fail, much better to find that out at that time than to have the failure occur when it dynamically links on end user machines. There would be inevitable bandwidth costs in updating…
There is a tradeoff between bandwidth and local processing in that you may download all updated dependent binaries or just get the new updated file and relink (or recompile) the affected programs locally.
Re: Static Linux
#54One downside to static linking is security vulnerabilities. Say, for example that all the programs on your computer that use OpenSSL statically link. When OpenSSL has a security flaw, you have to not only update OpenSSL, but all of those other programs too.
Re: Static Linux
#55Earlier quoted context omitted.
> I wish Linux would replace dynamic libraries (especially ones referencing specific paths) with a system based on the library's hash. Given this scheme, how would you distribute a security patch? Is each user of the library supposed to re-compile against the patched library? Also, a program A depends on library B and library C v1.1. Library B also depends on C, but v1.2. Which gets used? > More often than not, when…
>Given this scheme, how would you distribute a security patch? Is each user of the library supposed to re-compile against the patched library? No, this is the responsibility of the server which distributes binaries to users via the package manager.
User, as in programmer who uses the library.
Re: Static Linux
#56Earlier quoted context omitted.
>Given this scheme, how would you distribute a security patch? Is each user of the library supposed to re-compile against the patched library? No, this is the responsibility of the server which distributes binaries to users via the package manager.
User, as in programmer who uses the library.
Programmers are used to recompiling all the time. What's the problem here?
Re: Static Linux
#57> 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. I never understood why the authors of dwm thought this was a "nice" feature of configuration via source code.
The other kinds of configuration aren't that much better.
The most common method of configuration on linux is to include a parser for one of many shitty text or markup formats (whatever is currently "hip", so JSON at the moment), then carefully bind each variable you might want to modify to a key/value mapping extracted from the config file - and if you want to keep the sanity of your users, include verbose error messages or even a debugger so they can fix their inevitable typos.
The way configuration works on Windows and Mac is largely the same, except you wrap a GUI around the text file to handle the validation of inputs, which is a slight improvement over text input.
The problem with those input methods is they don't exactly allow you to configure much. You have to decide ahead of time all of the possible variables that one might want to change - and even then, you can't even compute new values to set the variables to, unless you embed an interpreter into your configuration format. As the program grows and gains more features, the configuration format needs amending, and grows uglier - which is what leads to Greenspun's tenth rule. Configuration files have their place - but most of the time, they're used where it'd be best to just have a programming language available.
I don't necessarily think dwm's idea of configuration via C is a great idea though, since they're not interpreting it and recompiling the whole program to make and test changes is a headache. Configuration via source code is the way to go, except it should be interpreted while the program is running, such that you only need to recompile for major breaking changes. Xmonad is configured via source code, but they have a separate process for your configuration, such that when you change it, the config is recompiled and the program relaunched without restarting the whole system. I'd personally opt to embed a Scheme into a WM, but that would probably go against suckless's minimalist philosophy.
Re: Static Linux
#58Earlier quoted context omitted.
That's not all that common Isn't it? Usually distros target their packages to a single library version, and often people run suites (Gnome, KDE, etc) that use a similar set of libraries in their different processes.
Indeed. ldd any substantial GTK app and scroll past the dependencies. They are huge. Most of them are shared across applications. Desktop would be crippled if every app was compiled with the whole stack of X, toolkit and Gnome libraries linked in statically.
I'd argue that libraries like GTK were only allowed to become so bloated because dynamic linking masked their true impact on the system. If static linking were the norm, we'd be using much simpler, cleaner libraries because people would think twice about adding 100+ megabytes to their binaries for basic GUIs.
Re: Static Linux
#59Stali has been in 'planning' for as long as I can remember. At least 4 years.
Re: Static Linux
#60Apart from the general system management advantages of dynamic libraries, they provide an important extensibility/customization mechanism (e.g. https://www.gnu.org/software/emacs/emacs-paper.html for an early mention).
High performance computing systems typically use dynamic linking extensively for that. One example: The hooks for profiling and tool support in the MPI standard for parallel programming pretty much depend on an LD_PRELOAD-type mechanism to be useful. Another: You can cope with the mess due to missing policy on BLAS libraries in Fedora/EPEL (unlike Debian) by using OpenBLAS replacements for the reference and ATLAS libraries; have them preferred by ld.so.conf and get a worthwhile system-wide speed increase on your Sandybridge nodes with EPEL packages.
Anyhow, rebuilding a static system to address a problem with a library ignores all its uses in user programs. The ability to adjust things via properly-engineered dynamic libraries really has a lot more pros than cons in my non-trivial experience. The use of rpath ("ones referencing specific paths"?) is mostly disallowed by packaging rules in the GNU/Linux distributions I know, so I'm not sure where that comment came from, and it tends to defeat the techniques above.