Saturday, October 31, 2009

10 reasons why Windows 7 could fail

October 22nd is the big day for the official release of the latest iteration of the Windows operating system. Many have dubbed it the savior that will bring the glory days back to Redmond.

Many have said that it will pretty much wipe clean the foul stench left behind by Windows Vista. I, and a few others, think that Windows 7 will not be the success most pundits are proclaiming. How can I say that? I will give you 10 reasons why Windows 7 could easily fail.

1: It’s too much like Vista

I have yet to run into a PC user who actually likes Vista. Oh, there maybe a few scattered fanboys out there who have decided that Aero is the prettiest of all interfaces and that the User Access Control is the be-all-end-all of security.

The truth of the matter is, Vista is a horrible operating system. And what’s going to surprise the public is that Windows 7 is a lot like Vista.

Oh sure, Microsoft has made a lot of changes under the hood. But average users won’t know that. They will see the Aero interface and the UAC and turn their noses up at the latest offering. And why not? Microsoft should have made a complete 180 from Vista.

Instead of improving on Vista, it should have picked up XP (the best of the Microsoft OSes) and given it a boost to hardware recognition and maybe added a prettier interface.

Unfortunately, Windows 7 is going to suffer simply because it looks and acts too much like Vista.

2: It will cost too much
People are going to be turned off by the cost of the operating system itself, as well as the cost of the minimum hardware requirements.

Yes, if your hardware can run Vista, it can run 7. But most people are still running XP, and that hardware won’t cut it with Windows 7.

Last I checked, we’re still in an economy that has people cutting back. Having to drop extra scratch on both an operating system and a new machine is going to be at the bottom of the list for most people. And most businesses are still clinging to XP.

3: XP is still too popular
Picking up where #2 left off… Windows XP is still the king of Microsoft operating systems. According to a survey done in February 2009, more than 71% of all business machines are still running XP.

A Forrester survey had suggested that Windows Vista would overthrow XP as the business operating system of choice.

That never happened. And the only way Microsoft will pull XP off of business machines around the world is when it reaches its end of life for support.

But did that actually stop users from using Windows 2000 altogether?

No. In fact, some people are still clinging to that version of Windows. But overall, XP is still the keeper of the crown for Windows operating systems.

4: The editions are too confusing
Which version of Windows 7 do you want? Oh, you thought Professional sounded like the best, only to find it doesn’t have features you need… so maybe it’s on to Ultimate.

And Starter sounds like it would be a good version to start with — as in “new to Windows” or “cheapest version.” But no, Starter is for netbooks. So you have to look at it like this:
  • Starter is for netbooks.
  • Premium is for those who want next to nothing.
  • Professional is for those who need to work from home and office.
  • Ultimate is what Windows should sell and nothing less.
I remember when Vista came out. Trying to get the version that included my name nearly required the creation of a matrix or a spreadsheet, and still many people came out with the wrong version.

5: No upgrades are available for XP (and Europe)
Hello XP users, you can’t upgrade. Only a clean install for you. Which, of course, is smart anyway — but that means you have to pay full price.

And guess what, European countries: Because you won a suit against Microsoft that prevents it from shipping Internet Explorer with Windows, you get no upgrade version for Windows 7.

Yes Microsoft is going to offer EU the full version for the upgrade price, but that price will still wind up being close to the full version price, if history repeats itself.

6: It’s no good for netbooks
The Starter version of Windows 7 is a joke. Yes, Microsoft did remove the “three apps at a time” restriction. But there are other limitations (beyond the hefty hardware requirements) that make it a poor candidate for netbooks:
  • No streaming media
  • No desktop customizations
  • No legacy app support
The first point is the real killer. Because most users don’t want to clog up their limited drive space with multimedia, not being able to stream media means they won’t be enjoying their tunes while they work. Too bad, Windows 7 users!

7: Single sign-on apps will fail
As it stands now, applications using biometric, smart card authentication and/or VPN authentication will fail unless they’re upgraded.

This could be a bad problem if the applications were created in house, or if they aren’t upgradeable.

