Sunday, December 21, 2014

Medieval Cyrllic (aka "Old Church Slavonic", "Old Bulgarian") fonts in LibreOffice

The only way I've seen this work is to take the TTF fonts created for Microsoft Word and adapt them. LibreOffice appears to require not only the TTF files, but also the associated AFM and PFB files. These cannot be created perfectly, but with font-forge, it's possible to produce versions of AFM and PFB which are reasonably close.
  1. Copy the TTF files into /home/foo/.fonts
  2. Open one of the TTF's in Font Forge
  3. Select "Generate Font", using the PFB option. An AFM will automatically be created
  4. Make sure all three versions of the file, TTF, AFM, and PFB files are in the /home/foo/.fonts
  5. Restart X
  6. Open LibreOffice -- the font should be in the font list
  7. Profit

locale issue

Full implementation of these fonts requires multi-byte encoding -- there are more than 256 glyphs available. This means of course dealing with locales. I don't like to use UTF-8 because, when encoding, it's inefficient. The best possible solution for a locale with these fonts appears to be "C". I checked my locale with the following (reports according to information in /etc/profile.d/locale.sh ). PAM (which I hate), apparently however stats /etc/environment. Plenty more can be read here.

$ locale
LANG=C
LC_CTYPE="C"
LC_NUMERIC="C"
LC_TIME="C"
LC_COLLATE="C"
LC_MONETARY="C"
LC_MESSAGES="C"
LC_PAPER="C"
LC_NAME="C"
LC_ADDRESS="C"
LC_TELEPHONE="C"
LC_MEASUREMENT="C"
LC_IDENTIFICATION="C"
LC_ALL=
Or, one by one...
$ echo $LANG
C
$ echo $LC_CTYPE
C
The LC_ALL variable is one I've wanted to investigate more fully. For example, I was reading on Stack Exchange that LC_ALL can override the settings of the other variable settings.

manually updating locale variables
There are several programs which update locale settings. I prefer to hand edit configurations. The primary Arch file to customize these settings is /etc/locale.conf, which generally must be created. Other distros use /etc/default/locale. Alternatively, suppose I just wanted to set one or two of these variables? I'd likely export them to the kernel directly from ~.bashrc (as I do my TexLive path). Using LC_ALL as an example, and assuming a more intelligent user...
$ nano .bashrc
export LC_ALL="C"
Masochists or less intelligent users might want to use...
$ nano .bashrc
export LC_ALL="en_US.UTF-8"

Monday, December 15, 2014

[solved] "disabled" printers in cups, "rendering complete" PT II

With an HP printer, if you click "print", but have left anything disconnected... you're going to get pissed. CUPS should simply print the job once the printer cable is reconnected. But instead of helpfully printing, CUPS is much more likely to invoke TWO horrible-to-undo factors... simultaneously.
  1. CUPS invokes a "disabled" status for the printer and does not reveal this. When you reconnect the printer, the document does not print, but the icon will only (unhelpfully) indicate "rendering complete" with a green "pause" status for the printer.
  2. You'll think, "I just need to delete the document and try again now that the cable is connected". YES, you'll have to delete the document from the queue or the problem can't be fixed. (Use lpstat -o to get the job number and then cancel [job number] to eliminate it from the queue). NO, the problem is not yet fixed, and if you try to print again, you need to delete those attempts as well. Delete all print jobs and re-enable the printer using one of the two options below.

option 1 (5 minutes)

If a person is extremely fortunate, CUPS was installed with CUPS-specific permissions and group categories aligned. There are three layers to these, the first layer being correct permissions for loopback/localhost. Users can check this by attempting to access the CUPS browser-based administration page, running out of port 631, ie, http://localhost:631/. If that works, attempt to clear the disabled printer status as follows.
  • Find your paused printer and click on it.
  • Under the "maintenance" options for that printer, click on "resume". This is what re-enables the printer.
  • Authenticate to activate changes. Typically the user is "root" and then root's password.
At this stage, printing should work again. If authentication failed, either skip to Option 2 below, or take the time* to untangle the group/member permissions (these are the second and third layers of CUPS configuration -- see "cups printer permissions" below) and then go back to the CUPS administration page, once complete.

*an entire afternoon

option 2 (15 minutes)

Remove and reinstall your printer, which hopefully is not an HP. Find your USB port for the printer (lsusb) and then, eg...
# lpadmin -x Officejet_Pro_8500_A910 $ hp-setup -i --auto 001:004
If not an HP printer, then you will likely never have this "disabled" printer problem, but if you do have to reinstall a non HP printer, then the easiest way I've found is, eg...
# lpadmin -x Brother # lpadmin -p Brother -E -v usb:/dev/usb/lp0 -m brother.ppd

