MidnightBSD 0.4 Betters The FreeBSD Desktop

[n3wu53r]

Okay I suppose that's an answer for statically linking in general. I certainly have used a form of static linking for bundling the actually valuable resource files into the binary so that they're not so easily taken and messed with, but... what I don't understand is why you'd need to statically link in the Qt libraries in that situation. Certainly your DRM related libraries should be statically linked in, but Qt? Do note this is a serious question, you've got me curious about the usecase.

According to this answer the LGPL can have static linking if you provide your object files.
http://stackoverflow.com/a/2277328

Edit: Although giving all your object files might not be desirable if you also are working with DRM.

[Ibidem]

Meh, its Linux and it has no BSD license, just GPL.
If it would be windows, it would be EULA.
If Solaris - then CDDL.
Or any proprietary OS that just gives a damn about BSD, simply stripping its code. Like windows.
And how about Linux+GNU userland+Emacs+W3 on top of it? Possible.

Either way, I claimed that BSD is parts-bin license and Cthulhux asked if my OS is without BSD code. Of course, it is without -- cut it, change it, copy paste it, rename it. Thing is - EULA protects the contents and restricts license modifications; GPL protects the contents and restricts license modifications. Parts bin license? How about companies releasing everything via BSD, not connected to BSD or partially (interfaces), but just "dumping"? Its like giving away the work. Never claimed if its bad, but its sure bad for a company. Its like carrying water in a sieve. Hence BSD is not a stable spot to build upon. Hence BSD OS is always awkward, incomplete or outclassed. Usually by proprietary equivalents.

1) As I said to someone else elsewhere, could you please check what you can build if you remove all glibc and kernel headers containing the BSD license notice?
Also, please remove sudo, ssh, mandoc, the groff mandoc, me, ms, and other BSD-derived macros, mdoc, tcl & tk, ldap, libtirpc, and any other permissively-licensed packages containing code copyright by "the Regents of the University of California."
Also post the output of these commands:

head -n 30 /usr/include/linux/quota.h
modinfo aes_generic

;-)

2) BSD is permissive, but not unrestricted like PD. Removing or changing the license and copyright notice is not permitted.

3) In theory, I'd be inclined to agree with the "never said if it's bad, but it's sure bad for a company" (to distribute their own software under).
In practice, I'm more dubious...was it RHEL+Fedora and RHEL clones, OpenMoko, or Android that had more systems deployed?
OK, that may be unfair. But an observation of all FOSS indicates more that success is sporadic than that BSD is worse than GPL in practical terms.
And a look at the features of Linux vs BSD seems to me to indicate that Linux has a superiority in some areas to BSD, but I don't see anything earthshaking and I have on occasion seen areas where BSD seemed better. Not positive what all of them were, but a few I can think of...NetBSD appeared more responsive under load than Linux (single core PIII, 2 packages building, desktop still seems to be perfectly responsive); the state of ZFS (some time ago); BSD had pf jit on x86 and amd64 long before Linux BPF got a JIT for amd64 (afaict, there is no bpf jit for 32bit x86 linux); crunchgen; more POSIX-conformant tty support (glibc on linux still doesn't support one of the flags mandated by POSIX, which will reset state to sane defaults)--sorry I don't have more details, I read about this a few months back; and kernel ABI stability.

4) What do you mean "BSD is not a stable spot to build upon"?

[Luke_Wolf]

According to this answer the LGPL can have static linking if you provide your object files.
http://stackoverflow.com/a/2277328

Edit: Although giving all your object files might not be desirable if you also are working with DRM.

yeah, and so my question remains this: What is the usecase for statically linking in the Qt toolkit? A usecase has been shown for statically linking in general but what about statically linking Qt which is what Brosis's complaint was about.

[intellivision]

Its obvious to me why they used ?toil?, not because its any "good", only because its "BSD" - that's moronic, unless its just for laughs.

Can you link me to your proof of this?

[n3wu53r]

