Posts Tagged ‘Linux’

« Older Entries

The Future of Linux

Thursday, June 19th, 2008

As a software developer, I get to see aspects of Windows, Linux, UNIX and Mac OS X of which end-users are oblivious. In previous posts, (for example, What Linux Needs to Learn from Windows) I have bemoaned the lack of standards between Linux distributions and the lack of system APIs. I’ve also praised Microsoft for delivering useful functionality in .NET (Programming is Fun [Again]).

Is Linux doomed to fail? Will Microsoft continue its hegemony?

If you read my series The Decline and Fall of Microsoft you know that I think Microsoft is facing some huge structural challenges. Nevertheless, here’s what I think is going to happen over the next 5 years:

  1. Microsoft will lose a large percentage of the general-purpose PC business to Apple. It will keep 50% or so, but mostly for dedicated workstations. Apple will take a majority of the laptop business.
  2. IT departments will continue to replace proprietary UNIX servers with Linux, especially given the move towards more virtualization.
  3. Windows will see an increased share of the server business driven by .NET and Sharepoint applications.
  4. Linux on the desktop will see minimal gains.
  5. Linux will dominate in the special-purpose, sub-notebook, business (such as with the Eee PC on which I am currently typing). Linux will also see increased use in some specific scenarios that require limited application availability.

All in all, I think there will be growth for Linux but it will actually lose overall composite share. I believe this for several reasons.

Although Linux is growing in the server business, I think that Microsoft will soon surpass its growth rate, if it hasn’t already (I don’t have my IDC numbers handy). Linux server growth is driven by UNIX-to-Linux conversions (i.e. new Oracle servers running Linux instead of Solaris) and by Apache server use. I think the former is a limited business and I think the latter is already limited by overall market growth. To grow share, Linux has to take away Windows server business, especially in the Intranet, and I don’t see this happening. Why? I think that Microsoft is winning the war for the hearts and minds of developers. Microsoft is an API company. Red Hat (except for JBoss) and Novell are not. Innovations in Linux API are mostly made by other companies (MySQL, Eclipse, Sugar CRM, etc.) and are often OS-independent. Microsoft, having totally stumbled on Vista, seems to have not screwed up Windows Server 2008, Sharepoint and SQL Server.

In the general-purpose, desktop/laptop business, Linux is missing Microsoft Office. In spite of the things I dislike about Office 2007, it’s still the Swiss Army knife of productivity software. Open Office is a poor, poor, substitute at any price. Even Office for the Mac is a poor substitute but it’s good enough. Workers who have the freedom to buy what they want (e.g. executives, technoids) will buy Macs. Vista is an embarrasment. I wish Microsoft would just port WPF and the new shell to XP, throw out everything else in Vista and admit its mistakes.

The only segment that I see Linux gaining market share is the specialty-use market. Sub-notebooks, like my Eee PC want to keep costs very low. This means they need an inexpensive OS that doesn’t require a lot of resources to run. Vista won’t cut it. Windows CE is too limited. I’d love to run Mac OS X on my Eee PC but I can’t without riling Apple’s lawyers. Linux is the only choice. Similarly, we’ve run into one or two companies that want to install Linux on a computer to use it only as a Citrix terminal. What’s weird is that they’ll be using Linux to run Windows applications via remote terminal services.

On the whole, this is not a very exciting future for Linux. There is still money to be made in the Linux business and Red Hat, Novell and others may be satisfied with the niches that I’ve described above. Personally, I find my prognoses somewhat depressing. I like Mac OS X but Apple’s walled-garden mentality is very 1980s. Microsoft still has a strong platform for software developers but I think that over time, their size and inability to execute will infect all areas in the company.

I wish that Linux was a better operating system than it is. I’d love there to be a credible alternative to the mess of Microsoft and the tyranny of Apple.

Tags: , ,
Posted in Business, Opinion Pieces, Technology | No Comments »

Sneakernet, revisited

Thursday, June 12th, 2008

In case you read my post, Email, the New “Sneakernet”, you might have been left wanting to know more about how to use Samba. There are plenty of sites and books dedicated to the topic, but here’s a quicky post on how to most easily use Samba.

