The Open Source movement has evolved into other areas of computering. Open Data, Open Hardware, and ,the topic that I want to talk about, Open Science, are three examples of this. Since I’m a biologist, I’m deeply connected to the science community but I want to also tie in my hobby of FOSS/Linux into my work. There are many non-coding (and coding) based things and groups that one can use for research and I want to talk about a few of them.
Mozilla, the creators of Firefox and Thunderbird, started a group last year that aims to help scientists, “to use the power of the open web to change the way science is done. [They] build educational resources, tools and prototypes for the research community to make science more open, collaborative and efficient.” (main page of Mozilla Science Lab).
Right now, they are are focusing on teaching scientists the basic skills in research via the Software Carpentry project. But I know that they are planning to get some projects for the community-building side for non-coders. I don’t know what those projects are but I know that they will be listed soon on the mailing-list of the group. For myself, I can’t wait until I get my hands on those projects to help them grow.
Another fairly new project within the last two years that was started by Center of Open Science that focuses on creating a framework that allows scientists to use the, “entire research lifecycle: planning, execution, reporting, archiving, and discovery”, (main page of OSF) fully and be able to share that with other people in there teams but thy could be in another place not near the head researcher.
I think this is one of the best tools out there because it allows you to upload things on the site and also from Dropbox and other services. I played around with it a bit but I have not fully used it, but when I do, I will write a post about it.
This is maybe one of the oldest projects that I think there is for Open Science and it’s Open Notebook Science. It’s the idea of have the lab notebook publicly available online. There is a small network of these.
I think, along with the OSF project, it is one of the best tools out there mainly because the data and other stuff is publicly available online for everyone to learn from your mistakes or to work with the data.
Hopefully as the time goes by, these projects will grow and researchers can collaborate better.
This little snippet of ~200 lines of YAML is the exact OpenStack that I'm deploying tonight, at the OpenStack Austin Meetup.
Anyone with a working Juju and MAAS setup, and 7 registered servers should be able to deploy this same OpenStack setup, in about 12 minutes, with a single command.
$ wget http://people.canonical.com/~kirkland/icehouseOB.yaml
$ juju-deployer -c icehouseOB.yaml
$ cat icehouseOB.yaml
to: [ceph=0, ceph=1, ceph=2]
- - "keystone:shared-db"
- - "nova-cloud-controller:shared-db"
- - "nova-cloud-controller:amqp"
- - "nova-cloud-controller:image-service"
- - "nova-cloud-controller:identity-service"
- - "glance:shared-db"
- - "glance:identity-service"
- - "cinder:shared-db"
- - "cinder:amqp"
- - "cinder:cinder-volume-service"
- - "cinder:identity-service"
- - "neutron-gateway:shared-db"
- - "neutron-gateway:amqp"
- - "neutron-gateway:quantum-network-service"
- - "openstack-dashboard:identity-service"
- - "nova-compute:shared-db"
- - "nova-compute:amqp"
- - "nova-compute:image-service"
- - "nova-compute:cloud-compute"
- - "cinder:storage-backend"
- - "ceph:client"
- - "ceph:client"
- - "ceph:client"
- - "ceilometer:identity-service"
- - "ceilometer:amqp"
- - "ceilometer:shared-db"
- - "ceilometer-agent:container"
- - "ceilometer-agent:ceilometer-service"
- - "heat:shared-db"
- - "heat:identity-service"
- - "heat:amqp"
- - "ceph-radosgw:mon"
- - "ceph-radosgw:identity-service"
- - "ntp:juju-info"
- - "ntp:juju-info"
- - "ntp:juju-info"
- - "ntp:juju-info"
- - "ntp:juju-info"
- - "ntp:juju-info"
- - "ntp:juju-info"
- - "ntp:juju-info"
- - "ntp:juju-info"
- - "ntp:juju-info"
- - "ntp:juju-info"
- - "ntp:juju-info"
- - "ntp:juju-info"
- - "ntp:juju-info"
The start of the jessie freeze is quickly approaching, so now is a good time to ensure that packages you rely on will the part of the upcoming release. Thanks to automated removals, the number of release critical bugs has been kept low, but this was achieved by removing many packages from jessie: 841 packages from unstable are not part of jessie, and won’t be part of the release if things don’t change.
It is actually simple to check if you have packages installed locally that are part of those 841 packages:
- apt-get install how-can-i-help (available in backports if you don’t use testing or unstable)
- how-can-i-help --old
- Look at packages listed under Packages removed from Debian ‘testing’ and Packages going to be removed from Debian ‘testing’
Then, please fix all the bugs :-) Seriously, not all RC bugs are hard to fix. A good starting point to understand why a package is not part of jessie is tracker.d.o.
On my laptop, the two packages that are not part of jessie are the geeqie image viewer (which looks likely to be fixed in time), and josm, the OpenStreetMap editor, due to three RC bugs. It seems much harder to fix… If you fix it in time for jessie, I’ll offer you a $drink!
Last week, we announced our "Ubuntu Loves Developers" effort! We got some great feedback and coverage. Multiple questions arose around how to help and be part of this effort. Here is the post to answer about thisOur philosophy
First, let's define the core principles around the Ubuntu Developer Tools Center and what we are trying to achieve with this:
- UDTC will always download, tests and support the latest available upstream developer stack. No version stuck in stone for 5 years, we get the latest and the best release that upstream delivers to all of us. We are conscious that being able to develop on a freshly updated environment is one of the core values of the developer audience and that's why we want to deliver that experience.
- We know that developers want stability overall and not have to upgrade or spend time maintaining their machine every 6 months. We agree they shouldn't have to and the platform should "get out of my way, I've got work to do". That's the reason why we focus heavily on the latest LTS release of Ubuntu. All tools will always be backported and supported on the latest Long Term Support release. Tests are running multiple times a day on this platform. In addition to this, we support, of course, the latest available Ubuntu Release for developers who likes to live on the edge!
- We want to ensure that the supported developer environment is always functional. Indeed, by always downloading latest version from upstream, the software stack can change its requirements, requiring newer or extra libraries and thus break. That's why we are running a whole suite of functional tests multiple times a day, on both version that you can find in distro and latest trunk. That way we know if:
- we broke ourself in trunk and needs to fix it before releasing.
- the platform broke one of the developer stack and we can promptly fix it.
- a third-party application or a website changed and broke the integration. We can then fix this really early on.
All those tests running will ensure the best experience we can deliver, while fetching always latest released version from upstream, and all this, on a very stable platform!Sounds cool, how can I help? Reports bugs and propose enhancements
The more direct way of reporting a bug or giving any suggestions is through the upstream bug tracker. Of course, you can always reach us out as well on social networks like g+, through the comments section of this blog, or on IRC: #ubuntu-desktop, on freenode. We are also starting to look at the #ubuntulovesdevs hashtag.
The tool is really to help developers, so do not hesitate to help us directing the Ubuntu Developer Tools Center on the way which is the best for you.Help translating
We already had some good translations contributions through launchpad! Thanks to all our translators, we got Basque, Chinese (Hong Kong), Chinese (Simplified), French, Italian and Spanish! There are only few strings up for translations in udtc and it should take less than half an hour in total to add a new one. It's a very good and useful way to contribute for people speaking other languages than English! We do look at them and merge them in the mainline automatically.Contribute on the code itself
Some people started to offer code contribution and that's a very good and motivating news. Do not hesitate to fork us on the upstream github repo. We'll ensure we keep up to date on all code contributions and pull requests. If you have any questions or for better coordination, open a bug to start the discussion around your awesome idea. We'll try to be around and guide you on how to add any framework support! You will not be alone!Write some documentation
We have some basic user documentation. If you feel there are any gaps or any missing news, feel free to edit the wiki page! You can as well merge some of the documentation of the README.md file or propose some enhancements to it!
To give an easy start to any developers who wants to hack on udtc iitself, we try to keep the README.md file readable and up to the current code content. However, this one can deviate a little bit, if you think that any part missing/explanation requires, you can propose any modifications to it to help future hackers having an easier start.Spread the word!
Finally, spreading the word that Ubuntu Loves Developers and we mean it! Talk about it on social network, tagging with #ubuntulovesdevs or in blog posts, or just chatting to your local community! We deeply care about our developer audience on the Ubuntu Desktop and Server and we want this to be known!
For more information and hopefully goodness, we'll have an ubuntu on air session session soon! We'll keep you posted on this blog when we have final dates details.
If you felt that I forgot to mention anything, do not hesitate to signal it as well, this is another form of very welcome contributions!
I'll discuss next week how we maintain and runs tests to ensure your developer tools are always working and supported!
When we setup Freexian’s offer to bring together funding from multiple companies in order to sponsor the work of multiple developers on Debian LTS, one of the rules that I imposed is that all paid contributors must provide a public monthly report of their paid work.
While the LTS project officially started in June, the first month where contributors were actually paid has been July. Freexian sponsored Thorsten Alteholz and Holger Levsen for 10.5 hours each in July and for 16.5 hours each in August. Here are their reports:
It’s worth noting that Freexian sponsored Holger’s work to fix the security tracker to support squeeze-lts. It’s my belief that using the money of our sponsors to make it easier for everybody to contribute to Debian LTS is money well spent.
As evidenced by the progress bar on Freexian’s offer page, we have not yet reached our minimal goal of funding the equivalent of a half-time position. And it shows in the results, the dla-needed.txt still shows around 30 open issues. This is slightly better than the state two months ago but we can improve a lot on the average time to push out a security update…
To have an idea of the relative importance of the contributions of the paid developers, I counted the number of uploads made by Thorsten and Holger since July: of 40 updates, they took care of 19 of them, so about the half.
I also looked at the other contributors: Raphaël Geissert stands out with 9 updates (I believe that he is contracted by Électricité de France for doing this) and most of the other contributors look like regular Debian maintainers taking care of their own packages (Paul Gevers with cacti, Christoph Berg with postgresql, Peter Palfrader with tor, Didier Raboud with cups, Kurt Roeckx with openssl, Balint Reczey with wireshark) except Matt Palmer and Luciano Bello who (likely) are benevolent members of the LTS team.
There are multiple things to learn here:
- Paid contributors already handle almost 70% of the updates. Counting only on volunteers would not have worked.
- Quite a few companies that promised help (and got mentioned in the press release) have not delivered the promised help yet (neither through Freexian nor directly).
Last but not least, this project wouldn’t exist without the support of multiple companies and organizations. Many thanks to them:
- Gold sponsors:
- Silver sponsors:
- Bronze sponsors:
Hopefully this list will expand over time! Any help to reach out to new companies and organizations is more than welcome.
While I’ve been off the grid I received an unusually high concentration of requests for a Qt5-based Grantlee. I’m working on getting that done for September.
I flew to Bilbao on the 11th of August and took a train to Burgos. From there I walked 500km over 21 days to arrive in Santiago. Although technically a Catholic pilgrimage, I approached it secularly as a walking holiday, a different environment while in-between jobs and some time for myself. Everyone walks their own Camino.First Insight: There is suffering
On arrival in Burgos, I needed to first get a ‘Credential’, which allows sleeping in the albergues for Peregrinos along the route, and records qualification to recieve a Compostela at the end of the journey. A credential may be obtained from the municipal albergue in Burgos so that was my first stop. It was almost 8pm when I arrived and the Hospitalero had been telling people since 4pm that the albergue was full. However, he kept a spare bed for such late arrivals and luckily he gave it to me. It made for a good start.
Stated in a deliberately impersonal way, the nature of suffering on the Camino was immediately apparent when I arrived in Burgos. For most people (with sufficient time), The Camino starts in St. Jean Pied de Port in France from where pilgrims walk over the Pyrenees, and through Pamplona before arriving in Burgos two weeks later. Colloqially, this first of three stages of the walk is known as the ‘Camino of Suffering’, where the pilgrim starts the challenge and experience. I spent the first evening with a few people who had developed the blisters and the tendonitis, people who were bidding farewell to the journey already (some people do it over multiple years), and people who were bidding farewell to companions.
In the morning I got up at 6am and started walking in the dark out of Burgos, following the centuries-old route along the second stage – the ‘Camino of Death’, so called because of the barren, flat landscape surroundings until reaching Astorga.
Initially I walked with one Italian guy and we soon caught up with two more Italians. Most of the time walking the Camino is spent walking alone though, so that little group quickly dissolved as people broke away or fell behind (ahem!). A social shock I experienced is that when someone in a group stops or slows (even one more-familiar than a few hours/days), the others simply continue on – they’re sure to be re-united at a break-point or end point later along the way. It’s something to get used to.Second Insight: Suffering should be understood
One of the things I learned on the Camino is that ‘normal’ is partly an environmental concept. It became ‘normal’ for me to get up at 6am, walk 20-30km per day, eat with some strangers and some familiar faces and go to sleep at 10pm. It did take about a week for that to become ‘normal’ (and even enjoyable!), but it is certainly not similar to my Berlin experience.
I had blisters since the first day of walking, but by the time I reached Bercianos I was no longer able to stand, let alone walk. I had a day off followed by a 7km walk to the next town where I happened to meet a foot doctor from Berlin who gave me all the help I needed, including her sandals. My footwear was the problem causing my blisters (I was walking in running shoes), so I bought myself a good, expensive pair of sandals when I got to Leon, gave the good doctor hers back and had no new problems caused by footwear for the next two weeks. What are the odds of a foot doctor having the same size feet as me?
Most of the people I encountered on the Camino were Italians, Spanish a close second, and plenty of Germans. I fell into a good rhythm with a group of Germans for the second two weeks which was nice. We spoke German as our common language.
Astorga is a beautiful town and it marks the transition of the peregrino from the ‘Camino of Death’ into the ‘Camino of Life’. The route through Galicia is much more steep than the previous stages and full of the sights, sounds and smells of dairy farms. Most of the milk produced in Spain is produced here. The sunflowers filling the landscape and the trail are long since gone.
Although the blisters did not return, the steep climbs and descents brought with them some tendonitis for the final two days of walking. Not much to complain about, timing wise.
It’s sad that the experience of walking the Camino can’t be captured by any camera or prose, but must be experienced to be understood. That’s just part of the nature of suffering :).
Like many, I continued on to Finisterre for a few days of sleeping on the beach and unlike most I spent the weekend after in Barcelona, for a very different experience of parks and beaches.
I'd like to start with addressing some of the issues with running this type of contest. We try to communicate the rules for this contest as clearly as possible, for example, you cannot even join the Flickr group without accepting the rules. However, we cannot force people to read terms and conditions, so we try to warn contestants if they aren't following the rules in order for them to correct their submission before deadline. Unfortunately we cannot force people to read their emails either, so we always have a few popular submissions that get disqualified. This contest was no different, we've had a few problems with wallpaper sizes and of course --- licensing issues.
With that being said, full contest results can be seen here, and down below are the five wallpapers that will be included in Lubuntu 14.10, a big congratulations to you all:
Sunset Over Lake by Andrei Daniel Ticlean Turn Back by Kari Wagner Void by Marxco DragonFly4 by Earl Lunt Colori D'autunno by Quellicol1000
I would also like to thank our friend Guillaume at Picompete for helping us host this contest. He's been helping us for years now, and we really appreciate everything he's done for us. It's a trustworthy service that we really recommend if you wish to host similar contests like this. Guillaume is also a big fan of open source and Linux, and he has offered to help other distributions if they ever need to host a poll.
Last week I published a new app to the Ubuntu Store, which isn’t anything particularly new, but this time I didn’t use my normal license, instead I went permissive. This is something I’ve been wavering on for a while now, and is the result of some developer soul-searching about why I’ve been using the GPL and what it’s done for me.Free as in mine
In the past I’ve always used the GPL or LGPL, not for philosophical reasons or because I thought software should be free (in the RMS sense), but because I was selfish. I used the GPL because I wanted to make sure nobody built something on top of my work without sharing it back to me. In my mind, using a strong copy-left license ensured I couldn’t be left out of someone else’s success with my project. And in a way it worked, I wasn’t left out, because most people never used, let alone built on, my projects. I was trying to solve a problem I didn’t actually have.You aren’t gonna need it
YAGNI (You aren’t gonna need it) is a principle of extreme programming that says you shouldn’t add features to a project until you know that it’s actually necessary. I don’t usually pay much mind to trendy programming methods, but I think this one might be applicable to the way I pick licenses. If my project aren’t being used and extended by others, why am I worried about it happening enough that I want to put restrictions on it? Maybe I don’t need the GPL’s protections afterall.A new direction
So from now on I’m going to prefer the BSD for new projects, and I’ll work on converting old ones to this license when I’ve been the only contributor. The worst that can happen is that somebody benefits from my code more than me, but that wouldn’t be much different to me than having nobody benefit from it more than me. I won’t actually lose anything. Nor will I be restricting my future options, on the contrary I can always go from a BSD to a GPL, but going the other direction is quite a bit harder once you accept contributions.
As mentioned in my earlier blog, I'm visiting several events in the US and Canada in October and November. The first of these, the talk about WebRTC in CRM at xTupleCon, has moved from the previously advertised timeslot to Wednesday, 15 October at 14:15.WebRTC meeting, Norfolk, VA
This will be a hands on event for developers and other IT professionals, especially those in web development, network administration and IP telephony. Please bring laptops and mobile devices with the latest versions of both Firefox and Chrome to experience WebRTC.Free software developers at xTupleCon
If you do want to attend xTupleCon itself, please contact xTuple directly through this form for details about the promotional tickets for free software developers.
- Final beta freeze is 9/25
- The one bug that is >= high in importance and not fixed is bug 1350810 in byobu, reminder sent to kirkland
- Everyone reminded to review assigned blueprints for any features that need to be postponed for 14.10 release, since we’re beyond feature freeze
- no updates
- no updates
- coreycb added arges to agenda
- arges reported to kickinz1 that bcache bug is fixed upstream, so that should trickle down soon
- There are a few sprints going on at the moment.
- no updates
Release Metrics and Incoming Bugs
Release metrics and incoming bug data can be reviewed at the following link:
Status: Utopic Development Kernel
The Utopic kernel has been rebased to the v3.16.2 upstream stable kernel
and uploaded to the archive, ie. linux-3.16.0-14.20. Please test
and let us know your results.
I’d also like to point out that our Utopic kernel freeze date is about 4
weeks away on Thurs Oct 9. Please don’t wait until the last minute to
submit patches needing to ship in the Utopic 14.10 release.
Important upcoming dates:
Mon Sep 22 – Utopic Final Beta Freeze (~2 weeks away)
Thurs Sep 25 – Utopic Final Beta (~2 weeks away)
Thurs Oct 9 – Utopic Kernel Freeze (~4 weeks away)
Thurs Oct 16 – Utopic Final Freeze (~5 weeks away)
Thurs Oct 23 – Utopic 14.10 Release (~6 weeks away)
The current CVE status can be reviewed at the following link:
Status: Stable, Security, and Bugfix Kernel Updates – Trusty/Precise/Lucid
Status for the main kernels, until today (Sept. 9):
- Lucid – verification & testing
- Precise – verification & testing
Trusty – verification & testing
Current opened tracking bugs details:
For SRUs, SRU report is a good source of information:
cycle: 29-Aug through 20-Sep
29-Aug Last day for kernel commits for this cycle
31-Aug – 06-Sep Kernel prep week.
07-Sep – 13-Sep Bug verification & Regression testing.
14-Sep – 20-Sep Regression testing & Release to -updates.
Open Discussion or Questions? Raise your hand to be recognized
No open discussion.
One thing we’d like to see is to bring these capabilities to our users. So I’ve been working on bundling together some of our ElasticSearch resources in Ubuntu so we can bring them to the cloud, it looks like this:
This is a standalone ElasticSearch cluster. I’ve added a few things:
- A preconfigured Kibana dashboard
- A script that preloads the cluster with the works of Shakespeare, so you can start the 10 minute introduction right away and get to work.
- Paramedic and Bigdesk so you can monitor your cluster.
One of the nice things about this bundle is it uses our ElasticSearch charm. Right off the bat you’re getting a charm that we’re using in production today. That means it’s tested (see the included tests, and it also uses many of the modern techniques for writing a charm. In this case, Michael Nelson leveraged Ansible to do most of the heavy lifting. Our ability to consume multiple tools to get the job done is one of the nice things that we can support in charms, so if you prefer a certain tool, then by all means use it! It also just consumes upstream packages, so you’ll always have a fresh version.Why ElasticSearch?
The major use of ElasticSearch is within Ubuntu’s Software Store for Unity 8. On Ubuntu Touch anytime a user is searching for and navigating the store they’re using ElasticSearch. ElasticSearch was chosen for a few reasons.
- It allowed us to design the store where every category is basically a search term. This allows the team to dynamically generate categories based on certain criteria. For example a list of “Top 10 apps” might be different depending whether you are in the US or in China.
- Since everything is designed around search, it lets the team “future proof” the Software Store for future categories and queries.
- ElasticSearch was designed to scale much more than other solutions we looked at. ElasticSearch can be horizontally scaled by just juju add-unit with no extra configuration.
- Since the team didn’t have to worry about learning how to make search it let them concentrate on the store itself and let ElasticSearch do the heavy lifting.
- Since ElasticSearch is driving the backend, this will enable Ubuntu Phone partners to offer customized views on top of the existing store without having to do major engineering work around building a branded store.
- Our team found the ElasticSearch documentation to be excellent.
Ok so let’s deploy this badboy. Assuming you’re brand new:sudo apt-get install juju juju-quickstart juju quickstart bundle:elasticsearch/cluster
At this point follow the ncurses menus to pick which cloud you want to deploy to and add your credentials and then Juju will bootstrap and start deploying ES.
Total deployment time will depend on where you’re deploying to, but on AWS US East 1 I can go from zero to cluster in about 10 minutes. By default I give you one Kibana node and one ElasticSearch node. For ElasticSearch we ensure you’re node has at least 4 CPU cores and 16GB of RAM. You can follow the instructions to load up the sample data and the other sample plugins I’ve included. Just go to the ip address of the Kibana unit in your browser and start searching:
Now you’re ready to horizontally scale:juju add-unit elasticsearch
To add a new node.And that’s it
You now have an ElasticSearch cluster. Using the same best practices that we’re doing in production. Amir Sanjar and I are prototyping bundling the ElasticSearch Hadoop plugin in a bundle as well, though that’s not quite ready (testing and help wanted!).
As you can see, we’ve barely scratched the surface. Chuck Butler’s been reworking the Logstash charm for Trusty, we expect that to land soon. We plan to make the charm a subordinate, you can just plop it onto any unit. The idea is to enable people to put logstash’s indexer on every unit they can shove all they care about into ElasticSearch.
“An idea is resilient. Highly contagious. Once an idea has taken hold of the brain it's almost impossible to eradicate.”
“Now, before you bother telling me it's impossible…”
“No, it's perfectly possible. It's just bloody difficult.”
Perhaps something like this...
“How could I ever acquire enough detail to make them think this is reality?”
“Don’t you want to take a leap of faith???”Sure, let's take a look!
Okay, this looks kinda neat, what is it?
This is an open source Java Spring web application, called Spring-Music, deployed as an app, running inside of Linux containers in CloudFoundry.
CloudFoundry is an open source Platform-as-a-Service (PAAS) cloud, deployed into Linux virtual machine instances in OpenStack, by Juju.
OpenStack is an open source Infrastructure-as-a-Service (IAAS) cloud, deployed by Juju and Landscape on top of MAAS.
Juju is an open source Orchestration System that deploys and scales complex services across many public clouds, private clouds, and bare metal servers.
Landscape is a systems management tool that automates software installation, updates, and maintenance in both physical and virtual machines. Oh, and it too is deployed by Juju.
MAAS is an open source bare metal provisioning system, providing a cloud-like API to physical servers. Juju can deploy services to MAAS, as well as public and private clouds.
"Ready for the kick?"
If you recall these concepts of nesting cloud technologies...
These are real technologies, which exist today!
These are Software-as-a-Service (SaaS) web apps served by an open source Platform-as-a-Service (PaaS) framework, running on top of an open source Infrastructure-as-a-Service (IaaS) cloud, deployed on an open source Metal-as-a-Service provisioning system, managed by an open source Orchestration-Service.
Spring Music, served by CloudFoundry, running on top of OpenStack, deployed on MAAS, managed by Juju and Landscape!
“The smallest seed of an idea can grow…”
Oh, and I won't leave you hanging...you're not dreaming!
Ubuntu Themes with support to GNOME >= 3.12
Install:sudo add-apt-repository ppa:l3on/ubuntu-themes-gnome-shell sudo apt-get update sudo apt-get install light-themes
For more info, check out lp:~l3on/ubuntu-themes/gnome-shell-fixes.
Improvements didn't happen overnight. But by the time we finished A Bug's Life, the production managers were no longer seen as impediments to creative process, but as peers--as first-class citizens. We had become better. This was success in itself, but it came with an added and unexpected benefit: The act of thinking about the problem and responding to it was invigorating and rewarding. We realized that our purpose was not merely to build a studio that made hit films but to foster a creative culture that would continually ask questions. Questions like: If we had done some things right to achieve success how could we ensure that we understood what those things were? Could we replicate them on our next projects? Perhaps as important, was replication of success even the right thing to do? How many serious, potentially disastrous problems were lurking just out of sight and threatening to undo us? What, if anything, could we do to bring the to light? How much of our success was luck? What would happen to our egos if we continued to succeed? Would they grow so large they could hurt us, and if so, what could we do to address that overconfidence? What dynamics would arise now that we were bringing new people into a successful enterprise as opposed to a struggling startup?
What had drawn me to science, all those years ago, was the search for understanding. Human interaction is far more complex than relativity or string theory, of course, but that only made it more interesting and important; it constantly challenged my presumptions.... Figuring out how to build a sustainable creative culture--one that didn't just pay lip service to the importance of things like honesty, excellence, communication, originality, and self-assessment but really *committed* to them, no matter how uncomfortable that became--wasn't a singular assignment....
As I saw it, our mandate was to foster a culture that would seek to keep our sightlines clear, even as we accepted that we were often trying to engage with and fix what we could not see. My hope was to make this culture so vigorous that it would survive when Pixar's founding members were long gone. [p. 64-5]Again, I see an almost perfect match between their task and ours, where ours=KDE e.V.. In the Community Working Group (CWG) in particular, I see my task as essentially gardening. This includes improving the soil, weeding, but never removing valuable little shoots which can grow into exciting new directions for the community. Of course I can't carry the metaphor too far, since others do the planting. But we can keep the conditions for growth optimal with our work.
In the documentation workshop yesterday, we explored the current state of the KDE documentation, how we can improve access, and grow the documentation team again. We also found some large choke points, which includes KDE.org. We really need a web team! KDE.org is valuable real estate on the web, which has been neglected for too long. More about that later.....
For now, looking forward to another day of hard work and fun in Brno!
Welcome to the Ubuntu Weekly Newsletter. This is issue #382 for the week September 1 – 7, 2014, and the full version is available here.
In this issue we cover:
- Welcome New Members and Developers
- Ubuntu Stats
- OpenStack Austin Meetup, with an Orange Box and Home Brew Beer!
- Arizona: Installfest schedule and locations
- Didier Roche: Ubuntu loves Developers
- Daniel Holbach: ubuntu-community-team list: Hang out, discuss new ideas
- Nicholas Skaggs: Autopilot Test Runners
- Lubuntu Blog: [Poll] Community wallpaper contest
- Unity8 & Mir update Sept 2, 2014
- Canonical News
- YES, I have ridden the UNICORN: The Ubuntu Utopic unicorn
- In The Blogosphere
- Ubuntu Podcast from the UK LoCo: S07E23 – The One with the Nap Partners
- Upcoming Meetings and Events
- Updates and Security for 10.04, 12.04 and 14.04
- And much more!
The issue of The Ubuntu Weekly Newsletter is brought to you by:
- Elizabeth K. Joseph
- Jose Antonio Rey
- And many others
Except where otherwise noted, content in this issue is licensed under a Creative Commons Attribution 3.0 License BY SA Creative Commons License
I do a podcast called Bad Voltage with a bunch of my pals. In it we cover Open Source and technology, we do interviews, reviews, and more. It is a lot of fun.
We started a contest recently in which the presenters have to take part in a debate, but with a viewpoint that is actually the opposite of what we actually think.
In the first episode of this three part series, Bryan Lunduke and Stuart Langridge duked it out. Lunduke won (seriously).
In the most recent episode, Jeremy Garcia and I went up against each other.
Sadly, my tiny opponent is beating me right now.
Thus, I ask for a favor. Go here and vote for Bacon. Doing so will make you feel great about your life, save a puppy, and potentially get you that promotion you have been wanting.
Also, for my Ubuntu friends…a vote for Bacon…is a vote for Ubuntu.
UPDATE: The stakes have been increased. Want to see me donate $300 to charity, have an awkward avatar, and pour a bucket of ice/ketchup/BBQ sauce/waste vegetables on me? Read more and then vote.
Due to changes in NGINX, there are now changes done to the default configurations which will break fastcgi sites.
NGINX in Debian, and as such, the PPAs, were previously shipping different configuration files which differed from NGINX itself. The Debian package has now synced with the nginx configurations upstream, and as such, certain very different changes have happened.
This is the massively-detailed NEWS entry in Debian for these changes:
nginx-common (1.6.1-2) unstable; urgency=medium
As of nginx-1.6.1-2 we have synced all configuration files with upstream and
we plan to keep them in sync from now on.
Unfortunately that might break existing configuration for some users. Please
check the matrix below for more information:
mime-types whitespace, changed js/rss mime type,
minor other changes & additions
scgi_params whitespace, added HTTPS
uwsgi_params whitespace, added HTTPS, removed UWSGI_SCHEME
fastcgi_params whitespace, removed SCRIPT_FILENAME
fastcgi.conf new upstream configuration file
Fastcgi configuration issues
nginx shipped a modified `fastcgi_params`, which declared `SCRIPT_FILENAME`
fastcgi_param. This line has now been removed. From now on we are also
shipping fastcgi.conf from the upstream repository, which includes a sane
`SCRIPT_FILENAME` parameter value.
So, if you are using fastcgi_params, you can try switching to fastcgi.conf
or manually set the relevant params.
You might also want to read the documentation section before proceeding.
section: $fastcgi_script_name variable.
You will need to change fastcgi_params to the fastcgi.conf file, or manually set the relevant parameters in your site configs, in order to make things work again.
(This is introduced in the PPAs as 1.6.1-2+precise0 +trusty0 and +utopic0. This is also introduced in the PPAs as 1.7.4-1+precise0 +trusty0 and +utopic0. THis will also be in Ubuntu in versions after 1.6.1-2)
Yesterday the stream of talks at KDE’s conference Akademy finished with the Akademy Awards and Sponsors’ Presentations. Thanks to kind sponsorship by Blue Systems we got to give the first presentation. Rather than talk about how much we loved KDE we decided to show our love by giving away our smart range of polo shirts and shirts to the many good looking members of KDE.