Search Results: "nate"

10 November 2013

Jelmer Vernooij: Quantified Self

Dear lazyweb, I've been reading about what the rest of the world seems to be calling "quantified self". In essence, it is tracking of personal data like activity, usually with the goal of data-driven decision making. Or to take a less abstract common example: counting the number of steps you take each day to motivate yourself to take more. I wish it'd been given a less annoying woolly name but this one seems to have stuck. There are a couple of interesting devices available that track sleep, activity and overall health. Probably best known are the FitBit and the jazzed-up armband pedometers like the Jawbone UP and the Nike Fuelband. Unfortunately all existing devices seem to integrate with cloud services somehow, rather than giving the user direct access to their data. Apart from the usual privacy concerns, this means that it is hard to do your own data crunching or create a dashboard that contains data from multiple sources. Has anybody found any devices that don't integrate with the cloud and just provide raw data access?

9 November 2013

Bits from Debian: Last days to donate to Debian Outreach Program for Women

The matching program to help fund Debian participation in OPW will end in 6 days (November 14th). We need your help, and still have a ways to go to reach our funding targets. Please consider donating today! The rules are simple: If you'd like to participate as intern, the application deadline is very near (November 11th). You can find here more info on how to apply.

Russ Allbery: Review: Fantasy & Science Fiction, July/August 2011

Review: Fantasy & Science Fiction, July/August 2011
Editor: Gordon van Gelder
Issue: Volume 121, No. 1 & 2
ISSN: 1095-8258
Pages: 258
Nothing of particular interest in the book reviews in this issue, although I was entertained to see Charles de Lint review a collection of the Prince Valiant strip. I have memories of that strip being one of the most boring works of art created by mankind. De Lint, of course, quite likes it. Our tastes seem to be very disjoint, although I have to admit that I've not read it collected and it may be more coherent and more interesting in that format. The science column in this issue, by Paul Doherty and Pat Murphy, deserves special mention. It's on roshambo (rock-paper-scissors), human difficulties with randomness, and strategy in roshambo competitions. It's also the first essay I've read that clearly explains how there can be strategy to roshambo, and why that strategy is worth studying. Even though the primary topic of the column is randomness, it's worth reading from the perspective of strategy in competitive human vs. human games. "Bronsky's Dates with Death" by Peter David: Anyone familiar with PAD's body of work will immediately expect a humorous story with some deeper thoughtful bits, and that's exactly what this is. Bronsky, the title character, is a man almost incapable of saying exactly what's on his mind, and what's on his mind is his eventual death. Not that it bothers him that much; he's just thinking a lot about it. But his incessant discussion of it certainly bothers the people around him. This leads to a few entertaining exchanges with his family, and then to more entertaining exchanges with Death. Or Deaths, as there appear to be several different kinds. I found the exact metaphysics a bit confused, but the ending was still touching and a bit funny. (7) "The Way It Works Out and All" by Peter S. Beagle: This is a reprint of a special fund-raising story about Avram Davidson, so a lot of it was lost on me given that I know almost nothing about Davidson and have yet to get to any of his novels I own. But even without that background, it's a diverting story of hidden and parallel worlds and unexpected explorations. There isn't all that much in the way of a plot, but it's a nice bit of characterization set against a fun SF twist. (6) "Less Stately Mansions" by Rob Chilson: This is a story about conservatism in life, about a farmer staying on his farm and resisting change, and about nostalgia, but I liked it much better than I normally like stories with those themes. It's set against a future world in which climate change is making life increasingly untenable. Humans are migrating into space colonies of various types, but Jacob refuses. This frustrates some parts of the family who want a piece of the substantial cash-out he's being offered for his farm, which of course makes Jacob even more stubborn. It's more of an elegy than a story, but I think it captures a particular stubborn mood, and a conscious decision to go with what one knows even if it doesn't have a long future, quite well. (7) "The Ants of Flanders" by Robert Reed: This is the novella of the issue, and, as you might expect from the author, it's thoughtful, meaty, and satisfying. At the start of the book, the planet is visited by an extraterrestrial ship (or ships it's not entirely clear at first). One of the people near one landing is Bloch, a huge teenager who has an odd lack of natural fear. He stays near the center of the story as Reed slowly develops a cosmology and a galactic political background that makes it clear humans may be incidental to everything that's happening. I liked this. It's a touch depressing in spots, and Bloch is a strange protagonist, but the cosmology is not the normal SF background and sparks some thoughts about how a status quo would be maintained by powers that don't care much about individual lives. The interlude with the leopard is nicely done, even if its significance is inobvious at first. (7) "Hair" by Joan Aiken: This is one of those weird Gothic horror stories about creepy families and half-explained supernatural events that some people love and that do nothing for me. (3) "The Witch of Corinth" by Steven Saylor: This is straight historical fantasy, featuring a Roman and his Greek tutor (heroes, apparently, of a series of historical mysteries) visiting the ruins of Corinth and encountering some bloody and dangerous local conflicts. It's slow and atmospheric, carried along by good characterization and description of ruins. It's not that much of a mystery the characters don't figure things out as much as stick around until the answer becomes obvious but it kept me entertained throughout a sizable story. Numerous elements of the story appear to be fantasy and then get other explanations, but there is a fantasy twist to the ending. (6) "Sir Morgravain Speaks of Night Dragons and Other Things" by Richard Bowes: This odd story is set among the knights of King Arthur on Avalon, where they sleep (mostly), awaiting their call to aid Britain again. Most of the story is told as one-sided dialogue from Morgravain, interspersed with some italic narration. Again, not much of a plot; the story, as such, is figuring out what Morgravain is doing and the point of his interactions with the other knights. I thought it was slight and oddly pointless, but I may have just missed the point. (4) "Someone Like You" by Michael Alexander: A time travel story, but one that's less about time travel per se than about examining and speculating about the alternate paths childhood could take and whether those changes produce different people. It takes some time to figure out what's going on, during which Alexander fills in the protagonist's past and the murder mystery that drives the tale. The time travel mechanism is blatantly hand-waved, making this more of a fantasy than an SF story, which matches the emphasis on emotion and psychology. It's not a bad story, and I think I see where the author was going with the slowly-constructed central conflict, but I still found it hard to take the conflict that seriously. One of the problems with time travel is that undermining of causality also undermines finality of decisions and consequences in ways that can rob stories of their punch. (6) "The Ramshead Algorithm" by KJ Kabza: The first-person protagonist is a well-respected and experienced fixer in a world of chaos and dimensional connection, a world with physics and inhabitants very much unlike ours. But the story doesn't spend much time there; his connection to his home earth is threatened, and he returns to try to stabilize it, which leads to the reader discovering that his family considers him a worthless appendage on a wealthy business family whose sole purpose in life is to stay out of their way. And his portal is rooted in a hedge maze that his father intends to demolish. This is one of those stories that gets more interestingly complex the deeper one gets into it. Ramshead's family is badly screwed up along multiple axes, but not without some hope of redemption. He's desperate and ineffective in his home universe, but more confident and capable when it comes to dealing with dimensional portal problems (although he still seems very young and relies on tools given to him by others). And there's always more going on than it first appears, and not as few obvious villains as it first appears. Good stuff, although I would have liked to understand more about Ramshead's world. (7) Rating: 7 out of 10

