Feed aggregator

Pasi Lallinaho: Preparing responsive design for Xubuntu

Planet Ubuntu - Tue, 11/25/2014 - 07:49

As some of you might know, I was appointed as the Xubuntu website lead after taking a 6-month break from leadership in Xubuntu.

Since this position was passed on from Lyz (who is by the way doing fantastic job as our marketing lead!), I wouldn’t have wanted to be nominated unless I could actually bring something to the table. Thus, the xubuntu-v-website blueprint lists all the new (and old) projects that I am driving to finish during the Vivid cycle.

Now, please let me briefly introduce you to the field which I’m currently improving…

Responsive design!

In the past days, I have been preparing responsive stylesheets for the Xubuntu website. While Xubuntu isn’t exactly targeted at any device that itself would have a great need for fully responsive design, we do think that it is important to be available for users browsing with those devices as well.

Currently, we have four stylesheets in addition to the regular ones. Two of these are actually useful even for people without small-resolution screens; they improve the user experience for situations when the browser viewport is simply limited.

In the first phase of building the responsive design, I have had three main goals. Maybe the most important aspect is to avoid horizontal scrolling. Accomplishing this already improves the browsing experience a lot especially on small screens. The two other goals are to make some of the typography adjust better to small resolutions while keeping it readable and keeping links, especially internal navigation, easily accessible by expanding their clickable area.

At this point, I’ve pretty much accomplished the first goal, but still have work to do with the other two. There are also some other visual aspects that I would like to improve before going public, but ultimately, they aren’t release-critical changes and can wait for later.

For now, the new stylesheets are only used in the staging site. Once we release them for the wider public, or if we feel like we need some broader beta testing, we will reach for people with mobile (and other small-resolution) devices on the Xubuntu development mailing list for testing.

If you can’t wait to have a preview and are willing to help testing, show up on our development IRC channel #xubuntu-devel on Freenode and introduce yourself. I’ll make sure to get a hold of you sooner than later.

What about Xubuntu documentation?

The Xubuntu documentation main branch has responsive design stylesheets applied already. This change have yet to make it to any release (including the development version), but will land at least in Vivid soon enough.

Once I have prepared the responsive stylesheets for the Xubuntu online documentation frontpage, I will coordinate an effort to get the online documentation to use the responsive design as soon as possible. Expect some email about this on the development mailing list as well.

While we are at it… Paperspace

On a similar note… Last night I released the responsive design that I had been preparing for quite some time for Paperspace, or in other words, the WordPress theme for this blog (and the other blogs in this domain). That said, if you see anything that looks off in any browser resolution below 1200 pixels wide, be in touch. Thank you!

Dustin Kirkland: Try These 7 Tips in Your Next Blog Post

Planet Ubuntu - Tue, 11/25/2014 - 07:17

In a presentation to my colleagues last week, I shared a few tips I've learned over the past 8 years, maintaining a reasonably active and read blog.  I'm delighted to share these with you now!1. Keep it short and sweet
Too often, we spend hours or days working on a blog post, trying to create an epic tome.  I have dozens of draft posts I'll never finish, as they're just too ambitious, and I should really break them down into shorter, more manageable articles.

