10ren

A git commit is a set of diffs, with respect to another commit.

Commits are thus arcs+nodes, forming a graph.

Each such commit has a unique name, locally and across all distributed copies. [actually a hash whose uniqueness is probabilistically "close enough"]

You can rearrange the graph, so that commits that previously formed independent branches of the graph are combined ("merged"). For commits with diffs on the same file, it either applies both diffs automatically, or detects that it can't do so safely, and demands manual help.

This is very cool.

--

(It seems to me) that the really clever parts of git are (1). the diff algorithm (which is old); and (2). the merge algorithm, including the detection (I don't know if it's old or new; maybe it's as simple as detecting overlap; but you want to prevent automatic merge if there's even a chance it might be wrong - probabilistic again).

What scares me about git is that there is no (simple) undo - and perhaps no undo at all in some cases; and that the commands aren't quite regular (like many unix tools). My experiments with it (doing weird things of course) often lead to messy, messed up graphs that I couldn't get out of.

It shouldn't be that hard. You have a bunch of nodes, you mix and match them one way, you mix them back.

--

I believe there exists (a). a very clean, clear, safe and regular model of these ideas that always works exactly as you'd expect; (b). a ui (commandline or gui) that reflects this model, simply and cleanly. It's just that I don't know what it is.

Oh man, it's such an awesome story. Thanks so much for replying. Good to hear the shack wasn't the first iteration (nor the last). Did it take some experience to be able to build a stable, long-lasting shack (perhaps just woodwork in general?)

How far were you from a town, for food, construction materials, etc and a PO (I guess biking distance)? I guess you had a friendly nearby neighbour for the extension lead? [I've been thinking solar, which I actually used for a hp200lx, using 4 rechargeable AAs, but today's netbooks need a gruntier, more elaborate setup: large solar panel, lead-acid battery, transformer etc. Seems error-prone. Maybe a kindle-like ARM+OLED/e-ink/LCD will change this.]

I'd like internet - either wired or mobile (we have rural mobile coverage, and the govt just reelected campaigned for more) - instead of a PO, but I'd still need a local town for food etc. It scares me a bit to be too far away - but that's where the peace/silence is that I want/need.

Just to collect figures and conversions for reference: http://www.wolframalpha.com/input/?i=%243000+1975

    $3,000 for 5 acres = $12,000 today 
    $40 per month      = $   160 today
      @ 10%            = $20,000 invested
    1200' ext lead = 365m
    Oregon 44N; Tasmania 42S

If these figures are applicable today, here in Australia, I could do this... now.

Logically, book vendors could impose similar restrictions with similar language and achieve the same result viz. circumvent the first sale doctrine.

There's a question: would anyone buy such a book? If you were offered identical books, one you could resell and one you couldn't but it was half the price - which would you buy?

I don't know the legal history of the first sale doctrine, but I assume it's mostly based on public policy, and to support things that people were already doing: reselling, lending etc. An interesting data point is that software in the form of video games is regularly resold and lent.

IIRC, a distinguishing feature of the autodesk software in this case is that it is very high-end commercial software, and thus not a consumer product. Buyers and sellers in business transactions are generally assumed by the courts to know what they're doing, and so the courts tend not to intervene with whatever bargain they've struck. That is: this is likely inapplicable to consumer software like video games.

ORMS: http://blog.brandonbloom.name/2009/10/orms-and-declarative-s...

Visual object-relational mappers allow you to integrate different DB schema and classes/objects, instead of deriving one from the other. What do people think of them? They aren't appealing to me, because they aren't very code-like... however, some relationships between disparate type-systems are much easier to express graphically than in code.

URL parameters: http://rails.nuvvo.com/lesson/6371-action-controller-paramet...

I really prefer Sinatra's way of doing this; and it's probably even more appropriate for prototyping (but not for big projects, where separate directories help handle complexity.) It's just amazingly simple and intuitive: http://www.sinatrarb.com/intro.html

      get '/hello/:name' do
        # matches "GET /hello/foo" and "GET /hello/bar"
        # params[:name] is 'foo' or 'bar'
        "Hello #{params[:name]}!"
      end

This poll contains 327+271 votes, yet has only 59 points.

Worth voting in, but not up.

Aside: Is it true that everyone thought the relational model was too slow to be practicable, until the Oracle team put a very fast implementation together (as Larry Ellison claimed in an interview)?

