Planet Ubuntu
Subscribe to Planet Ubuntu feed
Planet Ubuntu - http://planet.ubuntu.com/
Updated: 23 min 37 sec ago

Daniel Holbach: Bringing Ubuntu App Dev Schools to YOUR LoCo

Tue, 2014-03-18 11:13

App development for Ubuntu is a hot topic and many have blogged and talked about this in the past months. Still I’d like to point out two things which never cease to amaze me:

  • Writing the code of the app once and have it work on everything from a phone to a TV.
  • It’s easy. We had people join the Ubuntu Core Apps team, who had never written apps using QML or HTML5. These people now delivered some of the apps which will come preinstalled with Ubuntu phones in stores this year. Getting their feet wet and initial drafts of the apps up and running was a matter of days only.

This is just fantastic and something we should share.

Ubuntu App Dev Schools?

 

At UDS we had a really nice discussion about how to bring more App Development training events to our Ubuntu community. We came up with a number of work items, focusing on

  • improving our presentation materials,
  • making it easier for newcomers to step in, learn and present,
  • reaching out to app developer communities and our LoCo teams at the same time.

With the Ubuntu Global Jam coming up in just 3 weeks and soon followed by the 14.04 release and its release parties, we have to move fast to make this happen. To coordinate this better, David and I decided to have a daily standup meeting on Google Hangout at 9:30 UTC. Let us know (maybe on #ubuntu-locoteams) if you want to join the conversation.

We need help.

Obviously we need teams to organise events, but we need other help as well:

  • Planning. Join our planning events mentioned above.
  • Hosting. If you are interested in running an event, you should check our docs and see if there’s anything missing in there.
  • Collaborating. Talk to your LoCo team and see if you can host an Ubuntu App Dev School for Ubuntu Global Jam or your local 14.04 release party. Give us feedback on how it’s going.
  • Slightly unrelated. Help me with a VirtualBox question: I set up a VirtualBox image using Trusty, so we can have an up-to-date image with the newest SDK preinstalled, so we’re prepared if Mac or Windows users turn up to an event. Unfortunately the resolution is just up to 640×480, even with the Guest Additions loaded. Can anyone help me out?

If you are preparing to run the event, please check our Materials section, review what we have and give us feedback. Either leave a comment on this page, or…

On the following days we are going to have some Feedback / Q&A sessions on Ubuntu on Air:

There you will not only have the opportunity to ask questions about organising your event, but also all the technical questions you should have for running your presentations.

Another opportunity to find out more, is the LoCo Teams Update on Air on Saturday at 19 UTC.

Bringing more apps to Ubuntu is lots of fun and will make Ubuntu for phones/tablets/laptops/desktops/TVs/everything else a lot more interesting!

Canonical Design Team: Making ubuntu.com responsive: making the rules a reality

Tue, 2014-03-18 11:09

This post is part of the series ‘Making ubuntu.com responsive‘.

The rules document we drafted proved a useful and good guide for those few development days, and a proof of concept was created and presented to the rest of the team.

When we all sat down to review the result, a few things were clear:

  • Even though lots (and lots) of tweaks and design thinking were needed, our desktop style guide did not look bad at all in small screens — the result was promising
  • The main places where things looked broken were custom hero and background images
  • Some one-off overriding styles applied in some pages did not play well in small screens, as they might have been added in absolute sizes (like pixels) or weren’t flowing as they should
  • Some pages that were long on the desktop quickly became very long at small screen sizes

First ubuntu.com responsive prototype.

Since this was a ‘quick and dirty’ test of some common-sense responsive rules, a lot had not been done in the code that would eventually have to be done, such as:

  • Refactoring the original Sass files to be mobile-first
  • Cleaning up the existing Sass files as much as possible: as websites grow, the need for custom, one-off exceptions increases, so we needed to set aside some time to rationalise some of these sneaky overrides

However, the exercise showed us that our existing framework was indeed flexible enough to be converted to be responsive, but it also showed us that we still had a lot of work to do!

Reading list

Canonical Design Team: Making ubuntu.com responsive: pilot projects (4)

Tue, 2014-03-18 09:18

This post is part of the series ‘Making ubuntu.com responsive‘.

Making www.ubuntu.com responsive has been an ongoing goal of ours for a while, and we’ve been discussing and preparing for it for over a year. However, the rest of the world doesn’t wait, and the work doesn’t stop coming in!

We knew that a couple of other projects, namely Ubuntu Resources and the new Canonical site, were going to have to be completed before the main site, and that they would have to follow mobile-first and responsive philosophies, which posed a few questions:

  • How were we going to manage three consecutive projects trying to find solutions for similar problems?
  • Which project was going to influence which? If we did something new on a new project, how was that going to affect ubuntu.com in the future?
  • In the case of canonical.com, the site structure was much simpler than ubuntu.com: how would solutions developed for such a case apply to something more complex?
  • Ubuntu Resources had a start date before the responsive ubuntu.com project, but a completion deadline after it: how would this impact the responsive solutions we were going to try to come up with?

These and other questions seemed to us tricky to solve at the time. However, we had time and resourcing constraints, and deadlines that we just had to work with.

In the end, the work that we did (and are still doing) on the two other sites helped and influenced the work that we’d be doing on ubuntu.com.

Ubuntu Resources

We launched the alpha version of Ubuntu Resources in November last year. This was our first look into creating a mobile-first website. We’ve recently released the beta version, which is still focused on improving the small screen experience. Right now, we are working on the medium screen size layouts of the site, which should be going live very soon.

Even though work on this project started before work on responsive ubuntu.com, we knew the deadline for completion of its final stages (adapted to large screen sizes) was likely to be after the first release of the retrofitted ubuntu.com.

Ubuntu Resources homepage.

These are some of the lessons we’ve learnt whilst working on this project:

  • To save space at the top of the screen and allow for more content to be visible, the global navigation (which links to other sites within the Ubuntu universe) could be relegated to the bottom of the screen, in small screens. To keep its visibility, we added a link from the site’s main navigation
  • Simply decreasing the typographic scale that we were using in our style guide wasn’t enough for small screens. We had to slightly reduce the largest sizes and increase the smallest ones to improve readability
  • Space is at a premium in small screens, so we massively reduced row and box padding and margins between elements
  • We’ve reused the grid from the Ubuntu phone, which divides the portrait phone screen in 40 square grid units (horizontally) and where spaces between elements are usually counted as one or more grid units. Since the objective was to have a more condensed version of margins and padding across the small screen version of the site, using this grid allowed for more flexibility, with much smaller spaces between elements, without having to create a new grid — reuse and recycle!
  • It was important to keep the strong Ubuntu brand at the top of the screen, even on small screens, and to keep the navigation as straightforward to use as possible. This meant keeping the Ubuntu orange navigation background and a clear Ubuntu logo (when at first we tried a simplified version of the logo without the Ubuntu wordmark, user feedback revealed landing on the site was confusing, as they didn’t recognise the simplified logo or why the word “resources” was in the navigation)

The phone grid.


Before (top) and after (bottom) Ubuntu Resources navigation: with and without the full Ubuntu logo.

Canonical.com

Early this year we launched the new and improved canonical.com, which is mobile-first and responsive.

While we were working on canonical.com, work on Ubuntu Resources was paused, which meant we could borrow some of the learnings from Resources but we’d need to find solutions to other problems we hadn’t yet addressed, such as scaling from small to medium and large screen sizes and defining those breakpoints.

From this project, we took away:

  • The medium screen size font sizes, again slightly adjusted for readability
  • Improved spacing between elements and padding on medium sized screens, which can be larger than in smaller screens, but slightly tighter than large screens
  • The use of the new folded paper background, developed for the phone designs
  • The use of flat colour blocks (mainly white and dark aubergine) to divide content, as opposed to divider lines
  • The use of SVG images for interface elements and icons, and a PNG fallback for non-supporting browsers
  • Patterns for reflowing images next to text in small screens: in most instances, when the image is to the left of the text, it can be moved above it in smaller screens; if the image is to the right of the text, it can be moved below it in smaller screens
  • An accordion pattern for small screens and tabs for larger screens

From left to right: comparison between margins and padding in small, medium and large screens.

The new folded paper background.

Tabs in small screens (left) and large screens (right).

Once canonical.com was launched, it was time to get back onto making ubuntu.com responsive. We felt that testing out ideas and strategies in smaller responsive projects before going full speed on our largest site was a positive experience, and would advise teams in similar scenarios to try and follow a similar strategy if the prospect of starting with your most popular site seems daunting or is simply impractical.

Reading list

Daniel Pocock: Hangouts Outage? Try WebRTC and JitMeet

Mon, 2014-03-17 21:35

With Hangouts being offline right now, it might be a good opportunity to catch up on some of the exciting, free and open alternatives:

Benjamin Kerensa: Sponsor Debconf14

Mon, 2014-03-17 20:30

Debconf14 is just around the corner and although we are making progress on securing sponsorships there is still a lot of progress that needs to be made in order to reach our goal. I’m writing this blog post to drum up some more sponsors. So if you are reading this and are a decision maker at your company or know a decision maker and are interested in supporting Debconf14, then please check out the Debconf14 Sponsor Brochure and if still interested then reach out to us at sponsors@debconf.org. I think it goes without saying that we would love to fill some of the top sponsorship tiers.

I hope to see you in August in Portland, OR for Debconf14!

 

About Debconf

DebConf is the annual Debian developers meeting. An event filled with discussions, workshops and coding parties – all of them highly technical in nature. DebConf14, the 15th Debian Conference, will be held Portland, Oregon, USA, from August 23rd to 31st, 2014 at Portland State University. For more detailed logistical information about attending, including what to bring, and directions, please visit the DebConf14 wiki.
This year’s schedule of events will be exciting, productive and fun. As in previous years (final report 2013 [PDF]), DebConf14 features speakers from around the world. Past Debian Conferences have been extremely beneficial for developing key components of the Debian system, infrastructure and community. Next year will surely continue that tradition.

The Fridge: Ubuntu Weekly Newsletter Issue 359

Mon, 2014-03-17 19:48

Welcome to the Ubuntu Weekly Newsletter. This is issue #359 for the week March 10 – 16, 2014, and the full version is available here.

In this issue we cover:

The issue of The Ubuntu Weekly Newsletter is brought to you by:

  • Elizabeth Krumbach Joseph
  • Paul White
  • Emily Gonyer
  • Jim Connett
  • And many others

If you have a story idea for the Weekly Newsletter, join the Ubuntu News Team mailing list and submit it. Ideas can also be added to the wiki!

Except where otherwise noted, content in this issue is licensed under a Creative Commons Attribution 3.0 License BY SA Creative Commons License

Jorge Castro: Introducing Juju Bundles

Mon, 2014-03-17 14:46

“Rick, I want you to fire up an empty cloud deployment”, said no boss ever.

The various teams who make up “The Ubuntu Server Team” work on various bits. Some work to make OpenStack easy to deploy, some work on packaging, some work on building images for all the public clouds we support. All this is fine and dandy, but at the end of the day, our users deploy things on top of Ubuntu Server, and these workloads are really what it’s all about.

Over the past two years it’s been increasingly obvious to us that orchestrating workloads is becoming one of the most important things we can help users with. What’s the point of an easy to use OpenStack installer if people can’t plop Hadoop, or Cassandra, or their Rails app right on top easily?

One part of this solution is our work on Juju, which makes orchestration simple; we can just manage deployments at the service level while not caring (too much) about individial instances. Some people wanted and needed things to be even highter level. “Look, I’ve got a pile of machines over here, I need a MongoDB cluster” and you don’t have the time! Or more increasingly, you know how to do all these steps, but need a way to make it portable so everyone else in your organization can benefit from your hard work.

So today we announced Juju Bundles. Technically, they’re very simple, it’s a yaml file that describes charms and their relationships to other charms. It can contain machine constraints, or any of the parameters you’d ship in a charm. That means deploying large swaths of services are now one command.

juju quickstart bundle:~charmers/mongodb/cluster juju quickstart bundle:~charmers/hadoop/cluster juju quickstart bundle:~charmers/mediawiki/scalable

There’s a 13 node 3 shard MongoDB cluster, a 7 node starter Hadoop cluster, and a 5 node Mediwiki. All of them can be horizontally scaled out of the box. juju add-unit -n10 hadoop-slavecluster and go to town. Not Bad!

Getting Started

If you’re on Ubuntu Rick has the info in his blog post, you basically:

sudo add-apt-repository ppa:juju/stable sudo apt-get update sudo apt-get install juju-quickstart

Then run one of the commands I mentioned:

juju quickstart bundle:~charmers/mongodb/cluster

Juju will then walk you through setting up an environment. Pick one. AWS, Microsoft Windows Azure, Joyent, HP Cloud, or your own OpenStack or laptop via LXC, then fill out your creds:

Now get a cup of coffee, or watch the console for the magic, maybe read the README.

Now go put that bad boy to work.

Quickstart is not yet available for OSX or Windows (we’re working on it), but if you want to play with it we’ve made a Vagrant box available for you to play with.

The Future

Over the course of the next few weeks as we ramp up to 14.04 we’ll be doing a few things. We’ll be tightening up the URLs to be easier to remember, so something like juju quickstart bundle:mongodb/cluster. Obviously we’d love to see more bundles from the community being submitted.

Check out the documentation for more, and for a more technical description of how bundles work check out Rick’s blog post. We also made a tutorial video on how to make and share your own bundles.

Mark Shuttleworth: ACPI, firmware and your security

Mon, 2014-03-17 13:05

ACPI comes from an era when the operating system was proprietary and couldn’t be changed by the hardware manufacturer.

We don’t live in that era any more.

However, we DO live in an era where any firmware code running on your phone, tablet, PC, TV, wifi router, washing machine, server, or the server running the cloud your SAAS app is running on, is a threat vector against you.

If you read the catalogue of spy tools and digital weaponry provided to us by Edward Snowden, you’ll see that firmware on your device is the NSA’s best friend. Your biggest mistake might be to assume that the NSA is the only institution abusing this position of trust – in fact, it’s reasonable to assume that all firmware is a cesspool of insecurity courtesy of incompetence of the worst degree from manufacturers, and competence of the highest degree from a very wide range of such agencies.

In ye olden days, a manufacturer would ship Windows, which could not be changed, and they wanted to innovate on the motherboard, so they used firmware to present a standard interface for things like power management to a platform that could not modified to accommodate their innovation.

Today, that same manufacturer can innovate on the hardware and publish a patch for Linux to express that innovation – and Linux is almost certainly the platform that matters. If Windows enters this market then the Windows driver model can evolve to give manufacturers this same ability to innovate in the Windows world, where proprietary unverifiable blobs are the norm.

Arguing for ACPI on your next-generation device is arguing for a trojan horse of monumental proportions to be installed in your living room and in your data centre. I’ve been to Troy, there is not much left.

We’ve spent a good deal of time working towards a world where you can inspect the code that is running on any device you run. In Ubuntu we work hard to make sure that any issues in that code can be fixed and delivered right away to millions of users. Bruce Schneier wisely calls security a process, not a product. But the processes for finding and fixing problems in firmware are non-existent and not improving.

I would very much like to be part of FIXING the security problem we engineers have created in our rush to ship products in the olden days. I’m totally committed to that.

So from my perspective:

  • Upstream kernel is the place to deliver the software portion of the innovation you’re selling. We have great processes now to deliver that innovation to users, and the same processes help us improve security and efficiency too.
  • Declarative firmware that describes hardware linkages and dependencies but doesn’t include executable code is the best chance we have of real bottom-up security. The Linux device tree is a very good starting point. We have work to do to improve it, and we need to recognise the importance of being able to fix declarations over the life of a product, but we must not introduce blobs in order to short cut that process.

Let’s do this right. Each generation gets its turn to define the platforms it wants to pass on – let’s pass on something we can be proud of.

Our mission in Ubuntu is to give the world’s people a free platform they can trust.  I suspect a lot of the Linux community is motivated by the same goal regardless of their distro. That also means finding ways to ensure that those trustworthy platforms can’t be compromised elsewhere. We can help vendors innovate AND ensure that users have a fighting chance of privacy and security in this brave new world. But we can’t do that if we cling to the tools of the past. Don’t cave in to expediency. Design a better future, it really can be much healthier than the present if we care and act accordingly.

 

Canonical Design Team: Making ubuntu.com responsive: setting the rules

Mon, 2014-03-17 11:32

This post is part of the series ‘Making ubuntu.com responsive‘.

The front end framework that powers www.ubuntu.com represents the visual evolution of the site over the past few years: designs have become cleaner, lighter and more open. It was designed without responsiveness in mind, but it has proven flexible, robust and great for our needs: user experience designers can quickly create wireframes for new and updated pages based on existing patterns and developers can create new pages that look good with little input from designers.

Web style guide front page.

Even though the framework uses a fixed-width container to wrap the content, the containers within it were built to percentages, which means that if that surrounding container were to be removed, the site would become fluid.

One page of the current site without a wrapping container.

We didn’t want to lose the work that has been put into this style guide. After a long discussion, we agreed that even though we were going to convert the CSS powering the site into mobile-first — so the media queries would be added for larger screen sizes instead of the other way around —, we were going to keep the desktop version as it was initially defined in the style guide.

This is likely a restriction that many other teams share: where there is a will and need to make an existing site responsive, but no budget and/or resources to start from scratch.

We decided that it would be a good idea if our developers, Anthony, Graham, and Karl, could sit in a room for a few days and create a ‘quick and dirty’ prototype of what our current site, using the current styles, would look like in a responsive world.

The main goals of this exercise were:

  1. To see how disastrous, or indeed how well, the style guide would play when a handful of responsive guidelines were applied
  2. To give the developers a better understanding of the effort required and issues involved in converting the existing stylesheets into a mobile-first, responsive format

We created a Google doc, structured in the same way as our style guide, where we laid out some rules that would get the developers started on the prototype.

The document started with the more broad and general rules:

  • Try to create breakpoints that fit our content, instead of just random device-specific sizes
  • Try to keep breakpoints to a minimum, with fluid designs in between each breakpoint

We then laid out some scaffolding (layout and grid) rules:

  • Content that is divided in half or thirds should convert into single column when it becomes too narrow
  • If the content is divided into quarters, there might be a step in the middle (halfs)
  • In rows that include an image to the left or right of the text, the image should move above or below the text, respectively
  • Hero images might need to be looked at individually rather than a single rule for all
  • Experiment reducing padding inside rows and boxes incrementally as the screen size decreases
  • Remove column dividers at smaller screen sizes

We then moved on to forms rules:

  • Our forms are already quite vertical, at this stage, make sure we are using correct HTML5 input types

And tables rules:

And finally JavaScript rules:

  • No forcing of equal-height boxes
  • Make tabbed content into expanding/collapsing accordion widgets

Many of our styles didn’t need changing at this stage and this was all written down in the doc too.

We also knew that, at this point, we couldn’t look into trickier problems such as the navigation, the typographic scale or how our multiple footers would play in a small screen, so we decided to leave this for later.


Navigation and multiple footers were too complex an issue to be solved at this early stage.

Now it was time for the developers, with this doc in hand, to take a first go at making www.ubuntu.com responsive!

Reading list

Canonical Design Team: Making ubuntu.com responsive: intro

Mon, 2014-03-17 11:19

We’ve known for a while it was time to convert our main site, www.ubuntu.com, into a responsive site, and we’re now nearing the end of the project!

The main www.ubuntu.com site receives millions of visitors every month and it holds information on the variety of Ubuntu products and services, allowing people to download Ubuntu, get in touch with Canonical or find support.

In an ideal scenario, if you were going to convert a non-responsive site into a responsive one, you would start from scratch and do everything right and perfectly from the beginning. But what would be the fun in that?

In reality, starting from scratch on a site the size of ubuntu.com is just not practical or easily achievable. We evolve, grow and iterate the site constantly for releases, upgrades, launches and design updates. It is a living, breathing site, and we can’t really afford to stop, and start again. We realise other teams will also be faced with this reality, so we want to share the journey we have taken and some lessons we learned along the way.

In this series of posts, we’ll document the process we’re following in making that transition. We hope to give others an insight into what’s going on behind the scenes, the obstacles we’re facing, the solutions we’ve tried, the questions we have, and basically the nitty gritty of a real world responsive retrofitting project.

We will be covering:

  • Setting the rules
  • Making the rules a reality
  • Pilot projects
  • Lessons learnt
  • Scoping the work
  • Approach to content
  • Making our grid responsive
  • Adapting our navigation to small screens
  • Dealing with responsive images
  • Updating font sizes and readability
  • Ensuring performance
  • JavaScript considerations
  • Testing on multiple devices

I’ll update the list above with links to new posts as we go along. We’d love to hear your thoughts, questions and solutions you’ve tried in your own projects, and how we can make this series more useful: leave your comments below, and we hope you enjoy the posts!

Kubuntu: Ladies Polo Shirts Now in Kubuntu Merchandise Shop

Mon, 2014-03-17 11:02
The Kubuntu Merchandise shop which sells a range of classy polo shirts has been restocked. By popular request it now features a range of ladies fit polo shirts.

Riccardo Padovani: One year later…

Mon, 2014-03-17 08:00

Lot of things has changed in last year in my life: I changed university, city, I started (and finished) my first course on Coursera, I started to contribute to Ubuntu and to write code, and I achieved the Ubuntu Membership and others fantastic things.

But what happened exatly one year ago? Well, I posted this image in Ubuntu community on Google+:

Seems like another era! How much work the community (and Canonical guys) have done!
This was the first time I did something for Ubuntu, a screenshot on G+. Since then I started to contribute to Ubuntu for Phones: few days later I did my first patch (nazi grammar patch :-P) and since July I started to contribute on an ongoing basis.
It has been an exciting year, I did more than 250 commits for more than 10,000 lines of code; not bad, whereas I had never programmed before and I do it in my free time. I want to continue on this way for long time :-)

