Lambda the Ultimate

...for this link. That was extremely interesting (and scary, too).

Thank you for the link, I very much enjoyed this paper. I think it was a 2008 paper, though.

Jim Collins basically sums this up beautifully with "The Window and the Mirror" metaphor.

It is too easy to look in the mirror and give yourself credit when everything goes right. It is equally to easy to look out the window and assign blame to others when everything goes wrong.

Level 5 Leaders, by contrast, look in the mirror and apportion blame to themselves, and when they look out the window, they attribute success to factors out of their control, such as luck.

Where I work, all the engineers are forced to be quite humble, because the two greatest contributions to our architecture were pushed by non-engineers. The engineers fought those two suggestions heavily, but in the end they turned out to be very wrong.

Right now, I am building some great software, but it is not because I am a genius programmer. I am pretty much an acknowledged moron. It is just because I am very familiar with a lot of technologies and libraries on my platform that basically make me feel like I'm sitting on the nose cone of a rocket.

This seems to me to be a pair of anti-intellectual, exploitative talks about how to substitute celebrity for engineering in getting ahead in tech.

Setting aside whether we think it is good or bad, is this not just an example of the widespread state of the industry in the FLOSS world?

Every successful project I can think of has either a "celebrity" behind it or a core group of funded participants or both.

To get this somewhat more on topic for LtU, think particularly about recent popular PLs. Think about how "opinionated software" attitudes have dominated PL developments in those communities.

Marketing skills, above and beyond technical skills, seems to be behind all of these success stories, and a critical component of that is arguing that the problems that you solve are the same as a potential user's problems and that the solution you offer is somehow better than the others on offer.

Note in particular that neither OP talk really spends much time describing the original problem space; viewers are left to assume that it covered their real problems. Equally the solution space is described only terms of attributes that are considered good for the solution. And who wouldn't want those?

Whether one thinks this is bad and wants to fight against it or thinks it is good and wants to hop on the gravy train with it, I think we have to start by accepting that this is actually how things are working right now. Without that, it is difficult to achieve one's ends in either direction.

I agree that it reflects the larger state of things and is how things "*are* working". I wouldn't describe the situation as driven by marketing skills, not quite. I have a less kind take than "marketing skills" but nothing appropriate to say about that in this forum.

-t

viewers are left to assume that it covered their real problems.

Distinctions that don't make a difference.

If you listen to the audience questions at Linus's talk, then you would observe that the viewers don't even know what their real problems are. Or, worse, are afraid to confront them. A lot of the objection was "...but in a corporate environment...", rather than a statement about characteristics of a corporate environment. It is not like Googlers are sheep; they just honest-to-goodness have de-prioritized thinking about it.

I actually think Linus did a good job acknowledging that his audience is vastly different from him; he pointed out Google probably has some ridiculous fiber powering their Perforce implementation, plus server farms everywhere.

I think the total counter-example to the Google Culture's approach to SCM is One Laptop Per Child. Thanks to the XO folks, many 5 year olds probably do software configuration management than some Fortune 500 companies!

What "particular insight" do you think he had? So far as I know, Git as released and developed by Linus was not especially original and in some significant ways was a regression from then-contemporary work.

-t

What then-contemporary work are you referring to? Mercurial (Hg), Monotone, or BitKeeper?

Linus's insight was that he could build a better tool than anything out there in two weeks. ;-)

Why was it better?

1. reliability: what you take out must match what you put in
2. performance changing the way developers work: mainly thanks to Git Object Model
3. distribution improves performance and workflow (yes, it is a consequence, but ends are as important as means)
4. distributed means branches do not have namespaces on a central server (corollary: creating a branch in your local repository does not require creating a unique namespace)
5. making merging ridiculously easy; branching is pointless without fast merging and conflict resolution
6. network of trust model
7. and this is very important: tracking collections of files (stuff like easily tracking commits to track down bugs or refactorings)

BitKeeper and Monotone both messed up the last point. BitKeeper was otherwise superior to Monotone. Monotone ignored point two.

What then-contemporary work are you referring to? Mercurial (Hg), Monotone, or BitKeeper?

Your list is missing one of the pioneering programs in the space, Arch, which was also known by the initials TLA for "Tom Lord's Arch". Arch predated Git by 4 years or so. Thomas' work was impressive, and from what I gather little things like some funding could have made a big difference to Arch's success.

