LAMP & Oracle Technical Information

Today's guest blogger Rahul Pathak, a Senior Product Manager on the AWS Database Team. Rahul has some news to share.

-- Jeff;

Amazon ElastiCache is now available in two additional Regions: US West (Oregon) and South America (Sao Paulo). Caching systems perform best when they are right next to your application servers, so we’re excited to now have ElastiCache available in all AWS Regions.

In conjunction with this, we're also adding new CloudFormation templates to allow you to set up complete, cache-enabled application stacks in both these Regions, quickly and predictably.

ElastiCache improves the performance of your applications by retrieving frequently used data from a fast, in-memory cache instead of relying entirely on disk-based databases. The service is ideal for increasing throughput for read-heavy workloads and it’s also used in compute intensive scenarios where you can speed up application performance by storing intermediate results in the cache.

If you already run Memcached in EC2, transitioning to ElastiCache is as simple as creating a cache cluster and updating your application configuration with the address of your new cache nodes. You can get more details and instructions in our "How Do I Migrate" FAQ.

If you're new to caching, Memcached, and ElastiCache, Jeff wrote an excellent overview when we launched the service in August 2011 that will tell you all you need to get started. In addition, you'll also find useful information in the recorded version of our "Turbo-charge Your Apps Using Amazon ElastiCache" webinar:

When running ElastiCache in a production environment keep in mind that more nodes give you higher availability while larger nodes ensure that more data can be kept in cache at any point in time. Fortunately, ElastiCache makes it easy to experiment with different configurations quickly and cost-effectively so you can find the setup that best meets your requirements and budget.

You can get started with Amazon ElastiCache by logging in to the AWS Management Console and creating a cache cluster in a matter of minutes.

-- Rahul

Simple Workflow
Today we are introducing the Amazon Simple Workflow service, SWF for short. This new service gives you the ability to build and run distributed, fault-tolerant applications that span multiple systems (cloud-based, on-premise, or both). Amazon Simple Workflow coordinates the flow of synchronous or asynchronous tasks (logical application steps) so that you can focus on your business and your application instead of having to worry about the infrastructure.

Why?
We want to make it easier for you to build distributed, fault-tolerant, cloud-based applications! In our own work with systems of this type, we have learned quite a bit. For example:

1. The applications often incorporate a workflow -- A series of steps that must take place in a predefined order, with opportunities to adjust the workflow as needed by making decisions and by handling special cases in a structured fashion.
2. The workflow often represents a business process - Think about all of the steps involved in processing an order on your favorite e-commerce site. Charging your credit card, updating your order history, arranging for the items to be shipped, shipping the items, tracking the shipment, replenishing inventory, handling returns, and much more.
3. Processes can be complex - Years ago, I was told that a single Amazon.com order needed to make its way through at least 40 different states or steps before it was considered complete. I am sure that the process has become even more complex over time.
4. Flexibility is key - Earlier attempts to specify and codify a workflow in declarative form have proven to be rigid and inflexible. At some point, procedural code becomes a necessity.
5. Ease of use is important - It should be possible to design and implement these applications without spending a lot of time acquiring specialized skills.

You can use Simple Workflow to handle many types of multi-stage operations including traditional business processes (handling an order or adding a new employee), setting up a complex multi-tiered application, or even handling the decision-making process for a multi-player online game.

Some Definitions

Let's start by defining a couple of terms:

• A Workflow is the automation of a business process.
• A Domain is a collection of related Workflows.
• Actions are the individual tasks undertaken to carry out a Workflow.
• Activity Workers are the pieces of code that actually implement the tasks. Each kind of Worker has its own Activity Type.
• A Decider implements a Workflow's coordination logic.

Let's say that we have an image processing workflow, and that it has the following tasks:

1. Accept uploaded file.
2. Store file in Amazon S3.
3. Validate file format and size.
4. Use Amazon Mechanical Turk to classify the image.
5. If the image is unacceptable, send an error message using Amazon SES and terminate the workflow.
6. If the image is acceptable, check the user's balance in the accounting system.
7. Launch an EC2 instance.
8. Wait for the EC2 instance to be ready, and then configure it (keys, packages, and so forth).
9. Convert the image to PNG format and generate a series of image thumbnails.
10. Upload the PNG image and the thumbnails to Amazon S3.
11. Adjust the user's balance in the accounting system.
12. Create an entry in the appropriate database table.
13. Send a status message to the user, again using Amazon SES.

Tasks 1 through 12 make up the Workflow. Each of the tasks is an Action. The code to implement each action is embodied in a specific Activity Worker.

The workflow's Decider is used to control the flow of execution from task to task. In this case, the Decider would make decisions based on the results of steps 4 (Mechanical Turk) and 6 (balance check). There's a nice, clean separation between the work to be done and the steps needed to do it.

Here's a picture:

 

What Does Simple Workflow Do?
Simple Workflow provides you with the infrastructure that you need to implement workflows such as the one above. It does all of the following (and a lot more):

• Stores metadata about a Workflow and its component parts.
• Stores tasks for Workers and queues them until a Worker needs them.
• Assigns tasks to Workers.
• Routes information between executions of a Workflow and the associated Workers.
• Tracks the progress of Workers on Tasks, with configurable timeouts.
• Maintains workflow state in a durable fashion.