But take a look on where we are. This is a screenshot on Ubuntu 14.04, on a smaller screen:

Awesome! In only one year so much improvements!

The convergence strategy is fantastic, we’re building the future :-)

So, why don’t you start to contribute to Ubuntu?

Ciao,
R.

This work is licensed under Creative Commons Attribution 3.0 Unported

Raphaël Hertzog: Kickstart the Arabic Translation of the Debian Handbook

Mon, 2014-03-17 07:31

I just wanted to highlight that Muhammad Saied, a volunteer translator of the Debian Administrator’s Handbook, is currently running a crowdfunding campaign with Mohamed Amine so that they can complete the Arabic translation that they started.

There’s only 6 days left to collect the last $2500… click here to help spread Debian to the Arabic world.

No comment | Liked this article? Click here. | My blog is Flattr-enabled.

Benjamin Mako Hill: Community Data Science Workshops in Seattle

Sun, 2014-03-16 18:41

Photo from the Boston Python Workshop – a similar workshop run in Boston that has inspired and provided a template for the CDSW.

On three Saturdays in April and May, I will be helping run three day-long project-based workshops at the University of Washington in Seattle. The workshops are for anyone interested in learning how to use programming and data science tools to ask and answer questions about online communities like Wikipedia, Twitter, free  and open source software, and civic media.

