tolenka

Remember, all public contribution to open source is good. Wishing that volunteers trying to scratch their own itch would do it in a way more convenient for you is unrealistic.

Perhaps I have unduly high standards for contributors, but I find that cleaning up other people's incomplete or unpolished code is often difficult, time consuming, and often takes longer than just writing the feature myself.

Whereas, if the contributor opened a dialog with me, I could help guide them towards something acceptable upstream with much less effort.

I'm not convinced that Github itself is a net-win for the mainline projects -- without Github, your only options for long-term sustainability of a fork are to submit your patches to the project or to expend considerably more effort maintaining a local vendor branch.

If you need to add a feature to a project, that requirement isn't going to disappate just because Github does not exist -- you will almost certainly implement it regardless, and the path of least resistance will be submitting (and having it accepted) upstream.

With Github, it becomes much, much easier to create a fork, hack out what you need, and maintain that fork indefinitely in a form that can't be pulled back in without further polish/review that will likely never happen.

An aside: I'd really love to excise "scratch an itch" from the collection of developer idioms.

It sounds so unnecessarily uncouth. =)

My point is that both are way ahead of your typical Java shop, and way ahead of Windows, and that FOSS and Linux do not deserve the beating given to them by the author of the blog post.

I think that's a bit unfair to Java shops. =)

AFAIK CFS is considered >= ULE2 by most people, and I'm not aware of significant regressions introduced by CFS, so the high degree of conservatism you pointed out in the FreeBSD project wouldn't have been warranted in this case. I don't have the background to argue the finer points of this issue, but it's off topic for this thread, anyway.

CFS is based on knowledge gleaned from years of work on earlier schedulers by Con Kolivas and Ingo Molnar. In the meantime, the scheduler was replaced several times in the "stable" tree while they "figured it out". It took just as long, made a bigger mess, and ultimately cost more to produce (not to mention all the flamewars and bad blood engendered in the process).

Whether CFS >= ULE2 is a very nuanced question, but it's fair to say that the schedulers are much closer.

I think what the commenter meant was the cathedral vs the bazaar model of development. Would'nt FreeBSD, NetBSD, etc all be in the same boat as Linux? Granted that Linux has a benevolent-dictator-aka-linus, but that does not make it deviate too much from the bazaar model.

Most other kernel development teams operate with a considerably more conservative approach ("the cathedral") than is engendered by Linux and specifically enabled by dvcs/git ("the bazaar").

In Eric Raymond's essay, he contrasted the two development models as such (quoting wikipedia):

The Cathedral model, in which source code is available with each software release, but code developed between releases is restricted to an exclusive group of software developers. GNU Emacs and GCC are presented as examples.

The Bazaar model, in which the code is developed over the Internet in view of the public. Raymond credits Linus Torvalds, leader of the Linux kernel project, as the inventor of this process. Raymond also provides anecdotal accounts of his own implementation of this model for the Fetchmail project.

http://en.wikipedia.org/wiki/The_Cathedral_and_the_Bazaar

I'd say just about every other kernel available today is developed in "the cathedral", although even then I think that Raymond's comparison (and judgments) are a vast oversimplification.

For all its flaws, git (and github) are becoming the preferred choice of hackers everywhere

Some very vocal people, but not what I'd say "hackers everywhere". As a regularly user of hg and git, I'm not particularly convinced that dvcs provides significantly compelling advantages outside of Linux's development model.

If any, Solaris is the only counter-example to Linux - not FreeBSD.

I'm not sure why you'd say that is.

The success of Linux deserves serious consideration, but breathless marvel at Linux and its development practices is entirely misplaced.

All the major patches are done by one expert, and many of them are fairly innovative. Ingo Molnar did CFS. Ted Ts'o does a lot of really high profile work on filesystems. There are many more examples.

Linux is full of examples of poorly designed systems being slipshod replaced for slightly better designed systems that are well behind the state of the art.

In the same time Linux has gone through multiple schedulers (and scheduler flamewars), FreeBSD developers have designed, implemented, tested, and iterated on ULE, and then ULE2, finally (after much review, testing, and careful consideration) merged it and made ULE2 the default scheduler.

