There already has been official announcement for this years GSoC at phpMyAdmin and it's time to share my bits. First of all more details about chosen projects are available on our wiki (missing bits will get updated soon). This year I'll be mentoring again three students. As usual, it was quite tough job to choose students and I hope we've chosen really good ones. Anyway we'll see this later during there summer :-). As we're currently on a (long) way to phpMyAdmin 4.0, basically all projects are somehow about cleanup and refactoring of quite historical code which lives in some dark places of phpMyAdmin. The only big difference is automated testing project, which is purely about writing new test cases and making tests cover more functionality. Anyway I'm looking forward to see first improvements from my students - Alex Marin, Yasitha Pandithawatta and Chanaka Indrajith.

Filed under: English Phpmyadmin 0 comments Flattr this!

I ve made the Testtools committers team own both the project and the trunk branch for both pyjunitxml and testscenarios. This removes me as a SPOF if anything needs doing in those projects any Testtools committer can now do it. (Including code review and landing). If you are a testtools committer and need PyPI release rights, ping me and I ll add you. (I wish PyPI had group management).

Today my system froze and failed to reboot. I plugged in an Ubuntu live USB stick and booted from it. Then I discovered the problem that my Intel SSD 320 broke. The output of hdparm is attached to the end of the blog post. You can see that the device size is reduced to 8 MB from 120 GB and the serial number is called BAD_CTX 00000159. The firmware of the SSD was up-to-date and the last firmware update should have fixed the 8 MB bug. The Intel SSD 320 is my second SSD. My first SSD was a Super Talent Ultradrive GX 64GB, which died after around fifteen month of heavy use. It left a big bunch of my data corruption behind. SSDs seems to be very unreliable. Both SSDs died, but I cant remember that one of my HDDs died. $ sudo hdparm -I /dev/sda /dev/sda: ATA device, with non-removable media
Model Number: INTEL SSDSA2CW120G3
Serial Number: BAD_CTX 00000159
Firmware Revision: 4PC10362
Transport: Serial, ATA8-AST, SATA 1.0a, SATA II Extensions, SATA Rev 2.5, SATA Rev 2.6
Standards:
Used: unknown (minor revision code 0x0029)
Supported: 8 7 6 5
Likely used: 8
Configuration:
Logical max current
cylinders 16383 16
heads 16 16
sectors/track 63 63
--
CHS current addressable sectors: 16128
LBA user addressable sectors: 16384
LBA48 user addressable sectors: 16384
Logical Sector size: 512 bytes
Physical Sector size: 512 bytes
device size with M = 1024*1024: 8 MBytes
device size with M = 1000*1000: 8 MBytes
cache/buffer size = unknown
Nominal Media Rotation Rate: Solid State Device
Capabilities:
LBA, IORDY(can be disabled)
Standby timer values: spec'd by Standard, no device specific minimum
R/W multiple sector transfer: Max = 16 Current = 16
DMA: mdma0 mdma1 mdma2 udma0 udma1 udma2 udma3 udma4 udma5 *udma6
Cycle time: min=120ns recommended=120ns
PIO: pio0 pio1 pio2 pio3 pio4
Cycle time: no flow control=120ns IORDY flow control=120ns
Commands/features:
Enabled Supported:
Security Mode feature set
* Power Management feature set
* Write cache
* Look-ahead
* Host Protected Area feature set
* WRITE_BUFFER command
* READ_BUFFER command
* NOP cmd
* DOWNLOAD_MICROCODE
SET_MAX security extension
* 48-bit Address feature set
* Device Configuration Overlay feature set
* Mandatory FLUSH_CACHE
* FLUSH_CACHE_EXT
* General Purpose Logging feature set
* WRITE_ DMA MULTIPLE _FUA_EXT
* 64-bit World wide name
* IDLE_IMMEDIATE with UNLOAD
* WRITE_UNCORRECTABLE_EXT command
* READ,WRITE _DMA_EXT_GPL commands
* Segmented DOWNLOAD_MICROCODE
* Gen1 signaling speed (1.5Gb/s)
* Gen2 signaling speed (3.0Gb/s)
* Phy event counters
* Software settings preservation
* SMART Command Transport (SCT) feature set
* SCT LBA Segment Access (AC2)
* SCT Error Recovery Control (AC3)
* SCT Features Control (AC4)
* SCT Data Tables (AC5)
* Data Set Management TRIM supported (limit 8 blocks)
* Deterministic read ZEROs after TRIM
Security:
Master password revision code = 65534
supported
not enabled
not locked
frozen
not expired: security count
supported: enhanced erase
2min for SECURITY ERASE UNIT. 2min for ENHANCED SECURITY ERASE UNIT.
Logical Unit WWN Device Identifier: 500151795951d4b9
NAA : 5
IEEE OUI : 001517
Unique ID : 95951d4b9
Checksum: correct


The marketing industry divides itself up into a number of businesses. Some are boutique agencies, but most are owned by one of the world's four major holding companies. These conglomerates pursue an aggressive M&A strategy, snapping up smaller companies all the time.

• Advertising this is the generation of ads and commercials; often blatant and obvious, sometimes more subtle. The objective is generally to trick people into buying something.
• Media media companies handle the placement of advertising; they are brokers for ad space and commercial slots in magazines, newspapers, radio, TV, billboards, taxicabs and specialty vehicles, people handing out pamphlets and samples on the street, free-standing cardboard cutouts, website banners, and so forth. They handle product placement everywhere (TV, movies, celebrities, video games, &c.), ranging from the blatant in-your-face product logo to the more subtle authorship of entire screenplays just to showcase and promote particular products.
• Research The least glamorous, but not the least lucrative, market research is about figuring out what customers think they want. This takes the form of polls and surveys (phone, mail, web, email), focus groups, and a variety of surveillance and tracking methods of which the customer may or may not be conscious (loyalty programs, social media, special discount/rewards programs tied to your credit card, web bugs and cookies, specialized URLs and SMS numbers, POS questions)
• Public Relations When you need to manipulate public perception in a more covert way, you might hire a PR firm. This can be something like for when a CEO strangles his wife and suddenly there are lots of news reports about how the company produces the cleanest-burning fuels, and what great things it does for charity. It can be spin on all kinds of political events, corporate performance, and lobbying.
• Medical Because of the greater amount of regulation in the medical sector, medical marketing is handled separately. This includes the same advertising process, but with lots of fine print and more restrictions on the claims which can be made. It includes research, but with different rules on the confidentiality of data and the ways you can experiment on people. Then it extends to services not found in other sectors, such as funneling money from pharmaceutical companies to doctors (this is called medical education ), and acting as middlemen between pharmaceutical companies and the people who produce science shows for television.
• Branding Depending on who you talk to, branding is not just the process of shaping the public's perception of a particular company or product or service, or families thereof, but also convincing the employees of the relevant companies that the particular message being hawked is the truth. Logos are part of brand identity.

There are other sets of services, as well as variations on the above, particularly in terms of targeting certain age groups or ethnic groups, but also particular industries or sectors (movies, politics). There is direct marketing (spamming) through all the imaginable media. There is also paying people to blog about certain things without disclosing their sponsorship.

Karen Tse gave an interesting TED talk about how to stop police torture as an investigative tool [1]. Mostly it s about training and empowering public defenders. Phil Plait gave an interesting TED talk about how to defend the Earth from asteroids [2]. Julian Baggini wrote an interesting article for the Financial Times about the persecution of Atheists in the US [3]. Charlie Todd of Improv Everywhere gave an amusing TED talk about Improv events that he has run [4]. He is most famous for organising people to wear blue shirts and khaki pants in Best Buy, but he s done lots of other funny things. Paul Zak gave an interesting TED talk about trust, morality, and oxytocin [5]. One of the many interesting fact that he shared is that oxytocin levels can significantly increase when using social networking sites. So people who use Facebook etc are likely to be more trustworthy as well as more trusting. The Occupy the Judge Rotenberg Center movement aims to stop the torture of Autistic children in the US [6], Anonymous is involved in that too. Paul Lewis gave an insightful TED talk about the use of crowdsourced data in news reporting [7]. A lot of the analysis of citizen journalism is based on comparing bloggers with full-time paid journalists, but Paul describes how professional full-time journalistic work can be greatly assisted by random people filming and photographing things that seem noteworthy. Make sure your next phone has the best possible camera phone cameras will never be great but the quality of the camera you have with you is what matters. Sam Harris published an interesting interview with Tim Prowse who is a Baptist minister who faked belief for two years after becoming an atheist [8A]. He also references The Clergy Project a support group for atheists who are current or former members of the clergy [8B]. Cracked has an insightful article about 6 things that rich people need to stop saying [9]. How do the 1% not understand these things? Barack Obama and Nichelle Nichols (who played Lt Uhura in the original Star Treck) give the Vulcan Salute in the White-House [10]. Gabriel Arana wrote an insightful article about his experiences with the ex-gay movement [11]. The therapist who hurt him so much is still doing the same to other victims. S#!T Ignorant People Say To Autistics is an interesting youtube video about ignorant and annoying people [12]. Strangely I ve received little of that myself, I wonder whether women on the Autism Spectrum get a lot more of that than men. At GManCaseFile an ex-FBI agent has written an informative post about how the TSA is failing [13]. The Nieder Family has an interesting article about how patents are being used to prevent the creation of assisted communication (AAC) devices for children [14]. Apparently the company that has the patents wants all AAC devices to be really expensive and profitable for them. This is yet another example of patents doing harm not good. Renew Economy has an informative article by Giles Parkinson about the affect that solar power generation will have on power prices [15]. In short as solar systems produce power when it s most needed (during the day and at the hottest time of the day for warm climates) it will dramatically reduce the auction price for wholesale power. That will hurt the business of the power companies and also allow lower prices on the retail market.

• [1] http://www.ted.com/talks/karen_tse_how_to_stop_torture.html
• [2] http://www.ted.com/talks/phil_plait_how_to_defend_earth_from_asteroids.html
• [3] http://www.ft.com/cms/s/2/d2239780-4d4e-11e1-8741-00144feabdc0.html
• [4] http://www.ted.com/talks/charlie_todd_the_shared_experience_of_absurdity.html
• [5] http://www.ted.com/talks/paul_zak_trust_morality_and_oxytocin.html
• [6] https://sites.google.com/site/occupythejudgerotenbergcenter/
• [7] http://www.ted.com/talks/paul_lewis_crowdsourcing_the_news.html
• [8A] http://www.samharris.org/blog/item/life-without-god
• [8B] http://clergyproject.org/
• [9] http://www.cracked.com/blog/6-things-rich-people-need-to-stop-saying/
• [10] http://colorlines.com/archives/2012/04/nichelle_nichols_throws_vulcan_signs_with_obama_in_the_oval_office.html
• [11] http://prospect.org/article/my-so-called-ex-gay-life
• [12] http://www.youtube.com/watch?v=5fTBM_3sdwE
• [13] http://gmancasefile.blogspot.com.au/2012/01/tsa-fail.html
• [14] http://niederfamily.blogspot.com.au/2012/03/goliath-v-david-aac-style.html
• [15] http://reneweconomy.com.au/2012/why-generators-are-terrified-of-solar-44279

