Canonical Voices

Posts tagged with 'ubuntu'

Daniel Holbach

Some of you might have noticed the Help app in the store, which has been around for a couple of weeks now. We are trying to make it friendlier and easier to use. Maybe you can comment and share your ideas/thoughts.

Apart from actual bugs and adding more and more useful content, we also wanted the app to look friendlier and be more intuitive and useful.

The latest trunk lp:help-app can be seen as version 0.3 in the store or if you run

bzr branch lp:help-app
less help-app/HACKING

you can run and check it out locally.

Here’s the design Daniel McGuire suggested going forward.

help-mockup

What are your thoughts? If you look at the content we currently have, how else would you expect the app to look like or work?

Thanks a lot Daniel for your work on this! :-)

Read more
Michael Hall

Ubuntu is sponsoring the South East Linux Fest this year in Charlotte North Carolina, and as part of that event we will have a room to use all day Friday, June 12, for an UbuCon. UbuCon is a mini-conference with presentations centered around Ubuntu the project and it’s community.

I’m recruiting speakers to fill the last three hour-long slots, if anybody is willing and able to attend the conference and wants to give a presentation to a room full of enthusiastic Ubuntu users, please email me at mhall119@ubuntu.com. Topic can be anything Ubuntu related, design, development, client, cloud, using it, community, etc.

Read more
Dustin Kirkland


In November of 2006, Canonical held an "all hands" event, which included a team building exercise.  Several teams recorded "Ubuntu commercials".

On one of the teams, Mark "Borat" Shuttleworth amusingly proffered,
"Ubuntu make wonderful things possible, for example, Linux appliance, with Ubuntu preinstalled, we call this -- the fridge!"


Nine years later, that tongue-in-cheek parody is no longer a joke.  It's a "cold" hard reality!

GE Appliances, FirstBuild, and Ubuntu announced a collaboration around a smart refrigerator, available today for $749, running Snappy Ubuntu Core on a Raspberry Pi 2, with multiple USB ports and available in-fridge accessories.  We had one in our booth at IoT World in San Francisco this week!










While the fridge prediction is indeed pretty amazing, the line that strikes me most is actually "Ubuntu make(s) wonderful things possible!"

With emphasis on "things".  As in, "Internet of Things."  The possibilities are absolutely endless in this brave new world of Snappy Ubuntu.  And that is indeed wonderful.

So what are you making with Ubuntu?!?

:-Dustin

Read more
Daniel Holbach

snappyIt’d be a bit of a stretch to call UOS Snappy Online Summit, but Snappy definitely was talk of the town this time around. It was also picked up by tech news sites, who not always depicted Ubuntu’s plans accurately. :-)

Anyway… if you missed some of the sessions, you can always go back, watch the videos of the sessions and check the notes. Here’s the links to the sessions which already happened:

Which leaves us with today, 7th May 2015! You can still join these sessions today – we’ll be glad to hear your input and ideas! :-)

  • 14:00 UTC: Ubuntu Core Brainstorm – Calling all Snappy pioneers
    Snappy and Ubuntu Core are still hot off the press, but it’s already clear that they’re going to bring a lot of opportunities and will make the lives of developers a lot easier. Let’s get together, brainstorm and find out where Snappy can be used in the future, which communities/tools/frameworks can be joined by it, which software should be ported to it and which crazy nice tutorials/demos can be easily put together. Anything goes, join us, no matter if on IRC or in the hangout!
  • 16:00 UTC: Snappy Q&A
    Everything you always wanted to know about Snappy and Ubuntu Core. Bring your questions here! Bring your friends as well. We’ll make sure to have all the relevant experts here.
  • 18:00 UTC: Replace ifupdown with networkd on snappy / cloud / server for 16.04
    What the title says. Networkers, we’ll need you here. :-)

The above are just my suggestions, obviously there’s loads of other good stuff on the schedule today! See you later!

Read more
Michael Hall

Ubuntu has been talking a lot about convergence lately, it’s something that we believe is going to be revolutionary and we want to be at the forefront of it. We love the idea of it, but so far we haven’t really had much experience with the reality of it.

image20150423_164034801I got my first taste of that reality two weeks ago, while at a work sprint in London. While Canonical has an office in London, it had other teams sprinting there, so the Desktop sprint I was at was instead held at a hotel. We planned to visit the office one day that week, it would be my first visit to any Canonical office, as well as my first time working at an actual office in several years. However, we also planned to meet up with the UK loco for release drinks that evening. This meant that we had to decide between leaving our laptops at the hotel, thus not having them to work on at the office, or taking them with us, but having to carry them around the pub all evening.

I chose to leave my laptop behind, but I did take my phone (Nexus 4 running Ubuntu) with me. After getting a quick tour of the office, I found a vacant seat at a desk, and pulled out my phone. Most of my day job can be done with the apps on my phone: I have email, I have a browser, I have a terminal with ssh, I can respond to our community everywhere they are active.

I spent the next couple of hours doing work, actual work, on my phone. The only problem I had was that I was doing it on a small screen, and I was burning through my battery. At one point I looked up and realized that the vacant desk I was sitting at was equipped with a laptop docking station. It had also a USB hub and an HDMI monitor cable available. If I had a slimport cable for my phone, I might have been able to plug it into this docking station and both power my phone and get a bigger screen to work with.

If I could have done that, I would have achieved the full reality of convergence, and it would have been just like if I had brought my laptop with me. Only with this I was able to simply slide it into my pocket when it was time to leave for drinks. It was tantalizingly close, I got a little taste of what it’s going to be like, and now I’m craving more of it.

Read more
Daniel Holbach

Not sure if you saw Marks’ blog post earlier, but I’ll make sure to be watching the keynote at http://ubuntuonair.com/ at 14:00 UTC today. :-)

Read more
Michael Hall

A couple of years ago the Ubuntu download page introduced a way for users to make a financial contribution to the ongoing development of Ubuntu and it’s surrounding projects and community. Later a program was established within Canonical to make the money donated specifically for supporting the community available directly to members of the community who would use it to benefit the wider project.

During the last month, at the request of members of the Ubuntu community and the Community Council, we have undertaken a review of the this program. While conducting a more thorough analysis of the what was donated to us and when, it was discovered that we made an error in our initial reporting, which has unfortunately affected the accuracy of all subsequent reports as well.

What Happened?

