The stable install put in place a kernel with no NFS-3 support, and the nfs-kernel-daemon accepted remote NFS clients but then the clients would just hang immediately; had to replace with the user daemon, and it seemed to work OK then.

Also, I tried the upgraded kernel offered by testing, and the machine wouldn't even boot, claiming it couldn't find the root filesystem; it kernel-crashed with the message "supply root= boot parameter", which I did, and it still crashed (nb: using the install-CD's kernel, the same thing happens (because it doesn't know where the root is, of course!), but if you supply the root param, it works. So, either that version of the kernel is spouting wrong error messages, or debian's compile of it is screwed up). My best guess was that although every partition is ext3 the debian maintainers had allowed the kernel to compile without ext3 support (noting, of course, that the install CD was fine!)?

Right now I'm attempting to get the machine to participate in our distributed compile/build system, and getting horrible kernel and NFS errors - and trying to establish if it's misconfiguration of the SCM, or if Debian's NFS is more deeply broken than just that one daemon, or if Mandrake's NFS client is broken (unfrotunately, there's nothign I can do to fix it if that's the case!).

So, one week and counting, and I still have no workstation (I'm limping along by ssh'ing to multiple other workstations to run my apps) and with major deadlines looming (and some missed) I don't have time to do much mroe for probably at least a week.

On the upside, Debian does have the best package manager I've yet seen - just like Suse's (it could almost be a "re-write from scratch" by the same authors, determined to do better second time around), but with more options, although just like Suse's the UI was designed by a moron who'd never heard of "ease of use" or anything like that (everything is achieved by combinations of 20-odd single-key commands, some of which are context-sensitive, and there's a "windows" metaphor with NO explicit indication of the windows' existence, and, and, and...). Oh, and the official Debian docs don't even mention the existence of this tool (aptitude); without it, debian package installing is even harder than RPM installing, although probably (given how buggy RPM is) more stable. In fact, the debian docs (having now used them in anger) are even worse than I thought before starting: my advice is don't even bother reading them, they're the worst or second-worst I've seen for any distro, including being wrong or self-contradictory.

Also, I tried the upgraded kernel offered by testing, and the machine wouldn't even boot, claiming it couldn't find the root filesystem; it kernel-crashed with the message "supply root= boot parameter", which I did, and it still crashed (nb: using the install-CD's kernel, the same thing happens (because it doesn't know where the root is, of course!), but if you supply the root param, it works. So, either that version of the kernel is spouting wrong error messages, or debian's compile of it is screwed up). My best guess was that although every partition is ext3 the debian maintainers had allowed the kernel to compile without ext3 support (noting, of course, that the install CD was fine!)?

Which kernel did you install and how did you install? I assume you did "apt-get install -t testing kernel-image-bla" and got the dependencies automatically installed. These kernels always come with a lot of stuff compiled as a module. You can use "modconf" to include certain modules, if you think anything is missing (not loaded automatically). Ext3 support is surely not the problem. The kernel images boot from a small image file (/etc/initrd.img-bla), so if your lilo.conf is messed up it won't boot correctly. So make sure your /etc/lilo.conf has such a section (2.6.5 kernel for AMD as an example):

The files can also be symlinks of course, but it doesn't hurt, if you enter the paths directly, especially if you have more than two kernels installed. (Imho debconf asks you, if lilo.conf should be modified automatically or if you want to do it yourself.)

Quote

Right now I'm attempting to get the machine to participate in our distributed compile/build system, and getting horrible kernel and NFS errors - and trying to establish if it's misconfiguration of the SCM, or if Debian's NFS is more deeply broken than just that one daemon, or if Mandrake's NFS client is broken (unfrotunately, there's nothign I can do to fix it if that's the case!).

There's rarely something completely broken in Debian, because the maintainers use the packages for their daily use. So try to get some help at the mailing lists to make sure you have done everything correctly. Check the bug reports and list archives to see, if someone else has reported a similar problem.

Quote

