I had some trouble using my usb printer.
Starting cups with "systemctl start cups" was working as expected. The page "http://localhost:631/" was presenting usefull informations (also listing the printer) but when I added a job "Waiting for printer to become available." was displayed for minutes over minutes.
A search on the web directed me to a thread with the solution inside. Following are the needed steps:
#list connected usb devices to fetch vendor id and product it
lsusb
#create rules for udev
vim /etc/udev/rules.d/10-usbprinter.rules
#add following entry, replace vendor id and product id if needed
ATTR{idVendor}=="04e8", ATTR{idProduct}=="3321", MODE:="0660", GROUP:="lp"
#reload udev
udevadm control --reload-rules
#replugin the printer
So you just want to start a java application and it does not work.
First idea "lets start it from within a shell to see something", so you do.
/usr/bin/java: line 2: /usr/lib/jvm/default/bin/java: Too many levels of symbolic links
/usr/bin/java: line 2: exec: /usr/lib/jvm/default/bin/java: cannot execute: Too many levels of symbolic links
If something like above is your output, change into root mode and fix this issue.
sudo su
cd /usr/lib/jvm
ls -halt
# something like "default -> default" should be listed
rm -fr default
# if you have installed java-7-openjdk, what should be listed by the ls above
ln -s java-7-openjdk default
And thats it, enjoy your working java applications again.
I found a great article on phoronix called "The Tour Of Linus Torvalds' Home Office". Inside are a few videos. Just take a few minutes and watch them. Their are two cool things to learn. First
A treadmill desk for regular browsing in the web. Second
My office is looking still normal (not that much pc's, cables etc. :-D).
The SUSE method for live kernel patching, kGraft, is being proposed for possible inclusion into the linux-next branch in hopes it will be merged into an upcoming Linux kernel release cycle.
The kGraft patches for live kernel patching continue to be revised and reviewed but at the same time there's still Kpatch that's been developed by Red Hat with some different design principles for updating the running kernel in real-time. To date there's been no general consensus on the superior solution nor any agreement to try to merge Kpatch and kGraft.
On Wednesday, Jiri Slaby of SUSE proposed in a new mailing list thread to kernel developers that kGraft be added to the -next tree for the kernel.
While the proposal was made, there was some immediate resistance since there's still no collaboration between kGraft and Kpatch. Additionally, some developers don't like that kthread management is being further complicated by the current kGraft patches. We'll keep monitoring the Kpatch vs. kGraft patches and will provide updates when there's a consensus on the matter.