[00:00] <RoyK> Sachiru: AT LAST, SIR TERRY, WE MUST WALK TOGETHER.
[00:01] <RoyK> sarnold: did you read Nation?
[00:02] <sarnold> RoyK: no, I didn't, I've only read discworld things so far
[00:02] <RoyK> sarnold: AT LAST, SIR TERRY, WE MUST WALK TOGETHER.
[00:02] <RoyK> sarnold: really, read it
[00:02] <sarnold> such genius :) hehe
[00:02] <RoyK> sarnold: it's one of his best
[00:03] <RoyK> it's that and Amazing Maurice
[00:04] <sarnold> RoyK: heh, I haven't read any of the YA books either
[00:04] <RoyK> hehe
[00:04] <RoyK> which says something
[00:05] <RoyK> some of them are the best he's written
[00:05] <RoyK> or wrote
[00:05] <sarnold> cool, thanks for the eouragementn
[00:05] <RoyK> now in paste tense
[00:05] <RoyK> past tense :P
[00:06] <RoyK> and please - read Gaimans books also
[00:06] <sarnold> hmm I don't think I've read raisin steam yet either, looks like amazon's got that in paperback now too :)
[00:06] <RoyK> the ocean at the end of the lane, the graveyard book, coraline
[00:09] <RoyK> sarnold: make sure to read Nation by Pratchett
[00:24] <sarnold> RoyK: thanks, ordered :)
[02:16] <teward> so i have an interesting issue - i'm trying to set a service to listen locally on 127.0.2.1, but of course it's not 'binding' because it's not added as an ip address that's bindable, I think.  is there a way to get something locally bound to that address, either by forcing it or adding the IP to the lo interface?/
[02:17] <sarnold> teward: try ip add 127.0.2.1 dev lo
[02:17] <sarnold> sigh
[02:18] <sarnold> ip addr add 127...
[02:24] <teward> sarnold: thanks
[02:31] <teward> sarnold: that worked, guess i have to add things to rc.local now.
[02:31] <teward> sarnold: know any way to add that address to the lo interface at boot time without adding commands to rc.local?
[02:32] <teward> (is it essentially the same as you would add addresses for eth0 or eth1, in /etc/network/interfaces ? )
[02:37] <sarnold> teward: good question... I think yuo're free to stick anything into the pre commands in interfaces(5). that would be my first choice.
[02:40] <teward> sarnold: i wonder if post-up works with it
[02:40] <teward> guess we'll find out after i reboot xD
[02:40] <sarnold> :)
[02:40] <teward> in other news, i hate resolvconf - why can't things just NOT need an extra program to manage resolv.conf >.<
[02:41] <sarnold> you can uninstall it if you wish
[02:41] <sarnold> i think things ought to work if you do
[02:41]  * teward shrugs
[02:41] <teward> sarnold: whoever set this system up put it on
[02:42]  * teward kinda inherited it :/
[02:42] <sarnold> just you get to manage it. which worked well for twenty years...
[02:42]  * teward chooses not to put resolvconf on his servers
[02:42] <sarnold> teward: probably whover set it up didn't care :)
[02:42] <teward> sarnold: well the person who set it up didn't care about a lot of things (that's all i'm going to say on the matter)
[02:42] <teward> sarnold: me, on the other hand, set it up in devel or staging or testing or even in a VM
[02:42] <teward> apply to production when complete at initial staging
[02:42] <teward> done
[02:43] <teward> works great until the next major vulnerability
[02:43] <Patrickdk> nothing is worse than resolvconf + chrooted programs
[02:43] <teward> ^ that
[02:43] <Patrickdk> like debian loves to do with everything
[02:44] <sarnold> eww sounds like an unfun combo
[02:53] <teward> sarnold: unfun indeed
[02:53] <teward> but don't get me started on using anything with SELinux - had to work with a centos box and i was ready to just say "BURN IT AND REPLACE IT WITH UBUNTU ALREADY"
[02:53] <teward> SEL was on on that system too :/
[03:54] <syeekick> I get input lag using putty to my ubuntu server, it's a local connection too. I've recieved the same problem remotely too, i just assumed it was a case of bad internet  speeds. Could it be the putty client? anyone got any ideas to decrease the input lag?
[12:15] <teward> bind9 dumps a lot of information to syslog, is there a way to reduce the amount of data it logs and have it log to a flat file instead of syslog?
[12:16] <OpenTokix> teward: yes, just configure loglevel
[12:17] <teward> OpenTokix: you going to be more forthcoming with info or do I have to go bother #bind instead
[12:17] <teward> (trying to follow their sparse documentation is resulting in a failure scenario)
[12:19] <teward> oop found it
[12:20] <OpenTokix> good =)
[12:24] <jamespage> rbasak, does armel/armhf have a hardware clock?
[12:24] <jamespage> rbasak, dealing with a ftbfs on ceph due to only dealing with arm64 and x86 right now
[12:24] <teward> OpenTokix: well, kinda found it - looks like bind9 in Trusty doesn't want to accept the logging { } clause :/
[12:24] <teward> guess i'll have to go poking at #bind for help
[12:24] <jamespage> rbasak, https://github.com/ceph/ceph/commit/060cbaacef5091755d598da6fd3b70119fb43184
[12:25] <rbasak> jamespage: you mean an RTC? Depends on the system.
[12:25] <rbasak> jamespage: also there can be an RTC but one that is not battery backed
[12:25] <jamespage> rbasak, hmm
[12:26] <rbasak> Oh, equivalent to rdtsc? That's different.
[12:26] <OpenTokix> teward: It does, it is just kind of wonky. - The thing is with bind logging is that default it is very verbose. And you have to understand your own bind configuration. - If you dont.... one should not run bind at all.
[12:26] <jamespage> rbasak, probably
[12:26] <jamespage> I have a ppc equiv - http://paste.ubuntu.com/10590583/
[12:26] <teward> OpenTokix: or it needs better documentation - the setup is experimental so I can learn the system, but with no documentation, well...
[12:27] <teward> s/the system/bind9/
[12:27] <teward> OpenTokix: and https://help.ubuntu.com/community/BIND9ServerHowto#Logging is wrong as well
[12:27] <teward> hence erroring
[12:27] <teward> oh wait
[12:27] <teward> wowwwwwwww
[12:27] <teward> i need to learn to read syslog >.<
[12:27] <teward> OpenTokix: i mistyped the log destination :/
[12:27] <OpenTokix> teward: =)
[12:28] <OpenTokix> teward: there is named-checkconf utility
[12:28] <OpenTokix> also named-checkzone
[12:28] <OpenTokix> to check any typos and such in your zone
[12:29] <jamespage> rbasak, does armhf have something similar?  google is indicating not...
[12:31] <RoyK> teward: you could use a RainerScript-based filter
[12:32] <rbasak> jamespage: I found http://blog.regehr.org/archives/794 which would work on any armv7 I think, but there are caveats. Kernel needs to enable it for userspace (there might be a good reason)
[12:33] <rbasak> jamespage: and I'm not sure it's synced between CPUs, so it wouldn't appear monotonically increasing without pinning a process to a single CPU
[12:33] <rbasak> jamespage: so might be buggy depending on the use
[12:34] <teward> RoyK: I could, but I've figured out the logging now - first i forgot to create the logging directory, then I forgot to chown the directory so bind can write to it.  Then I accidentally had a terminal crash when SSHing to the VM this is on so... *shrugs*
[12:35] <rbasak> jamespage: it might be worth understanding the need a bit better to find a good solution.
[12:36] <rbasak> jamespage: eg. would clock_gettime(2) do?
[12:36] <jamespage> rbasak, right now the only place I can see it in the codebase is in the src/test/objectstore/ObjectStoreTransactionBenchmark.cc
[12:36] <rbasak> jamespage: maybe just disable that test then?
[12:37] <jamespage> rbasak, that's not the issue - the Cycles code is a core part of ceph, so right now I get a FTBFS on armhf
[12:37] <rbasak> clock_gettime() would work for benchmarking but have far lower resolution and affect the test, as it involves an extra system call and slows thing down
[12:37] <rbasak> So we could use clock_gettime for the armhf implementation maybe. Or replace it with a no-op if we know it's only ever used in a test.
[12:39] <rbasak> jamespage: maybe safer to remove the test and the function entirely with an #ifdef?
[12:39] <rbasak> Then if it ends up being called later, it'll get flagged up.
[12:40] <rbasak> Though look out for ABI breakage.
[12:40] <jamespage> rbasak, what about http://neocontra.blogspot.co.uk/2013/05/user-mode-performance-counters-for.html
[12:40] <rbasak> Having said that even if the ABI didn't export a particular function before, adding it back later wouldn't constitute ABI breakage.
[12:41] <rbasak> jamespage: that's essentially the same. It either needs a system call, or a kernel module to enable userspace access.
[12:43] <rbasak> jamespage: I wonder why the kernel doesn't provide userspace access by default. Maybe that's something we should get fixed in the kernel.
[12:43] <rbasak> (unless there's a good reason)
[12:49] <jamespage> rbasak, that would be nice to know - smb - any ideas?
[12:50] <smb> jamespage, I always have many ideas ... though I have not yet read about what you are talking right now
[12:50] <rbasak> :)
[12:53] <smb> Ok, so cannot say anything right now. Neither performance counters nor nor specifics of the Arm world would be something I can answer from the top of my head
[12:54] <rbasak> ogra_ might know: ^^
[12:55] <rbasak> ogra_: we're after an rdtsc equivalent for armhf. There does seem to be something, but it's not enabled for access from userspace by default, so needs a kernel module to turn it on. Do you have any idea why?
[12:56] <ogra_> rtc's are often an exception on arm
[12:56] <ogra_> and if you have an rtc it most likely doesnt come with a battery
[12:57] <ogra_> (which is why we ship fixrtc in all ubuntu initrds and make sure it is executed on all arm boots usually)
[12:59] <ogra_> (does that help you in any way? )
[13:00] <rbasak> ogra_: it's not an RTC - it's a volatile monotonic high resolution counter that you can read from userspace without a system call. For high resolution timing of things.
[13:00] <ogra_> rbasak, ah, well, thats probably a question for ppisati then
[13:00] <rbasak> On Intel it's built in to the CPU and increments at CPU clock frequency
[13:01] <ogra_> being our arm kernel guy
[13:01]  * ogra_ rarely touches kernel code beyond configs 
[13:02] <rbasak> THanks, I'll ask him in #ubuntu-kernel
[13:03] <smb> rbasak, jamespage It might help to ask on #ubuntu-kernel
[13:03] <jamespage> ack
[13:03] <ogra_> yeah
[13:40] <soren> smoser: Do you have any good ideas for how to avoid having my ssh keys regenerated each time an instance from the same volume?
[13:40] <smoser> soren, so you want to boot multiple different instances with the same ssh keys
[13:40] <soren> Well...
[13:41] <smoser> it should only do that once "per-instance". based on the instance-id.
[13:41] <soren> You *could* phrase it that way.
[13:41] <smoser> you can feed it user-data that says to only do that once per-ever
[13:41] <soren> Is there an easy way to do it on first boot?
[13:41] <soren> The problem is this:
[13:42] <soren> I boot from volume (which gets created based on a regular image).
[13:42] <soren> Say I want to extend that volume.
[13:42] <soren> That means I have to terminate the instance (not just stop it).
[13:42] <soren> ...so that I can detach the volume.
[13:42] <soren> Extend it.
[13:42] <soren> Boot a new instance from it.
[13:43] <soren> And then cloud-init sees it as a new instance. Which it technically is, but not in the usual sense.
[13:45] <smoser> soren, http://paste.ubuntu.com/10590885/
[13:45] <smoser> ithink thats what you want.
[13:46] <soren> smoser: Sweet.
[13:46] <smoser> that should run the ssh key generation only once. (leaves a marker in /var/lib/cloud/sem/ssh.once or something)
[13:46] <soren> smoser: When is that logic applied?
[13:46] <soren> Yeah, that's what I was afraid of.
[13:46] <soren> That won't help me, then.
[13:47] <soren> Then I'd need the image to have the config in place on first boot.
[13:47] <smoser> oh.. i see. the next time you turn it on it has (possibly) differen tuser-data
[13:47] <soren> ...so that it'll create that file.
[13:47] <smoser> well, basically you need to get your image configured such that it only ever runs that once.
[13:47] <soren> Right.
[13:47] <smoser> you can put that config in the image when you capture the volume or what
[13:47] <soren> That's the point:
[13:47] <soren> I don't "capture" the volume.
[13:48] <soren> I do something like:
[13:48] <soren> nova boot --block-device source=image,id=<id of one of your trusty images>,dest=volume,size=20,bootindex=0 blah
[13:48] <soren> ...which creates a new 20 GB volume by copying your trusty image.
[13:48] <soren> ...and then I boot from that.
[13:48] <soren> So it's a completely vanilla image.
[13:50] <soren> So maybe I just -- on first boot -- need to update that config (as in your paste) *and* manually create the relevant semaphore file.
[13:51] <soren> Or am I misunderstanding the implementation? Is the semaphore file always created, but only checked for in case of (e.g.) "[ssh, once]" or does it only get created in case of (e.g.) "[ssh, once]"?
[13:58] <jamespage> rbasak, so do we have a good fallbck for this?
[13:59] <rbasak> jamespage: I think we should either verify that clock_gettime(2) is acceptable and use that, or ifdef out both the function definition and the test.
[14:00] <rbasak> If the function is never called it shouldn't matter if it doesn't exist, right?
[14:00] <rbasak> I have no objection to using perf as per your find in http://neocontra.blogspot.co.uk/2013/05/user-mode-performance-counters-for.html either
[14:23] <smoser> soren, i'm confused.
[14:23] <smoser> you boot from a volume. it should create ssh keys only when the instance-id has changed.
[14:23] <smoser> on first boot, its non-existant.
[14:23] <smoser> so '' -> 'some-silly-long-uuid' is  a change
[14:23] <smoser> and it creates ssh keys
[14:23] <smoser> on reboot, it wont.
[14:24] <smoser> if you capture the volume, and then start a new one from that, it will.
[14:26] <patdk-wk> yes, for some reason he is *terminating* the instance
[14:27] <patdk-wk> to resize the disk
[14:27] <patdk-wk> then creating a new instance using the resized disk
[14:27] <patdk-wk> so some-silly-long-uuid changes
[14:27] <patdk-wk> not sure why he is doing it that way, but I haven't exactly done it too often myself
[15:58] <zkvvoob> Hello people! Could anyone, please, help me with this: after I upgraded my server to 14.04, which came with Apache 2.4.7 (as compared to 2.2, which I had been running before), mod_fcgid cannot be installed. I need it in order to run ISPConfig, a free alternative to cPanel.
[16:02] <zkvvoob> Besides, right now I can't access any of the websites that were previously working on the server - Chrome says "No access to this page"
[16:03] <RoyK> zkvvoob: check the logs
[16:04] <zkvvoob> RoyK^Work: http://pastebin.com/gL1bv6Qj here's apache's error.log
[16:05] <jamespage> rbasak, http://paste.ubuntu.com/10591552/
[16:05] <jamespage> how does that look to you?
[16:06] <zetheroo> I am having a really hard time believing that resolv.conf is really this messed up in Ubuntu Server 14.04
[16:07] <zetheroo> Once an initial networking setup is created and resolv.conf is populated with nameservers, how does one simply change the nameservers?
[16:08] <zetheroo> I have seen all kinds of How-To's online claiming to show you how to do this in a mere few steps, but it doesn't work ... resolv.conf is pretty damn frustrating
[16:09] <patdk-wk> heh?
[16:09] <patdk-wk> if your using resolvconf
[16:09] <patdk-wk> you should NEVER touch it
[16:09] <patdk-wk> you just set /etc/network/interfaces correctly
[16:09] <zetheroo> and if you want to change your DNS?
[16:09] <zetheroo> what then?
[16:10] <patdk-wk> you change it in interfaces
[16:10] <patdk-wk> and bump the interface
[16:10] <patdk-wk> or you *manually* call resolvconf with the changes
[16:10] <zetheroo> ok, so lets try that (even though I think I have done that several times...)
[16:11] <zetheroo> right now I have this in my resolv.conf: http://paste.ubuntu.com/10591599/
[16:11] <zetheroo> I want to replace the .8 nameserver with .9
[16:12] <pmatulis> isn't there a limit of 3 or that changed?
[16:12] <OpenTokix> no
[16:12] <OpenTokix> no limit afaik
[16:12] <OpenTokix> zetheroo: Looks like yuour resolv.conf is manually handled, just edit the file and your set.
[16:12] <zetheroo> so I edit the /etc/network/interfaces file
[16:12] <OpenTokix> zetheroo: if you had the resolvconf-package, it would say in the top of the file
[16:13] <zetheroo> OpenTokix: so how is it manually configured on some but not on others?
[16:13] <OpenTokix> zetheroo: Depends on the resolvconf package
[16:14] <OpenTokix> if you have resolvconf installed, it pulls info from /etc/network/interfaces
[16:14] <OpenTokix> zetheroo: if resolvconf is removed, you edit the file directly
[16:14] <zetheroo> ok, tried editing the resolv.conf and upon saving it I get :   Premission denied
[16:14] <OpenTokix> zetheroo: its owned by root: sudo vim /etc/resolv.conf
[16:14] <OpenTokix> or whatever editor you prefer
[16:14] <zetheroo> I am logged in as root
[16:15] <zetheroo> -rw-r--r-- 1 root root 125 Dec 24 11:14 /etc/resolv.conf
[16:15] <OpenTokix> and whoami returns: root?
[16:15] <zetheroo> yes
[16:16] <OpenTokix> zetheroo: lsattr /etc/resolv.conf
[16:16] <zetheroo> ----i--------e-- /etc/resolv.conf
[16:16] <OpenTokix> it should say; -...--e-
[16:16] <OpenTokix> ok
[16:16] <OpenTokix> chattr -i /etc/resolv.conf
[16:16] <zetheroo> ok
[16:16] <zetheroo> no output
[16:16] <OpenTokix> zetheroo: Who changed the attribute of the file?
[16:17] <OpenTokix> no, if you do lsattr the i is removed
[16:17] <OpenTokix> i is "imutable"
[16:17] <zetheroo> ok
[16:17] <OpenTokix> now you can edit the file
[16:17] <zetheroo> ok thanks
[16:17] <OpenTokix> and if you want to make it imutable again, chattr +i /etc/resolv.conf
[16:17] <OpenTokix> And then like resolvconf cant change the file either
[16:17] <OpenTokix> zetheroo: someone is not knowing what they are doing in the system
[16:17] <zetheroo> :)
[16:17] <zetheroo> ok
[16:17] <OpenTokix> zetheroo: Check if resolvconf is insalled: dpkg --get-selections |grep resolvconf
[16:18] <zetheroo> yes it is
[16:18] <zetheroo> resolvconf					install
[16:18] <OpenTokix> yeah
[16:18] <zetheroo> :P
[16:18] <OpenTokix> So someone manually edited the file, and then it got changed back
[16:18] <OpenTokix> they got frustrated
[16:18] <OpenTokix> and made the file immutable
[16:18] <zetheroo> ok
[16:18] <OpenTokix> just remove resolvconf
[16:18] <OpenTokix> apt-get remove resolvconf
[16:18] <OpenTokix> if it your machine that is
[16:19] <OpenTokix> if its someone else machines, talk to them first before you mess around with system software
[16:19] <zetheroo> but then it wants to remove ubuntu-minimal ...
[16:19] <OpenTokix> wierd
[16:20] <OpenTokix> It does not depend on ubuntu-minimal
[16:21] <OpenTokix> zetheroo: Easiest is to put it as imutable again, after you change it. - I am leaving the office now
[16:22] <zetheroo> ok
[16:22] <zetheroo> thanks!!
[16:26] <zetheroo> ok
[16:26] <zetheroo> I see
[16:28] <zetheroo> how do you update resolvconf?
[16:29] <zetheroo> or "bump the interface"?
[16:29] <rberg_> 'resolvconf -u' will update it
[16:30] <rbasak> jamespage: you should probably check for errors in the call to perf_event_open - is fddev valid? Then again read is defined to return an error if the fd is invalid, so maybe that doesn't matter.
[16:30] <rbasak> jamespage: it does mean two syscalls per request, which doubles the already bad syscall latency for timing.
[16:31] <rbasak> jamespage: if this function starts getting used in critical path production code, it'll seriously regress performance.
[16:31] <rbasak> jamespage: that's why I was saying to remove the function entirely - then if the function starts getting used in production code, an FTBFS would flag it up.
[16:31] <zetheroo> ok, I found a server with a resolv.conf file which is being generated by resolvconf ... so going to try to change the DNS IP from .8 to .9 in the interfaces file and then do 'resolvconf -u' to update the resolv.conf file ... lets see if this works .. :)
[16:32] <zetheroo> nope - no go
[16:32] <rberg_> zetheroo: I believe if you change the nameserver in the interfaces file you will need to ifdown; ifup the interface to update
[16:32] <zetheroo> resolv.conf still the same with the wrong nameserver IP
[16:33] <rberg_> (I tend to add them to the lo interface)
[16:33] <zetheroo> rberg_: but won't doing ifdown sever my ssh connection!?
[16:33] <rberg_> yes
[16:33] <zetheroo> :(
[16:34] <rberg_> I dont know if I trust a 'service networking restart' over ssh
[16:34] <zetheroo> ok, so I can do it with the IPMI connection ...
[16:35] <zetheroo> the interface is a bridge (br0), so it should just be a matter of 'ifdown br0' and then 'ifup br0' - right?
[16:35] <rberg_> (I kind of hate resolvconf) yeah it would be the interface where you added the nameservers
[16:36] <zetheroo> ok, done and dusted - that worked.
[16:36] <zetheroo> resolv.conf has the correct DNS IP
[16:36] <zetheroo> :)
[16:37] <rberg_> sweet! like I said on my servers I added nameservers to lo so I can easly restart them
[16:37] <zetheroo> to lo?
[16:37] <zetheroo> I didn't know you could do that
[16:37] <zetheroo> if you add the nameservers to lo do they them apply to all NIC's?
[16:38] <rberg_> yep
[16:38] <zetheroo> ok, interesting
[16:42] <zetheroo> on another system when I do 'resolvconf -u' I get this: /etc/resolvconf/update.d/libc: Warning: /etc/resolv.conf is not a symbolic link to /run/resolvconf/resolv.conf
[16:43] <rberg_> ohh I have something for that in a script somewhere
[16:45] <rberg_> I wonder if 'dpkg-reconfigure resolvconf' will do it
[17:57] <zkvvob> Hello! Could you, please, help me figure out why a Wordpress installation on a Ubuntu 14.04/Apache2.4.7 server suddenly starded returning ERROR 500/Internal Server Error when accessing the site?
[18:14] <zkvvoob> Hi all. I'm getting "Abort class-pclzip.php : Missing zlib extensions" when activating iThemes Security plugin for Wordpress. Could you tell me what I need to install on an Ubuntu 14.04.2/Apache 2.4.7 server in order to solve this issue?
[18:42] <lordievader> Good evening.
[18:55] <Guest89380> Hi.  I'm moving distros, and just starting to evaluate Ubuntu-Server.  A key requirement for my Server is Xen v4.5.x support.  Iiuc, in released 'Trusty', Xen 4.4.x is supported; v4.5.x is only available for (still experimental?) 'Vivid'.  Since Xen 4.5 is *released* from upstream, how's it work in Ubuntu-land.  Will Xen 4.5.x be released for Ubuntu 14 Trusty? or only for the eventual  Vivid release?
[18:58] <rbasak> Guest89380: it is unlikely to be made available in Trusty, unless somebody volunteers to backport it.
[18:58] <rbasak> I have no idea about Vivid and Xen.
[18:58] <Walex2> Guest89380: 14.04 is a long term support release. backports are usually available, but not supported.
[18:59] <Guest89380> ( No idea why my nick changed ... will figure that out in a bit )
[19:00] <Guest89380> Ok, so if I need Xen 4.5x, either build it myself, or adopt a release branch with it "in there" ...
[19:00] <Guest89380> which seems like Vivid
[19:00] <rbasak> Right, so wait until Vivid's release in April.
[19:00] <rbasak> Or arrange a backport.
[19:01] <Guest89380> rbasak: I wouldn't know one if I saw one! ;-)  I'm on day1 of Ubuntu ...
[19:03] <Guest89380> I'm evaluating Arch & Ubuntu-Server -- both provide access to Xen 4.5, currently through different unsupported paths.  Need to muse on how I feel about both.
[19:03] <rbasak> For enterprise use I'd really buy whatever solution Xen recommend.
[19:03] <rbasak> (I mean Citrix of course)
[19:04] <rbasak> Especially if you care about having the latest rather than something that's settled.
[19:04] <rbasak> Or, join the community in maintaining Xen in Ubuntu
[19:07] <Guest89380> rbasak: Sure, I know the argument.  I Haven't been comfortable with Xen's 'dustiness' on the likes of RH/Centos for a long time.  I've been on Opensuse for awhile; that needs to change.  I need more flexibility in Dom0 than Citrix provides (i.e., prefer a plain ol' distro).  Both Arch & Ubuntu get me pretty darn close -- but not 100%.  Yet.  Different feel to each, though.  Lots depends on community, docs & Xen upstream's 'attitude' about it.
[19:08] <rbasak> Guest89380: time to switch away from Xen then maybe?
[19:08] <rbasak> I hear Openstack on Ubuntu with KVM is awesome.
[19:08] <rbasak> :-P
[19:09] <Guest89380> rbasak: nah.  need Xen's additional capabilities.  On my personal box, tho, thinking about playing with it -- and throwing Docker in the mix.  "In my spare time", of course.
[19:09] <rbasak> smb spends some time on Xen in Ubuntu.
[19:09] <rbasak> (working on it, that is)
[19:10] <rbasak> I know little about it though.
[19:11] <Guest89380> rbasak: I'm a little "spooked" by Ubuntu's "abandonment" of Xen (that was awhile ago, then it changed, and I'm working with out-of-date data & perceptions, I'm aware), and the whole "we may NOT stick with systemd" in Vivid+.  I'm a fan, have invested heavily and successfully in it already, and am not interested in yest another about-face down the line.
[19:11] <Guest89380> Yes, I've some homework-reading to do.
[19:12] <Guest89380> oh, smb's a person in here.  I read "Small & Medium Business" ... was confused a moment :-)
[19:14] <rbasak> Guest89380: huh? My understanding is that we're committed to systemd because Debian is, and there's been no indecision there. The only question is when we're technically ready to make the switch.
[19:14] <rbasak> (Vivid is looking good so far)
[19:15] <Guest89380> rbasak: fwiw: http://www.phoronix.com/scan.php?page=news_item&px=Ubuntu-Systemd-Monday , "Should there be much fallout from the systemd-booted Ubuntu, Martin wrote, "if after some weeks we find that there are too many or too big regressions, we can revert to upstart by default with two simple uploads (ubuntu-standard and init).""
[19:16] <Guest89380> I guess it depends what you read between the lines ...
[19:16] <rbasak> Guest89380: that's called a rollback plan. It would be crazy not to have one. That doesn't mean that we want to do it. That just means that we will switch to systemd when we don't think it'll regress things.
[19:16] <rbasak> "when it's ready"
[19:16] <rbasak> This is what happens when technical mailing list posts get media-ified.
[19:17] <rbasak> The plan is to switch to systemd. That has not changed. However Vivid will release on time. That has not changed. So if we can't ship with systemd, the switch will be postponed.
[19:17] <rbasak> So Martin had a plan for that.
[19:17] <rbasak> However, things are still looking good for the systemd switch in Vivid.
[19:17] <Guest89380> rbasak: fair.  i'm being a hypocrite worrying about it, tbh.  Opensuse screwed the pooch with their stack-switch to 'wicked' networking, with NO rollback option/plan.  1st time I've ever come across a release wilfully broken for an entire release cycle, AND a don't-give-a-admn attitude about it.
[19:18] <Guest89380> damn, even
[19:20] <Guest89380> how do LTS's work ... does every release get an LTS variant?  i.e., will there be a 15-LTS?
[19:21] <bekks> !lts
[19:23] <hanlon2> bekks: right.  not my question, though
[19:24] <patdk-wk> no
[19:24] <patdk-wk> normally LTS is every other year
[19:24] <patdk-wk> but that is not fixed in stone
[19:25] <hanlon2> patdk-wk: ok.  so Vivid's likely a "ride" 'til next LTS ...
[19:25] <patdk-wk> the next projected lts, is 16.04, but dunno if it will be till then :)
[19:26] <hanlon2> decisions, decisions ...
[19:28] <hanlon2> I'll admit that I very much like the idea of a server-centric community (in here ...) that's actually "heard" of Xen, and doesn't spend 99% of its time whining about Desktop button colors.
[19:28] <hanlon2> (now watch, I've probly jinxed it)
[19:30] <hanlon2> from what I can tell, those in here != those in #ubuntu/#kubuntu
[19:30] <hanlon2> mostly
[19:45] <rww> I HATE THE DESKTOP BUTTON COLORS
[19:45] <hanlon2> rww: What's a desktop?
[19:45] <rww> as far as LTS, it's been every two years since we started doing LTS, and I'd be comfortable planning for it to continue to be every two years
[19:45] <rww> (we are at my workplace, anyway)
[19:46] <rww> i forget if you'll be able to do 15.04 -> 16.04 directly or if it needs to go through 15.10 though
[19:46] <patdk-wk> must go through 15.10
[19:47] <patdk-wk> if you don't, unexpected results are expected
[19:47] <rww> i think they tweaked something with the supported upgrade paths, but yeah, i'd probably go through 15.10 regardless
[19:48] <hanlon2> are the x.04 & x.10 actual 6-month release schedule spreads? (possibly having an aha! moment ...)
[19:48] <rww> yes
[19:48] <rww> it's year.month :)
[19:48] <hanlon2> oh FFS! duh ...
[19:48]  * hanlon2 cringes
[19:51] <unused_PhD> is it possible to create a kvm with uvt-kvm with a default user other then ubuntu?