Process Identifiers (PIDs) are a scarce resource. On Linux they are only 15 bits by default. The Process Identifier Preservation Society (PIPS) aims to reduce abuse and wastage of the PID space. To join the society please read the following advice.

Common issues Several languages generally allow you to run all your code in one process. Some of the code that you might want to incorporate or use is not available in the form of ELF libraries or language specific libraries but only in the form of ELF binaries or interpreted scripts. As a result using additional PID space is sometimes unavoidable. Many languages have multiple methods of starting external processes and usually some of them waste PID space by running commands in a shell. You can avoid those methods or use the exec builtin to preserve the shell PID. It might be tempting to explicitly use shell in languages that don't allow implicit shell use but that just wastes extra PIDs. Several languages allow you to fork one process into two, this uses an extra PID and is to be avoided unless necessary.

Shell Programs written in the shell languages use a lot of PIDs. Even shells that have a lot of shell builtins (like busybox sh) appear to use the PID space by forking a child process. To join PIPS you should just stop writing programs in shell or use as many builtins as possible and use exec to preserve PIDs.

Init Several init systems are written in or use shell extensively and thus eat huge bowls of PIDs for breakfast. To join the PIPS you should switch away from sysvinit, openrc, init=/bin/sh etc.

C/C++ The common issues section applies to the C/C++ language. To join PIPS you should rewrite your code to use fork()+exec(), g_spawn*() or libpipeline instead of the g_spawn_command_line*(), system() and popen() functions.

Perl The common issues section applies to the Perl language. To join PIPS you should rewrite your code to avoid backticks and only pass arrays to the system(), open(), open2(), open3() functions.

PHP The common issues section applies to the PHP language. To join PIPS you should rewrite your code to use pcntl_exec() instead of backticks, exec(), system(), passthru(), shell_exec(), popen() and proc_open(). Apparently pcntl_exec() is disabled by default on Debian and pcntl_* are often unavailable so you should just not spawn processes. You could also just drop PHP already.

Python The common issues section applies to the Python language. To join PIPS you should rewrite your code to use the subprocess module and avoid passing shell=True to the subprocess.Popen() function. The os.system(), os.popen() functions and the commands module all run their commands in a shell, wasting PID space. The popen2 module requires passing arrays instead of strings in order to avoid the command being run in a shell.

Java The common issues section applies to the Java language. To join PIPS you should rewrite your code to use ProcessBuilder or only pass arrays of strings to Runtime.getRuntime().exec().

Haskell The common issues section applies to the Haskell language. To join PIPS you should only ever pass a RawCommand to createProcess and never use the shell, system, runCommand or runInteractiveCommand functions from the System.Process and System.Cmd libraries.

OCaml The common issues section applies to the OCaml language. To join PIPS you should rewrite your code to use fork+exec or the create_process* wrappers instead of system, open_process, open_process_in, open_process_out and open_process_full.

Go Go allows running external processes but doesn't allow you to waste PID space by running commands in shell. Avoid explicitly running the shell though.

Rust Rust allows running external processes but doesn't allow you to waste PID space by running commands in shell. Avoid explicitly running the shell though.

Erlang The common issues section applies to the Erlang language. To join PIPS you should rewrite your code to use erlang:open_port( spawn_executable, ... , ...) instead of os:cmd or the other options to erlang:open_port.

Node.js The common issues section applies to the Node.js language. To join PIPS you should rewrite your code to use the child_process.execFile() function (or other child_process functions) instead of child_process.exec().

Julia Julia allows running external processes but doesn't allow you to waste PID space by running commands in shell. It emulates a lot of shell features instead. Avoid explicitly running the shell though.

Dart The common issues section applies to the Dart language. To join PIPS simply do not enable the runInShell parameter of the Process object.

PS Let me know if I missed something in one of these languages. You should also do most of the above to avoid shell metacharacter injection attacks that usually allow arbitrary code execution. Dear language authors, don't allow running external processes in shell, kthxbye!

