Do we really need a dependency hell in Haiku? Please can anyone explain me?

1
I really dont want to start a flame, but i simply cant understand somethings ( always from a average user position ) i would really apreciate if someone can drop some light on this. ( I am not a developer so maybe my conclusions are wrong, based on things i think i understand but maybe not, if so let me know )

From my pov i understand that developers work on a library or an API that gives other people the ability to make other things making use of the mentioned library of API. Let´s put it simple. FFMEG is an incredible project made of codecs, some binaries and some developers use it to make another programs or tools to view multimedia files or video conversion tools, and so on, right? Lets put another example.QT and GTK. Two important projects, some kind of graphical APIS that a bunch of programa use later or are based on. Remember how many KDESC and Gnome programas there are? We can find zillions of libraries beeing needed in any Linux distro leading to have thousands and thousands of files in every hardisk, leading to very complex operations made by software manager programs to avoid breaking anything…etc,etc… the problem is much more importante when u consider using or need to use more than one version of some program, librari, api…

Then here comes the question. Obviously writting programs, and doing very important and huge projects like KDE, Samba, OpenOffice, FfMpeg, Firefox and so on is very difficult and expensive in time and resources and duplicating work is not very clever. But do we really need this lots of stuff in Haiku? Qt is ported so can be used in Haiku. Gtk will come for sure. and what more? all the apps that bring those APIS too? Do we need/want another Linux distro with a new kernel ( Haiku )? Haiku project has and incredible advantadge over Windows and Linux cause in some way, they have to be what they have been through this years, users cannot ignore that they dont choose how they want the operatin system to be, they just use what developers have decided in the last years, even if they were right or wrong. Haiku has the chance to do it from now from scratch. Haiku has no burden in this moment. Lets keep it simple and real. Lets wait patiently for the availability of some good software and lets not mess everything in a dependency hell like in Linux having the “great chance” and the “freedom” to choose from 300 alternatives that do the same. That does not help anymore. Lets have one graphical API, one media rendering libraries, one 3d stack, and lets develop them in an unified way for the sake of simplicity, and confort for everybody. I really DONT imagine my Haiku with Totem, Rythmbox and smb4k. I will always try to keep de Be.Os spirit alive and will try to use the least Linux programs in my Haiku. Nor it´s wallpapers, icons, and other stuff. By the way, what´s the point of designing, programming and making a lightweight, and low resource usage operating system if later we add non-optimized programs, unnecessary bloated pieces of software and things like that?

Any appreciations of my idea would be great, let me know if i am wrong, thanks for reading.

2

Sounds like solid reasoning. I used BeOS Max as my main OS until a few months ago when I decided to give Haiku a shot. I didnt know development on Haiku started as long ago ( nine years?) as it did.
Being the patient type, I’m hopeful that all the favorite BeOS apps will be ported to Haiku. BamBam is a nice one. Pineapple News is another. So far neither are available yet but its probably just a matter of time :slight_smile:

3

A lot of games will be ported when Haiku gets 3d acceleration. A lot of them are cross platform. Simulations like FlightGear use openal, openscenegraph and simgear,etc. Will Haiku have the equivalent that these ported games and sims can use?. Will all these other dependencies be ported too? I know it can be a real pain though from the point of view of dependencies and not being able to update to a later version because it uses a later library that is not available in your current version of Linux for example. It seems very hard to not think that if no Haiku source for similar applications is available then Haiku wont be able to escape this. Or might there be some way to adapt Haiku libs to any future applications dependencies, without breaking compatibility for current application?

4

I wonder if the same idea of a modular kernel could be applied to libraries? Each lib broken up into modules and each module corresponding to a section in the monolithic lib that the application normally uses. If there are changes in a certain section only a new small module needs to be adapted from the source of the original. For any given application the right modules are assembled for compatibility, no matter if it needs an older version or the latest. All the assembled modules are presented as one lib to the application.
The question then is how would compilers handle this? Easy moderate or difficult.
Also note I’m not a developer as well except for knowing BASIC and doing a few C++ tutorials.

5

Well Snuhwolf, the idea is that all of your favourite Be programs should work out-of-the-box with Haiku, but it seems that development is drifting from that idea. Supposedly R2 will completely drop any BeOS support. I think at the moment, the focus seems to be on quantity and not quality. It would be great to have native apps for things like office suites, media encoders, etc., but that will take a lot of time, so the focus rests on porting, which needs a lot of libraries to work. I agree with you, I think it’d be great if there were a swiss army knife of libraries, a do anything and do it well kit, but even if there were, when people develop apps, they’ll probably want to use their own libraries for a specific function. In my opinion, as long as the app comes with the necessary libraries, then it’s fine. The number of times I got a missing library notice before I understood how to fix it was just annoying.

