I really fail to see why we are still keeping those bits in gate, which are replaced by every (all?) illumos based distributions.

which bits?

like vi, lp, sendmail, csh, curses maybe?

burn them all

:D

not burn, but put them in another gate or leave it to the distros

burn them on a dvd to send it on the Moon for the future

denk we should not taint the moon with those

nah, we should keep it in a seperate repo. for example I can't get used to vim, I really prefer the old vi. I know that's probably not the taste of the masses, but nobody get's hurt to keep that thing ;)

distros don't have to include it anyway

what's the real difference between vi and vim for you?

multiple undo makes me mad, so as the macro recorder I often accidentally stumble into

wonder if `vim -C` takes care of that

and I can't remember how to turn off auto-indent for yaml :)

yuripv: unfortunately not :)

that's why I have /usr/has/bin very early in $PATH :)

it seems to get rid of multiple undo, at least

i must admit i didn't ever run shipped vi in illumos (i do in freebsd though)

I use vi if it needs to be fast, otherwise emacs :)

in any case, vi is not the worst (actually far from that) cruft found in the tree

agree

csh should be buried. deep below. because it's not only dead, it started smelling aweful 20y ago already

;)

still use ksh at home

same here

too much bother at work, csh was the default for donkeys years and lots of scripts only available for csh

SAP? ;)

No, Siemens

ah, that would have been my second guess :)

The best way to make sure the things you care about stay around is to help improve them and make them 64-bit clean.

rmustacc: good avise, you are right.

heh.. some things never change i guess

The reason they come up in contexts like this is folks are looking at archs like ARMv8 where aarch32 doesn't exist so inertia isn't enough for some things.

siemens telecom (no idea where that division is now) had a product called an 'FFP' (fast feature platform) that ran on sparc 20s

and heavily used csh as i recall

There's unlikely to be some separate gate that the project maintains for things we've decided we're not maintaining, though anyone can.

rmustacc: well, my idea was more or less a "retirement" repo

rmustacc: isolate it from gate in a clean way at least, so it can be built individually at that moment. that would make it easier for others to pick up

easier than just fixing it in gate?

Woodstock: nah, just instead of "just dropping it from gate"

how about not dropping it, but disabling it just on platforms where it is known to be broken?

but I might have the chance to spend some time in the next two weeks as my company will send me likely to Pakistan this saturday and they don't have alcohol...

Woodstock: also a good idea

i don't know.. sometimes dealing with that ancient code, alcohol can be a useful assistant :)

well, it was easier for me to touch last(1) and sar(1m) when being sober ;)

rmustacc: i'm wondering if this might be worth an explanation in mac_intr(9S)... if i can explain it well...

it's suggested from the man page that mac will handle enabling/disabling interrupts for a ring

except it appears (unless something else is goofy), it doesn't do that after starting a ring

so the mac ring's start function would need to do that initially

I get that enabling/disabling is used to switch to/from polling mode, but i guess maybe the disconnect is that (maybe?) a ring always starts in interrupt/non-polling

?

I know very little of the specifics, but I expect you wouldn't end up in polling mode unless we had decided it was valuable

so, I would expect to start in interrupt mode

jbk: We can probably add more; however, the 'Registering with MAC' section makes it clear that interrupts should be enabled as part of that sequence.

MAC handles dynamic toggling, but it's expected you get all the basics enabled.

But we can certainly make it better regardless.

And yes, everything starts in interrupt mode.

variables min and max: int64_t min, int64_t max; if (max > INT64_MAX || min < INT64_MIN)....

sometimes neither our belt nor braces fit properly

speaking of which do any of you know ldap internals fairly well?

snoop does: offset = 1+ tag&0x007f;

and I am far from sure they understood the precedence of that

or even whether they thought the weird spacing helped

/* length is multiple octet. */

offset = 1+ tag&0x007f;

and I feel adding the parens around the _actual_ precedence would be a grave mistake, given how unclear it is it's what they hoped it would be

I believe ldap uses ASN.1 BER

those are not words I'd hoped to hear, but that sounds familiar.

He's right. :(

IIRC 1 byte tag, then a variable-length length, then bytes.

ah, in this case "tag" is the first byte of the length. if the high bit is clear, the low 7 bits are the length. If the high bit is set, the low 7 bits are the length of the length in bytes.

that seems like they wanted `1 + (tag & 0x7f)` then?

yes

"oops"

unclear how much trouble this could cause.

I'd like to paste this into the bug I'm filing, if nobody minds?

go for it.

I filed #15919 (fenix?) but lack the network environment to do much about it at the moment.

BUG 15919: snoop LDAP decoding has precedence confusion (New)

↳ illumos.org/issues/15919