Search Results: "ed"

26 January 2014

Daniel Pocock: Beyond init systems: other opportunities for simplification

One thing that everybody agrees on in the debate about Debian's init system replacement is that the manifests used by most of the new schemes are far more concise than traditional init scripts. Simplification need not stop there however. Another opportunity for simplification exists in the creation of users at package installation. Every packaging tool has a different approach and all of them involve multiple lines of boilerplate script code duplicated between hundreds of packages that all need exactly the same thing. What is worse, embedding this logic into the postinst scripts on Debian or %post logic of an RPM makes it far more awkard for a system administrator to audit the user account requirements of packages (when installing many of them in a hurry) or to customise the logic for a whole site without rebuilding the whole packages. Potential improvement How to improve this? Well, packages (on any distribution) could be invited to declare the user and group accounts they depend on. A central configuration parameter in /etc/dpkg/dpkg.cfg or /etc/rpm would then control how the package manager behaves, with several possible options:
  • Create users/groups on demand without prompting
  • Abort installation/configuration of any package if the pre-requisite users do not exist on the system
  • Prompt: at the beginning of any package install, ask the administrator to create the users himself before proceeding, with an option to abort and potentially displaying some convenient LDIF fragments and other samples that the administrator can cut and paste.
Running a command like apt-get --simulate would give a system administrator an immediate view of all users/groups required by the packages they propose to install.

Matthias Klumpp: Next stop: FOSDEM 14

After years of missing this conference, I will finally make it to Brussels this time! I will even have some talks, one about Listaller (in the lightning-talks section) and one about AppStream and Listaller in the Distributions track. The lightning-talk will explain why distributing (some) applications independent from the distribution makes sense, and how Listaller does this. I will also very briefly talk about the concepts behind Listaller and which tools it offers for application developers to create & package cross-distro apps. The AppStream & Listaller talk will be much more detailed. It will cover the rationale for AppStream, what AppData is good for and how AppData files relate to AppStream. I will also reflect the AppData adoption in GNOME/Fedora and why GNOME-Software is the right way to go forward in developing software-centers. It will of course also include our future plans for AppStream. On the Listaller side, I will talk about how Listaller is connected to AppStream and PackageKit and why distributions should ship a way to install cross-distro packaged apps at all. I will explain module-definitions and why they are useful. An overview of the internals of Listaller and it s system integration is also included, as well as how it can be compared to competing installation solutions. If you are at FOSDEM and have questions about AppStream/PackageKit/Listaller/Tanglu/Debian/etc., please ask them! ;-) See you there! FOSDEM

Dirk Eddelbuettel: RcppClassic 0.9.5

A maintenance release of RcppClassic, now at version 0.9.5, went out to CRAN today. Nothing changed in user-facing code. The build was triggered by a change in an upcoming Rcpp release (more about that another time), and a few minor updates were needed for extended checks done by R. Courtesy of CRANberries, there is the set of changes relative to the previous release 0.9.4. 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.

25 January 2014

Ben Hutchings: Looking back on my time at Solarflare, part 1

