Search Results: "ag"

9 June 2010

Russell Coker: Mailing List Meta-Discussions

It seems that most mailing lists occasionally have meta-discussions about what is on-topic, the few that don t are the ones that have very strong moderation authoritarian moderators who jump on the first infraction and clearly specify the rules. I don t recall the list of acceptable topics for any mailing list including also discussions about what is on-topic . As this is the Internet I m sure that someone will immediately point out an example of such a list, but apart from the counter-example that someone will provide it seems obvious that for the majority of mailing lists a meta-discussion is not strictly on topic. Regardless of a meta-discussion not being on-topic I don t think there s anything wrong with such a discussion on occasion. But if a meta-discussion is to be based on the volume of off-topic messages it would be nice if the people who advocate such a position could try and encourage the discussion in a way that reduced the number of messages. Replying to lots of messages is not a good strategy if your position is that there are too many messages. If a meta-discussion is going to be about moving off-topic discussions to other forums that are more appropriate then it would be nice to have the meta-discussion move to another forum if possible. My previous post which advocates creating a separate mailing list for chatty messages was an attempt to move a discussion to a different forum [1]. Anyone who believes that such discussions don t belong on a list such as debian-private is free to commit their thoughts to some place that they consider more appropriate and provide the URL to any interested parties. I think that it s worth noting that the only comment on my previous post is one that describes how to filter mail to split the traffic from the debian-private list into different mailboxes. I had hoped that other people would write blog posts advocating their positions which would allow us to consider the merits of various ideas without the he-said-she-said element of mailing list discussions. Most mailing lists have a policy against profanity and some go further and ban personal abuse. Therefore it seems hypocritical to advocate a strict interpretation of the rules in regard to what is on-topic while also breaking the rules regarding profanity or personal abuse. I don t think it s asking a lot to suggest that the small minority of messages that someone writes on the topic of a list meta-discussion should obey the set of rules that they advocate I m not suggesting that someone should obey all the rules all the time, just when they are trying to enforce them. Also you can argue that a list policy against profanity doesn t preclude sending profane messages off-list, but if the off-list messages are for the purpose of promoting the list rules it still seems hypocritical to use profanity. It is a fair point that off-topic discussions and jokes can distract people from important issues and derail important discussions. It would be good if people who take such positions would implement them in terms of meta-discussions. If the purpose of a meta-discussion is to avoid distraction from important issues then it seems like a really good idea to try and avoid distraction in the meta-discussion thread. I wonder whether a meta-discussion can provide anything other than a source of lulz for all the people who don t care about the issue in question. The meta-discussions in the Debian project seem to always result in nothing changing, not even when the majority of people who comment agree that the current situation is not ideal. When an almost identical meta-discussion happens regularly it seems particularly pointless to start such a discussion for the purpose of reducing off-topic content. Revisiting an old discussion can do some good when circumstances change or when someone has some new insight. I know that it s difficult to avoid being sucked into such discussions, when I was diagnosed with AS [2] I decided to try and minimise my involvement in such discussions but I haven t been as successful at doing so as I had hoped.

Ross Burton: Gypsy 0.8 Released

