From raulcuza at gmail.com Mon Apr 1 21:18:24 2019 From: raulcuza at gmail.com (Raul Cuza) Date: Mon, 1 Apr 2019 21:18:24 -0400 Subject: [talk] OpsMops Halted (probably OT but tangentially related to April 3 talk) Message-ID: (1) https://threadreaderapp.com/thread/1091710068234641408.html (2) https://news.ycombinator.com/item?id=18716628 (3) https://techbeacon.com/devops/how-create-devops-testing-culture-3-keys-success # tl;dr (1) is the announcement that Michael DeHaan is stopping development of OpsMop only after a few months of working on it. This is the same developer who wrote Ansible. (2) is a small selection of the reaction to DeHaan's announcement about OpsMop and proof that his reasons for stopping development have merit. (More about the reasons for his stopping below.) (3) is a tech BS jargon heavy article that shows that there are other people who agree with DeHaan but have their head too far up their chosen solution to see the solution to their misery. # Why am I sharing this? I miss the (nonexistent?) tech era when the hardware, operating system and application were all crafted to work together by the same team; choices were optimized for the people, problem and situation. Building out a tech solution today involves so many layers piled on each other that it is a miserable experience troubleshooting through all the garbage code. Maybe if I had some choice over which open source OS I had to run on other people's hardware, I would not sound like a grumpy old sysadmin right now. I sympathize with DeHaan who wishes DevOps didn't mean DSL writing SysAdmins who work only on ops and automation. I also don't want to fall into his trap of having to be "feed by interaction" which is ultimately why he stopped work on OpsMop. If a project scratches an itch, then why not work on it whether you are going to be on the cover of PC Magazine or not? But then again, I am not a tech artist, so maybe I don't understand. Finally, Adam Auerbach in "How to Create a a DevOps Testing Culture" essentially agrees with DeHaan, but for the sake of DevOps Culture? which misses the point. """ *Successful DevOps adoption* requires more than just automation across the software development lifecycle; you also must change the way your team is organized, the way you work, and the expectations you have for people on your team. It means having engineers in all roles and removing the dependency on enterprise IT teams?such as operations or security testing?from getting features out the door. """ (my emphasis) The point isn't DevOps adoption, but building the effective tech solution efficiently. I do agree that all the Go/No Go people should be on the same team and working together. Having outside people who don't take the time to understand the technology but can stop its deployment is a sad situation. Gatekeepers are feudal "Expert Class" that should be democratized by spreading the skill around evenly (i.e. turn their expertise into testing code and engineer can read!). Ra?l "really needs to stop procrastinating" Cuza p.s. Maybe I should be more forgiving as in my day I wielded tech jargon like I had found the Holy Grail. But I'm older than that now; so meh. From edlinuxguru at gmail.com Mon Apr 1 21:59:53 2019 From: edlinuxguru at gmail.com (Edward Capriolo) Date: Mon, 1 Apr 2019 21:59:53 -0400 Subject: [talk] OpsMops Halted (probably OT but tangentially related to April 3 talk) In-Reply-To: References: Message-ID: On Mon, Apr 1, 2019 at 9:19 PM Raul Cuza wrote: > (1) https://threadreaderapp.com/thread/1091710068234641408.html > (2) https://news.ycombinator.com/item?id=18716628 > (3) > https://techbeacon.com/devops/how-create-devops-testing-culture-3-keys-success > > # tl;dr > (1) is the announcement that Michael DeHaan is stopping development of > OpsMop only after a few months of working on it. This is the same > developer who wrote Ansible. > > (2) is a small selection of the reaction to DeHaan's announcement > about OpsMop and proof that his reasons for stopping development have > merit. (More about the reasons for his stopping below.) > > (3) is a tech BS jargon heavy article that shows that there are other > people who agree with DeHaan but have their head too far up their > chosen solution to see the solution to their misery. > > # Why am I sharing this? > I miss the (nonexistent?) tech era when the hardware, operating system > and application were all crafted to work together by the same team; > choices were optimized for the people, problem and situation. Building > out a tech solution today involves so many layers piled on each other > that it is a miserable experience troubleshooting through all the > garbage code. Maybe if I had some choice over which open source OS I > had to run on other people's hardware, I would not sound like a grumpy > old sysadmin right now. > > I sympathize with DeHaan who wishes DevOps didn't mean DSL writing > SysAdmins who work only on ops and automation. I also don't want to > fall into his trap of having to be "feed by interaction" which is > ultimately why he stopped work on OpsMop. If a project scratches an > itch, then why not work on it whether you are going to be on the cover > of PC Magazine or not? But then again, I am not a tech artist, so > maybe I don't understand. > > Finally, Adam Auerbach in "How to Create a a DevOps Testing Culture" > essentially agrees with DeHaan, but for the sake of DevOps Culture? > which misses the point. > > """ > *Successful DevOps adoption* requires more than just automation across > the software development lifecycle; you also must change the way your > team is organized, the way you work, and the expectations you have for > people on your team. It means having engineers in all roles and > removing the dependency on enterprise IT teams?such as operations or > security testing?from getting features out the door. > """ (my emphasis) > > The point isn't DevOps adoption, but building the effective tech > solution efficiently. I do agree that all the Go/No Go people should > be on the same team and working together. Having outside people who > don't take the time to understand the technology but can stop its > deployment is a sad situation. Gatekeepers are feudal "Expert Class" > that should be democratized by spreading the skill around evenly (i.e. > turn their expertise into testing code and engineer can read!). > > Ra?l "really needs to stop procrastinating" Cuza > > p.s. Maybe I should be more forgiving as in my day I wielded tech > jargon like I had found the Holy Grail. But I'm older than that now; > so meh. > > _______________________________________________ > talk mailing list > talk at lists.nycbug.org > http://lists.nycbug.org:8080/mailman/listinfo/talk "We get tired, and we let things just go. We use what other people are using. We run clouds on top of our freaking clouds for no reason, and we are much more interested in tech fashion than what makes us productive. We tolerate software with thousands of bugs." Really? but Ansible which wraps python on top of shell commands is more productive? I used some of the first versions of ansible.They were bad, in particular the entire "this sexy python thing does not work with RHEL, because of strange python ssh library and having to patch ssh server to involve pipelining", and it "worked" out of the box but ran as slow as dirt because it would uses some python math module instead of c-code to do ssl :) Touching a file was wrapped in multiple levels of python, ow and the YAML files... And out for every command I wanted to run it was running 19 other commands to "fact check" my system. Most programers don't know much about operating systems or networking, most ops people hate writing code. All dev-ops is now is now just what every sysadmin calls themselves when getting a new job. If you reject the devops labelgo going even more cutting edge and call yourself an SRE. lol Open source software feeds off interaction. And this is my diagnosis basically - widescale burnout. It's been coming in slow but we didn't see it. Agile and DevOps are the burnout. IMHO we are *poorer* technologically than we were 6 years ago in some areas. Why Not really what is going on. In the 60s people theorized that computing would soon enter the conceptual age. IE I tell my compiler "make me a program with 2 text boxes and a button that when I click on the text boxes it adds them". https://www.techrepublic.com/article/developers-rejoice-now-ai-can-write-code-for-you/ If a AI program can write code, why should a human have to write code to setup a system.Think like back to the future 2.... "You have to use your hands....thats like a baby toy" -------------- next part -------------- An HTML attachment was scrubbed... URL: From raulcuza at gmail.com Tue Apr 2 09:49:54 2019 From: raulcuza at gmail.com (Raul Cuza) Date: Tue, 2 Apr 2019 09:49:54 -0400 Subject: [talk] OpsMops Halted (probably OT but tangentially related to April 3 talk) In-Reply-To: References: Message-ID: On Mon, Apr 1, 2019 at 10:00 PM Edward Capriolo wrote: > > > "We get tired, and we let things just go. We use what other people are using. We run clouds on top of our freaking clouds for no reason, and we are much more interested in tech fashion than what makes us productive. We tolerate software with thousands of bugs." > > Really? but Ansible which wraps python on top of shell commands is more productive? I used some of the first versions of ansible.They were bad, in particular the entire "this sexy python thing does not work with RHEL, because of strange python ssh library and having to patch ssh server to involve pipelining", and it "worked" out of the box but ran as slow as dirt because it would uses some python math module instead of c-code to do ssl :) Touching a file was wrapped in multiple levels of python, ow and the YAML files... And out for every command I wanted to run it was running 19 other commands to "fact check" my system. > > Most programers don't know much about operating systems or networking, most ops people hate writing code. All dev-ops is now is now just what every sysadmin calls themselves when getting a new job. If you reject the devops labelgo going even more cutting edge and call yourself an SRE. lol > > Open source software feeds off interaction. And this is my diagnosis basically - widescale burnout. It's been coming in slow but we didn't see it. Agile and DevOps are the burnout. IMHO we are *poorer* technologically than we were 6 years ago in some areas. Why > > Not really what is going on. In the 60s people theorized that computing would soon enter the conceptual age. IE I tell my compiler "make me a program with 2 text boxes and a button that when I click on the text boxes it adds them". https://www.techrepublic.com/article/developers-rejoice-now-ai-can-write-code-for-you/ > > If a AI program can write code, why should a human have to write code to setup a system.Think like back to the future 2.... > > "You have to use your hands....thats like a baby toy" > > > I'm not going to argue that using hands isn't like a baby toy. Like a baby, adult brains are stimulated by body movement. This is different from person to person, but I think the whole body is part of thinking. My fingers help me remember phone numbers for example. As for "make me a program..." that is fascinating. I think we agree that there is a difference between the levels of abstraction in telling the compiler the steps of building something (e.g. "make 2 text boxes and a button" can be done with English or with Python with equal results) to the level of abstraction of "make me an application that attracts 10,000 paying customers." I agree that a compiler can get to the point that you can use English to program it. I have no clue if it will ever get to the point that you can tell it the goal of the application and it will be able to write it. Now if a system is doing everything to setup another system, we've left Comp Sci and entered biology. Ra?l From kmsujit at gmail.com Tue Apr 2 10:12:49 2019 From: kmsujit at gmail.com (Sujit K M) Date: Tue, 2 Apr 2019 19:42:49 +0530 Subject: [talk] OpsMops Halted (probably OT but tangentially related to April 3 talk) In-Reply-To: References: Message-ID: On Tue, Apr 2, 2019 at 7:20 PM Raul Cuza wrote: > I'm not going to argue that using hands isn't like a baby toy. Like a > baby, adult brains are stimulated by body movement. This is different > from person to person, but I think the whole body is part of thinking. > My fingers help me remember phone numbers for example. It depends on what capacity a person or a living being have. As we find not all living beings are capable and not all human beings are equal, some have fast hands, some are 100 mts champions, some are marathon runners. But I have never seen or made the choice of multiple professions or hobbists. > As for "make me a program..." that is fascinating. I think we agree > that there is a difference between the levels of abstraction in > telling the compiler the steps of building something (e.g. "make 2 > text boxes and a button" can be done with English or with Python with > equal results) to the level of abstraction of "make me an application > that attracts 10,000 paying customers." I agree that a compiler can > get to the point that you can use English to program it. I have no > clue if it will ever get to the point that you can tell it the goal of > the application and it will be able to write it. > > Now if a system is doing everything to setup another system, we've > left Comp Sci and entered biology. We are not leading to biology, we are moving on to advances made in computing, like speech to text can dictate a program, an intelligent IDE should convert a program from synonym's in programming and complete the program which can be tested and corrected at the IDE level. Would take Dev Ops to another level. From mcevoy.pat at gmail.com Tue Apr 2 10:19:14 2019 From: mcevoy.pat at gmail.com (Pat McEvoy) Date: Tue, 2 Apr 2019 10:19:14 -0400 Subject: [talk] NYC*BUG Message-ID: Next NYC*BUG: tomorrow! Verification As Code of Infrastructure As Code, Raul Cuza More info: https://www.nycbug.org/index?action=view&id=10666 -------------- next part -------------- An HTML attachment was scrubbed... URL: From viewtiful.icchan at gmail.com Tue Apr 2 10:25:54 2019 From: viewtiful.icchan at gmail.com (Robert Menes) Date: Tue, 2 Apr 2019 10:25:54 -0400 Subject: [talk] NYC*BUG In-Reply-To: References: Message-ID: I'll be there! --Robert On Tue, Apr 2, 2019, 10:19 Pat McEvoy wrote: > Next NYC*BUG: tomorrow! > > Verification As Code of Infrastructure As Code, Raul Cuza > > More info: > https://www.nycbug.org/index?action=view&id=10666 > > > _______________________________________________ > talk mailing list > talk at lists.nycbug.org > http://lists.nycbug.org:8080/mailman/listinfo/talk > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mcevoy.pat at gmail.com Thu Apr 4 01:08:28 2019 From: mcevoy.pat at gmail.com (Pat McEvoy) Date: Thu, 4 Apr 2019 01:08:28 -0400 Subject: [talk] Speaker for May NYC*Bug meeting Message-ID: Hello all, We are looking for a speaker for the May 2019 meeting. If anyone has a project they are working on they would like to share, we would love to hear about it. Please hit talk@ with ideas for future meeting ideas. Be well, P From mcevoy.pat at gmail.com Thu Apr 4 15:36:20 2019 From: mcevoy.pat at gmail.com (Pat McEvoy) Date: Thu, 4 Apr 2019 15:36:20 -0400 Subject: [talk] Shell FU by Isaac (.ike) Levy Message-ID: Posted the way overdue video of that killer talk .ike did in November 2016 It is referenced in Ivan?s talk from February 2019. https://youtu.be/S_aTzXVRRlM Enjoy, P From george at ceetonetechnology.com Mon Apr 8 18:57:00 2019 From: george at ceetonetechnology.com (George Rosamond) Date: Mon, 08 Apr 2019 22:57:00 +0000 Subject: [talk] BSDCan 2019 Registration Open Message-ID: Feel free to use to the talk@ list to coordinate plans. Dan L says... Registration for BSDCan 2019 opened on Sunday and already we have 26 people registered. It is 5 weeks until Mother's Day and then a few days more until BSDCan. Not much time now! Register today: https://www.bsdcan.org/2019/registration.php The schedule, previously 'leaked' on Github, was released late last week. Don't miss byhvecon on 14 May: https://www.bsdcan.org/2019/schedule/ When booking accommodation at U90 (on campus), you may get told they are sold out. They are not. Be sure to check this: * you've used our booking code BSDCAN2019 (expires 14 May, see https://www.bsdcan.org/2019/accommodations.php) * you're checking out on Sunday (the code only covers a certain period; if you want to stay longer, please make a separate booking, and pay for it when you arrive). There will be an unsponsored social event held on Saturday night: * $45 for your food. * Be sure to book your spot when you register. * Bringing someone? You can buy that ticket when you get to Ottawa email me so we save you a spot. It's only four short weeks until the BSDCan team hits Ottawa, getting things ready for you. See you soon! Thanks to our sponsors Verisign/vBSDCon - https://www.vbsdcon.com/ Tarsnap - https://www.tarsnap.com/ The FreeBSD Foundation - https://www.freebsdfoundation.org/ NetApp - http://www.netapp.com/ NetBSD - https://www.netbsd.org/ Netzkommune - https://www.netzkommune.de/ Netflix - https://www.netflix.com/ Stefan Sperling - http://www.stefansperling.de/ Six Feet Up - https://sixfeetup.com/ Follow us: Facebook: https://www.facebook.com/groups/BSDCan/ Twitter: http://www.twitter.com/bsdcan From george at ceetonetechnology.com Sat Apr 13 13:05:00 2019 From: george at ceetonetechnology.com (George Rosamond) Date: Sat, 13 Apr 2019 17:05:00 +0000 Subject: [talk] BSDCan 2019 corrections Message-ID: <292856ea-f4d4-a499-43f5-5a98345d817b@ceetonetechnology.com> These are corrections sent by Dan L to the previous email: > > 1 - The booking code for UOttawa residencies expires on 14 April (Sunday, tomorrow as I type this), not May as erroneously stated. > > 2 - The closing social is $50, not $45. > > In both cases, the website contained the correct information and my email was incorrect. > > Sorry about that. My apologies. > > Keep in mind for the residences: > > When booking accommodation at U90 (on campus), you may get told they are sold out. They are not. Be sure to check this: >> >> * you've used our booking code BSDCAN2019 >> * you're checking out on Sunday (the code only covers a certain period; if you want to stay longer, please make a separate booking, and pay for it when you arrive). From mcevoy.pat at gmail.com Mon Apr 15 14:07:48 2019 From: mcevoy.pat at gmail.com (Pat McEvoy) Date: Mon, 15 Apr 2019 14:07:48 -0400 Subject: [talk] Ideas for future NYC*Bug talks Message-ID: <76A20240-3BC8-4871-A93C-B405F0E893CB@gmail.com> Does anyone have any ideas percolating for a future NYC*Bug talk? Some ideas came up while closing down the last session and I would love to keep the momentum going. It would be a great way to test your idea before presentation at a conference. BTW, I hope to have two more meeting videos out before BSDCan. I have changed my workflow so the logjam of meeting video releases should be at an end. Be well and have a good spring everyone. P From fire at firecrow.com Mon Apr 15 14:27:32 2019 From: fire at firecrow.com (fire crow) Date: Mon, 15 Apr 2019 14:27:32 -0400 Subject: [talk] Ideas for future NYC*Bug talks In-Reply-To: <76A20240-3BC8-4871-A93C-B405F0E893CB@gmail.com> References: <76A20240-3BC8-4871-A93C-B405F0E893CB@gmail.com> Message-ID: how about a tour of the datastructures in the freebsd kernel, e.g. the radix or red black trees. I can speak to the radix tree implementation used for accesing network addreases ~fire On Mon, Apr 15, 2019, 14:07 Pat McEvoy wrote: > Does anyone have any ideas percolating for a future NYC*Bug talk? Some > ideas came up while closing down the last session and I would love to keep > the momentum going. It would be a great way to test your idea before > presentation at a conference. > BTW, I hope to have two more meeting videos out before BSDCan. I have > changed my workflow so the logjam of meeting video releases should be at an > end. Be well and have a good spring everyone. > > P > > _______________________________________________ > talk mailing list > talk at lists.nycbug.org > http://lists.nycbug.org:8080/mailman/listinfo/talk > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kmsujit at gmail.com Sat Apr 20 08:43:23 2019 From: kmsujit at gmail.com (Sujit K M) Date: Sat, 20 Apr 2019 18:13:23 +0530 Subject: [talk] A Long Drawn Suspense on Ubuntu Installations Message-ID: I have been trying Ubuntu since 18.04. Installed it on my Laptop and Desktop. But one thing I always found was that efi grub somehow fails on both my machines. I would love to be given the opportunity to install what I want. I don't want EFI support so don't install it by some configuration. For me it is leading to lot of tricks to install Ubuntu on my laptop or desktop like I found out that installing on EXT filesystem some how lets it install on 18.04/18.08(This inspite of the fact that though grub efi install still fails on 18.04/18.08) also it fails on 19.04 for my laptop some how. I am not being asked for efi support or no packages are there to be installed in case of my desktop. I want to avoid that. From fire at firecrow.com Sat Apr 20 11:22:21 2019 From: fire at firecrow.com (fire crow) Date: Sat, 20 Apr 2019 11:22:21 -0400 Subject: [talk] A Long Drawn Suspense on Ubuntu Installations In-Reply-To: References: Message-ID: On Sat, Apr 20, 2019, 08:43 Sujit K M wrote: > I have been trying Ubuntu since 18.04. Installed it on my Laptop and > Desktop. > But one thing I always found was that efi grub somehow fails on both > my machines. > I would love to be given the opportunity to install what I want. I > don't want EFI support > so don't install it by some configuration. For me it is leading to lot > of tricks to install > Ubuntu on my laptop or desktop like I found out that installing on EXT > filesystem some > how lets it install on 18.04/18.08(This inspite of the fact that > though grub efi install still fails on > 18.04/18.08) also it fails on 19.04 for my laptop some how. I am not > being asked for efi > support or no packages are there to be installed in case of my > desktop. I want to avoid that. > What does your bios say, boot legacy or boot uefi? I found that setting boot to legacy solved my efi problems. ~fire > _______________________________________________ > talk mailing list > talk at lists.nycbug.org > http://lists.nycbug.org:8080/mailman/listinfo/talk > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kmsujit at gmail.com Sat Apr 20 11:34:34 2019 From: kmsujit at gmail.com (Sujit K M) Date: Sat, 20 Apr 2019 21:04:34 +0530 Subject: [talk] A Long Drawn Suspense on Ubuntu Installations In-Reply-To: References: Message-ID: > What does your bios say, boot legacy or boot uefi? I found that setting boot to legacy solved my efi problems. I tried both. Still it fails. Though I find it to be in the history of releases that ubuntu has gone through, there seems to be some problem with UEFI. Could you please let me of any write ups which I can look at to be on the same page? From fire at firecrow.com Sat Apr 20 11:55:54 2019 From: fire at firecrow.com (fire crow) Date: Sat, 20 Apr 2019 11:55:54 -0400 Subject: [talk] A Long Drawn Suspense on Ubuntu Installations In-Reply-To: References: Message-ID: On Sat, Apr 20, 2019, 11:34 Sujit K M wrote: > > What does your bios say, boot legacy or boot uefi? I found that setting > boot to legacy solved my efi problems. > I tried both. Still it fails. Though I find it to be in the history of > releases that ubuntu has gone through, there seems > to be some problem with UEFI. Could you please let me of any write ups > which I can look at to be on the same page? > if you see the grub menu you can press e to see the details of that boot option, Im not intimately familiar with what to look for but it may give you some google candy. ~fire > -------------- next part -------------- An HTML attachment was scrubbed... URL: From njt at ayvali.org Tue Apr 23 19:04:09 2019 From: njt at ayvali.org (N.J. Thomas) Date: Tue, 23 Apr 2019 16:04:09 -0700 Subject: [talk] A Long Drawn Suspense on Ubuntu Installations In-Reply-To: References: Message-ID: <20190423230409.GV91002@ayvali.org> * Sujit K M [2019-04-20 18:13:23+0530]: > Installed it on my Laptop and Desktop. But one thing I always found > was that efi grub somehow fails on both my machines. I would love to > be given the opportunity to install what I want. hi Sujit, Have you tried checking with the local Linux group, NYLUG? I would think you would have better luck discussing a Ubuntu install with them, as opposed to NYCBUG. hth, Thomas From kmsujit at gmail.com Sat Apr 27 04:15:32 2019 From: kmsujit at gmail.com (Sujit K M) Date: Sat, 27 Apr 2019 13:45:32 +0530 Subject: [talk] A Long Drawn Suspense on Ubuntu Installations In-Reply-To: <20190423230409.GV91002@ayvali.org> References: <20190423230409.GV91002@ayvali.org> Message-ID: > hi Sujit, > > Have you tried checking with the local Linux group, NYLUG? I would think > you would have better luck discussing a Ubuntu install with them, as > opposed to NYCBUG. > > hth, > Thomas https://ubuntuforums.org/showthread.php?t=946630 Looks like you can select packages to install with or without grub efi support for example. I tried several options before landing up with these. Something similar to FreeBSD like network installation. Where I could select the packages to deselect some of the packages. Though what I was very complicated like if you have windows installed install grub-win and the follow the below set of operations. https://help.ubuntu.com/community/Installation/NetbootInstallFromInternet I could not try and not willing too as it might lead to unusable after installs of my PC or Laptop. From ike at blackskyresearch.net Sat Apr 27 10:05:41 2019 From: ike at blackskyresearch.net (Isaac (.ike) Levy) Date: Sat, 27 Apr 2019 10:05:41 -0400 Subject: [talk] Fwd: [FreeBSD-Announce] 2019 FreeBSD Community Survey References: <86sgu419tp.fsf@phe.ftfl.ca> Message-ID: Hi All, Sorry to cross-post, but thought the "FreeBSD Community Survey? below looked interesting. https://www.research.net/r/freebsd2019 Best, .ike > Begin forwarded message: > > From: FreeBSD Core Team Secretary > Subject: [FreeBSD-Announce] 2019 FreeBSD Community Survey > Date: April 26, 2019 at 10:05:54 PM EDT > To: freebsd-announce at freebsd.org > Reply-To: FreeBSD Core Team > > The FreeBSD Core Team invites you to complete the 2019 FreeBSD Community > Survey. > > https://www.research.net/r/freebsd2019 > > Its purpose is to collect quantitative data from the public in order to > help guide the project's priorities and efforts. > > It will remain open for 17 days and close at midnight May 13 UTC (Monday > 5pm PDT). > > Given the wide range of people and organizations involved in the > project, this first iteration of our annual survey covers a broad range > of topics and is more exhaustive than future annual surveys will be. > Thus, it will take a little longer to complete, approximately 15 minutes > with a maximum of 47 questions. Your participation and time investment > are appreciated. > > Please feel free to share the survey URL with your employer, co-workers, > friends, or any other community members interested in FreeBSD. > > -- The FreeBSD Core Team (on behalf of the FreeBSD Community) From ike at blackskyresearch.net Sat Apr 27 12:37:31 2019 From: ike at blackskyresearch.net (Isaac (.ike) Levy) Date: Sat, 27 Apr 2019 12:37:31 -0400 Subject: [talk] Fwd: [FreeBSD-Announce] 2019 FreeBSD Community Survey In-Reply-To: References: <86sgu419tp.fsf@phe.ftfl.ca> Message-ID: Hi all, So without sharing my answers to various questions, I found the FreeBSD survey pretty interesting, and wanted to toss out some points for conversation in the group. Again, the FreeBSD survey is here: https://www.research.net/r/freebsd2019 Note for Survey takers: Depending on your answers on first page, (user vs. developer), you get different questions on the pages which follow. While this was probably intended to be a respectful time-saver for the person filling it out, I found there are a number of *VERY* relevant technical questions for users like us, which are only on ?contributor? pages. I?d strongly recommend folks on this list do start the survey stating they are a ?Contributor?, even if you put down very very little contribution time to FreeBSD in followup questions. While the survey questions reveal various tool choices and possible changes, it is a pretty great effort on the Foundation?s part to focus on discussing ?what we all do?, not just silly votes on tooling. With that, I hope my critique and questions below are thought of as constructive points for conversation, not just whining :) ? With that, I think a number of questions from the questionnaire deserve discussion: > 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. > - 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?. > 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. > 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 From raulcuza at gmail.com Sat Apr 27 13:20:05 2019 From: raulcuza at gmail.com (Raul Cuza) Date: Sat, 27 Apr 2019 13:20:05 -0400 Subject: [talk] Fwd: [FreeBSD-Announce] 2019 FreeBSD Community Survey In-Reply-To: References: <86sgu419tp.fsf@phe.ftfl.ca> Message-ID: Thank you for highlighting this survey. Day dreaming about having a choice other than Linux at work made me happy. > > 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. > > > - 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. "out of the box" also means you don't want to think about sysctl because everything just works. > > > 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. 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. > > > > 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 From imp at bsdimp.com Sat Apr 27 13:20:27 2019 From: imp at bsdimp.com (Warner Losh) Date: Sat, 27 Apr 2019 11:20:27 -0600 Subject: [talk] Fwd: [FreeBSD-Announce] 2019 FreeBSD Community Survey In-Reply-To: References: <86sgu419tp.fsf@phe.ftfl.ca> Message-ID: On Sat, Apr 27, 2019 at 10:39 AM Isaac (.ike) Levy 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: From ike at blackskyresearch.net Sat Apr 27 14:45:45 2019 From: ike at blackskyresearch.net (Isaac (.ike) Levy) Date: Sat, 27 Apr 2019 14:45:45 -0400 Subject: [talk] Fwd: [FreeBSD-Announce] 2019 FreeBSD Community Survey In-Reply-To: References: <86sgu419tp.fsf@phe.ftfl.ca> Message-ID: > On Apr 27, 2019, at 1:20 PM, Raul Cuza 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 From ipsens at ripsbusker.no.eu.org Sat Apr 27 15:15:12 2019 From: ipsens at ripsbusker.no.eu.org (Ipsen S Ripsbusker) Date: Sat, 27 Apr 2019 19:15:12 +0000 Subject: [talk] SATA cables Message-ID: <20190427191515.5A5EFE44D7@mailuser.nyi.internal> We learned last time that several of us no longer have our boxes of leftover cables. I am among those, and I need six SATA cables. I'll trade beer for SATA cables. And here's a thought: Anyone wanna exchange our junk cables during one meeting? It would be like a book swap. https://en.wikipedia.org/wiki/Book_swapping From ike at blackskyresearch.net Sat Apr 27 16:03:22 2019 From: ike at blackskyresearch.net (Isaac (.ike) Levy) Date: Sat, 27 Apr 2019 16:03:22 -0400 Subject: [talk] Fwd: [FreeBSD-Announce] 2019 FreeBSD Community Survey In-Reply-To: References: <86sgu419tp.fsf@phe.ftfl.ca> Message-ID: > On Apr 27, 2019, at 1:20 PM, Warner Losh wrote: > > > > On Sat, Apr 27, 2019 at 10:39 AM Isaac (.ike) Levy 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 From ike at blackskyresearch.net Sat Apr 27 16:06:08 2019 From: ike at blackskyresearch.net (Isaac (.ike) Levy) Date: Sat, 27 Apr 2019 16:06:08 -0400 Subject: [talk] SATA cables In-Reply-To: <20190427191515.5A5EFE44D7@mailuser.nyi.internal> References: <20190427191515.5A5EFE44D7@mailuser.nyi.internal> Message-ID: <52425025-E8A5-47D8-8B4A-83CFAC03C3C5@blackskyresearch.net> I have six SATA cables, fresh in unopened bags, (on shelf for 2yrs). Contact me off-list if you want to pick them up in Williamsburg- or, can bring to meeting next Wed. Best, .ike > On Apr 27, 2019, at 3:15 PM, Ipsen S Ripsbusker wrote: > > We learned last time that several of us no longer have our boxes > of leftover cables. I am among those, and I need six SATA cables. > I'll trade beer for SATA cables. > > And here's a thought: Anyone wanna exchange our junk cables during > one meeting? It would be like a book swap. > https://en.wikipedia.org/wiki/Book_swapping > > _______________________________________________ > talk mailing list > talk at lists.nycbug.org > http://lists.nycbug.org:8080/mailman/listinfo/talk From pete at nomadlogic.org Sat Apr 27 19:43:19 2019 From: pete at nomadlogic.org (Pete Wright) Date: Sat, 27 Apr 2019 16:43:19 -0700 Subject: [talk] Fwd: [FreeBSD-Announce] 2019 FreeBSD Community Survey In-Reply-To: References: <86sgu419tp.fsf@phe.ftfl.ca> Message-ID: <5b82211e-aef5-8825-5e6c-2981db374f79@nomadlogic.org> On 4/27/19 1:03 PM, Isaac (.ike) Levy wrote: > -- > 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) /me waves at .ike after doing a bit of hacking on the graphics stack the past couple years i'd have to say that it's been super convenient to have that work happen on github as i use git extensively for work and am familiar with the flow. the only thing i wished was that we used gitlab rather than github - then we could trivially have gitlab runner processes and have easy CI and testing. we used it at a previous gig of mine and i felt like it is a much more robust git-suite when you notice some of the gaps that github has. > > ?- > 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... i've had several starts and stoppages attempting to update the graphics section of the handbook.? i have limited time, and can crank out wiki and markdown stuff quickly - but the LOE of DocBook is a bit high for my time constraints tbh. hopefully this survey can bring this issue to surface and find a way to get people more productive - be it better DocBook tools (wysiwyg editor would be huge) or move to asciidoc or something... -pete -- Pete Wright pete at nomadlogic.org @nomadlogicLA From kmsujit at gmail.com Sun Apr 28 01:14:51 2019 From: kmsujit at gmail.com (Sujit K M) Date: Sun, 28 Apr 2019 10:44:51 +0530 Subject: [talk] Fwd: [FreeBSD-Announce] 2019 FreeBSD Community Survey In-Reply-To: References: <86sgu419tp.fsf@phe.ftfl.ca> Message-ID: > With that, I think a number of questions from the questionnaire deserve discussion: > > > 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. I have never heard or seen ads for FreeBSD for Amazon/Google Cloud. How do they recruit their developers. > 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) Docker??Kubernetes?? It is Linux/Mac/Windows Based, like it is dependent on kernel for these OS's. Even Solaris doesn't support Docker/Kubernetes as such. My question is what are the current alternatives for these if Google/Amazon support Cloud for FreeBSD. I also saw questions on Cassandra why limited to this? From jim at netgate.com Sun Apr 28 01:33:58 2019 From: jim at netgate.com (Jim Thompson) Date: Sun, 28 Apr 2019 00:33:58 -0500 Subject: [talk] Fwd: [FreeBSD-Announce] 2019 FreeBSD Community Survey In-Reply-To: References: <86sgu419tp.fsf@phe.ftfl.ca> Message-ID: > On Apr 28, 2019, at 12:14 AM, Sujit K M wrote: > >> With that, I think a number of questions from the questionnaire deserve discussion: >> >>> 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. > > I have never heard or seen ads for FreeBSD for Amazon/Google Cloud. > How do they recruit their developers. Colin Percival on AWS: http://www.daemonology.net/blog/2018-02-12-FreeBSD-EC2-history.html Google itself on Google Cloud https://googlecloudplatform.uservoice.com/forums/302595-compute-engine/suggestions/18618931-freebsd https://console.cloud.google.com/launcher/details/freebsd-cloud/freebsd-10 https://console.cloud.google.com/launcher/details/freebsd-cloud/freebsd-11 https://console.cloud.google.com/launcher/details/freebsd-cloud/freebsd-12 >> 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) > > Docker??Kubernetes?? It is Linux/Mac/Windows Based, like it is > dependent on kernel for these OS's. > Even Solaris doesn't support Docker/Kubernetes as such. My question is > what are the current alternatives for > these if Google/Amazon support Cloud for FreeBSD. While k8s doesn?t run on FreeBSD (though jails are quite similar), Docker does: https://wiki.freebsd.org/Docker -------------- next part -------------- An HTML attachment was scrubbed... URL: From ipsens at ripsbusker.no.eu.org Sun Apr 28 23:10:34 2019 From: ipsens at ripsbusker.no.eu.org (Ipsen S Ripsbusker) Date: Mon, 29 Apr 2019 03:10:34 +0000 Subject: [talk] SATA cables In-Reply-To: References: <20190427191515.5A5EFE44D7@mailuser.nyi.internal> Message-ID: <20190429031038.26705E40E3@mailuser.nyi.internal> Thank you for all of the offers! The SATA cables are the most pressing for me, and Ike is bringing those, but I suppose all of these would be nice too: * Power strip with eight outlets * Surge protector (ideally part of the power strip) * 6-foot or longer USB type A to USB type B cable * Three adapters from the big 4-pin hard drive power plug to the small fan power plug * One adapter from DisplayPort or DVI to HDMI * Two USB type A to ethernet plugs From mcevoy.pat at gmail.com Tue Apr 30 09:43:30 2019 From: mcevoy.pat at gmail.com (Pat McEvoy) Date: Tue, 30 Apr 2019 09:43:30 -0400 Subject: [talk] Next NYC*BUG: Tomorrow! Message-ID: <3D6AD610-6B86-4F69-94A7-88D995A1C96D@gmail.com> Details here: https://www.nycbug.org/index?action=view&id=10667 From mcevoy.pat at gmail.com Tue Apr 30 19:16:18 2019 From: mcevoy.pat at gmail.com (Pat McEvoy) Date: Tue, 30 Apr 2019 19:16:18 -0400 Subject: [talk] BSDCan laptop w/USB3 loan ask Message-ID: Hello All, Patrick, the BSDTV guy here. If anyone has a laptop that will run either FreeBSD or Windows with USB3 and wouldn?t mind lending it out for a week and a half, please let me know. I will be at the NYC*BUG meeting tomorrow or could pick up in near future. Planning 5 streams this year so any spare gear is welcome. Also plan to stream BhyveCon the Tuesday before tutorials. Thank you in advance and hope to see you in Ottawa. Be well. Patrick