Oracle forks Jenkins | Hacker News Reader

Oracle forks Jenkins

artima.com

78 pointsDanielRibeiro38 comments

In philosophy this is called the problem of identity over time. A ship is taken apart, piece by piece. Then the pieces are used to build two separate ships. One ship has the original nameplate; the other has the original sailors. Which is the original ship?

This is only a problem if you believe that you only have a boolean answer. Western philosophy loves setting up these weird one-or-the-other answers to questions and then spending decades dancing around the real answer which is: both or neither at the same time. Typically comes from also removing the context and timing of asking the question.

I'd answer the above question: "They are both the original ship, and not the original at the same time." But, this baffles people who believe that you can't be two things at once, even though the majority of truly interesting phenomena in the world are complex enough that they fit into this answer.

Another classic done this way is: "A farmer looks at a painted cut-out of a milk cow far away against a tree and mistakes it for a cow. Is it a cow or is it not a cow." Again, why can't it be both. At that moment in time, given the context of a farmer, it's a cow because he believes it and it's not a cow because it's just a painting of one.

I also think this need to shove everything into a boolean algebra problem is why most software is difficult. If you're supposed to model the real world then it'd be nice to not have to turn everything into True and False.

The cow example sounds like a formulation of the Gettier problem[1]. Gettier wrote a single paper assailing the Justified True Belief theory of knowledge.

    Suppose that you're driving past a field and you see what you believe is a sheep. 
    It is also true that there is a sheep in the field. 
    However, what you've actually seen is a rock. 
    Behind the rock there stands a sheep.
    Do you have knowledge that there is a sheep in the field?

This and related problems are a great starting point to a lot of interesting epistemology. I think you would enjoy contextualist epistemic theory. [2]

[1] http://alfanos.org/pdfs/04_issues_philo_fall08/07_gettier.pd...

[2] http://plato.stanford.edu/entries/contextualism-epistemology...

I don't like your cow example because it really isn't a cow, that's the absolute truth.

Maybe a better example would be "is the earth rotating around the moon or is the moon around the earth?" What if the moon and earth had the same mass?

Well, the correct answer in that one is "neither"; they're both orbiting their common center of gravity, which is near, but not equal to, the center of the earth.

Non-questions like these are also why a great many people dislike philosophy.

Maybe I'm not thinking hard enough, but it seems like a fairly straightforward question to me. Once you define what you mean by "ship" (which probably also requires defining who is answering/asking the question) then you'll have your answer. Under most definitions that spring into my head, the answer is "neither".

(though the ship metaphor doesn't translate perfectly to the Hudkins/Jenson story, since really it's more like you cloned the original ship twice, put the original nameplate on one clone, the original sailors on the other clone, then burned the remainder of the original).

I think the error that many people make in holding on to their belief that the question must have an answer is the fault of those people, not philosophy. How did you get to the point you can confidently label that a 'non-question' if you did not consider the problem philosophically?