Cebif, could you possibly explain what you wrote in your last post again, as I’m too dumb to understand it :slight_smile: and would like to know exactly what you mean, as it sounds like an interesting idea.

6

[quote=cebif]
I wonder if the same idea of a modular kernel could be applied to libraries? Each lib broken up into modules and each module corresponding to a section in the monolithic lib that the application normally uses.[/quote]

To the extent that this makes some sense, it’s already done. The C library used by any modern Linux distribution has versioned symbols, which means that even a core function can be updated incompatibly and newer programs get the new version while older programs get the old version.

But remember that compatibility is a lot of development work for each affected library. The GNU libc has the necessary volunteers (and paid developers) to make this happen, but most libraries would not. We can easily look at the example of libpng, the PNG image library. Recent versions of libpng have forwards compatibility, a program compiled against a version from 2009 will work with a version from 2010. But the developers of libpng had to learn how to achieve this, they started out ignorant, and made incompatible changes because they didn’t know any better. During that period a program compiled against one libpng would only work with exactly that version, any new version would cause it to report an error or just crash outright.

7

Well how well my idea would work, depends on the possibility of being able to enforce what is available in Haiku or being able to quickly and easily being able to adapt what is available. Also it being attractive enough to the majority of people that port or develop.
The idea is to split lib source files (and binaries) up into sections by the functions in each. If a lib changes, perhaps by a bug fix in a certain section or functionality being improved. All that has to be done is recompile an alternative section (module) for newer apps until the developer/s get around to recompiling the older apps to use the newer module. That would mean the lib binaries also having to be split into modules. The application would see the lib not as separate files but as one lib. The applications accessing the lib would let a Haiku lib controller know their names, by changing a variable to the string of its name. If it was a newer app that used added functionalty it would be expecting the lib to have a later version name. When that app had been installed, the difference in the lib as corresponding to the module would also have been installed. This module would have the name of whole lib and number or section of the code it came from originally plus the part of the name that coresponded to the update. The older module would remain also.
This way the lib controller could assemble when the app was first run links (no need to update names in the case of links from older modules to newer version) to all the modules (new and older) that the newer app could use in a separate sub folder. For the app to see all the modules as one new version lib; at the end of each modules code it would have to refer to the start of the next module by referring back to the lib controller that re referred to the start of the next module in numbered order as in the links to them from the sub folder. So all applications would instead refer to the lib controller instead of to the libraries folder/s.
Splitting libs up into modules would make easier to make changes since one change might only be needed to one section and therefore only a small recompile. Nothing would be broken for older apps. It would depend on the lib controller acting like what the application expected as far as the correct name.

8

[quote=NoHaikuForMe][quote=cebif]
I wonder if the same idea of a modular kernel could be applied to libraries? Each lib broken up into modules and each module corresponding to a section in the monolithic lib that the application normally uses.[/quote]

To the extent that this makes some sense, it’s already done. The C library used by any modern Linux distribution has versioned symbols, which means that even a core function can be updated incompatibly and newer programs get the new version while older programs get the old version.[/quote]
Are you talking about the source having something similar to what I’m thinking? What about also the binaries derived from the source. Are they whole binaries for each version of the lib? Or am I thinking wrongly that libs can include multiple functions. (not a developer) You will see in my post after you posted, when I answered stellerpower, that I also would have different versions of binary modules if another later application wanted a later lib. All the older modules for that lib would still be used, except the module where the later change had been made. Applications would refer to a lib controller instead of the lib folder.
That way if an application developer saw functionality that wasn’t good enough in the lib, he might only need to change the source/binary module for that functionality. The libraries folder could be kept down in size and a small amount of recompiling for one module.
Any newer application would only install the module it needed not the whole library/s. When it was first run it would register its name with the lib controller which let the app see only the modules as a whole lib with the name it expected. Also it might be better to organize that the lib controller looks in the /boot/apps folder to register all names periodically or at boot up. If no older applications are installed, that match a first run log the app controller can then delete the older modules of libs.

9

