December 2013 - Roundtable

IBM "clicky" keyboards
by Adam Thompson 13 Oct '16

13 Oct '16

Enough people have wondered/asked/complained to me about this that I'm posting this now as a public service. IBM Model "M" keyboards are still available, *NEW*, today. They are expensive, but they are the original design that you can use as a melee weapon. The catch is that they don't say "IBM" or even "Lexmark" on them. They are available for purchase from the manufacturer, Unicomp, who can be found online at http://www.pckeyboard.com/. You can also find some vintage NIB units from time to time at http://www.clickykeyboards.com/. There are also a number of other manufacturers now making similar, but not quite as good, keyboards. - CVT Inc., the maker of the Avant Stellar (I own two of them), which is the direct descendant of the Northgate Omnikey, seems to have restructured and no trace of their keyboard manufacturing operation can be found online. However, Northgate keyboards are still available new-in-box from (this is a horrible site, beware) http://www.northgate-keyboard-repair.com/. - The Happy Hacking keyboard (now owned by Fujitsu, apparently) is equally comforting to some people despite having a totally different feel. They, and many others, can be had from http://www.elitekeyboards.com/ - Das Keyboard - Anything using Cherry MX Green, Blue, or White keyswitches. The "green" switches apparently are the closest anyone's come yet to emulating the IBM/Lexmark/Unicomp switches... and they can be had in MUCH cheaper keyboards, like the Rosewill RK-9000 (http://www.newegg.ca/Product/Product.aspx?Item=N82E16823201040 and http://techreport.com/review/23405/rosewill-rk-9000-series-mechanical-ke yboards-reviewed). - And there are an increasing number (yes, again, after the big die-off ca. 2009) of speciality manufacturers of "ergonomic" keyboards that are making clicky keyswitches available as an option. One of the better ones is a tiny shop in Ontario, but I can't find the name right now. References: http://en.wikipedia.org/wiki/Model_M_keyboard http://en.wikipedia.org/wiki/Unicomp http://deskthority.net/wiki/Cherry_MX -Adam Thompson athompso(a)athompso.net

7 12

SpamAssassin false positives on DATE_IN_FUTURE_96_Q?
by Gilbert E. Detillieux 23 Feb '16

23 Feb '16

