Now my son Colin wants to attend Archaeology Field School this summer in Armenia. He's been accepted, but has no funding. He's started up a funding site at http://www.gofundme.com/7nuudw. If you care about these things, please donate.
Thanks so much for standing up for your values.
LXC uses cgroups to track and constrain resource use by containers. Historically cgroups have been administered through a filesystem interface. A root owned task can mount the cgroup filesystem and change its current cgroup or the limits of its cgroup. Lxc must therefore rely on apparmor to disallow cgroup mounts, and make sure to bind mount only the container’s own cgroup into the container. It must also calculate its own cgroup for each controller to choose and track a full new cgroup for a new container. Along with some other complications, this caused the amount of code in lxc to deal with cgroups to become quite large.
To help deal with this, we wrote cgmanager, the cgroup manager. Its primary goal was to allow any task to seamlessly and securely (in terms of the host’s safety) administer its own cgroups. Its secondary goal was to ensure that lxc could deal with cgroups equally simply regardless of whether it was nested.
Cgmanager presents a D-Bus interface for making cgroup administration requests. Every request is made in relation to the requesting task’s current cgroup. Therefore ‘lxc-start’ can simply request for cgroup u1 to be created, without having to worry about what cgroup it is in now.
To make this work, we read the (un-alterable) process credentials of the requesting task over the D-Bus socket. We can check the task’s current cgroup using /proc/pid/cgroup, as well as check its /proc/pid/status and /proc/pid/uid_map. For a simple request like ‘create a cgroup’, this is all the information we need.
For requests relating to another task (“Move that task to another cgroup”) or credentials (“Change ownership to that userid”), we have two cases. If the requestor is in the same namespaces as the cgmanager (which we can verify on recent kernels), then the requestor can pass the values as regular integers. We can then verify using /proc whether the requestor has the privilege to perform the access.
But if the requestor is in a different namespace, then we need to uids and pids converted. We do this by having the requestor pass SCM_CREDENTIALS over a file descriptor. When these are passed, the kernel (a) ensures that the requesting task has privilege to write those credentials, and (b) converts them from the requestor’s namespace to the reader (cgmanager).
The SCM-enhanced D-Bus calls are a bit more complicated to use than regular D-Bus calls, and can’t be made with (unpatched) dbus-send. Therefore we provide a cgmanager proxy (cgproxy) which accepts the plain D-Bus requests from a task which shares its namespaces and converts them to the enhanced messages. So when you fire up a Trusty containers host, it will run the cgmanager. Each container on that host can bind the cgmanager D-Bus socket and run a cgproxy. (The cgmanager upstart job will start the right daemon at startup) Lxc can administer cgroups the exact same way whether it is being run inside a container or on the host.
Cgmanager is now in main in trusty. When you log into a trusty desktop, logind should place you into your own cgroup, which you can verify by reading /proc/self/cgroup. If entries there look like2:cpuset:/user/1000.user/c2.session
then you have your own delegated cgroups. If it instead looks like2:cpuset:/
then you do not. You can create your own cgroup using cgm, which is just a script to wrap rather long calls to dbus-send.sudo cgm create all $USER sudo cgm chown all $USER $(id -u) $(id -g)
Next enter your shell into the new cgroup usingcgm movepid all $USER $$
Now you can go on to https://www.stgraber.org/2014/01/17/lxc-1-0-unprivileged-containers/ to run your unprivileged containers. Or, I sometimes like to stick a compute job in a separate freezer cgroup so I can freeze it if the cpu needs to cool down,cgm create freezer cc bash docompile.sh & cgm movepid freezer cc $!
This way I can manually freeze the job when I like, or I can have a script watching my cpu temp as follows:state="thawed" while [ 1 ]; do d=`cat /sys/devices/virtual/thermal/thermal_zone0/temp` || d=1000; d=$((d/1000)); if [ $d -gt 93 -a "$state" = "thawed" ]; then cgm setvalue freezer cc freezer.state FROZEN state="frozen" elif [ $d -lt 89 -a "$state" = "frozen" ]; then cgm setvalue freezer cc freezer.state THAWED state="thawed"; fi; sleep 1; done
How can I help? To help test, visit the iso tracker milestone page for 'Trusty Beta 2'. 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.
So what's new? Besides the usual slew of updates to the applications, stack and kernel, unity has new goodies like minimize on click, menus in toolbar, new lockscreen, and borderless windows!
What if I'm late? The testing runs through this Thursday March 27th, when the the images for beta 2 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!
I’ve wanted to visit Bletchley Park for years. It is where thousands of people toiled twenty-four hours a day to decipher enemy radio messages during the second world war, in absolute secrecy. It is where some of the brightest minds of a generation put their considerable mental skills to an incredibly valuable purpose. It is also where modern computing was born, notably through the work of Alan Turing and others.
So I was very pleased to be invited by my friend James to visit Bletchley as part of his stag weekend. After years of neglect, and in the face of demolition, the park is now being extensively restored. A new visitors’ centre will be introduced, and more of the huts opened up to the public. I have no doubt that these features will improve the experience overall, but there was a feeling of Trigger’s Broom as I looked over the huts closest to the mansion house. Never open to the public before, they looked good with new roofs and walls. But perhaps a little too clean.
And it really is only the huts closest to the house that are being renovated. Others are used by the neighbouring National Museum of Computing, small companies and a huge number are still derelict. Whilst I hope that the remaining huts will be preserved, it would be great if visitors could see the huts in their current dilapidated state too. The neglect of Bletchley Park is part of its story, and I would love to explore the derelict huts as they are now. I would love to shoot inside them – so many ideas in my head for that!
Most of the people working there were aged between eighteen and twenty-one, so you can imagine how much buzz and life there was in the place, despite the graveness of the work being carried out. Having visited the park as it is today, I wish that I had been able to visit it during the war. To see people walking around the huts, efficiency and eccentricity hand-in-hand, to know the import and intellect of what was being carried out, and how it would produce the technology that we all rely on every day, would have been incredible.Pin It
- Recognises AARCH64, SuperH (fix), PPC64, PPCspe, PPC64LE, OpenRISC systems.
- Added symbolic names in '--ranges'.
- Displays Linux binary personality (and flags).
- Improved '--capabilities' output showing not only bounding set, but also whether each capability is supported, permitted, effective and inheritable values.
- Added '--memory' which shows NUMA memory details.
- Added '--cpu' which displays CPU affinity details.
- Added rpm spec file allowing it to build on RHEL5, Fedora, etc.
- Improved '--sizeof' which now shows lots more standard types.
- Displays FreeBSD Capsicum capabilities.
- Lots of fixes.
Take a look at the links on the main procenv page to see the different environments that it is currently building in (the build logs show the build environments as procenv runs itself as part of its build):
nothing new to report this week
Release Metrics and Incoming Bugs
Release metrics and incoming bug data can be reviewed at the following link:
Milestone Targeted Work Items
4 work items
2 work items
1 work item
1 work item
2 work items
3 work items
Status: Trusty Development Kernel
The 3.13.0-19.40 Trusty kernel has been uploaded to the archive. We’ll
anticipate one more upload before kernel freeze on Thurs Apr 3. If
there are any patches which need to land in our 14.04 Trusty kernel, get
them submitted to the Ubuntu kernel team mailing list asap. After
kernel freeze, all patches are subject to our Ubuntu SRU policy.
Important upcoming dates:
Thurs Apr 03 – Kernel Freeze (~1 week away)
Thurs Apr 17 – Ubuntu 14.04 Final Release (~3 weeks away)
The current CVE status can be reviewed at the following link:
Status: Stable, Security, and Bugfix Kernel Updates – Saucy/Raring/Quantal/Precise/Lucid
Status for the main kernels, until today (Mar. 25):
- Lucid – No changes this cycle
- Precise – No changes this cycle
- Quantal – Testing
Saucy – Testing
Current opened tracking bugs details:
For SRUs, SRU report is a good source of information:
Open Discussion or Questions? Raise your hand to be recognized
No open discussions.
Quite often I do make fresh pasta and it's always better to use than dried box pasta (not to discount dry pasta for its convenience however). But, for me, part of the fun of making pasta is that it's quite hands-on.
- 3 x 1 cup all-purpose flour, bread flour or semolina (or a combination thereof)
- 3 x 1/4 teaspoon kosher salt
- 3 x 1 large egg
This recipe is proportional, which is based around the egg (since it's the least divisible, obviously). It also uses the "well technique" of making pasta, since it requires next to no equipment.
As for what flour to use, you can use all semolina to make a semolina pasta, or all flour. Or a good mix would be half semolina and half flour. A high gluten (protein) flour like the bread flour is good for pasta dough.
- Sift together the dry ingredients in a large bowl.
- Dump your dry ingredients into a heap onto a large clean cutting board & make a well in the centre.
- Crack your eggs into the flour well.
- Using a fork lightly beat the eggs and begin to gradually encorporate the flour.
- You can do this by using the tip of fork tines to bring flour into the eggs a little bit at a time while you stir.
- When it begins to come together into a clumpy mess, you can switch to a dough scraper to continue kneading in the flour or, as I prefer to, use your (clean) floured hands.
- Continue kneading and the dough will begin to smooth out and start to look like the below.
- When the dough becomes smooth, form it into into a nice ball, lightly flour it & wrap it in plastic.
- Let it rest at room temperature for at least a half hour, before forming and cutting.
- Optionally, you can refrigerate it for several days or roll it into sheets and freeze.
I'll keep it brief while I throw my hat into this over-hatted ring while it's still in the the limelight –I prefer lemon light myself.
Since the display server makes no obvious impact to a user's experience therefore they're oblivious to itl I only learnt what Surfaceflinger was when the whole display server thing started.
It's only nerds like us that even know about it or care about how it works (I'll exclude myself from the latter condition) since we follow or are involved in the goings-on of open source.
So, can we take the display server down off it's pedestal, move on and continue to make awesome things? Pretty please? You can have some chocolate cake. :)
Also, points if you get my title reference.
Welcome to the Ubuntu Weekly Newsletter. This is issue #360 for the week March 17 – 23, 2014, and the full version is available here.
In this issue we cover:
- Ubuntu Stats
- Bringing Ubuntu App Dev Schools to YOUR LoCo
- App Dev School in Lima!
- Ubucon LatinAmerica is coming!
- Kubuntu: Ladies Polo Shirts Now in Kubuntu Merchandise Shop
- Mark Shuttleworth: ACPI, firmware and your security
- Daniel Holbach: Ubuntu Apps in China
- Timo Jyrinki: Qt 5.2.1 in Ubuntu
- Ubuntu Open Week for Trusty: Call for Instructors
- Ubuntu GNOME: It is Official, Ubuntu GNOME got the LTS Status
- Michael Hall: First steps towards a converged email client for Ubuntu
- Alan Pope: Running Core Apps on the Desktop
- March 2014 Core Apps Hack Days!
- Canonical News
- In The Press
- In The Blogosphere
- Other Articles of Interest
- Featured Audio and Video
- Weekly Ubuntu Development Team Meetings
- Upcoming Meetings and Events
- Updates and Security for 10.04, 12.04, 12.10 and 13.10
- And much more!
The issue of The Ubuntu Weekly Newsletter is brought to you by:
- Elizabeth Krumbach Joseph
- Paul White
- Jim Connett
- 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
At the vUDS in November we talked about having events where local communities could learn more about app development for Ubuntu for the first time. Since then we have come a long way:
- We have some really nice materials set up.
- The first events were held in a number of places around the world.
- We got feedback and improved our docs.
- Before the Ubuntu Global Jam and the release parties for 14.04 LTS we will have two Q&A sessions where you can ask all organisational and technical questions you might have.
You don’t have to do everything yourself!
When we started the initiative, we first talked to members of the Ubuntu community who knew a bit of app development already. Many of them liked the idea, but didn’t quite know how to set up an event or how to organise everything. We tried to address this by bringing them in touch with some of the LoCo teams which helped in a bunch of cases where events have already happened or are going to happen quite soon. We want more of this to happen.
It’s only understandable that you can’t do everything yourself, or that one person’s skills lie in a more organisational field and somebody else has some more experience with app development. Bringing the two together, we are going to have more interesting events, more people introduced to writing apps for Ubuntu, which will be great for everyone involved.
Sounds good so far? Here’s what you can do to get more folks exposed to how sweet and easy it is to write apps for Ubuntu.
As somebody who can organise events, but might need to find a speaker: Ask in #ubuntu-app-devel on Freenode or on the ubuntu-app-devel@ mailing list, to see if anyone is in your area to give a talk. Ask on your LoCo’s or LUG’s mailing list as well. Even if somebody who’s into programming hasn’t developed using Ubuntu’s SDK yet, they should be able to familiarise themselves with the technologies quite easily.
As somebody who has written code before and didn’t find the Ubuntu app development materials too challenging, but might need to find some help with organising the event: Ask on the loco-contacts@ mailing list. There are LoCos all around the world and most of them will be happy to see somebody give a talk at an event.
Whichever camp you’re in:
- Check out our docs. They explain what’s required to make the event a success.
- Join our Q&A sessions at:
- Talk to us. Just comment on the blog post and we can surely help you out somehow.
Let’s make this happen together. Writing apps for Ubuntu and publishing them has never been easier, and they’ll make Ubuntu on phones/tablets much more interesting, and will run on the desktop as well.
I’ve been using Ubuntu on my only phone for over six months now, and I’ve been loving it. But all this time it’s been missing something, something I couldn’t quite put my finger on. Then, Saturday night, it finally hit me, it’s missing the community.
That’s not to say that the community isn’t involved in building it, all of the core apps have been community developed, as have several parts of our toolkit and even the platform itself. Everything about Ubuntu for phones is open source and open to the community.
But the community wasn’t on my phone. Their work was, but not the people. I have Facebook and Google+ and Twitter, sure, but everybody is on those, and you have to either follow or friend people there to see anything from them. I wanted something that put the community of Ubuntu phone users, on my Ubuntu phone. So, I started to make one.Community Cast
Community Cast is a very simple, very basic, public message broadcasting service for Ubuntu. It’s not instant messaging, or social networking. It doesn’t to chat rooms or groups. It isn’t secure, at all. It does just one thing, it lets you send a short message to everybody else who uses it. It’s a place to say hello to other users of Ubuntu phone (or tablet). That’s it, that’s all.
As I mentioned at the start, I only realized what I wanted Saturday night, but after spending just a few hours on it, I’ve managed to get a barely functional client and server, which I’m making available now to anybody who wants to help build it.Server
The server piece is a very small Django app, with a single BroadcastMessage data model, and the Django Rest Framework that allows you to list and post messages via JSON. To keep things simple, it doesn’t do any authentication yet, so it’s certainly not ready for any kind of production use. I would like it to get Ubuntu One authentication information from the client, but I’m still working out how to do that. I threw this very basic server up on our internal testing OpenStack cloud already, but it’s running the built-in http server and an sqlite3 database, so if it slows to a crawl or stops working don’t be surprised. Like I said, it’s not production ready. But if you want to help me get it there, you can get the code with bzr branch lp:~mhall119/+junk/communitycast-server, then just run syncdb and runserver to start it.Client
The client is just as simple and unfinished as the server (I’ve only put a few hours into them both combined, remember?), but it’s enough to use. Again there’s no authentication, so anybody with the client code can post to my server, but I want to use the Ubuntu Online Accounts to authenticate a user via their Ubuntu One account. There’s also no automatic updating, you have to press the refresh button in the toolbar to check for new messages. But it works. You can get the code for it with bzr branch lp:~mhall119/+junk/communitycast-client and it will by default connect to my test instance. If you want to run your own server, you can change the baseUrl property on the MessageListModel to point to your local (or remote) server.Screenshots
There isn’t much to show, but here’s what it looks like right now. I hope that there’s enough interest from others to get some better designs for the client and help implementing them and filling out the rest of the features on both the client and server.
Not bad for a few hours of work. I have a functional client and server, with the server even deployed to the cloud. Developing for Ubuntu is proving to be extremely fast and easy.
The revelations from Edward Snowden concerning massive surveillance of communications demonstrates the need for each person to be able to control their computers and phones.
Yet computer and telephone manufacturers and retailers typically impose on users programs that jeopardise their privacy.
Each person should therefore have the opportunity to refuse to pay for non-Free software, and be allowed to choose the programs that run on their telephone and computer.
Today, Association for the free digital culture – CLibre joins other organisations throughout the world in requesting an unfettered choice of the operating system on telephones, laptops and other computing devices.
Sign the international petition! http://no.more.racketware.info/petition/click/en
Further information. http://no.more.racketware.info/en/index
Do you want help in promoting this petition? Visit http://no.more.racketware.info/petition/indexTweet
I have lots of positive things to say about the OpenStack community. They managed to create a great mixture of professional yet agile and FLOSSy. Amazing CI/CD and devstack is just an awesome way to kickstart development on OpenStack.
Last month I discovered Marconi (https://wiki.openstack.org/wiki/Marconi)...
Basically its a new MQ written in pure Python and allos different backends. The awesome thing is you can run it without having to run the whole openstack stuff and it works... It is still a young project but the community around it its awesome ans their IRC #openstack-marconi is very responsive. These guys could use a hand so if you are a Python enthusiast or want to hack on something OpenStack related without needing to have the whole stack running, please show some support and try to help out. There is a lot of low hanging fruit (https://bugs.launchpad.net/openstack/marconi) :)
The Ubuntu webbrowser sets its own default user agent string, and also provides a list of overrides which define different user agent strings for specific sites that do broken UA sniffing. This is a concept that we’ve borrowed from Firefox OS.
With QtWebkit, the overriding is performed via the same mechanism that is used for setting the default user agent string – by setting the WebViewExperimental.userAgent property. However, this has a major shortcoming – it provides no means to override the user agent string for specific frames. Say, for example, that you need to provide an override for www.twitter.com, but not for www.example.org. If a page from www.example.org embeds www.twitter.com in an iframe, there isn’t a mechanism to change the user agent string for the child frame.
When overriding the user agent string for a frame, there are 2 places that this needs to happen:
- The User-Agent header in outgoing HTTP requests.
Fortunately, Chromium provides a mechanism by which we can implement the second one – net::NetworkDelegate::OnBeforeSendHeaders(). Unfortunately, this is called on Chromium’s IO thread which makes it difficult to expose as a signal in QML (a QML engine can only execute code on a single thread). The notification is asynchronous, which means we could dispatch an event to the UI thread, emit a signal in QML and then dispatch an event back to Chromium’s IO thread. However, this has shortcomings of its own:
- A typical page load can generate more than 100 network requests. For example, loading BBC News generated 165 requests when I tested it here. Assuming we have multiple notifications per request, processing all of these on the UI thread in QML could have a noticeable performance impact.
- Not all notifications we get from net::NetworkDelegate are asynchronous. For example, cookie access permission requests aren’t.
For handling events that happen on Chromium’s IO thread, we have a new class – WebContextDelegateWorker. This is very similar to QML’s WorkerScript – it runs script on a worker thread and provides sendMessage/onMessage API’s for exchanging data with QML on the UI thread. However, it provides a mechanism for scripts to expose entry points that can be called from Chromium’s IO thread (actually, they’re not called from Chromium’s IO thread – they’re called on the worker thread by blocking the IO thread. But, you don’t need to care about that).
To overridethe User-Agent header for specific requests in Oxide, you can do something like the following:
This doesn’t affect navigator.userAgent though. In order to provide an override mechanism for this, we had to apply a small patch to Chromium to give embedders the opportunity to provide an override value when accessed. We did consider exposing a signal in QML for overriding this, based on the assumption that this would run much less frequently than network notifications. However, in the end we decided to reuse WebContextDelegateWorker, based on the assumption that developers who want to override navigator.userAgent will probably also want to use the same overrides for the User-Agent header. Doing this means that you only need the override list in one script context.
To override navigator.userAgent, the above code becomes:
Oxide doesn’t have a per-WebView property that’s equivalent to WebViewExperimental.userAgent in QtWebkit, as we decided that this would be redundant with the above override mechanism. Instead, the default user agent string is configured by setting the WebContext.userAgent property.Other uses for WebContextDelegateWorker
WebContextDelegateWorker is also used for overriding the default storage access policy via WebContext.storageAccessPermissionDelegate (in QML) and exports.onStoragePermissionRequest (in the worker). This is currently only used for cookies, but is due to be expanded to local storage, app cache, indexedDB and WebDB. The default storage access policy is controlled by WebContext.cookiePolicy
dict.has_key() was removed in Python 3.x.
This sed regex could fix them all:sed -r "s/([a-z,A-Z,0-9,.,_]*)\.has_key\('([^']*)'\)/'\2' in \1/g" \ -i `find -name "*.py"`
With the very latest great news – Ubuntu GNOME 14.04 will be an LTS release supported for 3 years – and with the great commitment of Ubuntu GNOME Team and the high quality that everyone showed for the last 5 months, we do need to carry on and keep up the great work. We have achieved a lot and less than a month to go to the final release and the very first LTS version of Ubuntu GNOME. The hard work has just started. Beta 2 or the final beta means this is what Ubuntu GNOME 14.04 LTS final release will look like, at least 90% or even more.
If you take a look at the Release Schedule Wiki Page, you will notice that there will be no more new features or any kind of changes to be done. At this stage/phase, it is mainly heavy testing and bugs fixing.
From today until 17th of April, 2014 (the date of the final release), we do need to make sure that Ubuntu GNOME 14.04 LTS will be solid and stable as a rock. Thus, we do need your help and support.
Final Beta or Beta 2 is not yet released. It will be released in 27th of March, 2014 but we must start testing from now and be ready.
What exactly do I need to test?
Ubuntu GNOME Trusty Tahr Daily Build
Okay, I’m new to this so how can I get started?
HOWTO Test Ubuntu GNOME
How can I get in touch with the Testing Team?
HOWTO Contact Ubuntu GNOME QA/Testing Team
Where else I could ask for some help?
Beside the mailing list of Ubuntu GNOME QA Team and Ubuntu GNOME IRC Channel, you can always post on Ubuntu Forums. There is a dedicated section for testing. However, please pay attention to:
This forum is for the discussion of the development of the next version of Ubuntu. Please Note: Ubuntu Developers do not usually read the forums, If you run into what you think is a bug, please use Launchpad to report it.
For anything else, please feel free to contact us.
Thank you for testing Ubuntu GNOME and helping us. We highly appreciate and respect that.
Ubuntu GNOME QA Lead
UbuConLA is an international event which happens every year and it is held in different parts of Latin America. This year UbuconLA will be in the beautiful city of Cartagena / Colombia. With the following objectives:
- Sharing the experiences and skills acquired in corporate environments by specialists from Latin America in several projects and contexts.
- Showing the level reached by Ubuntu GNU / Linux and professionals working in business environments, as well as consultants, users or systems managers.
- Technically and socially integrate users and specialists from Latin America, both for acquisition of new knowledge and skills and taking advantage of the creation business opportunities in the region.
- Spreading the Ubuntu spirit throughout Latin America.
- Institutionalizing UbuConLA as “The Annual Ubuntu Event “for Latin America.
The 2014 edition will be held in Cartagena, Colombia, at the Universidad Tecnologica de Bolivar on the 14 and 16 of August 2014.
This edition of the UbuConLA will be having people from, Argentina, Uruguay, Peru, Mexico, Venezuela, Colombia and Spain.
Besides if you want to be an speaker, visit http://ubuconla.org/callforpapers.php
And always is good to see Jono’s messages :D (this for ubuconla2013)
More news and updates on our social networks:
You can get more information on our website http://ubuconla.org/ or contact email the organizers at: ubuconla2013 [AT] ubuconla [DOT] org
In the modern display stack there are five main components:
- Display Server / Shell
- Toolkit / Platform API
For (too) many years we've lived with the X display server in the open source world. But now we are moving into next generation display servers (as Apple and Microsoft did many years ago). At the moment there are two new classes of contender for X replacement, Mir and a set of Wayland based compositors (e.g. weston, mutter-wayland etc).
Applications use toolkits and platform APIs to access graphical functionality. There are plenty of toolkits out there (e.g. GTK+, Qt) and existing libraries are growing more broad, consistent and stable to be considered as a complete platform API (which is great for developers).
If you read the Internet you would think the most important part in this new world is the display server. But actually it's just a detail that doesn't matter that much.
- Applications access the display server via a toolkit. All the successful toolkits support multiple backends because there's more than one OS out there today. In general you can take a GTK+ application and run it in Windows and everything just works.
- The hardware and drivers are becoming more and more generic. Video cards used to have very specialised functionality and OpenGL used to provide only a fixed function function. Now video cards are basically massively parallel processors (see OpenCL) and OpenGL is a means of passing shaders and buffer contents.
So what does matter now?
- It does matter that we have open drivers. Because there will be different things exercising them we need to be able to fix drivers when display server B hits a bug but A doesn't. We saw this working with Mir on Android drivers. Since these drivers are only normally used by SurfaceFlinger there are odd bugs if you do things differently. Filing a bug report is no substitute to being able to read and fix the driver yourself.
- The shell matters a lot more. We're moving on from the WIMP paradigm. We have multiple form factors now. The shell expresses what an application can do and different shells are likely to vary in what they allow.