QWANtify is excited to announce, effective May 1, 2010, their purchase by Safe Bridge Solutions, Inc. of Madison, WI. Read More »
Sometimes it’s much more interesting to just read the comments on Slashdot rather than the articles. Today is an article titled “Why Linux Has Failed on the Desktop” (http://linux.slashdot.org/article.pl?sid=07/07/24/1432245&from=rss). The comments are quite interesting.
Personally, I don’t feel that Linux has failed on the desktop. I think it’s just fine. There were all kinds of comments about the actual article about how the kernel is really built for servers which value high throughput over low latency, about how the desktop UI just isn’t responsive, how it can be a pain to configure devices, etc. These are all great points. But, I don’t believe that any of these things point to the failure of Linux as a viable desktop OS.
Part of the problem stems from the open source approach of Linux. The kernel itself is open source and most applications people use are open source. Because of this, there tends to be a do-it-yourself viewpoint of using Linux as a desktop OS. If you use Linux, you pretty much need to know it inside and out. Can there really be an easy to use version of Linux that performs and has the ease of use that other operating systems have? I’m not certain.
One of the unusual things about running Linux is that a distribution is just a bunch of different applications cobbled together in a semi-coherent manner using whatever packaging and distribution system the distribution creators decided to use. When you use something like MacOS or Windows, the vendor locks you into one specific desktop UI and their suite of programs.
I’ve used large Linux distributions in the past and got really turned off by them. Sure, they seem simpler and easier to use because they have all kinds of nice GUI programs with them, but they all turned out to be awful for me. Eventually they got all kinds of application crud on them that performed poorly and caused crashing issues. That’s why I turned to a distribution like Gentoo. Gentoo gives me the flexibility to install whatever I want, compile my kernel however I want, use whatever desktop UI I want. All of this adds up to machines that run fantastic.
I purposely compile my kernel to be low latency (it’s a configuration choice). I use a very minimal desktop UI (Fluxbox, I think it’s something like 4 MB in memory). The other Windows-esque UIs (KDE, Gnome) tend to be memory hogs and really heavyweight (much like another suite of operating systems from a company whose name starts with ‘M’ and ends with ‘T’). I have a 2 Ghz AMD box with 256 MB of RAM that Gentoo runs great on. Sure, loading apps is a bit slow, but once programs are up I have absolutely no problems speed-wise. Firefox runs fast, Eclipse runs fast, even running Win2K in Vmware runs faster than Win2K on a similar machine in my house where it’s the installed OS.
So, my feeling is that Linux is definitely NOT a failure on the desktop. Will Linux ever gain the kind of popularity that Windows or Mac have? Probably not. Maybe that’s OK, though. I’m fine with being one of a small minority of users that actually use Linux as their primary OS. I’m fine with dealing with the issues that come with being a Linux user. It’s not for everyone, that’s for sure, but I’m hoping to convince others that it’s OK to make the switch.
Filed in: Team Member Blog Comments (0)
Back in January of this year I became aware, through Laurie Benson a friend of mine and our corporate counsel Foley Lardner, about a national woman business award that was considering piloting their program through each state in the United States, beginning with Wisconsin.
Filed in: Company Insight Comments (0)
Why is it so important to encourage team building within an organization?
Filed in: Company Insight Comments (0)
I ran across a thread on Slashdot (http://science.slashdot.org/article.pl?sid=07/07/11/217218&from=rss) about the collection of glass photographic plates that is stored at the observatory at Harvard. It’s apparently about 25 percent worth of all the world’s currently existing photographic plates. There are over half a million of them covering the sky of both hemispheres with images from the past century. Definitely sounds like some very important history is stored in these photos, and they’re considering digitizing them for long term storage.
The problem is how to store the data for the long term. I don’t know about the best way to store glass photographic plates, but I’m not certain that anyone has come up with viable long term digital storage. It’s estimated that the total amount of data contained within these photos is a petabyte. That’s an enormous amount of data even by today’s standards. 1000 gigabytes is a terabyte. 1000 terabytes is a petabyte. There is a fascinating article at Wikipedia (http://en.wikipedia.org/wiki/Petabyte) about the petabyte.
I can certainly picture vast arrays of hard drives or stacks of optical discs, but for long term storage? Hard drives are prone to failure (although I do seem to have some ancient drives that still do the job), and today’s optical discs degrade in merely a few years. So what can we do to store information that is historical in nature? Hard copy? Back up data onto fresh devices every few years? I don’t have the answer. Hopefully someday someone will come up with the answer so we don’t lose things like books from the beginning of printing and these photos of the night sky.
Filed in: Team Member Blog Comments (0)
One of the things that I’ve been getting into lately is the usage of various code analysis tools as part of a standard build. There are numerous tools that can be very helpful when used as part of a continuous integration process.
One of the most common static analysis tools is JavaNCSS. It’s a simple tool and it doesn’t do all that much, but I think that it can be beneficial to use.
You point JavaNCSS to your source files and it will output the number of NCSS (Non-Commenting Source Statements) per package, class, and function. Just for kicks, it also calculates the CCN (Cyclomatic Complexity Number) for each function and displays the number of Javadoc comments per package, class, and function. Some of this may seem a bit useless and even pointless, but I think that there’s value to all the information that it calculates.
Most people would look at the number of lines of code and say “whoop-dee-doo!”. Yeah, it is kind of hokey. “Look! I coded 1000 lines today! Bonus time!” Seriously, though. The number of lines of code probably makes more sense to track at the function and class level. If the number of lines of code for a function is large or has been increasing over time, there might be an opportunity to take another look at that code to determine if extra functionality is creeping into the function that shouldn’t be there. If the number of lines of code in a class seems large, then perhaps the class has functionality inside of it that would be better in a different class.
The CCN can be used similarly. The CCN (aka, the McCabe Metric, http://en.wikipedia.org/wiki/Cyclomatic_complexity) is a number that describes the complexity of the code. There’s a whole complex discussion about it on the Wikipedia entry, but basically it’s a measure of how much branching there is in the code. If the number is low, then the code is very straightforward and does not have many decision points. If the number is high, then there are a lot of decision points (if/then/else statements, loops, switch statements, etc.). Generally, if the number is high for a method it could possibly be a candidate for refactoring. Take a look at the method to see if the decision points can be compressed together, or if some of the branching is unnecessary, or if the method could be logically split up into other reusable methods. Many times, however, despite a large CCN there is a reason the method is written how it’s written and that’s ok.
Lastly, I actually like the Javadoc counter. Looking at the counts per function makes it really easy to spot which functions are lacking documentation.
JavaNCSS is a nice little tool to help out with some basic static code analysis. It can be found here: http://www.kclee.de/clemens/java/javancss/
Filed in: Team Member Blog Comments (0)
Because I like to do strange things sometimes I thought it would be fun to start a Hello World archive. As I get interested in checking out other languages, writing a Hello World program is the first and easiest thing to program. I figured that archiving all the programs would be a nice thing to do as a point of reference.
I may expand the archive to include more advanced programs for comparison, but for now Hello World is a good start.
Feel free to check it out at http://tech.fradkin.com/helloworld/index.html.
Filed in: Team Member Blog Comments (0)
This is a subject you’re going to continually hear me harping about.
Filed in: Company Insight Comments (0)
My MATC IT mentoring is going well. For the most part, since February, we’ve met every other week.
Filed in: Company Insight Comments (0)