Skip to content

By Jordi in public

And now for something completely different…

I managed to get an easter egg into Octave. I’ve always been a little sad that we are not having enough fun in Octave, so I added some facts about the world’s greatest hacker to the source tree. Just type

fact

in the Octave interpreter to read them.

Giving credit where credit is due, thanks to Stallmanfacts.com and to Reddit for starting the whole thing.

Note: I cleaned up the facts a little, removing or amending the ones that were stupid or inflammatory. But this is ok, because these facts are obviously free software under the terms of the GNU General Public license version 3 as published by the Free Software Foundation, or, at your option, any later version? Right? ;-)

Tags: , , , ,

By Jordi in public

This is something I wrote a while ago on a Bitbucket bug post. Since then, I’ve close my Bitbucket account, and I still haven’t found satisfactory free hg hosting. I have this, but it feels very makeshift and temporary. I don’t care too much about all the bells and whistles like bug tracker and wiki. I never used that. I just want to have some hosting, and I want someone else to take maintain it, for a fee, if necessary.

I’m reproducing this because Bitbucket might some day decide to take down my request which is currently public, because free software needs free tools and I still want a free commercial hg hosting. If you know of someone, please let me know.


(Reported by jordigh on 2011-09-27)

I hope you hear me out. I hope someone with some decision power hears me out.

Right now, Bitbucket is not free. When Bitbucket has functionality that I dislike, I am not free to implement suggestions for you. At best, I can beg and argue with you when you decide that my suggestion is not a good one. If Bitbucket were free, I could go and implement it and show you, “see, this is how it could work, what do you think?” I could have much more leverage with which to help Bitbucket be better if it were free.

I was told that Bitbucket is not free because it is commercial. I do not understand why this is an explanation. Red Hat is free and commercial. Some of the best money I’ve ever spent. Gitorious is free and commercial despite more directly competing with a behemoth like github. From what we know of their finances, both of these are successful commercial ventures. And they are free.

I am not asking you to give up your trademark, your savoir-faire, your brand image, your hosting, your servers. Ultimately, all of this is what you really sell, just like Red Hat sells support and Gitorious sells support and hosting. I only see you adding value to Bitbucket if you make it free.

Hell, I will pay for access to the source. As much as 50, no, 100 USD per month for a premium source access subscription. Make it so that only premium subscribers have read access to the master Bitbucket repository. I will pay for the privilege to collaborate with you instead of begging you to make changes and arguing with you when you decide WONTFIX, HOLD, LATER, NOTABUG, CANTREPRODUCE.

Make it AGPL. If I or anyone else decides to run off with the source and make a knockoff site (which, btw, I haven’t seen happen with gitorious yet, perhaps you have?), your source won’t give us a competitive advantage, because we won’t have the service, hosting, trademark, brand name, and support you actually sell. Give me the opportunity to buy another product from you.

As it is stands right now, I am not happy with Bitbucket. I think it has potential, but I can’t fix it when it doesn’t work. Every user of this site is a developer. Every user is a potential collaborator, moreso than any other kind of software. We hackers also like to hack with our and on our tools. We are already writing code. We all give you our source. You don’t give us yours. We gave you Mercurial, Python, Pygments, Django. Please give us Bitbucket.

Collaborate with us. Share source like we share it with you. Make it free.

Charles McLaughlin

written 2011-09-27

* Changed status from new to wontfix.

Hi Jordi,

Thanks for your suggestion and the offer to hack on our code. This has come up before, for instance in issue #1566. You make some great points, but we still don’t have any immediate plans to open source the entire code base. For starters, we link against Mercurial, so if we distribute the code it would become GPL. If we wanted to sell a “behind the firewall” version of Bitbucket with a different license we would need to rewrite a significant amount of code and possibly shell out to hg to avoid linking. Since Atlassian bought Bitbucket a year ago we’ve added hundreds of improvements, stabilized and improved performance, and scaled the infrastructure to handle huge increases in users and repositories. That’s were our focus is, but we are committed to the open source community.

While this doesn’t satisfy your request, as we develop new features we’re open sourcing as much as possible. Here’s an example:

http://blog.bitbucket.org/2011/05/17/tracking-slow-requests-with-dogslow/

And there’s more to come.

Regards,

Charles

(written 2011-10-03 on by jordigh)

