Hello there, inquisitive friend! I’m pleased to announce the newest Links As A Service offering. It’s called inks which is like links, but without the L for loser. Basically Reddit or Hacker News, but without the disagreeable trolls and military industrial complex shills downvoting everything to hide the truth.
Some newer laptops adjust the screen brightness according to ambient light in the room. This is fairly annoying in most cases, because what I really care about is the relative brightness of the screen contents. White web pages are too bright in a dark room. Fortunately, there’s a tool, Lumen, which can adjust the backlight based on actual brightness. Unfortunately, it’s for somebody else’s computer.
In order to write xautobacklight we need to do about three things. We need to measure the screen brightness (and consequently detect changes). We need to adjust the backlight to a comfortable level. And, as a bonus, we need to fiddle with the contrast.
Continue reading xautobacklight...
The recent fuss about f.lux on iPhone made me take another look at desktop solutions for shifting the screen’s color temperature. f.lux is only available as a linux binary, but there’s a program called redshift that may work.
Let’s try installing redshift package, on my regular desktop machine with other desktop like software on it.
Continue reading sct - set color temperature...
The NSA has a secret project that can redirect web browsers to sites containing more sophisticated exploits called QUANTUM INSERT. (Do I still need to say allegedly?) It works by injecting packets into the TCP stream, though overwriting the stream may be a more accurate description. Refer to Deep dive into QUANTUM INSERT for more details. At the end of that post, there’s links to some code that can help one detect QI attacks in the wild. As noted by Wired and Bruce Schneier, among dozens of others, now we can defend ourselves against this attack (well, at least detect it).
Continue reading on the detection of quantum insert...
Three days of the doas.
I started working on doas quite some time ago after some personal issues with the default sudo config. The “safe environment” was under constant revision and I regularly found myself unable to run pkg_add or build a flavored port or whatever because the expected variables were being excised from the environment. If I had been paying attention, keeping sudoers up to date probably would not have been such an ordeal, but I don’t like change.
The core of the problem was really that some people like to use sudo to build elaborate sysadmin infrastructures with highly refined sets of permissions and checks and balances. Some people (me) like to use sudo to get a root shell without remembering two passwords. And so there was considerable tension trying to ship a default config that would mostly work with the second group, but not be too permissive for the first group.
Continue reading doas - dedicated openbsd application subexecutor...
Since the dawn of time, the OpenBSD buffer cache replacement algorithm has been LRU. It’s not always ideal, but it often comes close enough and it’s simple enough to implement that it’s remained the tried and true classic for a long time. I just changed the algorithm to one modelled somewhat after the 2Q algorithm by Johnson and Shasha. (PDF)
LRU is simple enough it doesn’t require much explanation. Keep a list of all buffers. Whenever you use one, put it on the front of the list. Whenever you need a new (recycled) buffer, take it from the end of the list. Those are the oldest, least recently used buffers. In high level terms, the current working set is at the front of the list and the previous working set is fading away off the end. It’s responsive to changes in the working set, very quickly replacing old unused buffers with the latest. In other words, it has a short history; it’s not “sticky”.
Continue reading 2Q buffer cache algorithm...
One of the obvious ideas I (and several others had) as soon as signify was released was to extend it to do more. After all, no program is complete until it can read email. Or at least munge up your email real bad.
Enter reop - reasonable expectation of privacy.
The current version of the source README is likely more up to date than this post.
With some curiosity I read Creating the perfect GPG keypair. My conclusion is that there’s no such thing has a perfect GPG key pair. And we wonder why people leak secrets using hotmail. This shouldn’t be hard. I had my own rant about GPG here, but I think others have explained the situation better. What’s the matter with PGP? and GPG And Me are two places to start.
Continue reading reop - reasonable expectation of privacy...
Despite my reservations about two factor auth, I decided to try implementing it. Don’t knock it til you’ve done it, right? I’ve previously played with Duo Security’s login_duo, and they have a nicely polished mobile app, but the command line tool doesn’t quite feel integrated with the rest of the system (it’s user opt-in, not admin mandated). Plus, it’s more fun to build your own. For this experiment, I picked Pushover as factor number two, which also comes with a nice app which can be used for other things as well. Now we just need some code to talk to Pushover.
Pushover is a web hook to smartphone push notification gateway. POST to a web server and it sends a message to your phone. Sounds perfect. We just need some plumbing to get from login to Pushover. After about five seconds of investigation, I realized that sending a challenge token to Pushover involves making an HTTPS request. After a further three seconds of thought, I realized I didn’t want to write the C code to make that happen. Perfect time to use Go. Just one problem. Go reserves a buttload of memory (address space) when it starts, even if it won’t ever use it, and bumps into the default resource limits. Back to C.
Continue reading login_pushover - two factor auth with pushover...
One of the things OpenBSD has never done is sign releases, for whatever reasons. But 2014 is a new year, time to make a change. The first thing you need to start signing OS releases (besides the release itself) is a signing tool. Other projects use a variety of tools for this, but unfortunately none of them were invented here. signify is a small tool I wrote to fill that gap. Here’s a few notes about it, working from the top down.
There are only two useful portmanteaus to be made from the words sign and verify. Verisign charges a lot of money, so we went with the free option.
The UI/UX is pretty spartan. It does lots of error checking, but makes no effort at error recovery. Early versions of signify refused to overwrite existing files, based on the theory that we’re going to stick this in a careful workflow and not make mistakes; i.e., overwriting a signature file by signing the same file twice indicates the workflow has failed. This was later changed, based on feedback from the poor souls who had to use the thing.
Continue reading signify - sign and verify...
Many moons ago I worked on a Windows graphical shell for Tarsnap. It never really went anywhere and I mostly forgot about it.
I was never quite sure what people wanted from such a client, which is partly why development stalled. If you just want something a little easier to use (click buttons, browse folders, etc.), I’ve got you covered. If you wanted some sort of Enterprise Workgroup management interface, I figure you already have far greater access to and familiarity with tools that can help do that than I do.
The one pain point I can imagine individual Windows users having that isn’t solved is simply getting Tarsnap running. Compiling Tarsnap from source may be outside the comfort zone of a lot of users. (As far as I know, the only way to compile or run tarsnap.exe is via cygwin.) Maybe I could host a Windows version, but do you trust me? Also there’s the problem of the cygwin dependency. It’s actually only a few DLLs which can be easily copied, but then I’m on the hook for providing the source to build cygwin1.dll, too. FWIW, once you’ve gotten tarsnap.exe built, it’s easily portable to other Windows systems that don’t have cygwin. Details in the readme.txt file.
Don’t try this at home. I gave up on my HP Pavilion g4 laptop as is and decided to try reviving it with a new CPU. The price for the A8 part was down to $30 on ebay. In theory, I was hoping the new integrated GPU would be sufficient to drive gaming on an external monitor at 1080p. According to the source of all true knowledge, stepping from the A4-3300M to the A8-3500M should give a substantial boost to graphics performance.
There’s a G4 teardown video which basically demonstrates the process. Remove 900 screws, bang on the plastic seams, and it all falls apart. Some pics below as well. This part went smoothly for something you aren’t supposed to be doing. The CPU itself lives in a nice ZIF socket and pops in and out easily. Right about the time I removed the CPU I realized I hadn’t considered thermal paste, but I didn’t have any and plowed ahead. Hoping the paste remnants on the heatsink would be sufficient, I figured if not I wasn’t going to leave things in a million pieces, so applying thermal paste would be a second teardown no matter what. Everything back together and we turn it on.
Continue reading laptop CPU transplant...
A while back, I read about filling dumpsters and going paperless with some interest, but it didn’t move me to action because I don’t really have that much paperwork. Then came another DIY approach, something worthy of turning into a project.
My paperless needs are rather modest. All I really want is to have easy access to a couple documents (contracts, stock options) to lookup or verify the occasional number. Utility bills and sales receipts and so forth are not a priority since I’m not running a business. But having a copy of my lease agreement on my laptop so I don’t have to find it in the important files box under my bed would be convenient. Word of caution: this is probably not the step by step guide you’re looking for.
Continue reading going paperless the hard way...