Search Results: "will"

30 May 2013

Mike Hommey:

Today, May the 30th, was my last day as a Mozilla employee. In a couple weeks, my wife, my cat and I will be on board of a flight heading about ten thousand kilometers east, and most of our stuff will be in some container on a boat. We re moving to Japan. As adventurous as this may sound, I m not venturing into unknown territory. My wife is Japanese, and I ve lived there for close to 15 months. A long time ago, arguably. I m not actually leaving Mozilla. I ll be back as a contractor, hopefully around the 25th of June. So as far as my fellow coworkers are concerned, I ll be going on a long-ish vacation and changing timezone (but I ll probably be around in the meanwhile on irc or bugmail, with high latency). Jump-starting in a different country is not something really easy to pull off, and working for Mozilla as a remotee has been a key element in being able to do so. Although I ve made it clear when I joined Mozilla that this would eventually happen, I m thankful I can now actually do it.

Daniel Pocock: Is open source communications software really free?

Does every communications technology based on open source and open standards enable free communications? Or is something more necessary? The FSF's campaign for a Skype replacement gives some indication that existing free software solutions have shortcomings. The opening paragraph of their campaign pitch suggests that with proprietary solutions, "we can't be sure who is listening in". Many open source solutions (including VoIP, IRC and email) have exactly the same limitation depending upon how they are configured and used. If the option of privacy is an essential characteristic of a communications system that should be considered a free solution, then simply using open source and open standards does not make a solution free. Some additional criteria are needed to help evaluate each solution to find out if it is free. Most major Linux distributions have criteria for evaluating software freedom. Debian has it's free software guidelines and provides an interesting set of tests that can be used when evaluating whether a license is free. Yet I could not find any evidence that the FSF or any other organisation has taken steps to define a similar set of guidelines for communications freedom The recent incident involved phone tapping at Associated Press gives more hints: journalists expect a certain amount of freedom to interact with and protect sources as they go about their work in a free society but their technology platform failed to give them that freedom. It is not just journalists who have this expectation and it is not just the Government who might be listening: in the UK, the roles were reversed as News International journalists allegedly gained access to communications records from crime victims and Government officials Defining concise high-level guidelines for communications technology that is genuinely free will not only help us in fulfilling the search for a Skype replacement but it could also have consequences for the evolution of email and other protocols that have evolved with relatively poor privacy support up to now or the successful design of completely self-contained solutions like the FreedomBox. This is one of the topics that has been raised recently on the Free Real-time Communications mailing list sponsored by FSF Europe.

Russ Allbery: Review: Get Everything Done

