Situation: - linux just committed suicide - a significant number of the tools I use on a weekly basis are linux/unix-only; some of them also need to be run on a fairly powerful box, so it's not viable to just semi-permanently VNC to one of our linux servers to use them (and some are network-test tools, which you want to run with no extra net-connections open!) - I do have win2k dual-boot, and will keep it, since it's a good emergency option (and I've got a bevy of win-only games on there )

So, looking at unixes available now: - solarisx86: well, I applied for it from Sun ooh, about 2.5 years ago now, but despite assurances they never sent the CD's. The last time I used s-x86 it had some serious "issues" - anyone around here using it on a daily basis? - xBSD: anyone using these? any compatibility problems with linux (e.g. problems with apps that run on linux but not BSD)? - Mandrake: never again; they FUBAR other people's software, put the suffix "-mdk" on the end, and leave you in a no-man's land of non-upgradeable software. Installer is also just as bad as RH at screwing up in major major ways - RH: (downloading Fedora now, as this appears the only decent option . I've heard RH has improved a lot in the last 1.5 releases (I've used RH5.2 through 8.0, and even 8 had serious problems ) - Debian: well, their site seems down, and anyway it's useless to me to have an OS which you are only able to use software that is several years out-of-date (anyone using Debian who has a permanent no-brainer workaround to this that doesn't rely on potentially buggy software? e.g. I'm in my present situation because of bugs in RPM, so I'd be very cautious about e.g. making things scary for poor little RPM's by using some hybrid apt/rpm tool...) - Others...?

PS I'm still hoping for the day when all critical tools have java versions, and I don't have to go through such agonizing contortions to balance a usable OS with one which actually runs my apps .

PPS If I had 2 grand to spare, I'd go and buy a Mac today . Sadly, I don't.

yes stable is stable so not up-to-date (interesting if you run a critical web-server, but not much), but SID (aka unstable) is really up to data (gnome 2.6, Xfree 4.3, etc..)

But what about the kernel, for instance? Given that the linux kernel has major "issues" wrt not being upgradeable unless you are a saint, you often end up stuck with whatever you started with (I don't have time to fix bugs in the linux kernel and associated tools just to perform an upgrade; I'm sure people with more time on their hands have an easier time of it).

Basically, after 30 minutes of searching, I cannot find an answer to such simple questions on the debian site, and the install process seems not much improved from last time I tried it - and I really don't have time to faff about learning the inadequacies of a new installer (I hate to say this, but I know most of the bugs in RH's installers, including those that have never been fixed in 5 years - and that means I know how to work around them).

I've not looked at it myself, nor debian, but the next time I get a spare box I will as running a source based distro (gentoo) is becomming more anoying each time I have to rebuild everything including X + gnome.

- Debian: well, their site seems down, and anyway it's useless to me to have an OS which you are only able to use software that is several years out-of-date (anyone using Debian who has a permanent no-brainer workaround to this that doesn't rely on potentially buggy software? e.g. I'm in my present situation because of bugs in RPM, so I'd be very cautious about e.g. making things scary for poor little RPM's by using some hybrid apt/rpm tool...) - Others...?.

Surprisingly I recommend Debian. You can always run testing/unstable, if you want newer software. Actually a lot of developers do this.

Surprisingly I recommend Debian. You can always run testing/unstable, if you want newer software. Actually a lot of developers do this.

Right. People keep saying that, but everyone avoids answering the question, so Debian remains a mystery. I don't understand why no-one will answer, except to make vague noises that Debian is kind of good. This is like the Deb docs - they don't actually *tell* you anything, as though info is only provided on a "need-to-know basis, and we've decided you don't need to know. Do not question this!"

But what about the kernel, for instance? Given that the linux kernel has major "issues" wrt not being upgradeable unless you are a saint, you often end up stuck with whatever you started with (I don't have time to fix bugs in the linux kernel and associated tools just to perform an upgrade; I'm sure people with more time on their hands have an easier time of it).

You can use a stable kernel, which is maintained and automatically updated by the security team (2.4.18).

Quote

Basically, after 30 minutes of searching, I cannot find an answer to such simple questions on the debian site, and the install process seems not much improved from last time I tried it - and I really don't have time to faff about learning the inadequacies of a new installer (I hate to say this, but I know most of the bugs in RH's installers, including those that have never been fixed in 5 years - and that means I know how to work around them).

