[OpenIndiana-discuss] LX Branded zones
SmartOS has restored LX zones. GD championed rejecting them in https://www.illumos.org/issues/104 Will LX Branded zones be making a come back in future OI releases? I may end up having to support something like Vertica where we are performance mindful. I do not want the risk a diverging OS (Solaris v. IllumOS) by using the Solaris distribution or the performance penalty of using linux in KVM. thoughts? j. ___ openindiana-discuss mailing list openindiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] LX Branded zones
On 01/23/15 17:06, Dave Koelmeyer wrote: On 24/01/15 07:30, jason matthews wrote: SmartOS has restored LX zones. GD championed rejecting them in https://www.illumos.org/issues/104 Will LX Branded zones be making a come back in future OI releases? I may end up having to support something like Vertica where we are performance mindful. I do not want the risk a diverging OS (Solaris v. IllumOS) by using the Solaris distribution or the performance penalty of using linux in KVM. thoughts? It would be *incredibly* useful. Just looking at: https://docs.google.com/spreadsheets/d/1YeL_ZLTmrGJDYtI5LNif6Y9SITBFP7DNirYfsPfjBDM/edit?pli=1#gid=385135179 Having lived through the effort at Sun, I don't think it's a great idea. The problem with the LX branded zones is that you need a huge team of people to chase every little feature in Linux. The bizarro world /proc that they have (hey! let's use /proc/kitchen/sink!) is by itself a giant resource suck, and that's just one small component. And if you manage to miss one or another little bit, then, because most Linux-tied applications tend to use everything (I'm lookin' at you, systemd), it means that a lot of the applications you really want won't actually work right. Or that you'll be debugging them forever. And even if you cross those hurdles -- somehow -- you end up on a treadmill where you're chasing (at least) every even-numbered Linux kernel version number until bovine homecoming. It's a huge resource expenditure that must be completed in a relatively short time frame. That's why Sun's LX was tied to a thoroughly obsolete Linux kernel version by the time it shipped and why it was never much more than a neat parlor trick. It let you run Microsoft's Skype so you could tee your conversations into the Camp Williams data center, should you be so inclined. Once you get past that, though, it wasn't really useful for actual production. You likely would not want to run an SAP or Oracle server on it. So where's the paying customer? I (obviously) can't speak for Garrett, but I'd expect that reasoning something along those lines might well have been behind those relatively short statements. But, hey, if you think you can do it and make it useful, then there's no real reason to solicit any opinions. Start coding it and prove me wrong. ;-} -- James Carlson 42.703N 71.076W carls...@workingcode.com ___ openindiana-discuss mailing list openindiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] LX Branded zones
On 1/23/15 2:30 PM, James Carlson wrote: But, hey, if you think you can do it and make it useful, then there's no real reason to solicit any opinions. Start coding it and prove me wrong. ;-} Or boot SmartOS and call it a day - which is probably want I am going to do to determine whether it will work. j. ___ openindiana-discuss mailing list openindiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] LX Branded zones
On 24/01/15 07:30, jason matthews wrote: SmartOS has restored LX zones. GD championed rejecting them in https://www.illumos.org/issues/104 Will LX Branded zones be making a come back in future OI releases? I may end up having to support something like Vertica where we are performance mindful. I do not want the risk a diverging OS (Solaris v. IllumOS) by using the Solaris distribution or the performance penalty of using linux in KVM. thoughts? It would be *incredibly* useful. Just looking at: https://docs.google.com/spreadsheets/d/1YeL_ZLTmrGJDYtI5LNif6Y9SITBFP7DNirYfsPfjBDM/edit?pli=1#gid=385135179 -- Dave Koelmeyer http://blog.davekoelmeyer.co.nz ___ openindiana-discuss mailing list openindiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] LX Branded zones
On Fri, Jan 23, 2015 at 5:30 PM, James Carlson carls...@workingcode.com wrote: Having lived through the effort at Sun, I don't think it's a great idea. The problem with the LX branded zones is that you need a huge team of people to chase every little feature in Linux. The bizarro world /proc that they have (hey! let's use /proc/kitchen/sink!) is by itself a giant resource suck, and that's just one small component. Thing is, in the real world, Linux libs can't (or won't tend to) move that much w/o the fear of breaking libc compatibility. Lx emulation is a pragmatic way of getting all (well, not all, but many) Linux junk to run on unix. If, perchance, a lot changes in their universe and people start writing app code to require it, then we do the same in tandem, but that's most decidedly not what's actually happening in the wild right now, so it's not really that much to babysit. Just accept that it's never gonna be perfect, because the nature of their whole system philosophy / nature of the beast is never gonna be perfect. So stop being a 'correctness' cathedral scientist for a sec, stfu and fudge it like they do. We (pulling from the smartos peeps, perhaps, because they have to for business reasons) maintain it by doing what we have to to keep the apps happy -- and just run that shit with no porting. Gross, disgusting bazaar mentality, yes. But quite timely and useful. Opens a whole new world of running slipshod, albeit hip and popular, code on a nice os. And the kicker is that you can instrument it better than they can on their own platform, which, in an admittedly snarky way, is kind of amusing and has a whole lot of legitimate adoption opportunities and implications. Man on the street says we need to get this into Illumos rtfn. Remove it later if it turns out to be utter shite. -j ___ openindiana-discuss mailing list openindiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] Mozilla Firefox 31.4.0 dumps core
On 22/01/2015 17:59, Apostolos Syropoulos via openindiana-discuss wrote: Hello, I have tried Mozilla Firefox 31.4.0 on a machine where I installed OpenIndiana a8 yesterday and it dumps core. Has anyone noticed this? A.S. Running on dev a9 without nits, even google maps is ok. Flash is going downhill, as more and more videos use newer features, so a larger percentage than last year is crashing now (but still in an acceptable 1-3% range). Always use new /usr/local/lib firefox directories and map ALL your helpers in gnome, thunderbird, acroread etc. to a /usr/local/bin/firefox. If only one falls back to the system installed old /usr/bin/firefox (get rid of that link, point it to your /usr/local/lib/firefox/firefox), I suspect that your .mozilla/firefox/ profile will be corrupted. -- Dr.Udo Grabowski Inst.f.Meteorology Climate Research IMK-ASF-SAT http://www.imk-asf.kit.edu/english/sat.php KIT - Karlsruhe Institute of Technology http://www.kit.edu Postfach 3640,76021 Karlsruhe,Germany T:(+49)721 608-26026 F:-926026 ___ openindiana-discuss mailing list openindiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
[OpenIndiana-discuss] zfs incremental send / recv looping forever?
Hi, I have a pool that is incrementally sent to a backup pool every day. It used to work since last week, now I get this in a loop, and I have to kill the send / recv, or the log will fill up soon: promoting data-backup/sonicle/zones/webtop/ROOT/zbe another pass: promoting data-backup/sonicle/zones/www/ROOT/zbe another pass: promoting data-backup/sonicle/zones/webtop/ROOT/zbe another pass: promoting data-backup/sonicle/zones/www/ROOT/zbe another pass: promoting data-backup/sonicle/zones/webtop/ROOT/zbe another pass: promoting data-backup/sonicle/zones/www/ROOT/zbe another pass: promoting data-backup/sonicle/zones/webtop/ROOT/zbe and on and on and on What is it trying to do?!? What is another pass??? The script is as easy as: zfs send -R -i $snapshot_fromsnap $snapshot_tosnap | /usr/sbin/zfs receive -Fduv $destpool Any idea?? BTW, I already did a full send from scratch again, and it worked fine, then I got the same error running the incremental send. I have to check but I think those zones are both cloned from another one. So probably the problem comes from the clone. But why loop forever? Can I feel safe to promote the clones and get rid of the original snap? Gabriele. ___ openindiana-discuss mailing list openindiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
