Slashdot Mirror

New submitter alfino writes: Less than two weeks away, DebConf15, the 16th Debian Conference, scheduled to take place 15–22 August in Heidelberg, Germany, has been officially announced. The organisers are expecting more than 550 participants from 53 countries (making it the largest DebConf so far, and the first in history that will be closing registrations early), and have presented a schedule packed with talks and events, including several prominent, invited speakers, and yet plenty of room for informal and ad-hoc collaboration. Most events will be streamed live to allow for remote participation, and archived for later consumption.

The celebrations of Debian's 22nd birthday on 16 August, the traditional "Cheese & Wine BoF", a screening of the Oscar-award-winning documentary Citizenfour (which mentions Debian in its end credits), and a day trip for all attendees top off the programme. Additionally, DebConf15 will be preceeded by DebCamp, a week of sprints, workshops and hacking sessions. It is expected that much progress will be made on Debian (gcc5 transition, planning of the next stable release "stretch", etc.), and of course Free Software in general. The conference itself begins with an Open Weekend geared to the public, and featuring a job fair.

Attendance is free of charge thanks to numerous sponsors, including Platinum Sponsor Hewlett-Packard. Registration is required nonetheless and only very few places are left.

The conference will be tracked on various social media sites using hashtag #DebConf15. Even though Debian does not endorse proprietary services, @DebConf will have the news.

jones_supa writes: SPARC isn't exactly a highly-used architecture anymore, so the Debian operating system is dropping support for the platform, according to Joerg Jaspert last week in the "debian-sparc" mailing list. He noted that this does not block a later comeback as "sparc64." Following that announcement, a new post today tells us that SPARC support was just removed from the unstable, experimental and jessie-updates channels.

jones_supa writes: SPARC isn't exactly a highly-used architecture anymore, so the Debian operating system is dropping support for the platform, according to Joerg Jaspert last week in the "debian-sparc" mailing list. He noted that this does not block a later comeback as "sparc64." Following that announcement, a new post today tells us that SPARC support was just removed from the unstable, experimental and jessie-updates channels.

An anonymous reader writes: Google has fallen under criticism for including a compiled audio-monitoring binary in Chromium for Debian. A report was logged at Debian's bug register on Tuesday noting the presence of a non-auditable 'hotword' module in Chromium 43. The module facilitates Google's "OK, Google" functionality, which listens for that phrase via a Chrome user's microphone and attempts afterwards to interpret the user's instructions as a search query. Matt Giuca from the Chromium development team responded after the furore developed, disclaiming Google from any responsibility from auditing Chromium code, but promising clearer controls over the feature in release 45.

prisoninmate writes: The Debian Project has announced the immediate availability of the first maintenance release of Debian GNU/Linux 8 (Jessie). As expected, Debian GNU/Linux 8.1 comes with a new Linux kernel, version 3.16.7-ctk11, which fixes the well-known EXT4 data corruption issue caused by delayed and unwritten extents, blacklists queued TRIM on Samsung 850 Pro SSDs, adds support for XHCI on APM Mustang USB, and updates Crucial/Micron blacklist in libata.

An anonymous reader sends this announcement from the debian-hurd mailing list: It is with huge pleasure that the Debian GNU/Hurd team announces the release of Debian GNU/Hurd 2015. This is a snapshot of Debian "sid" at the time of the stable Debian "jessie" release (April 2015), so it is mostly based on the same sources. It is not an official Debian release, but it is an official Debian GNU/Hurd port release. The installation ISO images can be downloaded from Debian Ports in the usual three Debian flavors: NETINST, CD, or DVD. Besides the friendly Debian installer, a pre-installed disk image is also available there, making it even easier to try Debian GNU/Hurd. The easiest way to run it is inside a VM such as qemu.

An anonymous reader sends this announcement from the debian-hurd mailing list: It is with huge pleasure that the Debian GNU/Hurd team announces the release of Debian GNU/Hurd 2015. This is a snapshot of Debian "sid" at the time of the stable Debian "jessie" release (April 2015), so it is mostly based on the same sources. It is not an official Debian release, but it is an official Debian GNU/Hurd port release. The installation ISO images can be downloaded from Debian Ports in the usual three Debian flavors: NETINST, CD, or DVD. Besides the friendly Debian installer, a pre-installed disk image is also available there, making it even easier to try Debian GNU/Hurd. The easiest way to run it is inside a VM such as qemu.

linuxscreenshot writes: After almost 24 months of constant development, the Debian project is proud to present its new stable version 8 (code name Jessie), which will be supported for the next five years thanks to the combined work of the Debian Security team and the Debian Long Term Support team. (Release notes.) Jessie ships with a new default init system, systemd. The systemd suite provides features such as faster boot times, cgroups for services, and the possibility of isolating part of the services. The sysvinit init system is still available in Jessie. Screenshots and a screencast are available.

