Re: Debian flamewar (was: Can I bother you with another Linux question?)
On Monday 21 November 2005 12:57, Ben Scott wrote: The Debian creed is Debian is God's Chosen Distribution. Debian is Perfect. All Glory to Debian! That's correct. Just bow and make the triangle thing pointing to your head and chest before you leave. :-) After all, Debian is *perfect*. Despite that being a very common belief, it really isn't true. After all, the vrms program isn't run automatically after a Debian install and at each user login. Until that happens, Debian really cannot be considered perfect. :-) Regards, . Randy -- Fast fact: It takes 23 gallons of water to produce a pound of tomatoes, it takes 5,214 gallons of water to produce a pound of beef. ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
Re: Debian flamewar (was: Can I bother you with another Linux question?)
After all, Debian is *perfect*. Despite that being a very common belief, it really isn't true. The question is, will it be the DCC or Ubuntu that perfects it? After all, the vrms program isn't run automatically after a Debian install and at each user login. Until that happens, Debian really cannot be considered perfect. :-) That's a bit much. Only need to run it after each dpkg or apt-get install. But instead, 'apt-get install vrms' adds vrms to cron ... -- /\ Bill Ricker N1VUX [EMAIL PROTECTED] \ / http://world.std.com/~wdr/ X Member of the ASCII Ribbon Campaign Against HTML Mail / \ ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
Re: Debian flamewar (was: Can I bother you with another Linux question?)
On 11/21/05, Ken D'Ambrosio [EMAIL PROTECTED] wrote: Wow. Deep breath, all. You misunderstand. This is *entertainment*. Especially when someone hands you a straight line like the OP did! :-) Debian -- stock Debian -- sucks to install. It's funny how Debian people almost always admit this, sometimes even preemptively. I get it ever time I rant about Debian. And yet I don't think I've ever specifically ranted about the installer. Not in years, in any event. I found the Debian Sarge installer to be a huge improvement over previous iterations. The basics (at a minimum) of hardware detection and automatic module support are all there. A few of the questions seemed silly (as they would answer themselves in a few screens), or poorly designed from a user standpoint, but all in all, it was quite serviceable. Sure, it wasn't the point-and-drool iconfest that Red Hat provides, but it worked. That's always my biggest criteria: Does the damn thing work? I fail to see this as a reason to love Debian, and, yet, I do. I admire many aspects of the Debian project. The Debian Social Contract and Debian Free Software Guidelines concisely and clearly state the ideals behind FOSS better then just about everything I've seen. A distribution built by and owned by the user community. Software by the people and for the people. As goals go, it just doesn't get much better then that. I love the the idea that each package is traceable to the packager, and that they are held at least somewhat personally responsible for their work. No faceless corporation or even project to hide behind. If Joe screws up, it's Joe's fault. (In theory, anyway.) In these days of lawsuits and disclaimers, that kind of personal accountability is as rare as unicorn blood. And, from a pragmatic point of view, the huge package repository is a wonderful thing. Debian-the-distribution, I like and admire. It's Debian-the-religion that I have a problem with. It leads to things Not Working, and for Stupid Reasons. (See criteria #1, above.) If a bug report is greeted with flames about how you're an idiot for choosing to install the provided package, something is broken, and it's not the software. I could get into details, but I think the rant-within-a-rant of my last post covers the gist well enough, and doing more would likely not be entertaining. Don't want that. ALL THAT BEING SAID, however, superficial sniping is just plain silly. But entertaining! :) -- Ben I like to play with fire! Scott ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
Re: Debian flamewar (was: OpenOffice doc...)
[I have re-arranged the order of subthreads for editorial purposes.] On Wed, 16 Feb 2005, at 9:01pm, [EMAIL PROTECTED] wrote: If I have 3 packages, A, B, and C ... Similarly, most packages don't rely on more packages. Irrelevant. The issue isn't that I expect most packages to depend on or conflict with each other; the issue is that a given package *could* do so. The only way to know is to test, and that's where all those potential interactions come in. ... this is a null argument here anyway. On the contrary, this is an aspect of my major objection to Debian. Let me reiterate that this objection is more of a mindset problem then a technical problem. I'll get to what it is further on. And by the time stable is outdated, testing is good enough ... You keep going back to quality, real or perceived. Repeat after me: Quality is not the issue here. Configuration Management is the issue. Indeed, in most environments where CM matters (which is most real production environments), it's much preferred to have a buggy system you're familiar with, then a potentially better system with unknown behaviors. As for deploying hundreds of machines, I have no idea how that's connected to choice of distro ...^^ Exactly my point. :-) Well, I'm lost then. What was your point? You stated that you have no idea how deployment issues are connected to the choice of distro. A major thrust of my point, all along, has been that Debian people have no idea about how deployment issues are connected to their distro. :-) I don't really see anyone doing anything better than APT, even on a Configuration management is completely hopeless if one's configuration varies depending on when you happened to pull your package set from testing/unstable/sarge/sid/pixar/whatever. Why does it depend on that? Configuration is very reliable in all releases of Debian I've found over the years. That's not Configuration Management. CM is not the act of configuring a system. CM means knowing what the configuration of each system is, how it got that way, who did it, when, and *why*. Not just the current state, but all the past states, and the transitions between them. Until you grok this, you will *never* understand where I'm coming from. You might try this for starters: http://www.google.com/search?q=%22configuration%20management%22 Right, but now I just can't type apt-get install foo and magically have everything work. I do this all the time for this or that package on my KnoppMyth install and haven't run into a problem yet. Well, I haven't used any of that stuff, so here I will have to bow to your experience. But know what I know about how computers work, I suspect you're seeing a carefully filtered subset of the overall potential problems that occurs when you mix binary packages against differing build and install environments, most likely due to careful CM on the part of the package maintainers. Either that, or you're just ignoring the problems, which I find a lot of Debian zealots do. It appears a lot of Debian zealots don't consider random breakages that can be fixed by doing some quick apt-get magic a problem. I don't know if you fall into this category (and if you don't, good for you), but I find far too many Debian people do. This is another aspect of my major problem with Debian. It really doesn't take too long for decent packages to hit Sarge now (or for the last year really). Exactly my point. testing and unstable are moving targets. Testing doesn't change significantly that fast. You just contradicted yourself. Either new packages appear quickly, or the distribution does not change much. Which is it? I'll admit the old installer wasn't pretty ... I never found the Debian installer itself all that bad. Sure, it ain't the point-and-click automagic experience that the latest Anaconda or YaST is, but it was clear (if highly technical) and gave me what I needed to go forward most of the time. I imagine it would be pretty scary for a newbie, but I'm not a newbie. When you get to the bootup, there's a choice of kernels and you choose the bf24 one for a 2.4 kernel rather than a 2.2 kernel. Okay, I just tried this on a Debian 3.0r2 CD I had lying around, on my main home PC, and it was still and once again unable to see all of my hard drive. cfdisk coughed and died with an error about a partition extending past the end of the disk. I guess this must be one of those rarely needed in business environments things you keep mentioning. ;-) If you're installing to play, you may want to consider Sarge CDs. H, last time I looked, the Debian web page gave the official stance that one should not expect ISO images of the unstable stuff, for obvious reasons. Of course, last time I looked at that corner of the Debian site was *years* ago. Since I see I can now download an ISO of a weekly build, I will do that
Re: Debian flamewar
On Wed, 16 Feb 2005, at 7:35am, [EMAIL PROTECTED] wrote: Yum works like a charm when everything is up to date in the repositories. It's next to useless otherwise. FWIW, one of the points I've been trying to make in all of this ranting is that no package manager -- apt-get, yum, rpm, dpkg, urpmi, xyzzy, or whatever -- can solve that problem. -- Ben Scott [EMAIL PROTECTED] | The opinions expressed in this message are those of the author and do | | not represent the views or policy of any other person or organization. | | All information is provided without warranty of any kind. | ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
Re: Debian flamewar (plus general ranting)
On Wed, 16 Feb 2005, at 7:55am, [EMAIL PROTECTED] wrote: And the fact that BSD ports downloads, configures, builds, and installs all the specified components *from source* leads BSD bigots into thinking that the BSD ports packagers must be doing a much better job then Red Hat or Debian packagers. Yeah, the source junkies never seem to take into account managing hundreds or even thousands of boxes. './configure;make;make install' gets old *real* fast in those situations. At least BSD ports automates that much. Really, though, I was referring to the fact that BSD ports (or Gentoo portage) is not magically better at handling dependencies; rather, by building everything locally, it bypasses the problem. Since the build environment *is* the target environment, everything becomes much easier. And, ideally, I suspect that is the way to go. Alas, closed source software still plays far too big a role in my world for me to take that route. And as soon as you introduce one pre-compiled binary into a source only system, everything goes straight to hell in a zip file. And, again, it's also largely responsible for why Windoze sucks so much. ... it's a minor kind of miracle the thing ever works at all. Does it work at all? ;-) Alas, yes, it does. If it was flat-out, dead-in-the-water broken I'd have a much easier time pitching Linux. :-/ -- Ben Scott [EMAIL PROTECTED] | The opinions expressed in this message are those of the author and do | | not represent the views or policy of any other person or organization. | | All information is provided without warranty of any kind. | ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
Re: Debian flamewar (was: OpenOffice doc...)
On Wednesday 16 February 2005 11:59 pm, Derek Martin wrote: Debian uses the same kernels as everyone else. In point of fact, no it doesn't. For example, Red Hat kernels contain many performance enhancements, bug fixes, and functionality So use those kernels? It's still the same code. Pick your kernel from kernel.org or from various patchsets or what have you. The kernel really doesn't have to do with the distro. You keep talking about need... It isn't always about need. If I'm running Sarge, and the guy next to me has FC3, but his system can do neat things that mine can't, I'm gonna want what he has... You keep telling me about mission critical systems in your business. You insist that stable is necessary for that, but turn the argument around when it comes to the shiny bleeding edge desktop and say that Sarge isn't close enough. Pick one point of view and stick with it. If you want the the pretty, shiny, modern desktop, then use Sarge and you'll have as much stability and reliability as well as up to date. This late in the game, Sarge is practically just an alternate stable branch. If you can't have that instability or testing, then you're probably building a server that you can use stable on without complaint. Pick the right release for whatever you're using. Don't keep coming back to me and saying Stable is too old for a desktop and Testing is too unstable for a server. I'm well aware of that, but you're using that argument as a means of describing how neither is useful at all. If Debian Testing is unsuitable as business desktop OS, then I'd say nothing in the Linux world is particularly ready yet. just close. Well, I'd say I don't agree; see above. I never said it was impossible to use Sarge as a desktop distro; there are simply better choices. And I keep missing the reason why? I run Sarge on all my desktops and have never had a problem with it or been missing some pretty software or something. You mention a video resolution problem, but that seems like an odd issue. That is autodetected by X when it starts for the most part, assuming you selected the appropriate resolution and type (LCD/CRT) of monitor in debconf, when installing. I'm sorry, but your point is just wrong. I can't do that, because it would be lying. It ISN'T stable. THERE IS NO NEW DEVELOPMENT IN A STABLE RELEASE. When everyone's systems break because we apt-get upgrade to broken changes in testing, I'd get fired. You can't try to tell me that it wouldn't happen; I've SEEN it happen. New development happens in unstable/sid. I've said it way too many times now that, this close to a stable release, testing is just as solid on a desktop. To call it stable as an adjective is not lying. Calling it by the stable/testing/unstable release names is just semantics. If you recount experience from way in the past about testing breaking things a year or more ago, there's a good reason. Stable was new enough that you didn't need to use Testing for modern software. Take that assumption and you realize that everything you said above is meaningless. That assumption is patently false. You're not very good at math are you. That assumption is supposed to be made to guide the discussion in the right direction. Either we work with that assumption or we work on discussing that assumption. Not both at the same time which makes my responses to you as randomly guided as the back and forth arguments you're making. If you disagree, that's alright. Since you disagree with that, there's no point in further discussing here. You obviously just have a preference for other setups and a lack of patience for things that aren't what you're used to. There's no doubt it is different. I'm not alone in thinking Testing is a good desktop OS and I'm not wrong either just because you disagree. I am more familiar with Debian systems though, so certainly it makes sense that I stick to what I know and you stick to what you know. I have tried it, and it was in fact Sarge which caused the problem I was refering to above , when it was testing. I installed it last year when I was in Korea, also. I found it lacking features that I was accustomed to, so I got rid of it. Features like what? Sounds like what I said above - it was different and you didn't like that, but missing features? Incidently, around the time I had my troubles with testing, one of my coworkers actually tried selling the idea of using Sarge/testing on all our systems... If we had done that at that time, the whole environment would have become useless that day, and I'd have been out of a job. Fortunately, a different coworker pointed out that at that specific point in time, Debian unstable was actually more stable (i.e. reliable) than testing was. We decided to stay with Red Hat. ;-) That's a great story, really. It sounds more like FUD than anything. If testing was more unstable than
Re: Debian flamewar (was: OpenOffice doc...)
On Wednesday 16 February 2005 11:18 pm, Derek Martin wrote: It isn't a null argument; you're missing the point. It isn't that the package depends on all the other packages, clearly that's not the case. The point isn't even that it does or does not interfere with some other package. The point is that it *MAY* interfere with other packages unexpectedly, and you have to test them all in order to be OK, I'm missing the point then... that's a common theme with your responses. I'm not going to try quantifying my stance on issues with made-up math that makes for a highly unrealistic model of package development. If it were realistic, none of the major releases would ever accomplish anything. My experience has been different. I once installed testing on my workstation at work, and nothing worked. Granted this situation isn't normal, but it illustrates the point. That hypothetical example I gave about glibc wasn't hypothetical at all... Though it may not have been glibc specifically, I don't remember. Something made my system unusable. I didn't have time to mess with it, so I promptely re-installed RH... Updating the primary library that every package is based on is a big change. That was going on way before Testing was ready for real usage. At that point in the Debian release cycle, you shouldn't have been using testing. My points so far have been about Testing now. Testing, now, is reliable. It was sort of usable then, but only with a lot of work. I was running stable then on my desktops and never felt behind then either. Newer software may not strictly speaking be necessary, but it's often desireable, because it's just plain better. Faster. Less buggy. Have nice features that make life easier. What have you. That's fine... pick the appropriate release for your needs. Sarge is fine for desktops now (not when glibc was being changed, but now). If performance is a factor, newer software usually performs better, because the developers have had the chance to do more optimizing (however notable exceptions abound). Newer software often has done a lot more than just plugged up old security holes; often it has re-designed the entire security model to make it inherently better. Sometimes, newer software just has happy bells and whistles that make managing it a lot easier than in old versions... That's a very non-quantifiable and non-justifiable point. To some degree I'm sure it's true, but on the same level as Gentoo being faster because it's compiled for your system. I've never felt held back by the performance of the older stuff on servers. That doesn't mean you won't; it only means you've been lucky thus far. I have done similar things and been bitten by them. Possibly, but that's unstable and I accept that. Unstable is where this can happen, no question about it. Just installing things with some intelligence is enough. Don't install something that needs to upgrade/remove/replace half your running system without a little bit of hesitation and planning. My shiny new (hypothetical) server hardware is only supported by the 2.6 kernel... What do I do? You're just being silly now. Why would you have to use 2.6 on a server? What kernel does RHEL4 was only just released this week on 2.6. Does that mean that RHEL3 can't use 2.6 kernels? Historically, IIRC, just downloading an ISO was not easy to do. If it is now, that's a welcome change. But I still don't want to spend 4 hours downloading a bunch of software that's 3 years old... How was it hard? You follow the links, visit the mirrors, and download it. That's always how it's been. And since when is testing 3 years old? Stop putting down stable when it suits you to make fun of age and putting down testing the rest of the time. I can't even tell which you're referring to half the time. You don't seem to understand what we mean by configuration management. It refers to maintaining the software and configurations of the software of a group of machines in some known state. Ideally, the state should be the SAME state across all the machines, unless there is a specific technical reason why it isn't. APT does not and can not do this for you. APT does not and can not do this for you. At least, not all by itself. That's why configuration management doesn't depend on the package manager. So what then do you use for this? I can actually already see doing this with APT without issue. But maybe I'm missing something still. Disclaimer: Ben and I are both from the old school of system administration... Keep everything the same, do things once, and do them right (as much as management will let you). Change NOTHING unless not doing so will result in catastrophe (ok, I'm exaggerating here:-). Do as little work as possible to keep things running well. Not because you're lazy, but because it shouldn't be necessary and your time is better spent working on something
Re: Debian flamewar (was: OpenOffice doc...)
On Wednesday 16 February 2005 09:30 pm, Christopher Schmidt wrote: 1. Partitions. Although it offered to guess partitions for me, it presented me with a menu with all the sizes and various options. As much as *I* understand, I wouldn't expect anyone else to understand it. It should be skipped, or put behind an Advanced Setup button so people don't mess it up. I noticed that too. I think since it's shown as a confirmation page, it's probably not a big deal, but people new to Linux still won't want to see it. I think that once Sarge is released, the expectation is that people will skin the installer and make prettier, maybe even GUI interfaces. I know the new installer was designed for that. Since that's the type of interface a non-technical user would likely use anyway, I hope that won't be an issue. 2. Resolution - The monitor came up with a default 800x600 resolution. I had to edit the xfree config file manually to get it to work. (The monitor is a 15 LCD, which goes up to 1024x768.) I know as a user, I'd be pissed off at that. I'm curious how you did monitor selection? Did you maybe select 24bit color and not have the video memory to support that bit depth and resolution? Or did you let it do everything automatically. I haven't had an issue yet, but I'd like to know what to look out for. -N ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
Re: Debian flamewar (was: OpenOffice doc...)
On Thu, Feb 17, 2005 at 07:24:02AM -0500, Neil Joseph Schelly wrote: On Wednesday 16 February 2005 09:30 pm, Christopher Schmidt wrote: 1. Partitions. Although it offered to guess partitions for me, it presented me with a menu with all the sizes and various options. As much as *I* understand, I wouldn't expect anyone else to understand it. It should be skipped, or put behind an Advanced Setup button so people don't mess it up. I noticed that too. I think since it's shown as a confirmation page, it's probably not a big deal, but people new to Linux still won't want to see it. I think that once Sarge is released, the expectation is that people will skin the installer and make prettier, maybe even GUI interfaces. I know the new installer was designed for that. Since that's the type of interface a non-technical user would likely use anyway, I hope that won't be an issue. Yeah, I didn't make that clear: it is just a confirmation screen. It still feels like it's missing out on the whole Don't let the user mess anything up that they shouldn't need to anyway. I personallly think that this screen is just asking for the user to mess it up :) 2. Resolution - The monitor came up with a default 800x600 resolution. I had to edit the xfree config file manually to get it to work. (The monitor is a 15 LCD, which goes up to 1024x768.) I know as a user, I'd be pissed off at that. I'm curious how you did monitor selection? Did you maybe select 24bit color and not have the video memory to support that bit depth and resolution? Or did you let it do everything automatically. I haven't had an issue yet, but I'd like to know what to look out for. I honestly have no clue. I didn't remember doing anything at all regarding the video card or the monitor, which was why I was surprised when it worked at all :) I don't remember makinga guess at video memory, or at color depth, so I'm not sure how it decided what to do: all of the setups seemed like they were definitely very basic, like I would expect from a default X install, rather than something which was configured. All in all though, much less painless process than installing Gentoo was... ;) -- Christopher Schmidt pgpT4BUWCdudo.pgp Description: PGP signature
Re: Debian flamewar (was: OpenOffice doc...)
On Thu, Feb 17, 2005 at 07:13:32AM -0500, Neil Joseph Schelly wrote: My shiny new (hypothetical) server hardware is only supported by the 2.6 kernel... What do I do? You're just being silly now. No, I'm not. If my server has a new mass storage controller that isn't recognized by the 2.4 kernel, but is recognized by the 2.6 controller, then debian stable won't install on it, but other more curent distros will. I'm not saying that such hardware exists right now, today, but it could, or it could tomorrow, and this kind of situation has existed in the past. Debian potato was impossible to install for a time on some hardware that wasn't recognized by the 2.2 kernel. The same will be true of sarge at some point, if it isn't already. Historically, IIRC, just downloading an ISO was not easy to do. If it is now, that's a welcome change. But I still don't want to spend 4 hours downloading a bunch of software that's 3 years old... How was it hard? You follow the links, visit the mirrors, and download it. I believe that's wrong. In the Bad Old Days, Debian didn't provide ISO images. You had to download all the files from the repositories, download some scripts, and make them yourself. Perhaps a long-time debian user here can confirm that this is correct? I'm talking maybe 1999 or 2000, but my memory's really unclear on this. APT does not and can not do this for you. At least, not all by itself. That's why configuration management doesn't depend on the package manager. So what then do you use for this? I can actually already see doing this with APT without issue. But maybe I'm missing something still. If you use APT by itself, you can't guarantee that all the systems will have the same versions, because APT doesn't schedule jobs. You need to use cron to schedule updates. Then, you need to have a local repository that you must build and maintain from which you can update, because if you use Internet mirrors for your updates, then you run the risk that some servers will get updated and others not due to circumstances outside your control. You probably can't update all your 1000 systems at one time, because it will overload your Internet connection. Then, since you're doing automatic updates, you need a process to update onto a test machine, run some automated tests to make sure that your next update won't blow up your environment in your face. And of course, you need a human to set all this up and make sure it doesn't break... APT alone can't do all that. No package management system can... That's why I use Debian. And Ben seems to make much more grounded arguments for his stance, for the record. I have trouble following yours and you continually keep jumping back and forth in your points. Bens's arguments and my arguments are the same. But how would you know? You already said you didn't understand what points Ben was trying to make... Essentially, there are three points here: Stability: Both Woody/stable and Sarge/testing have stability at this point. Testing doesn't always have stability, I'll admit, but right now, Sarge does. This point is useless, unless you're only going to administer your systems righ now. It doesn't work that way in real life. And how can you guarantee me that the next updates to sarge won't break it? Regardless of what you say about testing being stable, my experience prevents me from trusting it in production. Reliability: Both Woody/stable and Sarge/testing have reliability. They aren't going to be seeing any significant changes, software versions, revisions from here on out. Upgrades are safe with Sarge and very safe with Woody. And I've already said a dozen times or so that I consider Woody too old to use for most purposes, when you consider that all of the other major distros' stable releases have much newer, better performing, security enhanced, more featureful software. Will Woody: install on my new hardware which requires a 2.6 kernel? support NFSv4? support mapping UIDs on NFS? support selinux out of the box? configure my X display properly on well-supported hardware? support running a PDC and BDC using samba (requires Samba 3.0)? support my neat web app that needs Apache 2.0? The answer to all of these is no, or in the case of X maybe. Yes, you can upgrade and upgrade and upgrade until it does, but that totally defeats the point of using a distro, IMO. Cutting edge stuff: Woody is outdated and I've already accepted that. For servers, this generally isn't an issue, It's only not an issue if you're willing to settle for sotware that isn't as powerful as you could be using. And sometimes, even then, it can be an issue. The bottom line is Debian's cycle is just too damn slow to be useful in production. That doesn't make it bad, it just makes other distros better choices IMO. -- Derek D. Martinhttp://www.pizzashack.org/ GPG Key ID: 0xDFBEAD02 -=-=-=-=- This
Re: Debian flamewar
Historically, IIRC, just downloading an ISO was not easy to do. If it is now, that's a welcome change. But I still don't want to spend 4 hours downloading a bunch of software that's 3 years old... How was it hard? You follow the links, visit the mirrors, and download it. I believe that's wrong. In the Bad Old Days, Debian didn't provide ISO images. You had to download all the files from the repositories, download some scripts, and make them yourself. Perhaps a long-time debian user here can confirm that this is correct? I'm talking maybe 1999 or 2000, but my memory's really unclear on this. This is true, then they had some weird ISO maker thing that you had to use rather then just downloading the entire disc set. Some places had them (linuxiso.org for one) but you couldn't get just raw ISO's from debian.org. The few times that I've tried and used Debian I would just get the minimal install ISO and install the rest with dpkg or apt. Essentially, there are three points here: Stability: Both Woody/stable and Sarge/testing have stability at this point. Testing doesn't always have stability, I'll admit, but right now, Sarge does. This point is useless, unless you're only going to administer your systems righ now. It doesn't work that way in real life. And how can you guarantee me that the next updates to sarge won't break it? Regardless of what you say about testing being stable, my experience prevents me from trusting it in production. Exactly, that's why you have a separate testing and stable, because one is for TESTING, and the other is STABLE :) That's the whole point. Cutting edge stuff: Woody is outdated and I've already accepted that. For servers, this generally isn't an issue, It's only not an issue if you're willing to settle for sotware that isn't as powerful as you could be using. And sometimes, even then, it can be an issue. The bottom line is Debian's cycle is just too damn slow to be useful in production. That doesn't make it bad, it just makes other distros better choices IMO. Bottom line is, if you want to use it in a production environment, you're going to want to use stable. If for anything else so the PHB won't bitch about using something labeled as testing. He doesn't want to take that risk, and neither do I. We are even slowly moving to RHEL where I work now for the stability and support because we've had issues with our RH9 and Fedora boxes. ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
Re: Debian flamewar (was: OpenOffice doc...)
How was it hard? You follow the links, visit the mirrors, and download it. I believe that's wrong. In the Bad Old Days, Debian didn't provide ISO images. Perhaps that's why they were called the bad *old* days? Perhaps a long-time debian user here can confirm that this is correct? It's not hard; if you look on www.debian.org, you'll see a link on the home page indented under Getting Debian called CD ISO images. It's easily visible -- one doesn't even have to scroll down the page. Click on that link and you'll find 3 download options: * Assemble images using jigdo * Download CD images with BitTorrent * Fetch full CD images I'm talking maybe 1999 or 2000, but my memory's really unclear on this. It doesn't seem logical to base a 2005 opinion of a GNU/Linux distro on how that distro was five or six years ago. Most all distros have improved greatly from that time. Regards, . Randy -- Myth: Private companies can do a better job running Social Security than the government. Fact: Wall Street firms would be the main winners from privatization, charging high fees for managing our investments and paying out the money once we retire. Due to swings in the stock market, workers would face the risk of ending up with far less money than they had expected. A private system would also reduce or eliminate death and disability insurance for workers' families. -- Wall Street's Fondest Dream: The Insanity of Privatizing Social Security, Dollars Sense magazine Nov/Dec 1998. ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
Re: Debian flamewar (was: OpenOffice doc...)
On Thu, Feb 17, 2005 at 10:59:42AM -0500, Derek Martin [EMAIL PROTECTED] wrote: No, I'm not. If my server has a new mass storage controller that isn't recognized by the 2.4 kernel, but is recognized by the 2.6 controller, then debian stable won't install on it, but other more curent distros will. I'm not saying that such hardware exists right now, today, but it could, or it could tomorrow, and this kind of situation has existed in the past. AFAIK, SATA was only recently added to the mainstream 2.4 kernel (2.4.27, IIRC). I'm not sure if Debian used a back-ported patch prior to that event or if it didn't support SATA. Also AFAIK, ACHI SATA support is in 2.6 but not 2.4 ATM. There may be some SATA controller chipsets support in 2.6 but not 2.4. Just a data point. -- Bob ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
Re: Debian flamewar (was: OpenOffice doc...)
On Feb 17, 2005, at 10:59, Derek Martin wrote: If my server has a new mass storage controller that isn't recognized by the 2.4 kernel, but is recognized by the 2.6 controller, then debian stable won't install on it, but other more curent distros will. I'm not saying that such hardware exists right now, today, but it could, or it could tomorrow, and this kind of situation has existed in the past. It does exist, in a matter of speaking. I've been putting in Apple XServe RAID arrays on linux machines and they have 2 fiber channel ports going to two fiber channel arrays (in a single chassis). I stripe them together using LVM and LVM support for a 3.5TB array (or any other big array) only exists (or is only easy/feasible) in a 2.6 kernel. I slap FC2 on and don't look back. -Bill - Bill McGonigle, Owner Work: 603.448.4440 BFC Computing, LLC Home: 603.448.1668 [EMAIL PROTECTED] Mobile: 603.252.2606 http://www.bfccomputing.com/Pager: 603.442.1833 AIM: wpmcgonigleSkype: bill_mcgonigle ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
Re: Debian flamewar (was: OpenOffice doc...)
On Thu, Feb 17, 2005 at 06:30:10AM -0500, Neil Joseph Schelly wrote: So use those kernels? It's still the same code. Pick your kernel from kernel.org or from various patchsets or what have you. The kernel really doesn't have to do with the distro. What part of the installer doesn't have the kernel I need to install this bloody distro on my hardware are you not comprehending? You keep telling me about mission critical systems in your business. You insist that stable is necessary for that, but turn the argument around when it comes to the shiny bleeding edge desktop and say that Sarge isn't close enough. You're suggesting that bleeding edge can't be stable... I think this is where you're going wrong. A new release of Red Hat Linux was generally pretty stable. There were always a few gotchas after it was first released, but no more than with Debian stable. Oh yes, as stable as stable is, it still has bugs, and requires updates. FC3 is probably a bad example, because Fedora Core is more bleeding edge and less reliable than stable releases of Red Hat Linux used to be, but that's intentional. So let's say Suse Pro instead. It's more current than Woody, and I believe more so than Sarge also, but it's still considered stable and by all acounts very reliable. At Mission Critical Linux, we used the latest stable releases of Red Hat for all new installs. Only the kernel guys ran Debian, they all ran unstable, and it was fine for them. But fixing problems they found was their job... so it worked for them. For everyone else, we had a lot of banging going on at our door whenever there was a slight glitch. Risking bugs in testing or unstable was not an option. Pick one point of view and stick with it. Once again, you're completely missing the point. Only Debian takes 3 years to put out a stable release. Other distros HAVE stability while also being more up-to-date. And because of that (and support reasons too), they are better choices than Debian for production environments. I am not saying Debian is bad software, it isn't. Nor am I saying you are a bad person for choosing it. There simply are better distributions for production environments. Your sysadmin team seems to agree with me, you've already said they use RH in production... Pick the right release for whatever you're using. Don't keep coming back to me and saying Stable is too old for a desktop and Testing is too unstable for a server. I'm not saying that at all. I'm saying Stable is too old for nearly ANYTHING, in a production environment, and Testing is too unstable for nearly ANYTHING, in a prooduction environment. The reason is simple: other distros have just as much stability while at the same time being newer and more featureful than their Debian counterparts. As a side issue, they also usually come with vendor support, though Red Hat seems to have dropped the ball on that account. If I were evaluating distros for production environments TODAY, I'd probably give Suse a good hard look before I even considered Debian. It's been a long time since I've seen what they have to offer. And if I didn't go with Suse for some reason, I'd almost certainly pick RHES or its counterparts over Debian. I'm well aware of that, but you're using that argument as a means of describing how neither is useful at all. No, they're plenty useful. But for the vast majority of production environments, other choices make more sense from both a usability perspective and a configuration management perspective. Most distros have a lot of their own bells and whistles to make a variety of things a lot easier. In my experience, Debian lacks in this department also, requiring a lot of things to be done manually and in some cases even painstakingly. New development happens in unstable/sid. I've said it way too many times now that, this close to a stable release, testing is just as solid on a desktop. Even if that's true (which I dispute), so what? The problem is that you are dependent upon being at a specific stage of a development cycle for that to be the case, and SANE businesses can't and won't depend on that. It's clear that you still don't grasp the ideas and importance of configuration management. I must not be required to change the software on my machine simply because the developers are entering a different phase of development... Reconfiguring systems must be done on MY terms, and my terms only. In other words, changes need to be able to be planned solely on busines need, not because of what the vendor is doing. You simply don't have that with Debian. To call it stable as an adjective is not lying. Calling it by the stable/testing/unstable release names is just semantics. That's preposterous. It's called testing because it's being tested. When problems are found, changes are made. I also occasionally write free software, and I had software which was in Debian testing, which was pulled from testing
Re: Debian flamewar (plus a GNU/Linux rant) (plus PHP4/PHP5 experiences)
On Tue, 2005-02-15 at 23:28 -0500, Kevin D. Clark wrote: Benjamin Scott [EMAIL PROTECTED] writes: ... You haven't lived until you realize that the poor slobs three cubes away from you have 6 copies of the same DLL, which they categorize by file size. When they want to run application A, they copy the X-byte DLL to the system directory. When they want to run application B, they copy the Y-byte DLL to the system directory. You hear people yelling things like NO...DON'T RUN THE APPLICATION WITH THE 9689-byte DLL -- IT CORRUPTS THE DATABASE!. Things like this cause me to weep. It would be a definite ROFL if it weren't so serious. In the past I've been involved with BIG Windows systems/applications developments, and you get nowhere unless you pay a big support fee to Microsoft and develop first-name relationships with various key engineers. I doubt if the situation has changed much today. Haven't bothered looking at their .net offerings since I became a die-hard Java and Linux type by then. While we are on the upgrade subject, I will soon be upgrading my dedicated server from RH9 to FC3. Upgrades of this magnitude *always* involved gotchas, but I've done this upgrade once before so I kinda know what to expect. I am forced to do this upgrade, BTW, because I *need* PHP5 running on that server, and keep running into dependency issues under RH9 that yum cannot resolve -- mainly because the RH9 repositories are no longer kept up to date. PHP5 has it own peculiar dependencies depending on what features you enable when you build it. And I spent time resolving one such dependency on RH9 and ran into yet another after that. That was a hint and a half for me to bite the bullet and just upgrade the entire distro. Yum works like a charm when everything is up to date in the repositories. It's next to useless otherwise. I've not used Debian before, and now after having followed this flamewar, methinks I'll stick to Fedora. RPMs and Yum are not perfect by a longshot, but I know how to work around those headaches. apt-get would introduce a new set of headaches, and I'm running low on the asprin. :-) --kevin BTW, if anyone's interested, getting my PHP4 code to run under PHP5 was mostly painless -- just a few minor changes I had to make. Alas, my code can't be pure PHP5, but parts of it must still run under PHP4 systems. Since PHP5 code generates syntax errors under PHP4, I've had to devise means to keep PHP5-code from even *loading* under PHP4. Turns out that my equivalent of an autoloader that I created for the PHP4 code lended itself nicely to the solution. The biggest difference which I had to deal with is how objects are passed, assigned and copied on PHP5. Since I've been paying strict attention to this under PHP4, that made it all that much easier to fix. The clone keyword under PHP5 breaks under PHP4, so I took the rather clever approach of using clone(...) which winds up calling a dummy function under PHP4 and works as the clone keyword under PHP5. That is pretty much the only really nasty kludge I had to implement. I really *like* PHP5 because now I can do the same style exception handling I had gotten used to with Java and C++. I also like the stack trace dump I automatically get by echoing the exception object. And there are a few other niceties that gives me the it's about bloody time reaction. -- -- Fred Don't let IE happen to YOU! - My daughter, who designs web sites for everything BUT Internet Explorer. ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
Re: Debian flamewar (plus a GNU/Linux rant)
On Tue, 2005-02-15 at 22:20 -0500, Benjamin Scott wrote: [snip] Hope that clears that up. :-) You may not agree with my estimates of what most problems with rpm have to do with ... If anything, I strongly *agree* with your views on this subject. Hmm, okay, that does clear it up. Sorry, I guess I misread what you wrote. [snip] And the fact that BSD ports downloads, configures, builds, and installs all the specified components *from source* leads BSD bigots into thinking that the BSD ports packagers must be doing a much better job then Red Hat or Debian packagers. Yeah, the source junkies never seem to take into account managing hundreds or even thousands of boxes. './configure;make;make install' gets old *real* fast in those situations. And, again, it's also largely responsible for why Windoze sucks so much. [snip] -- then, yah, it's a minor kind of miracle the thing ever works at all. Does it work at all? ;-) -- -Paul Iadonisi Senior System Administrator Red Hat Certified Engineer / Local Linux Lobbyist Ever see a penguin fly? -- Try Linux. GPL all the way: Sell services, don't lease secrets ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
Re: Debian flamewar (was: OpenOffice doc...)
On Tue, Feb 15, 2005 at 11:24:28PM -0500, Benjamin Scott [EMAIL PROTECTED] wrote: On Tue, 15 Feb 2005, at 6:26am, [EMAIL PROTECTED] wrote: If I have 3 packages, A, B, and C, I need to test A with B, A with C, and B with C -- 3 interactions. If I have 4 packages -- A, B, C, and D -- I need to test A with each of B, C, and D, and B with each of C and D, and C with D: 6 interactions. FWIW, for the behavior you are describing, the number of interactions is N*(N-1)/2. In other words, exactly half of the N^2-N behavior you original thought it was, and still O(N^2), which I think is your point. Yes, IAAM (I Am A Mathematician) -- or at least I have an undergrad degree saying that I used to understand this stuff better than I do now. :-) [ Also note that I'm not justifying your analysis, just provided the math describing your analysis ] -- Bob ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
Re: Debian flamewar (was: OpenOffice doc...)
On Tue, Feb 15, 2005 at 11:24:28PM -0500, Benjamin Scott [EMAIL PROTECTED] wrote: Me too. Hell, it's ruining my mind. I've lately found myself trying to tab-complete file names I haven't created yet! Damn shell doesn't have that DWIM module installed yet... It can come close. Run `shopt -s cdspell` in bash and it will correct some spelling mistakes when using the `cd` command. :-) -- Bob ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
Re: Debian flamewar (was: OpenOffice doc...)
On Tuesday 15 February 2005 11:24 pm, Benjamin Scott wrote: If I have 3 packages, A, B, and C, I need to test A with B, A with C, and B with C -- 3 interactions. If I have 4 packages -- A, B, C, and D -- I need to test A with each of B, C, and D, and B with each of C and D, and C with D: 6 interactions. Here's a table: Similarly, most packages don't rely on more packages. So another maintainer responsible for another package means he or she will do what is necessary to keep track of its dependencies and that will be the same number of dependencies as most apps, namely just one or two. Your example assumes that all packages interfere or interact with all others and that's unnecssary complexity. Anyway, I'm not a math guy and this is a null argument here anyway. It really doesn't take too long for decent packages to hit Sarge now (or for the last year really). Exactly my point. testing and unstable are moving targets. It's in flux. To test something, it needs to be *unchanging*. Once it's tested, you can't change it again, or you have to test again. Since packages build on one another, you have a real hard time getting a release out. That's why woody is two-and-a-half years old at this point. While Red Hat's offerings are definitely of a lower quality then Debian, is woody *three years worth of testing* better? Hell no. You're way past the point of diminishing returns. Testing doesn't change significantly that fast. And by the time stable is outdated, testing is good enough that it can be safely used instead. For servers, you can still stick to stable unless there's something you need in testing, but so close to the next stable release (as Debian is now), I would feel fine with Testing running in production. And when Testing is unreliable, that means a new Stable has just been released that will be modern enough for at least a year for all intents and purposes... especially in a business environment where the latest/greatest toys aren't necessary. Right, but now I just can't type apt-get install foo and magically have everything work. And one will quite quickly get into the dependency hell that people are all too quick to blame on RPM. I do this all the time for this or that package on my KnoppMyth install and haven't run into a problem yet. And it pulls from lots of different locations. Sure, I have to reboot every couple of weeks or so, but that's more or less because MythTV is only at version 0.16 (or I think 0.17 was just released). It's not because of conflicts and I haven't had any trouble with conflicts when I've installed new things with APT. And I get this kernel how...? :) Cool. Wanna tell me how I use it? I've got Debian 3.0r2 images on my hard disk. (I see 3.0r4 is out now, but they keep telling me not much has changed...) I've attempted installs of this Debian before, but my HD is When you get to the bootup, there's a choice of kernels and you choose the bf24 one for a 2.4 kernel rather than a 2.2 kernel. I'll admit the old installer wasn't pretty for reasons like this, but the new one kicks ass. If you're installing to play, you may want to consider Sarge CDs. For Woody though, if you wait long enough for the installation to start it will, but if you look at the boot options, you'll see that just typing bf24 will start with a newer kernel. The Debian zealots I know have been telling me the installer is going to get much better Real Soon Now for over five years. You'll pardon me if I don't hold my breath. :) It is. It's not coming soon - it's here. Download a Sarge ISO and see for yourself. If you're looking for a GUI, then you'll still be disappointed, but I don't care about eye candy for something I see so rarely. It's quick and very straightforward and very simple now though. The advanced functionality of the old one still seems to be there, but you just don't need it anymore. Sure. How do I install it? In the past, I've been told the way to install it is to install stable and then apt-get dist-upgrade (I think that was the command). See above. :) You could... I'd just download a Sarge ISO. I don't really see anyone doing anything better than APT, even on a large scale here. Read my keystokes: It's not the frelling package manager. :-) Configuration management is completely hopeless if one's configuration varies depending on when you happened to pull your package set from testing/unstable/sarge/sid/pixar/whatever. Why does it depend on that? Configuration is very reliable in all releases of Debian I've found over the years. It doesn't change and often makes a lot more sense than other distros I've used. Although that is likely as much a what you're used to thing than anything else. As for deploying hundreds of machines, I have no idea how that's connected to choice of distro ...^^ Exactly my point. :-) Well, I'm
Re: Debian flamewar (was: OpenOffice doc...)
On Tuesday 15 February 2005 09:51 pm, Derek Martin wrote: I don't buy that. It takes a LOT longer for it to hit stable, but by that time it's ludicrously rock solid. Um, huh? It strikes me that you said, I don't buy that, and then proceeded to agree with everything Ben said... I said it takes a lot longer to hit stable, but the rest of my post discussed how waiting for things to hit stable isn't necessary. It's convenient how snipping out the point of my paragraph lets you poke holes in my stance. And so what if it's ludicrously rock-solid, if it doesn't recognize my hardware? Not so useful, regardless of how stable it may be... Debian uses the same kernels as everyone else. It's trivial to make your own if you're finding that the stock kernel doesn't support whatever setup you have. I can't agree with that, and just the fact that you said it suggests to me that you're not a system administrator. Ignoring for the moment the lack of vendor support options from Debian (being not a company), most businesses have little tolerance for unstable software. The non-stable branches of Debian update far too often to be useful as a standard desktop platform for support reasons at most companies who have their heads on straight. Notable exceptions for companies whose business is directly Linux-related... I am a network administrator, for what that's worth. I find statements like that just silly in a discussion such as that. It's like calling names or something equally childish. As for lack of vendor support, if that's important, I think HP recently started supporting Debian, didn't they? Where I work, the servers run RHEL. They pay for up2date and nothing else. Vendor support is essentially worthless as in this case Debian also updates packages for security problems free of charge. Some businesses just have issues trusting free - they have all the tolerance in the world for unstable software, as evidenced by the number of times I have to restart systems or services in our Windows server systems and the annoyance of having Outlook 2003 start scrambling my folder structure in need of a reboot. And business desktops by the way, since you brought it up, rarely have need for things past stable. If Debian Testing is unsuitable as business desktop OS, then I'd say nothing in the Linux world is particularly ready yet. just close. Not true. KnoppMyth does a great job of running my TV. And they manage their own repository (in addition to the Debian testing/unstable ones and a few others). If I really want, I can install anything from there, but then again, I don't need that on my TV. If I needed the full repositories, then a spin-off wasn't the right choice I'd say. You appear to be contradicting yourself... You appear to be grasping for straws. Spin-offs are great for single-purpose or specialized machines. If you want a general purpose machine, then you stick to the big repositories. Pick what suits you - it's a simple concept. Stable/Testing/Unstable are just names. If you don't like them called that, then call them Woody/Sarge/Sid. You're missing the point, which is something like, If it ain't stable, it ain't usable. This doesn't mean that YOU can't use it, it means that the management of an organization can't risk using it, because if there's a problem, it could mean a serious loss of work/time/money/etc. In practice, so-called stable releases of certain software may be no better, but you're never going to convince a non-technical manager type that it's a good idea to use something which is not considered production- quality by the people who are developing it... And you're missing the point. Don't ask your manager to approve the use of testing/unstable because it's just a name. Call it Debian Sarge and call it a solid release that is under modern development and always up to date, within a reasonable few weeks timeframe to work out any bugs in new development. Pick the appropriate release for the job - it's silly to consider anything else when you're making a decision like this. These are tired arguments... Testing is quite stable and reliable and up-to-date. Take that assumption and you realize that everything you said above is meaningless. If we disagree on that point, fine... then we can disagree on anything you said above and discussing it back and forth won't change anything. If you haven't tried running Sarge though, then you're really not qualified for further telling me I don't know what I'm talking about. And if you're not willing to try, then just leave it be at that - that you're not interested in either learning what I mean or confirming what you say. -N ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
Re: Debian flamewar (was: OpenOffice doc...)
On Tue, Feb 15, 2005 at 11:24:28PM -0500, Benjamin Scott wrote: On that note, I've been through the new installer a few times and while I never minded the old one much, the new one is really slick. The Debian zealots I know have been telling me the installer is going to get much better Real Soon Now for over five years. You'll pardon me if I don't hold my breath. :) For the record, I installed Debian for the first time about a month ago. (My girlfriend's Mandrake box was toast, probably because the package management stuff on 9.0 does not make it easy or understandable how the hell I'm supposed to upgrade things, so... I didn't. A default Mandrake box that I don't know how to update or configure ... and apparently someone got in and started sending spam through it. I felt bad, but blamed Mandrake anyway.) The install process was easy, no guessing, no nothing, except for two points: 1. Partitions. Although it offered to guess partitions for me, it presented me with a menu with all the sizes and various options. As much as *I* understand, I wouldn't expect anyone else to understand it. It should be skipped, or put behind an Advanced Setup button so people don't mess it up. 2. Resolution - The monitor came up with a default 800x600 resolution. I had to edit the xfree config file manually to get it to work. (The monitor is a 15 LCD, which goes up to 1024x768.) I know as a user, I'd be pissed off at that. Other than that, it was extremely painless: just insert CD, follow prompts, reboot. -- Christopher Schmidt pgpsdKuYkStav.pgp Description: PGP signature
Re: Debian flamewar (was: OpenOffice doc...)
On Wed, Feb 16, 2005 at 09:01:13PM -0500, Neil Joseph Schelly wrote: Similarly, most packages don't rely on more packages. So another maintainer responsible for another package means he or she will do what is necessary to keep track of its dependencies and that will be the same number of dependencies as most apps, namely just one or two. Your example assumes that all packages interfere or interact with all others and that's unnecssary complexity. Anyway, I'm not a math guy and this is a null argument here anyway. It isn't a null argument; you're missing the point. It isn't that the package depends on all the other packages, clearly that's not the case. The point isn't even that it does or does not interfere with some other package. The point is that it *MAY* interfere with other packages unexpectedly, and you have to test them all in order to be certain that it doesn't. This slows the testing process down, and is a big part of the reason it takes 3 years to release a stable release. Exactly my point. testing and unstable are moving targets. It's in flux. To test something, it needs to be *unchanging*. [SNIP] Testing doesn't change significantly that fast. And by the time stable is outdated, testing is good enough that it can be safely used instead. My experience has been different. I once installed testing on my workstation at work, and nothing worked. Granted this situation isn't normal, but it illustrates the point. That hypothetical example I gave about glibc wasn't hypothetical at all... Though it may not have been glibc specifically, I don't remember. Something made my system unusable. I didn't have time to mess with it, so I promptely re-installed RH... feel fine with Testing running in production. You shouldn't; and if you keep doing it, and run regular updates, I'd bet big money that eventually you'll get bitten by it. And when Testing is unreliable, that means a new Stable has just been released that will be modern enough for at least a year for all intents and purposes... especially in a business environment where the latest/greatest toys aren't necessary. Newer software may not strictly speaking be necessary, but it's often desireable, because it's just plain better. Faster. Less buggy. Have nice features that make life easier. What have you. If performance is a factor, newer software usually performs better, because the developers have had the chance to do more optimizing (however notable exceptions abound). Newer software often has done a lot more than just plugged up old security holes; often it has re-designed the entire security model to make it inherently better. Sometimes, newer software just has happy bells and whistles that make managing it a lot easier than in old versions... Right, but now I just can't type apt-get install foo and magically have everything work. And one will quite quickly get into the dependency hell that people are all too quick to blame on RPM. I do this all the time for this or that package on my KnoppMyth install and haven't run into a problem yet. That doesn't mean you won't; it only means you've been lucky thus far. I have done similar things and been bitten by them. Cool. Wanna tell me how I use it? I've got Debian 3.0r2 images on my hard disk. (I see 3.0r4 is out now, but they keep telling me not much has changed...) I've attempted installs of this Debian before, but my HD is When you get to the bootup, there's a choice of kernels and you choose the bf24 one for a 2.4 kernel rather than a 2.2 kernel. My shiny new (hypothetical) server hardware is only supported by the 2.6 kernel... What do I do? The Debian zealots I know have been telling me the installer is going to get much better Real Soon Now for over five years. You'll pardon me if I don't hold my breath. :) It is. It's not coming soon - it's here. Download a Sarge ISO and see for yourself. I have... I admit it was much better than the potato installer, but that didn't take much. It still seemed to me like it was a bit behind the times... As for X being configured in a grossly sub-optimal state, that seems absurd. All the other major distros have been getting that pretty much right for a LONG time now. If nothing else, Debian could just steal code and have it working tomorrow... If you're looking for a GUI, then you'll still be disappointed, but I don't care about eye candy for something I see so rarely. If you're a sysadmin for a large site, you tend to see it quite often. I don't care about the eye candy that much anyway, but I still found it to be, um, let's say my least favorite installer of all the major distros. :) You could... I'd just download a Sarge ISO. Historically, IIRC, just downloading an ISO was not easy to do. If it is now, that's a welcome change. But I still don't want to spend 4 hours downloading a bunch of software that's 3 years old... I don't
Re: Debian flamewar (was: OpenOffice doc...)
On Wed, Feb 16, 2005 at 09:15:29PM -0500, Neil Joseph Schelly wrote: And so what if it's ludicrously rock-solid, if it doesn't recognize my hardware? Not so useful, regardless of how stable it may be... Debian uses the same kernels as everyone else. In point of fact, no it doesn't. For example, Red Hat kernels contain many performance enhancements, bug fixes, and functionality enhancements that other distros don't have. I don't know what Debian's kernel devel process is, but they either use Linus kernels, or more likely they apply their own set of enhancements. Either way, they're not using the same kernels as Red Hat. And business desktops by the way, since you brought it up, rarely have need for things past stable. You keep talking about need... It isn't always about need. If I'm running Sarge, and the guy next to me has FC3, but his system can do neat things that mine can't, I'm gonna want what he has... If Debian Testing is unsuitable as business desktop OS, then I'd say nothing in the Linux world is particularly ready yet. just close. Well, I'd say I don't agree; see above. I never said it was impossible to use Sarge as a desktop distro; there are simply better choices. You're missing the point, which is something like, If it ain't stable, it ain't usable. This doesn't mean that YOU can't use it, it means that the management of an organization can't risk using it, because if there's a problem, it could mean a serious loss of work/time/money/etc. In practice, so-called stable releases of certain software may be no better, but you're never going to convince a non-technical manager type that it's a good idea to use something which is not considered production- quality by the people who are developing it... And you're missing the point. Don't ask your manager to approve the use of testing/unstable because it's just a name. Call it Debian Sarge and call it a solid release that is under modern development and always up to date, within a reasonable few weeks timeframe to work out any bugs in new development. I'm sorry, but your point is just wrong. I can't do that, because it would be lying. It ISN'T stable. THERE IS NO NEW DEVELOPMENT IN A STABLE RELEASE. When everyone's systems break because we apt-get upgrade to broken changes in testing, I'd get fired. You can't try to tell me that it wouldn't happen; I've SEEN it happen. These are tired arguments... Testing is quite stable and reliable and up-to-date. It isn't stable ENOUGH. I refer you to my last post re: configuration management and my comments above. Take that assumption and you realize that everything you said above is meaningless. That assumption is patently false. If you haven't tried running Sarge though, then you're really not qualified for further telling me I don't know what I'm talking about. I have tried it, and it was in fact Sarge which caused the problem I was refering to above , when it was testing. I installed it last year when I was in Korea, also. I found it lacking features that I was accustomed to, so I got rid of it. Incidently, around the time I had my troubles with testing, one of my coworkers actually tried selling the idea of using Sarge/testing on all our systems... If we had done that at that time, the whole environment would have become useless that day, and I'd have been out of a job. Fortunately, a different coworker pointed out that at that specific point in time, Debian unstable was actually more stable (i.e. reliable) than testing was. We decided to stay with Red Hat. ;-) -- Derek D. Martinhttp://www.pizzashack.org/ GPG Key ID: 0xDFBEAD02 -=-=-=-=- This message is posted from an invalid address. Replying to it will result in undeliverable mail. Sorry for the inconvenience. Thank the spammers. pgptDpEw05tR4.pgp Description: PGP signature
Re: Debian flamewar (was: OpenOffice doc...)
On Tuesday 15 February 2005 12:42 am, Benjamin Scott wrote: Hah! You didn't expect a calm, reasoned approach to actually stop a good flamewar, did you? :-) My bad... The single-large repository part is what's important. It takes a little longer to unify configuration ... No, it takes a **LOT** longer. If the number of components in a Configuration Management scenario is N, then the number of potential interactions is (N^2)-N. Think about that for a minute. I don't buy that. It takes a LOT longer for it to hit stable, but by that time it's ludicrously rock solid. Usually, the cutting edge stuff can't really be that stable upstream, so you use testing anyway if you want the latest desktop or something. It really doesn't take too long for decent packages to hit Sarge now (or for the last year really). It would make a *lot* more sense to get some kind of base system configured, tested, and released first. Then the people working on the base system could move on to hacking on the next release, while the people responsible for things like X11 or whatever could get *their* stuff This assumes they are too slow, but I don't feel too limited by that release cycle anyway. There's an appropriate Debian release for every machine out there, 90% of the time. The exception I see is servers near the end of a Stable lifecycle (ie now). If you're making a server now, it would be preferable to have MySQL4, Apache2, Exim4, etc, but those aren't in Stable. I don't think Potato had this many new revolutions in primary server packages during it's reign as stable, so Woody is getting a little dated I think for some server installs. As soon as you switch to a spin-off, you lose the benefit of the huge Debian repository. Not true. KnoppMyth does a great job of running my TV. And they manage their own repository (in addition to the Debian testing/unstable ones and a few others). If I really want, I can install anything from there, but then again, I don't need that on my TV. If I needed the full repositories, then a spin-off wasn't the right choice I'd say. Once more, servers don't need the latest greatest KDE and Gnome ... No, but it would be nice if they could install. At this point in time, the current stable is so badly out-of-date that I can't even depend on it to see most of the mass storage devices I work with. That's sorta what I said above, but a different kernel, even for the install, is rather painless and can fix your storage problems. I've installed stable on a system with only a MegaRaid controller in it. The install kernel is 2.2 and typically doesn't support this, but there's an optional 2.4 kernel on the install for this kind of stuff. On that note, I've been through the new installer a few times and while I never minded the old one much, the new one is really slick. Sarge will be out soon and magically, those will be available. Yah, I get that a lot every time I try Debian. The next release will be out Real Soon Now. I believe that like I believe Red Hat claiming their QA process eliminates most of the major bugs prior to release. In this case, it will. They're down to something like 60 release-critical bugs. Within a few months, I think it'll be released. But if you want that functionality, it's effectively available now. It's not like you have to wait for it's release to use it. And as for non-servers, just use Testing. It's stable enough for any desktop. Further evidence that Debian zealots lack any concept of Configuration Management. :-) I don't really see anyone doing anything better than APT, even on a large scale here. In the world I work in, just use testing/unstable/etc. is not an acceptable answer. I like to say that CM is basically taking the aphorism Better the devil you know and turning it into a science. When you're deploying tens, hundreds, or even thousands of computers, you need to be able to keep track of what is where, and when. Stable/Testing/Unstable are just names. If you don't like them called that, then call them Woody/Sarge/Sid. If you feel safer that way, go for it. It's just semantics. As for deploying hundreds of machines, I have no idea how that's connected to choice of distro, so I'll leave it alone, though I'm curious about this as a potential future topic for discussion. And apt-source is an awesome source management tool. Hmmm, I don't think that existed the last time I looked. H, I can't seem to find info on it now, in an admittedly very cursory search. Got a link? tab-completion has ruined my memory. apt-src is the package. That should yield more interesting searches. -N ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
Re: Debian flamewar (plus a GNU/Linux rant)
[sorry if this is a double post. I posted with the wrong address] On Tue, 2005-02-15 at 00:54 -0500, Benjamin Scott wrote: On Thu, 10 Feb 2005, at 6:43pm, [EMAIL PROTECTED] wrote: Wait, I'm have a little trouble understanding the problem. I know you know this, but it's educational to state it explicitly: The problem is simply that binary compatibility is hard. Agreed, but it is most certainly not something that should be abandon given the potential benefits. [snip] There must be something about this that is either hard to comprehend, or hard to accept. It gives a lot of RPM users trouble, it gives Debian users a sense of superiority, Um, Ben ... I take exception to this. By saying that it is hard to comprehend or hard to accept your are implying that the problem is on my end. You may not agree with my estimates of what most problems with rpm have to do with (i.e.: not real problems with rpm *itself*, but rather with the way it is being used, or the way specific rpm packages are built), but I'm sure, if necessary, I could gather some real statistics that match my assertion that rpm is not the problem. I don't believe for a second that it has much to do with Debian users' sense of superiority. I've seen that sense of superiority displayed many times (though not much on this list) and it's nothing more than plain arrogance. And a refusal to look at what the real problems are, i.e.: not with rpm itself. it's what makes BSD ports work so well, and it's largely responsible for making Microsoft Windows the unholy mess that it is. Clearly, there's a disconnect here. -- -Paul Iadonisi Senior System Administrator Red Hat Certified Engineer / Local Linux Lobbyist Ever see a penguin fly? -- Try Linux. GPL all the way: Sell services, don't lease secrets ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
Re: Debian flamewar (was: OpenOffice doc...)
On Feb 15, 2005, at 00:42, Benjamin Scott wrote: No, it takes a **LOT** longer. If the number of components in a Configuration Management scenario is N, then the number of potential interactions is (N^2)-N. Think about that for a minute. You forgot to iterate over the number of functions exposed by each component (N). :( Probably somebody somewhere with enough resources could come up with a system to profile each package and build dependency graphs and built good validation scripts for each package and setup a cluster of test machines and scripts to automate testing of each of the Nf^2 possible configurations and create pass/fail lists and auto-feedback about breakage but it ain't ever gonna happen. IT is rapidly converging on figuring out why stuff breaks when upgrades happen. -Bill - Bill McGonigle, Owner Work: 603.448.4440 BFC Computing, LLC Home: 603.448.1668 [EMAIL PROTECTED] Mobile: 603.252.2606 http://www.bfccomputing.com/Pager: 603.442.1833 AIM: wpmcgonigleSkype: bill_mcgonigle ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
Re: Debian flamewar (was: OpenOffice doc...)
On Tue, Feb 15, 2005 at 06:26:46AM -0500, Neil Joseph Schelly wrote: No, it takes a **LOT** longer. If the number of components in a Configuration Management scenario is N, then the number of potential interactions is (N^2)-N. Think about that for a minute. I don't buy that. It takes a LOT longer for it to hit stable, but by that time it's ludicrously rock solid. Um, huh? It strikes me that you said, I don't buy that, and then proceeded to agree with everything Ben said... And so what if it's ludicrously rock-solid, if it doesn't recognize my hardware? Not so useful, regardless of how stable it may be... This assumes they are too slow, but I don't feel too limited by that release cycle anyway. There's an appropriate Debian release for every machine out there, 90% of the time. I can't agree with that, and just the fact that you said it suggests to me that you're not a system administrator. Ignoring for the moment the lack of vendor support options from Debian (being not a company), most businesses have little tolerance for unstable software. The non-stable branches of Debian update far too often to be useful as a standard desktop platform for support reasons at most companies who have their heads on straight. Notable exceptions for companies whose business is directly Linux-related... At any given moment, both testing and unstable may be completely broken by a recent change (such as a glibc update). To system administrators trying to manage 100 or 1000 desktop systems, that's just unacceptable. The stable branch isn't current enough to support the newest hardware, even on the day it's released. It too is unacceptable as a choice for deskopt OS, IMO. Debian isn't a good choice for corporate desktops in typical environments, IMO. As soon as you switch to a spin-off, you lose the benefit of the huge Debian repository. Not true. KnoppMyth does a great job of running my TV. And they manage their own repository (in addition to the Debian testing/unstable ones and a few others). If I really want, I can install anything from there, but then again, I don't need that on my TV. If I needed the full repositories, then a spin-off wasn't the right choice I'd say. You appear to be contradicting yourself... Once more, servers don't need the latest greatest KDE and Gnome ... No, but it would be nice if they could install. At this point in time, the current stable is so badly out-of-date that I can't even depend on it to see most of the mass storage devices I work with. That's sorta what I said above, but a different kernel, even for the install, is rather painless and can fix your storage problems. Maybe. Upgrading the kernel may require the upgrade of additional support software too, such as for example updated NFS tools, raid tools, and others. It may also require upgrading packages that aren't related to the reason for the change, such as firewall tools. At that point, you've got a maintenance nightmare, and you're much better off just choosing a more modern distro which has what you need. In the world I work in, just use testing/unstable/etc. is not an acceptable answer. I like to say that CM is basically taking the aphorism Better the devil you know and turning it into a science. When you're deploying tens, hundreds, or even thousands of computers, you need to be able to keep track of what is where, and when. Stable/Testing/Unstable are just names. If you don't like them called that, then call them Woody/Sarge/Sid. You're missing the point, which is something like, If it ain't stable, it ain't usable. This doesn't mean that YOU can't use it, it means that the management of an organization can't risk using it, because if there's a problem, it could mean a serious loss of work/time/money/etc. In practice, so-called stable releases of certain software may be no better, but you're never going to convince a non-technical manager type that it's a good idea to use something which is not considered production- quality by the people who are developing it... -- Derek D. Martinhttp://www.pizzashack.org/ GPG Key ID: 0xDFBEAD02 -=-=-=-=- This message is posted from an invalid address. Replying to it will result in undeliverable mail. Sorry for the inconvenience. Thank the spammers. pgp8QRuvnzrB1.pgp Description: PGP signature
Re: Debian flamewar (was: OpenOffice doc...)
On Tue, 15 Feb 2005, at 9:51pm, [EMAIL PROTECTED] wrote: In practice, so-called stable releases of certain software may be no better, but you're never going to convince a non-technical manager type that it's a good idea to use something which is not considered production-quality by the people who are developing it... Or even a technical type. For all of Red Hat Software's faults (and they are legion), they do at least understand the concept of configuration and release management. If you tell me a system is running Red Hat Enterprise Linux 3.0, then right away I know the versions, patches, build options, and everything else about the kernel, C library, C compiler, X11, KDE/GNOME, and a bunch of other things about the system. If you tell me a system is running Debian Sarge, about all that tells me is that it's probably running Linux. :) As an IT professional, I've pretty much reached the conclusion that everything sucks. My job is to figure *how* a given product sucks, and come up with standard ways to work around the suckage. Once I've done all that work, I will often stick with a product I *know* to be inferior, simply because I've already done that work. I know switching to the superior product will still end up with me muttering curses under my breath at some point. So I stick with the devil I know. That's what CM is all about. That's why saying just use testing/unstable won't work. Not because it's of quality, but because it's a moving target. Until Debian zealots get that through their amazingly thick skulls, Debian will make no inroads with me on a professional level. And I know I speak for many other professional geeks as well. Debian also makes no inroads with me on a hobby level, either, but I suspect that's just because it knows my opinion and so refuses to ever work properly. ;-) -- Ben Scott [EMAIL PROTECTED] | The opinions expressed in this message are those of the author and do | | not represent the views or policy of any other person or organization. | | All information is provided without warranty of any kind. | ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
Re: Debian flamewar (plus a GNU/Linux rant)
On Tue, 15 Feb 2005, at 12:01pm, [EMAIL PROTECTED] wrote: There must be something about this that is either hard to comprehend, or hard to accept. It gives a lot of RPM users trouble, it gives Debian users a sense of superiority, Um, Ben ... I take exception to this. By saying that it is hard to comprehend or hard to accept your are implying that the problem is on my end. That was not my intent. As I said, I know *you* know this. I was trying communicate an observation that it appears, *in general*, people have a problem with this concept. People, *in general*, keep trying to blame things on a package manager, or a dependency manager, or a binary package repository, or a lack of any of these, when the cause is really just that binary compatibility is simply a lot harder then many people *in general* appreciate. Hope that clears that up. :-) You may not agree with my estimates of what most problems with rpm have to do with ... If anything, I strongly *agree* with your views on this subject. I don't believe for a second that it has much to do with Debian users' sense of superiority. I was attempting to assert, about half-seriously, that the binary compatibility confusion issue was a contributor to Debian elitism. Specifically, that having such a large pool of configured, compiled, and tested packages readily available via apt-get install foo leads a lot of Debian people into think APT is somehow magic. Likewise, RPM properly saying I don't think you have the pieces you need for this to work leads so many people into thinking that RPM *causes* dependency hell. And the fact that BSD ports downloads, configures, builds, and installs all the specified components *from source* leads BSD bigots into thinking that the BSD ports packagers must be doing a much better job then Red Hat or Debian packagers. And, again, it's also largely responsible for why Windoze sucks so much. When everything a binary which you have no source for, and no two packages share information on what is being installed, and you can only install one version of any given library at once time -- then, yah, it's a minor kind of miracle the thing ever works at all. :-) -- Ben Scott [EMAIL PROTECTED] | The opinions expressed in this message are those of the author and do | | not represent the views or policy of any other person or organization. | | All information is provided without warranty of any kind. | ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
Re: Debian flamewar (was: OpenOffice doc...)
On Tue, 15 Feb 2005, at 6:26am, [EMAIL PROTECTED] wrote: The single-large repository part is what's important. It takes a little longer to unify configuration ... No, it takes a **LOT** longer. If the number of components in a Configuration Management scenario is N, then the number of potential interactions is (N^2)-N. Think about that for a minute. I don't buy that. Do I need to draw a picture? :-) (Actually, (N^2)-N is wrong. That assumes all components have precisely one interaction to worry about, and that all interactions are one-way. But I don't remember the right one, and I flunked combinatorics. :) ) If I have 3 packages, A, B, and C, I need to test A with B, A with C, and B with C -- 3 interactions. If I have 4 packages -- A, B, C, and D -- I need to test A with each of B, C, and D, and B with each of C and D, and C with D: 6 interactions. Here's a table: # Pkgs # Ints Ints 2 1 AB 3 3 AB AC BC 4 6 AB AC AD BC BD CD 5 10 AB AC AD AE BC BD BE CD CE DE 6 15 AB AC AD AE AF BC BD BE BF CD CE CF DE DF EF Notice how the progression for the number of interactions is distinctly non-linear. I may not be good at abstract mathematics, but I can tell the one value is getting bigger a lot faster the the other one is. It takes a LOT longer for it to hit stable, but by that time it's ludicrously rock solid. It's not a matter of quality, it's a matter of time-to-test. It really doesn't take too long for decent packages to hit Sarge now (or for the last year really). Exactly my point. testing and unstable are moving targets. It's in flux. To test something, it needs to be *unchanging*. Once it's tested, you can't change it again, or you have to test again. Since packages build on one another, you have a real hard time getting a release out. That's why woody is two-and-a-half years old at this point. While Red Hat's offerings are definitely of a lower quality then Debian, is woody *three years worth of testing* better? Hell no. You're way past the point of diminishing returns. This assumes they are too slow, but I don't feel too limited by that release cycle anyway. I'm happy you don't feel that way. Seriously. However, many *do* feel that way, for reasons I've explained elsewhere (see my comments WRT CM IRT Derek Martin). As soon as you switch to a spin-off, you lose the benefit of the huge Debian repository. Not true. KnoppMyth does a great job of running my TV. And they manage their own repository (in addition to the Debian testing/unstable ones and a few others). Right, but now I just can't type apt-get install foo and magically have everything work. And one will quite quickly get into the dependency hell that people are all too quick to blame on RPM. That's sorta what I said above, but a different kernel, even for the install, is rather painless and can fix your storage problems. And I get this kernel how...? :) The install kernel is 2.2 and typically doesn't support this, but there's an optional 2.4 kernel on the install for this kind of stuff. Cool. Wanna tell me how I use it? I've got Debian 3.0r2 images on my hard disk. (I see 3.0r4 is out now, but they keep telling me not much has changed...) I've attempted installs of this Debian before, but my HD is 160 GB and most of the stuff below the 24-bit barrier is already allocated. The woody kernel is so old it can't see above the 24-bit barrier. I've got a tiny space (a couple hundred MB) for the base system to install in. That I can do. But I can't fit a C compiler to build my own kernel. I tried downloading an updated 2.4 kernel, but I couldn't get the initrd to work. I even went to far as to build my own initrd image with a custom shell, and played around with it as much as I could. It all looks to be there, it just pukes once I leave the initrd and the kernel tries to pivot the roots. It eventually gets to: pivot_root: No such file or directory /sbin/init: cannot open dev/console: No such file or directory Kernel panic: Attempted to kill init! and then halts. Then I reboot back into FC3. :) On that note, I've been through the new installer a few times and while I never minded the old one much, the new one is really slick. The Debian zealots I know have been telling me the installer is going to get much better Real Soon Now for over five years. You'll pardon me if I don't hold my breath. :) Within a few months, I think it'll be released. But if you want that functionality, it's effectively available now. It's not like you have to wait for it's release to use it. Sure. How do I install it? In the past, I've been told the way to install it is to install stable and then apt-get dist-upgrade (I think that was the command). See above. :) And as for non-servers, just use Testing. It's stable enough for any desktop. Further evidence that Debian
Re: Debian flamewar (plus a GNU/Linux rant)
Benjamin Scott [EMAIL PROTECTED] writes: And, again, it's also largely responsible for why Windoze sucks so much. When everything a binary which you have no source for, and no two packages share information on what is being installed, and you can only install one version of any given library at once time -- then, yah, it's a minor kind of miracle the thing ever works at all. You haven't lived until you realize that the poor slobs three cubes away from you have 6 copies of the same DLL, which they categorize by file size. When they want to run application A, they copy the X-byte DLL to the system directory. When they want to run application B, they copy the Y-byte DLL to the system directory. You hear people yelling things like NO...DON'T RUN THE APPLICATION WITH THE 9689-byte DLL -- IT CORRUPTS THE DATABASE!. Things like this cause me to weep. --kevin -- GnuPG ID: B280F24E And the madness of the crowd alumni.unh.edu!kdc Is an epileptic fit -- Tom Waits ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
Re: Debian flamewar (was: OpenOffice doc...)
On Thu, 10 Feb 2005, at 6:38am, [EMAIL PROTECTED] wrote: It was a small comment that I didn't expect would incite such a banter, but let me throw a few words of explanation through here at least to try and settle the water. Hah! You didn't expect a calm, reasoned approach to actually stop a good flamewar, did you? :-) The single-large repository part is what's important. It takes a little longer to unify configuration ... No, it takes a **LOT** longer. If the number of components in a Configuration Management scenario is N, then the number of potential interactions is (N^2)-N. Think about that for a minute. Now, my original language is perhaps imprecise. It's not so much the single large repository, but the fact that the Debian project keeps trying to get the *entire thing* tested for release *simultaneously*. That's just not feasible. It would make a *lot* more sense to get some kind of base system configured, tested, and released first. Then the people working on the base system could move on to hacking on the next release, while the people responsible for things like X11 or whatever could get *their* stuff configured and tested based on the stable base. Followed by GNOME and/or KDE. And so on. Build up. You'd still have the large repository, but at least there'd be a hope in hell of keeping it moving. Right now Debian is trying to perform synchronized cathedral building. As for the manageable chunks, I think the Debian offshoots are best at that. As soon as you switch to a spin-off, you lose the benefit of the huge Debian repository. Once more, servers don't need the latest greatest KDE and Gnome ... No, but it would be nice if they could install. At this point in time, the current stable is so badly out-of-date that I can't even depend on it to see most of the mass storage devices I work with. Sarge will be out soon and magically, those will be available. Yah, I get that a lot every time I try Debian. The next release will be out Real Soon Now. I believe that like I believe Red Hat claiming their QA process eliminates most of the major bugs prior to release. And as for non-servers, just use Testing. It's stable enough for any desktop. Further evidence that Debian zealots lack any concept of Configuration Management. :-) In the world I work in, just use testing/unstable/etc. is not an acceptable answer. I like to say that CM is basically taking the aphorism Better the devil you know and turning it into a science. When you're deploying tens, hundreds, or even thousands of computers, you need to be able to keep track of what is where, and when. If don't have a consistent picture of what the configuration is (or was), support is an absolute horror. I think it's actually one of the levels of Dante's Inferno. And sure, there's nothing to keep me from performing my own CM on top of testing or unstable or whatever. But, of course, that really raises the question: Isn't that what a distribution is for? I don't use dpkg enough to compare to rpm for speed, but I generally find apt far faster than yum. I could believe that. It has been while, but from what I recall, while APT wasn't a speed demon, it did seem a lot faster then I find yum now. And apt-source is an awesome source management tool. Hmmm, I don't think that existed the last time I looked. H, I can't seem to find info on it now, in an admittedly very cursory search. Got a link? -- Ben Scott [EMAIL PROTECTED] | The opinions expressed in this message are those of the author and do | | not represent the views or policy of any other person or organization. | | All information is provided without warranty of any kind. | ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
Re: Debian flamewar
On Fri, 11 Feb 2005, at 9:26am, [EMAIL PROTECTED] wrote: By the way, everyone here is a nazi, therefore I hereby declare this debate/thread/discussion over! :) Quirk's Exception states that deliberately attempting to cause a Godwin Event will always fail. ;-) -- Ben Scott [EMAIL PROTECTED] | The opinions expressed in this message are those of the author and do | | not represent the views or policy of any other person or organization. | | All information is provided without warranty of any kind. | ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
Re: Debian flamewar (was: OpenOffice doc...)
On Fri, 11 Feb 2005, at 8:00am, [EMAIL PROTECTED] wrote: That's close to what I was talking about. The really neat part (IMHO) about apt-cache search is that it doesn't just do a glob search on package names, it does a glob search on the files *within* the packages. I think yum whatprovides foo will do something akin to that. -- Ben Scott [EMAIL PROTECTED] | The opinions expressed in this message are those of the author and do | | not represent the views or policy of any other person or organization. | | All information is provided without warranty of any kind. | ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
Re: Debian flamewar (was: OpenOffice doc...)
On Thu, 10 Feb 2005, at 6:38am, [EMAIL PROTECTED] wrote: But all the Debian zealots just say APT rocks and RPM sux!! and wonder why nobody cares. I don't recall saying RPM sux... On Thu, 10 Feb 2005, at 10:06am, [EMAIL PROTECTED] wrote: But all the Debian zealots just say APT rocks and RPM sux!! and wonder why nobody cares. Not true - I'm a zealot and I've never said it. 8) That's the other thing about Debian zealots. None of them understand hyperbole. ;-) -- Ben Scott [EMAIL PROTECTED] | The opinions expressed in this message are those of the author and do | | not represent the views or policy of any other person or organization. | | All information is provided without warranty of any kind. | ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
Re: Debian flamewar (was: OpenOffice doc...)
On Wed, 9 Feb 2005, at 11:29pm, [EMAIL PROTECTED] wrote: I couldn't agree more. [giant snip] Okay, Derek Martin posted a message where he did nothing but agree with me. Isn't that one of the signs of the apocalypse? ;-) -- Ben Scott [EMAIL PROTECTED] | The opinions expressed in this message are those of the author and do | | not represent the views or policy of any other person or organization. | | All information is provided without warranty of any kind. | ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
Re: Debian flamewar (plus a GNU/Linux rant)
On Thu, 10 Feb 2005, at 6:43pm, [EMAIL PROTECTED] wrote: Wait, I'm have a little trouble understanding the problem. I know you know this, but it's educational to state it explicitly: The problem is simply that binary compatibility is hard. Easy enough; it's the implications that are subtle. Like that building a key system library with different options makes it a different package. That changing a key system library thus changes the entire configuration management scenario. That a package that has different subcomponents, each with their own dependencies, is a package that depends on all of them. That auto-built dependencies tend to be even pickier then the real ones. That packages are only as good as their (builder supplied) metadata. And so on and so forth. There must be something about this that is either hard to comprehend, or hard to accept. It gives a lot of RPM users trouble, it gives Debian users a sense of superiority, it's what makes BSD ports work so well, and it's largely responsible for making Microsoft Windows the unholy mess that it is. Clearly, there's a disconnect here. -- Ben Scott [EMAIL PROTECTED] | The opinions expressed in this message are those of the author and do | | not represent the views or policy of any other person or organization. | | All information is provided without warranty of any kind. | ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
Re: Debian flamewar (was: OpenOffice doc...)
On Thu, 2005-02-10 at 19:11 -0500, Paul Iadonisi wrote: On Thu, 2005-02-10 at 10:41 -0500, Cole Tuininga wrote: Okay, here's at least some answers. You asked if yum had the equivalent of apt-cache search. Well, I haven't used apt in a while, but does what it looks like it does, then, yes, the version of yum available in Fedora Core 3 has a yum search function which will do a glob and return a list of matching packages. That's close to what I was talking about. The really neat part (IMHO) about apt-cache search is that it doesn't just do a glob search on package names, it does a glob search on the files *within* the packages. As an example, let's say I happen to know that in order to get a remote machine to handle X forwarding with ssh, I need the xauth command. But I'm not really sure in what package I would find xauth. $ apt-cache search xauth xbase-clients - miscellaneous X clients xvfb - virtual framebuffer X server Sounds like xbase-clients is what I want. This is the thing that kinda wowed me about apt when I first started playing with debian. I'm imagining that yum probably has a similar ability though. [snip interesting comments on apt-get's role in the rpm world] I actually hadn't realized yum was written in python, though I probably should have figured it out. As you say, the RH install/configuration team sure seems to be endeared towards the language. For my part, I can't blame 'em. ;) -- Give a man a match, and you keep him warm for an evening. Light him on fire, and he's warm for the rest of his life. Cole Tuininga Lead Developer Code Energy, Inc [EMAIL PROTECTED] PGP Key ID: 0x43E5755D ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
Re: Debian flamewar
Cole Tuininga wrote: As an example, let's say I happen to know that in order to get a remote machine to handle X forwarding with ssh, I need the xauth command. But I'm not really sure in what package I would find xauth. $ apt-cache search xauth xbase-clients - miscellaneous X clients xvfb - virtual framebuffer X server Sounds like xbase-clients is what I want. This is the thing that kinda wowed me about apt when I first started playing with debian. I'm imagining that yum probably has a similar ability though. That was one of the things I liked most about Debian too. I think it has inspired the other extended package managers (yum, urpm, ...). For example, Mandrake's equivalent is: # What package contains xauth: $ urpmq xauth mkxauth # Fuzzy search (these packages mention xauth): $ urpmq -y xauth The following packages contain xauth: XFree86 mkxauth pam # Who depends on this package: $ urpmq -R xsane xsane xsane-gimp # What does this package depend on: $ urpmq -d xsane bash chkconfig common-licenses fontconfig glibc grep hotplug ifplugd ldconfig libatk1.0_0 libexif9 libexpat0 libfontconfig1 libfreetype6 libgdk_pixbuf2.0_0 libglib2.0_0 libgphoto-hotplug libgphoto2 libgtk+-x11-2.0_0 libieee1284_3 libjpeg62 libpango1.0_0 libpcre0 libpng3 libsane1 libtermcap2 libtiff3 libusb0.1_4 libxfree86 libxpm4 pango sash usbutils xsane zlib1 Of course, this one can be less useful for some packages, since dependencies can fan out rapidly. xauth, for example, depends on 80 different packages. -- Dan Jenkins ([EMAIL PROTECTED]) Rastech Inc., Bedford, NH, USA --- 1-603-206-9951 *** Technical Support for over a Quarter Century ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
Re: Debian flamewar
On Feb 10, 2005, Bill McGonigle wrote: On Feb 10, 2005, at 18:43, Paul Iadonisi wrote: Okay, putting the sarcasm aside, I have no problem with referring to Red Hat Enterprise Linux as well as Fedora Core as GNU/Linux based operating systems. I used to not care too much about the push for GNU/Linux but upon further reflection it does tend to denigrate the contributions of other significant developers. A linux webserver depends just as much on Apache as it does on libc as it does on the linux kernel. Hmmm, last time I checked it was the NASA Space Shuttle, not insert name of largest contractor here Space Shuttle. NASA not only didn't design the space shuttle, but they don't even assemble the damn thing. I'm sorry, but the FSF has no ground to stand on in this debate. Their own GPL states that you are free to do what ever you want with their software as long as you retain the copyright notice and provide access to the source. No where does it state that you must name a collection of software in which theirs is the majority after their project. Free software is all about the freedom of CHOICE. And that includes the right to choose what name you want to give your collection of it. By the way, everyone here is a nazi, therefore I hereby declare this debate/thread/discussion over! :) -- Seeya, Paul ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
Re: Debian flamewar
By the way, everyone here is a nazi, therefore I hereby declare this debate/thread/discussion over! :) BWAHAHAHAHAHAHAHAHHAHAHAHAAHAHAH Yah, that will make this stop :) ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
Re: Debian flamewar
On Fri, 2005-02-11 at 09:08, Dan Jenkins wrote: Cole Tuininga wrote: As an example, let's say I happen to know that in order to get a remote machine to handle X forwarding with ssh, I need the xauth command. But I'm not really sure in what package I would find xauth. $ apt-cache search xauth xbase-clients - miscellaneous X clients xvfb - virtual framebuffer X server Sounds like xbase-clients is what I want. This is the thing that kinda wowed me about apt when I first started playing with debian. I'm imagining that yum probably has a similar ability though. That was one of the things I liked most about Debian too. I think it has inspired the other extended package managers (yum, urpm, ...). For example, Mandrake's equivalent is: # What package contains xauth: $ urpmq xauth mkxauth # Fuzzy search (these packages mention xauth): $ urpmq -y xauth The following packages contain xauth: XFree86 mkxauth pam # Who depends on this package: $ urpmq -R xsane xsane xsane-gimp # What does this package depend on: $ urpmq -d xsane bash chkconfig common-licenses fontconfig glibc grep hotplug ifplugd ldconfig libatk1.0_0 libexif9 libexpat0 libfontconfig1 libfreetype6 libgdk_pixbuf2.0_0 libglib2.0_0 libgphoto-hotplug libgphoto2 libgtk+-x11-2.0_0 libieee1284_3 libjpeg62 libpango1.0_0 libpcre0 libpng3 libsane1 libtermcap2 libtiff3 libusb0.1_4 libxfree86 libxpm4 pango sash usbutils xsane zlib1 Of course, this one can be less useful for some packages, since dependencies can fan out rapidly. xauth, for example, depends on 80 different packages. And let's not forget Mandrake's handy urpmf command for this: [EMAIL PROTECTED]:~$ urpmf xauth xorg-x11:/usr/X11R6/bin/xauth xorg-x11:/usr/X11R6/man/man1/xauth.1x.bz2 kdebluetooth-devel:/usr/include/qobex/qobexauth.h smlnj:/usr/lib/smlnj/src/eXene/graph-util/CM/DEPEND/xauth-sig.sml smlnj:/usr/lib/smlnj/src/eXene/graph-util/CM/DEPEND/xauth.sml smlnj:/usr/lib/smlnj/src/eXene/graph-util/CM/x86-unix/xauth-sig.sml.bin smlnj:/usr/lib/smlnj/src/eXene/graph-util/CM/x86-unix/xauth.sml.bin smlnj:/usr/lib/smlnj/src/eXene/graph-util/xauth-sig.sml smlnj:/usr/lib/smlnj/src/eXene/graph-util/xauth.sml freeswan:/usr/share/doc/freeswan-2.04/std/draft-beaulieu-ike-xauth-02.txt XFree86:/usr/X11R6/bin/xauth XFree86:/usr/X11R6/man/man1/xauth.1x.bz2 [EMAIL PROTECTED]:~$ When a compile barfs because it's looking for a specific file, urpmf is ideal for identifying exactly which -devel RPM(s) can provide that file. [EMAIL PROTECTED]:~$ urpmf xrender.pc libxorg-x11-devel:/usr/lib/pkgconfig/xrender.pc libxfree86-devel:/usr/lib/pkgconfig/xrender.pc [EMAIL PROTECTED]:~$ -- Bill Mullen RLU# 270075 ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
Re: Debian flamewar (was: OpenOffice doc...)
On Wednesday 09 February 2005 10:42 pm, Benjamin Scott wrote: (Long-time members of this list will recognize the subject, which I drag out whenever I get particularly irritated by all the Debian elitists who think nobody's ever installed software before. If you're not interested in this kind of crap, just ignore this thread.) It was a small comment that I didn't expect would incite such a banter, but let me throw a few words of explanation through here at least to try and settle the water. The size of Debian's main package repository (the distribution, really) is really what most Debian zealots like when they say they like apt-get. It isn't the tool, it's the effort that goes into that repository. That repository is one of the things that keeps bringing me back to try Debian. That is right of course. When I say APT, I meant the attention to details in Debian's package depositories and that is obviously a misnomer. But that comes from the conversation about it being as simple as using APT to get packages and by and large, it is. Now especially with APT available for RPM-based repositories, it probably should be corrected, but it also seems that RPM-based repositories are moving to using yum instead. Whatever floats your boat... Unfortunately, it appears to me that Debian people, apparently as a universal rule, have no concept of software configuration management at all. So as the number of packages increases, the single-large-repository model takes longer and longer to do integration testing. That makes stable doomed to be perpetually hopelessly out-of-date. Which is not good. I keep waiting for Debian people to realize that until they break things down into manageable chunks, they're never going to make progress. The single-large repository part is what's important. It takes a little longer to unify configuration in such a way that it almost doesn't matter which web server, or which MTA you install for example, but that extra time it takes to try making sure everyone follows the same universal configuration management practices is appreciated by Debian users. Again, it's just different from other systems sometimes, but once you're familiar with a Debian system, it makes a lot of sense. I think the same thing when I get on a RedHat-based system. As for the manageable chunks, I think the Debian offshoots are best at that. There are lots of Debian sub-projects out there for education distros, office distros, mythtv distros - some official, some not. Ultimately, that niche is already filled with options... Debian doesn't need to break up to fill it. On the topic of Stable still being hopelessly out of date, just consider how annoyed you are hearing about Debian and APT and imagine the same from me when I hear someone talk about Debian being out of date. Once more, servers don't need the latest greatest KDE and Gnome and cd burning software and office suites, etc. Stable is fine for them. This is probably the first time in awhile that I have felt Stable is starting to get a little old with no MySQL4, Exim4, Apache2, etc... but that's just because it's at it's oldest now. Sarge will be out soon and magically, those will be available. And as for non-servers, just use Testing. It's stable enough for any desktop. If you can express your annoyance by Debian zealots, then this paragraph was my Debian zealot rebuttal ;-). Another really impressive but usually overlooked feature of Debian is the general attitude that Free Software and community development are the way to go. Things like the Debian Social Contract and the Debian Free Software That's true, but I generally associate that will ranting and try not to mention that so as not to start flame wars about overly-obsessive lawyer-type people with long shaggy hair. Regardless, I started a flame war anyway, so yes, I'll mention I feel better knowing someone is paying attention to these details, but I also dip into other repositories on occasion for things like dvdcss and lame. I guess I'm a bit of a contradiction, but I find value at least in knowing exactly which packages aren't really free. But all the Debian zealots just say APT rocks and RPM sux!! and wonder why nobody cares. I don't recall saying RPM sux, just that APT was very valuable when you got used to it. And also according to the misnomer discussion above, I'm really just talking about the repositories and the attention to detail and all that. I've used both dpkg and rpm, and IMNSHO, I think rpm is the better of the two. Some operations are a lot faster, and others are just a lot nicer to use (rpm -V and rpm -Uvh, for example). And the build tools and source management of rpm blow away Debian's offerings. Or they did when I last looked at them, which was admittedly a few years ago. But given Debian's rate of change, I don't expect it's that much different. I don't use dpkg enough to compare
Re: Debian flamewar (was: OpenOffice doc...)
I'm top posting.. so deal. If you don't like up2date or yum, go get apt-get for rpm and shut your yap. http://apt.freshrpms.net/ it's like bitching that the tires on your ford is not the same as the tires on your chevy, just go get the same freakin' tires that's on the ford if you don't like the ones on your chevy.. At least apt-get for RPM is free. Mmmm ... distro flamewars in the morning for breakfast yummy... *grin* On Wed, 2005-02-09 at 22:42 -0500, Benjamin Scott wrote: Long-time members of this list will recognize the subject, which I drag out whenever I get particularly irritated by all the Debian elitists who think nobody's ever installed software before. Woah hoss! 8) There is no claim below of Debian being better than anything (here's my original comment - judge for yourself). On Wed, 9 Feb 2005, at 4:27pm, [EMAIL PROTECTED] wrote: Debian's equivalent of rpm is dpkg. Apt is sort of like up2date on a large quantity of steroids. 8) The OP made a comment about wishing that there was a single command like the rpm command for debian. I was giving the analogy to offer explanation - not comparison of distros. I don't think I was out of line to imply that apt does a lot of things that up2date doesn't do. This wasn't intended to claim apt as the be-all end-all of package management, but rather to compare tools I was familiar with. That said, I've never been one to step away from a nice toasty flamewar. ;) I've never, ever been that impressed by the functionality of apt-get vs anything else. Yes, it manages package dependencies. So do/did yum, up2date, rpmfind, and autorpm. Out of curiosity, does yum do something like apt's apt-cache search function? I've been out of the rpm world long enough to have never used yum and I just remember really being impressed by apt-cache search when I switched to debian (circa Redhat 7.2ish). I still find it to be an inordinately helpful command. I've been having my RPM dependencies solved for me for years and years. It just really ain't all that impressive. Get over yourselves. We would, if you rpm zealots would just recognize our superiority. ^ | | *Joke! Joke!* Flamewars aside, I think that part of the zeal towards apt for folks like me is that it does so much more than just dependency resolution. The size of Debian's main package repository (the distribution, really) is really what most Debian zealots like when they say they like apt-get. It isn't the tool, it's the effort that goes into that repository. That repository is one of the things that keeps bringing me back to try Debian. So very true. It's handy to have them all in one place. Again, I'm not familiar with yum, but aren't there yum repositories out there that allow RPM types to have pretty comparable lists of software? That makes stable doomed to be perpetually hopelessly out-of-date. Which is not good. I keep waiting for Debian people to realize that until they break things down into manageable chunks, they're never going to make progress. Some might argue that Ubuntu is accomplishing this. This isn't to exclude any other distros or claim any superiority of Ubuntu ;) but to offer it as an example of some folks that are doing something about what you're talking about. But all the Debian zealots just say APT rocks and RPM sux!! and wonder why nobody cares. Not true - I'm a zealot and I've never said it. 8) I certainly prefer apt to rpm and am happy to explain why to whomever cares, but everybody's certainly entitled to their own preferences. On Wed, 9 Feb 2005, at 8:14pm, [EMAIL PROTECTED] wrote: Use apt for more than a day and I'm sure you'll never look back at rpm. Apples and oranges. Use yum for more then a day, and I'm sure you'll never look back at dpkg would be equally (in)valid. Quite true. I've used both dpkg and rpm, and IMNSHO, I think rpm is the better of the two. This I would also have to agree with. For those unfamiliar with debian though, dpkg is a very rarely used or needed command. Are rpm based distros getting to be that way as well? That is, getting to the point where the rpm command itself is becoming less and less used in favor of things such as yum? ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
Re: Debian flamewar
On Thu, 2005-02-10 at 14:11, Bob Bell wrote: On Thu, Feb 10, 2005 at 01:09:50AM -0500, Jason Stephenson [EMAIL PROTECTED] wrote: It was largely the issues of package management that made me decide to go with FreeBSD and OpenBSD for my computers at home, instead of various flavors of GNU/Linux. I found the ports collections to be the solution to deb and rpm hells. If you want to try Linux again sometime, I suggest you consider Gentoo. Probably the most similar to the BSDs wrt ports and such. I use it and like it. There would certainly be a learning curve, but there's a lot of good documentation at gentoo.org. I wholeheartedly agree. We run a Gentoo box here, an old dual-PII/350 with a couple of SCSI drives. It gets fairly light duty; its main 24/7 job is running an Enemy Territory server (at et.hubnetworking.net, if anyone on the list cares to drop by g). Gentoo's package management system, portage, is just a joy to work with, IMHO. As for the RPM-based distros, I think Mandrake's urpm* tools are superb. Just my $0.02USD ... -- Bill Mullen RLU# 270075 ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
Re: Debian flamewar (plus a GNU/Linux rant)
[As The Linux Lobbyist comes to life, he says...] Oh, goody, my favorite flamewar! ;-) On Thu, 2005-02-10 at 01:09 -0500, Jason Stephenson wrote: Heh. I find this discussion mildly interesting from where I sit, a mostly xBSD user. As preface, let me say that I like the BSDs somewhat, save the anti- GPL bigotry among many of the developers that is usually accompanied by a completely lack of understanding (or deliberate misrepresentation) of its terms. [snip] we had multiple systems running HP-UX, Solaris, IRIX, Red Hat GNU/Linux, Debian GNU/Linux, FreeBSD, and even 1 Hmm, Red Hat GNU/Linux? Is that something new that Red Hat is selling and/or distributing? Because I've never heard of it before. Funny...poking around http://www.redhat.com/, it looks like Red Hat has heard of it either! So I guess I'm not crazy. Okay, putting the sarcasm aside, I have no problem with referring to Red Hat Enterprise Linux as well as Fedora Core as GNU/Linux based operating systems. But as far as I'm concerned, when you put the distribution together, you get to keep the naming rights. Not the FSF. Not the GNU project. And not (sorry, I know he may be on this list, but that's life) Richard Stallman. For the record, I like and agree with nearly everything, if not everything that has come from those three. And if RMS and I hashed this particular issue out over a latte we'd probably end up agreeing in the end. It was largely the issues of package management that made me decide to go with FreeBSD and OpenBSD for my computers at home, instead of various flavors of GNU/Linux. I found the ports collections to be the solution to deb and rpm hells. In almost every case, I cd into the program's ports directory, type 'make install' and the software builds, installs, and then runs with no hitches. There's very little to package manage and that's how it should be, IMHO. Ah, but you are demonstrating almost the exact disconnect that Ben spoke about in his initial complaint about how the Debianites equate the large collection of debs available at many mirrors with the functionality of apt-get when apt-get is not at all unique and arguably inferior to many of the equivalent dependency resolution tools available in rpmland. What's missing in the GNU/Linux world (there, see? I'm not totally opposed to GNU/Linux usage ;-)) outside of Debian is a good process. (Debian, of course, could use a little *less* process so that there is an update more than once a decade.) The tools are really there with possibly some minor tweaks necessary. What the BSD ports collection seems to have is an excellent process for making sure that everything works together. I don't know how big the ports collections are in the various BSDs, but its possible that there is also more software than you will find in the typical GNU/Linux distro (save Debian, of course). I experienced all kinds of problems on the Linux machines, mainly because we were a research institution and the profs would need some bizarre hardware combination that wouldn't quite work with the default packages from the various releases. It became a nightmare trying to maintain a machine loading packages from 2 different Debian releases, or trying to install binary RPMs on some of the RedHat machines with different kernels, etc. Wait, I'm have a little trouble understanding the problem. What were the problems specifically? If you are saying that you needed to install a custom kernel and because you did that (with make bzImage;make modules;make install;make modules_install or whatever), then I think I see the problem. It all comes down to packaging. I'm a packaging fanatic. I hate stuff in /usr/local. I also won't touch a 'make install' as root with a ten foot pole that poops all over my filesystem. I create rpms in my sleep even. If I were a Slackware fan, I'd create tgz's in my sleep. The point is, an OS should be divided up into manageable chunks so that they can be updated independently and without source. Source is good, but how many times, for example, do you want to build perl and answer those questions? So, I've even going as far as foregoing the (rather baroque, IMO) usually kernel compile/install. Instead, I start with Red Hat's source rpm file and make the mods there. Add a tag to the Release: to indicate it's changed and 'rpmbuild -bs SPECS/kernel-2.6.spec;rpmbuild --rebuild --target=i586,i686,noarch SRPMS/kernel-version-release.src.rpm' and a while latter I have some binary kernel rpms that keeps the dependency tree in /var/lib/rpm consistent. It's work, yes, but once you master it, it's *much* easier to diagnose many classes of problems. You master the OSes you need to deal with. What I'm saying is that your choice to go with BSDs in some places was very likely the right one for you, particularly if you had more of an interest in learning them because that inertia alone would help you in managing those
Re: Debian flamewar (was: OpenOffice doc...)
On Thu, 2005-02-10 at 10:41 -0500, Cole Tuininga wrote: [snip] Furthermore, I was asking questions regarding yum because I have interest in learning about it. Okay, here's at least some answers. You asked if yum had the equivalent of apt-cache search. Well, I haven't used apt in a while, but does what it looks like it does, then, yes, the version of yum available in Fedora Core 3 has a yum search function which will do a glob and return a list of matching packages. You also asked if there were yum repos that have comparable selections of software to Debian. Ah, well, that's a tall order to fill ;-). But, the biggest two I know of are http://atrpms.net/ and http://dag.wieers.com/home-made/apt/. Both of them, I think, are both apt- and yum-enabled. There's also, of course, the venerable http://freshrpms.net/. Honestly, I'd forgotten about apt for rpm (from how little I hear of it, it sounds like it's little used? Is this true? If so, anybody have thoughts as to why?) Well, there are certainly apt-rpm *fans* on the fedora lists ;-). One of the problems with apt-rpm, at least historically, is that it was a real PITA to create the repo from a directory of rpms. Yum, in contrast, was one simple yum command (forgot the subcommand -- it's been a while -- yum now has a separate 'createrepo' command). Also, historically, apt-rpm was atrocious performance-wise. That's improved dramatically, but explains one of the reasons the leaning was toward yum when Fedora Core was being conceived. And then there is the matter of the language it was written in: C++. Whatever your opinion of C++, the simple fact is that a significant portion of Red Hat's tools developers have historically known and been proficient in python. Yum is written in python. That meant it was going to be much simpler just from an on-going maintenance point of view to keep it integrated well with rpm and other admin tools within Fedora Core. That's just Fedora Core, of course, since that's my experience. Another thing to keep in mind is that there has been a common repo format in development for some time and I think that most of the depsolver tools will be able to grok it if they don't already. That's good news for everybody involved because it means repo maintainers can just 'createrepo' and have it immediately be accessible via apt-get, yum, urpm*, up2date and the like. -- -Paul Iadonisi Senior System Administrator Red Hat Certified Engineer / Local Linux Lobbyist Ever see a penguin fly? -- Try Linux. GPL all the way: Sell services, don't lease secrets ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
Re: Debian flamewar (plus a GNU/Linux rant)
On Feb 10, 2005, at 18:43, Paul Iadonisi wrote: Okay, putting the sarcasm aside, I have no problem with referring to Red Hat Enterprise Linux as well as Fedora Core as GNU/Linux based operating systems. I used to not care too much about the push for GNU/Linux but upon further reflection it does tend to denigrate the contributions of other significant developers. A linux webserver depends just as much on Apache as it does on libc as it does on the linux kernel. Maybe someone should start an OSS/Linux meme. -Bill - Bill McGonigle, Owner Work: 603.448.4440 BFC Computing, LLC Home: 603.448.1668 [EMAIL PROTECTED] Cell: 603.252.2606 http://www.bfccomputing.com/Page: 603.442.1833 AIM: wpmcgonigleSkype: bill_mcgonigle ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
Re: Debian flamewar (was: OpenOffice doc...)
On Wed, Feb 09, 2005 at 10:42:15PM -0500, Benjamin Scott wrote: On Wed, 9 Feb 2005, at 4:27pm, [EMAIL PROTECTED] wrote: Debian's equivalent of rpm is dpkg. Apt is sort of like up2date on a large quantity of steroids. 8) I've never, ever been that impressed by the functionality of apt-get vs anything else. Yes, it manages package dependencies. So do/did yum, up2date, rpmfind, and autorpm. I've been having my RPM dependencies solved for me for years and years. It just really ain't all that impressive. Get over yourselves. The size of Debian's main package repository (the distribution, really) is really what most Debian zealots like when they say they like apt-get. I couldn't agree more. Unfortunately, it appears to me that Debian people, apparently as a universal rule, have no concept of software configuration management at all. Here again, I couldn't agree more. And I also get a little incensed when I hear people tlalking about how superior Debian software is than Red Hat (or choose your favorite other distro to beat on). I've managed both of these, and others, both on my own personal systems and in corporate environments, big and small. By and large, the software is the very same software. Despite Debian's long testing cycles, they still ship with loads of strange bugs, and I seem to be good at finding them all. ;-) Red Hat isn't better; they're just different. Frankly, I'm not even all that impressed with apt's dependency resolution skills... I've come across several situations where it was impossible to install a package I wanted, because its dependencies had been removed from or otherwise didn't exist in the repository. I've also come across situations where doing a dist-upgrade completely broke my system. Red hat isn't better here either, and admittedly probably worse. But then, regardless of OS, I'd much rather do a fresh install than an upgrade any day. It's kind of like moving; it's a PITA, but it gives you a great opportunity to do house cleaning. ;-) One reason I always shied away from Debian is because it was hard to download CD images... you had to build them yourself. While I've heard that they provide all the tools to make it easy to build the CDs, I have to confess that I spent long enough wandering around the maze of their documentation that I just gave up. Regardless, it's an extra step that frankly, I want my distro to do for me. I've also seen Debian packages configure things in strange ways that (IMO) no self-respecting system administrator would ever imagine... In that regard, I do actually think Red Hat is better, but that may just be a matter of personal preference. Another really impressive but usually overlooked feature of Debian is the general attitude that Free Software and community development are the way to go. Things like the Debian Social Contract and the Debian Free Software Guidelines. No other major distribution has anything like that. Debian takes the Free Software mindset (the bazaar if you're an ESR fan) and applies it to the entire distribution. That's cool. Agreed too. I also like Debian's emphasis on accountability. Each package has an official maintainer, who is ultimately responsible for that package. You're not dealing with a faceless corporate entity. Got a problem, contact the maintainer. Maintainers need credentials (signed keys or a photo ID), and have an existing maintainer vouch for them. Nice. Red Hat has something similar in their development team, but the difference is that the assigned maintainer is YAUPOWE (Yet Another Under-Paid Over-Worked Employee). But I'm not sure if there's any practical difference here. A lot of times the RH guys push stuff off on the official maintainers, who often are the Debian maintainers too. The bottom line is the better distribution is the one you find easiest to work with for whatever purpose you have in mind... Inherently, they're all about the same. -8^) [-- I'm going bald...] -- Derek D. Martinhttp://www.pizzashack.org/ GPG Key ID: 0xDFBEAD02 -=-=-=-=- This message is posted from an invalid address. Replying to it will result in undeliverable mail. Sorry for the inconvenience. Thank the spammers. pgpjrW4nLW1WA.pgp Description: PGP signature
Re: Debian flamewar (was: OpenOffice doc...)
On Wed, 9 Feb 2005 23:33:03 -0500 (EST), Benjamin Scott [EMAIL PROTECTED] wrote: On Wed, 9 Feb 2005, at 11:00pm, [EMAIL PROTECTED] wrote: Are there only the official Debian repositories or are there others that don't follow the Debian standards? One does see third-party packages for Debian, and even repositories, but they're a lot less common then for, say, Red Hat/Fedora. I suspect this is mainly because it's a lot easier to get a package into Debian/sid, and once it's in it's available to everyone almost immediately. So there's just a lot less call for it. That certainly make sense In my hazy memories, I recall that RPM came after dpkg and was developed, in part, by the dpkg developer under hire from Redhat. I haven't heard that before, and from what I've read, that is at least partly incorrect. Not that I'm an expert or the information I have is authoritative; far from it. But from what I've read, dpkg was born in 1994. RPP, the distant ancestor to RPM, was born around the same time. RPP was followed by PMS, then PM. Finally, RPM officially debuted in 1995 with Red Hat Linux 2.0. As I said, hazy memories. :-) Maybe it was yggdrasil? The only package system I remember in wide use before Redhat came out was SLS's which Slackware continued. Not really a package though. Of course, none of this precludes learning lessons from Debian. Certainly, RPM came well after dpkg did. References: http://www.debian.org/doc/manuals/project-history/ch-releases.en.html http://www.debian.or.jp/events/2002/0919-lc2002/JP-Enkai-History.html http://rikers.org/rpmbook/node9.html http://www.owlriver.com/RH-true-names.html -- Ben Scott [EMAIL PROTECTED] | The opinions expressed in this message are those of the author and do | | not represent the views or policy of any other person or organization. | | All information is provided without warranty of any kind. | ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
Re: Debian flamewar
Heh. I find this discussion mildly interesting from where I sit, a mostly xBSD user. It's funny, too, 'cause I didn't start using FreeBSD for my workstations and personal servers until I worked in a data center environment with mixed UNIX systems. At the University of Kentucky's College of Engineering Computing Center, we had multiple systems running HP-UX, Solaris, IRIX, Red Hat GNU/Linux, Debian GNU/Linux, FreeBSD, and even 1 web server with OpenBSD for a certain network/clustering research group that some on this list have probably heard of. Also, the two of us in the UNIX Support Group were responsible for several dozen other UNIX and Linux workstations spread throughout the college and not just the servers in the back room. It was largely the issues of package management that made me decide to go with FreeBSD and OpenBSD for my computers at home, instead of various flavors of GNU/Linux. I found the ports collections to be the solution to deb and rpm hells. In almost every case, I cd into the program's ports directory, type 'make install' and the software builds, installs, and then runs with no hitches. There's very little to package manage and that's how it should be, IMHO. I experienced all kinds of problems on the Linux machines, mainly because we were a research institution and the profs would need some bizarre hardware combination that wouldn't quite work with the default packages from the various releases. It became a nightmare trying to maintain a machine loading packages from 2 different Debian releases, or trying to install binary RPMs on some of the RedHat machines with different kernels, etc. It soon became routine for my colleague and I to install nearly everything from source code on certain machines because we knew that the packages would not work. I have found that installing from source, and knowing what different gcc and make errors mean, is the only way to get software that will run on your machine 100% with no faults other than their own bugs or bugs in the libraries they link to. It can be time consuming to maintain a machine with source-compiled binaries, but I haven't found any update routine that's simpler or more sure-fire than: cvsup -g -L2 /home/root/sup/FreeBSD-ports-supfile pkg-delete -a cd /usr/ports/[pkg-cat]/[pkg-name] make install clean The last two lines need to be repeated for each package you wish to install. I can't count the number of times I've had apt-get update apt-get install fail and for what reasons when. I've also dealt with RPM-hell of having to install RPM after RPM, just to get the one thing that I want to use installed. I've also had installs fail on some machine, again because of custom packages needed for one reason or another. I can tell you that I've only ever had two package fail make install in FreeBSD ports because one time I updated right after a change to one package, and the second time because the package maintainer had written his makefile to check for the headers from a specific version of the mysql libs and I'd installed a more recent one. In both cases, the fixes were simple changes to the makefile that I sent off to the package maintainers. One was incorporated into the makefile, and the other maintainer wrote back thanking me, but that he'd already updated the repository with a better change. I've not ever had a problem with ports on OpenBSD, but I've used it much less. Oh, and don't get me started on the package management in IRIX, HP-UX, and Solaris. They have varying degrees of success and failure, and you often have to go to third party sources on the Internet or resort to installing things from source for the useful stuff. Anyway, to me, it isn't software without source code, and I do prefer to install from source because then you know it works with the libraries installed on your system because it was compiled against those very libraries. You don't need to worry about binary compatibility issues between different library and kernel versions busting your binary packages. Yeah, you could end up with something that doesn't compile, but at least then, you can see what the problem is and fix it yourself. Well, gee, that was longer than I anticipated. ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
Re: Debian flamewar (was: Hello?)
On Fri, 2002-08-09 at 15:24, Ed Lawson wrote: [EMAIL PROTECTED] wrote: I wish the Debian community would stop acting like Debian is God's Gift to Linux! It is of course with some trepidation that I respond, but upon reading my post I am unable to discern what language therein could lead a person to reasonably conclude that I have espoused or acted in a manner which suggests Debian is God's Gift to Linux. Or even that it is better to anything else. While these are doubltless not the last words to be seen on the topic, they are my last words. Ed Lawson Said in good humor Okay, so it's said in good humor. But I see exactly what Ben was talking about. What you posted was a fix for a vulnerability in mailman that was back-ported by the Debian team and released as part of a security advisory. In that message you proclaimed that this was another reason to like Debian. Ben's point, I believe, is that it is a bit strange to proclaim as a reason to like Debian, something that not only is not unique to it, but, according to the example you gave, an area where it fell short -- the fix was released two month's after another popular distribution's fix for the same problem. Several months ago, I set up my brother-in-law with a dual boot Windows 2000 / Red Hat 7.2 system at home. He works for HP as a VMS principle firmware developer. He has an ia64 system at his office at work with Red Hat 7.1 (which is what he use for some VMS development). Just a few days ago, he was having trouble figuring out how to download, install, and configure wu-ftpd. After hours of research, he gave up and finally sent me some email. Here is a quote from him as someone who hasn't had all that much exposure to Linux: ...All I can find are tiny bits and pieces of information here and there, some of it conflicting. And then there are the Debian zealots. Oy! What's got into them? No initial biases, just some personal experience. Your message would have been much more effective and kept the focus on the discussion about mailman without the uncalled for Debian comment. -- -Paul Iadonisi Senior System Administrator Red Hat Certified Engineer / Local Linux Lobbyist Ever see a penguin fly? -- Try Linux. GPL all the way: Sell services, don't lease secrets ___ gnhlug-discuss mailing list [EMAIL PROTECTED] http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