The workshops are for people with no previous programming experience and the goal is to bring together researchers as well as participants and leaders in online communities.  The workshops will all be free of charge and open to the public given availability of space.

Our goal is that, after the three workshops, participants will be able to use data to produce numbers, hypothesis tests, tables, and graphical visualizations to answer questions like:

  • Are new contributors to an article in Wikipedia sticking around longer or contributing more than people who joined last year?
  • Who are the most active or influential users of a particular Twitter hashtag?
  • Are people who participated in a Wikipedia outreach event staying involved? How do they compare to people that joined the project outside of the event?

If you are interested in participating, fill out our registration form here. The deadline to register is Wednesday March 26th.  We will let participants know if we have room for them by Saturday March 29th. Space is limited and will depend on how many mentors we can recruit for the sessions.

If you already have experience with Python, please consider helping out at the sessions as a mentor. Being a mentor will involve working with participants and talking them through the challenges they encounter in programming. No special preparation is required.  If you’re interested,  send me an email.

Shane Fagan: Linux games this year that im looking forward to

Sun, 2014-03-16 14:06

I try to do 1 of these a year so here is my list of things im waiting on.

Last year I said I can't wait for "Counter Strike Global Offensive". I love the game and am watching the finals of IEM right now on Twitch. I was in the beta but since I don't have a Windows partition since last year I couldn't play it or some other really good games that I am waiting on. Any time now Valve :-/ (side note as of this post its on sale so if you like FPS games and have a computer made in the past 2 years id suggest picking it up)

