Switch to DuckDuckGo Search
   June 15, 2020  
< | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | >


NOTICE: This channel is no longer actively logged.

Toggle Join/Part | bottom
[00:03:13] *** jamtorus <jamtorus!~quassel@s91904428.blix.com> has joined #illumos
[00:06:07] *** jellydonut <jellydonut!~quassel@s91904422.blix.com> has quit IRC (Ping timeout: 260 seconds)
[00:09:36] *** jellydonut <jellydonut!~quassel@s91904422.blix.com> has joined #illumos
[00:10:34] *** jamtorus <jamtorus!~quassel@s91904428.blix.com> has quit IRC (Ping timeout: 240 seconds)
[00:24:22] *** jamtorus <jamtorus!~quassel@s91904426.blix.com> has joined #illumos
[00:26:49] *** jellydonut <jellydonut!~quassel@s91904422.blix.com> has quit IRC (Ping timeout: 246 seconds)
[00:32:04] *** jellydonut <jellydonut!~quassel@s91904426.blix.com> has joined #illumos
[00:33:49] *** jamtorus <jamtorus!~quassel@s91904426.blix.com> has quit IRC (Ping timeout: 264 seconds)
[00:43:27] *** idodeclare <idodeclare!~textual@cpe-76-185-177-63.satx.res.rr.com> has quit IRC (Quit: My MacBook has gone to sleep. ZZZzzz…)
[01:25:36] <richlowe> LeftWing: yurip did some work on that too, as did I
[01:25:43] <richlowe> (all separately as far as I know)
[01:25:53] <richlowe> I think yurip's was pretty complete?
[01:26:59] <richlowe> You could also in the short term add symbol filters to libc for the important bits
[01:36:12] *** idodeclare <idodeclare!~textual@cpe-76-185-177-63.satx.res.rr.com> has joined #illumos
[01:44:09] *** sundbry <sundbry!495dd9a8@c-73-93-217-168.hsd1.ca.comcast.net> has joined #illumos
[01:47:21] <sundbry> I am seeing the strangest thing trying to run a dhcp server on an OmniOS server. Outbound UDP packets longer than 267 bytes are dropping.
[01:48:40] <sundbry> Tried with two different network cards thinking it could have been a driver issue. It just does not send udp packets larger than 267 bytes. I have a simple python program to reproduce it.
[01:49:28] *** dodobrain <dodobrain!~dodobrain@unaffiliated/freakabcd> has joined #illumos
[01:51:03] *** wl_ <wl_!~wl_@2605:6000:1b0c:4825::87c> has quit IRC (Quit: Leaving)
[03:20:53] *** ldepandis <ldepandis!~ldepandis@unaffiliated/ldepandis> has joined #illumos
[03:44:59] <rzezeski> sundbry: Interesting, I did a few quick tests on a fairly new kernel on OI and am noticing some UDP oddities that I can't quite explain. Though it seems to have nothing to do with packet size. Feel free to post a link to your python program or send it to me at ryan at zinascii dot com and I'll see what happens on my end.
[03:45:09] <rzezeski> But for now I need to step away for dinner.
[05:02:21] *** btibble <btibble!~brantibbl@c-69-94-200-89.hs.gigamonster.net> has quit IRC (Ping timeout: 265 seconds)
[05:30:51] <LeftWing> richlowe: I'd be happy with any approach that doesn't foreclose on future improvement, even if it's only a bit of the way there
[05:31:20] <LeftWing> I have just promised to do too many things already or I'd consider doing it myself
[05:34:08] *** arnoldoree <arnoldoree!~arnoldore@2001:d08:1829:d22b:2d86:a872:ebdd:53f3> has joined #illumos
[05:49:54] *** Tempt <Tempt!~avenger@unaffiliated/tempt> has quit IRC (Ping timeout: 260 seconds)
[05:51:31] *** Tempt <Tempt!~avenger@unaffiliated/tempt> has joined #illumos
[05:51:31] *** ChanServ sets mode: +o Tempt
[05:57:58] *** Tempt <Tempt!~avenger@unaffiliated/tempt> has quit IRC (Ping timeout: 258 seconds)
[06:17:18] *** Tempt <Tempt!~avenger@unaffiliated/tempt> has joined #illumos
[06:17:18] *** ChanServ sets mode: +o Tempt
[06:27:02] *** MilkmanDan <MilkmanDan!~dan@wilug/expat/MilkmanDan> has quit IRC (Ping timeout: 260 seconds)
[06:29:41] *** MilkmanDan <MilkmanDan!~dan@wilug/expat/MilkmanDan> has joined #illumos
[07:09:17] *** yuripv <yuripv!~yuripv@91.240.124.137> has joined #illumos
[07:09:46] *** BOKALDO <BOKALDO!~BOKALDO@87.110.91.190> has joined #illumos
[07:18:17] *** dodobrain <dodobrain!~dodobrain@unaffiliated/freakabcd> has quit IRC (Remote host closed the connection)
[07:42:05] *** ldepandis <ldepandis!~ldepandis@unaffiliated/ldepandis> has quit IRC (Quit: My MacBook has gone to sleep. ZZZzzz…)
[07:45:24] *** arnoldoree <arnoldoree!~arnoldore@2001:d08:1829:d22b:2d86:a872:ebdd:53f3> has quit IRC (Ping timeout: 256 seconds)
[07:47:58] *** yuripv <yuripv!~yuripv@91.240.124.137> has quit IRC (Ping timeout: 256 seconds)
[07:48:32] *** dodobrain <dodobrain!~dodobrain@unaffiliated/freakabcd> has joined #illumos
[07:52:05] *** eau <eau!~eau@unaffiliated/eau> has quit IRC (Remote host closed the connection)
[08:02:31] *** yuripv <yuripv!~yuripv@91.240.124.137> has joined #illumos
[08:06:17] *** eau <eau!~eau@unaffiliated/eau> has joined #illumos
[08:11:16] *** ldepandis <ldepandis!~ldepandis@unaffiliated/ldepandis> has joined #illumos
[08:20:02] *** neuroserve <neuroserve!~toens@ip-95-222-232-47.hsi15.unitymediagroup.de> has quit IRC (Ping timeout: 265 seconds)
[08:23:03] <sundbry> rzezeski: I sent you an email with my observations. Thanks for offering to take a look!
[08:31:01] *** tsoome <tsoome!~tsoome@bb3b-d7c1-53e4-5c10-2f80-4a40-07d0-2001.sta.estpak.ee> has quit IRC (Quit: My MacBook has gone to sleep. ZZZzzz…)
[08:45:15] *** alanc <alanc!~alanc@inet-hqmc02-o.oracle.com> has quit IRC (Remote host closed the connection)
[08:45:43] *** alanc <alanc!~alanc@inet-hqmc02-o.oracle.com> has joined #illumos
[09:06:44] *** melloc1 <melloc1!~codytimec@104.166.94.34> has quit IRC (Ping timeout: 256 seconds)
[09:07:00] *** melloc1 <melloc1!~codytimec@2607:3f00:11:24::3> has joined #illumos
[09:32:07] *** andy_js <andy_js!~andy@94.11.185.123> has joined #illumos
[09:44:08] *** joltman <joltman!znc@gateway/vpn/privateinternetaccess/joltman> has quit IRC (Ping timeout: 258 seconds)
[09:48:01] *** joltman <joltman!~znc@unaffiliated/joltman> has joined #illumos
[09:59:06] *** ptribble <ptribble!~ptribble@cpc92716-cmbg20-2-0-cust138.5-4.cable.virginm.net> has joined #illumos
[10:02:50] *** eau <eau!~eau@unaffiliated/eau> has quit IRC (Remote host closed the connection)
[10:05:05] *** eau <eau!~eau@unaffiliated/eau> has joined #illumos
[10:09:30] *** neuroserve <neuroserve!~toens@ip-94-114-236-221.unity-media.net> has joined #illumos
[10:17:00] *** kovert <kovert!~kovert@204.141.173.249> has quit IRC (Ping timeout: 265 seconds)
[10:17:41] *** roryrjb <roryrjb!rory@gateway/vpn/privateinternetaccess/roryrjb> has joined #illumos
[10:19:39] *** kovert <kovert!~kovert@204.141.173.249> has joined #illumos
[11:15:21] *** tsoome <tsoome!~tsoome@148-52-235-80.sta.estpak.ee> has joined #illumos
[11:36:11] *** roryrjb <roryrjb!rory@gateway/vpn/privateinternetaccess/roryrjb> has quit IRC (Quit: leaving)
[12:26:39] *** tsoome <tsoome!~tsoome@148-52-235-80.sta.estpak.ee> has quit IRC (Quit: My MacBook has gone to sleep. ZZZzzz…)
[12:36:15] *** liv3010m <liv3010m!~liv3010m@77-72-245-190.fibertel.com.ar> has quit IRC (Ping timeout: 258 seconds)
[12:38:05] *** liv3010m <liv3010m!~liv3010m@190.245.72.77> has joined #illumos
[12:58:13] *** nbhauke <nbhauke!~hauke@55d4869b.access.ecotel.net> has joined #illumos
[13:17:26] *** arnoldoree <arnoldoree!~arnoldore@113.210.95.110> has joined #illumos
[13:29:21] *** jcea <jcea!~Thunderbi@2001:bc8:2ecd:caed:7670:6e00:7670:6e00> has joined #illumos
[13:32:07] *** jcea <jcea!~Thunderbi@2001:bc8:2ecd:caed:7670:6e00:7670:6e00> has quit IRC (Remote host closed the connection)
[13:37:34] *** jcea <jcea!~Thunderbi@2001:bc8:2ecd:caed:7670:6e00:7670:6e00> has joined #illumos
[13:47:43] *** tsoome <tsoome!~tsoome@b59a-bdc3-1467-c467-2f80-4a40-07d0-2001.sta.estpak.ee> has joined #illumos
[13:48:22] *** arnoldoree <arnoldoree!~arnoldore@113.210.95.110> has quit IRC (Ping timeout: 256 seconds)
[13:56:34] *** clapont <clapont!~clapont@unaffiliated/clapont> has quit IRC (Ping timeout: 256 seconds)
[13:59:51] *** BOKALDO <BOKALDO!~BOKALDO@87.110.91.190> has quit IRC (Quit: Leaving)
[14:15:40] *** arnoldoree <arnoldoree!~arnoldore@113.210.65.129> has joined #illumos
[15:27:46] *** BOKALDO <BOKALDO!~BOKALDO@87.110.91.190> has joined #illumos
[15:29:08] *** arnoldoree <arnoldoree!~arnoldore@113.210.65.129> has quit IRC (Ping timeout: 258 seconds)
[15:41:32] *** arnoldoree <arnoldoree!~arnoldore@2001:d08:1812:bdf1:dbf0:d566:b48e:920b> has joined #illumos
[15:42:22] *** neirac <neirac!~cneir@pc-4-149-45-190.cm.vtr.net> has joined #illumos
[16:30:11] *** psarria <psarria!~psarria@74.red-79-146-99.dynamicip.rima-tde.net> has quit IRC (Read error: Connection reset by peer)
[16:42:15] *** xzilla <xzilla!~robert@pool-71-166-61-141.bltmmd.fios.verizon.net> has joined #illumos
[16:44:11] *** ldepandis <ldepandis!~ldepandis@unaffiliated/ldepandis> has quit IRC (Quit: My MacBook has gone to sleep. ZZZzzz…)
[16:50:41] *** ldepandis <ldepandis!~ldepandis@unaffiliated/ldepandis> has joined #illumos
[17:11:33] *** sundbry <sundbry!495dd9a8@c-73-93-217-168.hsd1.ca.comcast.net> has quit IRC (Remote host closed the connection)
[17:26:59] *** sjorge <sjorge!~sjorge@unaffiliated/sjorge> has quit IRC (Quit: 410 Gone)
[17:33:15] *** sjorge <sjorge!~sjorge@unaffiliated/sjorge> has joined #illumos
[17:53:06] *** dodobrain <dodobrain!~dodobrain@unaffiliated/freakabcd> has quit IRC (Ping timeout: 256 seconds)
[17:57:00] <vgusev_> LeftWing: I tried edit the ticket and Subject is still not editable. Could you check, illumos.org has two vgusev
[18:00:37] *** jellydonut <jellydonut!~quassel@s91904426.blix.com> has quit IRC (Quit: jellydonut)
[18:00:58] <vgusev_> probatly you assigned Developer profile to vgusev from @icloud
[18:01:14] <LeftWing> You have two accounts?!
[18:02:25] *** jellydonut <jellydonut!~quassel@s91904425.blix.com> has joined #illumos
[18:02:44] <yuripv> He should be fined.
[18:03:02] <yuripv> (Look who's talking now.)
[18:03:05] <LeftWing> lol
[18:04:02] <LeftWing> vgusev_: So, I assigned the role to the one you used to create the bug
[18:04:11] <LeftWing> If you have a second account can we please remove it so that you have just the one?
[18:05:13] <vgusev_> LeftWing: Yes, please remove gusev.vitaliy
[18:05:54] <LeftWing> Done! Thank you.
[18:09:04] *** patdk-lap <patdk-lap!~patrickdk@208.94.189.75> has quit IRC (Ping timeout: 246 seconds)
[18:10:12] <vgusev_> LeftWing: what if call the ticket "mdb segfaults if libc compiled with SEE2 optimisation" ?
[18:12:56] *** neuroserve <neuroserve!~toens@ip-94-114-236-221.unity-media.net> has quit IRC (Ping timeout: 256 seconds)
[18:15:09] <LeftWing> vgusev_: I would probably make it reflect what's going on; e.g., "setjmp must allow for 8 byte aligned buffer on amd64"
[18:15:57] <LeftWing> While the mdb thing is how folks noticed this, the actual issue is with the libc functions under the new compiler or compiler options
[18:16:04] *** neuroserve <neuroserve!~toens@ip-178-202-213-58.hsi09.unitymediagroup.de> has joined #illumos
[18:20:32] <vgusev_> LeftWing: But in case of "setjmp must allow..." it is not evident what is result and reason for "must".
[18:22:34] *** patdk-lap <patdk-lap!~patrickdk@wsip-68-14-235-202.ph.ph.cox.net> has joined #illumos
[18:24:00] <rmustacc> Huh? I thought it was the fact that you have a strucutre with one alignment that is being cast to a structure with a different alignment.
[18:24:16] <rmustacc> And the compiler assumes that when you're maniuplating the ucontext_t a pointer to it will be correctly aligned.
[18:26:24] <LeftWing> I mean, the "must" is because that's the ABI we've established
[18:35:51] *** ldepandis <ldepandis!~ldepandis@unaffiliated/ldepandis> has quit IRC (Read error: Connection reset by peer)
[18:44:45] <vgusev_> rmustacc: what name of the bug would you suggest ? :)
[18:46:41] *** psarria <psarria!~psarria@74.red-79-146-99.dynamicip.rima-tde.net> has joined #illumos
[18:47:26] *** btibble <btibble!~brantibbl@c-69-94-200-89.hs.gigamonster.net> has joined #illumos
[18:52:59] *** btibble_ <btibble_!~brantibbl@c-69-94-200-89.hs.gigamonster.net> has joined #illumos
[18:54:24] *** clapont <clapont!~clapont@unaffiliated/clapont> has joined #illumos
[18:55:45] *** brantibb <brantibb!~brantibbl@c-69-94-200-89.hs.gigamonster.net> has joined #illumos
[19:10:44] <ryao> Is there anyone here familiar with how mutexes work? Long story short, I was inspired to look into how pthread mutexes on Linux could be improved yesterday and I think I might have something with some more work. I asked in #gentoo-dev if anyone would care to review it when I had it working, but they referred me to the glibc mailing list. I was hoping to find a few people with whom to consult as I make more
[19:10:50] <ryao> progress before I start firing off mailing list emails.
[19:12:05] *** nbhauke <nbhauke!~hauke@55d4869b.access.ecotel.net> has quit IRC (Quit: nbhauke)
[19:12:58] <ryao> Basically, the way that the glibc pthread mutexes work is that if they are uncontended, they are just an atomic on lock/unlock. However, if they are contended, all thread blocked must do a syscall to wake up other sleepers. Furthermore, there is no ordering and even worse, a thread grabbing the lock at the right point can cut in front of every body that was waiting. Lastly, they keep hitting the same spot
[19:13:04] <ryao> in memory on all operations, so there are cache line contention issues.
[19:16:00] <ryao> I suspect that it is possible to do a mutex version of a MCS lock where the mutex is literally a single pointer and additional memory is used on the stacks of sleepers. Uncontested lock/unlock will only use an atomic while the last thread to unlock a lock that has no other waiters can avoid a syscall. A wait list would be implemented so that the blocking order is strictly FIFO. Furthermore, blocked threads
[19:16:05] <ryao> will be blocked on their own stacks, which avoids cacheline contention and is more NUMA friendly.
[19:16:18] <ryao> I sketched out most of a prototype algorithm to do it last night when I should have been sleeping.
[19:17:41] <ryao> Also, a guy from Microsoft hinted on the LKML that Microsoft had achieved something similar with their SRW locks, so it is likely possible. A quick read of their description of SRW locks and what I have almost finished sketching out suggests that they are similar, but different, as I am just thinking about mutexes at the moment.
[19:31:41] <jbk> https://grok.elemental.org/source/xref/illumos-gate/usr/src/lib/libc/port/threads/synch.c?r=48bbca81 has the main bits of the illumos libc implementation
[19:33:03] <jbk> i've dug in too deeply, so I could have things wrong, but i believe if contested, we spin for a short amoutn of time in the hope the lock's only held briefly, then fi that fails, we switch to waiting and put the thread on a queue
[19:34:34] <jbk> and if there are any threads queued, pick one off the queue and tell the kernel to wake it up
[19:34:57] <jbk> (I imagine mutexes shared across processes are probably more complex, so i'm just talking about ones in the same process)
[19:35:29] <jbk> so i think we have ordering
[19:36:14] <jbk> but i think we only need to take a trip through the kernel if we've held the mutex for a 'long' time (for some definition of long) to wakeup another thread
[19:36:52] <jbk> at which point, the overhead of doing that is (maybe?) noise compared to the amount of time blocked threads are waiting
[19:37:36] <jbk> but i'd encourage you to look over the code.. as I said, that's my basic recollection, and I might have gotten bits wrong, or missed some stuff
[19:38:49] <gitomat> [illumos-gate] 12571 pcisch: NULL pointer errors -- Toomas Soome <tsoome at me dot com>
[19:42:13] <ryao> jbk: It looks like this has all of the properties that I thought were possible to implment, although it uses more memory.
[19:43:04] <ryao> s/implment/implement/
[19:44:01] <ryao> I think it is possible to avoid `mmap()`.
[19:45:04] <jbk> aside from the size of mutex_t, which i don't think we can change without breaking every existing binary and library build on illumos, the rest of it i think is private, so it could be possible to change the innards to improve things
[19:47:06] <gitomat> [illumos-gate] 12546 pcieb: NULL pointer errors -- Toomas Soome <tsoome at me dot com>
[19:47:25] <rmustacc> It may be private, but it's also part of the ABI.
[19:47:37] <rmustacc> Because of the requirements of having the static initializers.
[19:49:26] <ryao> jbk, rmustacc: When I finish the algorithm, all I should need in the mutex_t will be a single pointer sized field that is initialized to NULL.
[19:50:11] <rmustacc> At the end of the day, you're looking at things for glibc, so not sure what we do really matters.
[19:50:27] <rmustacc> They'll have different requirements around the API and ABI and the opaqueness.
[19:50:33] <ryao> rmustacc: Well, it is a generic algorithm. I am happy to share it with everyone. :)
[19:51:05] <rmustacc> If you want to do the work, test it, and prove out the benefits, that'd be great.
[19:51:07] <ryao> Or would be... I almost finished it. I just need to handle one more edge case and it should work... I kind of have two other higher priority projects to do, but I wanted to try to find reviewers in advance.
[19:51:31] <rmustacc> But the proof will be in the pudding, as they say.
[19:52:06] <gitomat> [illumos-gate] 12796 pcks11_softtoken C_GetMechanismList() should validate its arguments -- Jason King <jason.king at joyent dot com>
[19:52:53] <ryao> Yeah. I was just hoping to find reviewers for the algorithm. I already found one from FreeBSD after asking here, so I should be good there, but I would love another set of eyes if anyone is willing to volunteer to be pinged.
[19:53:19] <ryao> Well, reviewers for the algorithm when it is finished. I wanted to ask in advance to hopefully get this out of my system so I can finish my other two higher priority projects...
[19:56:42] <ryao> jbk: It looks like there is some padding that could be used to retrofit the new algorithm if it works out: https://grok.elemental.org/source/xref/illumos-gate/usr/src/uts/common/sys/synch.h?r=fafb665d#79
[19:59:13] <ryao> By the way, another reason I am asking is that talking to a few reviewers privately is going to be much less embarassing if it doesn't work than a public spectacle of myself on a mailing list.
[20:03:05] *** nbhauke <nbhauke!~hauke@55d4869b.access.ecotel.net> has joined #illumos
[20:05:13] <ryao> Also, the irony of the spectacle in IRC that my excitement is creating is not lost on me. I have convinced myself that it is possible though, so all that is left is hopefully the busy work of actually getting a working prototype, coming up with some sort of proof, etcetera.
[20:07:58] *** Riastradh <Riastradh!~riastradh@netbsd/developer/riastradh> has quit IRC (Ping timeout: 256 seconds)
[20:12:44] *** nbhauke <nbhauke!~hauke@55d4869b.access.ecotel.net> has quit IRC (Quit: nbhauke)
[20:35:49] <vgusev_> LeftWing: updated https://www.illumos.org/rb/r/2565/
[20:45:19] *** IDoNotKn1w <IDoNotKn1w!epost@kudu.in-berlin.de> has joined #illumos
[20:45:19] *** IDoNotKnow <IDoNotKnow!epost@kudu.in-berlin.de> has quit IRC (Read error: Connection reset by peer)
[20:52:19] *** nbhauke <nbhauke!~hauke@55d4869b.access.ecotel.net> has joined #illumos
[20:54:33] *** Riastradh <Riastradh!~riastradh@netbsd/developer/riastradh> has joined #illumos
[20:56:14] <rmustacc> w/in 1
[20:59:16] <vgusev_> rmustacc: are you happy with rb/2565 or it needs something to be improved ?
[20:59:47] <rmustacc> I haven't had a chance to look at all your updates since you posted them this morning.
[21:10:09] *** ptribble <ptribble!~ptribble@cpc92716-cmbg20-2-0-cust138.5-4.cable.virginm.net> has quit IRC (Quit: Leaving)
[21:30:58] <vgusev_> rmustacc: I suspect you confused by gregset_t size substraction. But that is not related neither to fix nor to bug.
[21:32:51] <rmustacc> vgusev_: Perhaps. I've been wrong and confused countless times before and probably will be in the future.
[21:33:10] <rmustacc> It would explain why it felt like we were talking about two different things.
[21:34:55] <vgusev_> rmustacc: Good, thanks. Hope that is only issue during moving to -mtune=intel compiler option.
[21:35:45] <jollyd> I will keep building and running with -mtune=generic on testing machines
[21:35:59] <jollyd> I'll report if anything shows up
[21:36:57] <rmustacc> vgusev_: I mean, I think that's a different story.
[21:37:51] <rmustacc> Someone who cared should really look at major binary differences in things, tbh. It feels like this was just the last obvious one.
[21:38:01] *** liv3010m <liv3010m!~liv3010m@190.245.72.77> has quit IRC (Ping timeout: 264 seconds)
[21:38:16] <rmustacc> Given our history with gcc changes and the behaviours there and the bugs found.
[21:39:51] <rmustacc> And yes, it looks like I did confuse the gregset_t stuff. Sorry.
[21:40:51] *** deejam- is now known as deejam
[21:46:29] *** BOKALDO <BOKALDO!~BOKALDO@87.110.91.190> has quit IRC (Quit: Leaving)
[21:48:45] *** liv3010m <liv3010m!~liv3010m@77-72-245-190.fibertel.com.ar> has joined #illumos
[21:58:14] <LeftWing> Yeah I think changing the optimisation flags is as big a deal with respect to verification as changing the compiler version
[21:58:59] <LeftWing> The program text will almost certainly be completely different afterwards
[22:42:54] *** btibble <btibble!~brantibbl@c-69-94-200-89.hs.gigamonster.net> has quit IRC (Ping timeout: 240 seconds)
[22:43:11] *** brantibb <brantibb!~brantibbl@c-69-94-200-89.hs.gigamonster.net> has quit IRC (Ping timeout: 260 seconds)
[22:43:14] *** btibble_ <btibble_!~brantibbl@c-69-94-200-89.hs.gigamonster.net> has quit IRC (Ping timeout: 256 seconds)
[22:57:13] *** yuripv <yuripv!~yuripv@91.240.124.137> has quit IRC (Ping timeout: 264 seconds)
[23:09:53] <LeftWing> FYI: If you own the "illumos.dev" domain I'd love to speak with you!
[23:18:22] *** patdk-lap <patdk-lap!~patrickdk@wsip-68-14-235-202.ph.ph.cox.net> has quit IRC (Ping timeout: 256 seconds)
[23:30:13] *** wl_ <wl_!~wl_@2605:6000:1b0c:4825::87c> has joined #illumos
[23:30:22] *** patdk-lap <patdk-lap!~patrickdk@wsip-68-14-235-202.ph.ph.cox.net> has joined #illumos
[23:45:23] *** andy_js <andy_js!~andy@94.11.185.123> has left #illumos
top

   June 15, 2020  
< | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | >