I have not had the experiences of either of you except when I have cluttered up my install with 3rd party and/or self built packages. I have found Debian to be a little more fragile in this regard.
Having said that, I have both Ubuntu and Debian installs that have gone through several updates without issue. At this point I actually automate my updates and reboots (the script checks to see if a reboot is required). I do not even gracefully end my sessions. Firefox complains that it was not shut down properly but continues to work as expected, even remembering the 50 odd tabs that I had open. In short my desktop (and server installs for that matter) have never been more stable. If there are no reboots, my insane firefox sessions can last for months (I open FF and leave it open, it only closes when I reboot). There may be a plugin/extension messing around with your FF install as well. There is a safe mode where you can test to see if the problem is in fact with an extension. The point is that there is nothing inherently unstable or broken with FF on Linux. I have to respond to this: "This is a very simple data base operation. All we need is a program to walk the directory tree and confirm required files are present and this is what apt has to do anyways. Well I would think eight (8) years should be sufficent". The apt (and yum on rpm based distros) system(s) date back to the 90s. They are all pretty rock solid at this point as long as you don't mess around under the hood (for example by manually compiling binaries and libraries). By design the system searches /usr/local first, so that you can have multiple versions of binaries and/or libraries installed for developing and or testing. It is simple to revert to the system default. If you *exclusively* use apt-get or one of the many front ends, you should not have the problems described above. While you can manually build binaries and libraries and they can work after an upgrade (I do this for nmap for example), there is a non-trivial chance of something going wrong. The moral of the story is that if you value system stability, stick to the system provided tools for installing and maintaining packages. There are even sophisticated systems in place for changing the system defaults by using symlinks. Have a look at update-alternatives or if you are using Debian, update-dependencies. The reality is far more sophisticated and elegant than the solution you suggest. It really is robust if used properly (which it will be by default). This is not the sort of thing that a regular user will need to use or see, it is only for those people who are interested (or like me compelled) to monkey about under the hood. It bears repeating, none of this will be visible nor required to an end user who only uses the system tools for installing and maintaining software. I am sure there is room for improvement but the basic operations are pretty solid at this point which is why people are saying 'Installing and maintaining modern Linux is a non issue for the potential user now. Lets move on". The problem comes from tinkering with the internals. Just like mucking about with the registry in Windows can cause issues, straying outside of your distributions management tools can also be problematic. This is kind of a fundamental truth about any such system. What this means is that I suspect there is something else going on with your installs. It is possible that there is something wrong with Debian, since their stance on non-free software can be a bit of a pain for end users. This is primarily why I do not recommend Debian to non-technical people (or anyone who does not have a lot of free time to troubleshoot) There are many user friendly options to choose from. I love Debian but there can be some rough edges, especially with proprietary drivers, codecs, and the like. Even though I can fix most of the problems that crop up, I choose to use other distributions that require less work to maintain since I want to spend my time doing something else. On the server side I have no problem with Debian, in fact I prefer it to everything else most of the time (Debian stable is now what Ubuntu LTS should have been). If you want a more hands free approach to deploy to other people, Ubuntu (Kubuntu or Lubuntu are fantastic and even better than vanilla Ubuntu IMHO) would be my first choice, Fedora my second. SolidXK (http://solydxk.com/) shows promise, though I have not tested it enough. Most of the graphics subsystem are handled by xrandr, with the GUI tools just acting like as a front end to this utility. The problem is that this depends on the correct driver already being installed. If you have switched from one vendor to another (Intel/nVidia/AMD) you have to install the correct driver (fglrx or nvidia). Ubuntu has a nice gui front end for this, Debian to my knowledge does not. Once you have installed the correct drivers (either via the GUI or CLI apt/aptitude front ends), you may need to "sudo dpkg-reconfigure xserver-xorg" and then reboot. I regularly switch between all three GPU vendors with little issue. My GUI based installs are currently all Ubuntu (with KDE mainly), so YMMV with Debian. Also I am not interested in hearing anyone's political or emotional opinions on why Ubuntu sucks, or rpm distros suck etc. Apt and yum are awesome (though I would choose apt over yum). If you want to use Debian with your proprietary drivers go ahead, it can probably be made to work. Please understand that your choice of distro does have consequences, which in this case means spending a lot more time keeping things running. Hth, On Thu, Feb 20, 2014 at 5:26 PM, Terrell Larson <t...@terralogic.net> wrote: > The last time I upgraded was quite a while ago - from Debian woody to > Sarge. This upgrade was a DISASTER. So much for promises. > > (I think there is a song about that) > > A process when it is shutting down much call wait() and this is when > system resouces are released. Until wait() is called the process goes > into a zombie state. I have firefox for instance die about once a week > since say about 2006. Oh it works... It just spews a few 100 zombies, > rns out of memory and the kernal kills it and cleans up the mess. > > Other than an annoyance this is not a big problem for me. I simply > restart it when its convient and go do something else while it > reloads... which it ususlly but not always does and if not then I do > have checkpoint files in the sessionstore.js files which in my case live > in: .mozilla/firefox/jfthz6j9.default> > > Its a library mismatch issue. Likely nothing more than that. So where > is the utility which can spin through the libraries and actually CONFIRM > that the proper versions are present. > > This is a very simple data base operation. All we need is a program to > walk the directory tree and confirm required files are present and this > is what apt has to do anyways. Well I would think eight (8) years > should be sufficent. > > So I am going back to the way I use to install an OS. I buy a new > computer and if I can't justify that I at least buy a new hard drive! > > I think this speaks to the comments below. > > What we need are very simple tools which can actually access a common > data base of dependancies which hopefully will run off the appropriate > mirrors. Then if a mistake is made it can be corrected and I would > suggest the next time said utility is run it should advise the client of > any other apps which might have a correction. And I'll speak (write) to > this next. > > Several years ago I was in a chat room and someone was trying to get a > CDBurner working. This was alas in Debian Sarge and I think the app was > k3b. I submitted the solution, perhaps to the wrong place. A year > later someone else on IRC was asking the same question. So I told him > where to go. A year later: No improvemnt. > > I conclude we have what Cool Hand Luke suggested is a failure to > communicate. > > ------------- > > Now I have a question: I'm about to install the latest version of > Debian. It will not be an upgrade. I'm not making that mistake again. > > The video in the machine in question is not what will be there down the > track. At this point I don't even know what card it is - but its good > enough for an install. Down the track I might put in two single monitor > cards - likely old decrepid ones, or I might try a 5 head card. > > These all required TOTALLY different drivers. > > How hard is it to switch video systems? If a card dies and there is no > spare how does one even get into a GUI to reconfigure a new card? > > I have NEVER liked GUI's for this simple reason. BUT - I believe it is > feasible to write a system tool which can run in "EITHER" command prompt > -or- GUI modes. Does anyone know if there is anything out there which > acutally does something like this? > > > > > > On Thu, Feb 20, 2014 at 03:55:43PM -0700, Mel Walters wrote: > > Linux. Debian (Stable) > > > > For the intense hobbyist only? > > Here is just a question: > > How much truth is in the statement 'Installing and maintaining modern > > Linux is a non issue for the potential user now. Lets move on.'? > > > > My recent experience was in helping a friend fix his upgrades after his > > GUI upgrade gave an unhelpful error code he was unable to overcome. > > The issues appeared to be authentication and the GUI hiding what was > > going on in the background. Others prefer the command line and ncursers > > like programs (aptitude) so they can see what is going on. With out my > > intermittent help he would be unable use Linux a lot of the time. > > Some of it is just computer user issues, but I'll bet that's not the > > whole picture. > > > > Thoughts? > > > > Mel > > > > > > _______________________________________________ > > clug-talk mailing list > > clug-talk@clug.ca > > http://clug.ca/mailman/listinfo/clug-talk_clug.ca > > Mailing List Guidelines (http://clug.ca/ml_guidelines.php) > > **Please remove these lines when replying > > _______________________________________________ > clug-talk mailing list > clug-talk@clug.ca > http://clug.ca/mailman/listinfo/clug-talk_clug.ca > Mailing List Guidelines (http://clug.ca/ml_guidelines.php) > **Please remove these lines when replying >
_______________________________________________ clug-talk mailing list clug-talk@clug.ca http://clug.ca/mailman/listinfo/clug-talk_clug.ca Mailing List Guidelines (http://clug.ca/ml_guidelines.php) **Please remove these lines when replying