The scheduler wasn't adopted until it was investigated from all angles over years, and found to not introduce any significant performance regressions.

The kicker? The previous scheduler was on par with Linux, ULE2 seems to perform considerably better for many workloads (eg, MySQL) on many-core machines.

Innovation isn't magic -- it involves a lot of hard work and careful design by a lot of people.

The Linux development process is lightyears ahead of the typical industrial development process. Git, which was created by and for Linux kernel hackers, has been instrumental in helping Linux get ahead.

Really? I'm not sure what innovations you're thinking of here.

  - Solaris' ZFS vs (incomplete) btrfs
  - *BSD's kqueue vs. epoll/inotify/dnotify/
  - Solaris' zones vs ?
  - FreeBSD vimage (network stack virtualization) vs ?

If you don't have write privileges into the SVN repository, you have no ability to revision control your changes without creating a tracking repository of your own.

This is fairly unique to open source software -- it's not something that occurs in an organization, and should only occur when a user without commit access is doing large-scale modifications to a project.

Unfortunately, the functionality often used to maintain divergent forks where individuals fail to push small hacks/changes immediately back to their origin project.

Creating a SVN branch for every experiment rapidly gets out of hand.

Out of hand how? I've worked in organizations where every single feature received a developer specific branch (eg, branches/tolenka-feature-xyz) and never ran into trouble.

The big difference with DCVSes is that scaling across lots of developers is not a problem, branches are strongly encouraged, and merging works really well.

Given merge tracking, merging works more or less the same as a DVCS.

As far as scaling across developers, I'm not sure what the issue is.

I can't say I understand your point.

With svn, I commit often, as long as the code builds and my own unit tests pass. If I need to make a lot of breaking changes, I use 'svn cp' to create a branch and then I can still leverage svn's merge tracking in keeping that branch up-to-date.

This seems like the same way I use git/hg, but without worrying about excessively divergent local/remote branches across machines -- I can see your branches, you can see mine, they're all centrally accessible by definition.

I would say that what I, and others, did was more like someone going to a website, hitting view-source, and saying "hmm this is interesting, there is something to be learned here" and then putting the interesting code snippets up on their blog. especially when the first line of my readme said "this is just for learning's sake, dont use this on your real website."

You reproduced the code wholesale -- that was infringement, not fair use.

Apple if your listening, why not just open source PastryKit?

They don't want to -- that's their prerogative. I find your sense of entitlement baffling.

I do understand the indifference -- the deadline is more or less completely arbitrary, as there are very few critical scheduling issues dependent on strictly punctual delivery, and all that is really required is reasonable timeliness. If the professors allow it, why not use the additional latitude to your advantage?

Hard deadlines are generally driven by what are ultimately financial/market concerns. I sweat the deadlines when a trade show is approaching, and I sweat the budget when we see schedule slippage on an release, but most of the time I'm happy as long as everyone is productive, progress is being made, and the budget looks OK.

Outside of school, deadlines are usually based on project estimates, and as long as you provide sufficient notice, it's often possible to adjust the schedule and dependent activities to fit the actual time required to complete task(s). If it's not possible, then business decisions have to be made regarding what tasks can be abandoned or modified to meet the hard deadlines -- regardless of how the business adapts, you're better off bringing up a scheduling issue before it becomes critical.

Given that deadlines in education are more or less entirely arbitrary, I don't see the harm in extending them within reason, and providing students with the opportunity to successfully complete their tasks.

As for tardiness -- it happens. If someone consistently fails to meet our estimates, but delivers a sufficient degree of value within a reasonable amount of time, then I'll simply learn to incorporate their individual turn-around time in my estimates.

Distribute the code to anyone else under any terms other than the GPL.

For most iPhone applications, why is this better than the built-in GameKit, which allows for peer-to-peer discoverability over bluetooth and WiFi without any active internet connectivity?

I could see an argument for cross-platform compatibility, as GameKit is iPhone-specific.

That said, is the service being provided sufficiently difficult to implement that it warrants paying (and relying on) an external service? How likely is it that an open source version of the server/client could be produced?