Saturday, February 14, 2004

Uncivil Union

Sometimes situations are too political to have a solution.


For those who have been more lucky than me and missed hearing incessantly about this saga, the Mass. Supreme Court ruled that the State had no ability to restrict marriage to one man and one woman. As I understand it, being neither from Mass. nor American, the reasoning behind this had to do with the setting up of a second class civil union status for other forms of marriage being unnacceptable under the state constitution.


So the whining and bickering and spitting and rock-throwing continues. And the weeping, hair-pulling and knashing of teeth on TV.


The religious folks feel quite put upon, after all. Ignore for the moment that the number of folks getting married is dropping like a stone. I can't be bothered to find actual links, but I hear that in the US the rate has dropped to 50% or so. In Canada somewhat lower. And in Scandinavia the rate of those living together actually being married is reputedly down around 20%. So marriage is under threat - not the threat that some seem to imagine these days, but the threat of disinterest in the institution of marriage or the institution of the Church.


But the religious right are so busy being belligerent about the whole thing they'll never never notice the real enemy.

Neither will they nor the politicians come to the obvious solution: take civil benefits away from those entering into non-civil unions.

Wouldn't that be easy?  This whole problem occurs because the State conveys rights and benefits to those entering into what is essentially a private relationship (marriage) conveyed by a private individual (priest). If the State only conveyed those rights and benefits to those entering into a civil union, then fine, straights could go down to the courthouse to enter into the civil union, and then wander over to the church to come clean with God. Non-straights could go down to the courthouse to enter into the civil union, and later go have whatever non-traditional ceremony they might want. And they can do so without reflecting anything at all on the sanctity of the private ceremony the church-goers believe is their duty to God.

And we all can stop worrying about people's private acts and private lives.

Well, except Michael Jackson's. *sigh*


For the record, I'm married, though I didn't get married until the US Immigration and Naturalisation Service (INS) required it of me. Happily, my partner was and is of the gender they appreciate. That is, not mine. Het privilege indeed.

[Comments from my previous blog]

1. a reader left...
Saturday, 21 February 2004 1:18 am
 
It's nice
chan [chan@hotpop.com]

Friday, February 13, 2004

Apples and Oranges

Those who have had the fortune (I waffle between good- and mis-) to work with me know I don't always take well to being asked the same stupid question more than twice. So in the hope of heading off a whole lot more unhappiness, I want to put this one to bed.


Why do people insist on asking whether J2EE technology performs better than .Net? Or scale, or have better up time, or whatever?


All these are useful measures of a product. And if there is one thing that Microsoft gets right in their marketing FUD against J2EE it is that ...


MS: "J2EE is not a product."


Me: Well Duh! It is a standard.


Not that Microsoft seems to know much about standards sometimes. So I'm a little unclear as to the point they are trying to get across with their 'not a product' criticism. There are over 25 products that implement that standard compared to what, 1 .Net? But I digress.


Performance and RAS (Reliability, Availability, Scalability) are great ways to measure and compare products, depending on your needs. And some product implementations of the J2EE standard will be optimised for different kinds of uses, and have RAS or performance or footprint differences that may help or hinder your desired deployment.


And that's what's so meaningless about making these sorts of comparisons to between J2EE and .Net this way. The scalability of an application server intended and optimised for small-footpring embeddable use is nothing to do with J2EE, it is a product feature.


The Honda Accord is much more nimble than a tractor, and keeps the rain off better than a motorcycle. Visit your local Honda dealer today.

Saturday, November 22, 2003

Thick or thin

Danno Ferrin blogged on the overuse of thin clients when sometimes thick are more appropriate. He describes a number of useful criteria to use when starting to think about which client style to use.

But he stops too soon. While he mentions at the end that WebStart is a new friend, he didn't attach this to thoughts on the scale of deployment. A lot of people use thin clients to avoid sneakernet install issues for think clients, but in reality JavaWebStart is solving this problem now for think clients.

