On Tue, Jan 13, 2015 at 5:41 PM, Joshua Smith <juice...@gmail.com> wrote: >> On Jan 13, 2015, at 6:14 PM, Royce Williams <ro...@tycho.org> wrote: >> >> At Craig Rodrigues' request, I'm starting a new thread here branched >> from a freebsd-ports@ thread. For those who want more context, the >> original thread starts here: >> >> https://lists.freebsd.org/pipermail/freebsd-ports/2015-January/097462.html >> >> It was initially about BIND REPLACE_BASE, but branched off into >> general sysadmin concerns that Craig wanted to respond to. >> >> Royce >> >> ---------- Forwarded message ---------- >> From: Royce Williams <ro...@tycho.org> >> Date: Mon, Jan 12, 2015 at 7:10 AM >> Subject: Re: BIND REPLACE_BASE option >> To: ports <freebsd-po...@freebsd.org> >> Cc: Deb Goodkin <d...@freebsdfoundation.org> >> >> On Mon, Jan 12, 2015 at 4:08 AM, Kurt Jaeger <li...@opsec.eu> wrote: >> >>>> No disputing that, just thinking, is FreeBSD being driven by user need, >>>> financial contributer need, developer need, security need, making things >>>> 'better' or just by people wanting to make their mark in a warped sense >>>> of "it'll all get better"...? >>> >>> Probably by developer *capacity* (not need) and fire-fighting, >>> like most IT stuff 8-( >> >> But like most IT stuff, resources are being asymmetrically applied to >> the root causes of the fires. >> >> Read the list of projects from last quarter:
I did not intend to pick on each of these projects, though you've responded as though I had. Rather, I am trying to encourage the Foundation to look at them in the aggregate, and think about other entire families of project ideas that could be encouraged. >> - Address Space Layout Randomization (ASLR) > > I would hardly consider this esoteric. I used the phrase "relatively esoteric" on purpose. "Esoteric" means "intended for or likely to be understood by only a small number of people with a specialized knowledge or interest," and "relatively" here means relative to other broad areas of high-level FreeBSD improvement. I stand by the assessment. I believe that small-shop admins would value stable port management and other basics like my list below before most of the projects on the list. >> - amd64 Xen Paravirtualization >> - bhyve > > The ability for FreeBSD to host VMs is definitely something that I find very > interesting and useful. I am a sysadmin. My intent was not to say that these things aren't useful. It was that there are some other basic things that could use some attention as well. >> - Chelsio iSCSI Offload Support >> - Debian GNU/kFreeBSD >> - FreeBSD Preseed Installation (PXE) > > This also fits right in the making a sysadmin a life easier wheel house. When sysadmins are afraid to upgrade ports because of a hidden cascade of dependencies that will result in an unusable system, PXE is a great way to recover. What would be even better is a way to reduce the chances of that cascade in the first place. >> - Jenkins Continuous Integration for FreeBSD >> - New Automounter > > An auto mounter that behaves more like what is in other unixes also improves > my life as a sysadmin. > >> - QEMU bsd-user-Enabled Ports Building >> - VMWare VAAI and Microsoft ODX Acceleration in CTL > > Not really sysadmin focused but definitely not esoteric. I was going to try to respond to this in some way, but I'd like to just restate my broader point that the project has opportunities in other kinds of areas that would make it so that more core resources become available to work on needed improvements like this one. >> - ZFSguru >> - Intel GPU Driver Update >> - SDIO Driver >> - UEFI Boot > > Like it or not UEFI is the future supporting it well is not optional. I agree. >> - Updated vt(4) System Console >> - Updating OpenCrypto >> - FreeBSD on Newer ARM Boards > >> - FreeBSD/arm64 >> - LLDB Debugger Port >> - LLVM Address Sanitizer (Asan) >> - SSE Variants of libc Routines for amd64 >> - FreeBSD Python Ports >> - GNOME/FreeBSD >> - KDE on FreeBSD >> - The Graphics Stack on FreeBSD >> - Xfce >> >> The Foundation section also lists these items not overlapping with the above: >> >> - FreeBSD Journal >> - PostgreSQL performance improvements >> - Ongoing release process >> - Development snapshots > > A better release process will likely benefit me as a sysadmin. Agreed. >> - VM images for releases > > Being able to boot the base system on the hyper visor of my choice with out > having to muddle through the installer is a huge time saver and a bandit of > sysadmin a everywhere. > >> - Secure Boot planning >> - Infrastructure hardware >> - Java licensing >> - Summits and summit sponsorship >> - Travel grants, tutorials, and talks >> - New Design and Implementation book >> - Recruitment flyers >> >> Are there long-term improvement projects that aren't being listed? If >> so, they should be. > > These are just projects sponsored by the foundation. I'm sure there are many > other developments occurring throughout the project that are not listed here > because they are not sponsored by the foundation. The purpose of my message was to ask the Foundation to consider shifting the balance of sponsorship a little to include a different class of projects, so I worked from the latest announced list of Foundation projects. >> At face value, the main project list is heavily weighted towards >> relatively esoteric OS features. > > See my other comments above. Frankly this is a bullshit statement. I worked very hard to make this message constructive, and you are making it difficult to remain so. What I'm saying is that just like an investment portfolio, the FreeBSD project portfolio needs to be examined for rebalancing once in a while. >> The Foundation list is heavily >> weighted towards advocacy and communication (as it should be). >> >> What is missing are high-level projects to help sysadmins maintain and >> use FreeBSD on an ongoing basis. >> >> Here are some projects that would help to close the sysadmin gap: >> >> - Automatic error reporting and analysis > > A crash reporting mechanism already exists. Is there a way to publicly view aggregated results, or see a list of bugs that were fixed because the mechanism is working? If so, that would be useful to know. >> - OS and port debugging tools for sysadmins >> - Independent project-wide usability analysis > > What does this mean? If you run into a usability or any other sort of > problem. Submit a PR. It may be hard to imagine what it might be like to be, say, a Solaris admin all your life, with no other Unix-like exposure ... when one day, someone comes to you and tells you that you have to upgrade the FreeBSD Apache server between now and when you have to go home and feed your kids. But I encourage you to think about it. There's no way to file a PR for this. It's the kind of thing that requires a champion within the project to build bridges, tear down walls, challenge assumptions, and tackle the problem. >> - Ports dependency isolation and reduction framework > > Doesn't seem like a sysadmin type thing to me. This would help sysadmins by supporting improving end-result reliability of the ports system generally, which I see as a cornerstone of why FreeBSD is hard today. >> - Ports system reliability parity with Linuxes > > Can you provide more details and expand upon this? Please bear in mind that what I'm about to say pains me greatly, as someone who has been a passionate advocate for FreeBSD at companies I work at for the past fourteen years. If a small or medium-sized shop wanted to set up a stable, basic web server, and feel confident that they can move smoothly through OS and server/application upgrades, I would recommend an Ubuntu-derived "LTS" (Long Term Support) release before I would recommend FreeBSD. When I try to explain to other OS' admins that we have to release a quarterly stable snapshot set of ports because regular rolling port updates are too fragile, or that we have to manually remember to check a text file every time we want to upgrade a port, and regularly have to manually deinstall the old port, they look at me like I'm insane. They take it for granted that basic, everyday port dependency management is a largely solved problem. That's what I meant by parity. >> - Searchable, taggable project FAQ > > Any number of the projects above are far more beneficial to sysadmin a > everywhere than this. Unless you're a sysadmin strapped for time. Or new to the project. Or split between multiple platforms. Or also assigned non-sysadmin duties. Or picked the wrong day to be too tired from the outage the night before and accidentally not read UPDATING. The FreeBSD forums and lists have people asking common questions. They are often answered by the same people -- people who are skilled, eager to help, and in danger of burning out by having to answer the same questions all the time. A FAQ with some self-organizing features -- perhaps even Stack Overflow-style, but with more curation -- could help with that. >> - Searchable hardware support matrix integrated with bug tracker > > +1 for this. Well, at least something was a good idea. :-) >> - Wiki curation and platform improvements >> >> These projects decentralize and improve support for sysadmins and new >> adopters. As a business case for the Foundation, these projects >> should also deeply free up developer resources to focus on other major >> projects. >> >> In the past, when I have pointed out this "sysadmin gap", I receive >> one of two answers: >> >> 1. Sounds great. Let us know when you have it finished. > > Perhaps just getting started with something would entice support. See answer #1 below. >> 2. We're too busy to do any of those things. >> >> ... to which I answer: >> >> 1. These projects require technical skill and political capital within >> the project. They are ideally suited for well-established independent >> FreeBSD consultants with large blocks of time sponsored by the FreeBSD >> Foundation. I can help (especially with the wiki work), but cannot >> tackle these deeper problems in the way that others can. >> >> 2. The reason you're busy is that you don't have these things. >> >> I applaud recent work on Jenkins and cluster infrastructure. I also >> appreciate Colin Percival's automated error reporting work, because >> it directly attacks the sysadmin gap. And I know that getting >> releases out the door is time-consuming and keeps the lights on. >> >> But the overall project list needed to be rebalanced towards system >> administration. I request that the Foundation consider this when >> calling for proposals for the next round of funded projects. _______________________________________________ freebsd-advocacy@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-advocacy To unsubscribe, send any mail to "freebsd-advocacy-unsubscr...@freebsd.org"
