SlackwareThis Forum is for the discussion of Slackware Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
A journalist writing an OS review typically reads the glossies and the release notes then installs the OS and spends maybe an hour or so exploring the user interface. That's why there there is so much about the installation process in OS reviews -- it's what the typical reviewer has spent most time doing with it!
How can such a process result in a proper assessment of something as complex as an OS? A proper assessment of an OS would need at least a month of using it day-to-day for a variety of tasks, ideally (and impractically) the same tasks that the review reader will be doing.
That's why reports from a variety of real OS users are a better source of information even if they are not accomplished technical writers -- the information is based on real-life experience of the OS.
The author of the article seems to misunderstand ease of use in Slackwares context. It is easy to use because for example the Package manager doesn't push a tonne of dependecnies down on an application that doesn't need them. I See this as an ease of use point.
That's what happens when they stick to a release schedule instead of releasing when ready.
"Oh My God! It's April/October! Get it out quick!"
The OpenBSD guys also work to a 6 monthly fixed schedule but don't suffer these issues. In fact, 4.6 was ready a good month before the release date.
I believe the key difference is that the guys in the OpenBSD project just like the Slackware team understand why it's important to keep it simple and do small 'deliverable' incremental improvements. In contrast Canonical are busy tying themselves in knots trying to deliver it all at once.
I get the feeling there's a tortoise and hare thingy going on here.
The whole package dependency tracking thing is sort of silly, though. Let me demonstrate why.
When you first get your RPM-based distribution (or DEB) and you want to add software, you can, up to whatever is on the DVD(s). Life is good.
Until you need something that is (example: Mandriva) in -contrib. Usually you're fine until something needs to replace a lot of stuff, packages that came with the distribution on its shiny DVDs. Sometimes these -contributed packages are just fine: the guys who compiled them did their job and built it against your libraries and the versions of stuff you have on the DVD(s). Life is good.
But when they did something exotic, you find yourself replacing lots of libs that came with your distribution. At this point life could very well start to suck.
My experience with Mandriva/Mandrake in the past has only once been a negative one. In fact, I'm really impressed with this distribution.
However, Mandriva still cannot be installed on a (almost) fully encrypted hard drive (README_CRYPT.TXT by Eric Hameleers), i.e. LUKS and LVM2, so Slackware is still the distribution for me. Their installer recently added a LVM2 compatibility, so you could LVM+LUKS I would imagine, but you'd have to unlock all partitions separately. That and I've never tried it (sometimes distributions like this break when you try to do fancy disk stuff).
Comparing Linux distributions is like comparing brothers in the same penguin family: they all have their faults, and their places where they excel. They are equal in total worth as brothers, but some are better at some things than others.
Until you need something that is (example: Mandriva) in -contrib. Usually you're fine until something needs to replace a lot of stuff, packages that came with the distribution on its shiny DVDs. Sometimes these -contributed packages are just fine: the guys who compiled them did their job and built it against your libraries and the versions of stuff you have on the DVD(s). Life is good.
But when they did something exotic, you find yourself replacing lots of libs that came with your distribution. At this point life could very well start to suck.
You seem to imply some -contrib packages aren't built well. But I can tell you that even official packages in some distributions are built well either. In any event, if you wanted to replace said bad package from distribution, or just install something completely new from source, you can run into the same trouble. This is because of the boneheaded decisions of the distribution maintainers.
Many distributions don't use vanilla sources. So any dependency for that program you are building might not behave the way you expect. I have found that myself when supporting other distributions. Even so, you might find you want a different package in place of another to get it "just right". Then you go replacing distribution's packages anyway. The only distribution that I know of that comes close to be easy building stuff for is slackware. And that really is partly based on the fact it doesn't have dependency checking, but it can also be the fact it tries to leave the programs as pristine as can be.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