As an introvert I like - well, I need to - spend time alone. I get my best ideas on my own. But when I truly thrive is when I am connected with others, cocreating. For the last couple of weeks it's been difficult for me to work on the visual design for the MiniDebConf in Barcelona next month. There have been practical reasons, but the real reason was that I was feeling stuck and overwhelmed. Sharing my uncomfortable feelings with my boyfriend finally made me able to see that I have been feeling alone, and feeling that I had to prove myself with my work. I felt disconnected from the people in Debian I want to cooperate with. I'd really benefit from sharing my thoughts and ideas more with others. The unpleasant feeling of "stuckness" dissolved when I said out loud what they were about, and ideas for changing my state appeared. Now I've started hanging out on the irc-channel more, I've asked for help in finding stuff in the huge pile of info, rules and previous examples and experiences at debian.org and my decision to blog and share more is strengthened. Finally the work has begun. Conferences are about meeting up and getting connected. Listening to somebody trying to enlighten you on a subject. Getting inspired. And so my idea of using speech bubbles as a visual identity koncept for the conference has everything to do with my own experience of connection and disconnection. Release, early, release often, I cannot say that I have done that. We really need the peoposals to be ready now. Thankfully I'll have time in the following days to get feedback and finish. I really hope people will accept the idea, but I'm expecting a debate.

(Or "Today's yak shaving exercise") I'm trying to get back into some Debian work today, which involved trying to send an email from my laptop, relayed through daedalus, which is in a colo facility. Then I started shaving my yak. daedalus rejected the email, because the relay attempt wasn't authenticated. It wasn't authenticated because Exim on my laptop wasn't happy about the Diffie-Hellman parameters Sendmail on daedalus was advertising, and had failed STARTTLS, and like a sensible person, I only allow encrypted authentication. Along the way, I figured I'd need to address the fact that the host certificate has expired long ago (truth is, I probably just needed to fix the Diffie-Hellman parameters file), but my whole CA certificate expired over a year ago. I couldn't find the encrypted USB key with my CA on it, so I decided to cut my losses and start from scratch. It's good to see OpenSSL hasn't got any more user friendly with time. I futzed around and generated a new CA key and certificate, a new CSR for Sendmail, signed it, did the appropriate sacrifices, and confirmed that STARTTLS now worked using OpenSSL s_client. Still couldn't send an email. Still had some bleating in the Exim logs:

2014-02-17 11:29:26 1WFD1M-00086p-KI TLS error on connection to daedalus.andrew.net.au [203.33.60.161] (gnutls_handshake): The Diffie-Hellman prime sent by the server is not acceptable (not long enough).

Back on daedalus, /etc/mail/tls/sendmail-common.prm has been an empty file since time immemorial. I managed to find something in Google's cache suggesting I should put something in it with openssl dhparam -out /etc/mail/tls/sendmail-common.prm -2 1024 I initially went for 4096 bits, because it must be better, right? I'm still waiting for the key generation to come back, while I'm writing this. At least it warned me in advance it was going to take a long time. How thoughtful. What would be more thoughtful was verifying the write permission to the file before the long operation so it could fail fast, rather. Sigh. I ended up giving up on 4096 and sticking with 1024, because I was getting old waiting. Yak shaved, I can send mail from my laptop now.

Let s assume you are a sysadmin and have to debug a daemon giving bad performance on one machine, but not on the other. Of course, you did not setup either machine, have only basic knowledge of the said daemon and would really love to watch that awesome piece of cinematographic art with a bunch of friends and a couple of beers. So it s like every day, right? The problem with understanding running setups is that you often have to read configuration files. And when reading one is not enough, you have to compare two or more of them. Suddenly, a wild problem occurs: order and indentation do not matter (unless they do), comments are often just beautiful noise and why the hell did that guy smoke/drink/eat while explicitly setting ALL THE OPTIONS to their defaults before actually setting them as he wanted. If you are using diff(1), you probably love to read a lot of differences, which are none in reality. Want an example? [foo]
bar = bar
foo = foo and # settings for foo
[foo]
# foo is best
foo = foo
# bar is ok here, FIXME?
bar = bar and [foo]
foo = x
bar = x
[foo]
foo = foo
bar = bar are actually the same, at least for some parsers. XTaran suggested using something like wdiff or dwdiff, which often helps, but not in the above case. Others suggested vimdiff, which is nice, but not really helpful here either. As there is a problem, and I love to solve these, I started a small new project: cfgdiff. It tries to parse two given files and give a diff of the content after normalizing it (merging duplicate keys, sorting keys, ignoring comments and blank lines, you name it). Currently it can parse various INI files, JSON, YAML and XML. That s probably not enough to be the single diff tool for configuration files, but it is quite a nice start. And you can extend it, of course ;)

