Overview
Examples
Screenshots
Comparisons
Applications
Download
Documentation
Tutorials
Bazaar
Status & Roadmap
FAQ
Authors & License
Forums
Funding Ultimate++
Search on this site
Search in forums












SourceForge.net Logo
Home » Community » Coffee corner » About Linux distros and incompatibilty...
About Linux distros and incompatibilty... [message #17002] Thu, 24 July 2008 21:42 Go to next message
guido is currently offline  guido
Messages: 169
Registered: April 2006
Experienced Member
luzr wrote on Thu, 24 July 2008 18:58


Well, maybe developers can do the same thing - target the same 80% user base as us. In fact, Ubunutu seems to be the exact kind of relief here you are calling for.



Works for 80% for two month, and then breaks with the next upgrade of some library. The whole concept of ISV doesn't exist in the world of the leading distros. If you are not in the repository you don't exist and they will break your software at a whim. Even if you get your binary nVidia driver from the official repository, the package system will mercilessly upgrade to an incompatible kernel by the next opportunity. You'll find yourself on the console prompt next morning, wondering what the hell is up. The dependency system should protect from that. But in this case apparently it isn't done on purpose. After all, we can't allow that eeevil binary blob holding up progress...

Also, I doubt those 80%. Ubuntu might be a fad as well. Who knows. Many a mighty have fallen over the years. Look where Mandrake is now. Have even heard of it? The Ubuntu of yesteryear.
Even if, paying customers probably be found rather at Novell and RedHat.
Re: Final release [message #17007 is a reply to message #17002] Thu, 24 July 2008 22:46 Go to previous messageGo to next message
mdelfede is currently offline  mdelfede
Messages: 1307
Registered: September 2007
Ultimate Contributor
Well, I tried 3 times in the past to switch from windows to Linux. All times because I was tired of viruses/slows down/need to reload the OS every 4-5 monthes.
First time with RH, just 2 weeks and then abandoned.
Second time, Mandrake, 1 month.
Third time with suse.... that one lasted a bit longer, but as usual I went back to windows because of problems.
Sorry... never tried Debian, maybe that would have been better choice.
Now, I'm on ubuntu since... 2 years about, I never had to reformat/reload the OS, nor got viruses... and just one os crash, but it was because I tried something very weird.
With wine now I can use the few apps I need for work... autocad, excel because of old macros (I'm migrating them) and a calculation app that hasn't a Linux counterpart.
I'm very happy with the switch, and I've to thanx Ubuntu because of that.
You're right, Linux misses some standards about dependencies, but... I believe that Ubuntu IS making the standard. Some people may dislike it, but it's so. 80% of users means something, and that's the first time I see that it can beat windows.
In all fields usually the most used stuffs build the standards, not some "artificial" guidelines, see LSB failure.

So, I'm thinking.... if already now 80% of linux users follow ubuntu's standard, maybe other distros should follow it also... I don't mean package managers or so, those belongs to user's preferences, as desktop environment. Just a common environment.

Max

p.s. Sorry for the O.T. Smile

[Updated on: Thu, 24 July 2008 22:46]

Report message to a moderator

Re: Final release [message #17009 is a reply to message #17002] Thu, 24 July 2008 22:53 Go to previous messageGo to next message
Zardos is currently offline  Zardos
Messages: 62
Registered: April 2007
Member
guido wrote on Thu, 24 July 2008 21:11

The blame should have gone to the people, who make it so hard for you to provide a widely working package, in the first place.

Sorry again! This should be a day to celebrate Razz

After eight years of Linux use, it is getting hard to tolerate these things any longer. People like me are starting to give up and go Mac for their desktop needs. Many have left already.
I'm flirting with Solaris, so as not having to leave my comfort zone completely. But fear it is too focused on the big enterprisy stuff, to become usefull as a regular desktop.


EXACTLY! I try to use Linux as my primary Desktop OS since so many years... But especially the package management systems are such a complete bullshit. Never ever will Linux catch up on the Desktop as long as there are no commercial Apps. And there will never be commercial Apps because nobody can package for zillions of distros. OSS projects can not package for all the distros, too.
And I really would like to switch to Linux completely. I was probably one of the first 1000 Linux Users, have hacked the kernel to make my IO-Cards working.

Well I'm seriously considering a Mac, too.

- Ralf

Re: Final release [message #17011 is a reply to message #17009] Thu, 24 July 2008 23:16 Go to previous messageGo to next message
unodgs is currently offline  unodgs
Messages: 1366
Registered: November 2005
Location: Poland
Ultimate Contributor

I think the best package managing system and dependency resolver I've ever seen was developed for arch linux. Pacman is very simple for end user, gives human readeble output and works perfectly well (at least for me). I'd like ubuntu switch to it. Sorry to say but debian based distros are too complicated (I mean manual configuration here) and a little bit bloated, but I'm very happy that thanks to ubuntu people could see there's something else than windows.
Re: Final release [message #17013 is a reply to message #17009] Thu, 24 July 2008 23:30 Go to previous messageGo to next message
unodgs is currently offline  unodgs
Messages: 1366
Registered: November 2005
Location: Poland
Ultimate Contributor

Quote:

And there will never be commercial Apps because nobody can package for zillions of distros. OSS projects can not package for all the distros, too.


I never loved the linux because of that. Why the system can't look like this:
/kernel
/xorg
/gnome
/kde
/users -> /me /wife...
/apps
All user applications are stored in apps directory. Every app has it's own directory and it keeps there all the files it needs there. That all /opt /usr/bin /usr/lib /bin /share /etc are crap very messy and unintuitive.
With such structure there could be one app installer for every distro.



Re: Final release [message #17015 is a reply to message #17013] Thu, 24 July 2008 23:57 Go to previous messageGo to next message
Zardos is currently offline  Zardos
Messages: 62
Registered: April 2007
Member
unodgs wrote on Thu, 24 July 2008 23:30


I never loved the linux because of that. Why the system can't look like this:
/kernel
/xorg
/gnome
/kde
/users -> /me /wife...
/apps


Well there is gobolinux (http://gobolinux.org/). It has such a nice filesystem layout as you described it and I liked it a lot. But what does it help if you can only get a limited number of OSS Apps? Sometimes I just need and WANT a commercial app. Photoshop or may be Paint Shop Pro, Software to do my tax. Software which uploads photos to a printing service to get printed photos via mail. And so on... Not starting to talk about games...

Well I have still not completly given up for Linux on the Desktop. For server-apps everything is fine with Linux.
I think things will only change if a big company starts pushing Linux on the desktop and try to make serious money with it.

- Ralf
Re: Final release [message #17016 is a reply to message #17015] Fri, 25 July 2008 00:14 Go to previous messageGo to next message
mdelfede is currently offline  mdelfede
Messages: 1307
Registered: September 2007
Ultimate Contributor
Zardos wrote on Thu, 24 July 2008 23:57

But what does it help if you can only get a limited number of OSS Apps? Sometimes I just need and WANT a commercial app. Photoshop or may be Paint Shop Pro, Software to do my tax. Software which uploads photos to a printing service to get printed photos via mail. And so on... Not starting to talk about games...

Well I have still not completly given up for Linux on the Desktop. For server-apps everything is fine with Linux.
I think things will only change if a big company starts pushing Linux on the desktop and try to make serious money with it.

- Ralf


What about wine ? Now it does work with many commercial apps, and many games, too. Maybe not perfect, but as user base increases, it'll be more and more good.
Up to now you can still run autocad, photoshop, dreamweaver, m$office, among others... I do use it with apps I need and I'm very happy with it.
Ah, with the Vista's miracle ( Smile ) sometimes now wine is more compatible than windows itself...

Max
Re: Final release [message #17028 is a reply to message #17015] Fri, 25 July 2008 17:16 Go to previous messageGo to next message
cbpporter is currently offline  cbpporter
Messages: 1401
Registered: September 2007
Ultimate Contributor
Zardos wrote on Fri, 25 July 2008 00:57


Well there is gobolinux (http://gobolinux.org/). It has such a nice filesystem layout as you described it and I liked it a lot.

Has anybody tried GoboLinux? Is it stable? Can it detect hardware well enough so I don't have to spend the next week on a forum just to get my network working? It looks like a fun experiment, but I'm not in the mood for head-ache inducing setups.
Re: Final release [message #17031 is a reply to message #17028] Fri, 25 July 2008 20:35 Go to previous messageGo to next message
Zardos is currently offline  Zardos
Messages: 62
Registered: April 2007
Member
cbpporter wrote on Fri, 25 July 2008 17:16


Has anybody tried GoboLinux? Is it stable? Can it detect hardware well enough so I don't have to spend the next week on a forum just to get my network working? It looks like a fun experiment, but I'm not in the mood for head-ache inducing setups.



I have used it for a year. The concept of the directory layout is beautiful. Installation of programmes is the way as it should be. No package management.

Hardware detection... And the whole rest: It's a hobby distro. With all its consequences. Be prepared for hanging around in forums.

But if you want to try something different and have some time left. It's worth a look.

For me most distros look the same. The difference is just "sucks slightly more" or "sucks slightly less". Ubuntu was the most pain free distro. But after Virtual Box stopped working, because the kernel was updated I have given up. Another problem of all distros is software updates. You have to wait for the mercy of the god like package maintainers until you can get an update. Developers usually do not create packages (to many distros) like for windows. There is no !practical! freedom. Of course I can compile it on my own. But I don't want. I have compiled enough foreign apps in my life. I still like writing programms, but this does not mean I like to compile Virtual box a kernel, Firefox or whatever.

Sorry, my frustration and dissapointment with Linux, GPL Zealots and the whole rest makes me sound like a troll.

This comment on linuxhaters sums it up:
http://linuxhaters.blogspot.com/2008/07/my-browser-needs-16- exabytes.html#disqus_thread


- Ralf

[Updated on: Fri, 25 July 2008 21:22]

Report message to a moderator

Re: Final release [message #17032 is a reply to message #17016] Fri, 25 July 2008 20:36 Go to previous messageGo to next message
guido is currently offline  guido
Messages: 169
Registered: April 2006
Experienced Member
mdelfede wrote on Fri, 25 July 2008 00:14


What about wine ? Now it does work with many commercial apps, and many games, too. Maybe not perfect, but as user base increases, it'll be more and more good.
Up to now you can still run autocad, photoshop, dreamweaver, m$office, among others... I do use it with apps I need and I'm very happy with it.
Ah, with the Vista's miracle ( Smile ) sometimes now wine is more compatible than windows itself...

Max



Wine can serve as band-aid for transitioning, not acceptable for sustained use. If you need to run above apps for a living, and why else would you spend that much money, running them on Linux is not viable, long term. They'll never work flawlessly.
Wine could be usefull for quick ports through libwine, treating it just like any other toolkit (like running Gimp on Windows). But I don't see that happening anywhere. Not even Google bothers with Picasa - they simply ship the whole wine runtime.

PS:
I just discovered, businesses are required by German law to file income tax online, and with a piece of Windows only software. They hint to Wine for Linux users. No mention of Mac...
Re: Final release [message #17033 is a reply to message #17031] Fri, 25 July 2008 21:04 Go to previous messageGo to next message
guido is currently offline  guido
Messages: 169
Registered: April 2006
Experienced Member
Zardos wrote on Fri, 25 July 2008 20:35

You have to wait for the mercy of the god like package maintainers until you can get an update


Not god like, rather like wardens.
People with no real skills in position of relative power.
The claim is added value by enhanced security and "integration".
How well that works we recently saw with the schmuck, who maintains openssl in Debian. He observed uninitialized memory in valgrind. Then went on to comment out the code responsible, with no idea what it does and no upstream talkback. Thereby leaving any Debian server exposed to be be hacked in minutes, for years.
He had removed the entropy gatherer of the ssl key random number generator, reducing the factual range of keys to like 32k.

[Updated on: Fri, 25 July 2008 21:05]

Report message to a moderator

Re: Final release [message #17050 is a reply to message #17032] Sat, 26 July 2008 19:05 Go to previous messageGo to next message
mdelfede is currently offline  mdelfede
Messages: 1307
Registered: September 2007
Ultimate Contributor
guido wrote on Fri, 25 July 2008 20:36



Wine can serve as band-aid for transitioning, not acceptable for sustained use. If you need to run above apps for a living, and why else would you spend that much money, running them on Linux is not viable, long term. They'll never work flawlessly.


Wrong, I do use 3 apps on wine and they work quite well.
One is perfect (calculation program), autocad is 95% perfect (just very slow TT fonts painting, made a workaround) and Excel (95% perfect too, it just don't allow to open 2 instances of it, but you can open as many files in one of them).

It was not easy, thougt, to have the 3 apps running ok, but now they do and I dropped completely my vmware machine I used for them. They're even faster than in windows.

You did maybe checked wine some time ago... latest progresses are impressive.
Ah, when I say "I do use 3 apps on wine" I mean for my daily work... I've tested many more of them. These 3 are the ones I use 10 ours a day Smile

Quote:


Wine could be usefull for quick ports through libwine, treating it just like any other toolkit (like running Gimp on Windows). But I don't see that happening anywhere. Not even Google bothers with Picasa - they simply ship the whole wine runtime.


I tried 2 apps ported with winelib... didn't like them too much. No great difference as having them running on wine. And, If they don't, there a great possibility that they don't run recompiled on winelibs too.

Quote:


PS:
I just discovered, businesses are required by German law to file income tax online, and with a piece of Windows only software. They hint to Wine for Linux users. No mention of Mac...


Well... same history here, in Italy. Official apps are just wine-only, and you MUST have them to file stuffs to public offices. M$ did a great job ""helping"" politics, I guess....

Max
Re: Final release [message #17052 is a reply to message #17031] Sat, 26 July 2008 19:25 Go to previous messageGo to next message
mdelfede is currently offline  mdelfede
Messages: 1307
Registered: September 2007
Ultimate Contributor
Zardos wrote on Fri, 25 July 2008 20:35


..................
Ubuntu was the most pain free distro. But after Virtual Box stopped working, because the kernel was updated I have given up.


Well, well... the problem is not exactly the same as in windows.
A "kernel update" means you reload the full low level system of os, which is about like switching from windows 2000 to winXP, not like applying what M$ people call "security update", which are usually just "putting some ribbon tape on a virus hole".
You do not "have" to update kernel, and many people don't because of such problems. I do prefere staying up to date, I know the problems and I'm ready to loose some time on it.
Just think to the hassle that windows xp users do have when switching to vista.... and you'll see that a linux kernel update is MUCH painless than that.

Quote:


Another problem of all distros is software updates. You have to wait for the mercy of the god like package maintainers until you can get an update. Developers usually do not create packages (to many distros) like for windows. There is no !practical! freedom. Of course I can compile it on my own. But I don't want. I have compiled enough foreign apps in my life. I still like writing programms, but this does not mean I like to compile Virtual box a kernel, Firefox or whatever.


Usually (I mean, usually in Ubuntu, I don't use other recent distros..), you have to recompile just apps that are shipped with kernel modules, so apps that do low-level system access.
VMWARE, virtualbox, some low-level drivers (not too many, indeed....) needs that one, that's true.
But, for vmware it's just a matter of doing a "sudo vmware-config.pl", wait a couple of minutes and all done. Dont' know about virtualbox, but I DO know about autocad 2005 and windows vista. It simply don't run, you MUST upgrade it if you've got vista. So, spend money to have just some eye-candy addition and an application that's slower than the old one.
Well... I prefere launch a "sudo vmware-config.pl" than to buy another app just because OS became incompatible....

Quote:


Sorry, my frustration and dissapointment with Linux, GPL Zealots and the whole rest makes me sound like a troll.



I was thinking like you for 3 times, before finding ubuntu.
Now I'm really happy with it ! Smile

Max
Re: Final release [message #17054 is a reply to message #17002] Sat, 26 July 2008 19:29 Go to previous messageGo to next message
mdelfede is currently offline  mdelfede
Messages: 1307
Registered: September 2007
Ultimate Contributor
bytefield wrote on Sat, 26 July 2008 13:02

Maybe this help to clarify where should be installed upp:
/usr/bin
/usr/local
We have to install in /usr/local just when we want that an update to not change our version of software and usually in /usr/local software are installed manually as guido said.

We should follow the line of all other software (like gimp, gftp, nmap, etc.) which get installed in /usr/bin. I think is better stay on current installation path.


I agree, 95% of apps I know do that. Apps installed in /opt, /local, /usr/local or so are just a pain for os maintainer.

BTW... great job with debian build script...I'll test it on next svn release. Maybe you found an "universal debian solution" Smile

Max
Re: Final release [message #17061 is a reply to message #17013] Sat, 26 July 2008 21:07 Go to previous messageGo to next message
mdelfede is currently offline  mdelfede
Messages: 1307
Registered: September 2007
Ultimate Contributor
unodgs wrote on Thu, 24 July 2008 23:30


I never loved the linux because of that. Why the system can't look like this:
/kernel
/xorg
/gnome
/kde
/users -> /me /wife...
/apps
All user applications are stored in apps directory. Every app has it's own directory and it keeps there all the files it needs there. That all /opt /usr/bin /usr/lib /bin /share /etc are crap very messy and unintuitive.
With such structure there could be one app installer for every distro.


With an 'uniform' file structure, I agree 100%. The only real linux problem is incompatibility with distros about file structure and used libs.
The former would be easy solveable, but I lost hope on it since years. Ubuntu is making a standard, and for me is ok.
The latter problem is more difficult, but can be solved installing needed libs as app dependency.

Your 'proposed' file structure... well, that's a bit more problematic. You say 'every app has it's own directory'.
Just think at 'path' problem and you'll see that's not manageable, OR you loose the ability to run apps from command line. Second problem... where do you put config files ? in app folder... impossible, unix doesn't have a *reliable* way to locate executable location. So it must be in a 'fixed' location, which could be /apps/myapp/ or, as it is by now, /etc/myapp. Just a naming difference.....
But the real, big problem are share libraries, as usual. Just look at windows, they name it "dll hell" because of something.
Do you want a truly 'shared' dll ? so it must be located on a fixed location, which is by now /usr/lib. Being so, if your app needs an upgraded shared lib, you must install it along the one already present --> dll hell problem.
You want to call it 'shared' but be sure that each app calls 'right' lib ? so put it in a by-app location, you solve dll hell problem but you can have 20 identical shared libs loaded in memory by 20 different apps.... I guess that's done, more or less, with .net apps.

IMHO, one best way to manage a big part of all problems is in .deb packages. RPM's had (IMHO.... please no flames here ! Smile )much more problems. They state *clearly* which libs an app needs, the location where download it, if some conflicts with others. And no need to ship a package burded with tons of dlls inside, which it's a not so small advantage.

Conclusion :

-windows way : easy, installers bundled with tons of dlls, accessory files and apps, don't detect easy dlls conflicts, they usually leave tons of files/registry entries when uninstalled.
IMHO one of the worst way to package stuffs.
You have sometimes problems when switching to a new os version.

-rpms way : more complicated installer, no dlls, but you must (IIRC...) manually get dependent rpms. Or use advanced tools like URPMI or so. With advanced tools, not so bad.

-debs way : small installers, they take care of dependency solving, they signals conflicts, they usually can detect if a package is not anymore needed and purge it. IMHO, one of the best ways to deploy stuffs.

with windows way, if you upgrade os you MUST reinstall all apps. No other reliable way... people that tells they just upgraded windows keeping old setups just have 2-3 apps installed, and usually also those have problems.

with ubuntu way, just click a button and wait some 3 ours to have your brand new system. Yep, sometimes with small problems, but easy solved (up to now, I went from 7.04 to 7.10 to 8.04 with no problem at all).

Ciao

Max
Re: Final release [message #17063 is a reply to message #17061] Sat, 26 July 2008 22:54 Go to previous messageGo to next message
unodgs is currently offline  unodgs
Messages: 1366
Registered: November 2005
Location: Poland
Ultimate Contributor

Quote:

Your 'proposed' file structure... well, that's a bit more problematic. You say 'every app has it's own directory'.
Just think at 'path' problem and you'll see that's not manageable, OR you loose the ability to run apps from command line. Second problem... where do you put config files ? in app folder... impossible, unix doesn't have a *reliable* way to locate executable location. So it must be in a 'fixed' location, which could be /apps/myapp/ or, as it is by now, /etc/myapp.


running apps from cmd - how many apps do you run from cmd daily? Maintaining PATH variable is not problematic to me.
'path problem' - what problem ??
config files - user configuration file in /users/../.appname, global app settings somewhere in app instalation directory tree (where exactely it dosn't meatter)
unix doesn't have a *reliable* way to locate executable location - I'm not unix expert - please explain what's the problem. Besides we're mostly interested in linux not all unixes. I don't see a problem in fixing this on system level (whatever this problem is Smile )
Quote:


But the real, big problem are share libraries, as usual. Just look at windows, they name it "dll hell" because of something.
Do you want a truly 'shared' dll ? so it must be located on a fixed location, which is by now /usr/lib. Being so, if your app needs an upgraded shared lib, you must install it along the one already present --> dll hell problem.
You want to call it 'shared' but be sure that each app calls 'right' lib ? so put it in a by-app location, you solve dll hell problem but you can have 20 identical shared libs loaded in memory by 20 different apps.... I guess that's done, more or less, with .net apps.

No I don't want any dll/so hell. For example my kde instllation uses qt 4.3. Application x use qt 4.3.1 so it KEEPS IT IN ITS OWN DIRECTORY. What's more - even if it uses exactely the same version it also has its own copy. I will delete kde - my app run will be still able to run.
Of course some files must be shared like xorg libs or kde libs. In my filesystem you would have /kde/3.3, /kde/3.4, /xorg/4.0, /xorg/4.2. System could hold in memory structure with that paths, so every app could read it and determine where files it needs are located and if the version they need exist.
I'm not scared about 20 identical shared libs loaded* (typicaly you have 10/15 apps run - and if you have more than 1gb that's no problem). I just want my app run without problems. I want it to be easily located and removed if necessary.
I agree with you about 'uniform' filesystem structure, but I don't want ubuntu to be that one.

* I'm also not scared about my cpu/gpu temperature. It's the same kind of fear Wink It exists only in people's psyche but has no effect in reality.
Re: Final release [message #17066 is a reply to message #17002] Sun, 27 July 2008 03:43 Go to previous messageGo to next message
emr84 is currently offline  emr84
Messages: 26
Registered: April 2008
Location: Argentina
Promising Member
Somebody has used autopackage? It seems to be an attempt to solve the installation problems on different distributions.
Re: Final release [message #17067 is a reply to message #17061] Sun, 27 July 2008 09:01 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 13975
Registered: November 2005
Ultimate Member
mdelfede wrote on Sat, 26 July 2008 15:07


Just think at 'path' problem and you'll see that's not manageable, OR you loose the ability to run apps from command line.



Why? If systems knows to search for binaries in Apps, it is only a little bit more complicated than PATH (which would be maintained only to express eventual priority).

Quote:


Second problem... where do you put config files ? in app folder... impossible, unix doesn't have a *reliable* way to locate executable location.



Actually, current solution in Core/App.cpp seems to work quite well...

Anyway, generally, I could imagine a better way how to handle these issues, but I have already got used to current model and .debs and I think that they work acceptably well. Arguing whether "home" should be called "users" and "usr" -> "apps" is wasting of time Smile

Mirek
Re: Final release [message #17072 is a reply to message #17063] Sun, 27 July 2008 14:47 Go to previous messageGo to next message
mdelfede is currently offline  mdelfede
Messages: 1307
Registered: September 2007
Ultimate Contributor
unodgs wrote on Sat, 26 July 2008 22:54

Quote:

Your 'proposed' file structure... well, that's a bit more problematic. You say 'every app has it's own directory'.
Just think at 'path' problem and you'll see that's not manageable, OR you loose the ability to run apps from command line. Second problem... where do you put config files ? in app folder... impossible, unix doesn't have a *reliable* way to locate executable location. So it must be in a 'fixed' location, which could be /apps/myapp/ or, as it is by now, /etc/myapp.


running apps from cmd - how many apps do you run from cmd daily? Maintaining PATH variable is not problematic to me.
'path problem' - what problem ??


Many of them, when I've got a terminal already opened I find quicker to use command line than menus.
BTW, the 'path problem' is that, which a folder for each app executable makes path zilions chars long an slow to parse.
Quote:


config files - user configuration file in /users/../.appname, global app settings somewhere in app instalation directory tree (where exactely it dosn't meatter)
unix doesn't have a *reliable* way to locate executable location - I'm not unix expert - please explain what's the problem.
Besides we're mostly interested in linux not all unixes. I don't see a problem in fixing this on system level (whatever this problem is Smile )


The problem is simple : you can't assume that argv[0] contains the full executable path, as in windows... it contains the command line used to run the app.
So, if it's on path, it's enought the app executable name, no path. If it's not a path, it can be a symbolic link to the executable. It's a known problem on Linux; there are solutions but all of them are seen as unreliable. I used one of them on my build scripts, if you look at it you'll find it cumbersome, using LSOF command to look for opened files and parse it.
Of course, Linux could be patched to solve this, but I believe it will never happen.

Quote:


No I don't want any dll/so hell. For example my kde instllation uses qt 4.3. Application x use qt 4.3.1 so it KEEPS IT IN ITS OWN DIRECTORY. What's more - even if it uses exactely the same version it also has its own copy. I will delete kde - my app run will be still able to run.

Of course some files must be shared like xorg libs or kde libs. In my filesystem you would have /kde/3.3, /kde/3.4, /xorg/4.0, /xorg/4.2. System could hold in memory structure with that paths, so every app could read it and determine where files it needs are located and if the version they need exist.
I'm not scared about 20 identical shared libs loaded* (typicaly you have 10/15 apps run - and if you have more than 1gb that's no problem). I just want my app run without problems. I want it to be easily located and removed if necessary.


That's (AFAIK) the .net solution to dll hell problem.
It's A solution, not the perfect one, and I think that it'll never be a 'perfect' solution.
IMHO it's better to have a single dll loaded for many apps, besides of being less memory hungry (that's not a big problem by now, indeed) the app startup time is much shorter (and that one IS a big problem sometimes).
Having a copy of KDE libs in 10 places would mean mantain all of them on a kde upgrade OR keep different version of them on a by-app basis. I wouldn't like that one... what happens if a security hole is found on current kde lib ? you upgrade package, you have the 'official' lib replaced and all your 9 copies still containing the hole...

Quote:


I agree with you about 'uniform' filesystem structure, but I don't want ubuntu to be that one.


Well... that's a matter of taste, of course. I wouldn't ever like to have a windows-like filesystem structure, in particular regarding system files.... Just look at c:\windows folder Smile
Ah, I forgot... c:\programs\common files\officexyz folder, c:\programs\common files\myapp, etc.
And if you change language, c:\programmi\file comuni\....
And that ""wonderful"" 'documents and settings' three !

What I really don't like on linux fs is /opt /usr/share /usr/share/1/2/3/.../2345 and so. Those are really useless.

Max


Max
Re: Final release [message #17073 is a reply to message #17067] Sun, 27 July 2008 14:56 Go to previous messageGo to previous message
mdelfede is currently offline  mdelfede
Messages: 1307
Registered: September 2007
Ultimate Contributor
luzr wrote on Sun, 27 July 2008 09:01

mdelfede wrote on Sat, 26 July 2008 15:07


Just think at 'path' problem and you'll see that's not manageable, OR you loose the ability to run apps from command line.



Why? If systems knows to search for binaries in Apps, it is only a little bit more complicated than PATH (which would be maintained only to express eventual priority).



It depends on how you do manage it.
If you have
/Apps/myapp1
/Apps/myapp2
.....
/Apps/myapp2345

you have OR a kilometric path OR your OS must search recursively through the full Apps folder.
Both of them are slow.

Quote:



Quote:


Second problem... where do you put config files ? in app folder... impossible, unix doesn't have a *reliable* way to locate executable location.



Actually, current solution in Core/App.cpp seems to work quite well...


I must admit that I didn't look at it Smile I'll do sometimes.
But believe me, that's a known problem with no 100% reliable solution.

Anyways, I don't like the windows way of putting config files (sometimes) on app executable folder. That one should be write protected and not accessible by normal app usage. Like it is now it's an opened door for malware and/or coding mistakes.
In app folder should go only fixed config files, I mean files with data not modifiable by program itself. The rest should go on registry or, as in linux, on user owned folders.

Quote:


Anyway, generally, I could imagine a better way how to handle these issues, but I have already got used to current model and .debs and I think that they work acceptably well. Arguing whether "home" should be called "users" and "usr" -> "apps" is wasting of time Smile




I agree Smile
Btw, those names are there for historical reasons (don't ask me which, I knew some of them in past but I forgot !!!)

Just another small OT : the same belongs to LISP language CAR/CADR statements (getting first elements of a list/list with first element removed). IIRC these names came from a PDP11 machine instruction code...

Max
Previous Topic: UPP SW deployment
Next Topic: Win32 UPP console application profiling? Some free easy to use tools, anyone?
Goto Forum:
  


Current Time: Thu Mar 28 10:19:43 CET 2024

Total time taken to generate the page: 0.01675 seconds