<div dir="ltr"><div dir="ltr"><div class="gmail_default" style="font-family:trebuchet ms,sans-serif;font-size:small">I like the web forum idea and I agree with the comments about HAMMER2 needing a HAMMER1-like mirroring capability soon-ish.</div><div><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div><br></div>Tim</div></div><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Jul 22, 2019 at 1:56 PM Matthew Dillon <<a href="mailto:dillon@backplane.com">dillon@backplane.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">For the last week I've been testing out a replacement for Monster, our 48-core opteron server.  The project will be removing Monster from the colo in a week or two and replacing it with three machines which together will use half the power that Monster did alone.<div><br></div><div>The goal is to clear out a little power budget in the colo and to really beef-up our package-building capabilities to reduce the turn-around time needed to test ports syncs and updates to the binary package system.  Currently we use two blades to do most of the building, plus monster sometimes.  The blades take almost a week (120 hours+) to do a full synth run and monster takes around 27.5 hours.  But we need to do three bulk builds more or less at the same time... one for the release branch, one for the development branch, and one for staging updates.  It just takes too long and its been gnawing at me for a little while.</div><div><br></div><div>Well, Zen 2 to the rescue!  These new CPUs can take ECC, there's actually an IPMI mobo available, and they are fast as hell and cheap for what we get.</div><div><br></div><div>The new machines will be two 3900X based servers, plus a dual-xeon system that I already had at home.   The 3900X's can each do a full synth run in 24.5 hours and the Xeon can do it in around 31 hours.  Monster will be retired.  And the crazy thing about this?  Monster burns 1000W going full bore.  Each of the 3900X servers burns 160W and the Xeon burns 200W.  In otherwords, we are replacing 1000W with only 520W and getting roughly 6x the performance efficiency in the upgrade.  This tell you just how much more power-efficient machines have become in the last 9 years or so.<br></div><div><br></div><div>This upgrade will allow us to do full builds for both release and dev in roughly one day instead of seven days, and do it without interfering with staging work that might be happening at the same time.</div><div><br></div><div>--</div><div><br></div><div>Future trends - DragonFlyBSD has reached a bit of a cross-roads.  With most of the SMP work now essentially complete across the entire system the main project focus is now on supplying reliable binary ports for release and developer branches, DRM  (GPU) support and other UI elements to keep DragonFlyBSD relevant on workstations, and continuing Filesystem work on HAMMER2 to get multi-device and clustering going.</div><div><br></div><div>John Marino (marino) pioneered the 'synth' system for dports and continues to help out, but his focus is on RavenPorts for now.  Rimvydas Jasinskas  (zrj) and Antonio Huete Jimenez (tuxillo) have done a huge amount of work bringing dports back into operational form and getting the FreeBSD ports sync stuff working better.    DragonFlyBSD is still using synth, and will probably remain on synth for the foreseeable future, though there is always some discussion about how best to move dports forwards.  It's an excellent build platform for us.</div><div><br></div><div>Francois Tigeot (ftigeot) has done a ton of work taking DRM up to Linux-4.7.10 and this has worked very well for Intel iGPUs.  We are now finally starting to dive into Linux's 'amdgpu' subsystem which is much older, in order to modernize our AMD support (which is still deficient).   Numerous other people have spent a considerable amount of time helping test GPU support and tracking down bugs.  The work is ongoing.</div><div><br></div><div>I apologize for only writing everyone's names in plain ascii :-)</div><div><br></div><div>Right now HAMMER2 makes for an excellent single-device filesystem (extremely well given that it supports writable snapshots and compression out of the box), but it remains deficient when it comes to expandable storage, multiple devices, and clustering.  This will be active work for me but honestly the amdgpu support has to come first so it's still going to be a long-haul for HAMMER2.</div><div><br></div><div>The mailing lists are not seeing much if any activity any more.  This is more a generational issue... people kinda prefer web-based forums these days and younger generations do not use mailing lists at all for group stuff (not really).  Even the devs almost universally use IRC and not mailing lists for discussions now (its kinda too bad that we don't have a permanent irc log stored on DFly servers for posterity).  So we are looking into potentially shifting user interaction to a web-based forum, perhaps this year, and retiring the mailing lists, leaving just an archive for the mailing list.  Possibly sometime this year, so look for action on that upcoming.</div><div><br></div><div>Our other main developers: Sascha Wildner (swildner), who keeps the tree in tip-top shape and catches numerous issues, Justin Sherrill (JustinS) who handles our distribution rolls and the DragonFly and general BSD blog on our home page, Sepherosa Ziehau (sephe) who focuses on the network subsystem, Tomohiro Kusumi who helps with HAMMER and HAMMER2, Peter Avalos, and more.  I will list more down below.<br></div><div><br></div><div>--</div><div><br></div><div>It's hard to say how the future will develop.  There are only three open-source operating systems in the entire world that really pull it together on having a complete, modern, SMP kernel:  Linux, DragonFlyBSD, and FreeBSD.  And that's it.  We also have NetBSD and OpenBSD and I'd kinda like to know what their plans are, because the future is clearly going not only multi-core, but many-core.  For everything.  But as I like to say, for SMP there are only three at the moment.  One can't dispute that Linux has nearly all the eyeballs, and DragonFly has very few.  But OpenSource tends to live on forever and algorithms never die... I think there is a place for all of these projects and there really aren't any alternatives if you want a sparkling clean system that doesn't have too many layers of abstraction.  At the current Juncture DragonFlyBSD is doing well and there are no plans to slow down or stop.</div><div><br></div><div><div>There are many other developers who help out with DragonFlyBSD on a regular basis, or drop in from time to time, as well as past developers who did an awful lot of work.   For this I am going to run the names out of the git log in alphabetical order, so I don't miss anyone (hopefully).  And to 'User' and 'Charlie Root'... we will never know who you were, but the party is still going!</div><div><br></div><div>-Matt</div><div><br></div><div>Aaron LI<br>Adam Hoka<br>Adam Sakareassen</div><div>Adrian Chadd<br>Aggelos Economopoulos<br>Alex Hornung<br>Alexander Kuleshov<br>Alexander Polakov<br>Alexandre Perrin<br>Antonio Huete<br>Antonio Huete Jimenez<br>Antonio Nikishaev<br>Aycan iRiCAN<br>Ben Woolley<br>Bill Yuan<br>Brad Hoffman<br>Brills Peng<br>Charlie Root<br>Chris Pressey<br>Chris Turner<br>Chris Turner<br>Chris Wilson<br>Christian Groessler<br>Constantine A. Murenin<br>Daniel Bilik<br>Dave Hayes<br>David P. Reese<br>David Rhodus<br>David Shao<br>David Xu<br>Diederik de Groot<br>Dimitris Papastamos<br>Dylan Reinhold<br>Ed Schouten<br>Eirik Nygaard<br>Eitan Adler<br>Francis GUDIN<br>Franco Fichtner<br>Fran\xc3\xa7ois Tigeot<br>Gregory Neil Shapiro<br>Gwenio<br>Hasso Tepper<br>Hidetoshi Shimokawa<br>Hiroki Sato<br>Hiten Pandya<br>Ilya Dryomov<br>Imre Vadasz<br>Imre Vad\xc3\xa1sz<br>Imre Vad\xc3\xa1sz<br>Jan Lentfer<br>Jan Sucan<br>Javier Alc\xc3\xa1zar<br>Jean-S\xc3\xa9bastien P\xc3\xa9dron<br></div><div>Jeffrey Hsu<br>Jeremy C. Reed<br>Jeroen Ruigrok/asmodai<br>Joe Talbott<br>Joerg Sonnenberger<br>Johannes Hofmann<br>John Marino<br>Jordan Gordeev<br>Joris Giovannangeli<br>Justin C. Sherrill<br>Levente Kurusa<br>Liam J. Foy<br>Lubos Boucek<br>Magliano Andrea<br>Markus Pfeiffer<br>Matt Dillon<br>Matteo Cypriani<br>Matthew Dillon<br>Matthias Rampke<br>Matthias Schmidt<br>Maurizio Lombardi<br>Max Herrgard<br>Max Herrg\xc3\xa5rd<br>Max Okumoto<br>Maxim Ag<br>Michael Neumann<br>Michael Neumann<br>Michael Neumann<br>Mihai Carabas<br>Nicolas Thery<br>Nicolas Thery<br>Nolan Lum<br>Noritoshi Demizu<br>Nuno Antunes<br>Nuno Antunes<br>Peeter<br>Peeter Must<br>Peter Avalos<br>Pierre-Alain TORET<br>Robert Garrett<br>Robin Hahling<br>Rui Paulo<br>Rumko<br>Samuel J. Greear<br>Sascha Wildner<br>Scott Ullrich<br>Sepherosa Ziehau<br>Simon 'corecode' Schubert<br>Simon Arlott<br>Simon Schubert<br>Simon Schubert<br>Stathis Kamperis<br>Sylvestre Gallon<br>Thomas E. Spanjaard<br>Thomas Nikolajsen<br>Tim<br>Tim Bisson<br>Tobias Heilig<br>Tomasz Konojacki<br>Tomohiro Kusumi<br>Ulrich Sp\xc3\xb6rlein</div><div>User<br>Venkatesh Srinivas<br>Victor Balada Diaz<br>Vishesh Yadav<br>Walter Sheets<br>YONETANI Tomokazu<br>Yellow Rabbit<br>Yonghong Yan<br>Zach Crownover<br>b86<br>dumbbell<br>glebius<br>hrs<br>jkim<br>minux<br>rnoland<br>sinetek<br>zrj<br>\xc3\x81kos Kov\xc3\xa1cs<br></div><div><br></div></div><div>-Matt</div></div>
</blockquote></div></div>