That's contradictory. You say "the install process seems not much improved from the last time I tried it" and "I really don't have time [...] new installer". The woody (Debian 3.0 is called woody) installer is still the same since it's release 2002. The installation is not really nice, but you can often stick with the defaults.

Right. People keep saying that, but everyone avoids answering the question, so Debian remains a mystery. I don't understand why no-one will answer, except to make vague noises that Debian is kind of good. This is like the Deb docs - they don't actually *tell* you anything, as though info is only provided on a "need-to-know basis, and we've decided you don't need to know. Do not question this!"

You can use a stable kernel, which is maintained and automatically updated by the security team (2.4.18).

Completely useless. I'm not a linux newbie, so there's no point trying to claim that an out-of-date broken kernel like 2.4.18 is "good enough"; it so obviously is NOT "good enough" to anyone who uses linux heavily. NB: As far back as 12 months ago I already had software that WILL NOT RUN on that kernel, and the ONLY SOLUTION is to upgrade your kernel!

This isn't a matter of personal opinion, it's reality. It sounds as though you may be one of those linux users who never quite stress their machine enough to discover the horrible truths of linux.

Quote

That's contradictory. You say "the install process seems not much improved from the last time I tried it" and "I really don't have time [...] new installer". The woody (Debian 3.0 is called woody) installer is still the same since it's release 2002. The installation is not really nice, but you can often stick with the defaults.

If the install process had improved, there wouldn't *be* a great big time-cost to using the installer; the fact that their documentation is so woefully inaduquate makes it look extremely likely that the installer doesn't work in lots of ways, doens't have sufficient help, probably doesn't warn you about things in advance - all of which means that I, as the user, am going to have to learn all the many ways in which their installer is broken, work out the documentation from guess work, and eventually thjink up cunning and mind-bending workarounds.

In short, will all RPM software install and work perfectly on Debian, and what does the user have to do to achieve this?

How well can you install current releases of open-source software, bearing in mind that almost nothing is made available in debian by the authors, and very nearly everything is available in RPM (that is available in any pkg)?

How well does debian cope with RPM's? *How* does it cope with them? I've seen a variety of different tools for installing RPM's on Debian, but I don't know how they work or what their quality is.

If there is any difficulty at all in getting software installed onto Debian, then it's not an option for my desktop - linux software being what it is, you need to upgrade pretty much instantly on most stuff (e.g. every release of OpenOffice and Mozilla has so many critical bugs that for serious work you pretty much have to upgrade ASAP on every minor release, because the chances are your system is fundamentally broken in some way until you do. The same was true of the initial NT-4 servicepacks: NT4 without SP3 is a completely unusable OS: it's broken in so many ways that most complex apps just don't work. I'm sure eventually Moz and OO will reach the point where they work well enough that users can slow down a bit on the upgrades, but not yet.)

For documentation you best look at madrake, suse and redhat. If I recall mandrake is not an option this time . I've not used suse, but I have used deadrat. I'm currently using red hat on a managed box over in yank land somewhere, and run gentoo at home (for my sins). I've run redhat up t 7.2, and not touched it since untill we got the box in the states. I'm fairly pleased with up2date as a package manager, and so far neither me nor the box have managed to kill the rpm database (although I did it a few times with <=7.2 which is why I left it alone). Having said that, gentoo managed to screw portage over at one point, so I don't supose it's really any better. Now that up2date will solve dependancies for you, it seems much better than before it existed. Redhat still installs loads of crap for you as far as I can tell (although the box came ready installed), but i've got rid of the junk (like rpc sat happily listening away for the next attack). Redhat also back port alot of stuff into their own kernel, so although we have a 2.4.21 kernel running, it has useful things in it like NPTL.

I'm in two minds as to what to try next distro wise, either debian sarge or redhat again, one gives you nothing to start with, the other gives you everything including the kitchen sink, even though your in the bathroom, so you have to cut some stuff out. It sounds like redhat is your best option, purly from the docs point of view, add to that the fact that redhat kernels have lots of extras in (dunno if jinput will work mind ) and my suggestions would be redhat.

