Friday, September 4, 2009

How to Disable Windows Automatic Restart After Updates

Tired of coming in to work in the morning only to find that all your work you forgot to save is lost because of an auto-restart by Windows during the middle of the night?

Me too.

Here's how to disable this major annoyance of Windows:


* In the Start Menu go to Run type “gpedit.msc” and press Enter

* Now a Group Policy editor will open. In this window navigate to: Computer Configuration -> Administrative Template -> Windows Components -> Windows Update

* Double click on No auto-restart for scheduled Automatic Updates installations

* In the settings window Choose Enabled and click OK

* Close Group Policy Editor


That's it.

Source: http://www.aviransplace.com/2004/12/18/tip-disable-auto-restart-in-windows-update/

Wednesday, August 19, 2009

Current Inflation

I heard this morning that inflation in Canada over the past year is at an alltime low of around 0.9% (or so, from memory). Seems a bit odd though that my rent and almost everything that I buy (food) has gone up around 5-10% at least over the past year.

One has to wonder what they are using to calculate the inflation rates around here, or if they ever buy anything at all. Damn lies and statistics, as usual.

Sunday, August 2, 2009

No cursor in Emacs 23 with -rv?

I just tried Emacs 23 for Windows and found a slight annoyance when run with the -rv switch: the cursor isn't visible!  A simple work around I found was to set the cursor color:

    M-x set-cursor-color