"Wasteland2" is something im definitely looking forward to playing. I played Fallout1 and my turn based story itch is getting to me since its definitely not a popular genre of games any more the space is definitely there for a game like this. Its already on steam in early access but not out on Linux yet but since its written in Unity3d it is only a matter of time before its out but ill wait to buy it myself, it seems like it will be on Linux in a few weeks given it was just released on MacOS. Side note they also have another game in development called torment tides of numenera which sounds like it won't be out till next year but it looks like a good game too.

"Planetary Annihilation", its a super strange thing to be excited for a game that I already have in my library but im still waiting to actually play it more since last time I had the chance was late alpha. I recently got an AMD R9270x and the game sadly doesn't work correctly on my machine. The even more frustrating part is I was using haswell graphics before that and they didn't work with it either. So I really hope their support gets better so I can actually play it some more but if you have Nvidia hardware go right ahead and play yourself if you like RTS games. This has a really fresh take on the genre of RTS.

"Prison architect", wow what a game for something so cheap and such a simple idea. Make a prison and keep the prisoners in there. The game is in early access as well like wasteland and planetary annihilation but is very stable and they are adding new things every month. Its really great to play a game that isn't finished and yet you can sink hours into it and make amazing things, then come back the next month and see whats changed. Go out and get it if you want something to relax and have fun and watch the rioting, fires, escapes and general mayhem that happens. I wouldn't say it would be the greatest game for kids or anything but about 15-50 should get a good laugh from it.