yeah, and so my question remains this: What is the usecase for statically linking in the Qt toolkit? A usecase has been shown for statically linking in general but what about statically linking Qt which is what Brosis's complaint was about.

Ease of deployment, and portability of the same binaries across multiple systems?
I think you may also want to static link to save resources, when compared to dynamically linking bundled libraries (aka, your not going to be linking to system libs, or system install of Qt even if you are going dynamic).

I've quoted some noteworthy slides from this link:
http://dl.suckless.org/stali/clt2010/stali.html
Slides 6-24 are the ones that concern static linking.

http://dl.suckless.org/stali/clt2010/static-linking.png
http://dl.suckless.org/stali/clt2010...ic-linking.png

Different kinds of static linking

Smart static linking
Linker links/extracts only those object files (from an archive) that expose required symbols
This has implications on the size of a static executable
This is the usual case nowadays
Dumb static linking
Linker links full blown archives
Very unusual nowadays, was usual back in the 60s when people kept things in simple and clean states due to hardware limitations

Joe sez static executables are huge!

Why are static executables huge?
Library bloat! glibc is a disaster - simple hello world results in 600kb overhead for no reason
Use less bloated libraries, start here:
uClibc
dietlibc
bionic
even BSD libc is a lot better than glibc
(Not mentioned in the actual slide but I'll add this: http://www.musl-libc.org/)

The 3 most notable slides:

Joe sez static executables consume more memory!

$ file grep
grep: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), statically linked, stripped
$ du -h grep
68K grep
$ file /bin/grep
/bin/grep: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.18, stripped
$ du -h /bin/grep
84K /bin/grep
$ ldd /bin/grep
linux-gate.so.1 => (0xb7850000)
libpcre.so.0 => /lib/libpcre.so.0 (0xb780c000)
libc.so.6 => /lib/libc.so.6 (0xb76c5000)
/lib/ld-linux.so.2 (0xb7851000)
$ du -h /lib/libpcre.so.0.0.1
216K /lib/libpcre.so.0.0.1
$ du -h /lib/libc-2.11.1.so
1.5M /lib/libc-2.11.1.so

Joe sez static executables consume more memory!

Ok so 68K vs 84K+216K+1.5M = 1836K
Running multiple static greps still only consumes 68K, since the executable itself isn't loaded into memory twice
Does this scale? Yes, for most parts it scales very well
So is Joe wrong? Yes
Even if he'd use a browser, compile time smart linking is still better than polluting the memory with dynamic libraries
Hold on, isn't there paging? Isn't there... sorry, won't go there!

Joe sez static executables start slower (huge, eh!)!

He is completely wrong.
Let's do some minimalist example, dynamic hello world vs static hello world, harness fork()/execvp()'s it 10000 times:

$ LD_LIBRARY_PATH=. ./harness ./run_dynamic
execution time: 1975592 microseconds
$ ./harness ./run_static
execution time: 732704 microseconds
So starting up performance of this static executable is 63% faster than it's dynamic counterpart
Does it scale? Yes

Yes I know they say bloated libs add a bunch of overhead, and these people would probably call Qt bloated (even glib from gnome is on their list of software that sucks http://suckless.org/sucks ).
That doesn't change the fact that if you want the same compiled binary to run across multiple linux systems and be deployed easily, static linking will probably be more resource efficient then bundling a bunch of dynamic libraries into a directory and putting that dir into a .tar or using a .bin installer for distribution. Of course to get the protability advantage you need to static link everything, even the libc, however using a lighter library like musl or uclibc (uclibc is supposed to be glibc source compatible afaik, but is LGPL) removes a lot of overhead as they say.

Although this is a use case for static linking, this still doesn't deal with brosis's complaint, as all this can be done without violationg LGPL. Either give object files, or also make a dynamic version available so you can supply the dynamic version to anyone wishing to relink, giving you lgpl compliance. DRM was the only use case against this, but like you said just static link your DRM libs and do whatever you want with Qt.