To make your Linux, UNIX or Mac files available to Windows clients, do this:

  1. Make sure you have a reasonably recent version of Samba on your Linux, UNIX or Mac machine. 3.x is generally good; 2.x is not.
  2. Edit or create /etc/samba/smb.conf to look like this:

    3. [global]
    workgroup = WGNAME
    netbios name = MYMACHINE

    [SHARENAME]
    path = /PATHTOSHARE
    public = yes
    guest ok = yes

    Where WGNAME is whatever you want to use as your Windows “workgroup name”, MYMACHINE is your computer’s “netbios” (short, network) name — one that ideally matches your DNS name, SHARENAME is the public name of your “share” (for example, “BobsHomeDir”) and PATHTOSHARE is the file system path that you want to make available as that share (for example, “/home/bob”).

  3. After creating or editing the /etc/samba/smb.conf file, you must start/restart the smbd daemon. Do this with:

    4. /etc/init.d/smbd restart

    (Note: Different versions of UNIX, Linux and Mac OS X do this differently).

  4. To access the files shared in step 2, on your windows machine, type:

    5. net use * \\MYMACHINE\SHARENAME

    Replacing MYMACHINE and SHARENAME as needed.

Doing the reverse, accessing Windows files from Linux/UNIX/Mac is easier. You don’t need to configure anything or run any daemons:

  1. As above, make sure you have a reasonably recent version of Samba.
  2. Run the smbclient program from the command line. It’s arguments look like this:

    3. smbclient -U DOMAIN\\username //WINCOMP/SHARENAME

    Replace DOMAIN and username with the Active Directory short domain name and username of a user that has access to the computer whose files you’re trying to reach . Replace WINCOMP with the name of that computer. You can use its short, Netbios, name or its fully qualified DNS name (e.g. wfsshare or wfsshare.corp.mycompany.com). Replace SHARENAME with the name of the “share” on the Windows computer. Note the use of a double “backslash” when specifying the username and domain. When using the command line shell on Linux/UNIX/Mac, you typically need to type in two backslashes when you want one. The backslash is a special “escape” character and you need two of them to end up with just one. No kidding.

  3. The smbclient program will prompt you for the password of the username that you specified. Type it in.
  4. The program will display a prompt and wait for you to type a command. At this point, pretend you are in ftp. Use the ls command to list available files. Use cd to change remote directories. Use get to retrieve a file. mget is also useful because it supports wildcards. put and mput can be used to copy files from Linux/UNIX/Mac to Windows. Use bye to quit.

There is an alternative to using smbclient. You can use the “smb filesystem”. This approach lets you “mount” a Windows disk into the Linux/UNIX/Mac filesystem so that you can access its files like you would any local file. Here’s how you do that:

  1. Create a “mount point” in your file system. This is where you want your Windows files to appear. On Linux, the media directory is often used for flash drives and other transient “disks”. You might want to use it for this purpose, too:

    2. mkdir /media/fromwindows

    (Replace fromwindows with whatever you want).

  2. Use the mount or mount.cifs command to mount your Windows share to the mount point. I’d try the second form first:

    3. mount.cifs //WINCOMP/SHARENAME /media/fromwindows -o user=USERNAME,password=PASSWORD

    WINCOMP and SHARENAME are as used earlier. USERNAME and PASSWORD are the username and password of a user that has permissions to access the given Windows file share.

  3. If your system complains that it doesn’t know mount.cifs try this instead:

    4. mount -t cifs //WINCOMP/SHARENAME /media/fromwindows -o user=USERNAME,password=PASSWORD

If this doesn’t work, try substituting smbfs for cifs. If that doesn’t work, just email the damned files!

Tags: , , , ,
Posted in Interoperability, Technology | No Comments »

E-Mail – the New “Sneakernet”

Wednesday, June 11th, 2008

As you can read in my “About” page, I’ve been involved with computing for a long time. Although the industry has seen tremendous progress during that time, every once in a while, something comes along that makes me think it is still 1980.

In the early days of personal computing (about 25 ago), when IBM PCs and Apple IIs started appearing on corporate desktops but before “LANs” became commonplace, the term “sneakernet” was used to refer to communicating information by physically walking it over. You’d write out your WordPerfect file to a 5-1/4″ “floppy” (which actually was “floppy”) then stroll over to your intended recipient. Pretty simple.

Later, even this simple scenario was complicated by the advent of 720Kb, 1.4Mb and 2.8Mb 3.5″ floppies (no longer “floppy”) and differences between IBM and Apple formats. The Mac used a weird variable speed technique that the PC could not read.

