Hacker News from Y Combinator

Syndicate content
Links for the intellectually curious, ranked by readers. // via fulltextrssfeed.com
Updated: 12 weeks 6 days ago

Take me as an Intern – 19yo student seeking internship

29 April 2015 - 1:00pm
Wire Clothing

I have created a label and collection of trendy clothes for our high school.

VIDEBY

Automatic collection, next visualization and management of electric energy consumption in buildings.

Mobile app

Mobile app with substitutions, timetables, news, magazine, school e-mail...

Upload.it

App to make uploading and downloading exam results more easier.

School site

Redesign of my school’s website. Trendy, responsive and with the focus on UX.

eStavebny Dennik

Co-Founded online streamlined booking system for builders. Made whole design and user interface.

Ice Bucket Challenge

Accepted famous Ice Bucket Challenge in my own way and get a big attention.

Basketball tournament

Organized basketball tournament in my hometown.

Introducing PackageManagement in Windows 10

29 April 2015 - 1:00pm

In Windows 10 we are launching a new PackageManagement feature (formerly referred to as OneGet) that enables ITPros or DevOps to automate software discovery, installation, and inventory (SDII), locally or remotely, no matter what the installer technology is and where the software is located. 

So why are we implementing PackageManagement? In the Linux world, people are familiar with package managers such as Apt-Get, YUM, RPM, etc, for different Linux distros.  In the Windows world, however, there are quite a few installer technologies, each having their own way to install software, such as MSI, MSU, APPX, and the list goes on and on. This creates a challenge for ITPros and DevOps and a need for a tool to automate the software deployment experience.  PackageManagement is aimed at solving this problem.  Let’s first have a glance at the architecture.

 

PackageManagement is essentially a Package Management Aggregator.  It creates a unified and consistent PowerShell interface for users and provides a plug-in model at the back end that different installer technologies or package managers can plug-in as providers, using PackageManagement APIs.  Each provider further manages one or multiple package sources (repositories) where software packages are stored.

Regardless of the installation technology underneath, users can use these common cmdlets to install/uninstall packages, add/remove/query package repositories, which we call Package Sources, and query a system for the software installed.

 

In the box, we will have

  • PackageManagement Core component,

  • a PowerShell module to provide cmdlets, and

  • a key set of providers. 

That’s it, all other providers can be installed on the fly.  This allows for a small footprint while not losing agility to dynamically bootstrap package providers and install packages from those providers.

The key set of providers coming in the box are:

  • a Bootstrap provider (the provider that knows where to get more providers from)
  • an MSI provider for handling MSI files
  • an MSU provider for handling Microsoft update files
  • an Programs provider (Add/Remove programs) for providing inventory data of anything that registered itself with Add/Remove programs
  • PowerShellGet -- for accessing PowerShell modules.

 

Let’s explore what PackageManagement can offer you. A handy Get-Command is a good start.

You can see that we provide three levels of management, i.e. provider, package source, and package. The cmdlets are pretty much self-explained. We are particularly interested at the Package level operations, so let’s explore further on the SDII operations.

Discover Packages

This will look at all package sources for the provider PSModule and return all the versions matching the package name.

Install Packages

Once you find the package, you can simply specify the version without specifying a package source and PackageManagement will install that version of package from the correct package source.

Inventory

You can specify the –provider parameter at Cmdlet get-package to check what’s installed in the local machine. There is a special provider Programs included. With –IncludeWindowsInstaller option, it returns a superset of packages comparing to the Add-and-Remove Program, which only lists those ‘volunteering’ registered MSI packages.

 

Besides Win10, PackageManagement is available for down level platforms in a few ways:

  • It is included in the Windows Management Frameworks 5.0 (WMF 5.0) Preview that supports back to Windows 7 and Windows Server 2008 R2. WMF 5.0 also contains PowerShell 5.0, DSC, and other components. 

  • For users who only want PackageManagement, we will soon release a stable version of just PackageManagement and PowerShellGet provider as a MSI package, and plan to refresh it frequently.

PackageManagement is also an open source project at https://github.com/OneGet. You can check out the latest news and code from there.

The days are long but the decades are short

29 April 2015 - 1:00am

I turned 30 last week and a friend asked me if I'd figured out any life advice in the past decade worth passing on.  I'm somewhat hesitant to publish this because I think these lists usually seem hollow, but here is a cleaned up version of my answer:

1) Never put your family, friends, or significant other low on your priority list.  Prefer a handful of truly close friends to a hundred acquaintances.  Don’t lose touch with old friends.  Occasionally stay up until the sun rises talking to people.  Have parties.

2) Life is not a dress rehearsal—this is probably it.  Make it count.  Time is extremely limited and goes by fast.  Do what makes you happy and fulfilled—few people get remembered hundreds of years after they die anyway.  Don’t do stuff that doesn’t make you happy (this happens most often when other people want you to do something).  Don’t spend time trying to maintain relationships with people you don’t like, and cut negative people out of your life.  Negativity is really bad.  Don’t let yourself make excuses for not doing the things you want to do.

3) How to succeed: pick the right thing to do (this is critical and usually ignored), focus, believe in yourself (especially when others tell you it’s not going to work), develop personal connections with people that will help you, learn to identify talented people, and work hard.  It’s hard to identify what to work on because original thought is hard.

4) On work: it’s difficult to do a great job on work you don’t care about.  And it’s hard to be totally happy/fulfilled in life if you don’t like what you do for your work.  Work very hard—a surprising number of people will be offended that you choose to work hard—but not so hard that the rest of your life passes you by.  Aim to be the best in the world at whatever you do professionally.  Even if you miss, you’ll probably end up in a pretty good place.  Figure out your own productivity system—don’t waste time being unorganized, working at suboptimal times, etc.  Don’t be afraid to take some career risks, especially early on.  Most people pick their career fairly randomly—really think hard about what you like, what fields are going to be successful, and try to talk to people in those fields.

5) On money: Whether or not money can buy happiness, it can buy freedom, and that’s a big deal.  Also, lack of money is very stressful.  In almost all ways, having enough money so that you don’t stress about paying rent does more to change your wellbeing than having enough money to buy your own jet.  Making money is often more fun than spending it, though I personally have never regretted money I’ve spent on friends, new experiences, saving time, travel, and causes I believe in.

6) Talk to people more.  Read more long content and less tweets.  Watch less TV.  Spend less time on the Internet.

7) Don’t waste time.  Most people waste most of their time, especially in business.

8) Don’t let yourself get pushed around.  As Paul Graham once said to me, “People can become formidable, but it’s hard to predict who”.  (There is a big difference between confident and arrogant.  Aim for the former, obviously.)

9) Have clear goals for yourself every day, every year, and every decade. 

10) However, as valuable as planning is, if a great opportunity comes along you should take it.  Don’t be afraid to do something slightly reckless.  One of the benefits of working hard is that good opportunities will come along, but it’s still up to you to jump on them when they do.

11) Go out of your way to be around smart, interesting, ambitious people.  Work for them and hire them (in fact, one of the most satisfying parts of work is forging deep relationships with really good people).  Try to spend time with people who are either among the best in the world at what they do or extremely promising but totally unknown.  It really is true that you become an average of the people you spend the most time with.

12) Minimize your own cognitive load from distracting things that don’t really matter.  It’s hard to overstate how important this is, and how bad most people are at it.  Get rid of distractions in your life.  Develop very strong ways to avoid letting crap you don’t like doing pile up and take your mental cycles, especially in your work life.

13) Keep your personal burn rate low.  This alone will give you a lot of opportunities in life.

14) Summers are the best.

15) Don’t worry so much.  Things in life are rarely as risky as they seem.  Most people are too risk-averse, and so most advice is biased too much towards conservative paths.

16) Ask for what you want.  

17) If you think you’re going to regret not doing something, you should probably do it.  Regret is the worst, and most people regret far more things they didn’t do than things they did do.  When in doubt, kiss the boy/girl.

18) Exercise.  Eat well.  Sleep.  Get out into nature with some regularity.

19) Go out of your way to help people.  Few things in life are as satisfying.  Be nice to strangers.  Be nice even when it doesn’t matter.

20) Youth is a really great thing.  Don’t waste it.  In fact, in your 20s, I think it’s ok to take a “Give me financial discipline, but not just yet” attitude.  All the money in the world will never get back time that passed you by.

21) Tell your parents you love them more often.  Go home and visit as often as you can.

22) This too shall pass.

23) Learn voraciously. 

24) Do new things often.  This seems to be really important.  Not only does doing new things seem to slow down the perception of time, increase happiness, and keep life interesting, but it seems to prevent people from calcifying in the ways that they think.  Aim to do something big, new, and risky every year in your personal and professional life.

25) Remember how intensely you loved your boyfriend/girlfriend when you were a teenager?  Love him/her that intensely now.  Remember how excited and happy you got about stuff as a kid?  Get that excited and happy now.

26) Don’t screw people and don’t burn bridges.  Pick your battles carefully.

27) Forgive people. 

28) Don’t chase status.  Status without substance doesn’t work for long and is unfulfilling.

29) Most things are ok in moderation.  Almost nothing is ok in extreme amounts.

30) Existential angst is part of life.  It is particularly noticeable around major life events or just after major career milestones.  It seems to particularly affect smart, ambitious people.  I think one of the reasons some people work so hard is so they don’t have to spend too much time thinking about this.  Nothing is wrong with you for feeling this way; you are not alone.

31) Be grateful and keep problems in perspective.  Don’t complain too much.  Don’t hate other people’s success (but remember that some people will hate your success, and you have to learn to ignore it). 

32) Be a doer, not a talker.

33) Given enough time, it is possible to adjust to almost anything, good or bad.  Humans are remarkable at this.

34) Think for a few seconds before you act.  Think for a few minutes if you’re angry.

35) Don’t judge other people too quickly.  You never know their whole story and why they did or didn’t do something.  Be empathetic.

36) The days are long but the decades are short.

Preparing for Warfare in Cyberspace

29 April 2015 - 1:00am
Photo

The National Cybersecurity and Communications Integration Center in Arlington, Va. Credit Evan Vucci/Associated Press

The Pentagon’s new 33-page cybersecurity strategy is an important evolution in how America proposes to address a top national security threat. It is intended to warn adversaries — especially China, Russia, Iran and North Korea — that the United States is prepared to retaliate, if necessary, against cyberattacks and is developing the weapons to do so.

As The Times recently reported, Russian hackers swept up some of President Obama’s email correspondence last year. Although the breach apparently affected only the White House’s unclassified computers, it was more intrusive and worrisome than publicly acknowledged and is a chilling example of how determined adversaries can penetrate the government system.

The United States’ cybersecurity efforts have typically focused on defending computer networks against hackers, criminals and foreign governments. Playing defense is still important, and the Obama administration has started to push Silicon Valley’s software companies to join in that fight. But the focus has shifted to developing the malware and other technologies that would give the United States offensive weapons should circumstances require disrupting an adversary’s network.

The strategy document provides some overdue transparency about a military program that is expected to increase to 6,200 workers in a few years and costs billions of dollars annually. Officials apparently hope talking more openly about America’s plans will deter adversaries who view cyberattacks as a cheap way to gather intelligence from more destructive operations.

The cyberthreat is “increasing in severity and sophistication,” Defense Secretary Ashton Carter said last week. Recent attacks — Russian intrusions against the Pentagon, State Department and White House as well as North Korea’s 2014 attack on Sony Pictures — have driven home that point. One worry is that investing in offensive tools and planning could militarize cyberspace and create a new front for conflict. More than a dozen other countries are making similar investments.

The new strategy, though overly broad in some of its language, begins to lay out the conditions under which the United States would use cyberweapons. Detecting and fending off routine attacks on American assets, like theft of intellectual property, would be the responsibility of private companies, which control 90 percent of the cybernetworks. In complex cases, the Department of Homeland Security would be responsible for detecting attacks and helping the private sector defend against them.

The government would have a “limited and specific role” in defending against the most serious attacks (estimated at about 2 percent of all attacks), described as involving “loss of life, significant damage to property, serious adverse U.S. foreign policy consequences or serious economic impact on the United States.”

At first, the government would use network defenses, and law enforcement agencies like the F.B.I. would respond. Then, if ordered by the president, the military could conduct operations to counter “an imminent or ongoing attack against the U.S. homeland or U.S. interests in cyberspace.”

It is essential that the laws of armed conflict that govern conventional warfare, which call for proportional response and reducing harm to civilians, are followed in any offensive cyberoperations. With so many government agencies involved in cybersecurity — the National Security Agency, the Department of Homeland Security, the Central Intelligence Agency, the F.B.I. and the Pentagon — the potential for turf fights and duplication is high.

The new strategy is the latest evidence that President Obama, having given up on Congress, is putting together his own response to the challenge. Since this is a global issue, still needed are international understandings about what constitutes cyberaggression and how governments should respond.

Follow The New York Times Opinion section on Facebook and Twitter, and sign up for the Opinion Today newsletter.

A version of this editorial appears in print on April 28, 2015, on page A26 of the New York edition with the headline: Preparing for Warfare in Cyberspace.

Loading...

NES graphics – Part 1

29 April 2015 - 1:00am

