Once upon a time I abandoned Internet Explorer for this really slick, really sleek new browser. It opened up faster, browsed quicker, and had more customizable features than IE. It really was the bee's knees and everybody thought so, I tell you what! And it's name was... Netscape.
Oh how the mighty do fall! A few minutes later Netscape decided that I would doubtless prefer the option of adorning the margins of my browser with custom graphics, to such paltry considerations as speed and performance. About the same time Microsoft wised up (if only momentarily) and tuned it's browser for performance, sending me and a whole generation of hopeless internet addicts running gleefully back to embrace everyone's least favorite browser once more.
Time passed, seasons changed, and sure enough a new contender emerged brandishing a moniker resembling that of a poorly conceived Pokemon character: Mozilla Firefox. And oh how the fanboys did come a'runnin to laud it's many noble virtues. (Not to mention a handful of it's noble faults.)
Internet Explorer was jilted once more - the ignorant slut - as we all collectively shouted, "I choose you, Firefox!" But not for sake of standards compliancy or plug-ins galore. For what did we cross the aisle? Speed, baby. Speed. It popped, it zinged, it whizzed like greased lightning trying to bury a turd on a marble rocking chair... or something. Of course this is not to undervalue the momentary virtue of being significantly less-targeted by malware than IE was. Surely many horny, porn surfers preferred Firefox for it's prophylactic ability to keep their digital doohickeys trojan free.
Aye, Mozilla and her Firefox were the cat's meow, I tell you what. They were...
But through a recent moment of serendipity I found call to step back and take a good look at our favorite son, Firefox, as it exists today; putting aside the hype and foregone conclusions of days passed. And you know what I noticed? Firefox is the absolute slowest browser to open. That's right. The slowest! Slower than IE. You know what else? The Flash plug-in's performance under Firefox is laggy.
Well, these two deficits don't exactly mount a huge case against it, I suppose. But still it was enough to drive me back to the browser dealership to take a look at the new models. You know what I found? The hatchback Ford Fiesta is fucking sexy!
And so is Google Chrome. It's been a while since I took Chrome for a test drive and time has aged her well. Chrome opens faster than any other browser I've tried. The flash performance kicks ass. Why? Probably because it's not a plug-in. The latest Flash player is built directly in.
Chrome gives me more viewable area than any other browser, mainly by ditching the Title bar, going straight to tabs, and placing the information you'd normally get from a Status bar into a hovering, disappearing, reappearing, magical mouse-over event from the land beyond time.
At first, I admit, I was disgruntled by the lack of configurable options. Well, now I champion this lacking. Less truly is more. Just give me a good, fast horse to ride and keep your bloated, deluxe model with the in-mane HD display and whinnyable ring-tones. I don't want it!
I have five extensions in Chrome right now. One puts a Gmail icon and new message count on the toolbar; another puts the Google Voice icon on the toolbar; another blocks flash content by default unless I click it; another brings in my Google Bookmarks; and the last allows me to save web pages as a single file. That's everything I need and more, right there. And with these features installed and enabled Chrome blasts out of the starting gate and round the track before Firefox can even loose it's obese, cellulite-ridden thighs from the ever tightening fit of the old Poke-ball. Chrome is as CSS3 and HTML5 compliant as any browser should be. It's hip. It's happening. It's the place to be, baby. Get on board the choo-choo train.
Firefox has followed in the footsteps of Netscape, favoring tens of thousands of plug-ins, and user-customizable skins over speed and performance. May she rest in peace... the whore.
Long live Google Chrome! (Until something better comes along.)
Showing posts with label computing. Show all posts
Showing posts with label computing. Show all posts
Expanding a DIV to Size of 'background-image'
I struggled with this for a bit yesterday and found naught but forums telling me 'it can't be done,' or 'why are you doing that, it's stupid,' so I thought I'd share the solution I developed.
Here's the scenario: You have a DIV that will contain some text. You have different background-images that you want displayed under the text depending on which page is showing. But the background images are of varying sizes.
What you want, therefore, is a way to expand your DIV to the dimensions of whatever background-image you happen to stick inside it, without having to explicitly declare width and height values, either at your style sheet or in-line.
...and now you're off the rails.
One could surely pose a number of "why not" scenarios, such as: 'Why not just declare the width and height in-line?' or 'Why not just make the text part of the images?' Or one could pontificate upon the myriad of client and server-side solutions for querying the image size and declaring the DIV dimensions equal by script. But instead, let's just assume that we are coders and geeks, and that if there is a simpler solution requiring less explicit declaration and more uniform code distribution, then that elegance of design is our tacit desire and reward.
First off we must accept and acknowledge the limitations before us. The 'background-image' declaration does not care for width and height. It will fill a DIV with the image you choose, but it cannot under any circumstances be used to alter the boundaries of the DIV. Give that up right now!
Besides which, a 'background-image' declaration here would have to be placed in-line to meet our need of changing it across different pages, and I think it a best-practice to avoid in-line styles wherever possible, favoring HTML tags for dynamic content.
The solution, therefore, must be implemented from within the DIV. Anything placed inside a DIV of undeclared width and height will expand that DIV to fit. So in place of a 'background-image' declaration, we will set an <img> tag inside the DIV. The IMG's dimensions will be determined upon page load and the DIV will expand to match.
Now comes the text we want displayed atop our IMG. Just shoehorn it in there with a <p> tag. We'll make it work in a minute.
So now we have a DIV containing two blocks: P and IMG. What we want is for the P tag to overlay the IMG tag, creating the effect of IMG as a background. We accomplish this by use of negative margins and 'z-index.'
First off, the P tag has its own vertical margins which we'll want to zero so we can have a simple text-block with no extraneous white-space to work with. As for making our IMG into a background, we can force the P tag to overlap IMG's boundaries by giving IMG a negative 'margin-top.'
If you looked now, you would find that the text of the P tag has more or less disappeared behind your IMG. Here the IMG tag has a higher natural z-index than the text, meaning it is being drawn after, or overtop of P. We can change that by giving the IMG a negative z-index, which places it dimensionally beneath P. Note here that when you set a 'z-index' you must also make the 'position' of the element explicit, or it will not take effect.
Finally your P tag should be sitting proudly atop your IMG which has effectively become a background-image. Huzzah! Full code follows...
Beautiful isn't it? Just four lines of CSS and you can now switch out one background for another of an entirely different width - and even a different height if the design is right - without so much as a whisper regarding those properties. All you declare explicitly is how far down to drop your text over the image. "Can't be done," my eye!
There are some pitfalls to watch out for when implementing this method. For instance, it might seem just as easy to make the 'margin-bottom' of P a negative instead of the 'margin-top' of IMG, but if you do it this way Internet Explorer, in particular, just might chop off the vertical edges of your IMG if P's block fails to fill the DIV out to the full height of IMG. This can be countered by augmenting line-height, but then you're fighting battles you don't have to. Yeah, I may have learned that one the hard way.
There you go: Dynamically expanding a DIV to the size of a background image. Tada!
The Problem
Here's the scenario: You have a DIV that will contain some text. You have different background-images that you want displayed under the text depending on which page is showing. But the background images are of varying sizes.
What you want, therefore, is a way to expand your DIV to the dimensions of whatever background-image you happen to stick inside it, without having to explicitly declare width and height values, either at your style sheet or in-line.
...and now you're off the rails.
One could surely pose a number of "why not" scenarios, such as: 'Why not just declare the width and height in-line?' or 'Why not just make the text part of the images?' Or one could pontificate upon the myriad of client and server-side solutions for querying the image size and declaring the DIV dimensions equal by script. But instead, let's just assume that we are coders and geeks, and that if there is a simpler solution requiring less explicit declaration and more uniform code distribution, then that elegance of design is our tacit desire and reward.
Solving
First off we must accept and acknowledge the limitations before us. The 'background-image' declaration does not care for width and height. It will fill a DIV with the image you choose, but it cannot under any circumstances be used to alter the boundaries of the DIV. Give that up right now!
Besides which, a 'background-image' declaration here would have to be placed in-line to meet our need of changing it across different pages, and I think it a best-practice to avoid in-line styles wherever possible, favoring HTML tags for dynamic content.
The solution, therefore, must be implemented from within the DIV. Anything placed inside a DIV of undeclared width and height will expand that DIV to fit. So in place of a 'background-image' declaration, we will set an <img> tag inside the DIV. The IMG's dimensions will be determined upon page load and the DIV will expand to match.
<div id="my_div">
<img src="images/bg1.gif">
</div>
Now comes the text we want displayed atop our IMG. Just shoehorn it in there with a <p> tag. We'll make it work in a minute.
<div id="my_div">
<p>Contact Us!</p>
<img src="images/bg1.gif">
</div>
So now we have a DIV containing two blocks: P and IMG. What we want is for the P tag to overlay the IMG tag, creating the effect of IMG as a background. We accomplish this by use of negative margins and 'z-index.'
First off, the P tag has its own vertical margins which we'll want to zero so we can have a simple text-block with no extraneous white-space to work with. As for making our IMG into a background, we can force the P tag to overlap IMG's boundaries by giving IMG a negative 'margin-top.'
#my_div p { margin: 0 }
#my_div img { margin-top: -80px }If you looked now, you would find that the text of the P tag has more or less disappeared behind your IMG. Here the IMG tag has a higher natural z-index than the text, meaning it is being drawn after, or overtop of P. We can change that by giving the IMG a negative z-index, which places it dimensionally beneath P. Note here that when you set a 'z-index' you must also make the 'position' of the element explicit, or it will not take effect.
#my_div p { margin: 0 }
#my_div img {
margin-top: -80px;
position: relative;
z-index: -1;
}Finally your P tag should be sitting proudly atop your IMG which has effectively become a background-image. Huzzah! Full code follows...
The Solution
<head>
<style type="text/css">
#my_div p { margin: 0 }
#my_div img {
margin-top: -80px;
position: relative;
z-index: -1;
}
</style>
</head>
<body>
<div id="my_div">
<p>Contact Us!</p>
<img src="images/bg1.gif">
</div>
</body>
Beautiful isn't it? Just four lines of CSS and you can now switch out one background for another of an entirely different width - and even a different height if the design is right - without so much as a whisper regarding those properties. All you declare explicitly is how far down to drop your text over the image. "Can't be done," my eye!
There are some pitfalls to watch out for when implementing this method. For instance, it might seem just as easy to make the 'margin-bottom' of P a negative instead of the 'margin-top' of IMG, but if you do it this way Internet Explorer, in particular, just might chop off the vertical edges of your IMG if P's block fails to fill the DIV out to the full height of IMG. This can be countered by augmenting line-height, but then you're fighting battles you don't have to. Yeah, I may have learned that one the hard way.
There you go: Dynamically expanding a DIV to the size of a background image. Tada!
Dissatisfied and Leaving - Jungle Disk
I've been using Jungle Disk for some time now to backup my data to Amazon's S3. I've formed a less-than-stellar opinion of the software on a number of different heads, (see: Jungle Disk 3.04 - Update From Hell) but today I noticed an 800mb data transfer in process and wondered what it was - so large - that I was unexpectedly backing up. Upon investigation I found that Jungle Disk was re-uploading a certain collection of videos and other files which I'd recently gathered together and moved into their own sub-folders. Now, these files had all existed in the backup previously, they were just moved one folder deeper from their last position.
I personally find it ludicrous that an online file backup system should be unable to deal with a simple move operation like this, without uploading the whole file's content a second time. There's hash data, modified dates, file sizes, file sampling, and so forth... all which could be used to recognize these changes to say: "Hey wait, this file is already on the server, it's just somewhere else in the file tree now. I don't need to upload the data again, I can just modify the associated meta data."
Today's 800Mb's pushed me over the edge and set me on the search for some other software solution that will quietly run in the background and let me backup to S3. Yes, Jungle Disk has so disappointed me that I'm willing to re-upload my entire data set at Amazon's usual 85Kbps just to be rid of them. I'm making inquiries now. I'll report any success using other software.
I personally find it ludicrous that an online file backup system should be unable to deal with a simple move operation like this, without uploading the whole file's content a second time. There's hash data, modified dates, file sizes, file sampling, and so forth... all which could be used to recognize these changes to say: "Hey wait, this file is already on the server, it's just somewhere else in the file tree now. I don't need to upload the data again, I can just modify the associated meta data."
Today's 800Mb's pushed me over the edge and set me on the search for some other software solution that will quietly run in the background and let me backup to S3. Yes, Jungle Disk has so disappointed me that I'm willing to re-upload my entire data set at Amazon's usual 85Kbps just to be rid of them. I'm making inquiries now. I'll report any success using other software.
'Virus Protector' Removal
I came across an infection going by the name of "Virus Protector" today. It had taken over the Windows XP shell via:
...replacing the value 'Explorer.exe' with its own executable (randomly generated filename) located under C:\Windows\system32\. It had also disabled the task manager via the registry at:
This combination left no entry point for online repair since even Safe Mode boots whatever shell the Winlogon refers it to.
I removed the hard drive and hooked it up to a diagnostic machine. I cleaned the temp files and ran a virus scan as a matter of course, but a certain methodology I used makes this article worth writing -- if only to me.
Guessing, at that time, that the Winlogon\shell value was the culprit I used LoadHive.exe to mount the software portion of the infected machine's registry located under C:\Windows\system32\config\.
Upon inspecting the Winlogon\shell value I found it redirected, (of course) but as I was accessing the registry offline now, correcting the corrupted key by editing the value at the registry wasn't the easiest solution. Instead, I made a copy of C:\Windows\explorer.exe, renamed it to match the name of the infection, and pasted it in place of the virus. This allowed me to boot the computer normally and continue the repair by unlocking the registry, which had also been disabled "by my Administrator." Thereafter I edited the Winlogon\shell's value back to its correct value of simply "Explorer.exe," thus defeating Virus Protector.
The End
P.S.: Pretty neat how you can close off a machine entirely just by hijacking the Winlogon\shell and disabling task manager, ain't it?
[ Update: Why didn't I just edit the Winlogon\shell value via Loadhive.exe, you ask? I have no good answer. I just got it in my head that Loadhive was a read-only tool. It's not. Changes made after a hive is loaded are written to the hive as they usually would be. So nevermind any of this, I guess. Just change the shell value when you're in regedit and be done with it. ]
HKLM\Software\Microsoft\Windows NT\CurrentVersion\Winlogon\shell
...replacing the value 'Explorer.exe' with its own executable (randomly generated filename) located under C:\Windows\system32\. It had also disabled the task manager via the registry at:
HKCU\Software\Microsoft\Windows\CurrentVersion\Policies\System
This combination left no entry point for online repair since even Safe Mode boots whatever shell the Winlogon refers it to.
I removed the hard drive and hooked it up to a diagnostic machine. I cleaned the temp files and ran a virus scan as a matter of course, but a certain methodology I used makes this article worth writing -- if only to me.
Guessing, at that time, that the Winlogon\shell value was the culprit I used LoadHive.exe to mount the software portion of the infected machine's registry located under C:\Windows\system32\config\.
Upon inspecting the Winlogon\shell value I found it redirected, (of course) but as I was accessing the registry offline now, correcting the corrupted key by editing the value at the registry wasn't the easiest solution. Instead, I made a copy of C:\Windows\explorer.exe, renamed it to match the name of the infection, and pasted it in place of the virus. This allowed me to boot the computer normally and continue the repair by unlocking the registry, which had also been disabled "by my Administrator." Thereafter I edited the Winlogon\shell's value back to its correct value of simply "Explorer.exe," thus defeating Virus Protector.
The End
P.S.: Pretty neat how you can close off a machine entirely just by hijacking the Winlogon\shell and disabling task manager, ain't it?
[ Update: Why didn't I just edit the Winlogon\shell value via Loadhive.exe, you ask? I have no good answer. I just got it in my head that Loadhive was a read-only tool. It's not. Changes made after a hive is loaded are written to the hive as they usually would be. So nevermind any of this, I guess. Just change the shell value when you're in regedit and be done with it. ]
'XP Internet Security' corrupts '.exe' file associations.
Click here to jump to Removal Instructions
We've got something new and interesting in the world of viruses today folks, and its proliferating like gang-busters judging by the three infections that made their way into the shop this week. The front end of the virus is calling itself "XP Internet Security," though there's nothing new about that.
We've long been plagued by "Internet Security" and "Personal Antivirus" (PAV) variants: Flashy viruses that throw up messages from the taskbar and open 'Scan result' styled windows telling you you've been infected with two or three dozen nasties and that the only way to get rid of them is to Click here, enter your credit card numbers, etc. Nope, there's nothing new or interesting about any of that. It's old hat! What is new and interesting about this latest "XP Internet Security" infection is the method by which the virus starts up.
Rather than squeeze into the boot sequence circa msconfig or attach itself to the winlogon or write itself into an AppInit_DLL statement, or a thousand other things I see three times daily every day of the calendar year, this new-styled "Internet Security" infection is hijacking the ".exe" file extension association. By prepending the path of the virus executable to .exe associations in the registry the virus gets an opportunity to start up every time any executable on the machine is called. And the best part of it - from the virus' perspective, anyway - is that this method of initialization, simple as it is, isn't monitored by the tools of the industry. In other words, Hijackthis doesn't look for registry changes there. (yet)
Thankfully this piece of malware came out a tad under-ripe. Had the developer spent a little more time with it, it might have really been a barn-burner. Had they integrated a method of masking the executable from detection, randomized the file name and hidden it in the system32 directory, it might have been all-but invisible! But the early release has doomed it to one-hit-wonder status.
Hijackthis doesn't detect the startup entry but it does see the executable running - it does tell us the path to the virus - and that's enough information to put this one to bed. You can run a Hijackthis scan, open the log, see the path to the virus, track it down, and simply delete it. (Or rename it as I usually do.)
But wait! Removing the virus is one thing. Undoing the damage to the registry is another. For once you quarantine or delete this virus, you'll immediately find that none of your programs open up anymore. Due to the way the virus had infected the .exe file extension, your machine has forgotten how to open executables!
This is where I pause to applaud the developer. That, my friend, is a thing of beauty. Kudos.
Anyway, its all fixed easily enough. The virus overwrites standard calls to executables, but it didn't modify the "Run as..." registry entries for them. So to start any program you need only right click it, select "Run as..." from the drop down menu, uncheck "Protect my computer and data..." and there you are; Bob's your uncle; program's running.
With that bit of information in hand you can navigate to the \Windows folder, (Explorer.exe, and therefore File Explorer, is unaffected by the extension corruption) pop into 'Regedit' and search the registry for references to the virus executable, repairing the infected associations as you go. That'll get your .exe's opening again.
Then it's just a matter of some incidental cleanup. The infection knocks out all the detection and notification features of the Windows Security Center and it also turns off the Windows Firewall, so you'll want to set that right as well.
I'm impressed with this virus because defeating it required a departure from my methodology. I don't usually need anything but Hijackthis and Sophos Anti-Rootkit to detect and defeat everything, and I suppose I didn't really need anything more than that here either. But for a minute there, this one left me scratching my head -- looking at a perfectly clean HJT scan and no indication of a rootkit. That's good! Then I remove the virus and discover these executable errors popping up like penalties imposed on me for killing the virus. That's really good! Then there's the joyful process of reverse engineering it and coming to understand how and where it was able to start up without being detected by a Hijackthis scan.
That's a worthy opponent! That's a satisfying day's work, there.
Removal Instructions
CAUTION: These instructions are not written so that just anyone can follow them. They are not written for you. You don't know what you're doing. You'll mess it up and it will be really bad. Don't read this. Don't try this. Call a computer repair guy, you cheapskate. You have everything to lose.
Locate the Virus
The variant described here installs itself to "C:\Documents and Settings\<User Account>\Local Settings\Application Data\av.exe". Other variants may install elsewhere. To detect them, download and install HijackThis. Select "Do a system scan and save a log file." In the log file, search the "Running Processes" area for suspects.
Show the Virus
Open "My Computer" and navigate to the location of the file. It is a system-hidden file so it will probably not appear. To see the file click Tools>Folder Options>View and uncheck the "Hide protected operating system files" box. Click yes when prompted with the warning and then click OK to close the Folder Options dialogue.
Kill the Virus
Delete the file "av.exe" or quarantine it by renaming it to "av.exe.quarantined". Go back into Tools>Folder Options>View and re-check the "Hide protected operating system files" box. Restart the computer.
Open Regedit
You will not be able to run .exe files regularly because the virus corrupted the registry. Open "My Computer" and navigate to C:\Windows. Locate Regedit.exe and right-click it. In the drop down select "Run as..." Uncheck the "Protect my computer and data from unauthorized program activity" box and click "OK."
Clean the Registry
Make sure "My Computer" is highlighted in the left pane of the Registry Editor and press CTRL+F to bring up the "Find" dialogue. In the search field type the file path to the virus. ("C:\Documents and Settings\<User Account>\Local Settings\Application Data\av.exe")
[UPDATE: Since writing I've found it beneficial to search the registry like so: .exe" /START. More recent versions of the infection I've just seen will install under multiple system accounts like 'LocalService' and 'NetworkService,' and with mutliple files like 'av.exe' and 'ave.exe' so being less specific may discover more infected registry entries.]
Click "Find Next." When you find a key with a value like this:
"C:\Documents and Settings\<User Account>\Local Settings\Application Data\av.exe" /START "%1" %*
...double click the value to edit it and delete the path to the virus along with the /START command from the beginning of the key, leaving whatever remains after it. In this case you would delete "C:\Documents and Settings\<User Account>\Local Settings\Application Data\av.exe" /START and you would leave "%1" %*. Then press the F3 key to continue searching the registry for more instances of the virus path.
You will probably also find a key for iexplore.exe that has the virus path followed by the path to iexplore.exe. Just delete the virus path and the /START portion from any keys you find - this one included - while retaining whatever follows, as described above.
You will find other keys that are just pure references to the virus. They are easy to distinguish from the previous kind if you pay attention. You can just delete those.
When you reach the end of the registry, close regedit. You can now run .exe files again. That is, unless you jacked it up. In which case you can always download the "EXE File Association Fix" at http://www.dougknox.com/xp/file_assoc.htm and merge it with the registry to get things running again. ...Unless you can't. In which case: I told you not to try this in the first place, man. What the hell were you thinking?
Re-enable Windows Security Center and Windows Firewall
The virus disables Windows Security Center features and the Windows Firewall. To put these in place again, open Control Panel>Security Center. Under Firewall click Recommendations. Uncheck "I have a Firewall Solution I will monitor myself...", click the "Enable Now" button, and click OK.
Under Virus Protection, click Recommendations. Uncheck the "I have an antivirus program that I'll monitor myself..." box and click OK.
In the left column of the Security Center click "Change the way Security Center alerts me" and put a check in all the boxes there. Click OK.
Done
You are done. Good work. Hit the showers.
AVG Offline Installer Download Link
It's harder to find than you'd think. AVG doesn't exactly publish this info, for some reason. This is valid for AVG 9.0 and at time of post pulls down the file "avg_free_stf_en_90_730a1834.exe."
I'm noting this link as much for myself as for you. In fact, more for myself. I never really cared for you.
http://www.avg.com/in-en/download-file-ins-afg
I'm noting this link as much for myself as for you. In fact, more for myself. I never really cared for you.
http://www.avg.com/in-en/download-file-ins-afg
Collapsing Margins / Borders in CSS
Here's a simple example of the kind of unexpected behavior caused by collapsing margins in CSS.
When displayed, (tested in Firefox 3.5.7) the code above produces the text "Hello flawed world!" on a cyan background, and nothing else. This is not as expected.
The <h#> tags have a built-in top and bottom margin to them of around 20px. Now, a margin, specifically, is white-space surrounding a tag, outside of it. Margins push out from a block's position to create empty space around it. With this in mind, the code above should produce 20px worth of red - the background color of the <div> containing the <h2> - above and below our cyan-backed text. But it doesn't.
Meet the concept of collapsing margins. Because nothing whatsoever has been placed in the space between the div's borders and the h2's borders, the browser is taking it upon itself to remove what it perceives as empty-space by collapsing the margins together.
I don't know why it might be beneficial for the browser to collapse margin-space this way, nevertheless here we are. We must work around it.
In order to get the desired margins to appear we must prevent the browser from perceiving them as empty. The simplest, most unobtrusive thing to shove in the gap is a bit of padding. Padding is sort of the inverse of margins, in that it creates white space within the block, rather than outside it; pushing inward from the borders. 1px worth of padding will keep your margins and borders from falling in on themselves.
The corrected code inserts 1px worth of top and bottom padding to the div. Again, note that the padding is added to the outer container. It pushes inward, giving the previously empty space between the edge of the h2 block and the edge of the div block a tiny bit of content. In the example I've used the 2-value format of the 'padding' style, where the first value represents top and bottom padding, and the second left and right.
I've always looked at margins and padding as being the same thing in a different direction. Apparently this isn't entirely true. For some reason the CSS standard views white-space created by margins as sacrificial when unoccupied, but maintains a hallowed view of white-space declared as padding. Preserving padding makes sense. Not preserving margins... I'm sure there's a reason, but from the coders perspective it seems an inconsistency.
<div style="background-color: red">
<h2 style="background-color: cyan">
Hello flawed world!
</h2>
</div>
The Problem
When displayed, (tested in Firefox 3.5.7) the code above produces the text "Hello flawed world!" on a cyan background, and nothing else. This is not as expected.
The <h#> tags have a built-in top and bottom margin to them of around 20px. Now, a margin, specifically, is white-space surrounding a tag, outside of it. Margins push out from a block's position to create empty space around it. With this in mind, the code above should produce 20px worth of red - the background color of the <div> containing the <h2> - above and below our cyan-backed text. But it doesn't.
Meet the concept of collapsing margins. Because nothing whatsoever has been placed in the space between the div's borders and the h2's borders, the browser is taking it upon itself to remove what it perceives as empty-space by collapsing the margins together.
I don't know why it might be beneficial for the browser to collapse margin-space this way, nevertheless here we are. We must work around it.
The Solution
In order to get the desired margins to appear we must prevent the browser from perceiving them as empty. The simplest, most unobtrusive thing to shove in the gap is a bit of padding. Padding is sort of the inverse of margins, in that it creates white space within the block, rather than outside it; pushing inward from the borders. 1px worth of padding will keep your margins and borders from falling in on themselves.
<div style="background-color: red; padding: 1px 0;">
<h2 style="background-color: cyan">
Hello flawed world!
</h2>
</div>
The corrected code inserts 1px worth of top and bottom padding to the div. Again, note that the padding is added to the outer container. It pushes inward, giving the previously empty space between the edge of the h2 block and the edge of the div block a tiny bit of content. In the example I've used the 2-value format of the 'padding' style, where the first value represents top and bottom padding, and the second left and right.
I've always looked at margins and padding as being the same thing in a different direction. Apparently this isn't entirely true. For some reason the CSS standard views white-space created by margins as sacrificial when unoccupied, but maintains a hallowed view of white-space declared as padding. Preserving padding makes sense. Not preserving margins... I'm sure there's a reason, but from the coders perspective it seems an inconsistency.
Jungle Disk 3.04 - Update From Hell
A letter to Jungle Disk Support: (An Online File Backup Solution)
Yesterday my Jungle Disk Desktop software asked permission to update itself to 3.04. I allowed it. Because of this I spent half an hour recreating my backup set, reverifying my S3 information, and generally redoing and undoing everything the update did. This was a sloppy, mismanaged, poorly implemented, and unintuitive software rollout. Please consider all of the following.
You will surely agree that there is no situation in which any software update should wipe out all previous customization and user information, and yet that's just what this update did on my system. After the software updated itself and restarted the machine I was asked to enter my login information. It was poor timing that this coincided with your service outage yesterday, so I closed the program and waited for your website to go live again.
When I was again able to log in, my new Jungle Disk 3.04 asked for my S3 data again -- mind you this S3 data was known to my previous version of JDisk. Then it walked me through creating my backup job all over again, from scratch, as though it had never ever heard of me before; as though I hadn't done this very task when I first signed up! With all due aggravation I went through this tedious, and unnecessary process once more; again finding all the little check marks - invisible unless you click the "Advanced" radio button, hidden throughout the visually unintuitive Configurations tree - which describe my desired backup set.
"No, this is the only computer I use JDisk on, DON'T hit the server with a bunch of LIST requests every two minutes that I'll have to pay for at the end of the month." "No, don't store ten versions of every file that gets edited, 3 is more than enough for me." And so on.
When I complete the arduous and completely unnecessary task of resubmitting all my original preferences, I click 'Backup Now,' just to make sure that everything is working; to confirm that Jungle Disk still sees all those files it took me over a hundred hours, uploading to the Cloud at 90kbps, to begin with. To my complete lack of surprise, it doesn't! It wants to upload my entire backup set all over again!
Here is where I discover your new Vault format, and further that it is incompatible with your old Jungle Disk 2.0 file system. And, of course, if I'd like to use a Vault then I'll have to upload all my data all over again -- even though it's all right there in the same S3 account and could surely be moved laterally if your Dev teams were to invest that effort.
So, all the configuration I've just done is worthless because I'm not going to spend another whole week clogging up my bandwidth, uploading files that are already there! After reading the comments of some equally frustrated users at the forums I head back into the visual mess that is the Configuration tree, delete the Vault that JDisk just walked me through erecting, and again! again! go to work configuring my old Jungle Disk 2.0 archive. Again!
Thankfully, the JDisk 2.0 backup set recognized the files that were already in the Cloud and I plan to continue using 2.0 for some time hereafter. I have no interest in the Vault now, as it is the Vault that caused me all this trouble.
Summarily, when a user clicks "Update," they shouldn't have to worry that all their previous configurations will be lost, nor that their files might become stranded in a sudden obsolescence. And if you are rolling out a new format it should be stated over and over again in large font, on otherwise empty pages, that your current data will not transfer to the new format. "You will have to upload it all again." And thereafter the user should be given the clear two prong choice to upgrade to Vault or stick with JDisk 2.0.
Settings that I have used previously should follow me into a rollout of new service. If I didn't want to backup 10 file versions in JDisk 2.0, then I probably don't want to in JDisk Vault either! For that matter, you should have saved the configurations from my original backup set before the update and simply duplicated those selections for Vault service, if I wanted to use Vault.
I also suspect that had I just accepted the Vault transition and uploaded my data all over again, nothing would have been said about my old JDisk 2.0 data still sitting up there in the cloud, costing me $.15 per Gb, per month, for the privilege, and rotting away to no use. I'm guessing you don't have any system in place to notify or remind the user of the redundant data they'll end up storing after transitioning to Vault.
While I'm at it, I might as well add that I would like the option to update more often than once a week, without having to do so every single day of the week. Putting the scheduling option on a slider, like it is, instead of a series of checkboxes is plainly ridiculous. I don't know how you came up with that one.
I like your service. I like storing my backup in Amazon's Cloud. Your software has proven itself technically proficient, quiet, robust, and reliable. But this rollout was intolerable in every aspect. I couldn't possibly recommend your software to the average user as it is. Jungle Disk is presently for power users only. Anyone who doesn't want to, or hasn't the experience to dig through pages of settings and preferences cannot use this software reliably. It is visually unintuitive, the wizards are incomplete, the advanced settings all need tweaking right out of the box, and if an update comes down - God forbid you install it straight away: you might lose everything you've already done.
I hope you will take my experiences in this upgrade and the preceding criticisms to heart and make the kind of changes that would allow me to recommend Jungle Disk to friends, colleagues, and customers.
Yesterday my Jungle Disk Desktop software asked permission to update itself to 3.04. I allowed it. Because of this I spent half an hour recreating my backup set, reverifying my S3 information, and generally redoing and undoing everything the update did. This was a sloppy, mismanaged, poorly implemented, and unintuitive software rollout. Please consider all of the following.
You will surely agree that there is no situation in which any software update should wipe out all previous customization and user information, and yet that's just what this update did on my system. After the software updated itself and restarted the machine I was asked to enter my login information. It was poor timing that this coincided with your service outage yesterday, so I closed the program and waited for your website to go live again.
When I was again able to log in, my new Jungle Disk 3.04 asked for my S3 data again -- mind you this S3 data was known to my previous version of JDisk. Then it walked me through creating my backup job all over again, from scratch, as though it had never ever heard of me before; as though I hadn't done this very task when I first signed up! With all due aggravation I went through this tedious, and unnecessary process once more; again finding all the little check marks - invisible unless you click the "Advanced" radio button, hidden throughout the visually unintuitive Configurations tree - which describe my desired backup set.
"No, this is the only computer I use JDisk on, DON'T hit the server with a bunch of LIST requests every two minutes that I'll have to pay for at the end of the month." "No, don't store ten versions of every file that gets edited, 3 is more than enough for me." And so on.
When I complete the arduous and completely unnecessary task of resubmitting all my original preferences, I click 'Backup Now,' just to make sure that everything is working; to confirm that Jungle Disk still sees all those files it took me over a hundred hours, uploading to the Cloud at 90kbps, to begin with. To my complete lack of surprise, it doesn't! It wants to upload my entire backup set all over again!
Here is where I discover your new Vault format, and further that it is incompatible with your old Jungle Disk 2.0 file system. And, of course, if I'd like to use a Vault then I'll have to upload all my data all over again -- even though it's all right there in the same S3 account and could surely be moved laterally if your Dev teams were to invest that effort.
So, all the configuration I've just done is worthless because I'm not going to spend another whole week clogging up my bandwidth, uploading files that are already there! After reading the comments of some equally frustrated users at the forums I head back into the visual mess that is the Configuration tree, delete the Vault that JDisk just walked me through erecting, and again! again! go to work configuring my old Jungle Disk 2.0 archive. Again!
Thankfully, the JDisk 2.0 backup set recognized the files that were already in the Cloud and I plan to continue using 2.0 for some time hereafter. I have no interest in the Vault now, as it is the Vault that caused me all this trouble.
Summarily, when a user clicks "Update," they shouldn't have to worry that all their previous configurations will be lost, nor that their files might become stranded in a sudden obsolescence. And if you are rolling out a new format it should be stated over and over again in large font, on otherwise empty pages, that your current data will not transfer to the new format. "You will have to upload it all again." And thereafter the user should be given the clear two prong choice to upgrade to Vault or stick with JDisk 2.0.
Settings that I have used previously should follow me into a rollout of new service. If I didn't want to backup 10 file versions in JDisk 2.0, then I probably don't want to in JDisk Vault either! For that matter, you should have saved the configurations from my original backup set before the update and simply duplicated those selections for Vault service, if I wanted to use Vault.
I also suspect that had I just accepted the Vault transition and uploaded my data all over again, nothing would have been said about my old JDisk 2.0 data still sitting up there in the cloud, costing me $.15 per Gb, per month, for the privilege, and rotting away to no use. I'm guessing you don't have any system in place to notify or remind the user of the redundant data they'll end up storing after transitioning to Vault.
While I'm at it, I might as well add that I would like the option to update more often than once a week, without having to do so every single day of the week. Putting the scheduling option on a slider, like it is, instead of a series of checkboxes is plainly ridiculous. I don't know how you came up with that one.
I like your service. I like storing my backup in Amazon's Cloud. Your software has proven itself technically proficient, quiet, robust, and reliable. But this rollout was intolerable in every aspect. I couldn't possibly recommend your software to the average user as it is. Jungle Disk is presently for power users only. Anyone who doesn't want to, or hasn't the experience to dig through pages of settings and preferences cannot use this software reliably. It is visually unintuitive, the wizards are incomplete, the advanced settings all need tweaking right out of the box, and if an update comes down - God forbid you install it straight away: you might lose everything you've already done.
I hope you will take my experiences in this upgrade and the preceding criticisms to heart and make the kind of changes that would allow me to recommend Jungle Disk to friends, colleagues, and customers.
Windows Install Halts at 'Loading Files' or 'Inpecting Hardware'
The Problem
An HP 764c came in today for a new hard drive and a clean install of Windows 7. The install disc froze up early at the "Windows is Loading Files" screen. As soon as the status bar filled up all the way, the CD drive spun down, and nada.
After swapping out memory, graphics card, ribbon cables, dvd-rom, and disabling every bit of hardware I could at the BIOS, I finally tried booting a Vista install disc in place of Win7. It too froze at exactly the same spot. Then I tried XP. The XP disc halted even quicker at the "Setup is inspecting your computer's hardware configuration" line. At some point I tried booting a liveCD of Ubuntu. (a Linux OS) Ubuntu booted happily; I opened Firefox; browsed Newgrounds... Ubuntu was running like a champ. This made it seem like a Windows hardware issue -- presumably a hardware fault Windows couldn't deal with, but that Ubuntu didn't mind.
This would prove a red herring.
The Solution
In the end, having dismissed every piece of hardware that could possibly be at fault, I discovered the culprit in the form of a snapped heatsink mount. The heatsink was only half secured and apparently the CPU was locking up the machine as it overheated. I confirmed this by laying the computer on its side and applying pressure to the loose side of the heatsink with a screw driver. So long as I held it down, the installs all scooted right passed their earlier failing points.
Ubuntu threw me way off the scent for a good, long time. Having seen a non-windows OS load into memory, run applications, and shutdown - all without hesitation - had exempted overheating from my suspicions early on.
That Ubuntu managed to run on a system with an overheating CPU is perhaps a testament to its efficiency. I can only imagine that Ubuntu never put a significant load onto the CPU, even as it booted from ram, installed drivers, and opened applications. Where, in comparison, all three Windows discs couldn't so much as query the PCI bus without tipping the scales and torching the CPU.
HijackThis crashes on Event 1000 - msvbvm60.dll
The Problem
I've seen this twice now. HijackThis crashes after being open for a bit, to the tune of a nondescript error message. In Windows Vista: "HijackThis has stopped working." Sometimes you'll get a few minutes use out of it before the crash. Sometimes just a few seconds. Sometimes it won't crash at all. It's only ever a problem on a laptop (I think) and this time I encountered it on a Gateway M-2626u running 64-bit Vista.
The Details
The application error log reads like this:
Faulting application HijackThis.exe, version 2.0.0.2, time stamp 0x466838c1, faulting module MSVBVM60.DLL, version 6.0.98.2, time stamp 0x4791a724, exception code 0xc0000005, fault offset 0x0005d26c, process id 0x114, application start time 0x01ca43853341371a.
At first I figured there was a virus on the machine crashing HJT on a timer event. Wrong. I figured msvbvm60.dll had been corrupted and so I tried replacing it. No change. I finally noted that the application seemed to crash when I was dragging the scroll-bar or maybe resizing the window. With this in mind, I thought the video drivers were somehow the problem; 64-bit hardware drivers are always suspect. But again, no.
The Solution
In the end the culprit lie in the touchpad, or rather Synaptic's touchpad drivers. HijackThis crashes, for whatever reason, when you trigger a mouse-scroll event using the right or bottom edges of the touchpad. It's very difficult to come to this conclusion unless you are intentionally trying to scroll this way. I wasn't, but I must have been catching the edges of the pad as I used the mouse and triggering a scroll; that made it very hard for me to see what was causing the application to suddenly die at such odd intervals of use.
The file that enables the scroll functions in question is the "Synaptics Pointing Device Driver" at "Program Files\Synaptics\SynTP\SynTPEnh.exe"
Disabling it in the startup routine via 'msconfig' will prevent HJT from crashing, though it will also disable the scroll functions of your touchpad; something most people never use and that only gets in the way, anyway. (Much as it did here.) I say turn the thing off.
Slice() is a Lie!
Today I tripped over a long forgotten Actionscript woe: De-Referencing arrays. What'll happen is, you'll slice() yourself off a copy of some multidimensional array, then later you'll change one of the values of your duplicate only to find it isn't really a duplicate, and the original it was slice()'d from has changed as well.
The problem is that slice() and concat() apparently only make true duplicates of the top level of an Array. So when you slice() off a 2D array, you end up with a genuine copy of that array - sure, sure - but what you've copied is really just a bunch of shallow references to the original.
Here's some code to try and make sense of it:
Mind you that if you alter the reference itself, say by changing the value of heretical[0] rather than going straight down to [0][0], you will have replaced the path to 'sacred' and heretical[0] will be thereafter wholly independent from sacred[0], such that any changes to heretical[0][0] will nolonger be reflected in 'sacred.'
It's a really old problem in Actionscript made new again by the Vector class brought in with Flash 10 and AS3. The Vector class is, after all, little more than a type-specified Array(), and so it is subject to the same slice() and concat() pitfalls. But in practice it's easy not to think of your Vectors as Arrays and that's how I managed to butt heads with slice() again today.
Here's an example of the slice issue using the Vector class:
Once you get deep into your own code - when your eyes have glossed over from too much trigonometry and micromanaging nested loops - it may not be immediately obvious to you that your Vector.<Vector.<int>> is, at end, an Array containing an Array containing some integers, or Array[Array[int]]. And that any duplication of that top level array really only passes along the inner array, which is still just a collection of references.
I don't know why Adobe hasn't provided a deep copy method for Arrays by now. I understand that the issue presented here isn't really a bug; that slice() is doing just what it says in the livedocs: Returning "a new array that consists of a range of elements from the original array, without modifying the original array." And that the shallow-references we end up with are the "elements" of the original array, as stated. Still, how many people have to bump their heads on the ceiling before Adobe integrates a method of really, truly, no shit, deep-copying an array? I suggest Array.noShitCopy();
The problem is that slice() and concat() apparently only make true duplicates of the top level of an Array. So when you slice() off a 2D array, you end up with a genuine copy of that array - sure, sure - but what you've copied is really just a bunch of shallow references to the original.
Here's some code to try and make sense of it:
var sacred:Array = [ [0,1,2], [3,4,5] ];
var heretical:Array = sacred.slice();
heretical[0][0] = 99;
trace(heretical); //99,1,2,3,4,5
trace(sacred); //99,1,2,3,4,5
Mind you that if you alter the reference itself, say by changing the value of heretical[0] rather than going straight down to [0][0], you will have replaced the path to 'sacred' and heretical[0] will be thereafter wholly independent from sacred[0], such that any changes to heretical[0][0] will nolonger be reflected in 'sacred.'
It's a really old problem in Actionscript made new again by the Vector class brought in with Flash 10 and AS3. The Vector class is, after all, little more than a type-specified Array(), and so it is subject to the same slice() and concat() pitfalls. But in practice it's easy not to think of your Vectors as Arrays and that's how I managed to butt heads with slice() again today.
Here's an example of the slice issue using the Vector class:
var sacred:Vector.<Vector.<int>> = new Vector.<Vector.<int>>;
var heretical:Vector.<Vector.<int>> = new Vector.<Vector.<int>>;
var vInt:Vector.<int> = new Vector.<int>;
vInt.push(0,1,2, 3,4,5);
sacred.push( vInt.slice(0,3) );
sacred.push( vInt.slice(3,6) );
heretical = sacred.slice();
heretical[0][0] = 99;
trace(heretical); //99,1,2,3,4,5
trace(sacred); //99,1,2,3,4,5
Once you get deep into your own code - when your eyes have glossed over from too much trigonometry and micromanaging nested loops - it may not be immediately obvious to you that your Vector.<Vector.<int>> is, at end, an Array containing an Array containing some integers, or Array[Array[int]]. And that any duplication of that top level array really only passes along the inner array, which is still just a collection of references.
I don't know why Adobe hasn't provided a deep copy method for Arrays by now. I understand that the issue presented here isn't really a bug; that slice() is doing just what it says in the livedocs: Returning "a new array that consists of a range of elements from the original array, without modifying the original array." And that the shallow-references we end up with are the "elements" of the original array, as stated. Still, how many people have to bump their heads on the ceiling before Adobe integrates a method of really, truly, no shit, deep-copying an array? I suggest Array.noShitCopy();
Personal Antivirus and msxmlm.dll
Personal Antivirus (PAV) is a piece of spyware that's been going around for a while now in various forms. It's one of the many pieces of malware that tries to look like an anti-malware tool. It scams you by telling you that you've been infected (true enough) and that to get rid of the infection you should click here... buy this... enter your credit card numbers now... that kind of thing.
It's standard stuff; not too creative in it's implementation... Hell, you can kill the bulk of it just by deleting/renaming its folder under the Program Files directory. But two or three times now it has caught me looking. And that's maddening!
Even after I've checked every possible load point, cleaned and confirmed them all, I'll still end up with an 'about:blank' hijack in internet explorer that displays PAV's "you could be infected" malarky. And it drives me up the wall, thinking there's something about this uninspired little piece of junkware that is able to hide itself from my methods.
Well, I finally enumerated the culprit today. Mind you, I've always gotten rid of the infection in the past, but I never took note of how. I would simply get to that point of frustration where you throw everything you've got against the wall until one thing or the other snaps.
Now I know, and it's the simplest thing! A BHO (browser helper object) calling itself &Helper, I think, filename "msxmlm.dll". It was always there in my hijackthis reports, staring up at me innocently enough, hiding a dirty little secret.
I've looked at so many hijackthis reports in the last four years that I've grown to leave the work to my eyes. Anything they don't recognize is almost certainly evil. But c:\windows\system32\msxmlm.dll is such a reasonable file path; it's blends so well with the million other ms*.dll files in XP's library; and &Helper is such a familiar word-shape to see in a report, that my eyes skip it every time.
It's funny, because for years now I've been saying that these malware developers are fools to use randomly generated filenames, executables, and the like - all which stick out like a sore thumb in a start-up list - and that it would make it that much more difficult for the human eye to lay hold of them if they made a concerted effort to blend in with the regular expressions and operations of the OS.
Somebody heard me, I guess. And to my credit I was right. Give me a rootkit any day of the week. They're as easy to detect as flamingos on the moon. One little dll with an unambiguous filename tucked into the BHO list will foil me all the quicker.
It's standard stuff; not too creative in it's implementation... Hell, you can kill the bulk of it just by deleting/renaming its folder under the Program Files directory. But two or three times now it has caught me looking. And that's maddening!
Even after I've checked every possible load point, cleaned and confirmed them all, I'll still end up with an 'about:blank' hijack in internet explorer that displays PAV's "you could be infected" malarky. And it drives me up the wall, thinking there's something about this uninspired little piece of junkware that is able to hide itself from my methods.
Well, I finally enumerated the culprit today. Mind you, I've always gotten rid of the infection in the past, but I never took note of how. I would simply get to that point of frustration where you throw everything you've got against the wall until one thing or the other snaps.
Now I know, and it's the simplest thing! A BHO (browser helper object) calling itself &Helper, I think, filename "msxmlm.dll". It was always there in my hijackthis reports, staring up at me innocently enough, hiding a dirty little secret.
I've looked at so many hijackthis reports in the last four years that I've grown to leave the work to my eyes. Anything they don't recognize is almost certainly evil. But c:\windows\system32\msxmlm.dll is such a reasonable file path; it's blends so well with the million other ms*.dll files in XP's library; and &Helper is such a familiar word-shape to see in a report, that my eyes skip it every time.
It's funny, because for years now I've been saying that these malware developers are fools to use randomly generated filenames, executables, and the like - all which stick out like a sore thumb in a start-up list - and that it would make it that much more difficult for the human eye to lay hold of them if they made a concerted effort to blend in with the regular expressions and operations of the OS.
Somebody heard me, I guess. And to my credit I was right. Give me a rootkit any day of the week. They're as easy to detect as flamingos on the moon. One little dll with an unambiguous filename tucked into the BHO list will foil me all the quicker.
FLCL Desktop Background (1024x768)
It's been years now I've had this image for a desktop. It's 1024x768. I found it online. Someone had taken a screen-cap of the climactic moment in FLCL when <SPOILER>Takun and Haruko kiss</SPOILER> and superimposed the FLCL logo in the corner. I loved it.
But it was blocky and grainy; a bit washed-out; as you'd expect a screen-cap of a TV broadcast to be. So I took it into Photoshop and went to work smoothing things out, sifting the grain from the chaff and so on... finally adjusting the color to my liking. As I say, the result has been my desktop image for many a year.
I was just poking around at it, seeing <GAY>what other colors it might favor</GAY> and I figured I'd share it... posterity and all that, you know. Thus I present to you:
Here's the new color scheme I'm using after today's session. I find it especially soothing.
But it was blocky and grainy; a bit washed-out; as you'd expect a screen-cap of a TV broadcast to be. So I took it into Photoshop and went to work smoothing things out, sifting the grain from the chaff and so on... finally adjusting the color to my liking. As I say, the result has been my desktop image for many a year.
I was just poking around at it, seeing <GAY>what other colors it might favor</GAY> and I figured I'd share it... posterity and all that, you know. Thus I present to you:
FLCL - I Love You. (The Desktop Experience)
UPDATE
Here's the new color scheme I'm using after today's session. I find it especially soothing.
Roy Smash!!!
Monday, after work, I wiped out my computer. I had grown annoyed beyond comfort by all the little hesitations the machine had picked up in it's many years of tireless service. The worst of all these being upwards of a five second delay when opening certain folders containing certain files, whose associated icons, presumably, the OS took its time digging up.
And becoming bored with my present iconoclasm, I resolved to engage some fresh experiment with this hard drive's renewal. I would have three partitions. The first would be reserved for the operating system, and nothing else. The second would be a page-file area. I've kept a small 2Gb page file partition for several generations now, and I can only laud the practice, as it is the best thing for minimizing file fragmentation and preventing file corruption. The third and final partition, of course, would house the programs and data.
Not too brave, nor far flung a venture, this. Until, perhaps, I add this stipulation: The operating system I would resign to no more than 4Gb's space! Oh yes, now we're flying by the seat of our coattails, grandmama!
I have no idea if I'll be able to sustain my OS in just this tiny space. As of now I have removed the Program Files and Temp directories to the data partition via the registry. I have augmented Firefox to house it's cache there as well. I've deleted all the windows update uninstall directories. And these tasks completed, of my 4Gb's remains a scant 1.38 in which for XP Pro to breathe. Even as I type this I find myself looking over the registry to see what more of my "Shell Folders" might be hastened off the System drive to make room for those other slowly growing files that surely bid to burst the seems of this eensy cordon, some few months travel further down the garden path.
And what do I gain, you ask, by my mad venture; what have I earned for the added labors? Ha! Fools! You know nothing of my power. By which I mean to say that I don't get squat.
Sure, there's someone out there to argue the needfulness and benefit of a thusly isolated OS, but don't forget: Dr. Phil is prime time TV. By which I mean to say that there's at least one whack job to trumpet everything. Honestly, I can't say as there is a meaningful point to this particular of my chosen configuration except that it make me brain go shiny joy-fun time. I just like the idea of it, and so it is; so it has become at the irresistible force of my will's demand. So all shall soon become before the might of my awesome, all-enveloping singular consciousness.
...Puny humans.
And becoming bored with my present iconoclasm, I resolved to engage some fresh experiment with this hard drive's renewal. I would have three partitions. The first would be reserved for the operating system, and nothing else. The second would be a page-file area. I've kept a small 2Gb page file partition for several generations now, and I can only laud the practice, as it is the best thing for minimizing file fragmentation and preventing file corruption. The third and final partition, of course, would house the programs and data.
Not too brave, nor far flung a venture, this. Until, perhaps, I add this stipulation: The operating system I would resign to no more than 4Gb's space! Oh yes, now we're flying by the seat of our coattails, grandmama!
I have no idea if I'll be able to sustain my OS in just this tiny space. As of now I have removed the Program Files and Temp directories to the data partition via the registry. I have augmented Firefox to house it's cache there as well. I've deleted all the windows update uninstall directories. And these tasks completed, of my 4Gb's remains a scant 1.38 in which for XP Pro to breathe. Even as I type this I find myself looking over the registry to see what more of my "Shell Folders" might be hastened off the System drive to make room for those other slowly growing files that surely bid to burst the seems of this eensy cordon, some few months travel further down the garden path.
And what do I gain, you ask, by my mad venture; what have I earned for the added labors? Ha! Fools! You know nothing of my power. By which I mean to say that I don't get squat.
Sure, there's someone out there to argue the needfulness and benefit of a thusly isolated OS, but don't forget: Dr. Phil is prime time TV. By which I mean to say that there's at least one whack job to trumpet everything. Honestly, I can't say as there is a meaningful point to this particular of my chosen configuration except that it make me brain go shiny joy-fun time. I just like the idea of it, and so it is; so it has become at the irresistible force of my will's demand. So all shall soon become before the might of my awesome, all-enveloping singular consciousness.
...Puny humans.
Truly Write Protecting a USB Drive
No registry hacks required.
I came up with this solution after my thumbdrive fell victim to a 'Virut' infected machine at work. 'Virut' attached itself to two executables on the drive, so that running either of the programs infected whatever system my USB drive was attached to.
After cleaning my drive with AVG Free Anti-Virus I searched far and wide for a way to be make my USB drive read-only. I looked into mounting the drive as a CD under the ISO9660 standard; I thought of encrypting the drive's contents; I played with multiple partitions...
I'm saddened to report that there is no way to truly write-protect a USB drive at the software level, and so the method I present here is admittedly imperfect. Nonetheless it provides some real advantages. Further, it is the only portable solution you will find short of buying a USB drive with a write-protect switch.
The trick is to fill the disk space entirely. When the USB drive is full all write operations will be denied. Viruses will neither be able to infect existing files, nor create their own.
I found this concept here at Jared Heinrichs' blog. All credit is due to Jared Heinrichs for exposing this all-too simple method, used elsewhere in pay-software.
Using the command-line tool 'fsutil' included in windows we can create a dummy file that fills every last bit of free space remaining on our drive, thus securing it. For an explanation of how to do this manually, visit Jared's post.
As for me, I wrote a batch file to automate the job.
Copy the code above into 'notepad' and save it to your usb drive as 'readonly.bat'. Run it and answer 'y' to the prompt to create your dummy file. The window will close itself upon successful completion. To "unlock" your drive, just delete the readonly.tmp file it creates.
I've restricted the code from writing a dummy file larger than 1Gb. This is a cheap way to prevent fsutil from filling up your hard drive or some other disk, in the event the batch file is accidentally run from the wrong drive. Remember: The batch file must be run from the USB drive itself.
If your USB drive is larger than 1Gb you can change this value in the batch script on the line that reads
To change it to the exact size of your thumbdrive, open My Computer, right click the 'Removable Disk' that represents your thumbdrive and click Properties. Use the number listed as "Capacity" to replace the 1024000000 in the code, making sure to remove all the commas. Careful here! One too many digits and the size limit could end up being 20Gb instead of 2Gb.
The flaw in this method of protection is that nothing prevents the deletion of files. If a virus is so inclined it can still wipe out your thumbdrive the instant you connect it. And if a virus' author were sufficiently devious, he could write a sneaky little function that deletes a few adjacent files, freeing just enough space on the disk to place the virus or infect an executable.
The flipside here is that even virus authors have lives and I'm not aware of any virus that makes such a herculean effort out of anticipating a full disk.
It's a flawed solution. But it is the best we can do without a hardware fix. It's greatest virtue is how unlikely it is that a virus will infect the drive without the user knowing. A virus may remove and replace a file completely, but cannot easily infect one to keep itself hidden. It can delete files to make room for itself, but we have gained warning by way of our missing files.
To prevent the program from running on a large local disc, it would be better to evaluate the total capacity of the drive instead of the free space remaining. But I could find no reasonable method of gaining a drive's true capacity at the command line. At first I figured adding together the free space and the used space values provided by
As a computer repair technician, I'm satisfied with this solution for myself and I'm happy to recommend it. Though, if pressed, I recommend buying a USB drive with a write-protect switch even more.
I came up with this solution after my thumbdrive fell victim to a 'Virut' infected machine at work. 'Virut' attached itself to two executables on the drive, so that running either of the programs infected whatever system my USB drive was attached to.
After cleaning my drive with AVG Free Anti-Virus I searched far and wide for a way to be make my USB drive read-only. I looked into mounting the drive as a CD under the ISO9660 standard; I thought of encrypting the drive's contents; I played with multiple partitions...
I'm saddened to report that there is no way to truly write-protect a USB drive at the software level, and so the method I present here is admittedly imperfect. Nonetheless it provides some real advantages. Further, it is the only portable solution you will find short of buying a USB drive with a write-protect switch.
The Solution
The trick is to fill the disk space entirely. When the USB drive is full all write operations will be denied. Viruses will neither be able to infect existing files, nor create their own.
I found this concept here at Jared Heinrichs' blog. All credit is due to Jared Heinrichs for exposing this all-too simple method, used elsewhere in pay-software.
Using the command-line tool 'fsutil' included in windows we can create a dummy file that fills every last bit of free space remaining on our drive, thus securing it. For an explanation of how to do this manually, visit Jared's post.
As for me, I wrote a batch file to automate the job.
The Code
@echo off
REM * Written by: Roy Tousignant
REM * Date: May 19th, 2009
REM * URL: youfuckingpeople.blogspot.com
SETLOCAL EnableDelayedExpansion
ECHO.
SET sizelimit=1024000000
SET tmpfile=%cd:~0,1%:\readonly.tmp
FOR /f "tokens=3 delims= " %%A in ('dir \ /-c ^| find /i "bytes free"') DO (
SET freespace=%%A
)
IF /i %freespace% lss %sizelimit% (
IF /i %freespace% gtr 0 (
IF EXIST !tmpfile! (
FOR /f "tokens=3 delims= " %%A in ('dir !tmpfile! /-c ^| find /i "1 file(s)"') DO (
SET tmpfilesize=%%A
)
) ELSE SET tmpfilesize=0
SET /a freespace = freespace + tmpfilesize
ECHO Writing !freespace! bytes to !tmpfile!
SET /P okay=Okay?[y/n]
SET okay=!okay:Y=y!
IF !okay! equ y (
ECHO.
del !tmpfile!
fsutil file createnew !tmpfile! !freespace!
GOTO End
) ELSE GOTO Abort
)
ECHO Disc is already full.
GOTO Abort
)
ECHO Script detects more than !sizelimit! bytes of free space.
ECHO This script refuses to fill more than !sizelimit! bytes of space.
GOTO Abort
:Abort
ECHO The procedure is aborted.
ECHO.
PAUSE
:End
Usage
Copy the code above into 'notepad' and save it to your usb drive as 'readonly.bat'. Run it and answer 'y' to the prompt to create your dummy file. The window will close itself upon successful completion. To "unlock" your drive, just delete the readonly.tmp file it creates.
More Usage
I've restricted the code from writing a dummy file larger than 1Gb. This is a cheap way to prevent fsutil from filling up your hard drive or some other disk, in the event the batch file is accidentally run from the wrong drive. Remember: The batch file must be run from the USB drive itself.
If your USB drive is larger than 1Gb you can change this value in the batch script on the line that reads
SET sizelimit=1024000000To change it to the exact size of your thumbdrive, open My Computer, right click the 'Removable Disk' that represents your thumbdrive and click Properties. Use the number listed as "Capacity" to replace the 1024000000 in the code, making sure to remove all the commas. Careful here! One too many digits and the size limit could end up being 20Gb instead of 2Gb.
Limitations
The flaw in this method of protection is that nothing prevents the deletion of files. If a virus is so inclined it can still wipe out your thumbdrive the instant you connect it. And if a virus' author were sufficiently devious, he could write a sneaky little function that deletes a few adjacent files, freeing just enough space on the disk to place the virus or infect an executable.
The flipside here is that even virus authors have lives and I'm not aware of any virus that makes such a herculean effort out of anticipating a full disk.
It's a flawed solution. But it is the best we can do without a hardware fix. It's greatest virtue is how unlikely it is that a virus will infect the drive without the user knowing. A virus may remove and replace a file completely, but cannot easily infect one to keep itself hidden. It can delete files to make room for itself, but we have gained warning by way of our missing files.
Design Notes
To prevent the program from running on a large local disc, it would be better to evaluate the total capacity of the drive instead of the free space remaining. But I could find no reasonable method of gaining a drive's true capacity at the command line. At first I figured adding together the free space and the used space values provided by
dir \ /s /-c would work, but in testing the value of used space reported over 100k less than correct. The only other method I could find involved the wmic, which added an intolerable delay to initializing an otherwise simple script.End of Line
As a computer repair technician, I'm satisfied with this solution for myself and I'm happy to recommend it. Though, if pressed, I recommend buying a USB drive with a write-protect switch even more.
Embed Flash MP3 Players w/ Javascript
What it Does:
The code provided here finds any <a> tags on the page that have been assigned the attribute, name="mp3". Then, using the URL from the <a> tag, it generates and places the proper code, embedding a flash mp3 player just above that <a> tag's link. Unaltered, this script uses the "Maxi" mp3 player hosted and available for download at http://flash-mp3-player.net/. (Though you need not download anything to run this script.)
Why?
First: Convenience. With this implementation I need only create a standard link and give it a name. From there, my mp3 player will appear on it's own, without all the ubiquitous <object><param><embed> malarky typically required to embed a flash file.
Secondly, to enable a reasonable level of dynamism to my Blogspot hosted site. If and when someone designs a slicker or more efficient mp3 player or... let's say the mp3 player I've been linking to disappears from its server someday - I'd like to be able to fix the broken links and integrate a new player into my site without having to edit every single post in which I'd ever embedded an audio file. This javascript standardizes the website's mp3 player, so that changing the embed code in the script effectively changes the embed code everywhere on the site.
How?
<script type="text/javascript">
/*
-----------------------------------------------
Dynamic Flash Embedder (for Linking MP3s)
Written by: Roy Tousignant
Date: 15 May 2009
URL: tvopiate.blogspot.com
----------------------------------------------- */
var playerloc = 'http://flash-mp3-player.net/medias/player_mp3_maxi.swf'
function buildObj(mp3) {
var flashtags = '<object data="'+playerloc+'" width="200" height="20" type="application/x-shockwave-flash">'
flashtags += '<param value="'+playerloc+'" name="movie">';
flashtags += '<param value="mp3='+mp3.href+'&showstop=1&showvolume=1" name="FlashVars">';
flashtags += '</object><br/>';
var obj = document.createElement('span');
obj.innerHTML = flashtags;
return obj;
}
function addPlayers() {
var mp3objs = document.getElementsByName('mp3');
var i = 0;
while (i < mp3objs.length) {
if(mp3objs[i].tagName == "A") {
mp3objs[i].parentNode.insertBefore(buildObj(mp3objs[i]), mp3objs[i]);
}
i++;
}
}
window.onload=addPlayers;
</script>
Usage
If you're using Blogger add a HTML/JavaScript gadget to your layout and paste in the code provided above. It doesn't matter where in your Blogspot layout you place the gadget. It will work just the same.
With the code in place you simply create links to the mp3 files you want to embed, making sure to include name="mp3" in the <a> tag. You can do this anywhere on your page: in posts; in the sidebars; in the header...
<a href="http://www.mymp3host.com/song.mp3" name="mp3">Download my Song</a>
That's it. Any links you make that carry the name "mp3" will magically receive an embedded mp3 player one line break above the link, allowing visitors to stream the file right there.
More Usage
Changing the flash player will probably require some basic understanding of simple coding. It's pretty straightforward to those who know, but for those who don't I'll provide an example. (Be it any help to you or not.)
To change the mp3 player that is being embedded you just need to edit the 'playerloc' and 'flashtags' variables near the top of the script to reflect the object/embed code for the new player.
For example, Google has a flash MP3 player that can be linked to. To embed Google's player manually onto a page you would use this object/embed code:
<object data="http://www.google.com/reader/ui/3247397568-audio-player.swf?audioUrl=http://www.mymp3host.com/song.mp3" width="400" height="27" type="application/x-shockwave-flash">
<param value="http://www.google.com/reader/ui/3247397568-audio-player.swf?audioUrl=http://www.mymp3host.com/song.mp3" name="movie">
<param name="flashVars" value="playerMode=embedded">
</object>
Therefore, to integrate Google's embed code into our script you would replace the playerloc and flashtags variables in our javascript code with:
var playerloc='http://www.google.com/reader/ui/3247397568-audio-player.swf?audioUrl=';
var flashtags = '<object data="' + playerloc + mp3.href + '" width="400" height="27" type="application/x-shockwave-flash">';
flashtags += '<param value="' + playerloc + mp3.href + '" name="movie">';
flashtags += '<param name="flashVars" value="playerMode=embedded">';
flashtags += '</object><br/>';
Note here that Google's player looks for the mp3 location to be included in-line with the link to the audio player itself, whereas the Maxi MP3 Player being used by default expects the mp3's url to be declared in the flashVar param.
And that's all the hints you get. ...ya' bunch of noobs.
Design Notes
"Why did you use a while loop instead of a for loop," you ask? To avoid a bug in blogger's code. In development whenever I saved the script to Blogger's HTML/Javascript gadget, use of the for loop caused everything thereafter to be scrambled.
End of Line
I suppose that's it. Wow, it might've taken as long documenting it as it did writing the damned thing. And I was trying to keep it brief! Actually it took me about 10 hours, start to finish, developing this script; forced to learn all sorts of javascript functions I'd never worked with before; fighting the Blogspot bugs to make it work in the gadget... Well.
Do leave me a comment if you're using it. I'd love to see my handiwork gracing other sites. And if you have any problems with it... 'the hell do I care?
Subscribe to:
Posts (Atom)