Our first report, published in May of 2014, combined the amounts donated to the community slider and the amounts dispersed to the community during the previous four financial quarters. In that report we listed the amount donated from April 2013 to June 2013 as being a total of $34,353.63. However, when looking over all of the quarterly donations going back to the start of the program, we realized that this amount actually covered donations made from April 2013 all the way to October 2013.

This means that the figure contains both the amount donated during that Apr-Jun quarter, as well as duplicating the amounts listed as being donated for the Jul-Sep quarter, and a part of the Oct-Dec quarter. The actual amount donated during just the Apr-Jun 2013 quarter was $15,726.72. As a result of this, and the fact that it affected the carry over balanced for all subsequent reports, I have gone back and corrected all of these to reflect the correct figures.

Now for the questions:

Where are the updated reports?

The reports have not moved, you can still access them from the previously published URLs, and they are also listed on a new Reports page on the community website. The original report data has been preserved in a copy which is linked to at the top of each revised report.

Where did the money go?

No money has been lost or taken away from the program, this change is only a correction to the actual state of things. We had originally over-stated the amount that was donated, due to an error when reading the raw donation data at the time the first report was written.

How could a mistake like this happen?

The information we get is a summary of a summary of the raw data. At some point in the process the wrong number was put in the wrong place. All of these reports are manually written and verified, which often catches errors such as this, but in the very first report this error was missed.

Are these numbers trustworthy?

I understand that a reduction in the balance number, in conjunction with questions being raised about the operation of the program, will lead some people to question the honesty of this change. But the fact remains that we were asked to investigate this, we did find a discrepant, and correcting it publicly is the right thing for us to do, regardless of how it may look.

Is the community funding program in trouble?

Absolutely not. Even with this correction there has been more money donated to the community slider than we have been able to use. There’s still a lot more good that can be done, if you think you have a good use for some of it please fill out a request.

Read more
Daniel Holbach

Next week we are going to have another Ubuntu Online Summit (5-7 May 2015). This is (among many other things) a great time for you to get involved with, learn about and help shape Ubuntu Snappy.

As I said in my last blog post I’m very impressed to see the general level of interest in Ubuntu Snappy given how new it is. It’ll be great to see who is joining the sessions and who is going to get involved.

For those of you who are new to it: Ubuntu Online Summit is an open event, where we’ll plan in hangouts and IRC the next Ubuntu release. You can

  • tune in
  • ask questions
  • bring up ideas
  • get to know the team
  • help out :-)

This is the preliminary schedule. Sessions might still move around a bit, but be sure to register for the event and subscribe to the blueprint/session – that way you are going to be notified of ongoing work and discussion.

Tuesday, 5th May 2015

Wednesday, 6th May 2015

Thursday, 7th May 2015

Please note that we are likely going to add more sessions, so you should definitely keep your eyes open and check the schedule every now and then.

I’m looking forward to seeing you all and seeing us shape what Snappy is going to be! See you next week!

Read more
Daniel Holbach

15.04 is out!

ubuntu.com

 

And another Ubuntu release went out the the door. I can’t believe that it’s the 22nd Ubuntu release already.

There’s a lot to be excited about in 15.04. The first phone powered by Ubuntu went out to customers and new devices are in the pipeline. The underpinnings of the various variants of Ubuntu are slowly converging, new Ubuntu flavours saw the light of day (MATE and Desktop next), new features landed, new apps added, more automated tests were added, etc. The future of Ubuntu is looking very bright.

What’s Ubuntu Core?

One thing I’m super happy about is a very very new addition: Ubuntu Core and snappy. What does it offer? It gives you a minimal Ubuntu system, automatic and bulletproof updates with rollback, an app store and very straight-forward enablement and packaging practices.

It has been brilliant to watch the snappy-devel@ and snappy-app-devel@ mailing lists in recent weeks and notice how much interest from enthusiasts, hobbyists, hardware manufacturers, porters and others get interested and get started. If you have a look at Dustin’s blog post, you get a good idea of what’s happening. It also features a video of Mark, who explains how Ubuntu has adapted to the demands of a changing IT world.

One fantastic example of how Ubuntu Snappy is already powering devices you had never thought of is the Erle-Copter. (If you can’t see the video, check out this link.)

It’s simply beautiful how product builders and hobbyists can now focus on what they’re interested in: building a tool, appliance, a robot, something crazy, something people will love or something which might change a small art of the world somewhere. What’s taken out of the equation by Ubuntu is: having to maintain a linux distro.

Maintaining a linux distro

Whenever I got a new device in my home I could SSH into, I was happy and proud. I always felt: “wow, they get it – they’re using open source software, they’re using linux”. This  feeling was replaced at some stage, when I realised how rarely my NAS or my router received system updates. When I checked for changelog entries of the updates I found out how only some of the important CVEs of the last year were mentioned, sometimes only “feature updates” were mentioned.

To me it’s clear that not all product builders or hardware companies collaborate with the NSA and create backdoors on purpose, but it’s hard work to maintain a linux stack and to do it responsibly.

That’s why I feel Ubuntu Core is an offering that “has legs” (as Mark Shuttleworth would say): as somebody who wants to focus on building a great product or solving a specific use case, you can do just that. You can ship your business logic in a snap on top of Ubuntu Core and be done with it. Brilliant!

What’s next?

Next week is Ubuntu Online Summit (5-7 May). There we are going to discuss the plans for the next time and that’s where you can get involved, ask questions, bring up your ideas and get to know the folks who are working on it now.

I’ll write a separate blog post in the coming days explaining what’s happening next week, until then feel free to have a look at:

 

Read more
David Planella

Ubuntu Online Summit
The 15.04 release frenzy over, but the next big event in the Ubuntu calendar is just around the corner. In about a week, from the 5th to 7th of May, the next edition of the Ubuntu Online Summit is taking off. Three days of sessions for developers, designers, advocates, users and all members of our diverse community.

Along the developer-oriented discussions you’ll find presentations, workshops, lightning talks and much more. It’s a great opportunity for existing and new members to get together and contribute to the talks, watch a workshop to learn something new, or ask your questions to many of the rockstars who make Ubuntu.