On the upside, Debian does have the best package manager I've yet seen - just like Suse's (it could almost be a "re-write from scratch" by the same authors, determined to do better second time around), but with more options, although just like Suse's the UI was designed by a moron who'd never heard of "ease of use" or anything like that (everything is achieved by combinations of 20-odd single-key commands, some of which are context-sensitive, and there's a "windows" metaphor with NO explicit indication of the windows' existence, and, and, and...). Oh, and the official Debian docs don't even mention the existence of this tool (aptitude); without it, debian package installing is even harder than RPM installing, although probably (given how buggy RPM is) more stable. In fact, the debian docs (having now used them in anger) are even worse than I thought before starting: my advice is don't even bother reading them, they're the worst or second-worst I've seen for any distro, including being wrong or self-contradictory.

Are the "Debian docs" the docs on debian.org?

Glad you are happy with the package management (I hope you did read my mail). The reason why aptitude isn't mentioned is, that users can choose their tool. I think KDE and Gnome have packaging tools, too, which may be easier to use. I prefer the commandline, because it's handy and the commands are quite simple anyway.

Btw. you should be more precise, if you report problems. It's not important here, but very important, if you look for help in Newsgroups/Mailing lists/Forums. It's also important not to try to change things, if you don't know, what you're doing.

Which kernel did you install and how did you install? I assume you did "apt-get install -t testing kernel-image-bla" and got the dependencies automatically installed. These kernels always come

Yep. It all seemed to work fine, just wouldn't boot .

Quote

The kernel images boot from a small image file (/etc/initrd.img-bla), so if your lilo.conf is messed up it won't boot correctly. So make

I have compiled kernels many times, and rescued lilo's (mine and other people's) quite a few times too; the first thing I did was check lilo.conf and tweak and fiddle to try and fix. Debian by default had chosen "auto-select", so anyone not familiar with lilo probably wouldn't even have realised they could enable the menu.

(nb: debian had configured lilo.conf using some deprecated paramters that no longer work; I had to fix those too).

Quote

correctly. Check the bug reports and list archives to see, if someone else has reported a similar problem.

I have minutes to debug my OS, not days. When I have days, I might look at mailing lists - but they are the most stupid way of doing support (list-archives never have decent search facilities - bear in mind this is the 21st century, and good searching is a well researched topic)

Quote

Are the "Debian docs" the docs on debian.org?

Yes, and any others I could find on debian-specific sites (in a desperate attempt to find something that made up for the debian.org rubbish...)

Quote

It's also important not to try to change things, if you don't know, what you're doing.