linuxscreenshot writes: After almost 24 months of constant development, the Debian project is proud to present its new stable version 8 (code name Jessie), which will be supported for the next five years thanks to the combined work of the Debian Security team and the Debian Long Term Support team. (Release notes.) Jessie ships with a new default init system, systemd. The systemd suite provides features such as faster boot times, cgroups for services, and the possibility of isolating part of the services. The sysvinit init system is still available in Jessie. Screenshots and a screencast are available.

An anonymous reader writes Google's Chrome/Chromium web browser does not support slightly older versions of the Linux kernel anymore. Linux 3.17 is now the minimum requirement. According to a thread on the Debian mailing list, a kernel feature called TSYNC is what makes the difference. When a backported patch for the Debian 8 kernel was requested, there were hostile replies about not wanting to support "Google spyware."

paskie writes: Voting on a Debian General Resolution that would require packagers to maintain support even for systems not running systemd ended tonight with the resolution failing to gather enough support.

This means that some Debian packages could require users to run systemd on their systems in theory — however, in practice Debian still works fine without systemd (even with e.g. GNOME) and this will certainly stay the case at least for the next stable release Jessie.

However, the controversial general resolution proposed late in the development cycle opened many wounds in the community, prompting some prominent developers to resign or leave altogether, stirring strong emotions — not due to adoption of systemd per se, but because of the emotional burn-out and shortcomings in the decision processes apparent in the wake of the systemd controversy.

Nevertheless, work on the next stable release is well underway and some developers are already trying to mend the community and soothe the wounds.

paskie writes: Voting on a Debian General Resolution that would require packagers to maintain support even for systems not running systemd ended tonight with the resolution failing to gather enough support.

This means that some Debian packages could require users to run systemd on their systems in theory — however, in practice Debian still works fine without systemd (even with e.g. GNOME) and this will certainly stay the case at least for the next stable release Jessie.

However, the controversial general resolution proposed late in the development cycle opened many wounds in the community, prompting some prominent developers to resign or leave altogether, stirring strong emotions — not due to adoption of systemd per se, but because of the emotional burn-out and shortcomings in the decision processes apparent in the wake of the systemd controversy.

Nevertheless, work on the next stable release is well underway and some developers are already trying to mend the community and soothe the wounds.

paskie writes: Voting on a Debian General Resolution that would require packagers to maintain support even for systems not running systemd ended tonight with the resolution failing to gather enough support.

This means that some Debian packages could require users to run systemd on their systems in theory — however, in practice Debian still works fine without systemd (even with e.g. GNOME) and this will certainly stay the case at least for the next stable release Jessie.

However, the controversial general resolution proposed late in the development cycle opened many wounds in the community, prompting some prominent developers to resign or leave altogether, stirring strong emotions — not due to adoption of systemd per se, but because of the emotional burn-out and shortcomings in the decision processes apparent in the wake of the systemd controversy.

Nevertheless, work on the next stable release is well underway and some developers are already trying to mend the community and soothe the wounds.

paskie writes: Voting on a Debian General Resolution that would require packagers to maintain support even for systems not running systemd ended tonight with the resolution failing to gather enough support.

This means that some Debian packages could require users to run systemd on their systems in theory — however, in practice Debian still works fine without systemd (even with e.g. GNOME) and this will certainly stay the case at least for the next stable release Jessie.

However, the controversial general resolution proposed late in the development cycle opened many wounds in the community, prompting some prominent developers to resign or leave altogether, stirring strong emotions — not due to adoption of systemd per se, but because of the emotional burn-out and shortcomings in the decision processes apparent in the wake of the systemd controversy.

Nevertheless, work on the next stable release is well underway and some developers are already trying to mend the community and soothe the wounds.

paskie writes: Voting on a Debian General Resolution that would require packagers to maintain support even for systems not running systemd ended tonight with the resolution failing to gather enough support.

This means that some Debian packages could require users to run systemd on their systems in theory — however, in practice Debian still works fine without systemd (even with e.g. GNOME) and this will certainly stay the case at least for the next stable release Jessie.

However, the controversial general resolution proposed late in the development cycle opened many wounds in the community, prompting some prominent developers to resign or leave altogether, stirring strong emotions — not due to adoption of systemd per se, but because of the emotional burn-out and shortcomings in the decision processes apparent in the wake of the systemd controversy.

Nevertheless, work on the next stable release is well underway and some developers are already trying to mend the community and soothe the wounds.

paskie writes: Voting on a Debian General Resolution that would require packagers to maintain support even for systems not running systemd ended tonight with the resolution failing to gather enough support.

This means that some Debian packages could require users to run systemd on their systems in theory — however, in practice Debian still works fine without systemd (even with e.g. GNOME) and this will certainly stay the case at least for the next stable release Jessie.