The real problem is that many of the companies that create applications that use (or depend upon) single sign-on have not made the leap to Windows 7 support.

So if a business depends upon single sign on, Windows 7 is going to be a big problem.

8: There are better alternatives
You knew this was coming. Both OS X and Linux have made strong headway in the market. With modern releases of Linux getting better and ever-more user friendly, the race is on to see what’s going to happen.

And every time Microsoft makes a misstep, it’s another gain for the competition. Windows Vista was a huge misstep, and it’s going to take more than a rework of that disaster to keep the competition at bay.

As more and more people become disillusioned with Windows, they’re going to look for alternatives. I have good news for you disillusioned Windows users: Ubuntu 9.04 is one of the most user-friendly Linux releases to date.

And with OS X Snow Leopard’s addition of Exchange support, Microsoft should really be concerned.

9: XP Mode may not help you
If you want to run applications that ran on Windows XP but not on Vista, you will have one solution — virtualization.

Here’s the problem: If you want to do this, you need a machine with at least 2 Gigs of RAM and a processor that supports on-chip virtualization. XP Mode consists of two pieces:

Virtualization software and a fully licensed version of Windows XP. Windows XP does not ship with Windows 7.

You will be able to download it for free if you have a licensed version of Windows 7 Professional, Ultimate, or Enterprise.

The big issue is the on-chip virtualization. Scott Woodgate, director of Windows enterprise and virtualization strategy, said this about which chips include virtualization support: “Some PCs have it and some don’t…

It’s not as clear as it should be relative to which PCs have support and which don’t.”

10: You’ll have to contend with DRM
Yes, DRM is the bane of users’ existence, and Windows 7 includes it. One little bit of DRM is a piece of code whose purpose is to ensure that no “prohibited device” is connected to the machine.

By “prohibited device,” I mean a device that could be used to record the output. Digital outputs are polled every 30ms, and analog outputs are polled every 150ms.

Other “features” also use or require DRM, and most of these are in place in case Hollywood needs them. In other words, Microsoft is giving the recording industry a bit of leverage against the user, should they need it.

This will not sit well with the user base, should it show its ugly head.

Your turn
Read enough to make you think twice about migrating to Windows 7?

Perhaps not. But with the Windows 7 pitfalls, one of these issues might bite you — making you wonder why you bothered to “upgrade.”

What’s your take on Windows 7? Join the discussion and share your thoughts.

Setting up your own DNS part 1: Getting started

For a caching-only setup then DNSMasq is better than this whole setup but I just wanted to view other alternatives too.
-------------------------------------------------------------------------------------------------------------
I have been playing with Linux for the last 15 years, but lately I have taken it to a whole new level. On my laptop I have set up a dual boot with Windows XP and Kubuntu, and after almost half a year of running this combination, I am amazed at how few times I have actually booted into Windows XP.

Had it not been for the video editing, the second part with Windows XP would not have existed. There are a few other programs I am using under Windows XP, but they are happy to run in VirtualBox without any need for rebooting.

I have had a server in the house on and off over the years, but after moving to Brazil, it became a real need.

The server is used for developing websites, testing different installations, caching updates for the workstations in the house, sharing files and sharing our laser printer as well as a number of other small things. It is also a way for me to learn more about networking, Linux servers etc.

Learning is also one of the reasons why I would like to set up a small caching DNS that also resolves the stuff.

I have on my local network. This task has been a challenge, but with the help of a lot of different online documentation, friends that have given me tips about this and that, I have managed to get it to a point where I can truly say it is working.

So I thought I would try to gather the information here, both to help others and for me to remember what I actually have done.


One thing has to be said loud and clear: This server is not exposed on the internet. It sits behind a firewall and is only used by us locally. No ports have been opened up for access from the outside and there is no need to update the rest of the world with the stuff running on our local network.

Before I started, I had to make a few decisions. One of them was that I wanted to use a real domain for this, so I chose to use a subdomain off my wisnaes.com domain – lan1.wisnaes.com.