Related posts:

1. Links March 2012 Washington s Blog has an informative summary of recent articles about...
2. Links February 2012 Sociological Images has an interesting article about the attempts to...
3. Links April 2010 Sam Harris gave an interesting TED talk about whether there...

Swift is the software behind the OpenStack Object Storage service. This service provides a simple storage service for applications using RESTful interfaces, providing maximum data availability and storage capacity. I explain here how some parts of the storage and replication in Swift works, and show some of its current limitations. If you don't know Swift and want to read a more "shallow" overview first, you can read John Dickinson's Swift Tech Overview. How Swift storage works If we refer to the CAP theorem, Swift chose availability and partition tolerance and dropped consistency. That means that you'll always get your data, they will be dispersed on many places, but you could get an old version of them (or no data at all) in some odd cases (like some server overload or failure). This compromise is made to allow maximum availability and scalability of the storage platform. But there are mechanisms built into Swift to minimize the potential data inconsistency window: they are responsible for data replication and consistency. The official Swift documentation explains the internal storage in a certain way, but I'm going to write my own explanation here about this. Consistent hashing Swift uses the principle of consistent hashing. It builds what it calls a ring. A ring represents the space of all possible computed hash values divided in equivalent parts. Each part of this space is called a partition. The following schema (stolen from the Riak project) shows the principle nicely: In a simple world, if you wanted to store some objects and distribute them on 4 nodes, you would split your hash space in 4. You would have 4 partitions, and computing hash(object) modulo 4 would tell you where to store your object: on node 0, 1, 2 or 3. But since you want to be able to extend your storage cluster to more nodes without breaking the whole hash mapping and moving everything around, you need to build a lot more partitions. Let's say we're going to build 2¹⁰ partitions. Since we have 4 nodes, each node will have 210 4 = 256 partitions. If we ever want to add a 5^th node, it's easy: we just have to re-balance the partitions and move 1 4 of the partitions from each node to this 5^th node. That means all our nodes will end up with 210 5 204 partitions. We can also define a weight for each node, in order for some nodes to get more partitions than others. With 2¹⁰ partitions, we can have up to 2¹⁰ nodes in our cluster. Yeepee. For reference, Gregory Holt, one of the Swift authors, also wrote an explanation post about the ring. Concretely, when building one Swift ring, you'll have to say how much partitions you want, and this is what this value is really about. Data duplication Now, to assure availability and partitioning (as seen in the CAP theorem) we also want to store replicas of our objects. By default, Swift stores 3 copies of every objects, but that's configurable. In that case, we need to store each partition defined above not only on 1 node, but on 2 others. So Swift adds another concept: zones. A zone is an isolated space that does not depends on other zone, so in case of an outage on a zone, the other zones are still available. Concretely, a zone is likely to be a disk, a server, or a whole cabinet, depending on the size of your cluster. It's up to you to chose anyway. Consequently, each partitions has not to be mapped to 1 host only anymore, but to N hosts. Each node will therefore store this number of partitions:

number of partition stored on one node = number of replicas   total number of partitions   number of node

Examples:

We split the ring in 2¹⁰ = 1024 partitions. We have 3 nodes. We want 3 replicas of data.
Each node will store a copy of the full partition space: 3 210 3 = 210 = 1024 partitions.

We split the ring in 2¹¹ = 2048 partitions. We have 5 nodes. We want 3 replicas of data.
Each node will store 211 3 5 1129 partitions.

We split the ring in 2¹¹ = 2048 partitions. We have 6 nodes. We want 3 replicas of data.
Each node will store 211 3 6 = 1024 partitions.

Three rings to rule them all In Swift, there is 3 categories of thing to store: account, container and objects. An account is what you'd expect it to be, a user account. An account contains containers (the equivalent of Amazon S3's buckets). Each container can contains user-defined key and values (just like a hash table or a dictionary): values are what Swift call objects. Swift wants you to build 3 different and independent rings to store its 3 kind of things (accounts, containers and objects). Internally, the two first categories are stored as SQLite databases, whereas the last one is stored using regular files. Note that this 3 rings can be stored and managed on 3 completely different set of servers. Data replication Now that we have our storage theory in place (accounts, containers and objects distributed into partitions, themselves stored into multiple zones), let's go the replication practice. When you put something in one of the 3 rings (being an account, a container or an object) it is uploaded into all the zones responsible for the ring partition the object belongs to. This upload into the different zones is the responsibility of the swift-proxy daemon. But if one of the zone is failing, you can't upload all your copies in all zones at the upload time. So you need a mechanism to be sure the failing zone will catch up to a correct state at some point. That's the role of the swift- container,account,object -replicator processes. This processes are running on each node part of a zone and replicates their contents to nodes of the other zones. When they run, they walk through all the contents from all the partitions on the whole file system and for each partition, issue a special REPLICATE HTTP request to all the other zones responsible for that same partition. The other zone responds with information about the local state of the partition. That allows the replicator process to decide if the remote zone has an up-to-date version of the partition. In case of account and containers, it doesn't check at the partition level, but check each account/container contained inside each partition. If something is not up-to-date, it will be pushed using rsync by the replicator process. This is why you'll read that the replication updates are "push based" in Swift documentation.

# Pseudo code describing replication process for accounts
# The principle is exactly the same for containers
for account in accounts:
    # Determine the partition used to store this account
    partition = hash(account) % number_of_partitions
    # The number of zone is the number of replicas configured
    for zone in partition.get_zones_storing_this_partition():
        # Send a HTTP REPLICATE command to the remote swift-account-server process
        version_of_account = zone.send_HTTP_REPLICATE_for(account):
        if version_of_account < account.version()
            account.sync_to(zone)

This replication process is O(number of account number of replicas). The more your number of account will increase and the more you will want replicas for your data, the more the replication time for your accounts will grow. The same rule applies for containers.

# Pseudo code describing replication process for objects
for partition in partitions_storing_objects:
    # The number of zone is the number of replicas configured
    for zone in partition.get_zones_storing_this_partition():
        # Send a HTTP REPLICATE command to the remote swift-object-server process
        verion_of_partition = zone.send_HTTP_REPLICATE_for(partition):
        if version_of_partition < partition.version()
            # Use rsync to synchronize the whole partition
            # and all its objects
            partition.rsync_to(zone)

This replication process is O(number of objects partitions number of replicas). The more your number of objects partitions will increase, and the more you will want replicas for your data, the more the replication time for your objects will grow. I think this is something important to know when deciding how to build your Swift architecture. Choose the right number the number of replicas, partitions and nodes. Replication process bottlenecks File accesses The problem, as you might have guessed, is that to replicate, it walks through every damn things, things being accounts, containers, or object's partition hash files. This means it need to open and read (part of) a every file your node stores to check that data need or not to be replicated! For accounts & containers replication, this is done every 30 seconds by default, but it will likely take more than 30 seconds as soon as you hit around 12 000 containers on a node (see measurements below). Therefore you'll end up checking consistency of accounts & containers on each all node all the time, using obviously a lot of CPU time. For reference, Alex Yang also did an analysis of that same problem. TCP connections Worst, the HTTP connections used to send the REPLICATE commands are not pooled: a new TCP connection is established each time something has to be checked against the same thing stored on a remote zone. This is why you'll see in the Swift's Deployment Guide this lines listed under "general system tuning":

# disable TIME_WAIT.. wait..
net.ipv4.tcp_tw_recycle=1
net.ipv4.tcp_tw_reuse=1
# double amount of allowed conntrack
net.ipv4.netfilter.ip_conntrack_max = 262144

In my humble opinion, this is more an ugly hack than a tuning. If you don't activate this and if you have a lot of containers on your node, you'll end up soon with thousands of connections in TIME_WAIT state, and you indeed risk to overload the IP conntrack module. Container deletion We also should talk about container deletion. When a user deletes a container from its account, the container is marked as deleted. And that's it. It's not deleted. Therefore the SQLite database file representing the container will continue to be checked for synchronization, over and over. The only way to have a container permanently deleted is to mark an account as deleted. This way the swift-account-reaper will delete all its containers and, finally, the account. Measurement On a pretty big server, I measured the replications to be done at a speed of around 350 account,container,object-partitions /second, which can be a real problem if you chose to build a lots of partition and you have a low number_of_node number_of_replicas ratio. For example, the default parameters runs the container replication every 30 seconds. To check replication status of 12 000 containers stored on one node at the speed of 350 containers/seconds, you'll need around 34 seconds to do so. In the end, you'll never stop checking replication of your containers, and the more you'll have containers, the more your inconsistency window will increase. Conclusion Until some of the code is fixed (the HTTP connection pooling probably being the "easiest" one), I warmly recommend to chose correctly the different Swift parameters for your setup. The replication process optimization consists in having the minimum amount of partitions per node, which can be done by:

• decreasing the number of partitions
• decreasing the number of replicas
• increasing the number of node

For very large setups, some code to speed up accounts and containers synchronization, and remove deleted containers will be required, but this does not exist yet, as far as I know.

I've recently been moving some important data into git-annex, and finding it simplifies things while also increasing my flexability. email archives I've kept my email archives in git for years. This works ok, just choose the right file format (compressed mbox) and number of files (one archive per mailbox per month or so) and git can handle this well enough, as email is not really large. But, email is not really small either. Keeping my email repository checked out on my netbook consumes 2 gigabytes of its 30 gigabyte SSD, half of which is duplication in .git. Also, I have only kept it at 2 gigabytes through careful selection of what classes of mail I archive. That made sense when archival disk was more expensive, but what makes sense these days is to archive everything. For a while I've wanted to have a "raw" archive, that includes all email I receive. (Even spam.) This protects against various disasters in mail filtering or reading. Setting that up was my impetus for switching my mail archives to git-annex today. The new system I've settled on is to first copy all incoming mail into a "raw" maildir folder. Then mailfilter sorts it into the folders I sync (with offlineimap) and read. Each day, the "raw" folder is moved into a mbox archive, and that's added to the git annex. Each month, the mail I've read is moved into a monthly archives, and added to the git annex. A simple script does the work. I counted the number of copies that existed of my mail when it was stored in git, and found 7 copies spread amoung just 3 drives. I decided to slim that back, and configured git-annex to require only 5 copies. But those 5 copies will spread amoung more drives, including several offline archival drives, so it will be more robust overall. My netbook will have an incomplete checkout of my mail, omitting the "raw" archive. If I need to peek inside a spam folder for a lost mail, I can quickly pull it down; if I need to free up space I can quickly drop older archives. This is the flexability that git-annex fans love. :) By the way, this also makes it easier to permanantly delete mail, when you really need to (ie, for contractual reasons). Before, I'd have to do a painful git-filter-branch if I needed to get rid of eg, mail for old jobs. Now I can git annex drop --force. Pro Tip: If you're doing this kind of migration to git-annex, you can save bandwidth by not re-transferring files to machines that already have a copy. I ran this command on my netbook to inject the archives it had in the old repository into the new repository, verifying checksums as it goes:

cd ~/mail/archive; find -type l -exec git annex reinject ~/mail.old/archive/    \;

Note on mairix compatability: I use mairix to index and search my mail. But it refuses to follow git-annex's symlinks to the content. So I have to point it at .git/annex/objects/. I also configured annex.backend to SHA256E, which keeps the extensions on my compressed mailbox files, which is necessary for mairix to realize they're compressed. debian packages I'd evolved a complex and fragile chain of personal apt repositories to hold Debian packages I've released. I recently got rid of the mess, which looked like this: dput local mini-dinstall repo dput→mini-dinstallrepo on my server →dput Debian The point of all that was that I could "upload" a package locally while offline and batch transfer it later. And I had a local and a public apt repository of just the packages I've uploaded. But these days, packages uploaded to Debian are available nearly immediately, so there's not much reason to do that. My old system also had a problem: It only kept the most recent single copy of each package. Again, disk is cheap, so I'd rather have archives of everything I have uploaded. Again I switched to git-annex. My new system is simplicity itself. I release a package by checking it into a "toupload" directory in my git annex repository on my netbook. Items in that directory are dput to Debian and moved to "released". I have various other clones of that repository, which I git annex move packages to periodically to free up SSD space. In the rare cases when I build a package on a server, I check it into the clone on the server, and again rely on git-annex to copy it around. Now, does anyone know a good way to download a copy of every package you're ever released from archive.debian.org? (Ideally as a list of urls I can feed to git annex addurl.) conclusion My email and Debian packages were the last large files I was not storing in git-annex. Even backups of my backups end up checked into git-annex and archived away. Now that I'm using git-annex in every place I can, my goal with it is to make it as easy as possible for as many of you to use it as possible, too. I have some inotify tricks up my sleeve that seem promising. Kickstarter may be involved. Watch this space!

A Polish geek going by the handle of mmemuar has recently written a blog post claiming that people use Autism as an excuse for bad behavior [1]. He gets enough things wrong in one short post to make it worth debunking it. It seems that Google s translation of Polish isn t as good as some other languages, but unless Google mistranslated about a dozen sections such that they had the exact opposite meaning then mmemuar s post has a lot of wrong ideas. Does Anyone use Autism as an Excuse? I ve read a lot of blog posts written by people on the Autism Spectrum, read many forum discussions, and talked to more than a few people in person. So far I haven t yet encountered any evidence of people using an Autism Spectrum Disorder (ASD) diagnosis as an excuse. There are probably about 70,000,000 people who meet the diagnostic criteria (most of whom have not been diagnosed due to not having access to anyone who is qualified to do an assessment). The number of people who have been diagnosed is large enough that I couldn t claim that none of them have ever used it as an excuse. The number of self-diagnosed people is also large enough that there has to be some people who wouldn t get diagnosed if professionally assessed. But I don t see any evidence that using an ASD as an excuse is at all common. I imagine that some people would take someone merely mentioning the fact that they have an ASD diagnosis in a public place (EG a mailing list or a blog post) as some sort of an excuse. One problem with such an interpretation is that for every way in which people on the Autism Spectrum annoy other people it s the ones who aren t diagnosed (or who reject a diagnosis) that will do it the most. Being diagnosed with an ASD is correlated with annoying other people less. Another problem is that keeping quiet about such things when they get raised for discussion so often takes a psychological toll. When someone is diagnosed as an adult a fairly common reaction is to study Psychology and Sociology (usually through web sites such as Sociological Images which I highly recommend [2]) and try to get a better understanding of other people. Any time you assume that everyone else thinks like you then you will get things wrong, when someone gets an ASD diagnosis they will probably take more care to avoid making such mistakes. Is Autism Obvious? Mmemuar says if you were full of autistic, which is very easy to overheat the brain from excess signals at the input, it would be very obvious to all . There are some people who are utterly incapable of acting like an NT. But the majority of people on the Autism Spectrum have some ability to pass as NT, it just takes a lot of effort. So if someone is spending all their effort to walk, talk, and make eye contact in a way that most people expect then they will have little spare effort for other things. This can result in them having little patience for other people. The solution to this is to not require people to look average. Even apart from Autism there are people who fidget, don t make eye contact in the way you expect, and do other things a little differently. Being tolerant of such things won t hurt you and will generally make things easier for everyone. TheAnMish gave a good Youtube presentation about the way that she has to act normal [3]. Note that while her video represents her own personal experiences (which differ slightly from those of other Aspies particularly male Aspies) they are regarded as representative enough for her video to be shown by Tony Attwood (a world renowned expert on Asperger Syndrome) at a conference about women on the Autism Spectrum. As an aside I disagree with her use of the word normal without scare-quotes. Learning about Psychology through Sci-Fi In the end of the blog post and in some of the comments there is discussion about learning to understand people through reading sci-fi books. The first problem with this is that fiction books generally have a range of characters that is determined by the author s understanding of people, if you read multiple books by an author then you will usually notice the same character types. The second problem is that characters in fiction books are simplified to fit into a reasonable sized book, in real life people have lots of really boring reasons for doing what they do, in fiction only stuff that is interesting ends up in print. But the biggest problem is that fiction books just aren t a good way of learning about people. Whatever lessons might be in a fiction book will probably be missed by a reader who is concentrating on the plot. You can learn things about people by reading an analysis of literature by a Psychologist or a Sociologist, but apart from that you probably won t be able to learn things if you don t already know them. As an aside, my experience of reading sci-fi books suggests that some of the popular sci-fi authors have such a poor understanding of people that it impairs their ability to write believable fiction about human characters. If I was going to try and learn about people by reading fiction I d choose something that s been popular for a long time. If a book has been popular for more than 100 years and sold well in different times, cultures, and languages then it probably has something to say about the human condition. Catching up on Youth Mmemuar says absolutely nothing prevents you to the age of twenty he began to catch up on some of youth . Actually one significant thing is that the human brain develops in particular stages, the older you get the more difficult it becomes to learn things. So even if it was just a matter of learning things someone who was behind at age 20 would have some significant difficulty in catching up. But some things just can t be learned, for example someone who has extreme discomfort in making eye contact can t just learn to be happy with it. Also there are some things which people would have learned if it was possible. For example people who have Prosopagnosia (an inability to recognise faces) suffer extreme bullying in school, if they could just learn to recognise people then they surely would do so, so if they complete school without learning then it s probably going to be impossible for them. Prosopagnosia is one of many conditions which can contribute to social difficulties and therefore contribute to an ASD diagnosis. Can Aspies get Married? Some people think that people on the Autism Spectrum can t get married. In fact this belief is so widely held that some people who seem very obviously Autistic are convinced that they are NT simply because they are married! The fact that there are more than few books offering advice to people who have married someone who is on the Autism Spectrum is clear proof that such claims are bogus. The Relevance to Geek Communities People who meet the diagnostic criteria for Asperger Syndrome will almost certainly be Geeks due to the Restricted, repetitive patterns of behavior, interests, or activities section of the diagnostic criteria (the proposed revision for the DSM-V is the best reference I know for this [4]) as the modern use of the term Geek applies to anyone who has an extreme interest in something. The more Geeky a community is the greater the incidence of people who could be diagnosed with an ASD. Spreading ideas such as those of mmemuar will lead to people not being assessed for an ASD. I would have been assessed earlier if it wasn t for hearing an influential member of the Linux community say some things which were similar in concept (although not as deliberate). Having people not be assessed is bad for the individuals in question and bad for the community.

• [1] http://mmazur.7thguard.net/2012/03/24/w-kwestii-aspergera/
• [2] http://thesocietypages.org/socimages/
• [3] http://www.youtube.com/watch?v=IFxWdpuyY6o
• [4] http://www.dsm5.org/ProposedRevisions/Pages/proposedrevision.aspx?rid=94

Related posts:

1. Autism Awareness and the Free Software Community It s Autism Awareness Month April is Autism Awareness month, there...
2. Autism vs Asperger Syndrome Diagnostic Changes for Autism Spectrum Disorders Currently Asperger Syndrome (AS)...
3. Communication Shutdown and Autism The AEIOU Foundation The AEIOU Foundation [1] is a support...

Posted a week ago, already deferred back then, this report is even more deferred now! But as there are people interest in knowing what the "DPL job" is about even among non debian-devel-announce subscribers, here is a blog-conveyed reproduction, for the records.

---

Dear project members,
here is my monthly DPL activity report, this time for last March. It is delayed by a couple of weeks because, myself being both incumbent and candidate DPL, I preferred not to use d-d-a during the voting period unless really needed. Apologies for the delay (or the unneeded paranoia, you name it). As a side effect of the delay, the results of the DPL election are now known. I'd like to thank all the people who took part in the elections: voters, people who asked questions on -vote, the secretary, and obviously Gergely and Wouter, without whom the campaign wouldn't have allowed to discuss relevant aspects of Debian "politics". Thanks for your trust. I'll do my best to match your expectations. ... and just to remind you what you've just asked for, here goes the BigMonthlyBlurb! Highlight: long-term hardware replacement planning The highlight for this month is long term planning of hardware replacement. It's something I've been discussing with DSA for quite a while and on which DSA has worked hard during the recent sprint. As a result, we now have a quite ambitious 5-year hardware replacement plan that will guarantee that all machines in production are under warranty at any given time (with the nice side effect of generally better performances, as they go hand in hand with newer hardware). The current estimated cost per year is 29'000 USD. That does not yet include buildds and porter-boxes, so it is expected to increase a bit to cover all our hardware needs. But we expect it not increase too much, as we tend to get explicit hardware donations to cover arch-specific needs. Given the current state of Debian finances and donation trends, the plan looks sustainable for at least 2-3 years. But this assessment still needs to be refined as soon as, together with the auditors, we'll manage to obtain the history of past Debian transactions, in particular from SPI. We've been waiting for this for about 5 months now, but I'm positive it could become a reality in the next weeks. In the meantime, it is surely safe to start with the plan for the next 1-1.5 years, so I'll give green light to DSA for the first acquisitions as soon as they're ready for it. When implemented, this plan will increase our ability to rely on hardware. But it also means we will need to become a bit more organized about fund-raising. The discussion started with the sprint report has some insights about how to do that. As part of this, we'll also need to share resources (e.g. contact databases, people, etc.) among the yearly DebConf fund-raising initiatives and the initiatives mentioned in the aforementioned discussion. Ongoing discussions