Above, you can see Abraham Lincoln's Gettysburg Address, from November 19, 1863.  It's merely 3 paragraphs, 10 sentences, and less than 300 words.  And yet it's one of the most powerful messages ever delivered in American history.  Lincoln wrote it himself on the train to Gettysburg, and delivered it as a speech in less than 2 minutes.
2. Use memorable imagery
Particularly, you need one striking image at the top of your post.  This is what most automatic syndicates or social media platforms will pick up and share, and will make the first impression on phones and tablets.
3. Pen a catchy, pithy title
More people will see or read your title than the post itself.  It's sort of like the chorus to that song you know, but you don't know the rest of the lyrics.  A good title attracts readers and invites re-shares.
4. Publish midweek
This is probably more applicable for professional, rather than hobbyist, topics, but the data I have on my blog (1.7 million unique page views over 8 years), is that the majority of traffic lands on Tuesday, Wednesday, and Thursday.  While I'm writing this very post on a rainy Saturday morning over a cup of coffee, I've scheduled it to publish at 8:17am (US Central time) on the following Tuesday morning.
5. Share to your social media circles
My posts are generally professional in nature, so I tend to share them on G+, Twitter, and LinkedIn.  Facebook is really more of a family-only thing for me, but you might choose to share your posts there too.  With the lamentable death of the Google Reader a few years ago, it's more important than ever to share links to posts on your social media platforms.
6. Hope for syndication, but never expect itSo this is the one "tip" that's really out of your control.  If you ever wake up one morning to an overflowing inbox, congratulations -- your post just went "viral".  Unfortunately, this either "happens", or it "doesn't".  In fact, it almost always "doesn't" for most of us.
7. Engage with comments only when it makes sense
If you choose to use a blog platform that allows comments (and I do recommend you do), then be a little careful about when and how to engage in the comments.  You can easily find yourself overwhelmed with vitriol and controversy.  You might get a pat on the back or two.  More likely, though, you'll end up under a bridge getting pounded by a troll.  Rather than waste your time fighting a silly battle with someone who'll never admit defeat, start writing your next post.  I ignore trolls entirely.
A Case StudyAs a case study, I'll take as an example the most successful post I've written: Fingerprints are Usernames, Not Passwords, with nearly a million unique page views.

  1. The entire post is short and sweet, weighing in at under 500 words and about 20 sentences
  2. One iconic, remarkable image at the top
  3. A succinct, expressive title
  4. Published on Tuesday, October 1, 2013
  5. 1561 +1's on G+, 168 retweets on Twitter
  6. Shared on Reddit and HackerNews (twice)
  7. 434 comments, some not so nice
Cheers!Dustin

The Fridge: Ubuntu Weekly Newsletter Issue 392

Planet Ubuntu - Mon, 11/24/2014 - 22:33

Welcome to the Ubuntu Weekly Newsletter. This is issue #392 for the week November 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:

  • Paul White
  • Elizabeth K. Joseph
  • Jose Antonio Rey
  • 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

The Fridge: Ubuntu Weekly Newsletter Issue 393

Planet Ubuntu - Mon, 11/24/2014 - 22:33

Ubuntu Weekly Newsletter Issue 393

The Fridge - Mon, 11/24/2014 - 22:33

Stephen Michael Kellat: Verifying Verification

Planet Ubuntu - Mon, 11/24/2014 - 17:00

Please remember that this is written by myself alone. Any reference to "we" below either refers to the five human beings that currently comprise the LoCo Council that I am part of or to the Ubuntu Realm in general. I apologize for any difficulties or consternation caused.

From the perspective of a community team, it can seem daunting when a "case management" bug is imposed relative to Verification or Re-Verification of a team. Many people wonder what that may mean. It might seem like a lot of work. It truly isn't.

In the Verification process, LoCo Council is checking to see if a community team has taken care of setting up some bare minimums. There is a basic expectation of some baseline things that all community teams should possess. Those items include:

  • A "Point of Contact" is set as the team's owner on Launchpad and is reachable
  • Online resources including IRC channel, wiki page, website, e-mail list, Forum/Discourse section, and LoCo Team Portal entry are set up
  • Your team conforms to naming standards

Some things that are useful to mention in a write-up to the LoCo Council include but are not limited to:

  • Links to your social media presences
  • Do you have members of your community who are part of the Ubuntu Members set?
  • What is your roadmap for the future?
  • What brought you to this point?

This doesn't have to be a magnum opus of literary works. An application for this does not even need copious pictures. Just the facts so that members of the Council can look at a glance to review where your community stands. From there we end up asking what your community's needs are and how the Council might assist you. If you've taken over three hours to put together the application, you may have possibly put too much effort into it. It is meant to be a quick process instead of a major high-stakes presentation.

We have only a fraction of community teams checked out to show that they in fact have baseline items set up. We could increase that in this cycle to be much better. There is a page on the wiki with links to a template for building your teams own application. If your team isn't currently verified, you can write to the Council at loco-council@lists.ubuntu.com to set up a time and date when the Council can consider such.

Jono Bacon: Ubuntu Governance Reboot: Five Proposals

Planet Ubuntu - Mon, 11/24/2014 - 15:35

Sorry, this is long, but hang in there.

A little while back I wrote a blog post that seemed to inspire some people and ruffle the feathers of some others. It was designed as a conversation-starter for how we can re-energize leadership in Ubuntu.

When I kicked off the blog post, Elizabeth quite rightly gave me a bit of a kick in the spuds about not providing a place to have a discussion, so I amended the blog post to a link to this thread where I encourage your feedback and participation.

Rather unsurprisingly, there was some good feedback, before much of it started wandering off the point a little bit.