[quote=cebif][
Are you talking about the source having something similar to what I’m thinking? What about also the binaries derived from the source. Are they whole binaries for each version of the lib?[/quote]

The (binary) library consists of a mapping of symbols onto data. Often the symbols are function names, and the data is program code for those functions. Libraries like glibc ‘tag’ some symbols with a version number, and programs compiled to use the library also have tags, so they get the same version. This means that if you have say glibc 2.11.2 installed and you run a program intended for glibc 2.6 it will work correctly, and so will a program intended for glib 2.3 or glibc 2.10

Less fundamental libraries can often ensure this just through thoughtful API design, but the C library does not have that luxury since the API is enshrined in a series of ISO standards, POSIX standards etc. and thus not easily changed to suit. So it uses symbol versioning.

You are correct that libraries commonly include many related functions.

[quote]You will see in my post after you posted, when I answered stellerpower, that I also would have different versions of binary modules if another later application wanted a later lib. All the older modules for that lib would still be used, except the module where the later change had been made. Applications would refer to a lib controller instead of the lib folder.
That way if an application developer saw functionality that wasn’t good enough in the lib, he might only need to change the source/binary module for that functionality. The libraries folder could be kept down in size and a small amount of recompiling for one module.
Any newer application would only install the module it needed not the whole library/s. When it was first run it would register its name with the lib controller which let the app see only the modules as a whole lib with the name it expected. Also it might be better to organize that the lib controller looks in the /boot/apps folder to register all names periodically or at boot up. If no older applications are installed, that match a first run log the app controller can then delete the older modules of libs.[/quote]

Here you’re mostly just shoving the vegetables around the plate. Dividing libraries up into smaller libraries and calling them “modules” doesn’t reduce the dependency problems, in fact it multiples them manyfold. Realistically the only way to stay in control would be to bundle up these modules in groups, which looks a lot like the original libraries you started with.

10

I absolutely hate dependency hell stuff. I can’t stand installing an application, only to find out that I have to install a couple of libraries that are small enough to include with the application itself. And even if the libraries when bundled together aren’t very small, that’s the price you pay for using a non-native application. The less native an application is, the less integrated it will be, the bigger the size will often be, and so on. This is only natural. Requiring users to install libraries system-wide only makes it all more annoying.

11

The same problem Linux faces, Haiku will have to face also with libraries. Haiku uses some POSIX libraries as do other POSIX programs running on Haiku.

Issues:

  1. Users with older version of OS trying to run application that requires newer libraries
  2. Users with newer version of OS trying to run application that requires older libraries

You may end up with mix of software that requires older or newer libraries because of compatibility. In that case, you end up with multiple libraries (real mess).

A good solution is; use latest version of OS + latest version of applications and hope they work with latest versions of libraries. This works for Linux because it is opensource and can recompile everything to work with latest libraries & OS.

ie: if all applications are compiled on latest version of OS then there should be no issue of which version of a library is required. Solutions: a) either providing every application compiled on same OS version (or just the problematic ones to do less work) or b) providing source and easy way to compile and install application for users.

I prefer not seeing any X Windows, GTK or KDE stuff on Haiku. I believe that If you want those type of applications then that person should really go with Linux. I prefer not making a Linux OS with Haiku kernel. I am for and have no issue with SDL, OpenGL, Qt, POSIX, ncurses and OpenAL because they add value to Haiku with little bloat & complexity and seem to work very well.

There is no way to stop someone from bringing X Windows, KDE and/or GTK+ to Haiku but these will never become part of standard Haiku (3rd party downloads/add-ons). People can then decide whether to download, install and use them or not.

12

good points, but there are some great Open Source programs, it would be a shame not to use them. Mac OS X, Linux, Windows can run vlc, firefox, apache, unless you are willing to rewrite everything, it would be difficult to avoid this at the beginning. I prefer to use great programs that use open formats (odf, svg…) rather than using $35-150 proprietary software with their own file format.

13

vlc from 0.9 can use Qt. I use vlc and like it also. Haiku also has mplayer & easy to port newer ffplay (ffmpeg) to play lots of stuff. Reason lacking newer vlc is because Haiku is missing one or two POSIX functions required to compile vlc (Qt).

Firefox 2.0 works on Haiku now. Firefox 3 requires cairo library - reason no release. FF3 Alpha was working on Haiku last time I checked. But why? Haiku has FF2, WebPositive, Arora (Qt), QtWeb (Qt), NetSurf, …, one or more of these should be good enough. Of course I like FF & Chrome & use them so nice to have them too but better for more native GUI versions.

Sure, you may miss out on some programs like OpenOffice but then a real port from X Windows should be more native to Haiku and not bring X to Haiku. That would add another layer - bigger mess, more complexity, less performance and harder to manage.