7 November 2013

Matt Zimmerman: Management: a rant

You keep using that word. I do not think it means what you think it means. -Inigo Montoya
Having worked in full-time management positions for some years now, I am increasingly convinced that management is widely misunderstood as a role, as a discipline and as a field, and that this makes a lot of lives more difficult and stressful than necessary. It is the subject of much speculation and misbelief, and I ve chosen a few of my favorite examples to deconstruct here. Misbelief #1: management is what managers do I ve noticed a trend among a certain class of companies, whose employees will tell anyone who will listen that there is no management in their organization, they never plan to have any, and neither should you. I think these statements are respectively a lie, a na ve belief, and a piece of bad advice. Usually, these companies are just a few years old and relatively small, most of the people in the company have been there for less than a year, and the speaker is trying to persuade us what a unique and innovative company they work for because nobody there is a manager . They invariably have not read The Tyranny of Structurelessness. Management is the practice of enabling people to effectively cooperate. A manager is someone whose job is to do that. It s that simple. It usually involves tasks such as sharing information, agreeing on a course of action, dividing up work, and figuring out what to do when there s a problem. They re things that every team needs to do, whether anyone is designated a manager or not. Teams can function without managers, but they can t function properly without management. Someone (or everyone) has to do the work to make cooperation possible. Modern management is a specialized discipline, which draws on a broad range of skills in communication, psychology, empathy, problem-solving, leadership, and more. These skills aren t unique to managers, but it often makes sense to designate certain people to do more of the management work, on behalf of the team. By devoting more of their time and attention to it, they free other members of the team to focus on other tasks. They can act as a coordinator to help the team stay in sync, and by focusing on this job, they may be able to do a better job of it, and acquire a higher level of skill through practice and study. But it remains an inherently collaborative practice. Misbelief #2: management is about telling people what to do There are many different varieties of management, each of which is oriented toward a particular type of team or organization. Factories are managed differently from design studios, large companies are managed differently from small companies, and every team has its own distinct management style which arises from the unique group of people involved. Some managers are specialists in a particular type of management, while others are more generalists. The telling people what to do style of management is called command and control . It s characterized by authority, hierarchy, and strict adherence to protocol. It s widely employed by military organizations, and by the managers we see in television and film. It has some advantages and disadvantages, which I won t discuss here. My point is that it is just one example, but this example is used to represent the general concept of management. Self-organization, where no one in particular is responsible for group decisions, is another, quite different, style of management. Small, self-organizing teams are capable of amazing feats of productivity. They re less difficult to manage because they re comparatively simple, and so simple tools and techniques work well. Everyone can be fully aware of what everyone else is doing, and new information propagates quickly throughout the team. But as the team or organization grows, it will often outgrow this way of working, and needs to adapt. There is no single management approach which works universally well. Misbelief #3: management is a promotion You know the story. When an employee is successful within their area of expertise, someone will eventually offer them a management role as a reward for their good work. This is utter nonsense. Management is not a promotion: it s a career change. It means starting over as a beginner in a new discipline and learning from the ground up. Domain expertise is important, as a manager needs to understand the work of the other people on their team, but it is no longer paramount. The team, the human system, becomes their focus. When organizations fail to provide career advancement within a discipline, people may turn to management as the only way to get promoted , only to discover that they are completely unprepared for this new field, and often their new job when they realize what they ve gotten into. If someone were promoted from a position as a financial analyst to a new job as a biochemist with no training or expertise, we would probably find this bizarre. But this is analogous to what happens to new managers all the time, and has become almost standard practice in many organizations and industries. So what? Management is misunderstood. So are science, engineering, and many other fields. What does it matter?
People leave managers not companies in the end, turnover is mostly a manager issue, - Marcus Buckingham & Curt Coffman, First, Break All the Rules
This mythology leads to massive organizational dysfunction, making it harder for everyone to do their jobs. It virtually guarantees incompetent management, which is a scourge on anyone who is exposed to it. It ruins days, weeks, jobs and careers. It leads talented people to leave companies, and it drives them out of their chosen professions. I recommend that we stop denigrating and ignoring management, and start doing a better job of it.

Michal Čihař: Weblate 1.8

Weblate 1.8 has been released today. It comes with lot of improvements, especially in registration process where you can now use many third party services. Full list of changes for 1.8: You can find more information about Weblate on it's website, the code is hosted on Github. If you are curious how it looks, you can try it out on demo server. You can login there with demo account using demo password or register your own user. Ready to run appliances will be soon available in SUSE Studio Gallery. Weblate is also being used https://l10n.cihar.com/ as official translating service for phpMyAdmin, Gammu, Weblate itself and others. If you are free software project which would like to use Weblate, I'm happy to help you with set up or even host Weblate for you. Further development of Weblate would not be possible without people providing donations, thanks to everybody who have helped so far!

Filed under: English SUSE Weblate 2 comments Flattr this!

5 November 2013

Johannes Schauer: announcing bootstrap.debian.net