I was delighted to see that Laura posted that a Community Council meeting on the 4th Dec at 5pm UTC has been set up to further discuss the topic. Thanks, CC, for taking the time to evaluate and discuss the topic in-hand.

I plan on joining the meeting, but I wanted to post five proposed recommendations that we can think about. Again, please feel free to share feedback about these ideas on the mailing list

1. Create our Governance Mission/Charter

I spent a bit of time trying to find the charter or mission statements for the Community Council and Technical Board and I couldn’t find anything. I suspect they are not formally documented as they were put together back in the early days, but other sub-councils have crisp charters (mostly based off the first sub-council, the Forum Council).

I think it could be interesting to define a crisp mission statement for Ubuntu governance. What is our governance here to do? What are the primary areas of opportunity? What are the priorities? What are the risks we want to avoid? Do we need both a CC and TB?

We already have the answers to some of these questions, but are the answers we have the right ones? Is there an opportunity to adjust our goals with our leadership and governance in the project?

Like many of the best mission statements, this should be a collaborative process. Not a mission defined by a single person or group, but an opportunity for multiple people to feed into so it feels like a shared mission. I would recommend that this be a process that all Ubuntu members can play a role in. Ubuntu members have earned their seat at the table via their contributions, and would be a wonderfully diverse group to pull ideas from.

This would give us a mission that feels shared, and feels representative of our community and culture. It would feel current and relevant, and help guide our governance and wider project forward.

2. Create an ‘Impact Constitution’

OK, I just made that term up, and yes, it sounds a bit buzzwordy, but let me explain.

The guiding principles in Ubuntu are the Ubuntu Promise. It puts in place a set of commitments that ensure Ubuntu always remains a collaborative Open Source project.

What we are missing though is a document that outlines the impact that Ubuntu gives you, others, and the wider world…the ways in which Ubuntu empowers us all to succeed, to create opportunity in our own lives and the life of others.

As an example:

Ubuntu is a Free Software platform and community. Our project is designed to create open technology that empowers individuals, groups, businesses, charities, and others. Ubuntu breaks down the digital divide, and brings together our collective energy into a system that is useful, practical, simple, and accessible.

Ubuntu empowers you to:

  1. Deploy an entirely free Operating System and archive of software to one of multiple computers in homes, offices, classrooms, government institutions, charities, and elsewhere.
  2. Learn a variety of programming and development languages and have the tools to design, create, test, and deploy software across desktops, phones, tablets, the cloud, the web, embedded devices and more.
  3. Have the tools for artistic creativity and expression in music, video, graphics, writing, and more.
  4. . . .

Imagine if we had a document with 20 or so of these impact statements that crisply show the power of our collective work. I think this will regularly remind us of the value of Ubuntu and provide a set of benefits that we as a wider community will seek to protect and improve.

I would then suggest that part of the governance charter of Ubuntu is that our leadership are there to inspire, empower, and protect the ‘impact constitution'; this then directly connects our governance and leadership to what we consider to be the primary practical impact of Ubuntu in making the world a better place.

3. Cross-Governance Strategic Meetings

Today we have CC meetings, TB meetings, FC meetings etc. I think it would be useful to have a monthly, or even quarterly meeting that brings together key representatives from each of the governance boards with a single specific goal – how do the different boards help further each other’s mission. As an example, how does the CC empower the TB for success? How does the TB empower the FC for success?

We don’t want governance that is either independent or dependent at the individual board level. We want governance that is inter-dependent with each other. This then creates a more connected network of leadership.

4. Annual In-Person Governance Summit

We have a community donations fund. I believe we should utilize it to get together key representatives across Ubuntu governance into the same room for two or three days to discuss (a) how to refine and optimize process, but also (b) how to further the impact of our ‘impact constitution’ and inspire wider opportunity in Ubuntu.

If Canonical could chip in and potentially there were a few sponsors, we could potentially bring all governance representatives together.

Now, it could be tempting to suggest we do this online. I think this would be a mistake. We want to get our leaders together to work together, socialize together, and bond together. The benefits of doing this in person significantly outweigh doing it online.

5. Optimize our community brand around “innovation”

Ubuntu has a good reputation for innovation. Desktop, Mobile, Tablet, Cloud…it is all systems go. Much of this innovation though is seen in the community as something that Canonical fosters and drives. There was a sentiment in the discussion after my last blog post that some folks feel that Canonical is in the driving seat of Ubuntu these days and there isn’t much the community can do to inspire and innovate. There was at times a jaded feeling that Canonical is standing in the way of our community doing great things.

