fu^3: wdc_pcmcia and ATA mode

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

re: Thinkpad R40 varia

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

re: Thinkpad R40 varia

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

fu: Thinkpad R40 varia

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

fs level 0

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

fu^2: Thinkpad R40 varia

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

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

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: >

re: fs level 0

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

RE: Switching swap partition

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

RE: Switching swap partition

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:

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

"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.

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

"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: amd64 OpenBSD 6.2 doesn't see hard disks when controller in RAID mode

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

RE: Increase swap size on a running instance

i...@nuemak.com wrote: > There seems to be no man page for "fooswap" :) Then write one! =) --schaafuit.

wdc_pcmcia and ATA mode

[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

RE: Query regarding exec in mandocdb.c

[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

wdc_pcmcia and ATA mode

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),

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

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

RE: code duplication

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

FU: RE: code duplication

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

re: code duplication

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)

re: code duplication

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

fu: spam (was: re: code duplication)

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...

re: spam

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

spam (was: re: code duplication)

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

fu: re: spam

*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.

wdc(4) caps probe & print

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)

fu: wdc_pcmcia and ATA mode

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

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

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: >

Thinkpad R40 varia

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

fu^2: wdc_pcmcia and ATA mode

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 >

RE: Tar and bzip2 maximum compression

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: Tar and bzip2 maximum compression

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

size of size_t

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

FU: size of size_t

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.

RE: size of size_t

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

RE: FU: size of size_t

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

RE: RE: size of size_t

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

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

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: FU: size of size_t

theo wrote: > > Time to begin buffing the 'd' key. Learning never ends, does it? --schaafuit.

RE: size of size_t

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.

RE: size of size_t

"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

RE: ASLR: How Robust is the Randomness?

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?

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.

RE: ASLR: How Robust is the Randomness?

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

RE: ASLR: How Robust is the Randomness?

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*.

obligatory leaving letter

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

RE: Hellos from the Lands of Norway.

"Ywe Cærlyn" wrote: > Palmleaf, schaafuit? Ask the Catholic church. --schaafuit.

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

Okay folks, it's a troll alright. /thread. --schaafuit.

RE: Hellos from the Lands of Norway.

"Sterling Archer" wrote: > P-p-palmleaf schaafuit? A-a-ask the Catholic church. --schaafuit.

RE: Image viewer alternative to eog

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 :^)

RE: Hellos from the Lands of Norway.

"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.

FU: RE: Hellos from the Lands of Norway.

I wrote: > "Sterling Archer" wrote: which sould've been: > "Ywe Cærlyn" wrote: But /thread, really. --schaafuit.

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

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: kernel reordering and config -e

"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

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

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

tar bombs (was: RE: Abort Trap question)

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

RE: kernel reordering and config -e

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 >

RE: kernel reordering and config -e

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 >

RE: kernel reordering and config -e

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: The "like" factor

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

FU: RE: The "like" factor

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

"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

RE: The "like" factor

"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.

RE: The "like" factor

"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

RE: The "like" factor

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

RE: The "like" factor

"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

RE: The "like" factor

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

RE: The "like" factor

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

RE: The "like" factor

"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

RE: FOSDEM 2018 - Distributions Devroom Call for Participation

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

RE: FOSDEM 2018 - Distributions Devroom Call for Participation

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

RE: FOSDEM 2018 - Distributions Devroom Call for Participation

*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.

blaat

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

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

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

re: obligatory leaving letter

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

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

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

RE: Why is no one discussing this anymore?

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

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

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

unsubscribing

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!

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

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

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

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,

devel/cmake

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

www/lynx

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

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

[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

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

[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

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

[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