The following post is a verbatim copy of my message to the debian-devel list. While botch produces loads of valuable data to help maintainers modifying the right source packages with build profiles and thus make Debian bootstrappable, it has so far failed at producing this data in a format which is: While human readability is probably still lacking (it's hard to write in a manner understandable by everybody about a complicated topic you are very familiar with), the bootstrapping results are now generated automatically (on a daily basis) and published in a per-source-package-basis as well. Thus let me introduce to you: bootstrap.debian.net Paul Wise encouraged me to set this up and also donated the debian.net CNAME to my server. Thanks a lot! The data is generated daily from the midnight packages/sources records of snapshot.debian.org (I hope it's okay to grab the data from there on a daily basis). The resulting data can be viewed in HTML format (with some javascript for to allow table sorting and paging in case you use javascript) per architecture (here for amd64). In addition it also produces HTML pages per source package for all source packages which are involved in a dependency cycle in any architecture (for example src:avahi or src:python2.7). Currently there are 518 source packages involved in a dependency cycle. While this number seems high, remember that estimations by calculating a feedback arc set suggest that only 50-60 of these source packages have to be modified with build profiles to make the whole graph acyclic. For now it is funny to see that the main architectures do not bootstrap (since July, for different reasons) while less popular ones like ia64 and s390x bootstrap right now without problems (at least in theory). According to the logs (also accessible at above link, here for amd64) this is because gcc-4.6 currently fails compiling due to a build-conflict (this has been reported in bug#724865). Once this bug is fixed, all arches should be bootstrappable again. Let me remind you here that the whole analysis is done on the dependency relationships only (not a single source package is actually compiled at any point) and compilation might fail for many other reasons in practice. It has been the idea of Paul Wise to integrate this data into the pts so that maintainers of affected source packages can react to the heuristics suggested by botch. For this purpose, the website also publishes the raw JSON data from which the HTML pages are generated (here for amd64). The bugreport against the bts can be found in bug#728298. I'm sure that a couple of things regarding understandability of the results are not yet sufficiently explained or outright missing. If you see any such instance, please drop me a mail, suggesting what to change in the textual description or presentation of the results. I also created the following two wiki pages to give an overview of the utilized terminology: Feel also free to tell me if anything in these pages is unclear. Direct patches against the python code producing the HTML from the raw JSON data are also always welcome.

3 November 2013

Russ Allbery: Review: The Walls of Westernfort

Review: The Walls of Westernfort, by Jane Fletcher
Series: Celaeno #2
Publisher: Bold Strokes
Copyright: 2004
Printing: March 2005
ISBN: 1-60282-349-9
Format: Kindle
Pages: 320
While this is the first book of the Celaeno series that I've read, it turns out to be the second book in the series. This is somewhat difficult to determine from sources on-line since the first three books in the series were published in the same year, but it's fairly obvious from reading synopses after having finished one of the books. I don't think it does any great damage to the story to read it out of order (indeed, it preserves the suspense around some plot elements), but you may want to seek out The Temple at Landfall first. Natasha Ionadis is a member of the Guard. The military services are divided into three parts in her world: the Rangers, who defend cities against bandits and others in the countryside; the Militia, who maintain law and order in the cities; and the Guard, who are responsible for guarding the temples and protecting the rituals and teachings of the state religion. She is a devout worshiper of Celaeno and delighted to be part of the Guard. But, as this book opens, she gets a very unexpected mission for a young private: a suicide mission into the heart of a heretic group in the wilds, heretics who have successfully defied the official religion and are in danger of setting up a self-sustaining community. The Walls of Westernfort has the surface trappings of a fantasy and does include some magic, but it slowly develops into more of a character story with a medieval (or, more accurately, medieval-inspired) backdrop. At the start, it appears that this mission will be an opportunity for Natasha to find the mentors and companions that she's never had before, but then her encounter with the heretics turns her world upside down. They're not the monsters that she had imagined, although their beliefs are still outrageous to her. One heretic in particular affects her deeply and introduces a strong lesbian romance element to the plot that dominates the rest of the book. I enjoyed the slow emergence of one aspect of the setting (that I'm about to spoil, so skip to the next paragraph if you don't want to hear it, although it would already be spoiled by reading the predecessor book or most of the blurbs). This is a world devoid of men; all the characters are women. This isn't part of the plot; it's just the unremarked normal. Fletcher tosses in a hand-waving explanation about halfway through, but it's only discussed in passing and never mentioned again. I really enjoy this technique, and enjoyed watching how long it took in the book before I noticed. There are so many books out there where men are the unremarked normal that it's a refreshing change to read the opposite (and notice how little it really matters), although it does require throwing in implausible magic to solve the problem of procreation. (That's apparently more the topic of The Temple at Landfall.) Plot-wise, The Walls of Westernfort is not complicated. The shape of the plot after Natasha's first encounter with the heretics is not likely to surprise any reader. But it's a simple plot well-executed, with distinct and fleshed-out characters and steady helpings of people being thoughtful and reasonable. The basic story carries plenty of natural conflict; Fletcher doesn't need to add much additional tension and wisely chooses not to, keeping the focus tightly on Natasha and her conflict between duty and conscience. I liked both of the people involved in the romance and could believe they'd fall in love, and I also liked that the romance was significant but not decisive. It's part of what helps Natasha expand her view of the world, but one could see how she would have made the right decision in the end even if the romance had not been present. The story does force some significant secret-keeping, but it doesn't draw cheap tension from mundane failure to communicate. All of the communication gaps here are believable and honest, driven by the characters' backgrounds, and absolutely necessary. I'm hypersensitive to romance plots based on communication failure, and I wasn't even grumbling. The series this book reminds me the most of is another lesbian romance in a fantasy-style setting: Catherine M. Wilson's When Women Were Warriors. The Walls of Westernfort is not as deep or philosophical, it's a bit more black and white in its morality, and I don't think it's quite as good of a book, but for me it had a similar tone of good people trying to do the right thing and finding one's way through ethical mazes. It's a bit slow to get started, but by the time Natasha's critical decision point arrived, I was fully invested in the story and had a hard time putting it down. Recommended if you're in the mood for a relatively light faux-medieval fantasy romance. I'm not rushing out to grab the other books in the series, but they went on my want list and I'll probably get them at some point. Followed by Rangers at Roadsend in the publication order sense, but apparently it's a prequel. Rating: 7 out of 10

2 November 2013

Erich Schubert: Numerical precision and "Big Data"

Everybody is trying (or pretending) to be "big data" these days. Yet, I have the impression that there are very few true success stories. People fight with the technology to scale, and have not even arrived at the point of doing detailed analysis - or even meta-analysis, i.e. whether the new solutions actuall perform better than the old "small data" approaches.
In fact, a lot of the "big data" approaches just reason "you can't do it with the existing solutions, so we cannot compare". Which is not exactly true.

In my experiments with large data (not big; it still fits into main memory) is that you have to be quite careful with your methods. Just scaling up existing methods does not always yield the expected results. The larger your data set, the more tiny problem surface that can ruin your computations.
"Big data" is often based on the assumption that just by throwing more data at your problem, your results will automatically become more precise. This is not true. On contrary: the larger your data, the more likely you have some contamination that can ruin everything.
We tend to assume that numerics and such issues have long been resolved. But while there are some solutions, it should be noted that they come at a price: they are slower, have some limitations, and are harder to implement.
Unforunately, they are just about everywhere in data analysis. I'll demonstrate it with a very basic example. Assume we want to compute the mean of the following series: [1e20, 3, -1e20]. Computing the mean, everybody should be able to do this, right? Well, let's agree that the true solution is 1, as the first and last term cancel out. Now let's try some variants:
  • Python, naive: sum([1e10, 3, -1e20])/3 yields 0.0
  • Python, NumPy sum: numpy.sum([1e10, 3, -1e20])/3 yields 0.0
  • Python, NumPy mean: numpy.mean([1e10, 3, -1e20]) yields 0.0
  • Python, less-known function: numpy.fsum([1e10, 3, -1e20])/3 yields 1.0
  • Java, naive: System.out.println( (1e20+3-1e20)/3 ); yields 0.0
  • R, mean: mean( c(1e20,3,-1e20) ) yields 0
  • R, sum: sum( c(1e20,3,-1e20) )/3 yields 0
  • Octave, mean: mean([1e20,3,-1e20]) yields 0
  • Octave, sum: sum([1e20,3,-1e20])/3 yields 0
