I was reading the backlog of the Fedora development mailing list and came across a post in which Richard Hughes made a very interesting comment:

I know lots of Red Hat developers worn down by the low-level harassment on this mailing list, so much so, that they just stop pushing the boundaries and go work on something else cool, e.g. ChromeOS.

I’ve been following this particular mailing list for many years, and the sad thing is, I think he’s right. There’s this underlying current of “us versus them” that can pop up, especially in longer-running threads, and “them” is someone with a @redhat.com email address.

On some levels this makes sense. Red Hat is the single largest entity in Fedora and many (if not most) of the movers and shakers in Fedora are Red Hat employees. A quick glance at the Fedora 21 System Wide Changes shows many more Red Hat employees than not. Is it any wonder that individual contributors can feel a bit like a sailboat in the way of an aircraft carrier?

So, is this some conspiracy to keep Fedora under Red Hat control? Is it something we should fight against? Or is there a reasonable explanation for Red Hat’s influence?

First off, there’s the question of whether people are hired at Red Hat to work on Fedora or whether they’re hired because of their work on Fedora. I had the opportunity at Devconf earlier this year to sit down with Patrick Uiterwijk, who did most of the work on Fedora’s OpenID provider, and was then hired by Red Hat because of that work. Patrick’s is not the only story like that. While not all competent Fedora contributors are Red Hat employees, Red Hat employees who contribute to Fedora are generally pretty darn competent, and competency in Fedora is rewarded with influence.

There’s also the fact that Red Hat pays people to work on Fedora. Many individual contributors are working on Fedora in their spare time. While this doesn’t necessarily affect the quality of their work, it does tend to affect the quantity. To give an example, at DevConf, I also talked with Stephen Gallagher about joining the Fedora Server working group. After DevConf, I signed up for the mailing list and then did… nothing. I’m the sysadmin and a teacher at my school, and at home I’m a husband and father of four children under six. While I have great intentions of helping out with the Server working group, it’s just not high enough on my list of priorities for me to have the time… and I suspect I’m not the only individual contributor in that boat.

Finally, there’s the fact that Red Hat’s employees actually get to know each other, at least to some extent. One of the big things I’ve learned in my years working here in Lebanon is the importance of relationship. It’s a lot easier to work with someone after you’ve sat down with them, had a coffee (or, in my case, a Coke) and chatted. This was the main reason I enjoyed DevConf and one reason I really wish I could make one of the Flock conferences.

So where does this leave us? Red Hat does have a large influence on Fedora. It’s not a conspiracy, it’s life, and attacking Red Hat employees because of its influence is counterproductive.

So, going back to Richard’s original message, we need to stop tearing each other down. When people speak, let’s assume good faith, and not assume that any ideas we disagree with will spell the end of Fedora, Linux or the world as we know it. Most of all, we need to make a conscious choice to value each other, even when we disagree.

Have a great 2015!

While we were on vacation back in the States during the summer, our camera started doing strange things with the flash, so we decided it was time to get a new one. After much reading and debating, we settled on the Samsung NX300M. It’s been a major step up from our old point and click, and we’ve enjoyed the quality of the shots a lot.

Being the nerd that I am, I started wondering what OS powered the camera and whether it was hackable. After doing some in-depth research (typing “hack NX300M” in Google), I came across these two fascinating articles about the NX300. Basically, any code that you put in autoexec.sh in the root directory of your SD card will be run as root during camera bootup. I immediately tried to make my own autoexec.sh on my NX300M, but, unfortunately, it didn’t work. After some experimentation, I found that the initial firmware for the camera (1.10) does run autoexec.sh, so I downgraded my firmware and got to work.

I decided to make the killer app for a Wifi-enabled camera (at least, I think it’s a killer app). The NX300M can do some pretty cool things with its built-in Wifi like acting as a hotspot so it can send pictures to your phone. It can also do some form of automatic backup to your Windows desktop, but, as we don’t have any Windows systems in our house, I was unable to try it. The annoying thing about the Windows automatic backup feature, though, is that you have to manually switch to the Wifi setting and choose “Auto Backup” to run it. If I’m going to be doing automatic backups from my camera, I want it to be truly automatic, oddly enough. And I want it to backup to my wife’s laptop, which is running Fedora, preferrably using a secure copy method like rsync over ssh or scp.

I spent several days trying to work out how to make this all work, and here are some notes from my attempt:

• There is one root filesystem and two support filesystems, all running ubifs.
• The root filesystem is read-only, and, though I can remount it as rw, any writes seem to go to /dev/null. I don’t understand ubifs enough to know whether this is expected behavior.
• The NX300M seems to be running the same ancient version of Tizen that the NX300 is, with a couple of proprietary binaries that do all the heavy lifting. Pretty much everything that Georg wrote about the NX300 in the above pages applied to the NX300M.
• Working out how to start Wifi from autoexec.sh was very difficult. The NX300M uses a very old version of connman plus a funky daemon called net-config to actually power up and down the Wifi card. Neither has a cli tool available on the NX300M to control it, and each can only be controlled via dbus. Running dbus introspection on net-config causes the camera to reboot. Who knew?
• /dev/log_main has a log of pretty much everything, including dbus commands. This is what I used to figure out what commands I needed to use to get the Wifi up.
• The NX300M comes bundled with an SSH client (though no SSH server), which makes the backup method pretty simple.
• Tizen has a power manager that’s run by the NX300M, but I’m not sure whether it’s actually being used. It appeared to me from the logs that the proprietary UI app was turning off the display and then the camera. To keep the camera from shutting off during the automatic backup, I ended up using xdotool to send keypresses to the UI. Yes, that’s ugly.
• The UI understands the concept of time zones, but everything at the OS level is in UTC, and, at least as far as I can tell, the camera treats the UTC time as if it’s the current time zone.
• There is a rtc on the camera, but it doesn’t seem to support wakeup events. 🙁

So, in the end I was able to put together a script that runs on boot that checks for any new pictures and, if there are any, connects to our Wifi and scp’s them to my wife’s laptop. It then appends the filename to a hidden file in the DCIM directory on the SD card that keeps track of which files have been copied across. If my wife decides to rename the file or the folder it’s in, I don’t really want to send the picture across again.

I’m releasing my code under the GPLv2+, and it’s available on GitHub. I hope somebody finds it useful.