[00:29:22] *** andy_js <andy_js!~andy@90.192.48.17> has quit IRC (Quit: andy_js)
[00:53:49] *** alp <alp!~alp@pyhalov.cc.rsu.ru> has quit IRC (Remote host closed the connection)
[00:57:26] *** makruger <makruger!~Michael@pool-108-20-232-57.bstnma.fios.verizon.net> has quit IRC (Ping timeout: 268 seconds)
[00:58:38] *** pjama1 <pjama1!~arnoldp@c211-31-52-41.kelvn3.qld.optusnet.com.au> has left #oi-dev
[01:01:36] *** alanc <alanc!~alanc@inet-hqmc03-o.oracle.com> has quit IRC (Remote host closed the connection)
[01:02:22] *** alanc <alanc!~alanc@inet-hqmc02-o.oracle.com> has joined #oi-dev
[01:02:22] *** ChanServ sets mode: +o alanc
[01:21:19] *** makruger <makruger!~Michael@pool-108-20-232-57.bstnma.fios.verizon.net> has joined #oi-dev
[01:56:28] *** makruger <makruger!~Michael@pool-108-20-232-57.bstnma.fios.verizon.net> has quit IRC (Ping timeout: 250 seconds)
[02:58:23] *** v_a_b <v_a_b!~volker@p5B371457.dip0.t-ipconnect.de> has quit IRC (Ping timeout: 245 seconds)
[03:01:57] *** v_a_b <v_a_b!~volker@p5B371624.dip0.t-ipconnect.de> has joined #oi-dev
[03:02:44] *** gwr__ <gwr__!~gwr@pool-72-74-26-75.bstnma.fios.verizon.net> has quit IRC (Ping timeout: 256 seconds)
[03:17:04] *** gwr__ <gwr__!~gwr@pool-72-74-26-75.bstnma.fios.verizon.net> has joined #oi-dev
[03:17:04] *** ChanServ sets mode: +o gwr__
[05:11:47] *** freakazoid0223 <freakazoid0223!~chatzilla@pool-108-52-4-128.phlapa.fios.verizon.net> has joined #oi-dev
[05:24:27] *** freakazoid0223 <freakazoid0223!~chatzilla@pool-108-52-4-128.phlapa.fios.verizon.net> has quit IRC (Ping timeout: 268 seconds)
[05:33:16] *** tozhu <tozhu!~Thunderbi@220.166.249.187> has quit IRC (Ping timeout: 260 seconds)
[05:52:17] *** tozhu <tozhu!~Thunderbi@220.166.249.187> has joined #oi-dev
[06:20:28] *** tozhu <tozhu!~Thunderbi@220.166.249.187> has quit IRC (Ping timeout: 245 seconds)
[06:34:14] *** freakazoid0223 <freakazoid0223!~chatzilla@pool-173-49-14-128.phlapa.fios.verizon.net> has joined #oi-dev
[06:40:26] *** alanc <alanc!~alanc@inet-hqmc02-o.oracle.com> has quit IRC (Ping timeout: 244 seconds)
[06:51:57] *** alanc <alanc!~alanc@inet-hqmc02-o.oracle.com> has joined #oi-dev
[06:51:57] *** ChanServ sets mode: +o alanc
[07:33:23] *** tozhu <tozhu!~Thunderbi@223.85.203.28> has joined #oi-dev
[07:36:28] *** tozhu1 <tozhu1!~Thunderbi@223.85.203.28> has joined #oi-dev
[07:39:51] *** tozhu <tozhu!~Thunderbi@223.85.203.28> has quit IRC (Ping timeout: 244 seconds)
[07:39:52] *** tozhu1 is now known as tozhu
[07:42:45] *** tozhu1 <tozhu1!~Thunderbi@223.85.203.28> has joined #oi-dev
[07:44:24] *** tozhu <tozhu!~Thunderbi@223.85.203.28> has quit IRC (Ping timeout: 260 seconds)
[07:44:25] *** tozhu1 is now known as tozhu
[08:19:45] *** tsoome <tsoome!~tsoome@80.235.90.220> has quit IRC (Ping timeout: 252 seconds)
[08:20:52] *** alp <alp!~alp@pyhalov.cc.rsu.ru> has joined #oi-dev
[08:45:11] *** tsoome <tsoome!~tsoome@11-10-196-88.dyn.estpak.ee> has joined #oi-dev
[09:27:08] *** rk4n3 <rk4n3!~rk4n3@24-159-210-156.static.roch.mn.charter.com> has quit IRC (Ping timeout: 250 seconds)
[09:29:01] *** jimklimov <jimklimov!~E9926362@dynamic-109-81-208-56.ipv4.broadband.iol.cz> has joined #oi-dev
[09:41:19] *** nikolam <nikolam!~nikolam@unaffiliated/nikolam> has joined #oi-dev
[09:41:32] *** jimklimov1 <jimklimov1!~E9926362@dynamic-109-81-208-56.ipv4.broadband.iol.cz> has joined #oi-dev
[09:42:24] *** jimklimov <jimklimov!~E9926362@dynamic-109-81-208-56.ipv4.broadband.iol.cz> has quit IRC (Read error: Connection reset by peer)
[09:45:46] *** jimklimov1 <jimklimov1!~E9926362@dynamic-109-81-208-56.ipv4.broadband.iol.cz> has quit IRC (Ping timeout: 250 seconds)
[09:52:21] *** merzo <merzo!~merzo@92.60.189.225> has joined #oi-dev
[09:56:13] *** andy_js <andy_js!~andy@90.192.48.17> has joined #oi-dev
[10:14:22] *** nikolam <nikolam!~nikolam@unaffiliated/nikolam> has quit IRC (Quit: Leaving)
[10:20:34] *** makruger <makruger!~Michael@pool-108-20-232-57.bstnma.fios.verizon.net> has joined #oi-dev
[10:44:21] *** makruger <makruger!~Michael@pool-108-20-232-57.bstnma.fios.verizon.net> has quit IRC (Ping timeout: 260 seconds)
[10:57:44] *** rk4n3 <rk4n3!~rk4n3@24-159-210-156.static.roch.mn.charter.com> has joined #oi-dev
[11:09:25] *** tozhu <tozhu!~Thunderbi@223.85.203.28> has quit IRC (Quit: tozhu)
[11:09:39] *** tozhu <tozhu!~Thunderbi@153.92.43.163> has joined #oi-dev
[11:18:34] *** tozhu <tozhu!~Thunderbi@153.92.43.163> has quit IRC (Ping timeout: 256 seconds)
[11:37:41] *** tozhu <tozhu!~Thunderbi@223.85.203.28> has joined #oi-dev
[11:47:21] *** tozhu <tozhu!~Thunderbi@223.85.203.28> has quit IRC (Ping timeout: 260 seconds)
[12:02:27] *** tozhu <tozhu!~Thunderbi@223.85.203.28> has joined #oi-dev
[12:10:53] *** tozhu <tozhu!~Thunderbi@223.85.203.28> has quit IRC (Ping timeout: 245 seconds)
[12:17:07] *** tozhu <tozhu!~Thunderbi@223.85.203.28> has joined #oi-dev
[13:01:10] *** grueni <grueni!~chatzilla@HSI-KBW-078-043-251-106.hsi4.kabel-badenwuerttemberg.de> has quit IRC (Quit: ChatZilla 0.9.92 [Firefox 49.0.2/20161019084923])
[13:01:22] *** grueni <grueni!~chatzilla@HSI-KBW-078-043-251-106.hsi4.kabel-badenwuerttemberg.de> has joined #oi-dev
[13:04:04] *** tozhu <tozhu!~Thunderbi@223.85.203.28> has quit IRC (Ping timeout: 260 seconds)
[14:19:24] <igork> Agnar/Agnar_: here?
[14:40:11] <Agnar_> igork: sure
[15:41:04] *** ptribble <ptribble!~ptribble@cpc92320-cmbg19-2-0-cust3282.5-4.cable.virginm.net> has joined #oi-dev
[16:19:03] *** tsoome <tsoome!~tsoome@11-10-196-88.dyn.estpak.ee> has quit IRC (Quit: tsoome)
[16:56:28] *** ptribble <ptribble!~ptribble@cpc92320-cmbg19-2-0-cust3282.5-4.cable.virginm.net> has quit IRC (Quit: Leaving)
[17:07:45] *** tsoome <tsoome!~tsoome@220-90-235-80.dyn.estpak.ee> has joined #oi-dev
[17:53:52] *** merzo <merzo!~merzo@92.60.189.225> has quit IRC (Ping timeout: 260 seconds)
[17:56:27] *** jimklimov <jimklimov!~E9926362@dynamic-109-81-208-56.ipv4.broadband.iol.cz> has joined #oi-dev
[18:16:15] *** leoric <leoric!~leoric@188.232.85.52> has joined #oi-dev
[18:19:29] <leoric> alanc: you are definitely in rage...
[18:20:05] <alanc> I did the push, but much of the work was done by the rest of the team over many months
[18:28:38] <richlowe> "excess FOSS"
[18:29:52] <richlowe> alanc: you'll never get a job in PR :)
[18:30:15] <alanc> is that a bad thing?
[18:33:04] <richlowe> well, depends how much you buy into that whole "personal brand" deal the kids talk about. :)
[18:33:24] <richlowe> but pushing _that_ such that the least interesting thing shows up in Subject is astonishing.
[18:34:14] <richlowe> We deleted some stuff! (*whispers* and made a cross-consolidation major desktop upgrade)
[18:36:30] <alanc> unfortunately, it goes in reverse order, and that one had to be last since it was removing things that had dependencies until the earlier changesets cleared them
[18:37:26] <alanc> suppose I could have added some meaningless change afterwards with "Switch desktop from GNOME 2 to GNOME 3"
[18:40:30] <leoric> there's one disadvantage... As gnome 2 was dead, you shouldn't have updated it each half a year ;)
[18:48:16] <jimklimov> um... alanc, Did your team figure out how to make Gnome3 usable? :-) or is Solaris GUI now as counterintuitive as that of modernized Linux distros? ;)
[19:13:11] <richlowe> he posted screenshots on twitter at one point.
[19:13:41] <richlowe> looked like a NeXT and a nokia n800 had a love child.
[19:14:54] *** jimklimov1 <jimklimov1!~E9926362@dynamic-109-81-208-56.ipv4.broadband.iol.cz> has joined #oi-dev
[19:15:00] *** jimklimov <jimklimov!~E9926362@dynamic-109-81-208-56.ipv4.broadband.iol.cz> has quit IRC (Read error: Connection reset by peer)
[19:16:27] <tsoome> NeXT was kind of neat… altho it is long time ago since I did see one:P
[19:19:48] <tsoome> I should ind some time to set up S12 and see myself, I guess:P
[20:02:10] *** tozhu <tozhu!~Thunderbi@220.166.249.187> has joined #oi-dev
[20:03:23] *** nikolam <nikolam!~nikolam@unaffiliated/nikolam> has joined #oi-dev
[20:06:42] *** tozhu <tozhu!~Thunderbi@220.166.249.187> has quit IRC (Ping timeout: 256 seconds)
[20:12:21] *** js <js!~js@84-73-73-206.dclient.hispeed.ch> has joined #oi-dev
[20:13:20] <js> Hi. I read that there is no SPARC support and help is wanted. Clicking that "help wanted" link, it does not tell what's actually missing. So, what's actually missing? Is it mostly build infrastructure, as Solaris has always supported SPARC?
[20:18:56] *** denk <denk!~denis@devel.tambov.ru> has quit IRC (Ping timeout: 260 seconds)
[20:19:39] *** denk <denk!~denis@devel.tambov.ru> has joined #oi-dev
[20:21:23] <js> nikolam: thx for the info. So what's missing is basically using the latest OpenSolaris and gradually updating things until OI can be built, it seems.
[20:22:41] <leoric> you can use teferi's iso as starting point
[20:22:49] <nikolam> well yes, I have one T2 with Osol 134 on it, that works with it, repo is still on pkg.openindiana.org/legacy. dilos illumos distro is also booting of Sparc, and since rexently it could also use LDOMs
[20:23:44] <nikolam> OpenSXCE also advertized very good Sparc support, yet it is not based on releasing full sources, etc.
[20:23:58] <js> I only have a T1000. :/
[20:24:03] <leoric> you are better to ping Agnar_ , perhaps it has some repositories or prebuilt packages
[20:24:12] <nikolam> it should work etc.
[20:24:13] <leoric> sorry, s/it/he/
[20:24:59] <nikolam> yes, Agnar i sthe guy and that page is unofficial epicenter of action. Including #dilos, if it makes working with LDOMs again
[20:25:35] <js> LDOMs are broken by what? (This is what I'm mainly after, as OpenBSD's support is. Well. Okay. But not good.)
[20:26:28] <nikolam> LDOMs is proprietary firmware, Agnar said it is not the issue per se, yet first things (bootstraping) first. Used to work on dilos.
[20:27:02] <nikolam> I am keeping Osol 134 at that T2 ATM.
[20:27:38] <js> nikolam: Sure. I'm currently trying to get a grasp on what would be required to actually use my T1000 for something useful, and that includes LDOMs.
[20:28:11] <js> I'm not sure if the T1000 is dead slow or OpenBSD, thus interested in seeing if Solaris runs any better
[20:28:29] <jimklimov1> js, What sort of tasks do you have for it?
[20:28:40] <jimklimov1> in single-threaded numbercrunching it is dead slow :-)
[20:29:26] <js> jimklimov1: i wanted to use it as a mail, web and XMPP server. But I'm only getting 2 MB/s read speeds on the encrypted drive. Which seems ridiculous.
[20:29:40] <jimklimov1> in parallel simple stuff (independent tasks, pigz/pbzip style) it is fast
[20:30:06] <js> And I blame OpenBSD's almost non-existent SMP support for it as well ;)
[20:30:13] <jimklimov1> fir that - it should be adequate, it is its niche
[20:30:46] <jimklimov1> also be sue to avoid floating-point
[20:31:27] <js> I don't fear writing some code. So if porting OI makes that thing usable, I might give that a go. But 2 MB/a read performance is way too low for a web and git server. And unencrypted is not an option in a DC.
[20:32:15] <leoric> I like it... you see g_assert() in code and are sure that at least this check is performed... but after some debugging find out that asserts are disabled in non-debug mode.
[20:35:12] <nikolam> T1 cores are slower then T2 cores, T3 has same, but faster clocked, next core is S3 is in T4-1
[20:37:44] *** denk <denk!~denis@devel.tambov.ru> has quit IRC (Ping timeout: 268 seconds)
[20:38:23] *** denk <denk!~denis@devel.tambov.ru> has joined #oi-dev
[20:43:22] *** jimklimov1 <jimklimov1!~E9926362@dynamic-109-81-208-56.ipv4.broadband.iol.cz> has quit IRC (Read error: Connection reset by peer)
[20:43:44] *** jimklimov <jimklimov!~E9926362@dynamic-109-81-208-56.ipv4.broadband.iol.cz> has joined #oi-dev
[20:56:29] *** jimklimov <jimklimov!~E9926362@dynamic-109-81-208-56.ipv4.broadband.iol.cz> has quit IRC (Read error: Connection reset by peer)
[20:57:18] *** jimklimov <jimklimov!~E9926362@dynamic-109-81-208-56.ipv4.broadband.iol.cz> has joined #oi-dev
[20:57:37] <richlowe> T1 is markedly slower than everything else.
[20:57:51] <richlowe> whether we're faster than OpenBSD depends on how far openbsd went to make it less slow.
[20:59:28] <jimklimov> js, What sort of encryption is used there? Namely, is it an option (and is that option used) to accelerate the encryption with MAU in T1?
[20:59:41] <js> richlowe: is T2 such a big upgrade?
[20:59:51] <js> jimklimov: T1 only supports RSA and DES through MAU
[20:59:52] <jimklimov> yes
[21:00:12] <js> hm, so maybe I should buy a T5120?
[21:00:15] <js> I need something that's 1U
[21:00:26] <jimklimov> T2 had different core layouts, the floating point units are one per core, not one per CPU, a better cryptounit, etc
[21:00:28] <js> that one at least supports hardware AES
[21:00:44] <richlowe> an FPU per-core rather than per-chip helps a lot of things a lot.
[21:00:55] <richlowe> but I don't recall how much faster they seemed.
[21:01:11] <jimklimov> depends on taasks, between marginally and noticeably ;)
[21:01:22] <js> richlowe: not for crypto, though ;)
[21:01:24] <js> I don't do much FPU stuff
[21:01:44] <jimklimov> e.g. Java usage, which was one of the niches, went well because on the native code side it is integer computation
[21:01:50] <js> but the crypto unit in the T2 is not tied to a core, so it's not just using some special instructions, right?
[21:02:09] <richlowe> what I remember shows up as a device node.
[21:02:12] <richlowe> but I don't remember much.
[21:02:23] <richlowe> if I were looking for something fast, I wouldn't be looking at SPARC :)
[21:02:30] <js> meh. Because OpenBSD currently doesn't support that at all. Was wondering how hard that is to add, actually :)
[21:02:33] *** denk <denk!~denis@devel.tambov.ru> has quit IRC (Ping timeout: 245 seconds)
[21:02:42] <jimklimov> js, IIRC if your task has some FPU math, it is blocked waiting for FPU transistors; in T2 it is using local ones, in T1 it waited for the one shared set
[21:03:02] <js> richlowe: I'm looking for something to replace my Athlon X2 440e
[21:03:09] <js> so, not much of a goal to beat ;D
[21:03:14] *** denk <denk!~denis@devel.tambov.ru> has joined #oi-dev
[21:03:34] <js> jimklimov: my main problem with OpenBSD is the giant kernel lock. One core decrypts the HD with just 2 MB/s, all the others wait
[21:03:50] <js> booting a non-SMP kernel, I at least get it to 4.5 MB/s - which is still rediculous
[21:04:09] <js> but the math checks out. OpenSSL speed gets 7 MB/s for AES-256, and AES-XTS does AES twice.
[21:05:37] <js> I guess I should just try OpenSolaris to see if it's the hardware or OpenBSD. I'm mainly using OpenBSD because Oracle killed OpenSolaris and all the forks don't seem to have decent SPARC support yet.
[21:06:01] *** jimklimov <jimklimov!~E9926362@dynamic-109-81-208-56.ipv4.broadband.iol.cz> has quit IRC (Read error: Connection reset by peer)
[21:06:02] *** jimklimov1 <jimklimov1!~E9926362@dynamic-109-81-208-56.ipv4.broadband.iol.cz> has joined #oi-dev
[21:06:03] <jimklimov1> effectively those strands were not much more than a set of registers prepared for the next step in calculation - or being prepared (and thus blocked/off-core) during the slow I/O to L1/L2/RAM/disk layers
[21:06:05] <richlowe> I would not be sure an early T-series machine would beat an athlon x2
[21:06:25] <jimklimov1> depends on tasks, again :)
[21:06:35] <richlowe> the best case would be very good, and the worst case very bad.
[21:07:25] <richlowe> that's sort of true in general, up through T3. They're either fantastic, or the worst things ever.
[21:07:31] <richlowe> no experience of newer.
[21:07:37] <js> richlowe: well, that AMD X2 is almost the same age as the T1000. And was lowend back then ;)
[21:07:40] <jimklimov1> context switching is expensive; on a few-cores machine for the same amount of tasks (say, 1000-5000 processes in memory sometimes having a reason to wake up and do a bit of work) just switching to poll all the process states can become the 100% job for CPU
[21:08:04] <js> richlowe: Hm, T3 seems still quite expensive, the T2 and T1 have become quite affordable, though
[21:08:10] <jimklimov1> so if you serve mail/web as a lot of independent tasks or LWPs, the T series win a lot
[21:08:14] <js> also, I'm in europe, not the US. In the US, you seem to get them muuuuch cheaper.
[21:08:24] <jimklimov1> my wife made a diploma on that, so we know well :)
[21:08:38] <js> jimklimov1: yeah, serving web doesn't work well though if you use disk encryption. At least on the T1000 ;).
[21:08:43] <js> with no hardware accel for AES
[21:09:16] <jimklimov1> js, Is that on ZFS in BSD? Are the unencrypted or encrypted bits stored in RAM ARC?
[21:09:36] <jimklimov1> That is, ideally you read the disks once and do not care how slow that misery was ;)
[21:09:45] <js> jimklimov1: that's on UFS (only thing OpenBSD supports and all the other BSDs don't support sun4v). I hope it's storing the encrypted bits in RAM :)
[21:10:01] <js> actually, I haven't gotten another OS to work on the T1000 yet :(
[21:10:06] <js> OpenBSD seems like the worst choice for that hardware
[21:11:24] <jimklimov1> for that diploma stuff, we conjured up a lot of benchmarks; in particular, pigz and pbzip2 over large files were run a lot on the full matrix of cores/threads assigned to the CPU group for the task
[21:11:54] <js> btw, is it an OpenBSD limitation, or does using ldoms mean you have to assign CPU threads to each of them in a fixed way?
[21:13:32] <jimklimov1> overall on the 4-thread version, the parallelized compression process was about 2.4 times faster than on a single thread (for same amount of cores used) - and IIRC scaled linearly both as you added cores (N*C) and threads (M*T*2.4/4.0) :)
[21:14:15] <js> jimklimov1: yeah, I believe this thing is much better if you multithread things :)
[21:14:31] <js> but having a giant kernel lock only allowing one thread to be in the kernel at once kills it all. Hence, I want something other than OpenBSD :)
[21:14:49] <jimklimov1> so as Sun marketing and engineering colleagues touted how such threading was a smart usage of the limited resource - transistios in a chip at given level of technology, and usage for treads was MUCH cheaper than usage for fully fledged cores (essentially free in comparison), the benefit for something fee was noticeably good
[21:15:35] <jimklimov1> note that early ZFS compression was single-threaded in (Open)Solaris; it took several years to get it multiprocessor capable
[21:15:59] <jimklimov1> and note that non-Oracle solaris descendants do not have encryption ATM
[21:16:17] <jimklimov1> beside encrypting devices (loopback) and building a pool on top of those
[21:16:35] <jimklimov1> there are projects to do native encryption, but I'm not sure how well they progressed
[21:17:01] <js> jimklimov1: any kind of encryption works for me as long as I get, let's say 10 MB/s.
[21:18:10] <js> is there still a place where I can download OpenSolaris?
[21:18:15] *** denk <denk!~denis@devel.tambov.ru> has quit IRC (Ping timeout: 244 seconds)
[21:18:21] <js> And did some webpage maybe mirror the firmware updates before Oracle made them paid?
[21:18:25] <jimklimov1> BTW, in a DC environment, how do you solve the ability of the system to boot up (get the keys) without compromising that only you can read it and intruders can't?
[21:19:22] <jimklimov1> js, Probably not - at least not officially. After all, they were available from Sun under specific license terms, even if free monetarily.
[21:20:11] <js> jimklimov1: SSH into ALOM over a management VPN
[21:21:09] <leoric> I have some doubts, personally I dislike it's usage of configure in COMPONENT_PRE_BUILD_ACTION... But, perhaps, it's just me?
[21:27:10] *** denk <denk!~denis@devel.tambov.ru> has joined #oi-dev
[21:28:48] *** jimklimov1 <jimklimov1!~E9926362@dynamic-109-81-208-56.ipv4.broadband.iol.cz> has quit IRC (Read error: Connection reset by peer)
[21:30:54] *** jimklimov <jimklimov!~E9926362@dynamic-109-81-208-56.ipv4.broadband.iol.cz> has joined #oi-dev
[21:32:13] <xenol> leoric: I am on it
[21:32:29] <leoric> good evening
[21:34:27] <xenol> hi
[21:34:39] <xenol> is jim on PR spree?
[21:34:57] <leoric> seems so
[21:36:44] <xenol> jimklimov: I placed mbuffer into sysutils because it is not shell, but an utility
[21:37:05] <xenol> it has shell/ in it's fmri, but it should be renamed
[21:37:12] *** freakazoid0223 <freakazoid0223!~chatzilla@pool-173-49-14-128.phlapa.fios.verizon.net> has left #oi-dev
[21:37:16] <jimklimov> alp complained about other sysitils that I copied from it and were tagged as shells
[21:37:36] <jimklimov> imho they are all sysutils indeed so maybe fmris better change
[21:37:50] <xenol> what's the point xjobs if we have parallel?
[21:40:20] <grueni> xenol: cluster PRs are man8 free now
[21:40:30] <xenol> grueni: will check it shortly
[21:41:55] <grueni> xenol: I fear I made a mistake and squashed the latest commits into the last one which you reviewed
[21:42:10] <xenol> I will figure it out
[21:47:43] <xenol> jimklimov: file usr/bin/xjobs path=usr/bin/$(MACH32)/xjobs -> why placing it in usr/bin/$(MACH32) instead of /usr/bin?
[21:48:02] <jimklimov> hm, probably a copy-o
[21:48:26] <leoric> do we still want fun with isaexec ?
[21:49:11] <leoric> if it's just a binary tool, perhaps we don't need 32-bit copy?
[21:49:23] <jimklimov> not a big issue imho, at lwast for low-level system stuff that might get run in 32-bit context
[21:49:35] <jimklimov> e.g. small VMs, liecds, etc
[21:51:10] <xenol> leoric: if we deliver 64bit, we should place it in /usr/bin, but it will trigger lint checks
[21:52:53] <jimklimov> regarding "why xjobs" - no good answer beside that I found it on author's page while updating mbuffer :)
[21:53:10] <jimklimov> no practical requirement so far
[21:54:29] *** nikolam <nikolam!~nikolam@unaffiliated/nikolam> has quit IRC (Ping timeout: 260 seconds)
[21:55:06] <richlowe> I mostly use (GNU) xargs -P
[21:55:23] <xenol> so do I
[21:55:35] <xenol> or parallel lately
[21:55:37] <richlowe> and fwiw, is there really _any_ environment in which the 32bit kernel is used on 64bit systems?
[21:55:39] <richlowe> I'd hope not.
[21:56:30] <jimklimov> well, for xargs -P you should know how many CPUs are there on this particular machine (or assigned to the project processor set)
[21:57:15] <jimklimov> xjobs apparently defaults to using the system's amount of CPUs as the base parallelization setting
[21:57:22] *** nikolam <nikolam!~nikolam@unaffiliated/nikolam> has joined #oi-dev
[22:10:00] <xenol> grueni: reviewing cluster bits now
[22:16:45] *** leoric <leoric!~leoric@188.232.85.52> has quit IRC (Remote host closed the connection)
[22:40:53] *** denk <denk!~denis@devel.tambov.ru> has quit IRC (Ping timeout: 245 seconds)
[22:41:54] *** denk <denk!~denis@195.19.104.16> has joined #oi-dev
[22:43:20] *** jimklimov <jimklimov!~E9926362@dynamic-109-81-208-56.ipv4.broadband.iol.cz> has quit IRC (Read error: Connection reset by peer)
[22:44:02] *** jimklimov <jimklimov!~E9926362@dynamic-109-81-208-56.ipv4.broadband.iol.cz> has joined #oi-dev
[22:57:16] *** jimklimov <jimklimov!~E9926362@dynamic-109-81-208-56.ipv4.broadband.iol.cz> has quit IRC (Ping timeout: 256 seconds)
[22:59:52] *** jimklimov <jimklimov!~E9926362@dynamic-109-81-208-56.ipv4.broadband.iol.cz> has joined #oi-dev
[23:17:54] *** jimklimov1 <jimklimov1!~E9926362@dynamic-109-81-208-56.ipv4.broadband.iol.cz> has joined #oi-dev
[23:18:12] *** jimklimov <jimklimov!~E9926362@dynamic-109-81-208-56.ipv4.broadband.iol.cz> has quit IRC (Ping timeout: 260 seconds)
[23:31:02] *** szony <szony!~szony@adw25.neoplus.adsl.tpnet.pl> has joined #oi-dev
[23:31:06] *** szony <szony!~szony@adw25.neoplus.adsl.tpnet.pl> has quit IRC (Client Quit)
[23:31:29] *** szony <szony!~szony@adw25.neoplus.adsl.tpnet.pl> has joined #oi-dev
[23:32:16] *** szony <szony!~szony@adw25.neoplus.adsl.tpnet.pl> has quit IRC (Client Quit)
[23:42:12] <richlowe> alanc: hope you're all good and drunk, now
[23:42:53] <alanc> should probably be, but sadly, not yet
[23:43:37] *** jimklimov1 <jimklimov1!~E9926362@dynamic-109-81-208-56.ipv4.broadband.iol.cz> has quit IRC (Quit: Leaving.)
[23:46:25] <richlowe> doesn't pkg disk-space check these days?
[23:47:05] <richlowe> could have sworn I even saw it tell me that's what it was doing.