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).
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.
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 :()
[quote]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]
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! ;D
[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).
[/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. 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.
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.
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.
[quote]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.
[/quote]
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:
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.
[/quote]
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?
[/quote]
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 :))
[/quote]
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.
BTW SID repository is huge more than 12 CD ISO I think, lot of software are packaged for debian
and if you really want to install a RPM, you can use alien for convert a .rpm to a .deb
It’s strange I don’t think you really want to switch off
[quote]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!
[/quote]
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.
[/quote]
The installations isn’t nice, but there is a lot of documentation. Debian doesn’t change the stable distribution (including installer) except security issues.
Endolf
[/quote]
Sorry, half asleep by the time I wrote that; I really meant that it’s missing from the routing table, despite being specified as the IP for lo in ifcfg-lo.
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
192.168.0.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
0.0.0.0 192.168.0.1 0.0.0.0 UG 0 0 0 eth0
:(. 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 :(.
I’m grateful that you’re offering to help, but I don’t have the time to spend on a careful examinaton - which is precisely why I wanted opinions from people who’d been through hell on linux and had also used debian a lot.
It’s like I’m asking for a review, and you’re offering to help me configure a system so I can check for myself - it’s very generous of your, but if I had time for that, I wouldn’t be asking for a review!
It took 6 hours just to install the basic set of packages for the RH server I just setup (mostly time spent choosing and checking version incompatibilities, checking for regression bugs we can’t live with, etc). You seem to think I could go through a package list in 5 minutes; generally it takes me considerably longer than that simply to read all the names and recall to mind what I know of each one.
PS Given how badly RH-10 is going I’m now trying a debian install in parallel on the server; if RH-10 isn’t going to work without hacking the packages or config, then there’s no point in it - that will still prevent us from recompiling the kernel. The theory was that RH-10 at least had to be better than 8 and 9, but this doesn’t appear to be the case; so, I had believed that RH-10 would be less likely than debian to waste days by catastrophically not working with something (given the unknown quality of how many of our critical apps are available as debs)
If there are any problems with the server in the next few weeks we’ll probably have to reformat and install something else (I wish we could put windows on it the rate things are going here, but amongst other things I need it as a peer in the build-farm, which means it must run unix). But I need at least the server working today :(.
The server has less in the way of exotic hardware than my workstation, but more in the way of exotic apps (lots of different tools from all over the place). AFAICS the workstation will probably still need to be RH-10 (assuming it installs OK on that machine!)
Yes, sorry. It’s a habit; I think it may even be a survival trait of being a systems architect: I get people coming to me all the time with “lets add this in”, or “we need to change this so that it works like that instead” etc - and I have to be the person insisting that changes are only made for the best of reasons (e.g. any fundamental architectural changes during dev need to be avoiding some fatal flaw or similar sev-1 problem, since they have a huge knock-on cost as the update gets propagated throughout the source code).
It has the positive benefit that once I’ve been convinced of something it’s almost guaranteed to be correct (because I’ve done so much cross-checking by that point, and explored all the possible errors) - and that the person doing the persuading normally ends up knowing more about what they were proposing than when they started. I appreciate it can be a frustrating process that no-one can be bothered with :), but when very busy you tend to slip into old habits, don’t you?
tried the net-installer suggested by the official docs. Was extremely encouraged (sarcasm) to see that there are only “unofficial” versions of this and that some of them are broken links (from the hopmepage of debian.org!). Inspired me with confidence
net-installer crashes lots of times when installing packages; seems author was too lazy to implement a “retry package X yes/no?” (just a guess, but it looks like it was caused by network timeouts, or a busy mirror server).
instller gives me great hope: when it crashes on a package, it shows you a list of install stages and lets you go back as many or as few as you want! (what RH obviously needed 5 years ago but they were incapable of doing for some reason)
even more exciting, when you select the “install pacakges” again, it doesn’t download any pacakges it had already installed!
However, at this point you start to wonder if the coder knew much about programming: they clearly have used an O(N) algorithm for checking packages, a process which surely is O(1); yuou sit there watching it get slower, and slwoer, and slower for no obvious reason.
Eventually packages install OK, and I Choose a Kernel (2.6)
And now it crashes trying to install PCMCIA (Oh for gods sake - it’s PAINFULLY obvious I don’t have PCMCIA cards - this is a tower server!).
At which point debian becomes a bit of a waste of time. The PCMCIA crash goes back to the “where shal I retry from” again, but now it has:
wiped ALL settings for the disk paritioning
corrupted / partially transformed the installed packages, so that if you try and restart from there, it crashes every time
gives you no effective option but to start by repartitioning; this means a 99% from-scratch restart. because of some stupid failure trying to install something that is obvivously useless
So. With another 2 hours wasted (thanks, Debian!) I’m giving it another go - perhaps a 2.4 kernel will not be so frickin stupid as to crash like that? Who knows? At any rate, it’s not impressive: just like RH, it has an installer with lots of gimmicks but equally many show-stopper bugs so that you wish whichever fool did the gimmicks had spent their time making the core parts actually work instead :(.
You could blame me for following the advice on the website; obviously I shouldn’t have been so trusting and stupid as to expect something I was encouraged to do would actually work . If it doesn’t work, howabout NOT putting it on front of your website, hmm? (rhetorical question :)).
Anyway, up-to-date Debian (i.e. not the stable release) is looking pretty poor so far.
[quote]Here are some pointers. I especially advise you to learn how the APT system works (because you are used to RPM).
[/quote]
More confidence-inspiring stuff; apparently, according to the APT people, every invention in UI and HCI of the last 20 years was a mistake, and we should only be using CLI’s. Not even text-based menus are to be spared:
??? Obviously, this isn’t necessarily written by the APT autors/maintainers - but it IS the official HOWTO, which of course is (being linux) effectively the main manual. If the developers disagree, presumably they would have made it clear by now.
So, the CLI version of apt, with almost as many options as RPM, but with ordinary users expected to understand and use a much greater percentage of them, is apparently without any kind of sensible UI? Great. Presumably anyone who can’t memorize all the options doesn’t deserve to use such great software?
EDIT: seems there ARE good UI tools for this, they just aren’t mentioned in the howto. The installer eventually found it’s way into “aptitude” which seems very good so far.
[quote] - And now it crashes trying to install PCMCIA (Oh for gods sake - it’s PAINFULLY obvious I don’t have PCMCIA cards - this is a tower server!).
At which point debian becomes a bit of a waste of time. The PCMCIA crash goes back to the “where shal I retry from” again, but now it has:
wiped ALL settings for the disk paritioning
corrupted / partially transformed the installed packages, so that if you try and restart from there, it crashes every time
gives you no effective option but to start by repartitioning; this means a 99% from-scratch restart. because of some stupid failure trying to install something that is obvivously useless
[/quote]
But, curiously, this time I don’t get asked for a kernel, and it installs without problems. It’s now doing the packages (took 1 hour to select a basic set of packages :() so I should soon now whether it’s worked.
Can you point me to the installer you used? If you can choose a 2.6.-kernel it’s probably the beta-installer of the next release or something else, but not the official installer. (There is no 2.6. kernel in stable.)
I recommend to download the first CD (ISO image) for the base installation. You can download the rest of the packages over the internet.
