Slashdot Mirror


User: Etyenne

Etyenne's activity in the archive.

Stories
0
Comments
673
First seen
Last seen
Profile
(view on slashdot.org)

Comments · 673

  1. Re:Fix LDAP first... on Samba 4 Reaches "Susan" Stage · · Score: 1
    For now, our solution is probably going to be "roll OpenLDAP, keep it separate from the Unix LDAP (iPlanet on Solaris), and just maintain two separate directories..." (ugh... the Holy Grail of Single Sign On eludes us once again...)

    You are making the common mistake of confusing "single sign-on" with centralized authentication. This is pretty common. Kerberos is single sign-on (well, as far as kerberized services and clients are concerned): you provide your credentials once, then authentication to various services happen transparently and without interaction with the user. LDAP can be used to build centralized authentication; your credentials still have to be provided to different services, which in turn authenticate against this central authentication mechanism. Sorry for the nitpicking, it's a pet peeve of mine.

  2. Re:Bias? on Wikinews Project Launched · · Score: 1

    If you care to share, I'd like to hear about these report on the credibility of Wikipedia.

  3. Re:From the article... on Linux Kernel to Fork? · · Score: 1

    Look, I'm not interested in a flamewar here. I will take responsibility and apologize for a rather acid tone in my initial comment, but upon reading this last message, I think you actually did a better job illustrating my point than I could possibly have done. And as long as we're on apologies, your insinuation of ignorance probably merits as much of an apology as any of my acidity.

    If you are not interested in flamewar, you need to chill out and take a deep breath before posting. This is the Internet. Don't get so rilled up.

    My constatation of ignorance does not merit an apologies, it merit a little education. Don't like to be lectured ? Don't be so opiniated about stuff you know little about then.

    Telling me that I should switch "package managers" or "packager installers" or "dependency resolvers" is symptomatic of the very same mentality. Once upon a time I was vaguely interested in learning how different package systems work, now I'm over it, and I don't find explanations of how I'm doing the wrong thing less than a total waste of time.

    Software installation and management in linux was problematic. Package managers are the solution to this problem. If you don't want to hear about the solution, you forfeit your right to complain about the problem in the first place.

    I have used urpmi and up2date on Mandrake and RedHat respectively, as well as Slackware's tgz installer. Upon installing Suse9.1 for a server, I skipped the nonsense and used plain old rpm -Uvh.

    This is workable only if you have very few systems to admin or do not bother about keeping them up-to-date. Your choice, but this is very poor system administration practice, and a waste of time to boot.

    All of the "package agents" had so many flaws in design - from timeouts on the client to Python errors to timeouts hitting overloaded servers - that I found it easier to search rpmfind than to wait 25 minutes for urpmi or Mandrake's GUI called DrakX (or whatever the hell it was called) to time out and tell me that it couldn't resolve dependencies.

    I have had a constantly good experience using apt (on both Debian and RedHat) and yum (on Fedora). Some repositories are indeed slow, but beside that I suffered none of the problem you described. Not to say that these problem does not happen, but they are certainly not as generalized as you make them to be.

    Sorry for the distro-blaming answers, but you are the second one who complain about Mandrake package management in this thread. Maybe this is where the problem lie, I am not qualified to comment as I am not a Mandrake user. But you can't generalize your experience on this distro to "Linux" in general. Debian have been using a package manager for almost a decade, with very few hiccups.

    You can tell me I'm not using the right version of the distro or the software or whatever, but until I can transparently and quickly get, install, and use software, I will stick by my spelled out statement about installing software on Linux: B-R-O-K-E-N.

    [root@sigil root]# apt-get install frozen-bubble
    Reading Package Lists... Done
    Building Dependency Tree... Done
    The following extra packages will be installed:
    SDL_gfx SDL_ttf perl-SDL smpeg
    The following NEW packages will be installed:
    SDL_gfx SDL_ttf frozen-bubble perl-SDL smpeg
    0 upgraded, 5 newly installed, 0 removed and 0 not upgraded.
    Need to get 8355kB of archives.
    After unpacking 14.2MB of additional disk space will be used.
    Do you want to continue? [Y/n] y
    Get:1 http://apt.physik.fu-berlin.de fedora/2/en/i386/at-stable SDL_ttf 2.0.6-3.rhfc2.at [22.7kB]
    Get:2 http://apt.physik.fu-berlin.de fedora/2/en/i386/at-stable smpeg 0.4.4-9_2.rhfc2.at [110kB]
    Get:3 http://apt.sw.be fedora/2/en/i386/dag SDL_gfx 2.0.12-3.1.fc2.dag [47.6kB]
    Get:4 http://apt.sw.be fedora/2/en/i386/dag perl-

  4. Re:From the article... on Linux Kernel to Fork? · · Score: 1

    No. A library package can (and often do) provide multiple version of the same library if appropriate. The situation you describe is not unheard of, but it's pretty uncommon if you keep your system up-to-date.

  5. Re:From the article... on Linux Kernel to Fork? · · Score: 1

    Libraries in Unix are versionned. That is why there are so many soft link in /lib and /usr/lib ending with numbers.

    In your example, the first application would use liba.so.3 and libb.so.2. The second would use libb.so.3 and liba.so.2. Pretty simple, actually.

  6. Re:From the article... on Linux Kernel to Fork? · · Score: 1
    And I've used quite a few GNOME and KDE package managers on a variety of flavors of Linux.

    Not that I want to be obtuse, but package manager are not related to your desktop environment. You may have a Gnome or a KDE frontend to a package manager, but it is not the package manager proper.

    For example, if I'm looking for a RedHat 8.0 binary for an MPEG player ( by poring through rpmfind.net looking for a binary that matches my distro and version), and either download an RPM compiled for SuSE (either by accident or out of desperation), my chances are pretty decent of having it tell me that it needs 6 dependencies resolved before I can watch a simple video clip.

    (Emphasis mine) You did exactly what you should not do. Finding and retrieving the correct package is the job of your package manager. The problems you experienced are exactly what apt, yum, urpm, emerge, YaST and the other package managers solve.

    Judging by what the description of your problem, I can pretty much infer that you actually never used, and/or don't know exactly what is meant by "package manager".

    I see you use RedHat 8; AFAIK, this version built-in package manager was up2date, which is of good help to keep your system up-to-date (duh) but pretty crappy as an aid in installing software. Go to Freshrpms.net and download the apt package for RedHat 8. Install it with rpm -ivh apt...i386.rpm (yeah, it suck to use the command line, but newer distro come with a GUI for package management built-in and RH 8.0 is getting old). Once this is done, type apt-get update followed by apt-get install synaptic. From there on, you can launch the Synaptic GUI frontend to apt from somewhere in the menu. Search for the mplayer package and install it. Bingo, you win.

    As I said, newer distro come with a decent package manager built-in so you don't have to go through these hoops. Fedora come with yum, but lack a decent GUI for the process. Both Mandrake and SuSE have decent GUI frontend from what I have been told.

    And you can make all the apologies you like for it, but it is B-R-O-K-E-N, and it's going to do a lot to stall the adoption of Linux until it's fixed.

    The only thing broken right now is your lack of knowledge about what a package manager is and does, and that is fortunately easy to fix. Follow the instructions above (or use a newer disto) and come back with your questions if you have any. I will gladly accept your apologies for your ignorance and name-calling.

  7. Re:From the article... on Linux Kernel to Fork? · · Score: 1
    The problem is with setup programs that don't use any of these methods and simply unpack their files, blindly overwriting anything in the way.

    Are there a better way ? How can a software installer deal with an installed library which is of a version known to break its application ?

    Make up your mind; either they are stored centrally and there wouldn't be extra copies or they are not stored centrally in which case DLL Hell is impossible.

    That's precisely the problem: both happen in a typical Windows system. DLL are scattered all over C:\Program Files, and those in windir\system32 are susceptible to being overwritten by careless installer.

    You are right in saying we can't blame MS for software that do not follow established guidelines. It just happen much less often in Linux.

  8. Re:From the article... on Linux Kernel to Fork? · · Score: 1
    Well, I don't know what "mere mortals" you know, but in my college 471 network lab class we are using RedHat 7.3 (IDK Why, the school refuses to upgrade).

    Probably your school refuse to upgrade because it take time your techs may not have, and involve a certain risk they are not willing to take. RH 7.3 was a pretty good and solid release, but its time have passed. It's like the Windows 98 of Linux; a lot of people use it as it was very widely deployed, but its time have passed and you would rather use something else today. You should remind your school administration that this release does not receive any more update, which may leave it open to some security bugs (unless they use the update service of Progeny, that is).

    One of my classmates has spent the entire semester till now trying to install FireFox with no success. Everyone else is stuck using Mozilla 0.9 that came with it as we cannot seem to install any software not specially prepared by the instructor.

    According to rpm.pbone.net, Dag's repo have an rpm of FireFox 1.0 for RedHat 7.3. Enjoy !

    These are Computer Information System majors, who have taken programming classes, data communication classes, and have done projects with various software to get to a high 400 level class. We cannot get software to install on linux reliably.

    I know some of them myself. A CS degree actually mean very little when it come to actual computer usage and troubleshooting. Certainly mean you're pretty smart, but that's about it.

    And why do I need a program to install a program? It just doesn't make any sense.

    It depend how you see it. You need a web browser to chase down freeware on the Internet, is'nt it ironic too ?

    In the end, if using a package manager make your life easier ... why not ?

  9. Re:From the article... on Linux Kernel to Fork? · · Score: 1

    Indeed, this is drawback of Linux package management. As a software developer, your best bet would be to keep your software dependencies sane (ideally, only LSB libs) and release a generic RPM.

    I don't think writing a spec is any more difficult than writing an MSI, but I might be wrong on the subject.

  10. Re:From the article... on Linux Kernel to Fork? · · Score: 1

    Here, take a Prozak on me.

    Package manager are certainly not perfect but they do work. As far as I know, the universe Ubuntu repo is considered experimental and possibly very broken (this may have changed with the 1.0 release, I don't use it). What I do know for sure is that my Mplayer rpm from Freshrpms.net installed without a hiccup and work flawlessly.

    Sorry for your bad experience, but anecdotes are anecdotes and package managers work for the vast majority of people. Badabingbadaboom.

  11. Re:From the article... on Linux Kernel to Fork? · · Score: 1

    On the Freshrpms.net repository mailing list, people often post request for packaging. Sometime, a packager come up and build one.

    Another alternative would be to bug the author of the program. He probably want his software to be as widely used as possible, and the best way to ensure that is to make it easy for people to install it. Otherwise, he might know anout someone who already package it.

    In last resort, you can compile it yourself. But, please, use an auto-packager like checkinstall to ease management.

  12. Re:Libraries? on Linux Kernel to Fork? · · Score: 1

    DLL are libraries. Libraries in Linux usually end with a .so suffix. Reusing libraries is a good idea (wheel reinventing and stuff), but does come at the expense of dependency problem. In Linux, we fixed that problem by using package managers, which resolve and install dependencies recursively. It work, what more can I add ?

    If you use Linux, which distro ? I might be able to point toward the one used in your installation.

  13. Re:From the article... on Linux Kernel to Fork? · · Score: 1

    This is precisely why most package manager including apt can be configured to install software from CD-ROM instead of online repositories.

    Installing a 120 MB software with package manager is no more painful than downloading a 120 MB installation .exe from the Web.

  14. Re:From the article... on Linux Kernel to Fork? · · Score: 2, Insightful

    I know you are making an attempt at sarcasm, but just to clarify, yes, apt take care of the downloading. You do not have to open to open your browser, look for the software, download it and install it by hand. All these step are automated, including fetching the software on the Internet. If you are on a slow link, most package managers can be configured to use a local media (CD-ROM) as software repository. But if you happen to have a fast link, then package manager and online software repositories really shine in ease-of-use.

  15. Re:From the article... on Linux Kernel to Fork? · · Score: 1

    I am not too familiar with Mandrake package manager, so I would not comment on it, but that distribution have a reputation of poor engineering. That is the reason why I don't use it personnally, but I know quite a few people I respect who swear by it, so I guess Mandrake work most of the time ... at least for some people.

    apt under both RedHat and Debian have never failed on me in the past few years. It just work.

    BTW, there is a package manager for MacOS X not totally unlike yum or apt used to install Open-Source software. It's called Fink, and quite a few Mac users I know have only good words to say about it. You can't escape it; package manager *is* a good idea.

  16. Re:From the article... on Linux Kernel to Fork? · · Score: 1

    Anecdote for anecdote, I have been using various form of package managers for the past three years on varios with no problems*. So does most Linux users. Maybe you hit a bug, shit happen, but these are certainly the exception.

  17. Re:From the article... on Linux Kernel to Fork? · · Score: 1

    If you really want to, you can go through the hardship of compiling a particuliar software yourself. But I find it is very rarely necessary, as almost all Linux software end up being available in one of the severl reputable repositories I use (Freshrpms, Livna, DAG, NewRPMs and kde-redhat, mostly).

    Adherence to a clique is a not a pre-requisite to use package manager and software repositories. They are open, no need to get along with the maintainer. For Fedora-specific instruction on how to use software repositories, check http://www.fedorafaq.org/#installsoftware

  18. Re:Uh-oh on Linux Kernel to Fork? · · Score: 1
    People compile things themselves for all kinds of reasons, I tell users to compile from CVS if they encounter a bug in between releases.

    Depending who your users are, I don't think your render them a service. Compiling is time-consuming and error-prone, not the kind of thing I am expecting a newbie to do.

    I compile almost everything myself, there's no reason not too and I configure/link only options/libs that I will use.

    It's fine if you have a lot spare time. I don't, unfortunately. Hopefully, all the software you install by hand have a nice make uninstall target, you keep a log of what you do to roll-back change when necessary.

    Hopefully, you use a source-based distro such a Gentoo. I would not want administer the mess that would be a system half package-based, half-compiled by hand.

    Who do you think would compile these non standard RPM's you mention if nobody is supposed to compile their own software?

    Not me, that's my entire point. Compiling is tedious, boring and time-consuming. Some people volunteered to do it in my place. Who am I to refuse the favor ?

    Do you really trust a third party to compile your software for you? I'm surprised nobody set up a RPM site that bundles spyware with every binary!

    Certainly could happen. That is why you configure only software repositories from reputable source and have your package manager validate GPG signature of packages (mine does by default). In practice, this is no more a problem than building trojaned source, for example.

    And yes, I do enjoy watching compiler output scroll by

    Whatever float your boat.

  19. Re:From the article... on Linux Kernel to Fork? · · Score: 1
    Sure, apps still come with the DLL version they want. Not so different from Linux, except that I have to hunt down the blasted right version, probably compile it, and sometimes even have to get new versions of libraries that the library is dependant on!

    Again, not if use a package manager. Sorry if I sound like a broken record, but apt-get install foo will download package foo, resolve and download all its dependencies recursively and install it for you with very little, if any, interaction. Welcome to the 21st century. Have you used Linux in the past .. four years ?

  20. Re:From the article... on Linux Kernel to Fork? · · Score: 1
    1) Explain to user why the desktop OS they currently use which seems to work simply except when they occasionally need to call their IT dude is really the wrong approach altogether

    Sorry, I can't parse this sentence. May you please make use of comma and/or punctuation ?

    I think the gist of it is : "Windows is broken but I don't notice (often); why should I care ?" To which I would answer : don't, keep using it if it work for you.

    2) Explain to user how the OS they "should" move to makes is so much better because makes it impossible to install a great deal of software packages.

    First, I never implied you "should" move to Linux. You could, if you want. You may not, for various reasons. It's up to you.

    Second, this question probably imply a false assumption. I am not sure what you mean by "great deal of software packages". If you mean Win32 software, well, duh. If you mean native Linux application, then you are greatly mistaken. Modern distro ship with a mind-boggling amount of application in the first place, which should include pretty much everything a typical would ever need. But since there is no such thing as a "typical user", there is a lot of third party software repositories full of software pre-packaged for the most popular distro. Once you know how to use a package manager (a knowledge scarce in this thread, unfortunately), installing software become actually easier in Linux than in Windows.

    3) Continue to complain about Windows when user prefers an OS on which mere mortals can install software packages.

    But mere mortal can install software in Linux too. Your assumption is simply wrong.

    Your point about multiple DLLs leading to eventual OS rot is a fair one, although I'd be interested to see what role unclean poweroffs, hardware degradation, etc play as opposed to application DLLs.

    I don't think any of these factor should play any role in OS degradation. OS should not "rot" in the first place. That's a shining example of users getting used to their OS flaws to the point of not seeing them anymore.

    The disk space argument is basically moot these days, though the multiple unpatched libraries issue is not, but the current RPM dependency resolution really doesn't handle ferreting out old (now insecure) library versions either.

    Wrong again. Assuming you did not compiled library yourself (and quite franckly, nobody in their right mind do that), all your installed libraries can be tracked down, accounted for and upgraded. This is actually the number one benefit of Linux package management. Wheter people bother with actually keeping their system up-to-date is another matter entirely; witness all the Windows worms based on old, already-patched security holes.

    Your point about disk space is definitely valid, though. Keep in mind however the mess of scattered files a typical Windows installation is.

    The only versioning proposal I've heard that makes sense is the DragonflyBSD one - where there's a smart dependency resolver that lets you use installed libraries when possible, and lets you easily install new library when that won't work.

    Wrong ... again. Library versionning actually predate Linux, and have been of Unix for ... I'm too young to know. It work damn well too.

    You don't need to be so insecure about your choice of OS. If you like Windows, by all means, continue to use it.

  21. Re:Behavior is an Illusion on Windows on Linux Kernel to Fork? · · Score: 1

    I like Fedora, which is the Free (beer and speech) off-shoot of RedHat. It is relatively up-to-date while getting an acceptable level of release engineering; this contrast with Debian apparent desuetude (when are they going to switch to x.org ?) and Mandrake if-it-compile-ship-it release engineering. It come with up2date utility (the flashing red "!" in the bottom-right corner of your screen), which include a GUI and which you may already be familiar with if use/admin an RHEL system. It also come with yum, by which some people swear. It is functionnally equivalent to apt, although I personnally find it very slow and full of annoying quirk (update on each operation unless you provide -C, etc).

    I personnally prefer apt, which is the Cadillac of package manager IMHO. It is also the most time-tested one, being the official package manager of Debian for what ? 5 or 6 years ? You can get the apt rpm for various flavor of RedHat and Fedora at http://apt.freshrpms.net; it will also pre-configure your system to use the excellent and well-garnished Freshrpms third-party package repository. Check the software installation section of http://www.fedorafaq.org for more info on package management under Fedora.

    Welcome abroad, and enjoy yourself !

  22. Re:From the article... on Linux Kernel to Fork? · · Score: 4, Insightful
    You don't understand. I don't WANT to go through all this bullshit.

    Going thru this "bullshit" is actually easier than installing software in Windows. Assuming you use and apt-based distro, just type apt-get install foo. You don't need to even download the software, apt does it for you. The only interaction it require is a confirmation if your package have dependencies. A minute or two later (depending on the size of the software and the speed of your connection), the magic happen : the software is installed ! No chasing software on the Web, no downloading, almost no interaction (don't you find clicking Next, Next, Next stupid at last ?). It's the best thing since sliced bread, yet you fail to see it. Again, which distro do you use so I can give you clear instructions on how to use your package manager properly ?

  23. Re:From the article... on Linux Kernel to Fork? · · Score: 1

    Sorry, not a SuSE user here. But I was damn certain that the YaST package installation facility was able to resolve dependency.

    For the other :

    • In Mandrake, do "urpmi <package name>" or use the package management GUI within the Control Center.
    • In older RedHat and current RHEL, use up2date <package>.
    • In newer RedHat and Fedora, use YUM : "yum install <package>". Be prepared for a long wait as yum download update header if you do not keep your system up-to-date, which lead me to recommend to ...
    • Use third-party apt with RPM-based distro. I like the package from Freshrpms as it just work out-of-the-box. Then, do "apt-get update; apt-get install <package>".
    • In Debian, it's apt-get just like above, and you have my sympathy if you don't know about it. For a GUI, try Synaptic (apt-get install synaptic).
    • In Gentoo, it's emerge. But you already know that if you use Gentoo.
  24. Re:Uh-oh on Linux Kernel to Fork? · · Score: 1
    Well sure I build things from source all the time (via make/make install), and sure their dependencies aren't backwards compatible. I often have several versions of many libraries installed at once (which is something that should almost never have to be done).

    Just a tip : you should use Checkinstall. That being said, I never really understood the people that insist on compiling stuff themselve. Unless you are using Gentoo (ha ha Gentoo), most distribution today come with a plethora of packages, and there are plenty of third-party repositories for packages that are not included in the default install; for Fedora, check Livna, Freshrpms, DAG, NewRPMs and a few others. Is it because you enjoy watching compiler output scroll by ?

    When you release a library you are making a promise that any future version of the library will offer the same functionality. New functionality is just that-- new. Bug fixes? Well you shouldn't have released it yet. People may now use the bugs to serve another purpose and you can't go "fixing" them, as you are now breaking your software.

    That is why library are versionned in Linux. Did you ever wondered what all these softlinks in /usr/lib where for ?

  25. Re:From the article... on Linux Kernel to Fork? · · Score: 1
    * BOTTOM-LINE - Before you state something guy, learn how it works... thanks!

    Thanks for the teaching, really. It's nice MS finally solved this pretty big problem. But, yike, what a hack !

    Do application today still ship their own DLL to avoid this mess ? How common are statically linked application today ? As you can see, I have been out of the Windows loops for a few years (fortunately).