This is geared more for end-users of Debian-based distros such as Ubuntu, MEPIS, and of course, Debian.

Some (most) of this is applicable to non-Debian based Linux distros like Fedora, Slackware, SUSE, or what-have-you; but in those latter cases, you will have to substitute the distro-specific line commands and packages (such as filename.rpm for Fedora instead of filename.deb).

For non-Debian/Ubuntu/MEPIS users, if you get hung up in here, I kindly direct you to the documentation pages (MAN pages if you can suffer to read the text in your terminal like a real geek), or over here at the CheckInstall home page.

Actually, I won’t presume to know more than the creators and maintainers of the program, so if you *are* an Ubuntu/Debian/MEPIS user and you get hung up here, by all means, check out the docs.

Packages vs. Source Code

Simply enough, a package is a container full of pre-compiled chunks of code - it need only be installed through the resident package manager. Packages usually have file extensions like *.deb (Ubuntu/Debian/etc) or *.rpm, (Red Hat/Fedora Core and related distros) or *.tgz (Slackware and its derivatives)

Source Code, by contrast, is pure, uncompiled code. By itself, it really doesn’t do much. To further blur things, source code is typically “zipped up” into an archive (usually in the *.tar.gz format). But despite the convenient bundling up of the code, it is not a package. Yet, the beauty of raw source code is that it can be compiled on any Linux box regardless of the distro, quite unlike some Windows applications which “require” Windows 2K or XP or *cough* are harshly broken on *cough* Vista *cough, cough, blecch*

Almost every distro of Linux these days - and definitely so for the 2.6+ kernels have a package manager/installation front-end utility built into it somewhere: Synaptic, apt-get, yum, urpmi, and so on. These package managers and their front-ends resolve dependencies and manage versions of the multitude of open-source software available to Linux.

Generally, there are two ways* of installing software on a Linux box. The first and easiest is to use your package manager (Synaptic in Debian-based distros) or using the command line:

apt-get install packagename

(or)

aptitude install packagename

The other way - commonly perceived and justified by some as the much harder of the two, is compiling the program from the Source Code.

This is somewhat true - while compiling the Source Code more or less guarantees that your code will be likely the latest and greatest version (although you can use Subversion - SVN - and get the REALLY bleeding edge stuff, typically the “working development” version which comes with all the headaches of being almost-beta software) built specifically to your machine’s architecture and your specifications, it does mean that you will have to do some more homework other than copy-pasting a line command or two into your terminal, or scrolling through piles of software in your distro’s repositories in Synaptic.

Compiling from Source means making sure that all its dependencies exist already on your machine (or else the compiling and making of the software fails with cryptic or ugly or worse, cryptically ugly messages).

It also may mean installing an updated version of qt3 or qt4 (a code framework) or gcc (a compiler) and a variety of make programs like cmake which actually put the Source Code into something your machine will want to work with.

And, assuming your distro hasn’t already installed them, you’ll want to make sure you’ve got gzip, bzip2, and zip, which will handle the most common zipped archives Source Code is usually compressed into: tar.gz, tar.bz2, and the eponymous *.zip files (and less commonly, *.Z files).

To make it easy on you, here is a hitlist of the most commonly used source-compiling tools you can install from the command line in Debian-based distros:

sudo aptitude install gzip bzip2 zip build-essential checkinstall gcc subversion

Once you’ve got all the particulars sorted out, a typical compilation sequence looks something like this:

- You download greatCode.0.1.0.5_i386.tar.gz or some other such thing with an impressive tail of version digits and characters that’ll make your knuckles and fingertips hurt - usually called a “tarball”, which must be first unzipped:

gunzip greatCode.0.1.0.5_i386.tar.gz

This will leave greatCode.0.1.0.5_i386.tar in your directory.

- Then, you “un-tar” the tarball into your Home directory (unless the docs say otherwise as to where to unpack the code) as such:

tar -xvf greatCode.0.1.0.5_i386.tar

Typically, this creates a directory greatCode.0.1.0.5_i386 with all the source code unpacked inside it.

- And supposing (just supposing now) you can’t be bothered with all that untarring and unzipping, you can always right click on the *.tar.gz (or similar) file and unpack it by selecting “Open with Archive Manager” in Gnome/Nautilus. I’ll go out on a limb and say that KDE or XFCE likely have a similar utility these days as well; I don’t use either of them, so that is my best guess.

