Page 4 of 4 FirstFirst ... 234
Results 31 to 35 of 35

Thread: MidnightBSD 0.4 Betters The FreeBSD Desktop

  1. #31
    Join Date
    Oct 2011
    Posts
    224

    Default

    Quote Originally Posted by Luke_Wolf View Post
    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.
    Last edited by n3wu53r; 07-07-2013 at 11:04 PM.

  2. #32
    Join Date
    Nov 2011
    Posts
    267

    Default

    Quote Originally Posted by brosis View Post
    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:
    Code:
    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"?

  3. #33
    Join Date
    Jun 2011
    Posts
    837

    Default

    Quote Originally Posted by n3wu53r View Post
    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.

  4. #34
    Join Date
    Jan 2013
    Posts
    525

    Default

    Quote Originally Posted by brosis View Post
    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?

  5. #35
    Join Date
    Oct 2011
    Posts
    224

    Default

    Quote Originally Posted by Luke_Wolf View Post
    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.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •