Forgot your password?

Comment: Re:I never ever commented on the SCO issue in any (Score 1) 187

We knew what was going on when you ran your anti-IBM campaign, sometimes even positioning yourself as arguing on behalf of our community. It was a way to lend credence to IBM and MS arguments during the SCO issue. To state otherwise is deceptive, perhaps even self-deceptive.

Florian, you would not be devoting all of this text to explaining yourself if you didn't feel the need to paint your actions in a positive light. That comes from guilt, whether you admit it to yourself or not.

Go write your app, and if you actually get to make any money with it you can give thanks, because it will happen despite what you worked for previously. Keep a low profile otherwise because your credibility is well and truly blown and you can only make things worse. And maybe someday you can really move past this part of your life. But I am not holding out much hope.

Comment: Re:A lot of to-do about $700 (Score 1) 243

by m.dillon (#48192361) Attached to: Help ESR Stamp Out CVS and SVN In Our Lifetime

Over $900, and he will match the donations with his own funds so... that's definitely enough for a pretty nice machine. And with the slashdotting, probably a lot more now.

The bigger problem is likely network bandwidth to his home if he's actually trying to run the server at home. He'd need uplink and downlink bandwidth so if he doesn't have FIOS or Google Fiber, that will be a bottleneck.


Comment: Re:Git Is Not The Be All End All (Score 1) 243

by m.dillon (#48192339) Attached to: Help ESR Stamp Out CVS and SVN In Our Lifetime

A single point of failure is a big problem. The biggest advantage of a distributed system is that the main repo doesn't have to take a variable client load that might interfere with developer pushes. You can distribute the main repo to secondary servers and have the developers commit/push to the main repo, but all readers (including web services) can simply access the secondary servers. This works spectacularly well for us.

The second biggest advantage is that backups are completely free. If something breaks badly, a repo will be out there somewhere (and for readers one can simply fail-over to another secondary server or use a local copy).

For most open source projects... probably all open source projects frankly, and probably 90% of the in-house commercial projects, a distributed system will be far superior.

I think people underestimate just how much repo searching costs when one has a single distribution point. I remember the days when FreeBSD, NetBSD, and other CVS repos would be constantly overloaded due to the lack of a distributed solution. And the mirrors generally did not work well at all because cron jobs doing updates would invariably catch a mirror in the middle of an update and completely break the local copy. So users AND developers naturally gravitated to the original and subsequently overloaded it. SVN doesn't really solve that problem if you want to run actual repo commands, verses greping one particular version of the source.

That just isn't an issue with git. There are still lots of projects not using git, and I had a HUGE mess of cron jobs that had to try very hard to keep their cvs or other trees in sync without blowing up and requiring maintainance every few weeks. Fortunately most of those projects now run git mirrors, so we can supply local copies of the git repo and broken-out sources for many projects on our developer box that developers can grep through on our own I/O dime instead of on other project's I/O dime.


Comment: Re:SVN and Git are not good for the same things (Score 1) 243

by m.dillon (#48192273) Attached to: Help ESR Stamp Out CVS and SVN In Our Lifetime

This isn't quite true. Git has no problem with large repos as long as the system ram and kernel caches can scale to the data footprint the basic git commands need to access them. However, git *DOES* have an issue with scaling to huge repos in general... it requires more I/O, certainly, and you can't easily operate on just a portion of a repo (a feature which I think Linus knows is needed). So repos which are well in excess of the RAM and OS resources required to do basic commands can present a problem. Google has precisely this problem and it is why they are unable to use git despite the number of employees who would like to.

Any system built for home or server use by a programmer/developer in the last 1-2 years is going to have at least 16G of ram. That can handle pretty big repos without missing a beat. I don't think there's much use complaining if you have a very old system with a tiny amount of ram, but you can ease your problems by using a SSD as a cache. And if you are talking about a large company... having the repo servers deal with very large git repos generally just requires ram (but client-side is still a problem).

And, certainly, I do not know a single open source project that has this problem that couldn't be solved with a measily 16G of ram.


Comment: It's not that big a deal (Score 1) 243

by m.dillon (#48192141) Attached to: Help ESR Stamp Out CVS and SVN In Our Lifetime

It's just that ESR has an old decrepit machine to do it on. A low-end Xeon w/16-32G of ECC ram and, most importantly, a nice SSD for the input data set, and a large HDD for the output (so as not to wear out the SSD), would do the job easily on repos far larger than 16GB. The IPS of those cpus is insane. Just one of our E3-1240v3 (haswell) blades can compile the entire FreeBSD ports repo from scratch in less than 24 hours.

For quiet, nothing fancy is really needed. These cpus run very cool, so you just get a big copper cooler (with a big variable but slow fan) and a case with a large (fixed, slow) 80mm input fan and a large (fixed slow) 80mm output fan and you won't hear a thing from the case.


Comment: Re:Bruce, I know why u r disappointed. Let me expl (Score 1) 187

So, I see this as rationalization.

The fact is, you took a leadership position, and later turned your coat for reasons that perhaps made sense to you. But they don't really make sense to anyone else. So, yes, everyone who supported you then is going to feel burned.

You also made yourself a paid voice that was often hostile to Free Software, all the way back to the SCO issue. Anyone could have told you that was bound to be a losing side and you would be forever tarred with their brush.

So nobody is going to believe you had any reason but cash, whatever rationalization you cook up after the fact. So, the bottom line is that you joined a list of people who we're never going to be able to trust or put the slightest amount of credibility in.

And ultimately it was for nothing. I've consistently tried to take the high road and it's led to a pretty good income, I would hazard a guess better than yours, not just being able to feel good about myself.

Comment: Re:This could be really good for Debian (Score 5, Insightful) 549

by Bruce Perens (#48188887) Attached to: Debian's Systemd Adoption Inspires Threat of Fork
I am beginning to be wary of systemd, but no. I am talking about anal-retentive policy wonks who believe they only make the distribution for themselves and have (perhaps without intending to) systematically marginalized Debiian and made the project a whore to Ubuntu.

There is no distinction between any AI program and some existent game.