[00:00] <nistonce> Oh, yeah, systemd-resolved doesn't seem to be the best software in general. I checked some Ubuntu VMs I had in response to that issue and they were 16.04 and not running systemd-resolved. Apparently its design isn't great...
[00:00] <Kamilion> and I tend to use openvswitch, so I'm not really affected by any of the churn in networkmangler or systemd's networkplan stuff.
[00:00] <Kamilion> I like what I'm seeing with systemd and nplan
[00:00] <Kamilion> but it's not where I need it to be yet to get openvswitch shoved in there and happy.
[00:01] <Kamilion> I'm hoping 18.04 will be more advantagious
[00:02] <nistonce> I'd like to think that's why they're bringing it in in 17.10, to get it ready for 18.04, by which point they'll not be trying anything too likely risky.
[00:02] <Kamilion> eh, xen's release cadence and canonical's don't really coincide
[00:02] <Kamilion> and 14.04 was a lot better at deploying newer releases on xen on LTS
[00:03] <nistonce> oh?
[00:03] <nistonce> That's surprising
[00:03] <Kamilion> 16.04's reliance on 4.6.5 is kind of... an odd move
[00:03] <Kamilion> not that I'm complaining, I didn't see much value in the xen 4.7 or 4.8 releases
[00:03] <Kamilion> and the security issues were resolved with 4.6.5's release
[00:04] <Kamilion> but it strikes me more as "we're too lazy to bother updating the whole toolstack to support the new features, so just wait until we are"
[00:05] <Kamilion> and pushing fresh qemus out to everyone with SRUs also doesn't seem to be a wonderfully great idea
[00:05] <Kamilion> so really, they're stuck 'tween a rock and a hard place.
[00:05] <Kamilion> Sometimes the best move is simply to abstain.
[00:14] <nistonce> It sounds like it may be partly a temporary timeline misalignment that eventually both Ubuntu LTS and Xen will reconverge (independently) to something improved
[00:15] <Kamilion> yep, 4.9's released, and 4.10 should cement the new pvops stuff before 18.04, hopefully.
[00:19] <nistonce> bzr's 'progress bar' is worse than https://www.xkcd.com/612/ -- at least there, the endpoint is know, but bzr branch will show X/Y, 2*X/Y, etc, then whoops, sorry, it's actually of Y*10
[00:19] <nistonce> So even knowing the speed it's downloading doesn't help
[00:49] <nistonce> zram apparently does help a lot: https://bryanquigley.com/memory-usage/ubuntu-16-04-livecd-memory-usage-compared (not news here, presumably, but I hadn't realized)
[00:59] <Kamilion> absolutely, and I'd highly recommend it for any non-secure workloads.
[01:00] <Kamilion> Seen AMD's slides for Ryzen Pro and EPYC yet? Supposed to support some interesting memory encryption shenanigans
[01:00] <nistonce> I could see that it'd add a horrific sidechannel for any sensitive workloads though, to be fair to the ubiquity people on this
[01:00] <nistonce> I'm simultaneously learning (by looking at how it does this) how it could be fixed and growing less convinced it's a net positive to fix :p
[01:01]  * Kamilion chuckles
[01:01] <Kamilion> Ubiquity is hack with hacks layerd on hacks
[01:01] <nistonce> Yeah, it's quite encouraging to see memory encryption get slightly more mainstream
[01:01] <Kamilion> and keep in mind that things are always churning around it
[01:02] <Kamilion> like the switch to aufs
[01:02] <nistonce> Especially for slightly-more-trusted cloud guest VMs
[01:02] <nistonce> It's actually a substantial attack surface mitigation
[01:02] <Kamilion> overlayfs and just something as simple as tail were a nightmare to deal with
[01:03] <nistonce> Yeah, a twisty maze of (self-)recursively called shell scripts
[01:03] <nistonce> a few of which deign to use set -e, but otherwise..
[01:03] <Kamilion> tip: use "tail ---disable-inotify -f FILE" on overlayfs
[01:03] <nistonce> Looks brittle
[01:03] <Kamilion> that's TRIPLE dash.
[01:03] <Kamilion> and also undocumented. XD
[01:04] <Kamilion> so yeah, I'm quite thankful we're now on aufs where things don't go all weirded out at the slightest edge case
[01:04] <nistonce> That might be the first triple-dash GNU/Linux option I've seen...
[01:04] <Kamilion> yep. I know it suprised the hell out of me to know it existed.
[01:04] <nistonce> (if anything, a lot of the outside cloud-related management commandline software I use, e.g., for AWS, goes back to single dashes)
[01:04] <Kamilion> and doubly so to learn it solved my issue
[01:05] <nistonce> Any idea why they didn't use --disable-inotify instead?
[01:05] <nistonce> or Google's cloud offerings, also a lot of -single-dash switches
[01:05] <Kamilion> in general inotify doesn't fail except under certain edge cases like half-retarded stacking filesystems
[01:06] <Kamilion> and it's so well-worn that fanotify responds to inotify now
[01:07] <nistonce> Doesn't fanotify not support everything inotify does?
[01:07] <nistonce> I haven't used either much so am not sure of details though
[01:07] <Kamilion> and has replaced it. yes.
[01:08] <Kamilion> anything that calls inotify is calling fanotify behind a shim, AFAIK
[01:08] <nistonce> Ah, first sentence of StackOverflow question on this: "fanotify, built on top of fsnotify, is supposed to replace inotify which replaced dnotify"
[01:12] <Kamilion> hence my comments on constant churn.
[01:12] <nistonce> IMO the most principled way to change ubiquity that I've so far spotted is for d-i/source/partman-base/parted-server.c to recognize that /dev/zram* isn't actually of type linux-swap no matter what it looks like
[01:13] <nistonce> Because while one could still argue it's a bad idea, it's not a bad idea to use with zram for the reason the scary dialog box says
[01:13] <Kamilion> if I recall correctly, d-i indicates it came from debian-installer
[01:13] <Kamilion> I don't know how much the two share, code-wise.
[01:13] <nistonce> Huh, so that'd be where to go with any patches, okay
[01:13] <Kamilion> dunno -- it may be a fork, it may be a submodule, I've never looked into it.
[01:14] <nistonce> I was confused about that, since when I bzr branched the ubiquity project, it didn't contain this error message at ll, but the tarball from https://launchpad.net/ubuntu/zesty/+source/ubiquity does
[01:14] <nistonce> (and also include d-i, etc)
[01:14] <Kamilion> submodule, yeah.
[01:14] <Kamilion> git makes that easy
[01:14] <Kamilion> bzr and subversion have their own wyrding way
[01:16] <nistonce> The less risky way is to just change ./d-i/source/partman-crypto/check.d/unsafe_swap but it's not completely trivial, since I'm not sure it passes enough information along from when it accumulates partition information to where it checks things on that list, so it's not just a one-liner, I think
[01:18] <nistonce> https://pastebin.com/Lu4U7Gi3
[01:19] <nistonce> so in that first while loop, add a check for whichever of type/fs/path/name/etc identify zram
[01:21] <nistonce> and continue (skip that device being accumulated), etc. But this is simple-looking enough I'm skeptical/wary of that there were reasons it didn't happen before. zram just doesn't have the properties that disk-backed swap does, such that https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=381870 would apply (for which that unsafe_swap check was added)
[01:22] <nistonce> so either they should remove it or reword it to address the more subtly bad security properties that zram has, side-channelwise, if one cares about disk encryption to begin with. either way, https://launchpadlibrarian.net/145919591/unsafeswap.png is bullshit.
[01:32] <nistonce> ah, indeed, it's a submodule at https://anonscm.debian.org/cgit/d-i/partman-crypto.git/tree/check.d/unsafe_swap
[01:40] <nistonce> e.g., https://pastebin.com/8prjBU1d is a concept patch
[04:19] <Kamilion> oh, I should mention, by default, the livecd behavior will derp around the disks looking for swap partitions and swapon -a anything it finds.
[04:20] <Kamilion> and, even more annoyingly, there's at least two or three places where this occurs, and I couldn't track them all down
[04:22] <Kamilion> and swapoff -a doesn't actually do what it says on the tin
[04:22] <Kamilion> https://github.com/kamilion/kamikazi-core/blob/62e8bc0260057b1f73e1c214a063bd4dac6bc938/tools/xenial/deploy/pre-update.sh
[04:23] <Kamilion>     # We have no idea how many disks are connected. Hopefully it's less than 96.
[04:23] <Kamilion>     for i in {0..96}; do         swapoff -a     done
[04:23] <nistonce> That's kind of insane
[04:23] <Kamilion> you have no idea. What was more insane was 48 wasn't enough the first time around *sob*
[04:24] <Kamilion> though, this has ended up being useful in *so* many other places.
[04:24] <Kamilion> https://github.com/kamilion/kamikazi-core/blob/62e8bc0260057b1f73e1c214a063bd4dac6bc938/tools/xenial/deploy/update-repos.sh
[04:25] <Kamilion> stash, pull, pop... works *suprisingly* well.
[04:27] <Kamilion> especally since some of the stuff in here has a chance of being changed in early runtime by the roles scripts
[04:27] <Kamilion> https://github.com/kamilion/kamikazi-core/tree/master/resources/xenial/config
[04:27] <nistonce> That looks handy, yeah.
[04:27] <nistonce> Seems like it would backfire occasionally, but your comment does note that
[04:28] <Kamilion> generally only barfs if there's local changes to something the remote side has updated
[04:28] <Kamilion> hence the segmentation in my repo of the three major zones, buildscripts, tools, and resources
[04:29] <nistonce> Does stash pop use the full git merge capabilities?
[04:29] <Kamilion> yeah
[04:29] <Kamilion> but it can't deal with some merges
[04:29] <Kamilion> hence the warning comment
[04:30] <nistonce> I see you love various popular PHP packages. :p
[04:30] <Kamilion> if you change something locally, stash it, and that segment of the file's updated remotely, popping the stash may require additional input to resolve
[04:31] <Kamilion> s/love/loath/i
[04:31] <nistonce> Still, it seems like a nice middle ground -- handles merges where feasible, better than most other easily accessible methods, and doesn't fail any worse when it can't
[04:31] <Kamilion> none of my images contain PHP or anything php related
[04:31] <Kamilion> I made a personal rule to stick with the languages shipped on the existing livecd
[04:32] <Kamilion> so by and large it's mostly python based tools and libraries.
[04:32] <Kamilion> you cannot have an ubuntu system without python -- it's required by the package manager.
[04:32] <nistonce> Seems reasonable. And while PHP's improving, apparently, designwise, there's some ridiculous stuff in the past -- the hash function formerly being len(function name), so to distribute among buckets, manually ensuring various similar functions are inconsistently named so that they have different lengths, etc.
[04:32] <Kamilion> pretty much everything else is optional at this point, including perl
[04:33] <Kamilion> http://www.phpsadness.com/sad/47
[04:33] <Kamilion> nuff said
[04:33] <Kamilion> $ php -r 'var_dump("61529519452809720693702583126814" == "61529519452809720000000000000000");'
[04:33] <Kamilion> bool(true)
[04:33] <nistonce> And a lot of that stuff in the past is still present because new people learning PHP find tutorials, etc from a decade ago or similar
[04:33] <nistonce> So it's never going away
[04:33] <Kamilion> `suppose the $password is "ximaz", which has an all-numeric hex-encoded MD5 hash of "61529519452809720693702583126814"`
[04:33] <Kamilion> "oh gee, that looks like a float to me, *truncated*"
[04:34] <Kamilion> well, you're just a shitty programmer, you SHOULD have used [04:34] <nistonce> That seems unsafe to expose to external data
[04:34] <Kamilion> what the hell is [04:34] <nistonce> And unsafe in a way a lot of people won't realize
[04:34] <Kamilion> bingo.
[04:34] <Kamilion> PHP is filled to the brim with "I need to pay an engineer more money to think" pitfalls, built in
[04:35] <Kamilion> and you tend to see the same trend with large PHP applications that aren't fully open source.
[04:36] <nistonce> Yeah, for all the apologetics for it I've seen, that it's just a matter of learning the quirks, it sure does seem to have a lot of such quirks, and more severe ones than I see the tu quoque responses unearthing in Python or even Perl or...
[04:36] <Kamilion> and the larger they are, the bigger the attack surface... and no, we wouldn't DARE think about making small modular microservices... of course not, SERVER SIDE INCLUDE ON EVERY PAGE
[04:36] <nistonce> C or C++ might be dangerous, but at least it's in mostly well-advertised ways, where there are real gains to be had
[04:36] <Kamilion> It actively encourages bad practices.
[04:37] <Kamilion> yeah.
[04:37] <Kamilion> And one of my reasons for sticking with python
[04:37] <Kamilion> if it's not fast in python, import a C/C++ library that does it faster.
[04:37] <nistonce> And, I've found the Python issue with Ubuntu myself recently too -- wanted to try Python 3.6, but it's not default anywhere
[04:37] <Kamilion> no need to overoptimize.
[04:37] <nistonce> even in 17.10
[04:38] <nistonce> So yes, one can get a PPA or etc, but then one has to compile any module one uses because any binary module only is packaged so far for Python 3.5
[04:38] <Kamilion> well, there's not a lot of changes between 3.5 and 3.6 from an application designer's perspective, just minor syntax sugar improvements; mostly on the async side.
[04:38] <nistonce> f strings look interesting, but that falls into the first category
[04:38] <Kamilion> but that's also one of python's shortfalls... It's event reactors are nice, but...
[04:38] <Kamilion> https://github.com/channelcat/sanic
[04:38] <Kamilion> nodejs's libuv just blows most others out of the water.
[04:39] <Kamilion> and uvloop is just so easy to take advantage of now
[04:39] <Kamilion> and it works well on windows too.
[04:39] <Kamilion> same python code runs lots more places, which is nice when you don't try to control your developer workstations
[04:40] <Kamilion> who cares as long as the wirebytes aren't crazy.
[04:40] <nistonce> Well-written Python can be quite fast, apparently. Here, it looks like it's mostly functioning as glue between a lot of C libraries
[04:40] <Kamilion> that's where python shines. Gluing together lots of faster code
[04:41] <Kamilion> and one of the biggest reasons it's seen such popularity in scientific computing
[04:41] <nistonce> Still, its lack of concern for speed does get me sometimes -- there's a base64 encoder/decoder in the base64 module, literally several times slower than one it wraps that's just a C function in the binascii module, because it runs a few lines of Python code.
[04:42] <Kamilion> python's also doing a lot more under the hood, with variable types, for instance.
[04:42] <nistonce> And optimizing Python can too easily become a game of obfuscating it because function calls are so slow (Py3.6 improves this, to some degree, reportedly)
[04:42] <Kamilion> Python's Decimal type still makes me squee inside as 'something they did right the first time'
[04:42] <Kamilion> they did improve the bytecode a bit in 3.6, that's true
[04:43] <nistonce> Or, because variable access is kind of slow, repeating the same constant values across the code, making maintenance harder
[04:43] <Kamilion> and there's other methods still, such as pypy or even JITting machine code out
[04:43] <Kamilion> http://deeplearning.net/software/theano/
[04:43] <Kamilion> Theano's really good about machine code emission
[04:43] <Kamilion> both on the CPU and on GPUs
[04:43] <nistonce> But the code measurably faster. etc. Lots of this sort of thing, so it ends up seeming like Python just wasn't designed to be optimized except insofar as one figures out how to call out of Python ASAP
[04:43] <Kamilion> yep.
[04:44] <Kamilion> Don't overoptimize.
[04:44] <Kamilion> prototype, make it work, optimize what's slow until it works the way you need it.
[04:44] <Kamilion> I started out with pure python scrypt constructs while I was working to understand it, then moved towards the C extension once I knew what I was doing.
[04:45] <Kamilion> 6 hashes per second with pure python code
[04:45] <Kamilion> 2364 hashes per second with the C wrapper around libscrypt.
[04:45] <Kamilion> but, then I have to have pip around, and the c compiler, and all the headers...
[04:46] <nistonce> Anything per-byte or per array index or per etc I've found to have that kind of mismatch, yeah
[04:46] <nistonce> Hits the VM hard
[04:46] <Kamilion> So, kamikazi has pip around, and the c compiler, and all the headers... and compiled versions of libscrypt and uwsgi...
[04:47] <Kamilion> In general it's pretty much set up to be a workable python development system out of the bag
[04:47] <Kamilion> plus, well, in order to support DKMS, I had to have that same baggage around...
[04:47] <nistonce> The need to have those does conflict somewhat with one of Python's main advantages, to which you alluded -- it's got a reasonably batteries-included approach which makes it one of the only usable language environments on Windows outside something JVM-based or similar.
[04:47] <Kamilion> open-vm-tools and sysdig both being dkms modules.
[04:48] <Kamilion> ruby's alright on windows, as is go
[04:48] <Kamilion> perl's fine too as long as you don't try relying on tk or other gui stuff
[04:48] <Kamilion> but anything that relies on sh -c generally fails hard
[04:49] <nistonce> Go packages seem to have a habit of pulling random packages from github without any clear indication of what sort of build environment they'd need
[04:49] <nistonce> Ditto Ruby, in my brief(er) experiments
[04:49] <Kamilion> go shares the java idea that packages can have a namespace on the greater internet
[04:49] <Kamilion> and I do appreciate that
[04:49] <Kamilion> Ruby, on the other hand... Nnnnnnghhhhhhhh.
[04:50] <Kamilion> SO MUCH ANGER. SO LITTLE TIME.
[04:50] <Kamilion> the whole gems thing and RVM is just oh. mi. gawd.
[04:50] <nistonce> Sure, for their design intentions, Go executes better than most languages I've tried
[04:50] <Kamilion> it spits out a static binary.
[04:50] <Kamilion> really no different than gcc or llvm clang's output
[04:51] <Kamilion> on the up side, it can also spit out dynamic modules (.so) that python is more than happy to load
[04:51] <Kamilion> so mixing go and python is a real good way to get concurrency and adaptability
[04:51] <nistonce> It does makes sense given that that Docker, etc have picked up on using it. It's a good language for a lot of things for which there wasn't a good, widespread language before
[04:51] <Kamilion> Rust too.
[04:52] <nistonce> I know they tried to lure C programmers in, but IMO Go works best as a kind of faster Python
[04:52] <Kamilion> well, the thing with docker is, containers have an average lifetime of about 2.45 days before they're simply destroyed and replaced by a newer version
[04:52] <Kamilion> And with go spitting out static binaries... that can kind of clash
[04:53] <Kamilion> I've already seen a couple instances where developers have ended up losing their go sources and being stuck with this opaque go binary they can't do anything further with
[04:53] <nistonce> I knew Rust emphasized C interop, but hadn't realized Go did. Neat.
[04:53] <Kamilion> machine code on disk is machine code on disk.
[04:53] <nistonce> How's that different from any other compiled language though, in principle?
[04:54] <Kamilion> well, python's compiled bytecode (.pyc) that's interpreted
[04:54] <nistonce> Sure, but some languages care more about keep to C calling conventions, name mangling, etc.
[04:54] <Kamilion> JVM does some similar stuff
[04:54] <nistonce> And some are happy to live in their own world
[04:54] <Kamilion> and the whole .net ecosystem uses CIL as an intermediary bytecode before rendering real machine code
[04:54] <Kamilion> which I thought was a very neat approach
[04:55] <Kamilion> and allows the same CIL to be specialized for ARM or AMD64 or SPARC
[04:55] <Kamilion> without having the original source code
[04:56] <nistonce> Sure. I guess I consider .pyc files barely-compiled. However, for the class of languages that compile to machine code, I don't see how Go makes it particularly harder to preserve source code. Most such languages don't embed source by default in object code, unless one intentionally enables debug symbols, etc.
[04:56] <Kamilion> so "a better idea than OSX Universal Binaries" which are just a bunch of ELF binaries for various architectures tar'd up. (It's more complex than that)
[04:56] <nistonce> Granted, by comparison with Python, the JVM, or .Net, it's more opaque.
[04:56] <Kamilion> As far as I know, during the go compilation, the binary is only partially stripped
[04:57] <Kamilion> so I don't think it has full debug symbols, but I think it does still have the basic dwarf symbols and function name mappings
[04:57] <Kamilion> and line number definitions
[04:57] <Kamilion> but I'm not a Go pro.
[04:57] <nistonce> So that's as much as any language I'm familiar with of its class. (But yeah, I've only written a couple of toy programs in Go.)
[04:57] <Kamilion> kinda picking up bits and pieces of it as I go along
[04:58] <Kamilion> same. Couple little microservice responders that spit a blob of JSON over a socket
[04:58] <Kamilion> and python+flask app that uses jinja2 to make the pages that request those JSON blobs
[04:58] <Kamilion> jinja2 does it's job well, I find.
[04:58] <nistonce> Sounds like the sort of thing it was designed for
[04:59] <Kamilion> and it's general purpouse, not just html specific like PHP tends to be
[04:59] <Kamilion> I've used it to template nginx configs, all kinds of stuff.
[04:59] <Kamilion> and flask is so simple and reliable because it doesn't *DO* anything
[05:00] <Kamilion> werkzeug does all the work, flask just defines a URL routing scheme and kind of says "yeah, I'm here so jinja2 is too, because it's one of my requirements"
[05:00] <Kamilion> defines a couple useful annotations too
[05:00] <Kamilion> but 90% of anything useful in a flask app is done by extensions like flask-login or flask-principal or flask-bouncer or flask-classy (which replaces the URL routing!)
[05:00] <nistonce> But it picks up some of PHP's onboarding strengths, I think, in being opinionated with reasonable default libraries packaged with every Go installation to start with. While Scala, Rust, Clojure, etc cycle through HTTP, JSON, etc libraries, never so far really annointing any as a widespread usable default, Go just ships with one. It may not be the best, but it works.
[05:01] <nistonce> A very PHP ethos.
[05:01] <nistonce> But with reasonable design backing it.
[05:01] <Kamilion> actually, go ships with a couple, and points you at a couple more.
[05:01] <Kamilion> you've got your choice of at least three HTTP compatible responders
[05:01] <nistonce> Still less fragmented, so far as I can tell
[05:02] <Kamilion> one that's HTTP2+TLS only, one that's HTTP2+HTTP1.1, and another pure HTTP1.1 minimal responder.
[05:02] <Kamilion> only the former actually bothers touching things as low as the TCP level
[05:02] <Kamilion> the other two are like "yeah, gimme a socket."
[05:03] <Kamilion> and then you can always just ask for more with their fancy namespaced requirements
[05:03] <nistonce> The glory of JSON in Scala: https://stackoverflow.com/questions/8054018/what-json-library-to-use-in-scala (yes, the main answer's from 2013, but the 'best' answers change every year through at least 2015)
[05:03] <Kamilion> like https://caddyserver.com/
[05:03] <Kamilion> heh, even python has that problem
[05:04] <Kamilion> I've been using ujson lately for performance stuff
[05:04] <Kamilion> but that's generally when I have to parse
[05:04] <nistonce> Those seem interestingly different enough (HTTP2+TLS, HTTP2+HTTP1.1, and pure HTTP1.1) that I don't consider those duplicate functionality
[05:04] <nistonce> There's just almost no overlap at all between the first and last for example
[05:04] <Kamilion> flask's built in 'jsonify' is pokey but more than enough to deal with a 20kb response
[05:04] <Kamilion> well, HTTP2 requires TLS, it's part of the spec
[05:05] <Kamilion> so the middle one basically sits on top of the left and right code
[05:05] <nistonce> Ditto on ujson. Surprisingly fast.
[05:05] <Kamilion> and upgrades HTTP1.1 to 2.0 if possible, switching on TLS in the process.
[05:05] <nistonce> And its source is straightforward -- no real tricks that I spotted.
[05:05] <Kamilion> yep.
[05:05] <Kamilion> I goof around with Unity3D games
[05:05] <Kamilion> so json's kind of a big thing for moving stuff back and forth for me
[05:06] <Kamilion> yaml's kind of partially supported but not exposed...
[05:06] <Kamilion> and their default object serialization is JSON based anyway, so trying to farf around with YAMLizing it would be counterintuitative
[05:07] <nistonce> So that HTTP library responder organization seems completely reasonable -- not duplicating things, but just nicely factoring them out.
[05:07] <nistonce> JSON's supported everywhere so
[05:07] <Kamilion> and Unity's all C# based... and not just C#... an old old version of mono 3.10...
[05:08] <Kamilion> so .net 3.5 is basically as far as you get.
[05:08] <nistonce> Even the newish Unity 5.x versions?
[05:08] <Kamilion> yep.
[05:08] <Kamilion> you get a couple .net 4 features like linq
[05:09] <Kamilion> but it won't be until Unity 2017's release (they've deprecated major/minor version numbers for a year/month scheme) that we actually see deep architecture improvements
[05:09] <nistonce> Odd on the surface they haven't updated to newer Mono
[05:09] <Kamilion> didn't need to -- the bytecode interpreter is reasonably robust
[05:09] <nistonce> I saw that. Was confused what it operationally meant -- whether they'd just do everything incrementally, or just abandon version numbers.
[05:10] <Kamilion> they've upgraded the bytecode compiler several times though
[05:10] <Kamilion> so there's an experimental build right now with the microsoft roslyn C# 6.0 compiler, that emits CIL bytecode still compatible with mono 3.10.
[05:11] <Kamilion> which is kind of interesting on a technical level
[05:11] <Kamilion> and other forum posts that have 3rd party'd it beforehand (almost 2 years ago now)
[05:11] <nistonce> Part of the .Net core initiative, or?
[05:11] <Kamilion> the compiler, yes; I don't know what they're going to do about "dotnet"
[05:12] <Kamilion> I believe they've gone and joined microsoft's little group, but it's unclear if they'll move to dotnet or mono4
[05:12] <nistonce> I'm sort of surprised the licensing aspects worked out with Roslyn
[05:12] <Kamilion> so far everything I've seen has pointed towards mono4 + the roslyn C#6 compiler
[05:13] <nistonce> MS hasn't always made it easy to redistribute their components
[05:13] <Kamilion> *chuff*
[05:13] <Kamilion> https://www.theregister.co.uk/2001/06/02/ballmer_linux_is_a_cancer/
[05:14] <Kamilion> Soon as they pitched him on the curb, things got a lot better, for the Samba team and novell
[05:14] <lynorian> And now he has a basketball team
[05:14] <nistonce> Ah, MS in full embrace/extend/extinguish era bloom
[05:15] <nistonce> It's sort of amazing how much more open their new CEO (forget his name)'s made them
[05:15] <Kamilion> There's so many comments I could make against that, but I'll leave it with "All the sport team owners I've ever seen have been pretentious jerks with very few morals"
[05:15] <Kamilion> ehh, I have some points of contention on that one
[05:16] <Kamilion> he pushed the windows 7 development model into small teams that tended to write code and test it, and only check into the main branch when the tests passed
[05:16] <Kamilion> and that made 7 one of the better released so far, and one of the bigger reasons why so many have latched onto it
[05:17] <Kamilion> then broke that model up for 8 and 10, and it's unsuprising why they can be brittle
[05:17] <Kamilion> but the servicing side definitely learned a lot from linux
[05:17] <Kamilion> the whole WIM model is a lot more linux-package-manager-transaction-like than ever
[05:18] <nistonce> The larger complaints I've mostly seen about 8 and 10, at least, haven't been obviously related to code quality, though some correlation might exist, but rather to clearly intentionally designed anti-user hostility.
[05:18] <nistonce> I've lost count of how many programs claim to remove Win10's spying/telemetry
[05:18] <Kamilion> I dunno. I feel microsoft did their best work around the pre-7-post-7 time... .NET had major improvements, powershell became a very nice tool...
[05:18] <Kamilion> *chuff*
[05:18] <nistonce> Sure, and they've picked up other aspects of that in Chocolatey, etc.
[05:18] <Kamilion> which of course is not possible, because they've shoved the telemetry right inside the visual studio runtime dlls now
[05:19] <Kamilion> and that even infests machines as old as XP and vista that run apps built with visual studio 2015/2017
[05:19] <nistonce> Had not realized/known that. Disappointing, but unsurprising.
[05:20] <Kamilion> and also wine :D
[05:20] <nistonce> They already retroactively added it to 7 and 8.x.
[05:20] <Kamilion> installing the visual C++ runtimes on wine is a real adventure.
[05:20] <Kamilion> "you need the msxml package first"
[05:20] <Kamilion> ends up just googling it and finding out about winetricks
[05:20] <nistonce> Well as someone invariably tries with each new malware release and posts on twitter, WINE is surprisingly Windows-compatible for both good and bad ends :p
[05:21] <Kamilion> https://github.com/Winetricks/winetricks
[05:21] <Kamilion> yep
[05:21] <Kamilion> I assume you saw https://github.com/taviso/loadlibrary ?
[05:22] <Kamilion> I got quite a few chuckles reading his readme.md
[05:22] <nistonce> Hah, I hadn't actually. That is funny
[05:22] <nistonce> It's even practical, which is a nice bonus
[05:23] <Kamilion> and someone will probably hook it up to python pretty soon
[05:23] <nistonce> Looks like that's how he's been finding all those AV 0-days
[05:23] <Kamilion> "Microsoft doesn't release public symbols for every build, and sometimes the symbols lag behind for a few months after release. Make sure you're using an mpengine version with public symbols available."
[05:24] <Kamilion> https://www.theregister.co.uk/2017/06/23/windows_10_leak/
[05:24] <Kamilion> well, I guess THAT's not a problem anymore
[05:25] <Kamilion> The "Shared Source Kit" they point out as being such a big boogeyman... isn't. It IS some source, but for a large bulk of driver-facing codesurfaces, not anything like ntoskrnl.exe
[05:25] <nistonce> At least that will catch people up to current versions
[05:26] <nistonce> It also looks like it's not super-secret to begin with, just somewhat controlled distribution
[05:26] <Kamilion> But just the fact that they HAVE a shared source kit now to be able to share with big ODMs is good in my book.
[05:26] <nistonce> Blackhats should be assumed to have access to it anyway
[05:26] <Kamilion> pfft
[05:26] <Kamilion> https://lcamtuf.blogspot.com/2014/11/pulling-jpegs-out-of-thin-air.html\
[05:26] <Kamilion> https://lcamtuf.blogspot.com/2014/11/pulling-jpegs-out-of-thin-air.html
[05:27] <Kamilion> we have AFL
[05:27] <Kamilion> and mixing AFL and loadlibrary is going to end up with some fuuuuuuuuuuuuuuuuuun
[05:27] <nistonce> hah, I like those possibilities
[05:28] <nistonce> I guess with tools that powerful, source access isn't as important anyway
[05:28] <Kamilion> "At this point, the fuzzer managed to synthesize the valid file header - and actually realized its significance. Using this output as the seed for the next round of fuzzing, it quickly starts getting deeper and deeper into the woods."
[05:28] <Kamilion> "Within several hundred generations and several hundred million execve() calls, it figures out more and more of the essential control structures that make a valid JPEG file - SOFs, Huffman tables, quantization tables, SOS markers, and so on..."
[05:28] <Kamilion> mostly thanks to libjpeg barfing at every 'bad' input
[05:29] <Kamilion> still, afl blows my mind.
[05:29] <Kamilion> It's basically flatline dixie in a github repo.
[05:29] <Kamilion> https://www.redbubble.com/people/wolfecreative/works/17996500-dixie-flatline-warning-label-sticker-white?grid_pos=87&p=sticker&rbs=aeb8b144-175c-40af-bcb4-8dc23a49cda1&ref=shop_grid
[05:31] <nistonce> Sure, even given that JPEG parsing seems to be specifically amenable to this, that level of automatic structure discover's quite an achievement
[05:31] <Kamilion> http://imgur.com/a/knY8l   https://n-o-d-e.net/cyberdeck64.html  http://i.imgur.com/zcxb6qk.png
[05:31] <Kamilion> the slide out display in that still tickles my inner geek
[05:32] <Kamilion> it's just too bad he ran with the MATE image instead of the Lubuntu one...
[05:33] <Kamilion> (super thanks to flexiondotorg for his work on MATE and Lubuntu for the Pis)
[05:35] <nistonce> That's one of the more interesting, I guess I'll call it a kind of (fictional) retrocomputing, where form factor's the trickier part
[05:35] <nistonce> projects that I've seen, and, it is quite appealing
[05:35] <Kamilion> yep. Good use for a commodore 64C case
[05:36] <nistonce> The slide out display is one of the best parts
[05:36] <Kamilion> https://www.redbubble.com/shop/cyberpunk+stickers
[05:36] <Kamilion> The stickers "make it" though.
[05:36] <Kamilion> especally the one on the bottom.
[05:37] <Kamilion> http://i.imgur.com/ixHyqFW.jpg
[05:38] <nistonce> They add a lot of polish to what would otherwise be a more straightforward use of that case, yeah.
[05:38] <Kamilion> what isn't visible is that this unit was meant for use with a HMD
[05:38] <Kamilion> the slide out screen is apparently hooked to the SPI bus and run at 33Mhz, leaving the HDMI port open
[05:39] <nistonce> The keyboard sort of blatantly doesn't fit with the rest of the aesthetic (the modern shallow laptop-ish style, etc) but the rest is remarkably coherent in all the details
[05:39] <Kamilion> the FN+Enter really makes me grin though
[05:40] <Kamilion> I know exactly why that's there (Filthy Domain-joined workstationseses! HISSS!)
[05:41] <Kamilion> it HAS pushed me towards thinking about the same concept
[05:41] <Kamilion> https://www.aliexpress.com/store/group/Orange-Pi-Zero-Plus-2-H5/1553371_511302832.html
[05:42] <Kamilion> https://goo.gl/photos/WqMLAni2FhE27Tm18
[05:42] <nistonce> Never dealt with them myself, but read accounts of people who have, and the failure modes can apparently be opaque, and weird stickiness with old domain settings, etc. Apparently not fun to deal with.
[05:42] <Kamilion> I think I might be able to fit an orange pi zero plus 2 H5 inside of this matias halfkeyboard.
[05:42] <Kamilion> I've already stuffed an arudino micro in there to replace the old palm pilot serial cable (9600 baud 8n1, thankfully)
[05:43] <nistonce> Do they run anything close to mainline Linux?
[05:43] <Kamilion> armbian's got a near-mainline build
[05:43] <nistonce> Last time I looked at those SBCs, most of them had some weird old kernel version they were stuck on
[05:43] <Kamilion> https://www.armbian.com/orange-pi-zero-2-h3/
[05:43] <Kamilion> yeah
[05:43] <Kamilion> allwinner's been slowly upstreaming stuff
[05:44] <Kamilion> and the H2/H3/H5 series are based off the A10/A20's IP blocks, which are pretty well GPL supported now
[05:44] <nistonce> That's encouraging, both the armbian link and Allwinner upstreaming
[05:44] <Kamilion> http://linux-sunxi.org/Xunlong_Orange_Pi_Zero_Plus_2
[05:44] <Kamilion> their little NAS board has me really interested
[05:45] <Kamilion> https://www.aliexpress.com/store/product/Orange-Pi-Zero-NAS-Expansion-board-Interface-board-Development-board-beyond-Raspberry-Pi/1553371_32789632568.html
[05:45] <Kamilion> got a pair of SATA UASP chips on it
[05:45] <Kamilion> http://www.jmicron.com/PDF/brief/jms578.pdf
[05:46] <Kamilion> which means SMART and most ATA stuff like Secure Erase should work
[05:46] <Kamilion> and UASP continues to work even under USB2.0 fallback (good thing to know!)
[05:46] <nistonce> Armbian is certainly good to know about. Still kind of an artifact to have an entire distribution that has to be designed around basically one small quirk (having a different bootloader, etc)
[05:47] <nistonce> (different device tree, different kernel)
[05:47] <Kamilion> that's actually being cleaned up right now
[05:47] <Kamilion> the arm64s are being prepped with uEFI tables and other fun annoyances
[05:47] <nistonce> I don't know that I'll trust these things too much until pick-your-mainstream-Linux-distribution (okay, not RHEL, probably, but Arch, maybe, or Debian, or Ubuntu, or ...) can run them
[05:48] <nistonce> and just swap out a couple of packages
[05:48] <Kamilion> so in theory we should have much less of a problem supporting ARM SOCs on arm64/AArch64
[05:48] <nistonce> Obviously armbian's better than not having armbian
[05:48] <Kamilion> for the most part it's only the original Raspberry pi that has the problem of not being able to run arbitrary distros
[05:48] <Kamilion> ubuntu made a choice to support arm7 and above, and it's an arm6 device, hence why rasbian needed to exist for it
[05:48] <Kamilion> and when linaro went with arm7, so did everyone else.
[05:49] <nistonce> So ARM is finally converging to being a real platform, not just a bunch of random SoCs with random on-chip peripherals with random pinouts
[05:49] <Kamilion> nah, we'll still have that for quite a while
[05:49] <Kamilion> device tree overlays and all kinds of idiotic uboot stuff for the tiny 32bit chips
[05:49] <Kamilion> https://www.servethehome.com/exclusive-first-cavium-thunderx-dual-48-core-96-core-total-arm-benchmarks/
[05:49] <Kamilion> the real big iron already went uEFI
[05:50] <Kamilion> and it's the smaller SoCs that are racing to catch up
[05:50] <Kamilion> Pi3 should have uEFI support fairly soon though
[05:50] <lynorian> I mean arm is much better than the joke that is ia-64 which is now dead
[05:51] <nistonce> And I've seen that its graphics support (upside of not really improving it much between Pi/Pi2/Pi3 is at least there's a stable target for driver development) has been more capable in its open source form lately
[05:51] <Kamilion> but beagleboard (who uses i2c roms to identify Capes) will probably still remain with it's existing setup
[05:51] <Kamilion> eh, there's another mali400 driver that's popped up a little while ago
[05:51] <Kamilion> but for the most part, mobile GPUs aren't really well supported in linux outside of vendorblobs and "look what we patched on the android kernel, good luck reusing it anywhere else"
[05:51] <nistonce> At least in c-ray, that chart shows it being more-or-less in the ballpart of competitive
[05:52] <nistonce> Needs 10x the cores to achieve it though
[05:52] <lynorian> Kamilion, why I do not use android
[05:52] <lynorian> is the whole only vendor blobs and can't get anything else to work
[05:53] <Kamilion> as long as you stay away from PowerVR, and recently, I heard rumors that apple was moving to their own in-house GPU IP core, and Imagination's about to be up shit creek, because nobody outside of apple likes them, and they've been extremely hostile to the open source community.
[05:53] <Kamilion> but there'll always be some sucker out there with more money than time, and less brains than engineers.
[05:54] <Kamilion> it WAS a nice architecture till they spat in FOSS' face.
[05:54] <Kamilion> now arm's malis are really preferable in my opinion, even if the support for them isn't great.
[05:55] <nistonce> Yeah http://www.bbc.com/news/business-40364662 "Shares in the company more than halved in April when Imagination said that Apple was to stop using its technology."
[05:55] <Kamilion> http://malideveloper.arm.com/faq/what-are-bifrost-midgard-and-utgard/
[05:55] <Kamilion> and guess what, bifrost and midgard both stole PowerVR's thunder
[05:55] <Kamilion> in this case, PowerVR's claim to fame, their tiled rendering engine.
[05:56] <Kamilion> ergh, broken link
[05:56] <Kamilion> http://www.anandtech.com/show/10375/arm-unveils-bifrost-and-mali-g71/3
[05:56] <Kamilion> and the nice thing is, the newer designs are mostly based around GL
[05:56] <Kamilion> and compute shaders.
[05:57] <Kamilion> and I've heard they're much easier to work with than the older mali400 designs
[05:57] <nistonce> New enough GL version that Vulcan works?
[05:58] <Kamilion> the G71 was designed for Vulkan, supposedly.
[05:58] <nistonce> Or rather *Vulkan
[05:58] <Kamilion> https://developer.arm.com/graphics/vulkan/vulkan-drivers
[05:59] <Kamilion> https://www.youtube.com/watch?v=W4dWzIagMPM
[05:59] <Kamilion> and they've had video samples for 1.3 years now
[05:59] <nistonce> Ah, should ease driver development -- it looks easier to factor out the chipset-specific parts with Vulkan than the monolithic blob that is GL
[05:59] <Kamilion> yeah, the chip is driven from implimenting the specs
[05:59] <Kamilion> nice to see ARM finally taking the hint
[06:00] <nistonce> So make good-quality open source drivers in time frames people care about more likely
[06:00] <nistonce> Without needing to reveal too many trade secrets, etc
[06:00] <Kamilion> and that's where the story comes to a crashing halt
[06:00] <Kamilion> Ohai, userspace support binary!
[06:00] <nistonce> Oh, good, GPL workarounds
[06:00] <Kamilion> Eventually someone will stick it under the mmio microscope and reimpliment it
[06:01] <Kamilion> but for now, it's blobby
[06:01] <nistonce> I guess better than something tightly bound to a specific ancient Android kernel
[06:01] <Kamilion> AT LEAST this time it's the sort of granularly blobby that makes it easier to replace section by section
[06:01] <Kamilion> unlike AMD's atombios... hoooo.
[06:02] <nistonce> For whatever reason, graphics is just generally a disaster area here, both mobile and desktop.
[06:02] <Kamilion> I don't think there's anyone who actually WANTS to try and take apart AMD's 8MB bios blob
[06:02] <nistonce> Hey, at least s3tc's coming out of patent in a few months
[06:03] <Kamilion> and what's funny is I'm still missing a 'stupid' ethernet monitor.
[06:03] <nistonce> So people can actually implement GL in open source
[06:03] <Kamilion> the closest I've got is a samsung smart TV with some hacky android-derived apps brutely shoved into it
[06:04] <Kamilion> I love the *idea* of steam in-home sharing
[06:04] <Kamilion> the implimentation is... Well, it has room for improvement. Heck of a lot better than nvidia's whole Sheild thing
[06:04] <nistonce> Aren't there dozens of those? https://inconsolation.wordpress.com/ would regularly list network monitors of some sort. Not exactly the sort you're looking for though I think -- too high level/summary view
[06:05] <Kamilion> http://moonlight-stream.com/
[06:05] <nistonce> But network monitors seem to be next to text editors regarding pointless toy reimplementations
[06:05] <Kamilion> yeah, and yet companies keep doing them
[06:05] <Kamilion> https://static.gamespot.com/uploads/original/123/1239113/2840664-onlive.jpg
[06:05] <Kamilion> "Remember me?"
[06:06] <Kamilion> http://store.steampowered.com/app/353380/Steam_Link/
[06:06] <Kamilion> "ohai"
[06:06] <Kamilion> http://www.jide.com/mini
[06:06] <Kamilion> "why halo thar"
[06:06] <Kamilion> https://www.ouya.tv/
[06:07] <Kamilion> "I'm not dead, just pining for the fjords... Just kidding, I'm dead."
[06:07] <nistonce> I assume they're all incompatible and at least borderline proprietary, undocumented protocols
[06:07] <Kamilion> bingo.
[06:07] <Kamilion> they're all doing the same thing
[06:07] <nistonce> It's too bad, because the idea is good
[06:08] <Kamilion> "hey ma, I can send input events along the same TCP stream I'm viewing this h264 stream from!"
[06:08] <Kamilion> moonlight works for the nvidia shield and other nvidia streaming receivers
[06:09] <Kamilion> and there is an implimentation of the Steam In Home Streaming source for SteamOS
[06:09] <Kamilion> but I don't know if it works for the plain Steam .deb packages
[06:09] <Kamilion> or if it could be tinkered with to stream arbitrary content like a desktop.
[06:10] <Kamilion> and even RDP has modern optimizations
[06:10] <nistonce> While it's not great for latency-sensitive games, I'd guess, there are lots of use cases for it
[06:10] <Kamilion> "Oh, I see you're watching an h264 stream in that browser, WHY DON'T I JUST FORWARD THE STREAM"
[06:11] <Kamilion> Actually works quite well for latency-sensative games -- 60FPS is about 16ms per frame and human reaction is somewhere between 120ms-200ms for visual motion stimulus to be integrated
[06:11] <nistonce> I've seen that ~.2 seconds number elsewhere as a UI threshold for subjectively instant
[06:12] <Kamilion> we CAN react faster by training ourselves; but ye average baseline human that doens't play Quake 3 Arena will end up in that range
[06:12] <Kamilion> plus many people have to "stop to read" the screen
[06:13] <Kamilion> and others will absorb an entire page of text without having to read any of it
[06:13] <lynorian> Well maybe f1 2015 which I run on 16.04 not sure of any other racing games
[06:13] <lynorian> yes well network latency for text does not matter
[06:14] <Kamilion> "for visual motion stimulus to be integrated" meaning for a decision to be made based on events; not just instinct reactionary stimuli like driving
[06:14] <Kamilion> but in other games where loot mechanics come into play
[06:15] <Kamilion> instinct and training can absolutely reduce the delay between hand/eye coordination
[06:16] <lynorian> Well loot is a seperate mode for mount and blade warband which can be what I want to call third person crossbow in one mode and then you loot
[06:16] <Kamilion> and I credit linux for being the major reason why I *can* parse an entire page of text in one instant; years and years and years of watching dmesg scroll past and picking interesting messages out of it mid-scroll..
[06:16] <lynorian> but for say battle for wesnoth latency will not matter
[06:16] <lynorian> Kamilion, it pisses my dad off as he cannot read anywhere near as fast as I am
[06:17] <Kamilion> likewise. My dad looks wherever the mouse cursor is
[06:17] <Kamilion> like a young child reading with his finger underlining the word
[06:18] <Kamilion> it's so frusterating being able to intuit what the computer will do next versus watch someone else slowly struggle through reading prompts I can dismiss in milliseconds
[06:19] <lynorian> yes
[06:19] <Kamilion> to me that dialog box is like the license plate on my car
[06:20] <Kamilion> I've seen it so many hundreds of times, it's information is burned into my brain
[06:20] <lynorian> Kamilion, I think I know ubiuqity dialog prompts better than the liscense plates on cars I drive
[06:20] <Kamilion> *chuckle*
[06:21] <Kamilion> i remember a couple years back... I think it was 13.10... had two typos in the ubibuity slides
[06:21] <lynorian> Then again there was a vm graphics side where every other letter was missing and I could get it to install
[06:22] <Kamilion> Securuity and Imstallation
[06:22] <Kamilion> I still laugh inwardly whenever I remember that
[06:23] <Kamilion> like hearing a child say "aminal"
[06:23] <lynorian> at least those are fairly easy to fix if you report a bug
[06:23] <Kamilion> they were fixed before release; they only showed up in the dailys
[06:24] <Kamilion> and I only remember that because 13.04 and 13.10 were real cluster---- releases for me
[06:25] <Kamilion> 13.10 is basically the reason why I don't bother with .10 releases now *sigh*
[06:25] <lynorian> Kamilion, I wasn't testing then
[06:25] <lynorian> I started with 14.04
[06:25] <Kamilion> 16.10 would have ended up breaking a whole bunch of random stuff for me
[06:25] <Kamilion> so glad I didn't even bother spending time on 16.10/17.04
[06:25] <Kamilion> speaking of which
[06:26] <lynorian> https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1380774 this bug is a bit funny looking back
[06:26] <Kamilion> my lxqt 16.04 installation is getting a bit long in the tooth
[06:26] <lynorian> yeah
[06:26] <Kamilion> has anyone actually fixed any of the lxqt packages?
[06:26] <Kamilion> or am I still stuck on ... 0.10? I think?
[06:26] <Kamilion> maybe 0.11
[06:26] <lynorian> 0.11 is in artful I know
[06:26] <lynorian> and probably zesty
[06:27] <lynorian> I do not think they are in 16.04
[06:27] <Kamilion> yeah, pcmanfm says it's 0.10
[06:27] <Kamilion> http://puu.sh/wyJTx/e3b0ae7b29.png
[06:28] <Kamilion> outside of the desktop-not-resizing bug, I havn't really run into anything outright broken.
[06:29] <Kamilion> root window doesn't update when the display server changes resolutions
[06:29] <lynorian> Kamilion, I remember that it is fixed in .11
[06:29] <Kamilion> which is easy to trigger in VMWare Worksation by View -> "Fit Guest Now"
[06:29] <Kamilion> oh good.
[06:30] <Kamilion> now if someone would PPA 0.11 for 16.04, I'd be all set, lol
[06:30]  * Kamilion eyes simon
[06:30] <Kamilion> eh, he's got enough to do already
[06:30] <lynorian> Kamilion, I think the Qt version changed as well
[06:31] <Kamilion> also, I love that lxqt has a windows 7 taskbar icon-only mode
[06:32] <Kamilion> so much less ugly than Lubuntu's LXDE defaults... http://puu.sh/wyK1m/426b9e52bb.png
[06:32] <lynorian> Kamilion, I hate stacked windows so want the text but I want to know if the default way too long
[06:32] <Kamilion> which are so much less ugly than LXDE's defaults... XD
[06:32] <Kamilion> Hm? Stacked windows?
[06:33] <Kamilion> not sure what you're referring to...
[06:34] <lynorian> on the taskbar
[06:35] <lynorian> I want one taskbar for one window
[06:35] <Kamilion> ohh
[06:35] <Kamilion> http://puu.sh/wyK8e/6a0361377a.jpg
[06:35] <Kamilion> So you don't like this?
[06:35] <Kamilion> the way they stack, EG, Explorer, Chrome, Putty, Paint.net, Notepad?
[06:35] <lynorian> yes I do not like that
[06:36] <Kamilion> yeah, win7+aero tends to make that work well, but LXQT's windowselector is not on par
[06:36] <Kamilion> http://puu.sh/wyKc2/a82e52f4b4.jpg
[06:37] <lynorian> Although it is easy to make the panel have say a stop menu
[06:37] <Kamilion> I find it's really easy to navigate to the window I want when their live-contents are shown as the thumbnail
[06:38] <Kamilion> http://puu.sh/wyKfz/8a26960086.png
[06:38] <Kamilion> Totally unhelpful.
[06:39] <Kamilion> Absolutely unreasonably helpful, I'd say, actually.
[06:40] <Kamilion> Hi, I could have the window title as well, but I'm just going to center this icon for you. 🖕
[06:40] <Kamilion> *unhelpful
[06:41] <Kamilion> and of course, the desktop switcher widget has also lost the ability to track windows visually
[06:42] <Kamilion> which would have at least been useful to shove into the window-picker in icon mode.
[06:42] <lynorian> Kamilion, qpdfview is awesome for me espically as I can increase the pdf cache size and not have many windows open
[06:42] <Kamilion> hm, I tend to work with browser tabs a lot more than PDFs
[06:43] <Kamilion> http://puu.sh/wyKoV/0fa97ea566.jpg  Which can get out of hand quickly, I've got 185 tabs open right now
[06:43] <Kamilion> and another 30,000 stashed away
[06:43] <Kamilion> http://puu.sh/wyKpS/fb110c6e40.jpg
[06:44] <lynorian> I actually do not like having that many tabs
[06:44] <Kamilion> yeah, that window is just about to get split in half
[06:44] <Kamilion> the button two over from the bookmark star does that
[06:45] <lynorian> Too easy to have a distracting tab for me I can close the whole window
[06:46] <Kamilion> I typically visit over a thousand sites a day
[06:47] <Kamilion> today has been fewer than normal because I had a relatively long phoronix binge-read earlier (it's a friday, after all)
[06:47] <Kamilion> oh, crap, gotta check lwn's thursday-dump
[06:48] <Kamilion> oooh, casync and mkosi...
[06:48] <Kamilion> https://lwn.net/Articles/726655/#Comments
[06:49] <Kamilion> https://lwn.net/SubscriberLink/726625/acdf8d0546cb57cf/
[06:49] <Kamilion> and since we discussed it earlier, async python: https://lwn.net/SubscriberLink/726600/dc0debc356028e06/
[06:52] <Kamilion> https://lwn.net/Articles/726005/  Comments here seem worth checking out as well; for once some level headed discussion <3
[06:52] <Kamilion> and links to other cool stuff
[06:53] <Kamilion> Wha.... http://appfs.rkeene.org/web/index   This is the first I've seen of an OSX-ish app-system for linux...
[06:54] <Kamilion> ohhh, LazyFS returns with a vengance
[08:47] <Guest_> My battery indicator shows 0% with full battery. Why and how can i fix this problem ?
[08:54] <tsimonq2> Guest_: Got a screenshot?
[08:54] <Guest_> Screenshot of what ?
[08:56] <tsimonq2> Guest_: Your battery indicator
[08:57] <Guest_> are you seriouse ? I say it shows 0% all the time.
[08:57] <Guest_> Do you need a screenshot of that ?
[08:58] <tsimonq2> Yes, I'm serious.
[08:58] <tsimonq2> It can help me identify the precise bug.
[08:59] <Guest_> A screenshot will not show anything.  A empty battery.
[09:00] <Guest_> I used the same lubuntu before without this problem. After i reinstall this happens.
[09:00] <Guest_> 16.10
[09:01] <tsimonq2> Within the next month, 16.10 will no longer be supported.
[09:01] <tsimonq2> Try upgrading to 17.04.
[09:01] <Guest_> I know..
[09:01] <Guest_> and that is why i use 16.10
[09:01] <tsimonq2> Why?
[09:01] <Guest_> uppgrade is not a solution.. it shud work anyway.
[09:02] <tsimonq2> It should, I agree.
[09:02] <tsimonq2> Which is why I want to get a screenshot, that will help me fix it...
[09:02] <Guest_> In yesterday after many updates it told me the disk was full evene with 900MB free space.. If i upgrade the problem will come back with all the updates.
[09:04] <tsimonq2> Not updating isn't a solution either.
[09:05] <Guest_> To talk about other thing is not a soulution.
[09:05] <Guest_> How can i fix the battery indicator ?
[09:05] <tsimonq2> It's not a simple solution.
[09:05] <tsimonq2> I don't know the answer.
[09:06] <Guest_> Why it works before and not now ?
[09:08] <tsimonq2> I don't know.
[09:11] <Xguest> Why was i removed from the chat ?
[09:17] <tsimonq2> You were not removed?
[10:19] <nomtat> i used the magnet download, but do not know what to do with the file. help?
[18:05] <m4sk1n> hi
[18:06] <m4sk1n> on 2015 there was (simple) lubuntu-related task in Google Code In. will there be something lubuntu/lxqt-related task in 2017? or is #lubuntu-devel better place for this kind of questions?
[18:59] <eco2geek> If anyone happens to be listening: I'm playing with your "experimental" LXQt edition
[19:00] <eco2geek> The Lubuntu blog says, "The LXQt ISO will most likely break your system."
[19:00] <wxl> eco2geek: might want to head over to #lubuntu-devel
[19:00] <eco2geek> OK will do.
[21:07] <Drachon> I'm needing help I was adjusting my security settings in my profile to require my password at boot and my os loops back to the login after entering the correct password. I adjusted the config to be autologin after this by backdooring in with a live disk now it doesn't even get to the login
[21:09] <wxl> Drachon: make a new user. if they don't have the same problem, something got messed up.
[21:10] <Drachon> I can't access the system without accessing the file system from a different os
[21:10] <wxl> sure you can. open up a tty with ctrl-alt-f1
[21:11] <wxl> you'd just have to do it non-graphically
[21:11] <Drachon> it then requested my password and looped back to the graphical login now won't even get to the login
[21:13] <Drachon> it now stops at bootrmfs with a prompt and doesn't respond to any of the comands it lists in it's help list
[21:13] <wxl> sounds like you severely messed it up.
[21:13] <wxl> i would advise a reinstall, but keep your home.
[21:14] <Drachon> i was afraid of that. thank you i was just hoping there was something else i could try first
[21:15] <wxl> yeah sorry. that's pretty drastic stuff
[21:15] <wxl> it could probably be unravelled but not easily without being in front of it
[21:18] <Drachon> ya it sux. i tried adjusting the settings from the file system but it didn't work even put the old files back in and it shows system check failed no file errors
[21:21] <Drachon> thank you wxl for the help i'm off to get this straight
[21:22] <wxl> good luck Drachon
[21:22] <Drachon> thanks I'll need it
[21:55] <wxl> i replied all
[21:55] <wxl> oops
[22:18] <n-iCe> hi
[23:27] <nistonce> If I'm interested in using the Nvidia driver blob, but don't want to risk its sending back telemetry, is there any sort of equivalent of https://packages.ubuntu.com/artful/firejail (or various other container tools) one can use to prevent it [as partly kernel code] from accessing said network? Dropping routes to known IP space could help, but that seems high-maintenance.
[23:31] <nistonce> e.g., some kind of nftables setup which unless a packet was identified with a specific userspace process, dropped said packet.
[23:35] <nistonce> Ah, https://wiki.nftables.org/wiki-nftables/index.php/Matching_packet_metainformation#Matching_packets_the_socket_UID
[23:35] <n-iCe> :D