And the last game is "Castle Story", its a pretty simple game kind of along the line of minecraft but its like an RTS mixed with tower defense. I really enjoyed the survival mode a lot and its really cool in general.

Tags: 

Lubuntu Blog: Countdown clock

Sun, 2014-03-16 13:13
I'd like to thank our friend and collaborator Corbin Davenport for this. Specially when I used to be a pain in the neck, asking for the new clock day after day, and I must say the result is, as always, really amazing (have a look on your right). You can use it on your own website. Just copy and paste this HTML code: <iframe src="http://ubuntuone.com/2mnKK5WN8YIBIS4TCtBBuD" style="width:170px;

Sam Hewitt: Onion Rings

Sun, 2014-03-16 00:00

I have to get my once-a-month greasy food cravings satiated some way –so I made onion rings a couple days ago.

They're also pretty straightforward to do. One simply dips rings of raw onion into a thin –what could be called pancake– batter, coats that with breadcrumbs and then deep-fries.

    Ingredients
  • 1 large onions (preferrably the "sweet" variety), cut into ~1 cm rings
  • 1-2 cups dry breadcrumbs –just blitz up whatever leftover bread you have around
  • 1 quart deep-frying fat, such as peanut oil, lard, etc.
  • seasoned salt (recipe provided below)
  • Batter Ingredients
  • 1 cup flour
  • 1 teaspoon baking powder
  • 1 teaspoon salt
  • 1 large egg
  • 1.5 cups milk
    Directions
  1. Whisk together the egg and milk, in a bowl.
  2. In a larger bowl, combine the flour, salt and baking powder.
  3. Dredge the raw onion rings in this flour, salt and baking powder mixture, tap away the excess, and set the rings aside.
  4. Add the eggy-milk to the dry ingredients and bring it together into a thin batter –it should drip fairly quickly off a fork. If it's too thin add more flour and if too thick add some more milk.
  5. Arrange the breadcrumbs in a large shallow dish (e.g. a baking sheet).
  6. Dip and lightly coat each onion ring in the batter and then gently toss in the breadcrumbs.
  7. Next, heat your fat/oil in a deep saucepan over medium heat until (if you have a fat thermometer, it's ~325 F/~160 C) or it begins to be visibly moving (I've deep-fried so many times I can tell by looking). Alternatively: use a deep-fryer.
  8. Fry the onion rings in batches until golden brown (~2-3 minutes).
  9. Season with the seasoned salt, if using, and serve hot. Enjoy. :)
