Thoughts on Linux hardware issues, etc

(originally I wrote this as a reply to a blog post, but because that blog has a horrible formatter I decided to expand it and post it here as well)

I have been using Linux (mostly Ubuntu and mostly at home) and Windows (mostly at work) for years now and I would probably use Linux full-time save, maybe, for games, although if a game runs on Linux I play it on Linux. My choice of Linux is purely practical. Simply put, I can work much more efficiently on Linux than I can on Windows. But enough about how much I like it, the problem is I keep hearing these complaints (or is it excuses?) about Linux that I find baseless. What is more surprising is that I hear them from computer-literate people, such as software developers. The rest might seem like another "5 biggest Linux myths" blog post, but in fact it is just a couple of notes I decided to take down not to forget them later and maybe use them as arguments in discussions.

1 - I find hardware compatibility hardly a relevant topic when comparing operating systems. I wish it stopped popping up at least in computer literate environments. If you are going to install Linux on Windows hardware, please do not expect that the install will go smoothly. Specifically, do not expect that sound, video or wireless will work out of the box. This is not a problem with Linux, it is just a fundamental law of computing that software must be compatible with the hardware it is running on. The same thing or even worse will happen to Windows when you try to install it on Linux hardware. Just recently, my brother got an Ubuntu laptop from System76 and tried to install XP on it. It wouldn't install until he patched some firmware on it. And then try installing Windows on anything that does not look like a standard PC. And then try installing Max OS on anything.

2 - A responder to a (blog) noted: "doing ANYTHING in Linux that becomes a 25-60 minute black hole". This is an utterly wrong statement. People usually apply this to hardware issues (in which case see point 1). However, once hardware issues are resolved (either by manual configuration or by buying certified Linux hardware) doing ANYTHING in Linux is a breeze. Of course due to exposure to such a vast repository of open-source software (of which maybe only 5% is of good quality) you will always install things that will not work as good you want. This brings me to my next point...

3 - Finding, installing and uninstalling software in Linux is easier than in any other operating system I have seen. This plays well with the huge amount of software available for Linux in that you can always install it, try it and uninstall it easily if you don't like it. No registry or program files leftovers will ever clog your system. Also thanks to advanced automatic dependency management programs take much less space, sharing many standard libraries. I have tons of stuff installed on my laptop and still have room for music and video on my 80 GB hard drive.

4 - Keeping your system up-to-date, and I don't mean just the OS, but everything installed on your system is incomparable. Linux is ahead of any other OS by orders of magnitude. Anything you install from a registered software repository (usually it's 99% of all your software) will be kept up-to-date with the rest of the system. Every now and then you are reminded that updates are available and these updates apply to your entire system: the OS (kernel), utilities, desktop manager, office suites, Apache, Firefox, well you get the point.

5 - This might be a matter of personal preference, but to me it feels much better to work on a system and to know that all it does at any given moment in time is what you asked it to do. There is no antivirus that checks every file you touch. There is no spyware and no spyware removers. Let's face it, no matter how clean your Windows system is, there is always some dark magic happening under the hood that for some reason: slows your system down, blocks you from performing normal tasks, crashes, automatically reboots without asking you first, etc, etc. When I copy/move/delete files I want the OS just do it, and since I still use Windows at work I am constantly reminded how much faster these basic operations are on Linux (from both speed and usability perspectives).

In conclusion I would like to reiterate that Linux hardware issues are overrated and irrelevant to discussions about features/usability/performance of the OS. What's worse is that the issue is magnified by the fact that most installations take place on foreign hardware and then the performance of the operating system is evaluated on that hardware. This is wrong. The question we should be discussing is 'When it does work does it perform better (from all aspects) compared to the competition or not?'

On Scala Language - First Impressions