(Another one worthy of mention is Darcs, which grew out of work on Arch, and predates Git by about 3 years.)

If we are talking about prior art on that level, then I believe the trump card is Aegis. Aegis pretty much predates everyone in everything. Oddly, I looked at Wikipedia's master comparison of version control systems, and it isn't even there!!! Wow! [Edit: Aegis is not even in their list of software configuration management software. Strange, considering it basically founded both fields.]

Arch was very slow as I recall (although it has been half a decade or more since I tried using it). Also, Arch was a pain to use, although I can't remember for the faintest reason why. Thomas is now working on a different sort of distributed, decentralized system... he used to call it Flower but he has since renamed it (I think) to something more Enterprise-y (IMHO).

I was pretty excited when Thomas started talking about a GNU Arch 2.0, which aligned with a lot of my interests in the topic. (And I believe Git has influenced his decisions on performance.) However, he's devoting his time to that Flower stuff.

I am not a SCM guru. Before Darcs came along, SCM made no sense to me. I really liked the concept in theory, but in practice they generally gave me little more than headaches, especially as I'm not a particularly good computer administrator. So I rarely used them for personal projects, and even when I used CVS for group projects, I didn't learn anything but the simplest commands.

And indeed, the groups I was involved with almost completely avoided the "advanced" features... although one had RCS (not CVS) very nicely integrated with their development environment, so you hardly knew it was there. I played with Arch briefly but could hardly make sense of it, though I knew several people who really liked it. I should have talked to them more about it.

Darcs was the first system that made sense and that I used somewhat regularly, though I've found my decades-long habit of not using SCM's hard to break entirely.

I still use Darcs some, I haven't used Monotone, I do use Bazaar (which I hate), and Mercurial seems pretty good. In any case, Git is definitely my favorite. Git has a gentle learning curve, it is fast, and the advanced features make sense and seem genuinely useful.

But Monotone and Mercurial got started years after Tom Lord's Arch; Bitkeeper and Arch are truly the popularly-known pioneers in the field, and this was before Bitkeeper was particularly well known. Tom Lord started Arch when CVS and Perforce were king, SVN was just getting started, and DVCS wasn't in the public's mind yet.

I want to know in what ways Git was a regression from other ideas out there at the time.

By the way, I agree on CVS and SVN. I once read Pragmatic Version Control using Subversion and I felt stupid and ugly the whole time reading it. ;-) It's not that the book is bad, but "it takes a long time to write a short letter" plus the author advocates SVN (I know, why would I complain about that when I was reading the book in the first place: work required use of SVN, and I always make it a point to master my tools no matter how bad they are).

I've found my decades-long habit of usually not using SCM's hard to entirely break.

Bad habits just lead to more bad habits, which is why most software is nowhere near as well-managed as it could be. I talk to a lot of programmers, and the most consistent thing I hear them say is, "We moved from CVS to SVN, because our developers did not want to go through the adjustment period of learning a completely different system." Such bad habits are sad: The most important living asset as a developer, the source code, is allocated the least amount of time worrying about and the attitude is merely "anything is better than nothing"! This sort of thinking is exactly how we get verbose ITIL standards for software configuration management... which are totally out-of-date with today's best practices in managing software.

Darcs was the first system that made sense and that I used somewhat regularly, though I've found my decades-long habit of usually not using SCM's hard to entirely break.

Tip: create an emacs elisp extension that combines save with commit (and wire it to a different keyboard macro than save). also, create an emacs elisp extension that upon starting a project, allows you to create a .elispgitconf hidden file that your other extension checks for automation of certain arguments, i.e. (def git-require-message true) this will automate interactivity of some commands, "filling in the blanks"

What then-contemporary work are you referring to? Mercurial (Hg), Monotone, or BitKeeper?

For open source ones, MonoTone and OpenCM in addition to those already covered, ie. Darcs and Aegis, the latter of which I had totally forgotten about (for probably the 3rd time). I am curious why Aegis never gained any traction.

When I looked at Aegis back in ~1994, my impression was that it had two flaws that would block adoption (and that blocked me from even testing it):

(A) It required the use of a custom build system, so to test it out I'd have to first switch build system
(B) It required the creation of tests that would fail against the old version and pass against the new version in order to handle submission.