I think this is a bit of an excuse. Yes, Canonical are primarily driving some key pieces…Unity, Mir, Juju for example…but there is nothing stopping anyone innovating in Ubuntu. Our archives are open, we have a multitude of toolsets people can use, we have extensive collaborative infrastructure, and an awesome community. Our flavors are a wonderful example of much of this innovation that is going on. There is significantly more in Ubuntu that is open than restricted.

As such, I think it could be useful to focus on this in our outgoing Ubuntu messaging and advocacy. As our ‘impact constitution’ could show, Ubuntu is a hotbed of innovation, and we could create some materials, messaging, taglines, imagery, videos, and more that inspires people to join a community that is doing cool new stuff.

This could be a great opportunity for designers and artists to participate, and I am sure the Canonical design team would be happy to provide some input too.

Imagine a world in which we see a constant stream of social media, blog posts, videos and more all thematically orientated around how Ubuntu is where the innovators innovate.

Bonus: Network of Ubucons

OK, this is a small extra one I would like to throw in for good measure.

The in-person Ubuntu Developer Summits were a phenomenal experience for so many people, myself included. While the Ubuntu Online Summit is an excellent, well-organized online event, there is something to be said about in-person events.

I think there is a great opportunity for us to define two UbuCons that become the primary in-person events where people meet other Ubuntu folks. One would be focused on the US, and one of Europe, and if we could get more (such as an Asian event), that would be awesome.

These would be driven by the community for the community. Again, I am sure the donations fund could help with the running costs.

In fact, before I left Canonical, this is something I started working on with the always-excellent Richard Gaskin who puts on the UbuCon before SCALE in LA each year.

This would be more than a LoCo Team meeting. It would be a formal Ubuntu event before another conference that brings together speakers, panel sessions, and more. It would be where Ubuntu people to come to meet, share, learn, and socialize.

I think these events could be a tremendous boon for the community.

Well, that’s it. I hope this provided some food for thought for further discussion. I am keen to hear your thoughts on the mailing list!

Colin King: Measuring stalled instructions with perf stat

Planet Ubuntu - Mon, 11/24/2014 - 12:43
Recently I was playing around with CPU loading and was trying to estimate the number of compute operations being executed on my machine.  In particular, I was interested to see how many instructions per cycle and stall cycles I was hitting on the more demanding instructions.   Fortunately, perf stat allows one to get detailed processor statistics to measure this.

In my first test, I wanted to see how the Intel rdrand instruction performed with 2 CPUs loaded (each with a hyper-thread):

$ perf stat stress-ng --rdrand 4 -t 60 --times
stress-ng: info: [7762] dispatching hogs: 4 rdrand
stress-ng: info: [7762] successful run completed in 60.00s
stress-ng: info: [7762] for a 60.00s run time:
stress-ng: info: [7762] 240.01s available CPU time
stress-ng: info: [7762] 231.05s user time ( 96.27%)
stress-ng: info: [7762] 0.11s system time ( 0.05%)
stress-ng: info: [7762] 231.16s total time ( 96.31%)

Performance counter stats for 'stress-ng --rdrand 4 -t 60 --times':

231161.945062 task-clock (msec) # 3.852 CPUs utilized
18,450 context-switches # 0.080 K/sec
92 cpu-migrations # 0.000 K/sec
821 page-faults # 0.004 K/sec
667,745,260,420 cycles # 2.889 GHz
646,960,295,083 stalled-cycles-frontend # 96.89% frontend cycles idle
stalled-cycles-backend
13,702,533,103 instructions # 0.02 insns per cycle
# 47.21 stalled cycles per insn
6,549,840,185 branches # 28.334 M/sec
2,352,175 branch-misses # 0.04% of all branches

60.006455711 seconds time elapsed

stress-ng's rdrand test just performs a 64 bit rdrand read and loops on this until the data is ready, and performs this 32 times in an unrolled loop.  Perf stat shows that each rdrand + loop sequence on average consumes about 47 stall cycles showing that rdrand is probably just waiting for the PRNG block to produce random data.

My next experiment was to run the stress-ng ackermann stressor; this performs a lot of recursion, hence one should see a predominantly large amount of branching.

