The Linux Foundation this week announced an expansion of the Dronecode project with investments from new members and the creation of three technical working groups. The foundation launched the open source project in 2014 in an effort to create a unified platform for commercial drone technology. Twenty-seven companies have joined Dronecode since, bringing membership to 51, officials said.
Black Duck Software on Tuesday announced it has added to its Hub software container-scanning capabilities that let users map open source security flaws for applications, Linux distros, and other software in Docker and other Linux containers. Adding a containerized scanner to a Docker host enables automatic identification of known open source vulnerabilities in all layers of containers on the host.
KDE contributor Ken Vermette has written The Quintessential 2016 Review of Plasma 5.5 which was released last month, a 9 page cover of the good, the bad and the beautiful.
Plasma 5.5 marks the beginning of the lifecycle where the vast majority of pe…
Tune in for an overview of our party plans and the reopening of Classic.
Hacking team fail0verflow last week demonstrated a hack of Sony’s PlayStation 4 game console that allows anyone running the modification to run the Linux OS on the appliance. The demo was part of a lightning talk session at the 32nd Chaos Communication Congress. The hackers used exploits in FreeBSD, PS4’s operating system and WebKit, which powers the game console’s browser.
I am confident that adopting a client-side framework through progressive decoupling will give us the best of both worlds. Of course, this does not mean I oppose fully decoupling through any other framework; in fact, I believe we should redouble our efforts toward a first-class API-first Drupal. But progressive decoupling means that we will be able to work toward a next-generation user experience without abandoning much of the work we’ve done so far.
Special thanks to all of the following experts who provided review and input: Miško Hevery (creator of Angular; Google) and Igor Minar (technical lead for Angular; Google); Ed Faulkner (core maintainer for Ember); Amitai Burstein (Drupal and Elm contributor; Gizra); Sebastian Siemssen (Drupal contributor, Elm and React developer; Zensations); and John Albin Wilkins (Drupal 8 mobile initiative lead), Alex Bronstein (Drupal core maintainer; Acquia), Wim Leers (Drupal core contributor; Acquia), and Preston So (Drupal contributor, Acquia).
First, have we decided on the right criteria regardless of the frameworks themselves? This is probably the most important at this stage. While many organizations choose to adopt client-side frameworks for fully decoupled implementations, Drupal is the first to consider layering a framework on top to allow both richly dynamic and more traditional modules to coexist gracefully through progressive decoupling. What issues around templates, rendering, and client-side caching should we incorporate into these criteria? Is there anything missing or overemphasized?
Finally, have we drawn the right conclusions against these criteria? In other words, did we fill out the cells correctly? While they have been reviewed by some of the frameworks’ experts, there might be unexpected gotchas or caveats.
At the moment, the most promising candidates in the comparison matrix appear to be Angular 2, Ember, and React, given their technical robustness, relative suitability for progressively decoupled Drupal, and their strong levels of community support and broader adoption. Given that Backbone is already in core and several modules already rely on it, we have included it too.
What we’ve learned from talking to the different projects is that they are often converging on similar techniques and best practices; they are by and large adding support for Virtual DOM implementations or rehydration (seamless state transfer), and they are all obsessing over small payload size and performance, better testability, etc. Therefore it is important to focus on the fundamental, often philosophical, differences between the projects that will likely be unchanged in time; key architectural differences, their release cadence and stance on backward compatibility, their license, their governance model, their flexibility and learning curve, etc.
From a quick glance at the criteria and our needs, it seems that Ember is currently our best candidate, as it appears to have a slight technical edge overall. Ember 2.0 has an all-new rendering engine named Glimmer, and it has server-side rendering through FastBoot. On the other hand, however, Ember is quite bulky and opinionated (enforcing patterns for code structure) compared to other candidate frameworks. A more fundamental difference is that unlike Angular and React, which have corporate governance and funding, Ember is a community-driven project like Drupal.
While React is lightweight, it needs integration with a variety of other libraries in the React ecosystem to work as a full-fledged implementation, which gives it a steep learning curve from an implementation standpoint. Because React is a relatively young project, best practices are shifting quickly and making it less attractive. The Virtual DOM, among React’s most compelling features, has also seen its core ideas filter into other framework projects. But more importantly, React is licensed with what I believe to be a potentially unacceptable patent clause, which states that an organization can no longer use React once it sues Facebook for any (unrelated) patent infringement. This has already generated some concerted pushback from both WordPress’s Calypso and React contributors.
Whatever the result of the debate around which client-side framework to adopt, I believe that Drupal needs to move quickly to embrace a framework that will aid development of a progressively decoupled architecture and corresponding user experience improvements. By providing some baseline criteria and including our accomplished community, I have no doubt we can reach this decision quickly but also intelligently.
Special thanks to Preston So for contributions to this blog post.
Front page news:
If your 2015 was anything like mine, it passed by extremely quickly. It was marked by periods of frustration (spammers still love Drupal.org) and elation (Drupal 8 launched, woot!).
That was a lot of work in what was a tumultuous year. Between all the DrupalCon websites, and major updates to some of our existing sub-sites, we launched as many sites as some web development shops—at least the smaller ones.
We made several small but high impact usability improvements to Drupal.org, and built better features to highlight the contributions of individuals and organizations on their profiles. We modernized and hardened our infrastructure. We made Drupal.org a little more beautiful to better promote this amazing software and community that we support to people finding us for the first time. Among all of that…
What was the most important work in 2015?
If I had to call out just one thing the Drupal.org team did this year that was essential to the success of Drupal and the community, I would highlight the great work done to launch DrupalCI and make it a production system that could handle our community’s unique testing needs.
DrupalCI (the CI stands for Continuous Integration) started as a community initiative. It had been in progress for years as work to replace our aging testbot infrastructure. The old testbots required a manual spin up of new testing servers that were hosted on VMs in a cluster at the Open Source Labs. They were proprietary and rigid. If a testbot went down, it would require manual intervention to free up the queue and allow tests to begin again.
By working closely with the community throughout Q2 and Q3 of 2015, we were able to launch a testing infrastructure that supports multiple testing environments—a feature which has already helped support other projects, like PHP 7—dynamically scales to the testing load, and which is tightly integrated with the Drupal.org issue queues. Overall the new system is much more configurable and far more scalable than the previous system.
Why is testing so vital to the community? Because Drupal 8 represents a much larger code base than Drupal 7. A huge proportion of those new lines of code are tests. Every time a patch is submitted to Drupal Core, up to 15,000+ tests are run—with over 100,000 assertions. Core maintainers and initiative leads need those tests to help them understand how the new code introduced will affect Drupal. Contrib developers can also use DrupalCI to ensure their modules will work well with Drupal.
Though the work to get DrupalCI into production and optimized, we were able to give core maintainers faster and more reliable information about code submitted for inclusion in Drupal.
I honestly believe that without DrupalCI, we would not have had Drupal 8 in 2015. It sped the release of Drupal, which makes it the most accomplishment for our team in 2015.
Happy but not satisfied
Larry Garfield (Crell) wrote a blog post shortly after the release of Drupal 8 where he talked about how he was happy that Drupal 8 was released—and feels it is a huge leap forward for the project—but he is not satisfied because he sees how much work is left to be done.
That is the nature of software. It can always be a little better—more performant, more usable, more extendable.
Drupal.org improved in 2015, but the team is far from satisfied. There is so much more work to complete.
At DrupalCon Amsterdam, I outlined the top 7 initiatives that the Drupal.org team would focus on. When I look back on the year, we did not hit all of our goals.
In April, one year into my time at the Drupal Association, I could point back to a lot of accomplishments, but for many, the improvements were not fast enough. By DrupalCon Los Angeles, we had achieved one of our initiative goals, and moved forward many more, but we added four more to our list. In agile project management terms, we burned up (added more work) than we burned down (work completed).
While the fact that more work is requested faster than we could complete it is not unusual, it did make us think, and we learned some lessons. We have to focus on fewer, high impact priorities. We need to plan for the unplannable – we know there will be unforeseen needs from the community and new technology to support that may not exist yet, and we must be flexible enough to respond. We need to build more partnerships and find great solutions with technology providers that are experts in their fields.
We are pretty excited that much of the planning and design work put into 2015 should result in a much more rapid pace of change to Drupal.org in 2016.
What’s next for Drupal.org
So, we are celebrating all the good things from 2015—there were a lot—but we are also closing the book on what was a challenging year.
Our focus shifts now to supporting the community as we all work to make Drupal 8 successful. We’ll be keeping the Drupal.org Roadmap up to date and adding in new initiatives.
As we start the new year, we are still committed to the content strategy work that will make the content creation experience on Drupal.org and sub-sites better. This will improve our documentation as well as make it easier to talk about the benefits of Drupal to decision makers that help choose Drupal as the best content management framework for their organization.
Additionally, we are doing some exciting work to better support Composer on Drupal.org to align us with the rest of the PHP community as well as planning some much needed improvements to our Git workflow and developer tools.
Lastly, we are not done improving how we highlight contributions within the Drupal community. As Dries outlined in Amsterdam, Drupal is a public good. We need to highlight the great work that people around the world are doing in building Drupal and the community that supports it.
We can’t wait to get started on 2016!
Front page news:
Simutrans plans the move to Steam. The game will be available for free on the distribution platform. This might help new players to get to know the game, and those who already play the game and also use Steam an easier way to keep Simutrans up to date. If you do not use Steam, don’t […]
Journey to this mystic land for our penultimate Winter Weekend.
As the new year begins, the focus falls on Invention and a big anniversary.
Researchers last week revealed a zero-day flaw that lets attackers take over a Linux system by pressing the backspace key repeatedly. Pressing backspace 17 to 20 times will overwrite the highest byte of the return address of the grub_memset() function, ultimately causing a reboot by redirecting control flow to the 0x00eb53e8 address, according to the Cybersecurity Group at the Universitat Politecnica de Valencia.
The Linux Foundation last week announced it was teaming up with a group of high-tech and financial giants on a project to advance the blockchain technology made famous by bitcoin virtual currency. IBM, Cisco and Intel have agreed to collaborate with a number of financial institutions and other companies to develop an enterprise-grade open source distributed ledger framework.
More festive fun is in store with these Winter Weekend bonuses.
A chat about Invention | Good Morning Gielinor | Community highlights |The best of 2015.
= Minutes for Tuesday, December 8th, 2015, 20:00 UTC =
Next meeting date Tuesday, December 15th, 2015, 20:00 UTC
== Attending ==
* Shaun McCance
Today, we are giving you more control over how your data is shared in Firefox by letting you block additional trackers in Private Browsing with Tracking Protection. We recently introduced Private Browsing with Tracking Protection to give you control over … Continue reading
Joomla! 3.4.6 is now available. This is a security release for the 3.x series of Joomla which addresses a critical security vulnerability and 2 low level security vulnerabilities. We strongly recommend that you update your sites immediately.
Don’t Forget to Vote! The 2015 November / December Fedora Elections officially began last Monday, and voting closes today (December 14th) at 23:59:00 UTC. Watch the timezone — that’s a lot sooner than midnight in many parts of the world…. Continue Reading →
Tarballs are due on 2015-12-14 before 23:59 UTC for the GNOME 3.19.3