EDIT according to the article, Oracle had the first commercial version of it, and so from their point of view at the time, I guess it was true. It doesn't say if IBM's release a few weeks later was of comparable speed.

Oracle is a pragmatic company. It's likely they'll just merge the easy stuff.

If there is insanely great stuff in the intersection you mention, it probably constitutes a research project, which it would make sense to undertake in the background (if at all). For Oracle, the only "insanely great" that counts is that which yields benefits that customers will pay for now/soon - not what's technically impressive. They're a sort of microsoft-research anti-particle. disclaimer I actually have no idea.

Allow me to answer in terms of integrated vs. modular architectures: they were fast enough when Java's virtual machine became viable, when .Net's virtual machine became viable, when interpreted scripting languages (Javascript, Python, Ruby) became viable.

Basically, whenever an extra layer that soaked up performance in return for other benefits (such faster development time, better error checking, more flexibility, easier, more intuitive) was actually adopted by real people, it meant that the computer was fast enough in their opinion to trade some of that fastness for other benefits.

relevant: http://xkcd.com/676/

The Innovator's Dilemma guy also talks about integrated vs. modular architectures. By integrated, he means made in one elegant piece, meshing together just so; by modular he means you can mix-and-match (eg. from different suppliers, or to customize attributes easily), with clearly defined standard interfaces. Maybe it sounds like modular is always better; while it is more customizable and cheaper, integrated can always outperform it. Which one wins in a market depends on what that market most demands at that time, with respect to where the technology is at that moment. Is it fast enough? Does it have enough functions? Is it flexible enough? Is it cheap enough? Markets tend to move back and forth between them, as they evolve over a period of years.

For smartphones, performance is still an issue (and will be for 2-3 years I'd guess, by Moore's law), and so integrated platforms do the best job at this. This is Apple's forte - but they have limited time to make hay and get as firmly established as possible.

It's limited, because once the market's demand for performance is sated ("fast enough"), the market will base decisions on other issues - such as price. And that is not Apple's forte, nor does Apple want it to be. Thus, Apple already has the iPad lined up. After that, there'll be in another market at a stage where Apple's extraordinary ability to integrate can shine.

To be clear: Android is modular.

followup: there's a great expression "throw it over the fence", for how IBM researchers used to commercialize their research. Here's some tech, whatever, seeya. (the fabled PARC labs seemed and microsoft research seems to be similar). An example of what happened is relational databases: invented at IBM, but commercialized by Oracle. You might say that Oracle is the baddie in this, but commercializing it here only made them money because they turned the tech into something people wanted. So, as far as benefiting the world goes, what they did was crucial. [according to Larry Ellison, the thing they did was make the nice theoretical idea fast enough, which nobody believed was possible - but what founders say is invariably - necessarily - part-PR, so I always take it with a grain of salt. I like a good story though.]

This interview (transcript) gives an idea of the process of adaption (for Enterprise software) http://news.ycombinator.com/item?id=1671852

BTW if all this seems overwhelming, you only have to do one step at a time, then you have some feedback to give you 1. information, 2. confidence and 3. energy for the next step. Activity in itself - even if it fails - gets your blood moving, and that's helpful.

Another angle is to try living this ideal life for a month or so. It might be difficult to pretend, because you can't 100% relax into it, but it might alert you to things you need you hadn't realized (eg. social); or, contrariness, give you a boost of motivation to do whatever it takes to secure it (eg work to save a little more money; research etc.)

It's just that idea of starting small, as a way to get started and get more information, more confidence (from having some progress), and get the blood flowing through acting on your vision.

BTW: lutsp is in the thread, who's actually done this (see his link to his shack.)

Thanks! It makes such a difference speaking to someone who's actually done it. Not theoretical.

I guess you must have been relatively near civilization - at least a town. Can I ask how much money it took... and how much you think it would take today?

I think it depends a lot on the land, which seems relatively expensive here in Australia; if you want water, electricity and sewage utilities. I get the impression there's very cheap land in some places in the States.

Just to be clear: I didn't say online trumps university.

Sounds like you're torn between selflessness and selfishness. But it's not that simple.

Don't worry about people stealing an idea. If it's original, you will have to ram it down their throats. - Howard Aiken

