Sunday, May 17, 2015

Uhoh...

Not a good morning.  Woke up to house server's death rattle.  Need to take a look at what brand hard drive I've been feeding it.

Friday, May 15, 2015

Adding !page commands to Gleebox

To go with yesterday's post, I also wanted the ability to open TT-RSS in a new window.  Doing so is straight-forward:

1) Edit glee.js and add the following (somewhere near the entry for 'rss'):
  {
     name: 'ttrss',
     method: 'openttrss',
     description: 'Open TT-RSS in a new page',
     statusText: 'Opening TT-RSS...'
  },
2) Edit pagecmds.js and add the following (somewhere near Glee.getRSSLink):
Glee.openttrss = function(newtab) {
   Glee.Browser.openURL('http://192.168.2.240/tt-rss',1,true);
   Glee.empty();
};
3) Restart your browser and test

Just in case you want to add other commands, Glee.Browser.openURL requires three arguments, in the following order:
Arg 1 = whichever URL you want to call, doesn't have to be http: or https:
Arg 2 = open a new tab? (0 or false = no, 1 or true = yes, "newtab" = dependent on input (enter = 0, shift-enter = 1))
Arg3 = selected? - if a new tab is opened, should focus be placed on it?  (1/true or 0/false)

Thursday, May 14, 2015

Gleebox fix for Google Reader command (using TT-RSS)

I'm a fan of Gleebox, especially since I'm getting older and marathon surf sessions can cause my elbow to ache (from reaching for the mouse, then the keyboard, then the mouse).  Using Gleebox saves wear and tear on my elbow and speeds up navigation across sites/pages.

One of Gleebox's drawbacks is that it hasn't been updated in awhile.  One notable broken part is the "open feed in Google Reader" option (Google Reader has been offline for years).  If you have your own TT-RSS instance, or have access to someone else's, the following steps will "re-purpose" the !rss command.

Assuming that you already have Gleebox installed as a Chrome extension on your workstation:

1) Find the pagecmd.js file.  On my desktop, it is located in:

.config/google-chrome/Default/Extensions/miinkdcjglbkbanpkghnkgkgbamdkgji/2.3.1_0/js

2) Open pagecmd.js in your favorite editor and look for the following lines:
// rss: Opens the rss feed of page in google reader
Glee.getRSSLink = function(newtab) {
  // code via bookmark for google reader
  var b = document.body;var GR________bookmarklet_domain = 'http://www.google.com';if (b && !document.xmlVersion) {void(z = document.createElement('script'));void(z.src = 'http://www.google.com/reader/ui/subscribe-bookmarklet.js');void(b.appendChild(z));}else {location = 'http://www.google.com/reader/view/feed/' + encodeURIComponent(location.href)}
};
Make them look like:
Glee.getRSSLink = function(newtab) {
  Glee.Browser.openURL('http://192.168.2.240/tt-rss/public.php?op=subscribe&feed_url='+encodeURIComponent(location.href),newtab,true);
  if(newtab) {
        Glee.empty();
  }
};
Note: there should be no carriage return between "public.php?" and "op=subscribe".  That should be a single line, starting with "Glee.Browser.openURL" and ending with "newtab,true);".  Of course, you should also edit the line so that the location of your TT-RSS server is accurate.

3) Close your browser, wait a few seconds, and open Chrome again.  Visit a page with an RSS feed and attempt to run the Gleebox "!rss" command.  It should attempt to add the feed to your TT-RSS instance.

Thursday, May 7, 2015

A forced marriage?