summary

  1. Cancel all print jobs. The fix might work without this, but it's unlikely. Find print job numbers using # lpstat -o and then # cancel [print number], one by one. You will see no change yet in the "rendering complete" status, but print jobs need to be cleared for the "rendering complete" status to subsequently be cleared.
  2. "resume" the printer in the CUPS browser interface (if available), or remove and reinstall the printer using the terminal. Either way, "rendering complete" should disappear at this step.
  3. Verify that CUPS changes have succeeded by attempting to print or, in a terminal, type "lpstat -p": the printer name should be there and have a status of "idle".

cups printer permissions (in progress)

Users will often only learn their CUPS configuration is misaligned when CUPS authentication fails at the final step of a long process that otherwise seemed to be successful. Any or all of the layers below can be the cause of the problem. Layer 1: loopback/localhost Sadly, CUPS is a network, not a standalone, print server. This means one must disable a percentage of their loopback protections if they want to use CUPS and the CUPS administration page. Outrageous, but true. Loopback is not dealt with on this page. Layer 2: groups
Layer 3: permissions Layer 4: /etc/cups/cups.conf (not always) Most times, nothing needs to be done to this file. When it does, the most typical adjustment involves.

x crashes, video crashes, mouse crashes, kernel panics

A friend has an old HP box that was running Arch. He was experiencing system lock-ups using Wikimapia in concert with Google Maps in a browser. These programs paint a lot of polygons when scrolling and the kernel panics seemed to show memory leaks or other unauthorized writing to the drive. The failures were to varieties: 1) lockups, and 2) exit to terminal with kernel panics. Some possibilities:
  1. xorg setting for video card
  2. xorg setting for mouse
  3. browser leaks with multiple many-polygon pages open (maps)
  4. the old Intel 82G33/G31 integrated controller card being overwhelmed
  5. ?

logs

We're looking for two main log types: Xorg crashes, and Kernel crashes. Xorg is the easiest -- hasn't changed much over the years. We can still find Xorg logs in /var/log/Xorg.0.log.old and copy to our user directory to read them in any text editor. Failures stand out, and there is usually enough information to start modifying one's xorg.conf file to fix whatever's wrong. In the case of my friend, it appears there was nothing failing and writing to Xorg.log, at least on a first-look.

Kernel crashes. During crashes, writing can be inconsistent; we can't be certain we'll have information. Additionally, journald crash logs are written in binary and, further, compressed, and so require the journalctl client to read whatever's in there (and of course "whatever's in there" can become corrupted during a panic). So it's 50-50 if we can see anything in these logs. IMO, verifying a corruption-free log is the place to begin.
# journalctl --verify
...in the case of my friend's logs, this revealed a plethora of corruptions at times I could not decipher, but may have corresponded to the panics.

Given all of this, it appeared the best thing to do was get some text readable log information.
# nano /etc/systemd/journald.conf
Storage=none
ForwardToSyslog=yes
...next crash, I should be able to see if there's anything out there in human readable text. Meanwhile...
# journalctl -b
... and look for errata.

video card

On the video card front, his old Intel 82G33/G31 is onboard and shares memory (fatal), but also appears to have some VRAM. No GPU.

Friday, December 5, 2014

[solved] (kinda) magical cups disappearance

Edit: I eventually rebooted after the CUPS reinstall and ran
# systemctl list-unit-files |grep cups
This time, and I'm not sure why, CUPS units appeared. One unit was org.cups.cupsd.service. Of course! A more complicated name for the service... how could I not guess this? So now, instead of the simpler...
# systemctl start cups
...we now have the impossible to remember...
# systemctl start org.cups.cupsd.service
...thanks a million, CUPS team. More keystrokes and slips of paper, perhaps that's the Linux legacy. At least this one is solved for now.

Edit 2: Evince not printing. Everything appears fine, but only blank pages result. Check it with a direct print. First command to get a list of the printer names, second command to directly print the file. In this case, suppose the name of the printer is "Foo", and the file to be printed is "somefile.pdf"...
# lpstat -p
# lp -d Foo somefile.pdf
If it prints this way, but not in Evince, it's got the f*cking bug.


I recently (12/5/2014) updated Arch and CUPS disappeared. It wasn't even there in the list of units. I ran...
# systemctl list-unit-files |grep -i cups
org.cups.cupsd.path
...which is just the CUPS scheduler, so no printers appeared. (The reason to use list-unit-files is it reveals any units, enabled or disabled). A check with
# pacman -Ss cups
showed cups was already installed. I reinstalled it, but still no appearance in the systemd list. Hmmm...

