Search Results: "ed"

28 May 2013

Christian Perrier: Bug #710000

Alexander Reichle-Schmehl created Debian bug #710000 on Monday May 27th 2013, against the ftp.debian.org pseudo-package, by cloning a bug report by Rene Engelhard. So, technically speaking, Rene reported this bug....but Tolimar is responsible for that. Bug #700000 was reported as of February 7th: 3 months and 20 days for 10,000 bugs. This is again a VERY significant drop in the bug reporting rate in Debian. Is that related to the release of jessie? We'll see that in the upcoming 4 months.

Daniel Pocock: The BBC and a confused concept of what is free and open

One of the top 10 read pages on the BBC website today is a feature article by acclaimed computer scientist and inventor Jaron Lanier (inventor of the term virtual reality) urging the middle class to Sell your data to save the economy and your future This particular quote stands out:
"The medicine of our time is purported to be open information. The medicine comes in many bottles: open software, free online education, European pirate parties, Wikileaks, social media, and endless variations of the above."
While Lanier makes some legitimate points about the way people share their personal data (everything from relationships to medical records) his writing in this instance seems to put concepts such as "open software" and free online education in the same basket as the abuse of medical records and the systematic collection of fingerprints and DNA samples by new-age tyrants. Various thoughts come to mind:
  • Would he make these same claims against software that is distributed under a strong copy-left license such as the GPL?
  • Is he arguing that software engineers should work for royalties on use of our code rather than salaries paid to developers who produce free, open source software?
  • Is centralised computer power a black-and-white issue? What is to stop the middle class from pooling their resources into distributed clusters that can compete with data-center owners like Facebook? SETI@home is one particularly well known example. By joining the cloud of their choice, the public is, in a way, democratically exercising control over the way computing power is used.
  • How does he define the difference between "free online education" and the free public libraries that we all know and love? If free online education, research papers and other materials are not available, then does he also believe libraries should start charging door fees?
  • Was this article edited by the BBC in such a way that it no longer coherently represents what he aimed to say? Editing errors are not unheard of in the press.
Of course, this type of confusion is not out of place for a country that has multiple broadcast services promoted under the names Freesat, Freesat and Freeview while none of them are actually free of charge due to a controversial tax on watching TV that a whopping 22% of the population refuse to pay.

Russell Coker: Links May 2013

Cameron Russell (who works as an underwear model) gave an interesting TED talk about beauty [1]. Ben Goldacre gave an interesting and energetic TED talk about bad science in medicine [2]. A lot of the material is aimed at non-experts, so this is a good talk to forward to your less scientific friends. Lev wrote a useful description of how to disable JavaScript from one site without disabling it from all sites which was inspired by Snopes [3]. This may be useful some time. Russ Allbery wrote an interesting post about work and success titled The Why? of Work [4]. Russ makes lots of good points and I m not going to summarise them (read the article, it s worth it). There is one point I disagree with, he says You are probably not going to change the world . The fact is that I ve observed Russ changing the world, he doesn t appear to have done anything that will get him an entry in a history book but he s done a lot of good work in Debian (a project that IS changing the world) and his insightful blog posts and comments on mailing lists influence many people. I believe that most people should think of changing the world as a group project where they are likely to be one of thousands or millions who are involved, then you can be part of changing the world every day. James Morrison wrote an insightful blog post about what he calls Penance driven development [5]. The basic concept of doing something good to make up for something you did which has a bad result (even if the bad result was inadvertent) is probably something that most people do to some extent, but formalising it in the context of software development work is a cencept I haven t seen described before. A 9yo boy named Caine created his own games arcade out of cardboard, when the filmmaker Nirvan Mullick saw it he created a short movie about it and promoted a flash mob event to play games at the arcade [6]. They also created the Imagination Foundation to encourage kids to create things from cardboard [7]. Tanguy Ortolo describes how to use the UDF filesystem instead of FAT for USB devices [8]. This allows you to create files larger than 2G while still allowing the device to be used on Windows systems. I ll keep using BTRFS for most of my USB sticks though. Bruce Schneier gave an informative TED talk about security models [9]. Probably most people who read my blog already have a good knowledge of most of the topics he covers. I think that the best use of this video is to educate less technical people you know. Blaine Harden gave an informative and disturbing TED talk about the concentration camps in North Korea [10]. At the end he points out the difficult task of helping people recover from their totalitarian government that will follow the fall of North Korea. Bruce Schneier has an interesting blog post about the use of a motherboard BMC controller (IPMI and similar) to compromise a server [11]. Also some business class desktop systems and laptops have similar functionality. Russ Allbery wrote an insightful article about the failures of consensus decision-making [12]. He compares the Wikipedia and Debian methods so his article is also informative for people who are interested in learning about those projects. The TED blog has a useful reference article with 10 places anyone can learn to code [13]. Racialicious has an interesting article about the people who take offense when it s pointed out that they have offended someone else [14]. Nick Selby wrote an interesting article criticising the Symantic response to the NYT getting hacked and also criticises anti-viru software in general [15]. He raises the point that most of us already know, anti-virus software doesn t do much good. Securing Windows networks is a losing game. Joshua Brindle wrote an interesting blog post about security on mobile phones and the attempts to use hypervisors for separating data of different levels [16]. He gives lots of useful background information about how to design and implement phone based systems.