Either way you unpack it, you now have this greatCode.0.1.0.5_i386 directory to deal with: I suggest renaming it to something easier to type when you need to find it quickly in your terminal (it won’t mess up your code, don’t worry) :

mv greatCode.0.1.0.5_i386 greatCode

Viola! Now change into your newly christened greatCode directory, and run this command:

./configure

This will send your terminal into a tizzy of flying text which can take anywhere from a few minutes to a coffee break to finish (depends upon your machine’s processing power and the complexity of the program).

What is happening is you have told the computer to run a batch file named “configure”, which checks and makes sure that all the dependencies are met, and builds the “makefiles” which will be used in the next step to actually compile the software. If you are missing something, you will likely get some cheesy message as mentioned above when the configure fails out.

Otherwise, it simply returns you to the command prompt, whereupon you simply type:

make

which compiles the program. Depending upon your machine’s power and program complexity, this might be time for catch up on your TiVO or a good book, or what-have you. Assuming that all goes well, and you aren’t missing anything that the configure script couldn’t account for, you’ll type:

make install

which naturally, installs the newly compiled software in another flurry of text flying by. Now this is all well and good, but if by some chance the coder(s) overlooked putting an uninstall piece in the makefile, removing the software without worrying about breaking stuff becomes a bit of an headache.

That is where checkinstall comes in.

At the last step, instead of running make install, run the following:

sudo checkinstall