I mentioned this problem at the last round-table session, but didn't get a solution, so I thought I'd post it here, just in case anyone has any suggestions to offer. I'm still seeing a whole bunch of false positives in SpamAssassin, since an update was installed in mid-September on a CentOS 5.7 system, for a rule called DATE_IN_FUTURE_96_Q, which is only supposed to be triggered when the "Date:" header has a date that is 4 days to 4 month ahead of the date in the "Received" header that has the _smallest_ difference in date. Here are the headers from the latest e-mail I've received with this false-positive. (I've stripped out irrelevant headers, for the sake of clarity and simplicity.) From topfivestories(a)messagent.itworldcanada.com Mon Nov 14 07:50:13 2011 Received: from mail.messagent.itworldcanada.com (mail.messagent.itworldcanada.com [207.112.10.80]) by palladium.cs.umanitoba.ca (8.13.8/8.13.8) with SMTP id pAEDoAxV028594 for <gedetil(a)cs.umanitoba.ca>; Mon, 14 Nov 2011 07:50:12 -0600 Date: Mon, 14 Nov 2011 08:50:13 -0500 X-Spam-Status: No, score=-0.3 required=5.0 tests=BAYES_00,DATE_IN_FUTURE_96_Q, HTML_MESSAGE,RP_MATCHES_RCVD autolearn=no version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on palladium.cs.umanitoba.ca Note that I'm calling spamd via the spamass-milter on a system running sendmail. Note also, that in the above example, the only "Received" header was the one generated by my own server. (I've had other false positives, however, with multiple "Received" headers, all of which were within seconds of the time in the "Date" header.) Any ideas? -- Gilbert E. Detillieux E-mail: <gedetil(a)muug.mb.ca> Manitoba UNIX User Group Web: http://www.muug.mb.ca/ PO Box 130 St-Boniface Phone: (204)474-8161 Winnipeg MB CANADA R2H 3B4 Fax: (204)474-7609

6 11

big scanner
by Trevor Cordes 27 May '15

27 May '15

Does anyone have big (like tabloid or bigger) scanner they want to sell? Even an ancient SCSI or parallel one might be ok. I just want *big*. Do they even make scanners bigger than legal or tabloid?

4 6

Linux distro for Pentium III
by Robert Dyck 01 Jun '14

01 Jun '14

I have a customer who wants a laptop with Linux. My impression is he wants to learn Linux. I have refurbished laptops: IBM ThinkPad A21m, with Pentium III processor @ 750 MHz, 512MB RAM, and I can upgrade the hard drive to 40GB. Which distro of Linux would you recommend? I would ask Mike Pfaiffer, but he passed away earlier this year. Thanks, Rob Dyck

8 16

Tablet dev software
by Robert Keizer 21 Dec '13

21 Dec '13

Greeting, I recently received a new Samsung tablet as a gift. Does anyone have experience with using a tablet as a primary development system? I'm leaning towards purchasing a HDMI cable and running a bluetooth keyboard/mouse. Rob.

2 1

SOLVED: PPPoE/pppd dying
by Trevor Cordes 21 Dec '13

21 Dec '13

Some may recall my strange pppoe hanging-up up watchdog-script restart problem from a few months back (original email included at bottom) to which no one replied ;-) After a few serendipitous epiphanies I stumbled upon the possibility of kernel "session id" as the culprit. I could get around that by starting pppoe stuff with setsid (either in perl or right at the command line). That got me my own session (removing me from the same session as the watchdog script). But that didn't solve it. But that led me to process groups, but that was also not it. Then I stumbled across in the fs /proc/*/cgroup and noticed that the ppp ps's were (still) tied to my watchdog script, via the systemd unit name (call it my-watchdog), so, where pppd is 13480: #cat /proc/13480/cgroup 10:perf_event:/ 9:blkio:/ 8:net_cls:/ 7:freezer:/ 6:devices:/ 5:memory:/ 4:cpuacct,cpu:/system/my-watchdog.service 3:cpuset:/ 2:name=systemd:/system/my-watchdog.service So that was the tie between the watchdog and the ppp* programs! Time to learn cgroups... argh. To make a long story short, this is all systemd's fault! Surprise! It makes sense now, as this bug only appeared for me around the time Fedora switched to systemd. Before that I was using inittab and then upstart to control these things and those tools don't use cgroups (well, upstart might?). Systemd, as a "feature", puts each *.service into its own eponymous cgroup. Then all child ps's of those would inherit the same cgroup settings. Then when the parent *.service gets restarted or killed, either the kernel or systemd (haven't deduced which; ideas?) propagates the kill signal to all members of the cgroup. Thus answering the question. The solution I settled on (for now) out of the about 20 ways it seemed one could fix it is to put the following in my my-watchdog.service file in the [Service] section: ControlGroup=cpuacct:/ name=systemd:/ Which then causes the relevant /proc/*/cgroup files to look like (relevant lines only): 4:cpuacct,cpu:/ 2:name=systemd:/ Thus tying them to the "root" cgroup and eliminating the propagation of kill signals. (Which hints that it is systemd propagating, not the kernel unless the kernel explicitly excludes the root cgroup.) I also achieved the same thing by writing directly to the /sys/fs/cgroup/ files, but that only achieves temporary independence and would have to be done each time ppp* is started. echo <pid> >> /sys/fs/cgroup/cpu,cpuacct/tasks echo <pid> >> /sys/fs/cgroup/systemd/tasks That's actually a viable solution, and perhaps better, as it allows me to keep my-watchdog in its own cgroup as systemd wants to do whilst separating out just the ppp* stuff. BUT, systemd's online docs indicate systemd will in the future block manual fs configuration like this. Also, the systemd docs and current Fedora 19 implementation seem to be a bit at odds and many of the options they discuss do not work when tried (invalid lvalue, etc). I also think that my solution here may not work in the future as they lock down cgroups more. I think perhaps the "real" solution to all of this is to somehow make ppp* a unit in systemd and have my-watchdog use systemd to control it. That way we achieve cgroup independence without doing anything weird. But, pppoe (client) doesn't really fit the systemd *.service mold as such and no one I can see has implemented it that way yet. This may be required in the future, however. The moral of the story is, if you use systemd and your service files/programs launch a process as a "side effect", that process will die when your service gets restarted/killed. If you are starting anything daemon-like that you want to survive, you'll need to implement workarounds as described in this email. On 20130324 17:53:30, Trevor Cordes wrote: > I have a script that starts/restarts PPPoE/pppd (MTS aDSL) as required on > a box. It used to work A-OK. After updates w ehil back (probably from > Fedora 14 -> 16 I think) a weird thing started happening: > > When my script is stopped (to be restarted after an update for instance), > it instantly kills pppd and so my pppoe connection. > > pppd[1572]: Terminating on signal 15 > pppd[1572]: Connect time 7.5 minutes. > pppd[1572]: Sent 136980 bytes, received 76924 bytes. > pppd[1572]: Connection terminated. > pppoe[1573]: read (asyncReadFromPPP): Session 14782: Input/output error > pppoe[1573]: Sent PADT > pppd[1572]: Exit. > > sig 15 is SIGTERM. > > I can see before this happens that the processes involved are at the root > owned by init (ps 1): > > root 4393 1 0 17:30 ? 00:00:00 /bin/bash /sbin/pppoe-connect /etc/sysconfig/network-scripts/ifcfg-ppp0 > root 4417 4393 0 17:30 ? 00:00:00 /usr/sbin/pppd pty /usr/sbin/pppoe -p /var/run/pppoe-adsl.pid.pppoe -I eth0 -T 60 -U -m 1412 ipparam ppp0 linkname ppp0 noipdefault noauth default-asyncmap defaultroute hide-p$ > nobody 4418 4417 0 17:30 ? 00:00:00 /usr/sbin/pppoe -p /var/run/pppoe-adsl.pid.pppoe -I eth0 -T 60 -U -m 1412 > > One would think that if it's been "daemonized" to be owned by init then > killing the calling script would not affect it. But it is. > > What my script actually call is ifup and then Fedora's network magic in > turn calls pppoe/pppd. ifup itself exits right after doing this (which is > probably why its children become children of init). > > I tried adding a nohup before the ifup, but it doesn't help. I guess that > makes sense since it's SIGTERM, not SIGHUP. > > I'm out of ideas to make sure this stuff stays up after restarting my > script, and don't know what could have changed in Fedora to make this > happen. > > Thanks!

1 0

Recommendations for wireless mini-keyboard/trackpad?
by Gilbert E. Detillieux 20 Dec '13

20 Dec '13

I'm thinking of getting a wireless mini-keyboard with integrated trackpad, with a USB receiver, to use as a remote control for an XBMC set-top box. I've tried using a Logitech K400r, which works great, but I thought something more compact might be more convenient (since I won't be doing a lot of touch-typing on it). There seems to be a wide range of prices for these things, from around $15 at the low end to over $100. I'm always interested in saving money, but I want something that will work well, of course. Has anyone tried these? Any recommendations for brands and models that are worth considering? Any that should be avoided? Thanks! -- Gilbert E. Detillieux E-mail: <gedetil(a)muug.mb.ca> Manitoba UNIX User Group Web: http://www.muug.mb.ca/ PO Box 130 St-Boniface Phone: (204)474-8161 Winnipeg MB CANADA R2H 3B4 Fax: (204)474-7609

2 1

out of inodes
by Trevor Cordes 13 Dec '13

13 Dec '13

As a follow-up to the opera-ate-my-inodes problem discussed at the meeting, I checked a few things out and realized that this surely is a problem not limited to bad (or lazy) admin choices, for the following reasons: 1. People with separate /home partitions aren't spared: what if an app or malicious user writes to /var/tmp, which on 99% of systems is going to be on the same partition as /. So a separate /home won't spare you from / running out of inodes: all it takes is one sticky-bit dir in the whole tree where a non-root can write to have one non-root user/app starve the system of inodes. 2. The thought that you should create your fs's with massively more inodes than your usage pattern could ever use won't help either, as the user/app could create 0 byte files that eat an inode but never a fs block. You'd run out of inodes before you hit the reserved-root-du limit no matter how many inodes you created at fs creation time. (Not to mention the non-insignificant loss of usable disk space that occurs if you allocate many orders of magnitude more inodes than you will ever need.) 3. Quotas might be able to help, but I'm not talking about public systems here, I'm talking about my own personal home desktop. Surely no one is running quotas against themselves on their personal home system? And surely that can't be offered as a "sane" solution the average Joe is supposed to implement. OK, here's the weirdest part: I just checked and my / is ext4! I thought Adam mentioned ext4 dynamically creates inode out of thin air (and I thought that too) like XFS? So why did I run out of inodes on a non-full (df) ext4 fs? If this "bug" indeed affects ext4 then for sure I am filing a bug report. If it only affected "legacy" fs's like ext3 then I probably would just let it pass (and switch to ext4 if I hadn't already). Thanks for everyone's input!

3 3

The voicemail messages we've been getting
by Daryl F 13 Dec '13

13 Dec '13

Attached are WAV and AMR formats. I create both forms. The first for my Windows user (wife) the other for my BlackBerry. Same data, different encoding. I'm suprised to see my MUA considers the Adaptive Multirate Recording's MIME type as TEXT/PLAIN. A little tweaking needed there. Happy Holidays to all. -Daryl

3 4

Amazon's new delivery system!
by Brian Doob 12 Dec '13

12 Dec '13

After our discussion of “Amazon Prime Air”, I think it’s worth sharing this video. This came online only a few days after Amazon’s drone announcement…. http://www.youtube.com/watch?v=jHrngvEok9M

1 0