Feeds

Qt 5.10 Beta available for testing with KDE neon

Planet KDE - Thu, 2017-10-12 06:53

Qt 5.10 Beta was released this week and the neon builder cloud elves have been compiling it away ready for testing.

There’s no QtWebEngine or Qt3D so stuff which needs those will be broken.

Other stuff likely broken too, don’t use it on a machine you’re not happy doing a reinstall on.

But the good news is the broken clock plasmoid works now


deb http://archive.neon.kde.org/testing xenial main

Categories: FLOSS Project Planets

Claus Ibsen: Apache Camel 2.20 released - What's new

Planet Apache - Thu, 2017-10-12 04:23
Apache Camel 2.20 has been released today and as usual I am tasked to write a blog about this great new release and what's the highlights.


The release has the following highlights.

1) Java 9 technical preview supportWe have started our work to support Java 9 and this release is what we call technical preview. The source code builds and runs on Java 9 and we will continue to improve work for official support in the following release.2) Improved startup timeWe have found a few spots to optimise the startup time of Apache Camel so it starts 100 - 200 milli seconds faster.

3) Optimised core to reduce footprint

Many internal optimisations in the Camel routing engine, such as reducing thread contention when updating JMX statistics, reducing internal state objects to claim less memory, and reducing the number of allocated objects to reduce overhead on GC etc, and much more.

4) Improved Spring Boot support and preparing for Spring Boot 2

We have improved Camel running on Spring Boot in various ways.

We also worked to make Apache Camel more ready and compatible with the upcoming Spring Boot 2 and Spring Framework 5. Officially support for these is expected in Camel 2.21 release.

5) Improved Spring lifecycle

Starting and stoping the CamelContext when used with Spring framework (SpringCamelContext) was revised to ensure that the Camel context is started last - when all resources should be available, and stopped first - while all resources are still available.

6) JMS 2.0 support

The camel-jms component now supports JMS 2.0 APIs.

7) Faster Map implementation for message headers

If you include camel-headersmap component on the classpath, then Camel will auto detect it on startup and use a faster implementation of case-insenstive map (used by camel message headers).

8) Health-Check API

We have added experimental support for a new health-check API  (which we will continue to work on over the next couple of releases).  The health checks can be leveraged in in cloud environments to detect non healthy contexts.

9) Cluster API

Introduced an experimental Cluster SPI (which we will continue to work on over the next couple of releases) for high availability contexts, out of the box Camel supports: atomix, consul, file, kubernetes and zookeeper as underlying clustering technologies through the respective components.

10) RouteController API

Introduced an experimental Route Controller SPI (which we will continue to work on over the next couple of releases) aimed to provide more fine-grained control of routes, out of the box Camel provides the following implementations:

  • SupervisingRouteController which delays startup of the routes after the camel context is properly started and attempt to restart routes that have not been starter successfully.
  • ClusteredRouteController which leverages Cluster SPI to start routes only when the context is elected as leader.

11) More components

As usual there is a bunch of new components for example we have support for calling AWS lambda functions in the camel-aws component. There is also a new json validator component, and camel-master is used with the new Cluster API to do route leader election in a cluster. There is 13 new components and 3 new data formats. You can find more details in the Camel 2.20 release notes.

We will now start working on the next release 2.21 which is scheduled in start of 2018. We are trying to push for a bit quicker release cycle of these bigger Camel releases, so we can go from doing 2 to 3 releases per year. This allows people to quicker pickup new functionality and components etc.

Also we want to get a release out that officially support Java 9, Spring Boot 2 and all the usual great stuff we add to each release, and what the community contributes.



Categories: FLOSS Project Planets

Edward J. Yoon: 조직 관성(Organizational Inertia)

Planet Apache - Thu, 2017-10-12 02:45
최근 들어던 세미나에 의하면 자연 법칙으로 존재하는 관성은 조직에도 존재한다.

다소 철학적 고찰이긴 한데, 우선,  관성(inertia)부터 알아보자.

관성이란 버스가 급출발 할 때 뒤로 쏠리는 그 힘이 바로 관성이다.  관성은 원래 상태를 유지하려는 성질에 불과하니 진짜힘이 아니다. 그래서 관성을 가짜힘이라고 한다. 진짜힘은 버스를 급출발 시키는 힘이다.

몸이 뒤로 쏠리는 가짜힘의 크기는 버스를 급출발 시키는 진짜힘의 크기에 의해서만 결정된다. 이게 관성과 운동의 상대성이다.

관성과 운동의 상대성을 생각하면, 조직의 관성은 변화의 크기에 의해서 결정되므로 그것은 요주의 대상이 아니라 오히려 변화의 파도라고 볼 수 있겠다.
Categories: FLOSS Project Planets

Timothy Chen: Hierarchical Scheduling for Diverse Datacenter Workloads

Planet Apache - Thu, 2017-10-12 02:24

Hierarchical Scheduling for Diverse Datacenter Workloads

In this post we’ll cover the paper that introduced HDRF (Hierarchical Dominant Resource Fairness) which builds upon the team’s existing work DRF (Dominant Resource Fairness), but looking to also provide hierarchical scheduling.

Background

Prior work DRF, was an algorithm that was able to decide how to allocate multi-dimensional resources to multiple frameworks, which it described how it can enforce fairness when scheduling multiple resource types with a flat hierarchy:

                 DRF  

    | —— |  —— | —— – |

   dev   test staging prod

    10     10      30       50

However, in most organizations it’s important to be able to describe resource allocation weights in a hierarchy that reflects its organizational intent:

                 H-DRF  

    | —— |  —— | —— – |

   fe      ads     spam   mail

   30      20        25       25

   /\        /\          /\         /\

 d  p     d p       d p     d  p       (d = dev, p = prod)

 50 50 20 80    30 70  40 60