Even when networks started showing up in office settings, sneakernet remained popular. Early networks required that file exchange be accomplished by writing the data to a “file server” and then having the recipient read it from the agreed location. Connecting to a file server required magic NetWare or LANMAN command-line incantations.

“Windows for Workgroups” and, later, Windows 95 made PC networking much easier. Meanwhile Apple had a very easy to use network based in AppleTalk, yet another example of Apple’s willingness/bias towards doing things their own way.

It did not take long for the industry to consolidate on standards. AppleTalk, like “token ring” and other competing protocols gave way to Ethernet. Netbios and IPX gave way to TCP/IP. For a while, file sharing was not too hard. Users could easily “share” folders or store things in their automatically shared Public folders and use these file file exchange. It was okay to wear dress shoes to work and leave the sneakers at home.

The arrival and broad adoption of the Internet introduced new challenges that reversed this trend. The Internet made possible the effective use of WANs (wide-area networks) and the connection of companies and company branches that were not normally connected in a private network. Sharing files through sneakernet, now, became impossible because sneakers would not get you from New York to Japan or Australia (at least, not without getting them wet). On the other hand, sharing files through simple operating system mechanisms also became (almost) impossible, mostly, due to security concerns.

Within their LANs, companies often have liberal policies regarding what type of network traffic is allowed to occur. File sharing protocols work within these corporations because the necessary TCP/IP ports are available and communication to/from these ports is permitted. Corporations typically separate their internal LANs from the external Internet by using firewalls. Firewalls are typically appliances (or dedicated computers running networking software) that control what type of information is allow to flow between the internal LAN and the external Ethernet. The TCP/IP ports required for file sharing are usually blocked by firewalls. No IT director wants random strangers on the Internet to be able to access computers in their corporate LANs and to read shared files.

The net result (no pun intended) is that sharing files across the Internet has gotten complicated again. Some companies will set up special FTP servers outside their firewalls. Others might use Internet “collaboration” web sites to facilitate file sharing. More often than not, I see people simply e-mailing files to each other. Crude but simple. The electronic equivalent of sneakernet.

Another thing that makes file sharing complicated even within a LAN is the use of different operating systems. Once again, Apple is involved here but, this time, it’s got plenty of company. Mac OS X is based on the FreeBSD operating system – a UNIX variant. Mac OS X has the same challenges that Linux and all flavors of UNIX (AIX, Solaris, HPUX) have. In order for these systems to “talk” to Microsoft systems, they have to do one of two things: they have to “look like” a Windows client to get data from a Windows server or they have to look like a Windows server so that Windows clients can get data from them. (FTP is, again, an option in LANs but a relatively painful one).

The Samba open source software can help with both of these. Samba, for example, provides the smbclient utility that allows UNIX systems to get data from Windows servers using an FTP-like interface (but without requiring the Windows servers to run any FTP software). Samba also provides the smbd service (daemon) that allows a UNIX computer to look like a Windows server so that it can be accessed by Windows clients.

Setting up a Samba server can be a difficult task, especially if you want it to be integrated with Microsoft Active Directory and to supports its user authentication features. There’s a great 700+ page book that describes how to do it. Nevertheless, there’s no better way to do this. If you’re willing to forego AD security, setting up Samba is a lot easier.

Beyond Samba, there’s also the “smb file system” smbfs and some commercial products to allow Linux and Mac OS X to act like a Windows client. Additionally, Apple and Linux vendors have begun to build such functionality into their standard graphical “shells”.

Perhaps, in another 25 years, we’ll have it all worked out.

Tags: , , ,
Posted in Interoperability, Technology | No Comments »

Get Mono

Tuesday, June 3rd, 2008

Wouldn’t it be great if you could write software that ran on Windows and non-Windows systems? Imagine if there was a programming language and a run-time system that supported object oriented programming and automatic garbage collection so that you could write software quickly and not have to worry about pesky memory pointer problems. Imagine, too, if that language came with an assortment of run-time libraries that let you write a variety of applications without having to call system-specific funtions. Wouldn’t it be great, too, if the language came accompanied by a first-class development environment with fast, incremental, compilation, a good editor and, most importantly, a great debugger?

Doesn’t exist. Sorry.