As acting release engineer of the Gypsy project (a GPS mux, if you didn't know) I'm proud to announce the release of Gypsy 0.8. So, what's new? Many thanks to Jussi Kukkonen for patch review, and Bastien Nocera for patch review and new features. The big question of course is what of the future? So far we've got some rough ideas. An overhaul of the device interaction layer is definitely required as actaully getting NMEA is becoming more complex: for integrated 3G/GPS chips you need to talk to oFono/ModemManager to get a socket, for some embedded GPS devices you need a proprietary binary that writes to a pipe, and so on. There are some new features we're considering too: server-side proximity detection and update rate limiting.

David Welton: Some difficult decisions?

I am, by nature, a tinkerer. I love to build things to see how they will work or because I have an idea that I think is fun. I am not so much of a natural business guy. I go build something "because it's there". Or rather, it's there in my mind, and I want to make it. I earn money, however, via consulting work. There are problems with this line of business though, namely that it doesn't scale very well unless, besides being good at a skill, you've also got the skills to build up a consulting business, which is very much about adding and managing people, something I'm not all that passionate about and would rather avoid. So what happens is that you go through slumps with less than full capacity, and then things pick up again, and before you know it, you hit your upper limit and can't take on any new work, putting a ceiling over your potential earnings. Sure, you can raise prices a bit, but that'll only get you so far. For a while now, I've been considering this problem, and I think some sort of product would be an ideal way out. Stories like Balsamiq's are inspirational, and along the lines of what I think might be nice. Don't get me wrong, I like my clients and like to help people solve problems a lot, but it's a stressful job in that you're never very far from having no income. I'm not much of an entrepreneur, though, in the sense of someone with a nose for making money. I tend to think about building something cool first, and not really worrying about making money with it. Predictably, some of the sites I have created are popular, but don't make any money. Sure, they have some ads, but that doesn't really make much unless you get really huge page views or have some sort of content that attracts users who will click on very lucrative advertisements. I've started to think that perhaps I should constrain myself in new initiatives to creating things that have a direct source of revenue: you want to use it, you pay. In my daydream world, I'd probably just hack on open source all day long, but there's no money in that for someone like me who is not the author of some huge, famous piece of software, nor a particularly great hacker in any case (I've met some, like Andrew Tridgell, and it's a really humbling experience). So that brings up the question of what to do with the aforementioned sites. One option would be to sell them off via a site like flippa.com, another would be simply to just let them sit there and stew, but they do take up some resources on my server, and require some maintainance now and then, and they're a bit of a distraction too (I start wondering about things to add or how to fiddle with them). Maybe there's a way to make money from some of them, but I'm too blind to see it. The ones I'm thinking about, are, in no particular order:

Gerfried Fuchs: Battle for Wesnoth 1.8

Some people still ask me from time to time when I'll upload Battle for Wesnoth 1.8. My usual answer is that it's there already since before the official announce went out in the wesnoth-1.8 package. The longer answer which also answers Why the name change? goes like this: People asked for a way to be able to install different branches side-by-side so that they can keep the old stable branch around for finishing started campaigns there while still being able to play with their friends multiplayer games using the new stable branch. Also people using the development version wanted to not having to get rid of the stable version just to use the development branch. So there it is! Enjoy! There though is still something missing though, and that's why the question where the 1.8 version of Wesnoth is still pops up: There is no transitional/meta package yet. This requires a bit more work including adding alternative handling (so one can still run wesnoth and not have to use the versioned wesnoth-1.8 binary name) and for that some dpkg-divert magic about the historical unversioned wesnoth packages. Given that my release is requesting quite some support overhead I can't tell yet when these things will be done, but a similarly related support contract will run out by the end of the month so potential I'll be able to find some time next month to finish this for good. If you want to have it done earlier or feel like helping out, feel free to send in patches after talking with me about the fineprints and potential approaches. Thanks in advance!

Russell Coker: Does Every Serious Mailing List need a Non-Serious Counterpart?

One practice that seems relatively common is for an organisation to have two main mailing lists, one for serious discussions that are expected to be relatively topical and another for anything that s not overly offensive. Humans are inherently incapable of avoiding social chatter when doing serious work. The people who don t want certain social interactions with their colleagues can find it annoying to have both social and serious discussions on the same list. While the people who want social discussions get annoyed when people ask them to keep discussions on topic. Organisations that I have been involved with have had mailing lists such as foo-chat and foo-talk for social discussions that involve the same people as the main list named foo , as well as having list names such as memo-list for random discussions that are separate from a large collection of lists which demand on-topic messages. The Debian project has some similar issues with the debian-private mailing list which is virtually required reading for Debian Developers. One complication that Debian has is that the debian-private list has certain privacy requirements (messages will be declassified after 3 years unless the author requests that they remain secret forever) which make it more difficult to migrate a discussion. You can t just migrate a discussion from a private list to a public list without leaking some information. So it seems to me that the best solution might be to have a list named debian-private-chat which has the same secrecy requirements but which is not required reading. As debates about what discussions are suitable for debian-private have been going on for more than 3 years I don t think there s any reason not to publish the fact that such discussions take place. Also it seems that every organisation of moderate scale that has a similar use of email and for which members socialise with each other could benefit from a similar mailing list structure. Note that I use a broad definition of the word socialise there s a lot of people who will never meet in person and a lot of the discussions are vaguely related to the main topic. I wonder whether it might be considered to be a best practice to automatically create a chat list at the same time as creating a serious discussion list.

Andrew Pollock: [debian] ISC DHCP 4.1 package progress report

It's been a while since I've been able to make any progress on the ISC DHCP 4.1 packaging. I had to cannibalise my test infrastructure to deal with hardware failure that would have rendered my MythTV installation out of commission, we bought a condo, did some renovations, and had a baby. I'm still playing catch up. The other day, I was able to recreate a test environment on my laptop using KVM, instead of Xen on a dedicated machine, and it's 37% more awesome than my old setup, so I'm back in the saddle again. I've been able to do some basic testing of the 4.1 packages that are in experimental, and they appear to work, and they upgrade cleanly from the 3.1 packages. There's the small issue of third-party packages that are plonking files in /etc/dhcp3 (it's just /etc/dhcp now). I finished filing bugs for the transition this morning, so I think the next step is to upload to unstable, which I think I'll do on the weekend.

Julien Danjou: Desktop notification support for Emacs

This last weeks, I've worked on implementing the Desktop Notification Specification into Emacs. It allows sending desktop notification in a very simple way.

