bkil vs. programming

Unity is full of bugs.We all know it. Usually the window manager fails and decorations are gone. Sometimes all windows are stacked on top of each other at a corner. It's so bad that I had to write a script for killing and restarting the effected processes easily from a shell to resume working. All of this usually occurs when doing twisted deeds like opening a web page, however it can sometimes be triggered by toggling fullscreen or starting an application. It is always unexpected and unpredictable. If you know what to do, you don't loose any work and you don't even need to close any windows. So it's only a cosmetic issue at this level, but still not very professional. Interestingly, I have encountered this mostly in 2012-2014, and they have much reduced the occurrence rate from about 2015. Nonetheless, I don't use Unity on any of my new installs since about 2013 because of this. If you are fortunate enough to never have used this wonderful peace of engineering, ...

A friend called for help when one of his computers failed a distribution upgrade. The upgrade was started from 12.04 LTS via the GUI. I'm not sure which version he had previously, but the standard update procedure stopped midway. The upgrade could not be resumed, so manual intervention was needed. I'm not sure whether the issue was caused by a bit error in memory, an out of space issue or by something else. Unfortunately, I don't have the error messages at hand. The solution boiled down to doing the following tedious steps: apt-get update apt-get dist-upgrade do-release-upgrade dpkg --configure -a apt-get -f install mcedit /var/lib/dpkg/status # delete section which is complained about mktexlsr # note down errors updmap-sys --synthwithtrees # note down errors mcedit /etc/texmf/... # remove invalid map file lines updmap-sys apt-get install ubuntu-desktop

The described method should work on even simple desktop environments. If I don't already have an xorg.conf for editing, I first generate it by  Xorg -config xorg.conf.new . To make the screen easier to read, you need to  scale DPI by setting Displaysize in the respective "Monitor" section of xorg.conf proportionally larger than it physically is. A native driver outputs the original image size in Xorg.0.log. You need to type in the real size values times the magnification factor. So if the real active area of your display is 200mm wide and 100mm high and want 1.5x larger text, you insert  Option DisplaySize 300 150 . Unfortunately, not all applications honor this setting. You need to increase the default zoom by hand in  Chromium . You need to update the hexadecimal "LogPixels" dpi setting in ~/.wine/system.reg for  Wine . Otherwise if you are using Gnome, you could also try to increase the text scaling factor with the Gnome Tweak Tool, Universal...

It worked easily with the VESA driver, however the legacy mode tables don't have any of today's fancy aspect ratios. OpenChrome, the default driver, just gave a blank screen. Reviewing Xorg.log revealed an abort by signal 11, segmentation fault (segfault). Let me share the process of fixing it. I went on to generate a new xorg.conf for editing by Xorg -config xorg.conf.new . I then proceeded to add as much fail-safe options as possible from the driver documentation : Section "Device" Option "ModeSwitchMethod" "legacy" # or blank & segfault Option "SWCursor" "true" # unsure Option "EnableAGPDMA" "True" # unsure Option "NoAccel" # or starts to lag after some time Identifier "IGP" Driver "openchrome" BusID "PCI:1:0:0" EndSection Section "Module" # unsure Disable ...

Actually it is not an option for Ivy Bridge, it is a must! In my opinion, a patch would have been in order to the LTS kernel. https://wiki.ubuntu.com/Kernel/LTSEnablementStack Some background: linuxquestions.org: [SOLVED] kernel 3.2.x causes system freeze on Intel Ivy Bridge platform(e.g. ThinkPad T430)? Launchpad: [IVB]12.04 64 bit System freezes (mouse, keyboard) ...

A default clean install usually doesn't fit me. However, I've installed Ubuntu LTS just like that on this machine when both were new. It has a small but fast SSD. It has been working flawlessly until now. I've recently reconsidered that I could use a bit more space. From experience, I never had a need for swap, as I'm using zram . So I've decided to simply delete the swap partition. Of course, solving it simply was only my dream. Technically, you need to delete the swap partition, optionally move middle partitions to the end, expand your root file system and be done with it. I've first made whole disk backups. I've booted off a flash drive containing Ubuntu 12.10. Deleting the partition with GParted was a breeze, as well as marking the rest of the needed operations, move and resize. But there was a catch: it bailed out with a cryptic message halfway. (I think it was "GNU Parted cannot resize this partition to this size. We're working on it!...

While it may sound like utter nonsense at first, on second thought maybe it really is: cron.standard: please provide configuration facility to avoid given filesystems Someone should really be thinking more about a serious reminder system. I've put together an iotop oneliner that logs disk actions with timestamps which pointed me to anacron. Daily mlocate updating was easy to reproduce and fine tune: simply add your HDD mount points to tho PRUNEPATHS variable of /etc/updatedb.conf . On the other hand, it took a few more attempts and many days in total to track down what causes the HDDs to still start up. When trying to further examine the issue by hand, /etc/cron.daily/standard didn't start them up on first look, perhaps because of caching. However, today after randomly testing things again, it finally did, which took me to adding CHECK_LOSTFOUND=no to /etc/default/cron . It's a pity though, that I'll have to use an alarm clock from now on.