Review: Get Everything Done, by Mark Forster
Publisher: Hodder & Stoughton
Copyright: 2000
ISBN: 0-340-74620-3
Format: Trade paperback
Pages: 190
Mark Forster is the author of my (current) favorite time management book, Do It Tomorrow, and several excellent blog posts. I've therefore been rather curious about some of his earlier books, and finally decided to order this one. It appears to only have been published in the UK, so it can be a bit expensive in the US unless you can find it used. The main reason why I like Forster's writing so much is that he's a theory and neat trick sort of author instead of a single system author. A lot of time management writing (such as Getting Things Done) presents a single system that's supposedly universal. If that system happens to work for you, great. If it doesn't, the usefulness of the book drops off rapidly. You have to work through the basic principles, which are often sidelined in the book, and come up with variations on your own. Forster is the other sort of time management author: he throws out a flurry of tricks and tactics and lets you see which ones stick. He doesn't have a single system; indeed, one of the most entertaining parts of Get Everything Done is a parable about following many of the common time management systems and having one's life get worse and worse. Instead, he talks about the underlying theory, about the different approaches he's tried and their tradeoffs, and about lots of little tricks that he's found help in one situation or another. It's more of a toolkit than a system. This is, of course, only as good as the clarity of presentation. In both Do It Tomorrow and here, the clarity is excellent. For example, one of the most eye-opening ideas he explores in this book is that time management is a horrible name for the field. Time continues on no matter what you do; you can't increase it, and you can't save it. Rather, what you're actually doing is attention management: for each moment, you're deciding where to direct your attention. Things to which you turn your attention will change; things that you don't pay attention to will not change (except possibly for the worse). I'm quite fond of this reframing of the problem. Forster's thinking about time, or, rather, attention management is not as fully-developed here as in the later Do It Tomorrow. Much of the latter book is about the theory and practice of to-do lists. The techniques presented here were, at least for me, less immediately inspiring, although still thought-provoking. Much of the book focuses on internal resistance and procrastination, on the concept of self-control and decision-making as a mental "muscle" that has to be exercised, and on a philosophy of attention management that slowly builds up to doing whatever one is resisting the most at the moment. I haven't had a chance to work through the exercises that he offers (Forster's books tend to be full of illuminating exercises), so I don't have a fully-formed opinion on their efficacy. I was able to put Do It Tomorrow into practice more immediately. However, one thing this book does do is tackle directly the problem of trying to do too many things. Since this, more than organization, is the heart of my personal attention management problems, I was delighted to see this. Most attention management books at least give lip service to the problem, but they provide little useful guidance. David Allen's Getting Things Done effectively rules it out of scope: the goal of the system is to free you to act on your decisions, but there's little or no attention paid to the practical problem of making those decisions. As a result, I had serious trouble with GTD when I tried to use it. My project and next action lists would simply grow without bound, and GTD offered no useful assistance with culling them. Deciding what to do is, of course, a hard problem, but Forster here offers some specific and useful techniques and spends some time on the necessity of culling one's backlog. He also states directly the problem that everyone else seems to dance around: if you don't cull your committments, no attention management system will actually help you. It will just enable you to do trivia more efficiently, and therefore allow you to fill your life with even more of it, while still feeling just as overwhelmed as before. The bluntness is refreshing, and the exercises in cataloging commitments with time values and then forcing yourself to reduce the commitment list to the doable look quite helpful. I would still start with Do It Tomorrow rather than this book, since I think some practical approaches to to-do list management are one of the best places to start with attention management. But I'm glad I picked up this book as well, despite the cost of the UK import, and I plan on working through the exercises in it. Unlike David Allen, who has one basic system and whose other book was interesting but not as helpful, Forster's toolkit approach means that more books mean more ideas and more possible tools. He doesn't stick with one concept and polish it; he tries a lot of different ideas and then analyzes their strengths and weaknesses. If Do It Tomorrow spoke to you, I recommend grabbing this one as well. (Yes, it's somewhat amusing for me to read and review this book immediately after The Making of the Indebted Man, since to an extent attention management is part of the remaking of the self that's the obligation of the debtor in Lazzarato's construction of the nature of debt. It was something that occurred to me while reading this book. But I think Forster does a good job of showing attention management as a tool to direct one's efforts towards an internal goal rather than externally-imposed goals.) Rating: 8 out of 10

29 May 2013

Lisandro Damián Nicanor Pérez Meyer: Presenting qtchooser

A few days ago we the Qt/KDE team uploaded a new tool in the Qt ecosystem: qtchooser.

This tool is a wrapper tool used to select between different Qt versions. Of course, the first and easiest example is choosing between Qt4 and Qt5. But it doesn't end there: it can also be used to select a user's build of Qt.

To experienced Debian users, at first sight, it might resemble Debian's alternatives system. But it goes much further than that, allowing users (not sysadmins) to decide their defaults, and even adding new ones, user-wide. All this can be done using different methods like command line arguments, environment variables and configuration files.

Apart from all that, this is the recommended upstream way of managing Qt, being picked up by several (if not all) distributions, so it can easily be supported by upstream in their documentation.

My Qt4 package in Debian does not uses qtchooser, do I need to change anything?No, we have tried to make things as smooth as possible. Your Qt4 packages should be safe. There will be more info on this later.

Russell Coker: Nexus 4

My wife has had a LG Nexus 4 for about 4 months now so it s time for me to review it and compare it to my Samsung Galaxy S3. A Sealed Case The first thing to note about the Nexus 4 is that it doesn t support changing a battery or using micro-SD storage. The advantage of these design choices is that it allows reduced weight and greater strength compared to what the phone might otherwise be. Such choices would also allow the phone to be slightly cheaper which is a massive advantage, it s worth noting that the Nexus 4 is significantly cheaper than any other device I can buy with comparable specs. My wife s phone has 8G of storage (not RAM thanks Robin) and cost $369 at the start of the year while the current price is $349 for the 8G version and $399 for the 16G version. Of course one down-side of this is that if you need 16G of storage then you need to spend an extra $50 on the 16G phone instead of buying a phone with 8G of storage and inserting a 16GB micro-SD card which costs $19 from OfficeWorks. Also there s no option of using a 32G SD card (which costs less than $50) or a 64G SD card. Battery etc The battery on the Nexus 4 isn t nearly big enough, when playing Ingress it lasts about half as long as my Galaxy S3, about 90 minutes to fully discharge. If it was possible to buy a bigger battery from a company like Mugan Power then the lack of battery capacity wouldn t be such a problem. But as it s impossible to buy a bigger battery (unless you are willing to do some soldering) the only option is an external battery. I was unable to find a Nexus 4 case which includes a battery (which is probably because the Nexus 4 is a lot less common than the Galaxy S3) so my wife had to buy an external battery. If you are serious about playing Ingress with a Nexus 4 then you will end up with a battery in your pocket and cable going to your phone from the battery, this is a real annoyance. While being a cheap fast phone with a clear screen makes it well suited to Ingress the issue of having a cable permanently attached is a real down-side. One significant feature of the Nexus 4 is that it supports wireless charging. I have no immediate plans to use that feature and the wireless charger isn t even on sale in Australia. But if the USB connector was to break then I could buy a wireless charger from the US and keep using the phone, while for every other phone I own a broken connector would render the phone entirely useless. Screen Brightness I have problems with my Galaxy S3 not being bright enough at midday when on auto brightness. I have problems with my wife s Nexus 4 being too bright in most situations other than use at midday. Sometimes at night it s painfully bright. The brightness of the display probably contributes to the excessive battery use. I don t know whether all Nexus 4 devices are like this or whether there is some variance. In any case it would be nice if the automatic screen brightness could be tuned so I could make it brighter on my phone and less bright on my wife s. According to AndroSensor my Galaxy S3 thinks that the ambient light in my computer room is 28 lux while my wife s Nexus 4 claims it s 4 lux. So I guess that part of the problem is the accuracy of the light sensors in the phones. On-Screen Buttons I am a big fan of hardware buttons. Hardware buttons work reliably when your fingers are damp and can be used by feel at night. My first Android phone the Sony-Ericsson Xperia X10 had three hardware buttons for settings, home, and back as well as buttons for power, changing volume, and taking a photo which I found very convenient. My Galaxy S3 has hardware buttons for power, home, and volume control. I think that Android phones should have more hardware buttons not less. Unfortunately it seems that Google and the phone manufacturers disagree with me and the trend is towards less buttons. Now the Nexus 4 only has hardware buttons for power, and volume control. One significant advantage of the Galaxy S3 over the Nexus 4 is that the S3 s settings and back buttons while not implemented in hardware are outside the usable screen area. So the 4.8 1280*720 display is all for application data while the buttons for home, settings, and back on the Nexus 4 take up space on the screen so only a subset of the 4.7 1280*768 is usable by applications. While according to specs the Nexus 4 has a screen almost as big as the Galaxy S3 and a slightly higher resolution in practice it has an obviously smaller screen with fewer usable pixels. Also one of the changes related to having the buttons on-screen means that the settings button is often in the top right corner which I find annoying. I didn t like that aspect of the GUI the first time I used a tablet running Android 3.0 and I still don t like it now. GPS My wife s Nexus 4 seems to be much less accurate than my Galaxy S3 for GPS. I don t know how much of this is due to phone design and how much is due to random factors in manufacturing. I presume that a large portion of it is due to random manufacturing issues because other people aren t complaining about it. Maybe she just got unlucky with an inaccurate phone. Shape and Appearance One feature that I really like in the Samsung Galaxy S is that it has a significant ridge surrounding the screen. If you place a Galaxy S face-down on a desk that makes it a lot less likely to get a scratch on the screen. The LG U990 Viewty also had a similar ridge. Of course the gel case I have bought for every Android phone has solved this problem, but it would really be nice to have a phone that I consider usable without needing to buy such a case. The Nexus 4 has a screen that curves at the edges which if anything makes the problem worse than merely lacking a ridge around the edge. On the up-side the Nexus 4 looks and feels nice before you use it. The back of the Nexus 4 sparkles, that s nice but when you buy a gel case (which doesn t seem to be optional with modern design trends) you don t get to see it. The Nexus 4 is a very attractive package, it s really a pity that they didn t design it to be usable without a gel case. Conclusion Kogan is currently selling the Galaxy S3 with 16G of storage for $429. When comparing that to the 16G version of the Nexus 4 at $399 that means there s a price of $30 to get a SD socket, the option of replacing a battery, one more hardware button, and more screen space. So when comparing the Google offers for the Nexus 4 with the Kogan offer on the Galaxy S3 or the Galaxy Note which also has 16G of storage and sells for $429 the Google offer doesn t seem appealing to me. The Nexus 4 is still a good phone and is working well for my wife, but she doesn t need as much storage as I do. Also when she got her phone the Galaxy S3 was much more expensive than it is now. Also Kogan offer the 16G version of the Nexus 4 for $389 which makes it more appealing when compared to the Galaxy S3. It s surprising that they can beat Google on price. Generally I recommend the Nexus 4 without hesitation to anyone who wants a very capable phone for less than $400 and doesn t need a lot of storage. If you need more storage then the Galaxy S3 is more appealing. Also if you need to use a phone a lot then a Galaxy S3 with a power case works well in situations where the Nexus 4 performs poorly.

Russ Allbery: Review: The Making of the Indebted Man

Review: The Making of the Indebted Man, by Maurizio Lazzarato
Translator: Joshua David Jordan
Publisher: Semiotext(e)
Copyright: 2011, 2012
Printing: 2012
ISBN: 1-58435-115-2
Format: Trade paperback
Pages: 199
This is a continuation of my effort to catch up on Marxist thought while pondering workplace governance, this time following the recommendations of a friend after a related conversation (about pension systems and basic income guarantee in a Usenet group Usenet isn't dead yet). As opposed to Democracy at Work, which is a popularization, The Making of the Indebted Man has more of the density of a scholarly text. The version I'm reading is also in translation, which I suspect makes it even harder going in places. The basic thesis, though, is clear: debt is far more central to the way that we construct not only economic systems but social systems and even internal models of our own nature than is often realized. We prefer to think of societies as structured around mutual exchange, but in practice they're more often constructed around concepts of debt and credit that have been fully internalized and used to construct a moral code for a responsible debtor. And this is not a neutral construction; rather, it is a key support mechanism of capitalism and of the financial and economic status quo, used (both intentionally and accidentally) to reduce uncertainty and to support exploitation and economic domination. This is one of those perspectives that didn't occur to me prior to reading this book but which is startlingly obvious in retrospect. Once Lazzarato starts pointing it out, the prevelance and universality of debt as a basic structure of social and economic life is striking. The creditor and debtor concept extends not just to obvious examples, such as consumer credit or mortgages, but also to education (via student loans), law enforcement ("pay one's debt to society"), employment (most employers, particularly during economic downturns, have successfully inverted the natural direction of the creditor relationship and have made employees feel in debt to the employer for having a job), and social services (unemployment and welfare benefits come with significant, if often unstated, debt-like requirements). Debt is also the great leveller. It now cuts across race, gender, and social class. Apart from a small handful of extremely rich individuals and corporations, Lazzarato claims, convincingly, that nearly everyone is enmeshed to some extent in a network of debt, or at least in in attitudes and moral pressures of a debtor. Nor is this a static situation. The role of debt in our social lives seems to be constantly increasing. The past fifteen years in particular have seen drastic increases in debt during a debt-funded economic boom combined with debt-funded asset bubbles. Even after the financial collapse, much of that growth of debt persists. Lazzarato, probably in part because he's Italian, focuses on national debt (more on that in a moment); as an American, I'd identify student loan debt as a more compelling example in the United States. Other countries probably have their own examples. For a system to be this widespread, it must serve some social purpose. Lazzarato sees it as an instrument of control. Debt has been very effectively built up as a moral obligation, and (unlike a society of mutual support) it's a very one-sided moral obligation that strongly favors existing power. The debtor is held to a tight moral standard of repayment of debts, and is morally condemned by all of society, including their peers, for a failure to repay. But there is little or no corresponding moral pressure on the creditor: perhaps a half-hearted dislike of high interest rates or occasional pressure to not change previously agreed terms, but nothing like the moral pressure applied to the debtor. To be a creditor is to have an agreed-upon, one-sided right to dictate to the debtor the terms on which they must conduct a portion of their life, and the larger the debt, the larger the portion. The debtor is expected to realign their life, at least in part, around paying off the debt, including choice of profession, decisions about when to quit a job, about how to prioritize personal spending, and so forth. This is all so automatic and so deeply ingrained that, even while writing this, I'm nodding along and thinking "well, of course." Lazzarato offers an opportunity to take a step back and think about the implications, particularly of the deeply one-sided web of obligations this creates. A Marxist analysis adds another level of consideration. One of the basic questions of Marxist thought is why workers put up with exploitation by capitalists. In a Marxist analysis, workers provide the productive output of society, which is then redirected and controlled by a relatively small capitalists. The workers massively outnumber the capitalists. Why would they be content for this situation to continue? Marx, of course, thought they wouldn't be, that the periodic crises of capitalism would eventually result in a socialist revolution by the workers. But by and large this hasn't happened. Why? Lazzarato offers debt as a partial explanation. The profits redirected by capitalists are returned to workers to some extent, but as debt rather than payment. This allows workers to participate to some extent in the growth of societal wealth from constantly increasing productivity, while simultaneously entangling workers in a system of moral control. Company stores, starvation wages, and other confiscatory practices are clear mechanisms of external control that provoke directed outrage. Debt is something that the debtor has nominally agreed to (however much the situation is manipulated to make that agreement almost inevitable), and to which attaches a deep tradition of moral responsibility. The worker has respected grounds on which to object to inequitable treatment; the debtor is wholly responsible for repayment, and is rarely considered to have grounds to complain about the debt. Most of the historical attempts to balance those scales, such as laws and religious rules against usury or the historical Jewish rule of Jubilee, have fallen by the wayside. This is a rather extended summary of what I got out of the book. I'm doing that in part because the book itself is somewhat heavy going. Lazzarato makes extensive use of specialized terms (often not defined) and fills the book with references to other works without much in the way of useful summary. It's the sort of book where, if you're not already well-versed in the field, you may need to just keep reading through some passages to find a point of reference that makes the argument retroactively make sense. I had a particular difficulty with "subjectivation," a term that Wikipedia tells me is from the writings of Michel Foucault (a major source for this book), which Lazzarato uses extensively but never adequately defines. Some external research indicates that this is a very difficult term to define, which explains why I was never quite comfortable with my understanding. I think Lazzarato is using it to get at the process of internalization of the morality of debt and the way that a debt society forces individuals into a mode of economic individualism in which many of their personal choices are bent towards making themselves better (more reliable, more trustworthy) debtors. But I'm not completely sure. There are also places in which I think Lazzarato takes his argument too far, although one of those, I think, reflects a difference in national economic status. He makes quite a lot of national debt in this book, placing it in the universal position of the overarching debt that turns every citizen into a debtor even if they've avoided other debts. This is possibly true in countries whose national debts are held in other currencies, or in countries like Italy that are part of the Euro (which, if one is not Germany or France, amounts to much the same thing). It's a dubious assertion for countries like the UK, Japan, or the United States, where the national debt is held in their own free-floating currency and is largely owed domestically, and partly plays into some frustratingly incorrect political rhetoric. One of the key dynamics of debt, namely the extreme power imbalance between debtor and creditor, is missing in countries with sovereign debt in their own currency, since those countries can always (if they're willing to pay the inflation price) simply print money to pay off national debt. Creditors know this, and therefore interest rates are much lower, the amount of leverage the creditor has is quite limited, and the sorts of debt crises seen in Italy and elsewhere in the Euro periphery are not seen. Lazzarato is understandably writing from the Italian perspective, but I think he weakens his argument by lumping national debt so completely into the same category as the other types of exploitative debt he discusses. The principle does feel universal to me, but the best examples of debt vary by country, so one has to be careful about generalizing specific examples. Another place where I simply disagree with his conclusions is around some of the more dramatic presentations of subjectivation. Lazzarato talks, at one point, about how debt reduces debtors to mechanical components, and uses as an example an ATM machine, which he portrays as uniquely dehumanizing through the mechanical process that someone has to follow to withdraw money. There may be some point here about the dehumanization of debt and its subsumption into the foundation of day-to-day social interaction, but he lost me entirely with the unwarranted technophobia of the specific example. The idea that machines and automation make us less human is an old argument that's orthogonal to the thrust of his argument. It reminded me of old contentions that human relationships made on-line aren't real, which is nonsense. Overall, this is a fascinating and insightful discussion hampered by a difficult and sometimes overly elliptical presentation, a bit too much drama and grand theorizing, and a few poor choices of examples. I found the basic idea extremely valuable, but the amount of work required to extract it occasionally irritating. (This could be partly due to the limits of translation, but I suspect most of the difficulty was present in the original.) I'm not sure that I would recommend the book, but I definitely recommend considering the underlying ideas. Debt now works alongside the employment relationship as a primary means of reinforcing economic and social control and hierarchy. This is likely via accidental development rather than any grand plan, but it's now being actively exploited by the creditors of society, large corporations most notably. Viewed in that light, the explosive growth of student loan debt in the United States is particularly frightening. After Lazzarato's extensive examination of the distortive effects of permanent debt, not just on economics and society but on our own conceptions of our selves and our duties and roles in life, the idea of trapping a generation in debt from the moment of their financial independence is deeply troubling, even nauseating. Rating: 6 out of 10

28 May 2013

Matthew Garrett: Secure Boot isn't the only problem facing Linux on Windows 8 hardware

There's now no shortage of Linux distributions that support Secure Boot out of the box, so that's a mostly solved problem. But even if your distribution supports it entirely you still need to boot your install media in the first place.

Hardware initialisation is a slightly odd thing. There's no specification that describes the state ancillary hardware has to be in after firmware OS handover, so the OS effectively has to reinitialise it again. This means that certain bits of hardware end up being initialised twice, and that's slow in some cases. The most obvious is probably USB, which has various timeouts as you wait for hardware to settle. Full USB support in the firmware probably adds a couple of seconds to boot time, and it's arguably wasted because the OS then has to do the same thing (but, thankfully, can at least do other things at the same time). So, looking for USB boot media takes time, and since the overwhelmingly common case is that users don't want to boot off USB, it's time that's almost always wasted.

One of the requirements for Windows 8 certified hardware is that it must complete firmware initialisation within a specific amount of time, something that Microsoft refer to as "Fast Boot". Meeting these requirements effectively makes it impossible to initialise USB, and it's likely that certain other things will also be skipped. If you've got a USB keyboard then this obviously means that your keyboard won't work until the OS starts, but even i8042 setup takes time and so some laptops with traditional PS/2-style keyboards may not set it up. That means the system will ignore the keyboard no matter how much you hammer it at boot, and the firmware will boot whichever OS it finds.

For a newly purchased device, that's going to be Windows 8. It's not too much of a problem with a fully installed Windows 8, since you can hold down shift while clicking the reboot icon and get a menu that lets you reboot into the firmware menu. Windows sets a flag in a UEFI variable and reboots the system, the firmware sees that flag and does full hardware initialisation and then drops you into the setup environment. It takes slightly longer to get into the firmware, but that's countered by the time you save every time you don't want to get into the firmware on boot.

So what's the problem? Well, the Windows 8 setup environment doesn't offer that reboot icon. Turn on a brand new Windows 8 system and you have two choices - agree to the Windows 8 license, or power the machine off. The only way to get into the firmware menu is to either agree to the Windows 8 license or to disassemble the machine enough that you can unplug the hard drive[1] and force the system to fall back to offering the boot menu.

I understand the commercial considerations that result in it ranging from being difficult to impossible to buy new hardware without Windows pre-installed, but up until now it was still straightforward to install an alternative OS without agreeing to the Windows license. Now, installing alternative operating systems on many new systems will require you to give up certain rights even if you want nothing other than to reach the system firmware menu.

I'm firmly of the opinion that there are benefits to Secure Boot. I'm also in favour of setups like Fast Boot. But I don't believe that anyone should be forced to agree to a EULA purely in order to be able to boot their own choice of OS on a system that they've already purchased.

[1] Which is a significant and probably warranty-voiding exercise on many systems, and that's assuming that it's not an SSD soldered to the motherboard

comment count unavailable comments

Lars Wirzenius: On the usefulness of wishlist bugs

Almost every bug tracker for free software projects has a section for wishlist bugs. Often this results in ever growing lists of wishes, most of which will never be fulfilled. A long list of bugs, even if it is wishlist bugs, is rarely useful. It's hard to keep track of what is there, and so the information is not kept up to date when things change. Even if a wishlist bug gets implemented, the bug is often overlooked, and remains on the list. Joel Spolsky calls this a software inventory. Carrying a large inventory has costs, and usually results in slowed-down development. It increases the friction of doing things in a project. I have some quite old wishlists for my own projects. I have even more wishlists hidden in my own GTD system. I am not happy about either, and I'm going to have to do something about that. Just closing all wishlist bugs immediately would be bad manners. Keeping them open indefinitely, just in case someone will some day decide to look through the list in order to hack on something, is wishful thinking: that rarely happens. So I'm thinking of a compromise: keep wishlist bugs open for a while, perhaps a few months, and if nothing is happening to them, close them with an apology.

Russell Coker: Links May 2013

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

Russell Coker: SCSI Failures

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

Andrew Pollock: [life] Running, a year later

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

Johannes Schauer: New bootstrap analysis results

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

Russ Allbery: Collected haul

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

27 May 2013

Michael Stapelberg: Results of the Debian systemd survey

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

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

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

Mike Hommey: signal() doubly considered harmful

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

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

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

26 May 2013

Craig Small: props-ng 3.3.8

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

25 May 2013

Michael Stapelberg: Cloning git-buildpackage repositories

Whenever I want to work on some package, I usually clone its git repository, make my changes, then push and upload the Debian package. I don t keep those repositories around in order to avoid cruft and also to have a 100% clean, up-to-date setup whenever I start working on something. Everytime I clone such a repository, I struggle with the setup. For example, I usually forget the --pristine-tar flag for gbp-clone. Also, I usually forget to push other branches (working on debian , forgetting upstream ) and, even more often, I forget pushing tags. I spent some time on this and figured out that one can use the following to make --pristine-tar the default:
cat >> ~/.gbp.conf <EOF
[DEFAULT]
pristine-tar = True
EOF
Avoiding my other pain points is not so easy apparently, so I wrote a little shell function (only tested with zsh!) which uses debcheckout to get the git URL, gbp-clone to actually clone it and a few git config calls to make me able to just git push when I am done and not worry about anything:
# Clones the git sources of a Debian package
# needs debcheckout from devscripts and gbp-clone from git-buildpackage
function d-clone()  
    local package=$1
    if debcheckout --print $package >/dev/null
    then
        set -- $(debcheckout --print $package)
        if [ "$1" != "git" ]
        then
            echo "$package does not use git, but $1 instead."
            return
        fi
        echo "cloning $2"
        gbp-clone $2   return
        # Change to the newest git repository
        cd $(dirname $(ls -1td */.git   head -1))   return
        # This tells git to push all branches at once,
        # i.e. if you changed upstream and debian (after git-import-orig),
        # both upstream and debian will be pushed when running  git push .
        git config push.default matching   return
        # This tells git to push tags automatically,
        # so you don t have to use  git push; git push --tags .
        git config --add remote.origin.push "+refs/heads/*:refs/remotes/origin/*"   return
        git config --add remote.origin.push "+refs/tags/*:refs/tags/*"   return
        echo "d-clone set up everything successfully."
    else
        echo "debcheckout $package failed. Is $package missing Vcs tags?"
    fi
 
With that function, starting work on a package becomes as easy as d-clone golang-doc .

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

I've run into quite a problem the last few days. I bought three new laptops for my parents and a few others. I bought Packard Bell Easynote LV to run Kubuntu on and use as their home computer. But I am completely unable to figure out how to install Linux on it. The computer is preinstalled with Windows 8, and I suspect it uses UEFI instead of a BIOS to boot. The problem is that I am unable to get it to PXE boot, and unable to get it to boot the Linux installer from my USB stick. I have yet to try the DVD install, and still hope it will work. when I turn on the computer, there is no information on what buttons to press to get the normal boot menu. I expect to get some boot menu to select PXE or USB stick booting. When booting, it first ask for the language to use, then for some regional settings, and finally if I will accept the Windows 8 terms of use. As these terms are completely unacceptable to me, I have no other choice but to turn off the computer and try again to get it to boot the Linux installer. I have gathered my findings so far on a Linlap page about the Packard Bell EasyNote LV model. If you have any idea how to get Linux installed on this machine, please get in touch or update that wiki page. If I can't find a way to install Linux, I will have to return the laptop to the seller and find another machine for my parents. I wonder, is this the way Linux will be forced out of the market using UEFI and "secure boot" by making it impossible to install Linux on new Laptops?

Next.

Previous.