I know you're not worried about theft, but the second part of the quote is still applicable.

--

Adoption requires much more than minimal price. For a start, price is only part of the cost of adoption. Other costs are changes in user behaviour, changes in infrastructure etc. Before you get to that point, users have to know about the new approach and the wonderful claims you have for it; they'll need some kind of assurance that the claims are true; it needs to be in a form where they can easily try it out to assess it (easy-to-adopt). It also needs to be usable.

All of this is a lot of hard work, which is a different kind of fun and excitement from a technology that will change the world. Commercialization is long and difficult - consider how long the mouse/desktop took. It's also a (surprisingly) huge, huge leap from "it works!" to "usable by mortals".

All the above is entirely about your first option "A) release it as open-source for maximum impact", because open-sourcing it does not guarantee in any way that it will have maximum impact - or indeed any impact whatsoever. Of course, you can dedicate your life to promoting it as open source, and make enough money to live on by consulting around it; but IHMO that's not the way to change the world.

It's partly because you won't have the resources for the enormous amount of work involved; it's partly that you won't be rewarded for that work. But it's mostly that your interests are not aligned with changing the world: you'll likely end up with a tool that clever developers can use; and not one that can be deployed easily and quickly by anyone. It will rely on service (provided by said developers, or yourself) rather than as a product.

--

To answer your question: the reality of tech adoption is tech improvement. So your job - what you work on day to day - will primarily be about adaption, not adoption. Finding out what people need in the technology, and adapting to that. Providing extra tools that people need to compliment it. Fixing bugs. Making improvements. Discovering fundamental technical problems you hadn't imagined and solving/working around them (adapting to reality.)

What many people seem to do is to try to sell it (C) - if the tech really can stand alone, and there's a clear felt specific existing need for it, then this is viable. Historically, this usually doesn't work (eg. Pagerank wasn't, Xerography wasn't) But can work, eg Birdseye (frozen food - though I think he had an initial business going at that point.)

Many high technology ideas are often sold as (B), but they often involve huge amounts of consultation with the initial customers, while the bugs are sorted out, and especially as you learn what the problem really is. Accounting for this work, the profit margin is negligible (or negative.) As the bugs get worked out, you can start to sell it cheaper.

But if it really is trivial to instantly adopt, without any adaption needed by the user, or by the technology, or by the market, and your claims are self-evident and will be instantly spread... then any of the three options are viable, and it would just be up to you.

--

Summary: the answer (IMHO) depends on how much ongoing work is involved in making the product useful and usable by real people: maximizing adaption, not adoption.

It's unnecessarily convoluted but correct, eg "accept the loner [as] a mentally sound individual" is a legitimate construction and "[K]now man" is a pun.

Philosophers tend to write this way. It's just that it's not punchy and to-the-point, like business writing or advertising.

University was great for intellectual stimulation, because there were always interesting people around, and interesting discussions.

I haven't seen anything similar in the real world (which excepts online.)

Another option is to resize browser window width, to get about 10-13 words per line; and crtl-+ for larger text.

[Sorry, I deleted without refreshing to check for replies. Here's the original:]

Aside: I'm curious if there are any OSI approved open source licenses that exclude server use.

I ask, because the current move towards services defeats the purpose of the GPL (of allowing access to the code users depend on.)

Welcome, cool to have you! Did you know you've been featured here? http://news.ycombinator.com/item?id=905377

If you don't mind, I wanted to ask you: did you own the land for your shack, or rent it? The latter is cheaper, but not independent. I recall Thoreau didn't own his shack.

Great question. I think more passive income is required for food etc. eg. my rule of thumb $1,000 invested will bring in about $1-2 per week; or, some businesses you own can (theoretically) provide passive income, but in practice it's not totally passive (1 hour per day is quite reasonable though.) But both sources will require more work to setup in the first place, to create the "asset". Another option is part-time consulting work; if you charge $100 per hour, that's $500 per week. Of course, you probably can't get that literally one hour per day; it would be bursty: (say) full-time for a few weeks, then don't work for a year. That's a popular hacker route. But again, you'd have some setup cost, in having the technical skills (and keeping them up to date) + (more importantly) having the business skills to keep getting the work, year after year (and the social temperament.) It's sounding more reliable to work for a whole year, and invest that.

Though my personal experience is that I really missed being productive for other people, and have decided to expend effort doing useful things for others (create the value that I want to create, on my own timetable and terms - largely an intersection of benefiting both others and myself.) It took me 2-3 years of not working to come to that decision, and it seems typical of people who retire. But even knowing that, I still had to see for myself. I expect you too. Of course, it's quite possible to just do that in the first place (I didn't.)

