unsubscribing

[leo_tck]

zeur here.

PSA: me's unsubscribing, again. theo dragged me here and I'm not
comfortable being here for long. Please Cc me in any matter that you
think concerns me. Thanks, folks!

--zeurkous.

-- 
Friggin' Machines!

FU: RE: Why is no one discussing this anymore?

[leo_tck]

zeur here.

I now[0] see that a whole bunch of lists were Cc'd, and while I'm not
sorry for not preserving the Ccs, I realize that you might not have been
addressing us, misc@OpenBSD.org.

I still think my point holds, though. This should be a matter of great
concern for OpenBSD, like it is to just about every other project
relying on licensed code, "open" or not.

--zeur.

[0] post-coffee-intake =) 

> This whole discussion is best served elsewhere.

-- 
Friggin' Machines!

RE: Why is no one discussing this anymore?

[leo_tck]

zeur here.

> This whole discussion is best served elsewhere.

Yeah, comfortably away from an affected project, for sure! Remember what
happened w/ ipf(4)? Now imagine peope getting angry at theo (not an
uncommon thing, given his behaviour), and retaliating by revoking their
license to crucial portions of kern_proc, or their port's locore?

What if the drm(4) developers would suddenly throw a hissy fit and
decree that it may only be used in lunix, or that it be placed under a
restrictive license? The copyright on some code is helt by corporations
(for-profit or otherwise) -- what if *THEY* decide to change their
policy? 

These are real issues.

--zeurkous.

-- 
Friggin' Machines!

RE: Yes: The linux devs can rescind their license grant. GPLv2 is a bare license and is revocable by the grantor.

[leo_tck]

zeur here.

> NOTHING to hold them to a promise THEY NEVER MADE.

This is what I've suspected for a long time -- the only solution appears
to be the public domain. For jurisdictions were the public domain is not
legally recognized (I've been told they exist), a workaround /may/ be to
not attach one's name to one's work.

IANAL.

--zeurkous.

-- 
Friggin' Machines!

www/lynx

[leo_tck]

zeur here.

Just a note: mebuilt lynx few days ago, and found to me dismay that the
'external editor' functionality had been disabled in favour of pledges.

That was the start of the story. The middle doesn't really matter here,
but I ended up building it w/ the patches/ dir in rather pristine
condition...

--zeurkous.

-- 
Friggin' Machines!

devel/cmake

[leo_tck]

zeur here.

I'm watching cmake build. I'm not sure whether to be amused or
horrified.
--zeur.

-- 
Friggin' Machines!

RE: patch: ps(1) broaden 'TT' field by 2 chars

[leo_tck]

zeur here!

Haai,

> I'm afraid that you are being extremely discourteous, to put it kindly.

theo started xD He even took my partner's complaint about his (theo's)
attitude public. Call me as childish as theo, but when an 'open source
leader blah blah' (not lacking a massive amount of kapsones, memight
add) voluntarily exposes himself, in a public place, as the worst random
luser, it's no wonder that he'll get his ass pwn3d. Talk about security
:)

> Do you have any idea how many scripts have been written to expect that
> this output will not change?

Ah, finally some technical discussion! Why not take it back to tech@ and
give my patches a proper hearing? Then I'll feel inclined to respond in
a 'courteous' manner, too...

> Did you consider how many log scripts I decided to just throw away when
> I changed from Apache 1 to Apache 2?

Tja, things change. When they change for the better we shouldn't
complain, as all too often they change for the worse. And the 'tard who
uses something hideously bloated as Apache shouldn't wonder about having
to throw away lots of stuff that 'just worked' before, pfft. (Again, I
have a purely technical response, but that's for tech@, should you
indeed take the matter back there).

> Too much work to fix. Too much work just to get by, much less rewrite
> scripts!