Friday was my last day at Solarflare Communications, which I joined in 2006 (originally as Level 5 Networks). When I started, Level 5 Networks (L5N) had a 2-port gigabit Ethernet controller called EF1 and a user-level network stack called EtherFabric which ran on Linux. It had nearly completed the Falcon project to develop a 10-gigabit controller (also supporing a 2-port gigabit mode) and was porting EtherFabric to Windows. Later that year, however, L5N merged with Solarflare Communications (SF), which was developing a 10GBASE-T PHY (for 10-gigabit Ethernet over twisted-pair cables). The investors and management saw the opportunity to create an integrated 10GBASE-T LAN-on-motherboard chip that would be attractive to OEMs and so had the potential for mass sales. EtherFabric was put on the back-burner, but regular net drivers for Linux, Windows and other operating systems became more important. In a change from my previous jobs, my initial role at L5N was to maintain and extend the in-house test automation software, Runbench, written in Python. I worked with Dickon Reed who had written most of Runbench up to then. One of my first major tasks was to extend it to cover DUTs running Windows. Aside from changing Runbench itself, I wrote a simple SSH server to be installed on DUTs, using the Twisted.Python framework. (Cygwin's port of OpenSSH wasn't suitable for running a lot of native Windows commands.) I rewrote the test-installation script for the Windows driver itself, converting it to Python (with a C extension to get around the WOW64 nonsense). As Windows does not allow loading a driver just once (like insmod in Linux), except by using the kernel debugger, I added a time check in the driver so the test-installation script can make it fail early when reloaded after a reboot, so that a crasher bug in the probe path would usually be recoverable. In 2007 I persuaded management in Cambridge to loan several older servers to DebConf. I took them there and back by car, and they were used to convert video for live streams and recordings. (This was repeated in 2009.) I was also asked to work on other small development tasks, including some cleanup on the Linux net driver (sfc). In mid-2007, when SF decided it was time to get sfc upstream (in-tree), I joined Steve Hodgson and Robert Stonehouse in working on that. Out-of-tree (separately distributed) drivers for Linux normally need a large number of preprocessor conditions for compatibility with Linux's kernel module API across a range of supported versions. They may also implement some features with a driver-specific interface that should be replaced with a standard interface (possibly including the work to define that standard). They may not comply with the kernel coding style or unwritten conventions for kernel code. All of these problems were present and had to be dealt with. As part of this work, I extended unifdef so that it could be used to remove all of the backward-compatibility and not-for-upstream code without introducing extra blank lines. I could then export the out-of-tree driver from CVS(!) into a kernel source tree automatically and turn it into a patch or patch series that would stand a chance of being acceptable upstream. Our first few attempts got little response, but eventually we newbies got the message that the driver was simply too big for a single submission and that putting patches on a web site because they're too big for the list was not a solution. In the next week, I removed about half of the code (on a git branch), resulting in a relatively lean driver that could be sent to the netdev list. And finally the 9th (I think) submission was accepted. Following this, I continued to work on sfc but was also brought into the Siena project. Siena (SFL9021) was the LAN-on-motherboard chip that had been planned following the merger. It combined a dual-port controller based on Falcon with a 10GBASE-T PHY and a management controller (MC) to support Lights-Out Management (LOM). (Since 10GBASE-T has not taken off, it is now mostly sold as the SFC9020 variant in which the PHY is disabled.) I worked on some of the test framework and test cases for validating the controller design in software simulation and FPGA. In the course of this I learned to read and (somewhat) understand the chip design written in Verilog, but only made a single trivial fix to it. In August 2009, the first Siena ASICs came back from the fab. There were a few ASIC-specific bugs but all of them were quickly worked around in firmware, so it would soon be ready for production. But there was much work still to be done on the driver and firmware. The firmware had until then been running in a smaller block of RAM with no peripherals to manage, while sfc had earlier been modified just enough to configure a sim or FPGA for running a userland test application. sfc now had many special cases scattered around it, and would tell the MC firmware to peek and poke registers that were no longer directly accessible from the host. The software and firmware developers had agreed that, in order to support LOM, the MC would be responsible for managing the ports and all peripherals and drivers would send higher-level requests to the MC. As a bonus, this removed the need for the driver to know the details of each new board, so that it would not be necessary to backport sfc into distribution kernels very often. Over the next few months, the firmware team did an excellent job of defining and implementing those operations, including writing the driver-side functions to invoke them. Meanwhile, Steve and I concentrated on refactoring sfc so most of the Falcon/Siena differences could be abstracted through a few structures with function pointers. The refactoring and new code for Siena were completed and submitted upstream in several large patch series in October and November. In fact, there were so many patches that Solarflare appeared in LWN's table of who wrote Linux 2.6.33 (as did I, thanks also to another patch series adding firmware metadata to many drivers). Sadly we had missed Linux 2.6.32 which was a longterm stable branch and used in many distributions, but I was able to get this version backported into all the major distributions over the next year. (To be continued.)

Russell Coker: Links January 2014