startup service

Then I recalled I'd made a custom startup service to remove the realtek module so it wouldn't continue sending errors. Could this be the problem?
# cat /etc/systemd/system/foostartup.service
[Unit]
Description=startup actions

[Service]
Type=oneshot
RemainAfterExit=no
ExecStart=/usr/bin/sleep 10s
ExecStart=/usr/bin/rmmod ums_realtek

[Install]
WantedBy=multi-user.target
But no, there was nothing in there which would effect CUPS.

Saturday, November 29, 2014

[solved] arch - update and java

Following Oracle's purchase of Java (2010), Java users can't be certain when Oracle attorneys or developers might make users' lives uncomfortable. If one wants Java functionality however, Oracle can't be avoided entirely. I am not a lawyer, but Oracle's open-source version of Java, OpenJDK, may be the most legally prudent Java option. That said, not every application plays nice with OpenJDK, of course, or Oracle wouldn't be able to profit from licensing its more user-friendly proprietary versions of Java.

What has the above meant to me operationally? When upgrading Arch with OpenJDK onboard, I've sometimes experienced conflicts which required a solution of, 1) uninstalling Java, 2) running the Arch update(s), and, 3) reinstalling or upgrading to the latest OpenJDK.

Arch update Java conflicts may look something like these (during pacman -Syu):
error: failed to commit transaction (conflicting files)
java-runtime-common: /usr/bin/java exists in filesystem
java-runtime-common: /usr/bin/keytool exists in filesystem
java-runtime-common: /usr/bin/orbd exists in filesystem
java-runtime-common: /usr/bin/pack200 exists in filesystem
java-runtime-common: /usr/bin/policytool exists in filesystem
java-runtime-common: /usr/bin/rmid exists in filesystem
java-runtime-common: /usr/bin/rmiregistry exists in filesystem
java-runtime-common: /usr/bin/servertool exists in filesystem
java-runtime-common: /usr/bin/tnameserv exists in filesystem
java-runtime-common: /usr/bin/unpack200 exists in filesystem
java-runtime-common: /usr/lib/jvm/default exists in filesystem
java-runtime-common: /usr/lib/jvm/default-runtime exists in filesystem
Errors occurred, no packages were upgraded.

The shortest path appears to be removing "java-common". Not so fast: OpenJDK requires java-common as a dependency; pacman typically will not allow its removal. The solution is to remove OpenJDK (at this writing version 7), update the system, and then reinstall OpenJDK:
# pacman -Rns jre7-openjdk
# pacman -Syu
# pacman -S jre7-openjdk

Applications (eg, geogebra, icedtea-web) that bark at this removal may also have to be removed prior to the Arch update, and then reinstalled (after jre).

location in system

$ ls -an /usr/bin/java
/usr/bin/java -> /usr/lib/jvm/default-runtime/bin/java

$ locate /bin/java
locate /bin/java
/usr/bin/java
/usr/bin/javaws
/usr/lib/jvm/java-8-openjdk/jre/bin/java
/usr/lib/libreoffice/ure/bin/javaldx
/usr/share/icedtea-web/bin/javaws

$ ls /usr/lib/mozilla/plugins
IcedTeaPlugin.so libflashplayer.so [missing java-plugin libnpjp2.so]

# find -name libjava.so
/usr/lib/jvm/java-8-openjdk/jre/lib/amd64/libjava.so
You can't find libnpjp2.so because you don't have normal java installed. Typically, you make a soft link between libnpjp2.so and the mozilla plugin directory. But in this case WITH OPEN JDK, our java soft link for mozilla (when we need it) is the icedtea plugin so we're actually set. All you have to do is go into "Add-Ons" in your browser and enable/disable it.


LibreOffice

After an Arch OpenJDK update, the LibreOffice portion sometimes still will notice you...
Optional dependencies for libreoffice-still
java-runtime: adds java support
java-environment: required by extension-wiki-publisher and extension-nlpsolver
...telling you for sure LibreOffice didn't detect OpenJDK. I opened LibreOffice -->Tools --> Options --> Advanced.



I selected the radio button for the Oracle option and then "OK". These actions seemed to activate Java.

Blackboard and Pipelight apps

Only Firefox has the stuff needed to process Moonlight, instead of Silverlight. Software must be installed that allows geolocating and so forth. These can be turned on and off by creating a softlink.

On the Blackboard account, also use Firefox (JRE).
ln -s /usr/lib/pipelight/libpipelight-silverlight5.1.so /usr/lib/mozilla/plugins/libpipelight-silverlight5.1.so

Sunday, November 16, 2014

[solved] xbacklight -- try to adjust your backlight to preserve it