• A couple of important clarifications on how to deal with trademark-encumbered software in the Debian archive have been posted to -project. It seems to me there might be consensus on the overall topic, but we need to write down guidelines for maintainers (and possibly a project position statement?). I could use some help on that front, so if you've followed the discussion and/or have an interest in trademark and free software, please get in touch.
• To put an end to the long and glorious life of DEP-5, I've marked it as ACCEPTED given that it has been "implemented" in February via inclusion in the debian-policy package. You still have some time to port your debian/copyright-s to it before the Wheezy freeze.
• I've been contacted by the DuckDuckGo about a revenue sharing agreement for the inbound traffic they already get from Debian browsers. I've informed -project proposing to accept it and that has spawned a discussion that has won us an LWN article. I haven't yet summarized the thread proposing a way forward; I'll do so shortly.
• as part of a discussion on unofficial "debian" repositories, I've proposed to open up the list of *.debian.net domains. As nobody disagreed, consensus has been quickly reached and the announced change is now imminent. Thanks to Carsten Hey and Gerfried Fuchs for their help in figuring out the details of the last discussion on the matter and DSA for their feedback.

Summer of Code Debian has been accepted as an organization for the Google Summer of Code. At the time these bits go out, the student application deadline has also elapsed. In March I've contributed a few project ideas and chased potential mentors for them, when I thought the project could be important for Debian and the prospective student. I'm happy that one (a dak building block needed for the implementation of PPAs and more) has found both mentors and students. We'll see if any of the corresponding student proposal is retained and how it goes. Communication I've given an interview, about Debian and Free Software in general, to La Repubblica, one of the major newspapers in Italy. The interview is available online, but only in Italian. If some kind (and Italian-speaking) soul would like to translate it into English, I'll be happy to publish the translation as well. (update 22/04/2012: Matteo Cortese has contributed an English translation of the interview, which I'll make available shortly) Legal stuff In order to transfer ownership of the Debian trademark in Japan to SPI, I've contacted the current owners (all Japanese Debian Developers or contributors) to do the needed paperwork. I've been blessed by the help of Kenshi Muto that has taken the matter in his hands. He is now navigating through Japanese trademark procedures, a subject neither myself nor SPI lawyers were familiar with. Thanks also to Jonathan McDowell who has done the needed paperwork, SPI-side. Sprints Plenty of sprints and sprint reports in March!: Debian Med, DSA, DAM/FrontDesk. Everything should also be available from the wiki sprint page where you can find info to organize your team sprint. Assets miscellanea

• I've signed the annual memorandum of understanding with the financial entity that will help us with local expenditures for DebConf12 in Nicaragua. This year is ISIC, with whom we have an important trust path via Norman Garcia Aguilar, member of the DebConf orga team.
• After discussion with auditors, we've resolved to set a 1 year deadline for reimbursement requests. The reason is that it's a PITA to keep track of longer-running requests (yes, they do happen!) and they add uncertainty to our available finances. There can be exceptions, but please help on this front by timely requesting reimbursements after travels or other expenses.

Cheers.

---

PS the boring day-to-day activity log for March is available at master:/srv/leader/news/bits-from-the-DPL.txt.201203

I ve recently caught up on a bunch of reading some of which are worth commending.

• Switch documents the factors that cause changes to fail (both in organisations and personal stuff), and provides a recipe for ensuring you have addressed those factors in any change you are planning.
• The Lean Startup Applies Lean principles to the learning what customers respond well to in the same way that Lean removes waste from the process of building some X, this removes waste from the process of determining what that X should be.
• The Innovator s Solution Pop science report of research done on why disruptive innovation at existing companies fails; covers structure, management, funding, market analysis, has recommendations to remove these sure-fail cases.
• The Innovator s DNA Pop science report of research done into how people innovate : turns out that there are a lot of things that one can do to be a better innovator.

Read them all, or none. I enjoyed them all.

I've just read and enjoyed this post by Mike Abrash about working at Valve. I enjoyed it for two reasons: firstly, doom played a pivotal role in shaping Abrash's thinking about the future of computing, or perhaps it shaped the future of computing itself. I'm not ashamed to admit that Doom played a pivotal role in making me the person I am today: it derailed my ambition to become a graphics designer, introduced me to the PC, programming and various other computer design technologies and concepts: things moved on from there. The second reason is the culture that Abrash describes at Valve: flat, creative-driven, unafraid of failure. I've been thinking a lot about work environments and the nature of management, both in the context of my work and Debian. What Abrash describes is still vastly different to life at University, but it did force me to reflect on how lucky I am to have the freedom and conditions I have, and consider the ways in which I define and shape the environment for myself and others.

LED Fireworks. Or, parent helpers go overboard My friend, Mike Ward, and I help out at our kids school by teaching 5th and 6th graders programming in conjunction with a Lego class. For several years, I was teaching Logo on ancient Apple II machines. The teacher had a great curriculum and the kids learned a lot, but this year we decided to switch things around and try them out on Arduinos. This spring, the kids are building a Lego display centered around a birthday party theme for the star elephant at the Oregon Zoo (Packy), who turned 50 last weekend. In a moment of fun, I suggested that perhaps we should have some fireworks, along with the presents and birthday cake. How hard could it be to wire up a couple of LEDs to an Arduino to make something that looked like fireworks? Selecting parts. Mike and I sat down to order some parts from Digikey. We found these nice, cheap, LED drivers from Sharp. Then we found a selection of LEDs from Cree along with current-programming resistors (12.7k ) to drive the LEDs at 20mA, and some bypass caps (0.1 F) to keep the parts happy. The LED drivers are simple shift registers, with separate clock and data. They have both input and output pins, so you can daisy chain them and drive as many as you like from a single pair of CPU pins. We figured 160 LEDs would be plenty, so we ordered 10 chips. The LED drivers came in a through-hole, DIP package; it seemed like we d be able to just stuff them into a breadboard and quickly wire things up. Prototyping the design The LED driver chips turn out to use a much finer pitch package than the usual 0.1 spacing. There s no way we could stuff them into a breadboard and quickly wire things up. Obviously, a bit more care while ordering would have uncovered this, but my experience with through-hole parts is limited to parts from the mid 1970s I soldered extension wires onto one chip to test the circuit, and managed to get one chip talking to an Arduino. Here s a short movie of that in action: You can see the LED driver chip sitting on a set of extension leads plugged into the breadboard. It s hooked to the SPI port on the Arduino board, with the clock set as fast as it will go. If you watch the video, you can see that the LEDs actually vary in brightness. They re actually being pulse-width modulated. Clocked at 2MHz, there s enough bandwidth in the SPI bus to drive 160 LEDs with 127 discrete pulse widths at nearly 100Hz (100 * 127 * 160 = 2032000). Is bread boarding practical? With the chip propped up on its extension wires, and the LEDs plugged in, the whole setup was not surprisingly fragile. Getting five of these chips wired up and running for the length of the Lego show (one day at school and two days at the zoo) seemed unlikely. So, we decided to build some custom circuit boards. Using the GEDA tools to make circuit boards My business partner, Bdale Garbee, and I build rocketry electronics through Altus Metrum. He s the hardware guy and I spend my weekends writing firmware for various micro-controllers. Of course, I use free software tools for the firmware, and Bdale uses the free gEDA tools for the hardware. I ve gotten vaguely familiar with those by helping Bdale review circuit diagrams and PC board layout over the years. So I figured I d be able to learn a bit more about them and come up with some designs. I decided to stick two LED drivers on each board. As the chips can drive each LED with up to 50mA of current, each board could potentially consume 1.6A at 5V. Sticking a linear regulator on each board capable of supplying that much current would have required a hefty heat sink. Instead, I decided to stick a mini USB connector on the board and use some cheap USB power supplies. Of course, there wasn t a pre-packaged schematic symbol or footprint for the LED driver, so I first had to construct those. But, with symbols for all of the parts I used available, I drew this circuit: Wiring up 32 LEDs It s really easy to draw wires showing 32 LEDs hooked up to each board. Actually selecting connectors that can be easily hooked up took a bit more time. The idea of crimping individual two-pin connectors for 160 LEDs didn t seem like fun, plus individual connectors were going to cost a small fortune (the best option I found would have cost about $0.40 per LED). Bdale suggested using ribbon cable with a crimp-on connector crimp a connector across the whole cable and then split out two-wire sets for each LED. I d still have to individually solder each LED to the wire, but on the board end, all I d have to do is crimp the connector on to the cable. Designing the circuit boards The gEDA tools separate schematic design and PCB layout into two separate tools; the schematic program, gschem, exports a netlist and set of components which the schematic program, PCB, can import. This sounded a bit clunky to me, as you have to re-export and re-import the schematic data into the PCB each time you make changes, but it seems to work reasonably well in practice. The first time the schematic data is imported to the PCB tool, all of the component footprints are simply stacked on top of one another. With those moved to sensible locations, the tool will show rats for each netlist. Having drawn the schematic with symbols that strongly resembled the actual components, it was pretty easy to work through the rats one at a time by painting copper on the board. I d noticed that all of the signals could easily be routed on one side of the board, so I flooded the back side with a ground plane to keep things quiet. The final circuit board design looks like this: Circuit boards. All Altus Metrum products are manufactured by Advanced Circuits, and we ve been quite happy with them. They offer a cheap and fast prototyping service through their barebonespcb.com site. These boards are two layers with no silk screen or solder mask. I uploaded my design and in a couple of days I got back some shiny circuit boards: The footprint I designed for the LED drivers turned out to have a very small gap between the pads for each pin and the ground plane. This lead to a couple of shorted pins in the five boards, which were pretty easy to diagnose as the LED driven by that pin would be stuck on. Here s another picture with the ribbon cable connected and an LED lit up: Mounting the LEDs I started by writing a small nickle program to simulate the trajectory of a ballistic fireworks shell followed by an explosion at apogee and subsequent ballistic tracks for the resulting pieces. I made the initial conditions of the launch somewhat random, and Mike and I sat and watched that draw things until we saw a couple that looked good . The output from that was a series of X/Y locations spaced uniformly in time. Mike used those to drill holes in a piece of acrylic from TAP plastics. He glued the LEDs into that with some white glue (so that we have a chance of getting them back out): A custom maple box? I spent last weekend visiting my father for his birthday. Meanwhile, Mike was busy back home building a case for the project. I got home and found that he had fabricated a solid maple case. It s beautiful, and holds all of the LEDs, boards, wires and a couple of 4-outlet USB power supplies. Here s a picture of the joint he made in the box corners: The finished product Here s the inside of the box: And here s a movie of the whole thing in action. It s missing 8 white LEDs; I hadn t ordered enough from Digikey. Downloading schematics and PCB artwork The hardware design is licensed under the TAPR Open Hardware License. It s all stored in git (of course):