The key difference with hierarchical scheduling is that when a node is not using its resources, it’s redistributed among the sibling nodes as opposed to all leaf nodes. For example, when dev environment in FE is not using its resources, it’s allocated to prod in FE instead. 

Naive implementations of hierarchical and multi-resource scheduling (such as collapsing the hierarchy into a flat hierarchy, or simply running DRF from root to leaf node) can lead to starvation, where in our example certain dev and prod environment never receiving any or their fair share of resources. This is referred as hierarchical share guarantee.

H-DRF

To avoid the problem of starvation, H-DRF incorporates two ideas when considering dominant share in the leaf nodes. The first idea is rescaling the leaf node’s resource consumption to the minimum node. The second idea is to ignore rescaling blocked nodes, where a node is blocked if one of the resources request is saturated or when it has no more tasks to launch. The actual proof and steps of the implementation is covered in the paper, and I won’t go over here in details. 

Notes

The interesting piece that was highlighted in this paper was that Hadoop implemented a naive version of HDRF and therefore has bugs where it can cause starvation in the tasks. Therefore, it’s not straightforward when attempting to modify how DRF works without proofing it’s starvation free and also provides fairness (unless it’s not the primary goal for your change). 

That said, there are more papers that continues to extend and modify DRF and also shown ways that can continue to show blindspots that HDRF didn’t cover, which I’ll try to cover more in the future.


Categories: FLOSS Project Planets

Dirk Eddelbuettel: RcppArmadillo 0.8.100.1.0

Planet Debian - Wed, 2017-10-11 22:13

We are thrilled to announce a new big RcppArmadillo release! Conrad recently moved Armadillo to the 8.* series, with significant improvements and speed ups for sparse matrix operations, and more. See below for a brief summary.

This also required some changes at our end which Binxiang Ni provided, and Serguei Sokol improved some instantiations. We now show the new vignette Binxiang Ni wrote for his GSoC contribution, and I converted it (and the other main vignette) to using the pinp package for sleeker pdf vignettes.

This release resumes our bi-monthly CRAN release cycle. I may make interim updates available at GitHub "as needed". And this time I managed to mess up the reverse depends testing, and missed one sync() call on the way back to R---but all that is now taken care of.

Armadillo is a powerful and expressive C++ template library for linear algebra aiming towards a good balance between speed and ease of use with a syntax deliberately close to a Matlab. RcppArmadillo integrates this library with the R environment and language--and is widely used by (currently) 405 other packages on CRAN.

A high-level summary of changes follows.