First of all, thanks for at least giving me a complete answer instead of simply dismissing me as a lunatic.

A few scraps of free software unrelated to the functionality I actually care to influence or modify don’t serve my needs, you are correct. I find scraps to not be a strong commitment to free software. I want the whole thing. Paying for it, like I said.

As to linking to the GPLed hg code, I suggested using the AGPL, which as you know, is much stronger copyleft compatible with the GPL. That way, you don’t have to rewrite anything (and it’s arguable if you can avoid copyleft by using a different interface), and if someone forks off your code, the source alone won’t give them an unfair advantage since they can’t add modifications to it and use it publicly unless they share them back to you.

I really think the real value is the hosting and the maintenance. And being able to submit patches. I see you as selling your services. If I could have those things, I would be happiest with bitbucket. I have my own hg hosting, but it’s a pain to maintain, and I would be happy if I could pay someone else to do it.

As for influencing your direction of development, I’m very disappointed to have received an email today about things you have implemented, none of which I want or need, and at least one that alarms me (git…?).

Furthermore, I’m hosting some GNU development on bb. I can no longer do that in good conscience. Since you don’t offer what I want, and I can’t influence what you are doing with the website except with ineffective pleading and arguing, I will be working this week on moving my work off bitbucket, closing my account, and maintaining my own hosting elsewhere. I’m sorry it has come to this.

Good luck with that git.

Tags: , , , ,

By Jordi in public

Dear hackers and Emacs users who consume Apple products,

Let me try to say that again a bit more eloquently…

You are supposed to be hackers. You are using Emacs, fer chrissakes. You are supposed to want development tools, to want them to be infinitely customisable, and to want to do those customisations yourself, because you’re supposed to be discerning, sophisticated, unsatisfied, skilled, playful, rebellious, individualistic, disobedient. You should be rocking out in Zion, celebrating your freedom and independence from the machines.

To use a trite and corny literary reference, this is your personal legend.

And yet, you bought Apple.

Apple is a control freak. It’s Emperor Palpatine with a graphic design makeover.


Cute Palpatine

Stylish Control Freak


It tells you what to buy, how to buy it, how to use it, and what to call it. It tells you to glorify clang over gcc due to technical measures and because a non-copyleft license is great for business (because their business requires being able to put shackles on you once in a while). It tells you it’s really the Unix that pleases your hacker insides, while at the same time doing things no other Unix does, locking you down with blithe disregard for your Unix rights. Apple throws around nice marketable names like POSIX and big cat names and iMonosyllable, and you love it. It tells you to think different, to be a Mac, not a PC, to use the world’s most advanced OS, to make it your iLife. And you’re cool with all of this.

Apple killed your inner hacker, and you’re happy with it, because keeping you deemed that keeping your inner hacker alive was too inconvenient. You satisfy yourself with a pale shadow of the hacker you once were.

I don’t get it. I’m frustrated, sad, angry that you have let this happen. You’re supposed to be the lifeblood of free software, and instead you’re using and defending McIntosh computers and devices.

I wish you could come back to being the playful rebel you once were. You’ve turned into the suits you’ve mocked in the past, and you’re happy about it.

Quite frankly, it’s starting to get lonely in Zion.

– Jordi G. H.

Tags: , , ,

On gitology

December 18, 2011
By Jordi in public

Our analysis of git hatred begins with a discussion of gitology, which I now define:

gitology (n. from git, a comptemptible fellow or DVCS): The pernicious study of the inner workings of git and how to apply them.

Thus gitology refers to the theoretical framework and mental model one must absorb as a prerequisite to becoming fully competent with git’s commonly-used features. Here a distinction must be made, because although there are many gitological concepts that only apply to git, many others are part of general DVCS theory. Gitology, however, sometimes interprets general DVCS concepts in its own way.

The following gitological concepts are not particular to git:

  • repositories (repos)
  • commits or changesets (csets)
  • directed acyclic graph (DAG)
  • branches
  • pushing and pulling changes
  • whole-repo tracking, not individual files
  • rebasing csets
  • pushing and pulling csets

