<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, Apr 27, 2019 at 10:39 AM Isaac (.ike) Levy <<a href="mailto:ike@blackskyresearch.net">ike@blackskyresearch.net</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">> 14. I would contribute to FreeBSD more if the FreeBSD Project:                                              <br>
> <br>
> - Transitioned to using git   <br>
> - Adopted a GitHub pull request style workflow        <br>
> - Had pre-commit test automation integrated into pull requests        <br>
> - Provided hosted infrastructure to facilitate development (e.g. cloud-hosted development and test instances) <br>
> - Transitioned from DocBook to a modern markup format and workflow (e.g. asciidoc and/or markdown)<br>
<br>
Well, this question is a big deal.<br>
I suggest NYC*BUG folks take the survey just to weigh in on these obvious bits:<br>
<br>
--<br>
move from svn to git?<br>
<br>
I say hallelujah,<br>
  - but what about licence?<br>
  - amazing to get the project into mainstream source control tooling<br>
  - I am a fan of the git(1) tooling, to me, it’s a best of breed UNIX tool<br>
<br>
I know people here have strong opinions...<br></blockquote><div><br></div><div>Yes. Yes they do.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Missing question:<br>
- If man pages were more important as part of code acceptance and code review.<br>
  (FreeBSD man pages have been slipping/struggling in this latest era)<br>
<br>
Focusing on DocBook is a tooling question, documentation is about *writing* and coordinating people.<br>
The entire coordination of the FreeBSD handbook needs attention, love, and simply someone driving.<br></blockquote><div><br></div><div>Good point and I don't disagree. Lord knows I've not been the best at documenting the stuff I've added...</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
> 16. How do you install software (excluding configuration management, which may invoke one of the following)?<br>
> <br>
>  FreeBSD Project-managed packages (e.g. pkg install bar)<br>
>  Custom pkg repo not FreeBSD project managed (e.g. local poudriere package cache or TrueOS)<br>
>  Ports (e.g. cd /usr/ports/foo/bar && make install)<br>
>  By hand (e.g. fetch foo.tar.xz && sha256 -c "..." foo.tar.xz && cd foo/ && make && sudo make install)<br>
>  Other (please specify)<br>
<br>
To a systems person like myself, this question lacks critical *context*.<br>
<br>
Anybody know what it refers to?<br></blockquote><div><br></div><div>Would the question make more sense if it read</div><div><br></div><div>When you add third-party software to a FreeBSD system, how do you do it?</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
> 23. When I install FreeBSD onto hardware (not a VM), the hardware running FreeBSD has an expected life of _________.<br>
> <br>
> <br>
<br>
To a systems person like myself, this question lacks critical *context*.<br>
<br>
Anybody know what it refers to?<br></blockquote><div><br></div><div>Netflix installs its hardware to last for 3-6 years. However, we completely replace the OS every 6 weeks (except around Christmas) with the occasional release skipped for some class of systems in its fleet. If I were filling out this survey for Netflix, I'd answer 6-12 weeks.</div><div><br></div><div>Warner Losh's home network infrastructure gets deployed with a life of ~10 years. However, it's updated every year + relevant security fixes. Here I'd answer 'about a year'.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
> 36. When I install FreeBSD into a VM, the VM has an average life of _______.                                              <br>
> <br>
>  1 week<br>
>  1 month<br>
>  1 quarter<br>
>  2 quarters<br>
>  1 year<br>
>  2 years<br>
>  3 years<br>
>  4 years<br>
>  5 years<br>
>  more than 5 years<br>
<br>
To a systems person like myself, this question lacks critical *context*.<br>
<br>
Anybody know what it refers to?<br></blockquote><div><br></div><div>Maybe this question would be better asked as "What is the average lifetime your FreeBSD VMs? How long will that instance live?"</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Questions 23 and 36 above:<br>
NOTE: discussions about fungible systems in enterprise environments is as old as the hills.<br>
Some application models work well because hosts are disposable units, (why upgrade a machine when one can replace).<br>
Other applications, typically stateful stuff, (databases, file servers, a million things which fall in between), are better suited to upgrade-in-place models.  Desktops and multi-use machines, absolutely thrive on upgrade-in-place models.<br>
<br>
But are these last two questions about FreeBSD project serving binary updates or something?<br>
Dying to know more context here.<br></blockquote><div><br></div><div>That I can't help with... This question was added after I had to stop helping to develop the survey...</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
> 24. At home I am currently using FreeBSD:<br>
> 13.X (-CURRENT)<br>
> 12.X (12-STABLE)<br>
> 11.X (11-STABLE)<br>
> 10.X<br>
> 9.X<br>
> 8.X<br>
> 7.X<br>
<br>
> 25. At work I am currently using FreeBSD:<br>
> 13.X (-CURRENT)<br>
> 12.X (12-STABLE)<br>
> 11.X (11-STABLE)<br>
> 10.X<br>
> 9.X<br>
> 8.X<br>
> 7.X<br>
<br>
One extremely frustrating omission here:<br>
What about RELEASE branches?<br></blockquote><div><br></div><div>Good point. This question just tests what major branch you are running, not the details on that branch.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
As a FreeBSD *USER*, as well as Sysadmin and regular contributor, it’s always been frustrating for people to always consider that users are using “CURRENT” or “STABLE”, (we play Country *and* Western).<br>
<br>
One great example: At home, my laptop is running 12-RELEASE.  Why?  Because I *do not do particular types of development with it*.  I come home from work, and I want to *use* the laptop to just do stuff, and I want that to happen reliably.<br>
At home, I do also have machines running STABLE and CURRENT, for various projects and reasons.<br>
I have other reasons where RELEASE has been part of my job/work-enviornments for decades now.<br>
<br>
I guess what I’m saying is these 2 questions (24, 25), touch a nerve where FreeBSD core/developers tend to ignore that end user cases exist, and a culture of dismissiveness for using RELEASE.<br>
<br>
This is my opinion here- I think the FreeBSD project would be better served to respect that users, (even advanced/contributing users), do care about running RELEASE.<br></blockquote><div><br></div><div>Good point...</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
> 26. I would be willing to participate in an anonymous, aggregated hardware survey to share device information with the project so it could aggregate and submit statistics to device vendors for the following classes of systems:<br>
> <br>
> Appliances<br>
> Desktops / Laptops<br>
> Embedded<br>
> Servers<br>
<br>
I think the FreeBSD foundation would be well served by talking to NYC*BUG folks about the decade+ of running DMESGD:<br>
<br>
  <a href="https://dmesgd.nycbug.org/index.cgi" rel="noreferrer" target="_blank">https://dmesgd.nycbug.org/index.cgi</a><br>