Fast Coexist has an interesting article about the art that Simon Beck creates by walking in snow [1]. If you are an artist you can create art in any way, even by walking in patterns in the snow. Russ Altman gave an interesting TED talk about using DNA testing before prescribing drugs [2]. I was surprised by the amount of variation in effects of codeine based on genetics, presumably many other drugs have a similar range. Helen Epstein wrote an interesting article about Dr. Sara Josephine Baker who revolutionised child care and saved the lives of a huge number of children [3]. Her tenacity is inspiring. Also it s interesting to note that the US Republican party was awful even before the Southern Strategy . The part about some doctors opposing child care because it s the will of God for children to die and keep them in employment is chilling. Jonathan Weiler wrote an insightful article about the problems with American journalism in defending the government [4]. He criticises the media for paying more attention to policing decorum than to content. Tobias Buckell wrote an interesting post about the so-called socialised health-care in the US [5]. He suggests that Ronald Reagan socialised health-care by preventing hospitals from dumping dying people on the street. I guess if doing nothing for people until they have a medical emergency counts as socialised health-care then the US has it. Kelvin Thomson MP made some insightful comments about climate change, the recent heat-wave in Australia, and renewable energy [6]. Iwan Baan gave an interesting TED talk about ways that people have built cheap homes in unexpected places [7], lots of good pictures. Racialicious has an interesting article by Arturo R. Garc a about research into the effects of concussion and the way the NFL in the US tried to prevent Dr. Bennet Omalu publicising the results of his research [8]. Stani (Jan Schmidt) wrote an interesting post about how they won a competition to design a commemerative Dutch 5 Euro coin [9]. The coin design is really good (a candidate for the geekiest coin ever), I want one! Seriously if anyone knows how to get one at a reasonable price (IE close to face value for circulated or not unreasonably expensive for uncirculated) then please let me know. When writing about Edward Snowden, Nathan says Imagine how great a country would be if if it were governed entirely by people who Dick Cheney would call Traitor [10]. That s so right, that might make the US a country I d be prepared to live in. Andrew Solomon gave an interesting TED talk Love No Matter What about raising different children [11]. Aditi Shankardass gave an interesting TED talk about using an ECG to analyse people diagnosed wit severe Autism and other developmental disorders [12]. Apparently some severe cases of Autism have a root cause that can be treated with anti-seizure medication. George Monbiot wrote an insightful article about the way that Bono and Bob Geldoff promote G8 government intervention in Africa and steal air-time that might be given to allow Africans to represent themselves in public debates [13]. Daniel Pocock wrote an informative article about racism in Australian politics and how it is bad for job-seekers and the economy (in addition to being horribly wrong) [14]. Aeon Magazine has an interesting article by Anne Buchanan about the difference between scientists and farmers [15]. She has some interesting points about the way that the lack of general knowledge impacts research, but misses the point that in most fields of study there is a huge problem of people not knowing about recent developments in their own field. I don t think it s a pipe dream to be well educated in humanities and science, but I guess that depends on the definition of well educated . Brian Cox gave an interesting TED talk titled Why We Need the Explorers about the benefits of scientific research [16]. Yupu Zhang, Abhishek Rajimwale, Andrea C. Arpaci-Dusseau, and Remzi H. Arpaci-Dusseau from the University of Wisconsin-Madison wrote an interesting paper about ZFS corruption in the face of disk and memory errors [17]. One thing to note is that turning off atime can reduce the probability of a memory error leading to corrupt data being written to disk, run zfs set atime=off tank to fix this. The comedian Solomon Georgio celebrated Martin Luther King day by tweeting I love you to racists [18]. It s an interesting approach and appears to have worked well.

24 January 2014

Paul Tagliamonte: Thanks, Valve (thalve)

I took Valve s offer up (by way of the kickass Collabora folks) for some games. I can confirm that I got them, and it looks like it s working great. Just want to give a shout-out and express my gratitude. I know it s not something they had to do, so it s super cool that they wanted to. Thalve!

Erich Schubert: Definition of Data Science

Everything is "big data" now, and everything is "data science". Because these terms lack a proper, falsifiable definition.
A number of attempts to define them exist, but they usually only consist of a number of "nice to haves" strung together. For Big Data, it's the 3+ V's, and for Data Science, this diagram on Wikipedia is a typical example.
This is not surprising: effectively these term are all marketing, not scientific attempts at definiting a research domain.
Actually, my favorite definition is this, except that it should maybe read pink pony in the middle, instead of unicorn.
Data science has been called "the sexiest job" so often, this has recently led to an integer overflow.
The problem with these definitions is that they are open-ended. They name some examples (like "volume") but they essentially leave it open to call anything "big data" or "data science" that you would like to. This is, of course, a marketers dream buzzword. There is nothing saying that "picking my nose" is not big data science.