However, the controversial general resolution proposed late in the development cycle opened many wounds in the community, prompting some prominent developers to resign or leave altogether, stirring strong emotions — not due to adoption of systemd per se, but because of the emotional burn-out and shortcomings in the decision processes apparent in the wake of the systemd controversy.

Nevertheless, work on the next stable release is well underway and some developers are already trying to mend the community and soothe the wounds.

paskie writes: Voting on a Debian General Resolution that would require packagers to maintain support even for systems not running systemd ended tonight with the resolution failing to gather enough support.

This means that some Debian packages could require users to run systemd on their systems in theory — however, in practice Debian still works fine without systemd (even with e.g. GNOME) and this will certainly stay the case at least for the next stable release Jessie.

However, the controversial general resolution proposed late in the development cycle opened many wounds in the community, prompting some prominent developers to resign or leave altogether, stirring strong emotions — not due to adoption of systemd per se, but because of the emotional burn-out and shortcomings in the decision processes apparent in the wake of the systemd controversy.

Nevertheless, work on the next stable release is well underway and some developers are already trying to mend the community and soothe the wounds.

paskie writes: Voting on a Debian General Resolution that would require packagers to maintain support even for systems not running systemd ended tonight with the resolution failing to gather enough support.

This means that some Debian packages could require users to run systemd on their systems in theory — however, in practice Debian still works fine without systemd (even with e.g. GNOME) and this will certainly stay the case at least for the next stable release Jessie.

However, the controversial general resolution proposed late in the development cycle opened many wounds in the community, prompting some prominent developers to resign or leave altogether, stirring strong emotions — not due to adoption of systemd per se, but because of the emotional burn-out and shortcomings in the decision processes apparent in the wake of the systemd controversy.

Nevertheless, work on the next stable release is well underway and some developers are already trying to mend the community and soothe the wounds.

paskie writes: Voting on a Debian General Resolution that would require packagers to maintain support even for systems not running systemd ended tonight with the resolution failing to gather enough support.

This means that some Debian packages could require users to run systemd on their systems in theory — however, in practice Debian still works fine without systemd (even with e.g. GNOME) and this will certainly stay the case at least for the next stable release Jessie.

However, the controversial general resolution proposed late in the development cycle opened many wounds in the community, prompting some prominent developers to resign or leave altogether, stirring strong emotions — not due to adoption of systemd per se, but because of the emotional burn-out and shortcomings in the decision processes apparent in the wake of the systemd controversy.

Nevertheless, work on the next stable release is well underway and some developers are already trying to mend the community and soothe the wounds.

paskie writes: Voting on a Debian General Resolution that would require packagers to maintain support even for systems not running systemd ended tonight with the resolution failing to gather enough support.

This means that some Debian packages could require users to run systemd on their systems in theory — however, in practice Debian still works fine without systemd (even with e.g. GNOME) and this will certainly stay the case at least for the next stable release Jessie.

However, the controversial general resolution proposed late in the development cycle opened many wounds in the community, prompting some prominent developers to resign or leave altogether, stirring strong emotions — not due to adoption of systemd per se, but because of the emotional burn-out and shortcomings in the decision processes apparent in the wake of the systemd controversy.

Nevertheless, work on the next stable release is well underway and some developers are already trying to mend the community and soothe the wounds.

paskie writes: Voting on a Debian General Resolution that would require packagers to maintain support even for systems not running systemd ended tonight with the resolution failing to gather enough support.

This means that some Debian packages could require users to run systemd on their systems in theory — however, in practice Debian still works fine without systemd (even with e.g. GNOME) and this will certainly stay the case at least for the next stable release Jessie.

However, the controversial general resolution proposed late in the development cycle opened many wounds in the community, prompting some prominent developers to resign or leave altogether, stirring strong emotions — not due to adoption of systemd per se, but because of the emotional burn-out and shortcomings in the decision processes apparent in the wake of the systemd controversy.

Nevertheless, work on the next stable release is well underway and some developers are already trying to mend the community and soothe the wounds.

paskie writes: Voting on a Debian General Resolution that would require packagers to maintain support even for systems not running systemd ended tonight with the resolution failing to gather enough support.

This means that some Debian packages could require users to run systemd on their systems in theory — however, in practice Debian still works fine without systemd (even with e.g. GNOME) and this will certainly stay the case at least for the next stable release Jessie.

However, the controversial general resolution proposed late in the development cycle opened many wounds in the community, prompting some prominent developers to resign or leave altogether, stirring strong emotions — not due to adoption of systemd per se, but because of the emotional burn-out and shortcomings in the decision processes apparent in the wake of the systemd controversy.

Nevertheless, work on the next stable release is well underway and some developers are already trying to mend the community and soothe the wounds.

paskie writes: Voting on a Debian General Resolution that would require packagers to maintain support even for systems not running systemd ended tonight with the resolution failing to gather enough support.