Fixing your script once to use -o (which it should've used all along) is
too much work, yet continuing to blunder around w/ already-broken stuff
is perfectly fine to you? Figures. 

> Pay attention. Look at undeadly.org. A big change backed out.

If my patches would have to wait a major release, so people have time to
fix their junk, I'd consider that perfectly acceptable. Instead, even
the tiny patches which are expected to have no substantial consequences
are just ignored by our esteemed developer team. What kind of fscking
attitude is that?

> Your diff may be the greatest change in the history of mankind.

I already feel where your argument is going :/

> But that doesn't guarantee it will be accepted.

*Thank* *you* *bloody* *Capn* *Obvious*! (Yup, it went there. Amazing,
isn't it?)

> In other words, don't take it personally.

Of course not, it's all fair on misc@ and tech@!

> You did.

My partner did more than I did, but yeah. Personally or not, the kind
of behaviour displayed by theo & co. deserves to be stood up to.

> Get over it.

If anyone's not over it -- it ain't me. I sort-of expected the kind of
put-him-down-immediately response given to me on tech@; what I didn't
expect is theo going over the line by such a great margin.

> And keep working and submit more and different diff's.

I'm not joining your little OS project, I have my own going. When I need
to modifiy OpenBSD (or indeed any other software), and I manage to make
the modification reasonably general-purpose, I'm happy to share patches.

But I'm not going out of my way to contribute. Especially not after
being made to feel very unwelcome about a year ago.

> Diff's are ALWAYS welcome. They aren't always feasible.

And? Where's the news?

> Chris Bennett

Well, thank you for giving me this little soap box. Let's just hope
people have been paying attention.

I have other things to do.

Baai,

 --De Zeurkous.

-- 
Friggin' Machines!

RE: Re: patch: ps(1) broaden 'TT' field by 2 chars

[leo_tck]

Haai, zeur here (in case there's any confusion)!

> I am sick of getting emails like this from the community.

*PERHAPS* it would be 'cause we're sick of your behaviour?

> When I get them, I'm going to forward them to public lists.

Oh, then I can respond in public, too :D

OpenBSD is too good to waste on *you*!

There, said it. After all, ever since me's made an appearance, you've
been treating me as a threat to your leadership; no, to your position!

Might as well say it: you're incompetent! The only reason you and your
bunch come off as good at times is 'cause just about every other
'leader' or 'core team' out there is /even less/ competent than you.

Hence, you folks may be the lesser evil, but evil you are! You and
your cronies appear to be obsessed with playing social games first and
foremost. That's enough to make me hate you. Wear it with pride! =)

Baai,

   --De Zeurkous.

P.S.: Of course, I am a threat to your position, yet not by intention;
  that my presence exposes your crappitude is not my problem.

-- 
Friggin' Machines!

dmesg of 'OpenBSD/i386 6.4' 'bsd' on 'ASUS X52F'

[leo_tck]

[not subscribed to this list, so please Cc me. thanks.]

An extraordinarly crap machine, certainly compared to the Thinkpad;
don't ask me how megot hold of it, or why me's using it at all.

The USB kbd has been provided by me and is thus not part of the craptop.

  --zeurkous.

OpenBSD 6.4 (GENERIC) #926: Thu Oct 11 13:43:06 MDT 2018
dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC
real mem  = 3066515456 (2924MB)
avail mem = 2995605504 (2856MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: date 10/30/09, SMBIOS rev. 2.6 @ 0xec3d0 (77 entries)
bios0: vendor American Megatrends Inc. version "K52F.210" date 08/30/2010
bios0: ASUSTeK Computer Inc. K52F
acpi0 at bios0: rev 2
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP APIC DBGP ECDT SLIC MCFG HPET SSDT
acpi0: wakeup devices PEG4(S4) PEG5(S4) PEG6(S4) P0P1(S4) EHC1(S3) USB1(S3) 
USB2(S3) USB3(S3) USB4(S3) EHC2(S3) USB5(S3) USB6(S3) USB7(S3) HDEF(S4) 
RP01(S4) RP02(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) Core(TM) i3 CPU M 370 @ 2.40GHz ("GenuineIntel" 686-class) 2.40 
GHz, 06-25-05
cpu0: 
FPU,V86,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,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,POPCNT,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,SENSOR,ARAT,MELTDOWN
mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges
cpu0: apic clock running at 132MHz
cpu0: mwait min=64, max=64, C-substates=0.2.1.1, IBE
cpu at mainbus0: not configured
cpu at mainbus0: not configured
cpu at mainbus0: not configured
ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 24 pins
acpiec0 at acpi0
acpimcfg0 at acpi0
acpimcfg0: addr 0xe000, bus 0-255
acpihpet0 at acpi0: 14318179 Hz
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus -1 (PEG1)
acpiprt2 at acpi0: bus -1 (PEG3)
acpiprt3 at acpi0: bus -1 (PEG5)
acpiprt4 at acpi0: bus 5 (P0P1)
acpiprt5 at acpi0: bus 1 (RP01)
acpiprt6 at acpi0: bus 2 (RP02)
acpiprt7 at acpi0: bus -1 (RP04)
acpiprt8 at acpi0: bus -1 (RP05)
acpiprt9 at acpi0: bus 4 (RP06)
acpiprt10 at acpi0: bus -1 (RP07)
acpiprt11 at acpi0: bus -1 (RP08)
acpiprt12 at acpi0: bus 3 (RP03)
acpicpu0 at acpi0: C2(350@245 mwait.3@0x20), C1(1000@3 mwait.1), PSS
acpitz0 at acpi0: critical temperature is 93 degC
acpicmos0 at acpi0
"ETD0001" at acpi0 not configured
acpiac0 at acpi0: AC unit online
acpibat0 at acpi0: BAT0 model "K52F-44" serial   type LIon oem "ASUSTek"
"ATK0100" at acpi0 not configured
acpibtn0 at acpi0: LID_
acpibtn1 at acpi0: SLPB
acpivideo0 at acpi0: GFX0
acpivideo1 at acpi0: GFX0
acpivideo2 at acpi0: GFX0
acpivout0 at acpivideo2: LCDD
bios0: ROM list: 0xc/0xfc00! 0xd/0x1000
cpu0: Enhanced SpeedStep 2395 MHz: speeds: 2399, 2266, 2133, 1999, 1866, 1733, 
1599, 1466, 1333, 1199, 1066, 933 MHz
pci0 at mainbus0 bus 0: configuration mode 1 (no bios)
pchb0 at pci0 dev 0 function 0 "Intel Core Host" rev 0x18
inteldrm0 at pci0 dev 2 function 0 "Intel HD Graphics" rev 0x18
drm0 at inteldrm0
intagp0 at inteldrm0
agp0 at intagp0: aperture at 0xc000, size 0x1000
inteldrm0: msi
inteldrm0: 1366x768, 32bpp
wsdisplay0 at inteldrm0 mux 1: console (std, vt100 emulation)
wsdisplay0: screen 1-5 added (std, vt100 emulation)
"Intel 3400 MEI" rev 0x06 at pci0 dev 22 function 0 not configured
ehci0 at pci0 dev 26 function 0 "Intel 3400 USB" rev 0x06: apic 2 int 16
usb0 at ehci0: USB revision 2.0
uhub0 at usb0 configuration 1 interface 0 "Intel EHCI root hub" rev 2.00/1.00 
addr 1
azalia0 at pci0 dev 27 function 0 "Intel 3400 HD Audio" rev 0x06: msi
azalia0: codecs: Conexant/0x5069, Intel/0x2804, using Conexant/0x5069
audio0 at azalia0
ppb0 at pci0 dev 28 function 0 "Intel 3400 PCIE" rev 0x06: apic 2 int 16
pci1 at ppb0 bus 1
ppb1 at pci0 dev 28 function 1 "Intel 3400 PCIE" rev 0x06: apic 2 int 17
pci2 at ppb1 bus 2
athn0 at pci2 dev 0 function 0 "Atheros AR9285" rev 0x01: apic 2 int 17
athn0: AR9285 rev 2 (1T1R), ROM rev 13, address 48:5d:60:3f:65:64
ppb2 at pci0 dev 28 function 2 "Intel 3400 PCIE" rev 0x06: apic 2 int 18
pci3 at ppb2 bus 3
ppb3 at pci0 dev 28 function 5 "Intel 3400 PCIE" rev 0x06: apic 2 int 17
pci4 at ppb3 bus 4
"JMicron SD/MMC" rev 0x80 at pci4 dev 0 function 0 not configured
sdhc0 at pci4 dev 0 function 2 "JMicron SD Host Controller" rev 0x80: apic 2 
int 18
sdhc0: SDHC 2.0, 50 MHz base clock
sdmmc0 at sdhc0: 4-bit, dma
"JMicron Memory Stick" rev 0x80 at pci4 dev 0 function 3 not configured
"JMicron xD" rev 0x80 at pci4 dev 0 function 4 not configured
jme0 at pci4 dev 0 function 5 "JMicron JMC250" rev 0x03: msi, address 
20:cf:30:d0:f1:8b
jmphy0 at jme0 phy 1: JMP211 10/100/1000 PHY, rev. 1
ehci1 at pci0 dev 29 function 0 "Intel 3400 USB" rev 0x06: apic 2 int 23
usb1 at ehci1: USB revision 2.0
uhub1 at usb1 configuration 1 interface 0 "Intel EHCI root hub" rev 2.00/1.00 

dmesg of 'OpenBSD/i386 6.4' 'bsd.rd' on 'ASUS X52F'

[leo_tck]

[not subscribed to this list, so please Cc me. thanks.]

An extraordinarly crap machine, certainly compared to the Thinkpad;
don't ask me how megot hold of it, or why me's using it at all.

The USB kbd has been provided by me and is thus not part of the craptop.

  --zeurkous.

OpenBSD 6.4 (RAMDISK_CD) #916: Thu Oct 11 14:00:12 MDT 2018
dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/RAMDISK_CD
real mem  = 3066560512 (2924MB)
avail mem = 3001634816 (2862MB)
mainbus0 at root
bios0 at mainbus0: date 10/30/09, SMBIOS rev. 2.6 @ 0xec3d0 (77 entries)
bios0: vendor American Megatrends Inc. version "K52F.210" date 08/30/2010
bios0: ASUSTeK Computer Inc. K52F
acpi0 at bios0: rev 2
acpi0: tables DSDT FACP APIC DBGP ECDT SLIC MCFG HPET SSDT
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Intel(R) Core(TM) i3 CPU M 370 @ 2.40GHz ("GenuineIntel" 686-class) 2.40 
GHz, 06-25-05
cpu0: 
FPU,V86,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,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,POPCNT,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,SENSOR,ARAT,MELTDOWN
cpu0: apic clock running at 132MHz
cpu0: mwait min=64, max=64, C-substates=0.2.1.1, IBE
cpu at mainbus0: not configured
cpu at mainbus0: not configured
cpu at mainbus0: not configured
ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 24 pins
acpiec0 at acpi0
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus -1 (PEG1)
acpiprt2 at acpi0: bus -1 (PEG3)
acpiprt3 at acpi0: bus -1 (PEG5)
acpiprt4 at acpi0: bus 5 (P0P1)
acpiprt5 at acpi0: bus 1 (RP01)
acpiprt6 at acpi0: bus 2 (RP02)
acpiprt7 at acpi0: bus -1 (RP04)
acpiprt8 at acpi0: bus -1 (RP05)
acpiprt9 at acpi0: bus 4 (RP06)
acpiprt10 at acpi0: bus -1 (RP07)
acpiprt11 at acpi0: bus -1 (RP08)
acpiprt12 at acpi0: bus 3 (RP03)
acpicpu at acpi0 not configured
acpitz at acpi0 not configured
acpicmos0 at acpi0
"ETD0001" at acpi0 not configured
"ACPI0003" at acpi0 not configured
"PNP0C0A" at acpi0 not configured
"ATK0100" at acpi0 not configured
"PNP0C0D" at acpi0 not configured
"PNP0C0E" at acpi0 not configured
bios0: ROM list: 0xc/0xfc00! 0xd/0x1000
pci0 at mainbus0 bus 0: configuration mode 1 (no bios)
pchb0 at pci0 dev 0 function 0 "Intel Core Host" rev 0x18
vga1 at pci0 dev 2 function 0 "Intel HD Graphics" rev 0x18
wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation)
"Intel 3400 MEI" rev 0x06 at pci0 dev 22 function 0 not configured
ehci0 at pci0 dev 26 function 0 "Intel 3400 USB" rev 0x06: apic 2 int 16
usb0 at ehci0: USB revision 2.0
uhub0 at usb0 configuration 1 interface 0 "Intel EHCI root hub" rev 2.00/1.00 
addr 1
"Intel 3400 HD Audio" rev 0x06 at pci0 dev 27 function 0 not configured
ppb0 at pci0 dev 28 function 0 "Intel 3400 PCIE" rev 0x06: apic 2 int 16
pci1 at ppb0 bus 1
ppb1 at pci0 dev 28 function 1 "Intel 3400 PCIE" rev 0x06: apic 2 int 17
pci2 at ppb1 bus 2
athn0 at pci2 dev 0 function 0 "Atheros AR9285" rev 0x01: apic 2 int 17
athn0: AR9285 rev 2 (1T1R), ROM rev 13, address 48:5d:60:3f:65:64
ppb2 at pci0 dev 28 function 2 "Intel 3400 PCIE" rev 0x06: apic 2 int 18
pci3 at ppb2 bus 3
ppb3 at pci0 dev 28 function 5 "Intel 3400 PCIE" rev 0x06: apic 2 int 17
pci4 at ppb3 bus 4
"JMicron SD/MMC" rev 0x80 at pci4 dev 0 function 0 not configured
sdhc0 at pci4 dev 0 function 2 "JMicron SD Host Controller" rev 0x80: apic 2 
int 18
sdhc0: SDHC 2.0, 50 MHz base clock
sdmmc0 at sdhc0: 4-bit, dma
"JMicron Memory Stick" rev 0x80 at pci4 dev 0 function 3 not configured
"JMicron xD" rev 0x80 at pci4 dev 0 function 4 not configured
jme0 at pci4 dev 0 function 5 "JMicron JMC250" rev 0x03: msi, address 
20:cf:30:d0:f1:8b
jmphy0 at jme0 phy 1: JMP211 10/100/1000 PHY, rev. 1
ehci1 at pci0 dev 29 function 0 "Intel 3400 USB" rev 0x06: apic 2 int 23
usb1 at ehci1: USB revision 2.0
uhub1 at usb1 configuration 1 interface 0 "Intel EHCI root hub" rev 2.00/1.00 
addr 1
ppb4 at pci0 dev 30 function 0 "Intel 82801BAM Hub-to-PCI" rev 0xa6
pci5 at ppb4 bus 5
pcib0 at pci0 dev 31 function 0 "Intel HM55 LPC" rev 0x06
ahci0 at pci0 dev 31 function 2 "Intel 3400 AHCI" rev 0x06: msi, AHCI 1.3
ahci0: port 0: 3.0Gb/s
ahci0: port 1: 1.5Gb/s
ahci0: PHY offline on port 4
scsibus0 at ahci0: 32 targets
sd0 at scsibus0 targ 0 lun 0:  SCSI3 0/direct fixed 
naa.5000c5002b9b0b58
sd0: 305245MB, 512 bytes/sector, 625142448 sectors
cd0 at scsibus0 targ 1 lun 0:  ATAPI 5/cdrom 
removable
"Intel 3400 SMBus" rev 0x06 at pci0 dev 31 function 3 not configured
"Intel 3400 Thermal" rev 0x06 at pci0 dev 31 function 6 not configured
isa0 at pcib0
isadma0 at isa0
pckbc0 at isa0 port 0x60/5 irq 1 irq 12
pckbd0 at pckbc0 (kbd slot)
wskbd0 at pckbd0: console keyboard, using wsdisplay0
npx0 at isa0 port 0xf0/16: reported by CPUID; using exception 16
pci6 at mainbus0 bus 255
pchb1 at pci6 dev 0 function 0 "Intel QuickPath" rev 0x05
pchb2 at pci6 dev 0 function 1 "Intel QuickPath" rev 0x05
pchb3 at pci6 

dmesg of 'OpenBSD/i386 6.4' 'bsd.mp' on 'ASUS X52F'

[leo_tck]

[not subscribed to this list, so please Cc me. thanks.]

An extraordinarly crap machine, certainly compared to the Thinkpad;
don't ask me how megot hold of it, or why me's using it at all.

The USB kbd has been provided by me and is thus not part of the craptop.

  --zeurkous.

OpenBSD 6.4 (GENERIC.MP) #943: Thu Oct 11 13:51:32 MDT 2018
dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC.MP
real mem  = 3066515456 (2924MB)
avail mem = 2995478528 (2856MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: date 10/30/09, SMBIOS rev. 2.6 @ 0xec3d0 (77 entries)
bios0: vendor American Megatrends Inc. version "K52F.210" date 08/30/2010
bios0: ASUSTeK Computer Inc. K52F
acpi0 at bios0: rev 2
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP APIC DBGP ECDT SLIC MCFG HPET SSDT
acpi0: wakeup devices PEG4(S4) PEG5(S4) PEG6(S4) P0P1(S4) EHC1(S3) USB1(S3) 
USB2(S3) USB3(S3) USB4(S3) EHC2(S3) USB5(S3) USB6(S3) USB7(S3) HDEF(S4) 
RP01(S4) RP02(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) Core(TM) i3 CPU M 370 @ 2.40GHz ("GenuineIntel" 686-class) 2.40 
GHz, 06-25-05
cpu0: 
FPU,V86,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,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,POPCNT,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,SENSOR,ARAT,MELTDOWN
mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges
cpu0: apic clock running at 132MHz
cpu0: mwait min=64, max=64, C-substates=0.2.1.1, IBE
cpu1 at mainbus0: apid 4 (application processor)
cpu1: Intel(R) Core(TM) i3 CPU M 370 @ 2.40GHz ("GenuineIntel" 686-class) 2.40 
GHz, 06-25-05
cpu1: 
FPU,V86,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,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,POPCNT,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,SENSOR,ARAT,MELTDOWN
cpu2 at mainbus0: apid 1 (application processor)
cpu2: Intel(R) Core(TM) i3 CPU M 370 @ 2.40GHz ("GenuineIntel" 686-class) 2.40 
GHz, 06-25-05
cpu2: 
FPU,V86,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,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,POPCNT,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,SENSOR,ARAT,MELTDOWN
cpu3 at mainbus0: apid 5 (application processor)
cpu3: Intel(R) Core(TM) i3 CPU M 370 @ 2.40GHz ("GenuineIntel" 686-class) 2.40 
GHz, 06-25-05
cpu3: 
FPU,V86,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,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,POPCNT,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,SENSOR,ARAT,MELTDOWN
ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 24 pins
acpiec0 at acpi0
acpimcfg0 at acpi0
acpimcfg0: addr 0xe000, bus 0-255
acpihpet0 at acpi0: 14318179 Hz
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus -1 (PEG1)
acpiprt2 at acpi0: bus -1 (PEG3)
acpiprt3 at acpi0: bus -1 (PEG5)
acpiprt4 at acpi0: bus 5 (P0P1)
acpiprt5 at acpi0: bus 1 (RP01)
acpiprt6 at acpi0: bus 2 (RP02)
acpiprt7 at acpi0: bus -1 (RP04)
acpiprt8 at acpi0: bus -1 (RP05)
acpiprt9 at acpi0: bus 4 (RP06)
acpiprt10 at acpi0: bus -1 (RP07)
acpiprt11 at acpi0: bus -1 (RP08)
acpiprt12 at acpi0: bus 3 (RP03)
acpicpu0 at acpi0: C2(350@245 mwait.3@0x20), C1(1000@3 mwait.1), PSS
acpicpu1 at acpi0: C2(350@245 mwait.3@0x20), C1(1000@3 mwait.1), PSS
acpicpu2 at acpi0: C2(350@245 mwait.3@0x20), C1(1000@3 mwait.1), PSS
acpicpu3 at acpi0: C2(350@245 mwait.3@0x20), C1(1000@3 mwait.1), PSS
acpitz0 at acpi0: critical temperature is 93 degC
acpicmos0 at acpi0
"ETD0001" at acpi0 not configured
acpiac0 at acpi0: AC unit online
acpibat0 at acpi0: BAT0 model "K52F-44" serial   type LIon oem "ASUSTek"
"ATK0100" at acpi0 not configured
acpibtn0 at acpi0: LID_
acpibtn1 at acpi0: SLPB
acpivideo0 at acpi0: GFX0
acpivideo1 at acpi0: GFX0
acpivideo2 at acpi0: GFX0
acpivout0 at acpivideo2: LCDD
bios0: ROM list: 0xc/0xfc00! 0xd/0x1000
cpu0: Enhanced SpeedStep 2394 MHz: speeds: 2399, 2266, 2133, 1999, 1866, 1733, 
1599, 1466, 1333, 1199, 1066, 933 MHz
pci0 at mainbus0 bus 0: configuration mode 1 (no bios)
pchb0 at pci0 dev 0 function 0 "Intel Core Host" rev 0x18
inteldrm0 at pci0 dev 2 function 0 "Intel HD Graphics" rev 0x18
drm0 at inteldrm0
intagp0 at inteldrm0
agp0 at intagp0: aperture at 0xc000, size 0x1000
inteldrm0: msi
inteldrm0: 1366x768, 32bpp
wsdisplay0 at inteldrm0 mux 1: console (std, vt100 emulation)
wsdisplay0: screen 1-5 added (std, vt100 emulation)
"Intel 3400 MEI" rev 0x06 at pci0 dev 22 function 0 not configured
ehci0 at pci0 dev 26 function 0 "Intel 3400 USB" rev 0x06: apic 2 int 16
usb0 at ehci0: USB revision 2.0
uhub0 at usb0 configuration 1 interface 0 "Intel EHCI root hub" rev 2.00/1.00 
addr 1
azalia0 

re: obligatory leaving letter

[leo_tck]

Haai,

I just read the responses of Ingo & Espie, among others. Yes, just now,
in the archives, since for some mysterious reason, they weren't cc'd to
me (despite that I clearly stated that I had left).

Y'know, I could go on a long rant again (I'm rather prone to them, ain't
I?), but I won't bother you with that. What I will bother you with is my
response to the two fellows named above (accompanied by a hearthy laugh):

You g{irl,uy,whatever}s are incorrigible. But that's kind of okay. You
see, well, since you didn't appear to get the hint before, I'll spell it
out to you: the reason I left really is that I don't want to be in the
way.

Keep up the good work everyone, really. Our goals may differ, our
methods may differ, our entire mindset may differ, but that's okay to
me, even if (going by Ingo & Espie's responses) it might not be to you.

Then there's the emerging "who got pissed off first and thus had the
right to be an ass" contest. I think I'll pass: my goal is not to
create (or sustain) drama. To the measure that I fail in that goal, I
apologize.

I hope this finally closes the matter of my departure.

Good day everyone,

Baai,

--zeurkous.

-- 
Friggin' Machines!

what is UNIX about? (was: Re: obligatory leaving letter)

[leo_tck]

Since I don't want to be guilty of spreading unfounded information, I'll
still respond, if tersely, to Rod{erick,rigo}, who doesn't appear to
have cc'd me either.

I'll quote [0]:
> What we wanted to preserve was not just a good environment in which to
> do programming, but a system around which a fellowship could form. We
> knew from experience that the essence of communal computing, as
> supplied by remote-access, time-shared machines, is not just to type
> programs into a terminal instead of a keypunch, but to encourage close
> communication.

dmr also (somewhat awkwardly) read that up from his tty in a promotional
video once. Thinking about the atmosphere depicted in the video, perhaps
'fellowship' is a more appropriate term than 'family', indeed.

Not that Rod{erick,rigo} was that much off: he simply looked at it from
a different angle.

--zeurkous.

[0] https://www.bell-labs.com/usr/dmr/www/hist.html

-- 
Friggin' Machines!

blaat

[leo_tck]

Haai,

[tl;dr: zeur ranting, skip if you're not in the mood]

While I'm no longer subscribed to this list, I wonder if I can enrich
your evening with a little... amateur psychonanalysis. Let's find out.

The recent Intel fiasco, as described (with more technical insight and
accuracy than seems to be their general modus operandi these days) on El
Reg, made me go to the list archives to have a look if the issue is
being discussed here (not quite yet, it appears; but then again, perhaps
it is not an issue w/ OpenBSD in the first place). Afterwards, I could
not resist the temptation to look at what happened on the list during my
absence (which I intend to continue; but while this is a one-time thing,
I might pop up now and then with rants like these).

Everything seems to be like usual: a lot of bickering and little
progress. My mind drifted to the past, and more generally to the
question as to why I fare so poorly in project-centered groups. I'll 
spare you my deliberations, yet I could only come to one conclusion:
such groups tend to look inward, and focus on social cohesion, to a
degree that makes me rather uncomfortable. I then tend to respond by
being more rebellious than is theoretically justified, and down the
crapper it goes (as you might well have guessed, I have RL problems
like this as well).

I'm still open to alternative explanations, whether opposing or
complementary (is both possible?). I'd be very grateful for them, in
fact. But I've learned not to actually expect anything...

A long time I've been wondering what makes people this way. Today, I
think I have a new puzzle piece towards the answer: I 'missed out' on
high school, so I didn't learn to identify and deal with what I believe
to be called 'cliques' at a relatively early, more impressionable age;
that would have prepared me for many a misadventure on mailing lists
like these.

Y'know, the funny thing is, I still don't feel that I've missed out on
anything by not attending high school, or observing the sudden dulling
of the spirit that seems to be so common in humans reaching adulthood;
indeed, I feel enriched by going and staying outside the paths that so
many would have me (and everyone else under their influence) follow. I
don't care if my way is longer, or more difficult: dtrt'ing is much too
important to me.

My experience of trying to discuss things here was frankly traumatic,
and made me question not only my own sanity, but that of Theo's,
Espie's, etc. as well. After all, what good is a mind that cannot stand
contrary influences? I was (and kind of still am) suspecting myself of
possessing such a mind, as well. In the end, I had to conclude that no,
none of us are quite insane; and that yes, we are all just acting on our
previous experiences (that's how a neural network works, after all).

It is thus probably not your fault that the OpenBSD project (and indeed
many other projects; I have mentioned NetBSD in a previous message) is
turned inward, yes, even incestous; and it is not my fault that I cannot
thrive in such an environment. Such is life.

What this all comes down to? No, I'm not a loser (hi Eric Furman!). Yes,
I still have objections to the way the project works, but they don't
matter. I should shut up and work on my own stuff. And as for you
folks... try to be a little more open to outside influence. I know it's
hard to learn to deal with it, but it might just help you in ways you
cannot even imagine right now. Life with an open mind is an adventure,
embrace it =)

There's bit of a snowstorm going on here in Wuerbenthal. I like it,
makes me feel cuddly and quiet. Truth be told, I tend to fare as badly
in summers as I do in closed communities. Sometimes I wonder why I don't
just mv to Siberia.

Oh, and to anyone writing me off as a drama queen or something: I'll at
least expect you to create an ED article on me to back it up. In fact,
I'd be honoured if you do. But I doubt you have the balls (take that as
a challenge if you will).

"It's a magical world, Hobbes, ol' buddy... Let's go exploring!"

Good evening,

Baai, 

--zeurkous.

-- 
Friggin' Machines!

obligatory leaving letter

[leo_tck]

Haai,

I think it's about time I write this.

I am De Zeurkous. I used the nick 'schaafuit' (originally devised for a
prank elsewhere) in an attempt not to let past preconceptions (for those
who don't know, I have a somewhat bad history with the NetBSD project)
rule the present. The story about using my bf's e-mail address is true,
however; the only act of deception was the assumption of another nick.

Despite ongoing personal problems (which are not at all relevant here),
I extended my UNIX experience considerably since 2007 (the year of the
NetBSD trouble). Things have settled considerably for me since then, so
I suggest that we let the past be the past and focus on what has been 
happening recently.


I admit to having some troll blood in my veins. However, I have been
here to contribute to OpenBSD discussion and have found myself genuinely
distraught the many times it descended into outright flamage. If that
makes me too soft material for OpenBSD, as Theo at least once implied,
well, so be it.

Now that is out of the way, I can get to the point.

In all honesty, I have come to the sad conclusion that the various BSD
projects, with their leaders being full of entitlement, don't really
appreciate what UNIX is all about (nevermind that gnu weenies are even
worse in this regard).

As dmr often pointed out (though perhaps not quite in the terms that I
will use here), UNIX is about community. I'd even argue that early UNIX
sites were like families, anticipating each other's needs and building
upon individual strenghts to achieve something that was not just
technically adequate, but something to be proud of. Unfortunately, I can
no longer verify this with dmr, but I'd imagine that UNIX did not just
feel familiar, but like something shared and even homely.

Unfortunately, UNIX development seems to have become profoundly
seperated from UNIX use. Whether related or not, it also appears to have
become a bare battle of egos, something that is quite alien to me, and
to UNIX itself as well.

I chose OpenBSD because of its somewhat desirable technical properties,
and I had hoped to be able to contribute. Alas, I am forced to concede
that for me this is not possible, as I appear to have quite different
goals (and a very different mindset) from its principal contributors,
despite my profound appreciation for the project's focus on security.

Now, by this point, you might suspect that I have some alternative in
mind, and possibly in development; this is indeed the case. You might
also suspect that I'm going to plug it here; however, I won't.

Since I have no particular desire to be a disruptive force to anyone,
I will leave you folks to your project.

And me to mine =)

Best of luck and greetings,

Baai,

--zeurkous.

P.S.: attached is a main(3) header file and manual page, as a little...
 'going-away present'.

--
Friggin' Machines!

main.tar.gz
Description: main.tar.gz

RE: ASLR: How Robust is the Randomness?

[leo_tck]

theo wrote:
> It is over your head. Or learn to read. Or learn to not reply before
> you think.

You know what? You're full of crap.

I may be inexperienced (as you once correctly pointed out), but I know
my theory very, very well. Chances are that in a lot of areas, I know
it better than *you*.

Like it or not, you're dealing with an equal here. You'll have to treat
me that way.

If you cannot handle that, well, I'm sorry for you.

/thread.

--schaafuit.

RE: ASLR: How Robust is the Randomness?

[leo_tck]

theo wrote:
> That interpretation is wrong. 

Could be, I'm no genius :)

> You don't understand fork+exec.

Wha?

> There
> is no decision to stop using an address space after failure. Instead,
> address spaces are intentionally split ahead of time to ensure a
> specific pointer value is only valid in one process image. Other
> similar load-images have unique layouts with unique pointer values.
> So when failure happens, there is no other context where crash-learned
> information can be reapplied in a non-crashed process image with the
> same mapping.

Uhm, how do I put this...

In the old model, if an attack causes a specific child to crash, and it
has been created using a simple fork, the parent, and all other
children -- past, present, and future -- will *continue to use* the
address space{, layout} that is common to them all.

In the new situation, children do an exec immediately, before
interacting with the peer. Hence, the addr space gets randomized, and
it will not be like the parent's, or like that of any other children
(given sufficient entropy).

Hence, repeating the same attack will most likely fail.

What is the part that I don't understand?

> Don't change my words.

Sorry, didn't mean to. It was a mere suggestion.

> It is over your head. Or learn to read. Or learn to not reply before
> you think.

Criticism is welcome. Unwarranted preconceptions are not.

(hmm, now what makes a preconception 'unwarranted'...?)

--schaafuit.

RE: ASLR: How Robust is the Randomness?

[leo_tck]

theo wrote:
> Then it is probably over your head. 

You guessed wrong :)

> Not much I can do about that.

Yes you can, s/reusing/continuing to use/.

--schaafuit.

RE: ASLR: How Robust is the Randomness?

[leo_tck]

Hi,

theo wrote:
> And, we have focused on never reusuing an address space after a crash,
> by designing software to use fork+exec.

I'm not sure I understand this point?

--schaafuit.

FU: RE: Hellos from the Lands of Norway.

[leo_tck]

I wrote:

> "Sterling Archer"  wrote:

which sould've been:

> "Ywe Cærlyn"  wrote:

But /thread, really.

 --schaafuit.

It's a troll! (Re: Hellos from the Lands of Norway.)

[leo_tck]

Okay folks, it's a troll alright.

/thread.

--schaafuit.

RE: Hellos from the Lands of Norway.

[leo_tck]

"Sterling Archer"  wrote:
> P-p-palmleaf schaafuit?

A-a-ask the Catholic church.
--schaafuit.

RE: Hellos from the Lands of Norway.

[leo_tck]

"Ywe Cærlyn"  wrote:
> Palmleaf, schaafuit?

Ask the Catholic church.
--schaafuit.

RE: Hellos from the Lands of Norway.

[leo_tck]

"Ywe Cærlyn"  wrote:
> Are you deaf and mute, boy? Enigmatic knowledge of backwardness? Fires?
> Keep talking and you´ll have that.

At least he won't have hairy palms and baldness.

Unlike you.

Try cabbage leaves for the latter.

--schaafuit.

RE: Image viewer alternative to eog

[leo_tck]

Hi,

"Sterling Archer"  wrote:
> You could try feh, it's in ports.

/me approves.

I use it combination with lynx to cover 90% of the usage cases of a
graphical browser (javashit peddlers can gth -- run it on your own
bloody machine, not mine!).

But that's me :^)

--schaafuit.

FU: RE: Hangup at "setting tty flags" after installation of puc(4) addon pci card

[leo_tck]

I wrote:
> Okay, I know this is shot in the dark, but hell: given the comments
> you quoted, how can we be sure that it will work on irqs >=15?
^

Plonk that '='.

 --schaafuit.

RE: Hangup at "setting tty flags" after installation of puc(4) addon pci card

[leo_tck]

Hi,

"Jens A. Griepentrog"  wrote:
> In fact, the card was offered to me to have the MosChip MCS9865.
> Since I do not believe that the system detects a wrong chip,
> this means that the chip seems to have a wrong imprint ...

There is another possibility: it is the same design but was manufactured
with different IDs burned in for political reasons.

Okay, I know this is shot in the dark, but hell: given the comments
you quoted, how can we be sure that it will work on irqs >=15?

Otherwise, you could try swapping the IDs in the source code and seeing
how that goes...

--schaafuit.

RE: kernel reordering and config -e

[leo_tck]

"Ed Hynan"  wrote:
> No patch from OP yet,

Yeah, I'm sorry, my OpenBSD machine is currently air-gapped and is still
running 6.1 :(

It's been hectic IRL 'round here.

> so how about this: for someone needing config -e
> it's probably sufficient if /usr/libexec/reorder_kernel checks for
> a post-processing script, and invokes it if present and executable.
>
> If the patch is acceptable, I'll post a sample post-processing script
> that, for config -f -e, should only need one parameter change for
> specific needs.

I think that's better than my hack :)

Is it really a good idea to have the kernel file name hardcoded like
that? Granted, I usually use a symlink myself, but still...

--schaafuit.

RE: kernel reordering and config -e

[leo_tck]

theo wrote:
> Hmm... I can't seem to find a patch in there anywhere.

I'll read that as 'proposal accepted', and will try and provide a patch 
soon.

 --schaafuit.

RE: kernel reordering and config -e

[leo_tck]

theo wrote:
> If someone wants to solve this fully there have been some proposals
> for keeping track of the instruction sequence, and attempting to
> reapply it upon each relink in the build directory. There just hasn't
> been any scripting changes to do that from anyone, and it isn't on my
> radar as important.

How about making reorder_kernel do something like:

$ if test -f /etc/ukc.conf; then 

RE: The "like" factor

[leo_tck]

"Bryan Harris"  wrote:
> "My mother had a favorite saying (origin unknown): "You can get used to
> anything if you do it long enough. Even hanging." She trotted out that
> saying whenever my siblings or I complained about something that wasn't
> going to change."
>
> And later:
>
> "Persuasion Tip #22: People automatically get used to minor annoyances over
> time."
>
> "My mom's point of view captures an important rule in persuasion. People
> can get past minor annoyances if you give them enough time. Humans quickly
> adapt to just about anything that doesn't kill them."

What Rupert described did not seem to me an annoyance.

And define 'adapt to'. Tolerate? Accept? Assimilate? 

I'll be honest with you: the social engineering approach rather
disgusts me. And I happen to know a lot of people who won't fall for it,
anyway. On the contrary. They'd be walking out the moment it'd be tried.

Overall, I'd advice against this approach.

--schaafuit.

RE: kernel reordering and config -e

[leo_tck]

Hi,

"Paul B. Henson"  wrote:
> Or do you need to update your settings
> in the config and compile a kernel from scratch? If you do, does
> /usr/share/compile automatically get populated with your new kernel
> objects and reordering just starts working, or do you need to do
> something manually to get it running with a locally compiled kernel?

A hack that might work is to ensure that the config -e is done each
time after the reorder, and the checksum updated for the next time
'round.

If the power ever goes off between the two passes, though, you'll
probably end up with the situation you bumped into now.

 --schaafuit.

RE: The "like" factor

[leo_tck]

I wrote:
>
> In that case, I'd interpret the beancounter's reponse as 'have to make
> sacrifices, don't we? *sigh*'.

I amend that.

Isn't it just loss?

We experienced techies try not to allow ourselves to get too attached
to an environment, don't we? But hasn't there been a 'first time' this
has happened, for us all? And were *we* that prepared for it?

It's like a replacement teddy bear, isn't it? The old one might be in
pieces and still the new one won't ever feel as real.

Or one's first love. It never quite feels the same again, does it?

Perhaps a shared drink to mark the transition will help the grieving
process along a little.

I could still be all wrong, so I'll just shut up for now and see what
others have to say.

--schaafuit.

RE: The "like" factor

[leo_tck]

"Rupert Gallagher"  wrote:
> Well, people hated Microsoft's new GUIs, and wanted the old windows xp/7 
> back, which we delivered. They are happy now, and so do we.
>
> They also hated the new GUI with the latest Office suite, so they kept using 
> the older version. LibreOffice has the Microsoft Office GUI, so they are 
> happy now, and so do we.
>
> The original file explorer has always been simple minded, and they are happy 
> to experiment with the alternatives.

In that case, I'd interpret the beancounter's reponse as 'have to make 
sacrifices, don't we? *sigh*'.

--schaafuit.

RE: The "like" factor

[leo_tck]

bytevolc...@safe-mail.net wrote:
>
> Think about this. You change the toolset they've been used to for
> years, with something radically different. Whether or not you like it,
> OpenOffice/Libreoffice/OpenBSD/Linux is radically different from a MS
> Office/Windows setup. Now instead of coming to work and just doing the
> job they were assigned to, they now have to learn new bits of software,
> and you "don't understand the problem."

There's not necessarily any technical problem, at least not one that
cannot be solved (luser education has been mentioned).

But of course there's still a problem. If I'm not too mistaken, that's
why Rupert asked for advice.

> Doesn't matter. It appears he just forced his users to use radically
> different software to do the same task, without understanding what they
> face, or justifying his reason for the change to the users.

Yeah well, going by his wording, I divine that he was sceptical himself
and it was decided higher up the food chain.

I don't approve of it (and that's putting it mildly), but in some
organizations that's just how it works.

> It won't help the case if you come across as unsympathetic/unwilling to
> understand your users, and it won't help if you don't try to work with
> them to resolve the issues.

Well, if the root issue is the command from up high, then it's either
obey or quit. A nasty dilemma, to say the least.

> This is the key to solving the "like" factor, as Rupert calls it. The
> users rightfully want a justification for the change, and they won't
> understand "oh this software is open source, so we're not locked in to
> proprietary closed Microsoft software." They won't care either, they
> just want to do the job and go home.

Again, if it's you as a sysadmin that makes the decisions, that *can*
fly as well in practice as it does in theory.

But often you find yourself just obeying 'corporate policy', and it can
take a true BOFH to sabotage it effectively. 

> I don't do this kind of thing anymore, but whenever I had to change the
> system around, some retraining was in order and I would provide the
> user with a comparison on how they did something in the old system vs
> how they do it in the new system.

When some hyped geek sells it to the CEO, or (more likely) the higher
regions fall for the $$$ argument, and they have declared it "not
needed", well, what are you going to do?

Say that the shareholders can stuff the extra dividends up their asses?

Again, not everyone is a BOFH.

 --schaafuit.

RE: The "like" factor

[leo_tck]

"Daniel Wilkins"  wrote:
> Something to consider is that there *are* areas where libreoffice is 
> deficient.

Yup.

>
> It's not uncommon for businesses to have a terrifying amount of embedded 
> visual
> basic and incredibly elaborate excel macros, I wouldn't be surprised if the
> (possibly theoretical) suit literally can't get their work done because they
> don't have access to their scripts and macros that some secretary wrote in
> 1999. Any migration which messes with office, if you want it to be successful
> you really need a serious period of testing where you grab up as many
> business-essential documents as you can and identifying scripts and macros
> which may become problems, then rewriting them in LO compatible way (LO
> has scripting, it's just not *literally* vbscript). It has a basic dialect
> so translation shouldn't necessarily be hard, just time consuming.

I'd like to shoot the person who first decided that documents should
contain arbitrary macros (can we really call them that way, as it's
imperative? I associated macros with a declarative style) that varies
their contents.

But indeed, that doesn't help anyone who's made the unwise decision
to do so, at least not anymore. Their stuff will break, guaranteed.

Though repeating the mistake by re-writing stuff in yet another
'macro' language, embedded in documents, is something that I'd rather
see avoided.

--schaafuit.

RE: The "like" factor

[leo_tck]

"Noah"  wrote:
> The software does mostly the same things, but you moved the menus and
> buttons around. The pictures they recognize aren't there. Things work just
> a little differently now. For some, it takes longer to do the things they
> need to do. They have muscle memory and "shortcuts" that some of us find
> silly (such as "I don't know what it's called, but it's always been the
> squiggly icon near the top right corner" or "it's the third thing down on
> the second menu bar list"). Chances are, the revolt would be similar
> upgrading from Win XP to 7, 7 to 10, or office 97 to office 2012.
>
> Prepare to be very patient with them. Give them the training and resources
> they need to get their workflows back. They just want to do their jobs, and
> they don't care if you dislike the tools they've grown comfortable with.

You're looking at it from a purely technical perspective. I'm not sure
that's justified, given all the potential social causes Rupert and I
just identified. 

Besides, despite all technical measures, you can't make people like
something.

Except of course with application of the hungry doberman and the length
of rubber hose...

--schaafuit.

FU: RE: The "like" factor

[leo_tck]

I wrote:
> windoze nt 5.2.

I meant 6.0. Sorry, haven't been keeping track and M$ is, true to
form, not making it easy by having obscured the number (and since
having switched to outright *lying* about it).

--schaafuit.

RE: The "like" factor

[leo_tck]

bytevolc...@safe-mail.net wrote:
> Perhaps it isn't just word/excel, but rather, getting used to the
> operating system changes and its antics. It appears you have changed
> their OS and their software, and this has upset them. No training was
> provided explaining to them the nooks and crannies of the new software,
> so they are frustrated as they are forced to satisfy someone elses'
> nerdgasm.

How is office politics necessarily equivalent to a 'nerdgasm'?

Either way, aren't most 'desktop environments', and libreoffice, 'sold'
on the premise that it's so easy to convert from M$ poop?

> I notice a big difference between modern MS Office and
> LibreOffice/OpenOffice, which is why I prefer the latter. I also notice
> a big difference between OpenBSD and Windows 10, and you would have to
> be a blithering idiot to not notice the differences.

Given the situation he described it was more like windoze nt 5.2. I
could be wrong on that, though.

> You seem to have forgotten the huge uproar Microsoft created in
> 2006/2007 with the idiotic "ribbon" interface. This is similar, but on
> a much smaller, more local scale.

Yeah, but like in most other abusive relationships, those people find it
very hard to leave M$, whatever they do.

And will still eye a potential replacement partner with a lot of
scepticism (not quite unjustified).

--schaafuit.

P.S.: why 'SPOOFED'?

RE: The "like" factor

[leo_tck]

"Rupert Gallagher"  rote:
> We nerds are the other side of the problem, because we are apparently unable 
> to understand their problem.

And even if we understand it, we often cannot offer a solution that
satisfies them.

> We have little simpathy for those who frown without evidence of an actual 
> problem.

The flip side of this is that a feeling sometimes *is* a good indicator
that there's something wrong, without being able to consciously define
that 'something'.

> Perhaps this is an example that humans still find it comfortable to
> "follow and go along together", like a herd of sheeps.

If that's all they've ever known...

> Since "word" and "excel" is what they hear and use, perhaps they feel
> "cheap" or "non-standard" by using something else.

IME that attitude goes from politics all the way down to underwear. 

> Perhaps all we need to do with libreoffice is to improve its
> spash-screen, its icons and menus, and they will never notice the
> difference.

Yeah well, gnome, kde, et al certainly appear to follow the 'IBM CUA'
approach: a grand unified set of rules, determined through extensive
pseudo-scientific research... resulting in an appearance that only a
mother could love :)

I might be wrong, though. I don't use those.

--schaafuit.

RE: The "like" factor

[leo_tck]

Hi,

"Rupert Gallagher"  wrote:
> How did you solve the "like" factor?

As I have no experience in office situations, I cannot answer that.

However, it would've been an interesting experiment to just swap the
logos and see how long it'd take for them to notice.

#include 

Hm, that makes me recall a dark and distant past in which I preferred
the look of windoze 3 over any other WIMPy GUI I had seen, even though
it was the least useful of 'em all, and in hindsight is certainly one of
the ugliest.

I was a little kid at the time. I suppose I was just not mature enough
to appreciate alternatives to what I'd been given. Besides, I had (and
still have) little use for WIMPy GUIs. As now, I mainly used them for
games that I like but are so broken that they will only run under them. 

And beancounters hate 'scruffies', not to forget, and that hate tends to
be mutual. Using something associated with an opposing tribe is
something that primates tend to rather frown upon.

If the beancounter was of the somewhat more mature variety, his
disappointment may just have been an 'it was nice while it lasted, but
we all have to grow up' type of reaction, though. I couldn't possibly
judge this.

If none of these explanations apply, I guess it's plain familiarity.

Or the groupthink that primates are well-known for.

--schaafuit.

tar bombs (was: RE: Abort Trap question)

[leo_tck]

Hi,

"Daniel Boyd"  wrote:
> Haha crap. I think this is what happened. I haven't bothered downloading 
> src.tar.gz in awhile bc of syspatch, but since this is a PowerPC machine, i 
> wanted to be ready for the first errata. This is what I get for doing things 
> from memory instead of reading the FAQ.

Mistakes happen, don't worry =)

Though I consider it good practice to at least do a 'pax -v | head'
before extracting anything. And in dubious cases, I create a '.x/' dir
first and do the extraction in there.

HTH,

  --schaafuit.

RE: FOSDEM 2018 - Distributions Devroom Call for Participation

[leo_tck]

Hi,

"Ingo Schwarze" <schwa...@usta.de> wrote:
> Hi leo_tck,

Hold on a sec, that's not my nick. I'm provisionally using my bf's
account (with permission!). Just saying since this will end up in the
archives and it shouldn't be ascribed to him.

You'll find my real nick at the bottom of my messages :)

> This is not spam. It is an on-topic posting.

Yes, the poster has enlightened me by private e-mail now. There's an
OpenBSD 'track', apparently, woohoo!

You really can't expect me to not consider a long, iterative, message, 
laden with buzzwords and sloppy English, advertising something, with
*no* mention of anything distinctly on-topic whatsoever, spam.

> Please refrain from insulting people, in particular those posting
> rarely who may not be very familiar with OpenBSD and might be
> mislead to think that such insults would be normal or acceptable
> in an OpenBSD context.

*cough* Theo *cough*.

But no, I absolutely have no intention of representing OpenBSD. Since I
didn't invoke any official capacity, didn't send mail from an
OpenBSD.org address (obviously I don't even have one!), and put that
little disclaimer at the top, it should've been, an be, clear that my
reply was from me little self only.

And from no-one else.

> FOSDEM is a major conference about Free Software, arguably even the
> major conference in Europe. OpenBSD as a free operating system.
> OpenBSD developers have presented at FOSDEM in the past. I'm
> actually considering to propose a presentation myself, and i'm
> grateful for the heads-up.

I suppose I should explain here that I'm not very much fonder of the
'free software' world than I'm of the 'proprietary crap' one. Not that 
I don't find the former approach infinitely superior, it's just that,
from me POV, there's an increasing failure to live up to the ideals.

But if you like this sort of thing, good luck w/ your presentation =)

No hard feelings, really.

> I consider FOSDEM a major opportunity for communication among
> free operating systems that rarely talk to each other. The *BSD
> conferences are no doubt useful too, but less suited to that
> particular purpose.

Yeah, after said private e-mail, I started to figure that the list of
buzzwords was in fact a list of excuses to convince one's boss to pay
for attendance.

Y'know, I find it funny and appropriate when a local shop owner hangs a
"closed for urgent technical reasons" sign when he's taken the day off
to enjoy a barrel of homebrew beer with a friend.

But if I'm right about those buzzwords, well, let's just say that the
level and kind of deception in them appalls me.

> While some of your questions may be interesting and some of your
> criticisms might have a point, discussing most of them would be
> off-topic on this list. A call for proposals for a major free
> software conference is clearly on topic here; nitpicking on the
> concept of the conference is not.

Honestly, if it's not spam, the announcement should really be better
worded, especially since the whole point of a conference is
communication. The announcement doesn't really reflect that.

Thanks for your enlightening response. I agree that this discussion is
off-topic and thus propose that any further replies (from anyone) be
sent by private e-mail.

Sincerely,

--schaafuit.

RE: FOSDEM 2018 - Distributions Devroom Call for Participation

[leo_tck]

*sigh*

I wrote:
> Yes, the poster has enlightened me by private e-mail now. There's an
> OpenBSD 'track', apparently, woohoo!

Correction: it was not the poster, and it was in public.

This broken webmail poop is why I din't respond everyday. Be glad! ;)

--schaafuit.

RE: FOSDEM 2018 - Distributions Devroom Call for Participation

[leo_tck]

Hi,

[I don't normally respond to spam, but I need to blow off some
 frustration =)]

"Brian Exelbierd"  wrote:
> Online at:
> https://lists.fosdem.org/pipermail/fosdem/2017-October/002648.html
> 
> The Distributions devroom will take place Sunday 4 February 2018 at
> FOSDEM, in Brussels, Belgium at the Universit=C3=A9 Libre de Bruxelles.

Interesting. What does this have to do with OpenBSD?

> For this year's distributions devroom, we want to focus on the ways that
> distribution technologies can be leveraged to allow for easier
> creation of a multi-verse of artifacts from single source trees.

Uhm, what does that *mean*, in technical terms?

> We also
> want to continue to highlight the huge efforts being made in shared
> environments around Build/Test/Release cycles.

Define 'shared environments'?

> We welcome submissions targeted at contributors interested in issues
> unique to distributions, especially in the following topics:
> 
> - Distribution and Community collaborations, eg: how does code flow from
>   developers to end users across communities, ensuring trust and code
>   audibility
^^

I propose reviving speak(1).

> - Automating building software for redistribution to minimize human
>   involvement, eg: bots that branch and build software, bots that
>   participate as team members extending human involvement

Counterproductive.

> - Cross-distribution collaboration on common issues, eg: content
>   distribution, infrastructure, and documentation

What's cross-distribution? Is it like cross-pollination?

> - Growing distribution communities, eg: onboarding new users, helping
>   new contributors learn community values and technology,  increasing
>   contributor technical skills, recognizing and rewarding contribution

Sounds like a schoolteacher approach to me. An onboarding school, haha!

> - Principals of Rolling Releases, Long Term Supported Releases (LTS),
>   Feature gated releases, and calendar releases

You do know that calendar releases have been obsolete since cal(1),
right?

Unless you like pretty pictures.

> - Distribution construction, installation, deployment, packaging and
>   content management

Ooh yes, when installing OpenBSD I'm very very interested in content
management, woohoo!

> - Balancing new code and active upstreams verus security updates, back
>   porting and minimization of user breaking changes

{,L}users are broken by design, so we don't need to worry about that =)

> - Delivering architecture independent software universally across
>   architectures within the confines of distribution systems

Gibberish.

> - Effectively communicating the difference in experience across
>   architectures for developers, packagers, and users

Ever heard of manual pages? They're great!

> - Working with vendors and including them in the community

What vendors? Most of them ain't interested.

> - The future of distributions, emerging trends and evolving user demands
>   from the idea of a platform

I DEMAND WINDOZE 3193179381, AND I DEMAND IT NOW!!!11!!1!! WH!11!!!

> Ideal submissions are actionable and opinionated. Submissions may
> be in the form of 25 or 50 minute talks, panel sessions, round-table
> discussions, or Birds of a Feather (BoF) sessions.

Actionable? Prolly. Opinionated? Yup. Write me in!

And I'll sign it with my shit.

Stop spamming us, really.

--schaafuit.

RE: A stupid question, re: xargs(1)

[leo_tck]

"Andreas Kusalananda Kähäri"  write:
>
> Another thing to avoid is having too exotic filenames.

Or always passing file names through vis(3) before writing them.

Though that's probably not as simple as it sounds.

--schaafuit.

RE: A stupid question, re: xargs(1)

[leo_tck]

"Raul Miller"  wrote:
>
> And if I search, I can find a tremendous variety of other elaborate
> approaches, including replacements for xargs. So it's not like this is
> not a real issue, nor is it like this isn't something that grows new
> handlings on an ongoing basis.

Unfortunately, especially in the modern world, alternatives keep popping 
up where none are really needed. Made that mistake plenty of time in my
lunix days, reinventing something only to then discover that there was a
simpler way to do things that I should've used.

Now, I'm not saying your problem isn't real: indeed, I'm sure it's the
kind of corner case where UNIX shows its age.

I don't think bloating already funky programs like xargs(1) with more
options is the solution though. IMO, you'd indeed better be looking for
a replacement.

Or writing one.

 --schaafuit.

RE: size of size_t

[leo_tck]

"Ian Sutton"  wrote:
>
> An important thing to ask yourself before suggesting things like this
> is "if this is such an obvious and trivial improvement, then why
> hasn't anyone already done it?". To put things in perspective, we had
> an entire release primarily predicated upon increasing the width of a
> similar type, time_t, from 32 -> 64 bits:
>
> https://www.openbsd.org/55.html

Obvious, perhaps. But it sure ain't trivial -- I'm very much aware of
that.

Okay, in theory, it's changing a couple of lines in a header file, and
everything should just magically work. But that's totally unrealistic
in practice, of course. In the case of size_t, to begin w/, there
appears to be lots of code that relies on the assumption that it's
really a simple unsigned long.

Which is true. Until the change is made.

On a related note, would you folks be interested in patches removing
said assumpting of equivalence from programs like dd(1)?

 --schaafuit.

RE: size of size_t

[leo_tck]

Hi,

"Janne Johansson"  wrote:
>
>> Okay, I don't have a 64-bit machine running OpenBSD to check -- but is
>> 'long'
>> 64-bits on those?
>
> How did you manage to come to the first conclusion, given the second part
> later?

*shrugs* an incorrect assumption.

 --schaafuit.

RE: RE: FU: size of size_t

[leo_tck]

theo wrote:
>
> Time to begin buffing the 'd' key.

Learning never ends, does it?

--schaafuit.

RE: amd64 OpenBSD 6.2 doesn't see hard disks when controller in RAID mode

[leo_tck]

theo wrote:
>
> Unfortunately we are still stuck here:
>
> 0. No code being developered, email and wiki discussion, gnashing of teeth

Seems par for the course these days. Blah blah, entitlement, whatnot,
and no work being done.

--zeur.

RE: RE: size of size_t

[leo_tck]

theo wrote:
>
> No, not really. If you won't use the publically available source tree
> and vast amounts of documentation about POSIX but instead jump
> straight towards assertive dialogue on a mailing list, then I don't
> see how we can help.

Funny thing is, you already explained in your other message.

> Basically you are saying we should just change everything, consequences
> and correctness be damned.

Uhm, no.

 --schaafuit.

RE: FU: size of size_t

[leo_tck]

theo wrote:
>
> off_t is used where it should be used. size_t is used where it should
> be used.

In that case I change the proposal to the introduction of an uoff_t, or
is there already something appropriate? If so, why doesn't dd(1) use it?

> You are showing inexperience.

Yes, you got that exactly. 

  --schaafuit.

RE: size of size_t

[leo_tck]

Hi,

>> I just discovered, to my dismay, that size_t is only 32 bits, even on
>> 64-bit processors. Is there a particular pressing reason for this? A
>> quick investigation reveals that even dd(1) is affected -- this is IMO
>> not good.
>
> You are wrong.
>
> limits.h:#define SIZE_T_MAX ULONG_MAX /* max value for a size_t (historic) */

Okay, I don't have a 64-bit machine running OpenBSD to check -- but is 'long'
64-bits on those? In that case I am indeed wrong.

>> I'd suggest, given modern file sizes, that we bump it to 64 bits on all
>> platforms. Comments?
>
> No way.

Can I trouble you for an explanation?

--schaafuit.

FU: size of size_t

[leo_tck]

I wrote:
> I'd suggest, given modern file sizes, that we bump it to 64 bits on all
> platforms.

Oh, and off_t *is* 64 bits, at least on i386; pity most routines don't
use it: they use size_t.

--schaafuit.

size of size_t

[leo_tck]

Hi,

I just discovered, to my dismay, that size_t is only 32 bits, even on
64-bit processors. Is there a particular pressing reason for this? A
quick investigation reveals that even dd(1) is affected -- this is IMO
not good.

I'd suggest, given modern file sizes, that we bump it to 64 bits on all
platforms. Comments?

--schaafuit.

RE: amd64 OpenBSD 6.2 doesn't see hard disks when controller in RAID mode

[leo_tck]

Don't mind if I jump in.

"Rostislav Krasny"  wrote:
>
> Boasty? I just try to help you to fix this bug by providing the
> information I've found. It's hard to fix it by myself because of the
> several times mentioned reasons. If you don't want to fix it just
> because you don't want I can live with that.

You appear unaware of the slippery slope. They're overworked already (or
appear to be, but I very much believe it). Let's just imagine they'll be
happy to make an exception here, and write the workaround that will make
your broken machine work. 'cause when lunix does it, it's a good idea!

And then tomorrow I'll insist they fix the wdc(4) caps probe & print
issue for me -- after all, I'm not familiar enough with the code, so
they should do it, shouldn't they?! And again someone will pop up with
an "important" problem. And another. And another. And before you know
it, you can bring flowers to Theo & co. in hospital after their heart
sugery. Oh, and can they fix this and that little problem too when they
recover?

UNIX was not made for people who are just willing, or able, to use.

> Bye

*waves*

--schaafuit.

RE: Switching swap partition

[leo_tck]

Haai,

"Frank Groeneveld"  wrote:
>
> swapctl -l always lists /dev/sd1b correctly.

Instead of sd0b? Then it appears fine.

>> You might want to keep sd0b around as a dump partition though, just in
>> case it ever panics before going multiluser...
>
> The point of this operation was to reclaim that space for other use ;-)