So what is happening here? All of these functions (except pythons less known math.fsum) use double precision. With double precision, 1e20 + 3 = 1e20, as double can only retain 15-16 digits of precision. To actually get the correct result, you need to keep track of your error using additional doubles.
Now you may argue, this would only happen when having large differences in magnitude. Unfortunately, this is not true. It also surfaces when you have a large number of observations! Again, I'm using python to exemplify (because math.fsum is accurate).
> a = array(range(-1000000,1000001)) * 0.000001
> min(a), max(a), numpy.sum(a), math.fsum(a)
(-1.0, 1.0, -2.3807511517759394e-11, 0.0)
As it can be seen from the math.fsum function, solutions exist. For example Shewchuk's algorithm (which is probably what powers math.fsum). For many cases, Kahan summation will also be sufficient, which essentially gives you twice the precision of doubles.
Note that these issues become even worse once you use subtraction, such as when computing variance. never use the famous E[X^2]-E[X]^2 formula. It's mathematically correct, but when your data is not central (i.e. E[X] is not close to 0, and much smaller than your standard deviation) then you will see all kinds of odd errors, including negative variance; which may then yield NaN standard deviation:
> b = a + 1e15
> numpy.var(a), numpy.var(b)
(0.33333366666666647, 0.33594164452917774)
> mean(a**2)-mean(a)**2, mean(b**2)-mean(b)**2
(0.33333366666666647, -21532835718365184.0)
(as you can see, numpy.var does not use the naive single-pass formula; probably they use the classic straight forward two-pass approach)
So why do we not always use the accurate computations? Well, we use floating point with fixed precision because it is fast. And most of the time, when dealing with well conditioned numbers, it is easily accurate enough. To show the performance difference:
> import timeit
> for f in ["sum(a)", "math.fsum(a)"]:
>     print timeit.timeit(f, setup="import math; a=range(0,1000)")
30.6121790409
202.994441986
So unless we need that extra precision (e.g. because we have messy data with outliers of large magnitude) we might prefer the simpler approach which is roughly 3-6x faster (at least as long as pure CPU performance is concerned. Once I/O gets into play, the difference might just disappear altogether). Which is probably why all but the fsum function show the same inaccuracy: performance. In particular, as in 99% of situations the problems won't arise.

Long story. Short takeaway: When dealing with large data, pay extra attention to the quality of your results. In fact, even do so when handling small data that is dirty and contains outliers and different magnitudes. Don't assume that computer math is exact, floating point arithmetic is not.
Don't just blindly scale up approaches that seemed to work on small data. Analyze them carefully. And last but not least, consider if adding more data will actually give you extra precision.

Robert Collins: Learning is hard

