[Cuis] Why not just kill changesets?
Juan Vuletich
juan at jvuletich.org
Thu Jan 3 10:23:04 CST 2013
Hi Casey,
I think we essentially agree. To summarize it a bit:
- Rebuilding the system from source would have some nice properties.
- This should be done without losing the nice properties of Smalltalk-80
we already enjoy.
- It is a rather big project. There are some open problems to solve, and
a lot of code to be written or adapted.
So, it is mainly about finding enough time / manpower to do it.
Cheers,
Juan Vuletich
Casey Ransberger wrote:
> Juan, you've made some interesting points here. I see some of your
> reasoning more clearly now.
>
> Comments inline.
>
> On Wed, Jan 2, 2013 at 7:07 AM, Juan Vuletich <juan at jvuletich.org
> <mailto:juan at jvuletich.org>> wrote:
>
> Ok. This will be long :)
>
>
> Yep:)
>
> Casey Ransberger wrote:
>
> Now that I've wrapped my head around the new Git Cuis dev
> model, I would recommend grabbing a healthy supply of torches
> and pitchforks, because I think I'm reaching for a Third
> Option here. So we're all on the same page about what that means:
>
> http://tvtropes.org/pmwiki/pmwiki.php/Main/TakeAThirdOption
>
>
> Thanks for the link. Sometimes I have trouble following the stuff
> you quote.
>
>
> I should work on that. I use too much slang at times.
>
> I thought about sending this straight to Juan, but why not,
> whole list. I expect that Juan's arguments will be interesting
> in this case.
>
> Alright! What do we really need changesets for then? Why not
> make developing the core the same as developing anything else?
> So if we killed changesets:
>
>
> Ok. It is a good question. I'll interleave some comments on your
> Cons/Pros, and then add mine.
>
>
> Cons:
>
> - We'd have to engineer our way around the "breaking the
> update stream" problem. This is work, but I'm sure it's
> doable. I did it once:) and ContentPack happened because I
> needed to do a spot of time travel to fix the update stream
> after I broke it. If I can travel through time, I'm pretty
> sure we can handle a bootstrapping problem. Especially given
> that we have the computational equivalent of a TARDIS at our
> disposal.
>
> - Cuis now depends completely on Git. Note: Git is *extremely
> popular,* not likely to go the way of the dodo any time soon,
> and maintained like the Linux kernel matters to Linus. Also,
> switching to another SCM should be relatively trivial when
> necessary, if not painless. And: Git presently runs most
> places where Cuis runs.
>
>
> Ehhh. No. Cuis doesn't depend on Git at all. We use Git as a
> shared, universally accessible repository. We also use it to
> version files, and to ease teamwork. But Cuis is not tied to Git.
> All Cuis needs is a local file system to store files (obviously, a
> local clone of a Git repository works).
>
>
> This makes sense.
>
> - Stuff I've missed.
>
>
> I add some cons. But before that, I see two ways here. One is to
> have a really small kernel, and load stuff to build images (the
> Pavel way). The other one is to have a bigger image, with packages
> always loaded, and load new versions of packages on top of old
> ones to update the images (the Squeak way). So:
>
>
> Ahh, I hadn't thought about that in this context. It seems to have
> been a prominent question in recent times. Monolithic vs. minimal. I
> favor the latter, though I'll admit that I don't have a clear idea
> about how to arrive there. Fortunately, Cuis is already very small, so
> it's less of a pressing concern than it is in e.g., Squeak.
>
>
> === Cons (a) miniKernel + loadable packages. Pavel's way:
>
> - The artefact is no longer a Smalltalk-80 system. This is very
> important to me. Smalltalk-80 is a huge landmark in the history of
> computing. One of the main reasons I do Cuis is to preserve and
> spread this legacy. This is the best tribute I can do to
> Smalltalk-80 and its developers.
>
>
> :) And a fine tribute it is! I don't think I follow this completely
> though. It's still the same system which came from PARC. To my mind,
> if you unload the system browser, and then load it back in, it's still
> the same system -- kind of like when the image was run through the
> tracer to get a 64-bit image: it's a different representation of the
> object memory, but still the same system in spirit.
>
> So I also think maybe I ought to talk about *why* I'd like to be able
> to unload things like the UI: mainly for headless web servers, or REST
> services in the backend of some big iron system. When you're e.g.
> whitepages.com <http://whitepages.com>, the sheer amount of traffic
> means you end up with a fleet of servers, and there start to be
> arguments about how to squeeze the best performance out of them. This
> has a nasty way of ending in Java. Morphic does stuff: and stuff takes
> time and electricity. In applications that don't need it, there are
> arguments for and against having it there. For: I can grab the image
> from the borked server and have the debugger open and waiting for me.
> Against: expensive compute resources that I probably don't need to be
> spending on.
>
>
> - Not having the dev tools in the image makes modifying it harder.
>
>
> Ah! Okay *now* I think I see where you're coming from. Right! I mean I
> wouldn't recommend programming in bytecode or anything:) and I'm not
> saying that we should develop in what's basically an OS kernel.
> Definitely our development images should have the same set of great
> tools we've got in there right now. But I *would* honestly prefer to
> build the image up from its component parts when we ship.
>
>
> - We're not showing newcomers the beauty of the Smalltalk system,
> but just a bunch of files they need to 'make' in order to have
> something useful.
>
>
> Again, this isn't my intent. I very much want folks to see the whole
> system when they come to it.
>
>
> - The mini-kernel will also need modifications from time to time.
> How do we do that? With ChangeSets?
>
>
> I knew you were going to go there:) and I'm pretty sure there's a way
> to bootstrap around that using purely git; this is the hypothetical
> "dependence" on git that I was talking about originally.
>
>
> - Maintenance will take more work. We'd need procedures to update
> or re-create the kernel, build the distributions, QA them, etc.
>
>
> Yeah. And maybe that actually doesn't make sense. To me, this sounds
> like the "right" way to do it, but some of that may just be dogma that
> I've been indoctrinated with. I definitely *don't* want to create
> painful, unnecessary human process. This is an excellent point, Juan.
>
>
> - As the only way to update an image is to rebuild it from
> scratch, people wouldn't be able to update their own images. To
> allow for this, we also introduce the Cons of (b), below.
>
>
> There's one that I didn't think of.
>
> === Cons (b) Packages always loaded. Squeak's way:
>
> - We'd need a package loader with atomic loading. Squeak doesn't
> yet have it, after a decade of using Monticello.
>
>
> Wait -- for some reason I don't think this is true any more. I thought
> they added atomic loading in Squeak's MC implementation a bit ago. I
> could be wrong, though. Anyhow, good point. There's a pile of work there.
>
>
> - We'd need version, dependency, and version dependency control.
> Otherwise, it is not just optional package loading that becomes
> fragile, but the base system itself.
>
>
> We get the versioning part from Git right? And I think the dependency
> control part might be undecidable with dynamic typing. I think that
> part is a problem with all dynamic languages. There's no way to know
> for sure what depends on what, but I definitely see your point. And
> destabilizing the base unnecessarily is a bad plan. Point taken.
>
>
> - It would be difficult and dangerous to update the Kernel and
> PackageLoader packages.
>
>
> Until we found a way to do it safely. Big pile of work. Totally.
>
>
> - In Squeak, we end having package postcripts, and strict load
> ordering of package version. Loading intermediate versions is
> required. There is, after all an update stream, but instead of a
> small set of changes, each update includes all the code. It
> becomes an huge monster that nobody can audit.
>
>
> Git changes are deltas.
>
>
> - Updating an image becomes muuuuuuch sloooooweeer.
>
>
> Agreed.
>
>
> - When updating an image it is much harder to understand what
> happened, to adapt our code.
>
>
> Pros:
>
> - No more confusing dichotomy between what's core and what
> isn't; everything becomes a package, and lives in whatever
> repository is appropriate. Symmetry. Exactly one way to manage
> code. Kernel can be reduced to a bloody stump which has the
> singular ability to load in other packages (attach limbs.)
> Epic win for modularity.
>
> - No more annoying dialogs about unsaved changes in core when
> there aren't actually any. Everything is a package, so there
> isn't a distinction. We don't need a special method to
> determine what's part of core and what isn't WRT the warnings
> about unsaved changed. Elegance, symmetry, less blivet to
> worry about.
>
>
>
> - We can completely unload (at least a lot) of the changeset
> handling machinery*
>
> - Smalltalk effectively becomes a peer to kernels which manage
> code in files, which makes us a lot less of a scary monster to
> newcomers.
>
> - Stuff I've missed.
>
> *Actually, I could be wrong about this part. Probably the Git
> stuff is using a lot of it. But I'll bet a single US dollar
> against the first of you who says killing changesets won't
> eliminate some net (as opposed to "gross") code, even if I
> might lose a dollar for dreaming too hard.
>
>
> We can see Squeak's experience with eliminating ChangeSets, and
> Pharo's experiments with Pharo-Core. Let's learn from them.
>
>
> Totally!
>
> I mean, why do anything halfway;) ?
>
> Okay, so I'm totally locking the doors. It's always raining in
> Seattle, so rebooting the Frankenstein monster shouldn't be
> hard, I just have to wait for some lightning. If you try
> creeping up on me, I'll be able to see your torches, so that's
> not gonna work. Email is the best plan!
>
> I can't wait to see what people think about this. Really, it's
> about whether or not managing code is or is not Smalltalk's
> problem in the modern world: and that's a hell of a question
> to talk about, or I think so. I think it's genuinely an
> important, and open question, specifically in this small
> community.
>
>
> Sure.
>
>
> At this point, we're almost more of a quorum than a community,
> and so: if we want to do this, we might be able to tackle it,
> if we as a group found it sensible, before senseless
> convention takes over and becomes effectively permanent, rigid.
>
>
> I agree. This is the best time to evaluate all possible options.
>
>
> Okay now's the time to use your torches and pitchforks. I'll
> be hiding under the couch. In an unspecified apartment in
> Seattle. Go.
>
>
> :) I hope tolerance and respect for everybody's freedom wins.
>
>
> I was joking about the torches and pitchforks!
>
> Cheers,
> Juan Vuletich
>
>
> P.S.
>
> I presently have low confidence that ContentPack still works
> right presently:( and I'm okay with that, but either I've got
> to fix it or we should unload it and move on.
>
> --
> Casey Ransberger
>
>
>
> _______________________________________________
> Cuis mailing list
> Cuis at jvuletich.org <mailto:Cuis at jvuletich.org>
> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
>
>
>
>
> --
> Casey Ransberger
> ------------------------------------------------------------------------
>
> _______________________________________________
> Cuis mailing list
> Cuis at jvuletich.org
> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
>
More information about the Cuis
mailing list