Released in 1983, the Nintendo Entertainment System (NES) home console was a cheap, yet capable machine that went on to achieve tremendous success. Using a custom designed Picture Processing Unit (PPU) for graphics, the system could produce visuals that were quite impressive at the time, and still hold up fairly well if viewed in the proper context. Of utmost importance was memory efficiency, creating graphics using as few bytes as possible. At the same time, however, the NES provided developers with powerful, easy to use features that helped set it apart from older home consoles. Understanding how NES graphics are made creates an appreciation for the technical prowess of the system, and provides contrast against how easy modern day game makers have it with today’s machines.

The background graphics of the NES are built from four separate components, that when combined together produce the image you see on screen. Each component handles a separate aspect; color, position, raw pixel art, etc. This may seem overly complex and cumbersome, but it ends up being much more memory efficient, and also enables simple effects with very little code. If you want to understand NES graphics, knowing these four components is key.

This document assumes some familiarity with computer math, in particular the fact that 8 bits = 1 byte, 8 bits can represent 256 values, and how hexadecimal notation works. However, even those without a technical background can hopefully find it interesting.

Here is an image from the opening scene of Castlevania (1986), of the gates leading to the titular castle. This image is 256×240 pixels, and uses 10 different colors. To represent this image in memory we’d want to take advantage of this limited color palette, and save space by only storing the minimum amount of information. One naive approach could be using an indexed palette, with 4 bits for every pixel, fitting 2 pixels per byte. This requires 256*240/2 = 30720 bytes, but as you’ll soon see, the NES does much better job.

Central to the topic of NES graphics are tiles and blocks [1]. A tile is an 8×8 region, while a block is 16×16, and each aligns to a grid of the same size. Once these grids are added, you may begin to see some of the underlying structure in the graphics. Here is the castle entrance with grid at x2 zoom.


This grid uses light green for blocks and dark green for tiles. The rulers along the axis have hexadecimal values that can be added together to find position; for example the heart in the status bar is at $15+$60 = $75, which is 117 in decimal. Each screen has 16×15 blocks (240) and 32×30 tiles (960). Let’s dive into how this image is represented, starting with the raw pixel art.

CHR represents raw pixel art, without color or position, and is defined in terms of tiles. An entire memory page contains 256 tiles of CHR, and each tile has 2 bit depth. Here’s the heart:

And its CHR representation [2]:

This representation takes 2 bits per pixel, so at a size of 8×8, that means 8*8*2 = 128 bits = 16 bytes. An entire page then takes 16*256 = 4096 bytes. Here’s all the CHR used by the castlevania image.

Recall that it takes 960 tiles to fill an image, but CHR only allows for 256. This means most of the tiles are repeated, on average 3.75 times, but more often than not a tiny number are used as the majority (such as a blank background, solid colors, or regular patterns). The castlevania image uses a lot of blank tiles, as well as solid blues. To see how tiles are assigned, we use nametables.

A nametable assigns a CHR tile to each position of the screen, of which there are 960. Each position uses a single byte, so the entire nametable takes up 960 bytes. The order of assignment is each row from left to right, top to bottom, and matches the calculated position found by adding the values from the rulers. So the upper-left-most position is $0, to the right of that is $1, and below it is $20.

The values for the nametable depend upon the order in which the CHR is filled. Here’s one possibility [3]:


In this instance, the heart (at position $75) has a value of $13.

Next, in order to add color, we need to select a palette.

The NES has a system palette of 64 colors [4], and from that you choose the palettes that are used for rendering. Each palette is 3 unique colors, plus the shared background color. An image has a maximum of 4 palettes, which takes up 16 bytes. Here is the palette for the Castlevania image:

Palettes cannot be used with complete abandon. Rather, only a single one may be used per block. This is what typically gives a very “blocky” appearance to NES games, the need to separate each 16×16 region by color palette. Skillfully made graphics, such as this Castlevania intro, avoid this by blending shared colors at block edges, removing the appearance of the grid.

Choosing which palette is used for each block is done using attributes, the final component.

Atributes are 2 bits for each block, and specify which of the 4 palettes to use. Here’s a picture showing which blocks uses which palette via its attributes: [5]


As you may notice, the palettes are isolated into sections, but this fact is cleverly hidden by sharing colors between different areas. The reds in the middle part of the gate blend into the surrounding walls, and the black background blurs the line between the castle and the gate.

At only 2 bits per block, or 4 blocks per byte, the attributes for an image use 240/4=60 bytes, though due to how they’re encoded they waste 4 bytes, using a total of 64. This means the total image, including the CHR, nametable, palette, and attributes, require 4096+960+16+64 = 5136 bytes, far better than the 30720 discussed above.

Creating these four components for NES graphics is more complicated than typical bitmap APIs, but tools can help. Original NES developers probably had some sort of toolchains, but whatever they were, they have been lost to history. Nowadays, developers will typically create their own programs for converting graphics to what the NES needs.

The images in this post were all created using makechr, a rewrite of the tool used to make Star Versus. It is a command-line tool designed for automated builds, and focuses on speed, good error messages, portability, and clarity. It also creates interesting visualizations such as those shown here.

Most of my knowledge of how to program the NES, especially how to create graphics, was acquired by following these guides:

[1] Terminology – Some documents refer to blocks as “meta-tiles”, which personally I find less useful.

[2] CHR encoding – The 2 bits per pixel are not stored adjacently. Rather, the full image is stored with just the low bits, then stored again with just the high bits.

So the heart would be stored like this:

Each row is one byte. So 01100110 is $66, 01111111 is $7f. In total, the bytes for the heart are:
$66 $7f $ff $ff $ff $7e $3c $18 $66 $5f $bf $bf $ff $7e $3c $18

[3] Nametable – This is not how the actual in-game graphics use the nametable. Typically, the alphabet will appear adjacently in memory, as is the case for how Castlevania really does it.

[4] System palette – The NES does not use an RGB palette, and the actual colors it renders may vary from tv to tv. Emulators tend to use completely different RGB palettes. The colors in this document match the hard-coded palette of makechr.

[5] Attribute encoding – Attributes are stored in a strange order. Instead of going left to right, up to down, a 2×2 section of blocks will be encoded in a single byte, in a Z shaped ordering. This is the reason why there are 4 wasted bytes; the bottom row takes a full 8 bytes.

For example, the block at $308 is stored with $30a, $348, and $34a. Their palette values are 1, 2, 3, and 3, and are stored in low position to high position, or 11 :: 11 :: 10 :: 01 = 11111001. Therefore, the byte value for these attributes is $f9.

. Bookmark the

.

Vault – A tool for managing secrets

29 April 2015 - 1:00am

Today we announce Vault — a tool for securely managing secrets and encrypting data in-transit. From storing credentials and API keys to encrypting passwords for user signups, Vault is meant to be a solution for all secret management needs.

A modern system requires access to a multitude of secrets: credentials for databases, API keys for external services, credentials for service-oriented architecture communication, etc. Understanding who is accessing what secrets is already very difficult and often platform-specific. Adding on key rolling, secure storage, and detailed audit logs is almost impossible without a custom solution. Vault solves all of these problems.

Vault is already being deployed in very large infrastructures. We are excited for the future of Vault, and what we have for you today is just the beginning of what we believe is an incredible tool.

Read on to learn more.

Vault is one giant leap forward for practical security in a cloud environment.

Rob Witoff, Director at Coinbase Features

Vault is the most feature-rich initial release of any of our open source projects. Vault has basic features you'd expect from a secret manager, but also has some novel features that we believe will modernize the space and extend the boundary for operational excellence.

We'll go into detail about some of the major features later in this post, but first we'll enumerate all the major features of Vault:

  • Secure secret storage: Arbitrary key/value secrets can be stored in Vault. These secrets are encrypted prior to being written to persistent storage, so gaining access to the raw storage isn't enough to access your secrets. Vault can write to disk, Consul, and more.

  • Dynamic secrets: Vault can generate secrets on-demand for some systems, such as AWS or SQL databases. For example, when an application needs to access an S3 bucket, it asks Vault for credentials, and Vault will generate an AWS keypair with valid permissions on demand. After creating these dynamic secrets, Vault will also automatically revoke them after the lease is up.

  • Leasing and renewal: All secrets in Vault have a lease associated with it. At the end of the lease, Vault will automatically revoke that secret. Clients are able to renew leases via built-in APIs.

  • Revocation: Vault has built-in support for secret revocation. Vault can revoke not only single secrets, but also a tree of secrets. For example, Vault can revoke all secrets read by a specific user or all secrets of a specific type. Revocation assists in key rolling as well as locking down systems in the case of an intrusion. This also allows for organizations to plan and train for various "break glass" procedures.

  • Data encryption: Vault can encrypt and decrypt data without storing it. This allows security teams to define encryption parameters and developers to store encrypted data in a location such as a SQL database without having to design their own encryption methods.

  • Auditing: All access to Vault can be sent to multiple audit backends. This includes any request to Vault: successes, failures, configuration, data access, etc. Audit logs can be sent to syslog, files, and more. Multiple audit backends can be enabled to have redundant copies of audit logs.

  • Access control policies: ACLs can be created to restrict or grant fine-grained access to any feature of Vault. This is a critical feature for a secret management system.

  • Multiple authentication methods: Vault includes multiple methods for authentication (each enabled individually) so you can choose what works best with your organization. For 0.1, Vault supports tokens, username/password, GitHub, certificates, and more. In the future, many more will be added.

Secrets

The goal of Vault is to manage secrets. At the most fundamental level, this includes reading/writing arbitrary secrets to Vault securely. Vault makes this very easy:

$ vault write secret/foo value=bar Success! Data written to: secret/foo $ vault read secret/foo Key Value lease_id secret/foo/9c5f3cf1-1239-0160-4311-d6544fd1018c lease_duration 2592000 value bar $ vault delete secret/foo Success! Deleted 'secret/foo'

Note: This and all other features of Vault are also possible through the complete HTTP API as well.

When you read a secret, Vault returns the data you wrote along with leasing information. Leasing is a core, critical part of Vault. Every secret in Vault must have a lease. The lease tells a consumer of a secret that the secret is guaranteed to remain valid for that lease period, but past the lease period, there is no guarantee the secret will still function. This forces clients to renew the lease periodically, where Vault can record this in the audit log and can use this opportunity to potentially deny lease renewal as well.

When writing secrets manually, revocation of secrets past the leasing period is also manual. However, Vault also supports dynamic secrets that have automatic revocation and are covered next.

Dynamic Secrets

In the modern world of API-driven everything, many systems also support programmatic creation of access credentials. Vault takes advantage of this support through a feature called dynamic secrets: secrets that are generated on-demand, and also support automatic revocation.

For Vault 0.1, Vault supports dynamically generating AWS, SQL, and Consul credentials.

The power of this feature is immense: credentials to access these systems no longer ever need to be written to disk. They can be accessed from Vault, stored in-memory, and automatically revoked when they're no longer used. If a specific application instance is compromised, that single key can be revoked, rather than some more global set of credentials.

The most revolutionary place we're seeing this feature used already is for SQL credentials. With dynamic SQL credentials, every application that needs database access is generated a new SQL user. For systems such as PostgreSQL, Vault even sets the VALID UNTIL field so PostgreSQL itself will revoke the user automatically.

Here is what reading a dynamic secret looks like:

$ vault read postgresql/creds/production Key Value lease_id postgresql/creds/production/8ade2cde-5081-e3b7-af1a-3b9fb070df66 lease_duration 3600 password 56b43bc3-b285-4803-abdf-662d6a105bd0 username vault-root-1430141210-1847

It looks just like reading a normal secret! The difference is that the returned username and password didn't exist prior to reading it, and in 3600 seconds (the lease duration shown), Vault will automatically delete that SQL user unless the lease is renewed.

Remember, all of this can be done from the API as well, and in the case of an application it probably would use the API so that the secret never has to be written to disk or copied anywhere else.

Security

You can see from above that reading and writing secrets from Vault is easy and even enjoyable. But more important than this usability is ensuring that these secrets are secure. We took security very seriously and use industry best practices to secure Vault.

The data stored with Vault is encrypted using 256-bit AES in GCM mode with a randomly generated nonce. This encryption happens in-memory prior to ever being sent to the backend storage driver. This way the storage never sees the unencrypted value.

The key used to encrypt the data is also encrypted using 256-bit AES in GCM mode. This is known as the master key. The encrypted encryption key is stored in the backend storage. The master key is then split using Shamir's Secret Sharing. Shamir's Secret Sharing ensures that no single person (including Vault) has the ability to decrypt the data. To decrypt the data, a threshold number of keys (by default three, but configurable) are required to unseal the Vault. These three keys are expected to be with three different individuals.

With the Vault unsealed, all API calls are done with HTTP over TLS. While it is possible to disable TLS, it requires explicitly opting into it both on the server as well as all clients.

All API calls to Vault require an identity obtained through authentication. This identity is mapped to various metadata. The identity and metadata are logged with every audit log entry. For example, if you use GitHub for authentication, the GitHub username and organization of the user is in the audit logs. If you use certificate authentication, the fingerprint of the client certificate is logged.

Within Vault, data is split into multiple backends. For example, when you write data to secret/foo, it is communicating with a different secret backend than when you read a PostgreSQL credential from postgresql/creds. Each backend is given a restricted view to the backend data. The backend at secret/foo can never access the data at postgresql/creds, for example. This isn't just an ACL; the backends themselves simply do not have a way to address data from other backends. This ensures that even within Vault there is protection against malicious activity.