I recently had an LCD display burn-out its backlight element and had the following consideration:
  • $60 (1.5 hrs) Replace screen and backlight combo
  • $12 (5 hrs) Replace backlight only
On my current schedule,I did the $60 but, since I was doing it for the backlight, I wanted to be sure I adjusted the backlight to a low setting going forward. The commands I'm aware of are
  • xgamma
  • xbacklight
  • xrandr
I've regularly used xgamma and xrandr in the past, but was never sure what I was adjusting -- the lcd, the backlight, or some blend. For example, with the new display, even when I set the gamma very low, eg
$ xgamma -gamma 0.1
...I would see what appeared to be a full-intensity backlight combined with a low contrast LCD setting. A similar problem appeared if I used xrandr, eg
$ xrandr --output LVDS --brightness 0.2
... which would give a bright haze (the backlight?) overlaying a barely visible display underneath. I wanted to definitively adjust the backlight so I could begin to untangle what was what. "Xbacklight" seemed the most logical choice. Murphy arrived immediately.

xbacklight problem

$ xbacklight
No outputs have backlight property
Checking the arch wiki on backlight control, we get the mysterious information:
All methods are exposed to the user through /sys/class/backlight and xrandr/xbacklight can choose one method to control brightness. It is still not very clear which one xbacklight prefers by default.
There is a note about how to fix the error message if one is using Debian, but of course Arch is not Debian. I did find the following directory however:
/sys/class/backlight/acpi_video0/
Based on what I read here from greengeek, I did the following with a nice dimming effect (required root)
# echo 1 > /sys/class/backlight/acpi_video0/brightness
Echoing a value obviously doesn't use an application (eg., xbacklight), but it appears to set the backlight effectively, and uses settings between 0 and 2.

final command combination

With the new LCD and backlight, a crisp setting appears to be
$ xgamma -gamma 0.4
# echo 0 > /sys/class/backlight/acpi_video0/brightness

xrandr and external displays or projectors

A person can get a printout of possible display settings for an external device attached to their desktop or laptop by simply typing $ xrandr. Using these, a person can set exact refresh settings for secondary displays, however, I haven't found backlight control of these displays. Still, xrandr is great to simply turn the display/projector on and off (with the proper screen resolution). Note the screen resolution of your laptop (eg. 1200x800)and send it to a projector...
$ xrandr --output VGA-0 --mode "1280x800" [initiates external video]
$ xrandr --output VGA-0 --off [terminates external video]