You could even just shrink it significantly -- I don't think a dump at
early boot would take up *that* much space...

 --schaafuit.

RE: Switching swap partition

[leo_tck]

Haai,

"Frank Groeneveld"  wrote:
> I recently switched the swap partition on a server from sd0b to sd1b.
> I've modified /etc/fstab accordingly and after a reboot swapctl -l lists
> it as being the only used swap partition correctly. Today I noticed this
> line in dmesg:
> root on sd0a (4340b9bfa4cdde0a.a) swap on sd0b dump on sd0b

FWIW, I believe these are just boot-time defaults.

> It still lists the old partition (which I modified to be of the
> "unknown" type in the disklabel, but removing the partition doesn't fix
> it either) as being the swap partition. How can I change this? I found a
> kernel compile option, but recompiling a kernel because I want swap on a
> different partition seems wrong.

It'd seem more wrong to me if it'd try to swap to a nonexistent
partition ;) Just in case, what is the output of 'swapctl -l' straight
after boot, preferably when still single-user? 

You might want to keep sd0b around as a dump partition though, just in
case it ever panics before going multiluser... 

--schaafuit.

RE: Tar and bzip2 maximum compression

[leo_tck]

Hi,

> Hi guys,
> How can I get the maximum compression from bzip2 by tar?
>
> I try this but not work [although with linux it works]:
> tar cvv file_to_compress | pbzip2 -9 -v > compressed.tbz2
> return--> tar: Failed open to write on /dev/rst0: Device not configured
>