OnLive sounds cool, but it's a little hard to believe, since latency is a common issue in regular gaming already. Demos are invariably carefully orchestrated. The other thing that gives me pause is that it is such a compelling vision for publishers. It's an absolutely magic idea. However, this enthusiasm is not technology-driven: it's not about what has become possible, but what would be really amazingly cool if it was possible.

But latency isn't such an issue for compiling etc. Someone was saying in the instant google thread that 250ms is imperceptible for search (and I've heard 200ms for the command line, from Rob Pike on Go). That's much lower hanging fruit than for gaming, where 250ms latency is far from instant but unplayable.

Aside: How far off are we from renting our PCs in the cloud, and just having a local terminal? I know it's an old Failed Dream (mainframe-terminal, client-server, settop box etc), but maybe we're getting closer...

It seems a bit ridiculous, because you still need a bit of local power for display and fast reactions, and current iPhones/netbooks could do with more power. But desktop PC's have been fast enough in that respect for a while. An advantage of the cloud is that as RAM, cycle prices etc drop, you get it (more of them or cheaper) without the hassle of physically upgrading. And bursty usage is available too, eg. when compiling.

There's solid economics here: it's a sort of timesharing idea, instead of cycles being wasted while you type, someone else uses them to compile. Even more compelling globally - someone else uses them while you sleep. The same argument works for sharing your desktop's own cycles, p2p, but a centralized cloud has admin advantages and other economies of scale.

Aside: I looked into AWS a couple weeks ago, to play with a simple webapp idea, but the myriad choices, acronyms and signups confused me, and there was [seemed to be] no free options for getting started, and initial traction. It seems focussed on sophisticated enterprise users (nothing wrong with that). So, I went with google's App Engine, which was much simpler, and has been great. These micro-instances seem the same.

Did I give up too soon?

I wish there was a way to play with it initially without giving up my email. I hate getting automated 'haven't seen you for a while' app-spam. It's pretty standard though, so maybe it's just me.

I'm using App Engine too; seems to be a good choice. And oddly, the performance stats for Python vs. Java seem indistinguishable. I would have thought Java would pull ahead on repetitive server-like tasks.

I've only read the first few pages, but this sounds exactly like Steve Blank's 4 steps - ie. fantastic.

So... no Components Off The Shelf for them.

Does anyone use COTS anymore, or are the a Failed Dream? Fred Brooks favoured them...

Although, I have seen Service Components [Architecture] (SCA) - where you assemble an app by integrating web-services in the cloud. eg. IBM acquired Cast Iron Systems 4 months ago. And with everything having an API, mashups, and tools like Yahoo pipes, maybe the 10's version of COTS is already here?

On the positive side, although google has no customer service or email for feedback, there's a chance that someone from google will see this comment here, and do something about it. A chance is better than nothing.

In this context, Steve Jobs personally responding to emails (apparently) is amazing positioning. Even if only to say "we disagree", it's a factor of infinity better than google.

Thanks, I'm surprised it wasn't in the first version.

I bet that UI came with the the Android acquisition. Though gmail is very good. All of their other good examples of UI's that I can think of also come from acquisitions: it's an opportunity. Google is great at engineering.

The RAM/CPU specs are close to my netbook. I'm surprised that JIT compilation isn't standard for a Java-related language, it's pretty old now.

The fragmentation is a concern, for market size (for apps), though it will sill be massively larger than for Apple. The appstore deficiency is a greater concern - google need to buy a startup for this, they suck at UI.

The Oracle suit does scare me though. Why invest sweat equity if it might all be washed away? That's the idea, I guess.

Regardless of what happens to this particular platform, the hardware is just about there, so something fantastic will soon be here.

reddit thread: http://www.reddit.com/r/Android/comments/dafec/android_first...

Google App Engine seems pretty cool. 1 GB per day free (outgoing) http://code.google.com/appengine/docs/quotas.html#Requests - there are other quotas for other resources, like datastore etc.