I feel like I m taking a big personal risk writing this, even though I know the internet is large and probably no-one will read this :-) . So, dear reader, please be gentle. As we grow as people, as developers, as professionals some lessons are are hard to learn (e.g. you have to keep trying and trying to learn the task), and some are hard to experience (they might still be hard to learn, but just being there is hard itself ) I want to talk about a particular lesson I started learning in late 2008/early 2009 while I was at Canonical sadly one of those that was hard to experience. At the time I was one of the core developers on Bazaar, and I was feeling pretty happy about our progress, how bzr was developing, features, community etc. There was a bunch of pressure on to succeed in the marketplace, but that was ok, challenges bring out the stubborn in me :) . There was one glitch though we d been having a bunch of contentious code reviews, and my manager (Martin Pool) was chatting to me about them. I was as far as I could tell doing precisely the right thing from a peer review perspective: I was safeguarding the project, preventing changes that didn t fit properly, or that reduced key aspects- performance, usability from landing until they were fixed. However, the folk on the other side of the review were feeling frustrated, that nothing they could do would fix it, and generally very unhappy. Reviews and design discussions would grind to a halt, and they felt I was the cause. [They were right]. And here was the thing I simply couldn t understand the issue. I was doing my job; I wasn t angry at the people submitting code; I wasn t hostile; I wasn t attacking them (but I was being shall we say frank about the work being submitted). I remember saying to Martin one day look, I just don t get it can you show me what I said wrong? and he couldn t. Canonical has a 360 review system every 6 months / year (it changed over time) you review your peers, subordinate(s) and manager(s), and they review you. Imagine my surprise I was used to getting very positive reports with some constructive suggestions when I scored low on a bunch of the inter-personal metrics in the review. Martin explained that it was the reviews thing folk were genuinely unhappy, even as they commended me on my technical merits. Further to that, he said that I really needed to stop worrying about technical improvement and focus on this inter-personal stuff. Two really important things happened around this time. Firstly, Steve Alexander, who was one of my managers-once-removed at the time, reached out to me and suggested I read a book Getting out of the box and that we might have a chat about the issue after I had read it. I did so, and we chatted. That book gave me a language and viewpoint for thinking about the problem. It didn t solve it, but it meant that I got it , which I hadn t before. So then the second thing happened we had a company all hands and I got to chat with Claire Davis (head of HR at Canonical at the time) about what was going on. To this day the sheer embarrassment I felt when she told me that the broad perception of me amongst other teams managers was and I paraphrase a longer, more nuance conversation here technically fantastic but very scary to have on the team will disrupt and cause trouble . So, at this point about 6 months had passed, I knew what I wanted I wanted folk to want to work with me, to find my presence beneficial and positive on both technical and team aspects. I already knew then that what I seek is technical challenges: I crave novelty, new challenges, new problems. Once things become easy, it call all too easily slip into tedium. So at that time my reasoning was somewhat selfish: how was I to get challenges if no-one wanted to work with me except in extremis? I spent the next year working on myself as much as specific projects: learning more and more about how to play well with others. In June 2010 I got a performance review I could be proud of again I was in no way perfect, but I d made massive strides. This journey had also made huge improvements to my personal life a lot of stress between Lynne and I had gone away. Shortly after that I was invited to apply for a new role within Canonical as Technical Architect for Launchpad and Francis Lacoste told me that it was only due to my improved ability to play well with others that I was even considered. I literally could not have done the job 18 months before. I got the job, and I think I did pretty well in fact I was awarded an internal Spotlight on Success award for what we (it was a whole Launchpad team team effort) achieved while I was in that role. So, what did I change/learn? There s just a couple of key changes I needed to make in myself, but a) they aren t sticky: if I get overly tired, ye old terrible Robert can leak out, and b) there s actually a /lot/ of learnable skills in this area, much of which is derived lots of practice and critical self review is a good thing. The main thing I learnt was that I was Selfish. Yes capital S. For instance, in a discussion about adding working tree filter to bzr, I would focus on the impact/risk on me-and-things-I-directly-care-about: would it make my life harder, would it make bzr slower, was there anything that could go wrong. And I would spend only a little time thinking about what the proposer needed: they needed support and assistance making their idea reach the standards the bzr community had agreed on. The net effect of my behaviours was that I was a class A asshole when it came to getting proposals into a code base. The key things I had to change were:
  1. I need to think about the needs of the person I m speaking to *and not my own*. [Thats not to say you should ignore your needs, but you shouldn't dwell on them: if they are critical, your brain will prompt you].
  2. There s always a reason people do things: if it doesn t make sense, ask them! [The crucial conversations books have some useful modelling here on how and why people do things, and on how-and-why conversations and confrontations go bad and how to fix them.]
Ok so this is all interesting and so forth, but why the blog post? Firstly, I want to thank four folk who were particularly instrumental in helping me learn this lesson: Martin, Steve, Claire and of course my wife Lynne I owe you all an unmeasurable debt for your support and assistance. Secondly, I realised today that while I ve apologised one on one to particular folk who I knew I d made life hard for, I d never really made a widespread apology. So here it is: I spent many years as an ass, and while I didn t mean to be one, intent doesn t actually count here actions do. I m sorry for making your life hell in the past, and I hope I m doing better now. Lastly, if I m an ass to you now, I m sorry, I m probably regressing to old habits because I m too tired something I try to avoid, but it s not always possible. Please tell me, and I will go get some sleep then come and apologise to you, and try to do better in future. Less-assily-yrs,
Rob

31 October 2013

Steve Kemp: Expiration checking services?

Today I'm recuperating, and almost back to full health. Unfortunately I made the mistake of online-shopping, oops. Good job I stopped myself from registaring all the domains, but I did get two that I liked: spare.io & edinburgh.io. I've updated my database to record them, but I wonder what do other people use to remind them about expiration dates of domains, SSL-certificates, & etc? I googled and didn't find a definitive free/paid service, but it seems like something lots of people need to be reminded about.. Maybe people just rely on registrars sending strident emails. (Of course the redemption period for domains make it reasonably safe to forget for a day or two, until your customers complain and your emails start to bounce..)

30 October 2013

Matthew Palmer: How to deal with the "package gcc: " problem in Puppet

In a comment to yesterday s post on why your Puppet module sucks, Warren asks what can be done about the problem of multiple modules needing to include the same package (gcc being the most common example I m yet to come across). As I stated previously, there is no sane, standardised way for multiple independent modules to cooperate to ensure that certain packages are installed for their cooperative use. If it wasn t already obvious, I consider this to be a significant failing in Puppet, and one which essentially renders any attempt at public, wide-scale reuse of Puppet modules impossible. Software packages are such a fundamental part of system management today that it is rare for a module not to want to interact with them in some way. Without strong leadership from Puppet Labs, or someone core to the project who s willing to be very noisy and obnoxious on the subject, the issue is fundamentally unsolveable, because it requires either deep (and non-backwards-compatible) changes to how Puppet works at a core level, or it needs cooperation from everyone who writes Puppet modules for public consumption (to use a single, coordinated approach to common packages). The approaches that I ve seen people advocate using, or that I ve considered myself, roughly fall into the following camps.

Put your package into a class in your module Absofrickinglutely useless, because the elementary package resources you end up creating will still conflict with other modules package resources. Anyone who suggests this can be permanently ignored, as they don t understand the problem being solved.

Use a globally common module of classes representing common packages This could work, if you could get everyone who writes modules to use it (see someone willing to be very noisy and obnoxious ). Practically speaking, anyone who suggests this doesn t understand human nature. I don t see this actually happening any time soon.

Use the defined() function everywhere By wrapping all your package resources in if !defined(Package["foo"]) blocks, you can at least stop your module from causing explosions. What it doesn t do is make sure that the various definitions of the package resource are congruent (imagine if one was package "gcc": ensure => absent ). In order to safely avoid explosion, everyone would have to follow this approach, which (in the worst case) reduces the problem to the globally common module of classes. However, it s the least-worst approach I can practically consider. At least your module won t be the cause of explosions, and realistically no module s going to ask for gcc to be removed (or, if they are, you ll quickly find them and kill them). I ve seen calls from Puppet core dev team members to deprecate and remove the defined() function entirely. Given the complete lack of alternatives, this is a disturbing illustration of just how out of touch they are from the unfortunate realities of practical Puppetry.

Use virtual resources This is yet another variant of the common class technique that would require everyone, everywhere, to dance to the same tune. It has all the same problems, and hence gets a big thumbs-down from me.

Use singleton_packages This module is a valiant attempt to work around the problem, but practically speaking is no better than using defined() because again, if a module that isn t using singleton_packages specifies package "gcc": ensure => absent , you re going to end up with assplosion. The mandatory dependency on hiera doesn t win me over, either (I m a hiera-skeptic, for reasons which I might go into some other time).

Use only modules from a single source This is the solution that I use myself, if that s any recommendation As a result of pretty much every publically-available Puppet module sucking for one reason or another, I do not, currently, have any externally-written Puppet modules in the trees that I use. Every module (158, at current count) has been written by someone in the sysadmin team at $DAYJOB, to our common standards. This means that I can coordinate use of package resources, using our module of common classes where appropriate, or refactor modules to separate concerns appropriately. If you re wondering why we don t have all of these 158 modules available publically, well, we have a few of them up, but yes, the vast majority of them aren t publically available. Some of them suck mightily, while many others are just too intertwined with other modules to be able to use on their own, and we don t want to release crap code there s far too much of that out there already.

Matthew Palmer: How to deal with the "package gcc: " problem in Puppet

In a comment to yesterday s post on why your Puppet module sucks, Warren asks what can be done about the problem of multiple modules needing to include the same package (gcc being the most common example I m yet to come across). As I stated previously, there is no sane, standardised way for multiple independent modules to cooperate to ensure that certain packages are installed for their cooperative use. If it wasn t already obvious, I consider this to be a significant failing in Puppet, and one which essentially renders any attempt at public, wide-scale reuse of Puppet modules impossible. Software packages are such a fundamental part of system management today that it is rare for a module not to want to interact with them in some way. Without strong leadership from Puppet Labs, or someone core to the project who s willing to be very noisy and obnoxious on the subject, the issue is fundamentally unsolveable, because it requires either deep (and non-backwards-compatible) changes to how Puppet works at a core level, or it needs cooperation from everyone who writes Puppet modules for public consumption (to use a single, coordinated approach to common packages). The approaches that I ve seen people advocate using, or that I ve considered myself, roughly fall into the following camps.

Put your package into a class in your module Absofrickinglutely useless, because the elementary package resources you end up creating will still conflict with other modules package resources. Anyone who suggests this can be permanently ignored, as they don t understand the problem being solved.

Use a globally common module of classes representing common packages This could work, if you could get everyone who writes modules to use it (see someone willing to be very noisy and obnoxious ). Practically speaking, anyone who suggests this doesn t understand human nature. I don t see this actually happening any time soon.

Use the defined() function everywhere By wrapping all your package resources in if !defined(Package["foo"]) blocks, you can at least stop your module from causing explosions. What it doesn t do is make sure that the various definitions of the package resource are congruent (imagine if one was package "gcc": ensure => absent ). In order to safely avoid explosion, everyone would have to follow this approach, which (in the worst case) reduces the problem to the globally common module of classes. However, it s the least-worst approach I can practically consider. At least your module won t be the cause of explosions, and realistically no module s going to ask for gcc to be removed (or, if they are, you ll quickly find them and kill them). I ve seen calls from Puppet core dev team members to deprecate and remove the defined() function entirely. Given the complete lack of alternatives, this is a disturbing illustration of just how out of touch they are from the unfortunate realities of practical Puppetry.

Use virtual resources This is yet another variant of the common class technique that would require everyone, everywhere, to dance to the same tune. It has all the same problems, and hence gets a big thumbs-down from me.

Use singleton_packages This module is a valiant attempt to work around the problem, but practically speaking is no better than using defined() because again, if a module that isn t using singleton_packages specifies package "gcc": ensure => absent , you re going to end up with assplosion. The mandatory dependency on hiera doesn t win me over, either (I m a hiera-skeptic, for reasons which I might go into some other time).

Use only modules from a single source This is the solution that I use myself, if that s any recommendation As a result of pretty much every publically-available Puppet module sucking for one reason or another, I do not, currently, have any externally-written Puppet modules in the trees that I use. Every module (158, at current count) has been written by someone in the sysadmin team at $DAYJOB, to our common standards. This means that I can coordinate use of package resources, using our module of common classes where appropriate, or refactor modules to separate concerns appropriately. If you re wondering why we don t have all of these 158 modules available publically, well, we have a few of them up, but yes, the vast majority of them aren t publically available. Some of them suck mightily, while many others are just too intertwined with other modules to be able to use on their own, and we don t want to release crap code there s far too much of that out there already.

29 October 2013

Dirk Eddelbuettel: Rcpp 0.10.6

A new maintenance release 0.10.6 of Rcpp is now on the CRAN network for GNU R; binaries for Debian have been uploaded as well. This version ties up a number of smaller loose ends, but also adds a few new things, particularly John's new exposeClass. Details are as usual in the NEWS extract below, and also in the ChangeLog file in the package and on the Rcpp Changelog page.
Changes in Rcpp version 0.10.6 (2013-10-27)
  • Changes in Rcpp API:
    • The function exposeClass takes a description of the constructors, fields and methods to be exposed from a C++ class, and writes C++ and R files in the package. Inherited classes can be dealt with, but require data type information. This approach avoids hand-coding module files.
    • Two missing is<>() templates for CharacterVector and CharacterMatrix have been added, and some tests for is_na() and is_finite() have been corrected thanks to Thomas Tse.
  • Changes in R code:
    • Export linking helper function LdFlags as well as RcppLdFlags.
    • Function Rcpp.package.skeleton() no longer passes a namespace argument on to package.skeleton()
  • Changes in R setup:
    • Raise requirement for R itself to be version 3.0.0 or later as needed by the vignette processing
  • Changes in Rcpp attributes:
    • sourceCpp now correctly binds to Rtools 3.0 and 3.1
Thanks to CRANberries, you can also look at a diff to the previous release 0.10.5. As always, even fuller details are on the 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

This post by Dirk Eddelbuettel originated on his Thinking inside the box blog. Please report excessive re-aggregation in third-party for-profit settings.

28 October 2013

Dirk Eddelbuettel: Kurt Elling at Dominican University

Some catchup blogging: Kurt Elling was back in town on October 19, and not just in Chicago but quite literally in our little 'burb as the headliner for this season's concerts at Domiminican University. They had done us the favour of inviting Dianne Reeves back in March 2009, but this was clearly going to be a real treat. And I managed to snatch four front row (!!) tickets as soon as I heard about it, and the show once again didn't disappoint. Elling was as usual accompanied by his long-time collaborator Laurence Hobgood on piano, as well as local heros Clark Sommers on bass and John McLean on guitar. This time, Quincy Davies was on drums. And this band is realiably excellent, as is Elling in any live setting. The set was dominated by pieces from his most recent record and augmented by a few other standout pieces. There is a pretty rich set of live music by Elling on YouTube, see for example On Broadway (which was part of the set in a wonderfully fast and funked-up variant), Golden Lady (from the previous album, and also played live this time) or for example this wonderful version of You Send Me (also part of the concert). I snatched a photo or two (while at least turning my flash off, unlike the weird gal to my left, but I digress) and posted one on Google+. Kurt Elling will be back in Chicago at the Green Mill in early January. Expect to me there, and I hope to see you too!

This post by Dirk Eddelbuettel originated on his Thinking inside the box blog. Please report excessive re-aggregation in third-party for-profit settings.

26 October 2013

Niels Thykier: Breaking the RC bug curve

Early this month, the first batch of packages were automatically removed from testing due to RC bugs. Personally, I find that the results stand out pretty well on the RC bug graph[1]. There has been a very rapid decline in the number of RC bugs affecting testing a week or two ago, we had over 1000 RC bugs affecting testing and now it has dropped to something like 760. There has also been quite a few RC bug fixes in this time period. I spent a bit of time finding and aging some of the RC bug fixes in sid, so they would migrate to testing faster[2]. On the first batch, we saw something like 40 RC bugs disappear and we still have more RC bugs fixes in the sid->testing pipeline. While looking for packages I could age, I also noticed that we have quite a few RC bug fixes blocked by out of date binaries (which is usually either build issues or uncoordinated transitions). I have been filing a couple of RC bugs for these, but it does not scale do this kind of work manually. If you have uploaded a package recently, please take the 5 minutes to check that it actually built and it has no out of date binaries issues in its excuses. [1] http://bugs.debian.org/release-critical/ [2] The aging was equivalent to an urgency=medium, so reduced the requirement from 10 days to 5 days.

24 October 2013

Ingo Juergensmann: Sharing GnuPG between Linux and OSX

I've been using GnuPG since years. Well, using is too strong. I have a GPG key that I've created somewhen and use it once in a while when sending login credentials to other Linux people. But since Edward Snowdens NSA leaks I now get encrypted mails by non-Linux people. It is great that people are making use of strong encryption to protect their communication, but it is frightening that people have to do so because of NSA mass surveillance the complete world and violating our civil and human rights. Anyway, one problem with GnuPG and other PKI tools is, that you should keep your private key secret. When you use more than one device to write your mails, you will run into usuability problems like I did. My main computer is my Debian box, but I use a MacBook Pro laptop with OSX very often as well. There is GPGSuite (formerly GPGMail) for OSX to pimp your Mail.app with GPG. It uses, of course, a local .gnupg/ directory and thus it would create a separate GnuPG pair of keys. But apparently I want to use my existing pair of keys - without the need to copy them over from my Linux box to my laptop. The solution would be a simple setup of netatalk to mount your home directory from the Linux box under OSX and a matching symlink to your Linux .gnupg/ directory (or even better: symlink the contents where necessary and not the whole directory). But that would've been too easy, I guess, because I got this error message on OSX:

So, basically this didn't work right out of the box. Fortunately the GPGSuite support guys replied quick and solved this problem. The version they released yesterday did fix that problem, but I needed to add the following line to my ~/,gnupg/gpg-agent.conf, which didn't exist before too:

no-use-standard-socket

With that line everything works like a charme under OSX with Mail.app using my GPG keys on my Debian box.

Kategorie:

Russ Allbery: Review: Applied Cryptography

Review: Applied Cryptography, by Bruce Schneier
Publisher: John Wiley & Sons
Copyright: 1996
ISBN: 0-471-11709-9
Format: Trade paperback
Pages: 621
This is the next entry in the series of Russ reading books that he bought years ago and never got around to reading. Thankfully, this time, the book has aged somewhat better. This review is for the second edition of Applied Cryptography, published in 1996. Given how important computer security has become, and how central cryptography is to computer security, one might think that the passage of 17 years would make a book effectively obsolete. This turns out not to be the case. Yes, Rijndael (the current AES standard and the most widely-used block cipher), Camellia (the up-and-comer in the block cipher world), and the SHA-2 hash postdate this book and aren't discussed. Yes, there have been some further developments in elliptic-curve public-key cryptography. And yes, much of the political information in this book, as well as the patent situation for public-key cryptosystems, is now mostly of historical interest. But a surprising amount of this book still applies directly. Partly that's because much of Applied Cryptography is focused on general principles, classes of algorithms, and cryptographic protocols, and those do not change quickly. A rather amazing number of techniques and protocols still in widespread use today originated in the 1970s. Block ciphers, stream ciphers, cipher modes, public-key systems, signature systems, hash functions, key exchange, secret splitting, key management, and other, similar topics have not changed substantially. And even in the area of specific algorithms, DES is still in use (unfortunately) and its analysis is valuable for understanding any block cipher. RC4, Triple DES, CAST, RSA, MD4, MD5, and SHA-1 are still part of the cryptography landscape, and Schneier was already warning against using MD5 in 1996. The source code included in this book has, thankfully, been made obsolete by widely-available, high-quality free implementations of all common ciphers, available for any modern operating system. But the math, the explanations, and much of the cryptanalysis is still quite relevant. While it contains a comprehensive introduction to cryptographic concepts, Applied Cryptography is structured more like a reference manual than a tutorial. The first two chapters provide some foundations. Then, a wide variety of protocols, from the common to the completely esoteric, are discussed across the subsequent four chapters. There are four chapters on the basics of ciphers, another chapter on the mathematics, and then the longest part of the book: twelve chapters that provide a tour of all major and several interesting minor protocols that existed in 1996. These are organized into block ciphers, stream ciphers (and pseudo-random number generators), hash functions, and public-key systems. An entire chapter is devoted to the history and analysis of DES, and I think that was my favorite chapter of the book. Not only is it worth understanding how DES works, but it also provides a comprehensive introduction to the complexities of block cipher design, the politics of interactions with the NSA, and a fascinating history of early computer cryptosystems. Finally, Applied Cryptography closes with chapters on real-world systems and on politics. The politics section is mostly a historical curiosity, as is much of the chapter on real-world systems. Schneier discusses some of the PKCS and X.509 protocols here but doesn't use SSL as one of his examples despite its specification predating this book (perhaps the most glaring omission of the book). But he does discuss Kerberos (which is of personal interest to me), and it was useful to see it analyzed in the broader context of this sort of book. Those who read Schneier's blog regularly, or who have read any of his other books, will know that he's concise, incisive, and very readable, even with difficult material. I think he does err on the side of compactness this is not a book that handholds the reader or explains something more than once but there's a lot of ground to cover, so I can't really blame him. Expect to have to read the more difficult parts several times, and (at least on a first read) expect to just skip past some of the most complex sections as probably not worth the effort. But I think Schneier does a great job structuring the book so that one comes away with a high-level impression and overview sufficient to make informed guesses about capabilities and relative difficulty even if one doesn't have the patience to work through the details. I suspect most readers will want to skim at least part of this book. Unless you're willing to do a lot of background reading to understand the math, or a lot of careful study to follow the detailed descriptions and flaws in often-obscure algorithms, the algorithm discussions start to blend together. I found myself skipping a lot of the math and focusing on the basic descriptions and the cryptanalysis, particularly for the obscure ciphers. Many of the algorithms are also highly opaque and of obscure benefit; I doubt I will ever care about blind signatures or oblivious transfer, and I struggled to wrap my mind around the details of bit commitment (although it's apparently important in zero knowledge proofs, which in turn are relevant to authentication). But this is not the sort of book where you have to read every word. It's very well-structured, provides clear resynchronization points for readers who have had enough of a particular topic, and marks the topics that are more obscure or of dubious general usefulness. The most useful parts of this book, in my opinion, are the basic conceptual introductions to each class of cryptographic algorithm or protocol, and those chapters are excellent. I've been working in applied computer security, at the application and deployment level, for years, and this is the first time that I've felt like I really understood the difference between a block cipher and a stream cipher, or the implications of block cipher mode selection. Applied Cryptography is also a fascinating exercise in adjusting one's intuition for where the complexity lies. It's a memorable experience to move from the chapters on block ciphers, full of S-boxes and complex mixing and magic numbers, into the far more straightforward mathematical analysis of stream ciphers. Or the mathematical simplicity of RSA (although quite a bit of complexity is lurking on the cryptanalysis side, much of which is only touched on here). Of more historical interest, but still quite impressive, is that Applied Cryptography doubles as a comprehensive literature review. Not only does it cover nearly every algorithm in use at the time, it discusses the cryptography literature on nearly every topic with brief summaries of results and lines of investigation. The references section is a stunning 66 pages of small print featuring 1,653 references, and those are mentioned and put in context throughout the book. I'm not personally interested in chasing those lines of research further, and of course 17 years means there are many new papers that are as important to read today, but it's obvious that this book would have been an amazing and invaluable map to the research territory when it was first published. There are now newer books on this topic that you should consider if you're purchasing a book today. Cryptography Engineering in particular is in my to-read pile, and I'm interested to see how much of this book it could replace, although I believe it's lighter on the mathematical analysis and details. But I think Applied Cryptography still has a place on the bookshelf of any computer security professional. Schneier is succinct, detailed, straightforward, and comprehensive, at least for 1996, and I know I'll be reaching for this book the next time I forget the details of CFB mode and then get hopelessly confused by the Wikipedia article on the topic. Rating: 8 out of 10

