[00:00] 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] 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] I like what I'm seeing with systemd and nplan [00:00] but it's not where I need it to be yet to get openvswitch shoved in there and happy. [00:01] I'm hoping 18.04 will be more advantagious [00:02] 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] eh, xen's release cadence and canonical's don't really coincide [00:02] and 14.04 was a lot better at deploying newer releases on xen on LTS [00:03] oh? [00:03] That's surprising [00:03] 16.04's reliance on 4.6.5 is kind of... an odd move [00:03] not that I'm complaining, I didn't see much value in the xen 4.7 or 4.8 releases [00:03] and the security issues were resolved with 4.6.5's release [00:04] 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] and pushing fresh qemus out to everyone with SRUs also doesn't seem to be a wonderfully great idea [00:05] so really, they're stuck 'tween a rock and a hard place. [00:05] Sometimes the best move is simply to abstain. [00:14] 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] yep, 4.9's released, and 4.10 should cement the new pvops stuff before 18.04, hopefully. [00:19] 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] So even knowing the speed it's downloading doesn't help [00:49] 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] absolutely, and I'd highly recommend it for any non-secure workloads. [01:00] Seen AMD's slides for Ryzen Pro and EPYC yet? Supposed to support some interesting memory encryption shenanigans [01:00] 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] 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] Ubiquity is hack with hacks layerd on hacks [01:01] Yeah, it's quite encouraging to see memory encryption get slightly more mainstream [01:01] and keep in mind that things are always churning around it [01:02] like the switch to aufs [01:02] Especially for slightly-more-trusted cloud guest VMs [01:02] It's actually a substantial attack surface mitigation [01:02] overlayfs and just something as simple as tail were a nightmare to deal with [01:03] Yeah, a twisty maze of (self-)recursively called shell scripts [01:03] a few of which deign to use set -e, but otherwise.. [01:03] tip: use "tail ---disable-inotify -f FILE" on overlayfs [01:03] Looks brittle [01:03] that's TRIPLE dash. [01:03] and also undocumented. XD [01:04] 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] That might be the first triple-dash GNU/Linux option I've seen... [01:04] yep. I know it suprised the hell out of me to know it existed. [01:04] (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] and doubly so to learn it solved my issue [01:05] Any idea why they didn't use --disable-inotify instead? [01:05] or Google's cloud offerings, also a lot of -single-dash switches [01:05] in general inotify doesn't fail except under certain edge cases like half-retarded stacking filesystems [01:06] and it's so well-worn that fanotify responds to inotify now [01:07] Doesn't fanotify not support everything inotify does? [01:07] I haven't used either much so am not sure of details though [01:07] and has replaced it. yes. [01:08] anything that calls inotify is calling fanotify behind a shim, AFAIK [01:08] Ah, first sentence of StackOverflow question on this: "fanotify, built on top of fsnotify, is supposed to replace inotify which replaced dnotify" [01:12] hence my comments on constant churn. [01:12] 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] 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] if I recall correctly, d-i indicates it came from debian-installer [01:13] I don't know how much the two share, code-wise. [01:13] Huh, so that'd be where to go with any patches, okay [01:13] dunno -- it may be a fork, it may be a submodule, I've never looked into it. [01:14] 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] (and also include d-i, etc) [01:14] submodule, yeah. [01:14] git makes that easy [01:14] bzr and subversion have their own wyrding way [01:16] 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] https://pastebin.com/Lu4U7Gi3 [01:19] so in that first while loop, add a check for whichever of type/fs/path/name/etc identify zram [01:21] 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:21] Debian bug 381870 in partman-crypto "Does not prevent setup of unencrypted swap" [Important,Fixed] [01:22] 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] ah, indeed, it's a submodule at https://anonscm.debian.org/cgit/d-i/partman-crypto.git/tree/check.d/unsafe_swap [01:40] e.g., https://pastebin.com/8prjBU1d is a concept patch [04:19] 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] 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] and swapoff -a doesn't actually do what it says on the tin [04:22] https://github.com/kamilion/kamikazi-core/blob/62e8bc0260057b1f73e1c214a063bd4dac6bc938/tools/xenial/deploy/pre-update.sh [04:23] # We have no idea how many disks are connected. Hopefully it's less than 96. [04:23] for i in {0..96}; do swapoff -a done [04:23] That's kind of insane [04:23] you have no idea. What was more insane was 48 wasn't enough the first time around *sob* [04:24] though, this has ended up being useful in *so* many other places. [04:24] https://github.com/kamilion/kamikazi-core/blob/62e8bc0260057b1f73e1c214a063bd4dac6bc938/tools/xenial/deploy/update-repos.sh [04:25] stash, pull, pop... works *suprisingly* well. [04:27] especally since some of the stuff in here has a chance of being changed in early runtime by the roles scripts [04:27] https://github.com/kamilion/kamikazi-core/tree/master/resources/xenial/config [04:27] That looks handy, yeah. [04:27] Seems like it would backfire occasionally, but your comment does note that [04:28] generally only barfs if there's local changes to something the remote side has updated [04:28] hence the segmentation in my repo of the three major zones, buildscripts, tools, and resources [04:29] Does stash pop use the full git merge capabilities? [04:29] yeah [04:29] but it can't deal with some merges [04:29] hence the warning comment [04:30] I see you love various popular PHP packages. :p [04:30] 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] s/love/loath/i [04:31] 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] none of my images contain PHP or anything php related [04:31] I made a personal rule to stick with the languages shipped on the existing livecd [04:32] so by and large it's mostly python based tools and libraries. [04:32] you cannot have an ubuntu system without python -- it's required by the package manager. [04:32] 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] pretty much everything else is optional at this point, including perl [04:33] http://www.phpsadness.com/sad/47 [04:33] nuff said [04:33] $ php -r 'var_dump("61529519452809720693702583126814" == "61529519452809720000000000000000");' [04:33] bool(true) [04:33] 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] So it's never going away [04:33] `suppose the $password is "ximaz", which has an all-numeric hex-encoded MD5 hash of "61529519452809720693702583126814"` [04:33] "oh gee, that looks like a float to me, *truncated*" [04:34] well, you're just a shitty programmer, you SHOULD have used ===... [04:34] That seems unsafe to expose to external data [04:34] what the hell is ===?! [04:34] And unsafe in a way a lot of people won't realize [04:34] bingo. [04:34] PHP is filled to the brim with "I need to pay an engineer more money to think" pitfalls, built in [04:35] and you tend to see the same trend with large PHP applications that aren't fully open source. [04:36] 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] 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] 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] It actively encourages bad practices. [04:37] yeah. [04:37] And one of my reasons for sticking with python [04:37] if it's not fast in python, import a C/C++ library that does it faster. [04:37] 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] no need to overoptimize. [04:37] even in 17.10 [04:38] 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] 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] f strings look interesting, but that falls into the first category [04:38] but that's also one of python's shortfalls... It's event reactors are nice, but... [04:38] https://github.com/channelcat/sanic [04:38] nodejs's libuv just blows most others out of the water. [04:39] and uvloop is just so easy to take advantage of now [04:39] and it works well on windows too. [04:39] same python code runs lots more places, which is nice when you don't try to control your developer workstations [04:40] who cares as long as the wirebytes aren't crazy. [04:40] 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] that's where python shines. Gluing together lots of faster code [04:41] and one of the biggest reasons it's seen such popularity in scientific computing [04:41] 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] python's also doing a lot more under the hood, with variable types, for instance. [04:42] 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] Python's Decimal type still makes me squee inside as 'something they did right the first time' [04:42] they did improve the bytecode a bit in 3.6, that's true [04:43] Or, because variable access is kind of slow, repeating the same constant values across the code, making maintenance harder [04:43] and there's other methods still, such as pypy or even JITting machine code out [04:43] http://deeplearning.net/software/theano/ [04:43] Theano's really good about machine code emission [04:43] both on the CPU and on GPUs [04:43] 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] yep. [04:44] Don't overoptimize. [04:44] prototype, make it work, optimize what's slow until it works the way you need it. [04:44] 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] 6 hashes per second with pure python code [04:45] 2364 hashes per second with the C wrapper around libscrypt. [04:45] but, then I have to have pip around, and the c compiler, and all the headers... [04:46] Anything per-byte or per array index or per etc I've found to have that kind of mismatch, yeah [04:46] Hits the VM hard [04:46] So, kamikazi has pip around, and the c compiler, and all the headers... and compiled versions of libscrypt and uwsgi... [04:47] In general it's pretty much set up to be a workable python development system out of the bag [04:47] plus, well, in order to support DKMS, I had to have that same baggage around... [04:47] 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] open-vm-tools and sysdig both being dkms modules. [04:48] ruby's alright on windows, as is go [04:48] perl's fine too as long as you don't try relying on tk or other gui stuff [04:48] but anything that relies on sh -c generally fails hard [04:49] 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] Ditto Ruby, in my brief(er) experiments [04:49] go shares the java idea that packages can have a namespace on the greater internet [04:49] and I do appreciate that [04:49] Ruby, on the other hand... Nnnnnnghhhhhhhh. [04:50] SO MUCH ANGER. SO LITTLE TIME. [04:50] the whole gems thing and RVM is just oh. mi. gawd. [04:50] Sure, for their design intentions, Go executes better than most languages I've tried [04:50] it spits out a static binary. [04:50] really no different than gcc or llvm clang's output [04:51] on the up side, it can also spit out dynamic modules (.so) that python is more than happy to load [04:51] so mixing go and python is a real good way to get concurrency and adaptability [04:51] 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] Rust too. [04:52] I know they tried to lure C programmers in, but IMO Go works best as a kind of faster Python [04:52] 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] And with go spitting out static binaries... that can kind of clash [04:53] 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] I knew Rust emphasized C interop, but hadn't realized Go did. Neat. [04:53] machine code on disk is machine code on disk. [04:53] How's that different from any other compiled language though, in principle? [04:54] well, python's compiled bytecode (.pyc) that's interpreted [04:54] Sure, but some languages care more about keep to C calling conventions, name mangling, etc. [04:54] JVM does some similar stuff [04:54] And some are happy to live in their own world [04:54] and the whole .net ecosystem uses CIL as an intermediary bytecode before rendering real machine code [04:54] which I thought was a very neat approach [04:55] and allows the same CIL to be specialized for ARM or AMD64 or SPARC [04:55] without having the original source code [04:56] 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] 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] Granted, by comparison with Python, the JVM, or .Net, it's more opaque. [04:56] As far as I know, during the go compilation, the binary is only partially stripped [04:57] 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] and line number definitions [04:57] but I'm not a Go pro. [04:57] 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] kinda picking up bits and pieces of it as I go along [04:58] same. Couple little microservice responders that spit a blob of JSON over a socket [04:58] and python+flask app that uses jinja2 to make the pages that request those JSON blobs [04:58] jinja2 does it's job well, I find. [04:58] Sounds like the sort of thing it was designed for [04:59] and it's general purpouse, not just html specific like PHP tends to be [04:59] I've used it to template nginx configs, all kinds of stuff. [04:59] and flask is so simple and reliable because it doesn't *DO* anything [05:00] 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] defines a couple useful annotations too [05:00] 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] 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] A very PHP ethos. [05:01] But with reasonable design backing it. [05:01] actually, go ships with a couple, and points you at a couple more. [05:01] you've got your choice of at least three HTTP compatible responders [05:01] Still less fragmented, so far as I can tell [05:02] one that's HTTP2+TLS only, one that's HTTP2+HTTP1.1, and another pure HTTP1.1 minimal responder. [05:02] only the former actually bothers touching things as low as the TCP level [05:02] the other two are like "yeah, gimme a socket." [05:03] and then you can always just ask for more with their fancy namespaced requirements [05:03] 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] like https://caddyserver.com/ [05:03] heh, even python has that problem [05:04] I've been using ujson lately for performance stuff [05:04] but that's generally when I have to parse [05:04] Those seem interestingly different enough (HTTP2+TLS, HTTP2+HTTP1.1, and pure HTTP1.1) that I don't consider those duplicate functionality [05:04] There's just almost no overlap at all between the first and last for example [05:04] flask's built in 'jsonify' is pokey but more than enough to deal with a 20kb response [05:04] well, HTTP2 requires TLS, it's part of the spec [05:05] so the middle one basically sits on top of the left and right code [05:05] Ditto on ujson. Surprisingly fast. [05:05] and upgrades HTTP1.1 to 2.0 if possible, switching on TLS in the process. [05:05] And its source is straightforward -- no real tricks that I spotted. [05:05] yep. [05:05] I goof around with Unity3D games [05:05] so json's kind of a big thing for moving stuff back and forth for me [05:06] yaml's kind of partially supported but not exposed... [05:06] and their default object serialization is JSON based anyway, so trying to farf around with YAMLizing it would be counterintuitative [05:07] So that HTTP library responder organization seems completely reasonable -- not duplicating things, but just nicely factoring them out. [05:07] JSON's supported everywhere so [05:07] and Unity's all C# based... and not just C#... an old old version of mono 3.10... [05:08] so .net 3.5 is basically as far as you get. [05:08] Even the newish Unity 5.x versions? [05:08] yep. [05:08] you get a couple .net 4 features like linq [05:09] 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] Odd on the surface they haven't updated to newer Mono [05:09] didn't need to -- the bytecode interpreter is reasonably robust [05:09] I saw that. Was confused what it operationally meant -- whether they'd just do everything incrementally, or just abandon version numbers. [05:10] they've upgraded the bytecode compiler several times though [05:10] 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] which is kind of interesting on a technical level [05:11] and other forum posts that have 3rd party'd it beforehand (almost 2 years ago now) [05:11] Part of the .Net core initiative, or? [05:11] the compiler, yes; I don't know what they're going to do about "dotnet" [05:12] 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] I'm sort of surprised the licensing aspects worked out with Roslyn [05:12] so far everything I've seen has pointed towards mono4 + the roslyn C#6 compiler [05:13] MS hasn't always made it easy to redistribute their components [05:13] *chuff* [05:13] https://www.theregister.co.uk/2001/06/02/ballmer_linux_is_a_cancer/ [05:14] Soon as they pitched him on the curb, things got a lot better, for the Samba team and novell [05:14] And now he has a basketball team [05:14] Ah, MS in full embrace/extend/extinguish era bloom [05:15] It's sort of amazing how much more open their new CEO (forget his name)'s made them [05:15] 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] ehh, I have some points of contention on that one [05:16] 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] 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] then broke that model up for 8 and 10, and it's unsuprising why they can be brittle [05:17] but the servicing side definitely learned a lot from linux [05:17] the whole WIM model is a lot more linux-package-manager-transaction-like than ever [05:18] 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] I've lost count of how many programs claim to remove Win10's spying/telemetry [05:18] 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] *chuff* [05:18] Sure, and they've picked up other aspects of that in Chocolatey, etc. [05:18] which of course is not possible, because they've shoved the telemetry right inside the visual studio runtime dlls now [05:19] and that even infests machines as old as XP and vista that run apps built with visual studio 2015/2017 [05:19] Had not realized/known that. Disappointing, but unsurprising. [05:20] and also wine :D [05:20] They already retroactively added it to 7 and 8.x. [05:20] installing the visual C++ runtimes on wine is a real adventure. [05:20] "you need the msxml package first" [05:20] ends up just googling it and finding out about winetricks [05:20] 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] https://github.com/Winetricks/winetricks [05:21] yep [05:21] I assume you saw https://github.com/taviso/loadlibrary ? [05:22] I got quite a few chuckles reading his readme.md [05:22] Hah, I hadn't actually. That is funny [05:22] It's even practical, which is a nice bonus [05:23] and someone will probably hook it up to python pretty soon [05:23] Looks like that's how he's been finding all those AV 0-days [05:23] "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] https://www.theregister.co.uk/2017/06/23/windows_10_leak/ [05:24] well, I guess THAT's not a problem anymore [05:25] 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] At least that will catch people up to current versions [05:26] It also looks like it's not super-secret to begin with, just somewhat controlled distribution [05:26] 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] Blackhats should be assumed to have access to it anyway [05:26] pfft [05:26] https://lcamtuf.blogspot.com/2014/11/pulling-jpegs-out-of-thin-air.html\ [05:26] https://lcamtuf.blogspot.com/2014/11/pulling-jpegs-out-of-thin-air.html [05:27] we have AFL [05:27] and mixing AFL and loadlibrary is going to end up with some fuuuuuuuuuuuuuuuuuun [05:27] hah, I like those possibilities [05:28] I guess with tools that powerful, source access isn't as important anyway [05:28] "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] "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] mostly thanks to libjpeg barfing at every 'bad' input [05:29] still, afl blows my mind. [05:29] It's basically flatline dixie in a github repo. [05:29] 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] 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] http://imgur.com/a/knY8l https://n-o-d-e.net/cyberdeck64.html http://i.imgur.com/zcxb6qk.png [05:31] the slide out display in that still tickles my inner geek [05:32] it's just too bad he ran with the MATE image instead of the Lubuntu one... [05:33] (super thanks to flexiondotorg for his work on MATE and Lubuntu for the Pis) [05:35] 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] projects that I've seen, and, it is quite appealing [05:35] yep. Good use for a commodore 64C case [05:36] The slide out display is one of the best parts [05:36] https://www.redbubble.com/shop/cyberpunk+stickers [05:36] The stickers "make it" though. [05:36] especally the one on the bottom. [05:37] http://i.imgur.com/ixHyqFW.jpg [05:38] They add a lot of polish to what would otherwise be a more straightforward use of that case, yeah. [05:38] what isn't visible is that this unit was meant for use with a HMD [05:38] the slide out screen is apparently hooked to the SPI bus and run at 33Mhz, leaving the HDMI port open [05:39] 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] the FN+Enter really makes me grin though [05:40] I know exactly why that's there (Filthy Domain-joined workstationseses! HISSS!) [05:41] it HAS pushed me towards thinking about the same concept [05:41] https://www.aliexpress.com/store/group/Orange-Pi-Zero-Plus-2-H5/1553371_511302832.html [05:42] https://goo.gl/photos/WqMLAni2FhE27Tm18 [05:42] 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] I think I might be able to fit an orange pi zero plus 2 H5 inside of this matias halfkeyboard. [05:42] I've already stuffed an arudino micro in there to replace the old palm pilot serial cable (9600 baud 8n1, thankfully) [05:43] Do they run anything close to mainline Linux? [05:43] armbian's got a near-mainline build [05:43] Last time I looked at those SBCs, most of them had some weird old kernel version they were stuck on [05:43] https://www.armbian.com/orange-pi-zero-2-h3/ [05:43] yeah [05:43] allwinner's been slowly upstreaming stuff [05:44] and the H2/H3/H5 series are based off the A10/A20's IP blocks, which are pretty well GPL supported now [05:44] That's encouraging, both the armbian link and Allwinner upstreaming [05:44] http://linux-sunxi.org/Xunlong_Orange_Pi_Zero_Plus_2 [05:44] their little NAS board has me really interested [05:45] https://www.aliexpress.com/store/product/Orange-Pi-Zero-NAS-Expansion-board-Interface-board-Development-board-beyond-Raspberry-Pi/1553371_32789632568.html [05:45] got a pair of SATA UASP chips on it [05:45] http://www.jmicron.com/PDF/brief/jms578.pdf [05:46] which means SMART and most ATA stuff like Secure Erase should work [05:46] and UASP continues to work even under USB2.0 fallback (good thing to know!) [05:46] 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] (different device tree, different kernel) [05:47] that's actually being cleaned up right now [05:47] the arm64s are being prepped with uEFI tables and other fun annoyances [05:47] 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] and just swap out a couple of packages [05:48] so in theory we should have much less of a problem supporting ARM SOCs on arm64/AArch64 [05:48] Obviously armbian's better than not having armbian [05:48] 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] 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] and when linaro went with arm7, so did everyone else. [05:49] 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] nah, we'll still have that for quite a while [05:49] device tree overlays and all kinds of idiotic uboot stuff for the tiny 32bit chips [05:49] https://www.servethehome.com/exclusive-first-cavium-thunderx-dual-48-core-96-core-total-arm-benchmarks/ [05:49] the real big iron already went uEFI [05:50] and it's the smaller SoCs that are racing to catch up [05:50] Pi3 should have uEFI support fairly soon though [05:50] I mean arm is much better than the joke that is ia-64 which is now dead [05:51] 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] but beagleboard (who uses i2c roms to identify Capes) will probably still remain with it's existing setup [05:51] eh, there's another mali400 driver that's popped up a little while ago [05:51] 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] At least in c-ray, that chart shows it being more-or-less in the ballpart of competitive [05:52] Needs 10x the cores to achieve it though [05:52] Kamilion, why I do not use android [05:52] is the whole only vendor blobs and can't get anything else to work [05:53] 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] but there'll always be some sucker out there with more money than time, and less brains than engineers. [05:54] it WAS a nice architecture till they spat in FOSS' face. [05:54] now arm's malis are really preferable in my opinion, even if the support for them isn't great. [05:55] 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] http://malideveloper.arm.com/faq/what-are-bifrost-midgard-and-utgard/ [05:55] and guess what, bifrost and midgard both stole PowerVR's thunder [05:55] in this case, PowerVR's claim to fame, their tiled rendering engine. [05:56] ergh, broken link [05:56] http://www.anandtech.com/show/10375/arm-unveils-bifrost-and-mali-g71/3 [05:56]