Slashdot is powered by your submissions, so send in your scoop


Forgot your password?

Slashdot videos: Now with more Slashdot!

  • View

  • Discuss

  • Share

We've improved Slashdot's video section; now you can view our video interviews, product close-ups and site visits with all the usual Slashdot options to comment, share, etc. No more walled garden! It's a work in progress -- we hope you'll check it out (Learn more about the recent updates).

User Journal

Journal: 7 - Why does Gimp depend on systemd? 2

Journal by phantomfive

This post is flotsam related to some dependencies. If you note any mistakes, please let me know, I'm collecting information.

Gimp doesn't depend on systemd as far as I can tell. Gimp runs on Windows. It does depend on libgtk, whose dependency list is available.

There are reports that Gimp depends on systemd, but that seems to be an artifact of a package dependency tree on one system, not that Gimp actually needs systemd.

What about Gnome? Does Gnome depend on systemd? The answer is yes....., although there are alternatives. Systembsd, systemd-shim, and LoginKit.

LoginKit doesn't seem to be complete, like some files were missing from commit or something. The README is attractive, though. It seems to only be attempting to provide services for logind.

Systembsd provides hostenamed, localed, logind, and timedated.

Systemd-shim provides c-group services, some unit file services, power/sleep/reboot services, and ntpdate services.

Neither code base has been updated in four months, and the code in neither one looks particularly well organized.

I suspect there are other things systemd provides that Gnome relies on, but those aren't immediately apparent. I'm not sure where to look to figure that out.

Before logind, Gnome used ConsoleKit to provide login support. Fascinatingly, the commit to remove support for ConsoleKit was made by Florien Mullner.

A lot of this stuff depends directly on DBus. In my opinion that is a mistake; the communication mechanism should be separate from the API interface.

In the next journal entry I will investigate how deeply libsystemd is tied into the init system, or whether it is truly modular.

User Journal

Journal: Systemd (or, how to make portable software) 10

Journal by phantomfive

In this post, Lennart explains that he doesn't know how to write portable C code. He says:

[Making systemd portable] would turn every second line of systemd into #ifdefs.

The purpose of my post here is to explain how to write portable code, without #ifdefs on every other line. If that happens, you are doing it the hard way.

An easier way is to create an OS independent layer. Call it OSI (since no one is using that acronym anymore, right?). Create a header file that declares all your functions, then create an implementation file for each platform. Every time you find a piece of functionality that is different on different platforms, throw it into that header file.

For example, if you need to take a screenshot, it will be different on every platform you find. In the header file, create a function OSI_Screenshot(). Then in your OSI_Windows.c file, add an implementation for windows. In your OSI_Linux.c, add a screenshot implementation for Linux. In your OSI_OSX.c, add your implementation for OSX. This technique can also work for extremely incompatible platforms, with OSI_printf(), or OSI_malloc(), etc. If you use your compiler correctly, you can compile it without any extra overhead from the function call.

An example of this technique can be found in Android (look at sysdeps.h and sysdeps_win32.c), demonstrating that this technique works. They don't have #ifdefs scattered throughout their code. The Android example is tougher than it needs to be, because Android added the compatibility layer after the code was written. If they had started at the beginning, the code would have been much simpler.

The lack of knowledge (about how to write portable code) in the systemd team is causing them to make bad decisions, because the alternative seems too hard. For example:

I have no plans porting it to other kernels, and I will not merge any such patches........Quite frankly, I'd like to question [cross-platform compatibility]. In the light of GNOME OS I think we need to ask ourselves the question if we do ourselves any good if we continue to support all kinds of kernels that simply cannot keep up with Linux anymore.

Those who don't understand the failures of the past are destined to repeat them. Plenty of vendors try to focus on a single platform, and their work disappeared, to be replaced by something that was cross-platform compatible, and usually better work. The discipline required to keep things portable results in better code (there's a quote from Mythical Man Month that fits here but I'm too lazy to look it up). The Gnome developers understand the importance of portability but that's a story for another post.

User Journal

Journal: Systemd's solution to large init scripts 1

Journal by phantomfive

