Couple of things I should touch on in this thread.
On Thursday, November 17, 2011 11:53:51 AM, Mark Wallace wrote: ... > 7) Printers are either one extreme or the other. Plug your printer in > before you install. Also plug your laptop in and have it online during > the install. An HP printer when plugged in after an install will > immediately tell you that it is installing the driver which will take a > few seconds. Other printers don't have Linux drivers at all. It's so > much easier than Windows where you have to put a CD in and then stop it > from installing a lot of bloatware. Printer drivers are broken up into several different packages on Debian-based systems these days. It's not necessary to have the printer plugged in at install time. (I never have.) Printers can be installed or removed using the Printer Configuration area within System Settings at any time. > 8) KDE tried to set it's install so that it would close down the > desktop effects if it didn't think that your video card could handle > it. (If your distro assumes that your video card had more capability > than it has, a blank screen could result.) KDE will disable the desktop > effects for you and if they won't reactivate when you check the box, KDE > believes that your video card isn't up to the job. You can manually turn compositing (i.e. desktop effects) on and off again by pressing Alt-Shift-F12. Sometimes you need to know this to turn compositing back on after a low-power state had automatically turned it off. On Thursday, November 17, 2011 12:59:14 PM, [email protected] wrote: ... > My impression of Mint is that it's got a very small support network, which > forces them to market themselves as conservative. It's a Ubuntu derivative. I'm told that Mint is going back to using Debian as the origin, because Ubuntu packages Unity and IIRC lacks the Gnome3 shell. Mint seems to be rapidly gaining a lot of trackion right now. ... > The impression that I get is that when something new comes out in Linux, > the package's committee are counting on the initial users to help them with > bug fixes. There's usually no committee; most software packages have an individual Maintainer. But for large bodies of software (like "KDE"), the work can be spread out by creating a packaging team for that section. I've been learning something about the Debian (and Debian derivative) development process, and it's a bit of a surprise. Normal users without any training can attempt to make a .deb package for software they'd like to see in Debian, and can submit it for review to the Debian Mentors website, whether it be something new or for a new version of something that is already in the software tree. If the package is acceptable then the Debian Developer (DD) that reviewed the package uploads the package into Debian, and the original packager that sent the packge in for review is set to be the Maintainer of that package and is the one that gets to handle bug reports. If that Maintainer doesn't have upload rights (and to start with they don't), then after any package fix the Maintainer goes back to the Mentors list to have a DD review and upload the package again. Usually for new packages, the "stable" version of the software being packaged is preferred, even for Debian "Unstable". The intent is to package up software that is "known working" and is of as high a quality as possible. This can sometimes be a bit frustrating for software authors, who would rather see the newest version of their software packaged up and being used, rather than an older version that they might not want to continue supporting. The orignal software author in package terms is usually referred to as "upstream". When a bug report comes in, the package Maintainer gets an email from the BTS [Bug Tracking System]. If the bug requires a patch to fix, then usually the Maintainer is encouraged to discuss the fix with Upstream. For situations where Upstream doesn't want to incorporate the patch/fix (or in sitautions where Upstream is gone), the patch is queued up in a patch list using 'quilt', and these quilt patches become part of the package and are therefore distributed with it. Downloading and expanding the source package using 'apt-get source <package>' downloads the source for that package and automatically applies the quilt patches that come with it. Often enough when a bug report first comes in, it's not assigned the correct package, but rather to a package where the troubling symptom is seen. It's therefore common for bugs to be reassigned to another package, sometimes being bounced around a couple of times as developers try to figure out which software is actually generating the bug. And then the process of fixing the bug may take a while as contact with Upstream needs to happen, patching, repackaging, re-uploading to the Mentors list for review, etc. So that's why an attempt is made not to have bugs in the first place, because bug reports shouldn't be relied upon. Nobody wants to upload buggy software. On Thursday, November 17, 2011 07:43:20 PM, [email protected] wrote: > Seriously, wasn't one of the major objectives of Linux was that it would be > happy with older hardware? The major objective was to create a usable system that was free and open, and maintains the user's right to see and alter the source code for it. The Linux kernel developers do mandate that old hardware that is still in use should continue to function and be supported, but it isn't specifically optimized for old hardware AFAIK. > At least, anything this side of 10 years old? I'd hate to see Linux > becoming like Windows, in that you need to upgrade to all new latest and > greatest hardware for each OS release. There must be some happy medium > between being able to use older hardware and having all the latest W7-like > kewl features in order to attract Windoze users. I'm a bit concerned by the movement towards requiring OpenGL that both Gnome and Qt (the basis for KDE) are taking. Getting 3D/OpenGL to work on Linux can sometimes still be problematic. -- Chris -- Chris Knadle [email protected] _______________________________________________ Mid-Hudson Valley Linux Users Group http://mhvlug.org http://mhvlug.org/cgi-bin/mailman/listinfo/mhvlug Upcoming Meetings (6pm - 8pm) MHVLS Auditorium Dec 7 - An Intro to Chef Jan 4 - Recovering the Brownfield: Revitalizing Open Source Projects Feb 1 - Home Networking Made Simple with Amahi Home Server