In addition to all of the above, Vault was in closed beta for over 6 weeks with over 50 individuals and corporations. We reached out specifically to security teams at companies as well as individuals with an interest/background in security to help review Vault prior to release. We've gotten basic approval from multiple companies and are confident that Vault has a strong foundation as we move forward.

This is just a brief overview of the security of Vault. For a full explanation, see the pages on the Vault security model and Vault architecture.

HashiCorp Built

At HashiCorp, we build solutions to DevOps problems that are technically sound and are a joy to use. We don't take shortcuts with the technologies we choose, and just as importantly we don't take shortcuts in the experience of using and operating our tools. As a result, HashiCorp-made tools are stable, scalable, and easy to use and operate.

Vault is the sixth such tool we've built. We've also built Vagrant, Packer, Serf, Consul, and Terraform. Vault works great with these other tools, but doesn't require any of them. We have plans to integrate Vault more closely into some of our other tools as well, such as automatically retrieving AWS credentials for Packer via Vault.

We're proud of Vault and are excited to see folks learn more about it and even begin to use it. As a disclaimer, Vault is a very important piece of your infrastructure, and security is paramount. For 0.1, we can't recommend production usage, but many companies are already deploying Vault into production and we're working hard to ensure we can stand by that right away.

Operationally, Vault promises to significantly simplify and enhance the security against internal threats and other service lifecycle management challenges. Based on our diligence and initial testing, HashiCorp has released another solid product that the industry can benefit from.

Sean Chittenden, Operations Architect at Groupon Learn More

To learn more about Vault, please visit the Vault website. From the home page, you can click "Launch Interactive Tutorial" and use all of Vault directly from your browser!

The following pages in particular are good next steps:

  • Intro - The intro section explains in more detail what Vault is, how it works, what use cases it has, and includes a brief getting started guide so you can start experimenting with Vault and learn about all of its features.

  • Internals - The internals section is an advanced topic but covers details about the internals of Vault. It isn't required to start using Vault, but it is recommended reading if you want to deploy Vault.

  • Comparison to other software - If you'd like to know how Vault is different from other options out there, take a look at this page and we go into detail on the differences.

  • GitHub - The source code for Vault is hosted on GitHub if you want to dive right in. We recommend reading the documentation first, since an understanding of how Vault works will help greatly in understanding the implementation.

A Rust Contributor Tries Their Hand at Go

29 April 2015 - 1:00am

For the past year or so I've been playing with the Rust programming language. I've come to love the language and spend quite a bit of my free time contributing to the compiler and the Servo browser engine.

Recently, for a course, we were asked to use Go for the assignments and project. Whilst a tad disappointed that I couldn't use Rust for it, I saw this as a great opportunity. Rust and Go have been compared a lot as the "hot new languages", and finally I'd get to see the other side of the argument.

By the end of the course, aside from some simpler assignments, I'd written a basic implementation of the Raft consensus algorithm and a toy application using it, both in Go.

Before I get into the experience, let me preface this by mentioning that Rust and Go don't exactly target the same audiences. Go is garbage collected and is okay with losing out on some performance for ergonomics; whereas Rust tries to keep everything as a compile time check as much as possible. This can make Rust better for lower level applications.

In my specific situation, however, I was playing around with distributed systems via threads (or goroutines), so this fit perfectly into the area of applicability of both languages.

This article isn't exactly intended to be a comparison between the two. I understand that as a newbie at Go, I'll be trying to do things the wrong way and make bad conclusions off of this. My way of coding may not be the "Go way" (I'm mostly carrying over my Rust style to my Go code since I don't know better); so everything may seem like a hack to me. Please keep this in mind whilst reading the post, and feel free to let me know the "Go way" of doing the things I was stumbling with.

This is more of a sketch of my experiences with the language, specifically from the point of view of someone coming from Rust; used to the Rusty way of doing things. It might be useful as an advisory to Rustaceans thinking about trying the language out, and what to expect.

Despite the performance costs, having a GC at your disposal after using Rust for very long is quite liberating. For a while my internalized borrow checker would throw red flags on me tossing around data indiscriminately, but I learned to ignore it as far as Go code goes. I was able to quickly share state via pointers without worrying about safety, which was quite useful.

Having channels as part of the language itself was also quite ergonomic. In Go, channels are used with the <- and -> operators:

ch := make(chan bool, 5)

 

ch <- true

response := <-ch

fmt.Println("Got: ", response)

In Rust, the corresponding is:

let (tx, rx) = channel();

 

tx.send(true);

 

let response = rx.recv().unwrap();

 

println!("Received {}", response);

It's not so different from what Go does, however having language-level operators for something is always nice. Initially I got confused often by which side the channel was, but after a while I got used to it. It also has an in built select block for selecting over channels (Rust has a macro for the same purpose, but no language support).

gofmt. The Go style of coding is different from the Rust one (tabs vs spaces, how declarations look), but I continued to use the Rust style because of the muscle memory (also too lazy to change the settings in my editor). gofmt made life easy since I could just run it in a directory and it would fix everything. Eventually I was able to learn the proper style by watching my code get corrected. I'd love to see a rustfmt, however!

Go is great for debugging programs with multiple threads, too. It can detect deadlocks and post traces for the threads (with metadata including what code the thread was spawned from, as well as its current state). It also posts such traces when the program crashes. These are totally awesome and saved me tons of time whilst debugging my code (which at times had all sorts of cross interactions between more than ten goroutines in the tests) Without a green threading framework, I'm not sure how easy it will be to integrate this into Rust (for debug builds, obviously), but I'd certainly like it to be there some day.

Go has really great green threads goroutines. They're rather efficient (I can spawn a thousand and it schedules them nicely), and easy to use.

Go has really good in built support and tooling for tests (Rust does too). I enjoyed writing tests in Go quite a bit due to this.

Unlike Rust, Go is really easy to pick up. It's possible to jump directly into it, and you can be writing useful programs after a single afternoon of messing around or reading. On the other hand, while basic Rust is easy to pick up, it takes a while to get used to the borrow checker (and in general understand ownership/borrowing). Additionally, most libraries make full use of advanced features (like associated types) and one needs to learn these too to be able to use the libraries.

There are quite a few things here, but bear in mind I'm new to Go, and am still learning the Go way of doing things. I would love to hear feedback about how I can overcome some of the problems I ran into.

No enums

Rust has enums, which are basically tagged unions. Different variants can contain different types of data, so we can have, for example:

enum Shape {

    Rectangle(Point, Point),

    Circle(Point, u8),

    Triangle(Point, Point, Point)

}

and when matching/destructuring, you get type-safe access to the contents of the variant.

This is extremely useful for sending typed messages across channels. For example, in Servo we use such an enum for sending details about the progress of a fetch to the corresponding XHR object. Another such enum is used for communication between the constellation and the compositor/script.

This gives us a great degree of type safety; I can send messages with different data within them, however I can only send messages that the other end will know how to handle since they must all be of the type of the message enum.

In Go there's no obvious way to get this. The closest thing is the type called interface {} which is similar to Box<Any> in Rust or Object in Java. This is a pointer to any type, with the ability to match on its type. As a Rustacean I felt incredibly dirty using this, since I expected that there would be an additional vtable overhead — in Rust Box<Any> or Box<Trait> are generally avoided in favor of generics (for compile time matching) or enums (for runtime matching). Besides, interface{} can be fed any type, so I can always accidentally send a message of the wrong type through a channel and it'll end up crashing the other end at runtime since it hit a default: case or something.

So, for example, in Rust I design a messaging system for drawing to a window like so:

enum MyMessage {

    Quit,

    DrawLine(Color, Point, Point),

    DrawTriangle(Color, Color, Point, Point, Point),

    SetBackground(Color)

    

    

    

    

}

 

fn painting_loop(rx: Receiver<MyMessage>) {

    loop {

        match rx.recv().unwrap() {

            Quit => {

                

            },

            DrawLine(color, a, b) => {

                

                

            },

            DrawTriangle(color, fill, a, b, c) => {

                

                

            },

            SetBackground(color) => {

                

            }

            

            

            

            

        }

    }

}

 

fn draw_thingy(tx: Sender<MyMessage) {

    tx.send(DrawLine(Red, Point{x:0, y:0}, Point{x: 1, y: 1}));

    tx.send(SetBackground(Blue))

    

}

 

fn main() {

    

    let (tx, rx) = channel();

 

    

    thread::spawn(move || {

        

        

        painting_loop(rx)

    })

 

    

    

    draw_thingy(tx)

}

whereas in Go, I would do something like this:

type Quit struct{}

type DrawLine struct {

    color Color

    a Point

    b Point

}

type DrawTriangle struct {

    color Color

    fill Color

    a Point

    b Point

    c Point

}

type SetBackground struct {

    color Color

}

 

func paintingLoop(ch chan interface{}) {

    

    

    for msg := range ch {

        switch msg.(type) {

            case Quit:

                

            case DrawLine:

                

                line := msg.(DrawLine)

                

            case DrawTriangle:

                tri := msg.(DrawTriangle)

                

            case SetBackground:

                bg := msg.(SetBackground)

                

            default:

                

                

        }

    }

}

 

func drawThingy(ch chan interface{}) {

    ch <- DrawLine {color: Red, a: Point{x:0, y: 0]}, b: Point{x: 1, y: 1}}

    ch <- SetBackground{color: Blue}

    

    

    ch <- true

    ch <- "foobar"

}

 

func main() {

    

    ch := make(chan interface{}, 100)

 

    

    

    go func() {

        

        paintingLoop(ch)

    }

 

    

    

    drawThingy(ch)

}

 

Of course, I could implement a custom interface MyMessage on the various types, but this will behave exactly like interface{} (implemented on all types) unless I add a dummy method to it, which seems hackish. This brings me to my next point:

Smart interfaces

This is something many would consider a feature in Go, however, coming from Rust, smart interfaces felt almost too magical, and sometimes tripped me up during refactors.

In Go, interfaces get implemented automatically if a type has methods of a matching signature. So an interface with no methods is equivalent to interface{}; and will be implemented on all types automatically. This means that we can't define "marker traits" like in Rust that add a simple layer of type safety over methods. It also means that interfaces can only be used to talk of code level behavior, not higher level abstractions. For example, in Rust we have the Eq trait, which uses the same method as PartialEq for equality (eq(&self, &other)), and the behavior of that method is exactly the same, however the two traits mean fundamentally different things: A type implementing PartialEq has a normal equivalence relation, whilst one that also implements Eq has a full equivalence relation. From the point of view of the code, there's no difference between their behavior. But as a programmer, I can now write code that only accepts types with a full equivalence relation, and exploit that guarantee to optimize my code.

Having interfaces be autoimplemented on the basis of the method signature is a rather ergonomic feature in my opinion and it reduces boilerplate. However, it's just not what I'm used to and it restricts me from writing certain types of code without using dummy methods like so to get static type safety.

Packages and imports

Go puts severe restrictions on where I can put my files. All files in a folder are namespaced into the same package (if you define multiple packages in one folder it errors out). There's no way to specify portable relative paths for importing packages either. To use a package defined in an adjacent folder, I had to do this, whereas in Rust (well, Cargo), it is easy to specify relative paths to packages (crates) like so. The import also only worked if I was developing from within my $GOPATH, so my code now resides within $GOPATH/src/github.com/Manishearth/cs733/; and I can't easily work on it elsewhere without pushing and running go get everytime.

Rust's module system does take hints from the file structure, and it can get confusing; however the behavior can be nearly arbitrarily overridden if necessary (you can even do scary things like this).

Documentation

Full disclosure, Rust's libraries aren't yet well documented. This relates largely to the fact that many of the libraries are still in flux ("unstable"). There are ongoing initiatives by developers like the awesome Steve Klabnik to improve the documentation.

Having said this, I also found that Go's documentation was skimpy in places, even for stable libraries.

For example, for the methods which read till a delimiter in bufio, it was rather confusing if they only return what has been buffered till the call, or block until the delimiter is found. Similarly, when it comes to I/O, the blocking/non-blocking behavior really should be explicit; similar to what Rust's Sender and Receiver do in their documentation.

Generics

This is a rather common gripe -- Go doesn't have any generics aside from its builtins (chans, arrays, slices, and maps can be strongly typed). Like my other points about enums and interfaces, we lose out on the ability for advanced type safety here.

Overall it seems like Go doesn't really aim for type safe abstractions, preferring runtime matching of types. That's a valid choice to make, though from a Rust background I'm not so fond of it.

Visibility

Visibility (public/private) is done via the capitalization of the field, method, or type name. This sort of restriction doesn't hinder usability, but it's quite annoying. The other day I had to make a bunch of fields public to satisfy Go's encoding package, and code needed to be updated everywhere with a manual find/replace (the same string was used in other contexts too so it couldn't be done automatically)

type Thingy struct {

    tweedledee bool 

    Tweedledum bool 

}

 

type thingy struct{

    

}

func foo(){}

func Bar(){}