Maybe you consider thinking "What would I anticipate differently depending on the answer?" when faced with such a question to be a philosophical consideration, but at that point everything becomes philosophy of some form and you lose the meaning of the term. ("Everyone philosophizes" is another such generalization that doesn't help communication.)

The problem with people trying to directly answer such questions (and questions like the classic tree-falls-in-a-forest one) does come from people, where else would it come from? But Philosophy as an art (not the general everything-is-philosophy) encourages these errors by positing the questions and then leaving them there as "cool mysteries". To carry on a metaphor of your post's sister, the mind is full of traps that lead to religious thinking, but Religion does nothing to help avoid those traps and actively encourages the sloppy thinking that results.

I think it's laymen rather than philosophers that are responsible for things being left as "cool mysteries." To philosophers, I gather, they're "open questions," things that either haven't been resolved yet because discourse is ongoing, or because philosophers have failed to find an answer. Or if they have been resolved, then they're questions presented by philosophy teachers to sharpen their students' analytical skills. But the questions rather than the skills trickle down to non-philosophers.

As a non-philosopher, I do personally like a cool mystery for its own sake, but my point, I suppose, is that since the question of "which one is the fork" reduces almost exactly to the Philosophy 101 presentation of the problem of identity over time, the same framework can be used for analyzing it. If I were to write a paper on it, my thesis would be that the question of "which one is the fork" is the result of a bug in the layer of semantics, and so what actually happens is determined by the lower layers of abstraction: code, law, and psychology.

Philosophy is useful in that it makes it easy to identify when someone is in over their head and just stringing together words.

"The problem with people trying to directly answer such questions... does come from people, where else would it come from?"

My point is that it specifically comes from the people making that error, not humanity in general, which would be meaningless. You tried to make it sound like I'm making a null point, but there is a point there. I was reacting to your own categorization as Philosophy as a distinct entity that can be disliked. Perhaps what you really meant is "Non-questions like these are also why a great many people dislike philosophers." I wouldn't have responded to that.

Now I suppose I'm qualifying for the category of people who are disliked. Well, that's neither news, nor particularly fair; I'm very not post-modern and while I fully understand the idea of the journey being the good part, the destination is very important too.

Agreed. In the end we merely moved around atoms and electrons within chemical space. Applying labels to things which are simply transient configurations and then invoking "deep philosophical ponderings" concerning the new identity of these arbitrary assignments is quite pointless.

Philosophy seems a lot like religion to a scientist.

I think the problem is whether the former Hudson community have a vote against a company sustaining an open-source project. When company's interests conflicts with the community ones, which interest will remain? I think the community decision is a pretty clear statement of what's best for the project. In a nutshell, we need a project that works for us, not for the company

All I hear about Jenkins/Hudson is in the context of this drama. Does anyone else actually use it?

Absolutely. Hudson is great (I would even say invaluable), and Kohsuke, the founder, is an inspirational programmer.

I just set it up to run tests on an app I'm developing after each check in. It was amazingly easy to get running, and so far it's worked wonderfully.

Amazingly for a Java app, I didn't have to touch a single XML file. Everything can be configured through the web interface. Fantastic!

It has a really nice REST API interface as well. One of the ways that API is expressed is through XML, but there are also JSON and Python versions (yes, the API sends you Python code in one version!)

How would a client make use of the Python code? By eval'ing it?

Yeah, exactly. From the docs:

Access the same data as Python for Python clients. This can be parsed into Python object as eval(urllib.urlopen("...").read()) and the resulting object tree is identical to that of JSON. However, when you do this, beware of the security implication. If you are connecting to a non-trusted Hudson, the server can send you malicious Python programs.

We use it at my $DAYJOB, and I'm planning to set up a Jenkins server for some of my open-source projects soon. So yeah, I guess I can say that someone uses it.

If you are not currently using something like it, start. If it doesn't do much for you because you don't have a good automated test suite, fix that. It's a critical problem in your build environment.

At the risk of speaking for somebody else, if Joel were to revisit his Joel Test I suspect using a Continuous Integration server would be added to the list.

Yes, my team has been using it for about two years to build over three dozen different projects. Great project.

We use it for testing some open source code that we release from our facility.

I use it, and is wonderful

Quantcast uses it pretty extensively.

>The decision to rename a project is certainly not, in and of itself, a fork. Mozilla's web browser went through a couple renames before landing on its present name of Firefox.

Bad example, since Firefox is a fork of Mozilla; it started as a stripped-down version.

The author is probably referring to the earlier name Firebird (http://www.mozilla.org/projects/firefox/firefox-name-faq.htm...). Firefox is still a part of Mozilla project.

For those interested, Firebird is an opensource database based on Borlard's Interbase.

Back in 2000, Borland (I think they may have been called Inprise at that stage) decided to opensource Interbase (version 6 I think) , which is where Firebird comes from. Shortly after, however, Borlard reversed their decision and took Interbase back in house again. Firebird remained active.

In a previous life I was a Delphi developer, and used Firebird almost exclusively. It was an amazing database - client server, yet fast with very small resource requirements and as good as no admin requirements. Set and forget. I really don't know why it hasn't had more widespread adoption, but some of the problem seems to be due to lack of good drivers