If we ever want to get to a usable definition and get rid of all the hype, we should consider a more precise definition; even when this means making it more exclusive (funnily enough, some people already called above open-ended definitions "elitist" ...).
Big data:
  • Must involve distributed computation on multiple servers
  • Must intermix computation and data management
  • Must advance over the state-of-the-art of relational databases, data warehousing and cloud computing in 2005
  • Must enable results that were unavailable with earlier approaches, or that would take substantially longer (runtime or latency)
  • Must be disruptively more data-driven
Data science:
  • Must incorporate domain knowledge (e.g. business, geology, etc.).
  • Must take computational aspects into account (scalability etc.).
  • Must involve scientific techniques such as hypothesis testing and result validation.
  • Results must be falsifiable.
  • Should involve more mathematics and statistics than earlier approaches.
  • Should involve more data management than earlier approaches (indexing, sketching&hashing etc.).
  • Should involve machine learning, AI or knowledge discovery algorithms.
  • Should involve visualization and rapid prototyping for software development.
  • Must satisfy at least one of these shoulds in a disruptive level.
But this is all far from a proper definition. Partially because these fields are so much in flux; but largely because they're just too ill-defined.
There is a lot of overlap, that we should try to flesh out. For example, data science is not just statistics. Because it is much more concerned with how data is organized and how the computations can be made efficiently. Yet often, statistics is much better at integrating domain knowledge. People coming from computation, on the other hand, usually care too little about the domain knowledge and falsifiability of their results - they're happy if they can compute anything.
Last but not least, nobody will be in favor of such a rigid definition and requirements. Because most likely, you will have to strip that "data scientist" label off your business card - and why bite the hand that feeds? Most of what I do certainly would not qualify as data science or big data anymore with an "elitist" definition. While this doesn't lessen my scientific results, it makes them less marketable.
Essentially, this is like a global "gentlemans agreement". Buzz these words while they last, then move on to the next similar "trending topic".

Maybe we should just leave these terms to the marketing folks, and let them bubble them till it bursts. Instead, we should just stick to the established and better defined terms...
Thank you.
Of course, sometimes you will have to play Buzzword Bingo. Nobody is going to stop you. But I will understand that you are doing "playing buzzword bingo", unless you get more precise.
Once you then have results that are so massively better, and really disrupted science, then you can still call it "data science" later on.
You have been seeing, I've been picking on the word "disruptive" a lot. As long as you are doing "business as usual", and focusing on off-the-shelf solution, it will not be disruptive. And it then won't be big data science, or a big data approach that yields major gains. It will be just "business as usual" with different labels, and return results as usual.
Let's face it. We don't just want big data or data science. What everybody is looking for is disruptive results, which will require a radical approach, not a slight modification involving slightly more computers of what you have been doing all along.

Gerfried Fuchs: Julia Engelmann

This is something different. It is something special. She is something special. I don't even remember how I stumbled upon her, actually. I think it was some suggested video somehow. I feel deeply sorry for those who don't understand German. But that's the way it is, the text is in German. And it's touching. Take your time, listen to it in a relaxed environment, when you don't have any distraction. There you are. And I'm sorry for those who don't understand German, but I don't want to hold this back from the others. And I am definitely looking forward to hear more from her. Hopefully she helps me motivate myself to write something new for the upcoming debconf and hold yet another poetry night there. And hopefully it also motivates others to join in.

/haiku permanent link Comments: 0 Flattr this

Julien Danjou: OpenStack Ceilometer Icehouse-2 milestone released

Yesterday, the second milestone of the Icehouse development branch of Ceilometer has been released and is now available for testing and download. This means the first half of the OpenStack Icehouse development has passed! New features For the Icehouse-1 milestone, we barely had enough time to implement 2 blueprints. We almost did a better job this time, but finally only 2 blueprints were implemented again. This is really far from what we planned initially. The infrastructure slowdown issues and the lower number of reviews is probably the root cause here. Anyway, Ceilometer now offers a REST API to accesses the stored event. The initial work to replace the /v2/meters endpoint with something more RESTy has started with the implementation of /v2/samples. Bug fixes Thirty-one bugs were fixed, though most of them might not interest you so I won't elaborate too much on that. Go read the list if you are curious. Toward Icehouse 3 We now have 29 blueprints targeting the Ceilometer's third Icehouse milestone, with some of them are already started and ready to merge. However, it's likely that we won't make all of them. As usual, the priority should indicate how confident we are that we want and need a feature. Still, it's likely the roadmap will be adjusted in the upcoming weeks. I'll try to make sure we'll get there without too much trouble for the 6th March 2013. Stay tuned!