$ perf stat stress-ng --cpu 4 --cpu-method ackermann -t 60 --times
stress-ng: info: [7796] dispatching hogs: 4 cpu
stress-ng: info: [7796] successful run completed in 60.03s
stress-ng: info: [7796] for a 60.03s run time:
stress-ng: info: [7796] 240.12s available CPU time
stress-ng: info: [7796] 226.69s user time ( 94.41%)
stress-ng: info: [7796] 0.26s system time ( 0.11%)
stress-ng: info: [7796] 226.95s total time ( 94.52%)

Performance counter stats for 'stress-ng --cpu 4 --cpu-method ackermann -t 60 --times':

226928.278602 task-clock (msec) # 3.780 CPUs utilized
21,752 context-switches # 0.096 K/sec
127 cpu-migrations # 0.001 K/sec
927 page-faults # 0.004 K/sec
594,117,596,619 cycles # 2.618 GHz
298,809,437,018 stalled-cycles-frontend # 50.29% frontend cycles idle
stalled-cycles-backend
845,746,011,976 instructions # 1.42 insns per cycle
# 0.35 stalled cycles per insn
298,414,546,095 branches # 1315.017 M/sec
95,739,331 branch-misses # 0.03% of all branches

60.032115099 seconds time elapsed

..so about 35% of the time is used in branching and we're getting  about 1.42 instructions per cycle and no many stall cycles, so the code is most probably executing inside the instruction cache, which isn't surprising because the test is rather small.

My final experiment was to measure the stall cycles when performing complex long double floating point math operations, again with stress-ng.

$ perf stat stress-ng --cpu 4 --cpu-method clongdouble -t 60 --times
stress-ng: info: [7854] dispatching hogs: 4 cpu
stress-ng: info: [7854] successful run completed in 60.00s
stress-ng: info: [7854] for a 60.00s run time:
stress-ng: info: [7854] 240.00s available CPU time
stress-ng: info: [7854] 225.15s user time ( 93.81%)
stress-ng: info: [7854] 0.44s system time ( 0.18%)
stress-ng: info: [7854] 225.59s total time ( 93.99%)

Performance counter stats for 'stress-ng --cpu 4 --cpu-method clongdouble -t 60 --times':

225578.329426 task-clock (msec) # 3.757 CPUs utilized
38,443 context-switches # 0.170 K/sec
96 cpu-migrations # 0.000 K/sec
845 page-faults # 0.004 K/sec
651,620,307,394 cycles # 2.889 GHz
521,346,311,902 stalled-cycles-frontend # 80.01% frontend cycles idle
stalled-cycles-backend
17,079,721,567 instructions # 0.03 insns per cycle
# 30.52 stalled cycles per insn
2,903,757,437 branches # 12.873 M/sec
52,844,177 branch-misses # 1.82% of all branches

60.048819970 seconds time elapsed

The complex math operations take some time to complete, stalling on average over 35 cycles per op.  Instead of using 4 concurrent processes, I re-ran this using just the two CPUs and eliminating 2 of the hyperthreads.  This resulted in 25.4 stall cycles per instruction showing that hyperthreaded processes are stalling because of contention on the floating point units.

Perf stat is an incredibly useful tool for examining performance issues at a very low level.   It is simple to use and yet provides excellent stats to allow one to identify issues and fine tune performance critical code.  Well worth using.

Dustin Kirkland: USENIX LISA14 Talk: Deploy and Scale OpenStack

Planet Ubuntu - Mon, 11/24/2014 - 10:01

I had the great pleasure to deliver a 90 minute talk at the USENIX LISA14 conference, in Seattle, Washington.

During the course of the talk, we managed to:

  • Deploy OpenStack Juno across 6 physical nodes, on an Orange Box on stage
  • Explain all of the major components of OpenStack (Nova, Neutron, Swift, Cinder, Horizon, Keystone, Glance, Ceilometer, Heat, Trove, Sahara)
  • Explore the deployed OpenStack cloud's Horizon interface in depth
  • Configured Neutron networking with internal and external networks, as well as a gateway and a router
  • Setup our security groups to open ICMP and SSH ports
  • Upload an SSH keypair
  • Modify the flavor parameters
  • Update a bunch of quotas
  • Add multiple images to Glance
  • Launch some instances until we max out our hypervisor limits
  • Scale up the Nova Compute nodes from 3 units to 6 units
  • Deploy a real workload (Hadoop + Hive + Kibana + Elastic Search)
  • Then, we deleted the entire environment, and ran it all over again from scratch, non-stop
