Re: FreeBSD Core Team Response to Controversial Social Media Posts
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!" > > > -- > 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" ___ 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 Sun, May 19, 2019 at 08:21:18PM -0700, 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. > Yes, that answers my question. Thanks. -- Steve ___ 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 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. /Johannes > ___ 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 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? -- Steve ___ 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: lib/libgcc_s fails on make all after make world succeeds
> On 19 May 2019, at 23:29, Julian H. Stacey wrote:
> >
> > Hi curr...@freebsd.org
> > On current src/ on 2 boxes, I have seen the same break for a week or 2,
> > lib/libgcc_s fails on make all after make world succeeds,
> > Anyone else seen it or got ideas please ? Notes below the sample.
> >
> > ===> lib/libgcc_s (all)
> > building shared library libgcc_s.so.1
> > cc -nodefaultlibs -Wl,--version-script=/usr/src/lib/libgcc_s/Version.map
> > -shared -Wl,-x -Wl,--fatal-warnings -Wl,--warn-shared-textrel -o \
> > libgcc_s.so.1.full -Wl,-soname,libgcc_s.so.1
> ...
> > -L/usr/obj/usr/src/amd64.amd64/lib/libc -lc \
> > ld: error: can't create dynamic relocation R_X86_64_32S \
> > against symbol: __je_sz_size2index_tab in readonly segment; \
> > recompile object files with -fPIC or pass '-Wl,-z,notext' \
> > to allow text relocations in the output
> defined in /usr/obj/usr/src/amd64.amd64/lib/libc/libc.a(jemalloc_sz.o)
>
> It looks like for some reason, it chooses to link with libc.a instead of
> libc.so here. Maybe your libc.so is not getting built at all, because
> of your environment?
I've removed my environment variables & src.conf & make.conf,
& new test running.
> Or maybe you are hitting some build race where libc.a is done, but
> libc.so is still being built, while at the same time, libgcc_s.so.1 is
> being linked?
>
> There are some difficult-to-reproduce races with libgcc_s, which are
> sometimes also hit by CI (I think Li-Wen mentioned them multiple times
> now). But usually I would expect this to be "solved" by simply
> re-running buildworld, as the race window is very small, and you have
> to be quite lucky (or unlucky, depending on your point of view :) to hit
> it.
>
> -Dimitry
Thanks Dimitry,
I'll re-read & consider but re. Race conditions, I hadnt thought
of that. I never use make [-j max_jobs] and ls -l ~jhs/.MAKE.JOBS
~root/.MAKE.JOBS # shows nothing
cd /usr/share/mk ; grep '\-j' *
bsd.cpu.mk:_CPUCFLAGS = -march=i686 -falign-functions=0 -falign-jumps=0
-falign-loops=0
bsd.info.mk:.if !empty(.MAKEFLAGS:M-j)
bsd.suffixes.mk:# XXX not -j safe
bsd.suffixes.mk:# XXX not -j safe
bsd.suffixes.mk:# XXX not -j safe
gendirdeps.mk: echo '# local dependencies - needed for -jN in clean tree'; \
meta.stage.mk:# for non-jobs mode the order here matters
cd /usr/src; grep '\-j' *
Makefile:# make universe -DMAKE_JUST_KERNELS JFLAG=-j${_jflag}
Makefile.inc1:echo "ncpu: $$(sysctl -n hw.ncpu)${.MAKE.JOBS:S/^/, make -j/}"
Makefile.inc1:.if ${.MAKEFLAGS:M-j}
Makefile.inc1:.error The buildenv target is incompatible with -j
Makefile.inc1:echo "ncpu: $$(sysctl -n hw.ncpu)${.MAKE.JOBS:S/^/, make -j/}"
Makefile.inc1: ${MAKE} -f Makefile.inc1 create-world-packages-jobs \
Makefile.inc1:.if make(create-world-packages-jobs)
Makefile.inc1:create-world-packages-jobs: .PHONY
Makefile.inc1:create-world-packages-jobs: create-world-package-${pkgname}
UPDATING: Avoid using make -j when upgrading. While generally safe,
there are
UPDATING: sometimes problems using -j to upgrade. If your upgrade fails
with
UPDATING: -j, please try again without -j. From time to time in the past
there
UPDATING: have been problems using -j with buildworld and/or
installworld. This
My 2 current hosts are old, a lot slower than I guess most developers use:
---
FreeBSD 13.0-CURRENT #14033: Sat May 11 18:48:02 CEST 2019
j...@blak.js.berklix.net:/usr/src/sys/amd64/compile/BLAK.small amd64
FreeBSD clang version 8.0.0 (tags/RELEASE_800/final 356365) (based on LLVM
8.0.0)
VT(vga): resolution 640x480
CPU: Intel(R) Core(TM)2 Duo CPU E6850 @ 3.00GHz (3000.00-MHz K8-class CPU)
Origin="GenuineIntel" Id=0x6fb Family=0x6 Model=0xf Stepping=11
Features=0xbfebfbff
Features2=0xe3fd
AMD Features=0x20100800
AMD Features2=0x1
VT-x: HLT,PAUSE
TSC: P-state invariant, performance statistics
real memory = 4294967296 (4096 MB)
avail memory = 4096159744 (3906 MB)
Event timer "LAPIC" quality 100
ACPI APIC Table:
FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs
FreeBSD/SMP: 1 package(s) x 2 core(s)
__stack_chk_init: WARNING: Initializing stack protection with non-random
cookies!
__stack_chk_init: WARNING: This severely limits the benefit of
-fstack-protector!
ioapic0: Changing APIC ID to 2
---
FreeBSD is a registered trademark of The FreeBSD Foundation.
FreeBSD 13.0-CURRENT #14033: Sat May 11 18:56:03 CEST 2019
j...@lapr.js.berklix.net:/usr/src/sys/amd64/compile/LAPR.small amd64
FreeBSD clang version 8.0.0 (tags/RELEASE_800/final 356365) (based on LLVM
8.0.0)
VT(vga): resolution 640x480
module urndis already present!
module_register: cannot register pccard/wi from kernel; already loaded from
if_wi.ko
Module pccard/wi failed to register: 17
module_register: cannot register pci/wi from kernel; already loaded from
if_wi.ko
Module pci/wi failed to register: 17
CPU: Intel(R) Core(TM) i3 CPU M 330 @ 2.13GHz (2128.42-MHz K8-class CPU)
Re: lib/libgcc_s fails on make all after make world succeeds
On 19 May 2019, at 23:29, Julian H. Stacey wrote: > > Hi curr...@freebsd.org > On current src/ on 2 boxes, I have seen the same break for a week or 2, > lib/libgcc_s fails on make all after make world succeeds, > Anyone else seen it or got ideas please ? Notes below the sample. > > ===> lib/libgcc_s (all) > building shared library libgcc_s.so.1 > cc -nodefaultlibs -Wl,--version-script=/usr/src/lib/libgcc_s/Version.map > -shared -Wl,-x -Wl,--fatal-warnings -Wl,--warn-shared-textrel -o \ > libgcc_s.so.1.full -Wl,-soname,libgcc_s.so.1 ... > -L/usr/obj/usr/src/amd64.amd64/lib/libc -lc \ > ld: error: can't create dynamic relocation R_X86_64_32S \ > against symbol: __je_sz_size2index_tab in readonly segment; \ > recompile object files with -fPIC or pass '-Wl,-z,notext' \ > to allow text relocations in the output defined in /usr/obj/usr/src/amd64.amd64/lib/libc/libc.a(jemalloc_sz.o) It looks like for some reason, it chooses to link with libc.a instead of libc.so here. Maybe your libc.so is not getting built at all, because of your environment? Or maybe you are hitting some build race where libc.a is done, but libc.so is still being built, while at the same time, libgcc_s.so.1 is being linked? There are some difficult-to-reproduce races with libgcc_s, which are sometimes also hit by CI (I think Li-Wen mentioned them multiple times now). But usually I would expect this to be "solved" by simply re-running buildworld, as the race window is very small, and you have to be quite lucky (or unlucky, depending on your point of view :) to hit it. -Dimitry signature.asc Description: Message signed with OpenPGP
Heads up for breaking drm update.
Hi Cross posting to -current and -x11. 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. A drm-???-kmod port for 5.0 drivers will be created as soon as we fixed a pretty serious vm page cache memory leak (limited to 5.0 code in ports). Once 5.0 is regarded stable, it will replace the 4.16 as default for -CURRENT (and future 12.1) (rejoice Vega graphics users:)) Until then, feel free to test with r347973+ and https://github.com/FreeBSDDesktop/kms-drm/tree/drm-v5.0 Cheers! ___ 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"
lib/libgcc_s fails on make all after make world succeeds
Hi curr...@freebsd.org On current src/ on 2 boxes, I have seen the same break for a week or 2, lib/libgcc_s fails on make all after make world succeeds, Anyone else seen it or got ideas please ? Notes below the sample. ===> lib/libgcc_s (all) building shared library libgcc_s.so.1 cc -nodefaultlibs -Wl,--version-script=/usr/src/lib/libgcc_s/Version.map -shared -Wl,-x -Wl,--fatal-warnings -Wl,--warn-shared-textrel -o \ libgcc_s.so.1.full -Wl,-soname,libgcc_s.so.1 `NM='nm' NMFLAGS='' \ lorder absvdi2.pico absvsi2.pico absvti2.pico addvdi3.pico addvsi3.pico \ addvti3.pico apple_versioning.pico ashldi3.pico ashlti3.pico \ ashrdi3.pico ashrti3.pico clear_cache.pico clzdi2.pico clzsi2.pico \ clzti2.pico cmpdi2.pico cmpti2.pico ctzdi2.pico ctzsi2.pico ctzti2.pico \ divdc3.pico divdi3.pico divmoddi4.pico divmodsi4.pico divsc3.pico \ divsi3.pico divtc3.pico divti3.pico divxc3.pico enable_execute_stack.pico \ eprintf.pico extendhfsf2.pico ffsdi2.pico ffssi2.pico ffsti2.pico \ fixdfdi.pico fixdfti.pico fixsfdi.pico fixsfti.pico fixunsdfdi.pico \ fixunsdfsi.pico fixunsdfti.pico fixunssfdi.pico fixunssfsi.pico \ fixunssfti.pico fixunsxfdi.pico fixunsxfsi.pico fixunsxfti.pico \ fixxfdi.pico fixxfti.pico floatditf.pico floatsitf.pico floattidf.pico \ floattisf.pico floattixf.pico floatunditf.pico floatunsidf.pico \ floatunsisf.pico floatuntidf.pico floatuntisf.pico floatuntixf.pico \ gcc_personality_v0.pico int_util.pico lshrdi3.pico lshrti3.pico \ moddi3.pico modsi3.pico modti3.pico muldc3.pico muldi3.pico \ mulodi4.pico mulosi4.pico muloti4.pico mulsc3.pico multi3.pico \ mulvdi3.pico mulvsi3.pico mulvti3.pico multc3.pico mulxc3.pico \ negdf2.pico negdi2.pico negsf2.pico negti2.pico negvdi2.pico \ negvsi2.pico negvti2.pico paritydi2.pico paritysi2.pico parityti2.pico \ popcountdi2.pico popcountsi2.pico popcountti2.pico powidf2.pico \ powisf2.pico powitf2.pico powixf2.pico subvdi3.pico subvsi3.pico \ subvti3.pico trampoline_setup.pico truncdfhf2.pico truncsfhf2.pico \ ucmpdi2.pico ucmpti2.pico udivdi3.pico udivmoddi4.pico udivmodsi4.pico \ udivmodti4.pico udivsi3.pico udivti3.pico umoddi3.pico umodsi3.pico \ umodti3.pico floatdidf.pico floatdisf.pico floatdixf.pico \ floatundidf.pico floatundisf.pico floatundixf.pico cpu_model.pico \ adddf3.pico addsf3.pico divdf3.pico divsf3.pico extendsfdf2.pico \ fixdfsi.pico fixsfsi.pico floatsidf.pico floatsisf.pico muldf3.pico \ mulsf3.pico subdf3.pico subsf3.pico truncdfsf2.pico comparedf2.pico \ comparesf2.pico gcc_personality_v0.pico int_util.pico Unwind-EHABI.pico \ Unwind-sjlj.pico UnwindLevel1-gcc-ext.pico UnwindLevel1.pico \ UnwindRegistersRestore.pico UnwindRegistersSave.pico libunwind.pico \ s_fabs.pico s_fabsf.pico s_fabsl.pico s_fmax.pico s_fmaxf.pico \ s_logb.pico s_logbf.pico s_scalbn.pico s_scalbnf.pico s_fmaxl.pico \ s_logbl.pico s_scalbnl.pico | tsort -q` \ -L/usr/obj/usr/src/amd64.amd64/lib/libc -lc \ ld: error: can't create dynamic relocation R_X86_64_32S \ against symbol: __je_sz_size2index_tab in readonly segment; \ recompile object files with -fPIC or pass '-Wl,-z,notext' \ to allow text relocations in the output >>> defined in /usr/obj/usr/src/amd64.amd64/lib/libc/libc.a(jemalloc_sz.o) >>> referenced by sz.h:0 \ (/usr/src/contrib/jemalloc/include/jemalloc/internal/sz.h:0) >>> jemalloc_jemalloc.o:(a0ialloc) in archive \ /usr/obj/usr/src/amd64.amd64/lib/libc/libc.a ld: error: can't create dynamic relocation R_X86_64_32 against local symbol \ in readonly segment; recompile object files with -fPIC or pass \ '-Wl,-z,notext' to allow text relocations in the output >>> defined in /usr/obj/usr/src/amd64.amd64/lib/libc/libc.a(jemalloc_jemalloc.o) >>> referenced by mutex.h:144 \ (/usr/src/contrib/jemalloc/include/jemalloc/internal/mutex.h:144) >>> jemalloc_jemalloc.o:(a0ialloc) in archive \ /usr/obj/usr/src/amd64.amd64/lib/libc/libc.a - First i thought it was my custom src/ but generic src/ breaks too. Then I did: /etc/src.conf Removed /etc/make.conf Removed env varsStripped to just PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/games:/usr/local/bin TERM=xterm TERMPATH=/etc/termcap:/usr/share/misc/termcap A new make buildworld is running on virgin generic src/ inside a script with cat .svn_revision 347964 cat .ctm_status src-cur 14046 That will take a while before I can report. Meantime I also have a 2nd box I can experiment on if people have ideas ? cat .svn_revision 347422 cat .ctm_status src-cur 14033 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
Re: FreeBSD Core Team Response to Controversial Social Media Posts
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!" -- 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 Sun, May 19, 2019 at 11:34 AM Igor Mozolevsky wrote: > On Sun, 19 May 2019 at 17:54, Warner Losh wrote: > > > > On Sun, May 19, 2019, 10:25 AM Graham Perrin wrote: > > > > > I know, it's not appropriate to find fun in a serious discussion, but > > > these six words did make me chuckle: > > > > > > > … freedom of expression … End of discussion. > > > > > > No offence intended. I was speed-reading (waiting for a browser to > > > launch) and those six words leapt out at me :-) > > > > > > > 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. 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. Warner ___ 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 Sun, May 19, 2019, 12:42 PM Igor Mozolevsky wrote: > On Sun, 19 May 2019 at 17:54, Warner Losh wrote: > > > > On Sun, May 19, 2019, 10:25 AM Graham Perrin wrote: > > > > > I know, it's not appropriate to find fun in a serious discussion, but > > > these six words did make me chuckle: > > > > > > > … freedom of expression … End of discussion. > > > > > > No offence intended. I was speed-reading (waiting for a browser to > > > launch) and those six words leapt out at me :-) > > > > > > > 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. > Additionally, the ruling from which that quote came was used to suppress dissent and imprison people for just that. It is a very shaking foundation on which to launch a censorship campaign. The main group was sentenced for yelling fire when there really was one. > ___ 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 Sun, 19 May 2019 at 17:54, Warner Losh wrote: > > On Sun, May 19, 2019, 10:25 AM Graham Perrin wrote: > > > I know, it's not appropriate to find fun in a serious discussion, but > > these six words did make me chuckle: > > > > > … freedom of expression … End of discussion. > > > > No offence intended. I was speed-reading (waiting for a browser to > > launch) and those six words leapt out at me :-) > > > > 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. -- 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: RFC w.r.t. toggling debugging on/off for mountd via a signal
On May 19, 2019 12:00:58 PM EDT, Rick Macklem wrote: > > >Cy Schubert wrote: >[lots of stuff snipped] >>Instead of syslog() calls, DTrace probes are designed for this type of >instrumentation. > >DTrace us way too obscure for me. Never used it, probably never will. >(Remember I'm the guy who still uses "ed" to edit all my text files, >because screen > editors like "vi" are too obscure for me.;-) > >If you want to volunteer to replace the syslog() calls in the patch >with DTrace stuff >(the patch is attached to PR#237860 and the calls are uses of the macro >called > LOGDEBUG) and create a simple explanation of how to enable/disable it, >feel free to do so. > >rick Sure, I can look at it when I'm back on solid ground. -- Pardon the typos and autocorrect, small keyboard in use. Cheers, Cy Schubert FreeBSD UNIX: Web: http://www.FreeBSD.org The need of the many outweighs the greed of the few. ___ 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 Sun, 19 May 2019 at 17:27, Graham Perrin wrote: > I know, it's not appropriate to find fun in a serious discussion, but > these six words did make me chuckle: > > > … freedom of expression … End of discussion. > > No offence intended. I was speed-reading (waiting for a browser to > launch) and those six words leapt out at me :-) Context is everything: for example, repeatedly punching someone in the face is generally frowned upon, yet is lauded in boxing ;-) Best, -- 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 Sun, May 19, 2019, 10:25 AM Graham Perrin wrote: > I know, it's not appropriate to find fun in a serious discussion, but > these six words did make me chuckle: > > > … freedom of expression … End of discussion. > > No offence intended. I was speed-reading (waiting for a browser to > launch) and those six words leapt out at me :-) > 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. FreeBSD is also an international group and while we share many norms, there are also surprising differences in them or in the extent to which people think our community norms should be policed in contexts only tangentially related to the project. It's really quite a thorny problem to craft a response to that is both meaningful and would enjoy the support of most of this diverse community in whose name the response is created. Warner Wishing you all a peaceful end to the weekend, > Graham > ___ > 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: FreeBSD Core Team Response to Controversial Social Media Posts
I know, it's not appropriate to find fun in a serious discussion, but these six words did make me chuckle: > … freedom of expression … End of discussion. No offence intended. I was speed-reading (waiting for a browser to launch) and those six words leapt out at me :-) Wishing you all a peaceful end to the weekend, Graham ___ 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: RFC w.r.t. toggling debugging on/off for mountd via a signal
Cy Schubert wrote: [lots of stuff snipped] >Instead of syslog() calls, DTrace probes are designed for this type of >instrumentation. DTrace us way too obscure for me. Never used it, probably never will. (Remember I'm the guy who still uses "ed" to edit all my text files, because screen editors like "vi" are too obscure for me.;-) If you want to volunteer to replace the syslog() calls in the patch with DTrace stuff (the patch is attached to PR#237860 and the calls are uses of the macro called LOGDEBUG) and create a simple explanation of how to enable/disable it, feel free to do so. rick ___ 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: RFC w.r.t. toggling debugging on/off for mountd via a signal
On May 19, 2019 4:55:01 AM EDT, Konstantin Belousov wrote: >On Sun, May 19, 2019 at 02:47:10AM +, Rick Macklem wrote: >> Alan Somers wrote: >> >On Sat, May 18, 2019 at 7:59 PM Rick Macklem >wrote: >> >> >> >> Hi, >> >> >> >> I've been working with Peter Errikson on a patch for mountd that >adds a new option >> >> for incremental updating of exports. This seems to be helping a >lot w.r.t. performance >> >> on an NFS server with lots (1+) of exported file systems. >> >> >> >> I have debug syslog() calls in the code, which I/Peter think would >be worth keeping >> >> in the production code in case someone runs into problems with >this new option. >> >> >> >> As such, I'd like to have the code compiled in by default (not >only if DEBUG is defined, >> >> as mountd.c has now). I also was thinking it would be nice if the >daemon didn't need >> >> to be restarted to enable/disable the debugging output, since that >breaks NFS >> >> mounting during the restart. >> >> >> >> So, I was thinking of having the debugging output toggled on/off >via SIGUSR1. >> >> >> >> What do you think of this idea? >> >> Any other/better ways to do this? >> >> Also, would LOG_DAEMON and LOG_DEBUG sound like the correct >facility and >> >> priority for theses syslog() calls? >> >> >> >> Thanks in advance for any comments, rick >> > >> >If the debug messages aren't so verbose that they'll slow down >> >syslogd, then you can just leave them enabled all the time. syslogd >> >will filter them. However, if they're super-verbose then SIGUSR1 >> >sounds reasonable. I can't think of another daemon with runtime >> >selectable logging verbosity like that. >> Yes, these are pretty chatty. 5-10 lines for each entry in an exports >file. >> Multiply that times the number of entries. (Peter's servers are >between 2 >> to 72000+ file systems. Not sure if he has multiple entries/file >system.) >> >> To give you a clue, without this patch, it can take 20sec->over 1min >to reload them >> when mountd gets a SIGHUP. >> >> It's just that the export file handling code is pretty convoluted, so >I think the patch >> is ok, but I won't be too surprised if someone finds a problem. > >Instead of toggling the debugging by SIGUSR1, you can make the daemon >to try to open some file by receiving the normal reload signal, e.g. >/var/run/mountd.debug. If the file is present, the debugging is >enabled. >The advantage is that the user knows what is the debugging state, >instead >of requiring to count the number of sent SIGUSR1's. > >More, in traditions of malloc(3), /var/run/mountd.debug could be a >symlink, >which is read and interpreted as some options controlling the debug. >___ >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" Instead of syslog() calls, DTrace probes are designed for this type of instrumentation. -- Pardon the typos and autocorrect, small keyboard in use. Cheers, Cy Schubert FreeBSD UNIX: Web: http://www.FreeBSD.org The need of the many outweighs the greed of the few. ___ 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: RFC w.r.t. toggling debugging on/off for mountd via a signal
On Sun, May 19, 2019 at 02:47:10AM +, Rick Macklem wrote: > Alan Somers wrote: > >On Sat, May 18, 2019 at 7:59 PM Rick Macklem wrote: > >> > >> Hi, > >> > >> I've been working with Peter Errikson on a patch for mountd that adds a > >> new option > >> for incremental updating of exports. This seems to be helping a lot w.r.t. > >> performance > >> on an NFS server with lots (1+) of exported file systems. > >> > >> I have debug syslog() calls in the code, which I/Peter think would be > >> worth keeping > >> in the production code in case someone runs into problems with this new > >> option. > >> > >> As such, I'd like to have the code compiled in by default (not only if > >> DEBUG is defined, > >> as mountd.c has now). I also was thinking it would be nice if the daemon > >> didn't need > >> to be restarted to enable/disable the debugging output, since that breaks > >> NFS > >> mounting during the restart. > >> > >> So, I was thinking of having the debugging output toggled on/off via > >> SIGUSR1. > >> > >> What do you think of this idea? > >> Any other/better ways to do this? > >> Also, would LOG_DAEMON and LOG_DEBUG sound like the correct facility and > >> priority for theses syslog() calls? > >> > >> Thanks in advance for any comments, rick > > > >If the debug messages aren't so verbose that they'll slow down > >syslogd, then you can just leave them enabled all the time. syslogd > >will filter them. However, if they're super-verbose then SIGUSR1 > >sounds reasonable. I can't think of another daemon with runtime > >selectable logging verbosity like that. > Yes, these are pretty chatty. 5-10 lines for each entry in an exports file. > Multiply that times the number of entries. (Peter's servers are between 2 > to 72000+ file systems. Not sure if he has multiple entries/file system.) > > To give you a clue, without this patch, it can take 20sec->over 1min to > reload them > when mountd gets a SIGHUP. > > It's just that the export file handling code is pretty convoluted, so I think > the patch > is ok, but I won't be too surprised if someone finds a problem. Instead of toggling the debugging by SIGUSR1, you can make the daemon to try to open some file by receiving the normal reload signal, e.g. /var/run/mountd.debug. If the file is present, the debugging is enabled. The advantage is that the user knows what is the debugging state, instead of requiring to count the number of sent SIGUSR1's. More, in traditions of malloc(3), /var/run/mountd.debug could be a symlink, which is read and interpreted as some options controlling the debug. ___ 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"