While the schedule is being finalized, here’s an overview (and preview) of the content that you should expect in each one of the tracks:

  • App & scope development: the SDK and developer platform roadmaps, phone core apps planning, developer workshops
  • Cloud: Ubuntu Core on clouds, Juju, Cloud DevOps discussions, charm tutorials, the Charm, OpenStack
  • Community: governance discussions, community event planning, Q+As, how to get involved in Ubuntu
  • Convergence: the road to convergence, the Ubuntu desktop roadmap, requirements and use cases to bring the desktop and phone together
  • Core: snappy Ubuntu Core, snappy post-vivid plans, snappy demos and Q+As
  • Show & Tell: presentations, demos, lightning talks (read: things that break and explode) on a varied range of topics

Joining the summit is easy, you’ll just need to follow the instructions and register for free to the Ubuntu Online Summit >

UOS highlights: back to the desktop, snappy and the road to convergence

This is going to be perhaps one of the most important summits in recent times. After a successful launch of the phone, followed by the exciting announcement and delivery of snappy Ubuntu Core, Ubuntu is entering a new era. An era of lean, secure, minimal and modular systems that can run on the cloud, on Internet-enabled devices, on the desktop and virtually anywhere.

While the focus on development in the last few cycles has been on shaping up and implementing the phone, this doesn’t mean other key parts of the project have been left out. The phone has helped create the platform and tools that will ultimately bring all these projects together, into a converged code base and user experience. From desktop to phone, to the cloud, to things, and back to the desktop.

The Ubuntu 15.10 cycle begins, and so does this exciting new era. The Ubuntu Online Summit will be a unique opportunity to pave the road to convergence and discuss how the next generation of the Ubuntu desktop is built. So the desktop is back on the spotlight, and snappy will be taking the lead role in bringing Ubuntu for devices and desktop together. Expect a week of interesting discussions and of thinking out of the box to get there!

Participating in the Ubuntu Online Summit

Does this whet your appetite? Come and join us at the Summit, learn more and contribute to shaping the future of Ubuntu! There are different ways of taking part in the online event via video hangouts:

  • Participate or watch sessions – everyone is welcome to participate and join a discussion to provide input or offer contribution. If you prefer to take a rear seat, that’s fine too. You can either subscribe to sessions, watch them on your browser or directly join a live hangout. Just remember to register first and learn how to join a session.
  • Propose a session – do you want to take a more active role in contributing to Ubuntu? Do you have a topic you’d like to discuss, or an idea you’d like to implement? Then you’ll probably want to propose a session to make it happen. There is still a week for accepting proposals, so why don’t you go ahead and propose a session?

Looking forward to seeing you all at the Summit!

The post Announcing the next Ubuntu Online Summit appeared first on David Planella.

Read more
Ben Howard

I am pleased to announce initial Vagrant images [1, 2]. These images are bit-for-bit the same as the KVM images, but have a Cloud-init configuration that allows Snappy to work within the Vagrant workflow.

Vagrant enables a cross platform developer experience on MacOS, Windows or Linux [3].

Note: due to the way that Snappy works, shared file systems within Vagrant is not possible at this time. We are working on getting the shared file system support enabled, but it will take us a little bit to get going.

If you want to use Vagrant packaged in the Ubuntu archives, in a terminal run::

  • sudo apt-get -y install vagrant
  • cd <WORKSPACE>
  • vagrant init http://goo.gl/DO7a9W 
  • vagrant up
  • vagrant ssh
If you use Vagrant from [4] (i.e Windows, Mac or install the latest Vagrant) then you can run:
  • vagrant init ubuntu/ubuntu-15.04-snappy-core-edge-amd64
  • vagrant up
  • vagrant ssh

These images are a work in progress. If you encounter any issues, please report them to "snappy-devel@lists.ubuntu.com" or ping me (utlemming) on Launchpad.net

---

[1] http://cloud-images.ubuntu.com/snappy/15.04/core/edge/current/core-edge-amd64-vagrant.box
[2] https://atlas.hashicorp.com/ubuntu/boxes/ubuntu-15.04-snappy-core-edge-amd64
[3] https://docs.vagrantup.com/v2/why-vagrant/index.html
[4] https://www.vagrantup.com/downloads.html

Read more
Nicholas Skaggs

It's Show and Tell Time!

Err, show and tell?
Who remembers their first years of schooling? At least for me growing up in the US, those first years invovled an activity called 'Show and Tell'. We were instructed to bring something in from home and talk about it. This could be a picture or souvenir from a trip or unique life event, something we made, another person who does interesting things, or just something we found really interesting. It was a way for us to learn more about each other in the classroom, as well as share cool things with each other.


Online Summit
Ok, snapping you back to reality, it's nearing time for UOS 15.05. UOS is the Ubuntu Online Summit we hold each cycle to talk about what's happening in ubuntu. UOS 15.05 will be on May 5th - May 7th.

So what does the childhood version of me reminiscing about show and tell have to do with UOS? Well, I'm glad you asked! There is a 'Show and Tell' track available to everyone as a platform for sharing interesting and unique things with the rest of the community. These sessions can be very short (5 or 10 minutes) and are a great way to share about your work within ubuntu.

With that in mind, it's a perfect opportunity for you to participate in 'Show and Tell' with the rest of the community. I encourage you to propose a session on the 'Show and Tell' track. This track exists for things like demos, quick talks, and 'show and tell' type things. It's perfect to spend 5 or 10 minutes talking about something you made or work on. Or perhaps something you find interesting. Or just a way to share a little about the team you work with or a project you've done. For those of you who may have been a part of the 'lightning talks' during the days of the physical UDS, anything that would have been considered a lightning talk is more than welcome in this track.

Cool, where do I signup?
Proposing a session is simple to do, and there's even a webpage to help! If you really get stuck, feel free to contact me, Svetlana Belkin, Marco Ceppi, or Allan Lesage who are your friendly track leads for this track. Once it's proposed the session will be assigned a date and time. Myself or another track lead will follow-up with you before UOS to ensure you are ready and the date and time is suitable for you.

Is there another way to participate?
Yes! Remember to checkout the show and tell sessions and participate by asking questions and enjoying the presentations. I guarantee you will learn something new. Maybe even useful!


Thanks for helping make UOS a success. I'll see you there!


Read more
Shuduo

日期:2015-04-14 作者:新闻更新 出处:IT.com.cn(IT世界网)

近日,Canonical与中国移动联合发起的“Ubuntu开发者创新大赛”正在各大高校如火如荼的展开,公开征集优秀适配Ubuntu操作系统的Scope、应用等作品。其中,优麒麟作为本次大赛的开发平台,为开发者提供了开放的、便捷的桌面操作系统,该系统易于开发者使用,开发者可以将更多的精力投入到创新作品的开发中。


