Incredible Blog of Penultimate Novelty
The greatest moment in leap-year musical history.
So there are like, 12 billion favorite techsnap moments that I have (thanks to Allan Jude, ChisLAS, and the Jupiter Broadcasting Network of excellent shows)... but this is the one that (consistently) makes me laugh the hardest.
The answer can only be MOAR... *but* it all must be simpler. MWHAHAHAHH. No one's seen that before.
While Brother's Support Site has generally accurate and up-to-date instructions and information as to how to get your scanner set up and working under basically all popular Linux distros, the way the information is organized (spread across arcane portions of the site, and across at least 7 pages), has irritated me enough over several deployments over the last year or so to the point where I thought I'd finally bite the bullet and take a moment to transcribe my notes for my most recent installation of a document fed Brother Scanner (specifically, an ImageCenter ADS-2000) on Linux Mint 17.
I don't go into adding the full functionality for the unit's scanner button (which requires setting up and configuring a seperate driver from Brother called the scan-key-tool), and I don't go into the super-awesome depths you can go to should you choose to take advantage of the impressive scripting and automation capabilities that Brother makes available for power users and others with unique requirements and demands (I've automated some sawheeet document processing handling routiunes, both for myself and others), but we will get ya up and running. Also, these basic steps should work (YMMV lol) with most of Brother's scanner models, and the basic steps are (roughly) the same regardless of distro.
The only major assumption we're making here is that you already have cups installed and configured for printing on your system - which is (oh, thank frigging GOD) now generally how most post-Neolithic distros ship. If you run into trouble (or just want to run into trouble), you can read all about what deploying and configuring cups CAN BE LIKE over at linuxfoundation.org.
So then: HTH you, cheers, and let's get to it!
-Before dealing with Brother's drivers, make sure you have the following packages installed:
sudo apt-get install xsane sane-utils psutils sane
-Then make sure you have the following directory and path on your system (should be there if you have cups, but best to be sure):
sudo mkdir /usr/share/cups/model
Plug In the Scanner:
It really sucks if you forget this step (which has happened to me)... nothing like trying to troubleshoot driver installs that SHOULD BE WORKING PERFECTLY only to realize an hour later that you forgot to plug the machine in, connect it to your computer (via USB), and turn the unit on (by opening the feeder tray). Also, I have had some setups and configurations get just a wee bit eccentric in some distros if the scanner isn't connected and powered on before continuing further (Ubuntu 12 most memorably).
Download Brother's "brscan" Linux Drivers:
-Go here and select the .deb flavor of the drivers, then pick between 32 and 64 bit flavors (here, we'll be assuming the 64bit drivers cause, well, we're not a frigging "Tandy Company" here anymore and have actually moved over 1.5 10ths of the way into the 21st Century, lol).
-Save that .deb package to your Downloads directory, then, back ensconced in the safety and efficaciousness of your terminal, type:
sudo dpkg -i --force-all ~/Downloads/brscan4-0.4.3-3.amd64.deb
(...that's the name of my driver file and version as of 2016-02-15, but be sure to check that you type the filename of YOUR dl accordingly)
-Check to see that the drivers actually installed:
dpkg -l | grep Brother
-If that outputs something that vaguely resembles the following, then so far so good:
ii brscan4 0.4.3-3 amd64 Brother Scanner Driver
Test Scan As Super User:
-Don't worry about the scary warning box you get after this next command; it's perfectly safe for us to do just this once to test that that we can actually can scan stuff:
-Click on the "I wanna do it anyway" button, and then wait for a few moments while xsane tries to find your scanner (this can take as long as a minute or so, so be patient).
-The main Xsane windows should then appear, one for setting your job specifications and a preview pane in the other. Click on "FILE," --> "Info" and check that the resulting window says something about Brother being your Vendor.
-Throw a few pieces of paper into your scanner, then, in the top left of the control window, enter the number of pages you want it to scan, the destination directory where you'd like them to be saved, the format ("Type") of file you'd like to save the scans as (I recommend JPEG for simplicity's sake during our first test), and then select "Automatic Document Feeder (left aligned,Duplex)" from the menu in the middle.
-Press the "Scan" button in the bottom right of the window, and then wait the 15-30 seconds for the scanner to actually (hopefully) begin imaging your documents. Take a look at the pages as they pop up in the preview pane; if they're not blank, then excellent!: We're almost done! Once it's done scanning, and you are satisfied, close Xsane (and tell it to discard all the images).
Make Scanning Available For Non-Superusers:
-We're almost done, but first, go here and scroll down to the section marked "Ubuntu 10.10, 11.4, etc. and download the nicely packaged udev rule .deb package. Then:
sudo dpkg - ~/Downloads/brother-udev-rule-type1-1.0.0-1.all.deb
Restart Your System:
-Reboot your machine. After logging back in, open Xsane again, this time though, using your normal every day user account. It should detect your scanner and open up like before. Run another series of test scans to make sure that everything is working smoothly for your "regular" user(s).
If you get a dialog box with red text saying that Xsane can't find scanner such and such at such and such address, close it down and see if doing it as Superuser still works. For some reason, I've had to restart my machine twice before the udev rules took affect for my normal user (tho I have no frigging idea as to how or why, lol). If THAT doesn't work, then check your work, making sure you didn't skip a step. If you find that you may have, go to Brother's Linux-Specific Information page and try following the instructions to Uninstall The Scanner Driver before trying to repeat the steps outlined above.
And hopefully that should get you well on your way to enjoying this (imho) really impressive, super fast, remarkably affordable ADF Scanner on Linux. If you want to go further (and get into writing your own automation scripts for more complex document processing requirements), I recommend starting with the brscan-key installation page (to get that front button working on your scanner), followed by checking out the "Use Scan-Key-Tool" page (which will give you a broad overview of what and how you can customize all kinds of behavior from the unit. Finally, be sure to check out some of the ways you can change the way the scan-key-tool's behavior (like automatically converting images to pdf files on output, amongst a myriad of other awesome things).
Hopefully soon I'll have time to set up the accounts and comments features of this site so you can post problems or corrections or suggestions here alongside this thread, but for now, if you run into probs or just want to holler at me, the best way is through twitter (@Vegaswriter) and I'll do my best to help. Cheers and happy scanning!
Can be found on slantnews.com (see the link below).
Just got done deploying csgoisfail.com via do droplet, replete with nginx, mysql, php, drupal 8, and drush from scratch, and - since scripting this sort of basic deployment has been on my mind for over three to five years now... long before the convenience of digitalocean droplets - basically tried to standardize this sort of deployment via script. I didn't have time to follow through with that (at least, not entirely), especially since digitalocean.com's dashboard incentivizes me to be lazy via allowing me to simply snapshot deployments.
Generally, I use DO snapshots inthe following use cases:
1: Before implementing major or experimental configuration alterations in productions, I'll (usually, if there's any chance that an important site could be borked, remember to) take the extra 10-60 minutes to poweroff the site and use the digitalocean dashboard to take a snapshot of the (then currently working) configuration. This is great because I don't have to create a whole backup set (with mysql dumps, files, and the associated myriad of config files and all, all of which I invariably forget some important nut or widget which makes restoring from such backups a pain in the ass, plus it requires entire redeployment time overhead of the entire server environment etc. etc.; with a snapshot, I get a one-click-redeployable image of everything on that server AT THAT MOMENT).
2: For backups - NOT A BEST PRACTICE, I KNOW, I KNOW, but what I lose from not having proper backups, redundancy, and walk-through-able-ness, I gain in *MAYBEY* (when the excrement hits the AC) at least having a snapshot to fall back on. I run (and have run) *TONS* of servers; not just for myself, but as managed servers for others, etc.; there's simply no way that I can provide legit backup services for EVERYTHING (though, for some servers, I do my damndest) that's under my purview (and of course, I advise clients of this as well, clearly and up-front... backups are a motherfucker to manage if you're not the sysadmin/engineer directly in charge of the infrastructure necessary, blah blah blah)... so yes: I use DO snapshots for backups (always cognizant of the possible losses should DO itself disappear tomorrow/other catastrophic problems to not having 3 copies of everything at all times). So there's the backups use case.
3: For Templatizing Server Deployments: This is by far my favorite (and DO's intended) use case for DO snapshots: I can spin up a server from a template snapshot, iterate all the fuck over it like a grafitti artist, filling it with whatever crazy madness or garbage I wish (be it intentionally experimental with the intent to deploy some iteration of said madness in production at a later date, or be it purely for throw-away "what shit sticks" purposes), keep notes on what I've done, what worked, what didnt', then either save that new iteration (if it meets my goals) to a new snapshot, or scrap it and roll it back to the previous snapshot. Having this capability is so far beyond my wildest imaginings in terms of being a sysadmin back when I started with servers (pre-2010) that it blows my mind.
4: For Templatizing Deployment Configurations (For PRODUCTION DEPLOYMENTS): There is nothing I love more than when someone else's needs and my skillset meet... EXCEPT (!!!): for when they do so *AND* I have already gone through the trouble of templatizing said solution. The whole idea of computer science is doing the hard stuff once (hopefully with ample comments and a workbook if necessary, but still: do it once, then never again); I subscribe to this ideal wholeheartedly in ideology - if not in actual implementation. So, any time I start noticing majorly useful design patterns (progrommatically, or from a systems administrator's perspective), I try to formalize those solutions into one standardized solution. To be honest, there really isn't way I can stay in the game otherwise; it makes managing on going commitments much easier and better for all, allows me to focus on the solutions (to read: necesary tweaks to accomplish the objectives at hand) and makes me faster overall (which is always good).
So, to that end, I've recently begun spending a lot of time thinking about the best ways to protect account credentials for all of those standard sysadmin services, hoping to standardize them across my snapshotted images. I haven't fully investigated/researched what I'd like to do (outlined below) but will be making this a project next week (once my current workload is less demanding).
Ideally, what I'd like to do is have a tiny partition of my VPS drive chunked out and encrypted, containing (as a reference to me, for when redeploying a snapshot of said image, either for myself or for a client) a set of boilerplate credentials for that snapshot.... This sounds stupid, but it would go a long way:
1. It would make me totaLLY less reticent to create credentials specifically for that service by virtue of removing the fear that I may forget/lose my creds as generated through any number of best-practices-recommended packages: If I could know that, on any given VPS, there was an encrypted (and therefore, presumably secure) partition, protected by either a key or (as is my preference) a great password phrase that I'm able to remember (I won't go further into my password generation methodology than that, but just know that, having spent a lot of my life cracking passwords, I know that they are actually useful when they are of a certain length AND are also memorable enough to be recalled by the admin), I could store all the user names and passwords generated for services for that server (SQL, CMS, etc. etc. etc.) in a plain basically a plaintext file.
Sure, I know that (even if possible) this isn't ENTIRELLY SECURE, but given the parameters we're talking about (VPS, etc.), it would go SUCH A LONG WAY towards mitigating against possible compromise. Ok. Back to work on csgoisfail.com.
Sure, I'm getting crushed by trying to cover AVN 2016 here in Vegas, but this morning, took a moment to clear my head with some good old-fashioned bloggy-criticism... LET NOT THE PERFECT BE THE ENEMY OF THE GOOD, that's what I say! So, for the first time since, like March of last year, a new movie: "Burn After Reading!"
It's been FOREFVER since I put together a decent showreel for my musical endeavors, but this site needs one. To that end, I'll be (courageously) delving through the 1,000+ hours of content I've created, flagging, tagging, clipping (gopchop-ping), then editing together what should be a badass 1 minute long showreel highlighting:
- Stride Piano
- Music Education
- Composer and Arranging (always so hard, cause it happens on paper, and filming paper is so very rarely exciting - exception: "Crumb")
- Band Leader (bunch of screencaps of lillypond running the generation of my book, I guess, followed by screencaps of all the pdfs opening, followed by my scanner toolchain, followed by ipad vid of my book on the ipad?)
- Ukulele goofiness
- Music box creation stuffs
- Chiptune and games music
- Podcasting/Voice overs/Engineering
So yeah... gonna be a pain in the ass - it's the exact type of thing I traditionally truly HATE spending my time on. But hopefully we can just bang it out today and get back to work building out the rest of this damned site.
... isn't as easy as it sounds (nothing ever is)...
But, as just as a sequel to my blog entry about "Breaking The Loop," (which currently can be found at http://sethflynnbarkan.com/node/7 although that's likely to change as I figure out wtf I'm doing with the urls on my site, so should be able to be found by searching sethflynnbarkan.com for "Breaking the loop," should that link fail)... regardless, I offer the following 3 awesome links to pieces about fear, conquering it, and basically overcoming the person you are so you can maybe get closer to being the person you would like to be (a lifelong project which, in spite of years of practice, I have yet to complete):
...For so many of us, fear is really about REJECTION. Check out this awesome bit of radio about "The Rejection Game!" (you can play too): http://www.npr.org/sections/health-shots/2015/01/16/377239011/by-making-a-game-out-of-rejection-a-man-conquers-fear
... and also...
... an awesome hour of radio from NPR's "Invisibilia" show: http://www.npr.org/programs/invisibilia/377515477/fearless
... Although Amy Cuddy's 2012 "fake it till you make it/become it" ted talk has become absurdly popular, well, if you haven't seen it, you should watch it: https://www.ted.com/talks/amy_cuddy_your_body_language_shapes_who_you_are?language=en