An interesting class of links are those embedded in a document without being marked up as a hyperlink. You can find them in places like news stories -- traditional media almost never hyperlinks urls that people say. They are also not uncommon in books, especially recent fiction. And also in audio and video.
These dark links are interesting partly because while they're not hyperlinks now, they could become hyperlinks in the future. For example, a book is converted to an ebook, and the ebook is read on a reader that automatically hyperlinks. It could happen with transcripted speech as well.
They're also interesting because some people will manually follow them in the present. And because the intent of the person who put the dark link in is often different than the usual intent of using a hyperlink. Some authors use dark links as a "rabbithole" leading to an Alternate reality game. Others make up a link that fits the context, without, apparently, worrying much about what's there in real life.
Grepping through piles of ebooks to find dark links, and domain squatting on them is one of those business models I have filed away in case I ever go bad. But it's probably being tried by others anyway. Although I have seen some dark links lately whose domain was not yet registered.
An early draft of RFC 2606 included reserved top level domains for ficticious domain names, including ".nil", ".xy", and ".tld", but that did not survive into the final RFC, which only provides "example.*". (".xy" is still probably a safe choice for fictional domains, since as the draft notes, that code will never be assigned to a country.)
The first thing I searched for in Google, back in 1999, was probably "linux", followed by my name.
The last thing I searched for in Google, on a snowy day in 2009, was "vdash".
With the decade over, and Google rolling out all manner of tracking cookies and javascript, it's time to move on. Just keeping on top of the torrent of privacy-affecting changes Google is making, and trying to parse the real meaning in the chirpy googlespeak announcements has become more work than the value their search engine adds. (This was the last straw.)
At least for now, I'll be using Duck Duck Go for search. It's small, quirky, has features the big competition lacks, and works well enough for my mostly moderate and occasionally intense needs. Sorta like Google in 1999.
Today is a nice milestone. For the first time my server is "in the cloud", and yet I have full control over the kernel it is running.
While it should be possible to do this with Xen, I never found a host who would. So for the three years since I got rid of colocated physical hardware, I was constantly nagging my Xen hosters to update their kernels, often to fix security issues. And I sometimes struggled with things like udev that needed a newer kernel. Most importantly it just didn't feel right for "my" server to not run my kernel. Even though in this modern day, "my" server is just a fever dream of bigger computer. I'm infected with the Sovereign Computing meme.
KVM probably makes this easier than does Xen. What Steve has set up at kvm-hosting.org is a great example and template for providing a small group with great hosting at a very fair price, with full control, and an excellent interface.
It's the little things, like being able to view the my neighboring
guests' virtial machines in top, that I really like.
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 2841 joey 20 0 1637m 1.0g 3152 S 7 13.2 48:27.20 kvm 6606 steve 20 0 1365m 1.0g 3540 S 2 13.2 9:29.52 kvm 2888 cernio 20 0 1269m 284m 3152 R 1 3.6 4:08.57 kvm 2800 ore2 20 0 754m 521m 3152 S 0 6.6 4:35.68 kvm
This all feels sorta science fictional when I step back and look at it.
notes for kernel setup on kvm-hosting.org
I want to be able to install regular Debian kernel packages. In these
packages, the virtio drivers are modules, and need to be manually added to
an initrd. So first edit /etc/initramfs-tools/modules and add the below
to it, then run update-initramfs -k all -u to rebuild the initrd. BTW,
some of these modules may not really be necessary.
virtio_blk virtio_console virtio_pci virtio_net virtio_balloon virtio-rng
Then edit /etc/kernel-img.conf to configure the kernels to add
a symlink to the latest version in /boot. This way, kvm-shell can be
configured to boot the latest kernel automatically.
do_symlinks = yes link_in_boot = yes
And here is a hook that rsyncs /boot, sending kernels and initrds to
kvm-hosting, so its interface will let me boot them. This was put in
/etc/initramfs-tools/hooks/kvmhostingrsync and made executable.
#!/bin/sh # Use --copy-links so the symlinks to the current # kernel and initrd are selectable in kvm-shell. # # Use --delete because I like living dangerously. :) rsync --copy-links --delete -vazr /boot/ kernels.kvm-hosting.net::joey-kernels/
Just a quick followup to my last post. A commenter told me that linode supports user-supplied kernels via pv-grub. So I am moving another server of mine from slicehost to there, and it's happily running Debian unstable's kernel. Linode has come a long way from its early days of flakey UML hosting.
I've been watching some good films recently. Two I especially liked.
Goodbye Solo starts in Winston-Salem and ends up at Blowing Rock. Both settings, as well as the taxi in between, are very familiar. The characters could easily be people I've met.
Tulpan is set in a steppe in Kazakhstan. The desert and dust devils mostly reminded me of Mars. Particularly of this amazing shot taken by the Spirit rover.
Still, I felt so much more at home in Tulpan. Kept pausing it to check out how the family had their yurt set up and furnished, and watched their very real-seeming life unfold, right down to the lambing scene. While Solo took the very familiar, and confounded expectations and biases at every step.
They're both fine films, from directors I want to see more of. I've seen Ramin Bahrani's work before Solo, and especially liked Man Push Cart. Don't know if I will ever find any of Sergei Dvortsevoy's earlier films.
As distributors we should not discourage upstreams that wish to generate binary packages themselves, rather we should cooperate with them, and ideally they will end up maintaining their stable release packages in our distributions.
I agree. Robert goes on to talk about the tendancy Debian (and apparently
also Ubuntu) have to dislike upstream providing a debian directory.
Funny thing is that we also like to say team maintenance is a good idea. An
upstream who is doing packaging work is a readymade half of a team; if you
write them telling them to rm -rf debian, you are turning away a team
member. With a slap in the face. Worse, it's a team member who has
demonstrated that they are capable of working in far more complex systems
than a debian directory, since they wrote/maintain the software itself.
BTW, for those who are skeptical of teams, on the basis that they dilute responsibility: A team consisting of an upstream developer and a distribution maintainer is inherently the more healthy sort of team, where each member has a well-defined area of expertise, but can also venture outside their area when needed.
When I packaged FBReader for Debian, upstream already had their own packaging, and I worked with them to fix problems with it and make it something I could be happy maintaining. This was sometimes tricky, since upstream was also maintaining packages for maemo. Sometimes the tools were not ideal. It was still worth it.
On the other side of the coin, d-i is an upstream for several
distributions. If they told us we needed to rm -rf debian, we'd not have
a lot of d-i left.
tools
I also agree with Robert that most of the trouble comes down to problems with tools. BTW, RPM does not have these problems, and in that world it's typical for upstream to provide a spec file.
Much of the problem comes down to the crummyness of dpkg's source format,
which cannot rename files, delete files, etc. That the source format
directs us to 1970's source management (ie, tarballs and patches), instead of
21st century source management (ie, DVCS), doesn't help either.
dpkg's 3.0 quilt source format tries to address the issue by removing any
debian directory in upstream's tarball. I am not sure that this is at all
the right approach; it makes it harder, not easier to work with upstream as
a team.
A better approach might be to consider anything that hardcodes the debian
directory as having a bug. If upstream can easily package debs using a deb,
or maemo, or ubuntu directory, you sidestep any potential conflict while
still being able to work with them via a symlink.
To put my time where my mouth is: Anytime debhelper prevents working
with an upstream who wants to ship a debian directory; that is a bug. I
will fix them. (Note that debhelper already provides a --ignore that can
be used if upstream has provided a dehelper control file that you can't
delete and don't want used.)
Previously: Look who's packaging
After the arrival of family, and the big snow, and the digging out, the gathering at the farm was dimished from its usual numbers. Without power, the house was lit by kerosine lanterns, candles, and the fireplace, and this felt very right for a solstice celebration. Musicians played old tunes in the sitting room (with the youngest kids adding percussion), while others nibbled on turkey (from the field next door) and stuffed grape leaves (from Turkey). Later, the cracks of overloaded trees echoed through the valley as the bonfire blazed high and bright through the night.
 |
Today, standing in the middle of a creek with snow still on its banks, meltwater lapping above my knees, barefoot, in my underwear, and using a tree trunk for support as I hauled across a big backpack and a sack full of Mediteranean food (and pants); I wondered for a minute if I knew what I was doing here.
But I think Anna enjoyed Santa's late (and pantsless) arrival to her snowed in farm, which has been without power for over a week. And I knew she needed the dutch oven I brought, to expand what she can cook in the wood stove. Also, Agricola turns out to be a fun game for winter on the farm.
I also briefly wondered what I was doing here as I coaxed a fire out of the damp and tiny stove in my yurt, almost running out of kindling. It's going to be a chilly night here anyway, but being here with just the light of the fire and my laptop, listening to the melting snow gently dripping down the sides, is a special experience in a day rather full of them.