Because the Workers and Deciders are both stateless, you can respond to increased traffic by simply adding additional Workers and Deciders as needed. This could be done using the Auto Scaling service for applications that are running on Amazon EC2 instances the AWS cloud.

Your Workers and your Deciders can be written in the programming language of your choice, and they can run in the cloud (e.g. on an Amazon EC2 instance), in your data center, or even on your desktop. You need only poll for work, handle it, and return the results to Simple Workflow. In other words, your code can run anywhere, as long as it can  "see" the Amazon Simple Workflow HTTPS endpoint. This gives you the flexibility to incorporate existing on-premise systems into new, cloud-based workflows. Simple Workflow lets you do "long polling" to reduce network traffic and unnecessary processing within your code. With this model, requests from your code will be held open for up to 60 seconds if necessary.

Inside the Decider
Your Decider code simply polls Simple Workflow asking for decisions to be made, and then decides on the next step. Your code has access to all of the information it needs to make a decision including the type of the workflow and a detailed history of the prior steps taken in the workflow. The Decider can also annotate the workflow with additional data.

Inside the Workers
Your Worker code also polls Simple Workflow, in effect asking for work that needs to be done. It always polls with respect to one or more Task Lists, so that one Worker can participate in multiple types of Workflows if desired. It pulls work from Task Lists, does the work, updates the Workflow's status, and goes on to the next task. In situations that involve long-running tasks, the worker can provide a "heartbeat" update to Simple Workflow. Deciders can insert Markers into the execution history of a Workflow for checkpointing or auditing purposes.

Timeouts, Signals, and Errors
Simple Workflow's Timeouts are used to ensure that an execution of a Workflow runs correctly. They can be set as needed for each type of Workflow. You have control over the following timeouts:

• Workflow Start to Close - how long an execution can take to complete.
• Decision Task Start to Close - How long a Decider can take to complete a decision task.
• Activity Task Start to Close - How long an Activity Worker can take to process a task of a given Activity Type.
• Activity Task Heartbeat - How long an Activity Worker can run without providing its status to Simple Workflow.
• Activity Task Schedule to Start - How long Simple Workflow waits before timing out a task if no workers are available to perform the task.
• Activity Task Schedule to Close - How long Simple Workflow will wait between the time a task is scheduled to the time that it is complete.

Signals are used to provide out-of-band information to an execution of a Workflow. You could use a signal to cancel a Workflow, tell it that necessary data is ready, or to provide information about an emergent situation. Each Signal is added to the Workflow's execution history and the Workflow's Decider controls what happens next.

Simple Workflow will make sure that execution of each Workflow proceeds as planned, using the Timeouts mentioned above to keep the Workflow from getting stuck if a task takes too long or if there is no activity code running.

Getting Started
Here's what you need to do to get started with Amazon Simple Workflow:

1. Write your Worker(s) using any programming language.
2. Write your Decider, again in any programming language.
3. Register the Workflow and the Activities.
4. Run the Workers and the Decider on any host that can "see" the Simple Workflow endpoint.
5. Initiate execution of a Workflow.
6. Monitor progress of the Workflow using the AWS Management Console.

The AWS Flow Framework
In order to make it even easier for you to get started with Amazon Simple Workflow, the AWS SDK for Java now includes the new AWS Flow Framework. This new framework includes a number of programming constructs that abstract out a number of task coordination details. For example, it uses a programming model based on Futures to handle dependencies between tasks. Initiating a Worker task is as easy as making a method call, and the framework takes care of the Workers and the Decision Tasks behind the scenes.

Simple Workflow API Basics
You can build your Workflow, your Workers, and your Decider, with just a handful of Simple Workflow APIs. Here's what you need to know to get started:

• Workflow Registration - The RegisterDomain, RegisterWorkflowType, and RegisterActivityType calls are used to register the various components that make up a Workflow.
  
  
• Implementing Deciders and Workers - The PollForDecisionTask call is used to fetch decision tasks, and the RespondDecisionTaskCompleted call is used to signal that a decision task has been completed. Similarly, the PollForActivityTask call is used to fetch activity tasks and the RespondActivityTaskCompleted call is used to signal that an activity task is complete.
  
  
• Starting a Workflow - The StartWorkflowExecution call is used to get a Workflow started.

The Amazon Simple Workflow API Reference contains information about these and other APIs.

 AWS Management Console Support
The AWS Management Console includes full support for Amazon Simple Workflow. Here's a tour, starting with the main (dashboard) page:

Register a workflow domain

Register a workflow for a workflow domain

Register an activity within a workflow:

Initiate execution of a workflow:

Provide input data to an execution:

See all of the currently executions of a given workflow:

Pricing
Like all of the services in the AWS Cloud, Amazon Simple Workflow is priced on an economical, pay-as-you-go basis. First, all AWS customers can get started for free. You can initiate execution of 1,000 Workflows and 10,000 tasks per month and you can keep them running for a total of 30,000 workflow-days (one workflow active for one day is equal to one workflow-day).