0 comment(s) this blog is flattr enabled

Today as it was raining and I couldn t do much gardening, psmisc version 22.21 was released. The files are located up on sourceforge at https://sourceforge.net/projects/psmisc/files/latest/download or at your favorite distro repository soon. Once again, thanks to all patch submitters, bug reports and translators for all their help in getting this out. Apologies to the translation teams for having two alpha versions. So what does psmisc 22.21 bring you? Amongst a lot of minor bug fixes it has:

• If you started a process and then spawned some threads and then decided to change the names of the threads, pstree would show the old name, it now shows the correct new name
• pstree has a new flag (-N) for namespace support, thanks Aristeu for the patches
• Previously fuser -M flag only worked if it was before -m, now it can be either order

The Debian psmisc package should be out in the next few hours.

An issue which I always find depressing but sadly unsurprising in discussions of process with software is the frequent disregard for human elements; indeed often the goal people have in creating process is to try to control and eliminate human elements. Little thought is given to what is going to motivate people to do what s asked and if they are going to follow it at all, or in the spirit it was intended. One example I ve seen several times is the idea that some engineers work on irrelevant things and that this can be fixed by requiring every commit to be tied to the project plan or a bug so off project work is obvious. This isn t really attacking the problem so much as putting a roadblock in place to try to avert it; the real problem is normally people not communicating about what they re doing and what s important but those problems are really hard to address. Sadly what tends to happen is that people work around the roadblock and cause some collateral damage; for example devaluing the bug tracker by referencing irrelevant bugs or creating meaningless bugs solely to allow commits, while continuing to behave like they did originally. This is often worse than the original situation. This sort of issue is one of the things I appreciate most about working on Linux there s quite a bit of process but because of the way it has been evolved the incentives are usually right to make sure they are followed in the spirit in which they were intended. For example the patch submission process is essentially just best practices for making sure changes go to people who care in a form which makes it easy for them to work with it; there is a bunch of tooling around it which built on those practices (and in turn influenced the practices) but it all comes back to that basic thing of getting attention for changes and making them easy to work with. As a result people mostly do the right thing (or close enough) so everything runs smoothly. The trick is to remember to standardize and write things down when it s needed notice the good practice and spread its adoption. The key difference here seems to be if process is viewed as something to solve problems for people or if it is viewed as a way to solve problems with people. If the problem is with the people then the view starts off negative and it s perhaps unsurprising that there is little consideration of how they will react. Sometimes it s not so much that a problem is seen with people as that the people doing don t have any real interest in the process (write only timesheets often bear no relation to reality for example) but there is an assumption that they are going to just do what they re asked (but instead they for example don t fill in their time sheets or don t provide accurate information). The end result is the same, their needs don t get considered and their actions end up being counterproductive. Starting to avoid these problems is fairly straightforward take a step back and consider why the people expected to carry out the process are going to want to do so. How does it help them? How will they see it helping others? Generally what s in it for them? If these are difficult questions to answer then there may be a problem it is likely people will ignore the process or do it badly without a lot of active enforcement, but perhaps that s OK for the situation. Beware of using metrics to provide incentives, metrics are gameable and that game can cause problems without care. But do think about people; making software is all about people.

I've started backporting some Perl modules to wheezy-backports - for starters, libbread-board-perl, which is now waiting in BACKPORTS-NEW. At work I've recently been trying to automate the deployment of our platform, and was originally trying to use Carton to manage the CPAN dependencies for us. It seems like it ought to be possible to make this work using CPAN-only tools. However, in practice, I've seen two strong negatives with this approach:

• it's a lot of work for developers to manage the entire dependency chain, and
• it takes forever to get the environment running.

Consider, when you spin up a fresh VM, you need to build Perl from source, and then compile every CPAN module you depend on. This includes all the modules needed to run all the test suites. That's not going to be fast. All that, and you still need a solution that works with the distro's package management, because you still need to install all the build dependencies. So, I'm trying a new approach - if someone else benefits from the packages I backport, even better.