中国移动&Ubuntu开发者创新大赛

本次赛事活动将使国内开发者接触到Ubuntu所带来的新一代移动体验。这将打破自第一款iPhone以来所形成的对于应用为王的固定模式,也将突破屏幕上惟有应用图标排列组成的单一视觉效果和使用上的局限。Ubuntu系统实现了内容和服务的前置,可直接呈现于屏幕上,从而有效的为用户创造一个丰富、快速且不碎片化的体验。而开发者只需花费相对于传统应用开发和维护而言很小的成本,便可在系统级别上创造出与应用同样的用户体验。这些独特体验是通过使用Ubuntu Scopes来完成的,它是Ubuntu独有的全新UI工具,可通过Ubuntu SDK获取。想了解更多Ubuntu Scopes和Ubuntu手机的信息,可访问Ubuntu官网。

赛事面向学生群体、职业开发者和开源社区,共设置6个奖项,奖励包括7万人民币现金和手机等奖品,并为学生组的获奖参赛者提供Canonical实习机会。报名截止时间为2015年5月15日,2015年6月进行决赛评选。开发者可访问“和你圆梦”百万青年创业就业计划官网报名参赛,

据悉,本次大赛的参赛开发者大都在使用优麒麟Ubuntu Kylin做Ubuntu手机开发的操作系统,作为一个中文化本地化的Ubuntu分支优麒麟,让国内开发者可以更轻松的使用Ubuntu手机的SDK来进行开发。

为了让国内业界开发者以及校内学生,更快更好的了解Ubuntu手机平台和开发技术,Canonical公司已在全国校内外场所举办多场落地培训互动。由知名专家高级工程师带队,为国内开发者个人团体从平台介绍到实际上手开发详尽讲解,并在现场手把手教大家如何开发Scope。同时,他们还为广大的开发者朋友准备了一定数量的优麒麟Ubuntu Kylin启动盘,内含Ubuntu SDK,以及一整套的培训教程资料,为开发者们提供了全面的技术支持。

开发者使用优麒麟平台进行Ubuntu手机应开发,可以轻松实现自己的创新想法、潮流创意等,让青年开发者率先接触到了新兴的移动生态系统,在获得崭新的创业机遇同时助力TD 产业蓬勃发展。日前,Ubuntu开发者创新大赛线上线下的技术培训活动已经在北京邮电、中科大、长沙中南大学、中山大学等高校展开。后续培训安排日程可通过关注Ubuntu微信账号(UbuntuByCanonical)获得。

Read more
Shuduo

2015-04-14 16:48 作者:www.guigu.org HV:87 来源:硅谷网 编辑:书明寒

  近日,记者了解到国产操作系统优麒麟正式发布了15.04 Beta 2测试版本,对重量级特色软件进行了升级,更好的方便用户体验,这款适合个人应用、大型企业和政府机构办公的操作系统在细节上的创新升级,提升了其品质和服务能力,获得了用户的认可,对于国内Linux操作系统的发展也起到了很好的示范作用。

  满足中国用户的使用习惯

  优麒麟设计之初就是为了做更有中国特色的操作系统,采用平台国际化与应用本地化融合的设计理念,通过定制本地化的桌面用户环境以及开发满足广大中文用户特定需求的应用软件来提供细腻的中文用户体验。

  记者从官方了解到,相对于14.10正式版,在细节上看到了更多创新,此次发布的测试版本累计修复了60多个Bug;更新了系统主题;系统内核升级到3.19,,能支持下一代英特尔Braswell芯片;用户桌面环境的改进包括默认打开“本地集成菜单”和启动器的“单击最小化”两个特性,更利于Windows熟练用户学习使用Unity用户界面。

  同时,新版本还升级了一些特色应用,软件中心、优客助手、优客农历等,其中优客助手2.0.1版本实现了全新的用户界面和操作方式,软件中心1.3.0版本增加了用户“完善翻译”和个人应用管理等功能。另外,开发团队与搜狗公司合作开发了搜狗输入法1.2版本,该版本已修复多个重要已知Bug,并支持细胞词库功能,当有最新更新时,已安装的用户可以自动更新。

  优麒麟获得用户认可

  绝大多数的开源软件在正式发布前会发布数版测试版本,然后会通过其技术社区不断后续完善,这也是开源软件正常的开发过程。这个版本应该是15.04正式版本之前最后发布的一个测试版本,接下来优麒麟开发团队将对系统关键组件、集成应用、中文化等进行更详细的测试以及Bug修复,这将为优麒麟推向市场奠定基础。

  去年,优麒麟系统进入了中央国家机关政府采购个人操作系统协议供货商名单。入围政府采购名单,意味着这款操作系统通过了国内最高层次的全面审核和认可,这对优麒麟来说是一个很好的发展机会。据悉,目前中央政府采购中心已经在安装试用优麒麟,而诸多部委和国家机构也正在评估试用安装优麒麟中。

  记者也从身边的朋友了解到,目前在国内很多的安卓手机开发工程师其实都是在使用优麒麟做安卓的开发,例如小米,盛大。“没有最好,只有更好”,优麒麟发布最新测试版本,就是为了更好的方便用户使用和体验,目前从下载数量看优麒麟正逐渐获得市场和消费者的认可。

Read more
David Planella

Nearly two years ago, the Ubuntu Community Donations Program was created as an extension to the donations page on ubuntu.com/download, where those individuals who download Ubuntu for free can choose to support the project financially with a voluntary contribution. In doing so, they can use a set of sliders to determine which parts of the project the amount they donate goes to (Ubuntu Desktop, Ubuntu for phone, Ubuntu for tablet, Ubuntu on public clouds, Cloud tools, Ubuntu Server with OpenStack, Community projects, Tip to Canonical).

While donations imply the trust from donors that Canonical is acting as a steward to manage their contributions, the feedback from the community back then was that the Community slider required a deeper level of attention in terms of management and transparency. With community being such an integral part of Ubuntu, and with the new opportunity to financially support new community projects, events or travel, it was just logical to ensure that the funds allocated to them were managed fairly and transparently, with public reporting every six months and a way for Ubuntu members to request funding.

Although the regular reports already provide a clear picture where the money donated for community projects is spent on, today I’d like to give an update on the bigger picture of the Community Donations Program and answer some questions community members have raised.

A successful two years