The following are purely gitological and add unnecessary complexity, in addition to eventually being unavoidable:

  • Exposing the index/staging area
  • Exposing other implementation details: blobs, trees, commits, refs
  • refs and refspecs
  • Branches are refs
  • Detached HEADs (a.k.a “not on a branch”)
  • Distinguishing remote and local tracking branches
  • Choosing which branch to pull onto
  • Bare repos
  • Hard, soft, mixed resets
  • Porcelain vs plumbing

I will say more of each in turn further down.

Unavoidable gitology

If you are a user of git, I invite you to try to describe the purely gitological concepts above. If you have used git more than casually, I am sure you probably know what most of them are. If you don’t know most of them, it is likely because you haven’t used git for very long.

It is clear that gitology is unavoidable. A user of git must quickly become a student of gitology for git will make no attempt to hide its ugly guts to said user. Consider for example one of the first tasks that a user of git will encounter, making a commit. This is how git’s manpage describes this operation (and manpage it is, in the classic style of nerd-only Unix documentation):

Stores the current contents of the index in a new commit along with a log message from the user describing the changes.

Immediately the first gitological concept pops up, the index. Now, the index is not unique to git, nor even to a DVCS. Practically every VCS must implement an index in one way or another However, it is an implementation detail, which a VCS might decide to not implement for whatever reason. The great gitological stroke of genius was to gleefully expose and moreover force the user to manually handle the index. Any other common VCS only optionally makes the user handle it. Moreover, this is touted as a frequently-loved feature of git.

Let me pause here for a moment to describe why this is characteristic of git’s pathological design choices.

  1. The index is an implementation detail. Git refers to implementation details as “plumbing” and the user interface as “porcelain”, in order to make it clear that git’s designers think of git with the same reverence I think of the instrument that handles the organic waste that my body produces. Git’s makers (I hesitate to suggest that they actually consciously designed this, so I won’t call them “designers” again) refer to the index as “porcelain”, whereas it should be “plumbing”, as evidenced by how it’s handled by hg, darcs, bzr, and yes, even crufty ol’ svn handles the index automatically.
  2. They used manpages to document them. The manpage is a Unix developer format that tends to lead to terse or obscure documentation. It doesn’t have to do this (e.g. BSD tends to have great manpages), but as the name indicates, it used to be just a single page, really, just a cheat sheet with mnemonics to remind people what they already should have known about a program. The UNIX Haters’ Handbook explores this documentation problem in more detail. In this case, if you didn’t already know what an index was, the manpage is going to make it difficult for you to figure it out. For programs that are intended to be used by nerdy Unix developers only this wouldn’t be a problem; however git is primarily a tool for collaboration, very widespread collaboration, and expecting all collaborators to be nerdy Unix developers is unrealistic and hinders the very collaboration it’s supposed to encourage. They could be Windows users, they could be less technical contributors like translators or graphic artists (yes, it makes sense to put graphics under source control, even a DVCS, with some care). Manpages are inadequate for these people.
  3. Exposing the index is frequently touted. Git encourages micro-management, and git’s users end up loving this micro-management (and blog about it, and write books, and have conferences, and so on ad nauseam). This is characteristic of the perversion that git promotes, focussing on details instead of getting work done. Of course it’s hard work to understand gitology, so of course people feel accomplished once they complete this work, but it’s work that shouldn’t exist. It’s not that it’s wrong to expose an implementation detail if it allows more advanced use. It’s wrong to have no way to hide this detail completely. There are workarounds, like passing options to commit, or using a front-end to git, but remember that I specifically do not hate front-ends to git (poor things are just doing the best they can to fix a horrible UI). It should be the other way around, though. It should be abstracted away from the user, and should the user want more advanced use, there should be a developer API upon which we can build more advanced tools.

Why gitology?

So why does git do the things that it does? Why expose all the plumbing? The situation is basically the following:



While the makers of git are so happy about all the flexibility that git offers due to exposing its plumbing, its users that are not also of the same persuasion are aghast that it requires learning about the path that human refuse follows through git.

The ability of a tool to be so flexible as to allow myself to get shot in the foot never did much for me other than leave me with injured feet.

A brief excursion into gitology

The gitological concepts I enumerated above are all deserving of a more thorough study in forthcoming blog posts. For the moment, I will briefly describe the remaining ones and why it’s not necessary in order to have a working DVCS.

Blobs, trees, commits, refs