Beyond that, there are three pricing dimensions:

• Executions - You pay $0.0001 for every Workflow execution, and an additional $0.000005 per day if they remain active for more than 24 hours.
• Tasks, Signals, and Markers - You pay $0.000025 for every task execution, timer, signal, and marker.
• Bandwidth - You pay $0.10 for the first Gigabyte of data transferred in. There is no charge for the first Gigabyte of data transferred out, and the usual tiered AWS charges after that.

Amazon Simple Workflow in Action
Here are some ways that people are already putting Amazon Simple Workflow to use:

• RightScale is using it to ensure fault-tolerant execution of their server scaling workflow. Read Thorsten von Eicken's post, RightScale Server Orchestration and Amazon SWF Launch, for more information.
• NASA uses Simple Workflow to coordinate the daily image processing tasks for the Mars Exploration Rovers. Read our new case study, NASA JPL and Amazon SWF, to see how they do it.
• Sage Bionetworks coordinates complex, heterogeneous scientific workflows. Check out the new case study, Sage Bionetworks and Amazon SWF, for complete information.

Go With the Flow
I am very interested in hearing about the applications and Workflows that you implement with Amazon Simple Workflow. Please feel free to leave a comment or to send me some email.

-- Jeff;

All exceptions are catchable with XML_XRD_Exception now

Esri is a leading provider of Geographic Information Systems (GIS) software and geo-database management applications. Their powerful mapping solutions have been used by Governments, industry, academics, and NGOs for nearly 30 years (read their history to learn more).

Over the years, they have ported their code from mainframes to minicomputers (anyone else remember DEC and Prime?), and then to personal computers. Now they are moving their applications to the AWS cloud to provide their customers with applications that can be launched quickly and then scaled as needed, all at a cost savings when compared to traditional on-premise hosting.

Watch this video to learn more about this potent combination:

We will be participating in the Esri Federal GIS Conference in Washington, DC this month; please visit the AWS Federal page for more information about this and other events.

On that page you will also find case studies from several AWS users in the Federal Government including the Recovery Accountability and Transparency Board, the US Department of Treasury, the DOE's National Renewable Energy Laboratory, the US Department of State, the US Department of Agriculture, the NASA Jet Propulsion Laboratory, and the European Space Agency.

On March 21, we will run a free Esri on the Cloud webinar at noon EST. Attend the webinar to learn how to use AWS to process GIS jobs faster and at a lower cost than an on-premise solution. Our special guest will be Shawn Kingsberry, CIO of the US Government's Recovery, Accountability, and Transparency board.

-- Jeff;

Teams from the openSUSE Buildservice and openSUSE Maintenance worked together since weeks now to integrate openSUSE distribution maintenance support into the Buildservice on build.opensuse.org.

There were a lot of changes and a lot of places had to be adapted, but finally they got it working: maintenance updates for openSUSE 12.1 are now handled inside the openSUSE Buildservice without further need of SUSE internal scripts (well: we still will have some of them running as backup for a while now).

As a lot of people were involved in this task and a lot of code has been written, some smaller bugs might still be included, even if everyone tries to avoid failures. One of the most visible bugs was the unsigned 12.1 update repository from 2012-02-18 until 2012-02-19: the reason was a sync script that tried to pull the repository from a wrong location where the signing was not yet done with the new setup.  We apologize for the trouble and irritation caused and really appreciate all the reports from our users about that broken repository – as this shows the high amount of interest and knowledge about the security impact such an unsigned repository has.

With the release of Milestone 1, the development of openSUSE 12.2 has started! We’re pleased to announce that Milestone 1 contains many minor updates, like a new Firefox version but also major things like new artwork and KDE 4.8.

Our release manager, Stephan “Coolo” Kulow said:

There have been enough weeks without another release,
so I started now with uploading Milestone1 of 12.2
(build151)

The main purpose of this release is to find all the
places that need to be changed from 12.1 to 12.2 – the
branding already made a great start. Milestone1 sure
looks great – and different to 12.1 already at this
early stage. Great work, artwork team.

Please keep in mind that Milestone 1 is only the beginning of the 12.2 development cycle and that some things might not work as they should. Please stay patient. We would appreciate if you would test the development release and report bugs and problems to us.

 

Have a lot of fun…

- Added new Generic FixmeSniff that shows error messages for all FIXME comments left in your code
-- Thanks to Sam Graham for the contribution
- The maxPercentage setting in the Squiz CommentedOutCodeSniff can now be overriden in a rulset.xml file
-- Thanks to Volker Dusch for the patch
- The Checkstyle and XML reports now use XMLWriter
-- Only change in output is that empty file tags are no longer produced for files with no violations
-- Thanks to Sebastian Bergmann for the patch
- Added PHP_CodeSniffer_Tokens::$bracketTokens to give sniff writers fast access to open and close bracket tokens
- Fixed an issue in AbstractPatternSniff where EOL tokens were not being correctly checked in some cases
- Fixed bug #19114 : CodeSniffer checks extension even for single file
- Fixed bug #19171 : Show sniff codes option is ignored by some report types
-- Thanks to Dominic Scheirlinck for the patch
- Fixed bug #19188 : Lots of PHP Notices when analyzing the Symfony framework
-- First issue was list-style.. lines in CSS files not properly adjusting open/close bracket positions
-- Second issue was notices caused by bug #19137
- Fixed bug #19208 : UpperCaseConstantName reports class members
-- Was also a problem with LowerCaseConstantName as well
- Fixed bug #19256 : T_DOC_COMMENT in CSS files breaks ClassDefinitionNameSpacingSniff
-- Thanks to Klaus Purer for the patch
- Fixed bug #19264 : Squiz.PHP.NonExecutableCode does not handle RETURN in CASE without BREAK
- Fixed bug #19270 : DuplicateClassName does not handle namespaces correctly
- Fixed bug #19283 : CSS @media rules cause false positives
-- Thanks to Klaus Purer for the patch