<br>
>From user security/privacy concerns, to the type and breadth of data collected- there’s some good lessons learned by DMESGD.<br></blockquote><div><br></div><div>Yes. We're well aware of dmesgd. It provides one type of data, and data that's has a lot of its sensitive data shorn off.</div><div><br></div><div>However, I work for Netflix and I can give you numbers like "more than 10k servers" or similar. Nothing with any kind of resolution to it that can be used to get an accurate notion of our network capacity, etc. Others have similar views. We're happy to post the dmesg for each type of system we have (we're up to about 30), but even there we have some sensitivity by some vendors that don't necessarily want their relationship with us known.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
> 27. I use the following sources for help:<br>
> <br>
> Source code<br>
> Manual pages<br>
> FreeBSD Handbook<br>
> FreeBSD Articles<br>
> FreeBSD Committers Guide<br>
> FreeBSD Developer Handbook<br>
> FreeBSD Forums<br>
> The FreeBSD Wiki<br>
> Mailing List Posts<br>
> Stack Overflow<br>
> Other (please specify)<br>
<br>
This question (and others around it) don’t address help deficiencies:<br>
<br>
One big problem right now, (I alluded to before), is there are *so many* places people turn for help.<br>
<br>
I believe the number of places is currently fragmented in bad ways, and would benefit by the community rallying around the FreeBSD handbook.  As a quasi-outsider, I’ve found the following barriers to this in recent years:<br>
<br>
- hard to “find a way in” to provide small/incremental help to the handbook<br>
  - technical complexity blockers, (what format? What repo? What workflow?)<br>
  - people/lead blockers, (who’s around to corral people into helping with documentation?)<br>
  - quality/review blockers (who’s reviewing community-generated documentation for consistency/quality?)<br>
<br>
Manual pages:<br>
  - need to find ways to let project outsiders submit changes/additions to manual pages<br>
  - need to find ways to make manual pages a more important part of developer culture<br>
    (from userland to kernel, particularly sysctl coverage)<br></blockquote><div><br></div><div>All good points (as are many others I've deleted for space), and none are really in dispute. Would you like to have a more in-depth conversation around these issues and how we can restructure the doc group to  improve these areas?</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">The ZFS codebase changes (Linux vs OpenZFS etc…) are a huge deal lately.<br>
I know some larger shop that’s silently dropping FreeBSD if the ZFS rewrite to Linux implementation proceeds.<br>
<br>
Just saying, future of ZFS on FreeBSD, this really needs some more public understanding- and discussion on it’s own.<br></blockquote><div><br></div><div>OpenZFS is moving towards rebasing its upstream from Illumos to ZoL and ZoL is expanding its coverage to include non-Linux OSes and has made explicit commitments to the OpenZFS leadership about keeping the source of truth useful for non-linux users. This has been public, but maybe not well publicized. FreeBSD is looking to rebase things to this new upstream.</div><div><br></div><div>I'm curious why that larger shop would drop things.</div><div><br></div><div>Warner</div></div></div>