But one of the larger problems in my mind, that Danno didn't mention, is UIs for which the data presented is driven by events other than the user. Stock trading consoles that want to display dynamically updating quote information. Power grid managment wants to display real-time loading, current,voltage, frequency samples. Sure you can solve these problems with auto-refresh, but that has its own cost in extra reads (solving for accuracy) or out of date data (solving for bandwidth). Not to mention that the actual data that is updated is way way smaller than the whole page refresh. Again, bandwidth.

Another case was a web calendar I was looking at lately. Setting up a group for cross referencing calendars to find availability, required flipping through piles of screens to find a person's calendar, go to another to add it to the group, go to the search again to find the next person. Came to something like 4 screens per person added. Each with HTTP page loading times. Took forever. Totally crazy. Compare to some fat clients doing similar things in one dialog.

Some thick clients are a joy to use, while their thin counterparts make me want to use another product.


[Comments from my previous blog]


1. a reader left...
Sunday, 23 November 2003 2:12 pm
 
Fat vs Thin is certainly a valid argument to have, but I think that most discussions rest of certain assumptions that dont have to hold true. The biggest of these is the assumption that every user action in a thin client requires a HTTP round-trip. Smart use of javascript and HTML makes it relatively easy to avoid these things - the web calendar you mention is a classic. The real argument there is, as Danno puts it, the amount of data coming down the pipe. In my spare time atm I'm working on a training diary aimed at rowers, available at http://training.coxless.com, which has a MS Money style interface to viewing a diary, and works (I think) very well.

Having said all that, there are plenty of times when a thick client works wonders - but the biggest argument from my point of view is the number of users. Having not too long ago finished a contract where a thick client was deployed to 60-70 users, and even at those numbers, deployment was an issue (mind you they refused to accept my advice regarding webstart).

Dmitri Colebatch
2. glen martin left...
Monday, 24 November 2003 10:18 am
 
Well, ok, there's javascript, but I think that is blending the two styles of interface. If there's behaviour running on the client, it can't precisely be called thin, can it?

Though I might be accused of splitting hairs here. Many seem to say thin when they really mean broswer-based. The problem is, if javascript (or whatever javascript alternative you care to name)isn't present or is disabled, what happens? True thin clients wouldn't have client-side behaviours.

But I think your closing thought perfectly underscores my thinking: Despite well known solution to the sneakernet problem, folks continue to choose thin vs thick for reasons of installation, rather than for more credible ones.

One reason of which is size of data in the pipe.

Given JavaWebStart, folks have the opportunity to make choices for more relevant reasons, which should in theory result in greater diversity of interfaces out there.

Tuesday, November 11, 2003

Derivation vs. residual knowledge

I am not a lawyer, and these comments do not constitute legal opinion, my own, my employer's, or any others'.
 
This post is not related directly and makes no comment on other timely happenings. I'm just following a train of thought.
 
I find myself wondering at the intersection of 'derived work' and 'residual knowledge'. SFAIK, on changing employment the future use of residual knowledge (eg. skills, not proprietary facts) is protected in at least some jurisdictions. LGPL source (to pick an example not precisely at random) is proprietary in the sense that there is an owner, and used under license.

But does 'derivation' require that the source be in front of you? Or that you are remembering the original source? Or thinking about it? Surely once you get to the point that your are remembering that laying out a solution using some pattern is useful, that is only residual knowledge, even if you conceptualised that pattern through looking at or hearing about some source.

Supposing residual knowledge rules could apply, and if only *some* jurisdictions protect residual knowledge, this could lead to a truly unpleasant situation in which *where* the code is typed becomes important. Blech!
The application of residual knowledge law in cases in which there isn't an employment contract is best left to those with more fortitude than myself.

Monday, September 15, 2003

Openness, public domain and SCO

Anne Thomas Manes was writing about various shades of gray in the openness of
Java and C#, and wrote [ed: this link is broken, Anne's old blog is apparently no more. Her new blog doesn't seem to have the old posts, reminiscent of my own blog migration pain.]

Public domain means open. It is the opposite of proprietary. Open source isn't nearly as open as public domain -- as illustrated by the SCO lawsuit regarding Linux. The fact that there is a license -- even an open source license -- means that someone owns the intellectual property in Linux. SCO is claiming that it owns some of that intellectual property, and it is demanding that companies pay for the right to use it.
While I think she has here and elsewhere in her comment accurately reflected the difference between public domain and proprietary,  the way I've taken her comment on SCO isn't quite accurate.

