Operating Systems > Linux and UNIX

Ubuntu: The Verdict

(1/9) > >>

Kintaro:
Well at first this seemed like a reasonable distro, however it has its problems. Firstly, it is shit. It is just plain shit. How anybody can stand this crap I have no idea. It ships with an outdated version of gaim which happens to crash all the time. Constantly, so I have to compile my own (outdated gaim also in apt repository). More than that it ships with no development utilities, making it a pain in the arse to build my own kernel. Also my panel has decided to crash and die on me, due to something or another hanging (one of the applets). It has another dozen inconsistant problems which make it a bucket of flaming crap.

I think I will go back to Fedora Core 4 which treated me much better.

bedouin:
It's not for power users.  For someone you want to turn onto Linux though, it's perfect.

Why are you bothering with Fedora?  Why not Debian?

Sorry, just can't stomach a RPM-based distro -- ever again.

udaki:
If I have been keeping user track correctly,weren't you X11 a while back?If so,didn't you used to cuss out fedora and hype slackware in your sig?what the hell happened?

ksym:

--- Quote from: bedouin ---It's not for power users.  For someone you want to turn onto Linux though, it's perfect.

Why are you bothering with Fedora?  Why not Debian?

Sorry, just can't stomach a RPM-based distro -- ever again.
--- End quote ---

So what exactly is wrong with RPM? IMO the packaging format
is nearly perfect, since RPM build process automatically
lists provided sonames in library packages, and software
packages automatically list required sonames.

With this it is very easy and quick to build entire
distribution profiles, just making sure that one soname
is provided only by one package at a time ;)

This also enables proprietary binary-only software
packages (in theory), to depend upon some soname in
the host distro, and then the created package can be
installed in any distro that has the same soname
provided in some other package. Neat huh?
And as we know, sonames are often generated
at compile time by using GNU Libtool and it's versioning
system, so library names are VERY dependable.

In debian you have to know the package names in order
to define dependencies. Packages do not list the sonames
they provide, or require direct sonames.
This sucks, since package names are mostly distro-spesific
crap -> makes distro-wide packages impossible.

The only thing that has made RPM distro's hard to maintain
in the past years has been the lack of higher-level
package management. But today with innovations like
urpmi, yast2, yum and such ... this is not really
the problem.

The only thing RPM -standard lacks are reverse-dependency
handling. Eg. if i have a program linked to libfoo.so.0.2.0,
so that it uses all the interfaces provided, it will
be linked to libfoo.so.0 (0 = the interface version linker
understands). And let's pretend we install this program
to another system, where we have a little older version
of our library, libfoo.so.0.1.0, installed. Our program
installs just fine, since libfoo.0.1.0 provides libfoo.so.0 ...
but when you run the program, it won't run since some
functions that are implemented in libfoo.so.0.2.0 are
not present in libfoo.so.0.1.0 ! Got the idea?

The solution would be to create an add-on package management
platform, that tracks not only direct-soname-deps, but
also reverse-soname-deps. And in this case it would
notice that the 'age' of libfoo in the target system is
too small, and would suggest to install a newer version
of libfoo.

Anyways, i've started to do somekinda "multi-distribution
runtime platform", eg. a separate subsystem with it's
own libraries and subsystems (platforms like KDE, Gnome).
My idea is to give user the possibility to install
software in non-static locations, like /usr/local/Apps
/home/luser/Apps etc ...
I hate the way modern distro's integrate every fucking software
into their /usr -hierarchy, instead of using package-spesific
installation directories. LSB-standard suggests that
non-base-system components should go to /opt/,
tho most distro's fuck this up without a good reason.

piratePenguin:
Check this out. If someone took that concept ("package users"), made it more user-friendly, built "package user" packages (possibly listing dependencies etc), and got it working in some distros... It would totally own (nothing could beat it on security, just what we need if/when more viruses become available on GNU/Linux).
I wanted to give it a go myself but I wouldn't know where to start (well... I might...).

Package users!... Absolute genius IMO.

Navigation

[0] Message Index

[#] Next page