#bitrig

[sevanjans]

A week of pkgsrc #11

A week of pkgsrc #11

It’s been a while since the last post in the series, the details of what was covered in these posts was the partial basis of my talk at BSDCan and I got to repeat the talk again in Berlin, I was much less nervous the second time, not having a fire alarm going off during the talk may have helped. I will cover briefly some things that were mentioned in the talks which I hadn’t written up here, for…

View On WordPress

[dentarg]

Relevant quotes from the OpenBSD forked thread at openbsd-misc.

Theo de Raadt:

On Wed, Jun 13, 2012 at 7:44 PM, Dominguez, Roland wrote:

I just came across this article and was wondering if it's legit: http://www.h-online.com/open/news/item/OpenBSD-forked-to-create-Bitrig-1616954.html

Yes, it's legit and it reflects the reality of the facts

Except for the fact that it is bullshit.

They started the fork because they got kicked out because one developer (Marco) hired 5 other developers for his startup company, and attempted to hire around 10 other developers in a sneaky and underhanded way. They were told, oh i forget they were "asked", to not tell anyone else in OpenBSD that this was happening, probably because people "including Theo" would be upset.

Funny thing is, I've never been upset about the 20+ OpenBSD and ex-OpenBSD developers who now work for google.

Previously, many of those developers were in critical positions in the development team. As they were suddenly hired with such terms and conditions, they became more scarce in OpenBSD -- perhaps because they suddenly got real busy with work, but also to avoid telling others that this was happening. Various projects lagged. To avoid telling a lie, they instead chose to not tell the truth. It had effects. It was dishonest of them to not tell their co-developers that they were creating vacuums in the development process.

So because of those decisions, they are now gone from OpenBSD. And now they miss it. So now, all these guys who work for the same company have started a fork. And it is directed by the guy who hired them in the first place.

From where I stand, that is the truth.

Yet none of that is in that article, because the truth hurts, doesn't it guys?

Ted Unangst:

On Sun, Jun 17, 2012 at 16:14, Peter Laufenberg wrote:

Funny thing is, I've never been upset about the 20+ OpenBSD and ex-OpenBSD developers who now work for google.

Do they still work on OpenBSD and contribute back?

yes. some more, some less.

Theo de Raadt:

first off, I do not understand the word "back" that Peter used.

they simply "contribute" by making changes in our tree. they don't "contribute back". using "back" implies that what they work on at google has anything to do with openbsd. none of us know if that is the case, and if it is, so what?

they are free to do anything they want.

google is their job. other people have jobs too :-)

those openbsd developers who work there, and also do commits here, do so out of passion, and fully cooperate with the other developers to move a source tree forward. that's good enough for us. other people work at other jobs, and the same happens.

secondly, what strikes me as very interesting is that almost all developers who get new jobs -- at google or elsewhere -- tell their co-developers that they are in the midst of a life-changing moment in their lives, and that will get busy and not be of as much use in the next while.

except that did not happen for the crew marco hired.

in that case, secrecy was paramount.

in that case, they got busy and did not tell the people they were working with. they effectively abandoned the projects that were active in the tree headed to the next release, and left other developers hanging out to dry -- by not telling them that 5+ of them were suddenly not capable of helping.

as a group, they chose to be ex-OpenBSD developers, by their actions of not participating with partners they had promised to develop with.

even now, some active OpenBSD developers are judging me for my reaction, and I can understand the uncertainly of their position.

make of it what you will.

it's too stressfull. perhaps i should become an ex-OpenBSD developer too, those people seem to have much more glamourous lives...

Theo de Raadt:

The secretive nature is concerning. But I hope that this situation can somehow turn out to be beneficial to both projects in the long term.

As long as my favourite and most relied upon OS continues to evolve, I will be happy. And I will certainly continue to buy from and donate to the OpenBSD project where possible.

Well let me break some secrets.

It is run by Marco Peereboom, and the machines it operators on are associated with the company comformal and their partners.

Dale Rahn is in there too.

So is Thordur, certain.

Owain is involved too, I think.

I am certain someone can use their git to find out who they are.

Ariane wants to be involved as well, but is still waiting to see how others in the project feel.

All of those people work for Marco Peereboom as employees and contractors.

They are a US operation.

Ariane van der Steldt:

On Mon, Jun 18, 2012 at 12:59:16AM -0600, Theo de Raadt wrote:

Ariane wants to be involved as well, but is still waiting to see how others in the project feel.

I've changed from waiting to being involved.

