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
<mailto: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 <mailto: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 <mailto: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