If I don't put the quotation marks around 1280x800, xrandr will bark at me that the resolution isn't found (most projectors don't natively have it).

Sunday, August 24, 2014

Brother HL-2275DW

Links: Arch instructions :: Brother Network Guide (PDF)
As always, handy commands:
LIST OF PENDING PRINT JOBS
# lpstat -o
CANCEL ALL PENDING PRINT JOBS
# cancel -a
Cancel -a sometimes doesn't work. In that case, one must individually cancel each named printjob, eg "cancel Brother-001", "cancel Brother-002", etc.

USB connection (10 minutes)

Connect a known-good printer using a USB cable. Turn on the printer. Next, go to this Arch page which lists the connection steps. Here is an abbreviated version, but note there are a few problems in 2015:
  1. I have CUPS but a2ps is also needed: #pacman -S a2ps.
  2. Reboot (or use systemctlto make sure CUPS daemon loads and is running. If users have good knowledge of systemctl command, check CUPS with systemclt or simply run any CUPS command and see what happens, eg...
    $ lpstat -p
    lpstat: Bad file descriptor
    ...indicates CUPS is not yet running.
    # systemctl list-unit-files |grep -i "cups"
    org.cups.cupsd.path enabled
    cups-browsed.service disabled
    org.cups.cups-lpd@.service static
    org.cups.cupsd.service enabled
    org.cups.cups-lpd.socket disabled
    org.cups.cupsd.socket enabled
    The lpd-socket is disabled, because I'm not on a network. It's not necessary. For normal stand-alone usage in this kludge, I only need cupsd.service. So I disable any lpd (network) services, browsed services, etc.
    # systemctl disable org.cups.cups-lpd@service
    # systemctl start org.cups.cupsd.service
    Now I can browse to the CUPS administration page (http://localhost:631). CUPS is running.
  3. $ yaourt brother-hl2270dw
  4. Navigate to CUPS: http://localhost:631.
  5. Click the Administration tab then click the Add Printer button. The username is "root" and the password is the root password of the user's computer. Follow the steps.

USB connection [fail version (4 hrs)]

I went to openprinting.org, typically helpful with Brothers, but this time filled with gobbledy gook and an empty PPD. The order of installation was supposed to be the printer and then the cupswrapper.
  1. Downloaded and unpacked the DEB's for the cupswrapper and the lprdriver. This was weird, since no "cupswrapper" is typically needed for a Brother, just a PPD.
  2. Found the PPD in the kludge of unpacked folders, rooted up and copied the PPD as /usr/share/cups/model/brother.ppd, then chowned it to 0:0 and chmodded it to 755
  3. # lpadmin -p Brother -E -v usb:/dev/usb/lp0 -m brother.ppd
  4. restarted CUPS and attempted to print. At first it looked promising, but then it exited, unable to locate the file, "/usr/lib/cups/filter/brother_lpdwrapper_BrGenML1". That file was in the unpacked kludge and I copied it to /usr/lib/cups/filter/, and chowned it to 0:0. Restarted CUPS and tried another print but received "waiting for printer to become available" status message.
  5. Verified the "Brother" entry generated during installation in /etc/cups/printers.conf looked normal. No obvious problems.
  6. Forced a testprint... cat /etc/printcap |lp -d Brother. Not working, so lpadmin -x Brother

WiFi connection

Unattempted

Friday, August 8, 2014

[solved] yet another CUPS related failure -- interference with xsane.

We've all encountered the problem with Xsane where it fails to detect a properly attached USB scanner. Many times this is due to an error in permissions around the scanning group -- the scanner will only be detected as root. Here's a variant: a detection fail in both root or user modes due to CUPS. In my system, if CUPS is running, the scanner cannot be detected in user or root. No informative error message explaining this will be displayed.

There are many ways to determine if the CUPS daemon is running, most involving root. The fastest way is to remember "I just used the printer", but another way from user-space is:
$ lpstat
lpstat: Bad file descriptor
lpstat returns this message when CUPS is not running, and will return a blank line if CUPS is running.

Depending on one's distribution, disable CUPS with...
# systemctl stop cups
Once CUPS is deactivated, Xsane should again detect the scanner in user mode if permissions are properly set.

CUPS accesses stand-alone boxes through loopback privileges into localhost and the CUPS daemon runs under root. Looping-back has associated permission locks which apparently block USB detection, not sure. Anyway, turn CUPS off and scan normally.


Editorial: Since the majority of Linux users are stand-alone users with non-network printers, I consider it a conceit of CUPS developers not to have created a simple stand-alone variant which doesn't need the spaghetti or security issues of loopback privileges. When one considers that the CUPS code is 20 years mature, that its PPD's are actively updated by others, and that only a few lines of code are likely necessary to access USB ports, it becomes annoying. Currently, many CUPS installations require more manipulation of groups than most Linux users possess. More importantly are the security liabilities created by loopback access. Few advanced users, and probably no average users, possess the significant PAM, LDAP, port scrambling, ipchains, etc, knowledge to be certain they've closed less obvious loopback security holes. By the normal desire of Linux users to print, and the lack of any direct stand-alone solution, it's possible many of our systems are quietly compromised.

Thursday, August 7, 2014

[solved] CUPS "rendering completed" errors PT I

Editorial: Stand alone systems with, say, a USB printer attached, are forced to behave like a network when printing with CUPS. This faux-network process on stand-alone systems is one of looping back ("loopback") to one's system ("localhost") -- occasionally a complicated process, depending on port set-up and permissions. Added to this are network security settings since one is opening one's ports "as if" on a network. Entire books are written about this -- it's way over the head of the average user to configure ipchains, LDAP, PAM, port scramblers, and so on properly. Long story short, conflicts are nearly certain on a simple stand-alone printing setup due to CUPS negligence of stand-alone users. I hope that someday, although it's already been 20 years, CUPS developers will humble themselves and address a direct printing solution (in addition to their excellent network solution). /end rant

At any rate, here is a recent fail. I attempted to print a document, but forgot to attach the printer first. CUPS often provides unhelpful or misleading error messages, but no error message was generated. Rather, CUPS continued to display normal status, with a message of "rendering completed". When the printer was attached, it never printed, and no additional documents could be printed. The message that rendering was completed continued to display.

Reinstall (10 minutes)

I verified there was still a PPD in /usr/share/cups/model, located the printer using $ lsusb (in my case 001:004). then...
# lpadmin -x Officejet_Pro_8500_A910
$ hp-setup -i --auto 001:004
Partway through installation is root authentication. The printer installs perfectly and is back to printing.

A tray icon is available as well, but it uses some RAM: /usr/bin/hp-devicesettings

SystemGroup (hours and hours)

CUPS makes a simple conceptual distinction between administrator and user. SystemGroup is a category of users with system-administrator CUPS privileges. Group refers to CUPS users with printing privileges. Although simple in concept and perhaps great on a network, CUPS permissions cause suffering for stand-alone Linux users. Linux systems already isolate administrator (root) and user (user) access. Adding an additional CUPS layer is both redundant and rife with permission overlap possibilities.

First, deal with Group -- add your username to group lp in the system's group administration file, /etc/group. This is a beneficial overlap between Linux and CUPS. CUPS simply looks to see if you're in lp, and you can print.

Now, the harder category, SystemGroup. At the top of /etc/cups/cups-files.conf are the default user settings (typically lp, as just noted). At the bottom of the file are the SystemGroup settings. These are finnicky.
# nano /etc/cups/cups-files.conf
# Default user and group for filters/backends/helper programs; this cannot be
# any user or group that resolves to ID 0 for security reasons...
User daemon
Group lp

# Administrator user group, used to match @SYSTEM in cupsd.conf policy rules...
SystemGroup sys root

# Do we allow file: device URIs other than to /dev/null? [No]
FileDevice Yes

You want the CUPS SystemGroup membership to be root, so it mirrors your Linux authentications for administration. But unlike the user (lp) level, you don't want a CUPS "SystemGroup" line in your Linux system. That is, don't add a "SystemGroup" group to /etc/group; lp -yes, SystemGroup - no. The latter is CUPS specific only. Confusing.

Tuesday, June 24, 2014

cp to/from a usb from terminal

With a USB drive attached to a desktop, I attempt to copy some files from the desktop to the USB HDD. I receive "filesystem does not support symbolic links" errors and can't copy. This becomes maddening because I have no symbolic links in the files to be copied nor am I attempting to establish any symbolic links. In short, I'm asking it to copy, it's responding by claiming I'm asking something else, and that it can't do that other thing. What can we verify to help ourselves troubleshoot this mess?
  • Make sure the file owners are the same, eg the same UID.
  • Double check that you can fstab various MSOFT file systems
$ cat /etc/fstab
/dev/sdb1 /media/sdb1 ext2 uid=1000,noauto,user 0 0

$ parted /dev/sdb -l
Model: USB DISK 2.0 (scsi)
Disk /dev/sdb: 1032MB
Sector size (logical/physical): 512B/512B
Partition Table: msdos
Disk Flags:

Number Start End Size Type File system Flags
1 1049kB 1032MB 1031MB primary

Is this an fstab problem?

Wednesday, April 30, 2014

cp, dd, dump, rsync -- diff

I want to back-up some items, and have 3 requirements, plus 3 hopefuls.

1.) Back-up to an ISO, eg to "20141231_bak.iso"
2.) Able to exclude some directories from the process.
3.) Fast
4.) If possible, backup an unmounted partition to avoid any "live acquisition" write errors
5.) If possible, update the ISO with file changes.
6.) If possible, prior to, or following backup, an app which locates duplicate files.