This means that some Debian packages could require users to run systemd on their systems in theory — however, in practice Debian still works fine without systemd (even with e.g. GNOME) and this will certainly stay the case at least for the next stable release Jessie.

However, the controversial general resolution proposed late in the development cycle opened many wounds in the community, prompting some prominent developers to resign or leave altogether, stirring strong emotions — not due to adoption of systemd per se, but because of the emotional burn-out and shortcomings in the decision processes apparent in the wake of the systemd controversy.

Nevertheless, work on the next stable release is well underway and some developers are already trying to mend the community and soothe the wounds.

An anonymous reader writes Debian developer Tollef Fog Heen submitted his resignation to the Debian Systemd package maintainers team mailing list today (Sun. Nov. 16th, 2014). In his brief post, he praises the team, but claims that he cannot continue to contribute due to the "load of continued attacks...becoming just too much." Presumably, he is referring to the heated and, at times, even vitriolic criticism of Debian's adoption of Systemd as the default init system for its upcoming Jessie release from commenters inside and outside of the Debian community. Currently, it is not known if Tollef will cease contributing to Debian altogether. A message from his twitter feed indicates that he may blog about his departure in the near future.

An anonymous reader writes: Long-time Debian developer Joey Hess has posted a resignation letter to the Debian mailing list. Hess was a big part of the development of the Debian installer, debhelper, Alien, and other systems. He says, "It's become abundantly clear that this is no longer the project I originally joined in 1996. We've made some good things, and I wish everyone well, but I'm out. ... If I have one regret from my 18 years in Debian, it's that when the Debian constitution was originally proposed, despite seeing it as dubious, I neglected to speak out against it. It's clear to me now that it's a toxic document, that has slowly but surely led Debian in very unhealthy directions."

New submitter Tsolias writes It appears that systemd is still a hot topic in the Debian community. As seen earlier today, there is a new movement shaping up against the adoption of systemd for the upcoming stable release [of Debian], Jessie. They claim that "systemd betrays the UNIX philosophy"; it makes things more complex, thus breaking the "do one thing and do it well" principle. Note that the linked Debian Fork page specifically says that the anonymous developers behind it support a proposal to preserve options in init systems, rather than demanding the removal of systemd, and are not opposed to change per se. They just don't want other parts of the system to be wholly dependent on systemd. "We contemplate adopting more recent alternatives to sysvinit, but not those undermining the basic design principles of "do one thing and do it well" with a complex collection of dozens of tightly coupled binaries and opaque logs."

An anonymous reader writes: A couple of months ago the technical committee for Debian decided in favor of systemd. This is now a subject for discussion once again, and Ian Jackson says he wants a general resolution, so every developer within the Debian project can decide. After a short time, the required amount of supporters was reached, and the discussion can start once again.

kdryer39 sends this news from CSO: A remotely exploitable vulnerability has been discovered by Stephane Chazelas in bash on Linux, and it is unpleasant. The vulnerability has the CVE identifier CVE-2014-6271. This affects Debian as well as other Linux distributions. The major attack vectors that have been identified in this case are HTTP requests and CGI scripts. Another attack surface is OpenSSH through the use of AcceptEnv variables. Also through TERM and SSH_ORIGINAL_COMMAND. An environmental variable with an arbitrary name can carry a nefarious function which can enable network exploitation.

An anonymous reader writes: Debian will switch back to using GNOME as the default desktop environment for the upcoming Debian 8.0 Jessie release, due out in 2015. The decision is based on accessibility and systemd integration, along with a host of other reasons. Debian switched away from GNOME back in 2012 .

An anonymous reader writes: Debian will switch back to using GNOME as the default desktop environment for the upcoming Debian 8.0 Jessie release, due out in 2015. The decision is based on accessibility and systemd integration, along with a host of other reasons. Debian switched away from GNOME back in 2012 .

First time accepted submitter systemDead (3645325) writes "I looked mostly with disinterest at Debian's decision last February to switch to systemd as the default init system for their future operating system releases. The Debian GNU/Linux distribution is, after all, famous for allowing users greater freedom to choose what system components they want to install. This appeared to be the case with the init system, given the presence of packages such as sysvinit-core, upstart, and even openrc as alternatives to systemd.

Unfortunately, while still theoretically possible, installing an alternative init system means doing without a number of useful, even essential system programs. By design, systemd appears to be a full-blown everything-including-the-kitchen-sink solution to the relatively simple problem of starting up a Unix-like system. Systemd, for example, is a hard-coded dependency for installing Network Manager, probably the most user-friendly way for a desktop Linux system to connect to a wireless or wired network. Just this week, I woke up to find out that systemd had become a dependency for running PolicyKit, the suite of programs responsible for user privileges and permissions in a typical Linux desktop.

I was able to replace Network Manager with connman, a lightweight program originally developed for mobile devices. But with systemd infecting even the PolicyKit framework, I find myself faced with a dilemma. Should I just let systemd take over my entire system, or should I retreat to my old terminal-based computing in the hope that the horde of the systemDead don't take over the Linux kernel itself?