Seasoned Salt

For me (and for onion rings) I like to make and use a seasoned salt with the following.

  • 3 tablespoons salt
  • 2 tablespoons chili powder
  • 1 tablespoon celery seed
  • 1 tablespoon paprika
  • 1 tablespoon garlic powder
  • 1 tablespoon onion powder
  • 1 tablespoon ground black pepper
  • 1 tablespoon ground cayenne pepper (optional)

You can vary the spice proportions to your tastes or use entirely different spices altogether. Really, what you decide to flavour salt with is up to you.

Paul Tagliamonte: Pygments 1.6

Sat, 2014-03-15 23:24

As of Pygments 1.7, there’s support for Hy!

http://pygments.org/docs/lexers/

Please report any bugs you find! This is great!

David Murphy: How GitHub communicates

Fri, 2014-03-14 21:23

Zach Holman writes about how GitHub communicates:

here’s a look at most of the communication that happened at GitHub on one random recent day: February 4, 2014

The expected methods are all there: chat (Campfire in their case), email, and – of course - GitHub itself.

One thing that piqued my interest was their internal-only social network “Team” which seems very reminiscent of how Automattic use WordPress & P2. Since I learned how Automattic use P2, I’ve been wondering if we could do something similar at Canonical. Perhaps we could use Google+  for this as we already use it for internal HangoutsUbuntu Developer Summit, and to power Ubuntu On-Air. There are ways to limit Google+ communities to members of your Google Apps domain.

