Why You Should NOT Ditch Windows XP

Nathan Bauman over at PCWorld had an article titled Why You Should Ditch Your Windows XP Laptop Right Now. This sort of pitch has always interested me after a fashion – the thinking just escapes me (as a personal Windows user). The reasoning for a corporate environment would be different, of course.

Here are the reasons Nathan lists for switching to Windows 7:

1. Windows 7 is easier to use.
2. Windows 7 is more secure.
3. Windows 7 supports disks with 4K blocks.
4. Windows 7 supports more than 2Gb memory.
5. Windows 8 is a disaster – so get Windows 7 before it goes away.

There are many reasons to stay with Windows XP for now. Be aware that I’ve not yet purchased my own Windows XP – I still have Windows 2000 for when I need Windows (which is almost never).

One reason is that Windows XP runs on virtually anything you can pick up – even one-year old and two-year old (gasp!) hardware. Requirements are 128Mb memory recommended and 1.5Gb disk on a Pentium at 233MHz or better. Windows 7 requires four times the memory, approximately 16 times the disk space, and four times the CPU power.

This variance in requirements leads to much lower costs for Windows XP hardware. A search on eBay for laptops with Windows XP shows a huge number of laptops for less than $300 – some as low as $120. These were laptops that presumably once sold for $1200 or $1800 or better. If we assume that a $300 laptop once sold for $1800, that is an 83% reduction in price from original retail – $1500 that stays in your pocket. New laptops with Windows 7 start at $350 or so for minimal systems; for a full-power system with Windows 7 it could be well over $1000.

The software itself is cheaper. Again, on eBay one can find Windows XP SP2 for $30-$40 whereas Windows 7 Ultimate is $75 and up – a savings of over %50.

Lastly, why buy Windows 7 now at retail prices when you can wait for Windows 8 – and get Windows 7 at fire-sale prices for hardware that by then will have lost 80% of its value. Just by waiting you can save thousands of dollars.

There is also the fact that a lot of software may not yet fully support Windows 7, and the software you count on the most may run only on Windows XP.

So now – that’s why you should stick with Windows XP (just remember to properly secure it!). Let everyone else spend their thousands of dollars and you can get their old equipment for a fraction of its original cost.

However, for an enterprise, the reasoning would be different – and the results might be different.

A Rift Opens Between KDE and GNOME

This is unfortunate indeed. KDE developers are accusing GNOME developers of not conforming to standards and not collaborating, and Mark Shuttleworth, founder of Canonical, expressed agreement with this view.

The focus seems to be directly related to something called appindicators – and to a larger degree, over the Ubuntu Unity desktop.

The argument goes like this: Canonical and KDE have in the past both approached the GNOME project with ideas, and have been shot down for poor reasons; GNOME refuses to collaborate on projects; others are working together and GNOME refuses.

You can decide for yourself whether this is valid or not. Blog posts have been erupting everywhere on this topic: Dave Neary of GNOME: Has GNOME rejected Canonical help? and Lessons Learned – Aaron Siego of KDE: collaboration’s demise – Mark Shuttleworth of Canonical: Internal competition is healthy, but depends on strong and mature leadership.

Over at OSNews, Thom Holwerda has two very informative pieces on the conflict – one on 10 March and one on 14 March.

Where this conflict will hurt the user is when the user chooses an application: will it work with GNOME or KDE et al? It will also hurt application development as the applications will have to choose – and many will have to choose one technology or the other (not both). This means that applications may only work on one environment or the other – or will have reduced capabilities in one environment or the other. It’s really too bad that the developers can’t come together and work together instead of conflicts like this.

Attachmate Snaps Up Novell (and SUSE)

Attachemate announced that they would purchase Novell for US$2.2 billion. This is good news – or seems to be, at least.

Attachmate merged with WRQ in 2005. WRQ was the company behind the Reflection for X product, which is an X server for Windows. Despite all the free and commercial competition, I always thought Reflection for X was one of the best available servers for Windows – and full-featured too.

Reflection for X has continued on since the Attachmate/WRQ merger, and the product seems to be healthy and vibrant.

I would expect – and hope – that SUSE Linux Enterprise Server (SLES) would continue and be invigorated with new life in the new corporation. We’ll see how this goes.

GNOME and Mono are also part of the transition, as I think I’ve said before. Being open source, they will likely continue if the original projects are hamstrung or crippled or shut down; however, my experiences with Attachmate suggest that there is a decent chance things will go well for the new SUSE and the new Novell.

Let’s hope so.

