Ubuntu: The Verdict

[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]

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.

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.

[ksym]

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.

No.

That system has no good groundbreaking ideas ...
no good dependency handling, no automation. Bah.

btw that still reverts to some perverted old unix-crap, like
'having to run ldconfig as root'. I've never had problem
creating a package/user spesific ldcaches so forth ...

If you wanna do something really cool, then try to
develop a package-build-system, that
1) works perfectly with other lower level systems like
gnu/autotools, linux kbuild, java ant-build, scons etc ...

2) has a tightly spesified standard, which does not allow
to define multiple versions of same package. all relevant
options, like --march optimisations, should be included
to the package ... maybe by compiling the binaries multiple
times

3) adds USEFUL metainformation to packages, allows
one to totally get rid of direct-dependencies.
Most needed libraries/othercrap would be integrated
to the package ... etc

And so forth etcetera ...

[bedouin]

I really don't care about the technical superiority or inferiority of RPMs; all I know is that every distro based on it sent me into the so-called RPM dependency hell.  My past experiences with it void any merits it may have.

apt-get, on the other hand, has worked flawlessly.  Nearly every Linux app that's not niche is included in Debian's package library.  On top of that, I'm running Debian on PPC, a minority platform that usually gets the shaft when it comes to binary packages; the coverage has been equal between PPC and x86 in Debian.

[piratePenguin]

No.

That system has no good groundbreaking ideas ...
no good dependency handling, no automation. Bah.

That's why I was thinking that a system that uses package users and has this dependency handling etc., would be pretty damn cool.

And the package users idea is ground shattering!

The hint I refered to, was (largely) specific to Linux From Scratch (LFS). It was NOT designed to be automated and have dependency tracking or whatever. A package manager based on those concepts, with automation, dependency tracking, et cetera, would be pretty damn sweet.

[Orethrius]

One of the members here had a pretty groundbreaking idea not too long ago in the form of Linux binary packages.  Don't remember if it was Jeff or Stryker though.  

[ksym]

One of the members here had a pretty groundbreaking idea not too long ago in the form of Linux binary packages. Don't remember if it was Jeff or Stryker though.

How about we make the packages normal ISO -images?
The packages would contain some XML-files, who would define
the sonames and other required interfaces (services, binaries etc) ... and these files would ALSO define the URL:s where
one could download the needed packages. Like bittorrent or
something.

And if an ISV want's to make a retard-proof click'n'pray
application, he would just include ALL the
libraries/binaries that are not defined in LSB.
Then in the target-distro a user could simply click the
ISO, mdm-platform daemon would loop-mount the ISO,
generate a sandbox (with sonames, ldcache, binary assignements
etc) and Run The Damn thing! =)

This idea I got by browsing some developer comments from
the Darwind project. Damn those Apple guys made a
fine job with that Frameworking system.

[WMD]

I like Apple's package system.  One program, one file, one folder for all.  This does raise some issues with dynamic vs. static linking, but that hasn't caused much trouble yet.

[worker201]

One of the members here had a pretty groundbreaking idea not too long ago in the form of Linux binary packages.  Don't remember if it was Jeff or Stryker though.  

I believe it was Jeffberg and theJimmyJames who came up with the idea.  They kicked ideas around with some guy whose name I have forgotten, and were going to build their own distro, Komodo Linux, with a GUI called GenSTeP.

[worker201]

I really don't care about the technical superiority or inferiority of RPMs; all I know is that every distro based on it sent me into the so-called RPM dependency hell.  My past experiences with it void any merits it may have.

apt-get, on the other hand, has worked flawlessly.  Nearly every Linux app that's not niche is included in Debian's package library.  On top of that, I'm running Debian on PPC, a minority platform that usually gets the shaft when it comes to binary packages; the coverage has been equal between PPC and x86 in Debian.

Where you been, slick?  apt works on rpm distros too.  Granted, there aren't as many packages as there are for Deb, but it works just the same.  There's even a GUI interface to it called synaptic that lets you click to install or remove packages.  I use it in Fedora.

Unfortunately, I can't tell what the integration is like with non-apted rpms.  Like, if you download an rpm and install it yourself, I don't think apt will know about it.  That could be improved on.  It certainly would be nice to have one central database that tracks every program on the machine, whether you installed it from source, package, or package manager.

[piratePenguin]

One of the members here had a pretty groundbreaking idea not too long ago in the form of Linux binary packages. Don't remember if it was Jeff or Stryker though.

Any of yas remember what this groundbreaking idea was more specifically?

[worker201]

Any of yas remember what this groundbreaking idea was more specifically?

The idea was to have packages work like OSX programs.  For a good example, take gimp.app - it uses a wrapper script to add all the dependencies to the package.  So instead of linking off system libraries, it links off its own resources.

Not all that well thought out - certain libraries, like gtk, atk, pango, freetype, and glibc, for example, need to be used over and over again, which is why we link and share them in the first place.  No offense to those guys, because they were cool, and at least tried to turn their ideas into reality, but they were thinkers, not doers.

I think synaptic is just about the best idea I've seen yet.  If you want to install a package, it tells you what dependencies need to be met, and one click allows you to add all these extra packages.  Unfortunately, the rpm repositories don't have the latest and greatest apps and versions.  The system tends to break down when you're dealing with a package like ffmpeg, which is updated almost daily, but released only every six months.  The only way to get a working copy is to go CVS - any package built off a release is completely unsupported.  And ffmpeg is damn difficult to install from source.  So you have to go outside the system occasionally.