Sorry, but it's just lies at this point
Sorry, but it's just lies at this point
Posted Aug 16, 2008 21:10 UTC (Sat) by drag (guest, #31333)In reply to: Sorry, but it's just lies at this point by khim
Parent article: Something going on with Fedora
> Have you tried to do the same (compile software and it's dependencies from scratch) under Windows? Try it some time. You'll probably need to find few abandoned packages, buy some tools - and in the end get some non-working piece of software because your system included wrong set of headers... They point is _I_Don't_have_to_. Not when I just want to run the software. Every major open source project I've seen that has Windows support supplies Windows users with executables and supplies Linux users with source tarballs, with only a few exceptions on the Linux side. ------------------------------------------- I think your misunderstanding me a bit: What I want to see is a video game like Planeshift (It's a decent Linux MMORPG which follows the ID Software approach were the engine is GPL, but the game itself is open, but non-free) simply supply two DEB (or whatever) packages, themselves, that outline the dependencies and versions they need. Then the various distributions just pull down that package. If there is something wrong then they figure it out and send a patch back to upstream. Right now the package makers working for the various distributions are a huge bottleneck in the distribution of new Linux software. This is because it requires such a huge manual brute-force approach. For some software this is the only way it's going to work, but for the vast majority.. something I expect like 80% don't need that level of dedication from the distributions. Even if they supply it in deb-src format, and distributions use their servers to compile it, then it's still worlds better then what we have now. Get it now? Going back to video games, in Linux there is no way for the average Linux user to compile them. The makers of them are forced to use all those nasty scripts and install dialogs to package them for Linux users. That's they only way they can get it to work. And like you said they are full of nastiness like having to use scripts with ld_library_path and statically compiled binaries and weirdness. These make the games much larger then they need to be and make it impossible for Linux users to use anything but the very latest games on the very latest distribution releases. And beta testing? _FORGET_IT_. It's impossible. Even for the latest and greatest from Debian Unstable I need to do things like setup a chroot environment because trying to install the software I need will obliterate any hope of having apt-get not break my system. And with that your looking at _days_ of effort. And on top of that, because the way Linux users are utterly dependent on their distributions-supplied packages, there is no way the average Linux users will ever know about 90% of the games that are available for Linux unless they subscribe religiously to something like happypenguin.org, So what we have in Linux distributions is a handful of fairly decent FPS or some smaller 'gnome' or 'kde' games and older stuff that are packaged by the distribution maintainers, but they don't have the time or desire to track down every new release of every game out there. And that's just games. I could go on and on for any sort of type of software you want. How about Host-based Intrusion detection systems? I am working on evaluating that stuff from work and due to various thingsthat are 100% out of the control of myself, my bosses, and my entire company, having to compile things from source is not fun. It's certainly possible, but it adds lots of hoops. And entirely besides that I don't like to have to install a large number of developer's tools on production machines. How many of these are packaged by your distribution? Samhain OSSEC Integrit AIDE Tripwire (OSS version) Tiger They all seem to be good, solid, and stable pieces of software. And they don't have very complex dependencies or anything like that. Some are packaged for certain distributions, some are packaged for others, and some are packaged for none. There is no reason why they can't simply supply a couple binaries in their own packages so I can install them and test them out, except that I can't. Because distributions are the gatekeepers to what is installable on my system and they don't have the manpower to manage all of that on their own. (OOOHHH.. that's right. I am using Linux so I don't have to care about malware or rootkits because the packages supplied by my distribution is the perfect way to provide my system with unbreakable security. Well that solves that problem!)
Posted Aug 16, 2008 23:23 UTC (Sat)
by njs (subscriber, #40338)
[Link]
Sorry, but it's just lies at this point
I'm sorry you feel so much frustration.
> How many of these are packaged by your distribution? Samhain, OSSEC, Integrit, AIDE,
Tripwire (OSS version), Tiger
I did take a quick look at this, though, and it looks like for Debian and Ubuntu the answer
is, all of them except OSSEC. Additionally, the Tiger package appears to contain extensive
enhancements to let it make use of the dpkg database to better validate installed files. A
quick google suggests[0] that the hold-up on integrating OSSEC is a combination of manpower,
the fact that the upstream package is garbage (seriously, /var/ossec/etc, /var/ossec/bin?),
and the fact that OSSEC is *not legal to redistribute*, because the authors don't understand
that the GPL and OpenSSL licenses are incompatible.
This is a rather nice example of how expertise in coding does not imply expertise in
distribution. They're different skill-sets.
I see two changes you might be arguing for. The first is that upstream authors should
habitually make their own packages. As we see in the case of OSSEC -- and this is pretty much
the universal opinion of anyone whose dealt with any sort of vendor-produced packages ever --
this is an AWFUL IDEA because a huge percentage of upstream will give you garbage. So as a
user, I insist on having some technical and legal gatekeeper between upstream and my machine.
In fact, the possibility of getting such a gatekeeper is generally considered to be one of the
major advantages of Linux over Windows.
The other thing you seem to argue is that okay, if we need a gatekeeper, there should still
only be one of them -- systems should be similar enough that once one person has done this
work, everyone can make use of it. Roughly, this comes down to saying "there should only be
one distribution". Which, well, I guess I can see the argument... but frankly it doesn't
matter how good the argument is, because as soon as you successfully got things down to one
distribution, some jerk would ignore all your hard work and start another one, and there we go
again. But maybe it helps to reflect that having multiple distributions also creates a lot of
good to justify the bad -- it creates competition to drive development, it provides space for
many different approaches to be explored (look at e.g. all the different init systems) before
any single one is picked, etc.
Hope that helps.
[0] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=361954