In a nutshell, we’re proud to say that the program continues to successfully achieve the goals it was set out for. Since its inception, it has given the ability to fund around 70,000 USD worth of community initiatives, conferences, travel and more. The money has always been allocated upon individual requests, the vast majority of which were accepted. Very few were declined, and when they were, we’ve always strived to provide good reasoning for the decision.

This process has given the opportunity to support a diverse set of teams and projects of the wide Ubuntu family, including flavours and sponsoring open source projects and conferences that have collaborated with Ubuntu over the years.

Program review and feedback

About two years into the Program, we felt a more thorough review was due: to assess how it has been working, to evaluate the community feedback and to decide if there are any adjustments required. Working with the Community Council on the review, we’ve also tried to address some questions from Ubuntu members that came in recently. Here is a summary of this review.

The feedback in general has been overwhelmingly positive. The Community Donations Program is not only seen as an initiative that hugely benefits the Ubuntu project, but also the figures and allocations on the reports and are a testament to this fact.

Criticism is also important to take, and when it has come, we’ve addressed it individually and updated the public policy or FAQ accordingly. Recently, it has arrived in two areas: the uncertainty in some cases where the exact cost is not known in advance (e.g. fluctuating travel costs from the date of the request until approval and booking) and the delay in actioning some of the requests. In the first case, we’ve updated the FAQ to reflect the fact that there is some flexibility allowed in the process to work with a reasonable estimate. In the second, we’ve tried to explain that while some requests are easy to approve and actioned in a matter of a few days (we review them all once a week), some others take longer due to several different factors: back and forth communication to clarify aspects of the requests, the amount of pending requests, and in some cases, the complexity of arranging the logistics. In general, we feel that it’s not unreasonable to expect sending a request at least a month in advance to what it is being planned to organize with the funds. We’re also making it clear that requests should be filled in advance as opposed to retroactively, so that community members do not end up in a difficult position should a request not be granted.

One of the questions that came in was regarding the flavour and upstream donation sliders. Originally, there were 3 community-related sliders on ubuntu.com/download: 1) Community participation in Ubuntu development, 2) Better coordination with Debian and upstreams, 3) Better support for flavours like Kubuntu, Xubuntu, Lubuntu. At some point during the 14.04 release sliders 2) and 3) were removed, leaving 1) as Community projects. Overall, this didn’t change the outcome of community allocations: since its beginning, the Community Donations Programme amounts have only come from the first slider, which is what the Canonical Community team are managing. From there, money is always allocated upon request fairly, not making a difference and benefiting Ubuntu, its flavours and upstreams equally.

All that said the lack of communication regarding the removal of the slider was something that was not intended and should have been communicated with the Community Team and the Community Council. It was a mistake for which we need to apologize. For any future changes in sliders that affect the community we will make sure that the Community Council is included in communications as an important stakeholder in the process.

Questions were also raised about the reporting on the community donations during the months in 2012/2013, between the donations page going live and the announcement of the Community Donations Program. As mentioned before, the Program was born out of the want to provide a higher level of transparency for the funds assigned to community projects. Up until then (and in the same way as they do today for the rest of the donation sliders) donors were trusting Canonical to manage the allocations fairly. Public reports were made retroactively only where it made sense (i.e. to align with fiscal quarters), but not going back all the way to the time before the start of the Program.

All in all, with these small adjustments we’re proud to say we’ll continue to support community projects with donations in the same way we’ve been doing these last two years.

And most especially, we’d like to say a big ‘thank you’ to everyone who has kindly donated and to everyone who has used the funds to help shaping the future of Ubuntu. You rock!

The post The Ubuntu Community Donations Program in review appeared first on David Planella.

Read more
bmichaelsen

Das ist alles nur geklaut und gestohlen,
nur gezogen und geraubt.
Entschuldigung, das hab ich mir erlaubt.
— die Prinzen, Alles nur geklaut

So, you might have noticed that there was no April Fools post from me this, year unlike previous years. One idea, I had was giving LibreOffice vi-key bindings — except that apparently already exists: vibreoffice. So I went looking for something else and found odpdown by Thorsten, who just started to work on LibreOffice fulltime again, and reading about it I always had the thought that it would be great to be able to run this right from your favourite editor: Vim.

And indeed: That is not hard to do. Here is a very raw video showing how to run presentations right out of vim:

Now, this is a quick hack, Linux only, requires you to have Python3 UNO-bindings installed etc. If you want to play with it: Clone the repo from github and get started. Kudos go out to Thorsten for the original odpdown on which this is piggybagging (“das ist alles nur geklaut”). So: Have fun with this — I will have to install vibreoffice now.


Read more
Barry Warsaw

Background

Snappy Ubuntu Core is a new edition of the Ubuntu you know and love, with some interesting new features, including atomic, transactional updates, and a much more lightweight application deployment story than traditional Debian/Ubuntu packaging.  Much of this work grew out of our development of a mobile/touch based version of Ubuntu for phones and tablets, but now Ubuntu Core is available for clouds and devices.

I find the transactional nature of upgrades to be very interesting.  While you still get a perfectly normal Ubuntu system, your root file system is read-only, so traditional apt-get based upgrades don't work.  Instead, your system version is image based; today you are running image 231 and tomorrow a new image is released to get you to 232.  When you upgrade to the new image, you get all the system changes.  We support both full and delta upgrades (the latter which reduces bandwidth), and even phased updates so that we can roll out new upgrades and quickly pull them from the server side if we notice a problem.  Snappy devices even support rolling back upgrades on a single device, by using a dual-partition root file system.  Phones generally don't support this due to lack of available space on the device.

Of course, the other part really interesting thing about Snappy is the lightweight, flexible approach to deploying applications.  I still remember my early days learning how to package software for Debian and Ubuntu, and now that I'm both an Ubuntu Core Developer and Debian Developer, I understand pretty well how to properly package things.  There's still plenty of black art involved, even for relatively easy upstream packages such as distutils/setuptools-based Python package available on the Cheeseshop (er, PyPI).  The Snappy approach on Ubuntu Core is much more lightweight and easy, and it doesn't require the magical approval of the archive elves, or the vagaries of PPAs, to make your applications quickly available to all your users.  There's even a robust online store for publishing your apps.

There's lots more about Snappy apps and Ubuntu Core that I won't cover here, so I encourage you to follow the links for more information.  You might also want to stop now and take the tour of Ubuntu Core (hey, I'm a poet and I didn't even realize it).