Java’s not it. Java promises to be this but it’s not. Here’s what’s wrong with it:

  1. Sun, and the Java community in general, wants to be so operating system independent that it wants to repeatedly reinvent the wheel. Instead of using JNI (the Java Native Interface) to call what are, for all intents and purposes, standard libraries (in our case, OpenLDAP, gssapi, and others) Java brings its own implementations of these, written in Java. Unfortunately, this means that Java libraries are always slower, slow to implement new features and more broken than their native analogs.
  2. Writing modern, web-based, Java applications is still dependent on which platform you choose to use: Tomcat, JBoss, WebSphere, Weblogic, Oracle Application Server, and more! All of these might be J2EE platforms but they’ve all their own unique architectures when it comes to security and other features.
  3. The Java run-time is huge. In our case (a product I worked on a couple of years ago), no degree of fussing with the Java run-time would get its virtual memory footprint below 200Mb when you added the classes needed web services. The physical memory use was around 50Mb which was a ridiculously large amount of memory for what was essentially a simple management agent.
  4. The Java UI classes (AWT, JFC/Swing) are complicated to use and result in applications that are uglier than their native counterparts. Admittedly, it is possible to write Java GUI apps that aren’t terrible (Eclipse, for example) but the fact that it’s so easy to identify Java apps by their contrast with native ones demonstrates the fundamental problem.
  5. Java is disliked by Microsoft and Microsoft is disliked by Javans!

This last point is important enough that it warrants further study. Microsoft dislikes Java because it can’t control it. I worked at Microsoft for 11 years (many of them, in the Developer Tools group). Control of APIs and how programmers write software is the single most important asset that Microsoft has. As long as Microsoft owns the hearts (at least, the minds) of the world’s developers it wields massive influence over the software industry.  Microsoft will continue to develop new APIs, tools and goodies for the developer community. Writing web services is ridiculously easy with .NET. Writing forms based application with .NET is equally so. Nothing comes close.

The Java community will generally scoff at .NET and have its own way of doing things. It will take longer to come to market and it will be almost as good. Except, maybe, the UI will look a little off and the Web services implementation won’t completely interoperate with .NET because Microsoft chose to not follow some specification exactly right. For the Java folk, being right is more important than being useful.

So, along comes Miguel de Icaza. If you don’t know Miguel, you should read about him right now. Miguel is a very, very, smart guy. He’s also a fellow Latino — an extra-added bonus. Anyway, Miguel gets the idea to implement .NET on Linux. Since Microsoft made .NET an ECMA standard, they had to document it! Miguel and his team developed a C# compiler and the .NET CLR (Common Language Runtime). They also implemented several of the other Microsoft libraries (including the 1.1 version of the forms library). They did this several years ago and released the Mono project.

The goals of Mono/.NET are similar to those of Java – provide an object-oriented programming system with automatic garbage collection and a set of useful libraries. The advantage of Mono is that it builds on what Microsoft is developing on Windows. You can write your apps for Windows, using Visual Studio for example, and then run them on Linux with Mono (you don’t actually even need to recompile them since .NET compiles source code to intermediate form and it’s the run-time that performs that final native compilation). The Mono run-time is smaller than the Java run-time and since all the necessary HTTP classes are available in the run-time library, it’s easy to implement web-services and web applications without having to bring in Tomcat, JBoss or some other application server. There is a small sample application, xsp, that demonstrates this.

Alas, like Java, Mono, too, fails to deliver the “holy grail”.

Miguel’s company, Ximian, was bought by Novell in 2003. While it’s easy to criticize Novell for not supporting Mono to a greater degree (Miguel has a small team), this is unfair. It is not easy for Novell to “monetize” Mono. The little money it makes off the product it uses to fund Miguel’s team.

Mono works but…for some things better than others. The .NET 2.0 libraries are still not complete. The Winforms libraries are still somewhat fragile. If you don’t have fonts that you can ship with your application it’s difficult to get the same application to look good on both Windows and Linux. Debugging Mono apps is still much, much, more complicated than debugging .NET apps with Visual Studio. A cross-platform debugging solution that allows Visual Studio to perform remote debugging of Mono apps would be killer.

In spite of its limitations, we’ve made great progress with Mono and have been able to port code from Windows to Linux. We’re still strugging with the Mac version and have not had much luck with Mono on UNIX.