Russell Coker: SCSI Failures

For a long time it was widely regarded that SCSI was the interface for all serious drives that were suitable for Enterprise Use or for anything else which requires reliable operation. On the other hand IDE was for cheap disks that were only suitable for home use. The SCSI vs IDE issue continues to this day but now we have SAS and SATA filling the same market niches with the main difference between the current debate and the debate a decade ago being that a SATA disk can be connected on a SAS bus. Both SAS and SATA have a single data cable for each disk which avoids the master/slave configuration on IDE and the issue of bus device ID number (from 0-7 or 0-15) and termination on SCSI. Termination When a high speed electrical signal travels through a cable some portion of the signal will be reflected from any cable end point or any point of damage. To prevent the signal reflection from the end of a cable you can have a set of resistors (or some other terminating device) at the end of the cable, see the Terminator(electrical) Wikipedia page [1] for a brief overview. As an aside I think that page could do with some work, if you are an EE with a bit of spare time then improving that page would be a good thing. SCSI was always designed to have termination while IDE never was. I presume that this was largely due to the cable length (18 for IDE vs 1.5m to 25m for SCSI) and the number of devices (2 for IDE vs 7 or 15 for SCSI). I also presume that some of the problems that I ve had with IDE systems have been related to signal problems that could have been avoided with a terminated bus. My first encounter with SCSI was when working for a small business that focused on WindowsNT software development. Everyone in the office knew a reasonable amount about computers and was happy to adjust the hardware of their own workstation. A room full of people who didn t understand termination who fiddled with SCSI buses tended to give a bad result. On the up-side I learned that a SCSI bus can work most of the time if you have a terminator in the middle of the cable and a hard drive at the end. There have been two occasions when I ve been at ground zero for a large deployment of servers from a company I ll call Moon Computers. In both cases there were two particularly large and expensive servers in a cluster and one of the cluster servers had data loss from bad SCSI termination. This is particularly annoying as the terminators have different colours, all that was needed to get the servers working was to change the hardware to make them look the same. As an aside the company with no backups [2] had one of the servers with bad SCSI termination. Heat SCSI disks and now SAS disks tend to be designed for higher performance, this usually means greater heat dissipation. A disk that dissipates a lot of heat won t necessarily work well in a desktop case with small and quiet fans. This can become a big problem if you have workstations running 24*7 in a hot place (such as any Australian city that s not in Tasmania) and turn the air-conditioner off on the weekends. One of my clients lost a few disks before they determined that IDE disks are the only option for systems that are to survive Australian heat without any proper cooling. Differences between IDE/SATA and SCSI/SAS In 2009 I wrote about vibration and SATA performance [3]. Rumor has it that SCSI/SAS disks are designed to operate in environments where there is a lot of vibration (servers with lots of big fans and fast disks) while IDE/SATA disks are designed for desktop and laptop systems in quiet environments. One thing I d like to do is to test performance of SATA vs SAS disks in a server that vibrates. SCSI/SAS disks have apparently been designed for operation in a RAID array and therefore will give a faster timeout on a read error (so another disk can return the data). While IDE/SATA disks are designed for a non-RAID situation and will spend longer trying to read the data. There are also various claims about the error rates from SCSI/SAS disks being better than those of IDE/SATA disks. But I think that in all cases the error rates are small enough not to be a problem if you use a filesystem like ZFS or BTRFS but they are also large enough to be a significant risk with modern data volumes if you have a lesser filesystem. Data Loss from Storage Failure In the data loss that I ve personally observed from storage failures the loss from SCSI problems (termination and heat) is about equal to all the hardware related data loss I ve seen on IDE disks. Given that the majority of disks I ve been responsible for have been IDE and SATA that s a bad sign for SCSI use in practice. But all serious data loss that I ve seen has involved the use of a single disk (no RAID) and inadequate backups. So a basic RAID-1 or RAID-5 installation will solve most hardware related data loss problems. There was one occasion when heat caused two disks in a RAID-1 to give errors at the same time, but by reading from both disks I managed to get almost all the data back, RAID can save you from some extreme error conditions. That situation would have been ideal for BTRFS or ZFS to recover data. Conclusion SCSI and SAS are designed for servers, using them in non-server systems seems to be a bad idea. Using SATA disks in servers can have problems too, but not typically problems that involve massive data loss. Using technology that is too complex for the people who install it seems risky. That includes allowing programmers to plug SCSI disks into their workstations and whoever it was from Moon computers or their resellers who apparently couldn t properly terminate a SCSI bus. It seems that the biggest advantage of SAS over SCSI is that SAS is simple enough for most people to be able to correctly install it. Making servers similar to the systems that the system administrators use at home seems like a really good idea. I think that one of the biggest benefits of using x86 systems as servers is that skills learned on home PCs can be transferred to administration of servers. Of course it would also be a good idea to have test servers that are identical to servers in production so that the sysadmin team can practice and make mistakes on systems that aren t mission critical, but companies seem to regard that as a waste of money apparently the risk of down-time is cheaper.