I'm not a lawyer, don't work for SCO or IBM, and don't play any of these
roles on TV.


While public domain is the antithesis of ownership, I don't think it would in any way have shielded anyone from the SCO lawsuit. Taking the SCO complaint at face value, just for the sake of argument: had some company, "HAL" perhaps, released code it licensed from SCO into the public domain, that
would in no way have protected HAL from SCO's wrath.

Nor would those who picked up the supposed public domain code have been protected. If I put stolen property on my curbside with a 'free' sign, you who pick it up still have received stolen property. Likely you wouldn't be charged for this unwitting act, but I would. And if you wanted to keep the stolen property, you could then be charged some fee.


The point here is that SCO's claim has nothing to do with the property having shown up in open source - it is to do with the property having been used by HAL outside of contracted context. SCO's ownership is the same no matter whether the contested use is open source, closed source, private transaction, employee theft, whatever.

I'm still not a lawyer.


[Comments from my previous blog]

1. a reader left...
Tuesday, 16 September 2003 5:25 pm
A de jure standard would make a huge difference in the SCO lawsuit -- except that Linux isn't a de jure standard. A de jure standard is public domain by law. Once the intellectual property is defined as public domain by an international standards body, no one can claim ownership of the IP. That's why the ISO standardization is such an important factor in regards to C# and CLI. Linux may be open source, but it is not in the public domain. This is one of the risks associated with open source -- your open source provider supplies no guarantee of indemnification if someone comes along and sues you for violating their IP. Hence SCO can sue any Linux user. This isn't possible with C# and CLI.

Anne Thomas Manes [amanes@burtongroup.com]
2. glen martin left...
Tuesday, 16 September 2003 6:40 pm
A standards body can try to put a technology in the public domain, but if the body doesn't own the technology in question it isn't then public domain. While there may be a difference for the end-user, for HAL or the standards body there would be some difficulty.

I believe there may be a situation along these lines with respect to some of the MS contributions to standards bodies like ECMA and W3C. If only portions of the standards are donated, the public domain release by the standards body isn't all that effective in permitting free (that is, unconstrained) use.
3. a reader left...
Wednesday, 17 September 2003 7:16 am
But that's the major difference between an international standards body, such as ISO, and a vendor consortium, such as W3C. W3C has no right to put technology into the public domain. W3C doesn't own the IP in the W3C standards. The vendors and/or people that contribute to W3C maintain their IP rights. Hence the recent controversy about royalty free and reasonable and non-discriminatory (RAND) licensing practices.

But ISO is different. Any technology contributed to an ISO standard must be donated to the public domain, and once the technology has been standardized, ISO provides indemnification (protection against lawsuits).

But I agree with you regarding your caveat about what portion of the technology is in the public domain. That's why I've been careful to say that only C# and CLI are international standards -- but .NET is a proprietary framework built on the C#/CLI standard. And that's why I'm suggesting that we really need a non-proprietary framework built on C#/CLI that has no IP-encumbrances from Microsoft. Currently, Mono has cloned a number of Microsoft-owned .NET classes (ASP.NET, ADO.NET, SOAP, etc.). I'm suggesting that a new set of frameworks should be built on top of the Mono base that aren't based on Microsoft-proprietary IP.

Anne Thomas Manes [amanes@burtongroup.com]

Sunday, September 14, 2003

Quote of the week

Responding to Bush's request to add certain terrorism-related crimes to the list of those for which the death penalty is available, Deborah Pearlstein of Lawyers Committee for Human Rights said

"When you're dealing with an enemy that has made suicide attacks its weapon of choice, expanding the death penalty seems like a particularly counterproductive proposal."

McNealy on California employment expense

There's a million rules that make the cost of operating here just off the charts.
Well, I said my industry was perhaps an exception in that services are not delivered primarily locally.  As usual, my blog is about my opinions, not those of my company. And sometimes it isn't even my opinion, just a thought experiment. This is perhaps a topic of greater divergence than others.