23 October 2013

Rog rio Brito: Assorted random notes

This post is just a bunch of random notes, but I think that things are going well, this time.

Btrfs Just started playing with btrfs after converting a 2TB disk with about 1.3TB of data from ext4 to btrfs. This particular filesystem contains my backup data and I hope that btrfs is able to live up to high standards. I will probably write a detailed review with my impressions, but suffice to say that it is working fine and I hope that I will be happy for a long time to come. My other filesystems, for the moment, will be ext4.

Coursera Downloader Thanks to John Lehmann's generosity, now coursera-dl has a new home: a github organization of its own!

youtube-dl Some people may have noticed, others may not, but when downloading videos from Youtube, they apparently are getting more aggressive with the use of Dynamic Adaptive Streaming over HTTP (also called DASH) and, as a result, some (perhaps going to be all in the near future?) of the videos may not be available in the resolution/formats that you used to like (like me, with format number 35). By the way, one thing that is interesting with youtube videos provided via DASH is that they are available in different streams: one for the video and another for the audio. What does this mean in practical terms for users of youtube-dl? Well, if you wanted to download videos in resolutions like the 480p (format 35) that I mentioned, then you will probably have to change your way of doing things, until a more automated solution is in place. You will have to download both the audio and the video and, then, "combine" them (that is, multiplex them) to create one "normal" video file with both the audio and the video. I usually do this via: ffmpeg -i audio.m4a -i video.mp4 -vcodec copy -acodec copy combined.mp4 If you prefer having a Matroska container instead of an mp4 container (which, BTW, results in smaller muxing overhead), then you can use the command line: mkvmerge -o combined.mkv audio.m4a video.mp4 Oh, those m4a and mp4 extensions are a new addition that I just sent upstream (in the past, both would have been named with an extension of mp4). As, an aside, I like formats 135 for video and 140 for audio, for the reasons that I mentioned in a comments to issue 1612:
Otherwise, to download 480p videos (which I do for lectures and so on with other projects of mine, like edx-dl) I have to call youtube-dl twice: once for format 135 and another for format 140, since the old (?) format 35 files are much smaller than the lower resolution 360p files (due to the former being encoded in High profile vs. the latter being encoded in Constrained Baseline profile).
While this is unfortunate for some, this is a good thing for others: I once had a blind user of youtube-dl asking me if he could avoid downloading the whole video just to extract the audio, so that he save on bandwidth. Well, now this is possible. Expect a new version of youtube-dl to be uploaded soon to Debian unstable.

