How to upgrade to a bigger SSD

Okay, on a 17" HP Envy, here's how to upgrade from a small SSD to a new SSD:

1. Make a Windows system repair disk via the control panel's Backup/Restore item.
2. Put the new SSD into an external USB case
3. Boot into a Linux live CD that supports your hardware, and dd the internal drive to the external drive.
4. Unplug the external drive, reboot back into Windows.
5. Now to extend the partitions on the new drive so you have your new C:. Plug in the external drive, run Easus Partition Master and move your rescue and tools partitions to the end of the drive and resize your C: partition on the new drive.
6. Shutdown the system
7. Remove the old SSD from the computer, replace it with the new SSD.
8. Boot into the repair disk. It'll then whine that your boot needs repairing. Let it.
9. Boot into the system, and then go to the control panel's 'System' item. Select "System Protection", then scroll down to the end of the list and you'll see something that says "C: (Unavailable)" that says System Protection is enabled. Click on it, then click "Configure", then "Disable".
10. Click your new "C:" partition, select 'Enable', then whatever percentage you want to enable for System Restore snapshots.

There you go. All done.

UDP or TCP for lossy networks?

So I was discussing video streams today and how typical video streaming protocols like RTP react to loss on the network -- i.e, by dropping frames -- and someone made the statement, "TCP would be better for lossy networks." He was wrong, of course. But I hear you saying, "but... but... TCP recovers from data loss!" Well, yes... if you don't care about timing or throughput, only about reliability. But if you're talking video streaming, TCP could result in loss of not only a few frames, but could result in loss of seconds worth of frames, or even cause video cameras, switches, or servers to crash.

At which point you're saying, "say wha?!" But here's the deal. If you lose a video packet with UDP, you lose a frame. RTP handles reassembling the packets into frames, if the next frame has come in and there's no packet to fill in slot X in the previous frame, RTP just throws the frame away. If you're getting 28 frames per second, you lose one frame out of that, big deal. Just replay the previous frame on replay, nobody will notice.

Now let's say you're using TCP. A missing packet occurs. TCP is expecting packet N... and doesn't get it. The TCP window goes SLAM at that point -- 4 megabytes of data backs up behind the missing packet as TCP tries to build its window and has a missing piece that it is waiting for, then TCP flow control assures that no more data is accepted until after the 1.5 second timeout causes a retransmit on the sender side. What this does is add 1.5 seconds worth of delay. You have a 1.5 seconds of delay, 4 megabyte window, and a gigabit Ethernet line, and what that means is that one lost packet every 1.5 seconds basically causes your gigabit Ethernet line to become a 21 megabit/sec Ethernet line. Congratulations, you just returned to 1985. And if you have 200 megabits/sec of incoming data, all that data is piled up in the network stack somewhere between you and the cameras, and you're in big trouble.

For streaming data, UDP thus handles a lossy network much more gracefully than TCP does. At least, that's true if you don't care about data loss due to redundancy in the data stream. I.e., frame 1000 in a video stream is very similar to frame 999 and frame 1001, so if frame 1000 goes missing it can be recontructed as simply the duplicate of the preceding or following frame. So what if you *do* care about data loss?

The reality is that if you *do* care about data loss, you're much more likely to get good results when streaming data if you use out-of-band data recovery. That is, if you've tried filling your frame, you already have packets for a couple more frames incoming, and you're missing a couple of packets, request packet retransmission directly via a NAK rather than wait for the sender to timeout waiting for an ACK. Thus *one* reason why most reliable multicast protocols rely on recipients proactively sending a NAK rather than time out waiting for an ACK before sending a packet. You can combine the two if you wish -- in this case, ACK would let the sender know that all packets in the frame were received thus it doesn't need to retain the frame in order to potentially service a NAK -- if you're really wanting both reliability and performance. But TCP doesn't do that. Which is why, on a lossy network, TCP is probably the worst protocol you could use for streaming data, and why the person who said "TCP is best for lossy networks" was wrong, at least for this application.

-ELG

The importance of strong product management

There's a lot of folks who whine about Windows 8, "Why did Microsoft have to change the UI? I like the old one!" The thing is, the old one simply isn't working well for a lot of people anymore. Hard drives have gotten so big, and people have installed so many programs on their systems, that the Start menu has achieved a depth that nuclear submarines would envy. Because the population is aging and eye-hand coordination is declining, both seeing all the tiny print on that Start menu and navigating it through several levels of sub-menus has become increasingly hard for a large percentage of the population. And finally, the Start menu paradigm simply doesn't work for tablets. If eye-hand coordination diving through the menu is an issue with a mouse, with a tablet touchscreen it would simply be impossible.