In this post, I want to talk about building and deploying snappy Python applications.  Python itself is not an officially supported development framework, but we have a secret weapon.  The system image client upgrader -- i.e. the component on the devices that checks for, verifies, downloads, and applies atomic updates -- is written in Python 3.  So the core system provides us with a full-featured Python 3 environment we can utilize.

The question that came to mind is this: given a command-line application available on PyPI, how easy is it to turn into a snap and install it on an Ubuntu Core system?  With some caveats I'll explore later, it's actually pretty easy!

Basic approach

The basic idea is this: let's take a package on PyPI, which may have additional dependencies also on PyPI, download them locally, and build them into a snap that we can install on an Ubuntu Core system.

The first question is, how do we build a local version of a fully-contained Python application?  My initial thought was to build a virtual environment using virtualenv or pyvenv, and then somehow turn that virtual environment into a snap.  This turns out to be difficult in practice because virtual environments aren't really designed for this.  They have issues with being relocated for example, and they can contain a lot of extraneous stuff that's great for development (virtual environment's actual purpose ) but unnecessary baggage for our use case.

My second thought involved turning a Python application into a single file executable, and from there it would be fairly easy to snappify.  Python has a long tradition of such tools, many with varying degrees of cross platform portability and standalone-ishness.  After looking again at some oldies but goodies (e.g. cx_freeze) and some new offerings, I decided to start with pex.

pex is a nice tool developed by Brian Wickman and the Twitter folks which they use to deploy Python applications to their production environment.  pex takes advantage of modern Python's support for zip imports, and a clever trick of zip files.

Python supports direct imports (of pure Python modules) from zip files, and the python executable's -m option works even when the module is inside a zip file.  Further, the presence of a __main__.py file within a package can be used as shorthand for executing the package, e.g. python -m myapp will run myapp/__main__.py if it exists.

Zip files are interesting because their index is at the end of the file.  This allows you to put whatever you want at the front of the file and it will still be considered a zip file.  pex exploits this by putting a shebang in the first line of the file, e.g. #!/usr/bin/python3 and thus the entire zip file becomes a single file executable of Python code.

There are of course, plenty of caveats.  Probably the main one is that Python cannot import extension modules directly from the zip, because the dlopen() function call only takes a file system path.  pex handles this by marking the resulting file as not zip safe, so the zip is written out to a temporary directory first.

The other issue of course, is that the zip file must contain all the dependencies not present in the base Python.  pex is actually fairly smart here, in that it will chase dependencies, much like pip and it will include those dependencies in the zip file.  You can also specify any missed dependencies explicitly on the pex command line.

Once we have the pex file, we need to add the required snappy metadata and configuration files, and run the snappy command to generate the .snap file, which can then be installed into Ubuntu Core.  Since we can extract almost all of the minimal required snappy metadata from the Python package metadata, we only need just a little input from the user, and the rest of work can be automated.

We're also going to avail ourselves of a convenient cheat.  Because Python 3 and its standard library are already part of Ubuntu Core on a snappy device, we don't need to worry about any of those dependencies.  We're only going to support Python 3, so we get its full stdlib for free.  If we needed access to Python 2, or any external libraries or add-ons that can't be made part of the zip file, we would need to create a snappy framework for that, and then utilize that framework for our snappy app.  That's outside the scope of this article though.

Requirements

To build Python snaps, you'll need to have a few things installed.  If you're using Ubuntu 15.04, just apt-get install the appropriate packages.  Otherwise, you can get any additional Python requirements by building a virtual environment and installing tools like pex and wheel into their, then invoking pex from that virtual environment.  But let's assume you have the Vivid Vervet (Ubuntu 15.04); here are the packages you need:
  •  python3
  •  python-pex-cli
  •  python3-wheel
  •  snappy-tools
  •  git
You'll also want a local git clone of https://gitlab.com/warsaw/pysnap.git which provides a convenient script called snap.py for automating the building of Python snaps.  We'll refer to this script extensively in the discussion below.

For extra credit, you might want to get a copy of Python 3.5 (unreleased as of this writing).  I'll show you how to do some interesting debugging with Python 3.5 later on.

From PyPI to snap in one easy step

Let's start with a simple example: world is a very simple script that can provide forward and reverse mappings of ISO 3166 two letter country codes (at least as of before ISO once again paywalled the database).  So if you get an email from guido@example.py you can find out where the BDFL has his secret lair:

$ world py
py originates from PARAGUAY

world is a pure-Python package with both a library and a command line interface. To get started with the snap.py script mentioned above, you need to create a minimal .ini file, such as:

[project]
name: world

[pex]
verbose: true

Let's call this file world.ini.  (In fact, you'll find this very file under the examples directory in the snap git repository.)  What do the various sections and variables control?
  •  name is the name of the project on PyPI.  It's used to look up metadata about the project on PyPI via PyPI's JSON API.
  •  verbose variable just defines whether to pass -v to the underlying pex command.
Now, to create the snap, just run:

$ ./snap.py examples/world.ini

You'll see a few progress messages and a warning which you can ignore.  Then out spits a file called world_3.1.1_all.snap.  Because this is pure Python, it's architecture independent.  That's a good thing because the snap will run on any device, such as a local amd64 kvm instance, or an ARM-based Ubuntu Core-compatible Lava Lamp.

Armed with this new snap, we can just install it on our device (in this case, a local kvm instance) and then run it:

$ snappy-remote --url=ssh://localhost:8022 install world_3.1.1_all.snap
$ ssh -p 8022 ubuntu@localhost
ubuntu@localhost:~$ world.world py
py originates from PARAGUAY

From git repository to snap in one easy step

Let's look at another example, this time using a stupid project that contains an extension module. This aptly named package just prints a yes for every -y argument, and no for every -n argument.

The difference here is that stupid isn't on PyPI; it's only available via git.  The snap.py helper is smart enough to know how to build snaps from git repositories.  Here's what the stupid.ini file looks like:

[project]
name: stupid
origin: git https://gitlab.com/warsaw/stupid.git

[pex]
verbose: yes

Notice that there's a [project]origin variable.  This just says that the origin of the package isn't PyPI, but instead a git repository, and then the public repo url is given.  The first word is just an arbitrary protocol tag; we could eventually extend this to handle other version control systems or origin types.  For now, only git is supported.

To build this snap:

$ ./snap.py examples/stupid.ini

