A service capable of socket activation must be able to receive its preinitialized sockets from systemd, instead of creating them internally. For most services this requires (minimal) patching. However, since systemd actually provides inetd compatibility a service working with inetd will also work with systemd -- which is quite useful for services like sshd for example.
While the Linux 3.17 kernel isn't being released for a few weeks, we already have a good idea for the DRM graphics driver improvements coming for the Linux 3.18 cycle.
Linux 3.17 has many new features, including many DRM graphics improvements, with Linux 3.18 there's of course more changes to get excited about; it's a never-ending cycle in improving Linux graphics drivers and the kernel stack as a whole. With Linux 3.18 though, it's going to be the first release where the drm-next merge window is closing early. Usually David Airlie, the DRM subsystem maintainer, allows new DRM graphics driver code to be introduced up until the start of the next kernel merge window, with that drm-next code-base then being sent in for mainline inclusion. Beginning with Linux 3.18, Airlie is planning to close the merge window of drm-next around the -rc5 state of the previous release. As a result, this week is likely the last that major new DRM graphics driver code has a chance to land for making the 3.18 window.
GNU/Linux is winning pretty much everywhere these days - well, aside from the desktop. On supercomputers, mobiles and embedded devices it dominates completely, but in the world of enterprise computing, where it has certainly done well, there's room for it to take further market share. How might it do that? One of the huge advantages that free software has over traditional closed source programs is that new companies can take existing code and come up with exciting new solutions very quickly, without the need for massive and long drawn-out research and development programs.
With X.Org Server 1.16 having landed in Ubuntu 14.10, it's time for some benchmarks comparing the 1.15 and 1.16 releases on Ubuntu while using the GLAMOR 2D acceleration library.
For some basic X.Org 2D benchmarks I tested a Radeon HD 7950 and R7 260X while running various Linux 2D desktop benchmarks on Ubuntu 14.10 with the Linux 3.16 kernel and Mesa 10.4-devel. In testing the two graphics cards, I was using X.Org Server 1.15.1 that was previously found in the Ubuntu Utopic archive and then switched to X.Org Server 1.16.0 with the rebuilt DDX driver packages too.
There is one truth that all the Linux faithful hold near and dear to their hearts -- that Linux is a leader when it comes to innovation. No other platform has been able to stake that claim for such a long period of time. Even when a different platform unveils something new, many times that innovation can be traced back to Linux.
One such technology is the convergent desktop. The idea behind the convergent desktop is simple -- a seamless transition from mobile to desktop (or laptop). This all started, for better or worse, with Ubuntu Edge. The idea behind Ubuntu Edge was brilliant: A high-end smartphone that, when plugged into a dock, would serve as a traditional desktop. Although the project ultimately failed (due to an inability to raise the $32 million dollars necessary to bring Ubuntu Edge to life), the idea stuck and now every platform is in a race to deliver the convergent desktop.
This ends up being a pain in the neck in the x86 world, but it could be much worse. Way back in 2008 I wrote something about why the Linux kernel reports itself to firmware as "Windows" but refuses to identify itself as Linux. The short version is that "Linux" doesn't actually identify the behaviour of the kernel in a meaningful way. "Linux" doesn't tell you whether the kernel can deal with buffers being passed when the spec says it should be a package. "Linux" doesn't tell you whether the OS knows how to deal with an HPET. "Linux" doesn't tell you whether the OS can reinitialise graphics hardware.