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

Isaac (.ike) Levy ike at blackskyresearch.net
Sat Apr 27 14:45:45 EDT 2019


> On Apr 27, 2019, at 1:20 PM, Raul Cuza <raulcuza at gmail.com> wrote:
> 
> Thank you for highlighting this survey. Day dreaming about having a
> choice other than Linux at work made me happy.

Doesn’t it make us all happy :)

Thanks for your notes Raul, responses inline:

> 
>>> 7. The FreeBSD Project produces software. I view FreeBSD's software as…
>>> - a building block for commercial appliances (customizable kernel plus packages)
>>> - a competitive advantage in my workplace
>>> - a complete and self-contained operating system
>>> - a consumable piece of released or shrink-wrapped software (a release)
>>> - a suite of userland packages (e.g. ports)
>>> - a toolkit that builds an end-to-end, customized distribution (e.g. make world + poudriere)
>>> - an embeddable kernel (e.g. PS4)
>>> - an opinionated "operating system as a service" that I consume
>> 
>> OK- I’ve heard this “operating system as a service” vocabulary before.  What the heck does it mean?  I’m honestly clueless here.
> 
> For me OS as a service basically means you don't think about the OS
> and don't have to tweak ANY configs on it. You get your app or write
> your app and it just runs. Docker claims to be this. Serverless is
> trying to create this.

Ah- thanks for clarifying this, I guess I know this meme well then, (and have never seen this model live up to the dream in any shop).

I’d be curious to see what the actual implementation questions are which got this question into this survey?

> 
>> 
>>> - the upstream for my distribution of choice (e.g. FreeNAS, pfSense, GhostBSD, HardenedBSD, OPNSense, etc)
>> 
>> 
>> 
>>> 8. Rate the following statements:
>>> - The FreeBSD project does a good job of addressing security concerns
>>> - Effective security should be provided "out of the box," even at the expense of functionality or performance
>>> - In order to address my security needs I perform research and configure my systems as needed for the individual application
>>> - I believe FreeBSD sets appropriate defaults with respect to various security mitigations and options
>>> - I know how to enable additional mitigations that are not enabled by default
>>> - Performance is a security consideration for server workloads
>>> - I believe FreeBSD sets appropriate defaults with respect to performance
>>> - For most workloads, I believe FreeBSD should set reasonable defaults that don't require post-installation adjustment
>> 
>> Critique of these multiple-choice questions: I believe they are a bit binary/dydactic, particularly the “out of the box config” bits.
>> 
>> I do wonder what specific topics this question is getting at?
>> 
>> In practice, I believe some security concerns should *absolutely* be handled out of the box, and are the OS responsibility.  Others, are my responsibility- it’s nuanced.  For example: various hardware/kernel security considerations, I totally expect to be secure, right out of the box.  TCP/net sysctls, I expect to be “generically performant” out of the box.  (These have been great for a decade or more.)
>> Yet, enabling sendmail or ntpd, (and vulnerabilities they may expose my box to), those are my choice to *use*, and my responsibility to keep up to date in a given context- and I don’t need FreeBSD setting reasonable defaults here.  Etc… etc… we could go on forever pointing at what should be secure “out of the box”.
>> 
>> Maybe I’m reading this wrong, but I think the question completely misses a MUCH bigger topic: Security and performance tuning is both better than it’s ever been, but less documented than it’s ever been- in both server/workstation contexts.
>> It’s disheartening how many times I’ve come to learn about a sysctl that’s important to my applied use by stumbling through a wiki/forum/blog post from some random person, and come to find it’s not documented at all in man pages, nor in handbook, maybe the freebsd wiki has 4 year old notes about it, and not even the source code which implements some sysctl is commented.
>> 
>> Understanding the composition of a system is critical to both security and performance, and is critical weather or not the system is secure/performant “out of the box”.
> 
> I think the "out of the box" statement is basically the Mac OS X
> model. Someone writes an exploit app that is effective on OS X? Well
> Apple updates adds its signature to its OS and now that exploit can't
> run. People don't even know these signatures are getting updated.
> Apple then patches the OS to actually fix the problem and the exploit
> no longer works for real. Basically, you use the OS and not thing
> about security because a team more responsible than you is on it.