What are your plans for working with or working around systemd? Are there any mainstream GNU/Linux distros that haven't adopted and have no plans of migrating to systemd? Or is migrating to one of the bigger BSD systems the better and more future-proof solution?"

First time accepted submitter systemDead (3645325) writes "I looked mostly with disinterest at Debian's decision last February to switch to systemd as the default init system for their future operating system releases. The Debian GNU/Linux distribution is, after all, famous for allowing users greater freedom to choose what system components they want to install. This appeared to be the case with the init system, given the presence of packages such as sysvinit-core, upstart, and even openrc as alternatives to systemd.

Unfortunately, while still theoretically possible, installing an alternative init system means doing without a number of useful, even essential system programs. By design, systemd appears to be a full-blown everything-including-the-kitchen-sink solution to the relatively simple problem of starting up a Unix-like system. Systemd, for example, is a hard-coded dependency for installing Network Manager, probably the most user-friendly way for a desktop Linux system to connect to a wireless or wired network. Just this week, I woke up to find out that systemd had become a dependency for running PolicyKit, the suite of programs responsible for user privileges and permissions in a typical Linux desktop.

I was able to replace Network Manager with connman, a lightweight program originally developed for mobile devices. But with systemd infecting even the PolicyKit framework, I find myself faced with a dilemma. Should I just let systemd take over my entire system, or should I retreat to my old terminal-based computing in the hope that the horde of the systemDead don't take over the Linux kernel itself?

What are your plans for working with or working around systemd? Are there any mainstream GNU/Linux distros that haven't adopted and have no plans of migrating to systemd? Or is migrating to one of the bigger BSD systems the better and more future-proof solution?"

First time accepted submitter systemDead (3645325) writes "I looked mostly with disinterest at Debian's decision last February to switch to systemd as the default init system for their future operating system releases. The Debian GNU/Linux distribution is, after all, famous for allowing users greater freedom to choose what system components they want to install. This appeared to be the case with the init system, given the presence of packages such as sysvinit-core, upstart, and even openrc as alternatives to systemd.

Unfortunately, while still theoretically possible, installing an alternative init system means doing without a number of useful, even essential system programs. By design, systemd appears to be a full-blown everything-including-the-kitchen-sink solution to the relatively simple problem of starting up a Unix-like system. Systemd, for example, is a hard-coded dependency for installing Network Manager, probably the most user-friendly way for a desktop Linux system to connect to a wireless or wired network. Just this week, I woke up to find out that systemd had become a dependency for running PolicyKit, the suite of programs responsible for user privileges and permissions in a typical Linux desktop.

I was able to replace Network Manager with connman, a lightweight program originally developed for mobile devices. But with systemd infecting even the PolicyKit framework, I find myself faced with a dilemma. Should I just let systemd take over my entire system, or should I retreat to my old terminal-based computing in the hope that the horde of the systemDead don't take over the Linux kernel itself?

What are your plans for working with or working around systemd? Are there any mainstream GNU/Linux distros that haven't adopted and have no plans of migrating to systemd? Or is migrating to one of the bigger BSD systems the better and more future-proof solution?"

First time accepted submitter systemDead (3645325) writes "I looked mostly with disinterest at Debian's decision last February to switch to systemd as the default init system for their future operating system releases. The Debian GNU/Linux distribution is, after all, famous for allowing users greater freedom to choose what system components they want to install. This appeared to be the case with the init system, given the presence of packages such as sysvinit-core, upstart, and even openrc as alternatives to systemd.

Unfortunately, while still theoretically possible, installing an alternative init system means doing without a number of useful, even essential system programs. By design, systemd appears to be a full-blown everything-including-the-kitchen-sink solution to the relatively simple problem of starting up a Unix-like system. Systemd, for example, is a hard-coded dependency for installing Network Manager, probably the most user-friendly way for a desktop Linux system to connect to a wireless or wired network. Just this week, I woke up to find out that systemd had become a dependency for running PolicyKit, the suite of programs responsible for user privileges and permissions in a typical Linux desktop.

I was able to replace Network Manager with connman, a lightweight program originally developed for mobile devices. But with systemd infecting even the PolicyKit framework, I find myself faced with a dilemma. Should I just let systemd take over my entire system, or should I retreat to my old terminal-based computing in the hope that the horde of the systemDead don't take over the Linux kernel itself?

What are your plans for working with or working around systemd? Are there any mainstream GNU/Linux distros that haven't adopted and have no plans of migrating to systemd? Or is migrating to one of the bigger BSD systems the better and more future-proof solution?"