Git’s simple storage model is simple enough to be exposed to the user, so why not make everyone learn it? The more internal details we can expose, the better. It is a rite of passage for any serious student of gitology to read Git For Computer Scientists or equivalent.

refs and refspecs

Refs are part of git’s storage model. They’re basically pointers, and just like carelessly manipulating C pointers results in segfaults, carelessly manipulating git’s refs results in lost data. Most of the time it’s not a problem, so naturally they should also be exposed to the user. Refspecs are a general class of ways to specify a ref, and some of their syntax is based on what a certain hacker learned to type when he was inspecting the results when a certain kernel took a core dump on him.

Branches are refs

A branch should be a simple concept independent of any implementation detail: a line of development in the repo’s DAG. For the most part, this is what they are in git, except that they identify branches with refs, so amongst other complications this leads to

Detached HEADs

When you check out an earlier commit in git, you end up with the cryptic “not in a branch” message… then where the hell are you? Isn’t the DAG made up exclusively of branches? No, a branch is a ref, so if you’re not at a commit (recursively) pointed to by a ref, you’re not anywhere and you might as well not exist and git will eventually garbage collect you.

Distinguishing remote and local tracking branches

A DVCS really shouldn’t care where branches are, and for symmetry (because symmetry is beautiful and simple) a branch shouldn’t change its nature if it’s here or there, or at least it shouldn’t appear this way to the user. Git, of course, disagrees and makes you remember the distinction between your local copy of the remote branch and the remote branch. It’s not such a big deal in the end, except when you run into

Choosing which branch to pull onto

In git, you can’t just say, “get over here whatever differences are over there” (i.e. “pull”, a common DVCS operation), because you have to remember where to pull it to. “Here” isn’t always enough to git, because the sad developmentally stunted self-described stupid content tracker can’t know which “here” you mean. You have to specify a branch. Because your branch isn’t the same as the branch over there, so it can’t always automatically go on whatever branch here corresponds to the branch there. This is all symptomatic of the asymmetry of remote and local tracking branches, as are

Bare repos

Because in git you can’t treat remote and local symmetrically (i.e. push and pull are not symmetric operations), you also can’t push (or shouldn’t, rather) push to any repos willy-nilly. So for example, you can’t make local clones in git and push and pull amongst them, because git can’t figure out what to do with the working directory of each. The gitological solution to not knowing what to do with the current working directory is to remove it altogether in what is known as a bare repo. There are workarounds, of course (create a zillion branches, which is what git users love doing), but git’s design choices really hinder the naturality of cloning. There is also deeper design problem lurking here that seeps through the stupidity of the content tracking.

Hard, soft, mixed resets

This one is admittedly more esoteric. There are several ways to do a “reset”, and really they all mean something completely different, but I chose this gitological example to point out another boneheaded aspect of git’s, shall we say, evolution. Gitology teaches that it’s best when a single command does too much and does completely different things depending on which options you choose but actually sort of the same thing if you realise that the underlying implementation is the same. It’s like having to “move” files if you want to “rename” them because that’s how filesystems are implemented, oh, wait, I start to see where these gitologists are getting their ideas from…

Coming up…

So this is just a taste of my git hate, because the fans were clamouring for more. I have so much more to hate about git, but I already feel a little useless having devoted this much breath to git, so I will probably take a while to write the next installment. It will come, though. It doesn’t look like git is getting any less hateful any time soon…

Tags: , ,

Git… enough!

September 25, 2011
By Jordi in public

When in the course of human events it becomes necessary for a software user to disparage a thoroughly hostile DVCS, there is no recourse but to blog about it. Thus, software diplomacy has failed, and we must face the fact that I irredeemably hate git. To prove this, let these facts be submitted to a candid world.

We, therefore, appealing to the wellbeing of all software users, do in the name and by the authority of all distributed version control system decency, solemnly publish and declare that git really fucking sucks, that the previous obscene intensifier was fully necessary, and that we should do all that is within our power to reduce and minimise the proliferation of git usage.

Why I must write this

Before I proceed with my study of git hate, I must first present an apologia for why I am writing this.

You may tell me, “fine, you hate git, don’t use it. It’s just your personal preference.” Normally, for any other software I use out of personal preference, I would agree. I am a student of the Church of Emacs, but this does not mean I think everyone should use Emacs. As long as you produce text, I don’t care how you do it. You can use your text editor of choice, I can use mine, and we will both be happy doing so.

