In a 45-page document filed late Wednesday, IBM argues that because SCO distributed a version of Linux under the open-source General Public License (GPL), it can't claim that Linux software is proprietary. IBM also argues that SCO software violates four IBM patents and that the company interfered with IBM's business by saying it had terminated IBM's right to ship a Unix product, AIX.
IBM is seeking unspecified monetary damages and an injunction stopping SCO from shipping its software. The counterclaims came as part of Big Blue's answer to SCO's amended suit and were filed in the same federal district court in Utah.
That sound you heard was the other shoe dropping
]]>Do you know how to use a hammer? A screwdriver? A saw? Almost certainly you do. Does that mean you can build a house? Well maybe, but unless you have previous experience at building houses, I don't think I'd want to live in the one you built. Knowing how to use the tools is not the same skill as being able to build a house.
So why is it that so many people seem to think that knowing how to use a profiling tool means you know how to tune an application? For sure, having a profiler as opposed to not having one makes tuning much easier, just like having a hammer as opposed to not having one makes building a house much easier. But the tool increases your productivity, it doesn't enable the ability. You don't suddenly have the ability to build a house because you know how to use a hammer; you don't suddenly have the ability to tune an application because you know how to use a profiler.
That's a very good point. Another thing I see a lot of is assumptions - you get to a site where there's a performance problem, and the customers tell you (with complete assuredness) what's too slow. I find that 9 times out of 10, they haven't even run the profiler - they've just made a guess about the problem. However, the author of that article is correct - while profiling is useful, just using the profiler won't tell you everything. Sometimes you have to tune the memory configuration, and that only shows indirectly via profiling. There are plenty of other similar cases - and they vary by application/language/environment/platform.
]]>]]>Most people on this planet knows nothing about blogging. I doubt if more than 5% of Internet users know what blogging is. Stepping back even further, Internet users are only a small portions of the world population. If the world population was a pancake, Internet users are the top crust and bloggers are just a small tip of it.
The extends keyword is evil; maybe not at the Charles Manson level, but bad enough that it should be shunned whenever possible. The Gang of Four Design Patterns book discusses at length replacing implementation inheritance (extends) with interface inheritance (implements).
Good designers write most of their code in terms of interfaces, not concrete base classes. This article describes why designers have such odd habits, and also introduces a few interface-based programming basics.
Interfaces versus classes I once attended a Java user group meeting where James Gosling (Java's inventor) was the featured speaker. During the memorable Q&A session, someone asked him: "If you could do Java over again, what would you change?" "I'd leave out classes," he replied. After the laughter died down, he explained that the real problem wasn't classes per se, but rather implementation inheritance (the extends relationship). Interface inheritance (the implements relationship) is preferable. You should avoid implementation inheritance whenever possible
Hmm. Yes, you should avoid deep inheritance hierarchies. But Inheritance is a tool, not a problem. Maybe the problem is that Gosling and Holub aren't bright enough to know how to use it appropriately? Or maybe the locking they see in this comes from the combination with static typing.... Hard to tell, but clues are few and far between in this article. As often happens, Dave Buck has the best response to this silly article:
]]>The first few examples given in this article actually point to difficulties with static typing, not inheritance. Smalltalk is immune to these since it uses dynamic typing.
The "fragile base problem" (for the benefit of people who didn't read the article) is that subclasses require knowledge of how the superclasses are implemented. If the superclass changes, changes may be needed in the subclasses to compensate.
Subclassing does allow a tighter coupling between classes than normal which makes it more fragile. Good design style is to reduce subclassing by using delegation instead. Good design style is also to avoid deep class hierarchies. I wouldn't say that subclassing is evil, though. It's like saying that lots of people are killed in car crashes every year, so we should avoid cars. Often, the alternatives are worse than the problem.
This is similar to (although not as extensive as) the markup support used by WikiWorks, the VW Wiki implementation. In any event, it makes it easier for me to add things like lists and tables to my posts, without having to punch out the full set of html tags...
]]>IDGNS: Your study has raised some eyebrows in the open source community. Why so?
Spindler: Regarding such legal principles as liability and warranty, the GPL clauses have absolutely no legal validity. Under the license, developers and distributors of open software are not liable for any problems with their products. The GPL avoids any wording that could imply liability. Such a license is simply unenforceable under German, or even European Union law for that matter.
IDGNS: Your study points to potential risks facing a number of groups involved in the open source value chain: developers, software companies and users. So, really, just about everyone who comes into contact with open source software in one way or other should be careful, right?
Spindler: Not everyone -- for instance, users who don't modify the software or distribute it. However, in the software developer community, liability is an unresolved issue. Consider developers working on a program from different countries. The legal question is: What sort of company is this? Is each participant liable or the group as a whole? Or consider a project in which one developer starts writing code and then hands over that code to another who continues writing and hands over to yet another. In this successive approach to code writing, is the author responsible only for the code he or she wrote or for all code in the final software product? The answer may differ in each jurisdiction.
It's interesting, and there's more to read. Well worth reading and considering.
]]>It seems to me that IT professionals spend an inordinate amount of time debugging problems that can be traced back to an anachronism in the way applications are built. The anachronism is the notion that disk space is more expensive than the person-hour cost of the poor customer installing the application. That used to be the case but is not the case any more.
...In a world where a gigabyte of disk space costs less than a cup of coffee, why do developers regularly spend hours of expensive time (drinking multiple cups of coffee) in order to sort out problems that only exist because of a misplaced desire to save a gigabyte of disk space?
This is interesting. I hadn't given it a lot of thought, but there's something to this. I'll have to ponder this before I come to a conclusion, but it certainly made me think...
]]>When you first fire it up (last item on the Debug menu of the launcher), you'll see a list of user processes. Right off, you'll notice that any open workspaces are running in their own process - this is an aspect of the MPUI (multi-process UI) that was introduced in VW 7.1. The bottom line on that is that there is no longer a singular (distinguished) UI process - so a process spawned from a workspace during experimental development won't hose down the whole UI.
Pull down the View menu in the process monitor - there are three options:
Switch to the system view - you'll see the idle loop process, the Low Space process, and a bunch of other things. You'll note that these processes are mostly at very high priorities - and that most of them are blocked most of the time. This explains how your system can become unresponsive if you get into a thrashing GC loop - the Low Space process is running at a priority of 91! If you get stuck in that, it's very hard to break out. If you see that happening, you might want to look at my memory management posts [here and here and here).
Now go back to the user view, and pull down the Process menu. Everything will be grayed out - because you haven't selected anything. So go ahead - select a workspace process and pull the menu again. You'll now see that only the proceed menu pick is disabled - because the process you have selected is, in fact, running. Go ahead an select Debug - bam, you get a debugger on that process. Go look at the process monitor - you'll see that the state is now suspended. Go ahead and hit the run button in the debugger, and notice that the state changes back.
This is very useful stuff. Say you have a background process in an application you are testing - and you suspect that the process is having a problem. Previously, it was fairly difficult to get into that process and figure out what was happening - now it's simple. Just select the process in the monitor, and either debug it or terminate it (depending on whatt your needs are). This can still be hard if your process becomes CPU bound and is running at a high priority, but it's a highly useful feature - I've made extensive use of it in BottomFeeder development.
Another nice thing you can do is use the dump option. That will dump the current execution stack for the selected process to a file. With a little work on your part, you could easily include this capability in an end user application as a diagnostic tool. The View option does almost the same thing, but dumps to a window instead of to a file.
The last thing to look at is the sample time - by default, every 2 seconds the monitor looks at the current state of running processes. You can increase or decrease the frequency.
All in all, the process monitor is a very useful tool - if you haven't been using it, make sure that you take a look
]]>That should address some of the things I've been gettting bug reports on
]]>Enter an RSS feed and an aggregator - people who want the content subscribe and get updates as they happen, sans spam. Watch the switchover start to happen
]]>"Dave Winer has on a number of occasions pointed out namespaces and said that they break interoperability," said Ruby, the RSS alternative advocate, who is a senior technical staff member at IBM in Raleigh, N.C., and a director of the Apache Software Foundation. "His RSS spec points to a list of namespaces, and it's extremely selective. It includes certain ones and not others. It's extremely confusing. I don't know anyone who knows what is and is not acceptable."
Wow - no one knows what's acceptable, and yet there are scads and scads of RSS feeds, and more readers than you can shake a stick at. For something that is so terribly confusing, it seems that somehow, people interested in the technology have managed to get past the personality problems of a few people who can't seem to get along. This has very little to do with technology, and an awful lot to do with a bunch of overwrought individuals who can't seem to "just get along".
Don't think so - just have a look at this:
The alternative - still in search of a name after being known variously as "Atom," "Echo" and "Pie"--would closely follow RSS technically but have different specifications. Ruby and other proponents say it would most likely wind up under the auspices of a standards organization, probably the Internet Engineering Task Force (IETF).
The degree to which the proposed alternative mirrors the fundamental structure of RSS is an indication of how much the debate has become a referendum on Winer's ownership of the format, rather than on the technology itself. While Winer relinquished his CEO duties at UserLand last summer, he retains his seat on its board of directors and remains the principal shareholder.
The new format looks an awful lot like the old format, but with all the tag names changed for fun. Heck, adding support for this nascent format in BottomFeeder didn't require any new domain objects - every single "Atom" artifact mapped straight over to an existing RSS artifact. To make matters more interesting, "Atom" adds a "capability" that is just plain stupid - mime encoded binary data sitting in the feed. Just what I want - downloading the same large dataset over and over again until it ages off.
The problem with Atom is that it's trying to do too much - the group backing it is getting into classic over-engineering mode, and trying to solve too many problems at once. What we need is a new, cleaner API for managing blogs (posting, editing, etc.). What we are going to end up with is one more format that needs supporting. The simple question you have to ask yourself is, if you have an RSS feed now, what value add do you get by switching to Atom? Probably none. The most likely result will be a need to keep pumping RSS, and support for the new format. Yay
]]>