| |||||||||||||
|
| |||||||||||||
Revealed: how Fedora and the community interactRevealed: how Fedora and the community interactPosted May 4, 2004 20:59 UTC (Tue) by maceto (guest, #16498)Parent article: Revealed: how Fedora and the community interact
I can`t understand why people use it? Doh!
(Log in to post comments)
Revealed: how Fedora and the community interact Posted May 4, 2004 21:17 UTC (Tue) by tomsi (subscriber, #2306) [Link] I use it. It has a nice non-intrusive easy-to-use GUI so it's good for my desktop stuff.I also use SUSE, but for my servers. I tried Debian but find it too arcane. Started with slackware and still like it; but currently not using it. Mepis and Peanut: Those are new to me - time to dig out an old machione and do some research.
Revealed: how Fedora and the community interact Posted May 6, 2004 3:48 UTC (Thu) by clintcan (guest, #21406) [Link] Peanut Linux is a minimalist distribution (350MB) based off slackware. The stable version 9.5 is about a year old (although it finds my hardware excellently!)The latest version, 9.6 is kernel 2.6.5 based with a cloop filesystem and the disk is capable of booting as a live CD. It installs itself using EXT2,EXT3,XFS and ReiserFS as well as a umsdos install. The site is down as of the moment.
Revealed: how Fedora and the community interact Posted May 4, 2004 22:09 UTC (Tue) by JoeBuck (subscriber, #2330) [Link] I run Fedora Core 1, despite the problems so effectively pointed out in the fake IRC chat. I have one box that runs Debian sarge, but that's just for fooling around, not getting work done. I like the idea of Debian, I really do. But woody is so old as to be useless, unstable is too unstable (a sid update broke ssh recently, which is a complete disaster when you can't get to your system remotely), and until recently sarge systems tended to be inconsistent (half of an older Gnome or KDE and half of a newer one). My wife is a non-techie but a good sport, and she can work effectively with Fedora Core (she uses Evolution, Open Office, and Mozilla and that's about all she needs). I would not subject her to any of the three Debian alternatives at this point, though sarge, if it could be pulled together in reasonable time, would be suitable. The combination of Fedora Core, Fedora Extras, and rpm.livna.org with apt-get and synaptic is quite effective for me. I might be willing to switch to Debian sarge at some point, assuming that it stabilizes nicely and the battles over sufficient freeness can be overcome.
Revealed: how Fedora and the community interact Posted May 4, 2004 23:41 UTC (Tue) by tjc (guest, #137) [Link] But woody is so old as to be useless, unstable is too unstable (a sid update broke ssh recently, which is a complete disaster when you can't get to your system remotely), and until recently sarge systems tended to be inconsistent (half of an older Gnome or KDE and half of a newer one).It seems like there's a place for a 4th version of Debian between unstable and testing. Maybe based on unstable, but a week or two behind in the updates. This way when something bad happens, like a broken X server, there's time to fix it before it propogates to "semi-unstable." Is there any provision for telling apt to delay updates for x number of days? If there is/were, that would be a nice way to control the "unstableness" while still using the same repository.
Revealed: how Fedora and the community interact Posted May 5, 2004 0:21 UTC (Wed) by JoeBuck (subscriber, #2330) [Link] No, Debian doesn't have the cycles to support yet a fourth version. Better to just focus on getting sarge finished.
Revealed: how Fedora and the community interact Posted May 5, 2004 3:03 UTC (Wed) by rfunk (subscriber, #4054) [Link] Maybe based on unstable, but a week or two behind in the updates. This way when something bad happens, like a broken X server, there's time to fix it before it propogates to "semi-unstable." You just defined the testing branch of Debian.
Revealed: how Fedora and the community interact Posted May 5, 2004 17:04 UTC (Wed) by tjc (guest, #137) [Link] You just defined the testing branch of Debian.Some of the packages in "testing" are months behind unstable. I'm looking for a delay of one or two weeks, not months.
Debian testing Posted May 5, 2004 17:32 UTC (Wed) by rfunk (subscriber, #4054) [Link] Some packages in testing are months behind because either the newerversions have "release-critical" bugs keeping them out, or they have dependencies that either haven't been in unstable long enough (or at all) or that themselves have release-critical bugs. Those dependencies are always the killer..... And if you're going to just unconditionally stick something in testing after being in unstable for a week, you're losing the benefits of that week delay in the first place.
Debian testing Posted May 5, 2004 18:47 UTC (Wed) by tjc (guest, #137) [Link] And if you're going to just unconditionally stick something in testing after being in unstable for a week, you're losing the benefits of that week delay in the first place.I'm not suggesting sticking anything in "testing." What I am suggesting is adding capabilities to apt so that updates can be delayed for x number of days in the hope that major problems can be avoided. This would not require an additional branch. Think of it as following someone on the highway 4 or 5 seconds behind, instead of right on their back bumper.
Debian testing Posted May 5, 2004 19:29 UTC (Wed) by rfunk (subscriber, #4054) [Link] I'm not suggesting sticking anything in "testing." The mechanism isn't important. You're talking about client-side smarts vs server side smarts, but the end result of what's installed on the system is really the important thing.
What I am suggesting is adding capabilities to apt so that updates can be delayed for x number of days in the hope that major problems can be avoided. But you need to do more than hope if you're going to avoid major problems. During that x number of delays, major problems may be found, but they may not be fixed yet. What you're proposing is to go ahead and get those packages even with known major problems, rather than wait until those major problems are fixed.
Debian testing Posted May 5, 2004 21:57 UTC (Wed) by tjc (guest, #137) [Link] The mechanism isn't important.Yes it is. If capabilities are added to apt, then there is no additional maintanance for the pool. It gets the same files, just delayed by an interval selected by the user. What you're proposing is to go ahead and get those packages even with known major problems, rather than wait until those major problems are fixed. No, that's not it either... What I would like is some time to find out that a problem exists before I install a package. If I could hold updates back for a week or two, that would provide some time for major problems to become known. Finding out that a package is messed up after it has been installed it isn't all that helpful.
Debian testing Posted May 6, 2004 9:47 UTC (Thu) by boomi (guest, #21418) [Link] > Finding out that a package is messed up after it has been installed it isn't all that helpful._Someone_ has to find out. If you use unstable, you agree to help discover bugs in new packages. Use testing if you don't want to do that. Btw: old packages are stored in /var/apt/ archives, you can easily restore an old version. Using unstable? You are asking for trouble. Which is a good thing, someone else won't have the
Debian testing Posted May 6, 2004 15:20 UTC (Thu) by tjc (guest, #137) [Link] If you use unstable, you agree to help discover bugs in new packages.I don't recall entering into any such agreement. :-) Use testing if you don't want to do that. Testing is too old for my taste. By the time it becomes stable, it will be nearly obsolete. It's sort of the worst of both worlds in that respect. There's a big gap between "testing" and "unstable." It's within this gap that Fedora Core and Mandrake exist. Debian could probably increase the size of their user base by a significant amount by filling this gap. Personally, I use "unstable" on my workstation, but I keep a partition with Fedora Core around in the event that "unstable" becomes too much of an adventure. I wait for the dust to settle, and come back in a week or so. This happens about once a year.
Debian testing Posted May 10, 2004 9:55 UTC (Mon) by mbanck (subscriber, #9035) [Link] There's a big gap between "testing" and "unstable."I don't believe this is true right now. The release team is doing a great job nowadays resolving problems in testing when two packages keep each other out and so. It used to be quite bad when only AJ was looking after testing, but since we have a couple of very bright "Release Lieutenants", things are moving quite well. For example, it used to take a new glibc package months to enter testing. Last week, 2.3.2.ds1-12 entered testing after being in unstable for just two weeks or so. I agree that stable might be too old for desktop use (I have to use it myself at work), but testing is only lacking behind only for some corner-cases, while it is quite uptodate in general. Michael
Quit it... there is a solution to both your qualms. Posted May 6, 2004 19:49 UTC (Thu) by gfolkert (guest, #21427) [Link] http://snapshot.debian.net/ apt-get debian packages on specified date (relative date)deb http://snapshot.debian.net/archive/date/datestr/debian unstable main contrib non-free deb http://snapshot.debian.net/archive/date/datestr/debian-non-US unstable/non-US main contrib non-free deb-src http://snapshot.debian.net/archive/date/datestr/debian unstable main contrib non-free deb-src http://snapshot.debian.net/archive/date/datestr/debian-non-US unstable/non-US main contrib non-freeNote that datestr is datestr recognized by date(1), such as yesterday, 2-days-ago, last-week, 2-weeks-ago. You will get everything JUST like you want.
Quit it... there is a solution to both your qualms. Posted May 6, 2004 21:47 UTC (Thu) by tjc (guest, #137) [Link] OK, now that's what I was looking for! Thanks.
Quit it... there is a solution to both your qualms. Posted May 10, 2004 12:03 UTC (Mon) by zigg (guest, #14265) [Link] Okay, that's just plain nutty. You get all the same bugs, all the same uninstallable packages, all the same horking -- just two weeks later than everyone else. The only possible advantage you can have is that maybe there might be a fix in two weeks that you can go and pull from unstable.After gnucash broke last time, I moved to testing. It works. It is not "behind" in any way that causes me any kind of trouble. I pulled one package from unstable -- kernel 2.6.5, to support my wireless card -- and even that is in testing now. Testing is what you want.
Revealed: how Fedora and the community interact Posted May 6, 2004 9:48 UTC (Thu) by angdraug (subscriber, #7487) [Link] There always is a reason for that: http://bjorn.haxx.se/debian/testing.pl
Revealed: how Fedora and the community interact Posted May 5, 2004 8:52 UTC (Wed) by evgeny (guest, #774) [Link] > Is there any provision for telling apt to delay updates for x number of> days? If there is/were, that would be a nice way to control the > "unstableness" while still using the same repository. There is apt-listbugs apt plugin which fetches bug reports for packages before installation and in case there are critical ones lets you decide what to do. For me, it reduced the apt-get upgrade headaches significantly. It would be nice yet to tell it to wait for a minimal delay (unless this is a security update) to allow for bug reports to flow in. It could be a separate (from listbugs) plugin.
Revealed: how Fedora and the community interact Posted May 5, 2004 17:07 UTC (Wed) by tjc (guest, #137) [Link] There is apt-listbugs apt plugin which fetches bug reports for packages before installation and in case there are critical ones lets you decide what to do.Thanks for the info - I will install apt-listbugs and give it a try.
Revealed: how Fedora and the community interact Posted May 5, 2004 17:09 UTC (Wed) by razholio (guest, #5706) [Link] 'But woody is so old as to be useless'*sigh* I maintain several woody servers doing radius, SMTP, IMAP, POP3, HTTP, HTTPS, SSH, SAMBA, DHCP, HTTP proxy and others... I enjoy the fact that these systems are up-to-date on security fixes (that never break anything) within hours of public disclosure, are rock-solid stable and make my life as an administrator rediculously easy. I have chosen to compile a couple apps, although i didn't *have* to. I can't imagine another distro on my servers. I have woody on my workstations too, although here I've had to do more work with several backports in /etc/apt/sources.list and lot's of stuff compiled from source (although usually the ./configure&&make&&make install three-step is faster than my co-worker's search for a fedora compatible RPM!). There are those times when I look at fedora, but they are infrequent for sure.
Revealed: how Fedora and the community interact Posted May 4, 2004 22:39 UTC (Tue) by AAP (guest, #721) [Link] RH used to be the distro for corporations. Maybe it still is, but I can't recommend RH/Fedora to individuals anymore. These days, I recommend Slackware for the tech-inclined, and SuSe for the people who want something that "just works".
Revealed: how Fedora and the community interact Posted May 4, 2004 23:37 UTC (Tue) by pjhacnau (subscriber, #4223) [Link] I use it.Yes, I like the GUI and don't like SuSE's (at least in 8; maybe 9.1 is much better) Yes, I was using RH before that and I'm lazy. My firewall is running a much-hacked version of 7.0 - prob hacked enough it shouldn't be called _any_ distro :). My server may change from it's current RH9 to another distro as FC1 won't install properly on it - @%@%# network probs. Slakware - what package control? Though having just noticed slack-get on freshmeat I may be out-of-touch there. Hadn't heard of Mepis or peanut before. But there are two things that keeps me on Fedora more than anything else: FreshRPMs and PlanetCCRMA.
Revealed: how Fedora and the community interact Posted May 5, 2004 11:05 UTC (Wed) by haraldt (guest, #961) [Link] Yes, I was using RH before that and I'm lazy. My firewall is running a much-hacked version of 7.0 - prob hacked enough it shouldn't be called _any_ distro :). My server may change from it's current RH9 to another distro as FC1 won't install properly on it - @%@%# network probs. Then you aren't lazy. You haven't found the right thing to install on your firewall yet. You shouldn't need to hack a distro half as much.
linux firewall Posted May 5, 2004 17:09 UTC (Wed) by alphajim (guest, #9856) [Link] very happy with the Bering branch of LEAF. Even uses a current kernel, and shorewall is very good at turning common sense config commands into iptables commands.
Revealed: how Fedora and the community interact Posted May 5, 2004 15:47 UTC (Wed) by gvy (guest, #11981) [Link] Try ALT, it's like Owl server-side, somewhat Mdk/SuSE-alike on the desktop (some things better, some worse), and apt/synaptic are just here.
Revealed: how Fedora and the community interact Posted May 10, 2004 1:48 UTC (Mon) by Arker (guest, #14205) [Link] Slack has awesome package control. It doesn't track dependencies (unless you install RPM, which is an option if you're really hooked on that) but it works great.
Revealed: how Fedora and the community interact Posted May 10, 2004 1:56 UTC (Mon) by Alan_Hicks (subscriber, #20469) [Link] Slakware - what package control?You're obviously out of touch. Slackware ships with a very advanced Actual Intelligence that not only does dependency checking, but also managed your system, installs updates, backports fixes dynamically, and generally handles everything that has to deal with your machine. This AI is so advanced that it can even in some cases create shell scripts to automate the maintenance of your machine, or even write and compile code for such purposes. I would not trust any dependency manager, system configurator, or bug-fixing software. None have proved as effective as Slackware's AI.
Why I'm using Fedora Posted May 5, 2004 19:03 UTC (Wed) by brouhaha (subscriber, #1698) [Link] I can`t understand why people use it?Because I ran RHL before, and upgrading to Fedora Core 1 was trivial. Switching to Debian, SuSE, or Mandrake would be a lot more work. I've been keeping an eye on Debian, as I'm a big fan of their hard line stance on freedom, but their stable distribution is ridiculously out of date, and the last time my friend Mike and I tried to install it, we got fed up with the obscure and complicated questions the installer asked. Mike and I each have more than twenty years of Unix experience, but some of the questions stumped both of us. I'm told the new Debian installer is much better, so someday when Sarge is released I'll give it a try. On the other hand, I'm quite interested in SEL, and it appears that Fedora Core 2 will be the first major distribution to support it. Most people seem to think that dpkg is much better than RPM, but as a software developer I disagree. It appears to me that a dpkg can contain exactly one source tarball and exactly one patch. That means that if I want to package up something with multiple patches, I have to mash the patches all together. Then when a new base release of the software I'm packaging needs only a subset of the original patches, and a few new ones, it's a royal pain to repackage it. Plus, that makes it much harder for someone else to take my dpkg and build a new one with a different set of patches. RPM seems like a clear winner here. Of course, most users aren't concerned with building patches, and Debian used to have an advantage for the user with apt, but now the same capabilities are available in Fedora with either yum or apt.
Why I'm using Fedora Posted May 5, 2004 20:33 UTC (Wed) by MightyPalm (guest, #21398) [Link] I'm really not following you here. What obscure and complicated questions are the debian installer asking you, that with more than 20 years of unix experience you cannot give an answer to?I've had people that never even used a unix-like OS before install debian, and all they needed was a pointer or two on some trivial stuff (i dunno why people are having such problems with the timezone, it asks you if your hardware clock is GMT, you see its your local (not-GMT) time, you answer no, but i've had to correct this for at least 3-4 of my friends that has installed debian). Anyhow, i look forward to get a clarification of where the current debian installer fails to be straight-forward and logical.
Why I'm using Fedora Posted May 6, 2004 10:01 UTC (Thu) by angdraug (subscriber, #7487) [Link] It appears to me that a dpkg can contain exactly one source tarball and exactly one patch. That means that if I want to package up something with multiple patches, I have to mash the patches all together. It appears wrong, you have to take a closer look. It all depends on how you organize things inside that single patch, there are several script systems of varying complexity that help you to organize your patches, see for example source packages for xfree86 or mutt. While we're at it, does rpm have something to replace debhelper and lintian? And don't underestimate the advantage of storing source tarball and packaging patches in two separate files. When you have to keep old versions of your packages around for version control, speed of growths of repository with rpms quickly becomes prohibitive to the whole affair: we have this problem in our company and it is one of the main factors that makes us consider switching to Debian.
Why I'm using Fedora Posted May 6, 2004 12:51 UTC (Thu) by pizza (subscriber, #46) [Link] I'm not sure what debhelper does (help automate package construction?), but there is an 'rpmlint' that at least catches the aggregious errors in your .spec files.The concept behind SRPMs is that it is entierely self-contained; everything that goes into the final package is found inside the SRPM; no external files (save the build dependencies) are needed. And SRPMs can include an effectilvely arbitrary number of individial "source" and "patch" files. Your version control problem sounds more like an artifact of how you create and maintain packages rather than anything inherent to the packaging format; after all keeping old version of .dpkgs wholly intact is going to create much the same repository scope as .[s]rpms, eh? Debian's advantages over everything else stem from three things -- policy, policy, policy. From a technical aspect (eg dpkg vs rpm) however, things are pretty much level, with strengths and weaknesses stemming from the slated goals of the distribution. I personally use RH/FC because I have to do the least amount of work to get the system set up and running how I like -- and the majority of said work is always working around the boneheaded policies of the distro. So naturally I chose the distro whose inherent boneheadedness maps the closest to mine.
Why I'm using Fedora Posted May 6, 2004 13:50 UTC (Thu) by angdraug (subscriber, #7487) [Link] I'm not sure what debhelper does (help automate package construction?) Yes. Automates tens of different package construction tasks, from manpage installation to X font registration or calculation of Perl dependencies. The concept behind SRPMs is that it is entierely self-contained; everything that goes into the final package is found inside the SRPM; no external files (save the build dependencies) are needed. And SRPMs can include an effectilvely arbitrary number of individial "source" and "patch" files. Same applies to a Debian source package: debianization patch can include arbitrary number of individual source and patch files. The only difference is that instead of one file you have a pair of files, which is, once again, entirely self-contained. Your version control problem sounds more like an artifact of how you create and maintain packages rather than anything inherent to the packaging format; after all keeping old version of .dpkgs wholly intact is going to create much the same repository scope as .[s]rpms, eh? Please, do your homework before making comments like this one, it exposes that you didn't actually take a look at the Debian packaging system, as I've suggested in my previous comment. Or else you would have at least noticed that binary packages in Debian have .deb extension ;-) As to our version control problem, we don't need to keep old versions of binary packages, we can reconstruct them from source packages anytime, given that we still keep the latter around. From the other hand, we can't just put the whole damn Linux distro into SCM, it's even more disk space and we only want to maintain a small part of it ourselves.
Why I'm using Fedora Posted May 6, 2004 22:22 UTC (Thu) by mattdm (subscriber, #18) [Link] It appears wrong, you have to take a closer look. It all depends on how you organize things inside that single patch, there are several script systems of varying complexity that help you to organize your patches, see for example source packages for xfree86 or mutt.That's okay if the package was arranged that way to start, but it's hard to take some _other_ package and add this to it. You have to reorganize the whole thing. And then if there's an upstream update, you have to go through the whole process again. With RPM, there's no external scripting systems of _any_ complexity required for this basic functionality. And don't underestimate the advantage of storing source tarball and packaging patches in two separate files. Okay. Meanwhile, don't underestimate the advantage of storing everything in one archive. There's no question that the collection of source files and patches and control file match and are the ones used to build the binaries you've got. When you have to keep old versions of your packages around for version control, speed of growths of repository with rpms quickly becomes prohibitive to the whole affair [...] How many versions of your packages do you have? Is this your own code you're packaging up? In that case, I recommend not making the final distribution package format your source code management tool -- use CVS or one of the newer things, and keep your spec file with your source code. If it's other people's stuff you're packaging, how many versions, do you realistically have? It's not like disk space costs much these days!
Why I'm using Fedora Posted May 7, 2004 10:11 UTC (Fri) by angdraug (subscriber, #7487) [Link] That's okay if the package was arranged that way to start, but it's hard to take some _other_ package and add this to it. If you deal with bad packaging, more often than not you have to rework it anyway, but it only has to be done once. And then if there's an upstream update, you have to go through the whole process again. Err, now I lost you. Is your upstream a someone else's source rpm of some software, or original tarball of the software? In the former case, what for? In the latter, I don't see why the packaging, once done properly, needs to be redone from scratch for each new upstream version, and how is it different for rpm and dpkg? With RPM, there's no external scripting systems of _any_ complexity required for this basic functionality. Right, and there is one single internal scripting system which you have no choice but to love and live with. I think we are rapidly moving towards the ground of personal preferences with this argument. My point wasn't to say that dpkg is better, it was to refute this claim: "RPM seems like a clear winner here". I can see advantages of both, and I aknowledge that by knowing dpkg better I also know its advantages better. Meanwhile, don't underestimate the advantage of storing everything in one archive. I'm afraid I still underestimate it: I utterly fail to see the difference in complexity between 1 and 2. Between 1 and n, yes, but not 2, it is still a single entity in my perception. To claim otherwise is the same as to claim that unpacking the source tarball into a directory with 1000 files somehow splits the entity of the package into 1000 entities, vs. merely changing the physical layout of the same entity. How many versions of your packages do you have? Is this your own code you're packaging up? In that case, I recommend not making the final distribution package format your source code management tool -- use CVS or one of the newer things, and keep your spec file with your source code. If it's other people's stuff you're packaging, how many versions, do you realistically have? It's not like disk space costs much these days! It is both our code and other people's stuff. For our code, we already keep it in CVS, and can track its history just fine (we're looking at "newer things" too, but that's another story). Our problem is with the other people's stuff, which also changes over time, and we would like to have a much more fine-grained history of that. At the moment, we freeze the external repository for each release branch of our software, and we have tens of these, so we're still ok storage-wise until this number grows to hundreds (single version of repository is at 10GB and growing, and we need to set aside quite some space for developers' build chroots, and we can't afford fast and reliable multi-terabyte array), but we have a problem when we have to update some external library to fix a bug in a 2-years old release, and then reproduce the build that was made before this update. It doesn't help much if we have a fine-grained version control of our own software, but are unable to reproduce the environment against which some old version of our software operated. As I've said, we're fine so far, but we're only one order of magnitude away from hitting the storage limit, and that may happen if we were to fork our repository for several lines of products or for different architectures.
Why I'm using Fedora Posted May 6, 2004 19:15 UTC (Thu) by yanfali (subscriber, #2949) [Link] I use it because I know RH so it was trivial to cross over. I really detested up2date, as it just never seemed to work well. However since I discovered the ATRPM repository and it's apt-get I've been very happy. Those guys are doing an incredible job and make it very easy to keep Fedora or legacy redhat patched.
Why I'm using Fedora Posted May 8, 2004 9:14 UTC (Sat) by apollock (subscriber, #14629) [Link]
Please, you're the sort of people that should be beta testing our spiffy new installer. See http://www.debian.org/devel/debian-installer We would value your feedback immensely on making the installation experience better.
|
|
||||||||||||