and a third that would probably have blocked it:

(C) It was complicated and seemed to have been built for use with a relatively large group of people, as opposed to being lightweight and easy for a single person to start with.

All of this makes it hard to get traction, especially in 1994 when unit testing wasn't a big thing.

I do not wish to get into such a fight, but your comments do not reflect much familiarity with the topic you are describing. Neither bk nor mtn behave as you say wrt. point 7, and wrt. point 2, mtn used the same object model git "discovered" at first, before our users talked us into a more complex one. This is hardly "ignoring". Further, git lacks any serious consideration on point 6, punting to PGP, which hardly anyone winds up using on their csets; it is therefore surprisingly vulnerable to transitive trust attacks in most deployments.

Most glaringly of all though: all then-contemporary tools (cdv, opencm, mtn, tla, aegis, vesta, bzr, arx, svk, darcs, many others) were more or less identical wrt. points 1, 3, 4, 5, and 7. Git collected existing work together well, chose a minimal and tasteful subset that works nicely, and made a couple innovations in terms of rewriting-before-publishing (rebase + GC). Otherwise it's mostly just a Very Fast Implementation of existing work.

Don't get me wrong: git clearly won majority mindshare for DVCS technology that was only spreading slowly at the time due to performance and complexity concerns. A fast and small implementation of an idea that spreads is worth 100 too-slow or too-complex ones that don't.

But don't confuse implementation success with research work; please do more homework before making such stories up.

Thank you for your thoughtful reply.

I'm not interested in a fight either. Can you point me to the mailing list discussions or bug requests where the users of Montone talked the designers into a more complicated model? I also never found research publications of your work.

For what it is worth, I have tried to do my homework, but according to you I've epic failed (fair enough, as you are the creator of Monotone). I have many Springer-Verlag conference workshop publications on Software Configuration Management, various practical books about software configuration management, product data management, Practical Reusable Unix Software, and also the book describing the design of Vesta, as well as Baxter's maintainenance-oriented compiler [1]. My interest in your work and others is to use the ideas explored in the past and find the right approach to building a modular, self-sustaining system. Being completely self-describing isn't very interesting unless you have good configuration management (IMHO).

Anyway, since I've trapped you here ;-) ...and this is a programming language discussion forum... please indulge me by allowing me to pick your brain ;-)

Wrt. users asking for a more complex object model, what about supporting various object models for different users, perhaps using feature-oriented programming? I think one of the cool things in Monotone is the use of Lua for extensibility, but the use of C++ I am less enthused by. So the Lua stuff then makes me ask, how can I just minimize that even further and use it to come up with an essential model for configuration management? I mean, really, the way I look at it, C++ was just used to implement the engine, so the real question becomes how can I implement a really fast engine ina tiny language? Then how do I make it so that engine is highly reconfigurable? Danny Dig did some really inspiring stuff here studying refactoring of programs for his Ph.D thesis, showing some ridiculously high percentage of all regressions are actually program refactorings, not new features added. But I suspect the issue is much deeper than that, as suggested by Jeff Overbey's amazing OOPSLA paper Regrowing a Language, where he actually shows Guy Steele was right, you can grow a language. Both Dig and Overbey are/were Ph.D. students under Ralph Johnson.