First time accepted submitter systemDead (3645325) writes "I looked mostly with disinterest at Debian's decision last February to switch to systemd as the default init system for their future operating system releases. The Debian GNU/Linux distribution is, after all, famous for allowing users greater freedom to choose what system components they want to install. This appeared to be the case with the init system, given the presence of packages such as sysvinit-core, upstart, and even openrc as alternatives to systemd.

Unfortunately, while still theoretically possible, installing an alternative init system means doing without a number of useful, even essential system programs. By design, systemd appears to be a full-blown everything-including-the-kitchen-sink solution to the relatively simple problem of starting up a Unix-like system. Systemd, for example, is a hard-coded dependency for installing Network Manager, probably the most user-friendly way for a desktop Linux system to connect to a wireless or wired network. Just this week, I woke up to find out that systemd had become a dependency for running PolicyKit, the suite of programs responsible for user privileges and permissions in a typical Linux desktop.

I was able to replace Network Manager with connman, a lightweight program originally developed for mobile devices. But with systemd infecting even the PolicyKit framework, I find myself faced with a dilemma. Should I just let systemd take over my entire system, or should I retreat to my old terminal-based computing in the hope that the horde of the systemDead don't take over the Linux kernel itself?

What are your plans for working with or working around systemd? Are there any mainstream GNU/Linux distros that haven't adopted and have no plans of migrating to systemd? Or is migrating to one of the bigger BSD systems the better and more future-proof solution?"

First time accepted submitter systemDead (3645325) writes "I looked mostly with disinterest at Debian's decision last February to switch to systemd as the default init system for their future operating system releases. The Debian GNU/Linux distribution is, after all, famous for allowing users greater freedom to choose what system components they want to install. This appeared to be the case with the init system, given the presence of packages such as sysvinit-core, upstart, and even openrc as alternatives to systemd.

Unfortunately, while still theoretically possible, installing an alternative init system means doing without a number of useful, even essential system programs. By design, systemd appears to be a full-blown everything-including-the-kitchen-sink solution to the relatively simple problem of starting up a Unix-like system. Systemd, for example, is a hard-coded dependency for installing Network Manager, probably the most user-friendly way for a desktop Linux system to connect to a wireless or wired network. Just this week, I woke up to find out that systemd had become a dependency for running PolicyKit, the suite of programs responsible for user privileges and permissions in a typical Linux desktop.

I was able to replace Network Manager with connman, a lightweight program originally developed for mobile devices. But with systemd infecting even the PolicyKit framework, I find myself faced with a dilemma. Should I just let systemd take over my entire system, or should I retreat to my old terminal-based computing in the hope that the horde of the systemDead don't take over the Linux kernel itself?

What are your plans for working with or working around systemd? Are there any mainstream GNU/Linux distros that haven't adopted and have no plans of migrating to systemd? Or is migrating to one of the bigger BSD systems the better and more future-proof solution?"

Eben Moglen's FreedomBox concept (personal servers for everyone to enable private communication) is getting closer to being an easy-to-install reality: all packages needed for FreedomBox are now in Debian's unstable branch, and should be migrating to testing in a week or two. Quoting Petter Reinholdtsen: "Today, the last of the packages currently used by the project to created the system images were accepted into Debian Unstable. It was the freedombox-setup package, which is used to configure the images during build and on the first boot. Now all one need to get going is the build code from the freedom-maker git repository and packages from Debian. And once the freedombox-setup package enter testing, we can build everything directly from Debian. :) Some key packages used by Freedombox are freedombox-setup, plinth, pagekite, tor, privoxy, owncloud, and dnsmasq. There are plans to integrate more packages into the setup. User documentation is maintained on the Debian wiki." You can create your own image with only three commands, at least if you have a DreamPlug or Raspberry Pi (you could also help port it to other platforms).

Eben Moglen's FreedomBox concept (personal servers for everyone to enable private communication) is getting closer to being an easy-to-install reality: all packages needed for FreedomBox are now in Debian's unstable branch, and should be migrating to testing in a week or two. Quoting Petter Reinholdtsen: "Today, the last of the packages currently used by the project to created the system images were accepted into Debian Unstable. It was the freedombox-setup package, which is used to configure the images during build and on the first boot. Now all one need to get going is the build code from the freedom-maker git repository and packages from Debian. And once the freedombox-setup package enter testing, we can build everything directly from Debian. :) Some key packages used by Freedombox are freedombox-setup, plinth, pagekite, tor, privoxy, owncloud, and dnsmasq. There are plans to integrate more packages into the setup. User documentation is maintained on the Debian wiki." You can create your own image with only three commands, at least if you have a DreamPlug or Raspberry Pi (you could also help port it to other platforms).