Daniel Pocock: DruCall updated, Lumicall talk at FOSDEM next weekend

The latest version of DruCall is now pushed to the Drupal Git Repository. As described previously, this version uses JSCommunicator (which is based on the popular JsSIP) as the underlying phone framework. I would be very grateful if somebody from the Drupal community could kindly help my projects escape from the sandbox. Try the new Drucall, free calls to mobiles running Lumicall As a demo of the power of SIP and DruCall, you can make free calls to mobiles running Lumicall. It will also dial any number registered in ENUM. Lumicall, the open alternative to Viber, FOSDEM 2014 I'll be giving a talk about the Lumicall project at FOSDEM 2014. The talk is at 13:00 on Sunday, 2 February in the Embedded and Mobile devroom. As space is usually limited in the devrooms and FOSDEM is a completely free event without any advance registration, please arrive early (maybe even 1 or 2 talks before mine) to get a seat.

23 January 2014

John Goerzen: Why and how to run ZFS on Linux

I m writing a bit about ZFS these days, and I thought I d write a bit about why I am using it, why it might or might not be interesting for you, and what you might do about it. ZFS Features and Background ZFS is not just a filesystem in the traditional sense, though you can use it that way. It is an integrated storage stack, which can completely replace the need for LVM, md-raid, and even hardware RAID controllers. This permits quite a bit of flexibility and optimization not present when building a stack involving those components. For instance, if a drive in a RAID fails, it needs only rebuild the parts that have actual data stored on them. Let s look at some of the features of ZFS: Although it is often considered a server filesystem, ZFS has been used in plenty of other situations for some time now, with ports to FreeBSD, Linux, and MacOS. I find it particularly useful: The added level of security in having cheap snapshots available is almost worth it by itself. ZFS drawbacks Compared to other Linux filesystems, there are a few drawbacks of ZFS: Converting to ZFS I have written up an extensive HOWTO on converting an existing system to use ZFS. It covers workarounds for all the boot-time bugs I have encountered as well as documenting all steps needed to make it happen. It works quite well. Additional Hints If setting up zvols to be used by VirtualBox or some such system, you might be interested in managing zvol ownership and permissions with udev.

Gunnar Wolf: Ligatured iceweasel