- Initial PEAR release
- Begun using PHP 5.3 idioms

It’s always exciting to find out that an app that has changed how I consume news and blog content on my mobile devices is using AWS to power some of their most engaging features. Such is the case with Pulse, a visual news reading app for iPhone, iPad and Android. Pulse uses Amazon Elastic MapReduce, our hosted Hadoop product, to analyze data from over 11 million users and to deliver the best news stories from a variety of different content publishers. Born out of a Stanford launchpad class and awarded for its elegant design by Apple at WWDC 2011, the Pulse app blends a strong high-tech backend with great visual appeal to conquer the eyes of mobile news readers everywhere.

Pulse backend team members from left to right: Simon, Lili, Greg, Leonard

The December 2011 update included a new feature called Smart Dock, which uses Hadoop and a tool called mrjob, developed by Yelp, to analyze users’ reading preferences and continuously recommend other articles or sources they might enjoy.

To understand the level of engineering that goes behind such rich customer features, I spoke to Greg Bayer, Backend Engineering Lead at Pulse:

How big is the “big data” that Pulse analyzes every day? 

Our application relies on accurately analyzing client event logs (as opposed to web logs) to extract trends and enable other rich features for our users. To give you a sense of the scale at which we run these analyses, we literally go through millions of events per hour, which translates to as many as 250+ Amazon Elastic MapReduce nodes on any given day. Since we are dealing with event logs, generated by our users from the various platforms on which they access our app (Android, iPhone, iPad, etc.), our logs grow in proportion to our user base. For example, the recent influx of new users from Kindle Fire (Android) means we now have a lot more logs coming in from those devices.  Also, since the logs are big, we’ve found that it is very efficient to write them to disk as fast as possible - directly from devices to Amazon EC2 (see my tandem article on the logging architecture we use and the graph below, which highlights some of our numbers).

For more Pulse numbers, checkout the full infographic.

Powering Rich Features for Our Users

Much of our backend is built on industry standard systems such as Hadoop. The innovation happens in how we leverage these systems to create value. For us, it’s all about how we can make the app more fun to use and provide rich features that our users will love. For techies, you can read about many of these features in the backend section of the Pulse engineering blog and learn about all the details.

The Right Choice for Big Data

I joined the team here pretty early on as the first backend engineer. I came to Pulse after working at Sandia National Labs, where I built and managed an in-house 70-node Hadoop cluster. This was an investment of over $100,000, operational support, and over 6 months time to get it fully fine-tuned. Needless to say, I was fully aware of the cost and resources needed to run something at the scale that Pulse would need to accommodate.

AWS was and still is the only feasible solution for us. I love the flexibility to quickly stand up a cluster of hundreds of nodes and the added flexibility of choosing the pricing scheme that’s needed for a job. If I need a job done faster, I can always spin up a very large cluster and get results in minutes, or take advantage of smaller instances and the spot marketplace for Amazon Elastic MapReduce if I’m looking to complete a job that’s not time-sensitive. Since an Amazon Elastic MapReduce cluster can simply be turned off when we are done, the cost to run big queries is usually quite reasonable. Consider a cluster of 100 m1.large machines: a set of queries that takes 45 minutes to run on this cluster could cost us approximately $11 - $34 (depending on whether we bid on spot instances or use regular on-demand instances).

Lessons Learned (the bold fomatting below is our doing :) )

It is important to consider the trade-offs and choose the right tool for the job. In our experience, AWS provides an exceptional capability to build systems as close to the metal as you like, while still avoiding the burden and inelasticity of owning your own hardware. It also provides some useful abstraction layers and services above the machine level.

By allowing virtual machines (Amazon EC2 instances) to be provisioned quickly and inexpensively, a small engineering team can stay more focused on the development of key product features. Since stopping and starting these instances is painless, it’s easy to quickly adapt to changing engineering or needs — perhaps scaling up to support 10x more users or shutting down a feature after pivoting a business model.

AWS also provides many other useful services that help save engineering time. Many standard systems, such as load balancers or Hadoop clusters, that normally require significant time and specialized knowledge to deploy, can be deployed automatically on Amazon EC2 for almost no setup or maintenance cost.

Simple, but powerful services like Amazon S3 and the newly released Amazon DynamoDB make building complex features on AWS even easier. Because bandwidth is fast and free between all AWS services, plugging together several of these services is a great way to bootstrap a scalable infrastructure.