Unfortunately, the same does not hold for git. Although git can be used in isolation without ever collaborating with anyone else (after all, it is a distributed version control system, so this makes it easy to use without other people or a remote server), this is not its primary use case. If everyone around me is using git, then I am too coerced to learn git if I want to collaborate with their software development. You may argue that I can use another DVCS because everything can convert back and forth to git, but interoperability can only go so far. Eventually someone uses a feature of git that another DVCS doesn’t implement, and I will have to use git anyway.

Moreover, it is clear that git is creating a community of people who are faffing around learning gitology and feeling good about themselves for understanding abstruse concepts which are completely orthogonal to actually getting work done. This is evidenced by all the blog posts written by people being frustrated with git. As the renowned 20th century mathematician G. H. Hardy once wrote, “it is a melancholy experience for a professional mathematician to find himself writing about mathematics. The function of a mathematician, is to do something, to prove new theorems, to add to mathematics, and not to talk about what he or other mathematicians have done.” In a similar vein, it’s a melancholy experience that we spend so much time blogging about how to use git, reading blogs about how to use git, and joke about using git, instead of getting work done. Without git.

Because everyone else is wasting their time praising and discussing git, the aptly-named stupid content tracker, I must now waste my own time to point out how blockheaded it is that we spend so much time learning the tool that should be tangential to our work and ultimately unrelated to our actual work.

What will not be hated on

I want to make it perfectly clear that I will direct my hatred at git and at git only. In particular, none of the following will receive any direct dosage of hatred:

  • github
  • magit
  • git Tower
  • gitg
  • TortoiseGit
  • Your Favourite non-commandline Interface to Git
  • Whatever other tool for tracking content that happens to use git as a database or whatever

I want to make this clear, because these tools above are the reason many people claim to love git. But just because good tools have been built on a horrible core doesn’t mean the core is good. As an example I will frequently come back to, C++ is a horrible language, but many good tools and frameworks have been built on top of it.

To all the hardcore git lovers out there, git is neither necessary nor sufficient for building all of the tools you probably love that have been built on top of git. The facilities git provides to build these tools on top of it could have been provided by any other DVCS. We can and should do better than git without sacrificing any of the things you love about git, other than whatever tool has been built on top of it.

Furthermore, I also want to make this very clear: the ultimate enemy is centralised version control, not git. CVCSes are what’s really slowing our collaboration down. git is only the major enemy within the DVCS camp, but if you’re forced to choose git over any CVCS, and git is really the only choice for a DVCS for you (this is rarely true, but I’m speaking hypothetically here), then, yes, choose git. It is by far the lesser of two evils in this hypothetical Catch-22.

What will be offered instead

I will frequently cite Mercurial, abbreviated hg, as an alternative to git. I contend that Mercurial is a safer, saner, better designed, and no less powerful alternative to git. While it may be true that Bitbucket, the major non-free provider of Mercurial hosting often compared to Github, may not fulfill the requirements you have come to expect from Github, this is not due to any limitation of hg itself. As I said, I want to only argue that git as a building block is rotten, but this is not directly related to how people have managed to polish this particular turd.

I do not, however, want to be taken as simply a an admirer of hg who is used to an hg workflow and thus hates git simply because git is not hg. I will make a thorough effort to present sound arguments for the myriad reasons why git sucks that will stand on their own without comparing them to hg. When I am finished expounding my revulsion for git, I will offer alternatives that hg or perhaps another DVCS offers that demonstrate that git’s ugliness is not necessary.

Necessary. This is also a word I will come back to often. A central theme of my attack is that is that all the complications that git has created are not necessary. In order to demonstrate this, I need to offer examples of where git’s equivalent functionality exists without the parts of git that are not necessary. This is why I will frequently cite hg.

So, enough with the meta. Let’s get on to the hating itself.

Tags: , , , ,

Sage Days 30

September 20, 2011
By Jordi in public

I wrote the narrative below a while ago, but I never got around to publishing it until now. I was present at Sage Days 30, a conference for Sage developers and users which took place in Acadia University in Wolfville, Nova Scotia.

Wolfville, Nova Scotia