This clones the repository into a temporary directory, builds the Python package into a wheel, and stores that wheel in a local directory.  pex has the ability to build its pex file from local wheels without hitting PyPI, which we use here.  Out spits a file called stupid_1.1a1_all.snap, which we can install in the kvm instance using the snappy-remote command as above, and then run it after ssh'ing in:

ubuntu@localhost:~$ stupid.stupid -ynnyn
yes
no
no
yes
no

Watch out though, because this snap is really not architecture-independent. It contains an extension module which is compiled on the host platform, so it is not portable to different architectures.  It works on my local kvm instance, but sadly not on my Lava Lamp.

Entry points

pex currently requires you to explicitly name the entry point of your Python application.  This is the function which serves as your main and it's what runs by default when the pex zip file is executed.

Usually, a Python package will define its entry point in its setup.py file, like so:

setup(
    ...
    entry_points={
        'console_scripts': ['stupid = stupid.__main__:main'],
        },
    ...
    )

And if you have a copy of the package, you can run a command to generate the various package metadata files:

$ python3 setup.py egg_info

If you look in the resulting stupid.egg_info/entry_points.txt file, you see the entry point clearly defined there.  Ideally, either pex or snap.py would just figure this out explicitly.  As it turns out, there's already a feature request open on pex for this, but in the meantime, how can we auto-detect the entry point?

For the stupid example, it's pretty easy.  Once we've cloned its git repository, we just run the egg_info command and read the entry_points.txt file.  Later, we can build the project's binary wheel from the same git clone.

It's a bit more problematic with world though because the package isn't downloaded from PyPI until pex runs, but the pex command line requires that you specify the entry point before the download occurs.

We can handle this by supporting an entry_point variable in the snap's .ini file.  For example, here's the world.ini file with an explicit entry point setting:

[project]
name: world
entry_point: worldlib.__main__:main

[pex]
verbose: true

What if we still wanted to auto-detect the entry point?  We could of course, download the world package in snap.py and run the egg-info command over that.  But pex also wants to download world and we don't want to have to download it twice.  Maybe we could download it in snap.py and then build a local wheel file for pex to consume.

As it turns out there's an easier way.

Unfortunately, package egg-info metadata is not availble on PyPI, although arguably it should be.  Fortunately, Vinay Sajip runs an external service that does make the metadata available, such as the metadata for world.

snap.py makes the entry_point variable optional, and if it's missing, it will grab the package metadata from a link like that given above.  An error will be thrown if the file can't be found, in which case, for now, you'd just add the [project]entry_point variable to the .ini file.

A little more snap.py detail

The snap.py script is more or less a pure convenience wrapper around several independent tools.  pex of course for creating the single executable zip file, but also the snappy command for building the .snap file.  It also utilizes python3 setup.py egg_info where possible to extract metadata and construct the snappy facade needed for the snappy build command.  Less typing for you!  In the case of a snap built from a git repository, it also performs the git cloning, and the python3 setup.py bdist_wheel command to create the wheel file that pex will consume.

There's one other important thing snap.py does: it fixes the resulting pex file's shebang line.  Because we're running these snaps on an Ubuntu Core system, we know that Python 3 will be available in /usr/bin/python3.  We want the pex file's shebang line to be exactly this.  While pex supports a --python option to specify the interpreter, it doesn't take the value literally.  Instead, it takes the last path component and passes it to /usr/bin/env so you end up with a shebang line like:

#!/usr/bin/env python3

That might work, but we don't want the pex file to be subject to the uncertainties of the $PATH environment variable.

One of the things that snap.py does is repack the pex file.  Remember, it's just a zip file with some magic at the top (that magic is the shebang), so we just read the file that pex spits out, and rewrite it with the shebang we want.  Eventually, pex itself will handle this and we won't need to do that anymore.

Debugging

While I was working out the code and techniques for this blog post, I ran into an interesting problem.  The world script would crash with some odd tracebacks.  I don't have the details anymore and they'd be superfluous, but suffice to say that the tracebacks really didn't help in figuring out the problem.  It would work in a local virtual environment build of world using either the (pip installed) PyPI package or run from the upstream git repository, but once the snap was installed in my kvm instance, it would traceback.  I didn't know if this was a bug in world, in the snap I built, or in the Ubuntu Core environment.  How could I figure that out?

Of course, the go to tool for debugging any Python problem is pdb.  I'll just assume you already know this.  If not, stop everything and go learn how to use the debugger.

Okay, but how was I going to get a pdb breakpoint into my snap?  This is where Python 3.5 comes in!

PEP 441, which has already been accepted and implemented in what will be Python 3.5, aims to improve support for zip applications.  Apropos this blog post, the new zipapp module can be used to zip up a directory into single executable file, with an argument to specify the shebang line, and a few other options.  It's related to what pex does, but without all the PyPI interactions and dependency chasing.  Here's how we can use it to debug a pex file.

Let's ignore snappy for the moment and just create a pex of the world application:

$ pex -r world -o world.pex -e worldlib.__main__:main
Now let's say we want to set a pdb breakpoint in the main() function so that we can debug the program, even when it's a single executable file.  We start by unzipping the pex:
$ mkdir world
$ cd world
$ unzip ../world.pex
If you poke around, you'll notice a __main__.py file in the current directory.  This is pex's own main entry point.  There are also two hidden directories, .bootstrap and .deps.  The former is more pex scaffolding, but inside the latter you'll see the unpacked wheel directories for world and its single dependency.

Drilling down a little farther, you'll see that inside the world wheel is the full source code for world itself.  Set a break point by visiting .deps/world-3.1.1-py2.py3-none-any.whl/worldlib/__main__.py in your editor.  Find the main() function and put this right after the def line:

import pdb; pdb.set_trace()

Save your changes and exit your editor.

At this point, you'll want to have Python 3.5 installed or available.  Let's assume that by the time you read this, Python 3.5 has been released and is the default Python 3 on your system.  If not, you can always download a pre-release of the source code, or just build Python 3.5 from its Mercurial repository.  I'll wait while you do this...

...and we're back!  Okay, now armed with Python 3.5, and still inside the world subdirectory you created above, just do this:

$ python3.5 -m zipapp . -p /usr/bin/python3 -o ../world.dbg

Now, before you can run ../world.dbg and watch the break point do its thing, you need to delete pex's own local cache, otherwise pex will execute the world dependency out of its cache, which won't have the break point set. This is a wart that might be worth reporting and fixing in pex itself.  For now:

