>Stali, which is built with statically linked binaries for speed and compactness, upends traditional ideas about how a Linux distribution should work
>The first public version of Stali, a Linux distribution built to be as fast and small as possible, has been released after several years of work. This first release of the entire Stali OS fits into a 34MB ISO
>Stali stands for static Linux, with "static" referring to how all binaries in the distribution are built statically against their libraries. Any routines in the library required by the binary are copied directly into the binary itself, instead of being linked to a shared copy of the library used by multiple programs.
>Stali's project head, Anselm R. Garbe (a developer currently working at BMW and creator of the DWM window manager), believes static linking works out better for most common use cases. The most obvious benefit is that static binaries have a smaller memory and on-disk footprint. Static binaries also claim to be faster, although there are no benchmarks as yet to show how Stali performs against other distributions.
>Another claimed about static linking is that it increases the stability of the binaries in question. They're less likely to break if shared libraries are updated, since those binaries don't have dependencies on them -- something Garbe believes is good for the long-term maintainability of the system. He also claims this approach minimizes attack vectors.
>Other changes to how traditional Linux distribution work are even more radical. For one, there's no package manager; instead, all updates are pulled from upstream by way of git. Also, the controversial systemd startup system isn't used; rather, Stali has its own sinit utility -- also statically linked -- that handles the job. Kernel modules aren't supported either, which is something of a requirement under static linking.
http://www.infoworld.com/article/3048737/open-source-tools/stali-distribution-smashes-assumptions-about-linux.html
Yup looking forward to this.
Basically a suckless.org OS.
>It's true
stali is not dead and not vaporware? Am I dreaming?
Gotta try that.
Why didn't he fork OpenBSD?
>>54335472
b-but I thought static linking used more space because several binaries would unnecessarily duplicate code, especially for standard library functions
maybe I am just a retard like my psychiatrist said
>>54336335
It does use more space. This is only a real problem though when you use shit libraries that do not work well with statically linkage.
That's why the use musl, which works super well for this stuff.
>>54336359
>It does use more space
then how is it so small?
>>54335472
>creator of the DWM window manager
distribution discarded
>>54336368
Their ISO is only 34MB because it hardly contains anything at all.
>>54336368
All the libraries are written by suckless autists, so they're really tiny
>>54336395
>>54336377
so would it be smaller or bigger if it was dynamically linked?
>>54336335
>I thought static linking used more space because several binaries would unnecessarily duplicate code, especially for standard library functions
It does, but really, how much space do your executables take up these days? How much RAM? How much space and memory is instead used up by active data structures or assets that have nothing to do with the executable or libraries?
>>54336405
The same arrangement of software would result in a smaller ISO if it were all dynamically linked. But again, what exactly are you saving?
>>54336405
It would be even smaller obviously.
>>54336405
slightly smaller
Looks OK.
>>54336429
>what exactly are you saving?
well I mean they're already going for an autistically tiny iso
why not just make it autisticallier tinierer?
Smaller binaries?
I've always been taught to think in terms of libraries first, especially in C-language design classes. When did this change? When Unix started experiencing some kind of DLL-hell thing?
can it run cmatrix?
>>54336449
They're not going for austistically tiny disk space.
They're going for autistically tiny memory usage.
>>54336454
>-rwxr-xr-x 1 root root 124K May 2 16:55 /bin/ls
hmm
>>54336449
Statically linking is simpler. You also save the ldd overhead at runtime.
Also it's not about how big the ISO is, it's about the size of the individual programs. They want them to load fast.
>>54336335
>Like I toll you yesterday I'm not your doctor, he is in the font buiding, I'm a psychiatrist you need a different kind of doctor.
More.
>34MB
So, I'm assuming it's quite literally GNU/Linux.
As in, that's a description of all the software in the distro.
>>54336449
I don't think a tiny iso is the goal. It's only tiny because there's fuck all on it, and there's fuck-all on it because they hate most software.
>>54336466
Static linkage does the exact opposite of reduce memory usage. It does increase loading speed but in both cases the difference is insignificant on modern systems.
Their point appears to be the elimination of dependency hell.
>>54336477
-rwxr-xr-x 1 root root 59K May 2 11:10 /bin/rm
lrwxrwxrwx 1 root root 4 May 2 16:02 /bin/sh -> bash
(i.e. -rwxr-xr-x 1 root root 773K May 2 11:32 /bin/bash)
-rwxr-xr-x 1 root root 128K May 2 14:30 /bin/cp
-rwxr-xr-x 1 root root 23K May 2 08:40 /bin/which
>>54336489
It also helps that the libraries they're linking against for the most part are meant for embedded use, hence tiny.
Embedded libs may lack vital functionality required for certain packages, but if you're building everything static anyway you can just use the full-blown lib for those particular apps only.
>>54336449
Because noone that autistic likes dynamic linking.
>>54336459
>When did this change?
Never, you just had a shitty education. The idea that libraries are some magic solution to writing real code is a myth perpetuated by people who think that all problems no matter how trivial are best solved by breaking them down into pre-solved problems and plugging in the answers in the right order, regardless of any holistic optimizations that could be made.
>>54336502
>59K for an ELF that does nothing but call `unlink`
What the fuck, suckless?
>>54336440
>>54336438
Not necessarily. It's possible that lots of libraries are only used for one tiny bit of code in each, and everything else in that library is not used at all. In that case, including the library as it is and dynamically linking to it would result in much larger ISO.
>>54336542
But they are still using libraries, just statically rather than dynamically linked.
>>54336564
that's from arch, should have mentioned
was just posting to compare to the stali ones that other guy was posting
>>54336570
That scenario becomes vanishingly unlikely with any reasonable quantity of software on the disc.
>>54336588
That's just your speculation.
>>54336564
It's 25.9K, not 59K, but still. How do 40 lines of code (http://git.suckless.org/sbase/tree/rm.c) turn into two dozen kilobytes of code?
The current version of the stali ISO is 24MB in size and is essentially just a bootstrap disk. You'll have to download your software once you have the basic OS installed.
>>54336624
>#include "fs.h"
>#include "util.h"
>>54336564
>>54336624
It does not just call unlink. Think about the r option.
>dwm
When will these suckless tards with their shitty opinions die?
lame, there's 4mb, 10mb, and 23 mb full blown distros with a graphic web browser etc, that guy should stick to making terminal styles and window managers
>>54335472
>OS suddenly takes 10 GB more to download for any install
>System updates are gigantic
Fuck this shit.
what about licenses and suckless? GPLv3 I guess
>>54336690
MIT/X
>>54336651
Are you honestly telling me it's acceptable for a simple recursive function to blow up to 20kb in size?
Ok so the OS is very very minimal, has less attack openings, and will run fast because of how slimmed down everything is. Wonderful. What makes THIS OS better than other minimal Linux distros? What's the big deal? I mean a very tiny OS size is great, but in the tech world where 1TB drives are the norm in everyday PCs, what benefit does it offer?
Is this made for something else? Car ECU, embedded systems? Etc? I'm a noob with this so while interesting, I don't see what's so special.
>>54336741
You need to link the file and directory handling libraries, dingus.
>>54336695
cool, we need Stallman's but you should be free to do use code and close yours
>>54335472
>Bug found in libc
>Redownload entire OS and all installed programs
Right.
>>54335472
lol this article sounds like it was written by a college freshman
>>54336761
>file and directory handling libraries
What? You call unlink() with a string. If it's a recursive rm, you call getdents() on the string and unlink() what's returned, recursing first if it's a directory.
What part of that involves 'file and directory handling libraries'?
>>54336824
it sounds like he just replaced some restaurant review with STASI Linux
>>54336827
http://git.suckless.org/sbase/tree/libutil/recurse.c
http://git.suckless.org/sbase/tree/libutil/rm.c
It's not that trivial.
>>54335472
has its' own SHIT utility ???
>>54336852
You need a new monitor.
>>54336741
>>54336827
The -r option calls glibc recurse(), which in turn calls other shit like readdir(), and so on.
You want to use getdents()? Well okay, but you'll need to code the recursive function yourself because rm uses recurse().
>all these stupid claims
>I'm just gonna claim the advantages of dynamic linking are actually of static linking
It's like watching a good lawyer trying to spin things.
>>54336827
>getdents()
Not POSIX.
>on the string and unlink() what's returned, recursing first if it's a directory
You going to code your own string handling functions too?
autis stalin
>>54336929
>POSIX
Who cares?
>>54336957
>sbase is a collection of unix tools that are inherently portable across UNIX and UNIX-like systems.
>>54336889
>glibc recurse()
>glibc
kek.
http://git.suckless.org/sbase/tree/libutil/recurse.c
>>54336929
>Not POSIX.
readdir() then. Same shit just slower.
>>54336851
>100 more lines of code
So how does 147 loc become 20kb?
>>54336957
>>54336972
You'd literally have to rewrite the whole utility suite and toolchain and make it less portable to accomplish some dubious space savings.
That's assuming you can actually write code that turns out smaller than the existing use of libraries.
>>54336741
No, I'm explaining how the statement that states that the code only calls unlink is incorrect.
>>54336998
>So how does 147 loc become 20kb?
It doesn't stop there. Look at what readdir calls, and then what that calls, etc...
>>54336972
>UNIX and UNIX-like systems
Literally shit nobody cares about.
Supporting all that legacy crap is the source of unending headache. Problems are gone as soon as you simply adopt Linux and forget about supporting some worthless legacy architecture only a bunch of employees at some company that isn't paying you care about.
>>54337017
Linux, consider it STANDARD!
>where have I heard this before?
>>54335472
Like with a lot of things, Suckless has gotten a few things right:
>simplicity helps things to be maintainable
>any dynamically linked code is untrustworthy and nigh impossible to use with setuid safely
>versioned symbols are bullshit
>the FHS is convoluted
>a lot of software these days is bloated as fuck
And quite a few more things wrong:
>static linking uses more space and means you can't easily update a low level library
>the suggested directory tree doesn't scale beyond a simple desktop system
>simplicity is not a panacea, and eventually you will have to create large systems
>C is a shit tier bug prone language
>recompiling to change configuration will never result in programs that non-developers can use effectively
>sinit is classic NIH syndrome
tl;dr elitism and worse-is-better purism still sucks
>>54335472
>statically linked binaries for speed and compactness
I can understand speed, but dynamically linking stuff usually results in lower overall size.
>>54336998
>>54337016
recurse() also does a lot more than just call readdir()
>>54337017
>If you abandon standards and jump on the latest fashion trend, I promise all your headaches will go away.
Yeah, for about a week.
Then they come back a hundred fold.
One of the most common discoveries in programming is that you are twice as retarded as you think you are, closely followed by the discovery that your ancestors are only half as retarded as you thought they were.
>>54335472
/g/ discussing real tech and non-shillware?
Woah
>>54337104
Yes, the invention of UNIX signals is surely a feat of great sages and archmages, perpetual bastions of knowledge and wisdom. So perfect that endless attempts to fix it have never been made. And Linux is not the only platform with signalfd function.
What could I possibly say to some guy who thinks Linux is the latest fashion trend? Go write code that supports GNU Hurd or some shit.
>>54337016
>It doesn't stop there. Look at what readdir calls, and then what that calls, etc...
It doesn't matter what readdir calls because readdir is a syscall.
>>54337078
It's still only 100 loc. The 4 or 5 string functions that it uses should be tiny, so the only real explanation for the size is a stupid-huge printf implementation (which makes some sense since musl's own demo page shows that a printf("hello world") type program runs up 13kb: https://www.musl-libc.org/how.html) and the (trivially avoidable) malloc call.
>>54337067
>C is a shit tier bug prone language
C is an absolutely fantastic programming language, for a very small set of problems. If your overall goal is something larger than manually twiddling bits in memory, you probably shouldn't be manually twiddling bits in memory.
>>54337148
UNIX sages were pretty shit, honestly. Now Multics, that's some deep magic.
>>54337167
It's still shit for that, and will still result in longer dev time and buggier programs compared to, say, Ada. The only class of problems for which C *is* barely suitable are those that can be expressed in about 500 lines or less. Much like most shell script languages.
>>54337193
Is it common for people to shit through the mouth wherever it is you live?
>>54336454
>>54336469
ls gives you the size of the filesystem node not the sum of all the files inside it.
Usedu -hs /foo/barto get the size of a dir as you would expect.
can it use pacman plz
>no systemd
Dropped. Sometimes it's cool to go against the stream, you know, but this is literal suicide. DOD.
>>54337160
How exactly do you propose to avoid calling malloc? I'm genuinely curious.
>>54337255
Is systemd good now or what?
>>54337269
It always was, /g/ just jumps on neckbeard bandwagons
>>54337269
systemd has always been good. It's just that the contrarians on /g/ loved to shitpost about it.
>>54337276
>>54337297
Having all my services subsumed into a monolithic chimera is delightful and certainly not asking for trouble.
>>54337315
>I cannot keep up with abstraction
Found the retard, boys.
>>54337276
>>54337297
Huh, last time I checked it was literally responsible for Windows-like begging for post-update reboots in Linux
>>54337330
i have no idea what you're talking about
>>54337269
Systemd is good to use but it still smells like political software.
>>54337330
Of course you need to reboot the system (some time in the future) after updating your init system. Just like you need to reboot the system (some time in the future) after you updating your kernel.
Difference is that people are fucking retards and so UBANTO decided it was a grand idea to tell people that the system needs a reboot right now.
>>54335472
It's almost like Java was right all along
>>54337398
You probably do need a reboot immediately if half your software is rolled into your init system.
>>54336485
>GNU/Linux
I don't think it uses any GNU software (maybe GCC). But they don't use glibc or GNU coreutils.
>>54337424
Unless you're doing changes to your init system (enabling/disabling/stopping/(re)starting services, ...) you really don't.
>>54337419
java is perfect
leave it alone, asshole
>>54337315
>hurr durr durr muh monolith!
For the millionth time: systemd is not monolithic.
http://0pointer.de/blog/projects/the-biggest-myths.html
Imbecile.
>>54337398
>Of course you need to reboot the system (some time in the future) after updating your init system
Only if the actual init (the PID 1) changes.
Which for the tiny ancient binary that is sysvinit, is almost never.
>>54337464
It is. Infact the library bundling is a sound idea, and it was a matter of time before C embraced it, expecially with memory being this cheap. It's not the 70s anymore.
No need to be rude, friend.
>>54337470
For the trillionth time: systemd is monolithic
http://judecnelson.blogspot.de/2014/09/systemd-biggest-fallacies.html
Moron.
>>54337264
Lines 47-51 of recurse.c call emalloc (which wraps malloc):new = emalloc(sizeof(struct history));
new->prev = r->hist;
r->hist = new;
new->dev = st.st_dev;
new->ino = st.st_ino;
This code simply adds a node to a linked list which keeps track of which directories have already been searched, presumably to avoid infinite loops when trying to delete a directory cycle. It's necessary because certain filesystems (notably sysfs) permit directory cycles, and these filesystems (notably /sys/bus) are (un)reasonably common.
However, there's no reason you couldn't just allocate the linked list node on the stack, since it gets freed at the end of the function call. Given that the stat structs are already stack-allocated, there's really no reason not to throw on the additional 8-16 bytes of overhead for a stack-allocated linked list and save closer to 32 on the heap.
>>54337526
That begs the question, then, of why is it not already doing that?
>>54337511
>systemctl needs systemd so it's monolithic
So if xrandr requires X.org that means X.org is monolithic?
And if Firefox depends on glibc that means the system is monolithic?
Arguments from a true pedantic autist!
>>54337587
X.org is monolithic, yes
Firefox relies on a standard C POSIX library, you can also build it with musl for example.
>>54337587
systemd, xorg and the kernel are probably the most monolithic pieces of your system.
>>54337587
X.org is monolithic.
glibc doesn't depend on Firefox, and Firefox doesn't necessarily have to be built against glibc.
Why so defensive?
>>54337632
>glibc doesn't depend on Firefox
systemd also doesn't depend on systemctl to be there.
>>54337646
Cancer doesn't need a human body to thrive, doesn't mean we should embrace that too.
>>54337646
systemd loses functionality that way, glibc doesn't
>>54337646
Yeah, because systemd is just so handy without it...
Also systemctl has no function whatsoever outside of systemd.
>>54337470
>b-b-but lennart told me so
Holy shit, if you can't tell how his arguments are complete crap, you should kill yourself.
>>54337560
>begs the question
>To beg a question means to assume the conclusion of an argument—a type of circular reasoning.
>why is it not already doing that?
Insufficient autism?
>>54337560
ask them
>>54337470
>systemd can't be monolithic, our one source tree compiles to over 69 binaries
It's like poetry.
>>54335472
So is this the new base for >logos?
>>54337779
>make a huge shared library with all my shit
>make tons of tiny binaries for every small aspect of it
non-monolithic programs are so easy since I enrolled in the Lennart School of Software Design.
>>54337255
>>54337276
>>54337297
>>54337470
>>54337587
>>54337646
systemd shill pls go and stay go
>>54337483
The correct sort of move is to ditch sysvinit in favour of something like runit.
>>54338358
runit can run on top of sysvinit's PID 1.
So can other daemon managers.
Really the only awful thing about sysvinit are the sysv-style init scripts. Which you don't have to use. For example Slackware uses more BSD-style init scripts.
>>54337442
Which userland do they use then?
>>54338697
musl and their own coreutils afaik
Up!
>dwm
Meeehhhhh
>>54337470
>At the time of this writing, journald can corrupt the log simply by crashing, putting the log into a state where it is impossible to tell whether or not it was corrupted or tampered with (the developers have known about this for years, and they don't think this is a bug).
Jesus christ
>>54342402
Lennart is a fucking faggot piece of shit!
>>54336330
No need to, OpenBSD is already great.
>>54336746
>Car ECU
those aren't allowed to be standard computers, standard computers are too slow
>>54336815
>bug found in glibc
>Redownload entire OS and all installed programs
>>54343327
>using glibc
>using anything GNU for that matter
Found the problem.
>>54337067
>>C is a shit tier bug prone language
Stopped reading. Maybe people will take you seriously when you learn to shit in a toilet.
So what do I do with a Linux/nonGNU system? How do I install packages? Do I have to compile everything myself?
Is this 1995?
>>54343368
Not the same guy.
Just wanted to say that, while I do agree that other low-level languages like Pascal are much better at avoiding buffer overflows than C, all you really have to do is usestrlcpyandstrlcat, and use them properly.
>>54343472
RTFM. You use git to install shit/update.
Package management really isn't that hard, and people only think it is because some distributions out there overcomplicate it.
>>54344379
>Pascal
Forced runtime checks are shit and hurt performance. You can't stop every possible buffer overflow at compile time either unless you cripple the language. C is perfectly fine if retards aren't getting their mitts on it.
>>54335472
>126+ replies
>not a single mention of slinky
How can you talk about static linking on a modern OS/environment and not talk about slinky?
(for reference: http://slinky.cs.arizona.edu/ )
>>54344468
>a slight modification of the Linux kernel
So why isn't it in mainline?
Czechmate.
>>54344515
It's an academic `slight`.
Regardless, the technology is definitely something that ought to at least be acknowledged if you're building a linux distribution based entirely around static linking.
>>54344467
>C is perfectly fine if retards aren't getting their mitts on it.
I know, that's what I said.
Slitaz is basically as big as that and works better/Has a graphical interface
>>54343368
>>54344467
It's always hilarious to watch a ctard's reaction when you dare to insult their religion. How's the array decay treating you these days?
>>54344379
Pascal is okay, but Ada is better. And the issues with C run a lot deeper than the unsafe standard library string functions.
>>54349869
>decay
no such thing in c
>>54350045
>not knowing what happens when you pass an array to a function in C
>not even googling the term to avoid seeming like an ignorant pleb
At least make some sort of effort.
>>54335472
I'll sit here and wait while the project maintainers realize the downsides of static linking.
>>54336489
>It does increase loading speed
Static linking can even decrease loading speed since dynamically linked libraries are probably already in memory. (For something like e.g. KDE stuff)
>>54335472
>Another claimed about static linking is that it increases the stability of the binaries in question. They're less likely to break if shared libraries are updated, since those binaries don't have dependencies on them
Three things wrong with this statement:
1. Static linking saves you from some ABI mismatches, but it doesn't save you from protocol mismatches.
2. In a statically linked world, it's possible to have many different programs that use _different_ versions of some common dependency, which is just as bad as using a version of a dependency that your program wasn't equipped to handle - if not even worse.
3. Static linking can decrease stability, because things like ABI changes, security updates, bug fixes or other issues affecting libraries will potentially not be synchronized across your system. If you update, say, OpenSSL with a critical emergency patch, then in a dynamically linked world everything will benefit from the security fix. In a statically linked world, the maintainers now have to rebuild absolutely every single package in the entire package set that uses OpenSSL.
tl;dr there are VERY good reasons why we use dynamic linking instead of static linking today, and this meme hipster distro that will die in a year won't change that.
>>54336542
>The idea that libraries are some magic solution to writing real code is a myth perpetuated by people who think that all problems no matter how trivial are best solved by breaking them down into pre-solved problems and plugging in the answers in the right order, regardless of any holistic optimizations that could be made.
A) this still uses libraries, just not dynamically linked, as >>54336582 points out.
B) in the vast majority of cases, it is actually best to break a problem down to its component pieces, use existing solutions to what pieces you can, and make new solutions to the rest, rather than reinventing absolutely everything. Sure, for some bits you can come up with a better solution, and if it's not more trouble than it's worth, do that. But using existing solutions is the best default.
>>54336330
Because openbsd is the least secure operating system in the world.
>>54336593
Facts are not mere speculation.
>minimizes attack vectors
So if a vuln is discovered in a library, anything that uses that library has to be recompiled instead of just the shared object being updated.
>>54336746
>has less attack openings
Significantly more actually.
> and will run fast because of how slimmed down everything is
May or may not be the case, since in a real running system, the same library will be in ram many times, which can cause slowdowns.
Is this a shitty version of Bedrock Linux?
So can I put DWM on this bitch and start shitposting?
>>54351487
write code and statically compile it
>>54335472
> no package manager
So what's the point?
I would love such a distro, but only if it would have the same features as a desktop or server distro, like Debian or whatever.
>>54351943
can also work the other way around, update to a shared library introduces a new vulnerability and every dependent binary is being affected
Anyway, what is meant by "minimizes attack vectors" is that dynamic linking introduces a great deal of complexity and additional attack methods. Look for example here: https://www.nth-dimension.org.uk/pub/BTL.pdf
> shared libraries:
> Can't update library X because it breaks program Y, so you're stuck with a vulnerability for every program you have that uses it
> Statically compiled libraries:
> Every program that needs package X needs to be updated when there's a vulnerability in library X, but at least you actually can update most of them.
>>54354583
Let alone compatibility issues, like you upgrade X library that breaks Y and Z.
And who cares about package sizes, or download?
We have fucking gbps connections (except the US, lol).
>>54354598
Am I the only who bothered to read the faq?
>Aren’t statically linked executables huge?
>It depends. Linking a stripped hello world program with glibc results in 600kb. Linking it with musl in about 7kb. Linking OpenBSD’s stripped ksh, which will be stali’s default shell, statically against musl results in a 170kb binary – linking it dynamically against glibc results in 234kb. Of course this won’t scale with every binary, for example we expect surf being about 5-6MB in size, but the normal Unix userland will be rather small, compared to most popular linux distros.
>>54354639
I did read the FAQ but they only have a small range of packages compiled/ready.
If you were to statically compile your entire userland - you would have to use glibc and other bloated stuff. I doubt you can use minimalistic replacements for everything.
That's what I meant.
I would not mind if a full Ubuntu 16.04 desktop install would take up 10-15-20 gigs of space.
A 128gb SSD is piss fucking cheap now.
And you could just literally install and run any kind of application without the need of compilation by hand and shit.
>>54354663
>I doubt you can use minimalistic replacements for everything.
It's suckless, they'll try.
>you would have to use glibc
You can take a look at other musl-based distros like Alpine, they even got Firefox working without glibc.
>>54354697
>It's suckless, they'll try.
That's why I know this will never be a new alternative. ;_;
It would be great if someone would just take the Ubuntu archive and statically compile that.
And the DEB would only contain the blob/elf.
>>54351968
>Significantly more actually.
None, practically, since the only things in the distro that touch the network are git and the kernel itself.
>Static linking causing memory exhaustion
That hasn't been a realistic problem on desktop machines for over 30 years, anon.
>>54355032
>since in a real running system, the same library will be in ram many times, which can cause slowdowns.
Static linking (with optimization every compiler supports) does not include the whole library in the binary, only more or less the parts that are actually used. So only that gets loaded into memory - with dynamic linking you always have to load the full libraries it depends on.
>>54354639
>small well written libraries are smaller than bloated crap
Well stop the fucking presses.
>>54343368
c is shit, no use defending it
if ada had won, we would be arguing on mars now
i dislike the current approach linux distros are taking ("EVERYTHING NEEDS TO BE DYNAMICALLY LINKED!") because it's a fucking hell to maintain.
static linking has its downsides as well.
use dynamic linking for shit where there are actually benefits (libraries likely used by most of the software on the platform) and static linking for everything else.
either way, the current state we're in is horrific and your gods, the creators of unix, john carmack, and several others have realized that.
package managers are not a complete solution to the problem, you still gotta consider dependency hygene.
keep in mind that pretty much every large company that has to manage dependencies at a large scale uses containerization, which is a lot more extreme than static linking.
>>54356031
>still gotta consider dependency hygiene
For that, we need to ditch the convoluted FHS layout. Gobolinux and NixOS have been making good strides in that direction.
I personally think static linking for trusted executables (eg setuid) and dynamic linking for everything else.
>>54356065
>I personally think static linking for trusted executables (eg setuid)
I would link all basic utilities (coreutils and few others) statically. It's no fun when a botched glibc upgrade makes your setup useless.
I'm already keeping a static busybox binary handy for that case.
>>54354583
> Can't update library X because it breaks program Y, so you're stuck with a vulnerability for every program you have that uses it
Only if your package manager is shit.
Try portage or nix, they can let you have multiple versions of dynamically linked libraries on your system (nix) or just preserve older versions needed for compatibility with programs that don't work with the newer versions (portage).
>>54356820
>Try portage or nix, they can let you have multiple versions of dynamically linked libraries on your system
Great, let's make overly complex package managers to deal with the problems of overly complex dynamic linking.
You should be a web dev.
>>54356839
>Why have the best of both worlds if you could have the best of none?
suckless ideology general
>>54356911
>best of both worlds
that's like calling a man with tits sutured on top "best of both worlds"
>>54355032
>vuln found in a lib
>must wait for maintainers to recompile against a more recent version of the lib every single package
>can't just download the fixed library and go
>less vulnerable
>>54355032
>imfuckingplying memory exhaustion
>what is cache
Only retards think stali is a good idea, CONFIRMED!
>>54356065
The best model is the qubesos model TbH. qubesos running over something light like openvz (i.e. without hardware virt), or even better, in a plain chrooted, cgrouped, namespaced environment, would be perfect for regular use, while using a xen or kvm backend for true secure use would remain an option.
>>54357028
What are you talking about?
The overhead of running something dynamically linked alone could already easily fill your cache.
>>54357746
Lol'd
ITT: People that argue about dependency management on the basis of their personal experience from managing a Linux desktop machine.
Sorry to burst your bubble, but pretty much every major company is using some sort of container for dependency management, which takes the concepts of static linking to the extreme.
Why do you think they do that? Because dynamic linking is so great compared to isolated environments?
static linked binaries are both a sysadmin and programmers nightmare
>>54359794
>t. neither a sysadmin nor a programmer
>>54359794
this is so wrong it hurts
>>54358543
>why do you think they do that?
Because it's cheaper to use more hardware to virtualise everything than it is to pay some programmers to rewrite the operating system to conform to the principle of least privilege.
>>54359794
bullshit. I really prefer it static-linked. Portability is the key.
>inb4 muh security, if one library gets hacked then you need to replace all the programs instead of just one library
you know what fuckers, I don't give a shit. Just because one single library is insecure (lets say one that is used by openssl and maybe vlc, dunno) then I am updating just the library, right. If everything is static-linked, I am just updating openssl. Why? Because vlc -even if the library is insecure- could just be hacked if I were stupid enough to let someone on my pc that uses it. IF anyone is already on/in my pc, then hell broke lose anyways. Kek
>>54359994
>one that is used by openssl
openssl is a library
>>54359989
Which is another argument for self contained applications.
>>54359879
windcuck detected, perhaps pcbsd
>>54359837
>clearly 20
>>54360041
I want deployment and maintenance to be as painful as possible!
>>54360094
if you mean 20cm dick then yes
>>54360097
point and click installers are great to sell games to /v/
Carmack can fuck off
>>54360026
yeah I guess I fucked that up. OpenSSH. Sorry.
Why care about saving some MBs in this day and era?
>inb4 servers
Im sure theres already software tailored to their very particular need, there has to be.
>>54337255
Lennart pls go
>>54336282
Don't they already have one?
>>54349869
>array decay
If you're that fucking worried about dimensions in a fucking array you can either pass a length parameter or make your own hokey fuck Array struct with the pointer and dimension (which your dumb fuck languages do anyways).
