Browsed by
Author: kepstin

Survey of terminal palettes: DIR_COLORS edition

Survey of terminal palettes: DIR_COLORS edition

A quick run through of how various GNOME terminal palettes look like with the 8-color+bold DIR_COLORS file shipped with coreutils and used by many Linux distributions.

Tango is a fairly light value but low saturation palette. The light background is an odd off-white shade that reduces contrast. When the “Show bold text in bright colors” option is enabled, bright cyan and bright green over the light background have minimal contrast. When using a dark background, the palette gives reasonable results, but the highly saturated red as used in archive files is problematic.

The contrast of blue over green used in the “other_writable” directory is very low.

Disabling the bright-is-bold option improves the contrast in light mode, but in dark mode the dark red, blue, and purple colours are now too close to the background color.

XTerm and Rxvt palettes are very similar; the main difference is that Xterm has a lighter, lower saturation bright blue. A real VGA console does not support bold text at all.

The Xterm palette suffers from bright cyan and green being nearly unreadable on the white background. The VGA palette is quite good, it appears that the default DIR_COLORS may have been optimized for the VGA palette specifically. The fifo is a bit low contrast due to the dark orange/brown shade, and the bright blue for directories is still a bit low contrast against the black background.

The current revision of the new GNOME palette is a compromise between the Tango and Xterm palettes. The lighter background colour in light mode improves contrast over Tango, while disabling the bold-is-bright option means the green is ok, and the cyan is, well, still not great. Contrast for the blue-on-green used for “other writable” directories is improved over Tango.

Dark mode with the new palette suffers a bit. Despite using a darker background than Tango, the dark red and blue colours remain very low contrast. The dark purple is a bit better than Tango. Enabling the “Show bold text in bright colors” option works around these issues.

Proposed modifications to DIR_COLORS

When used with the stock 8-colors + bold DIR_COLORS file that many Linux distributions use (and is shipped with coreutils), the new GNOME palette has better contrast than Tango in the light mode. The dark mode is about the same.

To improve dark mode in GNOME terminal with the “Show bold text in bright colors” option disabled, distributions should modify the DIR_COLORS file to use 16-colour terminal escapes to explicitly select the bright colors rather than relying on bold colors being shown as bright. I recommend making the following changes:

Replace the values “31”, “34”, “35”, and “37” with the values “91”, “94”, “95”, and “97” in all locations except OTHER_WRITABLE. This change causes the bright versions of Red, Blue, Purple, and White to be used as foreground colors.

The CAPABILITY, STICKY_OTHER_WRITABLE, and OTHER_WRITABLE file types use a dark foreground color. To improve contrast, a brighter background color can be selected: change “41” and “42” to “101” and “102” on these entries.

The FIFO and DEVICE types explicitly set a dark background, so using bright foreground helps improve contrast: change “33” to “93” on both entries.

CAPABILITY is pretty terrible in all colour palettes. Changing the background to purple rather than red allows it to have a white foreground, like SETUID. Use “97;45”

The result looks like this:

The brighter blue, red, and purple remain readable on a light background, and improve contrast on the dark background.

WCAG results for the new GNOME palette

These results assume the DIR_COLORS contrast improvements have been applied. Note that for places where bold text is used, I’m using the “Large text” contrast guidelines if the colors failed the normal text check. Spots where this was done are marked.

File TypeColoursWCAG (Light background)WCAG (Dark background)
NormalNo color codeAAAAAA
DirectoryBold Bright BlueAAAA (Large text)
LinkBold Dim CyanFailAA
FifoBright Yellow over Dim BlackAAAAAA
SocketBold Bright PurpleAA (Large Text)AA (Large text)
DeviceBold Bright Yellow over Dim Black AAAAAA
OrphanBold Bright Red over Dim BlackAA (Large text)AA (Large text)
MissingBold Bright White over Dim RedAAAA
SETUIDBright White over Dim RedAAAA
SETGIDBlack over Dim YellowAAAA
CapabilityBright White over Dim PurpleAAAA
Sticky, Other writableDim Black over Bright GreenAAAAAA
Other writableDim Blue over Bright GreenFailFail
StickyBright White over Dim BlueAAAAAA
ExecutableBold Dim GreenAA (Large text)AA
ArchiveBold Bright RedAA (Large text)AA (Large text)
ImageBold Bright PurpleAA (Large text)AA (Large text)
MediaBold Dim CyanFailAA

I don’t think there’s much room to improve this more without using separate DIR_COLORS configurations for dark vs. light backgrounds. Changing the palette to reduce the brightness of Dim Cyan would improve the contrast of some file types with a light background, but it would hurt other applications that rely on Dim Cyan being readable over a Dim Blue background.

Thoughts on OpenWRT and OSTree

Thoughts on OpenWRT and OSTree