Thanks for your time, Greg & best of luck to the Pulse team! 

-rodica

Related: Pulse Engineering - Scaling to 10M on AWS

QA release
Request #14860 New option: AUTORESET

QA release
Bug #18694 Filesystem.php GetDir wrongly encoded filesnames containing single quotes

Oracle Announces General Availability of MySQL Cluster 7.2

* Fixed misspells errors.

Earlier today, GigaOM published a cost comparison of self-hosting vs. hosting on AWS. I wanted to bring to your attention a few quick issues that we saw with this analysis:

Lower Costs in Other AWS Regions - The comparison used the AWS costs for the US West (San Francisco) Region, ignoring the fact that EC2 pricing in the US East (Northern Virginia) and US West (Oregon) is lower ($0.76 vs. $0.68 for On-Demand Extra Large Instances).

Three Year Reserved Instances - The comparison used one year Reserved Instances, but a three year amortization schedule for the self-hosted hardware. You save over 22% by using three year Reserved Instances instead of one year Reserved Instances, and the comparison is closer to apples-to-apples.

High Utilization Reserved Instances - The comparison used a combination of Medium Utilization Reserved Instances and On-Demand Instances. Given the predictable traffic pattern in the original post, a blend of High and Low Utilization Reserved Instances would reduce your costs, and still give you the flexibility to easily scale up and scale down that you don't get with traditional hosting.

Load Balancer (and other Networking) Costs - The self-hosted column does not include the cost of a redundant set of load balancers. They also need top-of-rack switches (to handle what is probably 5 racks worth of servers) and a router.

No Administrative Costs - Although the self-hosted model specifically excludes maintenance and administrative costs, it is not reasonable to assume that none of the self-hosted hardware will fail in the course of the three year period. It is also dangerous to assume that labor costs will be the same in both cases, as labor can be a significant expense when you are self-hosting.

Data Transfer Costs - The self-hosted example assumes a commit of over 4 Gbps of bandwidth capacity. If you have ever contracted for bandwidth & connectivity at this scale, you undoubtedly know that you must actually commit to a certain amount of data transfer, and that your costs will change significantly if you are over or under your commitment.

We did our own calculations taking in to account only the first four issues listed above and came up with a monthly cost for AWS of $56,043 (vs. the $70,854 quoted in the article). Obviously each workload differs based on the nature of what resources are utilized most.

These analyses are always tricky to do and you always need to make apples-to-apples cost comparisons and the benefits associated with each approach. We're always happy to work with those wanting to get in to the details of these analyses; we continue to focus on lowering infrastructure costs and we're far from being done.

-- Jeff;

Wanting to share your experiences with a larger PHP community? Please submit your name and topic ideas (even if you are only suggesting topics and not wishing to actually present them) - each topic requires a separate submission, submit as many as you like: http://speakers.northeastphp.org We hope to have topics and hands-on workshops in four tracks: Core PHP topics (Intermediate to Advanced levels) Web development related topics Training track (workshop style) UX related topics This event is co-organized by 3 User Groups in the Northeast of North America, namely: Atlantic Canada, Vermont and Area, and Boston.

Busy time at the booth

openSUSE brought lots of fun to FOSDEM in Brussels, Belgium. We’re all exhausted now from selling beer, t-shirts, hats and giving demonstrations of openSUSE with GNOME Shell, KDE, Plasma Active, openSUSE-on-ARM (running XFCE) and countless other things. Yet we did want to tell you about FOSDEM before we go catch up on sleep!

Beer and Goodies

Like last year, the crew from the SUSE office in Nuremberg loaded up a bus with people, beer and anything/one else needed for FOSDEM. The bus was left during Friday night at the ULB where FOSDEM would happen. Despite the risk of somebody breaking in and stealing our awesome goodies, it was deemed more important to join the other FOSDEM go-ers in their attack on the tasty-beverage supply of Brussels! Besides, a night outside in the > -10C degrees from last weekend ensured the beer would be cold and ready to drink.

Cool hats to keep your head warm

The next morning, those smart enough not to drink too much (or (wo)manly enough to ignore the hangover and show up anyway) prepared the booth for the onslaught of visitors eager to learn the latest about openSUSE and buy the coolest beer at FOSDEM. Besides this great beverage we also had the usual assortment of stickers, openSUSE DVDs, t-shirts (in any size as long as your size is Large) and of course our demo systems showing off openSUSE. This year we had our big touch screens again, one with GNOME Shell, the other with the latest from KDE, as well as an assortment of smaller devices. Several of them ran ARM with either consoles or XFCE and there was a “WeTab” with Plasma Active on it as well.

Interestingly, our beer got “forked” by the Firefox crowd who bought a bunch of them (we threw in some t-shirts) and put a firefox sticker over the Old Toad badge. Yes, “Free as in Beer” and all that. Suffice to say the beer was not only popular (as some evil tongues claimed) because the K building had no other drinks available – everyone who tried it agreed it was actually a high quality lager. If you want to know more about the beer, see here. Sorry, we don’t ship it, but if you look us up at LinuxTag in May (Berlin) we will have some!

