November 19, 2010 
< | 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 | >
November 19, 2010 [00:00:19] *** axisys has quit IRC[00:00:45] *** McBofh has quit IRC[00:02:24] *** stallion has quit IRC[00:02:28] *** McBofh has joined #illumos[00:15:34] *** jamesd_laptop has quit IRC[00:16:00] *** jamesd_laptop has joined #illumos[00:16:50] *** davenz has joined #illumos[00:23:31] *** glagasse has quit IRC[00:24:58] *** dreh has quit IRC[00:26:25] *** postwait has quit IRC[00:30:40] *** dnm has quit IRC[00:32:07] *** cmbntr has quit IRC[00:34:46] *** dreh has joined #illumos[00:36:07] *** _ams_ has quit IRC[00:37:09] *** glagasse has joined #illumos[00:44:33] *** psychicist has quit IRC[00:53:49] *** zynox has quit IRC[00:54:52] *** zynox has joined #illumos[00:55:54] *** xmikus01 has quit IRC[00:56:14] *** nrubsig has joined #illumos[00:57:21] *** glagasse has quit IRC[01:03:49] <nrubsig> seanmcg: Hi![01:04:25] *** gber has quit IRC[01:22:29] *** jelmd_ has joined #illumos[01:22:29] *** jelmd has quit IRC[01:22:32] *** jelmd_ is now known as jelmd[01:28:21] *** anti_alanc has joined #illumos[01:30:12] *** anti_alanc has quit IRC[01:30:31] *** anti_alanc2 has joined #illumos[01:32:07] *** anti_alanc2 has quit IRC[01:55:29] *** Edgeman has quit IRC[01:55:53] *** Edgeman has joined #illumos[01:57:53] *** mavhc has quit IRC[02:17:49] *** N2Deep has joined #illumos[02:40:44] *** jamesd__ has joined #illumos[02:43:49] *** jamesd_laptop has quit IRC[02:44:40] *** bradend1 has joined #illumos[02:44:48] *** bradend1 has quit IRC[02:47:09] *** bradend has quit IRC[02:52:47] *** Shoggoth has joined #illumos[02:57:16] *** man_u has quit IRC[02:58:10] *** man_u has joined #illumos[03:06:19] *** mavhc has joined #illumos[03:09:36] *** mavhc has joined #illumos[03:14:25] *** N2Deep has quit IRC[03:15:23] *** McBofh has quit IRC[03:22:30] *** jamesd_laptop has joined #illumos[03:24:41] *** jamesd2 has joined #illumos[03:25:26] * descipher pondering what I could do with VMFS mounts and ZFS.[03:26:05] *** jamesd__ has quit IRC[03:26:43] *** jamesd_laptop has quit IRC[03:26:46] <nrubsig> descipher: What is "VMFS" ?[03:27:06] <Shoggoth> VMware's proprietary clustered filesystem[03:27:49] <Shoggoth> descipher: two things are possible that I can see...[03:28:08] <Shoggoth> 1) create a VMFS volume on-top of a zvol that's shared via iSCSI[03:28:17] <Shoggoth> 2) share out a zfs mount via NFS[03:28:27] <Shoggoth> it would be interesting to see which performs better[03:30:14] *** randw has quit IRC[03:31:29] <lewellyn> apparently #2 sucks for vmware[03:32:16] <Shoggoth> really?[03:32:30] <Shoggoth> do you mean specifically with zfs/nfs[03:32:35] <Shoggoth> or nfs in general[03:33:08] <Shoggoth> btw. how are you lewellyn? long time[03:35:28] <lewellyn> busy[03:36:04] <Shoggoth> heh... the usual then :)[03:36:16] <descipher> Shoggoth: Exploring off loading VM cloning and high performance VM moves, backups etc.[03:36:23] <lewellyn> but yeah. anecdotal evidence says that vmware's nfs client blows.[03:38:10] <Shoggoth> lewellyn: from what I understand it was improved a fair bit in v4 but it wouldn't surprise me that it's still not crash hot[03:38:33] *** McBofh has joined #illumos[03:38:35] <Shoggoth> descipher: I'd be inclined to go with option #1[03:38:47] <descipher> The ability to mount a VMFS store on illumos would bring vStorage APIs into play for ZFS.[03:41:37] <descipher> ESX 4 did fix the CPU loading issues but NFS requires o_sync for to protect the metadata.[03:43:11] <descipher> I am exploring fuse mounts of VMFS on solaris.[03:47:12] <jbk> well i believe there's source for vmfs[03:49:14] *** ivo_ has quit IRC[03:49:39] <gwr> Is there much interest in FUSE for Illumos?[03:50:08] <lewellyn> was there much interest in fuse for opensolaris? ;)[03:50:18] <gwr> Is the FUSE port one finds on opensolaris.org usable? (crashes? hangs? OK?)[03:50:43] <gwr> A little, late in the game (just before I left)[03:50:43] <lewellyn> i hear it's slow. but that's fuse for you *shrug*[03:50:54] <Triskelios> gwr: it seems to work pretty reliably so far, haven't been able to crash the current version[03:51:31] <gwr> I wrote another one... wanted to experiment with using door calls to talk to the user-space part, completely ditching the "fuse channel" message stuff.[03:52:06] <gwr> Just a proof of concept though. Would need more work to make it useful.[03:52:22] <Triskelios> gwr: I only occasionally use FUSE for sshfs, exfat, or NTFS-3G with it though, but it's a lifesaver when I need it[03:53:03] <gwr> Triskelios: do you know if any of those fuse modules require "fuse_lowlevel" ?[03:53:29] <lewellyn> ok. i'm supposed to make a patch of this stuff, but i don't know which files they need patches for. wtf. and the guy who can tell me is gone for the day as of moments ago.[03:53:30] <gwr> And were you able to build them on OpenSolaris or Illumos?[03:53:34] <lewellyn> i guess that means irc for me? :P[03:54:14] <Triskelios> gwr: they build and work on OpenIndiana[03:54:33] <gwr> Cool. Maybe you could send me some pointers?[03:54:57] <gwr> One thing I needed to go further was some "interesting" fuse modules.[03:55:00] <Triskelios> gwr: the specs are in SFE[03:55:12] <gwr> sfw?[03:55:20] <Triskelios> smrt: explain spec-files-extra[03:55:21] <smrt> ⌂ A collection of popular software which is not in OpenSolaris. The SFE project ports software using RPM-style spec files. See also: bootstrap-sfe-latest-, pkgbuild. http://wong.to/sfewiki for more info, including installation instructions.[03:55:34] <lewellyn> see that url :)[03:56:18] <Triskelios> doesn't appear any of them use the fuse_lowlevel interfaces (NTFS-3G has a "fuse-lite" which I[03:56:20] <gwr> interesting. hadn't run across that before! (I live under a rock :)[03:56:23] <Triskelios> 'm pretty sure we don't use)[03:57:24] <descipher> There is a vmfs-tools open source project for Linux which could be explored.[03:57:40] <Triskelios> grep SFEfuse *.spec should turn up all of the FUSE packages (SFEfuse is just a wrapper around SUNWfuse)[03:57:43] <lewellyn> gwr: sfe discussion (and pkgbuild in general) happens in #pkgbuild :)[03:57:47] <gwr> My POC fusefs (using doors:) showed promise for being quite a bit faster and more efficient than the existing one, thanks to making many fewer calls out to user space.[03:57:54] <nrubsig> gwr: ---> /msg[03:58:16] <gwr> While I may not have time to pursue, I should put it somewhere with notes on "what to do next"...[03:59:04] <lewellyn> i personally abuse the sfe bootstrap script to quickly and easily get all the basic stuff needed for compilation installed[04:00:00] <lewellyn> it grabs a buncha packages ;)[04:00:43] <Triskelios> gwr: are there major user-kernel copies that are avoided as well?[04:03:08] <gwr> no, I didn't get far enough to try that.[04:03:53] <gwr> And as far as I could tell, the copying was not (necessarily) the biggest problem.[04:06:52] <gwr> Keeping all the "node cache" state in user-land seems to exact the greatest cost, in part because the *olaris VFS makes a _lot_ of calls to lookup and drop vnodes, i.e. up to 5 times for each line of an "ls" listing...[04:07:39] <gwr> My POC used an in-kernel node cache instead, so could satisfy most VFS activity without calls out to user-land.[04:10:24] <Triskelios> interesting, does this mean most real filesystems also implement something similar?[04:12:52] <gwr> yes. all.[04:13:38] <gwr> The VFS layer in *olaris assumes it's "cheap" to lookup a vnode, drop it, lookup again... (reclaim from cache is expected)[04:13:49] <gwr> so one better have a cache that works :)[04:14:51] <gwr> I know, because when I was the lead for smbfs, it started out having a cache in which reclaim didn't really work, at least not without going over-the-wire, which kind of defeats the purpose of a cache...[04:15:34] <gwr> As you might guess, my POC borrowed heavily from smbfs, as I observed that fuse and smbfs have very similar needs for managing their node cache.[04:16:02] <nrubsig> gwr: grumpf[04:16:24] <nrubsig> gwr: has anyone thought about now to re-export such a cache via NFS <= V3 ?[04:16:29] <nrubsig> er[04:16:38] <nrubsig> s/cache/filesystem/[04:17:02] *** Stellar|2 has joined #illumos[04:17:05] <nrubsig> Usually when I hear his I somehow get the feeling that the inode numbers won't be the same after reboot...[04:17:07] <nrubsig> ... right ?[04:19:14] *** Stellar has quit IRC[04:20:14] <gwr> The node cache in smbfs is now uses very similar TTL logic as NFS.[04:20:42] <gwr> (though the lookup mechanism and data structures are different)[04:21:14] <gwr> By "re-export", are you referring to "sharing out" something that's not local?[04:21:56] <Triskelios> I guess he means exporting a FUSE mount over NFS. the FUSE inode strategy is dependent on the provider, I think[04:24:12] <nrubsig> gwr: yes[04:25:40] *** edude03 has joined #illumos[04:26:12] <jbk> i'd still love to make an in-kernel AFP implementation[04:26:15] <jbk> but ENOTIME[04:32:44] *** Stellar|2 has quit IRC[04:35:58] * descipher Suspects that if illumos did have a writable VMFS mount capability fuse or otherwise it would have a significant avantage over Solaris 11 for VMware shops.[04:36:09] *** enderst has left #illumos[04:36:26] <lewellyn> descipher: except that it's open source... ;)[04:39:32] <descipher> All the better. It will have greater value to other distros and must also be kept open.[04:43:30] <jbk> uugh.. i hate this #define hell in trying to get the right symbols defined[04:45:47] <lewellyn> jbk: i keep choosing unpopular tasks, too.[04:46:17] <lewellyn> alanc: btw, poking at Xsun is on tonight's agenda, i'm told. (aka, i'm allowed to sit in front of my computer and cuss) :)[04:47:32] <alanc> Xsun does have that effect on people[04:47:44] <lewellyn> i figured.[04:47:46] <nrubsig> gwr: wanna be scared ?[04:47:58] <lewellyn> what, someone willingly trying to compile Xsun isn't scary?[04:48:05] <descipher> But you have to earn it. lol[04:48:17] * alanc is testing other boundaries tonight[04:48:49] <lewellyn> in advance, i am not volunteering to replace the binary-only kernel drivers... ;)[04:49:00] <nrubsig> gwr: Guess what $ typeset -T hello_t=( typeset h="hello world" ; print() { print "${_.h}" ; } ) ; hello_t blabla ; blabla.print # does ?[04:49:35] <jbk> lewellyn: been there, done that :)[04:49:36] <lewellyn> too many characters ;)[04:49:43] <lewellyn> jbk: oh, you tried compiling Xsun?[04:49:46] <gwr> no clue! (at least, not with the mental energy available at this late hour:)[04:49:53] <lewellyn> gwr: the answer is in the text.[04:49:53] <jbk> no, just binary-only kernel drivers[04:49:57] <jbk> (though not for xsun)[04:50:01] <nrubsig> gwr: typeset -T ---> object-oriented type system[04:50:11] <nrubsig> gwr: typeset -T declares a new type[04:50:14] <lewellyn> jbk: i lack enough hardware to do much, for starters :)[04:50:25] <lewellyn> i only have afb and m64[04:50:32] <jbk> part of why my work hasn't been putback yet[04:50:36] <jbk> i have a replacement for pcn[04:50:40] <jbk> works w/ vbox[04:50:43] <lewellyn> kick ass. it's done? :D[04:50:50] <jbk> been done[04:50:57] <lewellyn> awesomeness.[04:51:00] <jbk> except i don't have extra boxes to do nicdrv testing[04:51:06] <jbk> so it sits[04:51:09] <lewellyn> vbox won't do? ;)[04:51:24] <alanc> lewellyn: you live far too close to complain about not having enough video cards, when I have a lab in MPK17 to clean out soon[04:51:25] <jbk> no, there is a desire to test it with actual hardware[04:51:33] <lewellyn> alanc: uh oh... ;)[04:51:44] <alanc> dozens of sbus cards even[04:51:48] <gwr> which part does pcn support again?[04:51:48] <lewellyn> alanc: ok then. i don't have enough machines, if i HAD the cards...[04:51:55] <jbk> gwr: amd pc-net[04:52:01] <jbk> _old_ 10/100mb card[04:52:11] <jbk> but emulated by a number of vms[04:52:17] <gwr> which vendor? (I have some old stuff around here)[04:52:18] <lewellyn> jbk: one of the best cards for openserver 5, too[04:52:21] <lewellyn> gwr: amd[04:52:41] <gwr> hmm... not sure I've seen one of those.[04:52:49] <gwr> What were they typically shipped in?[04:52:57] <lewellyn> btw, is anyone planning on using bootstrap-sfe this evening?[04:58:02] <jbk> not me[04:59:01] <lewellyn> i need people to test my latest patch to the testing script :)[04:59:14] <jbk> i'm trying to get as much done w/ the ikev2 config file parsing as i can[04:59:22] <lewellyn> preferably on things besides SX11... and maybe not 134/134b...[04:59:29] <jbk> since i'm pretty much won't be touching it at all for the next 2 weeks[05:05:43] <descipher> smrt: explain bootstrap-sfe[05:05:43] <smrt> Um. I seem to not know anything about bootstrap-sfe...[05:05:52] <lewellyn> smrt: explain spec-files-extra[05:05:52] <smrt> ⌂ A collection of popular software which is not in OpenSolaris. The SFE project ports software using RPM-style spec files. See also: bootstrap-sfe-latest-, pkgbuild. http://wong.to/sfewiki for more info, including installation instructions.[05:06:16] <lewellyn> see that url for how to get the testing script. i'll put my patch up as soon as i run it through another test :)[05:06:26] <lewellyn> pkg is still slow on sparc :([05:06:38] <Meths> Does that latest factlet really have a trailing - ?[05:06:48] <lewellyn> Meths: no. i haven't bothered fixing it yet[05:07:00] <Meths> ok[05:07:22] <lewellyn> 18640 root 34M 20M run 59 0 0:02:37 97% pkg.depotd/64[05:07:29] <lewellyn> hm. :([05:07:49] <Meths> Is it pkg or python?[05:07:55] <lewellyn> both.[05:09:56] <bdha> LeftWing has been running his depot off Apache. Might want to talk to him.[05:11:24] <lewellyn> bdha: it's my localhost depot[05:11:35] <lewellyn> pkg eats 90%+ cpu for minutes at a time, too[05:11:52] <lewellyn> afaik, this is still a known issue on sparc[05:11:56] <bdha> aha[05:11:58] <bdha> Fun[05:12:20] <lewellyn> iirc, it's to do with underperforming json[05:12:30] <bdha> I just got my AI server up. One of the install guys suggested I use server_install as opposed to babel_install, which shut me up pretty well.[05:12:33] * bdha was being grumpy.[05:12:54] <lewellyn> just install redistributable! ;)[05:13:05] <bdha> Heh, no thanks.[05:13:17] <bdha> Even ~420 pkgs is too much, but I'll live with it. Or pare it down further.[05:13:25] <lewellyn> it's as close as you get to the "full" install of previous versions[05:13:37] <bdha> Next I need to get it on some metal, Puppetify and Poboxify it, and then get some zones doing some work.[05:13:47] <bdha> Yeah, all my Solaris 10 systems install crnet. :)[05:13:52] <lewellyn> heh[05:14:00] <Meths> Pobox?[05:14:04] <lewellyn> .com[05:14:20] <bdha> Aye.[05:24:33] <richlowe> You could cut server_install down further still, doing what you tried to do at first.[05:26:31] <bdha> Gonna give that a shot, aye.[05:26:36] <bdha> But now back to movie.[05:28:31] <lewellyn> Meths: 21089 root 95M 82M run 11 0 0:05:23 97% pkg/1[05:28:56] <jbk> heh cool[05:29:04] * jbk always likes it when code at least mostly works on the first try[05:30:19] <Meths> lewellyn: Fun :/[05:31:02] <lewellyn> yeah. 10-20 minutes, minimum, to get through the sfe bootstrap script. :([05:31:10] <lewellyn> that's without installing packages[05:31:30] *** axisys has joined #illumos[05:31:37] *** dnm has joined #illumos[05:37:16] *** carlomagno has quit IRC[05:38:18] *** carlomagno has joined #illumos[05:38:33] <LeftWing> apache ips repo ftw[05:55:06] *** steleman has joined #illumos[05:57:09] *** Edgeman has quit IRC[05:57:46] *** freakazoid0223 has joined #illumos[06:01:45] *** samuelyounge has quit IRC[06:06:46] <richlowe> lewellyn: what kind of sparc is this?[06:08:45] <richlowe> even on good, capable, machines upgrades suck.[06:13:19] *** hsp has joined #illumos[06:13:35] *** davenz has quit IRC[06:32:23] <gdamore> hey all.[06:32:49] <gdamore> richlowe: http://mexico.purplecow.org/gdamore/webrev/noexcept/[06:32:56] <gdamore> (or anyone else)[06:33:20] <gdamore> this is mostly a cleanup of stale (#ifdef'd out) code in svr4pkg, but I also made some minor improvements to pkgtrans.[06:36:17] *** oninoshiko has quit IRC[06:37:09] *** oninoshiko has joined #illumos[06:42:05] *** Shoggoth has quit IRC[06:44:01] *** digifor has joined #illumos[06:48:22] *** POloser has joined #illumos[06:53:15] *** samuelyounge has joined #illumos[06:56:22] <nrubsig> gwr: precompiling SMF stuff is on my wishlist, assuming gdamore doesn't remove my head for that idea[06:57:15] <nrubsig> gdamore: do you have time for a test of "grep -r" ?[06:59:13] * nrubsig adds -regex and -iregex to "find" in the meantime.[06:59:19] <nrubsig> and "iname", too.[07:02:53] *** Zauberpony has joined #illumos[07:04:23] *** Zauberpo1y has quit IRC[07:05:34] <jbk> gdamore: the 'exception_pkg()' and 'set_nonABI_symlinks()' functions -- are the needed for anything else, or can they also be eliminated?[07:09:45] *** Edgeman has joined #illumos[07:10:30] *** freakazoid0223 has quit IRC[07:10:40] *** davenz has joined #illumos[07:17:20] *** Shoggoth has joined #illumos[07:23:19] *** alhazred has joined #illumos[07:23:32] <nrubsig> can anyone please install http://nrubsig.org/people/gisburn/work/solaris/ksh93_integration/opensolaris_ksh20101112_i686_20101119_rev2268.tar.bz2 and see how this works, please ?[07:28:30] *** koan has quit IRC[07:33:41] *** koan has joined #illumos[07:35:25] *** digifor has quit IRC[07:35:50] *** edude03 has quit IRC[07:56:29] <gdamore> jbk: they are indeed used.[08:14:35] <madwizard> mornin' coffee[08:15:56] <madwizard> nrubsig: Precompiling SMF stuff?[08:16:07] <nrubsig> madwizard: yes[08:17:05] <madwizard> What exactly? I'm curious[08:17:52] <nrubsig> madwizard man shcomp[08:18:55] <madwizard> Ah[08:19:10] <madwizard> SMF is written i ksh?[08:19:21] <e^ipi> no it's written in XML[08:19:28] <e^ipi> and sqlite[08:19:32] <e^ipi> for some damned reason[08:20:08] <madwizard> e^ipi: I now that manifests for imoirt are written in xml and that after import they live in sqlite[08:20:19] <madwizard> This is why I wonder, what can be precompiled there[08:20:30] <madwizard> I guess some scripts[08:20:32] <e^ipi> nothing, you can populate the sqlite database[08:20:45] *** ivo_ has joined #illumos[08:21:21] <nrubsig> e^ipi: there is a binary XML format but it is nothing which will speed-up things significantly[08:21:53] <richlowe> neither will compiling the method scripts.[08:25:32] *** xapiens has quit IRC[08:28:01] *** davenz has left #illumos[08:28:11] <gdamore> precompiling SMF scripts? Ugh, please now.[08:28:12] <gdamore> now.[08:28:14] <gdamore> no.[08:28:17] <gdamore> no no no no.[08:30:31] <nrubsig> richlowe: on a 2GHz x86 machines you're right. On a 233MHz ARM machine the difference is many seconds.[08:31:10] <samuelyounge> Is the AMD-x86 standard back compatible with the features of the Intel Pentium specs?[08:31:21] <gdamore> for userland code, yes.[08:31:38] <samuelyounge> ok thanks[08:33:48] *** DesiJat has joined #illumos[08:36:40] *** Shoggoth has quit IRC[08:47:48] *** DocPheniX has quit IRC[08:49:03] *** ottom has quit IRC[08:50:03] *** RoyK has quit IRC[08:51:09] *** olivine has joined #illumos[08:55:24] *** jamesd2 has quit IRC[08:59:38] *** schily___ has quit IRC[09:00:40] *** jamesd2 has joined #illumos[09:04:58] *** schily___ has joined #illumos[09:35:43] *** nrubsig has quit IRC[09:40:55] *** sickness has joined #illumos[09:45:16] *** ivo_ has quit IRC[09:45:50] *** sancho has joined #illumos[09:50:02] *** merzo has joined #illumos[09:57:02] *** steleman has quit IRC[10:00:34] *** hnhn has joined #illumos[10:03:32] *** gebi has joined #illumos[10:03:32] *** gebi has joined #illumos[10:11:46] *** Tenzer|off is now known as Tenzer|work[10:21:56] *** Garen has joined #illumos[10:22:02] <lewellyn> richlowe: U30 ;)[10:22:12] <lewellyn> i need a good machine to test Xsun on, after all![10:24:21] *** gber has joined #illumos[10:27:34] *** |AbsyntH| has joined #illumos[10:28:55] *** |AbsyntH| has quit IRC[10:29:02] *** |AbsyntH| has joined #illumos[10:34:51] *** jamesd_laptop has joined #illumos[10:36:17] *** jamesd__ has joined #illumos[10:37:27] *** jamesd__ has quit IRC[10:37:52] *** jamesd2 has quit IRC[10:38:00] *** jamesd__ has joined #illumos[10:39:40] *** jamesd_laptop has quit IRC[10:40:19] *** HyperJohnGraham has quit IRC[10:41:43] *** HyperJohnGraham has joined #illumos[10:42:45] *** xmikus01 has joined #illumos[10:42:48] *** e-jones has joined #illumos[10:48:46] *** toddf has quit IRC[10:49:45] *** toddf has joined #illumos[10:51:48] *** sancho has quit IRC[10:56:37] *** sancho has joined #illumos[11:06:11] *** ivan has quit IRC[11:06:36] *** RoyK has joined #illumos[11:14:28] *** e-jones has left #illumos[11:23:50] <estibi> hi[11:23:56] <lewellyn> mu[11:24:41] *** Gervystar has joined #illumos[11:24:43] *** axisys has quit IRC[11:42:58] *** axisys has joined #illumos[12:13:44] *** alhazred has quit IRC[12:15:20] *** alhazred has joined #illumos[12:24:09] *** anilg has joined #illumos[12:35:15] *** bayoda has quit IRC[12:42:17] *** bayoda has joined #illumos[12:46:50] *** |AbsyntH| has quit IRC[12:55:58] *** hsp has quit IRC[13:08:09] *** PatrickS has quit IRC[13:18:42] *** alhazred has quit IRC[13:18:58] *** alhazred has joined #illumos[13:20:02] *** DaQatz has quit IRC[13:24:07] *** POloser has left #illumos[13:27:01] *** andunix has joined #illumos[13:27:04] *** andunix has left #illumos[13:27:56] *** ThothCrimson has quit IRC[13:32:08] *** merzo has quit IRC[13:36:58] *** gber_ has joined #illumos[13:39:36] *** edude03 has joined #illumos[13:40:09] *** gber has quit IRC[13:40:32] *** gber_ is now known as gber[13:50:05] *** edude03 has quit IRC[13:52:18] *** alhazred has quit IRC[13:56:00] *** POloser has joined #illumos[14:01:10] *** PatrickS has joined #illumos[14:03:44] *** alhazred has joined #illumos[14:05:15] *** zynox has quit IRC[14:05:25] *** Tenzer|work is now known as Tenzer|off[14:05:45] *** zynox has joined #illumos[14:21:14] *** alhazred has quit IRC[14:21:39] *** randw has joined #illumos[14:22:04] *** alhazred has joined #illumos[14:29:45] *** POloser has left #illumos[14:31:23] *** randw has quit IRC[14:37:06] *** psychicist has joined #illumos[14:41:50] *** jamesd_laptop has joined #illumos[14:45:06] *** jamesd__ has quit IRC[14:45:21] *** jamesd_laptop has quit IRC[14:45:48] *** jamesd_laptop has joined #illumos[14:53:49] *** DaQatz has joined #illumos[14:56:18] *** hajma has quit IRC[14:56:21] *** hajma_ has joined #illumos[15:01:15] *** JoeBanana has quit IRC[15:04:07] *** JoeBanana has joined #illumos[15:23:15] *** sancho has quit IRC[15:23:20] *** xapiens has joined #illumos[15:35:53] *** russiane39 has quit IRC[15:36:08] *** merzo has joined #illumos[15:43:19] *** russiane39 has joined #illumos[15:43:27] *** hnhn has quit IRC[15:59:16] *** hnhn has joined #illumos[16:22:20] *** RoyK has quit IRC[16:22:25] *** PatrickS_ has joined #illumos[16:23:30] *** dnm has quit IRC[16:23:57] *** PatrickS has quit IRC[16:25:49] *** dajhorn has joined #illumos[16:28:49] *** ivan has joined #illumos[16:41:27] *** PatrickS_ has quit IRC[16:45:32] * descipher Thinks we need to create VMFS mount capability sooner that later in illumos.[16:46:46] *** jamesd2 has joined #illumos[16:47:42] *** jamesd2 has quit IRC[16:48:15] *** jamesd2 has joined #illumos[16:48:34] *** jamesd_laptop has quit IRC[16:49:08] * descipher As i am not an fs developer I could do an ugly hack with nuts and bolts if a real fs developer does not see any value.[16:57:56] *** randw has joined #illumos[17:02:43] *** sponix has quit IRC[17:02:47] *** Immundus has joined #illumos[17:12:50] *** jamesd_laptop has joined #illumos[17:15:05] *** jamesd__ has joined #illumos[17:16:00] *** jamesd2 has quit IRC[17:18:42] *** jamesd_laptop has quit IRC[17:25:01] *** carlomagno has quit IRC[17:28:12] *** dnm has joined #illumos[17:31:54] *** ivan has quit IRC[17:39:05] *** ivan has joined #illumos[17:39:40] *** jamesd_laptop has joined #illumos[17:43:27] *** jamesd__ has quit IRC[17:50:44] *** ivan has quit IRC[17:52:43] *** ivan has joined #illumos[17:53:45] *** zynox has quit IRC[17:55:18] *** zynox has joined #illumos[17:59:52] *** Immundus has quit IRC[18:02:19] *** hnhn has quit IRC[18:04:40] <gdamore> SPARC compilation fixes: http://mexico.purplecow.org/gdamore/webrev/sparc/[18:05:51] *** _ams_ has joined #illumos[18:11:25] *** merzo has quit IRC[18:12:33] *** alhazred_ has joined #illumos[18:12:38] *** alhazred has quit IRC[18:14:23] *** ivo_ has joined #illumos[18:16:57] *** postwait has joined #illumos[18:20:36] *** jamesd_laptop has quit IRC[18:21:07] *** jamesd_laptop has joined #illumos[18:26:59] *** Zauberpo1y has joined #illumos[18:27:00] *** Zauberpony has quit IRC[18:28:54] *** jamesd_laptop has quit IRC[18:28:56] *** jamesd2 has joined #illumos[18:29:52] *** frankS2 has quit IRC[18:29:52] *** frankS2 has joined #illumos[18:33:51] *** jamesd2 has quit IRC[18:34:10] *** kart_ has quit IRC[18:43:00] *** hnhn has joined #illumos[19:14:03] *** alhazred_ has quit IRC[19:14:09] *** alhazred has joined #illumos[19:14:17] *** anilg has left #illumos[19:15:40] *** ottom has joined #illumos[19:27:01] *** kart_ has joined #illumos[19:37:51] *** ffea has joined #illumos[19:51:19] *** carlomagno has joined #illumos[20:08:32] *** kart_ has quit IRC[20:11:10] *** Gervystar has quit IRC[20:42:12] *** sponix has joined #illumos[20:48:06] *** alhazred has quit IRC[20:59:24] *** ffea has quit IRC[21:03:08] *** ffea has joined #illumos[21:12:35] <CIA-75> illumos Garrett D'Amore <garrett at nexenta dot com>: 298 SPARC build fails in smt_pause.o Reviewed by: gwr at nexenta dot com Reviewed by: albert.lee at nexenta dot com Reviewed by: estseg at gmail dot com Approved by: gwr at nexenta dot com[21:13:44] *** descipher has quit IRC[21:17:26] *** pjfloyd has joined #illumos[21:32:12] *** e-jones has joined #illumos[21:35:04] *** ffea has quit IRC[21:50:29] *** spike- has quit IRC[21:51:36] *** spike- has joined #illumos[22:00:08] *** Gervystar has joined #illumos[22:03:23] <gdamore> http://mexico.purplecow.org/gdamore/webrev/noexcept/[22:03:31] <gdamore> this is the clean up of some svr4 stuff... :-)[22:08:52] *** Gervystar has quit IRC[22:12:34] *** e^ipi has quit IRC[22:12:37] *** Gervystar has joined #illumos[22:14:21] *** e^ipi has joined #illumos[22:21:11] *** e-jones has quit IRC[22:22:30] *** Gervystar has quit IRC[22:23:42] <madwizard> Coffee[22:28:08] <btQuark> greetings[22:28:27] <btQuark> any idea when the encryption bits from solaris11 express will surface for integration by illumos?[22:28:47] *** ivo_ has quit IRC[22:28:48] <alanc> no one knows[22:29:04] <btQuark> i wonder if it will happen at all[22:29:42] <btQuark> and if someone will do a comparison of zfs encryption to the linux or bsd variants[22:30:51] <alanc> you aren't the only one wondering, but again, no one knows[22:32:22] *** samuelyounge has quit IRC[22:35:40] <madwizard> Yup[22:38:51] *** samuelyounge has joined #illumos[22:40:29] *** datadigger has quit IRC[22:44:07] <gdamore> btQuark: it *will* happen, but it might not be exactly what Oracle integrated.[22:44:26] <gdamore> We don't have have access to the latest Oracle source, but we *do* have access to Darren's earlier prototypes.[22:45:03] <btQuark> lets see where solaris/illumos is in one year...[22:45:12] <gdamore> Anyone using any ZFS version after 28 should *not* count on any dataset portability to anything except Oracle's OS, because nobody gets to know what Oracle's versions are.[22:45:39] <gdamore> We'll be integrating stuff in far less than a year. We are not waiting for Oracle to "maybe" open its sources in the future. I honestly don't think it will happen at all.[22:45:49] *** nachox_ has joined #illumos[22:46:37] <lblume> How are operating systems going to be able to differentiate between zfs flavours?[22:47:01] <gdamore> they *can't*.[22:47:19] <gdamore> in the future, it will probably come down to just two "families" of ZFS[22:47:30] <gdamore> the Oracle family... and the agreed upon version that everyone else uses.[22:47:58] <gdamore> Oracle have basically "abandoned" the concept of "Open Storage".[22:48:25] <gdamore> So now if you run SX11 or an Oracle storage appliance, you have to accept it comes with vendor lock-in.[22:48:56] <lblume> will there be at least a "last interoperable version" ?[22:49:02] <gdamore> version 28.[22:49:17] <lewellyn> gdamore: i'll look at your svr4 webrev when i have spare cycles, btw. not enough sleep to overclock myself today ;)[22:49:18] <gdamore> from that point on, Oracle forked.[22:49:24] <estibi> gdamore: what is the reason for removing gettext calls?[22:49:30] <gdamore> ok... I might integrate sooner.[22:49:40] <gdamore> estibi: I didn't... the gettext calls are in the messages.h definition of the macro.[22:49:51] <gdamore> so the compiled result is the same....[22:49:52] <lewellyn> gdamore: i'm expecting to be at a stopping place in about an hour[22:49:54] <btQuark> gdamore - yuck, if i want locked in storage i'll take the original from netapp[22:50:05] <gdamore> btQuark: right.[22:50:19] <lblume> I hope there'll be an easy way to remember that number when creating a new pool...[22:50:22] <btQuark> that stuff works, most of all times[22:50:47] <gdamore> we might have a way to force a number in the future, but I strongly doubt Oracle will.[22:50:48] <btQuark> and looks nice, even if one cannot call the last sun storage devices ugly[22:51:14] <btQuark> shiny white-silver boxes :)[22:51:22] <lblume> Well, goodwill from you will be even more appreciated, I guess :-)[22:52:53] <gdamore> from whom?[22:55:20] <lblume> At least the most generous deities and karmic entities. Ok, wishful thinking. Sorry.[22:58:00] <lewellyn> you catch more flies with yachts than vinegar.[22:58:20] <lblume> Except fruit flies.[22:58:49] <lewellyn> i'm sure a few of those end up on larry's sails, too[23:00:00] <lblume> Let' s go and check.[23:07:36] *** robinbowes has quit IRC[23:08:03] *** PatrickS_ has joined #illumos[23:08:25] <btQuark> xD[23:08:38] <btQuark> we need the illumos yacht then ;)[23:09:40] <samuelyounge> How about the illumos submarine, so we can torpedo Larry yacht.[23:11:16] * alanc now has "we all live in illumos submarine" stuck running through his head[23:11:21] <lblume> That would be ungentlemanly.[23:13:59] *** _ams_ has quit IRC[23:14:17] *** nrubsig has joined #illumos[23:15:06] <estibi> gdamore: http://mexico.purplecow.org/gdamore/webrev/noexcept/usr/src/cmd/svr4pkg/pkgtrans/main.c.html line 157 doesn't it need also free() and pkgerr_free(err) before exit()?[23:15:07] <nrubsig> gdamore: Congratultions to the SPARC fix... :-)[23:15:15] <nrubsig> gdamore: Next step: Merge ARM[23:15:24] *** datadigger has joined #illumos[23:15:31] * nrubsig *ducks*[23:15:44] <gdamore> estibi: Maybe... but that wasn't in the original code.[23:16:12] <nrubsig> Stupid question: I use |open()| to open a directory, use |fchdir()| to move cwd to that directory... can I |close()| the fd then ?[23:16:14] <gdamore> Frankly the svr4pkg stuff is in *really* sad repair. I almost wonder if it *would* be easier to rewrite it.[23:16:45] <gdamore> I don't see why not... although that sounds like a crazy way to do something.[23:16:49] <nrubsig> gdamore: Is the original script version of svr4pkg still around ?[23:17:01] <nrubsig> gdamore: you mean |fchdir()| ?[23:17:20] <gdamore> "script version"? I think you mean the script version of *patching*, not *packaging*[23:17:25] <btQuark> i would love to hava small footprint solaris[23:17:30] <btQuark> or illumos[23:17:32] <nrubsig> gdamore: SystemV packaging was once a script[23:17:34] <gdamore> I'm working on it.[23:17:41] <gdamore> hard to believe...[23:18:06] <gdamore> I suspect given about a week or two, I could rewrite all this stuff from scratch and have something that works a helluva lot better than the crap we have.[23:18:20] *** robinbowes has joined #illumos[23:18:21] <gdamore> The problem are the legacy edge cases though.[23:18:32] <estibi> gdamore: 164 logerr(gettext(KEYSTORE_OPEN), keystore_file); another gettext to remove[23:18:34] <gdamore> e.g. the NON_ABI scripting and symbolic links.[23:18:52] <gdamore> I didn't change that message though...[23:18:55] <nrubsig> gdamore: back to |fchdir()| ... I 'm in the middle of the |ftw()| code moving over to |openat()| to make it more efficient.[23:19:00] <gdamore> so that code is right.[23:19:42] <gdamore> using fchdir is a *bad* idea[23:19:51] <nrubsig> gdamore: why ?[23:19:53] <gdamore> it affects the entire process.[23:19:59] <nrubsig> gdamore: I know that.[23:20:02] <gdamore> so other threads can wind up doing bad things.[23:20:07] <alanc> you mean you're starting to understand why IPS chose to throw away the SVR4 code?[23:20:13] <nrubsig> gdamore: we will use |openat()| in the future[23:20:32] <alanc> (despite what other design decisions of theirs you may disagree with)[23:20:32] <gdamore> We could have thrown away the implementation, but we didn't need to throw away package compatibility.[23:21:12] <gdamore> I'll have a hard time blessing any rewrite of libc to implicitly change global program state like cwd.[23:21:31] <alanc> IPS still has package compatibility - you can still add SVR4 packages and IPS fakes enough of the SVR4 data files to allow dependencies in them to work[23:21:42] <gdamore> ah, I see ftw has a FTW_CHDIR... ok.[23:21:53] <nrubsig> gdamore: erm, I'm not in libc[23:22:27] <gdamore> oh, this is in your crazy AST rewrite-the-entire-universe thing.[23:22:39] <gdamore> Another part of ksh93/AST that *really* bugs me....[23:22:52] *** gebi has quit IRC[23:23:01] <gdamore> (It can't *possibly* be that the system might have provided a sane implementation of these things....)[23:23:25] <nrubsig> gdamore: I had that discussion yesterday. Point ios that libc::stdio and libc::malloc are impossible to use because they are so outdated.[23:23:30] <gdamore> On this particular point I find myself in agreement with Joerg. Replacing the entire system runtime for a shell is *crazy*[23:23:43] <nrubsig> gdamore: and Solaris libc has no |ftw()|[23:23:56] <sommerfeld> given openat(2), there's no reason why library code needs to call chdir()[23:24:10] <gdamore> nrubsig: wrong, it does![23:24:19] <jbk> /usr/include/ftw.h[23:24:23] <jbk> i see it there[23:24:27] <alanc> [8842] | 304504| 41|FUNC |GLOB |3 |15 |ftw[23:24:28] <jbk> no comment on how well it works[23:24:31] <gdamore> I just checked *nm*[23:24:32] <alanc> and I see it in libc.so.1[23:24:46] <gdamore> sommerfeld: ++[23:24:50] <jbk> even a man page for it[23:25:05] <nrubsig> sommerfeld: the problem is that there was (until recently) no |O_DIRECTORY| to make use of |openat()|[23:25:37] <gdamore> nrubsig: rather than code up crazy ksh93-specific hackery and replacement routines, why not fix some of the stuff in libc itself?[23:25:42] <gdamore> If there are problems....[23:25:49] <jbk> thouhg in terms of rewriting, i would like to finish rewriting /bin/ls -- because the current version does not scale well to large directories (which seem to be more common now w/ zfs) and the existing code is so messy that trying to fix it would be painful[23:25:59] <e^ipi> gdamore: because then there would be things that aren't ksh93[23:26:05] <e^ipi> and that's just crazy talk[23:26:32] <gdamore> jbk: careful. I'm pretty sure ksh93 has a builtin ls...[23:26:43] <nachox_> ew, i was going to say that :P[23:26:49] * gdamore hunts around for Xserver.ksh ....[23:27:25] <nrubsig> gdamore: fixing libc is at least not possible for stdio unless we break binary compatiblity[23:27:31] <jbk> actually if it works well, i wouldn't mind using it as a base.. one thing i discovered is that the required behavior (by various standards) is rather annoying in that it does a lot of very different things depending on combinations of flags and such[23:27:33] <gdamore> what are the *problems* ?[23:27:34] <CIA-75> illumos Garrett D'Amore <garrett at nexenta dot com>: 424 svr4pkg should remove ALLOW_EXCEPTION_LIST_PKG Reviewed by: albert.lee at nexenta dot com Approved by: gwr at nexenta dot com[23:28:23] <gdamore> jbk: are you going to fix the existing const string problem in ls? seems like you should.[23:28:30] <gdamore> since you introduced it. :-)[23:28:50] <nrubsig> gdamore: not async-signal-safe, not fully threadsafe, pre-POSIX behaviour for wide characters, massive slowness. I've send a more complete list to gwr yesterday.[23:29:17] <jbk> gdamore: well i was thinking it could be a byte sized fixed[23:29:19] <gdamore> I'm unconvinced that all of those require incompatible binary changes[23:29:20] <jbk> err fix[23:29:38] <gdamore> jbk: nobody else is doing bite size things. Please fix yourself.[23:29:41] <jbk> but if no one wants to pick it up[23:30:10] <jbk> it'll be a couple of weeks though :) i'm busy all weekend, then traveling for thanksgiving[23:30:25] <gdamore> If we all leave all the bite-sized stuff... the project will appear stagnant....[23:30:25] <nrubsig> gdamore: I am convinced because a) April Chin and Cynthia Eastham did the evaluation. b) there are arcane limits like the 256 fd limit. Technically there is the extended_fd.so thing but that does not work for shared libraries.[23:30:59] <nrubsig> gdamore: and the old stdio implemenzation exposes other details like rpivate buffers which old applications happily use[23:30:59] <gdamore> Um... but that's not a problem when you control the ksh93 application itself, right?[23:31:00] <e^ipi> i'm going to reiterate once again that who gives a shit about the standards[23:31:11] <e^ipi> we cannot test things against UNIX, nor will we ever be certified[23:31:11] <gdamore> nrubsig: only in 32-bit apps.[23:31:34] <gdamore> I don't know that this is true, e^ipi[23:31:34] <jbk> we could relegate those to a branded zone[23:31:35] <nrubsig> e^ipi: the alternative is to litter the application with lots of workarounds. We can do that, at the expense of more code[23:31:36] <e^ipi> so fuck the standards, do what's right by fiat or common agreement[23:31:40] <jbk> and fix stdio[23:31:40] <lewellyn> e^ipi: glibc certainly doesn't care, why should illumos? ;)[23:32:20] <gdamore> I'm happy to see reasonable fixes to stdio. I'm less happy to see libcmd/libast grow to slowly replace the entire operating system.[23:32:28] *** dajhorn has quit IRC[23:32:39] <e^ipi> gdamore: if eventually someone feels like ponying up the millions of dollars to certify then the development time of getting it up to snuff will be small[23:32:45] <nrubsig> jbk: that was Tim SparlinÄs team doing, they had a project for a stdio replacement in the work when they were RIF'ed[23:32:49] <e^ipi> but i find that pretty unlikely[23:32:53] <gdamore> In fact, I might have a look at libast to see if there is shit in there that I can throw away by using system provided variants instead.[23:33:48] <e^ipi> do it[23:34:05] <gdamore> multiple competing implementation is just plain stupid.[23:34:10] <nrubsig> gdamore: we've been there already. There is very little left which can be done.[23:34:23] <gdamore> and yet you are adding to it (see ftw)[23:34:42] <gdamore> garrett@thinkpad{23}> ls usr/src/lib/libast/common/dir/[23:34:42] <gdamore> dirlib.h opendir.c rewinddir.c telldir.c[23:34:42] <gdamore> getdents.c readdir.c seekdir.c[23:34:46] <nrubsig> gdamore: malloc can't be replaced because libc::malloc is not async-signal-safe. And don't get me started with stdio[23:34:56] <gdamore> try to tell me that *all* that can't easily be replaced with system variants?[23:36:20] <gdamore> is that true for libumem::malloc as well?[23:36:35] <nrubsig> gdamore: yes[23:36:56] <gdamore> and somehow this isn't fixable I presume... (I've not looked)[23:37:00] <nrubsig> gdamore: AFAIK that opendir.c is a no-op because |_dir_ok| is set, right ?[23:37:07] <nrubsig> gdamore: this is fixable[23:37:13] <nrubsig> for malloc[23:37:14] <gdamore> then wtf do we have the code for it.[23:37:30] <nrubsig> because noone wanted to do the fix ?[23:37:44] *** Sloar has joined #illumos[23:38:12] <gdamore> I think this kind of shit is one reason why you guys drop multimegabyte code dumps on us... so nobody will have enough energy to bitch about shit like this.[23:38:42] <nrubsig> gdamore: There've been _arguments_ over and over again about async-signal-safe malloc in MPK17. The agreement is: Yes, it is usefull, And "no", there is no funding.[23:38:53] <gdamore> a private copy of memcmp()?!?[23:38:58] <lewellyn> nrubsig: MPK17 doesn't matter in #illumos[23:39:09] <nrubsig> gdamore: and there was the argument about possible "risk" of touching something system-global[23:39:14] <nrubsig> like libc[23:39:14] <gdamore> MPK17 doesn't matter anymore to anyone. I think its vacant now. :-)[23:39:17] <nrubsig> gdamore: where ?[23:39:20] <lewellyn> few of us have "funding" for the things we want to do[23:39:32] <gdamore> usr/src/lib/libast/common/comp/memcmp.c[23:39:34] <jbk> yeah, i certaintly don't :)[23:39:53] <e^ipi> i do, so that's fun ;)[23:40:08] <nrubsig> gdamore: first major line is a #if _lib_memcmp ...[23:40:10] <gdamore> I can fund shit too, if there is a compelling reason.[23:40:20] <gdamore> Why even have the file, or have the compiler look at it.[23:40:39] <gdamore> this portability shiite needs to be removed if it isn't actually in use.[23:40:52] <gdamore> I had this same argument with Joerg over his portability library, too.[23:41:11] <gdamore> You have exactly *one* portability target in illumos.... illumos.[23:41:27] <nrubsig> gdamore: right[23:41:45] <sommerfeld> if you don't want to yield change control over the code, aim at the distributions and integrate via a "just build the tarball with patches" consolidation.[23:41:48] <gdamore> in fact, I venture to do say a lot of what's in libast falls into this.[23:41:58] <gdamore> sommerfeld: exactly.[23:42:05] <nrubsig> gdamore: but right now I'm doing g11n and have my nose in _bug_ reports while the compiler is working[23:42:09] <sommerfeld> (jds, sfw, ...)[23:43:01] *** pjfloyd has quit IRC[23:43:11] <nrubsig> sommerfeld: I have no problems with other people touching the code, assuming they don't blow things up.[23:43:14] <gdamore> I think I might spend a half day or so ripping out a few 10k's of code that are irrelevant to illumos.[23:43:21] <sommerfeld> (BTW, I think that's the right approach for any package with a portability library)[23:43:48] <nrubsig> sommerfeld: so far I don't want to end-up like Solaris ksh88. Sun did a very good and complete job with messing that shell up and wreak the code.[23:44:06] <gdamore> please stop worrying about that.[23:44:25] <nrubsig> sommerfeld: and the end the consensus at _Sun_ is that ksh88 has become unmaintainable and a nightmare.[23:44:26] <sommerfeld> if you don't want it to be wrecked, integrate it via sfw[23:44:29] <gdamore> if you want fidelity to the upstream, you need to follow sommerfeld's example. we're past that point in the discussion now.[23:44:56] <nrubsig> What again was "fidelity" ?[23:45:08] <gdamore> equivalence mostly.[23:45:16] <gdamore> there will be changes that we make locally....[23:45:42] <jbk> really, anything that you want to maintain in sync with some external repository is probably not a good candidate for ON[23:45:45] <gdamore> I think I'm going to start the first round.... I should be able to save a fair amount of compilation time just by removing the source code files that don't actually do anything.[23:45:46] <jbk> and better to go elsewhere[23:46:22] <e^ipi> gdamore: and the .png's[23:46:37] <e^ipi> won't save any disk space, but then at least there won't be fucking png's in ON[23:46:42] <gdamore> what pngs?[23:47:03] <nrubsig> gdamore: one sec[23:47:13] <e^ipi> http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/lib/libshell/misc/images/[23:47:23] <nrubsig> gdamore: Tim Sparlin's team requested to have a place for the shell style guide[23:47:29] <lewellyn> wtf. images!?[23:47:34] <e^ipi> lewellyn: you know it[23:47:42] * lewellyn literally facepalms[23:47:50] <e^ipi> nrubsig: sparlin's team was shitcanned years ago[23:47:51] <e^ipi> drop it[23:47:52] <nrubsig> gdamore: so we stuffed it into usr/share/doc/ksh[23:48:02] <nrubsig> e^ipi: right now we have no other place[23:48:05] <gdamore> that did *not* need to be in ON[23:48:11] <e^ipi> nrubsig: yes you do... /dev/null[23:48:19] <gdamore> a website somewhere, I don't care.[23:49:35] <jbk> has anyone setup a copy of SFW?[23:49:51] <lewellyn> jbk: no. my interest lies with re-implementing it, tbh.[23:49:53] <alanc> gdamore: /usr/bin/Xserver *is* a ksh93 script already - but that's just to translate SMF properties to command line options to the Xorg/Xvnc/etc. binaries[23:49:59] <gdamore> we actually need to maintain a fork of SFW.. remains to be seen if OI are going to work with us or not.[23:50:15] <gdamore> alanc: that's almost... funny.[23:50:15] *** schily___ is now known as schily_[23:50:16] <jbk> just wondering if it might be useful to have a parallel repository for such 3rd party software[23:50:42] <lewellyn> jbk: yes. but imo the sfw model isn't "correct" these days[23:51:15] <jbk> well whatever form, just something more geared towards software where you want to periodically sync from some upstream source[23:51:23] <lewellyn> if nothing else, the benefit is a userland basis that distros can all have in common if they choose[23:51:27] *** RoyK has joined #illumos[23:52:32] <lewellyn> jbk: i may be making the first step in that direction soon, as a side effect of other not-illumos-related stuff :)[23:53:42] <alanc> eww, those *.pngs should be removed on general principle (they're just images of courier text on a color background - use CSS instead and become accessible for free)[23:55:14] <jbk> gdamore: speaking of things, who wed are you to the existing ipsec configuration file syntax? :)[23:55:34] <jbk> err how wed[23:56:31] <gdamore> not very... maybe not at all.[23:56:36] <jbk> ok..[23:56:49] <jbk> the ike config's gonna have to change regardless for v2[23:57:07] <gdamore> alanc: I agree with the whole point about ... wtf did you bother with a PNG for that! :-p[23:57:15] <jbk> but i'd like to get v2 working, then add v1 compatability, then i'd really like to look at revamping the whole config files[23:57:26] *** robinbowes has quit IRC[23:57:43] <jbk> since it reeks of not being designed for actual use :)[23:57:52] <nrubsig> gdamore: because the CSS did not work for FireFox2 then in Solaris 11[23:58:33] <lewellyn> nrubsig: then you did it wrong.[23:58:56] <lewellyn> wait. ff*2* in S11?[23:59:00] <jbk> it wasn't until i started diving into this that i finally actually understood how to get ipsec working :)[23:59:03] <lewellyn> ff2 is deader than ie6[23:59:06] <nrubsig> lewellyn: B38+[23:59:13] <lewellyn> nrubsig: that's not S11[23:59:37] <lewellyn> regardless, you did it wrong.