Page 19 of 19 FirstFirst ... 9171819
Results 181 to 190 of 190

Thread: Lennart Poettering Talks Up His New Linux Vision That Involves Btrfs

  1. #181
    Join Date
    May 2014
    Location
    Valencia, Spain
    Posts
    2

    Default sand vs lube

    Note that in result this allows installing not only multiple end-user applications into the same btrfs volume, but also multiple operating systems, multiple system instances
    quotes like this are unhelpful; whatever effort I was making to form a reasonable opinion got shattered right there. That's a usecase of someone looking for trouble; not a problem worth solving. Maybe Lennart just got excited by the possibilities but it makes for a terrible pitch. Locking in on Btrfs early on is also distracting since it's really only about the concept of fs remaps.

    "What the user wants" is pretty airy since Windows/OSX have their fair share of problems but then he talks about helping software vendors with runtime dependencies - which is it? Maybe there's a great project there to solve real problems but there's too much noise to see it. FOCUS please!

    -- p

  2. #182
    Join Date
    Apr 2008
    Location
    Saskatchewan, Canada
    Posts
    462

    Default

    Quote Originally Posted by RahulSundaram View Post
    The emphasis on shared libraries were brought on by the many man months it took to fix a security issue in zlib when static or bundling were more common.
    The great thing about Windows is that zlib is a DLL... but every piece of crap program has its own copy.

    I lost count of the number of zlib.dlls I had to replace on my old XP machine when there was a major security hole a while back.

  3. #183
    Join Date
    Mar 2011
    Posts
    219

    Default

    Quote Originally Posted by RahulSundaram View Post
    Look it up. It is well documented. The packaging guidelines from distributions that advise against static linking and bundling was born from such experiences. Note that this policy usually has several exceptions so the idea of striking a reasonable balance is already implemented. However shared libraries aren't the problem. The lack of standard runtimes across distributions is. Several distributions also patch and introduce their own library versioning downstream
    I had a quick look at a couple of guidelines from different distributions. It does not seem like anyone is demanding an exclusive use of dynamic linking. More like it was formulated in an unfortunate way with some of them. They all do support static libraries even it is just for the cases where no shared library can be build.

    And, yes, it is a problem, because only by pointing at what other distros do is one not looking at what oneself can do. And there will always be some distro that is not going to care about what the rest of the world does and one will always keep running into this problem. The last thing a distro really should to do is to depend on other distros.

    The best chance still is to reduce the number of dependencies, to start working on a standard for those that remain, and to become open to even fully statically linked binaries. The later is not ideal, but when it means a package is available in a large-static form, too, then it has a good chance for the package to become popular beyond its distro and thereby adding to the popularity of the distro itself. This too helps in bringing down the barriers between distros.
    Last edited by sdack; 09-04-2014 at 02:11 PM.

  4. #184
    Join Date
    Apr 2008
    Location
    Saskatchewan, Canada
    Posts
    462

    Default

    No, we don't need to support static linking. Static linking is for idiots, because it means the only way to fix bugs in a common library is to wait for a new version of your app.

    Hey, guess what? I run Linux because I don't want to run an insecure heap of crap like Windows. Please stop trying to turn it into one.

  5. #185

    Default

    Quote Originally Posted by sdack View Post
    The last thing a distro really should to do is to depend on other distros.

    The best chance still is to reduce the number of dependencies, to start working on a standard for those that remain, and to become open to even fully statically linked binaries.
    Well, Linux distros do depend on each other because we are a community and patches etc flow from one distro to another all the time. Distributions already do static linking when required but noone is going to do it willy nilly for all the binaries. That would just import another form of dll hell in Linux.

  6. #186
    Join Date
    Nov 2010
    Posts
    85

    Default

    Quote Originally Posted by sdack View Post
    And in the other thread (on systemd) did I already explain to someone where /sbin and /usr/sbin originally came from.
    After all the modifications imposed by systemd the Filesystem Hierarchy Specification finally began to make sense.
    Before that, we had "configuration" in /etc that was changed dynamically at runtime ( mtab and hosts after updating hostname).
    Additionally, the base system was spread over so many directories that mounting it from NFS was very problematic.

    Systemd enforces a really strict design discipline, but this is exactly what makes a system well engineered.

  7. #187
    Join Date
    Mar 2011
    Posts
    219

    Default

    Quote Originally Posted by movieman View Post
    No, we don't need to support static linking. Static linking is for idiots, because it means the only way to fix bugs in a common library is to wait for a new version of your app.

    Hey, guess what? I run Linux because I don't want to run an insecure heap of crap like Windows. Please stop trying to turn it into one.
    No. You assume that your library and your binary come from different sources when really they come from the same source, the maker of your distro. You are also not supposed to have everything statically linked exclusively. You only statically link the smaller libraries, which are unlikely to be found everywhere and also do not have a dependency count as high as libc or libX for example. When you then have a bug in such a library then you will need to download the binaries just like you would need to download a new version of a shared library. This means somewhat more downloads, but it is not going to be a problem and these will be available on the same day as the fixed library. So then you have a reasonable amount of dependencies and distros can begin with a standardization. But when the tree of dependencies is left wild and untrimmed can you not create a standard.

    And in addition to this, do you offer fully statically linked packages to work around problems until a standard has been found. Yes, I agree with you that such packages are difficult to fix when a bug is found. You then have to drop it and download a newer package. But the point is that it can be used with other distros, too, opposed to not at all.

    Btrfs will only replace old problems with new problems. In the end will one still need to download a package containing binaries and libraries. Btrfs will not avoid the problem of missing libraries when there is no standard. In the worst case would a btrfs volume need to ship an application with all libraries, including libc, to avoid missing ones and version mismatches, and would not be much different from an ELF file of the same size.

    And just to mention it on the side, statically linked binaries run about 5%-7% faster than dynamically linked ones, because these require less or no position independent code (PIC). Gamers are willing to give a kidney for such a bonus and any distro, which does not offer it will get ignored by gamers.

  8. #188
    Join Date
    Mar 2011
    Posts
    219

    Default

    Quote Originally Posted by Mat2 View Post
    Systemd enforces a really strict design discipline, but this is exactly what makes a system well engineered.
    Well, this is now getting idealistic. It needs to work and not cause trouble really. Enforcing strict discipline when most programmers are on average 25 years old or so is of much value to them as alcohol-free beer is, which means if systemd works then they will not care for it, but when it fails is it only a cause for more complaints. So you could have implemented it in Ada, too. It is not a selling point to a lot of people.
    Last edited by sdack; 09-04-2014 at 06:52 PM.

  9. #189
    Join Date
    Sep 2011
    Posts
    111

    Default

    Quote Originally Posted by anda_skoa View Post
    ...Basically all ISVs ship their product in binary form, only very few ship sources only.

    I doubt that all those free ware and share ware authors whos products one can download on sites such as download.com have sumitted their sources and had the hoster build it.
    More likely they had the resources do create their installers themselves, apparently even without having Google's or BlackBerry's resources.

    Cheers,
    _
    Is there a way that OpenSuse's OBS service can help in this regard? Was its purpose to take some source and build packages for a number of important Linux distros? This way they only have to work on binary packages once and just distribute whatever OBS outputs.

  10. #190
    Join Date
    Oct 2013
    Posts
    401

    Default

    Really awesome proposal for how to create runtime. It has everything Lennart and his cabal forgot in their otherwise nice project. It touches 3 major missing points. What runtime is? What is goal of the runtime? What should something like runtime mean for users and developers?

    https://mail.gnome.org/archives/gnom.../msg00000.html

    i don't know about other people, so i say this as my viewpoint. if every project approached runtimes with this direction, that would be awesome.

Posting Permissions

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