This is the 2nd point release of OpenStack Havana (this is the name of the current stable release of OpenStack). It was out on Thursday (US time), and I uploaded it on Friday (Chinese time). Unfortunately, I realized that the latest python-keystoneclient didn t support the token and endpoint command line options, effectively breaking Keystone itself, and all automated endpoint registration in all core packages. So after fixing Keystone and openstack-pkg-tools, I had to re-upload a 2nd Debian release. However, after this glitch, the packages passed successfully our CI testing suite: my friends at eNovance and I run the tempest functional test suite each time there s this kind of major update, so that we can validate the packages are working as expected. And all went well after the new keystone command line options were fixed in the postinst scripts. As a side note, I fail to see consistency on deprecating these interfaces. While we still have the old glance index thing in the Glance client (this is really old), keystoneclient just broke backward compatibility, when keystone is quite recent. So, it looks to me that it wasn t a great idea to just remove token and endpoint this way (though I can understand the need of consistency). Hopefully, this will all be fixed anyway, when we move to the unified python-openstackclient command lines instead of per-project clients. I realized today that the pkg-openstack team now maintains more than 100 packages. This of course includes general purpose Python modules, which probably will move to the Python module team if it one day supports Git (life is too short: I do not wish to learn such a deprecated technology as SVN). Though this is still a lot of packages, and some more are coming: as per the OpenStack TODO list wiki page, Ironic (a replacement for nova-baremetal), TripleO (OpenStack on OpenStack), Tuskar (contols where things are deployed with TripleO) and Designate (DNS as a Service) are already packaged, and I am waiting for the Icehouse (this is the name of the next stable release) beta3 to be out to upload them to Experimental. This is scheduled for the 6th of March. I believe I am currently nearly up-to-date with the current global-requirements.txt (eg: python dependencies of OpenStack), pending a few Python module upgrades, so hopefully, packaging OpenStack Icehouse beta3 will smooth.

After so many attempts to have my shiny Movistar Peru (Internet M vil) 3G ZTE MF193 modem to work out-of-the-box in Debian jessie (unstable) with NetworkManager, the word frustration was hitting on my head. Even trying to do the right thing, led me to craziness. I gave up on fanzines and decided to take the old-school route. Release wvdial and friends! Trying different combinations for wvdial.conf was no heaven for sure, but I ve found this wonderful guide from Christian Ams ss from Vienna, Austria! that really made a difference. Of course he s talking about the MF180 model but you get the idea. So I m sharing what was different for the MF193. Basically, I ve done the eject and disable CD-ROM thing already, but still no progress. I ve also tried using wvdial to send AT commands to the evasive /dev/ttyUSBX device. Starting from scratch confirmed that I ve done such things properly indeed. I was amused by the fact that I could use screen to talk to the modem! (yo, all the time wasted trying to have minicom and friends play nice) So, let s get to the point. After following this procedure, you should be able to use NetworkManager to connect to the Interwebs using the 3G data service from Movistar Peru.

1. Step 1 follow the guide
2. Step 2 Here I had to use /dev/ttyUSB4
3. Step 3 follow the guide
4. Unplug your USB modem
5. Plug your USB modem. This time you should see only /dev/ttyUSB 0,1,2 and /dev/gsmmodem should be missing (not sure if this is a bug). Now /dev/ttyUSB2 is your guy.
6. Step 4 use /dev/ttyUSB2
7. Run wvdial from CLI it should connect successfully.
8. Stop wvdial
9. Select the Network icon on GNOME3, click on the Mobile Broadband configuration you have, if not create one.
10. Voil . Happy surfing!

I m pasting my wvdial.conf, just in case.

[Dialer Defaults]
Modem = /dev/ttyUSB2
Username = movistar@datos
Password = movistar
APN = movistar.pe
Phone = *99#
Stupid Mode = 1
Init2 = AT+CGDCONT=4,"IP","movistar.pe"

I ve been hacking (on and off) on a small bit of code (written in Hy) called Acid. So, all of this is *really* fluid, and I m going to change it s API and code (it s currently just one massive hack), but I think the idea has kinda jelled enough for me to chat a bit about. Acid is a DSL for writing event-driven Hy. Currently it s just using global events (that ll change soon), and it s a monumental hack (not sure how much I can do there), but it works pretty well. It s built on top of tulip / asyncio, which is an amazing new Python 3.4 standard library package for working with async code. Although asyncio is designed around network-based usecases, I ve been trying to shoehorn in an event system on top of it. It s going well so far. A basic Acid script looks something like:

(trip
  (on :startup
    (every 1 second (emit :clock-pulse nil)))
  (on :clock-pulse (print "."))
  (emit :startup nil))

which will print a dot ( . ) every second forever. Something a bit more advanced (fetch the MBTA Red line T information once a minute forever)