and then type 'white' when prompted for the new color.  To make this permanent, you can always add:

   (set-cursor-color 'white)

to your $HOME/.emacs file.

Saturday, January 24, 2009

lol

snarge (noun) : remains of a bird found on an aircraft after a bird strike
The engines of US Airways flight 1549 will be examined by the NTSB and
the snarge recovered for analysis. —Carla Dove, Smithsonian, National
Public Radio, Jan 16, 2009
Submitted by: Rick Hansen from Massachusetts on Jan. 22, 2009 12:21

Source: http://www3.merriam-webster.com/opendictionary/newword_display_recent.php

Thursday, December 18, 2008

Fwd: Sandisk Flash Card article

Don't Waste Your Time With Tying To Boot Sandisk Flash Cards
------------------------------------------------------------

I've wasted a number of hours recently trying to make a flash based
root Gentoo system on a Sandisk 8GB card using a nifty Flash->IDE
adapter I picked up from Ebay for ~$10. In summary, it doesn't work,
at least not for the Dell Latitude LS I was hoping to silence...[1]

It turns out that the card I picked up comes with a shockingly
non-standard 576 byte sector size (as opposed to the 512 bytes of
every other IDE drive on the planet that I have seen or known). This
causes the files stored on the drive to start on addresses which are
not multiples of the 512 bytes which causes GRUB to fail with the
informative 'Error 16' sometimes, or more frequently 'Read Error'.
More importantly, IT JUST DOESN'T WORK.

This phenomenon has been seen in the past when using reiserfs on your
boot partition (due to it's tail packing algorithm). Normally this can
be solved by mounting the partition using the 'notail' option; I was
using the normal ext2 so this was not the problem in my case.

So I am wondering, Sandisk, is there a reason for the 576 byte sector
size other than to completely screw up Linux boot loaders and keep
people from creating cheap flash based systems? Of course, I am no
flash chip design expert so there might be some technical problems
which require such an odd value, but I'm sure if I asked the company
I'd recieve no response...

I am pondering the option of pouring through the GRUB source trying to
find the trigger that hits 'Error 16' and removing it to see if that
might help it work but I haven't had the chance yet. If so I'll post
the results and the patch, but I feel that it could just be another
waste of my time hunting for multiple random occurences of hardcoded
checks scattered around code that has had too many people put their
fingers on it. Time to write another simple, modern boot loader?

Good thing I checked the return policy on the card before I bought it.
I'm taking it back and buying some winter boots, if I can find some.

[1] It did work on my other Compaq EVO so I am assuming that it is the
relatively ancient Phoenix BIOS that is the causing the problems. I
checked the Dell site and found that the A09 BIOS version was the most
up to date available for the system.


just something i wrote for myself that i thought i would share with...myself

---------- Forwarded message ----------
From: Burton Samograd <burton.samograd@gmail.com>
Date: Fri, Nov 14, 2008 at 7:05 AM
Subject: Sandisk Flash Card article
To: burton.samograd@gmail.com


Don't Waste Your Time With Tying To Boot Sandisk Flash Cards
------------------------------------------------------------

I've wasted a number of hours recently trying to make a flash based
root Gentoo system on a Sandisk 8GB card using a nifty Flash->IDE
adapter I picked up from Ebay for ~$10. In summary, it doesn't work,
at least not for the Dell Latitude LS I was hoping to silence...[1]

It turns out that the card I picked up comes with a shockingly
non-standard 576 byte sector size (as opposed to the 512 bytes of
every other IDE drive on the planet that I have seen or known). This
causes the files stored on the drive to start on addresses which are
not multiples of the 512 bytes which causes GRUB to fail with the
informative 'Error 16' sometimes, or more frequently 'Read Error'.
More importantly, IT JUST DOESN'T WORK.

This phenomenon has been seen in the past when using reiserfs on your
boot partition (due to it's tail packing algorithm). Normally this can
be solved by mounting the partition using the 'notail' option; I was
using the normal ext2 so this was not the problem in my case.

So I am wondering, Sandisk, is there a reason for the 576 byte sector
size other than to completely screw up Linux boot loaders and keep
people from creating cheap flash based systems? Of course, I am no
flash chip design expert so there might be some technical problems
which require such an odd value, but I'm sure if I asked the company
I'd recieve no response...

I am pondering the option of pouring through the GRUB source trying to
find the trigger that hits 'Error 16' and removing it to see if that
might help it work but I haven't had the chance yet. If so I'll post
the results and the patch, but I feel that it could just be another
waste of my time hunting for multiple random occurences of hardcoded
checks scattered around code that has had too many people put their
fingers on it. Time to write another simple, modern boot loader?

Good thing I checked the return policy on the card before I bought it.
I'm taking it back and buying some winter boots, if I can find some.

[1] It did work on my other Compaq EVO so I am assuming that it is the
relatively ancient Phoenix BIOS that is the causing the problems. I
checked the Dell site and found that the A09 BIOS version was the most
up to date available for the system.

Wednesday, December 17, 2008

Sunday, September 7, 2008

useanenum

Barry Schwarz 07 Sep, 09:04
Re: Increment a number in compile time macro
On Sat, 6 Sep 2008 23:54:08 -0700 (PDT), Bin Chen
wrote:

>switch(i) {
>case 1:
> break;
>case 2:
> break;
>[...]
>case N:
> break;
>
>}
>
>Now, after some time I want to add a 'case 2' between case 1 and case
>2, the result means every case number after case 2 need to be
>incremented by 1, it there a macro tricks to make life easier? Such
>as:
>
>switch(i) {
>case AUTO_INC_MACRO:
> break;
>case AUTO_INC_MACRO:

Macros don't perform calculations. They only perform text
substitution. And a subsequent appearance of a macro in your code
will not have access to the result of a previous appearance.

However, you can do what you want with an enum. Something of the form
enum {CASE1=1, CASE2, ..., CASEN};
and change each case label to
case CASE1:
...
case CASE2:
etc.

Later, when you want to insert a case between CASE1 and CASE2, change
you enum to
enum {CASE1=1, CASE1A, CASE2, ..., CASEN};
and insert the new block of code immediately before the CASE2 label.

To eliminate the rampant confusion after a half-dozen insertions where
CASE6 may be 7 while CASE10 is 13, I would suggest using identifiers
that are suggestive of the function to be performed rather than their
numeric value. Something like
enum {INSERT=1, DELETE, EDIT, COMPUTE};
and then you could later amend it to
enum {INSERT=1, DELETE, EDIT, PRINT, COMPUTE};

~/.history