Mums has one of these, that I pointed out to her when it was on sale. Works fine, but a couple of tips:

Clean the corona wire with 20 - 25 passes of the integrated cleaning "tab" BEFORE first installing the drum/cartridge unit: These printers are known for a vertical black line of the first some dozen pages of a new cartridge; the cleaning eliminates or greatly lessens this.

The wireless connection works fine, but you need to configure it for the first time using a wired connection (e.g. Ethernet connection into your router). Establishing the initial wireless configuration using a wireless connection is problematic and/or, depending on what comment you are reading online, simply doesn't work.

The other week, Amazon had this thing for $90. It is a bargain. For that, you get 2400x600, 23 pages/min, USB, Ethernet, and wireless connectivity (the latter two meaning it is network-capable out of the box). The Brother driver and supporting software is actually decent (on Windows, at least). There was a problem with the Linux driver; a bug prevented -- of all things -- printing on Tuesday due to errant pattern matching in the print command contents. Hopefully, that's fixed, now. There were also workarounds described online.

I learned of Skim a few months ago, and it looks like a great tool. Extensive navigation and annotation abilities, with the annotations saved separately (merging them into the PDF file is also supported). Exactly what I want for migrating to more on-screen research and study.

Unfortunately, it is dependent upon Mac OS PDF handling libraries. I've been wishing/hoping something similar will appear that is cross platform. Some recent news about Python-based PDF libraries (I forget the specific names, at the moment) has perked my interest/hope a bit.

I hope something does develop. Or that I generate enough spare cash to finally put down for a Mac. (Suboptimal: I don't want to be tied to Apple's libraries.)

Thanks. I have "Lila" on the nightstand, waiting to be (re)started. (It's been that way for some considerable time.) Your post is a reminder to go back and revisit the earlier work -- it's been years, but I remember being consumed one summer and cramming the margins with notes and my own observations.

aka "Lightning"?

Entirely agree. There was a nascent guideline for users: Check the "padlock". Check that the protocol is https.

Designers then started breaking this. To avoid an extra https serve, particularly on a front page or popular page. For the sake of "Design", including putting a sign in form on the front page. Etc.

At least I knew to, if at all possible, force the site to serve up an https version of the sign on page. Most users have no clue about that. And the means for accomplishing this vary. Sometimes, you can do it by replacing "http" with "https" and resubmitting. Sometimes by submitting a blank form. Sometimes you have to populate the form with garbage in order to get by initial checks; the "error" page that comes back when the garbage credentials aren't found is served as https, if you're lucky.

Users were just learning to secure their transactions, when those who presumably had interest in the users' doing so, broke the paradigm, and broke it hard.

I'm at the end of my patience with such fools, who consider themselves professionals.

I'll also mention the idiots who populate their https pages with http references to components. Once you pull in one unencrypted piece, you've opened the door to exploitation. Get a f*cking clue.