(defn get-endpoint-url [line]
  (.format "http://developer.mbta.com/lib/rthr/ 0 .json"
    (get  :red-line  "red"
          :blue-line "blue"  line)))
(trip
  ;; OK. Let's do some work with MBTA feeds.
  (on :update-feed
      ;; let's just update feeds on a cron.
      (print (.json (.get requests (get-endpoint-url event))))
      (emit :feed-updated event))
  (every 1 minute
         (emit :update-feed :red-line)))

Clearly, both of these examples are just as clear as their straight functional counterparts, but I m keen to see what I can do with temporal recursion for long-running daemons. I think my first job will be porting snitch's codebase to Acid. Let me know if you have any ideas!

Recently I started doing a internet-wide scan for rsync servers, thinking it might be fun to write a toy search-engine/indexer. Even the basics such as searching against the names of exported shares would be interesting, I thought. Today I abandoned that after exploring some of the results, (created with zmap), because there's just too much private data out there, wide open IP redacted for obvious reason:

shelob ~ $ rsync  rsync://xx.xx.xx.xx/
ginevra        	Ginevra backup
krsna          	Alberto Laptop Backup
franziska      	Franz Laptop Backup
genoveffa      	Franz Laptop Backup 2

Some nice shares there. Lets see if they're as open as they appear to be:

shelob ~ $ rsync  rsync://xx.xx.xx.xx/ginevra/home/
drwxrwsr-x        4096 2013/10/30 13:42:29 .
drwxr-sr-x        4096 2009/02/03 10:32:27 abl
drwxr-s---       12288 2014/02/12 20:05:22 alberto
drwxr-xr-x        4096 2011/12/13 17:12:46 alessandra
drwxr-sr-x       20480 2014/02/12 22:55:01 backup
drwxr-xr-x        4096 2008/10/03 14:51:29 bertacci
..

Yup. Backups of /home, /etc/, and more. I found numerous examples of this, along with a significant number of hosts that exported "www" + "sql", as a pair, and a large number of hosts that just exported "squid/". I assume they must be some cpanel-like system, because I can't understand why thousands of people would export the same shares with the same comments otherwise. I still would like to run the indexer, but with so much easy content to steal, well I think the liability would kill me. I considered not posting this, but I suspect "bad people" already know..,

I ve written a lot lately about ZFS, and one of its very nice features is the ability to make snapshots that are lightweight, space-efficient, and don t hurt performance (unlike, say, LVM snapshots). ZFS also has zfs send and zfs receive commands that can send the content of the snapshot, or a delta between two snapshots, as a data stream similar in concept to an amped-up tar file. These can be used to, for instance, very efficiently send backups to another machine. Rather than having to stat() every single file on a filesystem as rsync has to, it sends effectively an intelligent binary delta which is also intelligent about operations such as renames. Since my last search for backup tools, I d been using BackupPC for my personal systems. But since I switched them to ZFS on Linux, I ve been wanting to try something better. There are a lot of tools out there to take ZFS snapshots and send them to another machine, and I summarized them on my wiki. I found zfSnap to work well for taking and rotating snapshots, but I didn t find anything that matched my criteria for sending them across the network. It seemed par for the course for these tools to think nothing of opening up full root access to a machine from others, whereas I would much rather lock it down with command= in authorized_keys. So I wrote my own, called simplesnap. As usual, I wrote extensive documentation for it as well, even though it is very simple to set up and use. So, with BackupPC, a backup of my workstation took almost 8 hours. (Its incremental might take as few as 3 hours) With ZFS snapshots and simplesnap, it takes 25 seconds. 25 seconds! So right now, instead of backing up once a day, I back up once an hour. There s no reason I couldn t back up every 5 minutes, in fact. The data consumes less space, is far faster to manage, and doesn t require a nightly hours-long cleanup process like BackupPC does zfs destroy on a snapshot just takes a few seconds. I use a pair of USB disks for backups, and rotate them to offsite storage periodically. They simply run ZFS atop dm-crypt (for security) and it works quite well even on those slow devices. Although ZFS doesn t do file-level dedup like BackupPC does, and the lz4 compression I ve set ZFS to use is less efficient than the gzip-like compression BackupPC uses, still the backups are more space-efficient. I am not quite sure why, but I suspect it s because there is a lot less metadata to keep track of, and perhaps also because BackupPC has to store a new copy of a file if even a byte changes, whereas ZFS can store just the changed blocks. Incidentally, I ve packaged both zfSnap and simplesnap for Debian and both are waiting in NEW.

