Since I blogged about it, a few things happened around APT maintenance.
First of all, it seems that more people got interested in the package. Many even *discovered* that one of our key packages was not that actively maintained.
Not everything is really settled, far from that. There is no strong team yet...but some hype happened.
A wiki page has been setup (I'm offline right now...just search on wiki.debian.org).
Eugene V. Lyubimkin started bug triaging activities and will need help and encouragement (or cookies).
Michael Vogt gave some indications about how to contribute to APT.
Things happened. And I don't even know if that done by Debian Developers, Debian ontributors or Debian Maintainers. Things just happen and that's good.
This is going to help us release lenny, while the two giant threads currently running on -project and -devel will not.
Linus Torvalds isn’t a hacker! Richard Stallman isn’t a hacker! Niels ProvosOf course, one can play the game of defining the authentic hacking (and it makes sense for many to do this!) but my interest as an anthropologist has never been to draw a bright and clear boundary between good hackers and bad hackers. or “real and fake hackers,” but instead to describe and grapple with the tension points and internal ambiguities among hackers (my whole course is designed around this theme, in fact). This is not to say that anything goes in the world of hacking (that is, I don’t consider any computer break in a hack; I often just call it a crime) but if there is a group of people calling themselves hackers and thinking to some degree of the ethical implications of their actions, as an anthropologist, this is enough “social evidence” to start asking some questions about the political and cultural significance of their actions.
isn’t a hacker! Fat/ugly, maybe! Hackers, no! And what is up with
the use of the term “cracker”? As far as I’m concerned, that term
applies to people that bypass copyright protection mechanisms.
Vladimir Levin? HACKER. phiber optik? HACKER. Kevin Mitnick? OK,
maybe a gay/bad one, but still WAS a “hacker.” Hope that’s clear.
For a minute, I’d like to think about The Announcement in terms of problems and solutions.
Problem: We don’t have enough non-developing contributors in Debian
Cooperatives South West is working in partnership with the Regional Infrastructure for Social Enterprise (RISE) to hold a Trade Fair with support from CDA (BRAVE Ltd.), Social Enterprise Works, Co-opportunity and Watershed Media Centre. It will be held on Monday 1 December at the Watershed in Bristol.
Due to the size of the venue, the number of exhibitors and delegates is limited, so complete the booking form as soon as possible. There is no charge for cooperatives to attend or to exhibit (but there will be a charge to cover catering and venue costs if you book but don’t attend or cancel).
The Social Enterprise Photography Competition is now launched across England. Regional winning photographs of the competition will be featured at the Trade Fair and the winners will be presented with their awards by a special guest. Please encourage all your friends and colleagues to submit photos of social enterprises.
(Thanks to Viv at Cooperatives-SW for the above information.)
ace root% apt-get install tftpd-hpaNote: If this installs an inetd at the same time, you may need to restart the inetd so it enables the tftpd service. The tftpd will serve files out of /var/lib/tftpboot, so we need to add some files for it to serve. You can use this script to fetch various netboot installers from Ubuntu's servers.
#!/bin/bash
set -u
set -e
cd /var/lib/tftpboot
for dist in dapper feisty gutsy hardy intrepid; do
mkdir -p $dist
for arch in amd64 i386; do
mkdir -p $dist/$arch/
(cd $dist/$arch/ && ncftpget -RT \
ftp://archive.ubuntu.com/ubuntu/dists/$dist/main/installer-$arch/current/images/netboot/)
done
done
Download ubuntu-tftp-update.sh
Now we need to alter our dhcpd configuration. (You are using DHCP
aren't you?) All we need to add is a group declaration to your subnet
declaration, adding a next-server and a filename
parameter. You can then add a host declaration for any machine you want
to netboot into the installer.
group # intrepid amd64
next-server 10.0.0.1;
filename "intrepid/amd64/pxelinux.0";
host foobar hardware ethernet 00:22:15:45:cc:fa; fixed-address foobar.example.com;
You'll need to restart the dhcp server so it picks up the new
setting. The next-server parameter is the name or IP address of your
tftp server. filename is the path to the bootloader. Obviously,
you can use this to pick which version of the installer you want to
run. If you do a lot of installations, it might be worth configuring
every installer you're likely to use and then move hosts in and out of
the suitable group as and when you need to install them.
All that's left to do now is to boot the computer and set it to boot
from the network and enjoy medialess installation.
While I don’t really have a strong opinion on the suggestions in Ganneff’s announcement in d-d-a, as I haven’t had time to think deeply about the consequences that they would have, but which I foresee to be very important (they could have strong implications in the Debian Project), and making use of my freedom of speech, I must say that I agree with Joey and Julien. I don’t like how the whole proposal has been done, and I also fear the accumulation of power that slowly seems to be going along in Debian. I believe that spread power usually is much better and healthier than the opposite, and if it’s true that decisions are being increasingly taken in cabals, we’re going in the wrong direction. About Julien’s post on people being too coward to say what they think, a long time ago I posted about NM process saying that “If you want to finish university, you should take care about getting on with the teachers. The result are submissive citizens that won t face authority even if they know they re right, in order to avoid problems“, and “What should be taken care about is that the NM process don t filter 
Here are some tricks that you can use to ensure that your announcement to
debian-devel-announce has maximal negative utility.
hide who's talking
Make sure that your announcement does not start off by making clear who's
speaking. The announcement will have a From line with your name on it, and
that's good enough. Everyone knows who you are, what groups you're a member
of, and can guess what group you're speaking for ... or whether you're just
speaking for yourself.
Throughout the annoucement, be use to use terms like "We plan", "let us
describe", "we are considering", "This is where our proposal comes in.", etc.
Maybe in a footnote include a clue such as a mention of "the NM-Committee",
but be sure to not sign the announcement with the name of any group or
team or set of people, so that the reader is left guessing about who this
"we" is all the way to the end and beyond.
(And hey, "cabal" is a fun word.)
weasel words
Scatter throughout the announcement some vaguely worded digs at things you
disagree with. The key here is to make clear what you really mean, while
providing enough plausible deniability that you can deny having said it
later.
So you might say ...
Some time ago a few Developers thus went and pushed forward the "Debian Maintainer" status.... Thus implying that this was a few malcontents who should be ignored. Sure, the whole project voted for this, and so you should be sure to allude to that vote somewhere else. Maybe in a different paragraph entirely, you could refer to "Debian Maintainers (DM) [GR-DM]". (It would be excessive to have that footnote refer to a bogus url like http://vote.debian.org/something.) the big lie Make sure that your announcement starts off all bright and cheery on the surface, with just a hint of deadly steel jaws underneath. Something like:
If you are an existing Debian Developer or Debian Maintainer, don't be afraid, we are not going to take anything away from you.Natter on for many, many pages of trivilities, good ideas, bad ideas, half-baked ideas, conflicting acronyms, and useless footnotes. Then spring the trap:
In future this will be a list maintained by the NM-committee. At the time of migrating from the old to the new way, Ftpmaster will convert the existing DM-Upload-Allowed fields into that list, so there should be no interruption in your ability to upload.And ability to upload is all that matters. Who cares about the regression back to the tyranny of unix permissions? Who cares that DDs won't be able to decide when they trust a DM to upload their package, or that DMs won't be able to sign up quickly and easily, or that DMs will have to petition a disinterested committe to change anything? Nothing will have changed, nothing will be taken away, nothing to see here, move along: The big lie.
The Linux desktop currently receives (certain) key events in two ways. Firstly, the currently active session will receive keycodes via X. Secondly, a subset of input events will be picked up by hal and sent via dbus. This information is available to all sessions. Which method you use to obtain input will depend on what you want to do:
I've just started a new job, so I decided to take a few days holiday in
between and work on something that's been on my todo list for way too long
now -- making the debian-installer work on the D-Link DNS-323.
After a couple of days of work, I've just finished off the install of
Debian on my DNS-323, which I initiated by loading a firmware image into
the web interface of the stock firmware, and then SSHing into the machine
at the appropriate moment. What this means is that anyone with a
DNS-323 can install Debian on it. I think that's worthy of a small, quiet
"woo hoo!"...
Looking back now, it seems to have been a fairly simple and
straightforward operation, but I can remember that it didn't look so
simple when I started a week ago. So, in the interests of perhaps
short-cutting someone else's adventure into the world of d-i hacking, I'm
writing everything up while it's fresh in my mind (the benefits of being
on holidays -- plenty of time to write long blog posts). Alternately, if
anyone has a random device they'd like to see d-i on but doesn't have the
inclination to do it themselves, feel free to send me one and I'll do it
for you.
Before I begin, I've got a few "shout outs" (I think that's what the cool
kids are calling it these days) to people who've helped me along the way.
First off, Martin Michlmayr has answered innumerable dumb questions from
me, and I think wrote most of the parts of d-i that I've extended -- it's
fair to say that I'd have had no hope of doing this without him. Thanks
also to the people in #debian-boot and #debian-arm for
answering questions and putting up with my frequent bouts of
self-congratulation whenever I passed the most miniscule milestone.
Finally, everyone who has put work into d-i has my thanks, too -- it's not
perfect, but it's a damn sight better (both to use and also to hack on)
than any other installer I've ever met.
So, without further ado, off we go...
Work out how to get a console
Unless you are a guru of unbelievable skill, you will undoubtedly not do
everything quite perfectly the first time, and you'll want to see the
kernel/init boot messages, and maybe in some cases try some investigation
and diagnostic work. For that, you're going to have to have some sort of
console access.
If the device doesn't have a full screen/keyboard thing going on, the
chances are you'll almost certainly end up with a serial console. A few
devices have a network management thingo that will give you a console,
usually over VNC or some sort of horrid Java applet, but I've only ever
encountered that in rackmount servers, which have a keyboard/video
interface anyway...
In theory, I suppose, the kernel could provide a network console, but I've
never heard of such a thing being attempted, and Google is not helping me
out. I might add that to the todo list as a future hacking project...
On the DNS-323, it was a serial console that was needed. Like a lot of the
embedded devices I've seen, it didn't quite talk RS-232, so I needed an
adapter (I got a TTL-232R-3V3 USB-to-3.3v-serial adapter from a
local electronics supply place, which worked perfectly with Linux as
soon as I plugged it in). I needed to solder a few wires to a connecter
inside, and connect that up to the USB doohickey, but it all came good in
the end. The chances are someone's done a similar job for your device of
choice, so a search for things like "devicename serial console" will almost
certainly pay off.
Work out how to load and boot a kernel/initrd
Your development work will involve booting weird kernels and initial
ramdisks to make everything work; you need some way of stuffing those into
the device and booting from them. Everything has a boot loader of one
sort or another; working out what you've got and how to make it sing and
dance is the ultimate quest here.
How this is done will vary greatly from device to device; the WRT-54GL,
for example, waits for a tftp connection for a couple of seconds on
startup, which you can use to send a new firmware; many other devices have
a boot loader that you have to explicitly control (via the console), but
it will make a tftp connection out to another machine if you ask it to.
Some devices you just need to load the data in via serial cable (at
115200bps it's bearable; at the 9600bps I've heard some devices work at,
it would be tres painful).
The DNS-323 runs uBoot as the boot loader, which will do a tftp request by
default. However, D-link, or Marvell, or someone in the
decision-making chain for this thing decided to knobble it and removed most
of the useful commands, so sending the thing via serial port is the only
option. Since writing to flash takes a pile of extra time, I found
(eventually) that you can just load the data into RAM somewhere and boot
from there, without needing to write it to flash (also handy to avoid
wasting precious write cycles), since you can tell uBoot to boot a kernel
located anywhere in the address space. Obviously you need to reload the
kernel/initrd on every boot if you don't write it to flash, so if you've
got a "stable" kernel or initrd that you think you'll be using for a while
(when you're testing the other item) you should flash it then.
One note on uBoot, that took me far too long to work out -- you can't just
stuff a kernel fresh off the Makefile in and assume it'll work -- uBoot
needs a special header prepended that tells it all about what you're
loading (architecture, file type, compression method, etc). You "wrap" a
file in this uBoot header with the "mkimage" command (in the
uboot-mkimage package in Debian).
Incidentally, if you need to remove the uBoot bits from a file, just strip
the first 64 bytes off -- that's all the uBoot header is, so something
like this will do nicely:
dd if=file.uboot of=file bs=64 skip=1A final uBoot warning: it's fairly important to specify a "load address" for the files; if you get them wrong, your kernel and initrd may or may not boot (I never quite got the hang of why some wrong values worked and some didn't). If your device uses uBoot, and you have the ability to extract the uBoot-enabled kernel and initrd from a vendor-provided firmware image, you can use mkimage -l to inspect what all the values need to be for your own kernels and initrds. Just stick with them. Does Debian support your hardware? Obviously, if you want to run Debian on something, Debian has to support that hardware. The easiest way to test this out is to try an install. For this, you'll need to retrieve an appropriate kernel and initrd pair for the installer. Some arches, like i386 and amd64, only have one kernel and initrd for the installer, so you just have to choose if you're going to netboot, or do a full CD install, or whatever. Other arches, though, like arm, have subtly different images for different machines. There are two reasons they vary: firstly, they often need to split into subarches, where they all share a general CPU architecture but there are enough differences in the hardware that they're not all supportable by the same kernel. At a more fine-grained level some different machines of the same sub-architecture need differently formatted firmware images to boot. On ARM, in particular, it's pretty common to need to prepend a "device ID" to the kernel image so that the kernel knows what sort of machine it's booting on, which means that every machine typically needs it's own kernel image, regardless of any other issues with firmware formats. Choosing the sub-architecture should be relatively straightforward, if you know much about the machine you're targetting. Picking a machine type can be a bit harder, but again, if you know what your boot loader needs, it shouldn't be too hard to find a kernel/initrd from the existing machines in your subarch that you can mangle to fit. Load up your kernel/initrd into the device, boot it, and see how far it gets. You might get lucky, and the kernel inits, your hard drives are detected, your NIC is initialised, and you're off and running without further ado. Or you might not be so lucky. The worst case is that the kernel doesn't even get as far as loading the initrd -- it might not print anything at all, or the kernel might hang part way through the boot. This is likely to require a fair amount of debugging fun, as initial boot failures get a bit tricky. A better situation is where the kernel boots OK, and d-i starts, but something in the install process falls over. This can either be a kernel/driver problem, or a d-i problem. Either way, since d-i has started, you're likely to be able to get a shell and do some debugging. In order to make d-i work, you need to have somewhere to install to (disks, usually) and a source of packages to install from (CD/DVD if you're on a suitably large device, or the network otherwise). These are the two key ingredients you need; most everything else is stuff that ranges between "nice to have" and "critical" for operational purposes, but which has absolutely zero impact on your ability to do the install, so we'll ignore it for now. For the DNS-323, I had a few kernel problems (which I'd been warned about by Martin before I started) -- the NIC wasn't initialised with it's MAC address, which meant it was running around my Ethernet screaming "I am 00:00:00:00:00:00! Ph33r m3!", and the SATA controller just didn't seem to exist at all. These were kinda critical to doing an install, so it was time to get hacking to make those work. There were also a couple of parts of d-i that needed tweaking -- the preseeding code didn't support the device, and I needed to package a tool to build a "complete" uploadable firmware image and teach d-i how to use it. Apart from that, though, things were looking pretty good. Make the Debian kernel support your hardware Once you've worked out what hardware you need to make work, you need to dig into the kernel and fix it. Sometimes, if you're really lucky, a kernel version newer than the one currently in Debian has better support for something, and you can backport the fix / feature improvement. Other times, there's something similar already in the kernel for a different device and you can crib off that (I did this extensively for my little fixes). Then there's the "ask an expert" school, where you find someone who knows what they're on about and pick their brain (I did a bit of that, too). Finally, there's plain old "research and development", for which there are piles of documentation already out there. My changes for the DNS-323 came to 121 added lines and 16 deleted lines, most of which was cribbed-and-tweaked from other parts of the kernel. I might have written 10-20 lines of code "from scratch". It's not always scary-hard. Cross-compiling your own kernel One thing that I think needs mentioning in the kernel hacking department is cross-compiling a modified kernel for testing purposes. Chances are your main workstation has a lot more grunt (and build tools) than whatever you're trying to get Debian onto, so cross-compilation is the way to go. You need to first grab a copy of the source you want to build (from apt-get source linux-image-blahdiblah, or a release tarball, or Linus' git repo, it doesn't really matter) and a cross-compilation toolchain. For my cross-compilation toolchain, I just added this to my sources.list:
deb http://www.emdebian.org/debian/ unstable mainthen I ran apt-get update, and installed these packages:
binutils-arm-linux-gnueabi gcc-4.1-arm-linux-gnueabi gcc-4.3-arm-linux-gnueabi-base libc6-dev-armel-crossKudos to the emdebian team for making that such an utterly painless exercise, by the way -- the days of needing to faff round with gcc sources to get a cross-compilation toolchain are apparently over. Once you've got a source tree and a cross-compiler available, you can run any of the usual kernel make commands (like make zImage or make oldconfig), as long as you've got a couple of make variables defined. In my case, I used:
ARCH=arm CROSS_COMPILE=arm-linux-gnueabi-ARCH tells the kernel what architecture to build for (useful in all make commands because not all arches have the same config options in make menuconfig, for example) and CROSS_COMPILE tells the build system what to prefix the calls to gcc, ld and such with (if you installed the same cross-compiler packages as I did, you'll find it installs files like /usr/bin/arm-linux-gnueabi-gcc, so you can ls /usr/bin/*gcc to find out what you'll need for the CROSS_COMPILE setting). Hack d-i to make things work In addition to tweaking the kernel, it's quite possible that the internals of d-i might need some tuning. It's possible that d-i might need to be "taught" to recognise the hardware in your device, or you'll need to extend some aspect of the installation process to complete the installation. In order to hack d-i, you need to know a bit about how it works and how it is structured, so let's run through that first. The entireity of d-i is based around udebs, which are packages of the same format as "real" debs, but which have been built differently (against a small libc, for instance) and have had everything that isn't absolutely necessary (docs, non-essential scripts, extra functionality, etc) stripped out of them to create the smallest possible packages. There are a variety of different udebs -- most are derived from otherwise normal, law-abiding citizens of the archive, like busybox (basic unix utilities like cp and ls), the shell that's used in the installer, parted, various libraries, and so on. Others are "special", and have no big brother in the archive. These are mostly "task" udebs, that define what actually happens in the installer. When they're "installed", they have special fields in the package metadata that define where in the install sequence they go, and they end up on the menu you see if your installation goes a bit pear-shaped. The tricky thing about udebs is that, as small as they are, there's too many of them to be able to have them all available when the system first boots, so even the "setup" of the installation gets done in several stages. First, the kernel and initrd boot. The initrd contains just enough stuff to get access to the rest of the udebs, and nothing else. Even this early stage is built from udebs -- there's lists of what goes into the initrd for various architectures and flavours of installer under installer/build/pkg-list in the d-i SVN. If you need an extra udeb in your initrd, that's the place to specify it. Once the initrd has gotten access to a source of packages (off a CD, over the network, telepathy, whatever) it can drag the rest of the packages it needs from there. Space is still an issue at this point, though -- there's no diskspace yet to put anything onto, so everything needs to fit into a ramdisk. Don't go loading anything you don't need. The packages loaded at this stage are what defines most of the steps that will be done for the rest of the install, so once all those extra udebs are loaded, the remainder of the install kicks off and does it's thing. Different architectures and install methods have different requirements, too, which complicates matters. For example, when you're installing on a regular PC with screen/keyboard, you can guide the install using that. However, if you've got no screen, how can you control the install? There's serial consoles, but requiring everyone to void the warranty (more) on their little embedded doodad by installing a serial console cable to install Debian isn't so hot. So, lacking a terminal, how do you control the install? Well, on install flavours for devices that might be in this situation, you can SSH into the installer and complete it that way. That feature is, like everything else, provided in a udeb -- called network-console, as it happens. But what IP address do you connect to, and what network settings does the device use? Again, without a console you can't configure your network, and not everyone has a DHCP server (and even fewer people have a DHCP server that will hand out an address that they'll know in advance, or be able to find out). So, there's a udeb (called oldsys-preseed) that does it's best to configure your network based on the settings already in the nvram for your device. In short, there's a lot of tricky, well-thought-out shit going on inside d-i, and you might have to deal with a little bit of it. The nice thing is that by now I expect most of the really hard problems have been solved, so with a bit of luck you'll only ever have to do minor tweaking. In general, all of the packages that are "d-i specific" live in packages in the d-i SVN. If you need to modify a udeb, you need to rebuild it and put it in installer/build/localudebs/ (creating it first if need be) and every time you change it, you need to delete installer/build/apt.udeb/cache/. To give a concrete example (from the ever-present DNS-323), I had to modify oldsys-preseed so that it would get the details from the nvram that the stock firmware uses to configure itself. This, in turn, required that the minix-modules udeb be included in the initrd, because the DNS-323's nvram is actually a small minix partition stored in flash. Painfully, this required some more hacking, because the armel d-i kernel wasn't configured to generate minix-modules. That might need some explanation... Since building the kernel is a fairly massive undertaking, CPU-wise, instead of building all the udebs from scratch there's a package called kernel-wedge to split a real linux-image package into lots of little udebs. There's a separate source package for each architecture, linux-kernel-di-$ARCH-2.6, that contains the configuration data for kernel-wedge to specify what udebs need to be built, and what goes into each of them. A small tweak to the armel package and voila! I had a minix-modules udeb to include in the initrd. With the config stuff I'd done in the d-i build itself and my changes to oldsys-preseed, we were done with d-i. Tell d-i how to build your bootable artifacts If your device needs a "different" install image from other similar devices, you need to write some makefile rules to build those files. Look under the installer/build/config/$ARCH/ directory to see the various rules files available. I had to package a new tool to create uploadable firmware images for the DNS-323, along with adding a rule to use that tool to build images. None of it was particularly difficult. Polish the diamond Getting d-i working is only part of the battle; it's quite likely that there will be other hardware in the machine that needs to be supported. This could involve kernel-level stuff to interface to the hardware, or userland tools to manage the hardware. There's several bits in the DNS-323 that still need work; I can't control the LEDs on the front panel, nor the fan, and I can't use the on-board temperature sensors yet. But, I do have Debian running on the thing, which is what I was shooting for. Examples If you're interested in exactly what I did, there are a number of bugs in the BTS that contain the patches I made:
Lenny is the codename for the next release of debian, which will be debian 5.0 formally. For the first time that I can remember, debian will fit on one disk. OK, so it’s a blu-ray disk (BD), but I’m sure it will be a selling point to some people. The announcement goes into some more detail about the implications for data transfer and mirror sizes, as well as noting that it stresses genisoimage beyond breaking point.
Before the release, there’s the small matter of about 200 bugs which we need to fix. If you can help, please do.
One prickly problem in some of the bugs is that a second debian release in a row is looking like it will allow violations of the Debian Free Software Guidelines into the release. (I don’t think all of the listed example bugs are violations, but some are). My main question about the firmware ones remains the same as two years ago:-
“I think the idea that refusing to ship non-free firmware in main will strengthen demand for free firmware is worthy of consideration. Debian helps users to take control of their operating system. Increasing the demand for free firmware might also help users to take control of their hardware, or at least highlight that there’s this crap which their operating system uses to support their hardware but doesn’t have its normal freedoms.” “However, I’m undecided whether it’s a good idea to exclude them from the distribution CDs and so on. How big is the problem of vital hardware which won’t work without firmware being copied to it? Should we split non-free into non-free-hardware and non-free, allowing non-free-hardware packages onto the CDs?”Ben’s technical blog: For those who care about firmware is tracking some of the hardware, but I don’t own any of the untested ones. That’s not surprising: I’ve been trying to avoid closed firmware for a few years now. Debian bug #502959 discusses how one of the key debian project machines is affected. There’s a nice suggestion of using some of the project’s $64,000 to buy some hardware that’s fully supported by free software, but the bug has been closed by Peter Palfrader with the message “go screw yourselves and do something useful, like find a bridge”. Yikes. Is there less vital hardware now than two years ago? Can the patches provided really not be included?
vim and related packages, author of some
popular Vim extensions and of vim-addon-manager)
it's considering switching to Emacs. What is worse is that
I've de facto already switched. May jamessan forgive
me.
OK, that was the hardest part to write, now ...
This choice will have an impact on me: partly because I'm quite
sure several fellow DDs will start making fun of this story
, and partly
because as many geeks I've always had strong opinions on the editor war.
Switching side ain't easy.
Hence, I've decided to write a small (2-3) series of blog posts
on the issue, to future memory. The post you are reading is about
why, since a few months ago, I wasn't willing to give Emacs a
try, and how I've changed my mind.
Why I wasn't willing to give Emacs a try, but then changed my
mind
I love knowing tools which can improve my workflow, no matter
the task. Editors happen to be at the intersection of many tasks,
hence knowing well his own editor and feeling
satisfied about it is quite important. This is even more so
for free software hackers which, for a reason or another, happen to
use the very same editor for a lot of different tasks; in my case:
programming, conf file hacking (i.e., playing the sysadm role),
mail writing, and everything in between.
I've started using vi on Solaris around 1998, then
switched to Vim starting from version 4.0, and then followed all
its releases up to 7.0. I consider my "Vim karma" to be quite hight
and I've delivered several talks about using Vim for LUGs and other
free software-related events. Still, I've always been hit bit
several minor nuisances and glitches of Vim which couldn't be fixed
by simple configuration tuning or add-on implementations (more on
this in a future post).
In the quest for the perfect workflow, those glitches have made
me try several times other editors hoping for more satisfying work
environments. Of course Emacs was one of them, which I've tried
repeatedly during the years; the last time was circa 2006.
For one reason or another, after a few days of experiments, I've
always decided to give up with it. Why? Various reasons, listed
below, together with an explanation of what (I think) has changed
since then.
gnome-terminal wrt my GUI editor I never understood.
Firing up Emacs was like getting back in time of 15 years, and if a
geek having a maximized terminal on most of its workspaces had this
feeling, then something was really wrong.
This has changed: starting again from Emacs 22.1, the editor has
frown support for that "bleeding edge" technology called GTK+.
Finally you can use Pango font faces and avoid the time travel
feeling when switching from a terminal to your GUI.
release early, release often...). The second argument is the bug tracking system: there was none, bug discussions happened only on the development mailing list and the bug tracker was a text file on CVS! (Yes, Vim doesn't have a proper BTS either, but I was looking for reasons to switch from it and hence looking for something better in several respects.) That has changed completely, as I discovered only at this year DebConf thanks to gismo. 2007 has enjoyed 1 Emacs release and 2008 already two. They do have a BTS now and guess what? is dear old debbugs. According to my first experiences as Emacs bug reported the maintainers are very reactive and also friendly in dealing with bug reporters. Finally, also keeping up with snapshot releases in Debian is entirely trivial, thanks to Romain's repository.
Emacs is a nice operating system, but lacks a good editor, or something such. In the past I had the impression that starting Emacs was really slow and that generally the memory footprint was too high to be acceptable. You know what: starting a full-blown
gvim with a good deals of add-ons (and I used quite a
lot of them, that's why vim-addon-manager
was born) is not that faster. And on the contrary, firing up an
emacsclient
is way faster than starting up a new gvim
instance.
Regarding memory consumption Emacs is still "gaining" the
battle. Still, one has to keep in mind the different workflow: with
Vim you are encouraged to enter and exit the editor (not without
drawbacks, as I'll discuss in a future post), while with Emacs you
always use the same one. It turns out that via
emacsclient the resulting feeling is the same as
having multiple editors (as you can fire them up as separate
windows or in separate consoles), still sharing all user
memory.
A final comment on memory consumption while looking at my
top sorted by decreasing RSS memory: the top process
is xulrunner (from the browser) with 356Mb, then Xorg (159M),
pidgin (128Mb !!!!), trackerd, gnome-terminal, gnome-panel, ...,
Emacs shows up with 51 Mb at the 7th position. Yes, it is not the
thinnest editor in the world, but on average machine it doesn't
really matter at all.
Ok, it's not that bad. But according to LWN (Subscriber-only content at this time, Debian developers can get a free account, though), there is a possibility that the OpenStreetMap data set will be relicensed (from CC-attribution-sharealike) and that the new license will be contract based, which would mean at least a click-through license. There is, thankfully, also a group of people who think that BSD or even Public Domain-style licensing would be better. Personally, I think the latter is very much preferrable; OSM has (I think, and hope that's not too optimistic) become big enough that it should be able to out-gun every vendor trying to take away OSM's work: the vendor with his few people will just not be able to keep up with the sheer number of OSM contributors.
Joerg Jaspert has posted a proposal to add some new types of contributor status to the Debian project. I like it. Clint Adams on the other hand is not a fan
Here's why I think it is a good idea. For some time, I have been involved in trying to get people involved in Debian particulary, but not exclusively, Indians. One thing I have heard over and over again is that getting involved is too overwhelming. Obviously there are some people who are motivated enough to deal with all the hurdles but there are others who could contribute something but lack the time or inclination to go through the whole New Maintainer process. Some kind of lesser privileged status with would enable them to participate with less responsibilities. And, it must be acknowledged, with less rights, but this type of person would not care about being able to vote or login to project servers. It can be argued that they can already do this via alioth or sponsorship but this proposal formally acknowledges that they are part of the Debian team. Being on the inside may in time give wallflowers the impetus to get more involved and eventually seek full developer status.
We already have this in part with the Debian Maintainer appellation which seems to be working well, this proposal just extends the idea a little bit.
One thing which was not made clear was if the proposal is a fait accompli or if there will be a GR about it. I think there ought to be one to give skeptics a chance to really prod and poke this thing or we will end up with another morass of recrimination and backbiting like what happened with dunc-tank.
If you impede me doing something I want to do, you are an asshole.So now we can still upload (except when a bribe-loving ftpmaster is being petty or when the release team is expediting a transition) and we can still vote, and we can log into a machine or two. We're running low on powers to take away. Maybe we could create an even lower class of citizen, some kind of undermaintainer without any voting rights. Whee. DM was born. Instead of fixing the problems of class inequality, we created another class. Fantastic. Why stop there? Why not create more? Clearly nobody wants to work toward an egalitarian culture, so we might as well make it like a game where you can hop from level to level. Then you can go to society parties and brag that you are a DVMRP-Q White Belt Green Stripe with a concentration in Taiwanese Bug Reporting, and that after a 6-month wait you can make a lateral move to second-chair cantor of Der Process under the wavy waves. As always, making the constructive suggestion to take things in the exact opposite direction will be called out as unconstructive.
CableCARD devices have generally supported only one-way access to cable systems, but their long, winding journey toward full two-way communications is finally coming to an end. Panasonic has announced that it is at last shipping new HDTVs enabled with tru2way technology to the two US markets where they can actually be used.So what’s the main thing you’re supposed to get with tru2way?
This means that you can walk out of a retail store with a tru2way-enabled HDTV, plug it in at home, and have immediate access to basic features like an on-screen guide and on-demand content.In other words, we are just now starting to see HDTVs that can just plug into the cable jack and work, without an add-on cable box and all the limitations that implies, right? Well, not really.
All tru2way-compatible devices will have a CableCARD slot built into them to facilitate the decryption of protected content, though details are still sketchy as to how this system will work with devices like PVRs. Physical CableCARDs will apparently not be needed to access basic two-way services and non-encrypted channels.Meaning that, in order to get anything you can’t get already with broadcast TV (”non-encrypted”), you still need a cable company tech to come out and install the CableCARD. And they don’t know how all of this will integrate with the new video recorders like TiVo. Why is this so hard? It’s producer paranoia. If they don’t play these games, you might watch some show for free, or share it so others can watch it for free, instead of… well, watching it for free live. And you might cut the commercials out, instead of… cutting the commercials out by getting up for more chips during the commercial breaks. (But that’s stealing, so you shouldn’t do that either.) Our family keeps edging closer to deciding to get a HDTV. But then I see stuff like this, and notice that the old tube TV still works fine…
Next.