Thu, 06 Aug 2009
Re:
I recently (some of it during debconf, some of it right after) blogged a few things that are, shall we say, controversial. Obviously I got some response to that. Since I haven't replied individually to most of those replies, I thought a new blog post would work well.
On my very short and rather unconstructingly hateful post about gnome-keyring, JanC wrote:
I can understand why you would get popups from seahorse-agent if you use that, but if ssh gives you popups from gnome-keyring, that sounds like something is misconfigured to me?
BTW: it's easy to configure things in such a way that seahorse-agent doesn't get used inside a terminal; it's just another ssh-agent after all...
Well, presumably. But I didn't do it.
wouter@celtic:~/data/blog/live/en/computer$ sudo dpkg-divert --list|grep gnome Password: local diversion of /usr/bin/gnome-power-manager to /usr/bin/gnome-power-manager-sucks local diversion of /usr/bin/gnome-keyring-daemon to /usr/bin/g-k-sucks wouter@celtic:~/data/blog/live/en/computer$ svn up ** (process:10384): WARNING **: couldn't communicate with gnome keyring daemon via dbus: Failed to execute program /usr/bin/gnome-keyring-daemon: Success ** (process:10384): WARNING **: couldn't communicate with gnome keyring daemon via dbus: Failed to execute program /usr/bin/gnome-keyring-daemon: Success ** (process:10384): WARNING **: couldn't communicate with gnome keyring daemon via dbus: Failed to execute program /usr/bin/gnome-keyring-daemon: Success ** (process:10384): WARNING **: couldn't communicate with gnome keyring daemon via dbus: Failed to execute program /usr/bin/gnome-keyring-daemon: Success ** (process:10384): WARNING **: couldn't communicate with gnome keyring daemon via dbus: Failed to execute program /usr/bin/gnome-keyring-daemon: Success ** (process:10384): WARNING **: couldn't communicate with gnome keyring daemon via dbus: Failed to execute program /usr/bin/gnome-keyring-daemon: Success At revision 1086. wouter@celtic:~/data/blog/live/en/computer$
Note particularly the fact that the login works perfectly okay right after whatever causes this finally gives up trying to call gnome-keyring, and svn finds the authentication info in its config file (this is my blog. Not as if there's anything of serious security there; those repositories that are important are behind SSH)
I never even asked anything to run gnome-keyring-daemon; but if I allow svn to do its thing without asking, this is what happens. I don't have libpam-gnome-keyring installed, and I'm no longer running gdm; two sources of things that run gnome-keyring-daemon without my asking. Yet the bloody thing keeps cropping up everywhere I look. It is broken, and it should not exist. Thank god for dpkg-divert.
On my post about MS and the GPL, some people wrote that Microsoft only published the code for GPL compliancy, not because they thought it a good idea or some such.
While this might be true, the fact of the matter is that, unlike many many many other companies out there, they decided to not just put a blob of code on their website and be done with it, but instead to do the right thing, and get the code merged. That is far beyond what the GPL requires them to do, and it signals to me that they did this because they are changing—the Microsoft of 10 years ago wouldn't even have written those drivers in the first place, let alone get them merged. That, I think, was the most important point of that post.
On my post about passwords, Matthew Johnson wrote:
An SSH key is very much not just "a password written down". Passwords are sent in the clear (inside the tunnel) and are therefore more subject to MITM attacks, keyloggers, etc. SSH keys, because of the asymmetric crypto, if you do manage an MITM attack using an SSH key does not reveal anything which could be used to authenticate another time.
Good point; I overlooked that. Yes, that does make passwords somewhat less secure, and defeats most of what I said. However, it does not defeat the fact that allowing only one way to login increases the chance that you will require some people to jump through hoops—me, I do not keep my SSH keys on my laptop's hard disk, so they don't get compromised should the laptop ever get stolen. That does make it harder for me to log on to a system using these keys, however, and it makes me consider generating a separate SSH key that I will keep on my laptop, just for Debian.org hosts. I need to log in to some of them far too often.
On that latter post about buildd maintenance, I received a response from Riku about how he feels using tr on the client-side is wrong, and how I should instead have patched buildd-mail instead to decode MIME encodings.
Technically, he's right. Practically, he's not. When I wrote this script, it was far easier to fix the problem once, on my side of the equation, rather than every time I install or upgrade buildd. At the time, the code was in a repository that only Ryan had commit access to, and as a result most people kept patches locally. I should still have a patch lying around somewhere that has the same effect as the one that got committed, but gave up trying to use it, as in my ever-changing set of buildd hosts, one would creep up again and again that did not have the patch applied, because it was recently reinstalled after a dead disk, or because buildd was upgraded, or some such, meaning that signatures would fail and I would have a shitload of unnecessary manual work. In such a context, writing code on my client side—in casu 21 characters—is far easier than trying to fix the code centrally.
Fri, 19 Dec 2008
Metablogging
Ciarán O'Riodan blogs about how to blog, and his post is a good read. Most of it is solid advice, and I find there's little I disagree with; if you want to get a blog that's well-read by many people, then his advice is probably sound. So why am I posting this in my 'retorts' category?
Because I feel that blogging isn't something that should be taken too seriously. A blog is an outlet, a place to get your thoughts out; it is a bit of a combination between a column and the readers' letters section in a newspaper.
The writing style of a blog should reflect that; when I write a blog post, I don't care about what the truth is, I only care about my opinion. If I want to write the truth, I'll write a wikipedia article. If I want to read about the truth, I'll go and kill myself—because I'm not naive enough to think something like "the truth" exists in this life. And if I want to read a magazine-style article, how about I'll go buy a magazine instead of reading a blog post?
A blog post doesn't require references (beyond, perhaps, what you're replying to); a blog is a reference, one to the personal opinion of the author. If you think something is great, then as far as your blog is concerned, that something may be the best thing since sliced bread. If you think something is ugly, crap, and should be forgotten about, then on your blog it is. In more than one sense, blogs are like opinions: everybody has one.
That doesn't mean I disagree with most of what Ciarán wrote; on the contrary. Points 1 through 3, and 6 through 10, will help you develop a good writing style. I couldn't agree more on point 11, that you have to push for publication yourself; and it's certainly true that being aggregated is a good way to put your thoughts in context, and to expose yourself to a larger readership. But I vehemently disagree with his point 4:
It can take time. A good article-style blog entry can take six hours to write!
Not that I think writing a blog post should take no time at all—this particular one has been almost an hour in the making, now—but because I feel that, simply, articles, with all their references, scientific or other background, and whatnot, simply do not belong on a blog. A bunch of articles with an RSS feed is not a blog, plain and simple. So while I do agree that it can take time, I do think you're doing fundamentally wrong if your blog post takes more than, say, an hour and a half, to be written.
So, in the interest of being constructive, here are my own suggestions:
- Don't think too much, just write. It may sound stupid, but the most important part about blogging is actually doing it, and not wondering about how or why.
- Do reread if possible. While blog posts are usually read in a few minutes, they take much longer to write; it's easy to lose track of your line of thinking during that process, in which case you may end up with a completely incoherent post. That certainly is to be avoided.
- Ciarán's argument that if it's worth doing, it's worth blogging
about certainly holds merit, but I'd go one step further: if it's
worth thinking about, it's also worth blogging about. After
all, a blog is mostly a braindump, so why not?
That's not to say every thought can be turned into a coherent blog post, and I have a bunch of half-finished unpublished blog posts on my local hard disk which I may revisit at some undefined point in the future; but the principle is there. - And last, but not least: don't care about what other people are doing. Your blog is your own, not someone else's; if you get an email that your content sucks, ignore it. If you get an email that you should be writing about something else instead, ignore it. You're not getting paid for your blog, are you?
Fri, 12 Sep 2008
Philip,
Sometimes you're just flat out wrong.
While I can understand your position of 'all fear-mongerers and religious fanatics should just commit suicide', I do not agree with it. However, this time, the girl you refer to didn't actually commit suicide because she fell in any of those categories.
Had you actually read that BBC story you link to in some detail, you'd have found that:
- The girl was sixteen years old. While old enough to understand danger, it usually isn't old enough to understand the intricacies of science.
- She took her own life after watching a sensationalist TV channel that was spreading the lie that the LHC would cause the earth to crack up
Now I agree that ignorance to science is something that should be advocated against; but if the facts of science are misrepresented through a TV channel that is only interested in its own profits, are those who do believe their only source of information then to be blamed? If the only data you get are outright lies, is the world then indeed a better place because it got rid of one "mis"believer?
I think not.
Sun, 27 Jan 2008
Software RAID
Russel blogs about write intent bitmaps, which are an option in the Linux Software RAID subsystem, which works somewhat like a journal on the RAID level: every time you write to the array, you first mark the bits you're going to write to as dirty, then write them, and then mark them as clean again. This allows the RAID subsystem to have to check much less in case of a system crash, where normally the system would have to run a full array rebuild.
He'd suggested this before on the debian-boot mailinglist, and when I read that post, it seemed to make sense. However, after reading his blog post, I'm not so sure anymore. In his words:
The down-side to this feature is that it will slightly reduce performance. But when comparing the possibility of a few percent performance loss all the time and the possibility of a massive performance loss for an hour or two after a crash it seems that losing a few percent all the time is almost always the desired option.
I vehemently disagree there. Performance is irrelevant in case you have a large server park; in that case, adding another server to the park is relatively cheap—you don't run hundreds of servers on a small budget, and besides in these days of virtualization, often migrating a service from one physical server to another isn't very hard.
However, this isn't true when you're talking about small businesses, or (especially) home servers. When I have a choice between high loss of performance in case of something which happens only rarely (in my experience, the Software RAID subsystem is pretty good in recovering from a power loss without having to go through the RAID rebuild, leaving only kernel crashes and similar) or a small but continuous performance loss on my home server, there is no doubt in my mind that I will choose the former. First, my home server is a Thecus N2100, which, while powerful enough to run a number of services for my home network, is not a very fast system with somewhat low resources in comparison to some other systems; and even a small loss of performance is probably noticeable. Second, the speed of recovery which the RAID subsystem uses (and, hence, its performance impact) is manageable through the files /proc/sys/dev/raid/speed_limit_max and /proc/sys/dev/raid/speed_limit_min. Obviously lowering the speed of the RAID rebuild will make the process take longer; but if performance matters that much to you, then lowering the rebuild speed can be an option. Finally, sometimes the RAID subsystem chooses to go through a lengthy check of the entire array; it would be interesting to know whether using the write intent bitmap feature disables this too. I suspect this is not the case, and if so it would seem as if enabling this feature would cost some performance for little benefit: in normal situations these checks happen far more often than actual RAID rebuilds; so the most important source of performance loss would not be handled at the cost of extra performance loss.
In closing, I guess the right answer to this question is that it's a trade-off; that choosing the right defaults should be done by upstream (to avoid confusion), and that the user should be given the possibility (somehow) of enabling or disabling this option in defiance of the defaults at install time (perhaps only in d-i's expert mode)
Tue, 22 Jan 2008
Adrian,
No, that is not the correct key combination. You were looking for start+r.
Thu, 23 Aug 2007
Chroots? Jails!
Russel Coker blogs about securing a daemon using a chroot, and offsets it against SE Linux. He argues that SE Linux provides better security; no doubt.
One downside about SE Linux, however, is that it's far more difficult to configure correctly than a chroot. Setting up a chroot involves creating a directory, copying or bind mounting stuff in there, and then just using the chroot system call (either from a shell script or from a daemon). Setting up a non-standard daemon using SE Linux involves a very fine-grained process of allowing access to files and system calls that many people inexperienced with SE Linux will find too hard to do.
OTOH, he's right that it's possible to break out of a chroot, and thus a chroot system isn't totally safe.
This is why the FreeBSD developers implemented the jail system call since FreeBSD 4: basically a chroot on steroids, it implements a basic form of virtualization -- your "chroot" gets an IP address assigned, and jailed processes cannot communicate with processes outside the jail other than through TCP/IP or some other form of networking. Processes outside the jail can modify stuff inside it, of course (it remains a simple directory).
Of course, Linux doesn't have anything like the jail system call, but it's easy to set up a similar level of security using virtualization, in a way that is far easier for the uninitiated than when using SE Linux. That's not to say that jails or virtualization will give you the same level of security that SE Linux can offer (e.g., with jails or virtualization a user can still exploit a bug in a network-facing daemon to turn your machine into a zombie; SE Linux can make this impossible), but it's a different option.
Fri, 13 Jul 2007
Traffic Shaping
Erich Schubert blogs about traffic shaping, and shows how you can do some basic traffic shaping using a rather long example. I'm sure that example works, but mine is slightly less complex:
tc qdisc add dev eth1 root tbf rate 212kbit burst 1540 latency 50ms
This is actually a literal example in the Linux Advanced Router and Traffic Control-HOWTO, and it works for me. Linux has a reasonably good default prioritizing and queueing already, and using the tbf filter doesn't replace them, whereas the detailed sfq example that Erich gave does. I'm doing this on my router (on the outgoing interface), not my laptop, which is also a rather important bit.
Of course, it working for me doesn't necessarily mean that it'll work for you too. But you might just want to try it...
Wed, 27 Sep 2006
GDM
Joey,
Debian's GDM does ship with the default file that contains lots and lots of comments. However, if you use the builtin configuration tool at least once, it will overwrite your configuration file with another file that contains just the configuration, not the comments anymore.
Perhaps that's what happened to you?
Tue, 16 May 2006
On huge ISPs and multi-level support requests.
They just told you how to get past their front lines: Call their business support on the toll-free phone number she gave you. Here's my take at what happened:
- You entered a question on a web form which is intended for user support questions.
- A first-line technical support person called
Irene
(who, most likely, is not trained as a computer person; since 90% of all calls can be fixed by going with the customer through their connection and email settings, you can train anyone to be a first-line technical support person in one day, with most of the time spent inHow do I handle the phone
andHow do I handle the ticket tracking system
) had a look at your request, saw that you had problems with sending email from remote systems, and copied a standard text about mail bounces in her reply to you. Remember that there are many peopleout there
who think they know a lot about computers because they know how to startregedit
and know a few buzzwords; the presence os such words in a support request is not necessarily a sign that there's some clue at the other end of the line. - You replied that no, this does not apply, and that yes, it's really
a problem at your end, because lots of words Irene does not
understand. She then decided you're totally out of her league, and
redirected you to their second-line support; second-line supportlines do
consist of people knowledgeable about computers, because at that point
it's no longer a trivial problem. Since you happen to be an ISP, which
is a company in her book, she referred you to the Business support line;
such a Business support line usually consists of people even
more knowledgeable about computers in general and the Internet
specifically, because companies usually have rather specific needs that
go a bit further than
I have an ADSL modem and a Windows box
.
Really. Call them. You'll find that you will be talking to someone
knowledgeable about what SMTP
is, and who is able to put a request with SMTP
administrators to fix this issue if that is required.
Take it from someone who used to work at one of Belgium's largest ISP's (at least, it was that when I used to work there—they've lost some market share since).
Sun, 09 Apr 2006
Crypto law, take two
- Yes, I had read their FAQ, and had seen that the controls are
implemented by each state themselves. That's why I concluded my comment
on that bit by
will have to investigate this
;-) - Yes, they can force you to decrypt your own data. Read Art. 88quater, §2, carefully.
Sun, 12 Mar 2006
Employment law
Please get some way to contact you up on your site. Having to reply through Planet isn't ideal.
Anyway.
I'm not familiar with employment law across all of Europe, but the claim that you have to employ them for a certain period after you actually fired them, or even that you can't fire someone without due process, is simply false—at least in Belgium, though I expect the same is true for most other member states of the European union.
First, there's the fact that every employment contract starts off with a "test period" which can take up to six months, depending on the type of employment (it is longer for hotshot management than it is for hand labour) and the length of the contract, if appropriate. During this period, an employer can fire someone without further explanation and without any process. This is to make sure that you can get rid of people who managed to sell skills on themselves they don't end up having.
Second, an employer can fire anyone right away for what is called 'urgent reasons'—things like employees stealing from the employer; basically anything that makes the employer lose trust in the employee (though this is strictly regulated, for obvious reasons).
Third, if you fire someone not during their testing period and not for urgent reasons, you do not have to keep them at your place; it is legal to tell someone that as of tomorrow, they no longer have to come to work -- you just have to give them a pay check for those three months (or whatever) you would have to employ them otherwise.
Finally, the thing also works in the other direction; if some important employee (say, the only guy with the root password) decides to quit, an employer can require that they stay at work for up to (IIRC) two weeks, so as to ensure continuity. But I understand you knew that part already...
Tue, 28 Feb 2006
#debian-tech
aj, my joining did not mean that I agreed with the channel. For me to join, ij had to convince me that it was important and that m68k had to be represented. And state that he didn't have the time.
As you may have noticed, I did not say much during that time, and did not ever join #debian-tech afterwards. The reason that I did join at that point was that this discussion was, indeed, important, and that it was going on at #debian-tech. I didn't want to risk not having a say again in the future of things that are important to me; the fact that I did this should not be interpreted as an acceptance of and agreement with the channel's charter.
I still feel very uncomfortable about the be nice, or
else...
charter of #debian-tech, because it means you can not know
whether something you say as a joke will be interpreted as hostility and
might get you kicked. The most important part of IRC, besides being a
quick and easy way to get help, is the ability to have some fun;
jeopardizing that makes an IRC channel so much less interesting to
me.
And, as it would appear by the replies that your recent post caused, to a lot of other people on planet debian as well.
Thu, 15 Dec 2005
On version control systems.
I never thought anyone would still seriously advocate CVS over anything else these days, but I was wrong.
Bernhard:
- Ever heard of atomic commits? You modify three files, commit. Turns out that in the time between you starting to edit stuff and you committing, someone else changed some stuff, and your commit doesn't apply somehow. The first file is committed, the second breaks, and the third isn't committed. Congratulations, you just broke the build, and you'll have to manually fix it. When editing three files, that's manageable; when your commit is (say) about 15 files or so, it's not really as manageable anymore. CVS doesn't have atomic commits.
- About it being rock solid, I only say
Hah
. I've seen way too many cvs pserver bugs out there—and that's still the only possible way to go if you want anonymous CVS access. - How about the fact that upstream CVS development is rather extremely dead, after most of their developers started to develop subversion because the CVS code is so extremely horrible to maintain?
- Moving files around isn't just a nice thing to have; it's an extremely important feature. Far too often have I seen people afraid to reorganize their code because that would lose history on the files. If you can't move files, you can hardly ever reorganize code, which means that you let your version control system dictate how you should work—which is bad, very bad.
- And finally, being able to tell someone that
this is fixed in r132
rather than having to saythis is fixed in r1.74 of foo/bar, r1.34 of foo/baz, and r1.82 of foo/quux
is very helpful. Your suggestion about dates (there's normally at least a quarter of an hour between commits
) only suggests that you haven't seen many large projects in the heat of code changes. And even if that weren't true, the fact that itnormally
isn't a problem makes it even more of a problem on the occasions that it, in fact, does take less than a few seconds between my commit and yours
Really. Have you tried comparing CVS to anything else, on a serious project?
There should really be a way for all those version control systems to talk to eachother. After all, they all have one thing in common: they're all ways to exchange patches. Surely there must be some way to device a protocol or something so that those patches can be easily sent from one version control system to the other and back again?
Thu, 22 Sep 2005
Playing police will not work
So there's now a Debian Tech channel. Apparently, some people thought there was need for a channel where we're all nice and friendly rather than start attacking eachother; and if you're not like that, you might get kicked out of there.
This isn't the first proposal from aj that involves forcefully being nice to eachother and policing those who're not doing so, but I don't think it's going to work. Debian has never done this; if you suddenly start making up such rules and request that people keep their temper, those people will just go somewhere else to cool off; and you'll lose the possibility for consensus that is so important for whatever Debian wants to accomplish.
I agree that our constant bickering isn't the most productive way to get things done; Debian would be so much more pleasant if everyone would just be nice to eachother. Unfortunately, Debian is a large group of largely unorganized people. It's actually normal in such a case that people fight every now and then—many of us are very passionate about what we do, and want the Debian system to be the best system out there. Which is good; it is one of the reasons why Debian actually is such a good system. But invariably, when so many people get to have a say about so many things, with everyone being basically equal (or at least, mostly so) as is the case for Debian, you'll have conflicts every now and then.
I can see two ways to handle that:
- Do not do anything. Accept the fact that there are fights every now and then, and deal with them; do remind yourself every now and then that these are all just bits and bytes, however, and do not hold grudges; or,
- Give some people more authority than others. We already have this (to some extent) in that people who 'do the work' get to decide, but when there's more than one person (of group of people) 'doing the work', there's currently a conflict of interest, and, as a reasult, heavy bickering. We could give some people the authority to make a judgement call in such a situation, but then you'd eventually end up with a corporate-type hierarchy that at least I myself would like to avoid.
It's also not quite unlikely that it gives more power to those who're first. I could come up with a proposal that would kill off whatever stuff you're trying to accomplish, while there's a different way to accomplish the same thing; you, being passionate about what you do, would go on and rant about it in some public space. Then you would be shut up by the "be nice" police, and my proposal would be implemented.
With the status quo, I would come up with the same proposal. You'd rant about it in public. I'd need to defend my proposal, which I'll do just as passionate, and we'll have a flamwar on a mailinglist from here to Tokio. In the end, we'd both be a bit less happy with what Debian has become, but -and this is important- either the status quo will be retained or a compromise will be found and could be implemented. It's not totally efficient, but it does work.
And really, forcing people to be nice—"or else!"...? That won't accomplish anything, really; it's just a different way of generally not being nice to eachother.
The question you should ask before implementing police states is "is this police going to add value to whatever we do," not "is this police going to make us happier?"
Even if being happy with what you do is, of course, generally desirable.
Mon, 29 Aug 2005
milter-ahead
It will never cease to amaze me how people keep using sendmail rather than exim, and then have to jump through ugly hoops to get it to do stuff which exim has on-board.
acl_check_rcpt: require verify=recipient/callout=defer_ok
Does quite exactly the same thing, and is builtin to exim(v4). Even better: it actually caches results, so that not only you don't overload your primary system, you might also block some extra mails even when the primary is down and your cache hasn't expired yet. Oh, and one can easily do the same thing for senders, so that you don't get mail with nonexisting email addresses in the envelope from. Catches quite some spam too, that.
Still, I don't run backup MXen, simply because distributing SpamAssassin bayes databases and rulesets is rather complicated... and if my mailserver goes down for a while, I'm sure any sending host will attempt to deliver their mail once I fix the problem. As has happened a few times already by now.
Thu, 26 May 2005
How do search engines work?
Adam Kessel recently commented in his blog about how MSN found his 'hidden' domain. Adam appears to think that by not spreading a URL of a webserver, he can hide the site from search engines.
As Google explains, however, hiding a site in such a way is plainly impossible.
That being said, of course MSN should honour robots.txt... if it really is MSN. Adam doesn't provide the IP address of the robot that crawled his 'hidden' webserver; but of course, if he runs whois <IP address of the bot requesting the page>, he can easily figure that out... and complain if required.
Fri, 11 Mar 2005
Printing
Lars blogged about printers, mainly about how he's dissatisfied with the current state of affairs. I agree that a state of affairs as he describes it would suck. Luckily, reality is a bit better :-)
You really should try installing CUPS, and the foomatic-filters-ppds package1. Once that is done, edit /etc/cups/cupsd.conf on any machine having a printer connected to it, and find the option "BrowseAddress". Enable it (there are enough comments in the file explaining you how to do that; make sure it doesn't send out stuff to machines on other networks). Once you restart cupsd, it will start to broadcast a list of printers available to it, and other machines in the network also running cupsd will pick it up (unless you disabled browsing on those machines) and make the printers available to the local system.
Using this setup, I do not have to reconfigure my laptop every time I want to print; both at home and at the office, I have systems broadcasting their printers; and all applications that directly support CUPS (rather than using lpr) will show me a list of printers available on the network. So, the network part of Lars' problems are already solved.
That leaves the manual setup of printer queues. Cups allows you to do this via an easy web interface (which, by default, only listens on localhost), but there are other options. Unfortunately, though, I don't think it's possible (yet) to make it as easy as Lars would want. But it's not as if it's hard...
1based on the views expressed in that packages' description, one could say that the maintainer of said package would probably disagree; but I find it much easier to just install a full list of prebuilt files rather than having to manually run foomatic-ppdfile and having to remember where to put the file.
Mon, 07 Mar 2005
NM graphs
Christoph Berg created some NM graphs, but has a problem with one of them where stuff overlaps too much.
I don't know neato at all, but I do know that there is a tool called 'springgraph', which supports a subset of neato syntax. Not much, but I think enough for the graphs he's using; and since springgraph calculates node distances dynamically, using an algorithm based on the number of connections, it might solve his problem.