Update: GrokLaw has a fantastic article detailing all the legal maneuvers as well as a list of articles from elsewhere on the web. Turns out there is also two different shareholder lawsuits in progress: one from Kendall Law Group, and one from Brodsky & Smith. It also happens that the previously rejected Novell buyer, Elliot Management, will now be a shareholder in Attachmate as part of the deal.

This is interesting…

Intel’s New Upgradeable CPU: Not a New Idea – But is it a Good One?

There has been some discussion about the new processor from Intel which comes with some features disabled and unlockable only by purchasing an unlock code from Intel. Peter Bright has an excellent write-up on the idea of an upgradeable processor.

If you administer mainframes or enterprise servers, you’ve likely already seen this idea. HP Superdomes, for example, can be purchased with deactivated processors and so forth, then the processors can be turned on temporarily or purchased outright at a later date. IBM Z System also comes with a similar capability – often called something like Capacity on Demand.

The main question is whether the consumer will find this a desirable thing or not; it is possible that the idea will not sell. I find that system “upgrades” are actually done by replacing the system completely.

It is also probably a better idea to increase system memory than it is to upgrade to a faster, more capable processor. More memory means more can be done without going to disk, which is always important as disk is the slowest element.

VMware to Buy Novell’s Linux Business?

This is very interesting indeed. VMware and Novell just announced that VMware would sell SUSE Linux Enterprise Server on VMware’s vSphere product (with full support by VMware) – and now there is a report by the Wall Street Journal that Novell’s Linux business could be bought by VMware. Talks are continuing, but this is intriguing to say the least.

The focus is on SUSE Linux Enterprise Server, but Novell’s Linux “businesses” also include GNOME and Mono; it should be interesting to see what happens next.

Novell has been through some very rough times – first WordPerfect, then Netware, then UNIXware, and now SUSE. When SCO (not The SCO Group!) was split up, what was left was a shell of its former self; I hope that does not happen to Novell.

If VMware buys Novell’s Linux business, then SUSE would join Zimbra and SpringSource in the fold.

Let’s not forget, too, that VMware is owned by the storage company EMC. This could make itself felt in superior support for EMC products in SUSE Linux.

Personally, I feel better about SUSE being in the hands of VMware than I ever did thinking about Sun (and Solaris) in the hands of Oracle. I would also be surprised if some other company got SUSE instead; with the recent cooperation between the two companies VMware is the natural choice.

There was also the rumor that Attachmate would take on some of Novell’s other businesses. Attachmate has been good to the Reflection Suite for X that I like and recommend; perhaps Attachmate could be a good match as well.

Novell and VMware Team Up

VMware announced in June that Novell’s SUSE Linux Enterprise Server (SLES) will be shipped with every copy of VMware’s vSphere product. In addition, VMware sales staff will have incentives to sell SLES. During the recent sales call by Novell, they expanded on the details of the enhanced partnership.

According to VMware’s page for SLES on VMware, it also sounds as if current vSphere customers would be eligible for a supported copy of SLES as well.

This is incredible news – it means that SUSE may be able to gain some traction in the data center. I’ve been partial to SUSE in some ways ever since I found that XFS (and JFS!) had been supported in SUSE Linux for years before Red Hat did – SUSE has always supported technologies first, providing more value than Red Hat did.

I also supported SUSE Linux in the data center in the past; it has been rock solid (as is Red Hat). SUSE Linux has a lot to offer – as does OpenSUSE (which just recently introduced 11.3).

Red Hat has always done well – as it should – but SUSE has been in the shadows for too long.

It has also been noted that VMware could be a company that buys SUSE and Novell’s Linux business. VMware was bought by EMC not that long ago. Cisco also has a joint venture with EMC that includes VMware products. Is it possible that Cisco will be shipping products with SLES on them?

Canonical Kills Ubuntu Maverik Meerkat (10.10) for Itanium (and Sparc)

It wasn’t long ago that Red Hat and Microsoft released statements that they would no longer support Itanium (with Red Hat Enterprise Linux and Windows respectively). Now Canonical has announced that Ubuntu 10.04 LTS (Long Term Support) will be the last supported Ubuntu on not only Itanium, but Sparc as well.

Itanium has thus lost three major operating systems (Red Hat Enterprise Linux, Windows, and Ubuntu Linux) over the past year. For HP Itanium owners, this means that Integrity Virtual Machines (IVMs) running Red Hat Linux or Microsoft Windows Server will no longer have support from HP (since the operating system designer has ceased support).

