06:47:22 <tsoome_> I really fail to see why we are still keeping those bits in gate, which are replaced by every (all?) illumos based distributions.
10:17:35 <yuripv> which bits?
10:24:48 <tsoome> like vi, lp, sendmail, csh, curses maybe?
10:27:23 <yuripv> burn them all
10:27:40 <tsoome> :D
11:42:27 <Agnar> not burn, but put them in another gate or leave it to the distros
12:06:59 <denk> burn them on a dvd to send it on the Moon for the future
13:30:42 <sjorge> denk we should not taint the moon with those
14:12:19 <Agnar> 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 ;)
14:12:43 <Agnar> distros don't have to include it anyway
14:15:26 <yuripv> what's the real difference between vi and vim for you?
14:15:59 <Agnar> multiple undo makes me mad, so as the macro recorder I often accidentally stumble into
14:16:17 <yuripv> wonder if `vim -C` takes care of that
14:16:28 <Agnar> and I can't remember how to turn off auto-indent for yaml :)
14:16:38 <Agnar> yuripv: unfortunately not :)
14:17:04 <Agnar> that's why I have /usr/has/bin very early in $PATH :)
14:17:06 <yuripv> it seems to get rid of multiple undo, at least
14:17:54 <yuripv> i must admit i didn't ever run shipped vi in illumos (i do in freebsd though)
14:18:19 <Agnar> I use vi if it needs to be fast, otherwise emacs :)
14:19:56 <yuripv> in any case, vi is not the worst (actually far from that) cruft found in the tree
14:22:47 <Agnar> agree
14:23:14 <Agnar> csh should be buried. deep below. because it's not only dead, it started smelling aweful 20y ago already
14:23:36 <Agnar> ;)
14:23:50 <paulf> still use ksh at home
14:24:40 <Agnar> same here
14:24:58 <paulf> too much bother at work, csh was the default for donkeys years and lots of scripts only available for csh
14:26:01 <Agnar> SAP? ;)
14:26:23 <paulf> No, Siemens
14:26:39 <Agnar> ah, that would have been my second guess :)
14:27:28 <rmustacc> The best way to make sure the things you care about stay around is to help improve them and make them 64-bit clean.
14:28:00 <Agnar> rmustacc: good avise, you are right.
14:28:32 <jbk> heh.. some things never change i guess
14:28:44 <rmustacc> 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.
14:29:06 <jbk> siemens telecom (no idea where that division is now) had a product called an 'FFP' (fast feature platform) that ran on sparc 20s
14:29:11 <jbk> and heavily used csh as i recall
14:29:13 <rmustacc> There's unlikely to be some separate gate that the project maintains for things we've decided we're not maintaining, though anyone can.
14:29:53 <Agnar> rmustacc: well, my idea was more or less a "retirement" repo
14:30:50 <Agnar> 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
14:32:21 <Woodstock> easier than just fixing it in gate?
14:32:59 <Agnar> Woodstock: nah, just instead of "just dropping it from gate"
14:33:52 <Woodstock> how about not dropping it, but disabling it just on platforms where it is known to be broken?
14:34:07 <Agnar> 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...
14:34:16 <Agnar> Woodstock: also a good idea
14:44:42 <jbk> i don't know.. sometimes dealing with that ancient code, alcohol can be a useful assistant :)
14:45:27 <Agnar> well, it was easier for me to touch last(1) and sar(1m) when being sober ;)
18:38:33 <jbk> rmustacc: i'm wondering if this might be worth an explanation in mac_intr(9S)... if i can explain it well...
18:39:02 <jbk> it's suggested from the man page that mac will handle enabling/disabling interrupts for a ring
18:39:21 <jbk> except it appears (unless something else is goofy), it doesn't do that after starting a ring
18:39:49 <jbk> so the mac ring's start function would need to do that initially
18:41:05 <jbk> 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
18:41:09 <jbk> ?
18:48:19 <jclulow> 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
18:48:26 <jclulow> so, I would expect to start in interrupt mode
18:56:23 <rmustacc> 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.
18:57:27 <rmustacc> MAC handles dynamic toggling, but it's expected you get all the basics enabled.
18:59:46 <rmustacc> But we can certainly make it better regardless.
19:00:10 <rmustacc> And yes, everything starts in interrupt mode.
21:40:25 <tsoome> variables min and max: int64_t min, int64_t max; if (max > INT64_MAX || min < INT64_MIN).... 
21:55:57 <richlowe> sometimes neither our belt nor braces fit properly
21:56:11 <richlowe> speaking of which do any of you know ldap internals fairly well?
21:56:21 <richlowe> snoop does: offset = 1+ tag&0x007f;
21:56:30 <richlowe> and I am far from sure they understood the precedence of that
21:56:37 <richlowe> or even whether they thought the weird spacing helped
21:56:57 <richlowe> /* length is multiple octet.  */
21:56:57 <richlowe> offset = 1+ tag&0x007f;
21:58:24 <richlowe> 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
23:44:19 <sommerfeld> I believe ldap uses ASN.1 BER
23:44:45 <richlowe> those are not words I'd hoped to hear, but that sounds familiar.
23:45:21 <danmcd> He's right.  :(
23:45:44 <sommerfeld> IIRC 1 byte tag, then a variable-length length, then bytes.
23:50:51 <sommerfeld> 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.
23:53:14 <richlowe> that seems like they wanted `1 + (tag & 0x7f)` then?
23:53:20 <sommerfeld> yes
23:54:00 <richlowe> "oops"
23:55:55 <sommerfeld> unclear how much trouble this could cause.
23:56:11 <richlowe> I'd like to paste this into the bug I'm filing, if nobody minds?
23:56:19 <sommerfeld> go for it.
23:59:00 <richlowe> I filed #15919 (fenix?) but lack the network environment to do much about it at the moment.
23:59:01 <fenix> BUG 15919: snoop LDAP decoding has precedence confusion (New)
23:59:01 <fenix> ↳ https://www.illumos.org/issues/15919