Wandering Thoughts archives

2021-12-19

My Firefox bookmarklet to see links I've visited more reliably

I want to make links that I've already visited be clearly visible in Firefox, so that I can avoid re-reading links that I've already read. My first solution to this was to use the Firefox Stylus addon to write a brute force rule for frequently visited sites, which forced the a:visited colour to the special 'VisitedText' colour that Firefox provides. Later, when I wrote about bookmarklets versus addons, it occurred to me that a bookmarklet was a great use for this in general; I don't always need it and don't necessarily want it, but a bookmarklet would let me try to fix sites with a click and then said I didn't know enough to write it. In a comment on that entry, seth shared a bookmarklet to do a large scale restyling. I took that and turned it into a simpler version that duplicated my Stylus effort.

My current 'v' bookmarklet (it has a short name to take up as little space as possible in my tab bar) is:

javascript:(function(){
   var css=document.createElement('style');
   document.head.appendChild(css);
   css.innerHTML='a:visited {color: VisitedText !important;}';
})();

Well, it is that with some indentation stripped out and run through the Vim operation ':%s/\(\n\| \)\+/%20/g', from seth's comment.

I was going to say that you could do a version of seth's full bookmarklet with using Firefox's system colours to get your browser's default colours, but it turns out that this isn't quite as simple as it looks because the normal web page foreground and background colours don't seem to be available unless you go for Firefox specific CSS colour names. I think you would want something like this:

javascript:(function(){
   var css=document.createElement('style');
   document.head.appendChild(css);
   css.innerHTML='
      * {background: -moz-default-background-color !important;
         color: -moz-default-color !important; }
      :link, :link * {color: LinkText !important;}
      :visited, :visited * {color: VisitedText !important;}';
})();

Right now I don't feel like I want to go this far often enough to have this bookmarklet in my tab bar. Partly this is because websites that have terrible colours often have other design and layout flaws, so I'm most likely going to reach for 'View in no style' or Firefox's Reader mode. Well, after I try one brute force solution. But fortunately, completely terrible colours are uncommon, perhaps because they're so obvious, far more so than other sorts of unreadable design (like tiny fonts).

web/SeeingVisitedLinksBookmarklet written at 23:29:27; Add Comment

Some brief notes for myself on growing a LVM root filesystem

I have a Fedora virtual machine image that I use to try out Fedora upgrades before I have to do them on my real system. Because it was created a long time ago, it had only a 20 GB disk. For a long time this was okay, but when I went to upgrade it from Fedora 34 to Fedora 35, the upgrade failed with an out of space error. Obviously the time had come to enlarge the disk and grow everything.

Growing the disk image depends on your virtualization system and in any case is usually pretty simple and obvious; that took me no time at all. First, you need to change the disk partitioning so that the LVM partition is expanded to cover the new disk space. Unfortunately, fdisk doesn't seem to directly support doing this. Some directions I found online suggested using fdisk to delete and recreate the partition, but I thought that was too alarming so I tried out GNU parted instead, because parted has a 'resizepart' operation. The magic unit to use in resizepart to make it use up all of the new free space is '-1s', which means 'the last sector of the disk'. It turns out that parted is more dangerous than I expected, because unlike software like fdisk, parted writes your changes to disk immediately. If I ever have to do this to real disks that I cannot take virtual machine snapshots of and roll back to if something goes wrong, I will use a different program.

(However, this is not a common thing to need to do on real disks. With real disks, you usually get a new disk and make a new partition table on it that has the right size from the start.)

With the partition resized (and the VM rebooted to get it to be fully recognized by the kernel), I needed to grow the LVM volume and the filesystem. This is a two step process. First, expand the LVM (physical) volume:

pvresize /dev/sda1

Second, grow the LVM partition to use all the space, and tell it to have ext4 resize things as well while we're here:

lvextend -l +100%FREE -r .../root

The -r asks LVM to also resize the filesystem for you. Using -l and its argument is a specific incantation for 'add 100% of the free space'. The format of this argument is not clearly explained in the lvextend manpage, nor is the fact that it only works with -l (which specifies how much to grow in terms of extents) and not -L (which specifies how much to grow in more normal units). Since I normally use -L, this was puzzling and annoying; I spent a bit of time flailing around and thinking that I had the syntax wrong somehow.

(I'm sure I'll need to do this to other virtual machine images in the future, and I will feel really silly at myself if I don't write this down now.)

PS: If your LVM or root partition is not the last partition on your virtual disk, you have a big problem that is well beyond the scope of this entry. I suggest making a new virtual disk and copying things over somehow.

linux/GrowingLVMRoot written at 02:34:42; Add Comment


Page tools: See As Normal.
Search:
Login: Password:
Atom Syndication: Recent Pages, Recent Comments.

This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.