Slides and a full video are below.  Enjoy!




Cheers,Dustin

Didier Roche: Ubuntu Developer Tools needs you for its new name!

Planet Ubuntu - Mon, 11/24/2014 - 08:31

We’ve been talking about the Ubuntu Developer Tools Center for a few months now. We’ve seen a lot of people testing it out & contributing and we had a good session at the Ubuntu Online Summit about what the near future holds for UDTC.

Also during that session, emerging from feedback we received we talked about how “UDTC” and “Ubuntu Developer Tools Centre” is a bit of mouthfull, and the acronym is quite easy to muddle. We agreed that we needed a new name, and that’s where we need your help.

We’re looking for a name which succinctly describes what the Developer Tools Center is all about, its values and philosophy. Specifically, that we are about developing ON Ubuntu, not just FOR Ubuntu. That we strive to ensure that the tools made available via the tools center are always in line with latest version delivered by the upstream developers. That we automate the testing and validation of this, so developers can rely on us. And that use LTS releases as our environment of choice so developers have a solid foundation on which to build. In a nutshell, a name that conveys that we love developers!

If you have a great idea for a new name please let us know by commenting on the Google+ post or by commenting on this blog post.

The final winner will be chosen by a group of Ubuntu contributors but please +1 your favorite to help us come up with a shortlist. The winner will receive the great honor of an Ubuntu T Shirt and knowing that they have changed history! We’ll close this contest by Monday 8th of December.

Now, it’s all up to you! If you want to also contribute to other parts of this ubuntu loves developers effort, you’re more than welcome!

Daniel Holbach: I Am Who I Am Because Of Who We All Are

Planet Ubuntu - Mon, 11/24/2014 - 08:07

I read the “We Are Not Loco” post  a few days ago. I could understand that Randall wanted to further liberate his team in terms of creativity and everything else, but to me it looks feels the wrong approach.

The post makes a simple promise: do away with bureaucracy, rename the team to use a less ambiguous name, JFDI! and things are going to be a lot better. This sounds compelling. We all like simplicity; in a faster and more complicated world we all would like things to be simpler again.

What I can also agree with is the general sense of empowerment. If you’re member of a team somewhere or want to become part of one: go ahead and do awesome things – your team will appreciate your hard work and your ideas.

So what was it in the post that made me sad? It took me a while to find out what specifically it was. The feeling set in when I realised somebody turned their back on a world-wide community and said “all right, we’re doing our own thing – what we used to do together to us is just old baggage”.

Sure, it’s always easier not having to discuss things in a big team. Especially if you want to agree on something like a name or any other small detail this might take ages. On the other hand: the world-wide LoCo community has achieved a lot of fantastic things together: there are lots of coordinated events around the world, there’s the LoCo team portal, and most importantly, there’s a common understanding of what teams can do and we all draw inspiration from each other’s teams. By making this a global initiative we created numerous avenues where new contributors find like-minded individuals (who all live in different places on the globe, but share the same love for Ubuntu and organising local events and activities). Here we can learn from each other, experiment and find out together what the best practices for local community awesomeness are.

Going away and equating the global LoCo community with bureaucracy to me is desolidarisation – it’s quite the opposite of “I Am Who I Am Because Of Who We All Are”.

Personally I would have preferred a set of targeted discussions which try to fix processes, improve communication channels and inspire a new round leaders of Ubuntu LoCo teams. Not everything you do in a LoCo team has to be approved by the entire set of other teams, actual reality in the LoCo world is quite different from that.

If you have ideas to discuss or suggestions, feel free to join our loco-contacts mailing list and bring it up there! It’s your chance to hang out with a lot of fun people from around the globe.

Stephen Michael Kellat: Our Tools: MORE POWER

Planet Ubuntu - Sun, 11/23/2014 - 17:00

Once the blog post by Jono Bacon hit about seeking a reboot in community governance, multiple threads bloomed in several directions. Things have wandered away from the original topic of governance structures to hit more vague, more general issues. To an extent I metaphorically keep biting my tongue about saying much more in the thread.

I do know that I have put forward the notion that we attempt an export to EPUB format of the xubuntu-docs package documentation. This, in part, is to help potentially ease a threshold for access. With the e-reader devices that do exist you could access the documentation on a separate device to read while you sit at the computer. This is only meant as an exploratory experimental notion rather than a commitment to ship.