Someone has decided to use my email address for a spam source. They have even used google to relay it which, given Googles current policies seems like a winning idea. I keep getting emails from Google s servers with header lines like this:

X-Original-Authentication-Results: mx.google.com; spf=hardfail (google.com: domain of csmall@small.dropbear.id.au does not designate 66.80.26.66 as permitted sender)

You don t say? You mean even though my SPF records do not include some dodgy server in California, even though Google knows I don t include this in my SPF records well we will let the email go through anyhow. SPF records mean that s where my email comes from. If the record has a -all at the end of it, like mine do, then it means don t accept it from anywhere else. The hardfail means Google sees the -all and still does nothing about it.

Related articles

• How to use an SPF Record to Prevent Spoofing & Improve E-mail Reliability (digitalocean.com)
• Spamfighting: mail server configuration (domsch.com)
• How to Create a SPF Record For Your Domain with Google Apps (digitalocean.com)

It's been quite a busy, varied day today. Lot's of fun as usual. Zoe has a dentist appointment tomorrow morning, so we went to the Thursday offering of her Brazilian Jiu-Jitsu class instead, and skipped Playgroup. We biked over extra early this morning, to make sure we were on time. There were two other kids in the class today, a 3 year old boy and a 2 and a half year old girl. The class went really well. We biked home the scenic way again, and grabbed a BBQ chicken for lunch along the way. The box of kinetic sand that I'd ordered was sitting on the doorstep. That still left us with about 45 minutes to kill before lunch, so I thought I'd start on making a second miniature clothes line with Zoe. Bunnings were selling these little kids safety sets at half price because they were a deleted product, and the set came with proper fitting eye protection, hearing protection and some gloves. The gloves are currently too big, but the glasses and hearing protection is great. I introduced her to the power drill and the hand saw. She liked drilling, and marking, but mostly was happy just watching. We managed to make most of the top of the clothes line before lunch, and then I whipped up some chicken quesadillas for lunch. We had a few disruptions during quiet time, so Zoe didn't nap. After quiet time, we did a mix of cleaning up the house a bit, some more wood working, and some self-directed play. After that, Zoe's friend Mackensie and her little sister came over for a play date after her Kindergarten class. She goes to the same Kindergarten as Zoe, but in the second half of the week. Mackensie's mum brought me a coffee, and we had some afternoon tea, and then I busted out the kinetic sand. It was a real hit with all the girls, as well as the adults. A very good product. That kept them occupied for a while. Zoe had found a Wallace and Gromit DVD while we were cleaning up, and she hasn't watched it for a while, so she was very keen to watch it. I told her she could watch it after Mackensie went home, and so we've kicked back on the couch to watch that while we wait for Sarah to arrive.

There are currently roughly 1500 source packages in Debian which possibly (very likely actually) do have broken URLs in debian/control. While it is quite useful that we have VCS information and Homepage URLs in the Packages file these days, we also created a rather big source of bitrot. These URLs are typically paste-and-forget. Sure, people occasionally catch the fact that a homepage or VCS has moved, especially if they are active and in good contact with their upstreams. However, there are also other cases...

I'm reserving the Wednesdays that Zoe doesn't have Kindergarten for longer excursions. Yesterday, we used it to go to Wet 'n' Wild. Zoe loves the place. She's been asking to go since last week. We've been three times now, the first time with friends, and twice by ourselves. I bought discounted VIP Passes for Zoe and I last year when they became available, so it makes going to Seaworld, Wet 'n' Wild or Movie World a no-brainer. So far Zoe's been to Seaworld twice too, once with me and once with Sarah. I'm saving Movie World for when it's too cold to go to Wet 'n' Wild any more. I've shifted my weekly chiropractic adjustment to 8am to help keep the day clear. Zoe came with me for that, and then we jumped in the car and headed down, running a couple of errands along the way, since the theme park doesn't open until 10am. We got there a little before it opened, so I used the extra time to apply sunscreen to Zoe and get her changed, and we got into the park pretty quickly. Zoe's only currently tall enough for Buccaneer Bay, the kid's play area, which is a shallow pool with a bunch of small slides in it, the giant wave pool, and Calypso Beach, which just involves floating around on an inflatable tube. We started, as usual, at Bucanneer Bay, then moved onto the wave pool for a bit, and then had some lunch and then lazed around at Calypso Beach. This was the first time we'd been in the wave pool for a wave cycle. I hadn't realised that they did it on a cycle. Last time and this time, when we jumped in, it was right at the end of a cycle, and it takes a while before they start it up again. Zoe thought jumping over the waves was pretty cool. This time at Calypso Beach, Zoe was quite confident fooling around in a kids tube by herself. She also figured out the water was only 0.8m deep, and was happy standing up and spinning around in her tube. We did about 3 laps of the course there. My cousin lives about 12 minutes from Wet 'n' Wild, and we usually drop in to visit her and her four kids on the way back. We've often stayed the night for a sleepover when it's a weekend. We hung out at their place for a little while afterwards, and then headed home. Zoe had a good nap in the car on the way home, and we were home slightly late for Sarah to pick her up.