A lot of this work has been done in the context of Java, such as Gavin Bierman's UpdateJ (language-level updates) and Dig's dReAM (VM-level updates), but Neil D. Jones has done possibly cooler stuff with Coccinelle (but I'm still wrapping my mind around his work). It would be much cooler to do this stuff in a tiny language that is maximally reflective and maximally open for extensibility.

There was a paper I read awhile back that I swear used feature-oriented programming as a possible way to make software configuration management/version control products less monolithic and more customizable to user needs while not sacrificing performance. I simply can't find it anymore. I searched for an hour today, just Googlin' and Googlin', and found nothing.

[1] "Design Maintenance Systems" by Ira Baxter http://doi.acm.org/10.1145/129852.129859

At first we had an even more-minimal model than git: just blobs + manifests, no changesets, and were inferring both the acyclic ancestry and rename/move events from metadata certificates. We then grew a formal backbone changeset system with the critical cryptographic DAG system (Jerome Fisher's work). Along the way we switched to robust file-identity tracking to make the rename/move code more solid. That turned out to be, in hindsight, probably one of the straws that broke the performance back. Far too much tracing identity through history. We only began to recover performance with the later "roster" representation of cached identity. Far too late.

Also critical, sadly, was the choice of storage engine. I simply didn't take I/O scalability seriously enough. Lots of stuff was done by loading full texts into memory, repeatedly (re-)encoding them and such.

Anyway, the major mid-development revision of the "object model" vocabulary, as you call it, happened around summer 2004: http://thread.gmane.org/gmane.comp.version-control.monotone.devel/913 plus several months of toying with related ideas thereafter; you'll notice that discussion discounts persistent file identity, which we eventually got talked into as well (mostly by very well-intentioned java developers). Unfortunately most of the motivating discussion happened off-list, on IRC and private email. But you can track the evolution of the model through the commit and ML chatter. Also can't give a definitive cut-off date, but the subset git and hg adopted in spring 05 was certainly on display by then. Just overgrown with other parts they elected to ignore (probably wisely).

To the rest of your points regarding "feature oriented programming", I don't really know what you're talking about, and lack time at the moment to figure it out. Sorry.

There was a paper I read awhile back that I swear used feature-oriented programming as a possible way to make software configuration management/version control products less monolithic and more customizable to user needs while not sacrificing performance. I simply can't find it anymore. I searched for an hour today, just Googlin' and Googlin', and found nothing.

[PDF] Using Federations for Flexible SCM Systems

Abstract. SCM products are large and monolithic, difficult to adapt and evolve, with high entry cost. This paper describes a new approach to SCM in which the system is built from, potentially heterogeneous, existing pieces, with assembly mechanisms that enforce high-level properties. The approach does not provide a simple SCM tool, but a family of tools that is easily customized, fits both low- end users (only the required functionalities are present at a very low cost), as well as high-end users (for which very advanced features and/or specific features can be easily added). The paper describes the concepts and mechanisms of federations, and shows how our federation technology was used to develop a family of SCM systems.

There is no denying that Linus's talk was much more of a sales pitch than a tech talk, But there was technical content. The subject of those talks was not implementation.

Linus didn't contribute any particularly original ideas; those were cherry picked from other systems. For his part, Linus identified particularly important features and stitched them together into a new foundation. And I daresay he was quite successful on both counts.

Same for Ben and Brian's talk; the technical content of their talk wasn't really about how to implement SCM's at all, that was more of a tangent. Their focus was on community dynamics, something that was just a tangent in Linus's talk.

For those that want a tech talk about the implementation of DVCS's, I liked Bryan O'Sullvan's talk on Mercurial. I know that I should probably look into quilt at some point.

I don't think that Linus, or Brian and Ben, and certainly not Bryan O'Sullivan believes that their SCM's are the last word in version control. But this conversation really went in a direction that I hadn't intended; I wasn't interested in SCMs so much as community dynamics.

So, in an effort to move this back towards a hopefully more objective discussion, instead of dropping names of obscure SCMs, what I find interesting is how Bryan and Linus and other Git/Hg people emphasize cleaning up the history, in part to hide your embarrassment, while Brian and Ben emphasize having mistakes on record, so that others can learn and hopefully keep egos from getting out of hand.

So, what do people here think of recording errors versus keeping a clean history?

I suppose Franz Kafka is still considered a literary genius despite everyone who wants to know it can know everything about his laundry lists.

Otherwise I do like an objective history because I've some faible for code archeology. In a former project of my career I attempted to reconstruct the early history of the product I worked on for years and handed it over to my successor in order to provide a better understanding on some of the stranger design decisions that have been made in the early days. Software is often a palimpsest and I consider code as an aging artifact. My motivations are somewhat different than those of Ben and Brian and it hasn't a pedagogical impetus ( "I have made mistakes, you can learn from than" ) but objectively they lead to the same conclusion.

As I re-read parts of this thread, your comment really stuck out at me in a way it didn't before.

You are right, though. If you have some idea about all the variations that have been attempted (and perhaps discarded) before converging on a given solution, then you have a much better idea of why things are as they are.

As I said elsewhere in this thread, a collection of good, highly polished changes is a much richer stream of information than a collection of failures. But a polished history might be denser as well, and it can greatly aide understanding to have reduce the density of a presentation by giving perspective and context to the main points and emphasize each in turn.

So, yes, you definitely lose something by hiding history. I think the right answer is as Anton said, that sometimes you want to hide something (usually reduce the amount of uninteresting information to sift through, and occasionally for other reasons), and sometimes you don't (for better historical perspective.) Perhaps you should err on the side of preservation, and let the archeologists decide what is interesting. ;-)

I still stand by my assessment that SVN's "right default" goes a bit beyond a mere default, and that it should be easy to use the software in either fashion.

what I find interesting is how Bryan and Linus and other Git/Hg people emphasize cleaning up the history, in part to hide your embarrassment, while Brian and Ben emphasize having mistakes on record, so that others can learn and hopefully keep egos from getting out of hand.

So, what do people here think of recording errors versus keeping a clean history?

I think Brian and Ben basically try to make a distinction that makes no difference.

Linus, on the other hand, concentrates on personal productivity and freedom for experimentation. Linus doesn't actually seem to look at it as "cleaning up the history", but rather quite the opposite: making the most important parts of history what goes into the history books! Imagine if your child's history book had "what Z-Bo ate for breakfast that made his tummy ache" in it.

If a branch is experimental, then it might not be worth your time reading. However, people can certainly still post it on their own git hub.

So, what do people here think of recording errors versus keeping a clean history?

There are times when it makes sense to do either. Someone might not want to expose their errors even though they could be useful to others. This is much more of a social issue than a technical one. I don't believe that tools are the first place one should be looking to manage this.

If a tool prevents people from doing what they want to be able to do, they'll work around it. So I don't think it's the "right defaults" that are important for something like this so much as what is and isn't allowed or well supported.

Not supporting something because it's considered undesirable can be a risky thing to do. It's a decision that language designers often have to make. There are many cases where, in the context of some language(s), the rationale against the feature being avoided is considered strong enough to take the risk of rebellion by users. "GOTO considered harmful" is a seminal rationale of this kind. (Edit: in those cases, alternatives are usually provided that are supposed to be at least as good or better than what they replace.)

But when workarounds are going to happen anyway, you face the situation that landscape designers do when pragmatic foot traffic carves an unplanned shortest-distance path across their carefully landscaped grass (this was a Christopher Alexander example, I believe). You're probably better off allowing for and responding to human nature.

That sort of pragmatism seems closely related to the allegedly "worse" side of the old "worse is better" debate. Linus is a master of it, as both Git and the shamelessly monolithic Linux kernel attest.

In other words, to bring this back to appropriate level, Git roolz, Subversion droolz. ;)

(Actually, I have a soft spot for Darcs, which has a more "purely functional" design. But that's one of those superficially anti-pragmatic choices that has consequences for early success.)

My friend Mark Drago holds the dubious distinction of being the contributor of one of the ugliest lines of code in Git history, according to Junio Hamano. ;-) Mark was actually simply just trying to fix a bug in the existing ugliness, and go about his day.

I think "you are doing this wrong" advice needs to come from the maintainer. It shows why Git is such a good project: Junio carefully reviews the code, and will say to you, "hmm, maybe you should try a different approach that looks more like so and so, and then resubmit."

Note, however, that neither Mark or Junio exercised any ego in any of this. Mark actually got a laugh out Junio's feedback, because he knew Junio was right. So ego isn't the issue here, and Git's workflow style didn't prevent the code base from getting better or others learning from their mistakes. Once Mark had some free time, he re-submitted a cleaner solution.

That sort of pragmatism seems closely related to the allegedly "worse" side of the old "worse is better" debate. Linus is a master of it, as both Git and the shamelessly monolithic Linux kernel attest.

I think Linus is not quite a "worse is better" philosopher. His code review mechanisms are impeccable, and that outshines any "monolithic" decisions he makes in design. The kernel review process is the gold standard in the software industry, IMHO.

I think Linus is not quite a "worse is better" philosopher. His code review mechanisms are impeccable, and that outshines any "monolithic" decisions he makes in design. The kernel review process is the gold standard in the software industry, IMHO.

It's a long time since I've read the original "Worse is better" material, but I'm not sure that "worse" in that context means what you're assuming. I'd summarize it as meaning something like "pragmatic but not as elegant as it could be." This often ends up being "better" in the sense that it solves more people's problems more quickly, and is thus successful.

In that context, the monolithic kernel was a pragmatic decision that helped Linux succeed, which is hard to criticize. You can point out that the decision has technical pros and cons, but the response to that is essentially that the "market" — of ideas, or of money — will decide which features it finds important. One of those features may be availability — when elegant designs take longer to reach fruition, whatever's available right now wins, at least initially.

Bottom line: It is way too easy to call any solution to an optimization problem a "Worse is better".

The reason for raising "worse is better" in this case is the presence of a classic criterion: an alternative solution, "the right thing", which makes some sort of claim to better elegance or integrity — such as the claims made about the reliability and security properties of microkernels. Similarly, the linked presentation suggests that tools which discourage hiding and encourage sharing are "the right default".

When it turns out in practice that pragmatic factors or priorities override the perceived rightness of "the right thing", so that the more pragmatic alternative is more successful, that's an example of worse is better.

An optimization solution that was "ugly" enough to compromise the externally visible elegance of a system, but which was important enough to be essential to success in practice, would qualify. That's not true of "any solution to an optimization problem".

The pejorative terminology can be misleading, though. It comes from applying a subjective and context-dependent judgment to a different context with different criteria for success. It arose out of a Lisper's attempt to explain why C and Unix were more widely successful. It's perhaps more meaningful as a way to understand that one's perception of "the right thing" may be ignoring important factors.

Popularity is often equated to success in human factors. This creates a dangerous myth in our profession: that programmers share the same psychology, and that people who deviate from standard technologies somehow have unusual psychologies.

For instance, S-expressions use a consistent prefix notation, allowing code and data to share the same compiler object format (the format itself passed into a prefix function called eval). However, there is still a lot of "admninistrative debris" with the traditional Lisp approach that modern functional languges don't usually force on programmers. Clojure is different, Lisp "re-loaded", with its [args] brackets syntax to highlight parameters/arguments, and with its explicit and implicit destructing options that ML has had forever.

In my opinion, you hit the nail on the head originally by saying that sometimes you want to hide your "mistakes" and sometimes you don't: both SVN and GIT allow you to do either, but SVN has the tendancy for discouraging people from using the system if they want to hide what they are doing, whereas GIT there is never any penalty to using the system.

I've kept a few of my more noteworthy failures around; however I also think that most of them aren't interesting to others. I think Ben and Brian overstate the value of keeping mistakes around, as honestly there are many more failures than there are successes, and they aren't as important. A pile of good changes is usually richer in information than a pile of mistakes.

On the other hand, through re-basing, the GIT crowd advocates sharing only polished snapshots and deltas instead of your complete experimental history by convention, even though git is easily used in either fashion.

So it seems Ben and Brain stand on pretty shaky ground, that SVN is much more than the "right default", it affects the way that somebody can effectively use the software. Thus they seem to fall victim to their own warnings of attempting heavy-handed technological "solutions" to something that's very much a social "problem", if indeed this is a significant justification for the SVN model.

And yes, I agree with your recollection of "worse is better", and daresay that Linus ascribes to this philosophy in the best possible sense. Richard Gabriel mentions the "PC loser-ing" problem in various incarnations of his essay. The solution that immediately came to mind when I first read about it was, why not use the "worse" solution, but have your compiler automatically inline the appropriate loop around every system call?

Defaults should not prevent or hinder loose coupling of systems. Ben and Brian, on the other hand, seem to take the rather weird position that community dynamics matter more than loosely coupled systems. In my experience, teams work better when there is no formal hierarchical structure to things.

Loosely coupled systems give you agnosticism you refer to with Git. The major difference, as you and Anton both point out, is that Git doesn't impose any penalty to using the system. On the other hand, commit access based systems do impose that penalty. The only commit access based system I like is Debian's package maintainer system (a somewhat opposite approach would be Gentoo). For software configuration management, commit access makes more sense than source code management. It greatly simplifies bug reports if everyone is testing against the same maintainer's packages. Such a policy doesn't require tight coupling, though, and is merely creating a highly cohesive system from loosely coupled parts. Even then, I like what Canonical's Launchpad project is doing to try to eliminate duplicate labor with regard to fixing bugs in packages across Linux distributions (propagating "Debian fixes" to SUSE, etc.)

I wrote a bit about what I think is unusual about git on my Livejournal nearly a year ago.

interesting site (if not widely LtU related :-) in general, thanks for posting that.