$ rm -rf ~/.pex
$ ../world.dbg

And now you should be dropped into pdb almost immediately.

If you wanted to build this debugging pex into a snap, just use the snappy build command directly.  You'll need to add the minimal metadata yourself (since currently snap.py doesn't preserve it).  See the Snappy developer documentation for more details.

Summary and Caveats


There's a lot of interesting technology here; pex for building single file executables of Python applications, and Snappy Ubuntu Core for atomic, transactional system updates and lightweight application deployment to the cloud and things.  These allow you to get started doing some basic deployments of Python applications.  No doubt there are lots of loose ends to clean up, and caveats to be aware of.  Here are some known ones:

  • All of the above only works with Python 3.  I think that's a feature, but you might disagree. ;)   This works on Ubuntu Core for free because Python 3 is an essential piece of the base image.  Working out how to deploy Python 2 as a Snappy framework would be an interesting exercise.
  • When we build a snap from a git repository for an application that isn't on PyPI, I don't currently have a way to also grab some dependencies from PyPI.  The stupid example shown here doesn't have any additional dependencies so it wasn't a problem.  Fixing this should be a fairly simple matter of engineering on the snap.py wrapper (pull requests welcome!)
  • We don't really have a great story for cross-compilation of extension modules. Solving this is probably a fairly complex initiative involving the distros, setuptools and other packaging tools, and upstream Python.  For now, your best bet might be to actually build the snap on the actual target hardware.
  • Importing extension modules requires a file system cache because of limitations in the dlopen() API.  There have been rumors of extensions to glibc which would provide a dlopen()-from-memory type of API which could solve this, or upstream Python's zip support may want to grow native support for caching.
Even with these caveats, it's pretty easy to turn a Python application into a Snappy Ubuntu Core application, publish it to the world, and profit!  So what are you waiting for?  Snap to it!

Read more
Daniel Holbach

What does being an Ubuntu member mean to you? Why did you do it back then?

I became an Ubuntu member about 10 years ago. It was part of the process of becoming member of the MOTU team. Before you could apply for upload rights, you had to be an Ubuntu member though.

That wasn’t all of it though. For me it wasn’t the @ubuntu.com mail address or “fulfilling the requirements for upload rights”. As I had helped out and contributed for months already, I felt part of the tribe and luckily many encouraged me to take the next step and apply for membership. I had grown to like the people I worked with and learned from a lot. It was a bit daunting, but being recognised for my contributions was a great experience. Afterwards I would say I did my fair share of encouraging others to apply as well. :-)

Which brings me to the two calls of action I wanted to get out there.

1) Encourage members of your team who haven’t applied for Ubuntu membership!

There are so many people doing fantastic work on AskUbuntu, the Forums, in Flavour teams, the Docs team, the QA world and all over the place when it comes to phones, desktops, IoT bits, servers, the cloud and more. Many many of them should really be Ubuntu members, but they haven’t heard of it, or don’t know how or are concerned of not “having done enough”.

If you have people like that in a project you are working in, please do encourage them. In an open source project we should aim to do a good job at recognising the great work of others.

2) Join the Ubuntu Membership Boards!

If you are an Ubuntu member, seriously consider joining the Ubuntu Membership Boards. The call for nominations is still open and it’s a great thing to be involved with.

When I joined the Community Council, the CC was still in charge of approving Ubuntu members and I enjoyed the meeting (even if they were quite looooooooooooooooooooong), when we got to talk to many contributors from all parts of the globe and from all parts of the Ubuntu landscape. Welcoming many of them to Ubuntu members team was just beautiful.

Nominate yourself and be quick about it! :-)

Read more
Nicholas Skaggs


Whoosh, Spring is in the air, Winter is over (at least for us Northern Hemisphere folks). With that, it's time for polishing the final beta image for vivid.

How can I help? 
To help test, visit the iso tracker milestone page for final beta.  The goal is to verify the images in preparation for the release. Find those bugs! The information at the top of the page will help you if you need help reporting a bug or understanding how to test. 

Isotracker? 
There's a first time for everything! Check out the handy links on top of the isotracker page detailing how to perform an image test, as well as a little about how the qatracker itself works. If you still aren't sure or get stuck, feel free to contact the qa community or myself for help.

What if I'm late?
The testing runs through this Thursday March 26th, when the the images for final beta will be released. If you miss the deadline we still love getting results! Test against the daily image milestone instead.

Thanks and happy testing everyone!

Read more
Michael Hall

Way back at the dawn of the open source era, Richard Stallman wrote the Four Freedoms which defined what it meant for software to be free. These are:

  • Freedom 0: The freedom to run the program for any purpose.
  • Freedom 1: The freedom to study how the program works, and change it to make it do what you wish.
  • Freedom 2: The freedom to redistribute copies so you can help your neighbor.
  • Freedom 3: The freedom to improve the program, and release your improvements (and modified versions in general) to the public, so that the whole community benefits.

For nearly three decades now they have been the foundation for our movement, the motivation for many of us, and the guiding principle for the decisions we make about what software to use.

But outside of our little corner of humanity, these freedoms are not seen as particularly important. In fact, the fast majority of people are not only happy to use software that violates them, but will often prefer to do so. I don’t even feel the need to provide supporting evidence for this claim, as I’m sure all of you have been on one side or the other of a losing arguement about why using open source software is important.

The problem, it seems, is that people who don’t plan on exercising any of these freedoms, from lack of interest or lack of ability, don’t place the same value on them as those of us who do. That’s why software developers are more likely to prefer open source than non-developers, because they might actually use those freedoms at some point.

But the people who don’t see a personal value in free software are missing a larger, more important freedom. One implied by the first four, though not specifically stated. A fifth freedom if you will, which I define as:

  • Freedom 4: The freedom to have the program improved by a person or persons of your choosing, and make that improvement available back to you and to the public.

Because even though the vast majority of proprietary software users will never be interested in studying or changing the source of the software they use, they will likely all, at some point in time, ask someone else if they can fix it. Who among us hasn’t had a friend or relative ask us to fix their Windows computer? And the true answer is that, without having the four freedoms (and implied fifth), only Microsoft can truly “fix” their OS, the rest of us can only try and undo the damage that’s been done.

So the next time you’re trying to convince someone of the important of free and open software, and they chime in with the fact that don’t want to change it, try pointing out that by using proprietary code they’re limiting their options for getting it fixed when it inevitably breaks.

Read more