I first need to make some remarks about the trip itself, which contrasts greatly with my last trip abroad into the US. I flew Air Canada this time, and I overall got a very good impression of them. Compared to the last airline I flew in (I think it was United) it was nice to actually feel treated like a human instead of cattle. Relatively comfy seats, food already included in the ticket, no idiocy like charging for checking in luggage, a very good selection of in-flight entertainment. I amused myself by watching as many French-language movies as possible.

I also want to remark upon the immigration experience. A few years ago, my compatriots started to behave very poorly as guests in Canada, in effect overwhelming Canada’s immigration services with spurious refugee status requests. As a result, Canada suddenly and without warning started to request visas from Mexicans, which caused quite a stir. I was very unhappy about having to go through the paperwork to obtain an entry visa, but all in all, it was handled pleasantly by the Canadian embassy in Mexico. The process took less time than their website warned it would take, and the requisite documents were relatively easy to acquire. And when I was at the border, I didn’t get finger and retina scanned, the immigration officer asked very basic questions, and I was through the checkpoint in less than a minute.

Airport security was also overall nicer than elsewhere. While they still have the idiotic rules of no liquids, my knitting gear went through security without a problem. I noticed Canada was also having the full-body X-ray scanners in place, but they weren’t being used. I did get stopped for a pat-down, but it was fairlly unobtrusive and the security guard didn’t put his hand between my legs. Not great, but not as bad as the US. All in all, I rate it 3 out of 5 stars.

This means we can still be friends, Canada. I’m sorry my fellow Mexicans were not being nice to you, but it’s good to see you’re still making an effort to be nice back anyways.

Then there was the experience of actually being in Canada. That was also overall pleasant in every way. En route from the airport in Halifax where I rendez-voused with other Sage Days 30 participants, we found a very chatty Hungarian cab driver who delighted us with stories of his native Hungary and present Canada. And once I actually arrived in Canada, Tattingstone Inn‘s managers are the amongst nicest people I have ever met. I have never felt more welcome or better taken care of. They accomodated for all of our requests in a luxurious old-fashioned farm home, delicious breakfasts, supremely comfortable lodgings, and all for a low, low price. I can’t sing the praises of our hosts enough.

And Canadian themselves, it’s truly astounding how polite they are, how willing to offer help, how welcoming they are, how generally aware of other cultures they can be. I already knew all of these things, but after being away from Canada for so long, I had started to forget them.

Sage Days 30

Now about the conference itself. It appears I walked into a rather tight-knit group of combinatorial algebraists who had very specific problems in mind they wanted to work on with Sage. The format of the conference was that the first few days were dedicated to getting neophytes acquainted with Sage in general and the tail end of the conference was dedicated to hands-on development on Sage itself. There were a number of undergraduates who had specific summer research requirements that were presumably being fulfilled by this conference.

I was impressed with a few characteristics of the community built around Sage and of Sage itself. Sage undubitably follows a free development model, but what’s interesting is how easily users can be turned into potential developers. It really is software for mathematicians, by mathematicians. In order to accomplish this, it does a few things differently than most other free projects I’ve observed. First of all, its main Mercurial source repository is only writable by a single maintainer. Everyone else sends patches for consideration. The driving motivation here seems to be that because these are mathematicians, not seasoned developers, the senior members of the community do not want to burden the mathematicians with the minutae of source control. In this same vein, I am convinced that Python was the perfect glue language for Sage. It is easy to learn, its syntax is very close to what mathematicians are used to thinking of, even if specialised programmers can find much fault for it.

The activation energy for collaboration is thus greatly reduced. I think this is Sage’s greatest strength. Every member of the community can easily make the transition from user to developer. Not to belittle Sage’s computational abilities, which are also quite commendable, but other projects like GNU Octave would do well to learn from Sage’s experience. I am working on how to make Octave collaboration easier too.

I enjoyed the socialisation in Sage Days 30 as much as the technical discussions and work. I was unfortunately not able to devote much time to the technical aspects, because at the time I was busy with technical work of my own for a job I have thankfully since abandoned in favour of a much more interesting position. But having dinner with mathematicians-slash-programmers provided me with a sort of mathematical human contact for which I was deeply starved. Playing ultimate frisbee and mafia (or werewolf, as they knew the game) with them was also a delicious experience. Playing mafia with mathematicians is a unique treat, because they treat the whole thing as an involved logic puzzle, analysing everything with great care. It makes for a very interesting game. I am happy I brought along my go board, which also generated some interest at the same dinner party where the mafia gaming took place. I was surprised to see that the game was new to a number of them, but they seemed to quickly pick up an interest in it.

