Google Finance is still using flash

Google Finance is still using flash...  In 2017.

Whaaaaaaaaaaaaatttttt?????

Fully lazy singleton in C++/CLI

Today I was trying to implement in C++/CLI the equivalent of the sixth Singleton pattern as shown here.

I liked the idea of using the Lazy class as it is fully lazy, and thread-safe, and very clear and simple.

I couldn't find any examples of anyone else doing it, so I gave it a go.  It took me a few minutes, but I was finally able to get it working:

ref class Singleton
{
public:
    static property Singleton^ Instance
    {
        Singleton^ get() { return m_lazy_instance->Value; }
    }

private:
    Singleton(); // Implemented in cpp

    static Singleton^ CreateInstance() { return gcnew Singleton(); }
    static System::Lazy^ m_lazy_instance = gcnew System::Lazy(gcnew System::Func(CreateInstance));
};

The secret was knowing to pass in a gcnew System::Func delegate to the System::Lazy constructor.

Note that if you naively create a System::Lazy using just the default constructor, it will compile but you will get an Exception at runtime because the Singleton constructor is private.

Windows 8.1 blurry scaling [SOLVED]

With a high-DPI display, you will likely have the display scaled to 125% or 150%. Windows may set it to this automatically (as the recommended setting).

Not sure if Windows 10 has the same problem, but on Windows 8.1 when you scale to 125% the default way, the text may appear dark and blurry.

Warning: Set your browser zoom level to 100% to ensure the screenshots below are not scaled by your browser, or else they won't look right!  Even better, right-click save each file and view them outside your browser!!

Here is an example dialog with no scaling (i.e., 100%):

Now if I set the scaling to larger (125%) as shown here:

Then the dialog looks like this:

The text is dark and blurry.  And no amount of adjusting ClearType will fix it.

But there is a very simple fix!  Check the "Let me choose one scaling level for all my displays", as shown here:

Then the dialog looks like this:

Viola!  Scaled beautifully and crystal clear.

Why does Windows choose an awful, blurry scaling over beautiful, clear scaling?  I realize that the default scaling is more advanced in that it handles displays with different DPIs by automatically scaling differently on each monitor.  But does that mean it has to be ugly?

Even if that were true, there is still no excuse for doing the ugly scaling when all of my monitors are the exact same size and exact same resolution.  Windows should detect that and choose to do the good scaling, just as if I had checked the "Let me choose one scaling..." checkbox.

This is why I really don't understand Microsoft.

Wake on Lan not working - Windows to blame

There may be several causes, including setting in the BIOS that need to be tweaked, but every time I have had issues with WoL, it has been due to a setting in Windows.

You might know already that to get WoL working, you have to go into the network adapter configuration and set "Wake on Magic Packet" to Enabled, and you might also need to set "Wake on Link Settings" to Forced (not sure).  Finally, you probably need to tweak the Power Management tab to check the "Allow the computer to turn off this device to save power" and the other checkboxes in here (actually, on the contrary, I actually had to uncheck this checkbox, which grays out the other two).

But what you may not know is that you have to turn off fast startup.  Windows must put the computer in a special sleep state with fast startup, one that does not allow WoL to happen.  Just guessing.  In any case, to turn off fast startup go to Control Panel -> Hardware and Sound -> Power Options, click on "Change plan settings", then "Change advanced power settings", then expand "Sleep" and "Allow hybrid sleep" and set it to Off.

Anyway, that's what I had to do to get WoL working.

Setting up Linux Router with PPPoE for CenturyLink DSL

There were two big gotchas, for me at least:

1. Ethernet packets must be in VLAN 201.
2. (a) Getting the right MTU and (b) clamping MSS to MTU.

Basically you just install and run ppoeconf, and it does everything for you:

1. configures /etc/ppp/peers/dsl-provider
2. modifies /etc/network/interfaces
3. starts up pppd

But then there are the gotchas.

Gotcha #1:

If the ethernet packets aren't tagged with VLAN 201, then your router can send out a PADI packet, but will never get back a PADO response from the DSL access concentrator.

My fix for the VLAN was easy.  The DSL modem I got already had a setting to make it tag ethernet packets with VLAN 201, but I didn't know that was required when I started, so I had to find this out the hard way.  If your modem can't do this for you, I know there is a way to set up a virtual interface named eth0.201 for example, but I've personally never done it.

Gotcha #2a:

pppoeconf pretty much takes care of this for you, setting the MTU to 1492 by default, which really should work, but after some ping testing and whatnot, I determined that for me I needed to set it to 1484.

So this is what my /etc/ppp/peers/dsl-provider looks like (with all comments removed):

noipdefault
defaultroute
hide-password
lcp-echo-interval 20
lcp-echo-failure 3
connect /bin/true
noauth
persist
mtu 1484
noaccomp
default-asyncmap
plugin rp-pppoe.so eth1
user "myppoeuser@qwest.net"

Gotcha #2b:

pppoeconf actually handles this for you as well, by creating a file in /etc/ppp/ip-up.d named 0clampmss with this firewall rule:

iptables -t mangle -o "$PPP_IFACE" --insert FORWARD 1 -p tcp --tcp-flags SYN,RST SYN -m tcpmss --mss 1400:65495 -j TCPMSS --clamp-mss-to-pmtu

Without this, some websites might work and others might not.  Some might load partway, etc.  That's what was happening to me, and I finally realized the problem was this rule had gone missing.  It was because I have my own firewall script that I had run, which flushes all the chains and adds just the rules I want.  So I needed to add a rule for this to my firewall script.