(Note: When you write code, you're making a UI for programmers. Learn to do it well.)

Below you can see a traditional unix init script. It's long, but if you're familiar with shell-script you can figure out what is going on. There is a lot of redundancy here, most init scripts have a switch that runs an option based on the first command-line parameter, for example. One solution is to put common code in a function, but Poettering decided to use config files.

Let's examine the general tradeoff between putting code in a function, and using config files (a form of declarative programming). Config files are fine as long as there aren't too many special cases. If there are too many special cases, you end up with so many options and keywords that it would have been easier to just use a scripting language.

The good side is systemd saves a lot of typing. Way down at the bottom, is a unit file for the same init script. It's clearly shorter, and easier to type.

The bad side is it has arcane keywords which are are not discoverable merely by looking at the file. This is a pattern that repeats itself over and over in systemd, things are easier if you know how to do them, but the system itself is inscrutable without arcane knowledge.

Ideal systems fulfill the requirements while making it easy for those who want to dig deeper. The system opens like the petals of a rose.

# Starts the abrt daemon
# chkconfig: 35 82 16
# description: Daemon to detect crashing apps
# processname: abrtd
# Provides: abrt
# Required-Start: $syslog $local_fs
# Required-Stop: $syslog $local_fs
# Default-Stop: 0 1 2 6
# Default-Start: 3 5
# Short-Description: start and stop abrt daemon
# Description: Listen to and dispatch crash events
# Source function library.
. /etc/rc.d/init.d/functions
# Set these variables if you are behind proxy
#export http_proxy=
#export https_proxy=
# See how we were called.
check() {
    # Check that we're a privileged user
    [ "`id -u`" = 0 ] || exit 4
    # Check if abrt is executable
    test -x $ABRT_BIN || exit 5
start() {
    # Check if it is already running
    if [ ! -f $LOCK ] && [ ! -f $OLD_LOCK ]; then
        echo -n $"Starting abrt daemon: "
        daemon $ABRT_BIN
        [ $RETVAL -eq 0 ] && touch $LOCK
    return $RETVAL
stop() {
    echo -n $"Stopping abrt daemon: "
    killproc $ABRT_BIN
    [ $RETVAL -eq 0 ] && rm -f $LOCK
    [ $RETVAL -eq 0 ] && rm -f $OLD_LOCK
    return $RETVAL
restart() {
reload() {
case "$1" in
    echo "$0: Unimplemented feature."
    if [ -f $LOCK ]; then
    # update from older version
    if [ -f $OLD_LOCK ]; then
    status abrtd
    echo $"Usage: $0 {start|stop|status|restart|condrestart|reload|force-reload}"
exit $RETVAL


Description=Daemon to detect crashing apps

Reference to the examples.

User Journal

Journal: systemd - Why did Debian Adopt it? 8

Journal by phantomfive

There's a Debian debate page, but it's disappointing and everything systemd does is listed with equal value. Thanks to Russ Albery for making a much more balanced assessment, explaining what he likes. The short answer to the question is: SystemD makes things much easier for people writing init scripts. It wasn't about cgroups, or speed, or login managers, it was about writing easy init scripts.

Here are the major complaints he has with the traditional startup system:

* Lack of integration with kernel-level events to properly order startup.
* No mechanism for process monitoring and restarting beyond inittab.
* Heavy reliance on shell scripting rather than declarative syntax.
* A fork and exit with PID file model for daemon startup.

He furthermore points out these problems with startup scripts:

The model of fork and exit without clear synchronization points is inherently racy, the boot model encoded into sysvinit doesn't reflect a modern system boot, and maintaining large and complex init scripts as conffiles has been painful for years. Nearly every init script, including the ones in my own packages, have various edge-case bugs or problems because it's very hard to write robust service startup in shell, even with the excellent helper programs and shell libraries that Debian has available.

Those are the main things that systemd fixes for a distro builder, and probably why so many distros have switched to systemd, because it was built for them.

User Journal

Journal: systemd - A descendent of Apple's LaunchD 1

Journal by phantomfive

Systemd is a descendent of Apple's launchd, Lennart suggested the world watch this movie to learn about it, so why? What is good about launchd?

OSX has an excellent inter-processing message system, part of the mach kernel (which they got from CMU). Because of this, many times processes talk to each other through the standard messaging queues. If you use a library to launch a browser window, or query wifi strength, it will communicate through a message queue (although the library takes care of the details).

The interesting thing is that launchd can open a message queue before the recipient is running. So launchd doesn't launch services until they are needed, and if they aren't needed, they never get launched. The benefit is that resources are preserved, things don't get launched until someone sends a message.

The benefit here is dependency resolution. Instead of forcing a deep calculation of what depends on what, or forcing the server script to declare everything it depends on, you can say "manage all these thousand services!" and only the few that are needed will be used, when they are needed.

Another thing I think Lennart copied from launchd is the declarative config files. You don't need to write a shell script, you merely need to indicate what should be launched, and maybe give it configuration options like "relaunch on failure" or "launch completely before receiving message." Of course, some people like config files, others prefer scripts.....that's not an argument I want to get into here, I'm merely pointing out things that seem to have come from launchd. (

What is bad:

Launchd is utterly undiscoverable. It would have been nice of them to put a README in /etc/rc/ or something saying, "hey, all your startup scripts are gone, look elsewhere."

Launchd has a complex hierarchy of directories that it searches for startup scripts. They have justifications for why, and a reason behind each one.......but justifications and reasons are not the same as good design. Every bad design decision ever made had a justification and a reason.

User Journal

Journal: Systemd - Efficiency and Pike's Rules of Programming 4

Journal by phantomfive

(DISCLAIMER: These are my notes and might be wrong.)

Lennart Poettering has never heard of Rob Pike's rules of programming. Let's examine why:

He said, "On my system the scripts in /etc/init.d call grep at least 77 times.... that has to be incredibly slow...., and should be rewritten in C."

You can time it yourself, with this command:

time for i in {1..77}; do grep user /etc/passwd > /dev/null; done

On my machine it takes 0.229 seconds.

Lennart didn't get the speed increase he wanted. From his benchmark report, "booting up with Upstart takes 27s, with systemd we reach 24s." This result isn't too bad: when I've made a similar mistake of writing code before timing anything, ignoring Pike's rules for programming, once I actually slowed the system down.

If you don't measure, you can't optimize.

For entertainment and enlightenment, here is a quote by Ken Thompson talking vaguely about Pike's rules for programming:

Early Unix programmers became good at modularity because they had to be. An OS is one of the most complicated pieces of code around. If it is not well structured, it will fall apart. There were a couple of early failures at building Unix that were scrapped. One can blame the early (structureless) C for this, but basically it was because the OS was too complicated to write. We needed both refinements in tools (like C structures) and good practice in using them (like Rob Pike's rules for programming) before we could tame that complexity.

User Journal

Journal: SystemD: The Beginning 7

Journal by phantomfive


To do a proper code review, you need to understand the purpose of the code, what all the stakeholders want. From my own perspective, init scripts work fine, but since Unix companies keep trying to create new init systems, they must have different needs than I do.

Here's a list of the stakeholders. I need to figure out what their goals are.
1) System admins.
2) Desktop users.
3) Distro builders.
5) Android (if systemd turns out to be good enough).
4) Programmers

My suspicion is that systemd has taken over because it makes things easier for 3.

At its core, Unix is a system for programmers. What other system comes with a compiler and multiple interpreters by default? Bash is so much more useable than DOS, or even powershell (yeah, go ahead and flame me but I'm right, Powershell doesn't even have < working). Unix was designed by programmers and for programmers.

The reason I'm talking about it is the traditional init process is incredibly discoverable. All you have to do is look in the /etc/rc directories, and you can figure out how your system boots. You can see it all. For a programmer it's easy. Poking around in the system to understand it is one thing that makes Unix great (and what I like about Slackware: the whole thing is lovingly crafted).

So that describes the approach I am taking to code review, and to the init process. Hopefully Systemd is an improvement.

User Journal

Journal: Soylent News 4

Journal by TheRaven64

I've not been posting on Slashdot much this week, because I've been trying out Soylent News, which is using (and old version of) Slashcode (with some improvements) and lacks corporate overlords. It seems to have captured most of what I like about discussions in Slashdot, although is suffering slightly from not having nearly as many active users (50 or so comments is still the norm and it probably needs 100+ to be sustainable).
If you've not visited yet, I'd recommend giving it a go.

I'm TheRaven over there.


Journal: Six Months with a Chromebook

Journal by chill

About six months ago my main PC died and I needed a new one. Not having a lot of cash, and not really having a lot of free time to spend on the computer, I decided to get an Acer C7 Chromebook to hold me over.

Refurbished units are available on Acer's official refurb store, over on E-Bay. I paid $149 at the time. Now the base 2 Gb unit with a 320 Gb HD is available for $139.

These are Intel Celeron-based systems with 2 SO-DIMM RAM sockets and a mini-PCIe slot that holds the a/b/g/n/Bluetooth adapter. With only one RAM socket populated, it was easy to pop in a 4 Gb module for a total of 6 Gb of RAM. Adding more RAM allows the system to operate better with multiple tabs open. Other than that, you won't notice much of a difference.

Now that I've been using this as my primary machine for the last 6 months I can render an informed opinion.

I'm amazed at how much of what I do now is thru a web browser. After adding an SSH app, there is very little I couldn't do with the Chromebook. Still, there are some critical limitations that have driven me to get a "real" computer.

One of the big ones is the lack of network file system support. There is no way to access SMB/CIFS or NFS shares on the Chromebook. It also doesn't have FTP support, though there is a commercial app available for FTP. It is only $1.99, but needs to phone home to make sure you've paid, so requires connectivity to function.

If you can live with accessing files only through Google Drive, everything is fine. But, if you have -- like me -- a few terabytes of data on local shares, you're stuck. No, uploading every movie, television show, educational video and audio file I've every ripped to Google Drive is not an option.

Speaking of uploading music, that is another limitation. If you use Google Music, you can play everything fine, but will need a "real" computer to upload any files.

Printing, too. There is no direct printing support. The system only supports "Google Cloud Print", which means you either buy a new printer that supports GCP or leave a PC running with the printer driver configured, and logged in to Chrome (browser). You also have to be comfortable with everything you print going up to Google and back down. Meh.

It is impressive what can be accomplished through the Chrome browser, an SSH app and an FTP app. There are numerous web IDEs such as Shift Edit that are actually very good for development of HTML, CSS, Javascript and other script-based languages.

Of course, Chrome doesn't do Java. There are still some things on the web that require Java.

The lack of network file system support is a show stopper for me. I'm also taking some online classes including a couple in Java development, which means I can't use the Chromebook.

Not that I'm getting rid of it. I have given it to my wife. My young son also has one.

For $139 plus $20 or so for extra RAM it makes a wonderful backup system. Or one to grab and take with if you aren't going to be doing heavy development.

Wireless Networking

Journal: Wireless Video Streaming - Update

Journal by chill

Some while back I posted a journal entry about streaming video to my television from a central server in my basement. My conclusion at the time was wireless B/G/N couldn't really cut it when streaming via SMB over TCP.

I've experimented with a couple things and finally got it working where I can stream 1080p video (ripped BluRay) to my television via wifi. The difference was switching to the 5.0 GHz band (802.11 a/n) and changing the file share from SMB over TCP (Samba shares) to NFSv4.

NFS has less overhead than SMB over TCP and the wireless channels in the 5 GHz range are wider than those in the 2.4 GHz range.

So this setup now works for me without issues:

Small PC w/Via C7 chip acting as a server. Runs NFS and has copies (h.264 encoded as MKV) of all my movies, television shows and music (Ogg-FLAC). Connects to 10/100 wired switch in basement.

Zotac ZBox HD-11 running w/o a hard drive and booting OpenELEC off a 2 Gb SD card. Connects to home network via Cisco/Linksys WUSB600N USB wireless dongle on 5 GHz band (802.11 n).

I still have Samba running on the server so the couple of gaming PCs my kids have can reach the movie shares and perform automatic backups to private shares. I need to find a nice (free) NFS client for Windows 7. Suggestions?


Journal: Manna From San Francisco 1

Journal by chill

Back in 2003 Marshall Brain, founder of How Stuff Works, wrote a short novel titled Manna . It is an exploration at what increasingly looks to be the logical conclusion of the Industrial Revolution. If you haven't had the opportunity to read it before, I highly recommend it. It isn't long or difficult, but it raises some very interesting notions.

I mention it now because of the news out of San Francisco.

While not the same angle as Manna, it essentially is a big step down the same path. In 2012 there were over 4 million people employed in the fast food industry in the United States. What is going to happen to the country when they're almost all replaced by automation?

Thinking about the different jobs that can be done better, faster and cheaper by robots today is an interesting exercise. Contemplating which jobs will be better handled by automated systems in 20, 50 and 100 scary. Scary, that is, unless we fundamentally change the way we think about work, employment and the economy. I'm having a very hard time thinking of any jobs that can't be better done by robots than humans, including the so called "creative" ones, in 50 - 100 years.


Journal: Lies of Omission 6

Journal by chill

This is a duplicate of a post I made in one of the recent topics. I'm copying it here for easier reference as I send it to a couple friends.

* * *

So what exactly is metadata?

Many years ago I was a telecommunications engineer for a large company and worked CALEA. For the uninitiated, that is law-enforcement wiretapping.

My job was to make sure CALEA functioned properly on the new cellular network. We tested on an internal, micro-cell network that was isolated from the real world. The end result was to make sure targeted devices sent CDR (call data records, or metadata) and voice to the destination. This was all piped thru IPSec tunnels to the appropriate destination law-enforcement agency.

In the event of a tunnel failure, CDRs were required to buffer but voice was not. Saving voice during an outage required too much storage space, but the text nature of CDRs meant they were small and largely compressible.

Metadata consisted of EVERYTHING THAT WAS NOT VOICE.

To be clear, it included the following:

called number
calling number
time of call
duration of call
keys pressed during call
cell tower registered to
other cell towers in range
gps coordinates
signal strength
imei (cell phone serial number)
and a few other bits of technical information.

Everything above "cell tower registered to" applies to traditional, POTS land line phones. This information seems to be what the disinformation campaign currently going on seems to revolve around. They never mention that there are over 327 MILLION cellular phones in the U.S., which is more than one per person. They never mention the bottom set of metadata.

Capturing all key presses makes sure things like call transfers, three-way calls and the like get captured.

It also grabs things like your voicemail PIN/password, which never seems to get explicitly mentioned.

But the cellular set is more interesting. This data come across in registration and keep-alive packets every few seconds. This is how the network knows you're still active and where to route calls to.

But by keeping all this metadata it allows whomever has it to plot of map of your phone's gross location and movements.

By "gross", I mean the location triangulated from cell tower strength and not GPS coordinates. Towers are triangular in nature and use panel antennas. They know which panel you connect thru and can triangulate your location down to a few meters just by the strength of your signal on a couple different towers.

GPS coordinates are "fine" location. For the most part the numbers sent across are either zeroed out or the last location your phone obtained a fix.

GPS isn't turned on all the time because it sucks batteries down. If you own a phone you know how long it can take to get a fix, so this feature isn't normally used.

HOWEVER, it can be turned on remotely and is a part of the E911 regulations pushed to help find incapacitated victims after 9/11.

[There is a reason the baseband radio chip in your phone has closed, binary-blob firmware -- whether or not the OS itself is FOSS. We wouldn't want the masses to be able to disable remote activation, would we? Or let them start changing frequencies and power levels.]

So, are we comfortable with the government knowing where we, thru our cell phones, are at every moment of the day? Because that is what metadata allows.

Think of what can be learned by applying modern pattern analysis to that data set.

User Journal

Journal: Aphelion SciFi Fantasy Horror Poetry Webzine in 2013!

Journal by TaoPhoenix

Okay, here we go!

I shall post a promotional piece for the Science Fiction - Fantasy - Horror - Poetry webzine Aphelion.

It's been around since 1997. However we gradually lost the "regular" posters through attrition and we haven't undertaken much marketing at all. This post is "semi-unauthorized" aka ad-hoc.

This campaign:
You're one of two crews I would like to encourage to join and post a note about at least a couple of stories! They do have a focus on newer and developing writers, so go REAL EASY on the comments - if you see something that a writer could have improved, PLEASE work REAL HARD to soft-ball it!

As part of a bit of backstory that we don't need to visit here, in this somewhat fragile year it's important to get a couple of really nice newcomers, because there is a potential bit of culture clash. They do not have the Anonymous Coward theme with all that entails, nor are they in tune with our top 10 "inside jokes" such as Frosty Ps0t, You Insensitive Clod, In Soviet Russia, and many types of posts that dance around the Funny-Flamebait line here. Also be very careful with the FTFY and Grammar posts. It's true Mechanics do have a place in writing, but the usage tone culture here of those posts is generally too aggressive for Aphelion.

But y'all have modded me up a bunch of times, so I must have been interesting a few times at least, so let's really get all you geniuses to go give them the best ya got, 'cause you're all smarter than me!

This is the only High Volume promo web post I am doing right now, because it's one of only a few sites I have followed for all these years (somewhere about 8!), so I don't feel it's much to ask one Journal post to grab some of you who have been feeding me Chocolate Donut +1 upmods all these years.

I would love to get _____ number of really enthused new visitors who plan to stay for at least a few months. For a site the size of Slashdot, we'll get a decent few at a minimum, and if we have the cure for the Woes when y'all don't like This Hour's Story, we might get a lot! Let's go all KickStarter-y with some fun milestones.
17 - Just because I like the number 17, and the lowest non-insulting goal.
25 - Round Number
32 - How could we not include this one!?
50 - Round Number
64 - Another obvious one
75 - Round Number
But then it gets a bit scarce, until ...
100 - Round Number
128 - The Comp Numbers will get a bit thin in a min
200 - Round Number
256 - QuarterFinal Compy number
500 - Stretch Goal Round Number
512 - Stretch Goal Compy
1000 - Last Round Number
1024 - Last Compy number

I have no right to expect more than that so I'll start to reign all this in soon!

For you login-metrics fans, they put in an aggressive anti-spam measure in this year, but please don't go all Gamey on me and try to break it! It's meant for 4th rate twerps who went all CopyPasta at the Ragu Factory. Just play nice. But do holler to me if it causes any of you actual trouble getting in, and I'll give you a Secret Decoder ByteCoin. Signed by the Retired Lieutenant Taco Vendor from down the street. Or something.

The Lead intro page: - typically a graphic that changes for each issue
They do a "Flip" where the current month issue is on a "hardlocked" set of links by story/item category such as Short Stories. So if you get busy, and want to go back next month, they'll be gone (temporarily!) and replaced by the new issue. There's a big topic in Archives, but that's another day.

The intro Editorial by the senior editor:

Short Stories:


"Features:" - most usually an instructional article on writing but a few other things sometimes

I would appreciate it if interested people would drop a note here too, just to close the loop so I both know who is headed over there, but also for the data check of that signup-test.

On the first two posts over there (because any single one might vanish from visibility because I am turbo posting this week!) to mention that me, Tao sent you from Slashdot. Plus it's an excuse to Cross Brand and all those other fun business terms! Go Slashdot! (Hi Dice!)

Watch the horde of smart people show up and impress the hell out of them!


Obligatory disclosures etc.
I am the Archives Editor over there, a position which involves fluidly evolving things generally oriented around fiddling with info about the magazine issues, rather than actually writing stories for them.

I apologize for the "soft links" because I don't know how to make them Clickable. But then I told ya y'all were smarter than I am!


Journal: Experiments in Raspberry Pi

Journal by chill

I've noted before that I have a media library setup. All of my media -- movies, TV shows, music, audiobooks -- are stored in digital format on a small server in my basement.

By "server" I mean a VIA-based mini-ITX box with 2 Tb of storage connected to my home network. For future reference, I wouldn't use a VIA-based motherboard again simply because they don't have USB 3.0 ports. Backing up 1+ Tb of data via USB 2.0 can take an entire day. Adding a USB 3.0 PCI card helped, but only a bit as the PCI bus is too slow to fully utilize USB 3.0 speeds.

Connected to the back of my television by a VESA mount was a Zotac Z-Box HD-ID11 acting as a playing device. The Z-Box has no hard drive and boots OpenELEC off of a 4 Gb SD card. It does have a CPU fan which hums softly, but really can't be heard except at night, when all is quiet. Setting a sleep timer on the system fixes that.

I've been scrupulous about ripping all my video using h.264 as a video codec. Everything under the sun has hardware-assisted h.264 playback, so it plays flawlessly everywhere.

In looking for a second system, I wanted something cheaper and smaller than the Z-Box and the Raspberry Pi seemed to fit the bill.

The Pi model B is $35. The VESA case is another $10, Transcend 4 Gb Class 10 SD card was $8, compact 4Gb USB stick was $10, and the HP Touchpad USB power charger was $20.

Why the HP Touchpad charger? Read this article comparing quality of various USB chargers for details.

Add it all up, throw in shipping and it was almost $100 on the nose. Oh, I reused my existing HDMI cable.

Installing OpenELEC on the Pi is trivial. Download the image, move the image to the SD card, boot. It worked the first time, no issues.

The results are where things get interesting. Thanks to the hardware-acceleration, video playback of everything from animated TV show rips to the latest 1080p BluRay rip was flawless.

Audio is a different story. The Pi doesn't have the chops to properly decode Dolby DTS/AC3 in CPU. While there is hardware-accelerated decoding on the ARM chip, it isn't licensed and thus disabled. The Pi people are working on being able to sell DTS licenses like they do for MPEG-2 and VC-1, but it will take some time.

So, for the high-definition audio streams you need to set OpenELEC to "passthru". Unfortunately my TV is one of the cheaper models and doesn't do DTS either. I need to get an AV receiver that can handle it. Until then (or the codec issue is resolved) a few of my BluRay rips are silent.

The real problem came not from video playback, but from the OpenELEC interface itself. No hardware-assist for X-Window to it is slower than molasses. Unusable in my opinion. Unusable without tweaking, that is.

Tweak 1: Update firmware on Raspberry Pi. A few changes were made and it helped speed things up a tad.

Tweak 2: Overclock the system. The Pi normally runs at 700 MHz. There is a simple text config file you can change that is read on boot. I've successfully overclocked to 900 MHz (ARM) / 333 MHz (Core) without issues. This made a noticeable difference.

Tweak 3: USB cache the data partition. While OpenELEC runs in RAM, the database of shows, thumbnails, cover art and all the rest reside on the SD card. And no matter how fast they claim to be, SD cards are slow compared to everything else. By creating an EXT4 partition on a small USB thumb drive and pointing OpenELEC at that, speed was greatly improved. Now the system boots off of the SD card (a limitation of the Pi) but runs off a USB stick.

Tweak 4: Turn off the per movie, full-screen background art. This just saves the lag of loading a full-screen art image for each movie title you scroll across. I never really noticed it before, so I'm not missing anything.

Tweak 5: The Pi has unified memory, meaning the CPU and GPU share the same RAM. Memory dedicated to the GPU is specified at boot in the cmdline.txt file. I upped it from the default of 128 Mb GPU (384 Mb CPU) to 192 Mb GPU (320 Mb CPU). I do not know if this did anything or not. I need to figure out a way to test it.

Fix 1: In the same config file where you overclock, I set "force_hdmi=1". The Pi has both an HDMI and composite video out. If it detects an HDMI connection, it will output to that. If not, it defaults to composite. So, if you use HDMI and reboot the Pi with the TV off, it'll default to composite and you'll need to reboot again. This way it just assumes HDMI always and I never have to worry about it. Of course, once I stop fiddling with it there will hardly ever be a reason to reboot. If it ain't broke...

Final tweak: Patience of a Zen Master. My media collection consists of well over a thousand pieces -- movies, TV episodes, cartoons, etc. OpenELEC goes through and updates the library, downloading what information it can from TheTVDB and TheMovieDB including various cover art. It caches it in the storage partition (thus the USB tweak above), but doesn't resize the downloaded artwork until display. As a result, when scrolling through a big library there are noticeable delays and missing artwork. Once cached it works fine. Until then, it is frustratingly sluggish. However, this took me an entire weekend of off and on attention to accomplish.

The end result of my experiment is that the Pi is usable for a large media library running OpenELEC. There can be a little lag of a second or so when switching screens from Home to, say, Weather or Movies, but not so much I'm bothered.

Before the tweaks it was unusable and I was looking for something else to use the Pi on. Now I'm happy.

One final note. I've always found streaming HD video over WiFi a waste of time. It never really worked for me. Right now my server is on a GigE switch and I have CAT-6A running to everywhere in the house. Still, I want options.

I use Samba to share stuff from the server and that has excessive overhead from what I've read. I just added NFS sharing and swapped the Pi over to that. My next step is to unplug the wire and see if I can now successfully stream via wireless.

User Journal

Journal: New Gun, New Ammo 18

Journal by chill

One of my hobbies is pistol shooting. I punch various sized holes in paper targets at a distances of up to 25 yards. One day I hope to have enough free time to try actual bullseye competition and not look like a total noob.

As good guns are not cheap, for now I only keep one at a time. Since I also want the gun to be available for self-defense, if needed, it has to be practical for concealed-carry as well.

So, for the last several months I've been shooting a Springfield XD-S. That is a single-stack, small-frame, .45 ACP and a marvel of modern gunsmithing. I love the gun and was loathe to part with it, but sell it I did.

The XD-S has basically two flaws, depending on how you look at things. The first is the grip safety.

The grip safety is a small lever on the back of the grip that must be depressed for the gun to fire. Combined with the trigger safety, you must grip the gun just right or it won't fire. Once you get used to it, it works fine. But if you have to draw in a hurry, such as in a defense situation, it can present problems.

Also, if you have soft webbing between your thumb and forefinger, it won't always depress the safety -- as my daughter found out. Her hands are soft and she had no end of problems getting a tight enough grip to depress the safety. Nothing that a little duct tape can't fix, but I don't like disabling safety mechanisms.

As an aside, the safety configuration makes the gun physically impossible to fire for a small child. This is, of course, a benefit. I'm of the opinion that there should be almost no circumstance EVER that a small child should be trying, but in the case of the worst there is an extra layer of safety.

I say "almost" because in order to test the safety of the gun around my bigger-than-average, soon-to-be 5 year-old child, I unloaded it and had him try a couple of things.

Strong as he is for his age, he was physically unable to rack the slide and thus not load a round into the chamber. Once racked by me (but NOT loaded, duh), he was physically unable to grip it properly to get it to fire. Nothing he did could make it go "click". The wife was appeased.

The second drawback is really a matter of perspective. It is a .45, which is a damn hand cannon. It has a fairly large bullet, will make a very loud bang, and punch a damn big hole in whatever you're aiming at.

And if you run 250+ rounds through it at the range your wrist will need iced and feel like you were punching cement blocks for fun.

What most non-shooters don't understand is that it really isn't so much the size of the round that causes recoil, but the size of the gun. Physical size, that is.

So, while a .45 ACP has a kick, it is much lessened in the traditional 1911-format big pistol. The mass of the gun absorbs a great deal of the recoil and your wrist bears less of the brunt of it.

With the XD-S, that mass isn't there, as 609 grams empty. A stock 1911 is closer to 1,100 grams. As a result, unless you have wrists like Popeye, or are a duty officer who puts several hundred rounds a month through a big-bore pistol, you'll feel it.

This really comes into play with women looking for purse pistols. They gravitate straight to the little .380 ACP pocket guns because of the size, not realizing that even though the .380 is a smaller round that smaller gun (260 grams) is going to kick more than the same round in a full-sized model.

To make a long story short (too late!), it isn't a fun gun to shoot. If you're looking for a backup pistol where you don't have to worry about pesky things like windshields, car doors, or drywall deflecting your shots, this baby is it. If you're looking for something to squeeze off a few hundred at the range, it isn't.

So, off to my local FFL dealer to consign the gun. It lasted less than 24 hours. :-)

In choosing a replacement, besides everything above, I also considered the possibility of over-penetration. If, God forbid, I have to use the thing in a self-defense situation, I don't want the bullet blowing through my target and into some hapless bystander.

So, back down the caliber ladder to 9 mm I went, ending up with a Ruger LC9. The astute among you will notice I picked another single-stack. My hands are a little small and I don't feel comfortable with double-stack grips, which means I don't consider anything by Glock.

At about 500 grams, it is still a bit small, but with 9 mm ammo ranging in mass from 68 - 125 grains (4.5 - 8 grams) it is much more in the "fun" category to shoot. I just stay away from +P ammo, as I never saw the need for the extra kick.

So, new gun in hand, I wanted to go to the range and put it through its paces. Unfortunately, we're in the middle of a nationwide shortage of pistol ammunition and after TWO WEEKS of not being able to buy a single round, I was able to pick up a couple of boxes of TulAmmo at my local Walmart.

TulAmmo is as cheap (cost) as it gets. A box of 50 rounds is about $10. The main difference is the bullet casings are steel instead of brass. Oh, and it is made in Russia. Yes, all I could find were Russian-made bullets. Ronald Reagan must be spinning in his grave. :-)

Google that stuff and all you get is warnings about how dirty, corrosive and prone to misfire it is. Nothing but complains.

Well, it was all I could find and I wanted to play with my new toy, dammit! So, 150 rounds in hand, I went to my local range to see what would happen. I picked up an extra 100 rounds of Winchester USA 9 mm 115 gr FMJ at the range itself to compare.

Short answer, it performed flawlessly. In 150 rounds I had no misfires, jams or failures to eject. The brass-cased Winchester had 1 failure to eject and one jam loading, which is actually pretty good. I've had some other brands that have exceeded 15% misfire rates, which is totally unacceptable.

As soon as I can get it in, I'm going to try some various defense rounds to see what I like the feel of. I have both frangible and high-expansion JHPs from a variety of manufacturers on order. I'm really wanting to see the difference in kick between the 68 grain frangible and the 125 grain JHP.

Once done and home, I disassembled the pistol for cleaning. I did not find it any dirtier than my XD-S was after the same number of "Made in USA, brass-cased, name-brand, factory new" rounds. In fact, I think it was a little cleaner, but that may be because of the smaller load of the 9 mm vs the .45 ACP.

So, I'm off to Walmart to see if they have any more in stock. I want to run 1,000+ through the gun to break it in and get a feel for it and at $10 a box (half of most competitors), TulAmmo is what I'll be shooting. I re-evaluate after the first 1,000 rounds.

I've got all the money I'll ever need if I die by 4 o'clock. -- Henny Youngman