git://keithp.com/git/hw/fireworks

All of the symbols I created are also available through git:

git://keithp.com/git/hw/keithp

Things I d do differently One of the frustrating things about moving atoms around instead of just bits is that once you ve got a physical artifact, it s really expensive to change it. There are a couple of minor things I would change if I were going to build more of these:

• Add mounting holes. Not having any way to mount the boards means that they re flopping around inside the cabinet. We ll probably find a way to tie them down somehow, but a couple of holes in the boards would have made that really easy.
• Increase the gap between the pin pads and the ground plane. The narrow space provided ample opportunity for solder bridges. I ve increased that spacing in the git repository version of the boards.
• Used a variable resistor for LED current control. With a fixed value, it s very difficult to adjust the relative brightness of the LEDs. Even though we used LEDs from the same series, the different colors have different apparent brightness.
• Used surface mount passives. We had bought through-hole parts when the plan was to build these on a breadboard, but soldering through-hole parts onto the board is more work than using surface mount parts. 0805 (or even 1206) parts are plenty large to solder by hand and are faster to deal with than having to fold leads, insert them into holes, flip the boards over, solder them down and trim the leads.
• Perhaps we went a bit overboard on this project

Things that worked well There were a couple of things that went better than I had expected:

• The gEDA tools aren t that hard to use. Constructing the circuit board really was a simple matter of painting with copper. If you can drive inkscape, you can make circuit boards.
• Advanced Circuits bare-bones PCB service. It was really cool to upload the output files from gEDA and have actual boards arrive in the mail a couple of days later.
• Building the boards. I really didn t expect all of the components to just fit in the boards; I figured I d mess up the footprints or drill sizes and end up kludging something onto the boards. Bdale did catch a small drill size on the LED driver pins, which I bumped up a bit, but other than that, all of the parts slipped in and soldered easily. Each board took about 10 minutes to put together.

Samuel Thibault is a French guy like me, but it took years until we met. He tends to keep a low profile, even though he s doing lots of good work that deserves to be mentioned. He focuses on improving Debian s accessibility and contributes to the Hurd. Who said he s a dreamer? Checkout his interview to have some news of Wheezy s status on those topics. Raphael: Who are you? Samuel: I am 30 years old, and live in Bordeaux, France. During the workday, I teach Computer Science (Architecture, Networking, Operating Systems, and Parallel Programming, roughly) at the University of Bordeaux, and conduct researches in heterogeneous parallel computing. During the evening, I play the drums and the trombone in various orchestra (harmonic/symphonic/banda/brass). During the night, I hack on whatever fun things I can find, mainly accessibility and the Hurd at the moment, but also miscellaneous bits such as the Linux console support. I am also involved in the development of Aquilenet, an associative ISP around Bordeaux, and getting involved in the development of the network infrastructure in Bordeaux. I am not practicing Judo any more, but I roller-skate to work, and I like hiking in the mountains. I also read quite a few mangas. Saturday mornings do not exist in my schedule (Sunday mornings do, it s Brass Band rehearsal ). Raphael: How did you start contributing to Debian? Samuel: Bit by bit. I have been hacking around GNU/Linux since around 1998. I installed my first Debian system around 2000, as a replacement for my old Mandrake installation (which after all my tinkering was actually no longer looking like a Mandrake system any more!). That was Potato at the time, which somebody offered me through a set of CDs (downloading packages over the Internet was unthinkable at the time with the old modems). I have been happily reading and hacking around documentation, source code, etc. provided on them. Contribution things really started to take off when I went to the ENS Lyon high school in 2001: broadband Internet access in one s own student room! Since sending a mail was then really free, I started submitting bugs against various packages I was using. Right after that I started submitting patches along them, and then patches to other bugs. I did that for a long time actually. I had very little knowledge of all packaging details at the time, I was just a happy hacker submitting reports and patches against the upstream source code. At ENS Lyon, I met a blind colleague with very similar hacking tastes (of course we got friends) and he proposed me, for our student project, to work on a brlnet project (now called brlapi), a client/server protocol that lets applications render text on braille devices themselves. Along the way, I got to learn in details how a blind person can use a Unix system and the principles that should be followed when developing Accessibility. That is how I got involved in it. We presented our project at JDLL, and the Hurd booth happened to be next to our table, so I discussed with the Hurd people there about how the Hurd console could be used through braille. That is how I got into the Hurd too. From then on, I progressively contributed more and more to the upstream parts of both accessibility software and the Hurd. And then to the packaging part of them. Through patches in bug reports first, as usual, as well as through discussions on the mailing lists. But quickly enough people gave me commit access so I could just throw the code in. I was also given control over the Hurd buildds to keep them running. It was all good at that stage: I could contribute in all the parts I was caring about. People however started telling me that I should just apply for being a Debian Developer; both from accessibility and Hurd sides. I had also seen a bunch of my friends going through the process. I was however a bit scared (or probably it was just an excuse) by having to manage a gpg key, it seemed like a quite dangerous tool to me (even if I already had commit access to glibc at the time anyway ). I eventually applied for DM in 2008 so as to at least be able to upload some packages to help the little manpower of the Accessibility and Hurd teams. Henceforth I had already a gpg key, thus no excuse any more. And having it in the DM keyring was not enough for e.g. signing the hurd-i386 buildd packages. So I ended up going through NM in 2009, which went very fast, since I had already been contributing to Debian and learning all the needed stuff for almost 10 years! I now have around 50 packages in my QA page, and being a DD is actually useful for my work, to easily push our software to the masses So to sum it up, the Debian project is very easy to contribute to and open to new people. It was used during discussions at the GNU Hackers Meeting 2011 as an example of a very open community with public mailing lists and discussions. The mere fact that anybody can take the initiative of manipulating the BTS (if not scared by the commands) without having to ask anybody is an excellent thing to welcome contributions; it is notable tha the GNU project migrated to the Debbugs BTS. More generally, I don t really see the DD status as a must, especially now that we have the DM status (which is still a very good way to drag people into becoming DDs). For instance, I gave a talk at FOSDEM 2008 about the state of accessibility in Debian. People did not care whom I was, they cared that there was important stuff going on and somebody talking about it. More generally, decisions that are made through a vote are actually very rare. Most of the time, things just happen on the mailing lists or IRC channels where anybody can join the discussion. So I would recommend beginners to first use the software, then start reporting bugs, then start digging in the software to try fix the bugs by oneself, eventually propose patches, get them reviewed. At some point the submitted patches will be correct already most of the time. That s when the maintainers will start getting bored of just applying the patches, and simply provide with commit access, and voil , one has become a main contributor. Raphael: You re one of the main contributors to the Debian GNU/Hurd port. What motivates you in this project? Samuel: As I mentioned above, I first got real contact with the Hurd from the accessibility point of view. That initially brought me into the Hurd console, which uses a flexible design and nice interfaces to interact with it. The Hurd driver for console accessibility is actually very straightforward, way simpler than the Windows or Linux drivers. That is what caught me initially. I have continued working on it for several reasons. First, the design is really interesting for users. There are many things that are natural in the Hurd while Linux is still struggling to achieve them, such as UID isolation, recently mentioned in LWN. What I really like in the Hurd is that it excels at providing users with the same features as the administrator s. For instance, I find it annoying that I still can not mount an ISO image that I build on e.g. ries.debian.org. Linux now has FUSE which is supposed to permit that, but I have never seen it enabled on an ssh-accessible machine, only on desktop machines, and usually just because the administrator happens to be the user of the machine (who could as well just have used sudo ) For me, it is actually Freedom #0 of Free Software: let the user run programs for any purpose, that is, combining things together all the possible ways, and not being prevented from doing some things just because the design does not permit to achieve them securely. I had the chance to give a Hurd talk to explain that at GHM 2011, whose main topic was extensibility , I called it GNU/Hurd AKA Extensibility from the Ground, because the design of the Hurd is basically meant for extensibility, and does not care whether it is done by root or a mere user. All the tools that root uses to build a GNU/Hurd system can be used by the user to build its own GNU/Hurd environment. That is guaranteed by the design itself: the libc asks for things not to the kernel, but to servers (called translators), which can be provided by root, or by the user. It is interesting to see that it is actually also tried with varying success in GNU/Linux, through gvfs or Plash. An example of things I love being able to do is: $ zgrep foo ~/ftp://cdn.debian.net/debian/dists/sid/main/Contents-*.gz On my Hurd box, the ~/ftp: directory is indeed actually served by an ftpfs translator, run under my user uid, which is thus completely harmless to the system. Secondly and not the least, the Hurd provides me with interesting yet not too hard challenges. LWN confirmed several times that the Linux kernel has become very difficult to significantly contribute to, so it is no real hacking fun any more. I have notably implemented TLS support in the Hurd and the Xen and 64bit support in the GNU Mach kernel used by the Hurd. All three were very interesting to do, but were already done for Linux (at least for all the architectures which I actually know a bit and own). It happens that both TLS and Xen hacking experience became actually useful later on: I implemented TLS in the threading library of our research team, and the Xen port was a quite interesting line on my CV for getting a postdoc position at XenSource Lastly, I would say that I am used to lost causes My work on accessibility is sometimes a real struggle, so the Hurd is almost a kind of relief. It is famous for his vapourware reputation anyway, and so it is fun to just try to contribute to it nevertheless. An interesting thing is that the opinion of people on the Hurd is often quite extreme, and only rarely neutral. Some will say it is pure vapourware, while others will say that it is the hope of humanity (yes we do see those coming to #hurd, and they are not always just trolls!). When I published a 0.401 version on 2011 April 1st, the comments of people were very diverse, and some even went as far as saying that it was horrible of us to make a joke about the promised software Raphael: The FTPmasters want to demote the Hurd port to the debian-ports.org archive if it doesn t manage a stable release with wheezy. We re now at 2 months of the freeze. How far are you from being releasable ? Samuel: Of course, I can not speak for the Debian Release team. The current progress is however encouraging. During Debconf11, Michael Banck and I discussed with a few Debian Release team members about the kind of goals that should be achieved, and we are near completion of that part. The Debian GNU/Hurd port can almost completely be installed from the official mirrors, using the standard Debian Installer. Some patches need some polishing, but others are just waiting for being uploaded Debian GNU/Hurd can start a graphical desktop and run office tools such as gnumeric, as well as the iceweasel graphical web browser, KDE applications thanks to Pino Toscano s care, and GNOME application thanks to Emilio Pozuelo Monfort s care. Of course, general textmode hacking with gcc/make/gdb/etc. just works smoothly. Thanks to recent work on ghc and ada by Svante Signell, the archive coverage has passed 76%. There was a concern about network board driver support: until recently, the GNU Mach kernel was indeed still using a glue layer to embed the Linux 2.2 or even 2.0 drivers (!). Finding a network board supported by such drivers had of course become a real challenge. Thanks to the GSoC work of Zheng Da, the DDE layer can now be used to embed Linux 2.6.32 drivers in userland translators, which was recently ACCEPTed into the archive, and thus brings way larger support for network boards. It also pushes yet more toward the Hurd design: network drivers as userland process rather than kernel modules. That said, the freeze itself is not the final deadline. Actually, freeze periods are rests for porters, because maintainers stop bringing newer upstream versions which of course break on peculiar architectures. That will probably be helpful to continue improving the archive coverage. Raphael: The kfreebsd port brought into light all the packages which were not portable between different kernels. Did that help the Hurd port or are the problems too different to expect any mutual benefit? Samuel: The two ports have clearly helped each other in many aspects. The hurd-i386 port is the only non-Linux one that has been kept working (at least basically) for the past decade. That helped to make sure that all tools (dpkg, apt, toolchain, etc.) were able to cope with non-Linux ports, and keep that odd-but-why-not goal around, and evidently-enough achievable. In return, the kFreeBSD port managed to show that it was actually releasable, at least as a technological preview, thus making an example. In the daily work, we have sometimes worked hand in hand. The recent porting efforts of the Debian Installer happened roughly at the same time. When fixing some piece of code for one, the switch-case would be left for the other. When some code could be reused by the other, a mail would be sent to advise doing so, etc. In the packaging effort, it also made a lot of difference that a non-Linux port is exposed as released architecture: people attempted by themselves to fix code that is Linuxish for no real reason. The presence of the kFreeBSD is however also sometimes a difficulty for the Hurd: in the discussions, it sometimes tends to become a target to be reached, even if the systems are not really comparable. I do not need to detail the long history of the FreeBSD kernel and the amount of people hacking on it, some of them full-time, while the Hurd has only a small handful of free-time hackers. The FreeBSD kernel stability has already seen long-term polishing, and a fair amount of the Debian software was actually already ported to the FreeBSD kernel, thanks to the big existing pure-FreeBSD hackerbase. These do not hold for the GNU/Hurd port, so the expectations should go along. Raphael: You re also very much involved in the Debian Accessibility team. What are the responsibilities of this team and what are you doing there? Samuel: As you would expect it, the Debian Accessibility team works on packaging accessibility-related packages, and helping users with them; I thus do both. But the goal is way beyond just that. Actual accessibility requires integration. Ideally enough, a blind user should be able to just come to a Debian desktop system, plug his braille device, or press a shortcut to enable speech synthesis, and just use the damn computer, without having to ask the administrator to install some oddly-named package and whatnot. Just like any sighted user would do. He should be able to diagnose why his system does not boot, and at worse be able to reinstall his computer all by himself (typically at 2am ). And that is hard to achieve, because it means discussing about integration by default of accessibility features. For instance, the Debian CD images now beep during at the boot menu. That is a precious feature that has been discussed between debian-boot and debian-accessibility for a few weeks before agreeing on how to do it without too much disturbance. Similarly, my proposition of installing the desktop accessibility engines has been discussed for some time before being commited. What was however surprisingly great is that when somebody brought the topic back for discussion, non-debian-accessibility people answered themselves. This is reassuring, because it means things can be done durably in Debian. On the installation side, our current status is that the stable Debian installer has a high contrast color theme, and several years ago, I have pushed toward making standard CD images automatically detect braille devices, which permits standalone installation. I have added to the Wheezy installer some software speech synthesis (which again brought discussion about size increase vs versatility etc.) for blind people who do not have a braille device. I find it interesting to work on such topic in Debian rather than another distribution, because Debian is an upstream for a lot of distributions. Hopefully they just inherit our accessibility work. It at least worked for the text installer of Ubuntu. Of course, the Accessibility team is looking for help, to maintain our current packages, but also introduce new packages from the TODO list or create some backports. One does not need to be an expert in accessibility: tools can usually be tested, at least basically, by anybody, without particular hardware (I do not own any, I contributed virtual ones to qemu). For new developments and ideas, it is strongly recommended to come and discuss on debian-accessibility, because it is easy to get on a wrong track that does not bring actual accessibility. We still have several goals to achieve: the closest one is to just fix the transition to gnome3, which has been quite bad for accessibility so far :/ On the longer run, we should ideally reach the scenario I have detailed above: desktop accessibility available and ready to be enabled easily by default. Raphael: What s the biggest problem of Debian? Samuel: Debian is famous for its heated debian-devel discussions. And some people eventually say this no fun any more . That is exemplified in a less extreme way in the debian-boot/accessibility discussions that I have mentioned above. Sometimes, one needs to have a real stubborn thick head to continue the discussion until finding a compromise that will be accepted for commit. That is a problem because people do not necessarily have so much patience, and will thus prefer to contribute to a project with easier acceptance. But it is also a quality: as I explained above, once it is there, it is apparently for good. The Ubuntu support of accessibility in its installer has been very diverse, in part due to quite changing codebase. The Debian Installer codebase is more in a convergence process. Its base will have almost not changed between squeeze and wheezy. That allowed the Debian Accessibility team to continue improving its accessibility support, and not have to re-do it. A wiki page explains how to test its accessibility features, and some non-debian-accessibility people do go through it. A problem I am much more frightened by is the manpower in some core teams. The Debian Installer, grub, glibc, Xorg, gcc, mozilla derivatives, When reading the changelogs of these, we essentially keep seeing the same very few names over and over. And when one core developer leaves, it is very often still the same names which appear again to do the work. It is hard to believe that there are a thousand DDs working on Debian. I fear that Debian does not manage to get people to work on core things. I often hear people saying that they do not even dare thinking about putting their hands inside Xorg, for instance. Xorg is complex, but it seems to me that it tends to be overrated, and a lot of people could actually help there, as well as all the teams mentioned above. And if nobody does it, who will? Raphael: Do you have wishes for Debian Wheezy? Samuel: That is an easy one Of course I wish that we manage to release the hurd-i386 port. I also wish that accessibility of gnome3 gets fixed enough to become usable again. The current state is worrying: so much has changed that the transition will be difficult for users already, the current bugs will clearly not help. I also hope to find the time to fix the qt-at-spi bridge, which should (at last!) bring complete KDE accessibility. Raphael: Is there someone in Debian that you admire for their contributions? Samuel: Given the concerns I expressed above, I admire all the people who do spend time on core packages, even when that is really not fun everyday. Just to alphabetically name a few people I have seen so often here and there in the areas I have touched in the last few years: Aur lien Jarno, Bastian Blank, Christian Perrier, Colin Watson, Cyril Brulebois, Frans Pop, J rg Jaspert, Joey Hess, Josselin Mouette, Julien Cristau, Matthias Klose, Mike Hommey, Otavio Salvador, Petr Salinger, Robert Millan, Steve Langasek. Man, so many things that each of them works on! Of course this list is biased towards the parts that I touched, but people working in others core areas also deserve the same admiration.