Andrew Pollock: [life] Running, a year later

So it's been about a year since I started running. In that time, I've gone from just being able to run 5K, to comfortably doing 10K in just under an hour. In that same time, my weight has gone from 77.5 kg to around 69 kg. The thing that started all of this off was the 5K Packard Summer Scamper, and next month I'm going to run in my first 14K fun run, the City2South. I thought I'd have a go at fund raising too, so if you'd like to make a donation, here's my page. I'm raising money for the Heart Foundation. I've constantly surprised myself with my progress. Just the last time I went for a run, I managed to set personal records on 1 km, 1 mile, 5 km and 10 km, which really blew me away. Once upon a time, I had this crazy idea to try and get into the Queensland Police Service, and one of the fitness requirements for applying was you had to be able to run 2.4 km in under 12 minutes, and I remember training away on the treadmill at the gym and only just scraping in under that time on a treadmill. Then I tried it on a running track, and I have these vague memories of it being a total slog. That was probably 10 years or more ago now. Now I could do that easily. I've got quite a nice 10 km running course in my local neighbourhood, so I'm thinking now that I'm comfortably running 10 km on this course, I should try and go for a half-marathon distance, so one of these weekends I'll just try running the same course twice plus a little bit more, just to see if I have it in me. Then maybe I'll consider entering a half-marathon, just for shits and giggles. I'll probably do it after I run 14 km, which will be the longest distance I've run to date. I only learned about the City2South run yesterday. The run that I've been planning on doing since returning to Brisbane is the Bridge to Brisbane. It looks like they've just opened up entries for it now, so I guess I should go sign up for it too.

Johannes Schauer: New bootstrap analysis results

I wrote a small wiki page for botch. It includes links to some hopefully useful resources like my FOSDEM 2013 talk or my master thesis about botch. The final goal of botch is to generate a build order with which Debian can be bootstrapped from zero to more than 18000 source packages. But such a build order can only be generated once enough source packages (by now the number is around 70) incorporate build profiles which allow to compile them with less build dependencies and thereby break all build dependency cycles. So an intermediary goal of botch is, to find a "good" (i.e. a close to minimal amount) selection of such build dependencies that should be dropped from their source packages. So far, the results of all heuristics we use for this task were just dumped to standard output. Since this textual format was hard to read for a human developer and even worse machine readable, that tool now outputs its results in JSON. This data is then converted by another tool to a more human readable format. One such format is HTML and with the help of javascript for sortable and pageable tables, the data can then be presented without producing too much visual clutter (at least compared to the initial textual format). Another advantage of HTML is, that the data can now easily be shared with other developers without them having to run botch or install any other program first. So without further ado, please find the result of running our heuristics on Debian Sid as of 2013-01-01 here: http://mister-muffin.de/bootstrap/stats/ Here is a screenshot of what you can expect (you can see part of the table of edges with most cycles through them): As a developer uses this information to add build profiles to source packages, this HTML page can be regenerated and will show which strongly connected components are now left in the graph and how to best make them acyclic as well. Besides other improvements I also updated the data I used to generate the graphs from this post. I found this update to be necessary since we found and fixed several implementation bugs since October 2012, so this new plot should be more accurate. Here a graph which shows the amount of vertices in the biggest strongly connected component of Debian Sid by date. Some datapoints are missing for dates for which important source packages in Sid were not compilable.

