Re: deep packet inspection over no TLS/SSL traffic
On 2022-05-09, Riccardo Giuntoli wrote: > I've found a distfiles on the fr openbsd mirror: > > https://ftp.fr.openbsd.org/pub/OpenBSD/distfiles/ndpi-4.2.tar.gz > > Someone try it? This is used by ntopng, we don't have anything to use this to make packet forwarding decisions (anyway, by the time you have used DPI to detect the protocol, it is too late to make a decision on packet routing). Also, I have found it to be a bit crashy. It's not so bad for ntopng if you're just using it to identify a network problem etc, but doesn't seem good as a continuously-running thing. >> On Sunday, May 8, 2022, Riccardo Giuntoli wrote: >> >> > Hello there, I've got a little wireless service provider where the edge >> > connect to different VPS providers in many geographic locations. One of >> > them, based in US, is applying DMCA doing DPI above no encrypted traffic. This seems complete overkill from the provider, I would replace them.
Re: deep packet inspection over no TLS/SSL traffic
On 2022/05/09 10:46, Riccardo Giuntoli wrote: > Yes I know. With rdomains and pair it would be nice to write a daemon > that inspect L7 search for bittorrent identification and take action > above those packets. > Yes. DMCA is a complete overkill. Vultr applies it. When business will It doesn't make sense though, DMCA relates to hosted content, you aren't hosting on the VPS though, right? If I understand correctly you just route through it? > grow I will host in some data center a pair of servers and do vmd > machines. But I've got to register for RIPE, get an IPv4 and IPv6 > class, and so on. It's a temporary solution. For now I'm using ndpi on > linux and changing DSCP. If you're in Europe, running this service via US-territory VPS seems a legal minefield and a bad idea both for network performance and privacy related reasons.
Re: Modern RFC3442 (Classless DHCP Static Routes)
On 2022-05-09, Stuart Henderson wrote: >>> >>> That doesn't seem like correct behavior (the ISC version certainly >>> offers both). Both options should be sent if configured, it's up to >>> the client to properly handle this. >>> Clients that are rfc3442 compliant will install the option 121 routes, >>> clients that are not rfc3442 compliant will ignore option 121 and >>> install the gateway supplied by option 3. If dhcpd doesn't hand out >>> option 3 when option 121 is configured then clients that are not >>> rfc3442 compliant will not receive a gateway address. >> >>> >> I fully agree, I was very surprised when I discovered this >> behaviour. But I haven't chased it down why this is. > > It was done to work-around broken clients: > > https://github.com/openbsd/src/commit/3f461432d6a77eea41f084ef892403cacc2ee370 ...so the correct configuration is clear: list both a 0.0.0.0/0 classless route and "option routers", and it should work for all cases.
Re: Atom code environment
jeanfrancois writes: Specifically the multiline work is very helpful that ought to be enough. Have I missed other editors with this ? There are extensions for both Vim and Emacs for this, e.g.: https://github.com/mg979/vim-visual-multi https://github.com/magnars/multiple-cursors.el Alexis.
Re: deep packet inspection over no TLS/SSL traffic
Yes I know. With rdomains and pair it would be nice to write a daemon that inspect L7 search for bittorrent identification and take action above those packets. Yes. DMCA is a complete overkill. Vultr applies it. When business will grow I will host in some data center a pair of servers and do vmd machines. But I've got to register for RIPE, get an IPv4 and IPv6 class, and so on. It's a temporary solution. For now I'm using ndpi on linux and changing DSCP. On Mon, May 9, 2022 at 10:18 AM Stuart Henderson wrote: > On 2022-05-09, Riccardo Giuntoli wrote: > > I've found a distfiles on the fr openbsd mirror: > > > > https://ftp.fr.openbsd.org/pub/OpenBSD/distfiles/ndpi-4.2.tar.gz > > > > Someone try it? > > This is used by ntopng, we don't have anything to use this to make > packet forwarding decisions (anyway, by the time you have used DPI > to detect the protocol, it is too late to make a decision on packet > routing). > > Also, I have found it to be a bit crashy. It's not so bad for ntopng > if you're just using it to identify a network problem etc, but doesn't > seem good as a continuously-running thing. > > >> On Sunday, May 8, 2022, Riccardo Giuntoli wrote: > >> > >> > Hello there, I've got a little wireless service provider where the > edge > >> > connect to different VPS providers in many geographic locations. One > of > >> > them, based in US, is applying DMCA doing DPI above no encrypted > traffic. > > This seems complete overkill from the provider, I would replace them. > > > -- Name: Riccardo Giuntoli Email: tag...@gmail.com Location: sant Pere de Ribes, BCN, Spain PGP Key: 0x67123739 PGP Fingerprint: CE75 16B5 D855 842FAB54 FB5C DDC6 4640 6712 3739 Key server: hkp://wwwkeys.eu.pgp.net
Re: Atom code environment
On Monday, May 9, 2022, Alexis wrote: > > jeanfrancois writes: > > Specifically the multiline work is very helpful that ought to be >> enough. Have I missed other editors with this ? >> > > There are extensions for both Vim and Emacs for this, e.g.: > > https://github.com/mg979/vim-visual-multi > > https://github.com/magnars/multiple-cursors.el > > > Alexis. > > I like/use vim very much, but also geany sometimes -- Atenciosamente, Fabio Martins (+5521) 97914-8106 (Signal) https://www.linkedin.com/in/fabio1337br/
Re: Modern RFC3442 (Classless DHCP Static Routes)
On 2022-05-06, Florian Obser wrote: > On 2022-05-06 10:28 -04, Sonic wrote: >> On Fri, May 6, 2022 at 7:18 AM Florian Obser wrote: >>> Also, dhcpd(8) does not even hand out option 3 when option 121 is >>> configured. >> >> That doesn't seem like correct behavior (the ISC version certainly >> offers both). Both options should be sent if configured, it's up to >> the client to properly handle this. >> Clients that are rfc3442 compliant will install the option 121 routes, >> clients that are not rfc3442 compliant will ignore option 121 and >> install the gateway supplied by option 3. If dhcpd doesn't hand out >> option 3 when option 121 is configured then clients that are not >> rfc3442 compliant will not receive a gateway address. > >> > I fully agree, I was very surprised when I discovered this > behaviour. But I haven't chased it down why this is. It was done to work-around broken clients: https://github.com/openbsd/src/commit/3f461432d6a77eea41f084ef892403cacc2ee370
Re: Modern RFC3442 (Classless DHCP Static Routes)
On Mon, May 9, 2022 at 6:03 AM Stuart Henderson wrote: > On 2022-05-09, Stuart Henderson wrote: > > ...so the correct configuration is clear: list both a 0.0.0.0/0 > classless route and "option routers", and it should work for all > cases. Yes. The server sends both, the clients that handle option 121 use its data and ignore option 3, the clients that do not handle option 121 ignore it and use the data in option 3 (which may offer a different default route).
Re: deep packet inspection over no TLS/SSL traffic
Correct it simple pass through interfaces: root@arnuwanda:/etc# ipsecctl -sa | grep 94.72.143.163 flow esp in proto gre from 94.72.143.163 to 65.20.98.172 peer 94.72.143.163 srcid ASN1_DN//C=ES/ST=Madrid/L=Madrid/O=Telecom Lobby/OU=VPNC/CN= choopa.telecomlobby.com dstid ASN1_DN//C=BG/ST=Lovech/L=Troyan/O=Telecom Lobby/OU=VPNC/CN=bg.telecomlobby.com type require flow esp out proto gre from 65.20.98.172 to 94.72.143.163 peer 94.72.143.163 srcid ASN1_DN//C=ES/ST=Madrid/L=Madrid/O=Telecom Lobby/OU=VPNC/CN=choopa.telecomlobby.com dstid ASN1_DN//C=BG/ST=Lovech/L=Troyan/O=Telecom Lobby/OU=VPNC/CN= bg.telecomlobby.com type require esp transport from 65.20.98.172 to 94.72.143.163 spi 0x7a783fbb enc chacha20-poly1305 esp transport from 94.72.143.163 to 65.20.98.172 spi 0xa0fd6c20 enc chacha20-poly1305 root@arnuwanda:/etc# ifconfig gre3 gre3: flags=8051 mtu 1392 description: bg.telecomlobby.com index 15 priority 0 llprio 6 keepalive: timeout 5 count 2 encap: vnetid none txprio payload rxprio packet groups: gre status: active tunnel: inet 65.20.98.172 --> 94.72.143.163 ttl 64 nodf ecn inet 10.10.9.81 --> 10.10.9.82 netmask 0xfffc root@arnuwanda:/etc# Next go out to the internet following default rdomain 0: root@arnuwanda:/etc# route -n show | grep default | head -n 1 default65.20.98.1 UGS 12 835576762 - 8 vio0 root@arnuwanda:/etc# Vultr has physical sites in all europe but they apply DMCA worldwide! On Mon, May 9, 2022 at 11:22 AM Stuart Henderson wrote: > On 2022/05/09 10:46, Riccardo Giuntoli wrote: > > Yes I know. With rdomains and pair it would be nice to write a daemon > > that inspect L7 search for bittorrent identification and take action > > above those packets. > > Yes. DMCA is a complete overkill. Vultr applies it. When business will > > It doesn't make sense though, DMCA relates to hosted content, you aren't > hosting on the VPS though, right? If I understand correctly you just > route through it? > > > grow I will host in some data center a pair of servers and do vmd > > machines. But I've got to register for RIPE, get an IPv4 and IPv6 > > class, and so on. It's a temporary solution. For now I'm using ndpi on > > linux and changing DSCP. > > If you're in Europe, running this service via US-territory VPS seems a > legal minefield and a bad idea both for network performance and privacy > related reasons. > > -- Name: Riccardo Giuntoli Email: tag...@gmail.com Location: sant Pere de Ribes, BCN, Spain PGP Key: 0x67123739 PGP Fingerprint: CE75 16B5 D855 842FAB54 FB5C DDC6 4640 6712 3739 Key server: hkp://wwwkeys.eu.pgp.net
WhatsApp Web in Chromium under OpenBSD 7.1
I'm not able to use WhatsApp Web in Chromium under OpenBSD 7.1 (amd64), no login page appears. Is there something bad in my configuration or is this a known problem? Thanks.
Re: WhatsApp Web in Chromium under OpenBSD 7.1
At home, once I reconnected to my own wifi the whatsapp QR reader login came up. After that the linking of Chrome on OpenBSD device went as expected. Before the reconnection to wifi there was no login whatsoever. Good Luck.
hw.perfpolicy behavior on desktop/server
Hi Guys, I'm running -current. Recently I noticed (not sure when it changed) that my CPU is not throttling anymore. The `hw.perfpolicy` is set to auto and `hw.setperf` is always at 100%. I red that there was a change in 7.1: - Changed the power management sysctl(8) hw.perfpolicy to "auto" at startup, defaulting to 100% performance with AC power connected and using the auto algorithm when on battery. So, my question is how I can change that behavior so the throttling is working again? Thanks in advance, Atanas ~$ sysctl hw hw.machine=amd64 hw.model=Intel(R) Xeon(R) CPU E3-1270 v3 @ 3.50GHz hw.ncpu=8 ... hw.cpuspeed=3501 hw.setperf=100 hw.vendor=Supermicro hw.product=X10SLH-F/X10SLM+-F hw.version=0123456789 hw.serialno=0123456789 hw.uuid=----0cc47a0b76d4 hw.physmem=34300481536 hw.usermem=34300465152 hw.ncpufound=8 hw.allowpowerdown=1 hw.perfpolicy=auto hw.smt=0 hw.ncpuonline=4 hw.power=1 Here is a dmesg: OpenBSD 7.1-current (GENERIC.MP) #502: Sat May 7 21:46:16 MDT 2022 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 34300481536 (32711MB) avail mem = 33243611136 (31703MB) random: good seed from bootblocks mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xec280 (37 entries) bios0: vendor American Megatrends Inc. version "3.4" date 01/21/2021 bios0: Supermicro X10SLH-F/X10SLM+-F acpi0 at bios0: ACPI 5.0 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP APIC FPDT FIDT SSDT SSDT SSDT SSDT SSDT MCFG PRAD HPET SSDT SSDT SPMI DMAR EINJ ERST HEST BERT acpi0: wakeup devices PEG0(S4) PEGP(S4) PEG1(S4) PEGP(S4) PEG2(S4) PEGP(S4) RP01(S4) PXSX(S4) RP02(S4) PXSX(S4) RP03(S4) PXSX(S4) RP04(S4) PXSX(S4) RP05(S4) PXSX(S4) [...] acpitimer0 at acpi0: 3579545 Hz, 24 bits acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel(R) Xeon(R) CPU E3-1270 v3 @ 3.50GHz, 3500.70 MHz, 06-3c-03 cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,PERF,ITSC,FSGSBASE,TSC_ADJUST,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,SRBDS_CTRL,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN cpu0: 256KB 64b/line 8-way L2 cache cpu0: smt 0, core 0, package 0 mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges cpu0: apic clock running at 99MHz cpu0: mwait min=64, max=64, C-substates=0.2.1.2.4, IBE cpu1 at mainbus0: apid 2 (application processor) cpu1: Intel(R) Xeon(R) CPU E3-1270 v3 @ 3.50GHz, 3500.00 MHz, 06-3c-03 cpu1: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,PERF,ITSC,FSGSBASE,TSC_ADJUST,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,SRBDS_CTRL,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN cpu1: 256KB 64b/line 8-way L2 cache cpu1: smt 0, core 1, package 0 cpu2 at mainbus0: apid 4 (application processor) cpu2: Intel(R) Xeon(R) CPU E3-1270 v3 @ 3.50GHz, 3500.00 MHz, 06-3c-03 cpu2: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,PERF,ITSC,FSGSBASE,TSC_ADJUST,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,SRBDS_CTRL,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN cpu2: 256KB 64b/line 8-way L2 cache cpu2: smt 0, core 2, package 0 cpu3 at mainbus0: apid 6 (application processor) cpu3: Intel(R) Xeon(R) CPU E3-1270 v3 @ 3.50GHz, 3500.00 MHz, 06-3c-03 cpu3: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,PERF,ITSC,FSGSBASE,TSC_ADJUST,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,SRBDS_CTRL,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN cpu3: 256KB 64b/line 8-way L2 cache cpu3: smt 0, core 3, package 0 cpu4 at mainbus0: apid 1 (application processor) cpu4: Intel(R) Xeon(R) CPU E3-1270 v3 @ 3.50GHz, 3500.00 MHz, 06-3c-03 cpu4:
Re: hw.perfpolicy behavior on desktop/server
On 2022-05-09, Atanas Vladimirov wrote:
> Hi Guys,
>
> I'm running -current.
> Recently I noticed (not sure when it changed) that my CPU is not
> throttling anymore. The `hw.perfpolicy` is set to auto and `hw.setperf`
> is always at 100%. I red that there was a change in 7.1:
>
> - Changed the power management sysctl(8) hw.perfpolicy to "auto" at
> startup, defaulting to 100% performance with AC power connected and
> using the auto algorithm when on battery.
>
> So, my question is how I can change that behavior so the throttling is
> working again?
Currently, you can either set it manually to low speed (hw.perfpolicy=manual,
hw.setperf=0), modify the kernel (e.g. with the diff below), or use obsdfreqd
from
packages. The latter is only in -current packages not 7.1, but it could be built
from ports.
Index: sched_bsd.c
===
RCS file: /cvs/src/sys/kern/sched_bsd.c,v
retrieving revision 1.70
diff -u -p -r1.70 sched_bsd.c
--- sched_bsd.c 30 Oct 2021 23:24:48 - 1.70
+++ sched_bsd.c 9 May 2022 17:13:10 -
@@ -525,7 +525,6 @@ int perfpolicy = PERFPOL_AUTO;
void setperf_auto(void *);
struct timeout setperf_to = TIMEOUT_INITIALIZER(setperf_auto, NULL);
-extern int hw_power;
void
setperf_auto(void *v)
@@ -544,11 +543,6 @@ setperf_auto(void *v)
if (cpu_setperf == NULL)
return;
- if (hw_power) {
- speedup = 1;
- goto faster;
- }
-
if (!idleticks)
if (!(idleticks = mallocarray(ncpusfound, sizeof(*idleticks),
M_DEVBUF, M_NOWAIT | M_ZERO)))
@@ -583,7 +577,6 @@ setperf_auto(void *v)
downbeats = 5;
if (speedup && perflevel != 100) {
-faster:
perflevel = 100;
cpu_setperf(perflevel);
} else if (!speedup && perflevel != 0 && --downbeats <= 0) {
Re: WhatsApp Web in Chromium under OpenBSD 7.1
On Mon, May 09, 2022 at 01:16:15PM +0200, Federico Giannici wrote: > I'm not able to use WhatsApp Web in Chromium under OpenBSD 7.1 (amd64), no > login page appears. > Is there something bad in my configuration or is this a known problem? > Thanks. That's because by default WebAssembly is not enabled in Chromium (I found out this was the culprit using the Developer Console, there was some error message). Starting Chromium with ENABLE_WASM=1 in your environment will make it work. Caspar
Re: WhatsApp Web in Chromium under OpenBSD 7.1
On 5/9/22 18:40, Caspar Schutijser wrote: On Mon, May 09, 2022 at 01:16:15PM +0200, Federico Giannici wrote: I'm not able to use WhatsApp Web in Chromium under OpenBSD 7.1 (amd64), no login page appears. Is there something bad in my configuration or is this a known problem? Thanks. That's because by default WebAssembly is not enabled in Chromium (I found out this was the culprit using the Developer Console, there was some error message). Starting Chromium with ENABLE_WASM=1 in your environment will make it work. Caspar OK, it worked! Now the question is: why WebAssembly is disabled by default under OpenBSD? Is there any contraindication to activate it? Thanks.
Re: hw.perfpolicy behavior on desktop/server
On 2022-05-09 20:17, Stuart Henderson wrote: Currently, you can either set it manually to low speed (hw.perfpolicy=manual, hw.setperf=0), modify the kernel (e.g. with the diff below), or use obsdfreqd from packages. The latter is only in -current packages not 7.1, but it could be built from ports. Thanks, Stuart! `obsdfreqd` is what I was looking for. It works very well! Best wishes, Atanas
Re: WhatsApp Web in Chromium under OpenBSD 7.1
> Now the question is: why WebAssembly is disabled by default under OpenBSD? > Is there any contraindication to activate it? do you want to run someone else's binary on your browser? by disabling WebAssembly, the browser will have less shit running to handle therefore decreases the attack surface. i prefer enabling it carefully and manually where appropriate, if no alternative!
Re: Modern RFC3442 (Classless DHCP Static Routes)
Dealing with broken clients can be handled with separate groups or even "deny booting;" instead of breaking the dhcp server.
Re: WhatsApp Web in Chromium under OpenBSD 7.1
On Mon, May 09, 2022 at 06:50:16PM +0200, Federico Giannici wrote: > On 5/9/22 18:40, Caspar Schutijser wrote: > > On Mon, May 09, 2022 at 01:16:15PM +0200, Federico Giannici wrote: > > > I'm not able to use WhatsApp Web in Chromium under OpenBSD 7.1 (amd64), no > > > login page appears. > > > Is there something bad in my configuration or is this a known problem? > > > Thanks. > > > > That's because by default WebAssembly is not enabled in Chromium (I > > found out this was the culprit using the Developer Console, there was > > some error message). > > > > Starting Chromium with ENABLE_WASM=1 in your environment will > > make it work. > > > > Caspar > > > > OK, it worked! > > Now the question is: why WebAssembly is disabled by default under OpenBSD? > Is there any contraindication to activate it? > > Thanks. WASM is unusable unless you have user limits set to near infinity, and having it enabled by default actively broke websites that would have otherwise worked without it. https://marc.info/?l=openbsd-ports=154376428820247=2 IMO it was disabled for good reason. An environment variable exists to override it for the few sites that need it. I kind of wish this had also happened in Firefox, but that may soon go in another direction.. -Bryan.
Re: OpenBSD ports require xbase set - still true?
The people who do the work make the decisions. Steffen Nurpmeso wrote: > Hello. > > Just a rant, not for ports@. > I am installing OpenBSD 7.1 right now; this is only a VM, and > i want to create / manage ports there. > Until now whenever i wanted to do this i had to install xbase, > otherwise the port makefile complained some. (I am afraid i have > forgotten the details.) Is this still true? I know i once > "hacked" it because for my ports it really was not needed, at > least not really. Hm. I think i even posted about this quite > some years ago. I have installed xbase now, maybe i even will use > it (OpenBSD X is always super proper, i cheered this often; CRUX > also, but of course not base-integrated). If not then 55 MB for > a file is quite an act. > > --steffen > | > |Der Kragenbaer,The moon bear, > |der holt sich munter he cheerfully and one by one > |einen nach dem anderen runter wa.ks himself off > |(By Robert Gernhardt) >
Re: OpenBSD ports require xbase set - still true?
I looked very closely, it started like this "Just a rant" And I knew the email was coming from a self-centered individual who is unhappy with the entirely volunteer work done by others, yet not unhappy enough to quit OpenBSD and switch to another operating sytem where there will be similar unhappiness because those other systems also won't do precisely what you want. Your email is not appropriate. If you don't like OpenBSD, use something else, because noone deserves an email which starts with those 3 words you chose, and the following complaint is such horseshit in a world where disk drives are cheap. I started OpenBSD a quarter of a century ago by spending $3500 for a 300MB drive and ate noodles and tuna for many months to make up for that, and we do not live in a world where you get to moan about 55MB, relative to whatever it takes to ease the complicate work undertaken by the ports developers. In short, Steffen, you need to shut up. Steffen Nurpmeso wrote: > Theo de Raadt wrote in > <36104.1652132...@cvs.openbsd.org>: > |The people who do the work make the decisions. > > Ok i will at least look what i was talking about. > > |Steffen Nurpmeso wrote: > | > |> Hello. > |> > |> Just a rant, not for ports@. > |> I am installing OpenBSD 7.1 right now; this is only a VM, and > |> i want to create / manage ports there. > |> Until now whenever i wanted to do this i had to install xbase, > |> otherwise the port makefile complained some. (I am afraid i have > |> forgotten the details.) Is this still true? I know i once > |> "hacked" it because for my ports it really was not needed, at > |> least not really. Hm. I think i even posted about this quite > |> some years ago. I have installed xbase now, maybe i even will use > |> it (OpenBSD X is always super proper, i cheered this often; CRUX > |> also, but of course not base-integrated). If not then 55 MB for > |> a file is quite an act. > |> > |> --steffen > |>| > |>|Der Kragenbaer,The moon bear, > |>|der holt sich munter he cheerfully and one by one > |>|einen nach dem anderen runter wa.ks himself off > |>|(By Robert Gernhardt) > |> > --End of <36104.1652132...@cvs.openbsd.org> > > --steffen > | > |Der Kragenbaer,The moon bear, > |der holt sich munter he cheerfully and one by one > |einen nach dem anderen runter wa.ks himself off > |(By Robert Gernhardt) >
Re: Firefox and stuttering USB audio
On 5/6/22 10:29, Courtney wrote: Hello all, [snip] * Setting dom.ipc.processCount to a lower number in about:config * Muddled with sndiod -b and -z flags * Set softdep,noatime for my different partitions in fstab (NVMe drive) * Tried with/without SMT (Intel 10700k) * Set some sysctl flags: [snip] uaudio0: play xfer, err = 6 This may be a driver bug, but before anything else, check the output of apm(1) for your performance mode.
Re: OpenBSD ports require xbase set - still true?
On 2022-05-09, Steffen Nurpmeso wrote: > Until now whenever i wanted to do this i had to install xbase, > otherwise the port makefile complained some. (I am afraid i have > forgotten the details.) Is this still true? Yes. We don't particularly want to deal with reports of build failures or worse builds which succeeded but are missing features, from people who have decided that they don't need to install all sets but e.g. didn't realise that some non-X software uses freetype or fontconfig (or in the past before it moved from xbase to base, expat). Having this as an error certainly seemed to help.
OpenBSD ports require xbase set - still true?
Hello. Just a rant, not for ports@. I am installing OpenBSD 7.1 right now; this is only a VM, and i want to create / manage ports there. Until now whenever i wanted to do this i had to install xbase, otherwise the port makefile complained some. (I am afraid i have forgotten the details.) Is this still true? I know i once "hacked" it because for my ports it really was not needed, at least not really. Hm. I think i even posted about this quite some years ago. I have installed xbase now, maybe i even will use it (OpenBSD X is always super proper, i cheered this often; CRUX also, but of course not base-integrated). If not then 55 MB for a file is quite an act. --steffen | |Der Kragenbaer,The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt)
Re: time drift in OpenBSD in proxmox (qemu-kvm) guest
Stuart Henderson wrote in
:
|On 2022/04/15 22:02, Tom Smyth wrote:
...
|Thanks for the suggestions - since the change I made in the last mail
|("I've changed mine to acpihpet0 and it seems much happier", i.e. setting
|the kern.timecounter.hardware sysctl to acpihpet0, based on Stefan's
|pointer) the time has stayed in sync.
|
|The machine is on what looks like the closest thing to "power saving"
|(option in machine config is "best experience") - since I leave this
|machine turned on, at around 0.30GBP/kWh power cost, and often with
|only ~50% of power generation where I live being low carbon unless
|it's particularly windy (https://www.carbonintensity.org.uk/#regional,
|https://www.gridwatch.templar.co.uk/) I'd like to keep it like that
|if possible :)
That is great.
But i find the focusing on Carbon quite misleading, as it is about
biodiversity and more, as possibly HM Prince Charles would say :)
Anyhow looking at this western-eye-polished mess at [2] i still
find that Germany will now buy liquid gas from the dirtiest
country of the world, that USA and Canada are in the top ten of
the dirtiest and have passed their overshoot day almost two months
ago, that Germany did so last week and that U.K. will in ten days.
[1] https://www.footprintnetwork.org/our-work/earth-overshoot-day/
[2]
https://www.overshootday.org/content/uploads/2022/04/Country_Overshoot_Days_2022_v2_sm.jpg
--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter he cheerfully and one by one
|einen nach dem anderen runter wa.ks himself off
|(By Robert Gernhardt)
Re: OpenBSD ports require xbase set - still true?
Theo de Raadt wrote in <36104.1652132...@cvs.openbsd.org>: |The people who do the work make the decisions. Ok i will at least look what i was talking about. |Steffen Nurpmeso wrote: | |> Hello. |> |> Just a rant, not for ports@. |> I am installing OpenBSD 7.1 right now; this is only a VM, and |> i want to create / manage ports there. |> Until now whenever i wanted to do this i had to install xbase, |> otherwise the port makefile complained some. (I am afraid i have |> forgotten the details.) Is this still true? I know i once |> "hacked" it because for my ports it really was not needed, at |> least not really. Hm. I think i even posted about this quite |> some years ago. I have installed xbase now, maybe i even will use |> it (OpenBSD X is always super proper, i cheered this often; CRUX |> also, but of course not base-integrated). If not then 55 MB for |> a file is quite an act. |> |> --steffen |>| |>|Der Kragenbaer,The moon bear, |>|der holt sich munter he cheerfully and one by one |>|einen nach dem anderen runter wa.ks himself off |>|(By Robert Gernhardt) |> --End of <36104.1652132...@cvs.openbsd.org> --steffen | |Der Kragenbaer,The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt)
Re: deep packet inspection over no TLS/SSL traffic
On May 9, 2022 2:16:51 AM MDT, Stuart Henderson wrote: > SNIP > (anyway, by the time you have used DPI >to detect the protocol, it is too late to make a decision on packet >routing). SNIP Well, not necessarily true, imagine GCHQ ... Just saying Hope you are doing well, diana
Re: deep packet inspection over no TLS/SSL traffic
I know. But yes it is to not get provider fees or shutdown. When I'll have more fees from my service, a rural wireless service provider, I'll acquire space in some IXP and then mount a vmd based host. >Hope you are doing well, Fighting hard because I'm a victim of human trade. Kindly regards, On Tue, May 10, 2022 at 2:17 AM deich...@placebonol.com < deich...@placebonol.com> wrote: > > > On May 9, 2022 2:16:51 AM MDT, Stuart Henderson > wrote: > > > SNIP > > (anyway, by the time you have used DPI > >to detect the protocol, it is too late to make a decision on packet > >routing). > SNIP > > Well, not necessarily true, imagine GCHQ ... > Just saying > > Hope you are doing well, > diana > > -- Name: Riccardo Giuntoli Email: tag...@gmail.com Location: sant Pere de Ribes, BCN, Spain PGP Key: 0x67123739 PGP Fingerprint: CE75 16B5 D855 842FAB54 FB5C DDC6 4640 6712 3739 Key server: hkp://wwwkeys.eu.pgp.net