---

Thank you to Samuel for the time spent answering my questions. I hope you enjoyed reading his answers as I did. Note that older interviews are indexed on wiki.debian.org/PeopleBehindDebian.

Subscribe to my newsletter to get my monthly summary of the Debian/Ubuntu news and to not miss further interviews. You can also follow along on Identi.ca, Google+, Twitter and Facebook.

3 comments Liked this article? Click here. My blog is Flattr-enabled.

At a customer, I've migrated a number of manually-maintained servers to having them be maintained through puppet not so long ago. Since then, some more machines have been added, and getting them up and running properly was a breeze: do a base install, install puppet, sign the certificate, restart puppet, and then wait and twiddle thumbs while puppet did its magic. Easy as pie. Now, a few months later, we needed to install a number of windows machines for a lab (not my choice), and the person involved asked me to figure out some diskspace so we could start creating images for those. Not a chance. Instead, I suggested looking for a configuration management system, similar to puppet. Since we're using Samba 3 to run the Windows network here, dropping everything in Active Directory was not an option. But a short while later, he came back with the note that puppet, in its 2.7 version, actually does support Windows as a platform for the managed machines. Interesting. The unfortunate bit was that puppet supports creating files and installing software when it is distributed as an MSI file, but not when it's distributed as a .exe file. This is not unexpected; MSI files can be installed noninteractively; but when something is distributed as a .exe file, it means it needs to be installed interactively; and puppet does not have the ability to interact with GUI software. The workaround: use something that does have that ability (in my case, autoit), and use an exec block in puppet to make it call those scripts. In effect, that's a bit like screenscraping. Add a creates stanza to the block, so that the installer isn't started again if the software at hand has already been installed. This 'autoit' thing also comes with a recording utility, allowing one to create an initial script by just doing the installation, and having the tool just record stuff. With that, the machines are installed 99% automated. I say 99%, because there are still some issues:

• Some software ships with an embedded google toolbar and an embedded google chrome. Not only do we not want that, it also makes automatic installation a Very Hard problem: if you install the software the very first time, it asks you whether you want to install Google Toolbar. If you decline, the rest of the installation is shown, and a registry key is set. If you then uninstall and reinstall, the Google Toolbar question isn't shown; instead, the Chrome question is shown. If you decline that, then the same happens with a different registry key.
  Google doesn't actually document where these keys are set, or how it can be disabled for any software that might possibly have embedded toolbars or browsers. Or, well if it does document it, I certainly didn't find any documentation about it; the fact that google tells me "you're running Linux, you don't need Google Toolbar, go fuck yourself" when I go to the toolbar.google.com website isn't very helpful.
  Anyway, the keys are under HKLM\Software\Google. You can't miss them.