In other words, the notion that the Windows 8 UI change is all about "marketing" is pretty much nonsense. It's been well known that the Cairo user interface introduced with Windows 95 has reached its logical limits for quite some time, and ideas for changing the UI to meet the new challenges of the 21st Century have been floating around inside Microsoft for years, if a look at the Microsoft Research web site is any guide. I'm sure that Marketing told engineering, "we need a UI that will be usable on a tablet! And oh, make it usable on a desktop too!", but at worst Marketing merely hurried what was already in progress, rather than being a direct cause of the changes in Windows 8. The writing was on the wall for the Cairo UI, and sooner or later it would have been consigned to the dustbin of history regardless of Marketing's frantic panic about tablets.

So unlike a lot of people, I'm not surprised at all that Windows 8 has a significant shift in UI functionality. What I *am* surprised at is that it was done so badly. Microsoft has a lot of good people, and Windows 8 has all the raw tools in it to be a great operating system. Yet there's some needless complexities in its operation that shouldn't be there, and some important missing functionality that should be, such as IOS or Android style icon folders (without that, you're in endless sideways-scrolling territory to get all your most-used programs onto the start screen). So what gives?

In my opinion, the biggest issue with Windows 8 is caused by a clear failure of product management. Good product managers are hard to find because the job requires an understanding of customers at an intuitive level such that you can devise workable requirements to meet their needs, yet sufficient technical chops to understand what is doable and guide engineering toward producing the product that is going to meet those requirements. It also requires taste -- the ability to look at a product and say, "yes, that is tasteful and will please our customers" or look at a product and say "that is a pile of garbage, get it out of my sight until you do X, Y, and Z to it." Furthermore, product managers have to be empowered to be able to make those sort of judgements and have them stick. For better or for worse, Steve Jobs provides the template for what a strong product manager looks like -- opinionated, tasteful, with an intuitive understanding of the customer, with enough technical chops to understand what can be done, and power to make it stick.

Thing is, it's hard to find product managers like that because the geeks and nerds who typically run engineering departments wouldn't know good taste if it bit them on their bum, while the sales flunkees who typically run marketing departments wouldn't know technical chops if said chops bit off their ear. You almost need a Steve Jobs to do it. Unfortunately Microsoft doesn't appear to have a Steve Jobs to find good product managers, or if they do have good product managers, haven't empowered said product managers to make critical decisions about the product. Which is a shame. Because Windows 8 has a lot of good ideas, and the underlying technology is good. It just fails because of a lack of good taste (and courage, but see my prior blog on that), not because of a lack of technical chops.

Which just goes to show that putting out a great product isn't a matter of having great technology. It has to be a team effort, and if you don't have that, what you'll get is either a product that doesn't meet the needs of the marketplace, or a product that's far less great than it should be. Something to think about, if you're thinking about forming or joining a new startup. Do you have the kind of team that it will take? Does the company you are thinking of joining have such a team? Important questions, yet pretty much every startup I've encountered is all about the technology, and the rest of what it takes to have a great product is completely ignored. Which is probably why so many startups fail. So it goes.

-ELG

Adding certificates for Windows 8 Mail

I run my own email server and of course SSL-encrypt both imap and smtp, but have a self-signed certificate, not a certification authority signed certificate. Outlook has no problem with that -- it whines about the certificate, but then gives me a dialog where I can import it. Once I import it, fine. But I don't have Outlook installed on my Windows 8 evaluation for a variety of reasons. So I tried Windows 8 Mail and rather than offer to import the certificates, I got a message that I needed to contact my system administrator to import some certificates. Erm, I *am* my system administrator! Hrm. So...

My email server is running Debian "squeeze" Linux with Exim4 as the smtp server and dovecot as the imap server. The first thing I needed to do was verify on the mail server that there were valid (self-signed) certificates for both exim4 and dovecot. This can be done with:

• openssl x509 -in some.crt -text -noout

This will give you a bunch of information about the certificate, so you may wish to pipe it to 'less'.

The exim4 certificate was expired so I regenerated it with:

• /usr/share/doc/exim4-base/examples/exim-gencert --force

So then I located the two certificates:

• Dovecot - /etc/ssl/certs/dovecot.pem
• Exim4 - /etc/exim4/exim.crt

I downloaded the two certificates to my Windows 8 system via sftp and renamed the dovecot certificate from dovecot.pem to dovecot.crt . The next thing I did was open the Microsoft Management Console by pressing Windows-R and typing 'mmc'. I then selected Add/Manage Snapons, and selected to add the Certificates snapon.

Next, open up the Certificates tree until you see "Trusted Root Certification Authorities" and open it up to see "Certificates" underneath it. Right-click on Certificates and click "All Tasks" then "Import". Import your two certificates and there you are -- now all your self-signed certificates coming from your email server look as valid as any certificates, and are accepted by Windows 8 Mail just fine.

So, uhm... why does Microsoft make this so hard? I dunno, they're Microsoft, I guess. But the "ask your system administrator" is just BS, because Windows 8 Mail will *never* be used by anybody who actually has a system administrator other than themselves -- all businesses will be using Outlook Mail as their email client for a number of reasons. Oh well, just another example of how Windows 8 is half-baked and characterized by an utter lack of understanding of, well, actual customers.

-ELG