I'm not sure what that means. Linux (seemingly debian especially) you never know what you're doing, because everyone's either too lazy to document properly, or else hides the docs where you can't find them, or (like GNU) puts them into some non-standard custom crappy doc system that's designed to make life as hard as possible for the user. Linux apps never have built-in help that is both helpful AND has full coverage...and rarely do they have built-in help that refers to the version you're running (it/s normally out-of-date and no longer valid; I've lost count of the number of times that app help has been self-contradictory).

Even worse, linux has no standardization, and linux geeks are among the most heinous committers of "not invented here (...so I'm refusing to use it because everyone else in the world is not as clever as *I* am)" syndrome. So what works on 5 distros will break the 6th. Configuration is almost always in different places - but almost always has the files present in the places you expected (and then you spend days wondering why your changes to /etc/xxx are having no effect: it's because the other scripts have been configured to ignore xxx even though the installer put it there!). When config is in the same place, it's almost always subtly different and incompatible - even from release to release.

[sarcasm]And, of course, the world of linux developers would spontaneously implode if any distro were to do something like make it easy to find config, or to have only one program for configuration with a name like "setup" - as opposed to having 20 of them, many with stupid names that mean nothing, like "aptitude" (!!?!) and "linuxconf" etc. And making them impossible to find unless you already know what they're called. [/sarcasm]

Basically, no-one ever knows what they're doing with linux, they just have a vague idea and always type with two fingers crossed. Except for a few die-hards who've been using the same versions without upgrading for the last 10 years, and finally know the ins and outs of all their apps. But don't think I'm bitter - I have plenty of windows licenses (XP, NT, 2k) spare and could run any version of windows instead; I choose to run linux for a variety of reasons (none to do with politics; some to do with windows bugs; many to do with linux-only apps )

I have minutes to debug my OS, not days. When I have days, I might look at mailing lists - but they are the most stupid way of doing support (list-archives never have decent search facilities - bear in mind this is the 21st century, and good searching is a well researched topic)

What about using google? It can search in groups. And it really doesn't take days. Why should you try to solve all the problems alone without any help from outside. It doesn't make sense for me.

Quote

I'm not sure what that means. Linux (seemingly debian especially) you never know what you're doing, because everyone's either too lazy to document properly, or else hides the docs where you can't find them, or (like GNU) puts them into some non-standard custom crappy doc system that's designed to make life as hard as possible for the user.

Are you talking about manpages? Btw. why are you so cryptic. One always has to guess, what you are talking about.

Quote

Linux apps never have built-in help that is both helpful AND has full coverage...and rarely do they have built-in help that refers to the version you're running (it/s normally out-of-date and no longer valid; I've lost count of the number of times that app help has been self-contradictory).

Do you really think they _never_ have builtin help? There are quite a number of counterexamples.

Quote

Even worse, linux has no standardization, and linux geeks are among the most heinous committers of "not invented here (...so I'm refusing to use it because everyone else in the world is not as clever as *I* am)" syndrome. So what works on 5 distros will break the 6th. Configuration is almost always in different places - but almost always has the files present in the places you expected (and then you spend days wondering why your changes to /etc/xxx are having no effect: it's because the other scripts have been configured to ignore xxx even though the installer put it there!). When config is in the same place, it's almost always subtly different and incompatible - even from release to release.

There is a filesystem standard and Debian cares about it.

Quote

[sarcasm]And, of course, the world of linux developers would spontaneously implode if any distro were to do something like make it easy to find config, or to have only one program for configuration with a name like "setup" - as opposed to having 20 of them, many with stupid names that mean nothing, like "aptitude" (!!?!) and "linuxconf" etc. And making them impossible to find unless you already know what they're called. [/sarcasm]

Aptitude is a tool for APT, not a complete linux configuration program and linuxconf isn't such a bad name, is it? And this problem is the same for all programs, isn't it? Why don't people call a chess program "chess program" or a browser "browser"? It doesn't work in an environment which offers choice.

Quote

Basically, no-one ever knows what they're doing with linux, they just have a vague idea and always type with two fingers crossed. Except for a few die-hards who've been using the same versions without upgrading for the last 10 years, and finally know the ins and outs of all their apps. But don't think I'm bitter - I have plenty of windows licenses (XP, NT, 2k) spare and could run any version of windows instead; I choose to run linux for a variety of reasons (none to do with politics; some to do with windows bugs; many to do with linux-only apps )

My experience is, that you have a learning curve for Debian. If you use it for some time and are a bit interested, you know how the system works. For Windows it doesn't really matter, if you use it 2 months or 5 years. You don't have a chance to find out how it works.

- I've spent 40+ hours trawling google on these problems for the last week; I also know (as it appears you do not) that google does NOT index vast swathes of mailing lists, and that where it does it often indexes them wrongly and sparsely. If you had more experience of system admin you would probably be painfully aware of this. That you even mentioned google leads into the next point... - i suspect you consistently understimate the amount of time and number of things I've tried by a factor of 10 - 20. If I'm not specific enough for you it's because the specifics would take literally hours just to type out; I have been administering systems for well over 10 years, I know most of the tricks in the book, and I can churn through all the options very quickly. A blow-by-blow account would take an incredibly long time to write down. - There is, as yet, no filesystem standard. FHS is not yet usable, and even so the current distros don't implement the draft (e.g. Redhat 10 does not implement FHS, which makes quite a mockery of it) - Apt is just as stupid a name as aptitude. Neither have anything to do with the file people download (always ends in ".deb"). All normal people use aptitude because its stupid not to. Whatever the hell you use, this is the app that is the ONLY WAY to install, uninstall, upgrade, downgrade, and fix your OS: what else is that if not a core system-setup tool? Linux is too crap to HAVE a single setup (e.g. windows control panel, although that itself is less of a single setup than it used to be), so you could re-use your argument that "[aptitude] is not a complete linux config" forever, no matter what tool we talk about. That's never going to undermine my original point, so save your breath. - "linuxconf" is no better a name than "lscu" (Linux System Configuration Utility): it's a name that is easy to associate when you know what it means, but is entirely unrelated to what people would think of unprompted. If you don't like this claim, you should read some HCI research, and some psychology, and learn about the importance of names, and how typical human minds perform labelling and discovery. I can assure you that 9 out of 10 people would not find linuxconf without prompting. - as it stands, there is only one real standard for setup and config tools, since only one OS vendor has been intelligent enough to create them: "setup". Many applications have also contributed loosely by adding the words "install" and "config" to the common vocabulary. Any setup program not called one of those is probably wrongly named. - ..but what really matters with configuration is that it MUST be presented to the user BEFORE the user goes looking for it. Here's a clue: In windows, there is a button called "Start". Every user finds that. On that menu, there are very few options (leaving aside XP, which has made some big leaps backwards), and from the very first time the user uses the computer, they find the control panel. Even better, win2k properly setup has an item "Administrative tools". Wow! Linux has "login:". Well, that's *really* helpful, isn't it? Also, have you ever typed the global standard "help" at a linux prompt? Or tried "f1" (the alternate version of this standard)?

Quote

For Windows it doesn't really matter, if you use it 2 months or 5 years. You don't have a chance to find out how it works.

This is classic trollbait: you say that the undocumented unstandardized system is the one people can learn and understand, and that the obvious, user-friendly, (but buggy) one is the one they "don't have a chance" with.

If I responded to the troll, no doubt you'd say "you can read the source for everything in linux!", which is obviously not true: how many users can read the source? The physical ability to do something is not equivalent with the practical option of doing it. This is why we have documentation in the first place!

I mentioned earlier that deb's are IME not available for many important applications, and Jens didn't believe me.

Well, here's an amusing one: you can't get Java 1.4 (Sun) for debian (according to the FAQ, and also 1.3 and 1.4 don't show up on the official debian mirrors I'm using for stable and testing). Reasons given in the Debian-Java-FAQ range from:

Quote

if you implement any part of the new 1.2 API or Jini API, even from scratch, Sun will "own" your implementation and you will have to pay them for the right to use it.

(note: you can only get sun's java 1.1.8 in debian, not even 1.2)

to

Quote

I don't think we can or want to distribute the JRE with Debian. The supplemental license terms of the JRE has a few very nasty clauses:

1. License to Distribute. You are granted a royalty-free right to reproduce and distribute the Software provided that you: (i)distribute the Software complete and unmodified, only as part of, and for the sole purpose of running, your Java applet or application ("Program") into which the Software is incorporated;

(it goes on to discuss various possible (mis?)interpretations of the legalese, and vaguely concludes that they can't / mustn't distribute a Sun JRE if they also distribute Kaffe or similar)

I'm not commenting on the (in)correctness of those opinions (I've not been following the legal ramifications of Sun's JRE licenses carefully, although as noted before on this forum I *have* been involved in re-distributing the JRE, and my memory of the situations is that the Debian FAQ is now wrong and needs updating - but I'll leave such issues to the experts!).

However, it could be a pain for anyone using debian systems who downloads a debian package that has an explicit dependency on java-vm (I've seen this once or twice with RPM's; it's still very rare, but does occasionally happen. It makes perfect sense to do this (exactly as much sense as a windows-exe that is just a java app without a jre) I think it's just that because RPM is NOT a cross-platform standard and Java comes with it's own x-plat install procedures this is not really taking off). Obviously, you'd need to create ghost debian packages to keep the debian packaging system happy (IIRC it's quite easy to create so-called "dummy packages").

I believe you can get the RPM, and "convert" it using the program "alien", however I'm probably just going to get the non-RPM linux JDK 1.4 and install it manually.

Now, that you have read the FAQ, you know why the current Sun Java is not part of the official Debian distribution.

Quote

I mentioned earlier that deb's are IME not available for many important applications, and Jens didn't believe me.

You said "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)?" and " 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."

Java isn't open source, so it doesn't count, but even, if you count it, it's available (just use the above line to install it). It's obvious, that your statements are wrong (because 1. more than ten thousand packages is more than nothing and 2. there are surely more than 10% of RPM apps available as DEBs) . This isn't a big problem. You didn't know Debian and the thousands of packages available before. Saying something wrong is human. I just find it strange, that you insist on your opinion, even though I told you it's not correct and you can convince yourself now. This isn't a subjective topic.

I think your behaviour _today_ is not really friendly. I tried to help and I answered one of your questions in detail by mail. You didn't reply and now you rant against me and Linux/Debian in the forum. Are you in a bad mood? I'm not resentful, so let's pass the peace pipe and stop this discussion or come back to a normal level.

The main subject of this thread seems to be installers. And since we're talking about installers, and you mentioned xBSD, i thought id drop in a line.

FreeBSD is one of the most stable, best documented, most supported OS out there. Its installtion system is second to none. It is immaculate. You can have packages or let freebsd compile it for you. The programmer who puts his own "ports" must provide at least the source. That way, when you want to install a package, freebsd creates a package from the source, changes it into a pkg, and then it gets installed. The only true comptitor in the linux range against freebsd is Gentoo. Because it has virtually copied how freebsd has worked for about 30 years. I suggest you give freebsd a try and then see which you like.

PS. FreeBSD isn't for the softhearted. The installtion of the actual OS is a real no brainer. But getting real performance out of freebsd is another issue. You will need to tweek certain things here and there. Maybe even enable the software RAID built in with freebsd.

Situation: - linux just committed suicide....So, looking at unixes available now: - 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...)

Debian won the battle of the unixes for me - it's still running on my laptop many weeks later.

Yes, it *is* painful that e.g. I'm running eclipse 2.1 instead of 3.0 (the Debian person responsible for eclipse saud they'd have 3 avaiable several weeks ago, but we're still waiting..), and it's scary that I have to have a custom proprietary version of Mozilla, and an even more proprietary version of OpenOffice (that actually comes with it's own Debian logo) that appears to have extra bugs that were NOT in the original. This is deeply scary stuff, but at the moment I'm working around the bugs and too scared to poke in case it all falls to pieces.

But...it is true that the package-management is better than the best bits of all the other linuxes put together (so long as you completely ignore "apt" and "apt-get" and all that crap - just use aptitude and, when you *cannot* use it, e.g. because you got the install files in an email, use dpkg instead).

In a further warning to would-be debian users I must point out that DEB files are just as dangerous as RPM files - at least one major piece of software I use the authors supplied their own DEB files and they were badly broken. Fortunately, I already knew them, and they had some spare time at the right moment, and we got it fixed within days. But it isn't as if DEB comes with anything like the java security policies - it has no more protection against badly packaged files than RPM does, and the majority of software is still a long way from being included in the core distribution (i.e. packaged by experts (Debian volunteers)).

The debian volunteers also sometimes screw up their own packages and don't document their deliberate breaking of other people's packages (e.g. they broke bugzilla and didn't tell anyone about it). I say this mainly to make it clear that Debian is *not* perfect and to make sure anyone adopting it realises that they will need to continue being suspicious of everything they install - if it don't work, remember to check the possibility that the author or packager broke it, not you - *despite* the many claims by Debian advocates that their intensive checking and slow pace of updates provides very high levels of reliability and security. Yes, it produces a better result; no, it's not so very much better as many of them claim.

Debian also appears to have some screwed up standard packages, not just the slightly esoteric ones. For instance, I'm running a bog-standard linux FTP server that I've used for years - only it's now running less than half the throughput (i.e. very slow downloads/uploads) and more than 5 times as slow (latency) as it did on the exact same hardware when running a different linux prior to re-install.

So. Be cautious. But in the most important test it comes up trumps: each time one of our machines @ Grex comes up for re-install (e.g. major kernel upgrade, new hardware, new image etc) it's getting Debian, so it's convinced us.

Some of your problems will be solved when Debian 3.1 will be released (some time this year). Currently the software in Debian is either old (if you use stable) or potentially buggy and without security support (if you use testing) or bleeding edge (if you use unstable). With the next release you'll get a moderately new stable system with security support and hopefully the next release cycle will be shorter than two years.

Regarding the security of DEB-packages I can just say that they are as secure or unsecure as the underlying system. What exactly should be more secure?

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