• This being Windows, sometimes the machine needs to be rebooted after an installation. The Windows Installer software, msiexec.exe, signals this fact by exiting with an exit state of 3010. Unfortunately, puppet doesn't understand that, causing it to mark the installation as failed, and retrying it on the next run. That's annoying.
• Sometimes, telling the machine to postpone rebooting causes the next installation to behave slightly differently, which will cause the autoit script to fail. When that happens, I need to kill autoit, exit the installer for the failed application, and allow puppet to finish. After that, and after a reboot of the machine and restart of puppet, everything works well.
• To be able to install software, Windows may sometimes need to kill some applications, or may need to take focus. This may interfere with the lab readings these machines will be used for, so is not an option. Instead, I've decided not to ever run puppet agent as a service, instead always calling it manually with the '--onetime' option, so it quits once the manifest is applied. Unfortunately, that makes it harder to update things; I'll have to walk by each and every one of the machines if I ever need to add something. I did consider adding that to a login script, but then the user logging in to the machine will most likely not ever have the required privileges to actually do what puppet needs done.

I'll have to think about this some more, I guess. First, it's clear that while puppet does have some Windows functionality, it's not entirely ready yet. And somehow, using autoit to add to Puppet functionality feels like an ugly hack. We'll see what the future brings.

Google rant Seems venting can be a worthwhile once in a while; the content of this post made its way into Google. No promises of any kind were made, but it's good to know that this is getting some exposure within Google :) That was quick. moreutils et al Steve Kemp is right; moreutils is very useful in some situations. And yes, it's a pity that we all have our own scripts without a central repository to host them all. The problem is one of diminishing returns and information overload; if any given collection becomes too large, it becomes tedious to look through it. You may have the Most Awesome Ever solution to any given problem, but unless whoever needs it can find it quickly, it's useless to them. Thorsten Glaser suggested this collection, but it suffers from the same basic problem: Not enough content? You won't find what you need. Too much content? You won't find what you need. Finding the right balance is highly non-trivial. Linux storage Russell Coker shared yet another chapter of his continuing quest for modern, reliable, software-based storage on Linux. The short version is "ZFS is not that good on Linux while btrfs is not ready for prime time, yet." That's, unfortunately, not much of a surprise. fsck.btrfs is still too new and the lack of RAID 5/6 is an absolute show-stopper as far as I am concerned. COW solves the writing speed issues so, hopefully, that old argument can finally be laid to rest. And on top of the "wastng" of more disks for RAID 10, the minimum number of failed disks that can lead to data loss on RAID 10 is two whereas it's three for RAID 6. No-brainer, imo. Anyone who does not agree with Dell's pricing structure should seriously consider looking at SuperMicro, by the way. Cheap(ish), reliable, high disk densities. Password hashes Saku Ytti talks about password hashing and the relative merits of different algorithms. While I agree that bcrypt incorporates a good approach inasmuch it's designed to be slow to compute and can be made slower as needed, I think he focuses on one aspect while disregarding all others. Still, the premise that deterring brute force attacks on known hashes is the only concern is wrong. Avoiding collisions, reasonable certainty that there are no computational shortcuts, irreversibility, pseudo-random output, full use of the output's possible values, and thorough analysis by experts in the field are important concerns, as well. Brute forcing known hashes is hardly the only attack. When brute forcing a service, i.e. against an unknown hash, no matter if the system is remote or local, the computational cost of hashing is mostly irrelevant. Rainbow tables help mitigate computational cost when trying to extract clear text in case the hash is known. And if there are a lot of collisions or an easy way to find them, knowing the clear text password is not needed. Simply use whatever generates the correct output and you're done. Again, I am not saying that bcrypt is a bad idea; it's just that there are more concerns than computational cost alone. Travel If you know your way around Novosibirsk, please contact me. We have almost no idea what to do while there other than visiting the railroad museum; part of the reason why we are stopping there is to have a break after ~50 hours on the train and because Novosibirsk is just an awesome name. Our focus while there will be on seeing interesting industrial or research sites. Given that there are large industrial complexes and formerly secret cold war secret research cities situated around Novosibirsk it would be a pity not to see any of them. We may end up hiring a taxi via the hotel and having that drive us around a bit. Somewhat boring and potentially costly, but a feasible backup. Blogging frequency I have to admit being am a bit worried about spamming the various aggregators which are fed from this blog. Writing this catchall post is an attempt to mitigate this. While I am getting a surprising amount of positive feedback, I would be interested to hear anything negative, if applicable, as well. You know how to reach me.

Google seems to become more and more annoying. Package download http://dl.google.com/linux/chrome/deb/ is slow. Not just slow, but slow. Any random apt-get update will take ages; just sitting there waiting for Google's servers to send any data. Downloading actual packages is slow, as well. Ironically, Google's PageRank will punish sites for loading slowly; it's a pity they don't use their considerable server & bandwidth capacities to fix slowness they are causing, themselves. Chrome Copy and paste is a central part of what I use a mouse for. X has had two copy buffers for as long as I can remember, one for mouse selection, pasting with middle mouse button and one for CTRL-c/CTRL-v. Chrome merges the two. That's bad enough in and as of itself, but every time Chrome gets focus, it will clobber anything you may have in your copy buffers at that time with anything that's selected. No matter if you selected it via mouse, via keyboard, a context switch autoselected something. Selection goes into buffer. Every time. Every. Single. Time. To add insult to injury, this is dependent on which tab is active. And if you happen to search on the site (CTRL-f), it will always use what's in the search bar to clobber buffers, no matter if anything on the actual website has been selected. I can't find the bug report about this at the moment, but Google's stance is that this is a feature and introducing an option for traditional copy & paste handling is not desirable. Google+ I get that they feel a need to combat Facebook, but still, pushing Google+ on you is just annoying. At least the Android application has had a permission change on ICS so it can not auto-update. It's the little things ;) WWW Unified branding, the need to support touch-based devices in their UI, etc. Still, GMail's new interface sucks and the old one will be going away for good. And while making some UI elements larger or displaying them unconditionally makes sense for hand-held portrait displays, this is highly annoying on wide-screen landscape displays. 1366x768 may have overtaken 1024x768, but 768 is a constant here and still not a lot. As an aside, hopefully the Apple Effect and the iPad 3 will break the age-long stalemate with regards to screen resolution. More is better, here. Android Bloatware Using stock Android means you won't get Facebook and other useless apps pre-installed. Yet, uninstalling stock applications, like Google+, is impossible. Rights management It's nice that I get to see what kind of access an application would like to have. It's not nice that I can not choose what access I am willing to grant any given application. I can make a binary decision, install or not install, but I can't refuse random access rights to applications. There are custom versions of Android out there which allow you to do this and many applications seem to cope with being unable to do some things. This should be a standard feature. Access management The concept of "access to USB storage" meaning "whatver your SD card or, in the Galaxy Nexus' case, just a specific directory" is also broken. There is a middle ground between "this application needs access to a large chunk of storage" and "this application needs complete access to said large chunk". Just assign the application a specific directory to write into and read from and done's done. Multi-user I can not hand anyone my phone to play a game or surf the Internet without giving them the ability to look through all my email, contacts, calendar, you name it. While I only give my phone to people I trust completely, this still sucks. How hard can it be to create a minimal guest mode which allows people to access a few pre-selected applications with a custom setting of if they are allowed to use cellular data and/or WiFi? Data access Authorized Access Ah, the big one.... Keep in mind that I am using Google's latest and greatest, the Samsung Galaxy Nexus GSM. It's as cutting-edge as you can get. Yes, having one continuous storage device is nice. But MTP support on Linux is abysmal and you are forced to access your data by means of MTP or PTP. gphoto2, gwenview, and gthumb are all unable to import any photos via PTP; no program I tried can transfer anything via MTP. gphoto2 will transfer the background images which APOD (highly recommended, by the way; there's also a donation application for this) stores on my phone. That's it. So, unless I send email to myself, use WiFi-based hacks, or root my phone, I can not access my data. On the strongest mobile platform in the world. Using the most powerful and versatile OS with up-to-date packages. In 2012. Yay. Unauthorized Access Not being able to access my data is a Bad Thing. Even worse is when others can access my data. Contrary to older Android versions, someone decided that it would be a good idea to allow MTP or PTP, only. As in "you can not disable MTP and PTP. One of them has the be activated." This is awesome when you want to charge your phone at an airport or at an acquaintance's possibly malware-ridden Windows machine. Everyone and their bot-herder can potentially access my data while I can not. Usability And while MTP/PTP is an either/or decision, they are using check-boxes, not radio buttons. There's a decade or more of UI experience about check-box versus radio button, so why not use it? I know of at least one owner of a Galaxy Nexus who was not even aware that he couldn't turn off MTP (the default) as the UI pretends otherwise. Opaqueness And good luck trying to contact anybody about this. Having filed a few bugs against Google stuff in the past, I simply gave up on it. Back when Gmail's mailing list filtering and labelling system was somewhat broken, I spent months hunting down people who knew people who knew someone who was able to actually do something about it.