Two ARM devices with openSUSE

FOSDEM

If you have never been to FOSDEM there is little we can do to describe this event. Nevertheless I will attempt to paint you a picture as everyone deserves to know how awesome it is! For starters, as you might know, our beloved Pascal “Yaloki” Bleser is part of the FOSDEM organisation. There is no doubt that the event can do anything but rock! Of course, while Pascal might be as strong as many men, he’s just a part in the mighty wheels that keep FOSDEM running. That is to say: it is big. VERY big. The two days the event lasts (Saturday and Sunday) are packed with over 400 sessions, summing up to over 200 hours of content (yes, in two days), varying from BOF sessions to keynotes and presentations and the attendees litteraly number in the many thousands.

This year, almost all booths were moved to the new K building, which also hosted a number of so-called “devrooms” (project or topic specific rooms). As the old location was getting crowded (crowded as in standing nose to nose breaks) the change was great, both from a hygenic and comfort point of view. Especially since the weather made going outside far less appealing as it had been in previous years – one has to feel sorry for the nicotine addicted at FOSDEM.

The new K building booth area

FOSDEM has a number of buildings spread over the ULB university campus, each of them filled with a number of booths as well as many rooms where talks are held. There are some HUGE rooms but most of them have capacities of 80-150 people. These rooms are organized by a FOSS project or by topic: there were the cross-desktop and the cross-distro rooms but also spaces for LibreOffice, Mozilla, embedded operating systems, JBoss, Mono, Java, Legal issues, virtualization, cloud and more. In other words: you will feel the need for a decent cloning machine once you get an idea of how much interesting stuff goes on in those two days. But (un?)fortunately, that’s not all. The “hallway track”, as in, the area around the booths, is absolutely STUFFED with interesting people. Core developers from projects ranging from Python to Arch Linux and LibreOffice to the kernel can be found wandering around. As a matter of fact, many FOSDEM veterans are known to not visit more than one or two talks – and those often presented by themselves. There are just too many people to talk to. And getting in contact with people at FOSDEM is both easy and hard. Hard, as you will find it difficult to find a person you are looking for in the huge crowd. And easy because most people are incredibly easy to aproach and very much open for a chat.

Motivational poster...

Results

So what did we take away from FOSDEM? First of all – about 6-700 euro from the sales of the t-shirts and beer. This money has been donated to the FOSDEM organisation in the hopes they will use it for something good (like giving themselves a well deserved evening of relaxation, food and drinks).

Second of all, openSUSE is clearly popular and getting more so. Our efforts are recognized and appreciated by our users and that’s a great thing! Many people where very happy to donate a bit for a t-shirt, a hat, some stickers, DVDs and more and we surely convinced quite a few to give openSUSE 12.1 a test drive. There was of course the usual slew of users thanking us for our efforts – as well as those coming with the issues they faced. Interestingly enough, stability was not often a big problem but there are still things “out there” which are not packaged. Hard to believe with the almost 170.000 packages on OBS! But yes, we don’t have the perfect Linux distribution yet, so keep up the good work!
There was quite a number of “geeko talks”, as usual. Of course a number of enthusiastic LibreOffice developers consider themselves Green but there were of course talks by openSUSE contributors in the cross-distribution, X-org, and cross-desktop rooms as well as in many other places. Highlights include talks on openQA, OBS, openSUSE-on-ARM, Snapper, a round table discussion around ambassadors with other distribution projects, and much more.

We had many hugs and catch-up moments as we don’t see each other all that often – it was truly great to meet so many friends again. With visitors from around Europe (and quite a few from other continents too) it was great seeing old and making new friends.

There were interesting discussions with fellow FOSS projects, e.g. with the Ubuntu LoCo team from Belgium that had a stand right next to us.

Last but not least, Richard and Tom deserve big hugs for their organizing work. And obviously, so does everyone else who was there. It was awesome because we were all there!

View more FOSDEM pictures here and here and all around the web…

A few weeks ago in A Coruña, Spain a Hackfest around GNOME Accessibility took place hosted by Igalia . openSUSE found the opportunity to make some questions to the people involved and then learn a bit more about this interesting Project. Our interviewers were Alejandro Piñeiro Iglesias, Joanmarie Diggs and Juanjo Marín.

 

1 – What is ATK and AT-SPI in simple words?

AT-SPI is the acronym for Assistive Technology Service Provider Interface. Its main purpose is to provide a means for an assistive technology to interact with an application. For instance, the Orca screen reader wants to present newly-inserted text, such as a new instant message, to the user. Therefore Orca asks AT-SPI to inform it whenever text gets inserted. When Orca is told what text has just been inserted, it can present that new text to the user in speech and in braille. Similarly, Orca presents each newly-focused object to the user as the user navigates via the keyboard. Orca can do this because AT-SPI tells it each time a new object gains focus.

Orca, of course, is not the only assistive technology out there. Speech recognition tools can make it possible for users to speak the name of something they wish to click on, like the ‘Close’ button in a dialog box, and then do the clicking for them through AT-SPI. A screen magnifier can make sure the user’s location is always visible on the screen by paying attention to changes in the location of the caret, in the selected item, and in the focused item — each of which gets reported to assistive technologies by AT-SPI.