And in Theo's interest in breaking secrecy: I've stepped down from maintaining uvm. Why? Politics between me and Theo. I'm unhappy with how the situation of the fork was handled. I've been collateral in the whole matter twice and taken it in stride. I've expressed interest in the fork and am now suspect/tainted. Third time's the charm. Discussions between me and Theo now trigger anger with both of us, which is not conducive to OpenBSD or our fellow developers. I cannot commit to uvm under those circumstances.

Uvm is now without architect/lead, but that's fine since it has been that for years.

Theo de Raadt:

On Mon, Jun 18, 2012 at 12:59:16AM -0600, Theo de Raadt wrote:

Ariane wants to be involved as well, but is still waiting to see how others in the project feel.

I've changed from waiting to being involved.

And in Theo's interest in breaking secrecy: I've stepped down from maintaining uvm. Why? Politics between me and Theo.

About 2 weeks ago ariane came to me privately to say this:

1) That 4 weeks ago she had become aware the fork did in fact exist, counter to previous assertions all the people now working on bitrig had gotten from their boss Marco. 2) Had just now decided to mention it to me. 3) Also just now had decided to on a desire to work on on both projects. 4) Want to know if this would be ok; if there would be consequences.

And finally:

5) For the last 4 weeks had been too busy to tell us, working 12 hour days.

I said I would not decide, but to ask all the developers.

However, instantly I recognized that the last part (5), about having too busy to tell us, was not truthful.

The truth is, ariane did not tell us because of fear. And I can understand that, there are many people upset to various levels about these happenings. However, wrapping that up in a lie about having been too busy is a not good. Those 4 weeks were spent mulling over whether to be part of that fork and how to tell us, not by being too busy with work.

Therefore, ariane, I do not believe that you found out something so politically big, sat on it for 4 weeks because of being too busy, and then suddenly decide to disclose it and the desire to be part of it.

And that is not political. I feel that I (and others in the project) have been lied to in that part.

I'm unhappy with how the situation of the fork was handled.

The situation of the fork was handled entirely by Marco Peereboom -- your boss.

I've been collateral in the whole matter twice and taken it in stride.

Yes, we are all blameless. Especially people at that company, who all claim they got too busy to tell others that they were too busy.

I've expressed interest in the fork and am now suspect/tainted.

Certainly you are: You misled us.

Third time's the charm. Discussions between me and Theo now trigger anger with both of us, which is not conducive to OpenBSD or our fellow developers.

I was not angry in my mail -- I was truthful and exact.

A diff was sent which adds a non-standard flag to mmap() to accelerate realloc() performance. For years the project has had an attitude that adding extensions to standardized system calls should be a last resort. Rather than discuss this with developers, ariane went and spent time, and then mailed in a diff -- asking only for an OK. Not requesting the start of a larger discussion, but only asking for an OK.

In a reply to that diff, I

(1) explained my continued reluctance for such non-standard flags.

(2) I also explained that this was a poor time to put such changes into the tree with a coming hackathon, followed by the lock to our next release soon after.

(3) I also then explained that due to recent events (recently two, serious repairs had to be made to ariane's uvm changes without ariane being around), I am pessimistic about the commitment level for such big changes in the tree. Normally a way around this is to test them as uncommited diffs in the snapshot builds, but I only do that for people who I totally trust (one reason is that mistakes can be quite costly, as I can damage 12 build environments in one go), and quite frankly, I do not trust Ariane nearly as much as before.

At that point, Ariane got seriously angry, and has now resigned.

I cannot commit to uvm under those circumstances.

Unfortunate.

Matthew Dempsky (OpenBSD developer working for Google):

On Wed, Jun 20, 2012 at 7:42 PM, Nico Kadel-Garcia wrote:

Coming back and checking the thread, allow me to start laughing REALLY HARD at this, since I've seen no other comments on it. The ability to lock your hardware with libc and glibc errors is only exceeded by the kernel itself, and maintaining compilers to take advantage of new libc features is...... well, it's a lot of work too. And keeping it compatible with the various other GPL or open source tools that are commonly used in the real world? Really, really good luck with those!!!!

I'm confused. The direction Bitrig is taking their toolchain is roughly the same that a lot of OpenBSD developers would like to go too, just Bitrig is explicitly not concerned about less common architectures which makes their job way easier.

I do hope they succeed on that matter at least. If they can't even get amd64/i386/arm working with LLVM, then it's a rough road ahead for us when we also have to worry about sparc, sh, mips, hppa, vax, and m88k too.