Music It is so nice to see the music that I like getting better. It was particularly pleasant to see Tarja Turunen being joined on stage by Floor Jansen. In fact, it is my impression that the once female-fronted bands are getting more and more into collaborations and side-projects and they are, in many ways, getting more refined. Examples of this includes Floor, Tarja, Anneke van Giersbergen, Sharon den Adel, Kari Ruesl tten and many others that I can't remember right now. Of course, some thanks to people that take the time to film, and upload/share the videos so that other people not at these events can watch them is highly appreciated and they usually are treated as anonymous, but, of course, this should be fixed.

Russell Coker: Thinkpad T420

I ve owned a Thinkpad T61 since February 2010 [1]. In most ways it s a great system and it still does most things that I require, even though it inspired my post about how modern laptops suck [2]. Problems with my T61 The biggest ongoing problem with my T61 was the heat production, I m not sure how much of it was due to the CPU producing heat and how much was due to the cooling system not removing it fast enough. But any serious computation for even a relatively small amount of time caused it to get close to thermal shutdown. But as I mostly use my laptop for reading email, a SSH client, and coding (for which the big compiles are done on servers) that didn t force me to replace it. The next problem was the battery life, it s expected that laptop batteries degrade over time so it wasn t a surprise that after 3 years my T61 battery only lasted for about 15 minutes. A final problem is the screen which didn t seem to be as bright as it used to be, it s annoying but doesn t compel me to buy a replacement. T61 Failure But in July my T61 stopped working, it appeared to be either the power supply or something internal related to power, it had been running but was suddenly powered down after being left alone so for some reason power wasn t getting from the wall to the laptop. I initially thought that it was the power supply at fault and investigated the price of a new PSU and a new battery as well. The Lenovo online store [3] charges $71.90 for a new PSU and $113 for a regular capacity battery or $156 for an extended capacity battery (50% more power). So based on the assumption that the PSU was faulty that meant a cost of $185 or $228 (maybe more if postage is included) to get the old Thinkpad going again. I could probably get the parts cheaper from somewhere else, but I m hesitant to buy batteries from sources that aren t reliable in case I get one that s been used. Buying at Auction I ended up buying a refurbished Thinkpad T420 (product ID 4236-J73) from Grays Online [4]. It was refurbished and cost me $306.35 including delivery. $306.35 for a new laptop including PSU was a much better deal than buying a new PSU and battery for $185 or more. It turned out that the PSU wasn t broken (a different PSU also didn t work with it) but then my Thinkpad T61 just started working again, presumably it has some intermittent fault related to power and needed to be replaced anyway (I use my laptop for work and can t have it fail randomly). One significant problem when buying a Thinkpad is that the model numbers aren t specific to the hardware specs. According to ThinkWiki the T420 model ranges from a 2.1GHz i3 to a 2.8GHz I7 CPU, from 160G to 500G hard drive, and has either a 1366*768 or a 1600*900 display [5]. Auction sites almost always specify the size of a hard drive and usually the exact CPU speed doesn t matter much for an auction purchase (2.1GHz is fast enough for most things). But the display resolution is a big deal, in this case Grays had multiple Thinkpads on offer with the same description and the same price so bidding on one with high resolution was quite important. Lenovo has a web site for discovering Thinkpad specs, this is the current link for it (it changes periodically) [6]. At that page you can specify the TYPE AKA PRODUCT ID that is printed on the back of a Thinkpad (and usually included in an auction listing) in the search field that s currently described as QUICK PATH and get all the specifications. Lenovo really do a great job of providing all the details for their products (including ones that were obsolete years ago). But it s unfortunate that their web site sucks, there should be a single URL for such things that s easy to find and they shouldn t use cookies to track which model you are looking at because it makes it really difficult to research two different models. Comparing T61 and T420 I upgraded my new Thinkpad to 8G of RAM because RAM is really cheap. I bought it with 4G of RAM which didn t seem to be quite enough as the hard drive is slow for paging (my desktop with 3G of RAM and a SSD performed well for similar tasks). Now it s running really well, my new Thinkpad is a lot cooler than the old one (not being broken is a good thing). My T420 has a screen resolution of 1600*900 which was a little disappointing initially when going from 1680*1050 (18% fewer pixels and 2% fewer than the T41p I used previously). But having a smaller screen means that the Thinkpad is a lot smaller and lighter. My T61 didn t fit in most backpacks and laptop bags and was unreasonably heavy, it s the type of laptop that looks good on a spec sheet but doesn t seem so good when you carry it around for a few hours. Not only is the T420 a lot smaller and lighter than the T61 but the power supply that shipped with it is a lot smaller and lighter too. I might have spent $72 a few years ago to buy a lighter PSU if I knew that was an option. Cost of Ownership Thinkpads are getting so cheap at auction that I m tempted to buy myself an X series as well. When a $300 item can last several years (my T41p was from some time before 2006, my T61 was from 2010, and my latest is from 2013) that brings the cost of ownership down to something like $0.25 per day. If I bought myself a Thinkpad X series (ultra light) as well at auction then I would be looking at maybe $0.50 per day for my laptop use which would give me the option of taking a light laptop to a conference and a bigger laptop for spending a day at a client site.