On the other hand, Rust has a keyword for exporting things, and whilst it has style recommendations for the capitalization of variable names (for good reason -- you don't want to accidentally replace an enum variant with a wildcard-esque binding in a match, for example), it doesn't error on them or change the semantics in any way, just emits a warning. On the other hand, in Go the item suddenly becomes private.

pub struct Thingy {

    tweedledee: bool 

    pub tweedledum: bool 

}

 

struct OtherThingy {

    

}

func foo(){}

pub func bar(){}

 

Warnings

Go throws hard errors on finding unused imports or unused variables. This rules out some workflows where I partially finish the code and check if it compiles. Quite often whilst debugging I have to add and remove code which uses packages like fmt or log, and I have to scroll up and edit the imports block every time. In Rust, while you can make these hard errors, by default they are just warnings.

This isn't really an issue with the language, just a minor annoyance in the implementation.

Conclusion

A major recurring point is that Go seems to advocate runtime over compile time checking (despite being a compiled language), something which is totally opposite to what Rust does. This is not just visible in language features (like the GC), but also in the tools that are provided — as mentioned above, Go does not give good tools for creating type safe abstractions, and the programmer must add dynamic matching over types to overcome this. This is similar (though not the same) as what languages like Python and Javascript advocate, however these are generally interpreted, not compiled (and come with the benefits of being interpreted), so there's a good tradeoff.

I wasn't an immediate convert to Go, having said this I really enjoyed learning, and playing with the language. I'm coming from a different paradigm and it would take me time to adjust. Having said this I highly recommend trying out the language.

— Manish.

Lenin's Body Improves with Age

29 April 2015 - 1:00am

YES! Send me a free issue of Scientific American with no obligation to continue the subscription. If I like it, I will be billed for the one-year subscription.

Scientific American is a trademark of Scientific American, Inc., used with permission

© 2015 Scientific American, a Division of Nature America, Inc.

View Mobile Site All Rights Reserved.

Release proposal: v2.0.0 (io.js)

28 April 2015 - 7:00am

A failure I haven't seen before, on one of the Windows slaves:

not ok 637 - test-timers-first-fire.js # #assert.js:88 # throw new assert.AssertionError({ # ^ #AssertionError: Timer fired early # at null._onTimeout (c:\workspace\iojs+any-pr+multi\nodes\win2008r2\test\parallel\test-timers-first-fire.js:11:10) # at Timer.listOnTimeout (timers.js:89:15) #timer fired in -0.6199840000000023

@piscisaureus, @trevnorris, @bnoordhuis or other, do you have any idea if this is relevant? setTimeout() set for 50, fires 0.6 ms early but the assertion is looking for it to be 0.6 ms early or smaller, possibly positive; i.e. delta > 0.5. To be honest I don't really understand the point of this test even with the comments in the original commit, 93b0624.

Is Science Dangerous? (2002) [pdf]

28 April 2015 - 7:00am

%PDF-1.3 %âãÏÓ 29 0 obj << /Linearized 1 /O 31 /H [ 720 263 ] /L 23754 /E 5454 /N 8 /T 23056 >> endobj xref 29 14 0000000016 00000 n 0000000627 00000 n 0000000983 00000 n 0000001137 00000 n 0000001265 00000 n 0000001482 00000 n 0000001979 00000 n 0000002194 00000 n 0000002604 00000 n 0000003157 00000 n 0000003369 00000 n 0000005225 00000 n 0000000720 00000 n 0000000962 00000 n trailer << /Size 43 /Info 26 0 R /Root 30 0 R /Prev 23046 /ID[<413c722706ca61d32406d3e06fa3e0dc><55b74cd88232b41678ce7be73ad0c172>] >> startxref 0 %%EOF 30 0 obj << /Type /Catalog /Pages 28 0 R /Metadata 27 0 R /PageLabels 25 0 R >> endobj 41 0 obj << /S 122 /L 165 /Filter /FlateDecode /Length 42 0 R >> stream H‰b```f``ºÀÀÂÀÀrž‡x€b ÈQäùiwd·gÈnŸ†òòð©@!öì%–¥j«§eíLß5»lQd²ûjÕiÕ+ÿÏÿÿÿÿ‡ÿ HlÞ²ÙaXlþdS€@Œ!PHsm?nΆ®³…‚ùn´Ýs`°ioKH00ÍÒL@ì `ûb9» endstream endobj 42 0 obj 150 endobj 31 0 obj << /Type /Page /Parent 28 0 R /Resources 32 0 R /Contents 39 0 R /MediaBox [ 0 0 595 842 ] /CropBox [ 0 0 595 842 ] /Rotate 0 >> endobj 32 0 obj << /ProcSet [ /PDF /Text ] /Font << /TT2 34 0 R /TT4 36 0 R /TT6 37 0 R >> /ExtGState << /GS1 40 0 R >> >> endobj 33 0 obj << /Type /FontDescriptor /Ascent 750 /CapHeight 676 /Descent -250 /Flags 262178 /FontBBox [ -168 -218 1000 935 ] /FontName /Times-Bold /ItalicAngle 0 /StemV 133 /XHeight 461 /StemH 139 >> endobj 34 0 obj << /Type /Font /Subtype /TrueType /FirstChar 32 /LastChar 148 /Widths [ 250 0 0 0 0 0 0 0 333 333 0 0 250 333 0 0 500 500 500 0 0 0 500 0 0 500 0 0 0 0 0 0 0 0 0 667 0 0 0 0 0 0 0 0 0 833 667 0 611 0 0 500 0 722 611 0 0 0 0 0 0 0 0 0 0 500 500 444 500 444 278 500 500 278 0 444 278 722 500 500 500 0 389 389 278 500 444 667 0 444 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 556 556 ] /Encoding /WinAnsiEncoding /BaseFont /Times-Italic /FontDescriptor 35 0 R >> endobj 35 0 obj << /Type /FontDescriptor /Ascent 750 /CapHeight 653 /Descent -250 /Flags 98 /FontBBox [ -169 -217 1010 883 ] /FontName /Times-Italic /ItalicAngle -15 /StemV 76 /XHeight 441 /StemH 76 >> endobj 36 0 obj << /Type /Font /Subtype /TrueType /FirstChar 32 /LastChar 121 /Widths [ 250 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 500 0 0 0 0 722 0 0 778 0 389 0 0 0 0 0 0 611 0 0 556 667 0 0 0 0 0 0 0 0 0 0 0 0 500 556 444 556 444 333 500 556 278 0 0 278 0 556 500 556 0 444 389 333 556 0 0 0 500 ] /Encoding /WinAnsiEncoding /BaseFont /Times-Bold /FontDescriptor 33 0 R >> endobj 37 0 obj << /Type /Font /Subtype /TrueType /FirstChar 32 /LastChar 150 /Widths [ 250 0 408 0 0 0 0 180 0 0 0 0 250 333 250 0 500 500 0 0 0 500 500 0 0 500 278 278 0 0 0 444 0 722 667 667 722 611 556 722 722 333 389 722 611 889 722 722 556 722 667 556 611 722 722 944 0 722 0 0 0 0 0 0 0 444 500 444 500 444 333 500 500 278 278 500 278 778 500 500 500 500 333 389 278 500 500 722 500 500 444 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 444 444 0 500 ] /Encoding /WinAnsiEncoding /BaseFont /Times-Roman /FontDescriptor 38 0 R >> endobj 38 0 obj << /Type /FontDescriptor /Ascent 750 /CapHeight 662 /Descent -250 /Flags 34 /FontBBox [ -168 -218 1000 898 ] /FontName /Times-Roman /ItalicAngle 0 /StemV 84 /XHeight 450 /StemH 84 >> endobj 39 0 obj << /Length 1762 /Filter [ /ASCII85Decode /FlateDecode ] >> stream 8;WR3gMYb*&H.4Y_n@R@HIkMc+3[g#VLI^_:QcA=%D)Bf6jL3Nq^'e;f%HK26,sn/1n# D.koC(s_t7`*Rl'$T>UMCft3!E6^og,3r*qFaBIY[)UR2%efq\S"[j)*.O)faNX35-:YUU6#h$hSp4M[e&]B9rpQi'r(i@`pX@ +PTYS=j+(3d(A7Z8;+=97Km"5,%ik4^nk=hfaK\rsOQ^>P+/"/p )gZ)=P#k=!XN@U/dp(S2"0ISDmQX;rgDH^!$LM*png]&^j6M!Gl8"cEBo/T:1KTbs )5_bPe$sj50^5)BKgGt66?gdL=QA8jVW8_95XO>T++GuJb7/I!i&p1m[+RP%lKYYQ ^9A.7$tZQ1&pftH.WY4YJI)Wg_p91?ZWeY/;L.]_HhR#PO*WQ$4[L/J<7.'po\HW[@WCpuG!-^=8[3+_O2 +>FlWaiG;=^JP9`ErW<7"s2i?q:;.Lh$k1dI0SqMVa6'Xhb0a ?@fA(s&?hgJ@>qJGPZh&SY=cFpGITXQQW+R`7T&K)(;NOK18o*h$T3pcF+)R3r(R\ dFrAo`C8DsUH@OgX?qW*Hi`kb+15a6[RQPDjtq(;4g^De,1!uF.ttX!j/.d#QcWo% S3H41F3Y++S!PBDL>@GDDSJuHqCf`+N_?JiU?*%oj[#.h?S#]d!GPaV@*4$olOGN' p8X/:\1ZI*%08eB6@so.g4C%9@=s6q,'(S`9h>E$IT?0V%/=)/@9HsH/NI8sXCLe( XN_?od6`Cd)78B9c=3sn\s*COT),#2=):^SR52#;&ig5D>9fAp*;$7Zi8V'H([=:r P\^lFfGdSZ+1mT86#0Lrg)iFj3nXY<>-CTTRORUa:$tV=o,itN9.*f[l_g0 Ji$_Zg:#a*U6Ze1C)A:aWAs_9nPQc=(65IWnPI>#`'l-B>/Bq'F3'Fo6k^$`A2<^C>Np 6lldN_O=J3(pCUYU4[,/Da4l0NNtJMaQ4fO:=WZaFuB$+UD"@)20sJZ<6;-Ij!$b>J<\l\ELGWe:gDZKaSZPN~> endstream endobj 40 0 obj << /Type /ExtGState /SA false /SM 0.02 /TR2 /Default >> endobj 1 0 obj << /Type /Page /Parent 28 0 R /Resources 2 0 R /Contents 3 0 R /MediaBox [ 0 0 595 842 ] /CropBox [ 0 0 595 842 ] /Rotate 0 >> endobj 2 0 obj << /ProcSet [ /PDF /Text ] /Font << /TT2 34 0 R /TT6 37 0 R /TT8 22 0 R >> /ExtGState << /GS1 40 0 R >> >> endobj 3 0 obj << /Length 2133 /Filter [ /ASCII85Decode /FlateDecode ] >> stream 8;V^q?#LZ@&Gu_2%u\*=/Y%a[cfh?Ag*1N5'LAHO%n.QghWg+UO$&Ld/'>'a/9tmM Q=9u9"GsVCSXl2)Hb2Cc]j/:F3A&i1o5gAZ+9&lWgf-5aF1PLZR_k?m8P?PZfCSe2g%hCLS%FQJ/$2/tS1_G>,"C7LqBd!M%EZ87=G'D!Oq5)kd .Tt%5W?oe!R;=DMe^_V4luE,$@$M!PLTYPg+g*P[3?XM`#*'^"]tb9pX)<;Wb+qi" P_i7/"^9mL3[bq]_gl/Q(n52K;X9+F=.4/6\RYI,af4NNV3>F&$Odd+iXlpIF:+A5 AC(HiXDGV26gu7k0l\:re>dTrLK5Q8N]@7uM)_n4,8(V1(l_`)hbiR#%lbF1indlI ]Rbgq`=>Idf)a+%"&r#A+$$`;eU*YAgo+&/#LBH/o:,&nn1CYA^a#259E^.%53-?V hclm%*KGIpr'IlQ'EsddQ?;6?UWpo/q:E`CA-dnW%V;44F=.=S@H-I :[GKW$BZ**oTrpiV2q_)hiGU$BQ1.PkLb;;sPV;Ae)n qlOs+Rc8^Xcn!JnWXebo3[Vh&Tq.$e9r_m[K%`3%"Gh54\Qm;qiSiX6h#JMV9JQUJ VUbB[l6@d*J:AOWOM7Q8_%/]#bRO=d!V#aEKHS(l`N@qINJ8_XO`OOD4XCSn"N:sW T@$+`IXi^(YS3$^0F5>$1O<;D7.u^HUeq\MOqXnt8!Da2=$`U#Wj=,\/K*,0lJ?#=N];m0 HRq$BbS[KT2fC,oZ#O('r1u9:O*9otAu&^&oGOC%B`M,^!=[Ga8U-J*<-@0Q(0Pik/25g"3%+#h!@,pi&5gtruG7eFaPkXh<4qr.#] <`*A"5oUYU@`Ys4G']Au2A\MQN#5U*]Jf(u*iEK)TOqT4`\D^C7O@qe+Yjp5\O$#% ;(`6iL@RX?6.1I+2N6jspHWC+lg@U6=)GjMJG(*Z.$FMU)0'NPgM:MLMng ac(kCJ5t9fSO'RZ9gL%p9b(5B)8I#h)X9go*2BRZ7Y_?C(cuX9+FV.N>K3Ip%EPW0 3)B8*dHBYMlWMGuD@b9`j%'M]M(6JSC,a)e.VudHl^k6IF*".r-&FM#94AiP9as2. qBPE1W%;(tS[0Eed4?%lBZgMS>O(]SQWQ#O>79MlW3R[/jXA2G bDjudh-gb_G"_ghfLB\\n0Nu2Kc]"=K[s)C*):(pV\K57@!T%h].$b&[pqkt^iQXM X/)uTeV+,[05O/5-]DAaQu]U9

Tiny robots climb walls carrying more than 100 times their weight

28 April 2015 - 7:00am

Video: Super-strong robot pulls heavy loads

Mighty things come in small packages. The little robots in this video can haul things that weigh over 100 times more than themselves.

The super-strong bots – built by mechanical engineers at Stanford University in California – will be presented next month at the International Conference on Robotics and Automation in Seattle, Washington.

The secret is in the adhesives on the robots' feet. Their design is inspired by geckos, which have climbing skills that are legendary in the animal kingdom. The adhesives are covered in minute rubber spikes that grip firmly onto the wall as the robot climbs. When pressure is applied, the spikes bend, increasing their surface area and thus their stickiness. When the robot picks its foot back up, the spikes straighten out again and detach easily.

The bots also move in a style that is borrowed from biology. Like an inchworm, one pad scooches the robot forward while the other stays in place to support the heavy load. This helps the robot avoid falls from missing its step and park without using up precious power.

Heavy lifting

All this adds up to robots with serious power. For example, one 9-gram bot can hoist more than a kilogram as it climbs. In this video it's carrying StickyBot, the Stanford lab's first ever robot gecko, built in 2006.

Another tiny climbing bot weighs just 20 milligrams but can carry 500 milligrams, a load about the size of a small paper clip. Engineer Elliot Hawkes built the bot under a microscope, using tweezers to put the parts together.

The most impressive feat of strength comes from a ground bot nicknamed μTug. Although it weighs just 12 grams, it can drag a weight that's 2000 times heavier – "the same as you pulling around a blue whale", explains David Christensen – who is in the same lab.

In future, the team thinks that machines like these could be useful for hauling heavy things in factories or on construction sites. They could also be useful in emergencies: for example, one might carry a rope ladder up to a person trapped on a high floor in a burning building.

But for tasks like these, the engineers may have to start attaching their adhesives to robots that are even larger – and thus more powerful. "If you leave yourself a little more room, you can do some pretty amazing things," says Christensen.

If you would like to reuse any content from New Scientist, either in print or online, please contact the syndication department first for permission. New Scientist does not own rights to photos, but there are a variety of licensing options available for use of articles and graphics we own the copyright to.

Console.mihai();

28 April 2015 - 7:00am

HTTP/1.1 200 OK Server: GitHub.com Date: Mon, 27 Apr 2015 20:16:15 GMT Content-Type: text/html; charset=utf-8 Content-Length: 13307 Last-Modified: Wed, 25 Feb 2015 10:00:35 GMT Access-Control-Allow-Origin: * Expires: Mon, 27 Apr 2015 20:26:15 GMT Cache-Control: max-age=600 Accept-Ranges: bytes

A few days ago Mihai Șucan went home to Romania. We're not expecting him to fix any more bugs in Firefox, but I'd like to raise a glass of Țuică, to the 1919 bugs that he has been involved in fixing in Firefox.

Devtools at Mozilla has only been a serious thing for a bit under 5 years. Firebug is much older, but wasn't really a Mozilla project. We started for real in the middle on 2010, and Mihai was one of the first people to start helping.

The console code was initially a complete mess. Code that everyone touched and no-one loved, born before there was momentum, when landing code was a dark art.

I remember more than once looking at console code thinking - 'I can do the right fix in a few weeks or the wrong fix in a few hours', and like many before me, leaving the root problem for someone else to fix.

That someone was Mihai.

Most of the Devtools team at Mozilla is remote, so all I knew of Mihai to start with, was his strange voice. I'm no expert on Romanian accents, but this was different. His voice was compressed and clearly a struggle. He coughed regularly. So we listened more carefully when he spoke and thought nothing of it.

And Mihai continued to fix the console. Kevin Dangoor, who ran Devtools at the time said to me once - "You know the problem with Mihai is simply feeding him enough bugs - that's nearly a full time job!"

When video chat became a thing, I think we all noticed Mihai's hands, and wondered how he typed, but were probably too embarrassed to ask what was up.

I'm not sure who asked first, but around the time we first all got together in London I asked if he could travel easily, and found out the detail.

Mihai has Epidermolysis Bullosa (sometimes known as E.B.) specifically - Recessive Dystrophic Epidermolysis Bullosa.

E.B. is a brutal skin condition which causes chronic blistering, and makes everyday objects dangerous. Those with it are sometimes called butterfly children because of their brittle skin. In Mihai's case it has left him in a wheelchair, and having to very gently punch the keyboard to get anything done.

E.B. makes you very vulnerable to skin cancer from the continued scarring from the blisters. So everyday objects that wouldn't pose a risk to those with normal skin become sharp and dangerous to people with E.B. Needless to say - anyone with E.B. has a huge mountain to climb every single day.

When presented with the mountain that just existing presents to EB sufferers, I think many people would be happy to just exist. But that's not Mihai, who has made developer tools for the web a personal mission. There aren't many things you can do when the outside is so dangerous, but Mihai found something he could do and did it with a passion.

Mihai's illness has meant he hasn't been able to work on the console recently, and we've probably not adjusted properly, but that's temporary.

Mihai's legacy is that there are hundreds of millions of people using a product, Firefox, that Mihai contributed to, hundreds of thousands of them of them spend a significant proportion of their time in the console that was his responsibility. And there are billions of people using websites created by people directly helped by Mihai's work.

In all but his darkest moments, Mihai copes without complaining. The annoying molehills that we complain about are largely irrelevant sideshows to Mihai, and working with him has been an honour.

If you've used Firefox Devtools, or if you've used any website where the author might have used Devtools, or if you're impressed by what Mihai has overcome, there's EB Research which investigates the root causes and solutions to the problem of EB.

Mihai always wants to do more, but he needs your help with this bit: EB Research.

(The video in this post is from a series created for DEBRA international by Lowe GGK. The full set of images and videos is well worth a look)

Posted by Joe Walker 16 Feb 2015 Comments

Please enable JavaScript to view the comments powered by Disqus.

Incompleteness

The blog is about general web development. (Atom feed)

MozBlog contains Mozilla stuff - i.e stuff for planet (Atom feed).

See also the Archives

If it's a choice between
incomplete or wrong,
side with Gödel.

About

I'm Joe Walker. I work for Mozilla making developer tools better i.e. creating tomorrow's Firebug.

See also joewalker on Github and @joewalker on Twitter, and 103130341946168853745 on Google+.

Projects
  • GCLI is a web developers command-line that's being used in Firefox Developer Tools, and alongside Ace
  • DOM Template is an experimental DOM template engine with some nice features like asynchronous layout
  • CSS Doctor is an experiment into how we can improve the CSS telemetry in a browser
  • DWR is a Java library that enables Java on the server and JavaScript in a browser to interact and call each other as simply as possible
Recent Posts Latest Tweets

Inside Popcorn Time, the Piracy Party Hollywood Can't Stop

27 April 2015 - 7:00pm
Popcorn Time

Popcorn Time was an instant hit when it launched just over a year ago: The video streaming service made BitTorrent piracy as easy as Netflix, but with far more content and none of those pesky monthly payments. Hollywood quickly intervened, pressuring Popcorn Time’s Argentinian developers to walk away from their creation. But anonymous coders soon relaunched the copyright-flouting software. Today, Popcorn Time is growing at a rate that has likely surpassed the original, and the people behind it say they’re working on changes designed to make the service virtually impervious to law enforcement.

As Popcorn Time celebrated the first anniversary of its rebirth, WIRED chatted via email and instant message with a software developer from Popcorn-Time.se, one of the most popular of several reincarnations of Popcorn Time. (The anonymous developer asked us to use Popcorn Time’s smiling popcorn-box mascot “Pochoclin” as his or her pseudonym.) Popcorn Time’s masked spokesperson says the streaming movie and TV app is flourishing—in defiance of many of the world’s most powerful copyright holders and EURid, the domain registrar that seized the original site’s web domain last year.

After everything we went through, this will be our sweetest revenge. Anonymous Popcorn Time spokesperson


Popcorn-Time.se, Pochoclin says, has millions of users and is growing at the mind-bending rate of 100,000 downloads per day. He or she also hinted that a forthcoming switch to a peer-to-peer architecture will make the service far harder for copyright cops to attack. “We’re at the threshold of one of the most exciting times since we started this project,” Pochoclin writes. “Making all our data available via p2p will mean that Popcorn Time will no longer rely on domains and centralized servers but only on its user base.”

“After everything we went through,” Pochoclin said, “this will be our sweetest revenge and our biggest victory.”

When Popcorn-Time.se started responding to WIRED’s questions in November, Pochoclin said the reborn project already had 4 million users. But it had taken a serious hit a few months earlier, when Brussels-based domain registrar EURid revoked its website domain, Time4Popcorn.eu. At its new Swedish domain, it’s only recently returned to that earlier adoption rate. (Pochoclin wouldn’t reveal the size of its current user base for fear of drawing more attention from law enforcement or copyright holders.) “[EURid’s domain seizure] was just a small setback … a small but painful kick to the balls,” the spokesperson says. “We’ve grown this project tremendously since we picked it up … The numbers just keep rising.”

A chart of Google searches for Popcorn Time over the last year, showing its quick growth since the shutdown of the original site in March of last year. (Source: Google Trends, which shows only relative search trends rather than absolute numbers of searches.)

For any other year-old startup, those numbers would seem ludicrous. But Popcorn Time is giving away Hollywood’s most valuable content for free, and making that piracy easier than ever. Download Popcorn Time’s app and in seconds you’re offered a slick menu of streaming TV shows and movies at least as easy to navigate as Netflix or Hulu—but with higher-quality video and hundreds of recent movies and TV shows paid services don’t offer.

Popcorn Time's BitTorrent-for-dummies approach has become the virtually undisputed future of video piracy.


Popcorn Time isn’t a new kind of piracy so much as an inviting new front-end interface for the BitTorrent underground. The software collects and organizes popular files from existing BitTorrent sources like the Pirate Bay, Kickass Torrents, Isohunt, and YTS. “We’re like Google,” Pochoclin says, “scraping for new content all over the internet.” By integrating its own video player and prioritizing its downloads from the first chunk of the video file to the last, it makes those sites’ files immediately streamable. With Popcorn Time, the complexity of BitTorrent search engines, trackers, clients, seeds, decompression, playback, and storage is reduced to a single click. That’s made this BitTorrent-for-dummies the virtually undisputed future of video piracy.

Pochoclin says Popcorn-Time.se offers this streaming service pro bono. It doesn’t charge for downloads, and neither its app nor its website display ads. “We just did it for the love of this project,” Pochoclin writes. “It was something we believed in. And once it started taking off … as it did from the start, all the love that we were getting from Popcorn Time users made us just keep on going without really stopping to think where this road is taking us.”

That road, it seems, points toward a collision course with the Hollywood’s copyright lawyers. Documents revealed in last year’s Sony hack revealed that the Motion Picture Association of America boasted of a “major victory” in pressuring Popcorn Time’s original developers to scupper the service. The MPAA declined to comment on any measures it’s taking against the new Popcorn Time. In a January 20 letter to shareholders, Netflix CEO Reed Hastings wrote that “piracy continues to be one of our biggest competitors,” and referred to Popcorn Time by name, calling a graph showing its rising Google searches “sobering.” Neither Netflix nor Hulu responded to WIRED’s requests for comment.

Pochoclin says the service doesn’t do anything illegal: It merely organizes preexisting BitTorrent files hosted on other sites. “It’s all automated and all working on existing open source technologies and existing websites online. Therefore, it’s legal. Or better … not illegal,” Pochoclin says. “We all live in a free society, where what is not forbidden is allowed.”

That’s not a defense that’s likely to succeed in an American court. An MPAA spokesperson pointed out in an email to WIRED that previous software like Napster, Grokster, isoHunt, and Limewire didn’t directly host content either, but courts ruled that all of them were infringing on copyrights. Even though it merely helps users stream video files made available elsewhere, Popcorn Time could be accused of “contributory liability,” says University of Richmond intellectual property law professor Jim Gibson. A service whose primary, intended function is aiding copyright infringement doesn’t need to host any files to be illegal. “If they know that they’re actually facilitating the downloading or streaming of copyrighted movies and they continue to do it, they’re in trouble,” Gibson says.

With legal threats looming, Popcorn-Time.se is working on new defenses. In about a month, the group says it plans to launch a version of the app that will update its TV and movie content with the same peer-to-peer BitTorrent protocol that it uses to stream movies, pulling data from other users rather than a central server. That means that even if its domain or other central infrastructure is taken down, Popcorn Time would still function. In a second upcoming phase, Popcorn-Time.se says it will have the ability to update the app itself via peer-to-peer downloads, using cryptographic signatures to ensure no malicious code propagates through its network. When those updates are in place, Pochoclin says, “only our users will decide whether we live or die … This way, Popcorn Time will be unstoppable.”

But even if the service itself does develop an invincible peer-to-peer architecture, Popcorn Time’s developers may be personally vulnerable to a lawsuit or even criminal charges. The Swedish founders of the Pirate Bay, for instance, were successfully prosecuted for running the massively popular BitTorrent website, and the United States is seeking the extradition of Megaupload founder Kim Dotcom from New Zealand to face criminal copyright infringement charges.

For now, Popcorn Time’s developers depend on their unnamed web hosting company to ensure their anonymity, which is hardly a bulletproof strategy. “We’re anonymous but not in hiding,” Pochoclin says. “We guess our hosting company does know who we are. But they’re not supposed to give our information out to anyone. And it’s good enough for us.”

With Popcorn Time’s popularity skyrocketing, it may soon find out whether those defenses are good enough to hold off a horde of MPAA lawyers, too. Pochoclin may be cute. But he’s made some powerful enemies.

Disque – a distributed message broker

27 April 2015 - 7:00pm
README.md

Disque is ongoing experiment to build a distributed, in memory, message broker. Its goal is to capture the essence of the "Redis as a jobs queue" use case, which is usually implemented using blocking list operations, and move it into an ad-hoc, self-contained, scalable, and fault tolerant design, with simple to understand properties and guarantees, but still resembling Redis in terms of simplicity, performances, and implementation as a C non-blocking networked server.

Currently (27 April 2015) the project is just an alpha quality preview, that was developed in roughly 120 hours, 244 different commits performed in 72 different days, often at night and during weekends. In short: don't expect much or rock solid production systems here.

WARNING: This is alpha code NOT suitable for production. The implementation and API will likely change in significant ways during the next months. The code and algorithms are not tested enough. A lot more work is needed.

Jq – A Command-line JSON processor

27 April 2015 - 7:00pm
jq jq

This website is made with Bonsai and Twitter Bootstrap, themed with Bootswatch.

jq is licensed under the MIT license (code) and the CC-BY-3.0 license (docs).

Take Nothing, Leave Nothing: On being banned from the world’s most remote island

27 April 2015 - 7:00pm

Seventeen hundred miles from what is customarily called civilization—in this case, the western shore of the Republic of South Africa—lies a tiny British-run volcanic island populated by fewer than three hundred people who lay claim to living in the most isolated permanent habitation in the world. 

I am presently sitting five cables off this island, Tristan da Cunha, wallowing on the swells on a small boat that is hove-to just off the mole at the entrance to the harbor of Edinburgh of the Seven Seas, the island’s capital and only settlement. But while my fellow passengers will soon be landing—once the easterly gale blows itself out and the seas die down to an acceptable level—and so are excitedly preparing themselves to enjoy the fascinations that Edinburgh has in store (a visit to the fields where the islanders grow potatoes being the main advertised attraction), I will not be joining them.

For I have been sternly and staunchly forbidden to land. The Island Council of this half-forgotten outpost of the remaining British Empire has for the last quarter century declared me a Banned Person. I am welcome on Tristan neither today nor, indeed, as was succinctly put to me in a diplomatic telegram last year, “ever.”

It would be idle to suggest that I have been terribly incommoded. Though some may suspect sour grapes, I have to confess that there is little of great charm to Tristan. Such as it possesses derives almost entirely from its status: there is a very large hand-painted sign in the Edinburgh square saying, welcome to the remotest island, and once our visitors have had themselves photographed beside it, have exchanged pleasantries with various islanders over warm English beer at the rather underdecorated Albatross Pub, have studied the piles of canned pork sausages and sugar-rich candies on sale in the cinder-block shop, and have made the obligatory two-mile pilgrimage (on the island’s only road) to the fields where the potatoes grow, most will be eager to return to their waiting cruise ship, to wonder as the island fades away astern, why on earth anyone would wish to live there.

The latest census says that 275 people do. They belong to just seven eternally intermarrying families. Two of the families are the descendants of the civilian support staff of a military garrison that Britain established on the island in 1815 to help ward off any French loyalists who might try to rescue Napoleon from St. Helena, 1,500 miles to the north. An Italian ship was later wrecked on the island, bringing with it two further surnames. Two more family names came down from passing American whalers and one from a similarly wandering Dutchman, expanding a gene pool which remains to this day severely limited—and is said to be responsible for the curious similarity of the islanders’ appearances, and the numerous cases of asthma, retinitis pigmentosa, and other genetically influenced ailments that afflict the population.

IMAGE:

Farewells before the return to Mecca, from a manuscript of al-Hariri’s Maqamat, Baghdad, c. 1240. National Library of France, Department of Manuscripts, Ms. 3929 f. 122.

Utter isolation—just a scattering of supply ships and randomly appearing cruise liners happen by each year; there is no airfield—instills a healthy self-reliance into what is in any case a very singular culture. The men fish for lobster (a pair of which appear on the islands’ coat of arms), tinker with their boat engines, tend the herd of cattle and flock of sheep, dig the vegetable patches; the women knit (large woolen sweaters called “ganzeys,” socks to be put inside sea boots called “ammunitions”), perform most of the island paperwork, organize regular morale-lifting celebrations. 

The older islanders incorporate nineteenth-century “thees” and “thous” into their speech—on hearing such chatter it seems perfectly reasonable that only sixty years ago all trade was performed by barter: to send a letter to England cost five potatoes. And though satellites have had their recent effect, it seems understandable, too, that until thirty years ago all contact with the outside world was by Morse code—fitful, unreliable, and subject to the vagaries of the ionosphere.

But London keeps its eye on this far corner of the Empire. Two British diplomats preside—colonial figures hardly cut from the same cloth as the old viceroys of India or governors of Nigeria or Hong Kong. The senior man is usually on the verge of retirement, having enjoyed rather too little distinction in his career, or else sporting a stated fascination with birdwatching, since there is a local and much celebrated albatross. His assistant is invariably an eager youngster—on this occasion an ambitious young woman who was leaving after six months for a long-sought and career-boosting posting outside Kandahar. There is usually rather little for the pair to do: the only signed order currently posted on the island’s official notice board refers to a power cut due for two hours the following Tuesday.

Once in a long while, though, there is a crisis. The event for which Tristan is perhaps best remembered was the eruption of its volcano in 1961, and the evacuation of the entire population. The 264 islanders—the population size has remained very stable for the last half century—were brought to England and put up in a disused army barracks in Hampshire. But the supposed delights of Western civilization—cars, elevators, cinemas, none of which the islanders had ever seen before—did not seduce them into staying: two years later all but fourteen went home. They rebuilt their ruined town and settled back to their uncomplicated routines of fishing for lobsters and knitting ganzeys. The Daily Mirror of the time said, admiringly, that by doing so the islanders had delivered to all smug Britons a much deserved and contemptuous slap.

I first went to the island in 1983, then again a little later. I was welcomed, though warily: the self-reliance of the islanders is matched by a fierce devotion to self-protection and privacy. They knew I was a writer: they warned me that anything I might publish would be read and analyzed for years to come. And though nothing untoward occurred while I was visiting (my time ashore I spent fully impressed with the idea of leaving only footprints and taking only snapshots) it was shortly after that second trip that I quite inadvertently committed the indiscretion which resulted in my lifetime prohibition. 

At first blush it all sounds to have been innocent indeed. It stems from a somewhat bizarre British government decision, taken during World War II, to reclassify some of its more remote island possessions as ships. Tristan was transmuted into HMS Atlantic Isle, and its role was to patrol (from its rock-hewn state of immobility) for any German U-boats that might be lurking in the southern Atlantic. To compound the fantasy a small party of sailors was posted there to man the ship—one of them a young and apparently romantically minded lieutenant and littérateur manqué named Derrick Booy. 

In the grand tradition that has long intertwined nice girls and sailors, Lieutenant Booy fell for one of the island’s prettiest, a slip of a lass then named Emily Hagan. He stayed only eight­een months on the island, and once the war was over he wrote a memoir, published in 1957. In it he made many tender mentions of Miss Hagan, and though his writings leave little doubt as to his own feelings, they are somewhat ambiguous as to the degree that his ardor was reciprocated. 

Two paragraphs stood out as most pertinent. One recorded the pair’s first meeting:

The night air was an enveloping golden presence as we stood at the break in the wall. I was conscious of bare, rounded arms and the fragrance of thickly clustered hair. The lingering day was full of noises. As the sky darkened to a deep, umbrageous blue, speckled with starlight, and the village was swallowed by darkness at the foot of the mountain, from somewhere in that blackness came the throaty plaint of an old sheep, like a voice from the mountain. From that other obscurity, silver-gleaming below the cliffs, came the muttered irony of the surf. The girl waited only a few minutes before her full lips breathed “Goodnight,” and she slipped toward the house. “Shall I come to see you again?” I called softly. She may or may not have answered “Yes.” If she did, it was probably from politeness.

And the other notes the mechanics of their eventual parting, recorded after Lieutenant Booy had boarded the whaler that would take him out to his waiting navy ship, and away.

The watchers on the beach were all very still, the women sitting again in their gaily dressed rows, as if waiting primly to be photographed. None of them waved or cheered. They just sat watching. All looked very much alike, young and old. But there was one at the end of a row, in a white dress with a red kerchief, bright-red over smooth, dark hair. She sat perfectly still, staring back until she became a white blur. Then her head went down, and the woman behind her—a large one in widow’s black—put a hand on her shoulder.

Whatever her feelings for the jolly Jack tar, ten years later Emily Hagan was married to Kenneth Rogers, an islander who had been employed as a mess boy by the visiting naval party, and who after the war worked both as the island’s baker and a butcher. By the time I got to Tristan he was in his sixties, working as a part-time assistant barman at the Albatross. But the very moment I fetched up outside his tiny thatched cottage, notebook in hand, he knew exactly what I wanted. “To see our H’em’ly, I suppose,” he said, glumly. He knew just why. He didn’t want to let me see her. He placed himself four-square behind his garden gate, keeping it firmly latched. 

IMAGE:

Odysseus and his companions passing the Isle of the Sirens, Roman mosaic, third century. Bardo Museum, Tunis, Tunisia. 

He gave me a stern lecture, all the more touching by being couched in his elegant and ancient English. He said he wished I would purge from my mind all that I had read in the “navy man’s” book. The revelations, he said, had “hurt us all. It was all a long, long time ago, and we’d just as soon forget it.” He was courteous, kindly, firm. And two days later, just before I left the island for good, he came down the harbor to see me off. “Remember,” he said, “whatever you write will last for years; we back on the island will pore over it and analyze it a thousand times. Be careful what you write—for our own sakes.”

But I have to confess that, when it came to writing, I ignored him. I began work on a book about all of the remaining outposts of the British Empire—for my visit to Tristan was but part of two long years of wanderings that took me from Pitcairn to Diego Garcia, from Bermuda to the Falkland Islands, from Hong Kong to Gibraltar, and to all those other weather-beaten relics of Imperial Britannia. When I came to the Tristan chapter, I decided that I would in fact tell the story of Emily Hagan and Derrick Booy, in full.

It would be a very small part of a story about a very small island in an overlooked corner of the world. But as a story it was a good one—especially if I quoted from his book Derrick Booy’s two rather overwrought paragraphs. My rationale for doing so was simple: everything had already been made public; everything was in the prints; and in any case the story, told in an exquisitely gentle fashion, was just a near-beer account of a wartime love affair which, by all accounts, had been tender, unconsummated, and quite possibly entirely imagined. I thought that back on a Tristan which now seemed a very, very long way away, old Kenneth Rogers was being just too, too sensitive: the story was the thing, that was all there was to it. So I wrote the book; it was duly published. The reviews were kindly, the sales modest—and I thought little more of it.

Except that twelve years passed, and then out of the blue in 1998 I was invited onto a cruise ship on passage through the Southern Ocean. I had been asked to go along to talk to the passengers about various places I had visited: the Antarctic, South Georgia, Gough Island, Inaccessible, Nightingale—and Tristan. I did as I was bidden, without incident for the first two weeks of the voyage. Then on a Friday morning, during a half gale just north of the Antarctic convergence, I gave my talk about the history of Tristan. We arrived the following evening, and when we were comfortably at anchor off the Edinburgh mole, we were boarded, somewhat surprisingly, by a very large imperial policeman. He had a brief announcement to make: everyone would be permitted onto the island the following morning, but regrettably not—the ship’s passenger manifest had been radioed ahead—Mr. Winchester.

I had, he explained sternly, betrayed an island secret. I had been warned; I had actually been implored. But I had gone ahead, and now the islanders were every bit as hurt and upset as Kenneth Rogers had forewarned. The constable was implacable, immovable. And so the passengers, most of them greatly amused, filed past me down to the gangway, boarded their Zodiacs, and were swept off behind the riprap into Calshot Harbor—named for the village in Hampshire to where the islanders had been evacuated in 1961—and off to see the sights of Edinburgh. When they returned an hour or so later they shook their heads as one: why would anyone want to live there? And then they puzzled over my exclusion: it’s not as though you had killed someone.

Another invitation, from a second cruise line, dropped through the mailbox in the spring of 2008: it was for a voyage due to begin in the austral autumn of 2009, in March. This time, anticipating problems, I wired ahead. I asked the British chief resident envoy to Tristan, David Morley (whose career path had previously included postings to such out-of-the-way legations as Kaduna, Mbabane, and Port Stanley) if I were still banned. Surely not, I said I supposed. Twenty-four years had passed. Emily and Kenneth Rogers were now both dead. Surely by now I had purged my contempt?

Weeks passed until his telegram of reply. Sadly no, he finally reported. The Island Council had met, had formally considered the request, and had voted that, “You will not be able to land on this occasion or, indeed, ever.”

I think that to get under the surface and really appreciate the beauty of any country, one has to go there poor.

- Grace Moore, 1944

And so with that knowledge I boarded the MY Corinthian II (in Ushuaia, in southern Patagonia, a town where I had once spent three months in prison on spying charges during the Falklands War, but which by contrast still welcomes me warmly each time I happen by), and off we sailed, along the familiar sub-Antarctic milk run. I delivered without incident my lectures about the Falklands, on South Georgia, on the history of the Atlantic—and eventually, about Tristan da Cunha. And it was then that I told the passengers that I would not be going with them, and explained why.

By now I had built up something of a rapport with the passengers, and a gasp went up. Most seemed quite incredulous. Nearly all were American. Many happened to be lawyers. These last were especially exasperated on my behalf. Over dinner later they insisted that I sue. Freedom of speech, they chorused. Moreover—Tristan is British, and you are British: it isn’t even an immigration question. It is a simple assault on free speech. A village in Yorkshire, said one attorney who had spent time there, would not legally be able to ban someone from visiting because he had written that the village was ugly, or the inhabitants were unpleasant, or that the publican was having an affair with the vicar’s wife. So sue! Go to the Tristan High Court! The St. Helena High Court! The House of Lords! You’ll be bound to win. No problem!

I let the passengers press past me once again on their way down onto the gangway, and I watched with some melancholy as they filed into the Zodiacs. I stood on the bridge with the lugubrious German captain and borrowed his binoculars to watch the tourists make their way to the Albatross, to the slopes of the volcano, to the church, to the potato fields. And then I went back to my cabin, and for the next few irritating hours pondered my fate and thought about travel in general, and about such weighty matters as the sayings of Blaise Pascal, who once infamously wrote that all of mankind’s ills stemmed from his inability to remain peacefully at home in his living room. Then as dusk was falling, I emerged back onto the deck to greet the returning scrum. 

And I found that I had in those few hours become both contrite, and a convert. Pascal, I concluded, had a point. I was now in fact quite certain that, whatever high principle might be involved, the islanders of Tristan were in fact quite right and I, as a clumsily meandering and utterly thoughtless outsider, was very, very wrong indeed.

For though I sedulously followed the rule of taking nothing and leaving nothing, it suddenly seemed to me that my very being on the island, and my later decision to record my impressions of that visit and the impressions of earlier visitors, had resulted in a series of entirely unintended and unanticipated consequences—consequences that were as inimical to the islanders’ contentment as if I had plundered or polluted there. 

I had no understanding whatsoever that by repeating that naval officer’s memoir, I could hurt the feelings of anyone. To my clumsy, unthinking, touristic mind, the notion seemed quite absurd. To be sure, old Kenneth Rogers had explained it to me kindly—but I had chosen to ignore his warning, to dismiss his assertion of feeling. I had failed, even for one second, to consider what he and his fellow islanders might think—because I held to an unspoken assumption that as a visitor from the sophisticated outside, I knew better, and that I had something of a prescriptive right to do with him and his like, more or less as I pleased. (Repeating it here, a second time, as a didactic exercise, seems unlikely to compound the felony: even as he told of the renewed ban, the island constable who boarded our vessel assured me that few of the younger islanders now minded, and only a very small number even remembered. “And if it were up to me, I’d let you back.”)

Then came a cascade of similar memories, from earlier journeys. The woman from San Diego whom I met in a truly remote Amazon village, buying up everything she could see—a volcano-sized pile of old chairs and tables and statuettes assembled on raffia mats in the village square, the villagers looking on in eager anticipation of their good fortune from the sale of their castoffs—but who promptly walked out on the deal when told that the village had no facility for taking her Visa card. The Microsoft billionaire who arrived on Namibia’s Skeleton Coast with five helicopters full of bodyguards, and demanded that all available local lions be collected in one oasis so that he could see and picture them. The Texan who insisted on being pictured beside his golf club’s pennant on every Arctic and Antarctic stop he made, then teeing off and driving one ball—such a little ball, he would sweetly insist—into the sea.

IMAGE:

Eight Bells, by Winslow Homer, 1886. Addison Gallery of American Art, Andover, Massachusetts.

We have an unceasing capacity to make ourselves nuisances, basically. Students of tourism science can and do construct elaborate theories from physics, of course, invoking such wizards as Heisenberg and the Hawthorne effect and the status of Schrödinger’s cat to explain the complex interactions between our status as tourist-observers and the changes we prompt in the peoples and places we go off to observe. But at its base is the simple fact that in so many instances, we simply behave abroad in manners we would never permit at home: we impose, we interfere, we condescend, we breach codes, we reveal secrets. And by doing so we leave behind much more than footfalls. We leave bruised feelings, bad taste, hurt, long memories.

Attractive-sounding mantras about footprints and photographs won’t fully resolve the problem. The only real solution, however impractical and improbable, is to hearken to Pascal’s much scorned adage, to resolve to resist the blandishments of the brochure, and stay away. Certainly the people of Tristan da Cunha would have been happier had I stayed back—and who would deny the rights of the people of Tristan, just as ourselves, to be left happy, and at peace?

Except that in the specific case of Tristan da Cunha, it is probably too late. The island has recently appointed a government tourist officer, and the community’s leadership has recently come formally to accept—rather later than most other places—that catering to the visiting curious is quite a reliable way of making what, back in the barter days of sixty years ago, most Tristanians knew little about—money. Tourism for the islanders, it was argued in Council, has the advantage of being less hazardous a road to riches than rowing out to catch lobsters, and a good deal more profitable than spending the long evenings knitting sweaters.

It has taken them some time, but now the most remote island in the world seems to have come fully round to opening its arms to the world’s immense traveling community, just as the people of Paris and Bangkok and Lima and London have done before them. That community is still swelling exponentially, and alarmingly: the 45 million Chinese who toured the world last year, for example, are expected by Beijing to reach 100 million by 2020. 

The 275 islanders far off in the South Atlantic may share the hope that among those thousands who eventually throng to have their picture taken beside the famous Edinburgh signboard, there will be few tourists as thoughtless as I. But they shouldn’t count on it. 

SpaceX Stats

27 April 2015 - 7:00pm
Previous
Missions
Upcoming
Missions
News
Summaries
FAQ Launch
Notifications
SpaceX Stats

"At the beginning of starting SpaceX, I thought that the most likely outcome was failure."

Here at SpaceX Stats, you can track SpaceX’s progress, countdown to upcoming launches in real time, get notifications of manifest changes (either via email or RSS), learn more about SpaceX, watch and read about past launches, and browse monthly news summaries about the company.

SpaceX designs, manufactures, and launches the most advanced rockets and spacecraft, and is the world’s fastest growing commercial launch supplier. The now 4000-strong company was founded in June 2002, by serial entrepreneur Elon Musk with the initial goal of recapturing the public’s imagination with spaceflight, reducing the cost of access to orbit by developing reusable rockets, and making life multi-planetary by expanding humanity’s presence to Mars.

Scroll down for statistics, use the white arrows on the left and right of your screen to navigate chronologically, and click the colored buttons in the top left corner to jump between pages!

Website developed by Lukas (lukas.io). This website is not in any way associated with SpaceX. Front page image Ⓒ 2014 Reddit user /u/ELON_Fanatic, all other images Ⓒ 2014 Space Exploration Technologies Inc.

Link to
launch
Next Launch - TurkmenÄlem 52E
  • UTC
  • Pacific
  • Eastern
  • Local
Counting down to 27 Apr 2015 22:14:00 UTC.

A Falcon 9 will launch Turkmenistan's first communications satellite into GTO orbit in April 2015.

Total
  • Total
  • Falcon 9
  • Falcon Heavy
  • Falcon 1
Launch Count

As of August 2014, SpaceX has launched 17 rockets (all from its sole rocket family, Falcon) to a variety of destinations, from LEO to the ISS to GEO; carrying scientific and commercial payloads along with Dragon under its commercial resupply contract with NASA.

Falcon 9 Launch Count

Falcon 9 is SpaceX's workhorse of the Falcon fleet, able to carry 13,150kg to LEO & 4,850kg to GTO. To date, it has launched on 11 occasions, predominantly lifting communications satellites and Dragon to the ISS. Designed to be thin enough to be carried on a flatbed truck; the pencil thin Falcon 9 at 3.7m wide is taller than the entire Space Shuttle stack, yet thinner than a Shuttle solid rocket booster.

Falcon Heavy Launch Count

Falcon Heavy is the world's most powerful rocket, pushing 4 million pounds of thrust (17.6MN) at liftoff, and is able to haul 53 metric tons to LEO - the equivalent of a fully loaded Boeing 737. Only the Saturn V has delivered more payload to orbit, yet it is a third of the cost of a Delta IV Heavy and has twice the performance. SpaceX is gearing up for the first flight of Falcon Heavy in 2015.

Falcon 1 Launch Count

Falcon 1, now retired, was SpaceX's original two stage rocket equipped with a single Merlin 1C engine - able to lift 670kg to LEO. Launched exclusively from Kwajalein, it was used for 5 flights, of which the first 3 failed. At the time of the first successful flight of Falcon 1 (flight 4), SpaceX was on the verge of bankruptcy.

Missions
  • Missions
  • ISS Resupplies
  • Flight Time
  • Cargo
Dragon Missions

Dragon - SpaceX's orbital spacecraft - has flown into space 5 times atop of a Falcon 9 rocket. On completion of its first mission in December 2010, Dragon became the first privately developed spacecraft to be successfully recovered from orbit. If required, Dragon can also be placed on top of Falcon Heavy. Future variants of Dragon are designed to carry crew and return propulsively to the launch site.

Resupplies

Under NASA's Commercial Resupply Services program, Dragon regularly lifts cargo to and returns cargo from the ISS as part of a 12-mission contract. SpaceX's valued contract contains both more missions at a cheaper price than a similar contract awarded to Orbital Sciences. As of June 2014, 3 of these missions have been completed.

Dragon Flight Time 119 8 44 43 Days Hours Minutes Seconds

Dragon's missions have become progressively longer during each flight. The first test flight of Dragon lasted just over 3 hours, while the most recent flight, CRS-3, ended up with a mission elapsed time nearing 30 days. Dragon's total on-orbit endurance however is up to 2 years. The next Dragon flight (CRS-4) is scheduled for August 2014.

Cargo

NASA's $1.6 billion CRS contract with SpaceX calls for 12 flights delivering a minimum of 20,000kg of cargo up to the station. Dragon remains the only spacecraft in service capable of returning large quantities of cargo from the Station to Earth.

SLC-40, Florida
  • SLC-40, Florida
  • SLC-4E, California
  • LC-39A, Florida
  • Boca Chica, Texas
  • Kwajalein
Launches from SLC-40, Florida

Florida, specifically, Cape Canaveral Air Force Station Space Launch Complex 40 (SLC-40), is the launch site of Falcon 9 carrying Dragon towards the International Space Station, and the starting point for satellites heading into Geostationary Earth Orbit.

Launches from SLC-4E, California

Vandenberg AFB Space Launch Complex 4E (SLC-4E) in California is SpaceX's departure point for satellites (mostly scientific and Earth observation) seeking a polar orbit around the Earth. SLC-4E was last used in 2005 for the final flight of the Titan IV rocket.

Launches from LC-39A, Florida

In April 2014, SpaceX signed an agreement with NASA for a 20 year lease on the historic Pad 39A at Kennedy Space Center. SpaceX will pay to build horizontal integration facilities, and hopes to launch the first Falcon Heavy from here in early 2015.

Launches from Boca Chica, Texas

Boca Chica Beach, Texas is the likely location of SpaceX's new commerical-only private launch site designed to handle LEO & GEO launches on a tight schedule, freeing up other launch sites for other uses. It is expected to become operational in 2016.

Launches from Omelek Island, Kwajalein

Omelek Island within the Kwajalein Atoll was SpaceX's first launch site and used exclusively to launch the Falcon 1. Far from other land, Kwajalein is surrounded by vast amounts of sea and open ocean, making it the perfect site to launch rockets. Ironically, this climate also led to the failure of the first Falcon 1 launch, during which the engine failed 25 seconds into flight due to a corroded bolt.

Operating Time
  • Operating Time
  • Success Rate
Merlin 1D Inflight Operating Time 3 0 36 Hours Minutes Seconds

Merlin 1D is the 4th iteration of SpaceX's Merlin engine family. Using a mixture of RP-1 (Kerosene) and Liquid Oxygen (LOX), it achieves a thrust to weight ratio exceeding 150, the highest of any kerolox engine. It delivers 654 kN (147,000 lbs) of thrust with a specific impulse of 282 seconds at sea level, and 716 kN (161,000 lbs) of thrust with a specific impulse of 311 seconds in a vacuum. After the second Falcon 9 v1.1 flight, Elon Musk announced that Merlin 1D was actually operating at 85% of its potential, and anticipated to be able to increase the sea level thrust to 730 kN (165,000 lbs).

Merlin 1D Success Rate

To date, no Merlin 1D engine has ever failed in flight, yielding a perfect 100% success rate with 54 engines. Up to 2 Merlin 1D engines can fail on board Falcon 9's first stage, and Falcon 9 can still successfully complete a mission.

Current Astronauts
  • Current Astronauts
  • Cumulative Astronauts
Astronauts - Current

No SpaceX astronauts are in orbit at this time. Currently, SpaceX is actively pursuing a human spaceflight program which will begin with a Dragon pad abort test in July 2014, followed by a Dragon in-flight abort test aboard a Falcon 9 in Early 2015. Completion of these milestones under NASA's Commercial Crew program will allow SpaceX to fly its first astronauts in 2016, and to the ISS in 2017.

Astronauts - Cumulative

Currently, SpaceX is actively pursuing a human spaceflight program which will begin with a Dragon pad abort test in July 2014, followed by a Dragon in-flight abort test aboard a Falcon 9 in Early 2015. The crewed version of Dragon, Dragon v2, will be able to carry up to 7 astronauts for several days and propulsively return to the launch site.

Primary Satellites
  • Primary Satellites
  • All Satellites
Primary Satellites Launched

SpaceX has launched six primary satellites in total; four of which with large masses, all on Falcon 9 v1.1 vehicles. These are CASSIOPE, SES-8, Thaicom 6, and AsiaSat 8; which weigh 500kg, 3,138kg, 3,016kg, & 4,535kg respectively. The former is a scientific and technology experiment mission for MDA Corporation of Canada and the latter three are both geostationary comunication satellites.

Satellites Launched

Over the course of 16 Falcon 9 & Falcon 1 missions, SpaceX has launched many satellites into Earth orbit, both successfully and unsuccessfully. The majority of these are nanosatellites and cubesats. In fact, on the Falcon 9 COTS 1 mission which lofted Dragon into the orbit for the first time, SpaceX deployed an additional 8 satellites. A close second is the inaugural launch of Falcon 9 v1.1 which lofted CASSIOPE into orbit along with 5 other secondary payloads.

Elon Musk's Bet Expires Elon Musk's bet expires at 1 January 2026 00:00 UTC

In April 2009, Michael S. Malone revealed, while interviewing Elon Musk, that the two had a bet that SpaceX would put a man on Mars by "2020 or 2025". Musk has continued to reiterate this rough timeframe since. No pressure, Elon.

All Vehicles
  • All Vehicles
  • Grasshopper
  • F9R
  • DragonFly
Reusability Development Flights

One of SpaceX's many ambitious goals is the creation of reusable rockets and spacecraft, and multiple suborbital development flights are required by multiple vehicles to accomplish this. These vehicles include F9R, to test the return of the Falcon 9 first stage to a landing site, and its precursor Grasshopper; along with DragonFly to help develop the propulsive landing capabilities of Dragon v2.

Grasshopper Flights

Grasshopper was an experimental vertical-takeoff vertical-landing suborbital rocket that SpaceX used to test and develop the technologies needed to successfully return a Falcon rocket back to the launch site propulsively after separation; and consists of a Falcon 9 lower stage body and a single Merlin 1D engine. It flew 8 times before being replaced in April 2014 by F9R-Dev1. Its launches became a hit on video-sharing site YouTube, with multiple flights topping 1 million views.

F9R Flights

F9R extends Grasshopper's flight profile into the transonic and supersonic regimes and includes landing legs and the longer Falcon 9v1.1 first stage. Once subsonic, low-altitude testing of F9R is complete at McGregor, Texas, a second F9R will fly out of Spaceport America, New Mexico to altitudes of up to 100km - fully simulating a Falcon 9 launch, reentry, and landing. F9R's promising life was sadly cut short when during ascent of its 5th flight, the Flight Termination System was activated, causing the rocket to explode.

DragonFly Flights

To test the propulsive return of Dragon v2 back to Earth with its eight hypergolic SuperDraco engines, the reusable DragonFly vehicle will also be tested at McGregor, Texas, once F9R flights there are complete. A number of different test types will be conducted, including 'assisted' tests where the vehicle is dropped from a helicopter and uses parachutes to land along with its engines, and more standard launch-landing flights under its own propulsion.

Reusability Dev. Flight Time

Together, Grasshopper, F9R and DragonFly have collectively been flown at the McGregor Test Facility in Texas for over 10 minutes! No roasted cows have been reported as of yet.

Distance

On 6 January 2014, SpaceX hardware achieved its farthest distance from Earth ever when Thaicom 6 and the Falcon 9 upper stage were boosted in a super-synchronous Geostationary Transfer Orbit around the Earth with an apogee of over 91,590km.

Quickest Turnaround -62 2 52 51 Days Hours Minutes Seconds

The quickest time between SpaceX launches has been broken thrice in SpaceX’s history. The current record was set on the turnaround from Falcon 9 Flight 10 (Orbcomm OG2 Launch 1) to Falcon 9 Flight 11 (AsiaSat 8). It was previously set earlier in 2013 & 2014 with flights 7 & 8. Prior to this Falcon 1 flights 3 & 4 in late 2008 held the record for over 5 years.

Mars Population Count

If a self-sustaining colony on Mars to make life multiplanetary is the goal - there's no better time to start than now. SpaceX eventually aims to, via its Mars Colonial Transporter mission architecture, transport people from Earth to Mars for as low as "$500,000" (relatively easy depending on how much lipstick you buy).

Vehicles Landed

Beginning in late-2014, SpaceX hopes for the first time ever to bring the lower stage of the Falcon 9 launch vehicle back to a landing site propulsively under its own power. Rapid reuse of rocket stages will reduce the cost of access to orbit. Dragon v2 will also land propulsively after returning from orbit. Eventually, SpaceX also hopes to return the upper stage of the Falcon 9 & Falcon Heavy back to a landing pad.

Hours Worked

Since 2002, thousands of SpaceX employees and Elon Musk have worked tirelessly to push the boundaries of engineering and technology, ultimately providing humanity with cheaper, faster, more reliable access to space. Thank you guys.

Under Pressure

27 April 2015 - 7:00am
So, Sunday morning, a time for relaxing after going out
the night before right ? Márcia and I had indeed gone
out last night - some very kind friends volunteered to babysit
Tiago for the evening so we could go and see The Birthday Massacre
play, as we wont be out in a while. They entertained him with
some science demos using dry-ice, which he loved, and even left
some of it behind, so we could do some more this morning for fun.
Indeed, he was very keen, and as soon as he had finished
breakfast he said "Daddy, can we do some more experiments please?"

"Sure" I said, and went to get the dry-ice. At which point I started
to realise that I may have done something a little foolish!

Dry-ice is solid carbon dioxide. At minus seventy nine degrees celcius it is
a little on the chilly side, so to stop it vanishing overnight I had put
the remaining crystals into a small thermos flask. I went to get this,
and because some might have turned to gas overnight I went onto the
balcony to release the pressure before opening it entirely. But the little
valve was jammed. "odd" I thought, and tried to loosen the whole top. again,
no luck. At which point I realised that either the extreme cold, or the
pressure inside the flask had jammed the top.

OK, so the top is jammed. Is this a problem ? Quick calculation in
my head - dry expands by about 850 times when it turns to gas. based
on the amount I put in, and the size of the flask, that's going to be roughly
a hundred atmospheres when it all sublimes. Which is inevitable as the
flask isn't going to keep it at minus seventy nine forever. The chances of
a small domestic thermos flask being able to resist a hundred atmospheres
of pressure without rupturing ? Well, that's pretty much zero.

I looked at the flask with that awful sinking feeling you get when
you realise you have created something which is inevitably going to explode
at some point in the future, and there's nothing you can do about it.

So, lets ring the dry ice people...

Well, I cant be the first person to do this, surely ? Indeed a quick
google shows that the Thermos webpage explicity says to not put dry ice in
one as it may cause the top "to eject forcefully" - a lovely piece of
understatement there. So I found a dry-ice supplier in London, and rang
them to ask what to do.

"I dunno mate" the man on the helpline said, "You are the first person we
have had who has ever done this". I asked what he would suggest.

"Try ringing the fire brigade?"

So, lets ring the fire brigade

I rang the fire brigade. "Uh, how to you expect us to be able
to help you?" said the woman on the phone. I replied that I assumed
the fire brigade encountered potentially exploding cylinders all the time
and would have some way of handling the situation. "oh yes" she said "We
call the Police to have the are cordoned off, and then we get well away
from them". Ah, not quite what I had expected. "maybe you could try
burying it in the garden?" she said helpfully - 'I live in a flat" I
replied.

So, lets ring the police

Actually, I really didn't want to do that. It occurred to me that Islington
police were unlikely to have any form of containment for my small exploding
flask problem and might have to call someone like the bomb squad. I baulked
at escalating the problem that far unless absolutely necessary.

What I really needed was advice from a friend who would understand
the physics of the situation, wouldn't be surprised in the slightest
as being asked for help, and with a proven track record of patiently
handling my somewhat misguided and potentially dangerous schemes.

So lets ring steer

Ah, finally some useful advice. Someone who does the calculation
in their own head, comes to the same numbers as me and the same "ooh, shit!"
conclusion. Yes, its going to go bang - most likely at the valve end
first. We discussed a few solutions - burying in the window box is not
a good idea, we cant get it cooled back down, he doesn't have any emergency
contacts at the University's, and I wouldn't want to carry it across town
anyway. I wasn't sure how much longer it would last, and had no way of
calculating it.

"What about throwing it into the canal?" I suggested

"It'll float" he said.

This is true. But then I thought "not if I weight it down with something".
We have tiles left over form the kitchen. maybe if I put them in a bag with
the flask ? Yes, that should work, as long as there's no air trapped in the
bag in an odd pocket, it should sink nicely, and go bang at the bottom
of the canal where it cant hurt anyone.

Thus a plan was formed...

The other big run in London this morning

I wrapped the flask in a Toys-R-Us bag with a load of ceramic tiles
and wrapped it all round with parcel tape. It made a heavy cylindrical
bundle, and I arranged it with the dangerous end pointing away from me. I
then placed it in front of me, and started to run down Packington Street
towards the canal.

Lets just say I was not feeling particularly calm about this by this
point. The flask had been warming outside for a good hour now, and
the weight of the tiles made it hard to hold away from my body, plus I
had to keep zig-zagging to avoid pointing the bit which was going to
explode at people coming up the street towards me. Thus, weaving
left and right, I sprinted down the hill, through the Packington
Estate, and to the edge of the canal, where I hurled the bag into the
centre of the canal with a splash.

..and there it floated...

"Noooo!!!!". Steer's words about making sure there were no air pockets
trapped in the back suddenly came into my head so very clearly.

"Sink! Please sink!" I cried at the bag.

People were staring at me a bit by now - the canal is a crowded place
on a Sunday morning, and I suspect my behaviour was somewhat out of
the ordinary. I sat my the canal - the bag was too far out to
retrieve, and starting to drift in the direction of the houseboats
moored on the other side. Oh god, I started to realise quite how much
worse the phone call to the police was now going to have to be.

But then, very slowly, one end of the bag began to bubble, the other
end raised into the air, and in the style of Titanic, it slipped
almost vertically below the surface of the water and sank to the bottom.

I stared at the water for a long while. I texted Steer and Márcia
let them know I was OK, and that it had worked. I was about to stand up
and head home when a curious thing happened. The surface of the canal
started bubbling over the spot where the bag had sunk and continued to do so.

More air trapped in the bag ? No, it went on and on, a continuous stream of
bubbles. I realised that the flask must have just ruptured, maybe a minute
and a half after throwing it into the water. That's how close I was to
having it explode in my hands.

I watched the bubbles until they finally finished, and (trembling a little
bit I have to admit) I walked home.

FOAM: New JavaScript Framework by Google Engineers

27 April 2015 - 7:00am
README.md

Build fully featured high preformance apps in less time using FOAM.

  • Application Efficiency

  • Developer Efficiency

"Fast apps Fast"

http://foamdev.com

http://localhost:8888/tests/FOAMTests.html.

Any failed regression test will highlight its results with red borders, and the "Update Master" button will write the test's latest results into the master. This edits tests/FUNTests.xml, which you should then check in. Be careful to make sure the new output of the test is actually valid!

http://localhost:8888/tests/FOAMTests.html?ui=1 to see just the UI tests.

The ?ui=1 parameter shows only tests with the 'ui' tag.

npm. Then you can run:

sudo npm install -g grunt-cli npm install grunt

Currently these files are bloated by rarely-used optional features like Canvas views, Google protobuffer support, and others. We plan to cut these out into separate files eventually.

Startup attempting to use drones to plant 36,000 trees a day

27 April 2015 - 7:00am

BioCarbon Engineering wants to use drones for good, using the technology to seed up to one billion trees a year, all without having to set foot on the ground.

26 billion trees are currently being burned down every year while only 15 billion are replanted. If successful, the initiative could help address this shortfall in a big way.

Drones should streamline reforestation considerably, with hand-planting being slow and expensive.

"The only way we're going to take on these age-old problems is with techniques that weren't available to us before," CEO and former Nasa-engineer Lauren Fletcher said. "By using this approach we can meet the scale of the problem out there."

The drones will fire pods containing pre-germinated seeds at the ground

BioCarbon's system for planting is really quite sophisticated, and should provide better uptake than traditional dry seeding by air.

First, drones flies above an area and report on its potential for restoration, then they descend to two or three metres above ground and fire out pods containing seeds that are pre-germinated and covered in a nutritious hydrogel.

Read more: There are only two truly intact forests left on Earth, study claims

Fletcher doesn't pretend that the method is as good as hand-sowing, but it's a hell of a lot quicker.

With two operators manning multiple drones, he thinks it should be possible to plant up to 36,000 trees a day, and at around 15% of the cost of traditional methods.

A prototype for the system impressed at the Drones for Good competition in the United Arab Emirates, and the company hopes to have fully-working versions by the end of the summer.