I am not a Linux expert. 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.
A brief article about this is here.
A brief article about this 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".
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 worked under LXQt, but more recent versions have.
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.
Modification to above answer as of 23-may-2018: Do not install bumblebee under any circumstance. Despite many reports of how well it works, it does not.
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".
I find it hard to image a better, easier to use torrent client than QBittorrent. It handles both torrent and magnet links similarly with ease, it displays download progress graphically during the download, it explicitly states how many pieces the torrent has been subdivided into, and displays in real time, how many have already been downloaded. It also has a convenient panel mode, where it works without occupying screen space aside from the small panel icon. A click of the panel icon raises the app to the screen, where you can check progress, and closing the window returns it to the panel. As far as I could discern, neither Deluge, Transmission, nor KTorrent has all these features.
pdftk, along with its other uses, always had a convenient way of superimposing two images. The command to do this was "pdftk image1 backgound image2 output combinedimage". Allegedly this also could be done using the composite feature of either ImageMagick or GraphicsMagick, but I have never gotten either of these to work consistently for me. In 2016, there was talk of pdftk disappearing totally because of the discontinuation of libgcj. However, it was rescued with the development of the package pdftk-java. After installation of both pdftk and pdftk-java, the above pdftk command worked perfectly, just as previously.
Sure! We hope this information is helpful!
Probably, if you are clever enough. But there is one important difference when dealing with long lines between the two subroutines that the alert programmer needs to keep in mind.
When repetitively invoking getline to retrieve consecutive lines, it will repetitively assign each line, along with its penultimate LF character and a terminal NULL character to the designated pointer, and will always assign enough memory space for it. Each subsequent invocation og getline will retrieve the next line.
When repetitively invoking fgets, the behaviour is different. To prevent buffer overflow, the second parameter of fgets tells it how much space to allocate for the line you are reading. If that parameter say, is N, and the line read is longer than N - 1 bytes, fgets fills the buffer designated by its first parameter with N-1 bytes followed by the NULL character. So clearly, like with getline, memory allocation overflow is not a problem. What can be troubling with fgets, is that the next time it is invoked after reading a long line, it fills the allocated buffer, not with the next line, but with the reminder of the line that had its first N -1 bytes already read.
If the possibility exits that your program might encounter a line longer than any reasonably-sized buffer space you might assign to it, the difficulties of accounting for fgets behaviour may make getline a better choice of subroutine for reading the lines.
Installing texlive the recommended way has always been painful. For Linux users, the recommended way is to find and download the latest version of install-tl.zip, uncompress it, and then change directory to the subdirectory the decompression unpacked and type "./install-tl". A few years ago, ./install-tl took between two and four hours to run. If it crashed in the middle, possibly because of a mistake you made, it would not resume, it had to start all over again. I do not know what has changed, but recently, ./install-tl has been taking more than 12 hours to complete, which is totally ridiculous.
Let us say that you have installed texlive, but for some reason need to reinstall it, either on the same computer or on a new computer. It seems non-sensible to invest another > 12 hours on installation and I have an alternative solution. The entire texlive distribution is contained within the subdirectory, /usr/local/texlive. Ever since the instructional day many years ago when I permanently lost everything on my computer, I have gotten into the habit of doing regular backups of my computer data. I hope you have the same habit. So I, and presumably you, already have a copy of texlive. All you have to do is transfer, by any means, your copy of /usr/local/texlive to the computer where it is lacking. The rsync command quickly accomplishes this, as would "cp -r" to and from a USB memory stick. This is probably all you need, but if you really want the latest version, you can issue the texlive command "tlmgr update --self && tlmgr update --all" which likely wil take only a few minutes to complete. I suspect tlmgr cannot update between years. I think it will update only to the latest version for the original year, it will not update a 2018 version to the latest version for 2019, even if that version is already available.