The only bright spot for HP’s IVM is OpenVMS 8.4, which is supported under an IVM for the first time. However, response to OpenVMS 8.4 has been mixed.

Martin Hingley has an interesting article about how the dropping of RHEL and Windows Server from Itanium will not affect HP; I disagree. For HP’s virtual infrastructure – based on the IVM product – the two biggest environments besides HP-UX are no longer available. An interesting survey would be to find out how many IVMs are being used and what operating systems they are running now and in the future.

With the loss of Red Hat and Microsoft – and now Canonical’s Ubuntu – this provides just that many fewer options for IVMs – and thus, fewer reasons to use an HP IVM. OpenVMS could pick up the slack, as many shops may be looking for a way to take OpenVMS off the bare metal, letting the hardware be used for other things.

If HP IVMs are used less and less, this could affect the Superdome line as well, as running Linux has always been a selling point for this product. As mentioned before, this may be offset by OpenVMS installations.

This also means that Novell’s SUSE Linux Enterprise Server becomes the only supported mainstream Linux environment on Itanium – on the Itanium 9100 processor at least.

From the other side, HP’s support for Linux seems to be waning: this statement can be found in the fine print on their Linux on Integrity page:

HP is not planning to certify or support any Linux distribution on the new Integrity servers based on the Intel Itanium processor 9300 series.

Even if HP doesn’t feel the effect of these defections, the HP’s IVM product family (and Superdome) probably will.

Oracle Sues Google Over Java on Android

Oracle – now having purchased Sun – has sued Google over their custom Java virtual machine for the Android mobile platform. In doing so, Oracle has sent reverberations throughout the open source and Java communities.

Google took the Java APIs and enhanced and changed them – then created a virtual machine (called Dalvik) which runs a custom format executable. This was part of the Android software when it was introduced in November 2007, and there were many complaints about Google’s treatment of Java – including complaints from Sun itself. Google’s response at the time to Sun’s complaints was:

Google and the other members of the Open Handset Alliance are working to help solve fragmentation and supporting the developer community by creating Android, a mobile platform that responds to the needs of the developers, has the backing of industry leaders, and will be available as open source under a nonrestrictive license.

To break that statement down, Google was saying:

• The Open Handset Alliance (not the Java Community Process or JCP) should be the Java stewards for mobile Java.
• Android (and Android Java) responds to the needs of the developers.
• Android is backed by industry.
• Android is available as open source.
• Android is available under a nonrestrictive license.
• Java 2 Mobile Edition (J2ME) has none of these capabilities.

Don’t miss the fact that Google created the Open Handset Alliance at the same time, and serves mainly as a source for Android – though it has in recent days been seen as useless by some.

Sun (now Oracle) has had a mobile version of Java (known as J2ME) since before Android existed – but Google bypassed it (and the Java Community Process or JCP) when it created its own JVM. Dalvik executables, in fact, are created from Java binaries, thus involving Java itself in the process of creation and development.

It appears that Google’s Android Java implementation was a direct attack on the JCP and on J2ME. To use J2ME, Google would have had to license it, as it was not available under a license that would have allowed commercial closed-source development: it was under the GPL, but without the classpath exemption that the J2SE had. Because of this lack of the classpath exemption, any development on the standard J2ME platform would have to be released as source code under the GPL.

This action by Oracle fits perfectly into its public persona: consider that Sun’s Chief Open-Source Officer, Simon Phipps, was not even offered a position at Oracle at all. He is or was on the advisory boards for OpenSolaris, OpenJDK, and OpenSparc. Other distinguished Sun engineers have left, including Kohsuke Kawaguchi (chief developer of Hudson), Charles Nutter and Thomas Enobo (both lead developers of JRuby), Tim Bray (Director of Web Technologies – which includes Java and JRuby), and James Gosling (creator of Java). It is notable that all of these people except Simon Phipps are luminaries in the Java realm at Sun. It is as if the Java engineers left wholesale once Oracle was about to take over.

Coverage of the lawsuit has been extensive. Stephen Shankland over at CNet has a story about why Oracle may have chosen to sue. Stephen O’Grady over at RedMonk may have one of the best in-depth analyses of this conflict out there. Groklaw has committed to following the lawsuit through the courts, and has an excellent introductory piece on the lawsuit. Steven Vaughn-Nichols suggests that this lawsuit is only the beginning, and that JBoss, Apache Jakarta, and the JCP better watch out (though I disagree).

From when Google introduced Android and its associated virtual machine, Dalvik, Stefano Mazzochi had one of the most complete explanations of what Google was doing and its implications.

