Better buy some bigger HDs
|
| Author | Content |
|---|---|
| maxxedout Aug 15, 2015 2:10 PM EDT |
NT |
| penguinist Aug 15, 2015 2:58 PM EDT |
maxxedout: umm I think we need you to use more words in order to get your point across. :) Or we will have to rename you "minnedout". |
| JaseP Aug 15, 2015 8:20 PM EDT |
I rarely even come anywhere near close to filling the root partition of my HDs. Generally speaking, 6GB is more than enough for a Linux distribution. I'm actually more concerned that making their own package manager will mean incompatibility with Debian packages... |
| maxxedout Aug 16, 2015 10:29 AM EDT |
Every piece of software will have it own libs that means duplicate libs. Libs maybe small but they will start to add up when installing 100+ apps. |
| gus3 Aug 16, 2015 8:10 PM EDT |
Gotta have room for all the image macros and cat videos... |
| cybertao Aug 16, 2015 8:22 PM EDT |
maxxedout wrote:Every piece of software will have it own libs that means duplicate libs. Libs maybe small but they will start to add up when installing 100+ apps.They are introducing it for proprietary packages, which is always troublesome in Linux. Valve took a similar approach with Steam which has a good chunk of Ubuntu included with it and each game include their own copies of supporting libraries. It's actually little different from 'dll hell' on Windows where multiple versions of dlls are kept as outright replacement can break other software that utilises it. |
| JaseP Aug 18, 2015 3:22 AM EDT |
Quoting: It's actually little different from 'dll hell' on Windows where multiple versions of dlls are kept as outright replacement can break other software that utilises it. Not so,... By packaging each app with staticaly linked libraries, you actually avoid that problem. Remember, ... Linux is not Windows... Those multiple libraries won't be colliding with one another. |
| cybertao Aug 18, 2015 5:58 AM EDT |
You don't avoid the problem, the libraries are just statically linked at compile time instead of dynamically at run time. Having multiple dynamic libraries does not mean they will clash. They will probably be installed to application specific directories and utilised by tweaking LD_LIBRARY_PATH before launching, or similar. DLL Hell could be solved by statically compiling software on Windows as well. But you lose the advantages dynamic linking can offer. |
| JaseP Aug 18, 2015 7:01 AM EDT |
What are you talking about?!?! It absolutely does!!! The libraries would be statically linked and shipped with the executables. Other apps would use their own versions of the same libraries, not the versions that other apps ship with... In Windows, various apps are updating the packages that are installed for all to use... The only issues with Canonical's scheme are having to update libraries multiple times, and the extra disk & memory space used. Statically linked libraries don't contaminate similar (or same) libraries used in another part of the system... Think about it in terms of its use with chroot: http://oss.sgi.com/LDP/LDP/lfs/html/chapter05/whystatic.html |
| cybertao Aug 18, 2015 7:24 AM EDT |
Libraries don't have to be in the base system path, they can be put in a folder that the system is told to search for libraries when launching the application by altering LD_LIBRARY_PATH first.
I'm not saying static linking isn't a possible solution, but it's not the only solution and might not be an option since proprietary software is dependent on the vendor building it (which is the problem in the first place). Dynamic linking maintains a measure of control as you can alter the libraries. That's a really old version of LFS, btw. They use dynamic linking throughout the entire process now, and the 'pure LFS hint' was in popular use back then. |
| JaseP Aug 18, 2015 7:54 AM EDT |
Quoting:Dynamic linking maintains a measure of control as you can alter the libraries. It's just as much a lack of control. Alter the library too much,... and you break the application. I recall having to create symbolic links to newer versions of the c++ library that a particular program depended on, because it very specifically wanted a particular version (would seg-fault without it). The authors didn't incorporate and statically link that version, but the methods hadn't changed within the newer version of the library, so I had to create a symbolic link with the name of the old library along side the new version (which it linked to)... That was about a decade ago. Static linking of libraries is very much what it seems like Canonical has in mind (in addition to their "special" new package scheme). My thought is that they intend to only update the base OS packages, and make the app packages fairly version independent (e.g.: one LibreOffice, VLC or GIMP package that will run on all versions of the OS). That way, they would only have to update the kernel and other "basic" packages of the OS (like the display server, the Desktop Environments, etc.) along with the OS version. |
| cybertao Aug 18, 2015 8:26 AM EDT |
LibreOffice, VLC, and GIMP are open-source packages. Open-source packages are not the problem; proprietary software is. http://www.linuxjournal.com/content/problems-ubuntus-software-center-and-how-canonical-plans-fix-them Quoting:When a new version of Ubuntu is released, commercial packages in the software center must be thoroughly checked for compatibility issues (the major open-source packages in the repos are audited before the distro version is upgraded). This introduces a bottleneck, with some applications waiting for months before they can be included in the store. Neither static or dynamic linking is a magic bullet to solve the problem of sandwiching proprietary software in a free software environment. Open-source apps can be compiled against new libraries (and updated if there are API issues). Supporting libraries for dynamically linked proprietary software can be bug fixed, those bugs can't be fixed if they are statically compiled into the application. Personally, I hope Snappy doesn't succeed in fostering more proprietary development. |
| CFWhitman Aug 18, 2015 11:26 AM EDT |
Snappy packages could use either static or dynamic libraries. The key thing is that, one way or the other, the libraries will be included in the package rather than as dependencies as in most open source software with a conventional package/dependency manager. "Dll hell" was basically just the Windows version of "dependency hell" in Linux. When you install different binary applications they can use different libraries, and the libraries can end up conflicting. The difference is the method that the two systems used to solve this issue. In Linux, "dependency hell" was solved by using a dependency manager, like apt-get or yum, and repositories. One program keeps track of the libraries that different software depends on, and only installs software that uses the same version of those libraries. This is managed by keeping a repository of software that all matches. If two programs in the repository depend on a library, they depend on the same version of it. To go to a new version, you need to update the repository which has updated versions of all the involved programs. In Windows, most of the software was not open source, so the approach Linux used to solve this issue was impossible. Instead, the problem was solved by greatly reducing the reliance on common system libraries. If two applications depended on the same library, they each included their own version of that library in their own application directory. That way, the libraries didn't conflict, and no more "dll hell." Snappy is basically an attempt to apply the Windows solution to the problem of conflicting libraries to Linux. For a lot of traditional proprietary Linux software, this isn't necessary because it already does things like Windows (at least like Windows used to) by using an installation script and installing to /opt (or /usr/local) and including its own dependencies. However, open source software, and proprietary software that relies on a common library, such as GTK, and is distributed through a dependency manager, could switch to the Snappy approach. This would make it so newer versions of software could be released without figuring out the dependency issues, or compiling the software specifically for the version of the distribution concerned. Of course the downside of Snappy is similar to some issues that you can have in Windows. Applications, and the system as a whole, take up much more disk space. Also, who knows, or could possibly keep track of, all the old libraries that could be leaving security holes around your system? Having a repository with an update manager instead of just some odd packages you got from random Web sites is supposed to mitigate the second issue. |
| skelband Aug 18, 2015 3:46 PM EDT |
Yeah, DLL hell in WIndows stemmed from Microsoft's annoying habit of using the exact same name for key runtime DLLs that are entirely different such as "MSVCRT.DLL". They don't these days but they still don't have an across-the-board strategy for version stamping their dynamic libraries by name. |
Posting in this forum is limited to members of the group: [ForumMods, SITEADMINS, MEMBERS.]
Becoming a member of LXer is easy and free. Join Us!