Recently I've been thinking about getting a new laptop. I have this rule that a laptop should last me at least 3 years (ideally more) and my old laptop was bought in September 2010. So for the past few months I've been trying to work out if there's something suitable on the market that is a good replacement (last time I didn't manage to find something that ticked all the boxes, but did pretty well for the price I paid). To start with I decided to track my laptops over time - largely because one of my concerns was about the size of a replacement, because I have a significant leaning towards subnotebooks. In the end the reason I decided to upgrade was for some extra CPU grunt; my old machine had a tendency to get pretty hot under any sort of load.

Date	Model	CPU	Screen	RAM	Storage	W (mm)	H (mm)	D (mm)	Weight	Cost
1991	Amstrad PPC 640D	NEC V30 8MHz	9" 640x200 non-backlit green LCD	640k	2 x 3.5" FDD	450	230	100	10kg	???
August 1997	Compaq Aero 4/33c	486sx33	7.8" 640x480 CSTN LCD	4MB	80MB	260	190	43	1.6kg	???
July 2002	Compaq Evo N200	P-III 700MHz	10.4" 1024x768 TFT	192MB	20GB	251	198	20	1.1kg	939.99
August 2005	Toshiba Portege R200	Pentium M 753 1.2GHz	12.1" 1024x768 TFT	1280MB	60GB	286	229	20	1.29kg	1313.58
September 2008	Asus EEE 901	Atom N270 1.6GHz	8.9" 1024x600 TFT	2GB	4GB + 16GB SSD	248	175	23	1.1kg	299.99
September 2010	Acer Aspire 1830T	Core-i5 470UM 1.33GHz	11.6" 1366x768 TFT	8GB	500GB	284	203	28	1.4kg	$699.99 (~ 480)

The EEE didn't actually replace the Toshiba, but I mention it for completeness. It was actually the only machine I moved to the US with, but after about a month of it as my primary machine I realized it wasn't an option for day to day use - though it was fantastic as a machine to throw in an overnight bag, especially when coupled with a 3G dongle. I wasn't keen on significantly increasing the size of my laptop. There are a number of decent 13" Ultrabook options out there, and I looked at a few of them, but nothing grabbed me as being worth the increase in size. Also I wanted something better than the Acer - one of the major problems was finding something smaller than 13" that had 8G RAM, let alone more. There's a significant trend towards everything soldered in for the smaller/slimmer notebooks, which makes some sense but means that the base spec had better be right. Much to my surprise the Microsoft Surface Pro 2 looked like an option. It comes with an i5-4300U processor (at least since around Christmas 2013), and the 256/512G SSD models have 8G RAM. Screen resolution is an attractive true HD (1920x1080) and the 10" display means it's smaller than the Aspire. Unfortunately the keyboard lets it down. It's fine given a flat surface, but not great if you want to support the whole thing on your lap. Which is something I tend to do with my laptop, whether that's on the sofa, or in bed, or on a bus/train. Another option was the Sony Vaio Pro 11. This is a pretty sweet laptop (I managed to get to play with one at a Sony store in the US). Super slim and light. 8GB RAM. True HD screen. However I have bad memories of the build quality of the older Vaios and the fact that there was /no/ user replaceable parts put me off - it's a safe bet that a laptop battery is going to need replaced in a 3 year lifespan. What I managed to find, and purchase, was a Dell Latitude E7240. I admit that the Dell brand made me wary - while I've not had any issue with their desktops I didn't associated their laptops as being particularly high quality. Mind you, I could say the same for Acer and I've been very pleased with the Aspire (if they'd had a more up to date model I'd have bought it). I bought the E7240 with the Core-i5 4300U (so the same as the Surface Pro 2) and True HD touch screen. It has a replaceable battery, expandable RAM (up to 16G) and the storage is an mSATA SSD. It also came with a built in 3G card. At 12.5" it's a little bigger than my old machine, but I decided that was a reasonable idea given the higher resolution. I'm typing this article on it now, having finally completed the setup and migration of the data from the old laptop to it this evening. More details once I've been using it for a little bit I think.