Acadia University

I was glad to also spend some time seeing some of the academic aspects of Acadia, where I am considering returning to academia and doing postgraduate work. The university is small, and it doesn’t even have a PhD programme, but I would be able to work with some people from there if I enroll in neighbouring Dalhousie in Halifax. Recently, during the second trip I shall speak of shortly, I coincidentally met some Acadia alumni who had many good things to say about it, about the smallness of the community and the few distractions there are, which allows one better concentration on academics. It sounds lovely. I am sending an application there shortly, and I hope I can get in.

Code sprint

September 3, 2011
By Jordi in public

Welcome to the sprint! Here is how it should proceed:

  1. From this list, pick an interesting function that you understand how it should work.
  2. Announce in #octave that you want to work on this function and also edit the wiki to say the same.
  3. Write a few simple tests for what you think the function should be able to do. Don’t attempt to test its efficiency, only if the function works. Use assert, error and test commands for writing your tests. Consult the doctstring for these functions if you need to.
  4. Once your tests are ready, put the special comment character %! at the front of all of your tests, and either prepare Mercurial patch (preferrable) or upload your changes to a pastebin (codepad is preferred). Or just push the patch if you have write privileges on Savannah.
  5. Mark the file as DONE in the wiki when the tests are pushed to the repo.
  6. GOTO 1

ARPACK situation

August 7, 2011
By Jordi in public

An open letter to all ARPACK users and developers

I’m writing this email to discuss the future of ARPACK. The problem is this: it’s a widely-used library, but it seems abandoned upstream (and upstream, to whom this is addressed, can confirm or deny). This has resulted in the problem of many mini-forks as each organisation distributes ARPACK patches its own way, and very often, for the same bugs. These are the ones I could find:

Additionally, the Mathworks (they make Matlab) probably also has their own version of ARPACK, but I wasn’t able to find a public version of it, nor an email to send them questions to. If someone could contact them, it would be nice to let them know.

These all seem to have modified ARPACK in some way, with minor or major bugfixes, and as far as I can tell, have mostly done so independently. To me, this seems like unnecessary work, if we’re all patching the library again and again and making our own private forks. What I therefore propose is to have some sort of central location for it and we all pool our efforts on this one location. I think it would be easiest to use Andreas Klöckner’s existing fork on github, since this requires the least maintenance and work from anyone. All that it requires for now is for each of the people above to see what patches they have made and transplant them to the git repo.

It would be helpful if upstream could confirm that they are happy with ARPACK development continuing on github and mention this on the ARPACK webpage, so that new people who are interested on ARPACK can be redirected.

Thanks,
– Jordi G. H.
GNU Octave developer

Tags: , , , , ,

By Jordi in public

This is pretty exciting.

I first read the first one of these about 10 years ago. The second one has finally been translated, and looks like publication is imminent. I hope the 3rd one doesn’t take as long!

What I like about these books is how poetic they are. They really expose the poetry of number theory. They don’t always give you the full details, often delegating them to 3rd party references, but they do give you that lovely beauty of the subject. Very motivating texts. I’m currently enjoying the first one.

The Japanese have an exquisite sense of aesthetics.

Tags: ,

By Jordi in personal

A recent conversation with a friend about Twitter vs identi.ca prompted the following response, slightly edited for formatting and anonymity:

<my friend>
man.. that’s my primary annoyance with the open source movement

<me>
What is?

<my friend>
the belief that everything has to be duplicated especially for open source, or it’s invalid

<my friend>
and a version of something that already exists with a smaller community around it and a worse user experience is somehow better

[snip]

<my friend>
someone creates something useful, and then a bunch of people jump on it and do a piss poor job trying to replicate it because they lack the ability to actually design (in the architectural as well as UX sense) and come up with a shit product that they think everyone should use because of some subjective moral high ground

While we were having this conversation, I was sitting in a cafe, it was a lovely sunny afternoon, the sun was beginning to set, and I was feeling very peaceful. I briefly tried a sort of rebuttal but couldn’t conjure up the energy to continue when the argument started to get heated. I replied instead that my surroundings were making me feel mellow. I wanted time instead to respond, which I will attempt to do now.

