**** BEGIN LOGGING AT Mon May 08 03:00:02 2017
May 08 11:58:41 <xes> oh please... https://arstechnica.com/security/2017/05/theres-a-spike-in-android-apps-that-covertly-listen-for-inaudible-sounds-in-ads/
May 08 12:32:01 <DocScrutinizer05> huh?
May 08 12:32:05 <DocScrutinizer05> april's fool?
May 08 12:32:43 <DocScrutinizer05> ohnoes! that's serious I guess
May 08 12:36:50 <DocScrutinizer05> http://www.shopkick.com/
May 08 12:37:53 <DocScrutinizer05> btw is that just me? my brain explodes, parsing >> Enabling the file effective capability bit implies that any file permitted or inheritable capability that causes a thread to acquire the corresponding permitted capability during an execve(2) (see the transformation rules described below) will also acquire that capability in its effective set.<<
May 08 12:38:57 <kerio> linux documentation lul
May 08 12:51:11 * DocScrutinizer05 wishes man pages (e.g man ip) would clearly state which capabilities the process needs to have granted to execute particular commands
May 08 12:54:27 <DocScrutinizer05> /me also wonders why on his suse system >> saturn:~ # getfattr `which ping` ;-->$ZILCH;     saturn:~ # getcap `which ping`  ;--> /usr/bin/ping = cap_net_raw+ep <<
May 08 12:54:42 <DocScrutinizer05> selinux, apparmor?
May 08 13:22:56 <DocScrutinizer05> ooh ok. getfattr --match=.* does the trick
May 08 14:45:16 <kerio> DocScrutinizer05: meanwhile freebsd can block raw sockets in jails even if you're literally uid 0
May 08 14:45:20 <kerio> :3
May 08 14:45:45 <DocScrutinizer05> suresure
May 08 14:45:53 <kerio> it actually does so by default
May 08 14:45:56 <kerio> you have to reenable raw sockets
May 08 14:46:04 <kerio> admittedly there's no granularity there
May 08 14:46:12 <DocScrutinizer05> for your leisure: https://people.eecs.berkeley.edu/~daw/papers/setuid-usenix02.pdf (dates back to 2002 or somesuch)
May 08 14:46:26 <kerio> ye but try freebsd tho ;o
May 08 14:46:33 <DocScrutinizer05> and https://superuser.com/questions/710253/allow-non-root-process-to-bind-to-port-80-and-443
May 08 14:46:37 <kerio> it's like if linux was actually sane
May 08 14:47:13 <kerio> the whole init system is written in bourne shell ;o
May 08 14:47:18 <kerio> the installer too
May 08 14:47:40 <DocScrutinizer05> >>systemd, the new service supervision and init system that can be found in some Linux distributions, is intended to do what inetd can do. However, it doesn't use a suite of small self-contained programs. One has to audit systemd in its entirety, unfortunately.<<
May 08 14:48:07 <kerio> it does have some pretty heavy monolithic parts
May 08 14:48:09 <kerio> like zfs
May 08 14:48:14 <kerio> but zfs is actually well written
May 08 14:49:16 * DocScrutinizer05 wonders if fremantle ubifs supports xattr
May 08 14:49:42 <kerio> we should migrate fremantle to zfs
May 08 14:50:13 <DocScrutinizer05> start with nuking optification!
May 08 14:50:17 <kerio> it only requires a hard minimum of 64mb
May 08 14:50:25 <kerio> what's 25% of your total ram, after all
May 08 14:57:02 <kerio> DocScrutinizer05: i think we can't freebsd, it doesn't have any filesystems for raw flash
May 08 14:57:05 <kerio> :(
May 08 14:57:35 <kerio> wait i lie
May 08 14:57:37 <kerio> it has a nandfs
May 08 14:57:43 <DocScrutinizer05> I bet you do, here
May 08 14:57:59 <DocScrutinizer05> I think freebsd is on a lot of embedded stuff
May 08 14:58:11 <kerio> are those embedded things actually running with just raw flash tho'
May 08 14:58:12 <kerio> ?
May 08 14:58:20 <DocScrutinizer05> no idea
May 08 14:58:24 <kerio> i thought the usual nowadays was eMMC
May 08 15:03:18 <kerio> DocScrutinizer05: btw i still haven't figured out how asterisk works :<
May 08 15:18:47 <bencoh> kerio: you could always load freebsd from nand and boot with an emmc-located rootfs anyway ;)
May 08 15:18:54 <kerio> sure
May 08 15:18:55 <bencoh> (load kernel* from nand)
May 08 15:19:05 <kerio> ...and use the internal nand as L2ARC ;o
May 08 15:19:17 <bencoh> :D
May 08 15:19:34 <kerio> praise the zfs
May 08 15:19:54 <bencoh> riight, this device has too much ram to spare
May 08 15:20:02 <bencoh> let's add some dedup
May 08 15:20:23 <DocScrutinizer05> LOL
May 08 15:21:29 <kerio> hey, the iphone is getting a copy-on-write filesystem
May 08 15:21:54 * DocScrutinizer05 wonders if a fs based on hashing single blocks (4k) instead of whole files might work
May 08 15:22:05 <kerio> hashing?
May 08 15:22:21 <bencoh> zfs dedup is probably not whole-file-based already
May 08 15:22:31 <kerio> yes, it's block-based
May 08 15:23:05 <kerio> with the size being (up to) the dataset's recordsize or (exactly) the zvol's volblocksize
May 08 15:23:08 <DocScrutinizer05> what btrfs and git do: store files only under their hash'name' and have the directory refer to those. automatically de-duplicates
May 08 15:23:18 <kerio> that's not really what btrfs does
May 08 15:23:23 <kerio> i'm pretty sure that btrfs is also block-based
May 08 15:23:34 <kerio> and no, it doesn't automatically dedup
May 08 15:23:35 <DocScrutinizer05> hmm, probably you're right
May 08 15:23:51 <DocScrutinizer05> git does, though
May 08 15:23:53 <kerio> it does refcounting if you snapshot and clone
May 08 15:24:09 <kerio> and you can copy and tell it to not actually write the blocks
May 08 15:24:10 <DocScrutinizer05> I know how btrfs works
May 08 15:24:15 <DocScrutinizer05> in general
May 08 15:24:25 <kerio> well, zfs also has an optional block-level dedup
May 08 15:24:36 <kerio> which i believe is not avaliable in btrfs (yet?)
May 08 15:24:47 <DocScrutinizer05> don't know
May 08 15:25:11 <DocScrutinizer05> I only seem to recal btrfs does dedup, no idea *how*
May 08 15:25:22 <DocScrutinizer05> I was assuming, probably incorrectly
May 08 15:25:28 <bencoh> /dev/null is a pretty good dedup option
May 08 15:25:30 <kerio> it's not dedup in the way people would think of it
May 08 15:26:01 <kerio> it's like...
May 08 15:26:04 <kerio> opportunistic dedup?
May 08 15:26:28 <DocScrutinizer05> anyway block level hash/dedup seems like a smart approach
May 08 15:26:41 <kerio> global dedup is probably a bad idea tbh
May 08 15:26:53 <kerio> unless your needs are very peculiar
May 08 15:27:08 <DocScrutinizer05> hm?
May 08 15:27:26 <kerio> how often do you think you'll have block-aligned duplicated data in your filesystem?
May 08 15:27:40 <kerio> with the block being quite big by default, like 128kb
May 08 15:27:42 <DocScrutinizer05> more often than you think
May 08 15:28:00 <kerio> sure if you copy a container you'll have perfect deduplication
May 08 15:28:05 <DocScrutinizer05> huh, who's using 128k blocks?
May 08 15:28:07 <kerio> but you can just do it explicitly with a snapshot and a clone
May 08 15:28:18 <kerio> DocScrutinizer05: the default recordsize for filesystem datasets in zfs is 128k
May 08 15:28:24 <kerio> which means that the blocks are up to 128kb
May 08 15:28:31 <DocScrutinizer05> zfs, meh
May 08 15:28:55 <kerio> yeah better to use the cheap penguin clone with the broken parity redundancy :^)
May 08 15:29:08 <DocScrutinizer05> huh?
May 08 15:29:18 <kerio> raid5 and the like
May 08 15:29:29 * DocScrutinizer05 heads out
May 08 15:30:05 <DocScrutinizer05> can't see raid5 in embedded
May 08 15:30:39 <DocScrutinizer05> no raid at all, to be honnest
May 08 15:31:11 <kerio> striping could be an option if having more storage devices ends up being cheaper than having one bigger storage device
May 08 15:31:19 <kerio> although that's probably seldom the case
May 08 15:31:35 <DocScrutinizer05> doing hash over a block in buffer before writing it to storage, then slightly modify metadata though seems a feasible approach
May 08 15:33:01 <DocScrutinizer05> just add one layer of redirection/abstraction, where dir entries don't list block numbers for a file but rather they list block hashes
May 08 15:33:03 <kerio> well, log-structured filesystems count as copy-on-write
May 08 15:33:25 <kerio> and there's *no way* you're doing full dedup on an embedded device
May 08 15:33:42 <DocScrutinizer05> aha
May 08 15:34:13 <kerio> that one layer of indirection ends up requiring either a lot of round trips to nonvolatile storage or an ungodly amount of ram
May 08 15:34:29 <DocScrutinizer05> huh? why?
May 08 15:34:38 <kerio> because every block has to be in there
May 08 15:34:44 <DocScrutinizer05> no
May 08 15:35:19 <kerio> yes
May 08 15:35:24 <DocScrutinizer05> I *could* implement that shit in bashscript even
May 08 15:35:55 <DocScrutinizer05> and it just writes 4k files called /.storage/7d643nfcj64393774fhswke73
May 08 15:36:08 <DocScrutinizer05> and when said file already exists then no write
May 08 15:37:37 <DocScrutinizer05> a 40k file /foo/bar would actually resemble a "symlink" of sorts, pointing to 10 block file like /.storage/7d643nfcj64393774fhswke73
May 08 15:38:55 <DocScrutinizer05> writing a second identical file /foo2/barX wouldn't create any data blocks but only generate same "symlink" list of 10 data block file hashes
May 08 15:39:29 <DocScrutinizer05> and writing a 4GB all-zeroes file would utomatically colape to only one data block
May 08 15:40:05 <DocScrutinizer05> since blockN=block2=block
May 08 15:40:12 <DocScrutinizer05> 1
May 08 15:43:04 <kerio> i mean
May 08 15:43:21 <kerio> the usual recommendation for zfs dedup are *five gigabytes* per tb of storage
May 08 15:43:26 <kerio> of ram, that is
May 08 15:43:36 <DocScrutinizer05> I'm NOT talking about zfs
May 08 15:43:41 <kerio> but i'm sure you could do it in shellscirpt
May 08 15:43:47 <kerio> *script
May 08 15:48:07 <DocScrutinizer05> I'm talking about basically doing a md5sum (or sha*) over a 4k block in filesystem buffer and then writing it to a "regular" filesystem under the name of that hash
May 08 15:49:18 <DocScrutinizer05> then create a file with the name that was originally meant for that 4k block, and write the hash name into it
May 08 15:50:16 <DocScrutinizer05> you're free to call that a "symlink" since in fact it works pretty similar
May 08 15:50:47 <DocScrutinizer05> just this "symlink" has a list of file destinations instead a single one
May 08 15:51:33 <DocScrutinizer05> and for read you concatenate the symlink destination data
May 08 15:52:29 <DocScrutinizer05> when ever any process writes a block with same hash (aka same content) then the data block already exists and thus doesn't need to get rewritten
May 08 15:53:38 <DocScrutinizer05> the problem with this approach is to *delete* data blocks. You need to do a garbage collection of sorts, or alternatively you had to count links just like with hardlinks 
May 08 15:55:25 <DocScrutinizer05> probbaly the GC can get simplified when each unlink() appends the list of hashes to a journal, so the GC only needs to check those data blocks for other links pointing to them
May 08 15:56:41 <DocScrutinizer05> or you implement refcount just like in inode based fs
May 08 15:58:37 <DocScrutinizer05> ("symlink" since in fact it works pretty similar) for files <4k it actually IS a symlink
May 08 16:02:48 <DocScrutinizer05> yes, you need some RAM for the GC. But not for regular use
May 08 16:03:48 <DocScrutinizer05> it's slower than a 'normal' fs - unless you have duplicate blocks in a file
May 08 16:05:19 <DocScrutinizer05> deduplication is pretty much instant, it basically comes for free
May 08 16:05:50 <DocScrutinizer05> except for the hash calculation
May 08 16:06:56 <DocScrutinizer05> thinking about it, I wonder if ubifs works similar already
May 08 16:14:20 <DocScrutinizer05> thimk about all the read-modify-write procedures that edit files and then write them back completely under a "new" name. They only need to write the changed 4k blocks, reusing the already existing unchanged blocks
May 08 16:23:46 <DocScrutinizer05> PoC perfectly feasuble in less than 100 lines bashscript, for a   hashfs-read /foo/bar|hashfs-write /foo/bar2; hashfs-ls /foo; hashfs-rm /foo/bar   (without the GC though)
May 08 18:39:20 <bencoh> http://maemo.org/packages/view/qmledit-qmlpreview/ seems nice :)
May 08 19:12:34 <buZz> anyone have a link to try that hildon port to devuan?
May 08 21:30:20 <DocScrutinizer05> there's no hildon port to devuan. freemangordon works on porting parts of hildon
May 08 21:31:17 <DocScrutinizer05> tbh hildon is a eather futty term
May 08 21:31:34 <DocScrutinizer05> rather fuzzy*
May 08 21:32:53 <DocScrutinizer05> if anything, hildon is similar to KDE or gnome. A DE
May 08 21:43:02 <DocScrutinizer05> http://paste.ubuntu.com/24539137
May 08 21:45:48 <DocScrutinizer05> add in a lot of this: http://paste.ubuntu.com/24539159
May 08 21:46:33 <DocScrutinizer05> an a few of these: http://paste.ubuntu.com/24539165
May 08 21:49:20 <DocScrutinizer05> for example without maemo-invoker/maemo-launcher none of the hildon-*.launch will start (and their counterparts without .launch extension are just symlinks:  lrwxrwxrwx 1 root root 22 2014-12-06 12:41 /usr/bin/hildon-home -> /usr/bin/maemo-invoker )
May 08 21:53:39 <DocScrutinizer05> checking the dependencies is real fun
May 08 21:55:20 <DocScrutinizer05> I guess you could run hildon-desktop on matchbox or even standard xorg, but... that's not really exciting
May 08 21:57:53 <DocScrutinizer05> of course you again need maemo-invoker/maemo-launcher (unless you build HD for running plain without launcher)
May 08 21:59:26 <DocScrutinizer05> that's however like running kwin on a system that has no other KDE support. Or even worse, since kwin could at least display other apps made for e.g. gnome
May 08 22:00:22 * DocScrutinizer05 waves and goes offline for a 25h
May 08 22:11:11 <Enrico_Menotti> Bye DocScrutinizer05 , thanks for all the info.
**** ENDING LOGGING AT Tue May 09 03:00:01 2017