I believe the ancient default for tar(1) is to try to open the 0th
st(1) device in raw mode, that's what you're seeting. Try:

% tar cvvf -

(piped to whatever you want) instead.

> Can anyone give me some tips?

It's more modern to use pax(1), whose syntax is different, but which
behaves in the way you'd expect these days.

> Thanks.

You're welcome :)

--schaafuit

RE: Tar and bzip2 maximum compression

[leo_tck]

I wrote:
>
> I believe the ancient default for tar(1) is to try to open the 0th
> st(1) device in raw mode, that's what you're seeting. Try:

grah... that's st(4), of course.

--schaafuit.

RE: Increase swap size on a running instance

[leo_tck]

i...@nuemak.com wrote:
> There seems to be no man page for "fooswap" :)

Then write one! =)
--schaafuit.

fu^2: Thinkpad R40 varia

[leo_tck]

About the system partition:

In the process of preparing to install OpenBSD, I set the 'IBM
Predesktop Area' BIOS option to 'Disabled', expecting a hidden
partition to appear. Imagine my surprise when only the NTFS partition
(it came w/ m$ poop installed), which filled the entire disk, was
visible. Did IBM really put it there?

Either way, out of expediency, I blasted the whole thing to make room
for OpenBSD. It seems to work fine, no error, and pressing the
'Access IBM' button during boot now brings up a small, textual boot
menu, including an option to enter the BIOS setup. Yay!

 --schaafuit.