Let me first try to address the concern at hand. Twitter vs identi.ca. If Twitter exists, why should identi.ca exist? The only reason I started to curiously poke around identi.ca is that I noticed Debian people were using it, and I’ve found that I’m very like-minded with other Debian users and developers. So I trusted their judgement about the usefulness and safety of identi.ca, and I started using it. I’m not particularly defensive about either website; I still think microblogging is kinda dumb. I just wanted to see for myself it would be as captivating as everyone seems to think it is, and I was glad I found a microblogging service that my friends seemed to like.

And yes, it’s true that the fact that I have the source for the website, (it’s under the AGPLv3, which is like the GPL but activates its copyleft clauses by network interaction, e.g. a website!) gives me warm fuzzies. I like having source, and I’m a little sad that the other big websites that I use frequently for their services, bitbucket and gmail, don’t give me source. I briefly tried out gitorious because I wish I could at least submit patches for bitbucket, but then that’s git, and I still prefer hg.

At any rate, if I have two websites of approximately equal functionality, one gives me source, another one doesn’t, then I will disregard popularity and choose the one with source. It’s just what I prefer. I think this is what the attack about “high moral ground” was about, that I think a website should be used because it has source.

I would like to defend against the accusation of high moral ground or holier-than-thou attitude. I now try to never personally appear or act that way, except in very obvious jest (e.g. by speaking religiously about Emacs). I have learned that telling people, don’t use that software, don’t buy that product are extremely counterproductive, so I’m not trying to impose upon anyone any sort of rules of what software I think they can or can’t use. I wish everyone was using identi.ca instead of Twitter and that identi.ca would stay free with that burst in popularity, but the way to that goal isn’t by telling people what they should do; at best you might suggest why they should value source for its own sake, because it enables other kinds of interaction, but it’s pointless to pontificate. So if I or any of my peers in the free software movement have pontificated to you, I apologise for myself and I apologise on their behalf. Empty rhetoric is not what we want you to get out of our work.

Which brings me to the rest of the accusation, what in my friend’s words is a “shit product”… which I don’t think identi.ca is, the interface seems very polished to me (I probably shouldn’t have started off showing the interface by showing off my own identi.ca dark theme; dark themes seem to provoke very intense negative reactions in people). If my wish of everyone using identi.ca or (Octave instead of Matlab!) won’t happen with preaching, then how will it happen? By building a non-shit product, one with a good user experience, one that is architecturally sound.

Clearly being free software isn’t an impediment to being of good quality. We can find software both free and not of good and bad quality. But if there is software that already exists of good quality and it’s not free, then why bother creating a free alternative? And here I come again to Octave and why I felt a poignant need to write this blog post. I am, after all, working on a free project with which I hope to give Matlab users and other people with numerical computing needs better ways to freely collaborate. Octave does frequently receive accusations of having a bad interface (but Jacob Dawid’s Quint project in our private Octave clone may very soon fix this!), of not having enough toolboxes, of being slow, of not having a JIT compiler… all of these are complaints of varying validity. Matlab users have come to expect them, and if we are to offer Octave as an alternative that respects their freedom, we also need to address user complaints.

Here I come to what I felt was the crux of my friend’s complaint. Why bother? If there is something that already works, why recreate it freely and offer something that is a worse user experience? Well, I find this defeatist. If you had the option of software of equal functionality and quality, wouldn’t you prefer it to be free? I think you, yes, you deserve free software, so I’m trying to build it for you, with you. It may not be all that you want right now, but we can always try to make it better. Perhaps you may even help me! Or not, you’re free to do what you want, just improve it privately without even giving me your improvements. That’s fine too.

Will we ever win? Will Octave ever be the de-facto numerical computing environment instead of Matlab like our brothers-in-GNU with the R project are for statistical computing? Will identi.ca receive Twitter refugees when the company takes an irredeemably evil turn in the future? Who knows. But we must not lose heart. We have the capacity to build something better, and because we all deserve something better, we must keep trying. It’s our duty to ourselves, as a community. It’s not a holier-than-thou attitude; it’s thou-art-just-as-holy-as-everyone-else attitude. These are worthwhile windmills to tilt at, we have the steed, we have the lance, so tilt we must.

Tags: , , , , ,