Archive: June 07, 2002
The title says it all. I'll have an example URL here once I restart my computer.
Goooooooood fooood tonight. Tawara - sushi and sashimi platter. Drool, soooo goood.
I'm trying out The Bat right now. It's pretty neat. Anyone ever try The Bat or have any opinions about e-mail programs other than Microsoft ones? Are there any e-mail progams that are cross platform?
Slashdot: Moshe Bar on Programming, Society, and Religion. I found this part about database clustering most interesting.
There have been talks with the DB2, Postgres, SAP DB and various other DB technologies. All their proprietary clustering technologies (in particular DB2's and Oracle RAC's) are bound to show very poor scalability and TOC. In the openMosix model, you install one DB2 or one Oracle 9i on one machine and - assuming we have finished implementing Distributed Shared Memory, something which we plan to do - then the processes making up an instance can migrate away to other nodes and make more room for a larger DB block caching area. All that happens transparently to the RDBMS under openMosix because we implement the clustering layer within the kernel and therefore all applications, whatever they might be, benefit from it.
Under Oracle RAC, for example, you need to install the RDMBS on everynode being part of the RAC cluster. If you need to apply a patch and that process takes, say, 2 hours, then the whole patching downtime to the DB will be 2 hours x n nodes. Also, in openMosix we are soon goin to implement Dolphin support, allowing us to copy a full 4KB page from node to node within 14.4 microseconds. Something like Oracle will immediately benefit from the cluster-wide ultra-low latency. If not in kernel space, then every application vendor would have to write his own driver, possibly conflicting with other applications trying to do the same on the same machine. In short, doing clustering at the DB application level is essentially flawed.
Network RAM is simply allowing mallocs or swap-outs to be done to the RAM of neighboring cluster node rather than to physical swap space on disk. In order to run databases under openMosix we will need to implement distributed shared memory. Due to the exceptional complexity of this project, I do not assume to have a valid implementation before the end of 2004.
And most distressing:
I am studying law because at my age I already see how much faster younger programmers are than me. Back when I was in my early twenties nobody could beat me at programming. Nowadays, when I sit next to people like Andrea Arcangeli, I realize that programming, too, (even considering the advantage of experience) is for the young. Perhapes extreme programming, ie good quality, high speed programming, should be considered a sport and not an art or science or a skill. Since, I do not see myself being a programmer at 60 years (which is more than years from now), I deduced that I have to find a new job between then and now. Law is something that really goes well with progressing age.
And see discussion about the above, and one more.
I won't touch the comments about religion and "G-d". Nothing new or interesting in what these people have to say 
Via PHPEverywhere, an interview with Adam Bosworth at XML Magazine.
To illustrate why XML is so essential to loose coupling, let's consider some failure cases. Database client-server computing is a failure case. When people change the implementation of the database, it almost always causes the client code to break because the client code has intimate knowledge of the table layout in the database. Somewhat surprisingly, object-oriented computing, even with interfaces, is also a failure case. We have learned that changes to the implementations of objects over time tend to break the clients.
The only real success story to date in the world of loose coupling is the Web itself. When people change the implementation of their sites, often in very fundamental ways, the browser continues to be able to browse the site. The reason this works is that the browser makes no assumptions about the site's implementation. The only thing the browser knows is the wire format (usually HTML) and the protocol.
One reason I haven't created linkbacks for my site yet is because I can't decide how to handle the case when I get links from a homepage. Mark Pilgrim makes the linkbacks auto-expire, which I'm not sure I'd want to do. It seems like you lose a record of who linked to you awhile ago - the link still may be valid. Although I'm really not sure what algorithm he uses to expire linkbacks.
In any case, if you get a link from someone's homepage, and if you program in your linkback checker some knowledge of common blogging tools and permalink url formats, I bet you could do a pretty good job of auto-discovering the appropriate permalink. I'd say it would have to work 90-95% of the time to be accurate enough, but I bet you could get that. It's only for weirdos like me who wrote their own system with links like no-one else's that it'd be hard for.
If there was only "a standard" for identifying permalinks...
The EuroPython people added another interview - this time with Eric Raymond.
EuroPython: You're a very experienced programmer, which languages have you been using ? Which ones do you still use regularly ? How would you situate Python among other languages ?
These days I write Python when I can and C when I must. Despite minor flaws, I think Python is the most expressive and powerful language I have ever used; it has even seduced me away from my old-time loyalty to LISP.
Via LGF: Wow, they're actually going to build the fence around a large chunk of Israel to try to keep murderers out. I wasn't sure if this would actually get done. Seems like most people in Israel support it too. Don't know why they're leaving some parts unprotected, however.
Oh, and before I forget (just thought I'd throw this in...) Noam Chomsky can bite me
Wow
I picture her there, cleaning out her desk, still dealing with the layoff news, recording this outbound message for people she'll never talk to on behalf of a company shedding her to protect its profit margin, with her manager watching her to make sure she says nothing derogatory...
Pinkjuice.com: Ruby makes me feel good.
I like the "Easy to extend existing classes" part the best
As a followup to my discovery of what I believe is an error in the CSS box model, I've sent an e-mail to the editor of the CSS3 box model specification, reproduced below:
----- Original Message -----
From: "Keith Devens"
To: <bert @ w3 .org>
Sent: Friday, June 07, 2002 12:02 AM
Subject: CSS3 Box Model concern
Dear Mr. Bos:
Please forgive me if you're not the appropriate person to send these
comments to.
I have concerns about one aspect of the CSS3 box model. Specifically, how
the height of a box is computed when its height is specified in percentages
and the containing box's height is "auto". The specific verbiage in CSS3 [1]
is this:
"A <percentage> is relative to the computed value of the width or height of
the containing block, but if that value is 'auto' the computed value for the
percentage is also 'auto'."
and in CSS2 [2]:
"The percentage is calculated with respect to the height of the generated
box's containing block. If the height of the containing block is not
specified explicitly (i.e., it depends on content height), the value is
interpreted like 'auto'."
After trying very hard to create a specific layout and speaking to some
folks on #mozillazine, I've come to believe, and those I spoke to in
#mozillazine agreed, that this is an error in the spec [3]. This one error
makes it impossible to produce many layouts with CSS that are otherwise
achievable using tables, and I give an example of this in [3].
I believe a better approach would be to always have a percentage height be
calculated relative to the computed value of the containing box, rather
than "resetting" a specified percentage value back to 'auto' if the
containing box isn't given a fixed height. My only conjecture as to why the
spec was written this way was because of a concern about implementation
difficulty. I don't believe this is an issue, however, because the layout
calculations performed if percentage values were computed according to the
containing box's computed height are similar to other calculations the user
agent already has to perform in other areas of layout, specifically, with
tables. Those I spoke to in #mozillazine also agreed that this would not be
an implementation concern.
Furthermore, even though it would break strict compatibility with CSS2 if
this were changed in CSS3, the real effect would be negligible. This is
because specifying a percentage height on an element contained within a box
without a fixed height is currently meaningless in CSS2 and in the current
working draft of CSS3. Therefore, if the spec allowed percentage heights to
be computed according to the computed height of a containing box, the spec
would take away no existing capabilities, and would add a significant new
capability. Moreover, that change would remove a special case currently put
into the spec, and would make height calculations more consistent, more
intuitive, and more flexible for the stylesheet writer.
I hope I have been clear in explaining my concern. Do you agree with my
conclusions? Is there anything I'm neglecting to take into consideration?
Thank you very much for taking the time to consider this issue. Again, if
you are not the person I should be sending this to, I'd appreciate it if you
could get me in touch with the right person. If there is anything else I can
do, or if you have any questions, please feel free to e-mail.
Sincerely,
Keith Devens
References:
[1] http://www.w3.org/TR/2001/WD-css3-box-20010726/#the-ltlengthgt
[2] http://www.w3.org/TR/REC-CSS2/visudet.html#the-height-property
[3] http://www.keithdevens.com/weblog/?id1950
|
Generated in about 0.066s. (Used 7 db queries) |
Friday, June 7, 2002
Permalink
I hate ASP.NET
I hate ASP... I was doing wonderswith PHP, then suddenly one of myclients...
Johnies: Mar 17, 6:14am