re: fs level 0

[leo_tck]

pe...@bsdly.net wrote:
> You probably read too much (or too little) into this part:
>
> 04.3BSD format file system.  This option is
>  primarily used to build root file systems that can
>  be understood by older boot ROMs.

Yes. Although my dislike of fanciness for (especially) the root file
system plays just as a big a part.

Turns out things can get *too* unfancy =)

> Checking CVSweb, it looks like this part was in the newfs man page at
> initial import in 1995. So for the option to be useful, you would need
> to look for hardware and ROMs that were considered old in 1995 or even
> earlier. It's possible that modern OpenBSD still supports some hardware
> that actually matches the description, but others will know for sure.

Yeah. That's how I understood it.

> Anyway, your R40 is likely to be no older than 2003 or so, and to me at
> least it sounds like the most useful thing to do would be to simply
> reinstall with as little deviation from the defaults as possible.

That's asking a lot from a deviate ;)

Seriously though, I already re-did my work, w/ the root fs at level 1. I
take it as a lesson learned.

> I didn't get hold of a ThinkPad that I was allowed to install OpenBSD on
> until about 2006, but by then the install and use experience was
> straightforward.

I don't seem to be running into any ThinkPad-specific problems either.

Except of course some hardware problems attributable to old age, but I
can hardly blame OpenBSD for that .

> - P

 --schaafuit.

fs level 0

[leo_tck]

Hi,