Some (well, the Java folk) scoff at Mono. They whine that C# ripped off Java. They say they like Eclipse or IntelliJ better than Visual Studio. They think that supporting .NET is inherently bad because it supports Microsoft. Microsoft loves that kind of talk. Think about it: the pro-Microsoft people write good looking applications, in a very productive manner, that run only on Windows. The anti-Microsoft people write crappy looking applications, in a less productive manner, that run on Linux and, begrudgingly, on Windows (but require installing the JDK and lots of standard-and-OS-independent-but-not-friendly twiddling around). The net result is that users associate Windows with good looking applications and associate portable applications with poor aesthetics and unfriendliness.

Mono is a great way to attract developers to non-Windows systems. Let’s hope that Novell continues to invest (and to increase its investment) in Mono so that it can deliver on its promise.

Tags: , , ,
Posted in Interoperability | No Comments »

When Secure Systems Are Not

Sunday, June 1st, 2008

My company makes security software for UNIX, Linux and Mac OS X computers. Those of you not familiar with these operating systems might be asking why we don’t do this for Windows since it’s so often Windows that’s the subject of security flaws in the popular press. The answer is that is a bit more complicated than you might think.

A lot of our business is driven by security regulations. SOX, PCI, HIPAA and other laws/initiatives require that computers that are in scope employ adequate security measures. The cost of non-compliance can be signficant: shareholder lawsuits, criminal charges or, worst of all, increased credit card transaction costs. If a company fails to attain the top PCI rating, it can be forced to pay higher fees that can run into tens millions of dollars a year for large e-commerce firms.

A computer is considered in scope from the perspective of security regulations if it is involved in the processes covered by the regulation. For HIPAA, any system that stores patient data would be considered in scope. For SOX, any system that feeds data into corporate financial reports would be in scope.

It is not surprising to find many non-Windows systems in scope (or put another way, it is not surprising to find that a disproportionate number of in scope systems are running operating systems other than Windows). Since Windows is more frequently the target of hacker attacks and has more known exploits, companies like to use non-Windows systems for security critical applications, especially if the applications run “on the network edge” — they’re available on the Internet. By definition, e-commerce applications are on the network edge and PCI, particularly, brings a lot of non-Windows systems into regulatory scope.

Now here’s the kicker: for the most part, non-Windows systems employ terrible security practices!

What good is it that the operating system is well-written and tested if the root password is weak? How about if all the admins regularly login as root and, thus, all know its password? How about if adequate logging facilities aren’t available because everyone is logging in as root?

These hypothetical scenarios occur much more often than you think. Why? Because most companies do not have any centralized account management for their non-Windows systems.

Their Windows systems typically use Microsoft Active Directory (AD). Users login with their personal accounts and are granted special privileges by being made members of specific administrative groups. Files and programs are tagged with access control lists (ACLs) that only allow authorized users to access them. Windows and AD support group policy features that allow standardized security practices to be enforced throughout the corporation. Special audit ACLs can be defined to keep track of accesses to restricted resources.

These practices, for the most part, are completely alien to non-Windows systems. Although there are several LDAP directories (from Sun, IBM, Red Hat, Novell, others) that can be used for centralized account management, these are rarely implemented. Either they’re too expensive or they are too clumsy to use.

A few companies use NIS servers (developed by Sun) for this purpose but NIS is, itself, not secure and the “NIS replacement business” is also a healthy source of income for us.

There is no analog for group policy in the non-Windows world. Implementing standard security practices across all non-Windows systems usually means using manual processes and settling for the least common denominator solution. Some old versions of UNIX restrict passwords to 8 characters in length, for example, and disallow the use of punctuation marks. They may not provide any mechanism for forcing periodic password changes, for requiring strong passwords or for reusing recent passwords.

The Likewise Software solution is to connect these systems to Microsoft Active Directory and to implement a powerful group policy solution for non-Windows systems. We allow companies to connect over 110 flavors of UNIX, Linux and Mac OS X to AD and to use the same username and password on all these systems. We enable effective and efficient use of sudo to implement role-based access control and eliminate the broad use of root logins.

So, the next time you’re considering the security of your company’s computing infrastructure, look beyond the evening news and spend a little time thinking about how your own practices affect the vulnerability of your systems.

Tags: , , ,
Posted in Interoperability | No Comments »

« Older Entries