In theory, OpenWRT should work reasonably well with OSTree – it’s already designed to be run with an immutable base layer (for squashfs images).

In terms of adapting OpenWRT to run on OSTree, the hardest thing I can think of would be working out how to do the bootloader on embedded devices. I don’t know enough about this space to know what has to be done here. OSTree currently works by putting kernel images and BootLoaderSpec config files into a boot directory, swapping symlinks to switch between them. It can then run extra code to transform that config to a different format, e.g. Fedora Silverblue generates GRUB2 configuration. This last configuration transformation step is the only potentially non-atomic part of the update.

Other than that, some changes needed would be boot script integration for mounting the OSTree root (an overlay fs is not used, since /etc is writable), filesystem layout adjustments (/usr merge, and a wrapper for opkg (opkg-ostree?) that does package installs via an OSTree layer, similar to how rpm-ostree works on Fedora Silverblue.

Much of the existing system upgrade tooling would no longer be needed, since OSTree already preserves /etc (and would preserve /var if it was a real directory rather than symlink to /tmp) during upgrades. The process would be to download the new base image, rebuild the opkg-ostree layer with locally-installed packages, and reboot.

That said, OSTree also requires better storage than is present in many of the older embedded devices that OpenWRT supports – you need enough space for multiple images (albeit common files are shared with hardlinks), and all of the updates are done at the file level, so it has to handle a fair amount of small file writes properly. I run OpenWRT on an x86-64 box with a modern SATA SSD, which would have no issue. It looks like many newer router/ap platforms support eMMC flash, which should work well (maybe use F2FS filesystem).

Ryzen Motherboard ECC Memory Summary

Ryzen Motherboard ECC Memory Summary

Update (2017-06-22): After looking at the poor state of ECC support for a while, I ended up picking up an MSI B350 TOMAHAWK board, which does not support ECC. A variety of factors contributed to this, not the least of which that it had PCI ports legacy hardware support. The end result? I’m no longer actively researching ECC support on Ryzen boards, so this list is probably going to steadily go out of date. Please feel free to contact me if you have updates!


This is just a list tracking what is known about which AM4 motherboards currently on the market support running with ECC memory.

If you see (or have tested) anything not on my list, please drop a comment and let me know about it so I can update.

Overview by Brand

ASRock

So far, all ASRock B350 and X370 boards have the following text in the spec sheets:

– AMD Ryzen series CPUs support DDR4 3200+(OC)/2933(OC)/2667/2400/2133 ECC & non-ECC, un-buffered memory

Additionally, there’s been confirmation from ASRock that the X370 boards have working ECC. An ASRock support rep. says that all AM4 boards support ECC (But a commenter notes that the relevant options are missing in some bios versions). So it’ll probably work! When I find confirmation for specific boards, I’ll add it to my detailed list.

ASUS

Many of the ASUS X370 and B350 boards are currently listed with support for ECC memory (e.g. from the PRIME B350-PLUS):

4 x DIMM, Max. 64GB, DDR4 3200(O.C.)/2933(O.C.)/2666/2400/2133 MHz ECC and non-ECC, Un-buffered Memory

but the “ECC” part of that has gone and come again over different revisions of the spec page. Some reports say that you may need an updated bios on some boards.

Some ASUS boards have been confirmed to work, both by AMD techs directly and by user testing. Details in the table below where known.

Biostar

On product pages for all B350 and X370 boards, they list

Support Non-ECC & ECC Un-buffered DIMM Memory modules

I’m still looking for confirmation on whether ECC memory is functional, but it’s a good start.

Gigabyte

On their spec comparison page, Gigabyte says that for their X370 boards:

Support for ECC Un-buffered DIMM 1Rx8/2Rx8 memory modules

but on the B350 boards:

Support for ECC Un-buffered DIMM 1Rx8/2Rx8 memory modules (operate in non-ECC mode)

which is pretty disappointing. It’s not clear exactly what “operate in non-ECC mode” even means (no EDAC?). I haven’t seen any tests yet to confirm either way.

MSI

There’s no mention of ECC in the specs list for any of the MSI boards. Status TBD, but I’m not optimistic.

Table of Infos

To get the “Works” status, I look for a review or test where someone has induced memory errors e.g. using Rowhammer, and has seen reports of corrected memory errors in the OS logs.

Board Chipset Form Factor ECC Status
ASUS PRIME X370-PRO X370 ATX Confirmed, Works
ASRock X370 Taichi X370 ATX Mostly works (no UE halt)
Gigabyte GA-AX370-Gaming 5 X370 ATX Probably Works
Scanning CDs with CCD/LED scanners

Scanning CDs with CCD/LED scanners

So, back on my recommended scanners post, I made a note that CCD sensor scanners that use LED lighting – which at this point is basically all of them – have an issue with scanning CDs. It looks like this: A CD scanned with a CCD/LED scanner has an annoying complex rainbow pattern This is, frankly, quite awful. It’s hard to read anything with the light pattern that appears, and it doesn’t look anything like the classic highlight that you see when holding a CD under a single light source, or on a CCFL-lit scanner. But I’ve finally found a solution!

One of the releases I picked up recently had its CDs in little translucent plastic sleeves. If I scanned the CD through the sleeve, rather than directly on the scanner bed, the rainbow pattern completely disappeared! It turned out that the frosted sleeve diffused the light enough to give a clean scan. Unfortunately, the sleeves that came with that release were too wrinkled to get good results, so I had to go look for alternate materials.

Read More Read More

Recommended Scanners for Album Art Scanning

Recommended Scanners for Album Art Scanning

Here’s a quick list of currently available scanner models that I recommend for people doing album art scanning.

The Criteria

I’m not covering scanning 12″ vinyl in this guide. For that, you need a large format scanner, which is a completely different price category of professional equipment – or use a camera and a glare-free lighting rig instead.

There are two basic kinds of scanners currently available, distinguished by the type of image sensor: CCD and CIS (Contact Image Sensor). The difference is that CCD sensors have a much larger depth of field. This is important in particular if you’re scanning digipak cases – with a CCD sensor, you can scan right through the tray without disassembling the case. It also improves the quality when scanning exterior of boxes or thick booklets that don’t lay completely flat. CIS sensors can only get a sharp image if the thing being scanned is perfectly flat against the glass surface.

The scanner must be able to do 600dpi scanning (non-interpolated). This is pretty much a given at this point, of course, since even the cheapest current model scanner can usually pull off 1200dpi or higher. But keep this in mind when looking for used or older model scanners.

The scanner must be a direct-connection USB device. Many network scanners and all-in-one devices apply compression and pre-filtering that often can’t be disabled; this reduces the effectiveness of later descreening steps. Scanners marketed as “Photo” scanners are usually good at preserving fine detail without compression artifacts.

Read More Read More

Spring 2015

Spring 2015

This is the big one. The one you’ve all been waiting for. This is the hype season.

(I didn’t post the stuff from last season, but, uh, I guess Parasyte, Your Lie in April, Cute High Earth Defense Club LOVE! all made the list, and I’m now catching up on Log Horizon.)

Maximum Hype

  • Fate/stay night Unlimited BudgetBlade Works. If you haven’t already seen the first season, you do not deserve to be reading this list.
  • Nisekoi (continued).
  • The Disappearance of Nagato Yuki-chan. The “alternate universe” style refocused anime based on a spin-off manga story. I may just own all the official English manga, and be a big Haruhi fan besides. It’s interesting that KyoAni turned this down; it’ll be animated by Satelight.
  • Ghost in the Shell: Arise (TV Anime). Not much detail, but the hype is real. GiTS makes a return to TV, but will it be SaC good?
  • Hello! Kin-iro Mosaic. More silly Engrish in this sequel. Ridiculous cute guaranteed.

Could probably use more hype than it has

  • Plastic Memories. Sci-fi story involving the collection and disposal of end-of-life androids. Has potential to be a touching story if pulled off well. If not, it’s off to the moe android junkyard.

Some Hype

  • Hibike! Euphonium. Reason: KyoAni.
  • Ninja Slayer. Reason: Trigger. But I dunno if I’ll keep up, it doesn’t seem like my fav. genre based on key art.
  • Magical Girl Lyrical Nanoha ViVid. It’s been ages since the first two Magical Girl Lyrical Nanoha series, and Strikers was such a let down. Will this new refocused anime based on an spin-off manga story pick the series back up again?
  • More Gintama. To be honest, I haven’t actually seen anything but bits and pieces of the series, but it seems like I could probably pick it up now without too much issue. Maybe catch up later

Anti-hype

I’m sure there are people who were looking forwards to them. But they’re not me.

  • Digimon Adventures. I’m sure there are lots of people who will watch and enjoy this. But I’m probably not gonna watch it, and therefore will never know whether I would have enjoyed it.
  • Battle Spirits Burning Soul. Not another trading card game anime.
  • Takamiya Nasuno Desu!. I’m not sure how they’re making another season of Teekyuu, let alone this spin-off series. Although… I’m not really one to say: I watched the entire Teekyuu series on Crunchyroll.

You’re probably hyped about different things than me. That’s too bad, but feel free to let me know what they might be…

Thanks to the Neregate Anime Chart, Anime News Network, and Crunchyroll for references.

New image-id release 2.1.0

New image-id release 2.1.0

This release switches the build system to gnu autotools, allowing me to add some logic so you can build against either libmirage 2.1 or 3.0! (Older versions of libmirage are not supported)

You now use the standard invocation ./configure && make to build the package, and there is a working make install as well.

Download from the Github release page.