Changes in RcppArmadillo version 0.8.100.1.0 (2017-10-05)
  • Upgraded to Armadillo release 8.100.1 (Feral Pursuits)

    • faster incremental construction of sparse matrices via element access operators

    • faster diagonal views in sparse matrices

    • expanded SpMat to save/load sparse matrices in coord format

    • expanded .save(),.load() to allow specification of datasets within HDF5 files

    • added affmul() to simplify application of affine transformations

    • warnings and errors are now printed by default to the std::cerr stream

    • added set_cerr_stream() and get_cerr_stream() to replace set_stream_err1(), set_stream_err2(), get_stream_err1(), get_stream_err2()

    • new configuration options ARMA_COUT_STREAM and ARMA_CERR_STREAM

  • Constructors for sparse matrices of types dgt, dtt amd dst now use Armadillo code for improved performance (Serguei Sokol in #175 addressing #173)

  • Sparse matrices call .sync() before accessing internal arrays (Binxiang Ni in #171)

  • The sparse matrix vignette has been converted to Rmarkdown using the pinp package, and is now correctly indexed. (#176)

Courtesy of CRANberries, there is a diffstat report. More detailed information is on the RcppArmadillo page. Questions, comments etc should go to the rcpp-devel mailing list off the R-Forge page.

This post by Dirk Eddelbuettel originated on his Thinking inside the box blog. Please report excessive re-aggregation in third-party for-profit settings.

Categories: FLOSS Project Planets

Justin Mason: Links for 2017-10-11

Planet Apache - Wed, 2017-10-11 19:58
  • Study: wearing hi-viz clothing does not reduce risk of collision for cyclists

    Journal of Transport & Health, 22 March 2017:

    This study found no evidence that cyclists using conspicuity aids were at reduced risk of a collision crash compared to non-users after adjustment for confounding, but there was some evidence of an increase in risk. Bias and residual confounding from differing route selection and cycling behaviours in users of conspicuity aids are possible explanations for these findings. Conspicuity aids may not be effective in reducing collision crash risk for cyclists in highly-motorised environments when used in the absence of other bicycle crash prevention measures such as increased segregation or lower motor vehicle speeds.

    (tags: health safety hi-viz clothing cycling commute visibility collision crashes papers)

Categories: FLOSS Project Planets

Steve Kemp: A busy week or two

Planet Debian - Wed, 2017-10-11 17:00

It feels like the past week or two has been very busy, and so I'm looking forward to my "holiday" next month.

I'm not really having a holiday of course, my wife is slowly returning to work, so I'll be taking a month of paternity leave, taking sole care of Oiva for the month of November. He's still a little angel, and now that he's reached 10 months old he's starting to get much more mobile - he's on the verge of walking, but not quite there yet. Mostly that means he wants you to hold his hands so that he can stand up, swaying back and forth before the inevitable collapse.

Beyond spending most of my evenings taking care of him, from the moment I return from work to his bedtime (around 7:30PM), I've made the Debian Administration website both read-only and much simpler. In the past that site was powered by a lot of servers, I think around 11. Now it has only a small number of machines, which should slowly decrease.

I've ripped out the database host, the redis host, the events-server, the planet-machine, the email-box, etc. Now we have a much simpler setup:

  • Front-end machine
    • Directly serves the code site
    • Directly serves the SSL site which exists solely for Let's Encrypt
    • Runs HAProxy to route the rest of the requests to the cluster.
  • 4 x Apache servers
    • Each one has a (read-only) MySQL database on it for the content.
      • In case of future-compromise I removed all user passwords, and scrambled the email-addresses.
      • I don't think there's a huge risk, but better safe than sorry.
    • Each one runs the web-application.
      • Which now caches each generated page to /tmp/x/x/x/x/$hash if it doesn't exist.
      • If the request is cached it is served from that cache rather than dynamically.

Finally although I'm slowly making progress with "radio stuff" I've knocked up a simple hack which uses an ultrasonic sensor to determine whether I'm sat in front of my (home) PC. If I am everything is good. If I'm absent the music is stopped and the screen locked. Kinda neat.

(Simple ESP8266 device wired to the sensor. When the state changes a message is posted to Mosquitto, where a listener reacts to the change(s).)

Oh, not final. I've also transfered my mobile phone from DNA.fi to MoiMobile. Which should complete soon, right now my phone is in limbo, active on niether service. Oops.

Categories: FLOSS Project Planets

Cutelyst 1.9.0 released!

Planet KDE - Wed, 2017-10-11 16:47

Cutelyst the Qt web framework got a new release. This is a rather small release but has some important fixes so I decided to roll sooner.

The dispatcher logic got 30% faster, parsing URL encoded data is also a bit faster on some cases (using less memory), Context objects can now be instantiated by library users to allow for example getting notifications from SQL databases and be able to forward to Cutelyst actions or Views, pkg-config support has also improved a bit but still misses most modules.

Have fun https://github.com/cutelyst/cutelyst/archive/v1.9.0.tar.gz


Categories: FLOSS Project Planets

Dries Buytaert: The evolution of Acquia's product strategy

Planet Drupal - Wed, 2017-10-11 16:26

Four months ago, I shared that Acquia was on the verge of a shift equivalent to the decision to launch Acquia Fields and Drupal Gardens in 2008. As we entered Acquia's second decade, we outlined a goal to move from content management to data-driven customer journeys. Today, Acquia announced two new products that support this mission: Acquia Journey and Acquia Digital Asset Manager (DAM).

Last year on my blog, I shared a video that demonstrated what is possible with cross-channel user experiences and Drupal. We showed a sample supermarket chain called Gourmet Market. Gourmet Market wants its customers to not only shop online using its website, but to also use Amazon Echo or push notifications to do business with them. The Gourmet Market prototype showed an omnichannel customer experience that is both online and offline, in store and at home, and across multiple digital touchpoints. The Gourmet Market demo video was real, but required manual development and lacked easy customization. Today, the launch of Acquia Journey and Acquia DAM makes building these kind of customer experiences a lot easier. It marks an important milestone in Acquia's history, as it will accelerate our transition from content management to data-driven customer journeys.

Introducing Acquia Journey

I've written a great deal about the Big Reverse of the Web, which describes the transition from "pull-based" delivery of the web, meaning we visit websites, to a "push-based" delivery, meaning the web comes to us. The Big Reverse forces a major re-architecture of the web to bring the right information, to the right person, at the right time, in the right context.

The Big Reserve also ushers in the shift from B2C to B2One, where organizations develop a one-to-one relationship with their customers, and contextual and personalized interactions are the norm. In the future, every organization will have to rethink how it interacts with customers.

Successfully delivering a B2One experience requires an understanding of your user's journey and matching the right information or service to the user's context. This alone is no easy feat, and many marketers and other digital experience builders often get frustrated with the challenge of rebuilding customer experiences. For example, although organizations can create brilliant campaigns and high-value content, it's difficult to effectively disseminate marketing efforts across multiple channels. When channels, data and marketing software act in different silos, it's nearly impossible to build a seamless customer experience. The inability to connect customer profiles and journey maps with various marketing tools can result in unsatisfied customers, failed conversion rates, and unrealized growth.

Acquia Journey delivers on this challenge by enabling marketers to build data-driven customer journeys. It allows marketers to easily map, assemble, orchestrate and manage customer experiences like the one we showed in our Gourmet Market prototype.

It's somewhat difficult to explain Acquia Journey in words — probably similar to trying to explain what a content management system does to someone who has never used one before. Acquia Journey provides a single interface to define and evaluate customer journeys across multiple interaction points. It combines a flowchart-style journey mapping tool with unified customer profiles and an automated decision engine. Rules-based triggers and logic select and deliver the best-next action for engaging customers.

One of the strengths of Acquia Journey is that it integrates many different technologies, from marketing and advertising technologies to CRM tools and commerce platforms. This makes it possible to quickly assemble powerful and complex customer journeys.

Acquia Journey will simplify how organizations deliver the "best next experience" for the customer. Providing users with the experience they not only want, but expect will increase conversion rates, grow brand awareness, and accelerate revenue. The ability for organizations to build more relevant user experiences not only aligns with our customers' needs but will enable them to make the biggest impact possible for their customers.

Acquia's evolving product offering also puts control of user data and experience back in the hands of the organization, instead of walled gardens. This is a step toward uniting the Open Web.

Introducing Acquia Digital Asset Manager (DAM)

Digital asset management systems have been around for a long time, and were originally hosted through on-premise servers. Today, most organizations have abandoned on-premise or do-it-yourself DAM solutions. After listening to our customers, it became clear that large organizations are seeking a digital asset management solution that centralizes control of creative assets for the entire company.

Many organizations lack a single-source of truth when it comes to managing digital assets. This challenge has been amplified as the number of assets has rapidly increased in a world with more devices, more channels, more campaigns, and more personalized and contextualized experiences. Acquia DAM provides a centralized repository for managing all rich media assets, including photos, videos, PDFs, and other corporate documents. Creative and marketing teams can upload and manage files in Acquia DAM, which can then be shared across the organization. Graphic designers, marketers and web managers all have a hand in translating creative concepts into experiences for their customers. With Acquia DAM, every team can rely on one dedicated application to gather requirements, share drafts, consolidate feedback and collect approvals for high-value marketing assets.

On top of Drupal's asset and media management capabilities, Acquia DAM provides various specialized functionality, such as automatic transcoding of assets upon download, image and video mark-up during approval workflows, and automated tagging for images using machine learning and image recognition.

By using a drag-and-drop interface on Acquia DAM, employees can easily publish approved assets in addition to searching the repository for what they need.

Acquia DAM seamlessly integrates with both Drupal 7 and Drupal 8 (using Drupal's "media entities"). In addition to Drupal, Acquia DAM is built to integrate with the entirety of the Acquia Platform. This includes Acquia Lift and Acquia Journey, which means that any asset managed in the Acquia DAM repository can be utilized to create personalized experiences across multiple Drupal sites. Additionally, through a REST API, Acquia DAM can also be integrated with other marketing technologies. For example, Acquia DAM supports designers with a plug in to Adobe Creative Cloud, which integrates with Photoshop, InDesign and Illustrator.

Acquia's roadmap to data-driven customer journeys

Throughout Acquia's first decade, we've been primarily focused on providing our customers with the tools and services necessary to scale and succeed with content management. We've been very successful with helping our customers scale and manage Drupal and cloud solutions. Drupal will remain a critical component to our customer's success, and we will continue to honor our history as committed supporters of open source, in addition to investing in Drupal's future.

However, many of our customers need more than content management to be digital winners. The ability to orchestrate customer experiences using content, user data, decisioning systems, analytics and more will be essential to an organization's success in the future. Acquia Journey and Acquia DAM will remove the complexity from how organizations build modern digital experiences and customer journeys. We believe that expanding our platform will be good not only for Acquia, but for our partners, the Drupal community, and our customers.

Categories: FLOSS Project Planets

Last Week Activity in Elisa

Planet KDE - Wed, 2017-10-11 16:06

Elisa is a music player designed to be simple and nice to use.

I have started again to work on Windows build of the application and a recipe to build Elisa is now integrated in the craft-blueprints-kde repository. It is already quite usable thanks to the portability offered by Qt and KF5 Frameworks and the quality of Craft meta build system.

Snapshot of Elisa on Windows 7

Apart from that, I have integrated the following things:

  • Fix a bug blocking the play when under some conditions asking to enqueue some music and playing immediately would not work ;
  • Fix the display of tracks count in the playlist ;
  • Improve the handling of Elisa application icon such that it is bundled in the executable ;
  • Continue to improve focus handling especially with touch screens ;
  • Add mouse hover effect in the list of view modes (all albums, all artists …).

I am currently working on improvements of error handling when playing music. I also plan to explore using Phonon to have a possibly easier out of the box experience for flatpak and Windows when using the vlc backend. I am getting frustrated by getting missing codec errors from QtMultimedia.

Edit: I added a screenshot of Elisa on Windows 7 as requested.


Categories: FLOSS Project Planets

mark.ie: Drupal Camp Dublin is Next Week - Last Chance for Tickets

Planet Drupal - Wed, 2017-10-11 14:44
Drupal Camp Dublin is Next Week - Last Chance for Tickets

Seems like just yesterday since we held DrupalCon in Dublin, now we're back with our annual Drupal Camp Dublin.

markconroy Wed, 10/11/2017 - 19:44

This year's Drupal Camp Dublin has a great line up of speakers from Ireland and abroad, covering such topics as:

  • Building multi-lingual, multi-region websites (Stella Power)
  • Working as a developer with attention-deficit disorder - add (Levi Govaerts)
  • Planning for disruptions (Jochen Lillich)
  • Migrating from Drupal 4 to 5 to 6 to 7 to 8 (Alan Burke)
  • Automating deployments (Luis Rodriguez)
  • Working webform and commerce and paragraphs and display suites and more (Chandeep Khosa)
  • Live debugging a site that's giving issues (Anthony Lindsay)
  • Deploy with Fabric, and test driven development (Oliver Davies)
  • Design in the Browser (yours truly, me, Mark Conroy)
  • Teaching web development at third level (Ruairi O'Reilly)
  • The QA process (Daniel Shaw)
  • Getting started with Docker (Ed Crompton)
  • The new theme coming to Drupal core (Mark Conroy)

And then there's some socials, and our Drupal Ireland AGM, and at least one other talk not announced yet, and ... you get the idea.

The full schedule is available on our website. There are some tickets left (only €20), get them before they are all gone.

Categories: FLOSS Project Planets

myDropWizard.com: Drupal 6 version of netFORUM Authentication not affected by SA-CONTRIB-2017-077

Planet Drupal - Wed, 2017-10-11 14:37

Today, there was a Moderately Critical security advisory for an Access Bypass vulnerability in the netFORUM Authentication module for Drupal 7:

netFORUM Authentication - Moderately critical - Access Bypass - SA-CONTRIB-2017-077

The module was bypassing protections on the Drupal 7 user login form, to deter brute force attempts to login to the site, and so was an Access Bypass vulnerability by making login less secure when using this module.

However, Drupal 6 (including Pressflow 6) don't have these same protections for the user login form, and so, using this module is no less secure than using vanilla Drupal 6. Of course, these protections could be added to this module, and while this would be great security hardening, this doesn't represent a vulnerability - only a weakness which is also present (and widely known) in Drupal 6 core.

If you'd like all your Drupal 6 modules to receive security updates and have the fixes deployed the same day they're released, please check out our D6LTS plans.

Note: if you use the myDropWizard module (totally free!), you'll be alerted to these and any future security updates, and will be able to use drush to install them (even though they won't necessarily have a release on Drupal.org).

Categories: FLOSS Project Planets

Mediacurrent: Mediacurrent Wins Three Nominations at 2017 Acquia Engage Conference

Planet Drupal - Wed, 2017-10-11 13:21

Mediacurrent has been selected as finalists for the 2017 Acquia Engage Awards in the categories of Financial Services, Travel and Tourism, and Digital Experience. These awards recognize the amazing sites and digital experiences that leading digital agencies are building with the Acquia Platform.

Categories: FLOSS Project Planets

Drupal blog: Drupal looking to adopt React

Planet Drupal - Wed, 2017-10-11 13:05

This blog has been re-posted with permission from Dries Buytaert's blog. Please leave your comments on the original post.

Last week at DrupalCon Vienna, I proposed adding a modern JavaScript framework to Drupal core. After the keynote, I met with core committers, framework managers, JavaScript subsystem maintainers, and JavaScript experts in the Drupal community to discuss next steps. In this blog post, I look back on how things have evolved, since the last time we explored adding a new JavaScript framework to Drupal core two years ago, and what we believe are the next steps after DrupalCon Vienna.

As a group, we agreed that we had learned a lot from watching the JavaScript community grow and change since our initial exploration. We agreed that today, React would be the most promising option given its expansive adoption by developers, its unopinionated and component-based nature, and its well-suitedness to building new Drupal interfaces in an incremental way. Today, I'm formally proposing that the Drupal community adopt React, after discussion and experimentation has taken place.

Two years ago, it was premature to pick a JavaScript framework

Three years ago, I developed several convictions related to "headless Drupal" or "decoupled Drupal". I believed that:

  1. More and more organizations wanted a headless Drupal so they can use a modern JavaScript framework to build application-like experiences.
  2. Drupal's authoring and site building experience could be improved by using a more modern JavaScript framework.
  3. JavaScript and Node.js were going to take the world by storm and that we would be smart to increase the amount of JavaScript expertise in our community.

(For the purposes of this blog post, I use the term "framework" to include both full MV* frameworks such as Angular, and also view-only libraries such as React combined piecemeal with additional libraries for managing routing, states, etc.)

By September 2015, I had built up enough conviction to write several long blog posts about these views (post 1, post 2, post 3). I felt we could accomplish all three things by adding a JavaScript framework to Drupal core. After careful analysis, I recommended that we consider React, Ember and Angular. My first choice was Ember, because I had concerns about a patent clause in Facebook's open-source license (since removed) and because Angular 2 was not yet in a stable release.

At the time, the Drupal community didn't like the idea of picking a JavaScript framework. The overwhelming reactions were these: it's too early to tell which JavaScript framework is going to win, the risk of picking the wrong JavaScript framework is too big, picking a single framework would cause us to lose users that favor other frameworks, etc. In addition, there were a lot of different preferences for a wide variety of JavaScript frameworks. While I'd have preferred to make a bold move, the community's concerns were valid.

Focusing on Drupal's web services instead

By May of 2016, after listening to the community, I changed my approach; instead of adding a specific JavaScript framework to Drupal, I decided we should double down on improving Drupal's web service APIs. Instead of being opinionated about what JavaScript framework to use, we would allow people to use their JavaScript framework of choice.

I did a deep dive on the state of Drupal's web services in early 2016 and helped define various next steps (post 1, post 2, post 3). I asked a few of the OCTO team members to focus on improving Drupal 8's web services APIs; funded improvements to Drupal core's REST API, as well as JSON API, GraphQL and OpenAPI; supported the creation of Waterwheel projects to help bootstrap an ecosystem of JavaScript front-end integrations; and most recently supported the development of Reservoir, a Drupal distribution for headless Drupal. There is also a lot of innovation coming from the community with lots of work on the Contenta distribution, JSON API, GraphQL, and more.

The end result? Drupal's web service APIs have progressed significantly the past year. Ed Faulkner of Ember told us: "I'm impressed by how fast Drupal made lots of progress with its REST API and the JSON API contrib module!". It's a good sign when a core maintainer of one of the leading JavaScript frameworks acknowledges Drupal's progress.

The current state of JavaScript in Drupal

Looking back, I'm glad we decided to focus first on improving Drupal's web services APIs; we discovered that there was a lot of work left to stabilize them. Cleanly integrating a JavaScript framework with Drupal would have been challenging 18 months ago. While there is still more work to be done, Drupal 8's available web service APIs have matured significantly.

Furthermore, by not committing to a specific framework, we are seeing Drupal developers explore a range of JavaScript frameworks and members of multiple JavaScript framework communities consuming Drupal's web services. I've seen Drupal 8 used as a content repository behind Angular, Ember, React, Vue, and other JavaScript frameworks. Very cool!

There is a lot to like about how Drupal's web service APIs matured and how we've seen Drupal integrated with a variety of different frameworks. But there is also no denying that not having a JavaScript framework in core came with certain tradeoffs:

  1. It created a barrier for significantly leveling up the Drupal community's JavaScript skills. In my opinion, we still lack sufficient JavaScript expertise among Drupal core contributors. While we do have JavaScript experts working hard to maintain and improve our existing JavaScript code, I would love to see more experts join that team.
  2. It made it harder to accelerate certain improvements to Drupal's authoring and site building experience.
  3. It made it harder to demonstrate how new best practices and certain JavaScript approaches could be leveraged and extended by core and contributed modules to create new Drupal features.

One trend we are now seeing is that traditional MV* frameworks are giving way to component libraries; most people seem to want a way to compose interfaces and interactions with reusable components (e.g. libraries like React, Vue, Polymer, and Glimmer) rather than use a framework with a heavy focus on MV* workflows (e.g. frameworks like Angular and Ember). This means that my original recommendation of Ember needs to be revisited.

Several years later, we still don't know what JavaScript framework will win, if any, and I'm willing to bet that waiting two more years won't give us any more clarity. JavaScript frameworks will continue to evolve and take new shapes. Picking a single one will always be difficult and to some degree "premature". That said, I see React having the most momentum today.

My recommendations at DrupalCon Vienna

Given that it's been almost two years since I last suggested adding a JavaScript framework to core, I decided to talk bring the topic back in my DrupalCon Vienna keynote presentation. Prior to my keynote, there had been some renewed excitement and momentum behind the idea. Two years later, here is what I recommended we should do next:

  • Invest more in Drupal's API-first initiative. In 2017, there is no denying that decoupled architectures and headless Drupal will be a big part of our future. We need to keep investing in Drupal's web service APIs. At a minimum, we should expand Drupal's web service APIs and standardize on JSON API. Separately, we need to examine how to give API consumers more access to and control over Drupal's capabilities.
  • Embrace all JavaScript frameworks for building Drupal-powered applications. We should give developers the flexibility to use their JavaScript framework of choice when building front-end applications on top of Drupal — so they can use the right tool for the job. The fact that you can front Drupal with Ember, Angular, Vue, React, and others is a great feature. We should also invest in expanding the Waterwheel ecosystem so we have SDKs and references for all these frameworks.
  • Pick a framework for Drupal's own administrative user interfaces. Drupal should pick a JavaScript framework for its own administrative interface. I'm not suggesting we abandon our stable base of PHP code; I'm just suggesting that we leverage JavaScript for the things that JavaScript is great at by moving relevant parts of our code from PHP to JavaScript. Specifically, Drupal's authoring and site building experience could benefit from user experience improvements. A JavaScript framework could make our content modeling, content listing, and configuration tools faster and more application-like by using instantaneous feedback rather than submitting form after form. Furthermore, using a decoupled administrative interface would allow us to dogfood our own web service APIs.
  • Let's start small by redesigning and rebuilding one or two features. Instead of rewriting the entirety of Drupal's administrative user interfaces, let's pick one or two features, and rewrite their UIs using a preselected JavaScript framework. This allows us to learn more about the pros and cons, allows us to dogfood some of our own APIs, and if we ultimately need to switch to another JavaScript framework or approach, it won't be very painful to rewrite or roll the changes back.
Selecting a JavaScript framework for Drupal's administrative UIs

In my keynote, I proposed a new strategic initiative to test and research how Drupal's administrative UX could be improved by using a JavaScript framework. The feedback was very positive.

As a first step, we have to choose which JavaScript framework will be used as part of the research. Following the keynote, we had several meetings at DrupalCon Vienna to discuss the proposed initiative with core committers, all of the JavaScript subsystem maintainers, as well as developers with real-world experience building decoupled applications using Drupal's APIs.

There was unanimous agreement that:

  1. Adding a JavaScript framework to Drupal core is a good idea.
  2. We want to have sufficient real-use experience to make a final decision prior to 8.6.0's development period (Q1 2018). To start, the Watchdog page would be the least intrusive interface to rebuild and would give us important insights before kicking off work on more complex interfaces.
  3. While a few people named alternative options, React was our preferred option, by far, due to its high degree of adoption, component-based and unopinionated nature, and its potential to make Drupal developers' skills more future-proof.
  4. This adoption should be carried out in a limited and incremental way so that the decision is easily reversible if better approaches come later on.

We created an issue on the Drupal core queue to discuss this more.

Conclusion

Drupal should support a variety of JavaScript libraries on the user-facing front end while relying on a single shared framework as a standard across Drupal administrative interfaces.

In short, I continue to believe that adopting more JavaScript is important for the future of Drupal. My original recommendation to include a modern JavaScript framework (or JavaScript libraries) for Drupal's administrative user interfaces still stands. I believe we should allow developers to use their JavaScript framework of choice to build front-end applications on top of Drupal and that we can start small with one or two administrative user interfaces.

After meeting with core maintainers, JavaScript subsystem maintainers, and framework managers at DrupalCon Vienna, I believe that React is the right direction to move for Drupal's administrative interfaces, but we encourage everyone in the community to discuss our recommendation. Doing so would allow us to make Drupal easier to use for site builders and content creators in an incremental and reversible way, keep Drupal developers' skills relevant in an increasingly JavaScript-driven world, move us ahead with modern tools for building user interfaces.

Special thanks to Preston So for contributions to this blog post and to Matt Grill, Wim Leers, Jason Enter, Gábor Hojtsy, and Alex Bronstein for their feedback during the writing process.

Categories: FLOSS Project Planets

Lonely Cactus: 10/11/2017

GNU Planet! - Wed, 2017-10-11 13:00
One of my favorite pastimes is imagining and planning to write new coding projects: researching technologies, checking out libraries I might use, making GUI mockups, downloading similar projects.

I was thinking the other day that it might be fun to create a desktop-based editor that had an HTTP server embedded.  The HTTP server would serve up only one document, which is the document being currently edited, and it would show a live representation of the screen as being show the person editing the document.

I was thinking it might be fun to re-implement the old HyperCard system.

I was thinking that it might be fun to make a real-time chat client/server, like the old talkd daemon did on consoles back in the day.  The client would show every character being typed, in real time, instead of line by line.

I was thinking it might be fun to make a collaboratively editable mosaic: a million tiles across by a million tiles wide, where each tile is 16 pixels square.  Anyone could make new tiles and could place them anywhere on the grid.

I was thinking that it might be fun to make a webpage whose primary purpose was to annoy the server operator.  The webpage would have buttons to make silly noises on the server machine, and the webcam on the server machine would capture pictures of the operator being annoyed and place them on the webpage.

I was thinking it would be fun to make a Twitter bot, that automatically searches for and retweets controversial statements, but, changing key words to make them more benign and playful.

I was thinking that it might be fun to make a Christian devotional app that keeps the list of the ~600 New Testament commandments and chooses one at random for someone to follow on any given day.  Also it could chime for Matins, Sext, Vespers, and Compline.

I was thinking it might be good to make an app for depressed and despairing people. Upon logging in, you could write about your struggle, and after submitting, you'd receive an anonymized note that someone else had written about their struggle.

Categories: FLOSS Project Planets

FSF Blogs: Update on Artifex v. Hancom GNU GPL compliance case

GNU Planet! - Wed, 2017-10-11 12:30

A new ruling was issued on September 25th in the ongoing GNU General Public License (GPL) compliance case of Artifex v. Hancom. The case involves a piece of software licensed under the GPL version 3 or later, called Ghostscript. It is a project from Artifex for handling PostScript, PDFs, and printers (GNU Ghostscript is a separate version of the project, and is not involved or implicated in the case). As we wrote previously:

In its suit, Artifex claimed two counts based on Hancom's inclusion of Ghostscript: (1) a violation of copyright; and (2) a breach of contract based on the GPL. ... While a violation of a free license giving rise to a copyright violation is now old hat, whether violation of a license like the GPL could be treated as a breach of contract has been long a topic of discussion among licensing geeks.

In the previous ruling, the judge in the case had denied a motion to dismiss those claims, allowing the case to proceed. We've now reached the next step in the suit, involving a motion for summary judgment on the contract claim, which was also denied. In a motion to dismiss, the court assumes the truth of the allegations involved and rules on whether such allegations actually present a valid legal claim. In summary judgment, the court is asked to look at the undisputed facts and determine whether the outcome is so obvious that the matter need not go through a full trial. Such motions are routine, but making it past summary judgment does mean that the issue of recovery under contract theory is still alive in this case.

Hancom here made several arguments against the contract claim, but one is of particular interest. Hancom argued that if any contract claim is allowed, damages should only be considered prior to the date of their initial violation. They argued that since the violation terminated their license, the contract also ended at that point. The judge noted that:

the language of the GPL suggests that Defendant’s obligations persisted beyond termination of its rights to propagate software using Ghostscript ... because the source code or offer of the source code is required each time a “covered work” is conveyed, each time Defendant distributed a product using Ghostscript there was arguably an ensuing obligation to provide or offer to provide the source code.

The judge also found that there was insufficient evidence at this point to rule on this issue, so we can't read too much into it. But the judge's thoughts on how conditions of the GPL persist after a violation is an important clue on how this issue could develop as the case proceeds. Although the GPL does not need to be upheld as a contract in order to protect user freedom -- it has worked successfully as a copyright license for decades -- procedural rulings like this are just more evidence that claims about it not standing up in court or being easy to defeat are baseless fear-mongering.

With summary judgment denied, the case will move forward, and will be very interesting to watch. To keep up to date on this case and more:

  • Subscribe to our Free Software Supporter mailing list to keep up to date on the latest in the free software licensing world.
  • Follow our Licensing & Compliance blog via rss
  • Donate or become an associate member to help support our licensing team.
Categories: FLOSS Project Planets

Update on Artifex v. Hancom GNU GPL compliance case

FSF Blogs - Wed, 2017-10-11 12:30

A new ruling was issued on September 25th in the ongoing GNU General Public License (GPL) compliance case of Artifex v. Hancom. The case involves a piece of software licensed under the GPL version 3 or later, called Ghostscript. It is a project from Artifex for handling PostScript, PDFs, and printers (GNU Ghostscript is a separate version of the project, and is not involved or implicated in the case). As we wrote previously:

In its suit, Artifex claimed two counts based on Hancom's inclusion of Ghostscript: (1) a violation of copyright; and (2) a breach of contract based on the GPL. ... While a violation of a free license giving rise to a copyright violation is now old hat, whether violation of a license like the GPL could be treated as a breach of contract has been long a topic of discussion among licensing geeks.

In the previous ruling, the judge in the case had denied a motion to dismiss those claims, allowing the case to proceed. We've now reached the next step in the suit, involving a motion for summary judgment on the contract claim, which was also denied. In a motion to dismiss, the court assumes the truth of the allegations involved and rules on whether such allegations actually present a valid legal claim. In summary judgment, the court is asked to look at the undisputed facts and determine whether the outcome is so obvious that the matter need not go through a full trial. Such motions are routine, but making it past summary judgment does mean that the issue of recovery under contract theory is still alive in this case.

Hancom here made several arguments against the contract claim, but one is of particular interest. Hancom argued that if any contract claim is allowed, damages should only be considered prior to the date of their initial violation. They argued that since the violation terminated their license, the contract also ended at that point. The judge noted that:

the language of the GPL suggests that Defendant’s obligations persisted beyond termination of its rights to propagate software using Ghostscript ... because the source code or offer of the source code is required each time a “covered work” is conveyed, each time Defendant distributed a product using Ghostscript there was arguably an ensuing obligation to provide or offer to provide the source code.

The judge also found that there was insufficient evidence at this point to rule on this issue, so we can't read too much into it. But the judge's thoughts on how conditions of the GPL persist after a violation is an important clue on how this issue could develop as the case proceeds. Although the GPL does not need to be upheld as a contract in order to protect user freedom -- it has worked successfully as a copyright license for decades -- procedural rulings like this are just more evidence that claims about it not standing up in court or being easy to defeat are baseless fear-mongering.

With summary judgment denied, the case will move forward, and will be very interesting to watch. To keep up to date on this case and more:

  • Subscribe to our Free Software Supporter mailing list to keep up to date on the latest in the free software licensing world.
  • Follow our Licensing & Compliance blog via rss
  • Donate or become an associate member to help support our licensing team.
Categories: FLOSS Project Planets

Michal Čihař: New projects on Hosted Weblate

Planet Debian - Wed, 2017-10-11 12:00

Hosted Weblate provides also free hosting for free software projects. The hosting requests queue has grown too long, so it's time to process it and include new project.

This time, the newly hosted projects include:

  • Hunspell - famous spell checker
  • Eolie - a web browser for GNOME
  • SkyTube - an open-source YouTube app for Android
  • Eventum - issue tracking system

Additionally there were some notable additions to existing projects:

If you want to support this effort, please donate to Weblate, especially recurring donations are welcome to make this service alive. You can do that easily on Liberapay or Bountysource.

Filed under: Debian English SUSE Weblate

Categories: FLOSS Project Planets

Krita 3.3.1

Planet KDE - Wed, 2017-10-11 03:47

Today we are releasing Krita 3.3.1, a bugfix release for Krita 3.3.0. This release fixes two important regressions:

  • Krita would crash if you would restart Krita after closing Krita with the reference images docker set to floating
  • Krita 3.3.0 could not read .kra backup files or .kra files that were unzipped, then zipped up manually.

Additionally, there are the following fixes and improvements:

  • Fix a crash when creating a swap file on OSX (Bernhard Liebl).
  • Merge down does not remove locked layers anymore (Nikita Smirnov)
  • Various performance improvements, especially for macOS (Bernhard Liebl)
  • Improve the look and feel of dragging and dropping layers (Bernhard Liebl)
  • Improve the tooltips in the brush preset selector (Bernhard Liebl)
  • Fix a memory leak in the color selectors (Boudewijn Rempt)
  • Fix rotation and tilt when using the Windows Ink api (Alvin Wong)
  • Don’t allow the fill tool to be used on group layers (Boudewijn Rempt)
  • Add brightness and contrast sliders for textured brushes (Rad)
  • Add paste-at-cursor (Dmitry Kazakov)
  • Improve performance of the cpu canvas (Alvin Wong)
  • Fix a crash on closing Krita when there is something on the clipboard (Dmitry Kazakov)
  • Add a button to open a file layer’s image in Krita (Wolthera van Hövell tot Westerflier)
Download Windows

Note for Windows users: if you encounter crashes, please follow these instructions to use the debug symbols so we can figure out where Krita crashes.

Linux

(If, for some reason, Firefox thinks it needs to load this as text: to download, right-click on the link.)

When it is updated, you can also use the Krita Lime PPA to install Krita 3.3.1 on Ubuntu and derivatives. There is also an updated snap.

OSX

Note: the gmic-qt and pdf plugins are not available on OSX.

Source code md5sums

For all downloads:

Key

The Linux appimage and the source tarball are signed. You can retrieve the public key over https here:
0x58b9596c722ea3bd.asc
. The signatures are here.

Support Krita

Krita is a free and open source project. Please consider supporting the project with donations or by buying training videos or the artbook! With your support, we can keep the core team working on Krita full-time.

Categories: FLOSS Project Planets

Bryan Pendleton: WC 2018 ? Not this year, I guess.

Planet Apache - Tue, 2017-10-10 22:31

I can't say this was a total stunner, but still: USA Stunned by Trinidad and Tobago, Eliminated From World Cup Contention

The nightmare scenario has played out for the U.S. men's national team.

A roller coaster of a qualifying campaign ended in shambles, with a stunning 2-1 loss to Trinidad & Tobago, coupled with wins by Panama and Honduras over Costa Rica and Mexico, respectively, has eliminated the USA from the World Cup. The Americans will not be playing in Russia next summer.

Trinidad and Tobago, which hadn't won in its last nine matches (0-8-1), exacted revenge for the 1989 elimination at the hands of the United States, doing so in stunning fashion. An own goal from Omar Gonzalez and a rocket from Alvin Jones provided the offense, while Christian Pulisic's second-half goal wasn't enough to save the Americans.

Oh, my.

And it seems like there's a fair chance I won't be able to root for Leo Messi, either?

Well, what shall I do?

Let's see: there's still Iceland! They're easy to root for!

Perhaps Wales? Perhaps Costa Rica? Perhaps Chile?

I'm ready, I'm an eager Yankee, looking for a team with some charisma, some elan, some heart, some fighting spirit.

Where are you? Are you out there?

It's still a few weeks until the tournament qualifications are known.

I guess I've got time to start looking...

Categories: FLOSS Project Planets
Syndicate content