Eben Moglen's FreedomBox concept (personal servers for everyone to enable private communication) is getting closer to being an easy-to-install reality: all packages needed for FreedomBox are now in Debian's unstable branch, and should be migrating to testing in a week or two. Quoting Petter Reinholdtsen: "Today, the last of the packages currently used by the project to created the system images were accepted into Debian Unstable. It was the freedombox-setup package, which is used to configure the images during build and on the first boot. Now all one need to get going is the build code from the freedom-maker git repository and packages from Debian. And once the freedombox-setup package enter testing, we can build everything directly from Debian. :) Some key packages used by Freedombox are freedombox-setup, plinth, pagekite, tor, privoxy, owncloud, and dnsmasq. There are plans to integrate more packages into the setup. User documentation is maintained on the Debian wiki." You can create your own image with only three commands, at least if you have a DreamPlug or Raspberry Pi (you could also help port it to other platforms).

Eben Moglen's FreedomBox concept (personal servers for everyone to enable private communication) is getting closer to being an easy-to-install reality: all packages needed for FreedomBox are now in Debian's unstable branch, and should be migrating to testing in a week or two. Quoting Petter Reinholdtsen: "Today, the last of the packages currently used by the project to created the system images were accepted into Debian Unstable. It was the freedombox-setup package, which is used to configure the images during build and on the first boot. Now all one need to get going is the build code from the freedom-maker git repository and packages from Debian. And once the freedombox-setup package enter testing, we can build everything directly from Debian. :) Some key packages used by Freedombox are freedombox-setup, plinth, pagekite, tor, privoxy, owncloud, and dnsmasq. There are plans to integrate more packages into the setup. User documentation is maintained on the Debian wiki." You can create your own image with only three commands, at least if you have a DreamPlug or Raspberry Pi (you could also help port it to other platforms).

An anonymous reader writes "For the last 6 weeks the Debian developers have had an election to determine the new Debian Project Leader. The election is now over and Lucas Nussbaum was re-elected. As always in Debian, the result of the voting was found using the Condorcet method."

An anonymous reader writes "For the last 6 weeks the Debian developers have had an election to determine the new Debian Project Leader. The election is now over and Lucas Nussbaum was re-elected. As always in Debian, the result of the voting was found using the Condorcet method."

An anonymous reader writes "For the last 6 weeks the Debian developers have had an election to determine the new Debian Project Leader. The election is now over and Lucas Nussbaum was re-elected. As always in Debian, the result of the voting was found using the Condorcet method."

Bismillah (993337) writes "A potentially very serious bug in OpenSSL 1.0.1 and 1.0.2 beta has been discovered that can leak just about any information, from keys to content. Better yet, it appears to have been introduced in 2011, and known since March 2012." Quoting the security advisory: "A missing bounds check in the handling of the TLS heartbeat extension can be used to reveal up to 64k of memory to a connected client or server." The attack may be repeated and it appears trivial to acquire the host's private key. If you were running a vulnerable release, it is even suggested that you go as far as revoking all of your keys. Distributions using OpenSSL 0.9.8 are not vulnerable (Debian Squeeze vintage). Debian Wheezy, Ubuntu 12.04.4, Centos 6.5, Fedora 18, SuSE 12.2, OpenBSD 5.4, FreeBSD 8.4, and NetBSD 5.0.2 and all following releases are vulnerable. OpenSSL released 1.0.1g today addressing the vulnerability. Debian's fix is in incoming and should hit mirrors soon, Fedora is having some trouble applying their patches, but a workaround patch to the package .spec (disabling heartbeats) is available for immediate application.

Via Bits from Debian, comes news that the security team is considering adding a Long Term Support suite for Squeeze (Debian 6) after Jessie (Debian 8) is released sometime next year. From the mailing list post: "At the moment it seems likely that an extended security support timespan for squeeze is possible. The plan is to go ahead, sort out the details as as it happens, and see how this works out and whether it is going to be continued with wheezy. The rough draft is that updates will be delivered via a separate suite (e.g. squeeze-lts), where everyone in the Debian keyring can upload in order to minimise bottlenecks and allow contributions by all interested parties. Some packages will be exempted upfront due to their volatile nature (e.g. some web applications) and others might be expected to see important changes. The LTS suite will be limited to amd64 and i386. The exact procedures will be sorted out soon and announced in a separate mail. ... It needs to be pointed out that for this effort to be sustainable actual contributions by interested parties are required. squeeze-lts is not something that will magically fall from the sky. If you're dependent/interested in extended security support you should make an effort to contribute." If successful, the LTS idea would possibly be carried over to Wheezy. With all of the changes coming in Jessie and its aggressive release schedule, this sysadmin really likes the idea of having a bit more breathing room for updating infrastructure between releases. The email also contains a bunch of other info on changes coming to the security process.

In related news, the Debian Installer team announced the first alpha of debian-installer for Jessie. Just the installer, not the distro as a whole (Jessie will be frozen in November). XFCE remains the default desktop, ia64 was kicked out of the archive, and a few new ARM variants are supported.