AT-SPI in turn needs a way to get this information from the applications being used. This is typically accomplished through the application’s toolkit.  For instance, Gtk+, Clutter, Gecko, and other toolkits implement an accessibility abstraction layer called ATK.  If a toolkit implements ATK, then AT-SPI will automatically receive the information from that toolkit thanks to the atk-bridge. It turns out that, in the case of Qt, there is no ATK implementation. Instead Qt implements its own direct bridge to AT-SPI. But that is a special case. What is important is that in all cases, accessible free desktop toolkits expose information to assistive technologies, and assistive technologies get that information via AT-SPI.

 

2 – How easy is for someone with disabilities to run a computer? How far is Linux from other similar proprietary software?

In short: it is not especially easy. And in some cases the problems start early on in the user experience because not all distros have accessible installers yet. Having said that, we are seeing more and more awareness of accessibility on the part of developers as well as distros. Thus we are getting closer and closer to the point of Linux accessibility which “just works.”

With respect to how far away Linux is from other similar proprietary software, we’ve admittedly got a ways to go. But it is also worth mentioning that in the case of Linux GUIs, accessibility is comparatively new, having been created just 10 years ago.

 

3 – Do you believe the financial costs make it more difficult?

Yes, in our opinion financial costs do make things more difficult for the end user. Accessibility related software and hardware tend to be quite specialized, and are only required by a very small percentage of the overall user market. As a result these tools are often expensive. For example, the leading, proprietary Windows screen readers cost in the ballpark of $1000 US for a single user license. In the case of the hardware, a braille display with just 24 cells can cost three thousands dollars (or more). Figuring out how to make the hardware more affordable is a difficult problem to solve, but we can at least reduce the overall costs faced by users through Free Software.

 

4 – How did you get involved with GNOME Accessibility?

Piñeiro: In my case it started when a former contractor asked Igalia to provide support for automatic testing. Accessibility technologies are also used to implement automatic testing (like the Mago project). As one of the outcomes of that work, I implemented a basic ATK implementation for Clutter. Then we decided that it would be useful to use that work for accessibility purposes. I contacted the Clutter maintainers to see if they would be interested. They were, so we started to include that functionality in Clutter itself. As part of that work, I began interacting with the GNOME Accessibility developer community and also attended the Boston Summit where I met Joanmarie Diggs who is one of the Orca developers.

Joanmarie: In 2006 Massachusetts announced their decision to make ODF the official file format of the Commonwealth. At that time, I was an Assistive Technology Specialist working at the Carroll Center for the Blind and, due to some issues surrounding the Commonwealth’s decision, a number of companies began paying us a visit to talk about free desktop accessibility. One of those companies was Sun Microsystems, which in those days was where much of the GNOME Accessibility development effort was housed. Orca was amongst the items presented to us, and for the first time I saw something I had wanted for the bulk of the previous decade, namely a screen reader that didn’t cost $1200 and which users and instructors could truly make their own by providing input and contributing code. At the time, my non-work systems were running Kubuntu, so it was just a matter of crossing over to GNOME and getting up to speed on Orca and how things worked in the GNOME community.

 

5 – Where do you get your feedback to improve the development of accessibility generally? Is there just a community involved?

We get a considerable and ongoing amount of input from the community. For instance, GNOME’s Orca mailing list has lots of discussion and can always be relied upon for timely feedback. The participants of that list range from basic users to individuals with enough knowledge to compile and install Orca from master in order to see if a new feature meets their needs or a proposed fix solves a problem. Some users even provide patches for proposed fixes or features to the developers.

We also get feedback from other sources. For example, when local governments want to migrate their desktops to Free Software solutions, they conduct evaluations of the accessibility tools, and provide us with feedback and/or a list of requirements.

 

6 – How can someone who wants to help join forces? Do they need to have any special hardware equipment?

Anyone interested in contributing should take a look at https://live.gnome.org/Accessibility/ or http://projects.gnome.org/accessibility/. There they will find information about accessibility in GNOME, the different areas (development and non-development) in which they help, and how to get in touch with us. Having access to assistive hardware devices is not required, unless of course someone wants to provide a feature or fix based on a specific type of hardware or a particular device.

 

7 – What has been achieved in this Hackfest and what are the next steps?

Being able to bring the free desktop accessibility developers — a group of individuals who are normally scattered around the globe — together in the same room for five full days of discussions was extremely valuable: We were able to talk about how GNOME does things versus how Qt does them; about the differences between Gecko and WebKitGtk; about what Orca needs from the toolkits, how AT-SPI provides it, and what challenges are faced by those toolkits when providing that information via ATK. It is essential that we achieve the most reliable, performant, and standardized accessibility implementation possible, and this event brought us closer to achieving that goal.

The most immediate next step is to implement solutions based on the conclusions reached during the hackfest. Beyond that, we need to keep working together to find answers and reach consensus on the questions and issues which remain unresolved.

Anyone interested in contribute can take a look at http://projects.gnome.org/accessibility/