In light of the feedback complaining about how DocBook can be difficult to address, sometimes it can be appropriate to test some of its power and show it off. DocBook has quite a lot of power to it if you have the ability to leverage it. With the variety of ways it can be exported into other formats than just the HTML files we already see shipped in Xubuntu, we can test new ways of shipping.

To the outsider, many of the processes used in creation of the various flavors of Ubuntu may seem like they can be simplified as they seem unnecessarily complicated. In some cases, we have excess power and flexibility built in for future expansion. In the times between Long Term Support releases we may need to take the time to show those who wish to join the community the power of our toolsets and what we can do with them.

Dimitri John Ledkov: Analyzing public OpenPGP keys

Planet Ubuntu - Sun, 11/23/2014 - 14:15
OpenPGP Message Format (RFC 4880) well defines key structure and wire formats (openpgp packets). Thus when I looked for public key network (SKS) server setup, I quickly found pointers to dump files in said format for bootstrapping a key server.

I did not feel like experimenting with Python and instead opted for Go and found http://code.google.com/p/go.crypto/openpgp/packet library that has comprehensive support for parsing openpgp low level structures. I've downloaded the SKS dump, verified it's MD5SUM hashes (lolz), and went ahead to process them in Go.

With help from http://github.com/lib/pq and database/sql, I've written a small program to churn through all the dump files, filter for primary RSA keys (not subkeys) and inject them into a database table. The things that I have chosen to inject are fingerprint, N, E. N & E are the modulus of the RSA key pair and the public exponent. Together they form a public part of an RSA keypair. So far, nothing fancy.

Next I've run an SQL query to see how unique things are... and found 92 unique N & E pairs that have from two and up to fifteen duplicates. In total it is 231 unique fingerprints, which use key material with a known duplicate in the public key network. That didn't sound good. And also odd - given that over 940 000 other RSA keys managed to get unique enough entropy to pull out a unique key out of the keyspace haystack (which is humongously huge by the way).

Having the list of the keys, I've fetched them and they do not look like regular keys - their UIDs do not have names & emails, instead they look like something from the monkeysphere. The keys look like they are originally used for TLS and/or SSH authentication, but were converted into OpenPGP format and uploaded into the public key server. This reminded me of the Debian's SSL key generation vulnerability CVE-2008-0166. So these keys might have been generated with bad entropy due to affected tools by that CVE and later converted to OpenPGP.