Russ Allbery: Review: Advanced Perl Programming

Review: Advanced Perl Programming, by Sriram Srinivasan
Publisher: O'Reilly
Copyright: August 1997
ISBN: 1-56592-220-4
Format: Trade paperback
Pages: 392
The problem with buying lots of books is that one frequently doesn't read them soon after purchase. And while nearly all fiction and most non-fiction doesn't have a time limit, technical books are more of a problem. As you might have guessed from the publication date and subject matter of this book, it's one I waited too long to read. I picked up Advanced Perl Programming not too long after it was first published in 1997. I bought it primarily for the chapters on XS programming, since I was just starting to develop and help maintain code that built Perl interfaces for C libraries. And then it sat on my bookshelf in the office, and then at home, until it was 16 years old. That's problematic for a general Perl programming guide; it's particularly troublesome for a book that dives deep into internals. That said, I still got some interesting information from it. Advanced Perl Programming is something of a grab bag of different and largely unrelated topics. It starts with a data structures overview (which is mostly about references), covers typeglobs and the Perl symbol table, briefly discusses closures, and then dives deeper into eval. That's followed by an overview of modules and object-oriented programming in Perl. The general Perl topics close with a solid (if outdated) discussion of tied objects and a somewhat rambling and remarkably general discussion of persistance. Srinivasan then covers some recommended module APIs for networking and graphics (Tk, specifically) while working through some complex examples, takes a deeper dive into eval and code generation, and concludes with three chapters on XS and embedded Perl interpreters. This is all solid material, but a lot of it is at least partly obsolete. The chapters on modules and object-oriented programming fare the worst; you'll find much better guides to those topics elsewhere. Data structures also fare poorly, partly because Srinivasan is still happy to use symbolic references, now considered bad style due to lack of compile-time checking. (That does mean, though, that this is one of the best introductions to symbolic references that you'll find, since few other Perl programmers discuss them.) But the rest of the book is fairly solid, if limited by age. If I'd read it when I first started with XS, it would have indeed helped. Advanced Perl Programming contains a succinct and clear overview of Perl internals and data representation (assuming, of course, it's not changed drastically, but I didn't notice any significant issues from what I know of internals from quite a lot of XS programming), particularly when combined with the earlier chapter on typeglobs and the symbol table. It is interesting, though, to see how much accepted Perl style has changed. Srinivasan is quite fond of eval with a scalar argument to construct code at runtime, something that most current authors recommend against when it can be avoided. The loss of static syntax checking means the technique is often hard to debug and can cause surprising runtime errors. Several of the more advanced tricks in this book are built on that framework, including a moderately interesting templating system that he constructs from scratch in this book. The examples here are also missing the focus on use strict, warnings, and avoiding special variables and unusual constructs that you see in more recent Perl books. This is a very thoughtful book, with several structural techniques that I appreciated and would like to see more technical writers use. One is the comparisons to the approaches of other languages at the end of most chapters. It puts Perl's approach in a broader context and encourages thought about alternative ways to view a particular feature and implementation tradeoffs in Perl's choices. Another is the careful discussion of design approaches and possibilities during the construction of larger examples. I think there's a tendency in technical books to spend a lot of time developing the best possible implementation of something and then show that completed example. Even with a detailed analysis of its construction, this can be less useful than a broader discussion of possible approaches, including dead ends. The problem, of course, is that 16 years is a long time, even for a relatively mature programming language, and Perl has changed. There are significant improvements not only to the standard library but to Perl core functionality that have happened since this book was written. The chapter on tying, which is otherwise excellent, is badly out of date on what functionality and methods are available and is no longer a reliable guide to using that feature except for simple cases. Similar problems plague the chapter on persistence, which develops the concept from basics that most programmers reading an advanced book no longer need, and which has been rendered mostly obsolete by further developments in the Perl module ecosystem. I think the best parts of this book, the ones that cover material that I think is still relatively accurate and that are not well-covered by other resources, are the chapters on typeglobs and on XS. The typeglob discussion is both clear and informative, covering material and techniques that are used in a few core Perl modules and that I've never seen adequately addressed elsewhere. I'd subsequently picked up XS and Perl embedding the hard way: lots of trial and error and reading difficult POD documentation. I wish I'd read this book earlier, since Srinivasan does a great job of basic orientation. He doesn't go far enough for me (the book I probably wanted was Extending and Embedding Perl by Jenness and Cozens, published five years later), but I would have been up and running with basic XS much faster by starting here. If this were 1997, or even 2000, I would probably recommend this book, albeit with a few caveats. Higher Order Perl is the place you should go for discussion of closures, rather than here (although of course it didn't exist then). I wasn't fond of string eval even in 1997, and I still think it produces code that, while efficient and quite powerful, is horribly difficult to understand. And the introduction to modules is adequate but not compelling; most other introductions to object-oriented programming and module construction in Perl are better. But even discarding those chapters (and the mostly unnecessary Tk reference), there's a lot of great material here that would have been quite helpful in 2000. Unfortunately, this is not the sort of technical book that ages well, and while I did pick up some useful background knowledge and a much better understanding of typeglobs, I mostly read this book because I wanted to salvage some knowledge from a book that sat for far too long on my shelves. There's really no reason to buy it today. If you run across it in a library, there are a few chapters that are still worth reading, but by and large if you know enough Perl to know where to be careful of landmines due to changes in Perl since the book was written, you also know enough Perl to not really need this book. Rating: 5 out of 10

Russ Allbery: Collected haul

I've been slow lately in writing these up (and, for that matter, in doing most other things related to reading; things have been rather busy lately). This is a bunch of here-and-there purchases over the last few months, including Powell's Indiespensible shipments. Sandra Barret Face of the Enemy (sff)
Anne Bishop Written in Red (sff)
Lois McMaster Bujold Captain Vorpatril's Alliance (sff)
Cary Caffrey The Girls from Alcyone (sff)
Jenni Fagan The Panopticon (mainstream)
Niels Ferguson, et al. Cryptography Engineering (non-fiction)
Jen Kirchner The Fourth Channel (sff)
Anothony Marra A Constellation of Vital Phenomena (mainstream)
Steve McConnell Code Complete (non-fiction)
Seanan McGuire Velveteen vs. The Junior Super-Patriots (sff)
Patrick Nielsen Hayden, et al. (ed.) Some of the Best from Tor.com: 2012 (sff anthology)
Lisa O'Donnell The Death of Bees (mainstream)
Susan Palwich Flying in Place (sff)
Kim Stanley Robinson 2312 (sff)
John Scalzi Redshirts (sff)
Ian Tregillis Bitter Seeds (sff)
Leon Trotsky The History of the Russian Revolution (non-fiction)
Simon Van Booy The Illusion of Separateness (mainstream)
Chris Anne Wolfe Shadows of Aggar (sff)
Barbara Ann Wright The Pyramid Waltz (sff) That's a lot of stuff. It includes a couple of non-fiction O'Reilly books from sales, a few months of Powell's Indiespensible subscriptions, a variety of books I picked up after a discussion of good lesbian fiction on Tor.com (romance without the obnoxious gender tropes, or at least as many of them), and the rest of the Hugo nominees for the year. I got a ton of reading done earlier this month. I wish I could say the same thing about reviews, but I only wrote a few. That's something that I want to try to catch up on soon, so there will probably be a flurry of those posted soon. I've already read Blackout and Redshirts of this year's nominees (a review of the latter is coming), so at least I'm not too far behind on the reading. Throne of the Crescent Moon is in progress now.

27 May 2013

Bits from Debian: Debian welcomes its 2013 crop of GSoC students!

We are proud to announce that 16 students have been accepted to work on improving Debian this summer through the Google Summer of Code! This is great news, following our 15 accepted students in 2012, and 9 accepted students in 2011. Here is the list of accepted students and projects: If you're interested in one of the projects, please follow the links and talk directly to the students or the mentors, or come hang out with us on IRC. Welcome everyone, and let's make sure we all have an amazing summer!

Michael Stapelberg: Results of the Debian systemd survey

A week ago, we started the Debian systemd survey. The goal was to figure out a few trends and answer the following two questions:
  1. Do our subjective impressions from the discussions on debian-devel reflect the general sentiment about systemd?
  2. What are the main concerns that most people have?
Thank you all for your participation! General I am happy to tell that 2113 people had a look at the survey and 573 people actually participated. Of those, 45.7% said they are a DD, DM or otherwise maintaining packages. 74.5% said they actually booted and used a computer running systemd. With regards to having systemd in Debian at all, not necessarily as the default init system, answers are as follows: 43.9% said they personally want systemd as the default init system in Debian, while 32.2% don t want that. The remaining 23.7% don t know yet. Top concerns About 50% of participants provided one or more concerns. Evaluating this part of the survey is obviously the hardest, since the answers were provided as free text. I tried categorizing the feedback into a few buckets. Each bucket comes with a number which is a weighted (!) count, i.e. the top concern counts 3 times, the second concern counts 2 times and the last concern just once. If you cannot find your personal concerns, that is because those which were just voiced by less then five people are not listed here. As I said, we cared about trends in this survey, not individual opinions.
  1. systemd is too complex, or bloated, or it does too many things, or has too many dependencies (weight: 217)
  2. systemd is not portable to non-linux systems, e.g. Debian/kFreeBSD or HURD (weight: 199)
  3. Debugging the boot process is harder than in sysvinit (weight: 106)
  4. I have a problem with systemd upstream and/or Lennart in particular (weight: 87)
  5. systemd violates the UNIX philosophy (weight: 35)
  6. I dislike binary logs and/or the journal in general (weight: 30)
  7. systemd is too new, still untested, unstable and experimental (weight: 24)
  8. I cannot find enough documentation in general or about the transition from sysvinit to systemd in particular (weight: 20)
  9. People need to learn new commands/how the new system works (weight: 20)
  10. I don t know what problems systemd solves and/or have no problems with sysvinit currently (weight: 19)
  11. I think the configuration is binary and/or the configuration format is weird (weight: 13)
  12. systemd s code is not good (memory leaks, performance problems) and/or upstream s development lacks best practices such as long-term stable branches (weight: 9)
  13. There are problems with systemd in Debian (e.g. Debian-specific extensions to /etc/fstab not supported, system doesn t boot) (weight: 9)
  14. Customizing the boot is harder than with sysvinit (weight: 8)
  15. systemd is not compatible with sysvinit (weight: 8)
I realize that the choice of buckets is somewhat broad and there are many different, finely nuanced opinions out there. Again, this is for seeing a trend, not accounting for every single individual opinion. In case you strongly believe that I did something wrong when evaluating the survey results, please contact me and we can work something out. Conclusions/Actions I know this is a controversial topic. Please don t start yet another systemd discussion on debian-devel. We, the systemd Debian maintainers, will try to come up with good answers to all listed concerns and communicate them in a friendly and concise way soon. Furthermore, we have recognized the need for more documentation/information about how things are supposed to work with regards to the transition (and systemd in general) and will address that, too. Raw questions/numbers
Total records in survey: 573
Are you a Debian Developer (DD) or Debian Maintainer (DM) or otherwise currently maintaining Debian packages?
262 Yes
311 No
Did you ever boot and use a computer running systemd? It does not matter whether that computer was running Debian or a different operating system.
427 Yes
146 No
What is your general sentiment towards having systemd in Debian (not necessarily as default)?
358 I welcome systemd in Debian, everything is fine.
 81 I am not sure yet.
 46 I don t care.
 88 I don t want systemd in Debian.
Would you personally want systemd as the default init system in Debian?
252 Yes
136 I don t know
185 No

Dirk Eddelbuettel: R / Finance 2013 Recap -- and Presentation Slides

The fifth internation R/Finance conference was held last weekend. As one of the founding co-organizers, I may well be accussed of a little bias, but we think we once again pulled off a very nice and successful weekend-long event. Participants had kind words to say during the conference, and a few first posts have appeared such as Joe Rickert's post over at the REvo blog. Some participants, myself included, had already posted on their personal websites (though had forgotten to mention it here). In any event, I just updated the website with links to the pdf (or ppt) slides of all presenters who shared their material with us. Supplemental material may be made available too at a later date. We hope you find these slides useful. Please do spread the word about the R/Finance conference as we expect to have a sixth edition in May 2014---and we do look forward to receiving even more outstanding submissions. Dates, details, call for papers, etc will be forthcoming over the next few months.

Mike Hommey: signal() doubly considered harmful

When you want to set signal handlers on UNIX systems, the typical choice is to use signal (specified in C89, C99 and POSIX.1-2001) or sigaction (specified in POSIX.1-2001 and System V r4). Quoting the signal manual page:
The only portable use of signal() is to set a signal s disposition to SIG_DFL or SIG_IGN. The semantics when using signal() to establish a signal handler vary across systems (and POSIX.1 explicitly permits this variation); do not use it for this purpose. POSIX.1 solved the portability mess by specifying sigaction(2), which provides explicit control of the semantics when a signal handler is invoked; use that interface instead of signal().
Then it goes on about the UNIX vs BSD semantics, and how they affect signal delivery, which essentially is the main reason why one would want to stop using signal and use sigaction instead, with specifically chosen flags. But this is not really what I wanted to talk about here. One of the uses of signal or sigaction is to temporarily set a signal handler and restore the old signal handler once the job is done. Notwithstanding the fact that it s a pretty horrible thing to do in a multi-threaded program, it s also a horrible thing to do at all with signal if sigaction is used. The core of the problem is the following: the information you get from signal() about the old signal handler is missing all the important pieces about it if it was originally set with sigaction(), namely, flags, masks and restorer. So if you do use signal() to temporarily set a signal handler and then restore the previous signal handler, you risk resetting flags, masks and restorer. The first awful thing this means is the previous signal handler might be expecting three arguments, only one of which will be valid when it s invoked. Unexpected things can also happen with the lack of expected flags or masks. This is why you ll see horrible workarounds like this or that. In short, if you do use signal() to temporarily set a signal handler and then restore the previous signal handler, you re doing it wrong. And if you do that in a system library or driver, thank you for screwing things up. I m looking at you libsc-a3xx.so.

Petter Reinholdtsen: How to install Linux on a Packard Bell Easynote LV preinstalled with Windows 8

Two days ago, I asked how I could install Linux on a Packard Bell EasyNote LV computer preinstalled with Windows 8. I found a solution, but am horrified with the obstacles put in the way of Linux users on a laptop with UEFI and Windows 8. I never found out if the cause of my problems were the use of UEFI secure booting or fast boot. I suspect fast boot was the problem, causing the firmware to boot directly from HD without considering any key presses and alternative devices, but do not know UEFI settings enough to tell. There is no way to install Linux on the machine in question without opening the box and disconnecting the hard drive! This is as far as I can tell, the only way to get access to the firmware setup menu without accepting the Windows 8 license agreement. I am told (and found description on how to) that it is possible to configure the firmware setup once booted into Windows 8. But as I believe the terms of that agreement are completely unacceptable, accepting the license was never an alternative. I do not enter agreements I do not intend to follow. I feared I had to return the laptops and ask for a refund, and waste many hours on this, but luckily there was a way to get it to work. But I would not recommend it to anyone planning to run Linux on it, and I have become sceptical to Windows 8 certified laptops. Is this the way Linux will be forced out of the market place, by making it close to impossible for "normal" users to install Linux without accepting the Microsoft Windows license terms? Or at least not without risking to loose the warranty? I've updated the Linux Laptop wiki page for Packard Bell EasyNote LV, to ensure the next person do not have to struggle as much as I did to get Linux into the machine. Thanks to Bob Rosbag, Florian Weimer, Philipp Kern, Ben Hutching, Michael Tokarev and others for feedback and ideas.

Daniel Pocock: Upstream packaging and Debian: Drupal third-party libraries API

Many large, successful, de-centralised software projects have a suite of their own packages maintained with their own platform-independent tools. Typical examples are Drupal's collection of module and theme packages, the R Project packages (CRAN) and the Central Repository for Maven packages (Java). In the case of Drupal:
  • Debian only really packages the core Drupal system and not the modules and themes
  • Gunnar's dh-make-drupal can easily Debianize many of the modules from Drupal's collection
  • Drupal has strict rules about the contents of packages distributed from their official collection. In particular, they must all be 100% compatible with the GPL v2 or later.
  • Another rule that is particularly exciting for Debian is that Drupal's hosted modules may not duplicate code (particularly JavaScript) from other projects/repositories: everyone installing a module must download and unpack the required JavaScript, often adding many steps to the module installation.
This is a particular opportunity for Debian to demonstrate it's strengths. Debian's pkg-javascript team has been busy packaging a huge collection of popular JavaScript libraries in a 100% free manner that guarantees adherence to the Debian Free Software Guidelines. This means that they have already done a lot of the groundwork to weed out minified (obfuscated) code that isn't accompanied by readable source code and ensure that there is a mechanism for conveniently and promptly distributing security fixes. The Drupal Libraries API module has now been packaged for Debian and is available in the unstable archive. The goal of this package is to facilitate the automated use of Debian's high-quality JavaScript packages to fulfill the dependency requirements of Drupal modules. Exact details of how these components fit together is currently explained in the README.Debian file distributed in the package. People packaging JavaScript for use by Drupal modules need to consider making a small glue' package to help Drupal's Libraries API discover the JavaScript. In many cases the glue package needs to do little more than creating a symlink from /usr/share/javascript to /usr/share/drupal7/libraries - this process can also potentially be automated by a future version of dh-make-drupal

26 May 2013

Craig Small: props-ng 3.3.8

Procps-ng 3.38 was released yesterday. Besides the bug fixes,there have been two main enhancements: NUMA and systemd support. top comes with NUMA support which is a soft dependency, meaning that if compilied with the support, top will try to link at runtime to libnuma. The new key presses are 2 and 3 which will show the Nodes or more detail about a specific node respectively. ps has two new output columns; unit and uunit. These permit ps to display the systemd unit and user unit fields. The systemd support is a
hard dependency which is enabled with with-systemd procps-ng is available from gitorious or sourceforge:

Gregor Herrmann: RC bugs 2013/21

like last week, I was working on the preparation of the Perl 5.18 transition. besides that I also uploaded some RC bug fixes, mostly by taking patches that came from Ubuntu (kudos!): as a side note (or better: question): why are the bugs for the upcoming Apache 2.4 and openjdk-7 transitions classified as 'serious', instead of as 'important', like the Perl 5.18 ones?

Richard Hartmann: Full House

Even though I only flew to and from Berlin for a single day due to time constraints at work, my first attendance at LinuxTag was a nice experience. Everything was organized rather well and people seemed to be having fun. The event itself has a decidedly commercial tone to it with lots of actual companies present both at booths and during talks. Also, there was a distinct lack of anything resembling a hackerspace, i.e. chairs, tables and power outlets. My talk has been received rather well, having both the highest attendance of all talks I went to during LinuxTag and the highest attendance of all of my own talks to date. When I began there were 105 people in the room excluding myself. During the talk there was a constant trickle of people entering which led to several people standing at the back and others sitting on the ground. With a grand total of two people leaving early, I guesstimate 130+ people have attended. As you can see on the photo below the percentage of attendees who are looking into their laptops/cell phones and not really paying attention was, once again, very low: Audience during my 'Gitify your life' talk at LinuxTag 2013 Now if only I could find a way to track how many of them did actually sat down afterwards and looked at the tools presented... Sadly, there was no video recording of the talk, but I may be able to get my hands at the video material recorded during OSD2013.

Thomas Koch: What do you think about the FairPhone?

My new employer sponsors me a phone of my choice (up to a certain cost) and I'm very inclined to order a FairPhone. I want to support them and I like to have a device that'd be easily hackable and allows me to run Debian on it.
But it'd be my first smartphone and I don't really know much about android phones. What do you think about the specs of the Fairphone? Do you think it'd be easy to run a free environment (Debian) on it?
update: apparently, this PHP blog engine does not allow any comments right now. Please send your comment to thomas (at ) koch.ro instead. I'm really looking forward to replace this thing with something sane.

Andrew Pollock: [life] Maker Fair 2013 virtual trip report

The Maker Faire is one of the Bay Area things that I'll really miss. Zoe had a ball last year (for weeks afterwards every outing was "Maker Faire!" regardless of what or where it was) Last year I didn't really get to cover it very well, so I ended up doing a bit of a virtual tour via the exhibitor list on their website, and so this year I thought I'd be there in spirit by doing the same thing again. Here's my picks:

25 May 2013

Jonas Smedegaard: FreedomBox - Helps You Stay Free!

On saturday 25. of May I gave a talk about FreedomBox at the "Claim back your device" track of LinuxTag in Berlin. LinuxTag is a fairly big annual conference about (yes, you guessed right) Linux and related topics. The FreedomBox is a project to help non-geeks care about their personal privacy when online, same ways as geeks have practiced for a decade or more. Concrete goal is to design a small, cheap physical box similar to an internet gateway or wifi router but with three additions: "Privacy" is commonly mistaken as "secrecy": Privacy is to keep you in control of your information, so that sharing or keeping to yourself is truly your own choice. Thanks a lot especially to Matthias Kirschner for inviting me as a speaker! Slides (sources) for the event.

Next.

Previous.