[talk] Fwd: [FreeBSD-Announce] 2019 FreeBSD Community Survey

[Warner Losh]

On Sat, Apr 27, 2019 at 10:39 AM Isaac (.ike) Levy <ike at blackskyresearch.net>
wrote:

> > 14. I would contribute to FreeBSD more if the FreeBSD Project:
>
> >
> > - Transitioned to using git
> > - Adopted a GitHub pull request style workflow
> > - Had pre-commit test automation integrated into pull requests
> > - Provided hosted infrastructure to facilitate development (e.g.
> cloud-hosted development and test instances)
> > - Transitioned from DocBook to a modern markup format and workflow (e.g.
> asciidoc and/or markdown)
>
> Well, this question is a big deal.
> I suggest NYC*BUG folks take the survey just to weigh in on these obvious
> bits:
>
> --
> move from svn to git?
>
> I say hallelujah,
>   - but what about licence?
>   - amazing to get the project into mainstream source control tooling
>   - I am a fan of the git(1) tooling, to me, it’s a best of breed UNIX tool
>
> I know people here have strong opinions...
>

Yes. Yes they do.

Missing question:
> - If man pages were more important as part of code acceptance and code
> review.
>   (FreeBSD man pages have been slipping/struggling in this latest era)
>
> Focusing on DocBook is a tooling question, documentation is about
> *writing* and coordinating people.
> The entire coordination of the FreeBSD handbook needs attention, love, and
> simply someone driving.
>

Good point and I don't disagree. Lord knows I've not been the best at
documenting the stuff I've added...

> 16. How do you install software (excluding configuration management,
> which may invoke one of the following)?
> >
> >  FreeBSD Project-managed packages (e.g. pkg install bar)
> >  Custom pkg repo not FreeBSD project managed (e.g. local poudriere
> package cache or TrueOS)
> >  Ports (e.g. cd /usr/ports/foo/bar && make install)
> >  By hand (e.g. fetch foo.tar.xz && sha256 -c "..." foo.tar.xz && cd foo/
> && make && sudo make install)
> >  Other (please specify)
>
> To a systems person like myself, this question lacks critical *context*.
>
> Anybody know what it refers to?
>

Would the question make more sense if it read

When you add third-party software to a FreeBSD system, how do you do it?


> > 23. When I install FreeBSD onto hardware (not a VM), the hardware
> running FreeBSD has an expected life of _________.
> >
> >
>
> To a systems person like myself, this question lacks critical *context*.
>
> Anybody know what it refers to?
>

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.

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'.

> 36. When I install FreeBSD into a VM, the VM has an average life of
> _______.
> >
> >  1 week
> >  1 month
> >  1 quarter
> >  2 quarters
> >  1 year
> >  2 years
> >  3 years
> >  4 years
> >  5 years
> >  more than 5 years
>
> To a systems person like myself, this question lacks critical *context*.
>
> Anybody know what it refers to?
>

Maybe this question would be better asked as "What is the average lifetime
your FreeBSD VMs? How long will that instance live?"


> Questions 23 and 36 above:
> NOTE: discussions about fungible systems in enterprise environments is as
> old as the hills.
> Some application models work well because hosts are disposable units, (why
> upgrade a machine when one can replace).
> 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.
>
> But are these last two questions about FreeBSD project serving binary
> updates or something?
> Dying to know more context here.
>

That I can't help with... This question was added after I had to stop
helping to develop the survey...


> > 24. At home I am currently using FreeBSD:
> > 13.X (-CURRENT)
> > 12.X (12-STABLE)
> > 11.X (11-STABLE)
> > 10.X
> > 9.X
> > 8.X
> > 7.X
>
> > 25. At work I am currently using FreeBSD:
> > 13.X (-CURRENT)
> > 12.X (12-STABLE)
> > 11.X (11-STABLE)
> > 10.X
> > 9.X
> > 8.X
> > 7.X
>
> One extremely frustrating omission here:
> What about RELEASE branches?
>

Good point. This question just tests what major branch you are running, not
the details on that branch.


> 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).
>
> 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.
> At home, I do also have machines running STABLE and CURRENT, for various
> projects and reasons.
> I have other reasons where RELEASE has been part of my
> job/work-enviornments for decades now.
>
> 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.
>
> 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.
>

Good point...


> > 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:
> >
> > Appliances
> > Desktops / Laptops
> > Embedded
> > Servers
>
> I think the FreeBSD foundation would be well served by talking to NYC*BUG
> folks about the decade+ of running DMESGD:
>
>   https://dmesgd.nycbug.org/index.cgi
>
> From user security/privacy concerns, to the type and breadth of data
> collected- there’s some good lessons learned by DMESGD.
>

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.

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.


> > 27. I use the following sources for help:
> >
> > Source code
> > Manual pages
> > FreeBSD Handbook
> > FreeBSD Articles
> > FreeBSD Committers Guide
> > FreeBSD Developer Handbook
> > FreeBSD Forums
> > The FreeBSD Wiki
> > Mailing List Posts
> > Stack Overflow
> > Other (please specify)
>
> This question (and others around it) don’t address help deficiencies:
>
> One big problem right now, (I alluded to before), is there are *so many*
> places people turn for help.
>
> 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:
>
> - hard to “find a way in” to provide small/incremental help to the handbook
>   - technical complexity blockers, (what format? What repo? What workflow?)
>   - people/lead blockers, (who’s around to corral people into helping with
> documentation?)
>   - quality/review blockers (who’s reviewing community-generated
> documentation for consistency/quality?)
>
> Manual pages:
>   - need to find ways to let project outsiders submit changes/additions to
> manual pages
>   - need to find ways to make manual pages a more important part of
> developer culture
>     (from userland to kernel, particularly sysctl coverage)
>

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?


> The ZFS codebase changes (Linux vs OpenZFS etc…) are a huge deal lately.
> I know some larger shop that’s silently dropping FreeBSD if the ZFS
> rewrite to Linux implementation proceeds.
>
> Just saying, future of ZFS on FreeBSD, this really needs some more public
> understanding- and discussion on it’s own.
>

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.

I'm curious why that larger shop would drop things.

Warner
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.nycbug.org:8080/pipermail/talk/attachments/20190427/40c5d065/attachment.html>