Ligatured iceweasel
I am not (yet?) reporting this as a bug as this happened with a several days old session open, and just while I was upgrading my Sid system, after a long time without doing so (probably since before the vacations started... In December 2013). But I cannot avoid sharing this interesting screenshot. Of course, this does not happen in other browsers. And AFAICT it only happens while reading the Debian Policy (either online or locally, even recoding it to UTF-8). Funniest thing, the Debian policy specifies no Javascript, no stylesheets at all... (Hey, and FWIW... Why is the online copy of the Debian policy still in iso-8859-1 It's not 1995 anymore...) [update] Of course, it's the default font, not only the Debian policy. Just as an example, the following text:
  1. <html><body><p>Ufffiii flat different!</p></body></html>
Yields the following output: [update 2] And, of course, after finishing the update process... I got a new version of Iceweasel. Restarted it, and everything is back to normal :-

Daniel Pocock: Test numbers for SIP and WebRTC

Want to test or troubleshoot WebRTC calling or SIP calling without bothering anybody? Now there are some test numbers you can call by just clicking in your desktop or mobile web browser. This can give you instant feedback about whether your SIP device, sound drivers, softphone and/or browser are in a good state. If using WebRTC, you can make calls to this service while studying the JavaScript console logs in your browser to see exactly how the protocol works. I hope this well help further increase the rate of positive outcomes for RTC projects using free software and open standards. Please feel free to provide any feedback about this service.

Keith Packard: Altos1.3.1

AltOS 1.3.1 Bug fixes and improved APRS support Bdale and I are pleased to announce the release of AltOS version 1.3.1. AltOS is the core of the software for all of the Altus Metrum products. It consists of firmware for our cc1111, STM32L151, LPC11U14 and ATtiny85 based electronics and Java-based ground station software. This is a minor release of AltOS, including bug fixes for TeleMega, TeleMetrum v2.0 and AltosUI . AltOS Firmware Antenna down fixed and APRS improved Firmware version 1.3 has a bug in the support for operating the flight computer with the antenna facing downwards; the accelerometer calibration data would be incorrect. Furthermore, the accelerometer self-test routine would be confused if the flight computer were moved in the first second after power on. The firmware now simply re-tries the self-test several times. I went out and bought a real APRS radio, the Yaesu FT1D to replace my venerable VX 7R. With this in hand, I changed our APRS support to use the compressed position format, which takes fewer bytes to send, offers increased resolution and includes altitude data. I took the altitude data out of the comment field and replaced that with battery and igniter voltages. This makes APRS reasonably useful in pad mode to monitor the state of the flight computer before boost. Anyone with a TeleMega should update to the new firmware eventually, although there aren t any critical bug fixes here, unless you re trying to operate the device with the antenna pointing downwards. AltosUI TeleMega support and offline map loading improved. I added all of the new TeleMega sensor data as possible elements in the graph. This lets you see roll rates and horizontal acceleration values for the whole flight. The Fire Igniter dialog now lists all of the TeleMega extra pyro channels so you can play with those on the ground as well. Our offline satellite images are downloaded from Google, but they restrict us to reading 50 images per minute. When we tried to download a 9x9 grid of images to save for later use on the flight line, Google would stop feeding us maps after the first 50. You d have to poke the button a second time to try and fill in the missing images. We fixed this by just limiting how fast we load maps, and now we can reliably load an 11x11 grid of images. Of course, there are also a few minor bug fixes, so it s probably worth updating even if the above issues don t affect you.

22 January 2014

Bartosz Fe&#324;ski: gift for Debian Developers from Valve

Nice gift from Valve to Debian Developers although when I m reading first reactions on #debian-devel I expect this to be bigger flamewar than systemd/upstart battle ;)

Clint Adams: December 2013 debian-keyring analysis

Total keys: 996
Key versions:
    996 4
Primary key pubkey algorithms:
    623 "DSA"
    373 "RSA"
Primary key pubkey sizes:
    624 1024
     27 2048
      2 3072
    340 4096
      2 8192
      1 10240
Total number of UIDs + UAts: 4394
Hash algorithm used for most recent self-sig:
      1 "RIPEMD160"
   3188 "SHA1"
   1041 "SHA256"
      1 "SHA384"
    163 "SHA512"
Judgment on preferred hash algorithms:
   1776 null
   2618 "weak hash with higher preference"
Judgment on expiration times:
     53 "expiration passed"
    111 "expiration too far in future"
   3887 "no expiration set"
    343 null
This was generated with debian-keyring 2013.12.13, hopenpgp-tools 0.4-1, jshon 20131010-3, and the following inefficient script:
#!/bin/zsh
infile=/usr/share/keyrings/debian-keyring.gpg
tempfile=$(mktemp)
trap 'rm $ tempfile ' EXIT
hokey lint --output-format JSON <$ infile  >$ tempfile 
print -n "Total keys: "
jshon -a -e keyFingerprint <$ tempfile    wc -l
print "Key versions: "
jshon -a -e keyVer -e val <$ tempfile    sort   uniq -c
print "Primary key pubkey algorithms: "
jshon -a -e keyAlgorithmAndSize -e pubkeyalgo -e val <$ tempfile    sort   uniq -c
print "Primary key pubkey sizes: "
jshon -a -e keyAlgorithmAndSize -e pubkeysize -e val <$ tempfile    sort -n   uniq -c
print -n "Total number of UIDs + UAts: "
jshon -a -e keyUIDsAndUAts -k <$ tempfile    wc -l
print "Hash algorithm used for most recent self-sig: "
jshon -a -e keyUIDsAndUAts -a -e uidSelfSigHashAlgorithms -a -e val <$ tempfile    sort   uniq -c
print "Judgment on preferred hash algorithms: "
jshon -a -e keyUIDsAndUAts -a -e uidPreferredHashAlgorithms -a -e explanation <$ tempfile    sort   uniq -c
print "Judgment on expiration times: "
jshon -a -e keyUIDsAndUAts -a -e uidKeyExpirationTimes -a -e explanation <$ tempfile    sort   uniq -c
This represents incorrect handling of revoked UIDs and user attributes, and possibly unknown bugs. "Judgments" are based on this document and are not generalized per key.

Erich Schubert: The init wars

The init wars have recently caught a lot of media attention (e.g. heise, prolinux, phoronix). However, one detail that is often overlooked: Debian is debating over the default, while all of them are already supported to a large extend, actually. Most likely, at least two of them will be made mandatory to support IMHO.
The discussion seems to be quite heated, with lots of people trying to evangelize for their preferred system. This actually only highlights that we need to support more than one, as Debian has always been about choice. This may mean some extra work for the debian-installer developers, because choosing the init system at install time (instead of switching later) will be much easier. More often than not, when switching from one init system to another you will have to perform a hard reset.
If you want to learn about the options, please go to the formal discussion page, which does a good job at presenting the positions in a neutral way.
Here is my subjective view of the init systems:
  • SysV init is the current default, and thus deserves to be mentioned first. It is slow, because it is based on a huge series of shell scripts. It can often be fragile, but at the same time it is very transparent. For a UNIX system administrator, SysV init is probably the preferred choice. You only reboot your servers every year anyway.
  • upstart seems to be a typical Canonical project. It solves a great deal of problems, but apparently isn't good enough at it for everybody, and they fail at including anyone in their efforts. Other examples of these fails include Unity and Mir, where they also announced the project as-is, instead of trying to get other supporters on board early (AFAICT). The key problem to widespread upstart acceptance seems to be the Canonical Contributor License Agreement that many would-be contributors are unwilling to accept. The only alternative would be to fork upstart completely, to make it independent of Canonical. (Note that upstart nevertheless is GPL, which is why it can be used by Debian just fine. The CLA only makes getting patches and enhancements included in the official version hard.)
  • systemd is the rising star in the init world. It probably has the best set of features, and it has started to incorporate/replace a number of existing projects such as ConsoleKit. I.e. it not only manages services, but also user sessions. It can be loosely tied to the GNOME project which has started to rely on it more and more (much to the unhappyness of Canonical, who used to be a key player for GNOME; note that officially, GNOME chose to not depend on systemd, yet I see this as the only reliable combination to get a complete GNOME system running, and since "systemd can eventually replace gnome-session" I foresee this tie to become closer). As the main drawback, systemd as is will (apparently) only work with the Linux kernel, whereas Debian has to also support kFreeBSD, NetBSD, Hurd and the OpenSolaris kernels (some aren't officially supported by Debian, but by separate projects).
So my take: I believe the only reasonable default is systemd. It has the most active development community and widest set of features. But as it cannot support all architectures, we need mandatory support for an alternative init system, probably SysV. Getting both working reliably will be a pain, in particular since more and more projects (e.g. GNOME) tie themselves closely to systemd, and would then become Linux-only or require major patches.
I have tried only systemd on a number of machines, and unfortunately I cannot report it as "prime time ready" yet. You do have the occasional upgrade problems and incompatibilities, as it is quite invasive. From screensavers activating during movies to double suspends, to being unable to shutdown my system when logged in (systemd would treat the login manager as separate session, and not being the sole user it would not allow me to shut down), I have seen quite a lot of annoyances happen. This is an obvious consequence of the active development on systemd. This means that we should make the decision early, because we will need a lot of time to resolve all these bugs for the release.
There are more disruptions coming on the way. Nobody seems to have talked about kDBUS yet, the integration of an IPC mechanism like DBUS into the Linux kernel. It IMHO has a good chance of making it into the Linux kernel rather soon, and I wouldn't be surprised if it became mandatory for systemd soon after. Which then implies that only a recent kernel (say, mid-2014) version might be fully supported by systemd soon.
I would also like to see less GNOME influence in systemd. I have pretty much given up on the GNOME community, which is moving into a UI direction that I hate: they seem to only care about tablet and mobile phones for dumb users, and slowly turn GNOME into an android UI; selling black background as major UI improvements. I feel that the key GNOME development community does not care about developers and desktop users like me anymore (but dream of being the next Android), and therefore I have abandoned GNOME and switched to XFCE.
I don't give upstart much of a chance. Of course there are some Debian developers already involved in its development (employed by Canonical), so this will cause some frustration. But so far, upstart is largely an Ubuntu-only solution. And just like Mir, I don't see much future in it; instead I foresee Ubuntu going systemd within a few years, because it will want to get all the latest GNOME features. Ubuntu relies on GNOME, and apparently GNOME already has chosen systemd over upstart (even though this is "officially" denied).
Sticking with SysV is obviously the easiest choice, but it does not make a lot of sense to me technically. It's okay for servers, but more and more desktop applications will start to rely on systemd. For legacy reasons, I would however like to retain good SysV support for at least 5-10 more years.

But what is the real problem? After all, this is a long overdue decision.
  • There is too much advocacy and evangelism, from either side. The CTTE isn't really left alone to do a technical decision, but instead the main factors have become of political nature, unfortunately. You have all kinds of companies (such as Spotify) weigh in on the debate, too.
  • The tone has become quite aggressive and emotional, unfortunately. I can already foresee some comments on this blog post "you are a liar, because GNOME is now spelled Gnome!!1!".
  • Media attention. This upcoming decision has been picked up by various Linux media already, increasing the pressure on everybody.
  • Last but not least, the impact will be major. Debian is one of the largest distributions, last but not least used by Ubuntu and Steam, amongst others. Debian preferring one over the other will be a slap in somebodys face, unfortunately.
So how to solve it? Let the CTTE do their discussions, and stop flooding them with mails trying to influence them. There has been so much influencing going on, it may even backfire. I'm confident they will find a reasonable decision, or they'll decide to poll all the DDs. If you want to influence the outcome provide patches to anything that doesn't yet fully support your init system of choice! I'm sure there are hundreds of packages which do neither have upstart nor systemd support yet (as is, I currently have 27 init.d scripts launched by systemd, for example). IMHO, nothing is more convincing than have things just work, and of course, contributing code. We are in open source development, and the one thing that gets you sympathy in the community is to contribute code to someone elses project. For example, contribute full integrated power-management support into XFCE, if you include power management functionality.
As is, I have apparently 7 packages installed with upstart support, and 25 with systemd support. So either, everybody is crazy about systemd, or they have the better record of getting their scripts accepted upstream. (Note that this straw poll is biased - with systemd, the benefits of not using "legacy" init.d script may just be larger).

John Goerzen: Debian-Live Rescue image with ZFS On Linux; Ditched btrfs

I m a geek. I enjoy playing with different filesystems, version control systems, and, well, for that matter, radios. I have lately started to worry about the risks of silent data corruption, and as such, looked to switch my personal systems to either ZFS or btrfs, both of which offer built-in checksumming of all data and metadata. I initially opted for btrfs, because of its tighter integration into the Linux kernel and ability to shrink an existing btrfs filesystem. However, as I wrote last month, that experiment was not a success. I had too many serious performance regressions and one too many kernel panics and decided it wasn t worth it. And that the SuSE people got it wrong, deeply wrong, when they declared btrfs ready for production. I never lost any data, to its credit. But it simply reduces uptime too much. That left ZFS. Before I build a system, I always want to make sure I can repair it. So I started with the Debian Live rescue image, and added the zfsonlinux.org repository to it, along with some key packages to enable the ZFS kernel modules, GRUB support, and initramfs support. The resulting image is described, and can be downloaded from, my ZFS Rescue Disc wiki page, which also has a link to my source tree on github. In future blog posts in the series, I will describe the process of converting existing Debian installations to use ZFS, of getting them to boot from ZFS, some bugs I encountered along the way, and some surprising performance regressions in ZFS compared to ext4 and btrfs.

Craig Small: WordPress 3.8 for Debian

Well if you can read this then you know it s working. After way too many weeks, Debian will have WordPress version 3.8. Thanks to Rapha l for his kind assistance and answering my questions about how it was built. The upload is still gurgling along and will make it there in its own time. He said Handing over packages is hard, I d agree but say taking over them is too. So, what does WordPress 3.8 look like? From the frontend I didn t really notice much. The big changes, at least cosmetically, seem to be for the admin backend. It just look slicker and cleaner. Hopefully Debian users find the update useful and I ve not broken anything. There s always the BTS if there is. I ve deliberately tried to minimise the changes for this version to limit the breakage.

Dirk Eddelbuettel: RcppArmadillo 0.4.000.2

A bug fix release of Armadillo came out and was turned into a new RcppArmadillo release which is now on CRAN and will go shortly to Debian. The complete list of changes is below.
Changes in RcppArmadillo version 0.4.000.2 (2014-01-21)
  • Upgraded to Armadillo release Version 4.000.2
    • fix for randi() generating out-of-interval values
    • workaround for a bug in the Intel compiler
Courtesy of CRANberries, there is also a diffstat report for the most recent release As always, 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.

Next.

Previous.