While installing OpenBSD 6.1, out of sheer, raging paranoia, I created
the root file system with -O 0. This worked fine, until I had extracted
everything, and the kernel crashed with some uvm error (the automagic
reboot came too soon for me to jot it down -- is it such a good idea
for bsd.rd to reboot so soon after a panic?), teaching me a lesson.

The obligatory fsck afterwards failed, as the level 0 fses are
apparently considered to be too old. Fair enough, but is it such a good
idea to continue support for them in newfs, and the kernel?

I propose that we don't leave it half-supported like this, and that the
relevant code be removed.

Or is there some use for it, that I'm overlooking?

--schaafuit.

dmesg of 'OpenBSD i386' 'bsd' on 'Thinkpad R40'

[leo_tck]

Included below.

--schaafuit.

bsd wrote:
> OpenBSD 6.1 (GENERIC) #291: Sat Apr  1 13:49:08 MDT 2017
> dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC
> cpu0: Intel(R) Pentium(R) M processor 1300MHz ("GenuineIntel" 686-class) 1.30 
> GHz
> cpu0: 
> FPU,V86,DE,PSE,TSC,MSR,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,TM,PBE,EST,TM2,PERF
> real mem  = 535707648 (510MB)
> avail mem = 512741376 (488MB)
> mpath0 at root
> scsibus0 at mpath0: 256 targets
> mainbus0 at root
> bios0 at mainbus0: date 07/15/03, BIOS32 rev. 0 @ 0xfd7b0, SMBIOS rev. 2.31 @ 
> 0xe0010 (53 entries)
> bios0: vendor IBM version "1PET46WW (1.14 )" date 07/15/2003
> bios0: IBM 27223DG
> acpi0 at bios0: rev 2
> acpi0: sleep states S0 S3 S4 S5
> acpi0: tables DSDT FACP SSDT ECDT TCPA BOOT
> acpi0: wakeup devices LID_(S3) SLPB(S3) UART(S3) PCI0(S3) PCI1(S4) USB0(S3) 
> USB1(S3) USB2(S3) AC9M(S4)
> acpitimer0 at acpi0: 3579545 Hz, 24 bits
> acpiec0 at acpi0
> acpiprt0 at acpi0: bus 0 (PCI0)
> acpiprt1 at acpi0: bus 1 (AGP_)
> acpiprt2 at acpi0: bus 2 (PCI1)
> acpipwrres0 at acpi0: PUBS, resource for USB0, USB1, USB7
> acpitz0 at acpi0: critical temperature is 97 degC
> acpibtn0 at acpi0: LID_
> acpibtn1 at acpi0: SLPB
> "PNP0303" at acpi0 not configured
> "IBM0057" at acpi0 not configured
> "PNP0501" at acpi0 not configured
> "PNP0400" at acpi0 not configured
> "IBM0071" at acpi0 not configured
> acpibat0 at acpi0: BAT0 model "IBM-02K6928" serial  2694 type LION oem 
> "Panasonic"
> acpiac0 at acpi0: AC unit online
> acpithinkpad0 at acpi0
> acpivideo0 at acpi0: VID_
> bios0: ROM list: 0xc/0x1 0xe/0x1
> cpu0 at mainbus0: (uniprocessor)
> mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges
> cpu0: Enhanced SpeedStep 1300 MHz: speeds: 1300, 1200, 1000, 800, 600 MHz
> pci0 at mainbus0 bus 0: configuration mode 1 (bios)
> pchb0 at pci0 dev 0 function 0 "Intel 82855PM Host" rev 0x03
> intelagp0 at pchb0
> agp0 at intelagp0: aperture at 0xd000, size 0x1000
> ppb0 at pci0 dev 1 function 0 "Intel 82855PM AGP" rev 0x03
> pci1 at ppb0 bus 1
> radeondrm0 at pci1 dev 0 function 0 "ATI Radeon Mobility M7" rev 0x00
> drm0 at radeondrm0
> radeondrm0: irq 11
> uhci0 at pci0 dev 29 function 0 "Intel 82801DB USB" rev 0x01: irq 11
> uhci1 at pci0 dev 29 function 1 "Intel 82801DB USB" rev 0x01: irq 11
> uhci2 at pci0 dev 29 function 2 "Intel 82801DB USB" rev 0x01: irq 11
> ehci0 at pci0 dev 29 function 7 "Intel 82801DB USB" rev 0x01: irq 11
> usb0 at ehci0: USB revision 2.0
> uhub0 at usb0 configuration 1 interface 0 "Intel EHCI root hub" rev 2.00/1.00 
> addr 1
> ppb1 at pci0 dev 30 function 0 "Intel 82801BAM Hub-to-PCI" rev 0x81
> pci2 at ppb1 bus 2
> cbb0 at pci2 dev 0 function 0 "TI PCI1510 CardBus" rev 0x00: irq 11
> ipw0 at pci2 dev 2 function 0 "Intel PRO/Wireless 2100" rev 0x04: irq 11, 
> address 00:04:23:81:d8:72
> "TI TSB43AB21 FireWire" rev 0x00 at pci2 dev 7 function 0 not configured
> fxp0 at pci2 dev 8 function 0 "Intel PRO/100 VE" rev 0x81, i82562: irq 11, 
> address 00:06:1b:d3:19:22
> inphy0 at fxp0 phy 1: i82562ET 10/100 PHY, rev. 0
> cardslot0 at cbb0 slot 0 flags 0
> cardbus0 at cardslot0: bus 3 device 0 cacheline 0x8, lattimer 0xb0
> pcmcia0 at cardslot0
> ichpcib0 at pci0 dev 31 function 0 "Intel 82801DBM LPC" rev 0x01
> pciide0 at pci0 dev 31 function 1 "Intel 82801DBM IDE" rev 0x01: DMA, channel 
> 0 configured to compatibility, channel 1 configured to compatibility
> wd0 at pciide0 channel 0 drive 0: 
> wd0: 16-sector PIO, LBA, 38154MB, 78140160 sectors
> wd0(pciide0:0:0): using PIO mode 4, Ultra-DMA mode 5
> atapiscsi0 at pciide0 channel 1 drive 0
> scsibus1 at atapiscsi0: 2 targets
> cd0 at scsibus1 targ 0 lun 0:  ATAPI 
> 5/cdrom removable
> cd0(pciide0:1:0): using PIO mode 4, Ultra-DMA mode 2
> ichiic0 at pci0 dev 31 function 3 "Intel 82801DB SMBus" rev 0x01: irq 11
> iic0 at ichiic0
> spdmem0 at iic0 addr 0x50: 256MB DDR SDRAM non-parity PC2100CL2.5
> spdmem1 at iic0 addr 0x51: 256MB DDR SDRAM non-parity PC2100CL2.5
> auich0 at pci0 dev 31 function 5 "Intel 82801DB AC97" rev 0x01: irq 11, ICH4
> ac97: codec id 0x41445374 (Analog Devices AD1981B)
> ac97: codec features headphone, 20 bit DAC, No 3D Stereo
> audio0 at auich0
> "Intel 82801DB Modem" rev 0x01 at pci0 dev 31 function 6 not configured
> usb1 at uhci0: USB revision 1.0
> uhub1 at usb1 configuration 1 interface 0 "Intel UHCI root hub" rev 1.00/1.00 
> addr 1
> usb2 at uhci1: USB revision 1.0
> uhub2 at usb2 configuration 1 interface 0 "Intel UHCI root hub" rev 1.00/1.00 
> addr 1
> usb3 at uhci2: USB revision 1.0
> uhub3 at usb3 configuration 1 interface 0 "Intel UHCI root hub" rev 1.00/1.00 
> addr 1
> isa0 at ichpcib0
> isadma0 at isa0
> pckbc0 at isa0 port 0x60/5 irq 1 irq 12
> pckbd0 at pckbc0 (kbd slot)
> wskbd0 at pckbd0: console keyboard
> pms0 at pckbc0 (aux slot)
> wsmouse0 at pms0 mux 0
> pcppi0 at isa0 port 0x61
> spkr0 at pcppi0
> lpt2 at isa0 port 

fu: Thinkpad R40 varia

[leo_tck]

Alright, I opened the sucker up.

First of all, it's a type 2722, w/ a 14" display. Sorry for omitting
that information before.

The CMOS battery is indeed there, wrapped in black rubber (or
rubber-like plastic), under the keyboard, next to the keyboard
and touchpad connectors. I suppose I'll see about replacing it, it ain't
a standard one.

While I haven't removed them, I also got a closer look at the PCMCIA/ATA
slots. They are indeed as I described, though they *appear* to be
connected to the same bus. It's small work so I might be wrong, though.

I've decided to just nuke the hdd contents (minus the system partition,
for now). Installing OpenBSD is more important =)

 --schaafuit.

re: Thinkpad R40 varia

[leo_tck]

riccardo.mott...@libero.it wrote:
> there is one, usually wrapped in a yellow plastic. a Lithium battery. I 
> have seen dozens of thinkpads of your vintage. From model to model it 
> might change place and way to access it. Usually under the palmrest or 
> under the keyboard. Sometimes near the RAM access door.

Thanks, I'll cross-check with the manual and then have a look.

> A non original hard-disk might give you a Bios error, but will work. No 
> need for any extra partition, you can install OpenBSD (or NetBSD or also 
> Linux) just straight on it. I have done that on many thinkpads, in 
> cluding models very similar to yours.

Thanks for the assurance! I think I'll keep it for now as a curiosity,
but it's good to know that I'm not so dependent on it as I had feared.

--schaafuit.

re: Thinkpad R40 varia

[leo_tck]

Hi,

florian.ermi...@mailbox.org wrote:
> Have you checked for a separate CMOS
> battery - which is probably long dead?

As a matter of fact I haven't yet. Stay tuned.

> I would be surprised if there's more than
> some diagnostic software for to ease the
> job of IBM's customer support=2E
> I installed OpenBSD on an ancient T20
> (which has a serial port, that's why I kept
> it around) once and didn't look out for any=20
> "system partitions"

Trouble is, it appears to be integrated with the BIOS to an unclear
degree.

> Probably be a second PCMCIA/CardBus=20
> slot=2E Those were important back then=2E

Then why is it of the opposite gender? Upon further inspection, the
guide rail also appears to be different. My best guess is still ATA...

--schaafuit.

fu^3: wdc_pcmcia and ATA mode

[leo_tck]

Work continues on this issue.

I found a copy of the CompactFlash 3.0 specification at [1].

In section 1.3, "Overview of CompactFlash Storage Card":

from file cfspc3_0.pdf:
> A CompactFlash storage card also runs in True IDE mode that is
> electrically compatible with an IDE disk drive."

This is obviously the way I'm trying to use the card.

> Once the CompactFlash Storage Card has been configured by the host,
> it appears to the host as a standard ATA (IDE) disk drive.

Note the term 'disk drive'. OpenBSD finds not a drive, but a
controller with a drive attached. That would appear to be PCMCIA (or,
as the standard puts it, 'PC Card') mode, alright.

In section 4.2, "Electrical Description":

> The CompactFlash Storage Card functions in three basic modes: 1) PC
> Card ATA using I/O Mode,

Aha, that's indeed what OpenBSD's using!

> 2) PC Card ATA using Memory Mode,

This must be the 'memory-mapped' mode that NetBSD appears to (at least
theoretically) support, and which might yield a performance improvement
compared to mode 1).

Might...

> 3) True IDE Mode, which is compatible with most disk drives.

Yup, that's what I want alright. And that's also what I foolishly
expected to work...

Next, in table 4, "Pin Assignments and Pin Type", the OE signal is
shown to double as 'ATA SEL' in ATA mode. In the the following table 5,
"Signal Description", the following hint is given:

> To enable True IDE Mode this input should be grounded by the host.

In section 4.7.1, "True IDE Mode I/O Function":

> The CompactFlash Storage Card and CF+ Card can be configured in a
> True IDE Mode of operation. The CompactFlash Storage Card is
> configured in this mode only when the -OE input signal is grounded by
> the host during the power off to power on cycle.

Power off to power on? Yelp. One could of course physically wire it so,
but then the host (and quite possibly its firmware!) would need to know
wtf is going on, or else it'd get very confused...

However, some escape is provided:

> Optionally, the CompactFlash Storage Cards and CF+ Cards may support
> the following optional detection methods:
>
> 1. The card is permitted to monitor the -OE (-ATA SEL) signal at any
>time(s) and switch to PCMCIA mode upon detecting a high level on
>the pin.
>
> 2. The card is permitted to re-arbitrate the interface mode
>determination following a transition of the (-)RESET pin.
>
> 3. The card is permitted to monitor the -OE (-ATA SEL) signal at any
>time(s) and switch to True IDE mode upon detection of a continuous
>low level on pin for an extended period of time.

'continuous'? 'extended'? That would seem to be rather open to
interpretation.

Nonetheless, when supported by the card, and given approrpriate host
hardware, any of these methods would appear to suffice. 

Section 6, "Software Interface", as a whole appears to confirm that the
wdc(4) detected and used by OpenBSD is in fact on the card itself.

Table 61, "Pinout Differences Between CF Storage Card and CF Adapter",
shows that the OE signal *does not* double as 'ATA SEL' on the PCMCIA
end, even though the wiring is supposed to be passive. This is worrying.

Next we consult the PCMCIA specification, volume 8, "PC Card Host System
Specification", found at [2]. Specifically, section 4, "PCI-to-CardBus
Bridge Register Description". Nothings there appears to say anything
about ATA mode, or software control of the OE signal -- it was clearly
not on the mind of anyone involved in writing that standard. 