Still waiting for mine - though I did buy a case for when it comes. News from www.raspberrypi.org - the prototype submitted for EMC testing has apparently passed, though the paperwork has to be validated (blog posting).
It has passed CE marking, FCC part 15 marking, Canadian certification and the Australian C-Tick scheme. There is also an updated trademark policy at new trademark rules ( http://www.raspberrypi.org/trademark-rules ) and a video over at the Farnell/Element14 website from Eben Upton detailing how to set up the Raspberry Pi, shots of booting, explanations of how to use an editor, compile a first Python program and how to build the graphics demos provided. ( http://www.element14.com/community/docs/DOC-44459 )

One of my clients is currently investigating new hosting arrangements. It s a bit of a complex process because there are lots of architectural issues relating to things such as the storage and backup of some terabytes of data and some serious computation on the data. Among other options we are considering cheap servers in the EX range from Hetzner [1] which provide 3TB of RAID-1 storage per server along with reasonable CPU power and RAM and Amazon EC2 [2]. Hetzner and Amazon aren t the only companies providing services that can be used to solve my client s problems, but they both provide good value for what they provide and we have prior experience with them. To add an extra complication my client did some web research on hosting companies and found that Hetzner wasn t even in the list of reliable hosting companies (whichever list that was). This is in some ways not particularly surprising, Hetzner offers servers without a full management interface (you can t see a serial console or a KVM, you merely get access to reset it) and the best value servers (the only servers to consider for many terabytes of data) have SATA disks which presumably have a lower MTBF than SAS disks. But I don t think that this is a real problem. Even when hardware that s designed for the desktop is run in a server room the reliability tends to be reasonable. My experience is that a desktop PC with two hard drives in a RAID-1 array will give a level of reliability in practice that compares very well to an expensive server with ECC RAM, redundant fans, redundant PSUs, etc. My experience is that the most critical factor for server reliability is management. A server that is designed to be reliable can give very poor uptime if poorly maintained or if there is no rapid way of discovering and fixing problems. But a system that is designed to be cheap can give quite good uptime if well maintained, if problems can be repidly discovered and fixed. A Brief Overview of Managing Servers There are text books about how to manage servers, so obviously I can t cover the topic in detail in a blog post. But here are some quick points. Note that I m not claiming that this list includes everything, please add comments about anything particularly noteworthy that you think I ve missed.

1. For a server to be well managed it needs to be kept up to date. It s probably a good idea for management to have this on the list of things to do. A plan to check for necessary updates and apply them at fixed times (at least once a week) would be a good thing. My experience is that usually managers don t have anything to do with this and sysadmins either apply patches or not at their own whim.
2. It is really ideal for people to know how all the software works. For every piece of software that s running it should either have come from a source that provides some degree of support (EG a Linux distribution) or be maintained by someone who knows it well. When you install custom software from people who become unavailable then it puts the reliability of the entire system at risk if anything breaks then you won t be able to get it fixed quickly.
3. It should be possible to rapidly discover problems, having a client phone you to tell you that your web site is offline is a bad thing. Ideally you will have software like Nagios monitoring the network and reporting problems via a SMS gateway service such as ClickaTell.com. I am not sure that Nagios is the best network monitoring system or that ClickaTell is the best SMS gateway, but they have both worked well in my experience. If you think that there are better options for either of those then please write a comment.
4. It should be possible to rapidly fix problems. That means that a sysadmin must be available 24*7 to respond to SMS and you must have a backup sysadmin for when the main person takes a holiday, or ideally two backup sysadmins so that if one is on holiday and another has an emergency then problems can still be fixed. Another thing to consider is that an increasing number of hotels, resorts, and cruise ships are providing net access. So you could decrease your need for backup sysadmins if you give a holiday bonus to a sysadmin who uses a hotel, resort, or cruise ship that has good net access. ;)
5. If it seems likely that there may be some staff changes then it s a really good idea to hire a potential replacement on a casual basis so that they can learn how things work. There have been a few occasions when I started a sysadmin contract after the old sysadmin ceased being on speaking terms with the company owner. This made it difficult for me to learn what s going on.
6. If your network is in any way complex (IE it s something that needs some skill to manage) then it will probably be impossible to hire someone who has experience in all the areas of technology at a salary you are prepared to pay. So you should assume that whoever you hire will do some learning on the job. This isn t necessarily a problem but is something that needs to be considered. If you use some unusual hardware or software and want it to run reliably then you should have a spare system for testing so that the types of mistake which are typically made in the learning process are not made on your production network.

Conclusion If you have a business which depends on running servers on the Internet and you don t do all the things in the above list then the reliability of a service like Hetzner probably isn t going to be an issue at all.

• [1] http://www.hetzner.de/hosting/produktmatrix/rootserver-produktmatrix-ex
• [2] http://aws.amazon.com/ec2/

Related posts:

1. Servers vs Phones Hetzner have recently updated their offerings to include servers with...
2. Why Internet Access in Australia Sucks In a comment on my post about (relatively) Cheap Net...
3. The National Cost of Slow Internet Access Australia has slow Internet access when compared to other first-world...

Another weekend, another running opportunity! This was a nice, simple, fast race. The announcer was claiming (if I understood correctly) it is the fastest race around Z rich: completely flat, on an airfield (which unfortunately meant all paved road). The weather was perfect (for running), a bit cold but no problems with overheating. So I managed my fastest time ever: according to the my Garmin (which for the first time recorded a slightly longer distance than the official one), I managed to run 10.18km in 50:39, which makes it 4:58/km! For the first time, below the 5:00 mark, yay! I'll ignore the official marking which claimed 10km in 50:57, since that ruins my nice result, hah! Back to earth however let's see some stats about this race. Just to put it in context: My current running speed is lower than the winner in the 70+ age category by a significant amount. Based on the graph shape, I would probably win at the 85+ category . Or to put it in a slightly different context, a cultural one. Back in my home country (Romania), a 70-year old person (especially male!) that is still able to move around well and to manage by himself is (most of the time) an exception. Of course there are many old men who are doing well, but in general old people are (usually) considered deprecated by this age. In comparison, in Switzerland, they are still active and are doing sport. And some of them, as you can see, doing it quite well. The difference between these two cultures in this regard (sport) is huge. Doing sports (except playing football) is considered something unusual, and in my home town there's a somewhat linear relation between people's age and their weight (both are monotonically increasing). When I first came to Switzerland, I was shocked to see so many people over 50 that are fit and active. Now, every time I go back to Romania, I'm shocked to see people so many people overweight and looking more than their actual age. I can't help but wonder what is the cause of this disregard for health or aversion to sports. Just the fact that "it's expected" for older people to be unhealthy? Is it somehow related to the difference in income/standard of life (I can't see a trivial connection)? Is it to lack of education about how to live a healthy life? Or maybe it's not a country difference, but rather the fact that I grew up in a quite small town; people in Bucharest are indeed looking more after their health than in my home town, and are therefore fitter. Who knows Anyway, rant over, and I'm still happy that I managed to beat my own record, thanks to a flat race and favourable weather!

Now that our departure is looming ahead of us, it's time to give a short update. (Turns out it's not so short, after all...) Preparation Visa Mongolian and Russian visas are done; we will apply for the Chinese ones next Monday. Travel All train tickets, hotels, hostels, and tents have been booked and both a horse-back tour through Mongolia and scuba diving in Lake Baikal have been pre-arranged. The Russian railway seems to do maintenance and development on the live website all the time which meant we were forced to book through a local travel agent. We paid a hefty extra charge for that privilege but still, that was less than half of what we would have paid if we had booked through a German agent. With the help of #china-lug on irc.freenode.net, we found accommodation in a traditional Siheyuan in an old Hutong. Hopefully, this will be a interesting as it sounds. Locals By the power of attending conferences and this blog, I now have local contacts in Moscow, Beijing, and Shanghai. Everyone who contacted me was extremely nice and helpful. I have been getting hints and tips galore; I doubt our preparations would be as neat as they are without this invaluable help. Thanks; you know who you are :) Packing list Apparently there's an interest in what we will be bringing; also, this will be a nice reminder for the future. Information and note-keeping

• Travel guides for the Trans-Siberian and Beijing (in case you use Lonely Planet books, the new layout they are using as of late is a lot better)
• Phrase books for Russian, Mongolian, and Mandarin
• Print-out of all bookings, etc.
• Paper notebook to track expenses, make notes, cross-reference photos, and various other uses
• Several sturdy ball pens
• Post-It notes and those neon-colored self-adhesive marker flags
• Permanent marker

Luggage

• Two Backpacks
• Deuter Helion 80, a duvel bag with wheels which transforms into a proper backpack. This. Is. Awesome.
• Rain covers for all bags

Clothing

• Heavy-duty hiking boots
• Sneakers
• Fleece jacket
• Hard shell jacket
• Worker's pants (pockets, pockets, pockets!)
• Base-ball cap (against sund and for propping up the hood of hood if neccessary)
• Wind-tight hat with close-fitting ear flaps (looks like crap, but is the best I ever had)
• Long underwear
• Assorted T-Shirts, socks, etc.

Personal and computer security

• Kubotan
• Copies of all documents, tickets, visas, etc.; apparently you should never hand originals of any documents to Russian police
• Hand-held GPS
• Two-way GPS tracking beacon with satellite uplink
• US Dollars as backup currency
• Second pair of glasses
• Old laptop with 1 TB drive and a fresh installation of Debian with no personal data, ssh keys, etc.
• VPN & SSH access to a throw-away virtual host back home
• Old dumbphone

Fastening, storage, and tools

• Reflective guy-wire with knot-less tighteners
• Bracelets made from braided para cord with whistle built into the clasp
• Stainless steel bolt-snaps
• Zip ties, assorted lengths
• Zip-Loc bags
• Plastic clamps for open bags, etc.
• Victorinox Swisstool with ratchet and bits (Leatherman, Gerber, you name it, can't even get close in quality)
• Pocket knife
• Cut-proof Kevlar gloves with latex anti-slip covering
• Ballistol (oil, skin protection, dealing with cuts, and for cleaning cutlery)
• Silicone grease
• MoS₂ grease
• Duct tape
• Super-glue (for deeper wounds, closing holes in fabric, etc.)
• Power outlet adapter (Russia and Mongolia use CEE 7/4 while China uses four different sockets)
• Electrical extension cord with multiple outlets
• Swedish firesteel
• Cigarette lighter
• Make-up remover pads (compressed cotton wool; great for starting fires)
• Various flashlights, headlamps, and key-chain lights (no power in the Mongolian desert, remember?)
• Laser pointer
• Tritium everglow key-chain marker
• Chemical hand and foot warmers

Health

• Gold/silver foil rescue blanket
• Water purifying tablets
• Medkit with painkillers, disinfectant, bandages, you name it

Photography

• DSLR with spare battery and battery grip that uses AA cells (again, no power in the Mongolian desert)
• Wide angle, prime and super-zoom lens
• Filters
• Backup point-and-shoot
• USB thumb drive
• 2 external HDDs
• SD cards
• Tripod

Minimal scuba gear

• Scuba mask
• Dive computer
• Dive compass
• Dive light

Food

• Picnic cutlery
• Plastic cup
• Folding 1.5 liter plastic bottles with sippy top
• Instant coffee
• Pulverized cocoa
• Teabags
• Muesli bars
• Hard sausages and cheeses
• Thermos
• Compact 8-spice shaker
• TupperWare box
• "Typically German food" that we will trade for local food on the train; Russians tell me that's their go-to food when in Germany and that we should bring it
  • Beer
  • Frankfurters
  • Mustard

Convenience

• Toilet paper
• Single-use washcloths
• Anti-mosquito head nets
• Silk sleeping bag liners (for train compartments and when sleeping in borrowed sleeping bags in the Gers)
• Old towel (can be thrown away if need be)
• Microfiber towel (light, packs to less than fist size)
• Sleeping mask
• Noise-cancelling earbuds
• Heavy-duty hand cleaning paste
• Washing paste for clothes
• Toiletries

Leisure

• Several card games
• Travel Trivial Pursuit
• Nintendo DS
• MP3 player
• e-book reader
• USB surround speakers
• Headphones
• Various movies and TV shows
• zsnes plus ROMs of legally-owned games
• Snuff tobacco (for socializing with Mongolian nomads)

That's it. Re-reading this list, I wonder how we managed to fit all of this into an 80-liter travel bag and a 15-liter backpack, but we did and with room to spare.