[talk] Fwd: [FreeBSD-Announce] 2019 FreeBSD Community Survey
Isaac (.ike) Levy
ike at blackskyresearch.net
Sat Apr 27 16:03:22 EDT 2019
> On Apr 27, 2019, at 1:20 PM, Warner Losh <imp at bsdimp.com> wrote:
>
>
>
> 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.
From the User community perspective, (I do not speak for all of nycbug here but I will ramble a bit from years of "consensus at the bar” on git for FreeBSD):
The SVN transition was costly.
- the svn transition was extremely painful for systems folk, because:
- lack of cvsup replacement for almost a year made building world very frustrating
- chicken/egg old svn in ports was bonkers, (GPL license, before svnlite(1))
Systems integrators, jail(8) users, basically anyone who compiled/customized kernel/world builds, suddenly had chicken/egg issues which did not affect developers in the same way at all…
- FreeBSD developers didn’t have time for empathy on this one, struggling with their own source control nightmares and battles us users probably never saw (nor should have).
Years later, svnlite(1) became part of the base system, (critical), and life has gone on for everyone.
This cvs->svn transition took some years. And in those years, professionally, I and other NYC*BUG colleagues all saw:
- the world forgot all about svn, git(1) just took over
- GitHub came to own the public open source zeitgeist (making more git users even)
- git(1) usage has spread more broadly than any other source control system before it
- the git “I have all branches already” paradigm *does not jive* with the svn “I have to have internet to change branches”, and this confuses the heck out of young/new people and FreeBSD project outsiders trying to get a fix/patch in.
—-
An ike-dream:
Anyhow, if the FreeBSD project or foundation can figure out how to deal with the git licensing, a move to git would probably do wonderful things for the project- and get a lot of institutional/historical knowledge out of the way for new developers.
Additionally, things like GitLab (or frankly GitHub public mirroring) can be layered on top of servers using straight git- to promote more open/fast/loose “downstream” contributions, allowing the FreeBSD project to simply secure and maintain a minimum of distributed boxes with the trusted source code.
--
In the meantime, let me give a user perspective on the current GitHub mirror of the FreeBSD project (from svn sources):
- It’s damn handy to have around, (quick reads, quicker branch flipping to track history of a problem)
- I’ve never (and would never) build actual running boxes/anything from it, (it’s “unofficial”, why would I waste time trusting it?)
- it’s not signed AFAIK (git has decent commit signing mechanisms which can incorporate gpg/pgp, but that’s really a matter of upstream/originators carrying this practice)
—-
Anyhow, I’ve rambled lots on this issue, and will shut up now.
Would love to hear others thoughts on this topic!
> 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?
Sure that clarifies, but it’s not what I’m confused about:
I am wondering *why* the FreeBSD foundation or project cares?
It seems this would indicate a need to prioritize one way or another in some actionable way, (e.g. more work to pkg and supporting [paying for] pkg repos and binary packages? (A lot of hardware and time necessary, afaik…)
Or, if everyone just builds software from source, or compiles ports, why should the FreeBSD Foundation keep paying to run the binary package infrastructure?
This is the kind of thing I’m wondering- not a clarification of the question, but *why* does the FreeBSD foundation care, in what context does the question exist?
(Also note on language and inference, “by hand” is vocabulary with baggage, I run build systems on FreeBSD boxes which automate complex software builds for which ports are not going to get me what I want so… compiling software from source is certainly not some kind of bespoke practice, as the language “by hand” could infer.)
>
> > 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’.
Yeah- the answers here are indeed totally dependent on use/context, my answers are actually quite varied for different layers of infrastructure at work alone. Some boxes fungible, some boxes long-lived.
What I’m more interested in, (for context and a good answer), why does the Foundation/core care? What decisions are being discussed which this survey question influences?
>
> > 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?”
Just like above, this question itself makes sense,
>
> 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…
I am starting to tear up, my curiosity as to what work this question informs for the Foundation/project is now boiling my brain :)
>
> > 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.
Funny: when I think of “major branch” I always think of “RELEASE”. Most FreeBSD developers always think of major branch as “CURRENT” or “STABLE”. :)
If it’s just the major dot release that these questions inform, the question may be better asked by just “12.x” “13.x” etc…
Separate question about weather people mostly run “RELEASE”, “STABLE”, or “CURRENT” might be relevant (and surprising to everyone).
>
> 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),
Oh please do, that’d be fascinating!
> but even there we have some sensitivity by some vendors that don't necessarily want their relationship with us known.
Interesting, and quite understandable.
One thing that deserves being stated: NYC*BUG folks are *well aware* of the old 'ubuntu-report’ issues (2012 or 2014?)- it’d be a real bad thing for FreeBSD if users consent/trust gets botched up by FreeBSD folks making similar mistakes collecting data from the OS without clear consent.
I mean, in the *BSD world this goes without saying- but who ever thought that Ubuntu would have done their snoopy crap when they did...
>
> > 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?
I’d be totally down with that.
Better idea even: make it a moderated NYC*BUG panel discussion, as a NYC*BUG meeting.
Bet we could get Ingo Schwartz to video in from .de, (he has a great history with NYC*BUG on this topic, and *plenty* of excellent culture/tools/execution experience from his mandoc work and presentations here…)
Thoughts? June or July?
>
> 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.
Most definitely not well publicized! :)
> FreeBSD is looking to rebase things to this new upstream.
>
> I'm curious why that larger shop would drop things.
Long story short: The shop I mentioned thrives on UNIX mentality, and has big issues with Linux slop. Filesystems are something that people get itchy about with respect to slop. With that, they at least prefer the Illumos history- in mentality and organization, along with the codebase, and now (?) new license changes.
Now, I can’t really blame them on any of these points, (it’s just the kind of FUD I can relate to :)
Yet, I’d be very interested to see more FreeBSD publicity on how this change actually impacts ZFS users?
ZFS has finally become “boring-ware” in FreeBSD- it’s so stable and clear that it’s just boring- and boring is perhaps the most desirable property for any filesystem.
This ZoL change absolutely deserves articulate, detailed, publicity and understanding, less it hurt the FreeBSD project (in ways that changing the source code control tooling never could dream of!). Kirk’s words on what it means to change/update filesystems totally apply here. :)
>
> Warner
Thanks Warner!
Best,
.ike
More information about the talk
mailing list