A couple of days ago I started playing with the Scala programming language (http://www.scala-lang.org). I decided to document my experience with this language. I will be talking in Java terms, so if you see me referring to, for example, something 'static', think of Java's definition of 'static'.

Several things immediately caught my attention. The language is concise, type-safe, lacks a keyword for declaring 'static' and 'final' members, lacks 'throws' keyword (i.e. all exceptions are runtime), fully interoperates with Java and Java libraries, contains elements of a functional language.

Certain things pop up in a Java developer's mind right away after hearing the above (I tested it on some of my Java-savvy friends and on myself, of course):

• But how do I declare static variables and constants?
• Functional elements, ha. Are we messing with the 'return' statement again? If there's no return statement I don't wanna hear about it. (Then they close their ears and go: "Bla-bla-bla-bla...")
• Interoperates with Java as in JNI or somethin'?
• No checked exceptions? How come?
  

I will try to answer these questions right away as it is almost impossible to move on. Java developers have heard a lot about attempts to make a language concise, expressive, and so on. All was at the expense of type-safety (Python, Ruby, Groovy, etc). So their scepticism just keeps growing.

This example answers all the questions:

package scalatest

import java.io.File

object HelloWorld {

  def main(args : Array[String]) {
    println(message0)
    println(message1)
    println(message2)
    println(message3)
    
    this.message3 = "hehe"
    println(message3)
    
    /*
    This won't compile
    message2 = "hehe"
    */
    
    val f = new File(".")
    println(f.getAbsolutePath)
    
    if (false) {
      throw new java.io.IOException("Just a test")
    }
    
    println("Semi-colons at the end of an expression are optional too");
    println("But you can" +
              " still do multi-line "
            + "expressions")
    
    val a =
"""This might be useful sometimes too.
You can embed Python-style multiline strings like this one.
Looks ugly at first, but I can see myself getting used to it.
I don't think I will use it a lot though"""

    println (a)
  }
  
  /**
   * A method with a return statement
   */
  def message0 : String = {
    if (new Random().nextBoolean()) {
      return "Hello, World!"
    } else {
      return "Goodbye, World!"
    }
  }
  
  /**
   * A method without a return statement
   */
  def message1 : String = {
    println("This is definitely a multi-line method")
    println("Looks like return statements are optional")
    if (new Random().nextBoolean()) {
      // Hopefully future IDEs will mark the returned expressions automatically
      "Hello, World!"
    } else {
      // It's not that hard
      "Goodbye, World!"
    }
  }
  
  /**
   * A constant (i.e. equivalent of Java final keyword)
   */
  val message2 : String = "abc"
  
  /**
   * Not a constant, just a field
   */
  var message3 : String = "def"
  
}

Static Variables: Scala solves Java's problem with static members by dedicating a special construct for this purpose. It's called 'object'. 'object' is a class-singleton. In this example HelloWorld is an object, so everything in it is automatically static. This is good, because when you allow static members in your regular classes (as Java does) you run into problems with polymorphism. Scala doesn't, hurray!

Constants: Scala has a very elegant solution for constants. Constants are simply values (the keyword is 'val'). Java uses an oxymoron syntax declaring a constant as variable that doesn't change. However, we are used to it by now, so we don't look at it this way anymore, but Scala does remove a lot of code bloat by calling constants what they really are:

  val HELLO = "World!"

VS

  public static final String HELLO = "World!";

The 'return' statement: Scala does mess with the 'return' statement. The good news is that you can still use it. It is optional. Plus, because the language is type-safe the compiler won't allow you to return just anything. Plus, there is a good chance that an intelligent syntax highlighter will mark the returning expression.

Interoperability with Java: Looks good. I checked it by using a Java class in Scala code (see the example). The claim is that you can also extend Java classes and implement Java interfaces and use Scala classes in your Java classes. This was a very practical decision. Struts application in Scala, anyone?

Checked exceptions: Scala does not require you to catch checked exceptions, but you can still use them (see the example). There is no mechanism to declare thrown exceptions either. Checked exceptions is still a debate (http://www.mindview.net/Etc/Discussions/CheckedExceptions). I don't like them. Only Java has them. The rest of the world lives happily without them. I try to avoid them as much as I can. Documenting thrown exception is one thing. Fixing bugs because of swallowed exceptions or interpreting methods throwing Throwable is another. All of this is created by the psychological phenomena created by checked exceptions. So I am glad that Scala does not have checked exceptions (I can already see 50% of my audience leaving this web-site :).

So, Scala seems to have gotten right the things that I usually complain about in Java, and they did not have to sacrifice type-safety. Let's see if they've got everything else right...