Hrmph, on signed binaries by trusted people:  At work, without a paid model (legally/contractually liable), not sure this kind of trust is ever something my employers can care about.
On a personal level, Apple’s policing of binaries is frustrating at best, and commonly leads to absurd workarounds and annoyances, and in the end- trust problems which are totally separate from how I trust or what I expect from my OS.

I can see a 3rd party company providing this sort of signature based runtime policing as some kind of FreeBSD support model.
(I believe it used to be called AntiVirus?).  I can also see open source projects focused on this sort of signature based execution emerging, like the Emerging Threats "ETOpen Ruleset” and the like.

Yet, I can’t see how the OS itself can manage getting into this business?


> "out of the box" also means you don't want to think about sysctl
> because everything just works.

Hrmph.  I think this “out of the box” stuff has real limits, and FreeBSD has done great with this stuff for years- largely by *turning everything off* by default.

I’m not arguing you here Raul- mostly saying I think this “out of the box” business needs more clarification in the context of these questions.

Even basic tuning, (I mentioned sysctl tweaking for network performance before): what even is a common case?  An extreme and common example for me, I run one pair of internet-facing boxes which I pass ZFS incremental snapshots back/forth constantly over a crossover cable.

- the internet network: tuned for that purpose, (very little to change from out of the box, some security/inet sysctls flipped for sanity and to reduce annoyances)

- the ZFS crossover network: MTU set to jumbo frames, TCP buffers tuned down, basically tuned to let the machine on each end comfortably saturate the pipe with ZS snapshots all day over ssh.

From here though, what network stack is “out of the box” the same?  A laptop is pretty different than a server, a cloud/VM may be extremely different in network usage/behavior, etc...



>>> 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...
>> 
>> 
>> --
>> DocBook to modern markup format?
>> 
>> 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.
> 
> I did some documentation work at BSDCAN and it was a pain to get it
> set up.

Yer’ telling me brother.
In a world where people are used to Tweeting, and GitHub PR’s, and Gists, etc… the barrier to getting even a spelling error upstream is a painful echo chamber.

> But maybe the entry should not be so easy because it's better
> to have a handbook that feels like it was written by one good author.

Your intent I agree with- but what about following classic publishing models: many contributors, few reviewers/proofreaders/editors who carry a consistent voice through?