Via Bits from Debian, comes news that the security team is considering adding a Long Term Support suite for Squeeze (Debian 6) after Jessie (Debian 8) is released sometime next year. From the mailing list post: "At the moment it seems likely that an extended security support timespan for squeeze is possible. The plan is to go ahead, sort out the details as as it happens, and see how this works out and whether it is going to be continued with wheezy. The rough draft is that updates will be delivered via a separate suite (e.g. squeeze-lts), where everyone in the Debian keyring can upload in order to minimise bottlenecks and allow contributions by all interested parties. Some packages will be exempted upfront due to their volatile nature (e.g. some web applications) and others might be expected to see important changes. The LTS suite will be limited to amd64 and i386. The exact procedures will be sorted out soon and announced in a separate mail. ... It needs to be pointed out that for this effort to be sustainable actual contributions by interested parties are required. squeeze-lts is not something that will magically fall from the sky. If you're dependent/interested in extended security support you should make an effort to contribute." If successful, the LTS idea would possibly be carried over to Wheezy. With all of the changes coming in Jessie and its aggressive release schedule, this sysadmin really likes the idea of having a bit more breathing room for updating infrastructure between releases. The email also contains a bunch of other info on changes coming to the security process.

In related news, the Debian Installer team announced the first alpha of debian-installer for Jessie. Just the installer, not the distro as a whole (Jessie will be frozen in November). XFCE remains the default desktop, ia64 was kicked out of the archive, and a few new ARM variants are supported.

Via Bits from Debian, comes news that the security team is considering adding a Long Term Support suite for Squeeze (Debian 6) after Jessie (Debian 8) is released sometime next year. From the mailing list post: "At the moment it seems likely that an extended security support timespan for squeeze is possible. The plan is to go ahead, sort out the details as as it happens, and see how this works out and whether it is going to be continued with wheezy. The rough draft is that updates will be delivered via a separate suite (e.g. squeeze-lts), where everyone in the Debian keyring can upload in order to minimise bottlenecks and allow contributions by all interested parties. Some packages will be exempted upfront due to their volatile nature (e.g. some web applications) and others might be expected to see important changes. The LTS suite will be limited to amd64 and i386. The exact procedures will be sorted out soon and announced in a separate mail. ... It needs to be pointed out that for this effort to be sustainable actual contributions by interested parties are required. squeeze-lts is not something that will magically fall from the sky. If you're dependent/interested in extended security support you should make an effort to contribute." If successful, the LTS idea would possibly be carried over to Wheezy. With all of the changes coming in Jessie and its aggressive release schedule, this sysadmin really likes the idea of having a bit more breathing room for updating infrastructure between releases. The email also contains a bunch of other info on changes coming to the security process.

In related news, the Debian Installer team announced the first alpha of debian-installer for Jessie. Just the installer, not the distro as a whole (Jessie will be frozen in November). XFCE remains the default desktop, ia64 was kicked out of the archive, and a few new ARM variants are supported.

Via Bits from Debian, comes news that the security team is considering adding a Long Term Support suite for Squeeze (Debian 6) after Jessie (Debian 8) is released sometime next year. From the mailing list post: "At the moment it seems likely that an extended security support timespan for squeeze is possible. The plan is to go ahead, sort out the details as as it happens, and see how this works out and whether it is going to be continued with wheezy. The rough draft is that updates will be delivered via a separate suite (e.g. squeeze-lts), where everyone in the Debian keyring can upload in order to minimise bottlenecks and allow contributions by all interested parties. Some packages will be exempted upfront due to their volatile nature (e.g. some web applications) and others might be expected to see important changes. The LTS suite will be limited to amd64 and i386. The exact procedures will be sorted out soon and announced in a separate mail. ... It needs to be pointed out that for this effort to be sustainable actual contributions by interested parties are required. squeeze-lts is not something that will magically fall from the sky. If you're dependent/interested in extended security support you should make an effort to contribute." If successful, the LTS idea would possibly be carried over to Wheezy. With all of the changes coming in Jessie and its aggressive release schedule, this sysadmin really likes the idea of having a bit more breathing room for updating infrastructure between releases. The email also contains a bunch of other info on changes coming to the security process.

In related news, the Debian Installer team announced the first alpha of debian-installer for Jessie. Just the installer, not the distro as a whole (Jessie will be frozen in November). XFCE remains the default desktop, ia64 was kicked out of the archive, and a few new ARM variants are supported.

sfcrazy writes "Bdale Garbee,chairman of the Debian Technical Committee, called for a ballot from the TC to chose the default init system. The votes are in systemd is the clear winner here. Bdale himself voted for systemd."

sfcrazy writes "Valve Software, the makers of Steam OS, is already winning praise from the larger free and open source community – mainly because of their pro-community approach. Now the company is 'giving back' to Debian by offering free subscription to Debian developers. This subscription will offer full access to current and future games produced by Valve. Since Steam OS is based on Debian GNU/Linux it's a nice way for Valve to say 'thank you' to Debian developers."