Suse is pretty good, but it's got some mental handicaps; if/when those get fixed, I suspect it will be one of the best (alongside Debian for non-desktop deployment).

Quote

I'm fairly pleased with up2date as a package manager, and so far neither me nor the box have managed to kill the rpm database

Ditto had the odd RH corrupted RPM-db in 6.x and 7.x

Mandrake killed the RPM database on multiple installations; incidentally it also managed to "disable" man pages, so that all RPM's would silently delete/not-install their docs, and there was no way to turn this off (even completely replacing the RPM version, completely wiping the RPM db and starting again, etc). I never found a linux user of sufficient skill who could work out WTF Mandrake had done...

Quote

existed. Redhat still installs loads of crap for you as far as I can tell (although the box came ready installed), but i've got rid of the junk (like rpc sat happily listening away for the next attack)....even though your in the bathroom, so you have to cut some stuff out.

Too true (was why I ran away from RH in the first place!).

A warning for all: Redhat 10 (or fedora, as the irritating marketing ****ers insist on calling it) is *just as bad as it always was* in terms of lieing to your face about what it will install. e.g. I tell it "no Gnome", and see loads of Gnome-only packages installing. e.g. it lets you get right to the end of the install before hinting that it's not going to let you select pacakges, because you're not as godlike as the RH engineers and shouldn't be allowed to - unless you entered the expert install at step 1. (these being the same godlike RH engineers who can't understand that "No Gnome" means "Do not install any packages that require or are a part of Gnome").

Oh, and they've downgraded the disk-paritioner - it now has fewer options than the RH7/8 one(s) and is harder to use.

In order to make the install work properly, you'll probably need to use the undocumented expert mode. Now, this used to be documented, and gives you extra options. In their infinite wisdom, they've apparently removed the option.

But...if you're an old-hand with RH, and you remember what the instructions USED to say on the opening screen, about how to get into expert mode, and just try it, it still works! Ah, how I love RH!

So, where it says "hit enter to install linux, or "linux text" to use the text install" do neither. Type "linux expert" instead. You will get the text-mode installer but with extra options, some of which IMHO are not so much "expert" options but "standard install options that every user should be allowed". For about 5 years mandrake's installer has let you switch into expert mode *at any point*; RH are still in 1980, where something as monumental as changing a boolean flag requires you to restart the install from scratch. Sigh...

Incidentally, there also seems to be considerably less interactive help than in old versions of RH. I could be mistaken; it's been a long while.

PPS: this has already added 2.5 hours to my re-install time; I have to re-start from scratch. Just as I expected!

In short, will all RPM software install and work perfectly on Debian, and what does the user have to do to achieve this?

No, you should only install RPMs in corner cases. You can convert RPMs to DEBs using a tool called "alien". I don't recommend installing an RPM directly.

Quote

How well can you install current releases of open-source software, bearing in mind that almost nothing is made available in debian by the authors, and very nearly everything is available in RPM (that is available in any pkg)?

Your assumption is not right. There's quite a lot of software available as debian packages. If you want current releases of open source software, you can use testing/unstable. Another options are backports (packages ported from unstable to stable).

Quote

How well does debian cope with RPM's? *How* does it cope with them? I've seen a variety of different tools for installing RPM's on Debian, but I don't know how they work or what their quality is.

The tools are probably good (not that the average user ever needs them), but if a package was designed for say Redhat 9, it may have wrong dependencies and the installation and deinstallation scripts may be designed for Redhat and not for Debian.

For which open source software, which you need, is there a package for Redhat, but none for Debian? What software do you need?

Quote

If there is any difficulty at all in getting software installed onto Debian, then it's not an option for my desktop - linux software being what it is, you need to upgrade pretty much instantly on most stuff (e.g. every release of OpenOffice and Mozilla has so many critical bugs that for serious work you pretty much have to upgrade ASAP on every minor release, because the chances are your system is fundamentally broken in some way until you do.

Updating is not a problem at all. Debian package management is excellent.

Give it a try. The installation is ugly, but with some good will you will be rewarded and have a really fine system for years. Debian is surely not perfect, but I think you'll like it.

Your assumption is not right. There's quite a lot of software available as debian packages. If you want current releases of open source software, you can use testing/unstable. Another options are backports (packages ported from unstable to stable).