With apologies for a rambling rant, it's been awhile since I've written on a security-related topic.  Mebbe 'cause it'd mostly been an exercise in frustration (don't expect this post to be any different, please)...

ITWire has an article entitled "Microsoft's new secure boot strategy will suit Linux firms"[1].  The author describes Microsoft's strong-arming (my opinion) the hardware community into implementing yet-another-ineffective fix from Redmond.  Doesn't anyone remember the claims that ASLR and DEP were supposed to solve everything?  What happened there? (Hint: I'm pointing out that there's an arms race.)

This latest appears to be an attempt to add DRM to the hardware, making it impossible to use any OS other than those from companies[2] that can afford the costs of repeated code signing after each update (it's interesting who gets that money). If this latest effort goes into effect, I think the only option appears to be: give in and announce the death of the general purpose computer (as it will no longer be "general purpose").

What really spins me up about the article's discussion of the idea that this course of action is "best for everyone involved".  The thought that I can't get past is: I'd thought that arranged marriages[4] died out somewhere in the last century.  By removing autonomy (user choice), MS is only guaranteeing that a greater number of people will be frustrated with given (limited) offerings.  I guess we'll just have to "learn to love the one we're with" (with apologies to Mr. Stills for the paraphrasing).

One of the limitations involved will be the forced reliance on systems with ever-increasing complexity.  It's quite frustrating to read the articles where discussion is on a theoretical-only level.  What engineering seems to forget that the more complex a system is, the more byzantine a failure will be and the more likely that such a failure will occur[5].  By increasing complexity, the gap between theory and implementation widens[6] and the likelihood of undesired synchronicity between "small problems" increases.

Overall, the article was good, if you can ignore the last few paragraphs.  The author seems to have forgotten that the "Linux companies" exist because of their communities, not the other way around[7].  Of course, "Linux companies" will be reluctant to make comment on another company's actions as it will likely affect their own bottom line.

As part of the author-described "so-called Linux community", I'm a bit frustrated with him, having ranted on this topic and having listened to other's dire concerns.  The author seems to be a non-participant in any "Linux community" and resorts to cheap shots from the outside[8][9].  It raises concerns over who he considers to not be part of "the community[10]".

Notes:
[1] http://www.itwire.com/opinion-and-analysis/open-sauce/67959-microsofts-new-secure-boot-strategy-will-suit-linux-firms
[2] Note: I'm writing this post on an OS that is not part of the group listed in the article.  First thing I did when I bought the workstation was to replace the hard drive and turn off UEFI.  I've written a number of tools for my own use and compile most other tools from source.
[3] Recommended reading: How Complex Systems Fail. http://web.mit.edu/2.75/resources/random/How%20Complex%20Systems%20Fail.pdf [4]
[4] http://en.wikipedia.org/wiki/Arranged_marriage  The discussion of physical disabilities being a factor seems appropo to the article's premise (i.e., forcing/limiting/removing choice).
[5] An information security paradigm, relating to failure/compromise: "Not if, but when."
[6] Keep in mind that programs _still_ are rated in errors/KLOCs.
[7] Linux is written by "the community".  This means that responses tend to be numerous and varied.  It's rate that a single countermeasure will be universal across all flavors of Linux (things have to "seriously bad" for that sort of thing to happen).
[8] Re: the author's closing "lack of backbone" statement.  I see that as a sign of a community refusing to stoop to the same toxic tactics employed by it's opposition (points for remembering which company called the other "a cancer"!).
[9] I'm also wary of any author whose primary set of references is his own content.  The article contains 11 links, 7 of which point to other of the author's content.  Of the remaining 4, three point to the Linux websites and one points to someone else's article which only describes
[10] Just because you say there was no response, doesn't make it true...   From 2011:
 - http://www.linuxjournal.com/content/microsoft%E2%80%99s-take-uefi-may-impede-linux-and-that%E2%80%99s-being-polite
 - http://linux.slashdot.org/story/11/09/23/1236221/microsoft-responds-to-linux-concerns-over-windows-8-and-uefi-secure-boot
 - https://lwn.net/Articles/447381/
 - http://www.freesoftwaremagazine.com/articles/uefi_and_windows_8_bad_news_gnu_linux
 - http://www.zdnet.com/article/linux-foundation-proposes-to-use-uefi-to-make-pcs-secure-and-free/
 - http://www.itworld.com/article/2737487/it-management/microsoft-washes-its-hands-of-uefi-linux-mess.html

Tuesday, May 5, 2015

USB IRToy v2 working

As much as I dislike using Stack Exchange (for being a pool of pedants, HTTA'ers, and LMGTFU'ers), there is the occasional nugget of gold to be found there.  Case in point: I'd thrown the USB IRToy (v2) in my junk box because it just absolutely refused to run consistently.  I'd even considered modifying the fan's remote, to give it an I2C or PiFace interface (a $40 solution to a $2 problem).

It wasn't that the issue isn't well known (it is).  My problem was that the suggested work-around (setting auto-suspend equal to -1) wasn't working.  I eventually tossed the device into the junk drawer with the hope that someone, someday would fix the firmware.

The good news: while researching tweaks for the RPi "IR Remote Shield v1,0", I stumbled across  Rael Gugelmin Cunha's response[1] about how changing autosuspend (on Ubuntu) from the command line is no longer viable.  Instead, he suggested to edit the grub, modifying the boot command so that the kernel recognizes the autosuspend directive.  I implemented this on my Kali desktop and it appears to have worked (or at least the board is still working properly 5 hours after it was installed).

Short version: I now have the ability to control the floor fan via web and Jabber.

[1] http://unix.stackexchange.com/questions/91027/how-to-disable-usb-autosuspend-on-kernel-3-7-10-or-above

Monday, May 4, 2015

RDA5807SP and Icecast problems

Spent an hour or so playing with a Raspberry Pi, a USB sound card, and the RDA5807SP breakout board.  Idea was to use the RPi to control the RDA5807SP, as well as streaming the output through an Icecast2 instance, also running on the RPi.

Overall, it works nicely for the first few minutes, then the audio begins to skip.  This happens regardless of the audio client employed (mplayer, vlc/cvlc, radiotray, etc.).  Based on mplayer's errors, it appears to be a caching issue:
A:  16.2 (16.1) of -0.0 (unknown)  0.1% 0% Cache empty, consider increasing -cache and/or -cache-min. [performance issue]
Since the issue appears to be independent of the client, I'm making the assumption is on the RPi end.  I'm hoping that this can be fixed.  More research in my future, I guess.