Looking at the openssl-blacklist package, it should be relatively easy for me to generate all possible RSA key-pairs and I believe all other material that is hashed to generate the fingerprint are also available (RFC 4880#12.2). Thus it should be reasonably possible to generate matching private keys, generate revocation certificates and publish the revocation certificate with pointers to CVE-2008-0166. (Or email it to the people who have signed given monkeysphered keys). When I have a minute I will work on generating openpgp-blacklist type of scripts to address this.

If anyone is interested in the Go source code I've written to process openpgp packets, please drop me a line and I'll publish it on github or something.

Ovidiu-Florin Bogdan: Awesome BSP in München

Planet Ubuntu - Sun, 11/23/2014 - 11:10
An awesome BSP just took place in München where teams from Kubuntu, Kolab, KDE PIM, Debian and LibreOffice came and planned the future and fixed bugs. This is my second year participating at this BSP and I must say it was an awesome experience. I got to see again my colleagues from Kubuntu and got to […]

Sam Hewitt: Totally Not Weird Cheese Gel (Made with Science!)

Planet Ubuntu - Sun, 11/23/2014 - 11:00

A significant part of cooking is chemical science, but few people think of it in this way, but when combining cooking with what people consider stereotypical chemistry –using & mixing things with long technical names– you can have more fun.

Cheese as a Condiment

A typical method of adding cheese to things is simply to place grated cheese over a pile of food and melting it (in an oven usually). Now one of the problems (as I see it) with this, is that when you heat cheese it tends to split apart into milk solids and liquid milk fat, so you end up with unnecessary grease.

In my mind, the cheese-as-a-condiment is one of that is more smooth & creamy, such as that of a fondue, but your average "out-of-the-package" cheese does not melt this way. You can purchase one of several (disgusting) cheese products that gives you this effect, but it's more fun to make one yourself and you have the added benefit of knowing what goes into it.

Can be then used on nachos, for example:

Emulsification

One way to do this to use a chemical emulsifier to make the liquid fats –cheese– soluble in something that it is normally not soluble in –such as water. Essentially, something that's done frequently in a factory setting to help make many processed cheese products, spreads, dips, etc.

Now there are a tonne of food-safe chemical emulsifiers each with slightly different properties that you could use, but the one that I have a stock of, and that works particularly well with milk fats, like those in cheese, is sodium citrate –the salt of citric acid– which you can get from your friendly online distributor of science-y cooking products.

Many of these are also flavourless, or given the usually relatively small amount in food, the flavour that might be imparted is insignificant. They're essentially used for textural changes.

    Ingredients
  • 250 mL water*
  • 10 grams sodium citrate
  • 3-4 cups grated cheese –such as, cheddar**

*if you're feeling more experimentative, you can use a different (water-based) liquid for additional flavour, such as wine or an infusion

**you can use whichever cheeses you fancy, but I'd avoid processed cheeses as they may have additives that could mess up the chemisty

    Directions
  1. In a pot make a solution of 0.25g/mL sodium citrate in water –boil the water and dissolve the salt.
  2. Reduce the heat and begin to melt the cheese into the water handful at a time while whisking constantly.
  3. When all the cheese has melted keep stirring while the mixture thickens.
  4. Serve or use hot –keep it warm.

At the end of this what you'll essentially have is a "cheese gel" which will stiffen as it cools, but it can easily be reheated to regain its smooth consistency.

When you've completed the emulusion you can add other ingredients to jazz it up a bit –some dried spices or chopped jalapenos, for example– before pouring it over things or using it as a dip. Do note, if you're pouring it over nachos, it's best to have heated the chips first.

Another great use for your cheese gel is to pour it out, while hot, onto a baking sheet and let cool. Then you can cut it into squares for that perfect melt needed for the perfect cheeseburger.

Ubuntu Podcast from the UK LoCo: S07E34 – The One with Unagi

Planet Ubuntu - Sun, 11/23/2014 - 07:30

We’re back with Season Seven, Episode Thirty-four of the Ubuntu Podcast! Just Laura Cowen and Mark Johnson here again.

 Download OGG  Download MP3 Play in Popup

In this week’s show:

  • We discuss the Ind.ie crowdsourcing campaign.

  • We also discuss:

  • We share some Command Line Lurve (from ionagogo) which finds live streams on a page. It’s great for watching online feeds without Flash. Just point it at a web page and it finds all the streams. Run with “best” (or a specific stream type) and it launches your video player such as VLC: livestreamer
  • And we read your feedback. Thanks for sending it in!

We’ll be back next week, so please send your comments and suggestions to: podcast@ubuntu-uk.org
Join us on IRC in #uupc on Freenode
Leave a voicemail via phone: +44 (0) 203 298 1600, sip: podcast@sip.ubuntu-uk.org and skype: ubuntuukpodcast
Follow us on Twitter
Find our Facebook Fan Page
Follow us on Google+

Jonathan Riddell: Junior Job: Breeze Icon theme for LibreOffice

Planet Ubuntu - Sun, 11/23/2014 - 07:23

Here’s a nice project if you’re bored and wanting to help make a very visual difference to KDE, port the Breeze icon theme to LibreOffice.

Wiki page up at https://community.kde.org/KDE_Visual_Design_Group/LibreOffice_Breeze

All help welcome

Open, Save and PDF icons are breeze, all the rest still to go

 

by

Jonathan Riddell

Planet Ubuntu - Sun, 11/23/2014 - 05:11

New seasonal KDE marketing campaign.  Use Kubuntu to get off the naughty list.

 

by

Charles Profitt: Custom Wallpaper

Planet Ubuntu - Sat, 11/22/2014 - 21:34

I recently upgraded to Ubuntu 14.10 and wanted to adorn my desktop with some new wallpapers. Usually, I find several suitable wallpapers on the web, but this time I did not. I then decided to make my own and wanted to share the results. All the following wallpapers were put together using GIMP.

Plain Hex Template

Hex Template Two

Hex With Dwarf

Hex Dragon


Stephen Michael Kellat: Checking Links Post-Snow

Planet Ubuntu - Sat, 11/22/2014 - 17:00

There may have been a ton of snowfall in the Lake Erie shore region susceptible to "Lake Effect" over the past week. We have had some warming up.

Thankfully we haven't had infrastructure failures. There had been some fears of that. A week has come to a close and a new one is to begin.

Pages

Subscribe to Ubuntu Arizona LoCo Team aggregator