This way, if I ever need to set up a lan at another site, I can simply name it lan2.wisnaes.com and avoid any conflicts.

But for the examples, I have substituted this with lan1.domainname.com so that nobody by accident uses my domain.

Other things I decided on either at the installation of Ubuntu server or before the configuration of the DNS:

Name of server: argoz
IP of server: 10.11.12.100
IP of gateway: 10.11.12.1
DNS1: 208.67.222.222 (OpenDNS)
DNS2: 208.67.220.220 (OpenDNS)

There are a few DNS packages to choose from, but I chose to go for bind9 as this seems to be the most common one and it can do everything from small stuff to really big stuff.

Installing it is as easy as typing
# sudo apt-get update
# sudo apt-get install bind9

on the command line. Follow the prompts, and you have the basic install with a standard configuration. Note that the install has to be done with sodu/root privileges. Either use sudo or become root temporarily.


Editing configuration files in Linux can be a daunting task for a person that is new to the whole concept. I do it when I have to and have done it a lot over the years.

But unlike some people that almost fall in love with the command line interface (CLI), I like it less and less as the time passes.

I prefer to use my time on other things than administrating and configuring the server. Once it is done, it should just work. And this makes CLI very difficult because I never remember the commands when I need them.

So I have to search the internet every time.

When I have to do it, my editor of choice is nano. So to edit a file, I type
# sudo nano filename.txt

The reason for the sudo is that most of the files that needs to be edited will be outside of the home directory and because of this, not possible to edit with normal user privileges.

Adding sudo and giving your password takes care of that.

Checking basic server configuration
First of all, it is a good idea to check that the standard stuff of the server has been configured correct after bind9 has been installed.

The first file to check would be the basic networking configuration on your server:
# sudo nano /etc/network/interfaces

Mine looks like this:
# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).

# The loopback network interface
auto lo
iface lo inet loopback

# The primary network interface
auto eth0
iface eth0 inet static
address 10.11.12.100
netmask 255.255.255.0
network 10.11.12.0
broadcast 10.11.12.255
gateway 10.11.12.1

Yours might differ, but this one should get you what you need.

Your server needs to know a DNS in order to look up requests. Of course, as you will have a DNS running locally, you just have to point it to itself.
# sudo nano /etc/resolv.conf
My server only has two lines here. One for the DNS, the other for the domain.
search lan1.domainname.com
nameserver 127.0.0.1

The hosts file could do the job as a simple “DNS”, but as we are setting up a complete DNS, it is better to keep it clean:
# sudo nano /etc/hosts

Something similar to this is ok, nothing else should be needed:
127.0.0.1       localhost

# The following lines are desirable for IPv6 capable hosts
::1     localhost ip6-localhost ip6-loopback
fe00::0 ip6-localnet
ff00::0 ip6-mcastprefix
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters
ff02::3 ip6-allhosts


The place for bind9 configuration files can differ a little between Linux distributions. On Ubuntu servers they are located in /etc/bind with the zonefiles placed under /etc/bind/zones .

The standard install of bind9 on Ubuntu server is to act as a caching DNS. But for this to work, you need to tell it where to look for an adress that it can not resolve locally.

So you need to edit a file called named.conf.options .
# sudo nano /etc/bind/named.conf.options

Here you have to add at least two DNS’es. I added the two from OpenDNS first, and then the two from my ISP just to be sure:
options {
        directory "/var/cache/bind";

        // If there is a firewall between you and nameservers you want
        // to talk to, you may need to fix the firewall to allow multiple
        // ports to talk.  See http://www.kb.cert.org/vuls/id/800113

        // If your ISP provided one or more IP addresses for stable
        // nameservers, you probably want to use them as forwarders.
        // Uncomment the following block, and insert the addresses replacing
        // the all-0's placeholder.

        forwarders {
             208.67.222.222;
             208.67.220.220;
             200.251.161.2;
             200.251.161.7;
         };

        auth-nxdomain no;    # conform to RFC1035
        listen-on-v6 { any; };

};
The zone files
Before we can start editing the zonefiles, we need to let bind9 know where they are. This is as easy as editing a file called named.conf.local .
# sudo nano /etc/bind/named.conf.local