IME, only one time in ten (if that) is there anything other than RPM. I install an awful lot of software, and this pattern is repeated everywhere. There are even still a significant number of apps that are only distributed as tar.gz (ARGH!) or even worse, as source (!!!). I can't produce any statistical data, beyond the fact that my experience seems shared with every friend and colleague who has ever been a linux admin.

Quote

The tools are probably good (not that the average user ever needs them), but if a package was designed for say Redhat 9, it may have wrong dependencies and the installation and deinstallation scripts may be designed for Redhat and not for Debian.

This was the excuse that used to be common for not providing RPM's. However, in the last few years I've found that almost every RPM installs fine on other non-RH systems (except where you have a screwed-up system, e.g. Mandrake which just breaks the whole of KDE in undocumented ways).

Quote

Updating is not a problem at all. Debian package management is excellent.

Give it a try. The installation is ugly, but with some good will you will be rewarded and have a really fine system for years. Debian is surely not perfect, but I think you'll like it.

Yes, I'm convinced of the above two points. Next time I have a server to install, it will be stable Debian (although not this time: I'm installing a server as well as my workstation, and the server needs a modern kernel AND I only have time to do it because I'm doing the workstation install anyway.).

But most open-source projects make the base assumption that all users will upgrade to the latest version instantly. Witness MySQL: a product (and company) which has an official policy of never fixing bugs in old versions. Staying with one major version of MySQL is not an option (never an option) because of the hundreds of critical bugs marked "WONTFIX" and "upgrade to 4.x.x. instead" even when the original reporter has made it clear that this is not an option (I guess that's *one* way of making more money: follow the MS model, and intentionally lower the quality of your software so that more people will pay for the support...).

PS: RH-10 is even worse than I thought: they've actually entirely removed the ability for the user to choose packages (although almost all the other "expert install" options are still there). I guess they just got embarassed at how crap their code for choosing packages was (c.f. my notes about their inability to understand te concept of "not Gnome" above)

Completely wrong. I never needed an RPM and I install quite a lot. I'm sure, that this is not just personal experience. It's often a lot easier to find an appropriate deb (mostly it's just "apt-cache search $package").

Quote

This was the excuse that used to be common for not providing RPM's. However, in the last few years I've found that almost every RPM installs fine on other non-RH systems (except where you have a screwed-up system, e.g. Mandrake which just breaks the whole of KDE in undocumented ways).

Why, the hell, should Debian provide RPMs? They have DEBs.

You made up an artificial problem, which doesn't exist. If you don't believe me, then tell me, which open source applications you need. You didn't answer this question before.

Quote

Yes, I'm convinced of the above two points. Next time I have a server to install, it will be stable Debian (although not this time: I'm installing a server as well as my workstation, and the server needs a modern kernel AND I only have time to do it because I'm doing the workstation install anyway.).

If you need a modern kernel, then type "apt-get install kernel-image-2.6.5-1-386".

You misunderstood me (my fault for being vague): I was referring the os projects that would not provide RPM's (5 years ago, more often than not I'd find that an app I wanted didn't have RPM's "as policy"; these days it's uncommon if not rare).

Quote

You made up an artificial problem, which doesn't exist. If you don't believe me, then tell me, which open source applications you need. You didn't answer this question before.

Pretty much all the software I use; if someone were to pay me, I'd happily do a report and detail all the particular programs. As it is, since I know of no automatic way of doing that, it would take me several hours to find out for you. I don't have several hours to spare. Sorry.

Quote

If you need a modern kernel, then type "apt-get install kernel-image-2.6.5-1-386".

The problems with kernel upgrades are little to do with the distribution; there are major bugs (I would call them "fundamental design errors") in the way that kernel upgrades happen, as put in place by the maintainers. It's irrelevant how good/bad Debian is at handling kernels unless the Debian authors have written a secret compiler that can compile the kernel source code without being as fragile as the current make-system (which falls over if you say "Boo!" at it).

There are multiple machines *in this office* which it is physically impossible to upgrade the kernel. We've been told to "reformat and re-install". This is by no means a unique experience (it's nothing to do with hardware, it's just stupid aspects of how kernel compiling is done, partly AIUI because of the insistence on using Make, which is one of the worst tools in the world for compilation-mgmt, and suicidal on a huge project like a kernel )

Pretty much all the software I use; if someone were to pay me, I'd happily do a report and detail all the particular programs. As it is, since I know of no automatic way of doing that, it would take me several hours to find out for you. I don't have several hours to spare. Sorry.

You can type "rpm -qa | sort" to list all packages. Admit it, you just don't want to give me material to prove you're wrong in this case!

Quote

The problems with kernel upgrades are little to do with the distribution; there are major bugs (I would call them "fundamental design errors") in the way that kernel upgrades happen, as put in place by the maintainers. It's irrelevant how good/bad Debian is at handling kernels unless the Debian authors have written a secret compiler that can compile the kernel source code without being as fragile as the current make-system (which falls over if you say "Boo!" at it).

There are two "Debian ways" to update your kernel. The first one is to compile the kernel as a debian package and the second one is to use a kernel image. If you use the compiled kernel images, you don't have to compile the kernel yourself. So apt-get install kernel-image-$version manages the whole installation. I prefer to do apt-get install kernel-image-$version-k7, which installs a kernel image compiled for Athlon/Duron (kernel-image-$version-686 is for Pentium). The drawback of kernel images is, that you can't create very small or exotic kernels. You can also install several kernels in parallel. This way you can have the official 2.4.18 kernel and a 2.6.5 kernel.

You can type "rpm -qa | sort" to list all packages. Admit it, you just don't want to give me material to prove you're wrong in this case!

No, then I have to go and find out which ones were offered in what forms. I probably also need, for each that is available as a DEB (e.g. where debian people have provided them rather than the authors), to check if there's some special reason why the latest version is absolutely essential, and whether the DEB is that up-to-date.

I would not be keen to post my RPM list on the net for others to pick-over themselves for security reasons.

Quote

There are two "Debian ways" to update your kernel. The first one is to compile the kernel as a debian package and the second one is to use a kernel image. If you use the compiled kernel images, you don't have to compile the kernel yourself.

Is this any different from the RH kernel RPM's which used to be distributed as-and-when they felt like it, and were often "interesting" variants on the mainstream kernel?

My memory is that there are/were plenty of situations where this is not an option and you really do have to compile yourself (I think to do with unusual hardware? Possibly for my external network-card?). But I'm no kernel hacker, so I wouldn't know; if someone could come forwards and cite cases where they'd had some of those situations which tend to dead-end your linux kernel, and that this had gone smoothly on debian, that would be great (to date, although I've asked this a lot (IRL more than online), debian users tend to just look at you blankly, and then suggest perhaps debian is immune to such things? That's no good unless the debian maintainers are writing their own unique kernel separate from Linus etc: these are known problems! Unfortunately debian users tend not to have ventured widely enough to have hit them. Incidentally, I've met a few BSD users who *have* recognized some of the painful problems on linux and claimed they have avoided them - but then pointed out that BSD has it's own problems to make up for it )

Disaster. RH 10 is so crap it can't even install two network cards and the loopback; I have a 127.0.0.1 that maps to NOTHING, and I have *no idea* how to get it back.

Also, ifup eth0 fails, but dhclient causes eth0 to correctly load from DHCP; the config options in sysconfig (for anyone familiar with RH...) are setup as per normal, specifying DHCP, but it's not doing it.

I am really screwed if I can't get 127.0.0.1 because there are SO many linux apps that will not run without it! Anyone have any ideas? I've got at least one that won't even *install* if it can't use that for loopback

It's Debian-unstable based, so your apps are bang up to date, and the hardware detection is good. Probably one of the best feaures is that it's a live-cd with an option to install, so you can try it without risking anything, and then surf the web while it installs! Plus, if it gets borked, you can use the install disc to boot in and try and sort out the problem.

The 2003.10 version runs kernel 2.4.22, and they've just started a beta test of 2005.05, which has the option of a 2.6 kernel.

I've been running it on a new laptop for a few months now, and had no real problems with it.

No, then I have to go and find out which ones were offered in what forms. I probably also need, for each that is available as a DEB (e.g. where debian people have provided them rather than the authors), to check if there's some special reason why the latest version is absolutely essential, and whether the DEB is that up-to-date.

The DEBs in unstable are up to date (only release versions of software of course, no alpha or beta releases; despite the name unstable has about the release quality of other distributions, but occassionally things can break). Is it really so secret and difficult to tell me, which apps you are using? If yes, you can go to the Debian website, click on "Debian packages" and search for the packages you need.

You're hard to convince (if possible at all). Reminds me of the story of MS and bug reports:

Quote

Friend: "I'd like to report a bug in Word. When you have an CR at the end of a document, the CR won't be saved in the document"MS: "Could you send me such a document?"Friend: "Eh, sir?"MS: "Could you send me such a document?"Friend: "That won't be possible."MS: "Why not?"Friend: "Because the CR won't be saved."MS: "If you can't reproduce the bug, than there's nothing we can do about it."Friend: "But..."MS: "Sorry sir, we can't help you. Good day."

Let me make an educated guess. Your next argument is probably, that you don't have time to check the Debian website, if the packages you need are in testing/unstable. This way you can still insist you're right.

Quote

I would not be keen to post my RPM list on the net for others to pick-over themselves for security reasons.

Sounds like security by obscurity. Of course you don't have to publish your package list, but it's quite easy for you to insist on your opinion, if you don't give others a chance to prove you're wrong. After all you blame Debian users for not answering your questions. In this case you don't give me a real chance to do it.

Quote

Is this any different from the RH kernel RPM's which used to be distributed as-and-when they felt like it, and were often "interesting" variants on the mainstream kernel?

Debian doesn't patch the kernels a lot.

Quote

My memory is that there are/were plenty of situations where this is not an option and you really do have to compile yourself (I think to do with unusual hardware? Possibly for my external network-card?). But I'm no kernel hacker, so I wouldn't know; if someone could come forwards and cite cases where they'd had some of those situations which tend to dead-end your linux kernel, and that this had gone smoothly on debian, that would be great (to date, although I've asked this a lot (IRL more than online), debian users tend to just look at you blankly, and then suggest perhaps debian is immune to such things? That's no good unless the debian maintainers are writing their own unique kernel separate from Linus etc: these are known problems! Unfortunately debian users tend not to have ventured widely enough to have hit them. Incidentally, I've met a few BSD users who *have* recognized some of the painful problems on linux and claimed they have avoided them - but then pointed out that BSD has it's own problems to make up for it )

It's not the task of Debian to try to solve the problems related to the Linux kernel. The maintainers just try to make the user's life as easy as possible. And yes for unusual hardware it's possible, that you have to compile your own kernel. The standard kernels often include a lot of modules you can load (or which are automatically loaded), but surely not all of them.

Completely useless. I'm not a linux newbie, so there's no point trying to claim that an out-of-date broken kernel like 2.4.18 is "good enough"; it so obviously is NOT "good enough" to anyone who uses linux heavily. NB: As far back as 12 months ago I already had software that WILL NOT RUN on that kernel, and the ONLY SOLUTION is to upgrade your kernel!

Ahem, which software? By this time the newest kernel version was 2.4.20. It's possible, that you have to upgrade the kernel for different reasons (e.g. JInput), but this is not a problem, if you are not a newbie. And saying that Debian's 2.4.18 kernel is broken is simply ridiculous.

Quote

If the install process had improved, there wouldn't *be* a great big time-cost to using the installer; the fact that their documentation is so woefully inaduquate makes it look extremely likely that the installer doesn't work in lots of ways, doens't have sufficient help, probably doesn't warn you about things in advance - all of which means that I, as the user, am going to have to learn all the many ways in which their installer is broken, work out the documentation from guess work, and eventually thjink up cunning and mind-bending workarounds.

The installations isn't nice, but there is a lot of documentation. Debian doesn't change the stable distribution (including installer) except security issues.

. I get the impression the only way I'm going to get any networking is by breaking RH (wiping all the crummy net config and just putting it all back in by hand, which will probably screw up all future scripts upgrades - but if the alternative is "no networking"...). My prior experience with RH is that you have to do this more often than not if you have anything even remotely "interesting" in your initial networking setup - this is one of the areas they took years to fix even the blatantly obvious show-stopper bugs .

java-gaming.org is not responsible for the content posted by its members, including references to external websites,
and other references that may or may not have a relation with our primarily
gaming and game production oriented community.
inquiries and complaints can be sent via email to the info‑account of the
company managing the website of java‑gaming.org