I am not an expert on Linux. The only contribution I can make is to relate my experiences in the hope they will be useful to others. I will try below to document carefully specific solutions to the problems I encountered.
First you need to add the the free and non-free RPMfusion repositories to your list of repositories as described here and then do "yum install libdvdread libdvdnav gstreamer-plugins-ugly gstreamer-plugins-bad".
DVDs still are not going to play unless you can decode the DVD-encoding scheme. The only library I know that does this is libdvdcss. I wasn't able to find a repository for libdvdcss, but I was able to download the source code for version 1.2.10 from Videolan. After unpacking the source code and "cd"-ing to the software's top directory, I executed the commands "./configure --prefix=/usr", "make", and finally "make install", and the software installed into /usr/lib.
When I bought a new computer, I was faced with a new problem. Unfortunately, neither Totem nor SmPlayer diagnosed the problem. vlc suggested that the regional code on the dvd player might be the problem. Under Fefora-19, I executed "sudo yum install regionset", and the issued the command "sudo regionset /dev/rs0". The second command reported that the region was not set and I followed directions to set it after which vlc and smplayer played dvds fine.
The installation of libdvdcss proceeded very smoothly, but Totem, the movie player for Fedora-16, did not know to look for the library in /usr/lib. This problem was solved in Fedora 16 by adding the line "export LD_LIBRARY_PATH=/usr/bin" to my .bashrc file (.bashrc is executed when you login to a bash shell, as is the default with many linux distributions). Starting from Fedora 18, Totem morphed into Videos in Fedora/GNOME, and I have never been able to get it to play DVDs from my CD/DVD drive. A solution was simply to use smplayer, which also is in the RPMfusion repositories, to play DVDs. I actually use and prefer smplayer to Videos for playing all video. For Fedora-21, I found that vlc was excellent at playing DVDs and videos.
Fedora 20 came with an additional problem. It contained gnome-mplayer and I was pleased that Fedora and GNOME seemed to be suporting something other than totem (Videos), I decided to try gnome-mplayer as my default dvd player. It complained that /dev/dvd did not exist, but seemed happier after I cd'd to /dev and issued the command "sudo ln -s sr0 dvd". Possibly some versions of Fedora 20 come with /dev/dvd, but mine, installed from Fedora 19 using Fedup, did not. In Fedora-21, I found vlc to be the best media player.
By the time Fedora-16 was released with firefox 7, all that was needed to achievce plugin functionality was to do "yum install gnash gnash-plugin icedtea-web" and both flash and flv content played correctly. OpenJDK's java version 1.6.0 was installed along with icedtea-web. It seems to run Java version 1.6.0_22
xboard works fine with Fedora 15 and all subsequent releases. To install, become a superuser and type "yum install xboard". xboard for Linux doesn't come with timeseal, a program designed to overcome the problem of losing time on your clock due to connection lag. Pre-compiled versions of timeseal I found on the Internet all seemed to be working but when I used them with xboard and connected to the Free Internet Chess Server (FICS), I got the message "Connection closed by ICS" and was disconnected.
The solution was to download openseal.c from here. I then changed directory to the directory containing openseal.c and issued the command "gcc openseal.c -o openseal". Everything worked perfectly when I ran xboard with the command "xboard -ics -icshost freechess.org -icshelper path-to-openseal", where path-to-openseal is the location of the compiled openseal.
For some reason, in Gnome 3, it was judged desireable to have windows maximize when dragged to the upper edge of the screen. If you don't like this, you can inhibit this behavior. The solution is for the user (not superuser) to run gconf-editor and then look at the desktop->gnome->shell->windows variables and make sure edge_tiling is not checked. Exit gconf-editor, logout, and the next time you log in you won't see edge_tiling.
Gconf-editor was not included by default in my installation so I first did "yum install gconf-editor".
By Fedora-20, the correct editor was dconf-editor, so do "sudo yum install dconf-editor", and then, as a regular user, launch dconf-editor, find org->gnome->shell->overrides and then uncheck edge-tiling. I haven't tried it, but presumably, from a command-line, you could accomplish the same by executing the command "gsettings set org.gnome.shell.overrides edge-tiling false".
Do one of two equivalent things. From a command line (not as root) issue the command "gsettings set org.gnome.shell.overrides edge-tiling false" or launch dconf-editor and in the gui click down the tree until you make sure that the edge-tiling option is not checked.
A brief article about window perserverance with GTK+ programming is here.
Prior to Fedora-16 and gcc-4.6, I simply put my shared libraries in a someplace sensible, like /usr/lib, and the system found them there. With Fedora-16, and Red Hat derived software in general, I am told, this no longer works. The reason is that Red Hat doesn't tell the linker to look in /usr/lib. So you have to tell it. There are two simple ways for the user to tell the system where to look. One is the file /etc/ld.so.conf and the other is the environmental variable LD_LIBRARY_PATH. You could edit the file /etc/ld.so.conf or issue the command "export LD_LIBRARY_PATH=/usr/lib" at login. Both these approaches will work. But if you, the user, change the shared-library search-path globally, every program on your system will be affected by that. While the mechanism exists for the user to effect these changes (only a super-user can edit /etc/ld.so.conf), that has been pointed out as a weakness (?vulnerability) in that inexperienced users can potentially affect how all programs run. If you realize as in my case that it was only the programs that I wrote and compiled which didn't know how to find my shared libraries, you realize there must be a way for the programmer to tell the program how to find the shared libraries. Actually, you want to give this information to the linker, ld, at compile time.
For a system that uses ELF for executable files, as Fedora and many others do, and if you are using GNU gcc, you can tell the linker where to find the run-time libraries by using the linker's -R option. gcc can pass the arguments to the linker using it's -Wl option. The format is "gcc -Wl,-R directory1 -Wl,-R directory2 etc..." which tells the dynamic linker to first look in directory1 and then directory2 for the executable shared libraries. Clearly either directory1 or directory2, if included, should be /usr/lib, since that is where most of the system's shared libraries are.
Having given you the reason why not to use "export LD_LIBRARY_PATH=/usr/lib" at login, I found that Totem would not know to look for libdvdcss in /usr/lib unless LD_LIBRARY_PATH was thus defined. This meant that Totem would not play DVDs, unless I set LD_LIBRARY_PATH appropriately.
You can find dozens of Internet references on how to silence the
sound-on-error feature of emacs. My problem was that the last few
times I installed emacs there was absolutely no auditory response when
errors were encountered. I finally found a reference in the EmacsWiki
which suggested that could be fixed by adding the following lines to my
".emacs" init file.
(setq visual-bell t )
(setq ring-bell-function (lambda() (call-process "play" nil 0 nil "/usr/share/sounds/freedesktop/stereo/bell.oga" )))
This is clearly quite complicated and I won't explain it all. I
won't explain usage of the emacs lisp functions call-process and
lambda(). The word "play" is the command on my system that plays
audio files. If you don't have this, install the
"sox" package with the command "sudo yum install sox" or "sudo apt-get install sox". After that
the "play" command was found in /usr/bin. I then searched through my
system for a suitable sound until I found
"/usr/share/sounds/freedesktop/stereo/bell.oga". Sounds of course, can have many other extensions as well.
The problem is that while using gedit or some other text/screen editor, you will be typing text to a certain point within a document and suddenly that point will shift. The problem is caused, on my laptop, by inadvertently touching the touchpad while typing. What you want to do is inhibit the touchpad during keyboard entry. This is exactly what is done by the program syndaemon which can, as the name implies, run as a daemon. The solution is to run (not as superuser) the very useful program gnome-session-properties, which determines which programs run during a GNOME session, and click on the "Add" button to add another program to be initiated at session startup. You want to arrange for the command "syndaemon -R -k -d" to be executed at startup.
This was not sufficient for my Dell Inspiron, which has a Alps rather than a Synaptics touchpad. The problem is that kernels prior to 3.9 do not recognize the Alps touchpad and instead consider it a generic PS/2 mouse. This problem persisted through at least versions 2.6 to 3.8.5 of the kernel, at least for my Dell Inspiron 15n.
The information here largely follows that described at HowOpenSource. The first step is to download the kernel source from www.kernel.org. Uncompress it to a location other than /usr/src/kernels/, which should be left for the system kernels. The next step is to read the README file in the top directory to learn how to create a ".config" file. Once you have generated a .config file for your kernel, simply type "make" to compile it and "make modules_install install" to install.
Download an iso-image of the distribution you want. Put the USB
device on the same computer as the image and, from the command line,
issue the command
sudo dd if=path-to-iso-image of=path-to-usb-device
as, for example,
sudo dd if=ubuntu-12.04.1-desktop-amd64.iso of=/dev/sdc
After the dd command exits, transfer the USB device to the computer you want to install that version of Linux on and arrange the boot order so that the USB device is tried first.
There are many more complicated procedures mentioned on the Internet, but the above is the not only the simplest, but is the only one that worked reliably for me.
"Yum install makeinfo" did not work for me, but "yum install texinfo" led to the appearance of /usr/bin/makeinfo.
Ubuntu and Fedora, as of March, 2013, both use grub2. Both have a command
that will update the grub2 configuration file according to defaults denoted in
/etc/defaults/grub. The Ubuntu command is "sudo update-grub" and the Fedora one
is "sudo grub2-mkconfig -o /boot/grub2/grub.cfg". Also, the Fedora command to
install grub on the hard drive's mbr is "grub2-install /dev/sda".
It is in the package dpkg-dev, but not dpkg-devel, both of which are
available in Fedora-19 repositories. Who was it that said Linux is an arcane
You will need to install several packages with the command "sudo yum install audacious audacious-plugins-amidi fluid-soundfont*". Once everything is installed, launch audacious and follow the path "File->Settings->Plugins" to ensure that the AMIDI-plugin is checked. Next, make sure that AMIDI-Plugin (MIDI Player) is highlighted and click settings. Go to the soundfount area and click on the plus (+). Use the navigator/browser that pops up to select a soundfont. Starting from the "Computer" location, selecting "/usr/share/soundfonts/default.sf2" works. I suspect choosing one of the other sf2 soundfounts in that directory also will work. I believe you can find all the packages listed above in the Fedora repositories. For additional audacious plugins, you may want to enable the rpmfusion repositories from this webpage.
It is my memory that at one time Audacious would not play a m3u playlist. I am not sure what has changed, but Audacious-3.5 under Ubuntu GNOME plays the playlist exactly as one would expect in that all the selections are listed and then played sequentially.
The first thing to note was that I finally found a true wireless printer. All those I had purchased previously had turned out to be only wireless-ready, whatever that meant. The HP Officejet-Pro 8610 is truly a wireless printer. You can connect it wirelessly to your router from its graphic CDG touchscreen. There are then two ways that I know of then to install the printer. One is to use the Gnome Desktop printer program, which was sufficient to enable wireless printing. The other was to use hplip, which also was able to install a wireless printer. On 1 July, 2015, the version number of hplip on my system was 3.15.2, which on my system complained it did not have the proper ppd file to install the hpfax device. The solution was to download and install hplip-3.15.6 from HPLIPopensource.com. During the installation, I chose the option to erase 3.15.2 and install the newer version and also gave permission for hplip-install to install other software it thought relevant. I then ran hp-setup as a non-superuser (requires having hp-gui also installed) and followed the directions for installing a wireless printer, installing both a printer and a fax. That two-step operation involved temporary use of a USB printer cable. Simple-scan, the gnome utility, could not find my wireless printer/scanner, so I installed xsane, which worked fine and was equally simple to use.
I don't know if it was necessary, but I removed gnome-screensaver. I could not figure out how to remove cinnamon-screen without messing up cinnamon desktop, so I left it. That did not prevent screen blanking with inactivity. The solution was to install xscreensaver and xscreensaver-data and then run xscreensaver-demo and select "Mode" as "Disable Screen Saver". This seems to work even as cinnamon-screen is running at the same time.
Another solution might be to run a program I called mimic-not-idle in background at startup. That very simple program is:
while true: do
xdotool keydown Shift_L keyup Shift_L
The program mimic-not-idle requires installation of package xdotool, which may not be installed by default in Ubuntu-GNOME.
With complicated programs, gcc-4.9 often would not recognize when the variable you were returning from a subroutine was a local one and you would not get a warning on compilation and the local variable was often, but not always, returned to the main routine accurately. With gcc-5, I got numerous warnings about returning pointers to local variables during compilation and my subroutines returned NULL, rather than the value of the local variable in the subroutine. When I wrote a very simple program to illustrate this behavior, both gcc-4.9 and gcc-5 gave warning during compilation and returned NULL during execution.
If you want to return a local variable from a subroutine, the way to do it properly is to declare (in the subroutine) that variable as static. In other words, declare the variable with "static char local-var;" rather than "char local-var;". The fact that you declare the variable as static does not mean the variable cannot change during the subroutine. It only means that its location does not get overwritten, so that it can reliably be returned. Probably everyone but me knew this ten years ago, but you'd be surprised how many of my poorly written subroutines worked under gcc-4.9 just as I wished they would.
The command "clear" typed in the terminal appears to work in that the screen is cleared and you no longer see the confidential information in front of you. However, while you are staring at seemingly blank terminal window, the confidential information is not gone. It has been pushed into the scrollback information and can be seen by scrolling backward. On the other hand, typing the command "reset" in the window, seems to erase everything, including the scrollback information.
For those of you not familar with it, budgie-desktop is a desktop environment designed by the developers of SolusOS. It is designed to be distribution-agnostic and work with many other distributions as well. My advice for changing the format of the date and time in the budgie panel was tested and worked for budgie-desktop installed over Lubuntu-16.04, but was not tested with SolusOS or any other distribution.
I do not know what controls the format of the time shown in the panel except that whether to display seconds or not can be controlled using gnome-teak-tool.
I don't know why, but the date format shown in the budgie panel is the same as the output from the command "date +%x", which is determined by the d_fmt entry in the LC_TIME section of the locale file located in /usr/share/i18n/locales/.
If you have superuser priviledges (either through the su or sudo commands) you can create and "install" custom locale files as follows: First, think up a name for your custom locale file. I chose en_MS. I had previously installed the english language pack so I had files in the /usr/share/i18n/locales directory like en_US and en_ZA, describing the standard USA and South Africa English formatting. I copied en_ZA to en_MS and then edited the d_fmt entry of en_MS to the format I wanted, which added the day of the week to the date %x format. To enter the correct desired format for the d_fmt entry, you have to be familiar with the Unicode table as well as the directives for formatting dates as defined for the strftime command.
To "install" the custom locale file, as superuser, I edited the /var/lib/locales/supported.d/en file to add the line, "en_MS.UTF-8 UTF-8", and issued the command "locale-gen". Alternatively, one could have simply modified the original locale file, remembering to save a copy in case you want to go back, and run locale-gen without the need to modify the file in /var/lib/locales/supported.d. Presumably if you installed the Spanish or French language packs the "en" files would be replaced with the corresponding "es" or "fr" files, and so on.
Now all that remains to do is ensure that the budgie clock applet knows the correct LC_TIME value. This can be done by editing ~/.pam_environment so that LC_TIME is defined as en_MS.UTF-8 after the next login. I don't know if everyone has a ~/.pam_environment file, or mine was created through some action I did previously, but its format is simple and easily discovered in case you have to create it "de novo".
As of 1 November, 2016, I had six different experiences using the LXQt-desktop in Lubuntu. These are described here along with some thoughts regarding Lubuntu's rather tepid flirtation with LXQt.
If you don't specifically configure google-chrome to use a webmail client for mailto, it will execute "xdg-email your_default_mailto_client" when you click on a mailto link. Your default email client can be set with the command "xdg-settings set default-url-scheme-handler mailto your_default_mailto_client", where your_default_mailto_client in the issued command is the actual name (without the full path) of the desktop file for the client you wish to use. At the end of 2016, neither xdg-email nor xdg-settings work under LXQt, but modified versions which do work can be downloaded and installed as described here.
The default display manager in Lubuntu is lightdm. The "default display manager" for LXQt is sddm. To change the display manager in Lubuntu to sddm and make sure that it is configured properly, issue the command "sudo dpkg-reconfigure sddm" and respond to the questions you will be asked, usually simply by hitting the enter key or using the up/down arrows if necessary.
There is long unsolved thread on the Antergos Community Forum discussing "Live CD cannot boot on UEFI computer". It is really a useful discussion of how to get an iso to boot using BIOS rather than UEFI. The main issue, however, is never resolved.
Not to get too philosophical, but the reason the problem is not resolved is the same reason most "unsolvable" problems remain unsolved, namely, because the correct solution is ruled out at the very beginning of the discussion. That forum states "... I will tell you right now that graphics is NOT the problem... I don't care what you read on the Internet, but graphics is NOT the issue". The issue remained unsolved because, unfortunately, I suspect graphics IS PRECISELY the issue. I had a very similar experience with my Asus ROG GL752VW laptop and resolved the problem by following the directions here. Antergos install isos allow one to modify the boot command line and what worked was to type at the end of the boot command line "modprobe.blacklist=nouveau". You can do the same with Ubuntu if you press F6.
The Antergos wiki suggests removing package xserver-xorg-video-nouveau after installing Bumblebee. The Ubuntu wiki does not. I believe that was an oversight in the Ubuntu wiki. On my Asus ROG GL752VW, which had a GeForce GTX 960M video card, it was necessary to do one of two things. One needed to remove the nouveau driver with "sudo apt-get purge drivers-xorg-video-nouveau" and then do "sudo update-initramfs -a", or alternatively, one could add "modprobe.blacklist=nouveau" to the GRUB_CMDLINE_LINUX_DEFAULT entry in /etc/default/grub and then do "grub-mkconfig -o /boot/grub/grub.cfg". If you fail to do one of those two things on my Asus laptop, reboots will fail unless you each time add "modprobe.blacklist=nouveau" to the boot command.
I did quite a few things to accomplish this. I am not sure they are all necessary. I copied two udev rules from /lib/udev/rules.d/ to /etc/udev/rules.d/. These were 61-persistent-storage-android.rules and 69-libmtp.rules. I also installed mtp-tools, libmtp9, libmtp-runtime, libmtp-common. Things did not work until finally I installed mtpfs and rebooted my computer. If I discover that any of these steps are unnecessary, I will edit the list at a later date. One probably also wants to adjust the the Auto Mount options under Edit->Preferences->Volume to suit your desires.
I believe the slow shutdown is related to the file /etc/init/sddm.conf, which states it was written based upon /etc/init/lightdm.conf. I found that the slow shutdown was speeded up by replacing this configuration file by issuing the command "sudo sddm --example-config > /etc/init/sddm.conf".
For some unknown reason, about every other kernel upgrade, Ubuntu seems to upgrade the kernel but fails to install inside the kernel the proper DKMS modules for my Nvidia GeForce 960M video card. This article by wangruohui suggested a way to install the Nvidia proprietary drivers into Ubuntu using an Nvidia driver installation file downloaded from Nvidia's website. The procedure is as follows:
1) Download from the Nvidia website the driver istallation file for the driveryou want to install and store it someplace within your account that you will remember.
2) Issue the command "sudo apt purge nvidia*". You will have to supply your password. Then issue the command "sudo apt autoremove".
3) You probably already have them installed, but to be sure, issue the command "sudo apt install build-essential dkms".
4) Blacklist the Nouveau video driver by creating a file called /etc/modprobe.d/blacklist-nouveau.conf which contains the two lines
options nouveau modeset=0
This step may be overkill since I believe the nvidia installer inserts a similar blacklisting file which is adequate.
5) The ultimate step is best done in a non-graphical environment. To accomplish this, reboot your computer and from the grub boot menu, using the up and down arrow keys on your keyboard, select the kernel for which you want to install the Nvidia drivers. Instead of just hitting the <enter> key as you would for a normal boot, hit "e <enter>", which will give you the ability to modify the boot commands. Again, using the up, down and right, left arrow keys, manuever to the end of the line that begins with "linux" and add to that line the phrase (minus the quotation marks) " systemd.unit=multi-user.target". After you then press control-x, you will be brought, not to a graphical login screen most people normally prefer, but to a login prompt for a non-graphical shell. Enter your user name and then password when prompted.
6) Change directory to the directory in which the Nvidia install file is and issue the command "sudo chmod +x <nvidia-install-file>", where <nvidia-install-file> is the name of the Nvidia installation file. Then issue the command "./<nvidia-install-file> --dkms". If everything goes smoothly, you should be done and the kernel should have the correct DKMS modules.
I am not sure how reliable the above method is. It worked at least once for me, but failed more times than that. In retrospect, I believe the failures may have been due to my having installed Ubuntu with UEFI and not following the several extra steps that may entail for installing the proprietary Nvidia driver. When I reinstalled Ubuntu using Legacy BIOS rather than UEFI, Ubuntu itself was able to install the proprietary driver properly from their PPA, without using the Nvidia installer file I downloaded from the Nvidia website.