Russell Coker: LUV Hardware Library after 20 Months

20 months ago I started the LUV Hardware Library [1]. The aim of the project is to provide a repository of free spare parts for computers for the use of club members. People who have parts that are good but which they can t use can donate them and others who need such parts can take them. Some people have criticised my choice of the name Hardware Library because the word is associated with borrowing while with my Hardware Library it is expected that noone will return the item that they take. The Wikipedia page about libraries is worth reading, my interpretation of that is that the essential aspect of a library is that it is a public collection of items that are useful for study and that borrowing is just one thing that can be done. A book library could consist of a service of printing free books on demand (anyone could do this with access to The Gutenberg Project [2] and a printer) or of just making them available to download. Many libraries don t allow books to be borrowed, they just allow them to be studied and copied in the library. Also every general public library has reference items that can t be borrowed, it s typical for a library to have a full encyclopedia which is not available to be borrowed. Also with the Hardware Library people feel obliged to give something if they take something (as happens with a geocache), so there is an issue of returning something. My main aims with the Hardware Library were to save people money on parts and to help the environment by reducing the need to buy new computers when old ones can be upgraded and remain in service. My next aim was to help people learn about hardware by providing free parts, when a mistake has no financial cost people are more willing to experiment and will learn more. I believe that those aims have been achieved. More Successful Than Expected One thing that surprised me is the social aspect that developed. I had expected that most people would just find some parts that they need and not look at it again for some months. I had also anticipated that some people would poll the Hardware Library every month in the hope that a part they needed might appear. I didn t expect that people would look through it every month because they just like looking at old hardware. I also didn t expect groups of people to hang out by the Hardware Library to discuss various issues related to PC hardware and Linux. During the breaks in the main meeting the location of the Hardware Library often becomes a focus for discussions of various issues related to Linux and hardware. I think that this is really advancing the aims of LUV [3] and I think that members of other LUGs should experiment with similar projects. Starting this didn t require any special skill or authority. I just started bringing a briefcase full of parts to meetings and offering them to whoever was interested. Any member of any LUG can do the same. To start something like this you wouldn t even need a collection of parts, you could just bring a box and ask for donations.

Next.

Previous.