>>> 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?
>> 
>> 
>>> 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?
>> 
>> 
>>> 
>>> 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?
>> 
>> 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.
>> 
>> 
>>> 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?
>> 
>> 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.
>> 
>> 
>>> 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.
>> 
>> 
>>> 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)
>> 
>>> 28. I read/watch the following to keep current with FreeBSD:
>>> 
>>> Blogs posts
>>> Calomel.org
>>> FreeBSD Journal
>>> FreeBSD Foundation newsletter
>>> FreeBSD Foundation blog posts
>>> Twitter
>>> YouTube
>>> Other (please specify)
>> 
>> I’d have said “I read/watch the following 3rd party places..."
>> 
>> Otherwise, I’d say critical omissions from this list are:
>> - Release Notes
>> - Release Announcement
>> 
>> 
>>> 34. The following attributes of FreeBSD in server workloads are important to me:
>>> 
>>>  (Not important, Neutral, Very Important, N/A)
>>> Access to Security Patches
>>> Cassandra Support
>> 
>> Can somebody point out what this is about?  Cassandra?  (e.g. is this something like the various PostgreSQL/sysV shared memory issues were in old days?)
>> 
>>> Namespace/cgroup support
>>> Immutable Server Images
>>> Docker Support
>>> Kubernetes Support
>>> Virtualization Support
>>> 
>> 
>> Would have loved a more organized/separate question set about contemporary virtualization stuff, e.g.:
>> - running docker containers (where namespace/cgroup is important)
>> - kubernetes (choking back vomit, but yeah important to address for work)
>> - immutable server images (this sort of facility exists in FreeBSD, what here are we talking about?  A docker implement?)
>> - Differentiation of Hypervisor virtualization, (bhyve, et al), vs process try (jail, docker, k8s, et al)
>> 
>>> Configuration Management Support (e.g. ansible, chef, salt, packer, puppet)
>> 
>> Hrm… Can of worms here, not even sure where this is coming from- (client, server, libraries, code in FreeBSD to support vs. engaging these projects so their tooling supports FreeBSD properly, etc…)
>> 
>> Can anyone on nycbug list point me to where these conversations are happening, if public list etc?
>> 
>>> Fault Management
>>> Filesystem Performance
>>> In-Place Upgrades (vs performing a fresh reinstall)
>>> Installation Size (e.g. base system)
>>> Network: Storage (e.g. iSCSI, NFS, smb/Samba)
>>> Network: Firewall
>>> Network: Router
>>> Network: NAT
>>> Network: Performance - Bandwidth
>>> Network: Performance - PPS
>>> NUMA Performance
>>> Observability (e.g. DTrace, ebpf)
>>> Security: Application (e.g. ASLR, spectre/meltdown mitigations)
>>> Security: Userland Controls (e.g. MAC, jails)
>>> Up-to-date server applications
>>> ZFS
>> 
>> 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.
>> 
>>> 37. Indicate which laptop models are important to you for running FreeBSD as a laptop OS:
>>> 
>>> Acer
>>> Apple MacBook Pro
>>> Asus
>>> Chromebook
>>> Dell
>>> HP
>>> Huawei
>>> Lenovo
>>> LG
>>> Microsoft Surface
>>> Purism
>>> Other (please specify)
>> 
>> NYC*BUG folks: who wants a modern *BSD laptop?  I do… Anything missing from this list?
>> 
>> 
>>> 38. Please rate the level of importance of the following laptop functionalities in terms of importance:
>>> 
>>> (Not important, Convenient, Important, Very Important, Critically important)
>>> Wireless Drivers (e.g. 802.11a, b, g, n, ac)
>>> Battery life/Power Management
>>> Suspend/Resume to RAM
>>> Accelerated graphics/GPU (e.g. drm2)
>>> Suspend/Resume to Disk
>>> Multi-monitor support
>>> Encryption at Rest
>>> Bluetooth Support
>>> 4K/5K resolution
>>> Touchscreen Support
>>> Out of the box experience / Ease of installation
>> 
>> Missing from this list: Synaptics touchpad support.  It is an outright disaster on FreeBSD, not a well respected problem, and a critical blocker to FreeBSD adoption on laptops.  That’s my opinion, but I see it as *the* blocker to FreeBSD on laptops, (OpenBSD folks really get this issue- and their implementation and user documentation shows it).
>> 
>> 
>>> 39. Please rate the level of importance of the following desktop functionalities in terms of importance:
>>> 
>>> Accelerated graphics/GPU (e.g. drm2)
>>> Multi-monitor support
>>> 4K/5K resolution
>>> Power Management
>>> Wireless Drivers (e.g. 802.11a, b, g, n, ac)
>>> Encryption at Rest
>>> Bluetooth Support
>>> Touchscreen Support
>>> Out of the box experience / Ease of installation
>> 
>> Missing from this list, (and laptop list), DRM/binary-blob questions.  Many FreeBSD desktop/laptop uses revolve around high security applications, and even though FreeBSD does not have the same aims as say OpenBSD does in this area, it’s still a critical point of discussion for *BSD desktops/laptops.
>> 
>>> 44. What type of events do you attend, if any?
>>> 
>>> - a local FreeBSD Meetup
>>> - FreeBSD conference
>>> - Linux conferences
>>> -  General Open Source Software conference (e.g. All Things Open, OSCon, Velocity)
>>> - System Administrator conferences (e.g. LISA)
>>> - Vendor sponsored conferences (e.g. Google or Microsoft)
>>> - Other (please specify)
>> 
>> NYC*BUG people: shout and make yourselves counted here :)
>> 
>> Best,
>> .ike
>> 
>> _______________________________________________
>> talk mailing list
>> talk at lists.nycbug.org
>> http://lists.nycbug.org:8080/mailman/listinfo/talk




More information about the talk mailing list