Thanks to GNOME accessibility team!

As you can tell from my recent post on Amazon S3 Growth for 2011, our customers are uploading new objects to Amazon S3 at an incredible rate. We continue to innovate on your behalf to drive down storage costs and pass along the resultant savings to you at every possible opportunity. We are now happy (some would even say excited) to announce another in a series of price reductions.

With this price change, all Amazon S3 standard storage customers will see a significant reduction in their storage costs. For instance, if you store 50 TB of data on average you will see a 12% reduction in your storage costs, and if you store 500 TB of data on average you will see a 13.5% reduction in your storage costs.

Effective February 1, 2012, the following prices are in effect for Amazon S3 standard storage in the US Standard region:

Storage Old (GB / Month) New (GB / Month) First 1TB $0.140 $0.125 Next 49TB
$0.125
$0.110 Next 450TB $0.110
$0.095 Next 500TB $0.095 $0.090 Next 4000TB $0.080 $0.080 (no change) Over 5000TB $0.055 $0.055 (no change)

The prices for all of the other regions are listed on the Amazon S3 Pricing page. For the AWS GovCloud region, the new lower prices can be found on the AWS GovCloud Pricing page.

There's been a lot written lately about storage availability and prices. We've often talked about the benefits that AWS's scale and focus creates for our customers. Our ability to lower prices again now is an example of this principle at work.

It might be useful for you to remember that an added advantage of using a cloud storage service such as Amazon S3 over using your own on-premise storage is that with cloud storage, the price reductions that we regularly roll out apply not only to any new storage that you might add but also to the existing storage that you have. This could amount to considerable financial savings for many of you.

-- Jeff;

We launched Amazon DynamoDB with a live video feed that was very well-attended. If you didn't get a chance to watch at the time, you can do so now:

You may also enjoy this short video featuring Werner Vogels, James Hamilton, Dave Lang, and Swami Sivasubramanian:

The Introducing Amazon DynamoDB Webinar will take place on February 15th at 10:00 AM PST. Stefano Stefani (Principal Software Engineer) and Dave Lang (Product Manager) will be presenting and fielding questions from the audience.The webinar is free but you do need to sign up.

-- Jeff;

Voting is now open for the 2012 election of at large directors of the Drupal Association. Two directors will be elected from among the ten candidates.

About the Drupal Association elections

When we designed a new governance structure for the Drupal Association last year, we decided that most of the board is selected through a nominating committee with the goal to carefully balance many factors like needed skills and geographical and sector representation. However, it was also deemed important that we have directors chosen directly by the Drupal community to make sure that the community is always well-represented.

We're holding our first open community elections! Two community "at large" directors will be elected to the Drupal Association Board of Directors, and YOU can get to say who they are!

Where to find out about candidates

• Review their nomination profiles.
• Read the notes from the two all candidates' meetings at http://groups.drupal.org/node/207398.

Who can vote?

Voting is open to all individuals who registered an account on drupal.org prior to January 18, 2012 and who have logged into that account at least once in the one-year period prior to February 3, 2012.

There is no need to register to vote. The voting system has been set up and prepopulated with the list of eligible voters.

How to vote

• Log in to this site.
• Visit the https://association.drupal.org/2012-vote page. After clicking through, you will be asked to rank each of the eligible voters, from 1st (top choice) to 10th (last choice). You also need to check a box confirming you're an eligible voter. Make your selections and save the form. That's it!

How does voting work?

The voting is done using the "Instant Runoff" voting method, powered by Decisions module. For more about this method of voting, please see this helpful YouTube video which explains it with post-it notes: http://www.youtube.com/watch?v=wA3_t-08Vr0

Can I change my mind after I've voted?

Yes! Before the close of voting, you can return to the voting form, cancel your previous vote, and submit a new vote.

When will voting close?

Tuesday, February 7, 2012 is the last day of voting. Voting will close at 00:00 UTC on Wednesday, February 8, 2012.

How will results be determined and announced?

When voting closes, a four-member elections team will review the results and post them to this site (association.drupal.org). Results will then be forwarded to the Drupal Association board for ratification.

The election team includes Angela Byron, DA board member; Cary Gordon, DA board member; Nedjo Rogers, DA advisory board member; and Thomas Svenson, Drupal community member who participated in the community process of planning the elections.

Why was voting delayed?

We had focused a bit too much on organizing the elections and left finalizing the actual voting system till the last minute. After several community members and Drupal Association staff pitched in, we got the elections system up about 3 hours after the planned opening of voting.

Wait. Only XXX eligible voters? What gives?

Despite the fact that the voting form lists far fewer, there are actually 270K Drupal.org accounts that fit the voter eligibility criteria. Valid accounts are added to the electorate list when they visit the Association website. These shenanigans are due to the Bakery module, our single-sign on solution, and the requirement to reconcile peoples' Association.drupal.org user IDs and their Drupal.org user IDs.

Problems and solutions

If you believe you are eligible to vote and try to vote and cannot or encounter some error, please post an issue to the Drupal Association issue queue, selecting "elections" as the component.

More about the elections

• The nominations announcement.
• The elections plan.
• All elections posts.