Running this will prompt you to answer several questions, such as naming the software and its version info (typically, I use the same version number as the source code calls it, and append the current date and possibly some configuration info, such as this from a recent local build I made of Celestia (space/planetarium simulator):

celestia_1.5.0.18Apr2008

You could, of course, name it something more meaningful to you.

Answering the questions helps checkinstall to build up *deb file and install the software, synching it up to the package manager so that it is accounted for (a sort of a very distant analog to the Windows registry).

And when you get bored of the program, uninstalling it is just as easy as either running Synaptic and marking it for removal, or running this little nifty command:

dpkg -r greatCode (where greatCode was the example program).

And it gets removed just as if it were a repository software installed from Synaptic.

The “easy” way (copy these commands from here and paste them into your Terminal shell line, using [CTRL]+[Shift]+[c] to insert them):

sudo umount /dev/cdrom dd if=/dev/cdrom of=file.iso bs=1024

And when you are done, make a checksum (this generates a hash code used to verify the file’s integrity, probably not terribly important if you are just backing up audio CDs or media DVDs, but very important if you are backing up code that you want to be sure not to corrupt) :

md5sum file.iso > file.iso.md5

Remember of course, that file can be whatever name you decide on. Also, on a typical Ubuntu install, the CD/DVD burner should be located at /dev/cdrom, and when backing up DVDs, you may want to use /dev/dvd instead.

You can also do this with folders as well:

mkisofs -r -o file.iso /Some_Folder/

And now for the “easier way”:

Right-click the icon for the CD/DVD on your desktop, and choose “Copy Disc”.

Edit the Copy Disc to: field to File Image and choose where you want to save it.

Easy as cake, but a gruesome pain to find if you were trying to find it in GnomeBaker or some other such utility.

H/T to Kevin van Zonneveld for his much more thorough look at this.

IE7 (Internet Explorer 7) can be a pain.

Not terribly surprising is its tendency to “take over” and re-direct you to a Microsoft web page even after you have set your home page to a blank page or to some other specific page after installing it (or upgrading from an earlier version.

But even resetting the default home page wasn’t doing the trick, as every time I started IE7, it would still redirect to a page that would tell you to about how utterly fantastic the latest release of IE is (the final redirected URL is http://runonce.msn.com/runonce2.aspx).

I found a fix for it here which requires a little fiddling with the Windows Registry.

Read (more…)

I was probably smacking my head against the wall to hard trying to figure out what the heck was wrong with my use of the Phoogle code (a very nifty PHP script which makes use of the Google Maps API) when I finally got around to moving a site I’ve been working on to its place on a production server - hosted on GoDaddy.com.

Needless to say, their tech support folks are less than terribly helpful, as they pointed out that Phoogle’s file_get_contents($apiURL.urlencode($address)); function, which calls out to the Google Maps web service, is not permitted on GoDaddy’s hosts. Tough cookies on that.

This makes a certain amount of sense from a security standpoint - having site (user) accessing and running remote scripts through the (GoDaddy’s) host could open doors to all sorts of unfriendly riff-raff who might want to do not-so-nice things.

The GoDaddy support guy gave me some workaround that involved using a proxy server for HTTPS (not particularly needed, and the workaround gave me headaches just looking at it — and that said, I may need to consider any future choice to host a site with them again - for reasons not related to the sensible-ness of the handling the security issue this way).

Anyways, I turned to my good friend, Google Search…

… which after a few hours of parsing the tech blogs and odd mailing list weirdness that it can turn up, such as helpful and well meaning folks telling the poor frustrated sod trying to get his Phoogle on a file_get_contents() shunning host to simply edit his web.config or php.config file with this or that tweak — yes, I’m sure that’s fine on my personal development box, but I suffer little delusions of getting within a bargepole’s length of accessing anything that looks like a .config file on my mass-marketed web host.

Eventually, after much wailing and gnashing of teeth, Google ‘fessed up this link to Alex Hillman’s Development blog, dangerouslyawesome.

Mr. Tillman’s workaround proved to not induce any migraines, because it replaced one line of code (the file_get_contents() function) with seven lines of somewhat awe-inspiring and imposing cURL functions.

It looked like this:


$ch = curl_init();
$timeout = 0; // set to zero for no timeout
curl_setopt($ch, CURLOPT_URL, $apiURL.urlencode($address));
curl_setopt($ch, CURLOPT_RETURNTRANSFER, 1);
curl_setopt($ch, CURLOPT_CONNECTTIMEOUT, $timeout);
$addressData = curl_exec($ch);
curl_close($ch);


Apparently this was originally designed to work with DreamHost… but it works on the GoDaddy host all the same.

I hope this helps someone else, as the power of the Interwebs propagates this about the Infotainment Super-Duper-Highway… as I sure do hate seeing other folks leave code-induced brainstains on the side of the walls.

One thing I really like about Linux (and by extension, Mac OS-X) is that it is relatively safe from the ravages of social engineering attempts - most of the “click on me, tee-hee” stuff that marks the lot of nasty malware-hiding spams is either geared to the Windows x86 environment (which a lot of folks run using full administrator rights - BAD!!) or requires a user to execute the malware-activating code.

Of course, it is possible to do the same with OS-X or Linux, but the probability of successfully running the malware decreases with the tendency of Linux/OS-X to require root access as well as (in Linux) to make the script executable. There is the odd chance that one might find himself linking to a bad/untrustworthy Debian repository or flagging a file as executable, and/or running a untrustworthy shell script with SUDO… but all of that tends to take a little more effort than simply clicky-on-the-pretty-link many folks are accustomed to.

All of the extra keystrokes which Linux tends to require to setup and run a new program generally is sufficient to make a person consider and reconsider exactly what it is that he or she is doing, where as the one-time Windows click gives you maybe three nanoseconds of “Hanging Coyote Time“, where you realize that you’ve potentially just made one heck of a big boo-boo.

This is why I tend to only use my Linux box to check the several mail accounts that I have, as well as do my general web surfing.

But then, there’s my work computer - where I am forced by the kindness of Uncle Sam to use BillyWare (in this case, Windows XP).

Ah, the work computer. Supposedly protected by a nearly impenetrable wall of defenses, virus scanners, and Exchange server filters managed by a bunch of high-foreheaded spectacle wearing folks in a well-fortified place *somewhere in the USA*.

Which brings me to the meat of today’s post: The “E-Greetings” Spam.

Ordinarily, our Exchange server does a terrific job of catching spams - but lately we’ve been getting a lot of these:

I’ve already deleted two or three dozen of these, and suspect that someone or three in our rather large Active Directory has probably compromised themselves with whatever worm/payload that one of these mails triggers by opening the mail and clicking the link inside… thus making our entire AD vulnerable to these annoying (and potentially damaging) spams.

This is classic social engineering, and at least three of the variations (particularly the one marked from “You have received an egreeting from a [insert generic acquaintance such as classmate/co-worker/etc.]” spam which has been linked to a keylogging malware. Great for grabbing passwords and other confidential info.

It’s really effective too, in that it works off of a conditioning that some people (myself included) may have had from getting and sending e-cards from vendors like BlueMountain or Ynot!. (These e-cards are exceptionally popular in Japan, as well).

Some folks out there in virus-writing land never tire of trying to get into (your) data… and sadly, it will create havoc for an otherwise innocent industry of digital greetings, until those vendors come up with a more secure way of delivering their content. HTTPS comes to mind, but it all boils down to trust, and a small dose of common sense, especially when using with Windows and/or native MS products:

One must always be vigilant and even a tad paranoid when opening up email or attachments - and it never hurts to send an email or text/call your friend to be sure he or she sent it in the first place.

… at this page with current mirrors:

https://wiki.ubuntu.com/PowerPCDownloads

This is a follow-up to the post I made a few weeks back concerning loading Ubuntu Linux on the older Mac PPC machines.

Hat tip to Sam Tygier from the Ubuntu Bug Squad who was so kind as to point out a few resources for (potential) PPC Ubuntu users.

This all started out by the need for me to erase and wipe a few hard disk drives (HDD) in a computer I am giving to someone in my family… granted, they are not terribly likely to root around for my personal info, since they pretty much already know anything that is worth knowing about me to start with. In this case, I’ll probably just reformat and repartion and re-install the OS.

That said, and following a particularly contentious and topic-hopping thread over at Dan Riehl’s site, the subject of securely wiping a HDD came up, which lead me to want to thoroughly check out some other ways people have of wiping their HDDs.

Now for me, I’m perfectly content to put a few 30.06 rounds into a HDD I’m going to trash out, or maybe have a nice, fun workout smashing it up with a wood-splitting maul (being sure to wrap it in some newspaper or some old rags to keep stray parts from flying everywhere). For the really paranoid, it might also helps to take the shattered platters and pour some battery acid or some other nasty solvent to melt the surface of the platters, and then toss them into the ocean (or deep lake or river) or bury the remains where they won’t likely be found.

Otherwise, I’ve generally just re-formatted and re-partioned a HDD and used Active@ KillDisk a few times to thoroughly write over the data on it…

Which works perfectly fine for the average user to guard against some pimply-faced geek with a few hacker tools he downloaded from some grey-shaded websites.

Fine, that is, if you are reasonably confident that your HDD won’t turn up on the bench of some FBI field office, or the NSA… not that anyone has anything to hide from a just and upright government, yes? But even with overwriting a drive 30x-40x with random algorithms and multiple repartions and OS installations won’t keep the dedicated eyes of a corporate espionage operative/data pirate or a governmental intelligence agency with obscene amounts of time and taxpayer capital from getting a magnetically scanned image of your drive… which is the basis for the Defense Department’s (DoD) standard that requires HDDs marked for disposal to be degaussed (hit with a heart-stoppingly powerful magnetic field) and then ground to into powder.

Which is, of course… well beyond the ability of the average user.

But I did some digging around to see how other folks might handle their HDD-recycling issues, and the following article below deals with it pretty good too, and won’t cost a dime.

Related Links:

• Peter Gutman’s Secure Deletion of Data from Magnetic and Solid-State Memory. Mr. Gutman is considered to be something of an expert in data security.
• Darik’s Boot and Nuke (DBAN) - a GPL’d freeware utility that is at DoD 5220-22.M standard for data destruction, and also uses the Gutman wipe, among others. Works for Windows, Linux, and Mac/Intel.
  • For Windows, simply run the executable. It will create a boot floppy or a bootable file on a USB thumbdrive. For a boot CD, download the .ISO file and burn it to a CD with your CD-burning software. Reboot your machine and follow the prompts.
  • For Linux and Mac/Intel, download the .ISO file and use either the cdrecord dban-1.0.7_i386.iso from a terminal command line (Linux) or use your OS’s native cd burning software (Linux and Mac) to burn the ISO to a usable CD.
  • For Mac/PPC, you are pretty much out of luck… (update) Get the LiveCD image (.iso) PPC version of Feisty Fawn 7.04 here, and install it accordingly.

Linux distribution links:

Any Linux distro with a LiveCD can be used to get a shell command line from which to launch DBAN, do a shred or a wipe, or play around with Linux in general without touching your existing settings (notwithstanding the previously mentioned drive nuking programs).

I like Ubuntu, so I’ll plug for them a bit here.

Ubuntu is a Debian-based Linux distro, with a very good self-support community, and commercial support by Canonical, Ltd. Supports x86, SPARC,64-bit (Alpha) and very limited legacy support for PPC on Ubuntu distros released prior to 2007.

PPC is something of a dying breed with Apple firmly embracing the Intel chip in its current and upcoming generations of Macs, therefore, wide-spread support for it is on the wane as well. With the release of Ubuntu “Feisty Fawn” (7.04), the PPC architecture is not supported.

Update: One of the kind commenters in this thread kindly provided a link to Feisty Fawn 7.04 for PPC. There is PPC support, but it is not in the main distribution stream for Ubuntu - that is, Canonical is not making it available on most of the Ubuntu download mirrors.

Therefore, get the current version at any Ubuntu mirror - unless you know you have an older Apple (G3,G4,G5, iBooks, iMacs, and PowerBooks - pretty much any Mac before 2005) in which case you may want to to check out this page for Feisty Fawn (and likely, the upcoming Gutsy Gibbon 7.10 in October).

Otherwise, the main mirrors only offer either “Dapper Drake” (6.06 LTS) or “Edgy Eft” (6.10) versions. If you have no intention of installing it as your desktop OS, you can download the “Server” version, which is a slimmed down version of the LiveCD without the pretty windowed interface, and downloads in about half to two-thirds the time of the “Desktop” version. If all you are doing is trying to get a Linux command shell from which to run the shred or wipe commands on a PPC, then you need not do more.

In summation for Ubuntu:

• Feisty Fawn (7.04) Supports Mac/PPC, although some community-based legwork may be needed to address particular issues. Community-based support is available as always, at the Ubuntu Forums, and PPC users may find some solace (and help) here.

  Otherwise great choice for x86, SPARC, Alpha, and most 64-bit machines.
  Get it at: On the main Ubuntu site. It is already (should be) preselected in the form.

PPC Feisty is available at the mirrors listed here.

• Dapper Drake (6.06 LTS, supported until June 2009) supports Mac/PPC.
  Get it (for PPC users) :
  Go to the Ubuntu FTP mirror list… pick a mirror, and then choose a the Desktop PPC option, which should begin downloading a file that looks something like this: ubuntu-6.06.1-desktop-powerpc.iso
  For those living in the Mid-Atlantic region of the USA, here’s a link to FTP server at Columbia University to directly download the PPC version of Dapper Drake. Note that this is the Desktop version of the ISO (just incase you want to test-drive Ubuntu on your PPC).
• Edgy Eft (6.10, supported until April 2008) also supports Mac/PPC. Follow the same path as for Dapper Drake, but select the PPC-specific ISO for Edgy Eft. Not much difference between the two, really… and Dapper Drake is supported for a longer time, should you wish to use it as your OS later on.

Following is a "How To" for installing HandBrake, a clever little DVD-to-computer file ripper. Which of course, is quite handy for backing up your existing DVD collection (as opposed to those Netflix rented *ahem* DVDs).

I originally posted this on the Ubuntu forums as a mash-up of all the tutorials and posts I located on the net in my quest to get HandBrake up and running… credits given to authors below. 

• This is primarily geared toward Linux users (Ubuntu or Debian in particular, although any Debian based distro like MEPIS, Xandros, Linspire, etc that uses aptitude/apt-get could make it work from these directions)
• For Fedora Core amd other RPM based distros… this HOWTO may not work as intended. I recommend checking your distro’s forums and package manager for codecs and things like the Jam compiler. 
• Mac owners (PPC or MacTel) might be more interested in the GUI version available at http://handbrake.m0k.org/?page_id=24
• Windows users: If you are willng to "experiment", there is an .exe being built. Details are on the HandBrake forums (you may need to register with the forums to see this link).

HandBrake 0.7.1 CLI "HOWTO"

Much of it is derived from Mayank Sharma’s tutorial at http://www.linux.com/article.pl?sid=06/04/13/2139238 entitled "CLI Magic: Porting DVDs with HandBrake", but as I ran into a few rough bumps with it…

Here is what I did (again, this is pieced together from a few different HOWTOs) to get it running on my aging machine running Dapper:

-1. Download the source tarball:

wget -c http://download.m0k.org/handbrake/HandBrake-0.7.1.tar.gz

sudo aptitude updatesudo aptitude install jam build-essential nasm libdvdcss2

tar xvf HandBrake-0.7.1.tar.gz

mv HandBrake-0.7.1 HandBrake

cd HandBrake

./configure

sudo nano ~./HandBrake/libhb/Jamfile

ObjectCcFlags $(LIBHB_SRC) : -I$(TOP)/contrib/include ; 

ObjectCcFlags $(LIBHB_SRC) : -I$(TOP)/contrib/include -I$(TOP)/contrib/mpeg4ip/lib/mp4v2 ; 

-9. Jam it all together (requires installation of Jam, see #2 above)

jam

cp HBTest /usr/local/bin/handbrake

This allows you to pass commands to handbrake anywhere in a terminal.

For the record, this rips movies/DVDs to a suitable *.avi or *.mpg slightly faster on my old Compaq Presario running Dapper than the full-on GUI version does in Mac OSX on my fresh-from-the-Apple Store MacBook.

Credits go to Peter James Bui, jbird123 from the Ubuntu forums, and Mayank Sharma as mentioned above.

And of course, the coders who put HandBrake together.

I may re-post some helpful instructions for using the CLI (Command Line Interface) if I get permission from the author… it will help explain the somewhat mysterious commands HandBrake uses.

In the meantime, there is always the "help" operator: 

handbrake -h

Or it could be that I happen to be running Linux (Xubuntu 6.06 - that is, Ubuntu 6.06 LTS with the XFCE 4.3~ X-Windows manager) on an atrociously old computer that should have been turned into a toilet paper dispenser a couple of years ago.

But since with a baby on the horizon, and fuel prices skyrocketing ever upward, my discretionary spending on new computers is very limited… so running Linux on the old AMD K7 box (733 MHz of pure blazing sluggishness) beats waiting 15 minutes for it to boot up Win XP. 

For all the hype… Linux is not something that "just works" out of the box (or in this case, off of the LiveCD) for most folks, especially if you are something of a "Windows Power User". There is much dinking about in config files, and if heaven forbid that you want to install a program that isn’t in your distribution’s (read: flavour of Linux) package management … you will find yourself actually compiling the program from the source code.

Of course, being something of a geek… that is no problem. It is just when after all the compiling is done, the program barfs up hair on your monitor that looks nothing like the pretty screen shots on the web site you downloaded the source from.

Or worse, you expect the game to actually respond in a reasonable amount of time to your mouse/joystick input. I mean, it could be my drivers or my geriatric computer…. but a part of me is still thinking that the source code could have been put together a bit more nicely: often I will load the Windows flavour of the same program (this time, packaged as a nice little *.exe installer file) and it runs "just right".

And don’t get me going on some of the lame graphics that the "best titles" in Linux gaming has to offer. I guess until there is a rea$on to develop games for Linux… I will be keeping a Windoze partition on my machines.  

Okay, I know that I normally have reserved this category for Linux-realted posts… but other than my upcoming Franken-Komputer project I plan on undertaking sometime this week, I haven’t had much to post in recent months on (Linux) IT stuff.

But, a recent addition to my family of computers is a MacBook that for all practical purposes, my mother-law bought for my wife. Now while they are contentedly purring about "what a cute machine it is" (wife), or "how it will help (my wife) get a job" (Mom-in-law)… I am drooling with excessive greed as to how wonderfully seemlessly it and fast it handles the high-performance graphics software I have access to without horking up a graphics card like my Wintel PCs do every time I try to do something.

Honestly, I can’t say I have any complaints about this Mac - it starts up quick, the GUI (graphic user interface - the windows-like system) is fairly intuitive and has very crisp graphics (Mac OS X "Tiger")… and although there is a bit of a learning curve to it (menus for each application are on the bar at the top of the screen as opposed to the actual application, and it changes as you shift between apps)… 

Overall, I am impressed with it.

As for the looming Franken-Komputer project (so called because it will be the result of my fusing parts from a couple of computers that are taking up too much room)… I hope to make it a dual-boot Windows/Linux machine, as there are yet a few things that can only be done in Windows (such as certain video games I like to play on occassion - and yes, I *could* run them over Wine/QEMU, but this is a cranky old 1.2 GHz/256MB SDRAM machine I’m rebuilding).

But for the most part,  we shall be a Mac/Linux household for the next few years to come.