Here you need to add the names for the zone definitions of your forward and reverse DNS lookups. The first one will be the name of your domain plus .db.

The other will be rev. plus the IP address of your server in reverse minus the last number plus .in-addr.arpa .

It is not as difficult as it sounds, but maybe easier to show you how mine looks:
//
// Do any local configuration here
//

// Consider adding the 1918 zones here, if they are not used in your
// organization
//include "/etc/bind/zones.rfc1918";

# This is the zone definition. replace example.com with your domain name
zone "lan1.domainname.com" {
        type master;
        file "/etc/bind/zones/lan1.domainname.com.db";
        };

# This is the zone definition for reverse DNS. replace 0.168.192 with your network address in $
zone "12.11.10.in-addr.arpa" {
     type master;
     file "/etc/bind/zones/rev.12.11.10.in-addr.arpa";
};

As the domain I wanted to use for my network is lan1.domainname.com, the zonefile will be called lan1.domainname.com.db.

And as my IP address for the server is 10.11.12.100, the reverse zone name will be rev.12.11.10.in-addr.arpa.

Creating these two files are as easy as editing them the usual ways:
# sudo nano /etc/bind/zones/lan1.domainname.com.db

Mine looks like this – I’ll do the explanation later:
$TTL 1h
lan1.domainname.com.      IN      SOA     argoz.lan1.domainname.com.   post.otherdomain.net. (

                                                        2009072804
                                                        28800
                                                        3600
                                                        604800
                                                        38400
 )

lan1.domainname.com.      IN      NS      argoz.lan1.domainname.com.

www             IN      CNAME   argoz.lan1.domainname.com.

localhost       IN      A       10.11.12.100

argoz           IN      A       10.11.12.100
aslan           IN      A       10.11.12.30
phoenix         IN      A       10.11.12.40
alambil         IN      A       10.11.12.50

As I am not an expert in DNS, I will stick to explaining the things you need to change to make it work. The rest, you can copy as it is here.

lan1.domainname.com. is the domain. Take extra care not to forget the last period!
argoz.lan1.domainname.com. is the full name of the server.


post.otherdomain.net. is the mail address to the administrator with a period instead of the @ sign on a different server.


2009072804 is a serial number that should change every time you change this zonefile. A very common way to do this number is to use the date in reverse order and a two digit number at the end.

In most cases, you will not need more than 99 changes during a 24 hour period.

I added a few special names to the list and I also added some of the other PC’s in the house just to be able to address them by name, not only by IP.

Also note – I do not have an in-house mail server (yet) so there is no MX record.

The last thing you need to do is to set up the reverse zone file:
# sudo nano /etc/bind/zones/rev.12.11.10.in-addr.arpa

Again, here is what this looks like on my server:
$TTL 1h
@ IN SOA argoz.lan1.domainname.com. post.otherdomain.net. (
                        2009072803;
                        28800;
                        604800;
                        604800;
                        86400
)

                IN      NS      argoz.lan1.domainname.com.
100              IN      PTR     argoz.lan1.domainname.com.
30              IN      PTR     aslan.lan1.domainname.com.
40              IN      PTR     phoenix.lan1.domainname.com.
50              IN      PTR     alambil.lan1.wdomainname.com.

After setting up the previous file, this one becomes a bit more clear. As with the other file, remember the trailing periods. And also remember to change the serial number if you open and change this file again later.

The last thing you need to do is to restart bind9 to get the whole thing to work:
# sudo /etc/init.d/bind9 restart

And then you can test your DNS with this command (substitute the domainname with your own):
# dig lan1.domainname.com

I am sure there are still errors in this setup, but it is working for me. I can do a dig and get a respons that seems to be ok.

Was this helpful? Any tips on how to improve things?

20 Linux Server Hardening Security Tips

This summary is not available. Please click here to view the post.