So this is where it ends :( Just another piece of pee-cee
pseudo-standardization. Yuck.

Not an OpenBSD problem. Sorry for the noise. Hope it's been useful
regardless.

--schaafuit.

[1] http://rumkin.com/reference/aquapad/media/cfspc3_0.pdf
[2] http://affon.narod.ru/08ho80.pdf

wdc(4) caps probe & print

[leo_tck]

Hi,

I was going to propose the following kludge^Wpatch...

--- sys/dev/ic/wdc.c.orig   2016-09-14 22:00:16.0 -0400
+++ sys/dev/ic/wdc.c2017-09-02 18:57:21.0 -0400
@@ -1326,6 +1326,9 @@
at_poll) != CMD_OK)
continue;
 
+   (void)printf("%s: supports PIO mode %i\n",
+drvp->drive_name, i + 3);
+
/*
 * If controller's driver can't set its PIO mode,
 * set the highest one the controller supports

...when my eyes fell on the following comment:

in the same file:
> void
> wdc_print_caps(struct ata_drive_datas *drvp)
> {
>   /* This is actually a lie until we fix the _probe_caps
>  algorithm. Don't print out lies */
> #if 0

What's the deal with this? How is the _probe_caps routine broken enough
to justify omitting the printout?

--schaafuit.

fu^2: wdc_pcmcia and ATA mode

[leo_tck]

Hi,

Now I've sent the general dmesg output, I'll provide the specific stuff
concerning the card.

On insertion:

cd61 wrote:
> wdc2 at pcmcia0 function 0 "TRANSCEND, TS64GCF400, " port 0x4000/16
> wd1 at wdc2 channel 0 drive 0: 
> wd1: 1-sector PIO, LBA48, 61064MB, 125059072 sectors
> wd1(wdc2:0:0): using BIOS timings

On removal:

> wd1 detached
> wdc2 detached

NetBSD-7.1's boot.iso, used for comparison, additionally outputs the
following:

boot wrote:
> wdc2: i/o mapped mode
> wd1: drive supports PIO mode 4

Part of the sore spot is the 'i/o mapped mode'. As I noted before,
NetBSD appears to support a 'memory mapped mode' as well, but no ATA,
either. Nonetheless, the 'memory mapped mode' may well be faster.

As to the second line, I wouldn't mind if OpenBSD would provide this
information. I think I'll propose a patch...

--schaafuit.

Thinkpad R40 varia

[leo_tck]

Just some notes on the damn thing:

Swapping the general battery clears the 'CMOS' memory. I surmise that
there is no seperate CMOS battery: I consider this a design flaw.

As with lots of IBM PC stuff of the era (since the PS/2?), there's a
'system partition' (or whatever they called it that week) that is
probably best preserved when swapping hdds (I'll be sure to make a
backup, just in case). The BIOS ('Phoenix FirstBIOS(tm)') setup is
reasonable, though: everything really important can be configured there
(or so it appears).

The lack of a serial port on the machine significantly limits its use
without a compatible docking station (I might try to get hold of one in
the future), or at least a PCMCIA serial port card.

The docking station connector's flaps don't appear to provide adequate
protection from the environment.

Again as (IIRC) common in the era it was produced, there are no flash
card ports, only {PCMCIA,CardBus}. Hence the wdc_pcmcia thread...

About the only documentation that I could find is the 'Hardware
Maintenance Manual'. I also have been able to track down a 'Service and
Troubleshooting Guide' and a 'Setup Guide'. E-mail me if you'd like
copies of any of these. I couldn't find a general luser manual, or
detailed specifications of the hardware (e.g. schematics).

There's what appears to be an extra port above the PCMCIA one, with a
female connector, but otherwise looking suspiciously similar, which I
haven't seen described (seperately) anywhere. I don't believe this is
for CardBus (though I could be wrong) -- for 2.5" hdds, maybe? If so, I
wonder if it supports hot-swapping...

--schaafuit.

dmesg of 'OpenBSD i386' 'cd61.iso' on 'Thinkpad R40'

[leo_tck]

Here's the promised dmesg.

--schaafuit.

cd61 wrote:
> OpenBSD 6.1 (RAMDISK_CD) #289: Sat Apr  1 13:58:25 MDT 2017
> dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/RAMDISK_CD
> cpu0: Intel(R) Pentium(R) M processor 1300MHz ("GenuineIntel" 686-class) 1.30 
> GHz
> cpu0: 
> FPU,V86,DE,PSE,TSC,MSR,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,TM,PBE,EST,TM2,PERF
> real mem  = 535490560 (510MB)
> avail mem = 516141056 (492MB)
> mainbus0 at root
> bios0 at mainbus0: date 07/15/03, BIOS32 rev. 0 @ 0xfd7b0, SMBIOS rev. 2.31 @ 
> 0xe0010 (53 entries)
> bios0: vendor IBM version "1PET46WW (1.14 )" date 07/15/2003
> bios0: IBM 27223DG
> acpi0 at bios0: rev 2
> acpi0: tables DSDT FACP SSDT ECDT TCPA BOOT
> acpiec0 at acpi0
> acpiprt0 at acpi0: bus 0 (PCI0)
> acpiprt1 at acpi0: bus 1 (AGP_)
> acpiprt2 at acpi0: bus 2 (PCI1)
> acpipwrres at acpi0 not configured
> acpitz at acpi0 not configured
> "PNP0C0D" at acpi0 not configured
> "PNP0C0E" at acpi0 not configured
> "PNP0303" at acpi0 not configured
> "IBM0057" at acpi0 not configured
> "PNP0501" at acpi0 not configured
> "PNP0400" at acpi0 not configured
> "IBM0071" at acpi0 not configured
> "PNP0C0A" at acpi0 not configured
> "ACPI0003" at acpi0 not configured
> "IBM0068" at acpi0 not configured
> bios0: ROM list: 0xc/0x1 0xe/0x1
> cpu0 at mainbus0: (uniprocessor)
> pci0 at mainbus0 bus 0: configuration mode 1 (bios)
> pchb0 at pci0 dev 0 function 0 "Intel 82855PM Host" rev 0x03
> ppb0 at pci0 dev 1 function 0 "Intel 82855PM AGP" rev 0x03
> pci1 at ppb0 bus 1
> vga1 at pci1 dev 0 function 0 "ATI Radeon Mobility M7" rev 0x00
> wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation)
> uhci0 at pci0 dev 29 function 0 "Intel 82801DB USB" rev 0x01: irq 11
> uhci1 at pci0 dev 29 function 1 "Intel 82801DB USB" rev 0x01: irq 11
> uhci2 at pci0 dev 29 function 2 "Intel 82801DB USB" rev 0x01: irq 11
> ehci0 at pci0 dev 29 function 7 "Intel 82801DB USB" rev 0x01: irq 11
> usb0 at ehci0: USB revision 2.0
> uhub0 at usb0 configuration 1 interface 0 "Intel EHCI root hub" rev 2.00/1.00 
> addr 1
> ppb1 at pci0 dev 30 function 0 "Intel 82801BAM Hub-to-PCI" rev 0x81
> pci2 at ppb1 bus 2
> cbb0 at pci2 dev 0 function 0 "TI PCI1510 CardBus" rev 0x00: irq 11
> ipw0 at pci2 dev 2 function 0 "Intel PRO/Wireless 2100" rev 0x04: irq 11, 
> address 00:04:23:81:d8:72
> "TI TSB43AB21 FireWire" rev 0x00 at pci2 dev 7 function 0 not configured
> fxp0 at pci2 dev 8 function 0 "Intel PRO/100 VE" rev 0x81, i82562: irq 11, 
> address 00:06:1b:d3:19:22
> inphy0 at fxp0 phy 1: i82562ET 10/100 PHY, rev. 0
> cardslot0 at cbb0 slot 0 flags 0
> cardbus0 at cardslot0: bus 3 device 0 cacheline 0x8, lattimer 0xb0
> pcmcia0 at cardslot0
> pcib0 at pci0 dev 31 function 0 "Intel 82801DBM LPC" rev 0x01
> pciide0 at pci0 dev 31 function 1 "Intel 82801DBM IDE" rev 0x01: DMA, channel 
> 0 configured to compatibility, channel 1 configured to compatibility
> wd0 at pciide0 channel 0 drive 0: 
> wd0: 16-sector PIO, LBA, 35245MB, 72182773 sectors
> wd0(pciide0:0:0): using PIO mode 4, Ultra-DMA mode 5
> atapiscsi0 at pciide0 channel 1 drive 0
> scsibus0 at atapiscsi0: 2 targets
> cd0 at scsibus0 targ 0 lun 0:  ATAPI 
> 5/cdrom removable
> cd0(pciide0:1:0): using PIO mode 4, Ultra-DMA mode 2
> "Intel 82801DB SMBus" rev 0x01 at pci0 dev 31 function 3 not configured
> "Intel 82801DB AC97" rev 0x01 at pci0 dev 31 function 5 not configured
> "Intel 82801DB Modem" rev 0x01 at pci0 dev 31 function 6 not configured
> usb1 at uhci0: USB revision 1.0
> uhub1 at usb1 configuration 1 interface 0 "Intel UHCI root hub" rev 1.00/1.00 
> addr 1
> usb2 at uhci1: USB revision 1.0
> uhub2 at usb2 configuration 1 interface 0 "Intel UHCI root hub" rev 1.00/1.00 
> addr 1
> usb3 at uhci2: USB revision 1.0
> uhub3 at usb3 configuration 1 interface 0 "Intel UHCI root hub" rev 1.00/1.00 
> addr 1
> isa0 at pcib0
> isadma0 at isa0
> pckbc0 at isa0 port 0x60/5 irq 1 irq 12
> pckbd0 at pckbc0 (kbd slot)
> wskbd0 at pckbd0: console keyboard, using wsdisplay0
> npx0 at isa0 port 0xf0/16: reported by CPUID; using exception 16
> softraid0 at root
> scsibus1 at softraid0: 256 targets
> root on rd0a swap on rd0b dump on rd0b

fu: wdc_pcmcia and ATA mode

[leo_tck]

To: misc@openbsd.org
Subject: fu: wdc_pcmcia and ATA mode

I wrote:
> I'm to install OpenBSD on an old Thinkpad, but I first need to dump
> the curr hdd contents, using the install cd, to a large CF card, via
> a PCMCIA adapter.
>
> The pcmcia stuff is correctly detected by the kernel, but wdc_pcmcia
> only appears to access the device in pcmcia mode (1-sector PIO),
> killing performance. I'm sure the CF card supports ATA mode and DMA
> as it's been used in the past as an ATA device through (guess what)
> an appropriate adapter.

Okay, I got a little further with this, but it didn't resolve the issue.

The adapter is a TS0MCF2PC. I haven't been able to open it up (glue is
involved and I simply don't have a thin enough screwdriver or knife to
avoid breaking the plastic). The flash card I used during the above is
an old SanDisk SDCFB 256M; it was for testing, only. Yesterday the card I
actually intend to use arrived, a Transcend TS64GCF400.

However, even that card, which is specified to support 'UDMA7', is used
by OpenBSD in what NetBSD (I tried it just in case) appears to call 'i/o
mapped mode'. 'memory mapped mode' appears to be an option on the other
side of the fence (or bikeshed?) there, but the straightforward route
would IMO still be to treat the card as an ATA device.

This leaves me with two concrete questions:

1) Does the cbb actually allow the card to work in ATA mode?
2) If so, why does OpenBSD not support it?

Perhaps, with help (I find modern kernels *slightly* overcomplicated, so
I'm bound to get some things wrong), I can then provide a patch to at
least work around this issue.

dmesg output will be provided later today (not via the 10-finger
interface ).

--schaafuit.

fu: re: spam

[leo_tck]

*curses* this pos webmail poop hid from me that that was a private msg,
so I sent to the list. grrr!

another reason to drop the matter, though :/

--schaafuit.

re: spam

[leo_tck]

choc...@jtan.com wrote:
> Excuse me, I apologise to butt in on what clearly of great importance to
> the future development of OpenBSD but I've not really been paying this
> argument much attention and I want to clear something up.
>
> Is this farce all because you're upset that a machine insulted you?

No, I just referenced it in passing. Some people took even greater
offense at my offense, and then it exploded like that.

Which wasn't my intention *shakes head*.

Although, of course, in the end, computers don't insult -- people do.

Though both are machines, for sure :)

I sent apologies to the people concerned, so to anyone reading this: can
we please drop the matter in public, now? Not 'cause I'm done arguing
(am I ever? ), but 'cause Matthew is right -- it's too noisy.

--schaafuit.

fu: spam (was: re: code duplication)

[leo_tck]

I wrote:
> Look at the uproar it created here...

Okay *sigh*, I can see how this can be misinterpreted; what I meant was
that someone offended (in this case somewhat unwittingly) created the
uproar, specifically, me.

I'm never too good to shoot flak at myself, don't worry...

--schaafuit.

spam (was: re: code duplication)

[leo_tck]

Hi,

bytevolc...@safe-mail.net wrote:
> Just a tip from an outsider.

Those are always more than welcome :)

> I would suggest you show a little sympathy for those who are getting
> spammed by useless Nigerian scammers, cryptovirus authors, and the
> like, claiming to be some kind of "Head of Financial Business
> Management Department Business Managing Director" or some other sort of
> made up title.

Yeah, that's why I normally use a maildir w/ a notification filter -- I
don't get alterted if the message contains certain terms. And at the end
of the day, it's easy to get rid of such messages using something along
the lines of 'fgrep | cut | xargs rm'.

Having to go through them with mail(1) must be a real horror...

> It would do you a lot better than whinging over a generic piece of text
> that wasn't directed specifically towards you anyway, and then calling
> people names,

