Wednesday November 28, 2007
Bill Sommerfeld's WeblogStill Under Construction. Watch for falling objects Best rehearsal quote in quite some time.. During a dress rehearsal of the battle scene in Pippin last night, the music director told the cast:
(I'm playing bass trombone in the orchestra of MTG's production. Opens this Friday.) (2007-11-28 10:36:46.0) PermalinkIf you think it's too good to be true, it is. So, I signed up for FiOS TV a week ago. They promised an install date of today, which I thought was a little fast. Turns out I was right. The installer shows up, looks around, and says that some outside wiring prep work that should have happened didn't. What's worse, the outside wiring folk apparently closed their install ticket saying "all set" when there is no evidence that there actually is an available tap in the cable anywhere near my house (the installers spent a bunch of time staring up at the poles and wiring before concluding that "construction" needed to be called to make a tap available). I'm in the midst of building our own flavor of labelled IPsec for Trusted Extensions, and took a look at what the "competition" (specifically, SELinux) is doing. I was surprised to notice that (at least if the ipsec-tools-0.7 source is to be believed) they've grabbed a codepoint assigned to RFC 3168 (Explicit Congestion Negotiation) rather than actually asking for one to be assigned via the normal IANA processes, or using the long-defined but rarely used capabilities of ikev1 to carry a sensitivity label. It looks like racoon2 gets this right (but doesn't have the SElinux security context support). I can't be the first person to notice this, can I? I'm surprised the complaint didn't include "failed to repair godzilla crush damage"
and "causes vertigo in blind people" (no, really!). I hope we get an injunction barring Gehry from making sandwiches. (MIT sues Gehry over Stata Center) (2007-11-07 18:52:00.0) PermalinkThree strikes, you're out (but it's only the first inning of a preseason game) The indiana prototype was released with the name "opensolaris developer preview". Having installed it and (briefly) attempted to get work done on it, I'm even more convinced the name was vastly premature. opensolaris. nope. it's the prototype output of a small implementation team and hasn't been through the rigor and wringer of the development process. It's a fascinating and impressive start, but.. it's not opensolaris yet, and I'm skeptical of some of the design choices (admittedly, I always am..) developer. I'm a developer so it should be for me to use? I installed it. I tried to run bugster to file a bug. Nope, no java. Tried to build some simple C programs. Nope, No C compiler, no make. Tried to add the binary nvidia driver so the display didn't look crappy -- got that working but it was an adventure -- pkgadd(1m) is busted so I had to pkgadd -R on a different system, rsync the bits over, and re-run the package's postinstall script a few times before it "took". If you want to play with the new packaging system, make sure you have another system running SXCE handy to actually do builds. And if you see something unexpected, please file bugs early and often. If you actually want to get work done, you're better off with SXDE/SXCE until further notice. preview. When I hear "preview" I think "movie sneak preview" .. getting a look at the almost-final production before they come out. SXCE & SXDE are previews. The Indiana prototype is like the raw footage viewed by the production team the day after it's shot before the bloopers have been edited out. Tim Foster's critique misses the point of the engineering objections. Attaching this name to a pre-alpha snapshot demo which is simply not even close to done is a mistake. It might make sense when Indiana is a little better baked, but IMHO, the current name attached to the current bits hurts the "brand". IMHO the name should have been held in reserve until it was ready for community endorsement.
Accusations of "stop energy" are "stop energy" So, there's this hot new newage-y (I think that rhymes with sewage-y) concept being bantered about by certain people called "Stop Energy". It seems that it's been used primarily as a non-rebuttal rebuttal to project review comments that the reviewee would rather not deal with. Many desireable properties of large systems are not localized to any one part of the system. Security is a key example, but performance and availability are others. Senior engineers in organizations which produce such systems often have an obsessive-compulsive streak -- because they have to. In order to preserve or enhance that property, you need to get all the details right, and this often results in long list of "stuff you got wrong" coming from reviewers. It's easy to misread this as a message to just give up. But it seems that the new thing is to instead accuse the reviewer of applying Stop Energy to the project. Based on what appears to be the canonical definition, it occurs to me that these accusations of "Stop Energy" are .. an exertion of Stop Energy against the reviewer. The reviewer actually is trying to help, it's just that there's a breakdown of communication such that constructive criticism is interpreted as an attempt at stonewalling. So, the frustrated reviewee counter-stonewalls, perhaps with this accusation. A more constructive response is to honestly ask "okay, so what should I do?". And then listen, and change your proposal accordingly. Maybe the requirement you just learned about overlaps with your requirements in such a way to produce a null solution set, so maybe you need to go back and adjust your requirements. UPDATE: Perhaps I should have been clearer. My non-snarky view is that "Stop Energy", if it exists, only exists in the mind of the person who stops in response to criticism. In a large project there isn't a single frame of reference in which you can declare some action unambiguously as "forward progress". Reviewers often point out things where, in certain frames of reference, a proposed change is a big (or small) step backwards. In the large, those reviewers are themselves charged with (say) improving the overall security of the system; and in that scope, one or more proposals that introduce more insecurity form a barrier to progress. Reviewees often hear the "no, don't do it that way" part of the message and then tune out and fail to get the message about the requirement they overlooked and cause the subsequent conversation about alternatives to fail. And as a result a message intended by its speaker as "do it a little differently" is received as "don't do it at all". Looking good, save for the name. Ran into a few bugs installing the Indiana prototype. 1) the installer got confused when I attempted to add the user "sommerfeld". (a 8-character username limit is a figment of useradd's imagination). I had to reboot and try again. 2) the lack of the nvidia binary driver in the distribution meant that it didn't cope with a 1920x1200 display. but otherwise it installed with a zfs root in almost no time flat from CD (system refused to boot from a USB key). It still needs a name change, though.. So, a preview of the new packaging & install technology produced by Project Indiana was just released. I'm shortly going to be installing it on a spare system in my office just to give it a shot. Unfortunately, it's being called the "OpenSolaris Developer Preview" and is being portrayed as a distinctly special binary distribution on the opensolaris home page. The name is unfortunate for a number of reasons:
I hope the folks who chose this name despite ample warning that it would cause trouble quickly reconsider. And I hope that the poor choice of name doesn't deter people from giving it a try. But the choice of names is forcing something of a constitutional crisis within opensolaris. (2007-11-01 10:29:50.0) Permalink Comments [1] |
Calendar
RSS Feeds
All /General /IETF /IPsec /Music /OpenSolaris /Solaris SearchLinks
Navigation |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||