If you're experiencing graphical issues with the adventure game Runaway:
A Road Aventure, I found an issue with AMD's anti-aliasing support.
The game performs it's own antialiasing, and the morphological filtering
anti-aliasing setting, as set in the Catalyst Control Center's "3D
Application Settings" will have to be disabled, else a very interesting
but unplayable situation happens where every game screen refresh, the
game performs its own antialiasing, and in the subsequent frames AMD's
own antialiasing kicks in and proceeds to blur further and further until
the next time the game redraws the screen itself, whereupon for a single
frame everything is perfect, but things quickly blur farther and farther
from there, as the anti-aliasing function is continiously re-applied to
the same buffer.
In case you're wondering what the maximum amount of motor oil in your
basement that can drip into the RAM banks of your Itanium2 with a lot of
registered ECC DDR dimms, it's about this much:
There were other slightly less lubricated DIMMs in the server that
continued to operate fine; this amount appears to be near the upper
ceiling for RAM lubrication.
The more you know!
As a testement to enterprise stability, the machine operated just fine
through the ordeal, albeit it stopped using 4GB out of the 12GB of RAM
on board until I gave the motherboard and RAM a good ol' degreasing.
Only one DIMM actually was permanently damaged as a result of the
ordeal; the rest have been put back into service.
There's an older video game named Spelunx,
a kind of kid-oriented Myst-style game with worse graphics, made by the
same company that put out Myst, Cyan.
A notable feature in the extremely-hidden backstory of this game, is an
in-game book, a key plot point of which is a royal decree issued for
persons everywhere to construct the very best yodeling toaster in the
kingdom.
Given the lack of competition in this area, I believe I should be
declared the de-facto winner of this particular competition :-) And yes,
it still toasts.
WARNING: Toasters operate directly on mains/line power, and can
get very hot. This isn't just a standard disclaimer, toasters (at least
my cheap GeneriBrand NoSafetyOversight Edition) are apparently not
expected to be reparable/openable and contain exteremely dangerous
circuitry. The main toast lever on my model presses down on a
quarter-inch by 3-inch thin strip of bendable copper that makes contact
with another static copper contact farther down when depressed. This
huge unexposed strip was, of course, line power, which was just applied
to the heating coils whenever they needed to be heating. The timer
functionality was implemented mechanically. So simple. So cheap. So
dangerous to work around with the power on while testing your
half-assembled yodel toaster.
The Willing Victim
On a related note, I cannot confirm or deny that the table below is
being held up by a soda bottle, nor that the table in question is
actually a door.
Parts/Tools Used
Small phillips screwdriver
Angle Grinder (seriously)
Old 5V wallwart
Audio-playing electronics
Sheet Metal (I used a spare breadboard backing plate)
Creation of an Electronic Audio Solution
I was originally going to put in a tiny AVR and bit-bang out the audio
into a PC speaker, but the amount of flash on the microcontrollers I had
was prohibitively small for storing sound samples, even with a few
space-saving tricks. The off-the-shelf solution was like $8 from an
online electronics place (google 'diy audio greeting card' or similar to
get several different models/suggestions), so I had no problem going
with that.
Disassembly of the Toaster's Plastic Housing
This toaster was easy to disassemble, as if the manufacturer was
secretly encouraging yodel-based modifications, with normal phillips
screws on the bottom holding a few plastic outer shell parts together.
The only unusual part was how they all snapped together and how the
plastic lever extension had to be removed first before continuing
disassembly. While performing this step, look for areas of open space
that will be A) Not excessively warm during device operations and B)
Enough space to fit your electronics guts.
Making The Parts Fit
YMMV; this step will obviously vary wildly or may be completely optional
with differing base toaster models.
Keep in mind when performing modifications that you won't want your poor
PCB getting too warm during Normal Toasting Operations (NTOs).
Toaster innards
Toaster, incision sites marked and ready for surgeon
The surgeon delicately performing the operation on the patient with an
angle grinder
Addition of Audio Circuitry
Find a nice way to mount your electronics guts into the chassis. Try not
to short it out on the metal heat shield, and try not accidentally
desolder the PCB during NTO.
In order to make a clean looking single-power-cord going into the
device, with no external signs of yodel-capabilities, I fished a spare
5V-DC wallwart out of my housemate's Box-O-Extra-Wallwarts(TM), and
integrated this into the device.
Addition/Integration of Button Circuitry
I confess I have not taken apart any toasters besides this one, so do
not consider me a subject matter expert. In my particular model, as
described in the warnings section, the lever just presses a strip of
wire connected directly to mains down to make contact with the resistive
heating circuit. I really hope this isn't how they all do it, that's
gross.
Anyways, you should either somehow latch onto whatever contact they
have, make your own contact that triggers when the button is pressed
and/or comes up after finishing a toast action. Having the
depress-action (falling edge) also resulting in a yodel gives the added
benefit of alerting you that your toast is complete! In my case the
toaster did not have a bell for this functionality like others might, so
this was a welcome feature to have.
In my case, I ended up cutting a small piece of sheet metal from a spare
breadboard backing and very carefully folding it, which was actually a
joy to work with, even given the small size of the mechanical/electrical
contact I was extending. I then wired this up along with a matching
contact to form a press-button circuit to my electronics.
According to contest creators, the last part of the message (the text
after the ::) on the badge is meant to be PDP-8 instructions. Ignoring
the last character of the one-bit-extra first four groups (which encodes
['1', 'o','5','7'] , representing the name of the contest's creator Ryan
"1o57" Clark) of these pairs, we have:
101010001000
111010000000
001010010011
111100000010
000000000000
000000000000
000000000000
This, as far as I can tell, translates into:
JMP 8
CLA
TAD 19
HLT
... and the all-zeroes sequences that follow could /technically/ be
ANDing the AC with zero, but, they're after the halt, and zeroed out
memory tends not to really mean much in a more sane context.
But, these instructions don't really make too much sense. Why would
someone program this? Did they make a typo with the JMP 8?
QR codes are cool! The Reed-Solomon coding for error correction in them
can be fairly robust, and given the appropriate QR-code format settings,
enough to push in plenty of invalid (but aesthetically pleasing!) data.
I whipped one up for Computer Science House, pointing at our website and
containing our logo (or, at least, my 8x8 pixel re-imagining of the
logo). A slightly larger logo could be accommodated via the generation
of a secondary URL for the purposes of manipulation of the raw QR code
image (i.e. something akin to example.com/redirect/a6p356adfaa, which
could /then/ link to csh.rit.edu in a redirect).
With this, one could theoretically generate a QR code with la large
amount of bit-overlap with a logo, thus minimizing the amount that error
correction has to make up for. However, the math for this is....
complex. I suppose one could easily attempt a brute-force
strings-generation while generating qr-codes, and keep the one generated
with the most overlap, but I have not calculated the scope of this
problem, thus not having determined its feasibility.
I've been pretty swamped with work lately, but I've found time to start
doing Project Euler problems,
which are pretty fun to solve. I've completed 16 of them today! It's a
pretty great way to exercise my mind with new ways of thinking, and it's
quite excellent for learning/practicing Haskell. Plus, I gave the bug to
my buddy Alex Grant, who is
currently catching up to me on Euler problems, in a vague attempt to
prove that Ruby is just as valuable a language for this sort of
programming problem, as well as having a lot of fun himself. I may have
lost him with the release of Portal 2 though... oh well, he'll be back.
:-)
I've been on a weird Haskell kick recently, and I gave an intro
presentation on the language for BarCamp
Rochester 2011, and it was well-received. Other than learning new
things and doing considerably more math-for-fun than I'm used to, life
has been pretty good. I also have a trivia-solving piece of software in
the works, and I'm pleased with the performance it has so far. Hopefully
I'll finish and unveil it by this year's Innovation
and Creativity Festival at the Rochester Institute of Technology!
Security Warrior by Cyrus Peikari and Anton Chuvakin
ISBN: 9780596005450
This book is an excellent introduction into the world of computer
security. I was a bit surprised at the contents; the book features many
more offensive techniques, like reverse engineering binaries, performing
successful stack/heap overflows, attacks on a variety of server/network
platforms, and defeating IDS/forensic technologies. I had initially
expected the book to be more focused on security defense, which is
covered, but certainly not in a typical ratio. I wouldn't complain
though, because as is stated in this book several times, a good offense
is a good defense. For instance, upon introducing stack overflows, the
authors wisely quip how a company could save a great deal of money and
embarrassment if its employees found such vulnerabilities before they
leak into the wild.
If I did have one bad thing to say about Security Warrior, it's that I
happen to know quite a bit about its entire first section already, so I
found parts quite tiresome. Having already read such texts as Chris
Eagle's "The Ida Pro Book", this book's section on disassembly seemed a
paltry introduction in comparison; however, it seems this amount would
be about right to gently introduce someone to the subject, were they not
already aware of this field of computer security knowledge.
All in all, Security Warrior is a good introductory text to a wide
variety of computer security related topics, and hopefully the reader
will leave interested in implementing at least a few of the defensive
strategies listed, or want to become more familiar with some of the more
interesting attack vectors. Further reading/knowledge will be needed
other than the information found here in order to do useful security
work, but, Security Warrior certainly at least gets the ball rolling and
the interest piqued.
So, normally, backup software is going to read 90+% of your machine's
hard drive, and push that data over the network to someplace else.
However, in the process of doing this, it is going to steamroll your
operating system's filesystem cache.
There are two improvements that can be had here, in my reckoning, and
I've seen neither in implementation.
1) Have the backup software back up the files that are in the operating
system's cache FIRST. Not only does this mean that important,
often-changed files get priority, it means that backups will be slightly
faster, as this data will come from memory, rather than from the disk.
This would probably require some way of getting at a list of what
files the kernel/caching-daemon/whatever has in memory, which I'm not
sure exists at the moment.
2) Have the backup software use a different way of accessing the disk
such that the file caching daemon does not cache the files that the
backup software is reading. This way, rather than steamrolling over the
carefully-laid out filesystem cache of the system's most often and/or
most recently used files, the uncommon never-accessed-normally files
don't suddenly get pushed into filesystem cache when the backup software
accesses them. This would lead to general system speedup, as "better"
files from disk would be cached, rather than rarely-used junk.
This could be as simple as adding an oflag option to the kernel
(i.e. fcntl.h in linux) that says "don't cache this please", and then
using this when calling the open function in the backup application.
... Just some musings I had while talking to Russ on our way driving to
California.
There is like, zero documentation for doing this on the Internet. No one
else wants to install Gentoo in a VServer guest on a Debian Itanium2
host? Lame.
This quick overview contains many things specific to my personal setup;
therefore:
You will want to check your local gentoo mirror to see what the
current ia64 tarball is.
You will want to change the name, hostname, and network address of
your vserver
You can use whatever directories you want; the actual files will go in
/var/lib/vservers/<hostname>/ , (and /etc/vservers/<hostname>/ ) and
you can delete the stage3 tarball after you’re done.
So you don’t get confused, “jolt” is the name of my debian host
machine, and “coffee” is the vserver guest I am creating.
#Install the Vserver kernel and utilities if
you already have not.