cp solution

For a mounted partition, cp is a reasonable option. We can take an entire data directory, say /home/foo, and safely back it up to an external HDD with a date. We would have to cycle the dumps, since there will be no indexes of changed files.
$ cp -a /home/foo/. /dev/hdb/20140430
Problem: again, slow. Doesn't write to a file, eg to an ISO. Doesn't allow excluded directories. Only works on mounted drives.


dd solution

We prefer backing-up an unmounted partition since there's no chance of new data being written during the backup -- dd fits this bill. Also it's fast. Thirdly, it does exactly what we want for our format: writes from a device to a file
$ dd if=/dev/hda2/ of=/home/foo/20141231_bak.iso
Problem: No directory exclusion since dd backs-up the entire partition. A second problem with duplicating the entire partition is the image includes all free space on the partition, requiring equivalent backup space to the partition. Solution: possibly use "conv=sparse" option to exclude blank space. This means, prior to backups, using something like zerofree to rapidly zero unallocated areas on the partion.

rsync solution

Rsync is not so fast the first time it's run, but subsequent incremental back-ups can be fast, and delta transfer (-W flag) may increase speed even on a USB (as opposed to network) backup. Problem: It's live acquisition; disk must be mounted. It doesn't natively write to a file.

Tuesday, April 8, 2014

Is an ellipse really a conic?

I don't think so. Consider that an ellipse is supposed to have equal eccentricity on each end -- it's not supposed to be shaped like a cross section of an egg.

But now consider that a cone has a varying radius from it's base to its vertex. At the vertex of a cone, the peak of the cone, the radius is zero, at its base, the radius of the cone is however large you want to make it.