That's your misconception, right there. I called the machine a jerkass,
and whether its admin is or not remains to be seen (I sent him an
apology, just in case he indeed took it personally, but I'm still
awaiting a potential answer).

> then whinging when your behaviour gets called out.

Lesson: never configure a public machine to misbehave. People might be
trying to get work done and take offense if they're stopped in that rude
manner (just a huge delay, 'permission denied' and closing the connection
would've IMO certainly sufficed).

Look at the uproar it created here...

> If I received the same piece of text, the first thought would be that
> at least the OpenBSD mailing list maintainer thinks the same way as I
> do about spammers.

That they should die in hell, or worse? Sure I agree! But not at the
expense of breaking e-mail in any manner. Then the forces of evil just
win.

> I even had a recent spammer impersonate Theo de
> Raadt!

That doesn't sound like a spammer to me, that sounds personal. Was it
in bulk?

> This is why the OLPC rubbish that went on about a decade ago did not
> sit well with me.

'cause every child might be a potential suicide bo^W^Wspammer? :X

Though I agree w/ you that it's rubbish.

--schaafuit.

re: code duplication

[leo_tck]

Hi,

dera...@openbsd.org wrote:
> Then please demonstrate your sensitivity by stopping use of the
> OpenBSD project's mailing lists.

Oh? Who's the thin-skinned one, now?

> Obviously what I'm saying isn't a personal insult.

I didn't even know his name, still don't know his e-mail addr, and
certainly didn't send a message to postmaster yelling at him that he's
a jerkass. I just referred, in passing, to his mail swerver's behavior.

That is all. 

> I just came
> to the conclusion you are a loudmouthed jackass.

Okay, if I infer what you mean correctly: no, I did not mean that Todd
is necessarily a complete jerkass, just 'cause he (indirectly) behaves
to me that way, just once.

I thought that was clear. Since it obviously is not, I apologize.

> So go away.

*shrugs* I suppose I can forget about you taking a look at my problems
with the wdc_pcmcia code, then.

--schaafuit.

re: code duplication

[leo_tck]

Hi,

schwa...@usta.de wrote:
> there isn't the one answer that fits all situations.
>
> The goal in this respect is simplicity and maintainability.

Yup.

> Often, it is simpler to maintain two copies of similar code.
> For example, the libc and kernel implementations of malloc(3)
> and malloc(9) are distinct. Reacharound between kernel and
> userland sources is usually a bad idea, causing #ifdefs,
> confusion, and bugs, but not simplicity.

In case of system routines like malloc() the seperation is not only
justifiable: it's obvious, at least to a degree. In general, any
routines that use syscalls would have to be excluded in the first
place :)

> Duplicate code *is*
> maintainable if you don't overdo it.

Yeah, and if it's fairly obvious where other copies would reside.

> When a new type of bug
> is found, OpenBSD developers have a habit of scanning the complete
> tree to see whether similar bugs lurk at other places, too.

I'm very much aware of that :)

> Often, it is simpler to create a library for functionality that has
> become stable enough and that has come into use at many places.
> For example, the imsg functions - see imsg_init(3) - were moved
> into libutil in 2010, after several years of development and
> stabilization. A smaller, more recent example is the reallocarray(3)
> family of functions in libc.

I don't know 'imsg', but reallocarray(3) is a clear example of a routine
that's useful to many diff programs, and should thus be externally
available.

> But making something a library doesn't always simplify things.
> Layering and abstraction often increase complexity. Sooner or
> later, you detect duplication inside your library, so you make
> it use a library which in turn uses a library. CPAN style
> interminable dependency chains are not simplicity. Or just
> look at the maze of libraries in FreeBSD.

A modern solution would be to ditch archive-style libraries altogether
and store the individual objects in seperate files. Though while that
would certainly help against dependency hell, it wouldn't quite be a
guarantee of its elimination...

> Everybody has to learn POSIX anyway.

Not that POSIX can't have it wrong though... *cough*

> But if you invent hundred
> additional interfaces abstracting combinations of functionality
> that you need here and there, people who want to read and maintain
> code suddenly have to learn 100 more interfaces. That is not
> necessarily simpler.

Of course not. Though if the set of library objects follows a consistent
naming scheme, and the manual pages are all there, it might not be so
bad.

The thing I'm really wary of is preprocessor macros. Even with a manual
page, I more than often find '$x expands to $y' to be a sign of
impending trouble. Especially if they're nested... 

> It really depends on the situation, and the balancing act between
> abstration and duplication needs experience and taste, not rigid
> principles.

Depends on how you define 'rigid principles'. A set of good working
and organizational habits, based on experience, can certainly be
beneficial. As long as it doesn't turn our craft into a religion...

> P.S.
> There is no good reason to insult Todd

I don't know him, I might've heard of him once. Needless to say, the
insult obviously wasn't personal.

> for running spamd(8), which
> is a standard tool and less annoying than some others.

How do you find 'Hello, spam sender. Pleased to be wasting your time.'
anything but a grave insult to someone who takes the trouble to manually
send e-mail?

> Managing
> completely open mailing lists is a very difficult, a tiresome, and
> a thankless job, in particular for popular lists like the OpenBSD
> ones, and i'm quite glad the service has been running so smoothly
> all these years.

I do appreciate that, and I don't complain much if messages get delayed
because of it.

But when I take the time and effort to not bother people with mangled
subject lines, and I'm just called a spammer and effectively dismissed,
then I call the responsible admin a jerkass for it.

'cause that's the feeling it evokes in me, even if it's through the
machine.

--schaafuit.

RE: code duplication

[leo_tck]

Hi,

rauldmil...@gmail.com wrote:
> On Sat, Aug 26, 2017 at 4:36 AM,   wrote:
>> The greater the body of code is, the smaller our understanding, or at
>> least our ability to grok the code.
>>
>> Even in the UNIX world, 'duckspeak' code -- just doing what seems right
>> without realizing the longer-term implications -- is unfortunately very
>> common.
>>
>> I don't think that we can really afford that in the modern world.
>
> Could you be more specific?

Lack of foresight. (I hope that indeed qualifies as 'more' specific and 
not 'less'...)

> What problem are you trying to solve?

Not a single, discrete one. More like a range of potential problems that
are, from my pov, just sitting there, waiting to manifest themselves.

As fun and useful as it must've been (it predates me! :), we're no
longer just playing research on PDPs. The margin of error has decreased
enormously since then. How many people use OpenBSD in their firewall? I
suppose many. Apart from the inconvenience of applying patches, do we
really want to take the risk of sites getting pwned just 'cause we fixed
a problem in one place and not in another? And that's just security.

Any bit of code is only as decent as the assumptions of the programmer.

Isn't it a *little* too easy to assume, that we know what we're doing?

I suppose that what I propose, is that we be more sceptical of our own
abilities, and act accordingly. By taking into account the flaws of
wetware: we're relatively good at invention, but relatively lousy at
verbatim repetition. We're good at quick-and-dirty workarounds, but
long-term solutions take us a lot more effort (not that they're not
worth it! :).

A well-designed computer can complement our capabilities. It cannot
replace our capabilities, nor can we replace the computer's. To try to
do either would be foolish.

But then again, we're all fools in the end, anyway =)

And then there's the issue of us limiting ourselves to operate within
the designs we ourselves create...

Sorry if this all sounds trivial, but given the state of a typical piece
of (even UNIX) code, I'm reminded of this stuff everyday.

I thought it wouldn't hurt to share it.

--schaafuit.

FU: RE: code duplication

[leo_tck]

Sorry for the tyop in the subject line, boy will I be glad to get rid of
this $#@$%&! webmail poop that doesn't know how to send a proper
reply...

Of course, to add insult to injury, I can't manually send the messages
either, as the openbsd.org mail swerver decides, on connection, that I'm
sending spam and proceeds to try to 'waste my time' by eating my
message... rrright, jerkass.

--schaafuit.

code replication (was: Re: Query regarding exec in mandocdb.c)

[leo_tck]

Hi,

rauldmil...@gmail.com wrote:
> But replication also gives robustness in the face of failure, so it
> can also be a security asset. Still an issue, just not a security
> problem. (Or, a problem, but for people trying to defeat security.)

Yes, but especially in cases of untested, new ways of doing things.

In other cases I'm not so sure the risk isn't more evenly balanced (in
which case I'd of course argue for less replication, for its other
benefits -- see below).

> That said, replication is intrinsic in the nature of computer
> programming. Patterns are useful and, therefore, replicated. But even
> more than that we start with a [relatively] small set of primitive
> instructions and build up from there.

There's another angle to consider: code size and complexity. Not for the
computer (though the compiler often gets a great deal less confused if
the code contains lots of calls than if it contains lots of actual
logic!), but for us, the programmers.

The greater the body of code is, the smaller our understanding, or at
least our ability to grok the code.

Even in the UNIX world, 'duckspeak' code -- just doing what seems right
without realizing the longer-term implications -- is unfortunately very
common.

I don't think that we can really afford that in the modern world.

> But getting rid of all replication is an impossible rabbit hole that
> you really do not want to go down.

One can, indeed, overdo things. But imnsho efforts to reduce replication
(or even writing such repetetetive code in the first place!) could be
turned up a notch or two :)

--schaafuit.

RE: Query regarding exec in mandocdb.c

[leo_tck]

[now I'm subscribed, might as well respond to some recent stuff from the
 archives...] 

321.geo...@gmail.com wrote:
> In mandocdb.c it appears cmp(1) and rm(1) are executed in a child
> process. It seems that if the logic from these programs were duplicated
> the pledge in mandocdb.c could be further restricted and even not bother
> with forking.
>
> Would such a change be pointless churn however? Both cmp(1) and rm(1)
> are simple programs and are pledge'd themselves. Not to mention the
> creation of the mandoc database is in itself a short lived process.
>
> To be clear I'm not proposing a change (indeed I have no diff) but
> rather I am simply curious to the opinion of others in the OpenBSD
> community.

Okay, in that case, please forgive me if I go off on a little bit of a
tangent.

I've used UNIX for quite a while now. Not being satisfied with just
using anything, I've (not deeply) poked at the luserspace internals
quite a bit over time.

Almost each time I read the source code of any UNIX program, whether it
came w/ the system or not, I find duplicated functionality.

As I see it, this is not just inefficient, but also a huge security
issue: if the same operation is stated differently in many different
places, how can we make sure that we squash all instances of a
particular bad habit or bug?

The only real solution that I've come up w/ over time is to put the
actual logic in libraries and leave the programs to be luser interfaces
to that logic.

Perhaps something not quite so extreme is needed. I wouldn't know.

It would certainly make it easier to execute the suggestion you make in
the first paragraph of your message.

--schaafuit.

[so, the spacing issue does not appear today, but the subject lines
 are fscked. g!]

wdc_pcmcia and ATA mode

[leo_tck]

Hi,

I'm to install OpenBSD on an old Thinkpad, but I first need to dump
the curr hdd contents, using the install cd, to a large CF card, via
a PCMCIA adapter.

The pcmcia stuff is correctly detected by the kernel, but wdc_pcmcia
only appears to access the device in pcmcia mode (1-sector PIO),
killing performance. I'm sure the CF card supports ATA mode and DMA
as it's been used in the past as an ATA device through (guess what)
an appropriate adapter.

Inspection of the source code appears to reveal that there's a rather
strict separation between wdc_pcmcia and (the presumably needed)
wdc_isa. Is this true?

Can I somehow safely force wdc_isa to attach instead of wdc_pcmcia, or
otherwise have OpenBSD have operate the card in ATA mode?

dmesg output has to be routed through the 10-finger interface and will
thus be provided only on request :)

Please understand that the situation is complicated by not having a
running OpenBSD install around (the whole point is to fix that!).

Nevertheless, I'm of course willing to try 'patches' in the form of
i386 CD boot images. If truly needed I can of course dump the hdd
contents through a certain terminal emulator developed in Helsinki,
but I'm sure you understand that I'd rather avoid that...

Thanks in advance for any insight or effort,

--schaafuit.

P.S.: Since I'm not currently subscribed to this mailing list, courtesy
  copies are very much appreciated. Also apologies for any broken
  spacing, this is currently beyond my control and will be fixed in
  the future.

wdc_pcmcia and ATA mode

[leo_tck]

[I sent this earlier w/o being subscribed, but I gather that the (imo
 fascist) anti-spam measures have eaten it, so here again it goes...]

Hi,

I'm to install OpenBSD on an old Thinkpad, but I first need to dump
the curr hdd contents, using the install cd, to a large CF card, via
a PCMCIA adapter.

The pcmcia stuff is correctly detected by the kernel, but wdc_pcmcia
only appears to access the device in pcmcia mode (1-sector PIO),
killing performance. I'm sure the CF card supports ATA mode and DMA
as it's been used in the past as an ATA device through (guess what)
an appropriate adapter.

Inspection of the source code appears to reveal that there's a rather
strict separation between wdc_pcmcia and (the presumably needed)
wdc_isa. Is this true?

Can I somehow safely force wdc_isa to attach instead of wdc_pcmcia, or
otherwise have OpenBSD operate the card in ATA mode?

dmesg output has to be routed through the 10-finger interface and will
thus be provided only on request :)

Please understand that the situation is complicated by not having a
running OpenBSD install around (the whole point is to fix that!).

Nevertheless, I'm of course willing to try 'patches' in the form of
i386 CD boot images. If truly needed I can of course dump the hdd
contents through a certain terminal emulator developed in Helsinki,
but I'm sure you understand that I'd rather avoid that...

Thanks in advance for any insight or effort,

--schaafuit.

P.S.: Apologies for any broken spacing, this is currently beyond my
  control and will be fixed in the future.