[03:16] <mscs> Hi there! I'm having an issue with my XPS13 and a thunderbolt docking station.  When I have an external display, keyboard, and mouse connected and I close the lid, my laptop suspends.
[03:16] <mscs> I've set HandleLidSwitchDocked=ignore in systemd, used dconf to edit the settings in gnome, all to no avail. Any idea what's up?
[03:17] <TJ-> mscs: anything in /var/log/syslog or /var/log/kern.log to indicate what is firing that off?
[03:18] <mscs> let me tail them and try
[03:18] <mscs> (I'm connected from a different host, so it should be ok)
[03:20] <mscs> ok. I've got the tail.
[03:22] <mscs> It's just sitting there, then on lid-close I see some kernel messages about preparing for sleep
[03:23] <mscs> doesn't look like there's anything about why. Would TLP cause it to do that?
[03:25] <TJ-> I've not played with artful but with all the changes it wouldn't surprise me if something has got lost amongst all the changes 
[03:26] <TJ-> mscs: is this with the GUI desktop running? try shutting down the GUI and just having the tty console and see whether it still sleeps on lid close. That at least would narrow down where the event is being initiated
[03:26] <mscs> ooh, good idea
[03:26] <mscs> gimme a few, let me try
[03:45] <mscs> TJ-: short answer, seems like it's something Gnome is doing.
[03:54] <TJ-> mscs: I thought it may be
[03:54] <TJ-> probably due to the upheaval of dropping unity and moving to gnome
[03:59] <lotuspsychje> mscs: whats going on, im on artful testing?
[04:08] <mscs> lotuspsychje: well, I've got a Dell XPS 13 9360 plugged into a Dell TB16 dock. 
[04:08] <mscs> I plug the laptop in over thunderbolt, the display, keyboard, and mouse all pick up fine and the laptop starts charging.
[04:08] <mscs> When I close the lid, rather than staying awake, the laptop suspends.
[04:09] <mscs> lid-close-suspend-external-monitor is false (the default), and (thanks to TJ-'s idea to test) I can tell that it doesn't happen when Gnome is stopped
[04:09] <lotuspsychje> mscs: power settings are set good?
[04:10] <mscs> as far as I can tell - they're all defaults, though I have TLP installed
[04:11] <mscs> I've got the latest bios from Dell, fully updated.
[04:12] <mscs> when we looked at syslog and kern.log the only thing we saw was the messages about the system getting ready to suspend, nothing that indicated what triggered it to do so
[04:12] <mscs> though... an update to upower just landed?
[04:13] <mscs> lol. That'd be funny. Let me try upgrading it real quick.
[04:19] <mscs> the plot thickens: it works fine in Xorg.
[04:29] <mscs> so upower update seems to have made it worse, not better. off to poke around for a bit
[04:40] <lotuspsychje> mscs: how you know your in wayland?
[04:55] <lotuspsychje> welcome azaki 
[04:55] <azaki> oh, hi. =p
[04:56] <azaki> i'm just gonna copy/paste it from the other channel, because yeah..
[04:56] <azaki> has canonical announced what the upgrade plan looks like right now for 17.10 ? i mean i assume that both people on ubuntu-gnome and ubuntu-unity are going to both just be upgraded to the same gnome-based ubuntu desktop
[04:56] <azaki> but i'm wondering if there will be any weirdness as a result of the past differences between unity and gnome flavors
[04:58] <lotuspsychje> azaki: 17.10 is still in development atm
[04:59] <lotuspsychje> azaki: so upgrade is not recommended yet
[05:00] <lotuspsychje> azaki: 17.10 gonna have gnome by default indeed
[05:03] <lotuspsychje> azaki: 18.04 will have gnome by default for LTS
[05:03] <azaki> i don't mean upgrade now...
[05:03] <azaki> i'm just wondering how the process will work.
[05:03] <azaki> i assume the old "ubuntu gnome" flavor is being discontinued?
[05:04] <lotuspsychje> azaki: ubuntu-gnome will be automaticly upgraded to ubuntu-desktop, wich is gnome by default
[05:05] <lotuspsychje> azaki: same goes for unity
[05:05] <azaki> ok, thanks. that's more or less what i wanted to know
[05:06] <azaki> because i know that canonical has been working on getting certain extensions out of the box, like dash-to-dock and others. which aren't shipped by default on current ubuntu-gnome
[05:06] <azaki> so yeah. anyways. thank you =)
[05:13] <lotuspsychje> azaki: they forked 2 extensions by default already
[05:13] <lotuspsychje> azaki: dash to dock fork and knotify indicators
[05:17] <azaki> is gnome "classic mode" still going to be available out of the box?
[05:18] <lotuspsychje> i dont think so azaki 
[05:18] <azaki> hm
[05:18] <lotuspsychje> azaki: but perhaps there might be a workaround
[05:19] <azaki> we're both talking about the same thing right? the classic mode that looks like gnome 2
[05:20] <lotuspsychje> yeah
[05:20] <lotuspsychje> default is gnome 3 right
[05:21] <azaki> yeah, the default gnome3 basically looks pretty plain, has no dock or window list.
[05:21] <azaki> and then there is the classic mode which looks like this: http://worldofgnome.org/uploads/2014/02/classic-312-desktop.png
[05:21] <lotuspsychje> !find classic
[05:21] <lotuspsychje> azaki: not sure of that mate, we will have to see in final release
[05:22] <krytarik> !info gnome-session-flashback
[05:24] <azaki> krytarik: oh, flashback is the classic mode session?
[05:26] <krytarik> Yep - https://wiki.gnome.org/Projects/GnomeFlashback
[05:28] <lotuspsychje> tnx krytarik 
[05:28] <krytarik> Sure.
[05:44] <lotuspsychje> azaki: you can also install 17.10 then wait until 18.04 LTS is out
[05:44] <lotuspsychje> to get used of new ubuntu
[05:45] <azaki> it's for a family member who is more used to the oldschool style of user interfaces
[05:45] <azaki> they are not familiar with "docks" or how they work.
[05:45] <azaki> =o
[05:46] <azaki> i suppose i could customize the extensions myself, but it's more convenient to just login using classic mode
[05:47] <lotuspsychje> azaki: you can enable/disable dock easy and make it look classic
[05:47] <lotuspsychje> just 2 addons by default
[05:48] <azaki> well, classic adds a window list also
[05:48] <azaki> and a all white theme to the ui
[05:48] <azaki> also adds the old "applications" and "places" menus in the upper bar
[05:51] <lotuspsychje> i know
[11:23] <RalphBa> hi all
[11:23] <RalphBa> I'm actually trying to install ubuntu 17.10 daily on an already encrypted usb drive. there is a huge btrfs and I tried to convince ubuntu installer to install on that btrfs without reformatting(took care there is no @ snapshot on it).
[11:23] <RalphBa>  I could configure installer, but it hangs at detecting filesystems
[11:23] <RalphBa> is there a way to even avoid partitioning configuration and directly mount /mnt for installation?
[11:24] <tomreyn> i don't think the installer supports installing into existing file systems. whats the use case?
[11:27] <ikonia> how would it know / be able to decyrpt the file system ?
[11:27] <RalphBa> I have a fully encrypted pen drive with a btrfs partition on it containing multiple subvolumes with multiple distros
[11:27] <ikonia> if it's already encypted like you say
[11:27] <RalphBa> it is
[11:27] <ikonia> how does it decrypt it ?
[11:27] <ikonia> how does it know the key ?
[11:27] <RalphBa> I would like the installer to install directly on a given subvolume and evene not to care about grub
[11:28] <ikonia> there is an option not to install grub
[11:28] <ikonia> but that sort of will fail due to the package hooks for the kernel packages
[11:28] <ikonia> as that will trigger hooks for grub
[11:28] <RalphBa> thats the thing, thats everything working. I just need the installer to do its thing on a subvolume and configure the system itself but ignoring the rest
[11:29] <ikonia> I'm curious to how it's decrypted the encypted disk for the install ?
[11:29] <ikonia> there are no prompts to enter a key, so how do you tell it where the key is to decyrpt ?
[11:29] <RalphBa> by already executing cryptsetup on console
[11:29] <ikonia> so you are manually decrypting the volume ?
[11:29] <ikonia> then starting the installer
[11:29] <RalphBa> I prepare everything, after doing cryptsetup you can select partition inside in installer
[11:30] <RalphBa> but the detecting filesystem step at installation itself hangs
[11:30] <RalphBa> so I would prefer to mount manually a subvolume as /mnt so installer ca do its stuff without caring about the rest
[11:30] <ikonia> how would it work post install, as the installer would not have setup al the cyrpt stuff, so it wouldn't know how to decrypt at boot time
[11:30] <ikonia> you can't install to /mnt target though
[11:31] <ikonia> it wants a device, not a file system
[11:32] <RalphBa> the actual ubuntu 17.04 on that usb drive is copied over from an unencrypted installation. there wasn't anything to do, everything is done by grub which is maintained by an arch installation
[11:32] <RalphBa> it passes everything as kernel arguments
[11:32] <ikonia> this sounds like pretty much non-existant use case
[11:32] <ikonia> right, so the OS doesn't need to care about the encyption
[11:33] <RalphBa> it is the use case, that ubuntu is not capable of full disk encryption (even kernel is encrypted, there is a grub hook in arch for letting grub decrypt)
[11:34] <RalphBa> so grub loads the kernel from the encrypted drive
[11:34] <ikonia> I thought it can handle FDE just fine
[11:34] <RalphBa> ?
[11:34] <RalphBa> when I tried last time with ubuntu there was still this "kernel has to be unencrypted" thing
[11:35] <RalphBa> also its kind of special setup, I avoid lvm
[11:35] <ikonia> depends on the encyption method, I'm sure it's been FDE ready since 14.04
[11:35] <ikonia> maybe earlier
[11:35] <RalphBa> just one huge btrfs
[11:36] <ikonia> the file system doesn't matter
[11:36] <RalphBa> otherwise abstraction costs performance
[11:36] <ikonia> it's disk encryption
[11:36] <ikonia> not file system encyption
[11:36] <RalphBa> yes, but ubuntu wants to setup an lvm volume for its stuff
[11:36] <RalphBa> inside the container
[11:37] <ikonia> ubuntu uses an LVM volume for one method and in the standard file system layout
[11:37] <RalphBa> well however, is it possible to just pass an already mounted /mnt to installer and skip the whole fs stuff?
[11:37] <ikonia> maybe I need to look at the current installer and see what it's capable of
[11:37] <ikonia> RalphBa: no, it won't install to /mnt/$something
[11:37] <ikonia> it wants a device not a file system 
[11:38] <RalphBa> is there a bootstrapping way?
[11:38] <ikonia> the old debootstrap guide maybe useful to adapt ?
[11:38] <RalphBa> hmm...
[11:39] <ikonia> but again you're creating a usecase / situation that it's not really designed for or desired by anyone other than you (that I've ever seen)
[11:39] <ikonia> you'll be on thin ice with it
[11:40] <RalphBa> I have no problem with fixing adapting an installed linux, just with making it installing in that case
[11:40] <RalphBa> when its there, I take care about the rest
[11:42] <RalphBa> how said, I already copied a 17.04 over and made it working well using that setup
[11:47] <tomreyn> this surely sounds like a debootstrap use case, if any.
[11:48] <RalphBa> ... I think it would be a nice thing if ubuntu once supports also a pro installation like arch.
[11:50] <RalphBa> well for now I have to do again what I didn't want to. install it first somewhere else and then copying it over :(
[11:55] <tomreyn> some call it pro, others call it finicky
[11:55] <RalphBa> and thats fun, aside of getting things more or less exactly how you want
[11:56] <RalphBa> and aside of learning a lot
[12:03] <RalphBa> ikonia, because of FDE. I actually try it on an empty drive and get the message, that the root partition on an encrypted drive needs a separate boot partition. so it does not support fde vie grub crypt feature
[12:03] <RalphBa> so yes, the usecase is pretty obvious when you want to avoid evil maid attacks
[12:04] <ikonia> docs show it supporting FDE 
[12:04] <RalphBa> how?
[12:04] <RalphBa> encrypting a drive and installing / in that encrypted container is not doing the thing
[12:05] <RalphBa> i fear here fde means not using ecryptfs
[12:05] <ikonia> have a look at the docs, I've not got a test box at hand to start the installer
[12:05] <tomreyn> ecryptfs is file system encryption, so not FDE
[12:06] <RalphBa> yes, and I fear with FDE they mean encrypting root instead of only ecryptfs but not encrypting also boot
[12:06] <RalphBa> but I mean FDE up to the last byte including the kernel
[12:07] <RalphBa> ok, up to the last bytes - grub
[12:10] <RalphBa> that first time I saw with a loot of frickeling around in arch linux
[12:10] <tomreyn> what the installer creates when you select the FDE option is an unencrypted /boot partition with kernel + initrd, the rest encrypted.
[12:10] <RalphBa> gladly its just a lot of frickling around with grub and do not really affect the kernel itself
[12:11] <RalphBa> tomreyn, unencrypted kernel = invitation for evil maid
[12:12] <tomreyn> i'm aware. and there's no way around evil maid unless you trust your firmware + hardware.
[12:12] <RalphBa> and how said, grub in the meantime is able to load the kernel from the luks container
[12:12] <tomreyn> do you?
[12:12] <tomreyn> doesn't matter if the firmware is compromised
[12:12] <RalphBa> well, better than having an exposed kernel :D
[12:13] <tomreyn> you can encrypt that in a second step if you want to, there are guides on it on the web, others have done it before.
[12:13] <RalphBa> for sure also thats not 100% but by avoiding an efi boot due to the lack of space in mbr its at least making evil maid pretty hard
[12:14] <tomreyn> i'm not convinced
[12:16] <ikonia> couldn't you just boot a kernel from a usb if you encypted the kernel to get around the "security" that an encypted kernel gives you ?
[12:16] <RalphBa> ikonia, the whole thing is an usb drive
[12:17] <ikonia> what whole thing ?
[12:17] <RalphBa> the installation will run on an usb drive. I have kind of workenv on a stick
[12:17] <ikonia> thats not what I meant
[12:17] <ikonia> I meant you're trying to protect your kernel by encypting it at boot time
[12:18] <ikonia> but couldn't you just boot a kernal from an external source to get around that "security" option
[12:18] <ikonia> I'm not seeing the value of encypting the kernel before boot
[12:18] <RalphBa> sure you could, but you'd still need the password
[12:18] <ikonia> ok ? 
[12:18] <RalphBa> which only me knows, and I will for sure not boot from another kernel
[12:19] <ikonia> what are you protecting against then ?
[12:19] <RalphBa> but only from one decrypted by grub
[12:19] <ikonia> so really you don't care about the kernel
[12:19] <ikonia> you're trying to protect the FDE encyption password held in the grub config on /boot ?
[12:20] <RalphBa> it is not held in grub config...
[12:20] <ikonia> then what are you trying to protect ?
[12:20] <RalphBa> I actually enter the password twice, one time for grub so it can load the kernel and one time for the kernel so it can decrypt root
[12:20] <ikonia> but what are you trying to protect by encypting /boot ?
[12:21] <RalphBa> so grub loaded from mbr, decrypts the kernel and the kernel decrypts root
[12:21] <ikonia> but what are you trying to protect by encypting /boot ?
[12:21] <RalphBa> So there is a decrypted chain except grub itself which is simply very small and because of the lack of space hard to compromise
[12:21] <ikonia> but what are you trying to protect by encypting /boot ?
[12:22] <RalphBa> the system I try to protect
[12:22] <ikonia> how ?
[12:22] <RalphBa> you know evil maid?
[12:22] <ikonia> what value is encypting /boot
[12:22] <ikonia> yes, I'm aware 
[12:22] <RalphBa> evail maid is an attack where you modify the unencrypted kernel to get the password when its entered by the user
[12:23] <ikonia> but it's binary 
[12:23] <ikonia> you're going to hack a copiled binary (realistically) 
[12:23] <RalphBa> to avoid the modification of the kernel, you put it inside the encrypted container
[12:23] <RalphBa> ikonia, nah, you simply replace it
[12:24] <ikonia> so you're going to replace the whole kernel and bootloader ? setup, 
[12:24] <RalphBa> when you want to do this attack, yes you simply replace it on unencrypted boot partition
[12:24] <RalphBa> thats why I want it to be inside the encrypted container
[12:25] <ikonia> how are you going to protect against keyloggers built into the keyboard ?
[12:25] <RalphBa> so it cannot be replaced
[12:25] <ikonia> or built into the firmware ?
[12:25] <RalphBa> for sure the security has limits, but a keylogger in my keyboard is something else than grabbing that stick when I'm not looking at
[12:26] <ikonia> whateer you feel is appropriate I guess
[12:26] <RalphBa> how said, the whole system is on a stick which is always with me. but I can't ensure that it is observed all the time
[12:27] <RalphBa> If I'd be an attacker, I'd take it and replace the kernel with a compromised one... If its unencrypted
[12:27] <ikonia> I'd swap out your keyboard connector
[12:28] <ikonia> easier quicker and less noticable than steeling your stick
[12:30] <tomreyn> well, that's a bit like comparing apples with oranges. yes, the entire system, both all hardware and software components (firmware, too) need to be secure to create a secure workstation. but to get there, one needs to start somewhere.
[12:31] <ikonia> unless you're in a serious data situation, I just feel it's overkill and creating a problem that you'll make an engineering mess trying to solve
[12:31] <tomreyn> so just because one component is not easily secured i would still appreciate ubuntu enabling all users to encrypt /boot and thus the kernel easily.
[12:31] <ikonia> as this discussion shows
[12:32] <ikonia> tomreyn: if it was possible easy and clean, it would be great
[12:32] <tomreyn> that's a legitimate POV, i agree.
[12:32] <RalphBa> ikonia, you'd need to enter my flat... even twice
[12:33] <ikonia> right, so why are you going to this level 
[12:33] <ikonia> if your location is protected why make this engineering mess
[12:34] <RalphBa> ikonia, the system is on a usb drive which is always with me, so not at home
[12:34] <RalphBa> and also not at company, but sometimes also in a bar
[12:34] <RalphBa> or disco, or restaurant
[12:34] <ikonia> are you not creating a problem then 
[12:35] <ikonia> carrying around a USB stick on with your "secure" data on ?
[12:35] <RalphBa> I have multiple places to work with
[12:35] <ikonia> actually - ignore me, this isn't really on topic, I think the short answer is "the installer is currently not capable of meeting your use case"
[12:36] <RalphBa> that... I already got
[12:36] <RalphBa> and the thing with the clean way, there is since it is no problem in arch and works like a charm.
[12:37] <RalphBa> grub already has this feature, I do not understand why ubuntu is not using it
[12:37] <ikonia> why don't you raise a bug report asking for clarification why the feature is not available and document the arch use case as an example
[12:38] <RalphBa> I could do that. and propably will
[12:39] <ikonia> seems like that would add some value 
[12:39] <tomreyn> please also read the *lengthy* discussions amongst grub developers befroe they intriduced the feature
[12:39] <ikonia> tomreyn: really, is there interesting background to this ?
[12:45] <tomreyn> i remember no details but that it was a long discussion, one of those with a potential to MAKE AN os DEVELOPMENT TEAM SPLIT UP.
[12:45] <tomreyn> whoops caps
[12:45] <ikonia> so clearly something serious in discussion there
[12:46] <tomreyn> also, it'd be good to read up on how rutkowska + team have implemented their workaround in qubes OS
[12:46] <RalphBa> ... ikonia do you think I'm speaking about nonexistent stuff?
[12:47] <RalphBa> that system is working for long time with arch and even with ubuntu 17.04 which I copied over from an unencrypted install
[12:47] <RalphBa> What I have to do again... thats the point
[12:48] <tomreyn> the fact that an implementation exists in another linux distribution doesn't automatically mean it's a robust implementation.
[12:48] <RalphBa> for me its actually working without problems
[12:49] <RalphBa> and without anything beeing decrypted... except grub itself
[12:49] <tomreyn> robust as in both reliably working and well hardened
[12:50] <RalphBa> as we know from linux in general, first it works then it gets hardened... but first someone has to work with
[12:51] <ikonia> RalphBa: I don't think it's non-existant, I think it's got to be balanced more, more so when you are partially creating the problem
[12:51] <ikonia> "copied over" is not an "install"
[12:51] <RalphBa> I'm aware, that it might not be as expected, but its better than the alternatives... from unencrypted linux kernel to (god beware) bitlocker
[12:52] <ikonia> you mock bitlocker - yet it's widely used in enterprises 
[12:52] <RalphBa> I know, and I know that its a pain in the as and not that secure you'd expect
[12:52] <ikonia> there are also products that can be put on the disk to encypt the disk (eg: sophos) that meet your requirement
[12:53] <ikonia> if you where serious about this you'd look at this sort of stuff, it feels like you're engineering a problem
[12:54] <RalphBa> it seems like I do this at home with low budget and not at company
[12:54] <ikonia> but you just said this is for work 
[12:54] <ikonia> as you work in multiple places
[12:54] <ikonia> and if this for home - then how secure does it "really" need to be
[12:54] <RalphBa> work is not always paid ;)
[12:54] <ikonia> no-one said it was
[12:55] <ikonia> thats why I said it feels like you're engineering a problem more than it needs to be
[12:55] <RalphBa> so as many I have two lives. one where I work for... money and one where I work for something useful
[12:55] <ikonia> and I admire people giving their time for a good cause
[12:55] <ikonia> but that doesn't really change the situation
[12:56] <RalphBa> The situation is simple, I do some critical stuff which I want to protect as good as I can within my limits and meeting my requirements
[12:56] <ikonia> if it was critical you wouldn't be taking it to a diso
[12:56] <ikonia> disco
[12:57] <ikonia> if it was critical you'd look at some other comercial products to help you cause rather than an engineering mess
[12:57] <RalphBa> Yes, it might be no usual case but it is mine. And it were always a strength of linux to support individualism. Otherwise I could use windows
[12:57] <RalphBa> It is on my keyring :D
[12:57] <ikonia> right, but it's not up to a distro to cater for your one in a million use case
[12:58] <RalphBa> no, it is not up to a distro to do that, but it would be fine if the distro respects individualism and provides hook ups where you can do something else than default
[12:58] <ikonia> it does respect individualism
[12:58] <ikonia> could you show me how ubuntu is not catering for individualism
[12:58] <RalphBa> this kind obviously not :D
[12:59] <ikonia> no, it's not
[12:59] <ikonia> or I wouldn't ask 
[12:59] <RalphBa> ubuntu is perfect when installed. but I asked for nothing more than a way to do parts of what installer is doing myself
[13:00] <ikonia> so you can do that
[13:00] <RalphBa> And that is even not bound to my special use case
[13:00] <ikonia> you can interact outside the installer, or you an patch the installer to do as you want
[13:00] <ikonia> that is bound to your usecase
[13:01] <RalphBa> no, there is another usecase installer does not allow
[13:01] <ikonia> it would be helpful to understand why ubuntu hasn't enabled the option you desire in the instaler
[13:01] <ikonia> insaller
[13:01] <ikonia> RalphBa: the installer will not cater for every usecase, 
[13:01] <RalphBa> makeing a one btrfs system where home is an own subvolume...
[13:01] <RalphBa> not possible
[13:01] <ikonia> so raise a bug/feature request for this, see if it is taken onboard
[13:01] <RalphBa> at installation... afterwards yes
[13:02] <ikonia> if there is a big need for this I'm sure people would invest engineering time
[13:02] <RalphBa> well, don't see the point of filing 100 bugs for saying, make the installer modular with the possibility to skip steps
[13:02] <ikonia> it's not 100 bugs
[13:02] <ikonia> it's 1
[13:03] <ikonia> install home onto btrfs subvolume
[13:03] <RalphBa> why not "let me do as I please and just do what I want"?
[13:04] <RalphBa> but ok, this is religion, makes no sense
[13:04] <ikonia> because that would rquire engineering work to make every component overridable
[13:04] <ikonia> that pretty much no-one wants
[13:04] <RalphBa> I have to leave for 20 minutes, after we can continue if there is need for
[13:04] <ikonia> and they would have to start applying crazy logic tracking, eg: if steps 1 + 2 skipped, valildate what was done outside the installer, before moving to step 3
[13:04] <ikonia> I don't think there is need
[13:04] <ikonia> you have a choice, raise a bug / feature request
[13:04] <ikonia> or don't
[15:24] <RalphBa> ikonia, its done. installed to unencrypted disk, copied it over, adapted fstab and crypttab, apt install cryptsetup, update-initramfs -u and everything works like a charm
[15:26] <RalphBa> gladly there is already enough stuff in the fs so the plain install cannot be used for pattern attack
[15:38] <ikonia> clearly everything doesn't work like a charm as you've had to do an excessive manual hack
[16:00] <adrian_1908> Hey, anyone having no sound in Flash under Firefox 56b ?
[16:00] <RalphBa> forget flash, its dead
[16:00] <RalphBa> oficially dead
[16:01] <RalphBa> I even wonder how you got it installed
[16:02] <adrian_1908> RalphBa: I can't, the content is flash. I share your sentiment otherwise. It worked for years before, this is a new issue for me.
[16:02] <RalphBa> how said, flash is declared dead by adobe
[16:03] <RalphBa> so you might get it installed/working but its nothing you should do
[16:05] <RalphBa> Given this progress, and in collaboration with several of our technology partners – including Apple, Facebook, Google, Microsoft and Mozilla – Adobe is planning to end-of-life Flash. Specifically, we will stop updating and distributing the Flash Player at the end of 2020 and encourage content creators to migrate any existing Flash content to these new open formats.
[16:06] <RalphBa> many browser distributors already stopped supporting flash
[16:06] <adrian_1908> Yeah yeah, I know all about that – that's not why I came here.
[16:06] <RalphBa> why you came here is because flash in firefox? is firefox still supporting it?
[16:08] <adrian_1908> Well it's certainly still possible to use it, I don't know about support by Mozilla.
[16:09] <RalphBa> ralph@ralph ~ % sudo apt install adobe-flash
[16:09] <RalphBa> completing package
[16:09] <RalphBa> adobe-flashplugin           adobe-flash-properties-kde
[16:09] <RalphBa> adobe-flash-properties-gtk
[16:09] <RalphBa> it seems to be still in partner repos
[16:12] <RalphBa> but no, sound is not working for me
[16:18] <brainwash> try with google chrome
[16:26] <nocco> I saw someone hade the option to log in using wayland instead of xorg. I didn't seem to have that option, is is something that i have to turn on?
[16:27] <brainwash> nocco: I assume it's not available when you install closed source GPU drivers
[16:27] <brainwash> nocco: is that the case?
[16:28] <ikonia> wayland is still having a problem with nvidia 
[16:28] <nocco> okej :(
[16:28] <ikonia> I'm running wayland on the greeter (only) with intel 
[16:29] <nocco> brainwash:  yes I have installed closed source gpu drivers
[16:31] <brainwash> you can still make it work though
[16:32] <nocco> Is there any open sourced option  for nvidia that I can use?
[16:32] <nocco> how ?
[16:32] <brainwash> bug 1697882
[16:34] <brainwash> 1) enabled KMS via nvidia-graphics-drivers.conf
[16:34] <brainwash> 2) sudo update-initramfs -u
[16:34] <brainwash> basically that
[16:34] <nocco> thanks!
[16:36] <nocco> Will games work better or worse in wayland? (Sorry now really sure what wayland is giving me when it lands in my hands.. )
[16:37] <brainwash> I assume that most run directly via opengl, so there shouldn't be a big performance hit
[16:39] <nocco> okej :(
[16:39] <brainwash> but running games through xwayland (mainly windows games using wine) will drag the performance down
[16:40] <brainwash> well, I'll have to search for some benchmarks I guess
[16:41] <brainwash> input could be an potential issue also
[16:41] <brainwash> performance wise it's best to stick to Xorg
[16:42] <brainwash> at least in 2017 :P
[16:42] <nocco> alright :P
[16:43] <nocco> What will wayland give me as a regular ubuntu user?
[16:44] <ducasse> nocco: several people have reported games lagging under the gnome wayland session
[16:45] <nocco> alright