The Death of OpenSolaris Confirmed

Recently, I posted about the future of OpenSolaris and the lack of response from Oracle.

Oracle still has no official response, and has no word on where OpenSolaris is going. However, a memo to Oracle Engineering was leaked and then posted to the OpenSolaris Discussion mailing list (osol-discuss) and was later confirmed by an Oracle employee to the mailing list.

William Yang has a nice write-up on the memo and its salient points; in short:

• Oracle will no longer let OpenSolaris track Solaris development.
• Solaris code will stay under the CDDL license.
• “OpenSolaris” as a distribution will no longer be released.
• Code will only be released after Solaris is released.

Also interesting is Oracle’s reasons for closing down OpenSolaris:

• Not enough man-power.
• Releases Solaris technology to competitors.
• Prevents users from using Solaris.

Oracle has never been a popular company; most Oracle DBAs in my experience have never been happy with Oracle’s support or licensing, for example. This contrasts with Sun, which has always had a positive image.

In the area of open source, Oracle has always been a champion of closed source, in contrast with Sun which had been a positive open source champion. As a result of this, we are seeing more and more open source projects by Sun either closed down or changed into closed source: consider the closing of Project Kenai (a SourceForge-like site for open source projects), the fears over the future of MySQL, and the death of OpenSolaris.

The OpenSolaris experience under Oracle has echos in MySQL: Monty Widenius, the founder of MySQL, was quite vocal in his opposition to the Oracle purchase of Sun, and expressed his fear that MySQL would become closed source. Perhaps his experience with SAP and MaxDB had something to do with that – MaxDB had been released under the GPL through 7.6, when it was returned back into SAP and became closed source once again.

About the time that Oracle announced its purchase of Sun, Monty began the GPL-licensed version of MySQL, MariaDB which has taken hold, and the European Union mandated that MySQL shall remain dual-licensed. I wonder if MySQL’s fate would have been similar to OpenSolaris if it had not been for Monty.

It would be interesting to track the other open source projects now under Oracle’s umbrella:

• Java (and OpenJDK), and its add-ons
• Glassfish (J2EE)
• MySQL
• NetBeans
• Lustre file system

Oracle’s Plans for OpenSolaris Murkier than Ever

The controversy around the future of OpenSolaris has been building to a fever pitch these last few weeks, most recently leading to the creation of Illumos, a new open source kernel tree based on the open source portions of OpenSolaris.

Way back in July of 2009, Steven Vaughn-Nichols suggested that OpenSolaris would wither on the vine through deliberate neglect by Oracle – and this seems to be happening (whereas his prediction of the same treatment for MySQL and VirtualBox seems to be misplaced). Then in February of 2010, Ben Rockwood wrote an open letter to Oracle about the future of Solaris and OpenSolaris.

Oracle’s most recent response (during an interview with ServerWatch) has been to state that development on Solaris continues apace, and that Solaris 11 is due out by the end of 2011. Most notable was the lack of any discussion on the future of OpenSolaris.

A few months ago, the OpenSolaris Governing Board – in effect, the people in charge of the details of operating the OpenSolaris community and its resources – are willing to resign en masse if Oracle does not talk to them; Peter Tribble (a member of the OpenSolaris Governing Board) talks about this action in his blog.

I agree with those that say that Oracle can do what it likes, and the threat made by the board is empty – not because of the threat itself, but because it will accomplish nothing, and has no effect on Oracle. If Oracle wants OpenSolaris to go away, it doesn’t matter what the OpenSolaris community thinks. The Governing Board simply has no leverage with Oracle.

No word on how this action will affect Belenix; while Nexenta is basically the OpenSolaris kernel plus a Debian/GNU userland, Belenix is an OpenSolaris kernel plus a mostly Solaris userland. The primary founder of Belenix (Moinak Ghosh) is on the OpenSolaris board; one of the other developers (Sriram Narayanan?) blogged about the board’s action shortly after it was taken in July. Perhaps Belenix would use the Illumos kernel as well?

However, the prospect of OpenSolaris living on in the form of Illumos is promising, and technologies that are part of the open source OpenSolaris will not be lost. Nexenta has already stated its interest in Illumos; this is perhaps because Nexenta relies on OpenSolaris (with its now doubtful future) for its kernel. Thus, it is perhaps no surprise that a Nexenta engineer is the driving force behind Illumos, and neither is it a surprise that Illumos is currently a kernel only.

So now – how long before we see a Debian/Illumos project? Or is that Nexenta now?