It has been all over the place. The Debian CTTE has chosen systemd over upstart as default init system by chairman call. This decision was overdue, as it was pretty clear that the tie will not change, and thus it will be up to chairman. There were no new positions presented, and nobody was being convinced of a different preference. The whole discussion had been escalating, and had started to harm Debian. Some people may not want to hear this, but another 10 ballots and options would not have changed this outcome. Repating essentially the same decision (systemd, upstart, or "other things nobody prefers") will do no good, but turn out the same result, a tie. Every vote counting I saw happen would turn out this tie. Half of the CTTE members prefer systemd, the other half upstart. The main problems, however, are these:

• People are not realizing this is about the default init for jessie, not about the only init to support. Debian was and is about choice, but even then you need to make something default... If you prefer SysV init or openRC, you will still be able to use it (it will be just fewer people debugging these startup scripts).
• Some people (not part of the CTTE) are just social inept trolls, and have rightfully been banned from the list.
• The discussion has been so heated up, a number of imporant secondary decisions have not yet been discussed in a civil manner. For example, we will have some packages (for example, Gnome Logs), which are specific to a particular init system, but not part of the init system. A policy needs to be written with these cases in mind that states when and how a package may depend on a particular init system. IMHO, a package that cannot support other init systems without major changes should be allowed to depend on that system, but then meta-packages such as the Gnome meta packages must not require this application.

So please, everybody get back to work now. If there ever is enough reason to overturn this decision, there are formal ways to do this, and there are people in the CTTE (half of the CTTE, actually) that will take care of this. Until then, live with the result of a 0.1 votes lead for systemd. Instead of pursuing a destructive hate campaign, why not improve your favorite init system instead. Oh, and don't forget about the need to spell out a policy for init system support requirements of packages.

Hello Planet Mozilla I started as a new employee a few weeks ago. I am working as Release Manager for the next releases of Firefox (both on desktop + android).
As a start, Lukas and I will be working on Firefox 29 (no pressure at all to start with Australis + Firefox account).
I grew up with the first versions of Netscape, followed the Phoenix/Firebird adventures and I have been a supporter of Firefox since then.
I am glad to join such an important project, especially in the perspective of the recent privacy scandals. I think that Mozilla is in the best position to communicate to the public, to denounce certain activities and provides technologies to bypass them. Besides that, let me introduce myself. I have been in free software for almost a decade.
My previous work as working on Scilab (from Inria to Scilab Enterprises) where I stayed for almost 8 years. Over the years, I worked on various development (C, C++, Java, Python, Scilab, etc), user experience, roadmap definition, release management, R and D / customer project management, management, board member, etc. During this period, I learnt tons of things from coding, release and product management, QA, etc. In parallel, I worked part time at IRILL, a free software research center (hosted by Inria). I was involved as community management ie organizing event like GNU Hacker meeting, FOSDEM, Euro LLVM, etc and recording them. I had the chance to meet plenty of people from the FLOSS world (including folks from Mozilla who suggested me to join the adventure). I am also involved in two communities: Debian and LLVM. The first one is Debian. I started to contribute in Debian to get Scilab properly packaged. 7 years
after, I am now maintaining
important packages like LLVM, Clang, libedit, emscripten (!) or BLAS/LAPACK, treasurer of the French representative association and organizing the French mini Debian Conference (Debconf) / Meetup. For the last couple of years, I contributed to LLVM, Clang and LLDB. I participated to the release 3.3 and 3.4. My technical contributions were mainly driven by the packaging, the nightly Debian/Ubuntu packages and also by the rebuild of the Debian archive using Clang (instead of gcc). And when I am not behind my laptop, I am teaching scuba diving with my girlfriend or hiking, mountaineering, ski touring, climbing, etc. Yeh, I am a bit hyperactive.