Re: ci.freebsd.org: powerpcspe build failing due to linker error in assembly code
On Mon, 20 May 2019 17:54:12 -0700 Enji Cooper wrote: > Hi, > The following build issue has been cropping up over the past > 6 hours. From > https://ci.freebsd.org/job/FreeBSD-head-powerpcspe-build/11154/console : > > 12:49:01 /usr/src/stand/powerpc/kboot/kerneltramp.S: Assembler > messages: 12:49:01 /usr/src/stand/powerpc/kboot/kerneltramp.S:88: > Error: Unrecognized opcode: `rldicr' > 12:49:01 /usr/src/stand/powerpc/kboot/kerneltramp.S:96: Error: > Unrecognized opcode: `rfid' > > This code hasn’t changed for some time. I’m not sure what > triggered the issue, but I suspect it has to deal with an external > [toolchain] change. Cheers! -Enji It's probably r348005's fault. It removes the ppc64bridge option. kboot should only be built for powerpc64 anyway. - Justin ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: ci.freebsd.org: powerpcspe build failing due to linker error in assembly code
On Mon, 2019-05-20 at 17:54 -0700, Enji Cooper wrote: > Hi, > The following build issue has been cropping up over the past 6 hours. > From https://ci.freebsd.org/job/FreeBSD-head-powerpcspe-build/11154/console : > > 12:49:01 /usr/src/stand/powerpc/kboot/kerneltramp.S: Assembler messages: > 12:49:01 /usr/src/stand/powerpc/kboot/kerneltramp.S:88: Error: Unrecognized > opcode: `rldicr' > 12:49:01 /usr/src/stand/powerpc/kboot/kerneltramp.S:96: Error: Unrecognized > opcode: `rfid' > > This code hasn’t changed for some time. I’m not sure what > triggered the issue, but I suspect it has to deal with an external > [toolchain] change. > Cheers! > -Enji r347992 seems like a good candidate. -- Ian ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
ci.freebsd.org: powerpcspe build failing due to linker error in assembly code
Hi, The following build issue has been cropping up over the past 6 hours. From https://ci.freebsd.org/job/FreeBSD-head-powerpcspe-build/11154/console : 12:49:01 /usr/src/stand/powerpc/kboot/kerneltramp.S: Assembler messages: 12:49:01 /usr/src/stand/powerpc/kboot/kerneltramp.S:88: Error: Unrecognized opcode: `rldicr' 12:49:01 /usr/src/stand/powerpc/kboot/kerneltramp.S:96: Error: Unrecognized opcode: `rfid' This code hasn’t changed for some time. I’m not sure what triggered the issue, but I suspect it has to deal with an external [toolchain] change. Cheers! -Enji ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: /usr/lib/libomp.so that was added in 13-CURRENT causes port failures and might conflict with libomp.so provided by devel/openmp
On Sat, 18 May 2019 at 22:23, Yuri wrote: > > Why was /usr/lib/libomp.so added to the base? It was added to the base because it's a runtime library required to support a feature provided by the base system compiler. Do you have an example of a failing port? ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
master.passwd & group broken in .svn_revision 347964 .ctm_status src-cur 14046
Hi current@ src/ is broken in .svn_revision 347964 .ctm_status src-cur 14046 after finaly getting past make buildworld make buildkernel make installkernel reboot it failed on mergemaster -p cp: /usr/src/etc/master.passwd: No such file or directory Clue here: https://svnweb.freebsd.org/base/head/etc/Makefile?view=log I could not afford another long wait for build so: cd /usr/src ; ln -s ../lib/libc/gen/master.passwd etc/master.passwd cd /usr/src ; ln -s ../lib/libc/gen/group etc/group If there's more moves coming, is it possible for them to all be in one cohesive .svn revision ? Cheers, Julian -- Julian Stacey, Consultant Systems Engineer, BSD Linux Unix, Munich Aachen Kent http://stolenvotes.uk Brexit ref. stole votes from 700,000 Brits in EU. Lies bought; Groups fined; 1.9 M young had no vote, 1.3 M old leavers died. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: FreeBSD Core Team Response to Controversial Social Media Posts
the discussion somehow diverted away from original idea... as i'm not politically correct person at all, i say that single report is not enough... it doesn't matter if legit or troll... it's also quite wrong if case gets special attention just because offended person adds that (s)he's discriminated because x i actually find it weird why the problem can't be directed to specific person... why do we need to turn it into "against group" issue On Monday, May 20, 2019, wrote: > Am 2019-05-20 11:33, schrieb Igor Mozolevsky: >> >> So you think a discussion on whether it is appropriate that CoC Ctte >> restricts freedom of expression is bikeshedding? >> >> Thank you for your valuable contribution! > > > IMO, the CoC was not meant to solve, decide or even regulate discussion about decades-old, very controversial geo-political problems. > > As such, I don't think it even applies here and the complaint should be dismissed on these grounds. > > Of course, the FreeBSD project is free to boot developers from its ranks more or less at will (not sure if you can sue your way back in) - but for that a new CoC wouldn't have been needed to begin with ;-) > > > > > > > ___ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" > ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Using loader.conf(5) 'exec' directive to set video mode
On 5/20/19 9:46 AM, Markus Graf wrote: Hello Anthony, I know I am not technically answering your question. Just in case you don't really care about the resolution but want bigger fonts. You can get nice big letters by setting: fontb32=terminus-b32.fnt font8x16=terminus-b32.fnt font8x8=terminus-b32.fnt in rc.conf Thanks Markus, That solution will work for when init(8) runs the RC scripts, but doesn't get me bigger text when the loader and kernel are spewing messages. But that is better than nothing, and will at least allow me to use vt(4) again without a magnifying glass. Best regards Markus Anthony Jenkins via freebsd-x11 writes: I'm running (a somewhat dated) FreeBSD 13.0-CURRENT (git commit 68c8581f7, Tue. Feb 12 13:01:55 2019) on a UEFI laptop with an Intel UHD display, booting a ZFS root filesystem (gptzfsboot(8)). CORRECTION: I installed (merged) /boot/boot1.efifat in the existing EFI system partition; I didn't install /boot/gptzfsboot into a freebsd-boot partition. Reference: https://wiki.freebsd.org/RootOnZFS/GPTZFSBoot#Manually_Installing_FreeBSD_on_ZFS I'm trying to get the console into a lower resolution than the native UHD when the kernel is booted. I can manually do this by breaking into the loader prompt at boot and entering 'mode 1', then 'boot'. loader.conf(5) says I can run this command automatically with the 'exec' directive, but the video mode doesn't change. $ sudo cat /boot/loader.conf Password: autoboot_delay="3" #boot_single="YES" boot_verbose="YES" kern.timecounter.hardware="HPET" hw.psm.synaptics_support="1" kern.vty="vt" hw.vga.textmode="1" efi_max_resolution="1920x1080" exec="mode 1" I've also tried using directive 'efi_max_resolution' - same result. Does 'exec' work on my configuration (UEFI boot, ZFS root), or am I not using it right? I've tried putting other loader commands in 'exec' with no effect. Same question for efi_max_resolution. A separate question (possibly for graphics@ or x11@) is when the i915(4) kernel module from the graphics/drm-current-kmod port is loaded by rc.conf(4)'s 'kld_list' variable. When I do manually set the console resolution using 'mode 1', it is reset to maximum resolution when i915(4) is loaded. Thanks in advance, Anthony Jenkins ___ freebsd-...@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-x11 To unsubscribe, send any mail to "freebsd-x11-unsubscr...@freebsd.org" ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Using loader.conf(5) 'exec' directive to set video mode
Hello Anthony, I know I am not technically answering your question. Just in case you don't really care about the resolution but want bigger fonts. You can get nice big letters by setting: fontb32=terminus-b32.fnt font8x16=terminus-b32.fnt font8x8=terminus-b32.fnt in rc.conf Best regards Markus Anthony Jenkins via freebsd-x11 writes: I'm running (a somewhat dated) FreeBSD 13.0-CURRENT (git commit 68c8581f7, Tue. Feb 12 13:01:55 2019) on a UEFI laptop with an Intel UHD display, booting a ZFS root filesystem (gptzfsboot(8)). I'm trying to get the console into a lower resolution than the native UHD when the kernel is booted. I can manually do this by breaking into the loader prompt at boot and entering 'mode 1', then 'boot'. loader.conf(5) says I can run this command automatically with the 'exec' directive, but the video mode doesn't change. $ sudo cat /boot/loader.conf Password: autoboot_delay="3" #boot_single="YES" boot_verbose="YES" kern.timecounter.hardware="HPET" hw.psm.synaptics_support="1" kern.vty="vt" hw.vga.textmode="1" efi_max_resolution="1920x1080" exec="mode 1" I've also tried using directive 'efi_max_resolution' - same result. Does 'exec' work on my configuration (UEFI boot, ZFS root), or am I not using it right? I've tried putting other loader commands in 'exec' with no effect. Same question for efi_max_resolution. A separate question (possibly for graphics@ or x11@) is when the i915(4) kernel module from the graphics/drm-current-kmod port is loaded by rc.conf(4)'s 'kld_list' variable. When I do manually set the console resolution using 'mode 1', it is reset to maximum resolution when i915(4) is loaded. Thanks in advance, Anthony Jenkins ___ freebsd-...@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-x11 To unsubscribe, send any mail to "freebsd-x11-unsubscr...@freebsd.org" -- Liebe Grüße Markus Graf ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Using loader.conf(5) 'exec' directive to set video mode
I'm running (a somewhat dated) FreeBSD 13.0-CURRENT (git commit 68c8581f7, Tue. Feb 12 13:01:55 2019) on a UEFI laptop with an Intel UHD display, booting a ZFS root filesystem (gptzfsboot(8)). I'm trying to get the console into a lower resolution than the native UHD when the kernel is booted. I can manually do this by breaking into the loader prompt at boot and entering 'mode 1', then 'boot'. loader.conf(5) says I can run this command automatically with the 'exec' directive, but the video mode doesn't change. $ sudo cat /boot/loader.conf Password: autoboot_delay="3" #boot_single="YES" boot_verbose="YES" kern.timecounter.hardware="HPET" hw.psm.synaptics_support="1" kern.vty="vt" hw.vga.textmode="1" efi_max_resolution="1920x1080" exec="mode 1" I've also tried using directive 'efi_max_resolution' - same result. Does 'exec' work on my configuration (UEFI boot, ZFS root), or am I not using it right? I've tried putting other loader commands in 'exec' with no effect. Same question for efi_max_resolution. A separate question (possibly for graphics@ or x11@) is when the i915(4) kernel module from the graphics/drm-current-kmod port is loaded by rc.conf(4)'s 'kld_list' variable. When I do manually set the console resolution using 'mode 1', it is reset to maximum resolution when i915(4) is loaded. Thanks in advance, Anthony Jenkins ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Heads up for breaking drm update.
On 2019-05-20 17:21, Michael Butler wrote: On 2019-05-19 23:21, Johannes Lundberg wrote: On 5/19/19 7:36 PM, Steve Kargl wrote: On Sun, May 19, 2019 at 02:50:54PM -0700, Johannes Lundberg wrote: LinuxKPI in base have received a lot of updates recently for Linux 5.0, a couple of them will break drm-current-kmod. So, as of r347973 you will need drm-current-kmod 4.16.g20190519. Ports have been updated and new packages should be available shortly. If drm-current-kmod is broken, should I venture to ask about drm-stable-kmod and drm-legacy-kmod? That's a very good question. Maybe I should have included more information regarding what's not affected. The last series of commits have been to LinuxKPI in -CURRENT. As such: drm-kmod: Meta port, not relevant drm-current-kmod: See original message drm-fbsd11.2-kmod: Not affected by changes in -CURRENT drm-fbsd12.0-kmod: Not affected by changes in -CURRENT drm-legacy-kmod: Not affected by changes in LinuxKPI drm-stable-kmod does not exist anymore. Stable drm kmod ports for other than -CURRENT are more or less frozen in separate branches where they only receive bug fixes (drm-fbsdxxx-kmod). Hope that answers your questions. It should also be noted that drm-current now has a new dependency on lindebugfs. It won't load without it :-( Previously, lindebugfs was part of the port, and loaded from the port. With this update, we simply switched to using the debugfs version that was imported into base. Regards -- Niclas Zeising FreeBSD Graphics Team ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Heads up for breaking drm update.
On 2019-05-19 23:21, Johannes Lundberg wrote: > > On 5/19/19 7:36 PM, Steve Kargl wrote: >> On Sun, May 19, 2019 at 02:50:54PM -0700, Johannes Lundberg wrote: >>> LinuxKPI in base have received a lot of updates recently for Linux 5.0, >>> a couple of them will break drm-current-kmod. So, as of r347973 you will >>> need drm-current-kmod 4.16.g20190519. Ports have been updated and new >>> packages should be available shortly. >>> >> If drm-current-kmod is broken, should I venture to ask >> about drm-stable-kmod and drm-legacy-kmod? > > That's a very good question. Maybe I should have included more > information regarding what's not affected. The last series of commits > have been to LinuxKPI in -CURRENT. As such: > > drm-kmod: Meta port, not relevant > drm-current-kmod: See original message > drm-fbsd11.2-kmod: Not affected by changes in -CURRENT > drm-fbsd12.0-kmod: Not affected by changes in -CURRENT > drm-legacy-kmod: Not affected by changes in LinuxKPI > > drm-stable-kmod does not exist anymore. Stable drm kmod ports for other > than -CURRENT are more or less frozen in separate branches where they > only receive bug fixes (drm-fbsdxxx-kmod). > > Hope that answers your questions. It should also be noted that drm-current now has a new dependency on lindebugfs. It won't load without it :-( imb ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: FreeBSD Core Team Response to Controversial Social Media Posts
Am 2019-05-20 11:33, schrieb Igor Mozolevsky: So you think a discussion on whether it is appropriate that CoC Ctte restricts freedom of expression is bikeshedding? Thank you for your valuable contribution! IMO, the CoC was not meant to solve, decide or even regulate discussion about decades-old, very controversial geo-political problems. As such, I don't think it even applies here and the complaint should be dismissed on these grounds. Of course, the FreeBSD project is free to boot developers from its ranks more or less at will (not sure if you can sue your way back in) - but for that a new CoC wouldn't have been needed to begin with ;-) ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
FreeBSD CI Weekly Report 2019-05-12
(bcc -current and -stable for more audience) FreeBSD CI Weekly Report 2019-05-12 === Here is a summary of the FreeBSD Continuous Integration results for the period from 2019-05-06 to 2019-05-12. During this period, we have: * 2151 builds (98.2% passed, 1.8% failed) were executed on aarch64, amd64, armv6, armv7, i386, mips, mips64, powerpc, powerpc64, powerpcspe, riscv64, sparc64 architectures for head, stable/12, stable/11 branches. * 394 test runs (43.9% passed, 13.7% unstable, 42.4% exception) were executed on amd64, i386, riscv64 architectures for head, stable/12, stable/11 branches. * 19 doc builds (100% passed) (The statistics from experimental jobs are omitted) If any of the issues found by CI are in your area of interest or expertise please investigate the PRs listed below. The latest web version of this report is available at https://hackmd.io/s/SJ9KUn16V and archive is available at http://hackfoldr.org/freebsd-ci-report/, any help is welcome. ## Failing Tests * https://ci.freebsd.org/job/FreeBSD-head-i386-test/ i386 test is current suffering from loading ipsec(4) kernel module, which is needed after https://svnweb.freebsd.org/changeset/base/347410 , causes kernel panic. * https://ci.freebsd.org/job/FreeBSD-stable-12-i386-test/ * sys.netpfil.pf.forward.v6 * sys.netpfil.pf.forward.v4 * sys.netpfil.pf.set_tos.v4 * lib.libc.regex.exhaust_test.regcomp_too_big * lib.libregex.exhaust_test.regcomp_too_big * https://ci.freebsd.org/job/FreeBSD-stable-11-i386-test/ * local.kyua.* (31 cases) * local.lutok.* (3 cases) ## Failing Tests (from experimental jobs) * https://ci.freebsd.org/job/FreeBSD-head-amd64-test_zfs/ There are ~60 failing cases, including flakey ones, see https://ci.freebsd.org/job/FreeBSD-head-amd64-test_zfs/lastCompletedBuild/testReport/ for more details ## Disabled Tests * lib.libc.sys.mmap_test.mmap_truncate_signal https://bugs.freebsd.org/211924 * sys.fs.tmpfs.mount_test.large https://bugs.freebsd.org/212862 * sys.fs.tmpfs.link_test.kqueue https://bugs.freebsd.org/213662 * sys.kqueue.libkqueue.kqueue_test.main https://bugs.freebsd.org/233586 * usr.bin.procstat.procstat_test.command_line_arguments https://bugs.freebsd.org/233587 * usr.bin.procstat.procstat_test.environment https://bugs.freebsd.org/233588 ## Open Issues * https://bugs.freebsd.org/237077 possible race in build: /usr/src/sys/amd64/linux/linux_support.s:38:2: error: expected relocatable expression * https://bugs.freebsd.org/237403 Tests in sys/opencrypto should be converted to Python3 * https://bugs.freebsd.org/237641 Flakey test case: common.misc.t_dtrace_contrib.tst_dynopt_d * https://bugs.freebsd.org/237652 tests.hotspare.hotspare_test.hotspare_snapshot_001_pos timeout since somewhere in (r346814, r 346845] * https://bugs.freebsd.org/237655 Non-deterministic panic when running pf tests in interface ioctl code (NULL passed to strncmp) * https://bugs.freebsd.org/237656 "Freed UMA keg (rtentry) was not empty (18 items). Lost 1 pages of memory." seen when running sys/netipsec tests * https://bugs.freebsd.org/237657 sys.kern.pdeathsig.signal_delivered_ptrace timing out periodically on i386 ### Cause build fails * [233735: Possible build race: genoffset.o /usr/src/sys/sys/types.h: error: machine/endian.h: No such file or directory](https://bugs.freebsd.org/233735) * [233769: Possible build race: ld: error: unable to find library -lgcc_s](https://bugs.freebsd.org/233769) ### Others [Tickets related to testing@](https://preview.tinyurl.com/y9maauwg) ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: FreeBSD Core Team Response to Controversial Social Media Posts
So you think a discussion on whether it is appropriate that CoC Ctte restricts freedom of expression is bikeshedding? Thank you for your valuable contribution! -- Igor M. On Mon, 20 May 2019 at 06:23, Daniel Braniss wrote: > > BIKE SHED SYNDROME? > > danny > PS: intentionally top posting :-) > > > On 19 May 2019, at 22:43, Igor Mozolevsky wrote: > > > > On Sun, 19 May 2019 at 20:16, Warner Losh wrote: > >> > >> On Sun, May 19, 2019 at 11:34 AM Igor Mozolevsky wrote: > >>> > >>> On Sun, 19 May 2019 at 17:54, Warner Losh wrote: > > > > > > > Yes. There will always be limits, just like in real life. You can't tell > fire in a theater, and claim freedom of expression, for example. > >>> > >>> > >>> > >>> While that is an often cited example, it is rather tenuous as far as > >>> "freedom of expression" is concerned: yelling "Fire!" in a crowded > >>> theatre is by no measure an expression of one's views, thoughts, or > >>> opinions. At the same time, the invocation of a CoC ctte review is > >>> triggered by precisely the latter. > >> > >> > >> It is a difficult problem. The project needs to protect itself and its > >> members from harm. Sometimes, though rarely, that harm > >> comes from expressing ones views in a way that's so extreme > >> it causes real and lasting problems either for the cohesiveness > >> of the project, or its effect on the project's reputation is so > >> extreme, people can't separate the two and stop using it. There > >> needs to be a review mechanism for cases that are extreme. > > > > It's very difficult to subscribe to that view! The first problem you > > encounter is "what is an objectively extreme expression"--what is > > extreme to one, might be entirely common place to another. I'm sure > > whatever religious book one takes there is a passage that goes along > > the lines of "judge people by their deeds not by their words"... > > Secondly, the greatest legal minds in the US wrangled with that and > > came up with one answer: *ANY* expression is protected for otherwise > > it would not be "freedom." > > > > > >> At the same time, reviews are detrimental if they are triggered > >> for 'ordinary' conduct: they take time and energy away from > >> the project that could otherwise be spent on making things > >> better. The trick is to have any such review reflect the broad > >> consensus within the project of what's clearly out of bounds, > >> as well as having a fair and just response by the board in > >> the cases that require some action. > > > > > > Agreement by consensus is most dangerous, for, usually, the loudest > > wins because people with no backbone fall in-line; the best > > explanation of democracy I have ever heard was: "two wolves and a > > sheep deciding what to have for dinner!" ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: FreeBSD Core Team Response to Controversial Social Media Posts
On Mon, 20 May 2019 at 09:20, David Chisnall wrote: > > On 19 May 2019, at 20:43, Igor Mozolevsky wrote: > > > > the best > > explanation of democracy I have ever heard was: "two wolves and a > > sheep deciding what to have for dinner!" > > If you believe that this quote in any way supports your argument, then I > would suggest that you work through the game theoretic implications of this > structure. > > (Hint: if the sheep can abstain, the sheep is never eaten and even without > abstention the sheep isn’t going to be eaten today) Wow, what an art of arbitrary context switching! If anything, you demonstrate utter failure of understanding how the herd-rule^H^H^H^H^H^H^H^Hdemocracy works: "majority wins;" for some contrived reason you seem to think that *everyone* needs to have voted... On top of that, if you want people to hear you, quit making opaque assertions, and muster some brain cells to set out an argument... Regardless, you, too, are attempting to (rather badly) reframe the original problem and divert discussion, and the original problem was whether or not CoC should restrict freedom of expression. Do you have anything to say on *this* topic? -- Igor M. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: FreeBSD Core Team Response to Controversial Social Media Posts
On 19 May 2019, at 20:43, Igor Mozolevsky wrote: > > the best > explanation of democracy I have ever heard was: "two wolves and a > sheep deciding what to have for dinner!" If you believe that this quote in any way supports your argument, then I would suggest that you work through the game theoretic implications of this structure. (Hint: if the sheep can abstain, the sheep is never eaten and even without abstention the sheep isn’t going to be eaten today) David ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