(notifications-notify
    :title "You've got mail!"
    :body "There's 34 mails unread"
    :app-icon "~/.emacs.d/icons/mail.png"
    :urgency 'low)
It supports the protocol signals (NotificationClosed and ActionInvoked) and the two main methods (Notify and CloseNotification). The methods specification are implemented entirely (hints, replaces, actions, icon, etc). The signals are supported via callbacks function provided on the notification creation. It have been merged into Emacs trunk today.
2010-06-09  Julien Danjou  <julien@danjou.info>
        * net/notifications.el: New file.
This also allowed me to discover, raise and fix a bug in the D-Bus binding of Emacs, which will be probably fixed in trunk soon.

8 June 2010

Dirk Eddelbuettel: Rcpp 0.8.1

Early this morning I sent Rcpp version 0.8.1 off to CRAN and Debian. In the meantime, Romain has already provided a very nice blog post about it. There are a few fairly visible new things in this release. As we want to focus the next few minor releases on completing the documentation, we started by adding a total of four (!!) new vignettes: The most interesting new feature is what we call Rcpp modules and is modeled after Boost::Python. This makes it pretty easy to expose C++ functions and classes to R -- without having to write glue code. This is pretty new and may change a tad over the coming releases, but it is also quite exciting. Other changes concern more improvements for use of inline which should now allow packages like our RcppArmadillo to be used with it, and some bug fixes. The full NEWS entry for this release follows below:
0.8.1   2010-06-08
    o   This release adds Rcpp modules. An Rcpp module is a collection of
        internal (C++) functions and classes that are exposed to R. This
        functionality has been inspired by Boost.Python.
        
        Modules are created internally using the RCPP_MODULE macro and
        retrieved in the R side with the Module function. This is a preview 
        release of the module functionality, which will keep improving until
        the Rcpp 0.9.0 release. 
        The new vignette "Rcpp-modules" documents the current feature set of
        Rcpp modules.
        
    o   The new vignette "Rcpp-package" details the steps involved in making a
        package that uses Rcpp.
    o   The new vignette "Rcpp-FAQ" collects a number of frequently asked
        questions and answers about Rcpp.
    o   The new vignette "Rcpp-extending" documents how to extend Rcpp
        with user defined types or types from third party libraries. Based on
        our experience with RcppArmadillo
        
    o   Rcpp.package.skeleton has been improved to generate a package using 
        an Rcpp module, controlled by the "module" argument
    o   Evaluating a call inside an environment did not work properly
        
    o   cppfunction has been withdrawn since the introduction of the more
        flexible cxxfunction in the inline package (0.3.5). Rcpp no longer
        depends on inline since many uses of Rcpp do not require inline at
        all. We still use inline for unit tests but this is now handled
        locally in the unit tests loader runTests.R. 
        Users of the now-withdrawn function cppfunction can redefine it as:
        
           cppfunction <- function(...) cxxfunction( ..., plugin = "Rcpp" )
    o   Support for std::complex was incomplete and has been enhanced.
    o   The methods XPtr<t>::getTag and XPtr<t>::getProtected are deprecated, 
        and will be removed in Rcpp 0.8.2. The methods tag() and prot() should
        be used instead. tag() and prot() support both LHS and RHS use. 
    o   END_RCPP now returns the R Nil values; new macro VOID_END_RCPP
        replicates prior behabiour
        
As always, even fuller details are in Rcpp Changelog page and the Rcpp page which also leads to the downloads, the browseable doxygen docs and zip files of doxygen output for the standard formats. A local directory has source and documentation too. Questions, comments etc should go to the rcpp-devel mailing list off the R-Forge page

Adrian von Bidder: Blue Velvet

A somewhat na ve young man, a kidnapping, a policeman's daughter, a night club singer, said policeman's partner being involved, a love triangle, a pervert and (probably because it's Lynch) a cut off ear. What more do you need ... ? Or, in other words, I absolutely regret not having seen Blue Velvet before. In contrast, Pink Flamingos takes its fight over the title of the filthiest woman alive (which sets the whole plot in motion) a bit too literal for my taste. I like movies that leave more things up to the imagination of the spectator. Or perhaps it's just that my sense of aesthetics doesn't agree with John Water's. (And to the person who knew nothing bettter to say than You idiot to my negative critique about Tarantino's Inglourious Basterds: I don't delete comments on my blog that don't agree with me. But I do not tolerate personal attacks. Post it to your own blog. You're as entitled to your opinion as I am.)

Mike Hommey: Playing with icegrind

In the past few days, I ve been playing with icegrind, a little valgrind plugin that Taras Glek wrote to investigate how Firefox startup spends its time in libxul.so reading/initialization, mostly. I invite you to check out his various posts on the subject, it s an interesting read. After some fiddling with the original icegrind patch in the bug linked above, I got some better understanding on the binary initialization phase (more on that in another post), as we could call it, and hit some problems due to problems in icegrind and elflog. The latest version of the icegrind patch as of writing solved my main problem half way (though it needs further modifications to work properly, see below). What icegrind actually does is to track memory accesses in mmap()ed memory. When the program being profiled mmap()s a file, icegrind looks for a corresponding sections file next to it (e.g. libxul.so.sections for libxul.so ). The sections file contains offsets, sizes, and sections names, that will be used by icegrind to report the accesses. Whenever the profiled program makes memory accesses (whether it is for instructions or data) within the mmap()ed range, icegrind will add the corresponding section name in a log file (e.g. libxul.so.log for libxul.so ). Please note it will only do so for the first access in the given section. To generate section information for ELF files, Taras also hacked an elflog program that scans an ELF binary (program or library) and will output sections for symbols present in its symtab. This means the binary needs not to be stripped, though the full fledged debugging symbols are not needed. It outputs the sections names in a form that would be reusable in a linker script after a build with the -ffunction-sections and -fdata-sections compiler options, but that s mostly irrelevant when what you are after is only to see what is going on, not to reorder the sections at link time. There are glitches in the way elflog works that makes the section names for .bss symbols wrong (they will start with .symtab, .shstrtab, .comment, etc. instead of .bss). Also, technically, the .bss section is not mapped from the file. Note icegrind has rough edges, is still experimental, and isn t very user friendly, as in unix permissions, because its input and output files need to be next to the file being mmap()ed, and when that is a library in /usr/lib, well, you need write access there ; or you need to copy the library in a different directory and adjust LD_LIBRARY_PATH. Anyways, it s already useful as it currently is. If you want to play with it yourself, here are steps that worked well for me: Once you re done with this setup, you are ready to start playing: Obviously, you don t have to play around with Firefox. You can try with other libraries, or even programs. You ll see in a subsequent post, however, that to get more interesting information, the elflog output is unfortunately not enough.

Uwe Hermann: flashrom 0.9.2 released -- Open-Source, crossplatform BIOS / EEPROM / flash chip programmer

The long-pending 0.9.2 version of the open-source, cross-platform, commandline flashrom utility has been released. From the announce:
New major user-visible features:
* Dozens of newly supported mainboards, chipsets and flash chips.
* Support for Dr. Kaiser PC-Waechter PCI devices (FPGA variant).
* Support for flashing SPI chips with the Bus Pirate.
* Support for the Dediprog SF100 external programmer.
* Selective blockwise erase for all flash chips.
* Automatic chip unlocking.
* Support for each programmer can be selected at compile time.
* Generic detection for unknown flash chips.
* Common mainboard features are now detected automatically.
* Mainboard matching via DMI strings.
* Laptop detection which triggers safety measures.
* Test flags for all part of flashrom operation.
* Windows support for USB-based and serial-based programmers.
* NetBSD support.
* DOS support.
* Slightly changed command line invocation. Please see the man page for details. Experimental new features:
* Support for some NVIDIA graphics cards.
* Chip test pattern generation.
* Bit-banging SPI infrastructure.
* Nvidia MCP6*/MCP7* chipset detection.
* Support for Highpoint ATA/RAID controllers. Infrastructural improvements and fixes:
* Lots of cleanups.
* Various bugfixes and workarounds for broken third-party software.
* Better error messages.
* Reliability fixes.
* Adjustable severity level for messages.
* Programmer-specific chip size limitation warnings.
* Multiple builtin frontends for flashrom are now possible.
* Increased strictness in board matching.
* Extensive selfchecks on startup to protect against miscompilation.
* Better timing precision for touchy flash chips.
* Do not rely on Linux kernel bugs for mapping memory.
* Improved documentation.
* Split frontend and backend functionality.
* Print runtime and build environment information.
The list of supported OSes and architectures is slowly getting longer, e.g. these have been tested: Linux, FreeBSD, NetBSD, DragonFly BSD, Nexenta, Solaris and Mac OS X. There's partial support for DOS (no USB/serial flashers) and Windows (no PCI flashers). Initial (partial) PowerPC and MIPS support has been merged, ARM support and other upcoming. Also, the list of external (non-mainboard) programmers increases, e.g. there is support for NICs (3COM, Realtek, SMC, others upcoming), SATA/IDE cards from Silicon Image and Highpoint, some NVIDIA cards, and various USB- or parallelport- or serialport- programmers such as the Busirate, Dediprog SF100, FT2232-based SPI programmers and more. More details at flashrom.org and in the list of supported chips, chipsets, baords, and programmers. I uploaded an svn version slightly more recent than 0.9.2 to Debian unstable, which should reach Debian testing (and Ubuntu I guess) soonish.

Matt Zimmerman: DevOps and Cloud

DevOps I first heard about DevOps from Lindsay Holmwood at linux.conf.au 2010. Since then, I ve been following the movement with interest. It seems to be about cross-functional involvement in software teams, specifically between software development and system administration (or operations). In many organizations, especially SaaS shops, these two groups are placed in opposition to each other: developers are driven to deliver new features to users, while system administrators are held accountable for the operation of the service. In the best case, they maintain a healthy balance by pushing in opposite directions, but more typically, they resent each other for getting in the way, as a result of this dichotomy:
Development Operations
is responsible for creating products offering services
is measured on delivery of new features high reliability
optimizes by increasing velocity controlling change
and so is perceived as reckless and irresponsible obstructing progress
Of course, both functions are essential to a viable service, and so DevOps aims to replace this opposition with cooperation. By removing this friction from the organization, we hope to improve efficiency, lower costs, and generally get more work done.
So, DevOps promotes the formation of cross-functional teams, where individuals still take on specialist development or operations roles, but work together toward the common goal of delivering a great experience to users. By working as teammates, rather than passing work over the wall , they can both contribute to development, deployment and maintenance according to their skills and expertise. The team becomes a devops team, and is responsible for the entire product life cycle. Particular tasks may be handled by specialists, but when there s a problem, it s the team s problem. Some take it a step further, and feel that what s needed is to combine the two disciplines, so that individuals contribute in both ways. Rather than thinking of themselves as developers or sysadmins , these folks consider themselves devops . They work to become proficient in both roles, and to synthesize new ways of working by drawing on both types of skills and experience. A common crossover activity is the development of sophisticated tools for automating deployment, monitoring, capacity management and failure resolution. DevOps meets Cloud Like DevOps, cloud is not a specific technology or method, but a reorganization of the model (as I ve written previously). It s about breaking down the problem in a different way, splitting and merging its parts, and creating a new representation which doesn t correspond piece-for-piece to the old one. DevOps drives cloud because it offers a richer toolkit for the way they work: fast, flexible, efficient. Tools like Amazon EC2 and Google App Engine solve the right sorts of problems. Cloud also drives DevOps because it calls into question the traditional way of organizing software teams. A development/operations division just doesn t fit cloud as well as a DevOps model. Deployment is a classic duty of system administrators. In many organizations, only the IT department can implement changes in the production environment. Reaping the benefits of an IaaS environment requires deploying through an API, and therefore deployment requires development. While it is already common practice for system administrators to develop tools for automating deployment, and tools like Puppet and Chef are gaining momentum, IaaS makes this a necessity, and raises the bar in terms of sophistication. Doing this well requires skills and knowledge from both sides of the fence between development and operations, and can accelerate development as well as promote stability in production.
This is exemplified by infrastructure service providers like Amazon Web Services, where customers pay by the hour for black box access to computing resources. How those resources are provisioned and maintained is entirely Amazon s problem, while its customers must decide how to deploy and manage their applications within Amazon s IaaS framework. In this scenario, some operations work has been explicitly outsourced to Amazon, but IaaS is not a substitute for system administration. Deployment, monitoring, failure recovery, performance management, OS maintenance, system configuration, and more are still needed. A development team which is lacking the experience or capacity for this type of work cannot simply switch to an IaaS model and expect these needs to be taken care of by their service provider.
With platform service providers, the boundaries are different. Developers, if they build their application on the appropriate platform, can effectively outsource (mostly) the management of the entire production environment to their service provider. The operating system is abstracted away, and its maintenance can be someone else s problem. For applications which can be built with the available facilities, this will be a very attractive option for many organizations. The customers of these services may be traditional developers, who have no need for operations expertise. PaaS providers, though, will require deep expertise in both disciplines in order to build and improve their platform and services, and will likely benefit from a DevOps approach. Technical architecture draws on both development and operations expertise, because design goals like performance and robustness are affected by all layers of the stack, from hardware, power and cooling all the way up to application code. DevOps itself promotes greater collaboration on architecture, by involving experts in both disciplines, but cloud is a great catalyst because cloud architecture can be described in code. Rather than talking to each other about their respective parts of the system, they can work together on the whole system at once. Developers, sysadmins and hybrids can all contribute to a unified source tree, containing both application code and a description of the production environment: how many virtual servers to deploy, their specifications, which components run on which servers, how they are configured, and so on. In this way, system and network architecture can evolve in lockstep with application architecture. Cloudy promises such as dynamic scaling and fault tolerance call for a DevOps approach in order to be realized in a real-world scenario. These systems involve dynamically manipulating production infrastructure in response to changing conditions, and the application must adapt to these changes. Whether this takes the form of an active, intelligent response or a passive crash-only approach, development and operational considerations need to be aligned. So what? DevOps and cloud will continue to reinforce each other and gain momentum. Both individuals and organizations will need to adapt in order to take advantage of the opportunities provided by these new models. Because they re complementary, it makes sense to adopt them together, so those with expertise in both will be at an advantage.

Russell Coker: Is the PC Dying?

I just read an interesting article about the dispute between Microsoft and Apple about types of PC [1]. Steve Jobs predicted a switch from desktop PCs to portable devices, while Steve Ballmer of Microsoft claimed that the iPad is just a new PC. Defining a PC I think that the defining characteristic of the IBM Compatible PC was it s open architecture. Right from the start the PC could have it s hardware expanded by adding new circuit boards into slots on the motherboard (similar to other PC systems of that era such as the Apple 2 and the S-100 bus). The deal with IBM included Intel sharing all it s CPU designs with other manufacturers such as NEC and AMD from the 8086 until the mid-90 s. AMD specialised in chips that were close copies of Intel chips at low prices and higher clock rates while NEC added new instructions. Compaq started the PC clone market as well as the laptop market, and system software for the IBM compatible PCs was primarily available from IBM and Microsoft in the early days, along with less popular variants such as CP/M86, Novell Netware and others. In the late 80 s there was OS/2 as an alternate OS and Windows as one of several optional GUI environments to run on top of MS-DOS or PC-DOS. In the mid 90 s PCs were used for running protected mode OSs such as Linux and Windows/NT. Now if we look at a system such as a Netbook then it clearly misses some of the defining characteristics of the desktop PC. I can t upgrade a Netbook in any meaningful way changing a storage device or adding more RAM does not compare to adding an ISA/MCA/EISA/VL-Bus/PCI/PCIe expansion card. With my EeePC 701 I don t even have an option of replacing the storage as it is soldered to the motherboard! A laptop allows me to add a PCMCIA or PC-Card device to expand it, but with a maximum of two cards and a high price this isn t a great option. What is Best for Home Users? For a while now my parents have been using 3G net access for their home Internet use [2]. So it seems that a laptop provides greater benefits for their use now than it previously did when they used Cable and ADSL net access. My parents have been considering getting a new monitor (1920*1080 resolution monitors are getting insanely cheap nowadays) and driving such a monitor effectively might require a more capable PC. I recently bought myself a nice refurbished Thinkpad for $796 [3], it seems likely that I could find a refurbished Thinkpad at auction which is a little older and slower for a lower price, even buying an old T41p would be a reasonable option. This would give my parents not only the option of using the Internet when on holidays, but also in a different part of their house when they are at home. The Apple iPad would probably be quite a reasonable Internet platform for my parents if it wasn t for the fact that it uses DRM. While it s not a great platform for writing, my parents probably don t do enough that it would be a huge problem for them. So I might look for a less restrictive tablet platform for my parents. At the moment the best resolution for a tablet seems to be 1024*768, but I expect that some tablets (maybe with a hybrid tablet/laptop design like the Always Innovating Smartbook [4]) with a higher resolution will be released soon. I hope that the iPad and other closed devices don t get any serious market share, but it seems likely that OSs such as Android which are only slightly more open will have a significant market share. Ultra-Mobile Design vs PCs Design One significant problem with ultra-mobile devices is that they make significant engineering trade-offs to get the small size. For a desktop system there are lots of ways of doing things inefficiently, running the AMD64 or i386 architecture which is wasteful of energy and having lots of unused space inside the box in case you decide to upgrade it. But for a laptop there are few opportunities for being inefficient, and for a tablet or smart phone everything has to be optimised. When the optimisation of a device starts by choosing a CPU that s unlike most other systems (note that there is a significant range of ARM CPUs that are not fully compatible with each other) it makes it very difficult to produce free software to run it. I can salvage a desktop PC from a rubbish bin and run Linux on it (and I ve done that many times), but I wouldn t even bother trying to run Linux on an old mobile phone. It seems that in the near future my parents (and many other people with similar needs) will be best suited by having a limited device such as a tablet that stores all data on the Internet and not having anything that greatly resembles a PC. In many ways it would be easier for me to support my parents by storing their data in the cloud and then automatically backing it up to removable SATA disks than with my current situation of supporting a fully capable PC and backing it up to a USB device whenever I visit them. I m also considering what to do for some relatives who are about to go on a holiday in Europe, they want to be able to send email etc. It might not be possible just yet, but it seems like an ideal way of doing this would be to provide them with something like an iPad that they can use with a local 3G SIM for the country that they stay in and they could then upload all their best photos to some server that I can backup and send email to everyone they know. An iPad isn t good for this now as you don t want to go on holidays in another country while carrying something that is really desirable to thieves. Ultra Mobile Devices are Killing PCs It seems to me that Google Android and the Apple iPad/iPhone OS are taking over significant parts of the PC market. The people who are doing traditional PC things are increasingly using Laptops and Netbooks, and the number of people who get the freedom that a PC user did in the 80 s and 90 s is decreasing rapidly. I predict that by 2012 the majority of Linux systems will be running Google Android on hardware that doesn t easily allow upgrading to more open software. At the moment probably the majority of Linux systems are wireless routers and other embedded devices that people don t generally think about. But when iPad type devices running a locked-down Linux installation start replacing Ubuntu and Fedora desktop systems people will take notice. I don t think that the death of the PC platform as we know it will kill Linux, but it certainly won t do us any good. If there were smarter people at Microsoft then they would be trying to work with the Linux community on developing innovative new ways of using desktop PCs. Of all the attempts that Microsoft has made to leave the PC platform the only success has been the X-Box which is apparently doing well. Tablet devices such as the iPad could work really well in a corporate environment (where MS makes most of it s money). On many occasions I ve been in a meeting and we had to adjourn due to someone needing to go to their desk to look something up. If everyone had an iPad type device at their desk that used a wired network when it was available and encrypted wireless otherwise then for a meeting everyone could take their tablet without it s keyboard and be able to consult all the usual sources of data without any interruption. Could a high-resolution version of the iPad kill MS-Windows in the corporate environment?

7 June 2010

John Goerzen: Boys

Yesterday afternoon, it was nice outside. Terah, Jacob, Oliver, and I went outside. I had my camera to take photos while Jacob and Oliver mostly played. We did try to pose them a bit, but the overall plan was to just take some photos of them doing their own thing. So I wound up taking 824 photos. Hurray for digital cameras. We narrowed that down to a few of our favorites, which you can view as a slideshow. I ll highlight few of those below. IMG_3926.JPG
Jacob walking down the drive way, gazing at all the beans coming up off in the distance IMG_3910.JPG
Hmm, Oliver, let me see too IMG_3823.JPG
Running is fun! IMG_3818.JPG
Peek-a-boo IMG_3802.JPG
Goerzen s Law of Child Photography: If you attempt to get them to pose, a minimum of one boy will have a weird expression at any given time. IMG_3763.JPG
Also, chances are good that a cat will sneak in and also do something. IMG_3710.JPG
My imagined conversation for this one: Here Oliver, this is how you use a piece of bark. Quiet, I m trying to eat this grass. IMG_3718.JPG
Oliver decides that grass stuck on his teeth isn t fun IMG_3684.JPG
No explanation for this one. IMG_3644.JPG
Classic brothers. Jacob is using a piece of bark to mess around in some dirt, while Oliver quietly learns how to do it. He never said it, but I can easily imagine him saying, Here Oliver, here s what you do with bark: you dig up dirt like this! It s funny! IMG_3619.JPG
BONZAI!!! IMG_3580.JPG
Guess I better watch where I point that camera IMG_3477.JPG
Here kitty get ready for some more petting *thwack* Strangely the cat seemed to love it. Our other cat avoids Oliver. IMG_3404.JPG
Jacob deriving a great deal of joy from telling us that his shirt says big SPIDER . He came up with that joke himself and thought it was hilarious. IMG_3366.JPG
This is one of a few photos of Jacob wearing a suit that I once wore. IMG_3292.JPG
It s hard to stand still when the hammock has a great train whistle on it. IMG_3241.JPG
I have no idea what he s planning here. But really, I think I should be afraid. IMG_3191.JPG
It s a fridge door. Yay?

Mart&iacute;n Ferrari: Python WTF

Lately, I have recurring WTF moments when working with Python. I'm still more or less a novice in Python, as I started to use it in my day job last year, so sometimes it could be blamed to ignorance. Today I was writing some code that takes any file descriptor as argument, and thought it could be nice to accept also objects that represent one. But it seems there is no common ancestor to file objects and socket objects, for example. In Perl, I'd just check for IO::Handle. Then, I wrote code to check if a passed argument was a socket, or a file descriptor to one, with some obvious check: isinstance(s, socket.socket). WRONG, when you create sockets with socketpair, they are of an undocumented type which is not a descendant of socket, nor of SocketType! (There is a patch for this since 2007) In general, I have found a lack of any reasonable object hierarchy, and many inconsistencies in the low-level interfaces, which is a pity, because Python is in general quite tidy. Comparing with Perl is unavoidable, and I would have expected that Python had learnt more from it. Another thing that amazes me is the lack of anything like CPAN, which is one of the reasons Perl was so successful. The cheese factory doesn't come close, as you need to publish your files somewhere else, there is no automated testing, no automatically generated documentation, or anything that requires access to the source code. In Perl-land, many people loathe the venerable MakeMaker, and some of the alternatives are ugly as hell. The Python equivalent (or so) to Makemaker, distutils, looks to me like a bad joke: advanced customisation is black magic (if possible at all), and doesn't provide absolutely basic things like running your unit tests! After fighting with it for some days, I decided to go back writing my own Makefile and calling distutils just to build and install. Tags: Planet Debian, Planet Lugfi, Programaci n

Steve McIntyre: Also sad about the Poulsbong^H^H

Apropos Matthew's post... I picked up a cheap netbook for Jo a couple of months ago, an Acer Aspire One 751. She liked the look and feel of the machine, and it was much smaller and more carryable than the massive old Dell "slab" she'd been using previously. Got a very good deal on it too, as it was the last one in stock at the local Comet store. All went well until we got it home and I started playing with it. That was when I found the painful truth: it was based on the Poulsbo, using Intel's crippled GMA500 graphics chipset. Up until then, I'd been very happy with buying Intel kit: for the last few years it's been a sure sign that the hardware would work well with Debian and Linux. Now they've come out with a crappy product that has destroyed that goodwill. I spent many hours working through various options to try and get this new netbook up and running properly using Debian, but to no avail - the various binary blobs wanted newer versions of code than was in Lenny and (by then) older stuff than was available in Squeeze. In the end I gave up and installed an outdated version of Ubuntu on the machine just so Jo could have it working for her when we went on holiday together. Since then, she's had to get used to the machine locking up once or twice a day while she's using it (something I can only assume is caused by the shitty drivers). She's happy enough in that it's much better than her old Vista-infested Dell machine, but it's really not a great experience for her compared to the Thinkpads she sees others using reliably and flawlessly at home. At some point I guess we'll simply ditch the machine altogether and get something less nasty. Thanks for the good stuff you used to make, Intel, but you've lost your way. I'll be damned careful next time to avoid this trap.

Chris Lamb: Distributing locking with Python and Redis

This is already possible with Memcache, but if you are already drinking the Koolaid...
import time
class Lock(object):
    def __init__(self, key, expires=60, timeout=10):
        """
        Distributed locking using Redis SETNX and GETSET.
        Usage::
            with Lock('my_lock'):
                print "Critical section"
        :param  expires     We consider any existing lock older than
                             expires  seconds to be invalid in order to
                            detect crashed clients. This value must be higher
                            than it takes the critical section to execute.
        :param  timeout     If another client has already obtained the lock,
                            sleep for a maximum of  timeout  seconds before
                            giving up. A value of 0 means we never wait.
        """
        self.key = key
        self.timeout = timeout
        self.expires = expires
    def __enter__(self):
        timeout = self.timeout
        while timeout >= 0:
            expires = time.time() + self.expires + 1
            if redis.setnx(self.key, expires):
                # We gained the lock; enter critical section
                return
            current_value = redis.get(self.key)
            # We found an expired lock and nobody raced us to replacing it
            if current_value and float(current_value) < time.time() and \
                redis.getset(self.key, expires) == current_value:
                    return
            timeout -= 1
            time.sleep(1)
        raise LockTimeout("Timeout whilst waiting for lock")
    def __exit__(self, exc_type, exc_value, traceback):
        redis.delete(self.key)
class LockTimeout(BaseException):
    pass
One common use case for distributed locks in web applications is to prevent clients dog-piling onto an expensive cache key:
def cache_without_dogpiling(key, cb, cache_expiry=None, *args, **kwargs):
    val = cache.get(key)
    if val is not None:
        return val
    # Cache miss; gain the lock to prevent multiple clients calling cb()
    with Lock(key, *args, **kwargs):
        # Check cache again - another client may have set the cache
        val = cache.get(key)
        if val is None:
            val = cb()
            cache.set(key, val, cache_expiry)
        return val
def slow():
    print "Inside slow()"
    return 1 + 1 # Python is slow
>>> cache_without_dogpiling('my_key', slow, 60 * 10)
Inside slow()
2
>>> cache_without_dogpiling('my_key', slow, 60 * 10)
2
As a bonus, if you don't want your test or development environment to rely on Redis, you can replace it with a no-op lock:
import contextlib
@contextlib.contextmanager
def Lock(*args, **kwargs):
    yield

Sjoerd Simons: Is that a tea cosy on your head?

Since some time the good people at NlNet have been sponsoring Collabora to add multi-party audio/video calling to XMPP and do an implementation of this in Telepathy. This project is otherwise known as Muji. This work has resulted in: To proof it actually works, a nice screenshot of the demo client in a 4-way call: 4-way Muji Call The screenshot is featuring myself in Collabora's UK office (top-left), Robert McQueen from a hotelroom in Taipei (top-right), Will Thompson and Magical trevor also from the Collabora UK office (bottom-left) and Mike Ruprecht from somewhere in Missouri. So we were quite spread out over our little planet. Both audio and video quality was quite good, even though the network in robs hotel was a bit flaky from time to time. In case you want to try it out have a look at the MujiDemoClient page.

Riku Voipio: WebGL on N900

With the recent "PR1.2" firmware upgrade of Nokia N900, a new feature was enabled in the browser - WebGL. WebGL is cool and scary. The cool part is that it is a chance to bring lots of games to to Linux users. The screenshot is from Match3D, a 3D tic-tac-toe game.

The best way to get started is with the Learning webgl tutorial. Passing through the lessons, some are clearly featuring buggy graphics. I don't know if the website, N900 browser or the OpenGL ES driver is being buggy. Which brings the scary part of WebGL - not only does one need to deal with buggy browsers, one has to deal with buggy 3D hardware/drivers! WebGL is still very much work in progress, and on N900 the webGL is rather an "easter egg" than a proper feature. For example the 3D graphics from the GPU does an extra roundtrip via CPU before appearing on the screen.

Other WebGL resources are planet WebGL for following blogs about WebGL, the Khronos Demo repository and more demos can be found at CubicVR site. The last CubicVR demos feature another scary new browser feature (not yet supported on N900) - audio processing in JavaScript.

Julien Danjou: Announcing erc-track-score

A couple of months ago, I've started using ERC to hang out on IRC. I've read all the pages on EmacsWiki about it, just to see how far I could customize it. I must admit that I was not disappointed, even if I expected to be. It's quite a nice software, and once well configured it's more convenient that my old irssi setup. While browsing EmacsWiki, I read an interesting idea about channel scoring/temperature on the erc-track page. The idea is to see if it's worth jumping to an IRC channel to see what people are talking about. Challenge accepted! I sat up and started to dig though ERC source code to find the information I needed about variables and functions. I finally did write something nice, which I called erc-track-score. And yet another piece of software I wrote for my lovely Emacs! How does it work? Ha-ha, I was sure you would ask. You're so predictable, dude! Read the following, and you'll know everything you ever wanted to know about it since the moment you read the title of that blog entry. Which probably turned you on. Nasty you. First of all, the score of a channel starts at zero. Zero means "seriously, don't bother, nothing is happening here". Upon each new message arrival, the score is incremented by 1. If a new message contains a keyword, your nickname or is sent by a pal, the score is increased by configurable values, by default between 2 and 20 points, depending on the match type. On the other hand, when a message is send by some fool, the score is decreased by 1 by default. Obviously, if the score is going negative, you really should not jump to the channel. Finally, the score is permanently and slowly brought back to 0. By default, the score is decreased by 1 point every 10 seconds. Overall, reading the score should gives you a good idea of the channel temperature. I'm still not sure what is the best formula to compute the score, but so far the default values seem quite good. We'll see.

Next.

Previous.