Using Lubuntu 12.04 for connections to icewm on Ubuntu 12.04. The exact configuration involves hosting a pulse sound server on each thin client , and configuring applications on the remote desktop to pipe back sound to the respective thin client. A trusted environment is assumed here, so please refer to the PulseAudio Network documentation on freedesktop.org and various general security guidelines (firewalls, tunnels, IPsec, VPN, etc.) if you're planning anything serious. Thin client setup: Purge any left over configuration: rm -Ri ~/.pulse Install PulseAudio: sudo apt-get install pulseaudio dbus-x11 Enable local sound access (not sure if needed): sudo adduser $USER pulse; sudo adduser $USER pulse-access then log out and log in again Give local and network access to the sound: cp -t ~/.pulse/ /etc/pulse/default.pa # APPIP="type application server IP address here" echo "load-module module-native-protocol-tcp auth-ip-acl=127.0.0.1/32;$APPIP/32" >...

It works out of the box with a plain wvdial after a small adjustment (need to erase the +FCLASS=0 part). It is detected as the following device (after the automatic mode switch): ID 12d1:1506 Huawei Technologies Co., Ltd. E398 LTE/UMTS/GSM Modem/Networkcard For the record, I paste the wvdial.conf configured for T-Mobile in Hungary: [Dialer Defaults] Init1 = ATZ Init2 = ATQ0 V1 E1 S0=0 &C1 &D2 +FCLASS=0 Init3 = AT+CGDCONT=1,"IP","internet" Modem = /dev/ttyUSB0 Username = wap Password = wap Modem Type = Analog Modem Baud = 9600 New PPPD = yes ISDN = 0 Phone = *99# Stupid Mode = 1 Most of the settings are not crucial, but some of them depend on your carrier, like "Init3", "Username" and "Password", while "Modem" depends on your device.

I had to revert from compressed BTRFS to Ext4 on my tiny netbook partition, as it wasn't playing nice. That's a pity, as Ubuntu is highly compressible and compression didn't slow it down. The system occupied less than half of the space and reported such, however when I was starting to fill up the space, it complained of insufficient space. Probably because of metadata allocation. As I didn't want to reinstall the system, I went the more costly route: * I've rebuilt the partition in an image on ext4, * copied over the data * copied the initrd image from another computer of mine with the exact same system, both were updated at the same time - otherwise it couldn't read the new kind of partition * adjusted grub settings * reinstalled grub (was extra painful when I attempted to do that inside an image..).

Hm, it looks like this post has stuck in my drafts for some years now... Compositing produces a considerable amount of flicker and the display is obstructed by random image parts. dmesg is also full of page flip errors. Solution: cat >~/.drirc <<EOF <driconf> <device screen="0" driver="dri2"> <application name="Default"> <option name="vblank_mode" value="0" /> </application> </device> </driconf> EOF service gdm restart via https://bugs.freedesktop.org/show_bug.cgi?id=30654#c10 and http://pastebin.com/3gr5VbHY Also needed to append the following to the kernel command line, or else I got a lot of squashfs block read errors: acpi=off noapic ide=nodma all_generic_ide pci=nommconf

If you connect this modem to a machine running Ubuntu, it mounts and opens the virtual driver disk. If you unmount the partition, usb_modeswitch automatically kicks in and switches the device from CD-ROM emulation to modem mode. Unfortunately, Network Manager would not connect regardless of configuration. However, after some trial and error, wvdial was able to establish connection and start transferring data. After reducing the unknowns, I've devised a small script which waits until the drive gets automatically mounted, unmounts the device, waits for settling and then establishes a connection with wvdial. This script was hooked up to a specific device addition udev rule to make it run automagically. As the devised udev rule did not narrow down the event good enough, actually two such invocations are done for each insertion, so a bit of an ugly hacking was involved to implement mutual exclusion.

The problem is triggered by me rapidly changing capitalization via shift while typing. I use the two shift keys symmetrically, but it always seems to involve the left shift. It lasts from about 10 to 30 seconds on average, but today it ceased to resolve by itself. So I started to research the issue (IN CAPS), and thankfully found something that seemed to work: CTRL+FN-F1 to switch to a console, then back to Xorg with CTRL+FN-F7, and pressing the left shift right away. Maybe it is indeed related to TVTime usage, I need to concentrate more on the issue. It is said to be caused by automatic periodical screen saver inhibition via stuffing control and shift keypresses using XTest. Ubuntu Bug #588473: shift key get stuck randomly