Note the end this week of pc98, the most focused of niche platforms.
- The trouble with FreeBSD. Gets a lot wrong, though.
- Found this sitting on my dusty bookshelf.
- Video editing and the FreeNAS Mini.
- a2k17 hackathon report: Patrick Wildt on the arm64 port
- Goodbye FreeBSD/pc98 (via)
- OpenBSD wallpaper.
- Lessons learnt from adding OpenBSD/x86_64 support to pkgsrc
- OPNSense 17.1 released.
- New BSD Magazine issue
Justin – what’s does the author get wrong in the “trouble with FreeBSD” post?
As written, it gives the impression that Matthew Dillon was the problem; that FreeBSD was fine but he was committing too fast – and implying that it wasn’t good code by calling him names – a “rockstar ninja 10x developer” is meant negatively in this context.
Rather than revisit old arguments and emails, you can look at the results – DragonFly worked very well, very early on, and FreeBSD 5 and 6 and to some extent 7 were a mess.
There’s an even larger comparison to be made between the two incidents highlighted in the story. I don’t know if Rice got into that in his talk. Matthew Dillon commits some code and there’s an argument about technical direction, and he gets stripped of his ability to contribute. Randi Harper gets attacked – not a technical argument, but actual threats – and the group does, at first, nothing. I know it’s a bit more complicated than that, but in broad strokes, that’s the opposite of how you maintain a community.
Of course, given my involvement in DragonFly, I have a clear bias on what I think was right – but my point is still correct. And also: this is all in the past and what we all work on now is not what we had then. It’s perhaps not worth worrying about/rehashing, except as a lesson for future growth in any BSD.
Justin – I appreciate the history and your viewpoint.
Question: I know this is unfair to ask … but given that DragonFly has now existed for 10+ years and the 2 code bases (FreeBSD & DragonFly) have diverged, what are the pros and cons of both DragonFly & FreeBSD given the technical decisions each has made over the years.
E.g. Is DragonFly better at networking but FreeBSD is better to be used as a storage appliance OS. I’m just making that up , but you get that idea. What’s the strengths and weakness of each OS?
That can’t be answered except in strokes so broad they become vague. One person’s “resistant to change” is another person’s “stability I need for a platform”. (To take slightly from the BSD talk you were asking about before.
I personally like DragonFly because the developer community is small and friendly. I’m confident that if and when I met any of the other developers, I’d happily buy them a drink. It may seem like a strange criterion, but why would I volunteer myself to work with a group that was other than that?
The claim about Dillon is that he’s an asshole who has to be project dictator, not that his technical contributions weren’t good. That claim is wholly consistent with his good work in the DragonFly fork.
(And it’s a relatively small part of the talk — calling it “a lot wrong” seems misleading.)
But at that time FreeBSD kept everything under to carpet. Why are the people that know and recall things so vividly now? As in Dillon actually took back his code since FreeBSD majority doesn’t need it..
At first I thought the lwn describes that pdf paper, from that recent bsd conf, that talks about why freebsd is way behind linux. But it turns into some useless recall of controversial events that took place in the not so organized freebsd of the past (it reminds me about the talks inside gentoo, regarding their organization, of the past few years, talks that are still very actual, ps : sorry, I was never interested into this part of the oses I use excepting when these organizational models are strong arguments when it comes to problems that I have to fight in order to be able to keep using certain software packages) instead.
pps: Why does it have to be there people that know and recall things so vividly now? As if Dillon actually took back his code since FreeBSD majority doesn’t need it..
C – The two main sections of the article are about how FreeBSD, as a group, treated its members when there was a conflict. The article casts it as a procedural problem, where having some rules laid down would have made it OK.
That would help. But, I’d argue that it’s an institutional problem, where the tendency for a small group to make nonpublic decisions makes it harder for tough actions (like the source control change) to be made, and for people to handle those changes. Whether that’s a lot wrong or not a lot wrong is probably not the point.
My informal experience with volunteer organizations is that you have to be public (or to overuse the phrase, ‘open’) with decisions, and the decision-making process. If you undercut people’s desire to contribute, you undercut the engine that makes a volunteer project run. I don’t know – does FreeBSD Core still maintain a secret mailing list? Do they have private meetings, or is there an agenda or minutes published? I think there’s a lot of value in these things, and working that way would possibly have avoided some of the following problems that were described.
What sort of communication they had in that core team if they say that Dillon talked (responded) to them through commit descriptions and basically through his actions, the commits themselves? Was the commit history lost along their svn/subversion -like software hopping? Shouldn’t such an incident details be easy to find with a google search? Why there is blank? Isn’t there a hacker hero in the Marvel -like comic universe, it must be isn’t it? Since Dillon’s that kind of a hero in their folklore.
What I’d be most interested in reading about is a detailed analysis of the strengthens and weaknesses of DBSD vs FreeBSD today.
No good will come from re-hashing the Dillon incident from over a decade ago.
But I do believe a lot can be learn in the technical decisions and outcomes of 2 codes based that were the same and have since gradually diverged.
Maybe I’m crazy, but it’s so rare to be able to study “identical twin” scenarios in life.
And given that DSBD & FreeBSD initially shared the exact same code base – I would find it an absolutely fascinating read to compare the two OSes today on feature, functionality, etc.
Unfortunately, I don’t know DSBD enough to write such a comparison.
Repeating the performance tests would be a good step:
https://www.dragonflybsd.org/performance/
In a perfect world, we’d have that sort of testing running near-continuously, for all the BSDs, so we’d have a performance benchmark to work with. I don’t know anyone who has that much time and spare hardware laying about, but dreaming is free.
Justin
I’d donate money to be used towards someone setting up a CI environment to run performance test.
Even though it wasn’t what I was talking about when I said I’d like to see a detailed paper on how FreeBSD and DBSD have diverged … I can see how there would be termodous value in this.
As such, how best can I donate so that my donation goes towards exactly this performance CI effort?
+1
On CI benchmark & comparison article on current state of FreeBSD vs DragonFly
Donating money to a specific effort is great, but we have to have someone specifically working on that first – and I don’t think there is anyone.
I read this somewhere, and it’s true: if you want to give to an open source project, money is fine, but developers need time more than they need money. This is perhaps why you sometimes see project that ask for funding to give people time away from normal paid work to produce more open source code – turning cash into time. Not saying that we could use that here, though, cause that requires a developer in just the right circumstances.
@justin
What’s you’re describing sounds similar to how LuaJIT ran.
It was an open source project that took donations to add specific features , in an effort to keep Mike Pall fully employees through sponsorship.
http://luajit.org/sponsors.html
I think that once HAMMER2 is in place, one of the primary reasons to use FreeBSD in the first place (ZFS), will diminish over time.
Any ETA on Hammer2 release date?
I’m addition to the eta on hammer2, the document below says it’s been in development since 2011.
Is it normal for a file system to take 6 years to develop?
https://www.dragonflybsd.org/hammer/
Anonymous: 6 years, sure. UFS is still being worked on by its primary architect and it’s… 4 decades old? 5? Admittedly not a lot of work, but it has been decades, after all.
In terms, Hammer1 is already superior to ZFS in some respects. But is it “better enough” and is Hammer2 even more compelling? I use ZFS on linux, and am completely sold — it’s saved my life several times. But most people in Linux-land still use ext4 (some of them avoid ZFS for licensing reasons, it’s true, but they could use FreeBSD if that was really the concern). Would people switch OS’s just for the filesystem? I used to use Dragonfly (and FreeBSD), and often think about it again, but I don’t have spare hardware lying around and linux is too convenient for my work.
Does anyone have any idea when Hammer2 will be released?
@bsd — “Shouldn’t such an incident details be easy to find with a google search?”
As I understand it (it predates my involvement in the project), the incident was mostly in private emails.
private emails? is the marino case also just in private emails? Now (marino) / then (dillon) in private emails and later (publicly) on lwn?
About the file systems, hammer was ready in a few months. Since there are flaws with it and hammer2 is the only way to go from that point on, why do people want hammer2 ready in hammer1’s time?