(Side note: I hate having two Google+ accounts!)

I really need to finish coalescing my thoughts and put them into their own post…

The other point I noted was that their use of email was both minimal and individual – Team and GitHub itself are their primary ways of disseminating information.

It always interesting to see how others do achieve similar goals to yourself.

The post How GitHub communicates appeared first on David Murphy.

David Murphy: How GitHub communicates

Fri, 2014-03-14 21:13

Zach Holman writes about how GitHub communicates:

here’s a look at most of the communication that happened at GitHub on one random recent day: February 4, 2014

The expected methods are all there: chat (Campfire in their case), email, and – of course – GitHub itself.

One thing that piqued my interest was their internal-only social network “Team” which seems very reminiscent of how Automattic use WordPress & P2. Since I learned how Automattic use P2, I’ve been wondering if we could do something similar at Canonical. Perhaps we could use Google+  for this as we already use it for internal Hangouts, Ubuntu Developer Summit, and to power Ubuntu On-Air. There are ways to limit Google+ communities to members of your Google Apps domain.

(Side note: I hate having two Google+ accounts!)

I really need to finish coalescing my thoughts and put them into their own post…

The other point I noted was that their use of email was both minimal and individual – Team and GitHub itself are their primary ways of disseminating information.

It always interesting to see how others do achieve similar goals to yourself.

The post How GitHub communicates appeared first on David Murphy.

Pages