#
# devel/p5-Test-Command
#
# Take care,
#
# --zeurkous, Sat Oct 24 14:18:57 UTC 2020.
#
--- ..v/3.2.1/config.mk Mon Jul 22 18:26:34 2019
+++ config.mk Sat Oct 24 14:01:45 2020
@@ -4,9 +4,9 @@
app ?= 0
curl ?= 1
debug ?= 0
-exif ?= 0
+exif ?= 1
help ?= 0
-verscmp ?= 1
+verscmp ?= 0
ess space taken up by other devices), it likely won't help OP much.
--zeurkous.
--
Friggin' Machines!
> real mem = 3634733056 (3466MB)<<<<<<<<<<<<<<<<<<<<<<<<
> avail mem = 3552747520 (3388MB)<<<<<<<<<<<<<<<<<<<<<<<<<<<<
>[snip]
> spdmem0 at iic0 addr 0x50: 8GB DDR3 SDRAM PC3-12800
> <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
Good luck,
--zeurkous.
--
Friggin' Machines!
beta$ /usr/bin/aucat -r 44100 -h wav -i ewhist2.wav -o - | page hexdump -C
You won't see it in real-time, but since you're using a static input
(me'll presume that ewhist2.wav is *not* a named pipe :), that'll
hopefully not be a problem for you.
Cheers,
-peter
HTH,
--zeurkous.
"Martin Schröder" wrote:
> Am Do., 23. Apr. 2020 um 21:31 Uhr schrieb :
>> No problem. Would it be too crude a suggestion that we go back to the
>> content now...?
>
> You didn't provide any patch.
That is entirely correct.
--zeurkous.
--
Friggin' Machines!
your idiotic "me.."-words?
Fine, me'll try and keep the idiotic ones out.
> Thanks
No problem. Would it be too crude a suggestion that we go back to the
content now...?
--zeurkous.
--
Friggin' Machines!
esponses.
Weird, isn't it? Anyway, as this would appear to be quite OT, me'd
suggest we continue this (if at all) in private mail...
> Jan
Take care,
--zeurkous.
--
Friggin' Machines!
theo wrote:
> You made it all up.
That's an easy accusation, with an easy response: No, medid not make any
of it up.
--zeurkous.
--
Friggin' Machines!
s to
be taken for the one and universal truth.
Can we please just assume that Groot is mature enough to be able to form
his own view based on our individual contributions?
Me'd like that.
--zeurkous.
--
Friggin' Machines!
Then GPT entered the story to make the mess complete. But me'll remain
blissfully unaware of the inner workings of that particular clusterfsck,
if you don't mind ;)
It's no shame to be confused by this garbage. Almost all of us'd like
better, but for the above hysterical raisins, it's not
to w/ a passphrase of '0' (automagically read
from a file at boot), but that was just needlessly complicated.
Fixing vnd(4) to work on devices, or just adding a
'concat-of-1-volume' (perhaps call it 'L'ayer) "level" to softraid, is
what me'd recommend. But that doesn't seem to help Groot (right now).
Hope the above helps,
--zeurkous.
--
Friggin' Machines!
Then, other programs (like sndioctl)
> will be rejected by sndiod until chrome disconnects.
>
> Adding the full cookie path wouldn't help as the directory doesn't
> exist yet.
>
> Hmm.
Yes, "Hmm." is right. Aren't you badly duplicating NAS here...?
MIT-MAGIC-COOKIE-1! M
theo wrote:
> You don't know your place.
Your opinion is well-considered.
--zeurkous.
--
Friggin' Machines!
t belonging to the terminal that the kbd is attached to.
>
> You are welcome to stick with 6.6, or even a newer release.
TYCO.
> Know your place.
Yeah well, even w/ the best advice, some people just can't be helped.
--zeurkous.
--
Friggin' Machines!
t. It's been
done w/ midi(4), why not w/ audio(4)?
>> Any program using sndiod is intended to be used one user at a time for
>> obvious privacy reasons, this is quickly explained in the last
>> section of sndio(7).
>
> What are the chances that isn't the user on the USB bus?
>
> Requiring people to use doas? Honestly, I find that offensive.
Me, too. .
--zeurkous.
--
Friggin' Machines!
privacy reasons, this is quickly explained in the last
> section of sndio(7).
The privacy concern is legitimate; the solution you have implemented is
needlessly restrictive. At the very least, socket permissions can be
relied on to provide access control. root will ignore such permissions,
maki
),
thereby making {audio,video,...} an integral part of the system -- just
like it should be in 2020 (for fsck's sake).
Until then, the use case "UNIX" remains unhandled.
--zeurkous.
--
Friggin' Machines!
orking around the
security issues by having the relevant device nodes only accessible (and
Xorg(1) only executable) by me as a luser (via groups 'x11' and 'audio',
respectively).
Me's not propagating the above as a solution; yet, as a workaround, me's
found it to be a life-saver.
Take care,
--zeurkous.
--
Friggin' Machines!
.
--zeurkous.
P.S.: No patch for UNIX, at least from me: you folks'll have to do w/
me advice :)
--
Friggin' Machines!
the OpenBSD project.
Again, please calm down. Even if theo & co. can't be nice, *we* can be
nice and thus make things nicer for everyone.
Take care,
--zeurkous.
--
Friggin' Machines!
"zap" wrote:
> you think proprietary softwatre is secure as much as linux loves being
> shit.
>
>[and it just went downhill from there...]
Please calm down. Somtimes mefeels the way you do, so meunderstands...
however, me'd advise not to make a public scene.
position is not under attack (at least not by me).
--zeurkous.
--
Friggin' Machines!
lates to OpenBSD;
Doesn't it, really? Comparison w/ the outside world is on of the most
useful critical tools that me's aware of.
> it seems like
> you just want a pedestal to piss on others from. This is not that place.
Medidn't observe zap do that (at least not yet).
--ze
ns.
> Either way, I do have respect for you guys. Even if you don't realize it.
Mehasn't doubted that.
--zeurkous.
--
Friggin' Machines!
theo wrote:
> What do thsi have to with OpenBSD?
Drat. Someone discovered The Homoheterothropic Society for the
Intermezzanic! Mesupposes we'll have to disband.
--zeur.
--
Friggin' Machines!
ive-aggressive behaviour that theo just
displayed here would stop.)
Love && cuddles,
--zeurkous.
P.S.: Be careful what you wish for.
--
Friggin' Machines!
Haai,
mewrote:
> Cc'ing webmaster@ (assuming it exists).
That didn't go so well: a "mailing list expansion problem", apparently
on the side of mail.openbsd.org. Since it ain't an obvious rejection,
me's informed postmaster@.
--zeur.
--
Friggin' Machines!
"Durial EB" wrote:
> Still down for me.
Appears intermittent. Cc'ing webmaster@ (assuming it exists).
--zeurkous.
> On Sun, Apr 12, 2020 at 5:44 PM wrote:
>
>> > Hello.
>> >
>> > What happened to the openbsd.org?
>> > I seems
> Hello.
>
> What happened to the openbsd.org?
> I seems to be down for 10+ hours for now.
WFM. Empty your name swerver cache, it might help.
> Regards,
>
> Roman
--zeur.
--
Friggin' Machines!
ave to discover
those. After ~50 years.
(The issue could also be solved by giving names a special format (for
example, by underlining them) in order to distinguish them even w/
spaces present. Such an approach has other benefits as well, but has
nothing to do with UNIX-as-we-know-it.)
--zeurkous.
--
Friggin' Machines!
https://doomwiki.org/wiki/Absurd%20texture%20name%20in%20error%20message
>
> Seems some people don't understand URIs...
Seems like some people eat everything the WWW n00bs emit, right up to
and including a turd.
What's next? All list messages in quoted-unreadable? C'mon.
--zeurkous.
--
Friggin' Machines!
"Anton Karpov" wrote:
> Ty vseh zaebal.
Amen.
--zeur.
>
> On Sat, 11 Apr 2020 at 13:28, Nikita Stepanov
> wrote:
>>
>> Does Intel driver supports 3d acceleration?
--
Friggin' Machines!
Indeed no use replying, though. Let him learn to do his homework.
> Yours,
> Ingo
Take care,
--zeurkous.
--
Friggin' Machines!
"Nikita Stepanov"
> Why?
'Cause the sun went dry, and the flowers said "bye".
Nasty of them, isn't it?
--zeur.
> 1:34, 11 aprelya 2020 g., Nikita Stepanov
> :
--
Friggin' Machines!
"Nikita Stepanov" wrote:
> I found https://man.openbsd.org/man4/nv.4
Then WTH did you ask?
Nevermind; n00bs gonna n00b, meguesses.
--zeurkous.
--
Friggin' Machines.
Here, me's using the nnx stuff as a vehicle to point out design
problems in UNIX: as always, YMMV, and no ad intended).
> Rod.
Hope the above has enlightened,
--zeurkous.
P.S.: Please don't address misc@ blindly: instead, address it in 'To:'
or 'Cc:'.
--
Friggin' Machines!
ut-of-pocket, there are still other issues than money.
--zeurkous.
--
Friggin' Machines!
e
>> contingent of folk who don't get it.
>
> The word "string" is also found in the man pages of bcmp and memcmp.
> Wrote by that large contingent?
Hysterical confusion (akin to the 'tty' confusion: terminal or simple
serial port?). They would better be changed to speak of arrays.
> Rod.
Baai,
--zeurkous.
--
Friggin' Machines!
L. There's a large
> contingent of folk who don't get it.
As an example of what happens when folks don't get it: [0].
In general, me'd strongly suggest that we speak of an 'array' when it's
not zero-terminated (that again should be redundant information here,
but yeah).
Baai,
--zeurkou
equence of the unreliability of IP.
No reason to be a jerk, though.
HTH,
--zeurkous.
--
Friggin' Machines!
ate, and
are more likely to benefit from a multi-process model w/ carefully
thought-out boundaries, than from a shared-everything thread model.
While that need not be the case here, mestrongly suspects it is. Take
heed, and measure. Always measure.
Take care,
--zeurkous.
> -Otto
--
Friggin' Machines!
unning behind and did
that idea die?
> I will never propose this kind of solution to normal people. :-)
Thankfully, we're not normal here =)
>> --
>> Friggin' Machines!
>
> Oh no, it is not the machines. It is their masters.
And their creators. The phrase is from an old Quake map that me's long
since forgotten the name of.
--zeurkous.
--
Friggin' Machines!
installing and
maintaining a load of overweight, clumsy, not-very-UNIXy packages *just*
to do the occasional javashit-bloated thing.
Just me half-stiver :)
--zeurkous.
--
Friggin' Machines!
st the patch below in more
> depth and commit it? Or do people consider this bloat?
While mecan see much merit in both sides of the argument, me'd say:
can't hurt, will help people, go!
> Yours,
> Ingo
Baai,
--zeurkous.
--
Friggin' Machines!
and will
> not result in anything that is usable to run UNIX software.
Then me'd say that it's high time the relevant standards are updated to
reflect that reality.
The latter is, of course, outside the purview of OpenBSD. (But we can
set a good example.)
Thank you.
Baai,
--zeurkous.
--
Friggin' Machines!
ence of the types.
Which, as you pointed out, does not affect OpenBSD (at this time), yet
might be a portability issue. Hence me raising it.
Baai,
--zeurkous.
--
Friggin' Machines!
OpenBSD. You must be confusing it with NetNIX, which is the
OS that will eventually emerge.
NetNIX will not have size_t.
Baai,
--zeurkous.
[0] Except, of course, it's an 'offset + 1'. Oops. But that's the least
of the problems if SIZE_MAX is not guaranteed to be the highest
address...
--
Friggin' Machines!
change to struct iovec?
--zeurkous.
--
Friggin' Machines!
ZE_MAX being an arbitrary value, with
no specified relation to the highest address, makes some compat code
pretty messy. Hence mehoped that there was some kind of guarantee; megot
the answer mefeared.
Thanks, your answer was quite helpful.
Baai,
--zeurkous.
--
Friggin' Machines!
advance,
Baai,
--zeurkous.
--
Friggin' Machines!
Fsck, me sleepy head typed 'isc' instead of the intended 'ajordomo'...
Suffice is to say that mehad enough of the bickering for a while.
--zeur.
--
Friggin' Machines!
please to quote "struct blaat" so that the underlining will be
unbroken (at least in the future, should the macros be fixed).
> Maybe i should suggest a stricter wording for .Vt and .Va in mdoc(7)
> and groff_mdoc(7) and maybe we should improve existing manuals.
> But it
"as long as it looks good on my
terminal" approach hadn't completely sunk in yet. But as it'll be 2020
in a matter of days, we really ought to either honor its basic ideas, or
come up with something better.
The latter could take the form of a generic C pretty-printer that can be
called as a roff macro, and produces roff output.
> Yours,
> Ingo
Baai,
--zeurkous.
--
Friggin' Machines!
[not subscribed, please Cc, thanks.]
theo wrote:
> wrote:
>
>> [not subscribed, please Cc, thanks.]
>>
>> theo wrote:
>> > wrote:
>> >
>> >> [not subscribed, please Cc, thanks.]
>> >>
>> >> theo wrote:
>> >> > wrote:
>> >> >
>> >> >> [not subscribed, please Cc, thanks.]
>> >> >>
>> >> >> "Jason
[not subscribed, please Cc, thanks.]
theo wrote:
> wrote:
>
>> [not subscribed, please Cc, thanks.]
>>
>> theo wrote:
>> > wrote:
>> >
>> >> [not subscribed, please Cc, thanks.]
>> >>
>> >> "Jason McIntyre" wrote:
>> >> >
>> >> > hi. the "asix chipset" bit seems unneccessary, since the driver
[not subscribed, please Cc, thanks.]
theo wrote:
> wrote:
>
>> [not subscribed, please Cc, thanks.]
>>
>> "Jason McIntyre" wrote:
>> >
>> > hi. the "asix chipset" bit seems unneccessary, since the driver is only
>> > for asix chips (as far as i can tell) and quickly skimming online fails
>> >
ses like:
.Vt "struct blaat" Va scaahp Ns Ic ";"
where the quotes are part of the invocation syntax.
--zeurkous.
> jmc
--
Friggin' Machines!
[not subscribed, please Cc, thanks.]
"Jason McIntyre" wrote:
>
> hi. the "asix chipset" bit seems unneccessary, since the driver is only
> for asix chips (as far as i can tell) and quickly skimming online fails
> to turn up such a model with a different chipset.
Dunno, there might well be a
upposes we're lucky in
this case...
...manual patch below.
--zeurkous.
Index: src/share/man/man4/axe.4
===
RCS file: /cvs/src/share/man/man4/axe.4,v
retrieving revision 1.45
diff -u -p -u -r1.45 axe.4
--- src/share/man/man4/axe
appears to have been fixed. Thanks!
--zeurkous.
--
Friggin' Machines!
Morning,
theo wrote:
> wrote:
>
>> That doesn't seem right. Did you folks use the wrong key when signing
>> the file, or is there a particular reason to do it this way that me's
>> not aware of...?
>
> These files have now been replaced. Does it look right?
Me's afraid not: SHA256.sig is now
That doesn't seem right. Did you folks use the wrong key when signing
the file, or is there a particular reason to do it this way that me's
not aware of...?
--zeur.
--
Friggin' Machines!
[not subscribed, please Cc, thanks.]
> OpenBSD 6.6 (GENERIC.MP) #304: Sat Oct 12 11:18:21 MDT 2019
> dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC.MP
> real mem = 3219472384 (3070MB)
> avail mem = 3145039872 (2999MB)
> mpath0 at root
> scsibus0 at mpath0: 256 targets
>
[not subscribed, please Cc, thanks.]
> OpenBSD 6.6 (GENERIC) #298: Sat Oct 12 11:06:10 MDT 2019
> dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC
> real mem = 3219472384 (3070MB)
> avail mem = 3145138176 (2999MB)
> mpath0 at root
> scsibus0 at mpath0: 256 targets
> mainbus0
(courtesy of me own
wscons(4) patches; see tech@).
Menever got the ipw(4) to work, but the seller (who ran windoze...)
warned me of that before the sale, so mefigures it's a hardware problem.
The R40 will now be used for odds and ends only, but it has certainly
served me well.
--zeurkous
[not subscribed, please Cc, thanks.]
> OpenBSD 6.6 (RAMDISK_CD) #294: Sat Oct 12 11:29:03 MDT 2019
> dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/RAMDISK_CD
> real mem = 3219439616 (3070MB)
> avail mem = 3151642624 (3005MB)
> mainbus0 at root
> bios0 at mainbus0: date 10/13/06,
Haai,
i...@openbsd.org wrote:
>
> Thank you for your dmesg, however, in the future would you mind sending
> these to dm...@openbsd.org instead of the mailing lists? dmesg@ is a
> special mailbox that will automatically add your dmesg to our archives
> in a more helpful way.
Of course, me's
[not subscribed, please Cc, thanks.]
OpenBSD 6.5 (GENERIC) #1338: Sat Apr 13 15:07:04 MDT 2019
dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC
real mem = 535707648 (510MB)
avail mem = 510660608 (487MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at
where the work becomes boring. Work that is
boring and yet has to be done, can be done by a computer. It is
therefore good that computers exist."
Amen.
--zeurkous.
--
Friggin' Machines!
[not subscribed, please Cc, thanks]
OpenBSD 6.5 (RAMDISK_CD) #1326: Sat Apr 13 15:26:51 MDT 2019
dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/RAMDISK_CD
real mem = 3066560512 (2924MB)
avail mem = 3001561088 (2862MB)
mainbus0 at root
bios0 at mainbus0: date 10/30/09, SMBIOS rev.
[not subscribed, please Cc, thanks.]
OpenBSD 6.5 (RAMDISK_CD) #1326: Sat Apr 13 15:26:51 MDT 2019
dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/RAMDISK_CD
real mem = 535752704 (510MB)
avail mem = 516853760 (492MB)
mainbus0 at root
bios0 at mainbus0: date 07/15/03, BIOS32 rev. 0 @
71 matches
Mail list logo
