I would be willing to help, your place, name the evening. Not sure if I can qualify as a propeller head, but I have wanted to skip straight to anti-gravity.(yup, a bona fide space cadet:)(magic carpet)
One of the challenges/strengths of this club is the diversity of the users. But the bigger problem is people have less and less time now, so the OS and programs have to work well and have very succinct manuals and documentation. This puts off the intelligent users too. Lets be sensitive to all pinched nerves and try moving on to the positive. Thanks, Mel Walters On Fri, 2014-02-21 at 10:40 -0500, Jerry Rukavina wrote: > Shawn, not everyone on this list is a propeller head, I am an average > user. > > I am trying to learn but it is a bitch...I must be too dumb to > understand. > > It is frustrating when things break or don't work at all and then having > to spend a ton of time trying to figure out the problems. Sometimes, and > lately all the time, that fix never happens, even though the 'helpful' > forums claim the fix is there. > > And try to get someone to actually work on the box to fix it! Where are > the millions of Linux users - not too many in Calgary, mythical I bet? I > have not found any commercial shops that work with Linux installs and > maintenance either. I could use some help today but can't find anyone. > > My time is better spent making a living instead of playing on the > computer, your suggestion for dummies to switch to windows is looking > more attractive. There would be more converts to Linux if things went > easier from the start and along the journey, imho. > > Jerry > > On 2014-02-21 00:49, Shawn wrote: > > One other factor in this discussion is not if Linux is easy enough to > > install or not, but if the user has the tech know-how and > > understandings to actually use the systems as they are intended. > > Stick a standard Windows user in front of a terminal shell, and you'll > > see much frustration and possible damage to your system. I ran into > > this recently with a Mac based developer who had zero comfort on the > > command line setting up basic PHP modules. > > > > My point is, that you can only dumb down the interfaces so much. > > Unity is a great example of an interface aimed at the mythical average > > user. The problem is that this mythical user seems to have been > > getting dumber over the years. If the trend continues, the interface > > will be a simple button labeled "do something", and the user will be > > upset it didn't do what they wanted. > > > > Domain knowledge is essential to using your tools properly. If the > > users do not understand how to use the GUI based installers, or the > > text based ones, then they should leave installation to someone who > > does. They can enter the picture after the desktop software is in > > place. > > > > On the other hand, the user has to gain that knowledge somehow > > (presuming they want to). At that point they need to be ready for the > > learning experience. That experience has gotten amazingly easier over > > the years, but it is still beneficial to understand what a "partition" > > is, or what "mount points" are. > > > > So, my end thoughts on this topic is that it all depends on the user > > who will be using the system. If they have no intention of learning > > how to maintain and use a Linux box then they should probably stick > > with Windows. If they are wanting to learn more about hardware, > > networking, system administration, etc. then by all means dive in head > > first with the distro of your choice. Ubuntu/Debian/Red Hat are all > > good starting points with lots of support out there. > > > > Claiming "Installing and maintaining modern Linux is a non issue for > > the potential user now" reflects assumptions about the base > > experience, skills, and domain knowledge of the end user. Those > > assumptions can quickly fall flat in the real world where it is not > > always tech savvy folks involved. > > > > I'm a great example of this. Having recently been um, strongly > > encouraged to use the Macs at work. It is a paradigm shift in how you > > use the systems. I have come to rely on Ctrl-C/Ctrl-V, middle click > > cut/paste, etc. These just are not there or are different on the > > Macs. Hell my function keys don't even work as expected. I find > > myself asking for simple things like "how do I get a screen shot?" or > > "what is the equivalent of F6 in Chrome?" Those who know me know I'm > > not a noob, but environmental changes are always going to be a > > challenge. If I find it so, I'd hate to be the mythical average > > user... > > > > My thoughts. > > > > Shawn > > > > On 14-02-20 06:28 PM, Gustin Johnson wrote: > >> 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 > >> > > > > _______________________________________________ > > 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