The ellipse is (supposedly) the result of cutting the cone at a SLANT. This means the radius of the cone is different at one end of the ellipse than the other. This means that the only way to have a true ellipse is to have a section of a cylinder, not of a cone. Nevertheless, they persist in calling it a "conic". Is there something I overlooked?

Monday, March 24, 2014

xdg-mime for media files

Links: general guidelines thread ::


After I upgrade a browser or install a new file manager, clicking on links opens an undesired application: a browser, mail client, etc. These have to do with MIME settings. There are two main MIME categories: 1) local HDD files, and 2) behavior when encountering remote files via a browser.

But locating MIME types and overseeing them has been kludgy. Recently, I located xdg-mime (probably one of "xdg-utils"). Xdg-mime can apparently operate across both root or user modes. Unless admin (root) locks them out, users can apparently create their own MIME approach. I'll post back on this once I determine the syntax and file location of the oversight file (mimetypes-file) but, at first glance, xdg-mime looks to be a central way to make changes.

manual changes

Before resorting to xdg-mime, it may be possible to determine which files contain "MimeType", since there may be ways to directly update these files. Caches contain a lot of this kind of syntax too, so it's good to clear caches before searching:
$ rm -r .cache/*
$ grep -rn MimeType

"desktop" files

Saturday, March 15, 2014

stop changing sh*t...

...just STOP.

We choose Linux because we like a stable OS we rarely have to upgrade or alter. But that's becoming more and more difficult. Unless I've overlooked something, even simple utilities are eventually "improved".

The latest is a bedrock of operation; dhcpcd. This has been a great application and whomever designed dhcpcd has my thanks. Unfortunately, it now appears to have been "upgraded".
ctrl_interface not defined in $wpa_supplicant_conf
not interacting with wpa_supplicant(8)
In other words, we have an unnecessary new level of dhcpcd specificity when dhcpcd initializes, because it will also seek to initialize wpa_supplicant. Apparently for that reason, the dhcpcd developer decided that the wpa_supplicant.conf file was fair game for him or her to use in a new way. So now he/she requires us to hand-enter ctrl_interface information into wpa_supplicant.conf. If we don't add this ctrl_interface line, dhcpcd is unhappy and fails. No DHCP lease. Brilliant.

This moron also failed an even more basic observation: that wpa_supplicant has its own independent initialization process which relies, appropriately, on /etc/wpa_supplicant.conf. During its initialization, if wpa_supplicant encounters the ctrl_interface line which dhcpcd required us to add, wpa_supplicant reads the line as an error, and exits. Bingo, Catch-22. If I don't modify the config file, I can't negotiate a DHCP lease. If do modify the config file, wpa_supplicant fails. I guess we didn't want to use our wireless cards anyway.

Developers, please just STOP upgrading utilities we rely upon and which have no need for upgrade. Please. And if you're going to do something creative anyway, AT LEAST generate a separate configuration file.

Sunday, March 9, 2014

[solved] ti-89 OS update, tilp

Links: manpage (ubuntu site) :: connect to system :: OS update (v3.1) :: ti planet (hella fun)
OK, I have a list of implicit derivatives --- better check them before I submit them. Whip out the handy TI-89 Titanium and...WTF?! No impDer function. Great. Check the OS. Oh noes, version 3.0. Gonna be a long night.

download fun

Nothing came up in pacman. Nada. Accordingly, prepared myself to waste hours and hours and hours installing TiLP and pray I can update the OS once inside the calculator.

Download and unzip the libraries and get to work compiling all three of them. What could possibly go wrong compiling and installing 3 libraries? Hahahahaha. Hey, let's try yaourt.

compile, install libs

$ yaourt -Ss tilp
Bingo.

yaourt install

Using the yaourt install was still kind of a drag because of the compilation of the libraries. A lot of messages showed up suggesting edits to the install, but I figured any alterations I made could create subsequent errors I wouldn't have notes for, so I just let it compile.

tilp

Probably because I didn't make the alterations, I got some error messages, but everything seemed to work OK in spite of this. Except the OS update. For that, I shut down tilp, checked the calculator again to be sure it was "on", and started tilp in root. At that point, I just dragged the new OS from the computer directory over to the calculator directory and let off the mouse. The software update program began to run and even showed a % progress reading. Once it was done, turned off tilp, disconnected and restarted calculator. Voila, software version was 3.1 and impDer available.

Friday, January 24, 2014

Medieval Cyrillic fonts in LaTeX (or XeLaTeX)

Links: tfm font install :: ttf fonts available :: old bulgarian lcyw

NB: A short note about WYSIWYG processor LibreOffice is at bottom.

Although analysts of Medieval Russian want to author text in modern Russian typefaces, they want their software to convert selected passages into Old Slavonic typefaces, change formatting, scale the text, and so on. These tasks could theoretically be accomplished in any good word processor. LaTeX with its immense formatting flexibility, would presumably be near the top of such a list but, unfortunately, straightforward LaTeX configuration solutions appear difficult to locate for older Cyrillic typefaces. Here's an outline of some of the steps I took.

LaTeX - installed cyrillic fonts

LaTeX font files have an associated .tfm file. Find their directory by following the variable (TEXMFLOCAL) which points to it. The list of directories for various fonts is underneath it...
$ kpsewhich --var-value TEXMFLOCAL
$ ls ~/latex/2013/texmf-dist/fonts/tfm/
$ cd latex/2013/texmf-dist/doc/fonts/
Inside here, we can see most any of the codes we need for the \renewcommand{\sfdefault}{some code}\normalfont command. I don't know of any definitive listing of all of them, but some have Cyrillic characters and some don't, eg Cantarell has Cyrillics and its code is "fca". To switch to Cantarell
\renewcommand{\sfdefault}{fca}\normalfont
For proper line breaks, it's additionally good to point out "\textcyrillic{}", eg.
\textcyrillic{машина}
And of course code is needed at the top of the TEX document:
\usepackage[T2A,T1]{fontenc}
\usepackage[utf8]{inputenc}
\usepackage[russian,english]{babel}

pdflatex - packages


In a TexLive installation, Old Slavonic text pasted from this posting compiled in pdflatex with the following headers...
\documentclass[letterpaper]{article}
\usepackage{amsmath,amsthm,amssymb}
\usepackage{mathtext}

\usepackage[T2A]{fontenc}
\usepackage[utf8]{inputenc}
\usepackage[english,bulgarian,russian,ukrainian]{babel}
\begin{document}
Russian text block
\end{document}
...however T2A coding is not a solution because it produced mostly Ukrainian versions instead of OCS. Close, but no cigar. Substituting T2C did slightly better, for example with "theta", but otherwise mostly produced Serbian versions. X2 coding provided only one dot over the "I", and so on. So we were left with pieces of success, but mostly failure (with respect to OCS), in each option. Unless I've overlooking something, it's possible one would have to build their own glyphs to properly code the OCS using pdflatex. Further, we'd still have run T1 coding if we have English (latin alphabet) portions in the document.

pdflatex - take two

I decided to seek from an Old Bulgarian angle. A Macro was located here, which included an INS with the DTX.
$ kpsewhich --var-value TEXMFHOME
$ unzip lcwy.zip -d ~/texmf
$ texhash

xelatex - packages


Using xelatex, the following compiled...

\documentclass[letterpaper]{article}

\usepackage{fontspec}
\usepackage{xunicode}
\usepackage{xltxtra}

\setmainfont{DejaVu Sans}

\begin{document}
Russian text block
\end{document}
... but produces a severe, sans-serif Ukrainian.

alphabetum


LibreOffice - ttf

For WYSIWYG, a partial solution is true-type fonts. We can obtain fonts here for some medieval slavic fonts. One researcher particularly liked "dilyan.ttf", and "BukyVede-Regular.ttf"; he said they were accurate except for lacking diacritics. I explained he could place TTF's into LibreOffice /usr/share/fonts or ~/.fonts, directory (I prefer ~./fonts); they were immediately available on his font list the next time he opened LibreOffice.

Monday, January 6, 2014

[solved] zotero consistency - standalone w/browsers

Links: Zotero resources

After an update to Chromium, and using standalone Zotero, I no longer had Zotero icons in the URLbar at book and article sites. What a pisser --- it looks like yet another "one of those things" on the long list of problems we all face during updates. I wish I were a database designer so I didn't have to rely on database products (eg. Zotero), but that's life.

solution

It appears the new disconnect between the browser and Zotero is a "translation" issue. I went to the Zotero site and downloaded the Chromium extension "Zotero Connector" and, voila, my URLbar icons for documents reappeared.

citation backup - zotero

Some of us forget where we installed the data directory when we installed Zotero originally. Open Zotero then note the "Show Data Directory" button (Edit-> Preferences -> Files and Folders) which points to it. The best backup is to copy the "zotero" folder with all subdirectories (eg., "storage").

bare bones

In a pinch, copy the file and subdirectory:
  • zotero.sqlite
  • "storage" subdirectory
With these, use a file manager to overwrite the vanilla versions of these after a vanilla install.

restoration

If I only have the database, without storage, I'd have to reenter all the notes and so forth, but I'd at least have my titles and authors. Overwriting an entire install's "storage" directory and zotero sqlite is a complete restoration.