| 00:00.25 | *** join/#maemo atk (Arch-TK@ircpuzzles/staff/Arch-TK) |
| 00:22.07 | *** join/#maemo infobot (ibot@rikers.org) |
| 00:22.07 | *** topic/#maemo is Welcome to #maemo http://maemo.org/intro/ | N9/harmattan related questions please in #harmattan ! | "firmware" see ~lf ~tabletsdev ~combined ~emmc ~flasher sdk: ~sb | http://wiki.maemo.org/Community_Council | Source: http://wiki.maemo.org/Sources | Chanlog: http://mg.pov.lt/maemo-irclog | #maemo-ssu is where the (few) devels and maintainers of the maemo-future meet |
| 00:48.24 | *** join/#maemo sunshavi (~user@190.234.106.64) |
| 01:06.11 | *** join/#maemo buZz (~buzz@192.161.48.59) |
| 01:15.44 | *** join/#maemo buZz (~buzz@192.161.48.59) |
| 01:34.37 | *** join/#maemo LouisA (~user@72.10.151.99) |
| 02:12.21 | *** join/#maemo LauRoman (~LauRoman@5-14-27-226.residential.rdsnet.ro) |
| 03:10.36 | *** join/#maemo vahe (~vahe@130.193.124.163) |
| 05:25.56 | *** join/#maemo spiiroin (~spiiroin@37-136-105-255.rev.dnainternet.fi) |
| 05:50.59 | *** join/#maemo AndrewX192 (~andrew@unaffiliated/andrewx192) |
| 06:01.49 | *** join/#maemo dafox (~dafox@188.207.101.124) |
| 06:19.26 | *** join/#maemo LauRoman|Alt (~LauRoman@5-14-27-226.residential.rdsnet.ro) |
| 06:19.48 | *** join/#maemo warfare (~falk@kilbeggan.fourecks.de) |
| 06:20.36 | *** join/#maemo vahe (~vahe@130.193.124.163) |
| 06:23.25 | *** join/#maemo atk (Arch-TK@ircpuzzles/staff/Arch-TK) |
| 06:23.52 | *** join/#maemo Oksana (~Wikiwide@Maemo/community/ex-council/Wikiwide) |
| 06:49.07 | *** join/#maemo dmth|intevation (~dmth|inte@2001:470:747a:2a:6af7:28ff:fe64:1ded) |
| 07:11.17 | *** join/#maemo arcean (~arcean@131.228.32.166) |
| 07:27.06 | *** join/#maemo eMHa_ (~mh@HSI-KBW-46-237-200-175.hsi.kabel-badenwuerttemberg.de) |
| 07:38.27 | *** join/#maemo frals (~frals@151.177.237.105) |
| 07:38.27 | *** join/#maemo frals (~frals@Maemo/community/contributor/frals) |
| 07:41.51 | *** join/#maemo florian (~fuchs@Maemo/community/contributor/florian) |
| 07:45.43 | *** join/#maemo geaaru (~geaaru@host170-152-static.43-88-b.business.telecomitalia.it) |
| 07:53.18 | *** join/#maemo Kabouik (~kabouik@158.38.1.70) |
| 07:59.32 | *** join/#maemo cyteen (~cyteen@212.159.5.224) |
| 08:52.31 | *** join/#maemo Pali (~pali@Maemo/community/contributor/Pali) |
| 09:24.13 | *** join/#maemo Pali (~pali@Maemo/community/contributor/Pali) |
| 09:25.09 | *** join/#maemo timeless (sid4015@firefox/developer/timeless) |
| 10:17.10 | *** join/#maemo ecloud (quassel@nat/qt/x-fvprakvbegdqodel) |
| 10:25.46 | *** join/#maemo turnit (~user@mon75-17-88-175-209-180.fbx.proxad.net) |
| 10:50.45 | *** join/#maemo xy2_ (~xy2_@mlv95-h01-176-134-46-233.dsl.sta.abo.bbox.fr) |
| 11:01.25 | *** join/#maemo LouisA (~user@cable-10-151-99.b2b2c.ca) |
| 11:07.57 | *** join/#maemo hurrian (~textual@unaffiliated/rikanee) |
| 11:30.03 | *** join/#maemo Kabouik (~kabouik@158.38.1.70) |
| 11:58.17 | *** join/#maemo eMHa_ (~mh@p200300738E178900267703FFFE6CC360.dip0.t-ipconnect.de) |
| 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/ |
| 12:08.25 | *** join/#maemo eMHa_ (~mh@p200300738E178900267703FFFE6CC360.dip0.t-ipconnect.de) |
| 12:10.59 | *** part/#maemo chadi (~chadi@unaffiliated/chadi) |
| 12:28.18 | *** join/#maemo at1as (~at1as@kurios.r4780y.com) |
| 12:32.01 | DocScrutinizer05 | huh? |
| 12:32.05 | DocScrutinizer05 | april's fool? |
| 12:32.43 | DocScrutinizer05 | ohnoes! that's serious I guess |
| 12:36.50 | DocScrutinizer05 | http://www.shopkick.com/ |
| 12:36.52 | *** join/#maemo vahe (~vahe@130.193.124.163) |
| 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.<< |
| 12:38.57 | kerio | linux documentation lul |
| 12:43.18 | *** join/#maemo xes_ (~xes@unaffiliated/xes) |
| 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 |
| 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 << |
| 12:54.42 | DocScrutinizer05 | selinux, apparmor? |
| 13:07.22 | *** join/#maemo louisdk (~louisdk@5.103.138.205) |
| 13:22.56 | DocScrutinizer05 | ooh ok. getfattr --match=.* does the trick |
| 13:25.36 | *** join/#maemo cyteen (~cyteen@cpc83573-brig19-2-0-cust508.3-3.cable.virginm.net) |
| 14:45.16 | kerio | DocScrutinizer05: meanwhile freebsd can block raw sockets in jails even if you're literally uid 0 |
| 14:45.20 | kerio | :3 |
| 14:45.45 | DocScrutinizer05 | suresure |
| 14:45.52 | kerio | it actually does so by default |
| 14:45.56 | kerio | you have to reenable raw sockets |
| 14:46.04 | kerio | admittedly there's no granularity there |
| 14:46.12 | DocScrutinizer05 | for your leisure: https://people.eecs.berkeley.edu/~daw/papers/setuid-usenix02.pdf (dates back to 2002 or somesuch) |
| 14:46.26 | kerio | ye but try freebsd tho ;o |
| 14:46.33 | DocScrutinizer05 | and https://superuser.com/questions/710253/allow-non-root-process-to-bind-to-port-80-and-443 |
| 14:46.36 | kerio | it's like if linux was actually sane |
| 14:47.13 | kerio | the whole init system is written in bourne shell ;o |
| 14:47.18 | kerio | the installer too |
| 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.<< |
| 14:48.07 | kerio | it does have some pretty heavy monolithic parts |
| 14:48.09 | kerio | like zfs |
| 14:48.14 | kerio | but zfs is actually well written |
| 14:49.16 | DocScrutinizer05 | wonders if fremantle ubifs supports xattr |
| 14:49.42 | kerio | we should migrate fremantle to zfs |
| 14:50.13 | DocScrutinizer05 | start with nuking optification! |
| 14:50.17 | kerio | it only requires a hard minimum of 64mb |
| 14:50.25 | kerio | what's 25% of your total ram, after all |
| 14:55.53 | *** join/#maemo eMHa_ (~mh@87.157.180.172) |
| 14:57.02 | kerio | DocScrutinizer05: i think we can't freebsd, it doesn't have any filesystems for raw flash |
| 14:57.05 | kerio | :( |
| 14:57.35 | kerio | wait i lie |
| 14:57.37 | kerio | it has a nandfs |
| 14:57.43 | DocScrutinizer05 | I bet you do, here |
| 14:57.55 | *** join/#maemo sunshavi (~user@190.234.106.64) |
| 14:57.59 | DocScrutinizer05 | I think freebsd is on a lot of embedded stuff |
| 14:58.11 | kerio | are those embedded things actually running with just raw flash tho' |
| 14:58.12 | kerio | ? |
| 14:58.20 | DocScrutinizer05 | no idea |
| 14:58.23 | kerio | i thought the usual nowadays was eMMC |
| 15:03.18 | kerio | DocScrutinizer05: btw i still haven't figured out how asterisk works :< |
| 15:16.45 | *** join/#maemo cyphase (~cyphase@unaffiliated/cyphase) |
| 15:18.47 | bencoh | kerio: you could always load freebsd from nand and boot with an emmc-located rootfs anyway ;) |
| 15:18.54 | kerio | sure |
| 15:18.55 | bencoh | (load kernel* from nand) |
| 15:19.05 | kerio | ...and use the internal nand as L2ARC ;o |
| 15:19.17 | bencoh | :D |
| 15:19.34 | kerio | praise the zfs |
| 15:19.54 | bencoh | riight, this device has too much ram to spare |
| 15:20.01 | bencoh | let's add some dedup |
| 15:20.23 | DocScrutinizer05 | LOL |
| 15:21.29 | kerio | hey, the iphone is getting a copy-on-write filesystem |
| 15:21.54 | DocScrutinizer05 | wonders if a fs based on hashing single blocks (4k) instead of whole files might work |
| 15:22.05 | kerio | hashing? |
| 15:22.21 | bencoh | zfs dedup is probably not whole-file-based already |
| 15:22.31 | kerio | yes, it's block-based |
| 15:23.05 | kerio | with the size being (up to) the dataset's recordsize or (exactly) the zvol's volblocksize |
| 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 |
| 15:23.18 | kerio | that's not really what btrfs does |
| 15:23.23 | kerio | i'm pretty sure that btrfs is also block-based |
| 15:23.34 | kerio | and no, it doesn't automatically dedup |
| 15:23.35 | DocScrutinizer05 | hmm, probably you're right |
| 15:23.51 | DocScrutinizer05 | git does, though |
| 15:23.53 | kerio | it does refcounting if you snapshot and clone |
| 15:24.09 | kerio | and you can copy and tell it to not actually write the blocks |
| 15:24.10 | DocScrutinizer05 | I know how btrfs works |
| 15:24.15 | DocScrutinizer05 | in general |
| 15:24.25 | kerio | well, zfs also has an optional block-level dedup |
| 15:24.36 | kerio | which i believe is not avaliable in btrfs (yet?) |
| 15:24.47 | DocScrutinizer05 | don't know |
| 15:25.11 | DocScrutinizer05 | I only seem to recal btrfs does dedup, no idea *how* |
| 15:25.22 | DocScrutinizer05 | I was assuming, probably incorrectly |
| 15:25.28 | bencoh | /dev/null is a pretty good dedup option |
| 15:25.30 | kerio | it's not dedup in the way people would think of it |
| 15:26.01 | kerio | it's like... |
| 15:26.04 | kerio | opportunistic dedup? |
| 15:26.28 | DocScrutinizer05 | anyway block level hash/dedup seems like a smart approach |
| 15:26.41 | kerio | global dedup is probably a bad idea tbh |
| 15:26.53 | kerio | unless your needs are very peculiar |
| 15:27.08 | DocScrutinizer05 | hm? |
| 15:27.26 | kerio | how often do you think you'll have block-aligned duplicated data in your filesystem? |
| 15:27.40 | kerio | with the block being quite big by default, like 128kb |
| 15:27.41 | DocScrutinizer05 | more often than you think |
| 15:28.00 | kerio | sure if you copy a container you'll have perfect deduplication |
| 15:28.05 | DocScrutinizer05 | huh, who's using 128k blocks? |
| 15:28.07 | kerio | but you can just do it explicitly with a snapshot and a clone |
| 15:28.18 | kerio | DocScrutinizer05: the default recordsize for filesystem datasets in zfs is 128k |
| 15:28.24 | kerio | which means that the blocks are up to 128kb |
| 15:28.31 | DocScrutinizer05 | zfs, meh |
| 15:28.55 | kerio | yeah better to use the cheap penguin clone with the broken parity redundancy :^) |
| 15:29.08 | DocScrutinizer05 | huh? |
| 15:29.18 | kerio | raid5 and the like |
| 15:29.29 | DocScrutinizer05 | heads out |
| 15:30.05 | DocScrutinizer05 | can't see raid5 in embedded |
| 15:30.39 | DocScrutinizer05 | no raid at all, to be honnest |
| 15:31.11 | kerio | striping could be an option if having more storage devices ends up being cheaper than having one bigger storage device |
| 15:31.18 | kerio | although that's probably seldom the case |
| 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 |
| 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 |
| 15:33.03 | kerio | well, log-structured filesystems count as copy-on-write |
| 15:33.25 | kerio | and there's *no way* you're doing full dedup on an embedded device |
| 15:33.42 | DocScrutinizer05 | aha |
| 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 |
| 15:34.29 | DocScrutinizer05 | huh? why? |
| 15:34.38 | kerio | because every block has to be in there |
| 15:34.44 | DocScrutinizer05 | no |
| 15:35.19 | kerio | yes |
| 15:35.24 | DocScrutinizer05 | I *could* implement that shit in bashscript even |
| 15:35.55 | DocScrutinizer05 | and it just writes 4k files called /.storage/7d643nfcj64393774fhswke73 |
| 15:36.08 | DocScrutinizer05 | and when said file already exists then no write |
| 15:37.37 | DocScrutinizer05 | a 40k file /foo/bar would actually resemble a "symlink" of sorts, pointing to 10 block file like /.storage/7d643nfcj64393774fhswke73 |
| 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 |
| 15:39.29 | DocScrutinizer05 | and writing a 4GB all-zeroes file would utomatically colape to only one data block |
| 15:40.05 | DocScrutinizer05 | since blockN=block2=block |
| 15:40.12 | DocScrutinizer05 | 1 |
| 15:43.04 | kerio | i mean |
| 15:43.21 | kerio | the usual recommendation for zfs dedup are *five gigabytes* per tb of storage |
| 15:43.26 | kerio | of ram, that is |
| 15:43.36 | DocScrutinizer05 | I'm NOT talking about zfs |
| 15:43.41 | kerio | but i'm sure you could do it in shellscirpt |
| 15:43.47 | kerio | *script |
| 15:46.02 | *** join/#maemo Wizzup (~Wizzup@a82-161-36-93.adsl.xs4all.nl) |
| 15:46.25 | *** join/#maemo chfoo[m] (chfoomatri@gateway/shell/matrix.org/x-itkesaynvigpoion) |
| 15:47.25 | *** join/#maemo dafox (~dafox@188.207.96.6) |
| 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 |
| 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 |
| 15:50.16 | DocScrutinizer05 | you're free to call that a "symlink" since in fact it works pretty similar |
| 15:50.47 | DocScrutinizer05 | just this "symlink" has a list of file destinations instead a single one |
| 15:51.33 | DocScrutinizer05 | and for read you concatenate the symlink destination data |
| 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 |
| 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 |
| 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 |
| 15:56.31 | *** join/#maemo xy2_ (~xy2_@195.245.16.93.rev.sfr.net) |
| 15:56.41 | DocScrutinizer05 | or you implement refcount just like in inode based fs |
| 15:58.37 | DocScrutinizer05 | ("symlink" since in fact it works pretty similar) for files <4k it actually IS a symlink |
| 16:02.48 | DocScrutinizer05 | yes, you need some RAM for the GC. But not for regular use |
| 16:03.48 | DocScrutinizer05 | it's slower than a 'normal' fs - unless you have duplicate blocks in a file |
| 16:05.19 | DocScrutinizer05 | deduplication is pretty much instant, it basically comes for free |
| 16:05.50 | DocScrutinizer05 | except for the hash calculation |
| 16:06.56 | DocScrutinizer05 | thinking about it, I wonder if ubifs works similar already |
| 16:13.43 | *** join/#maemo platicus1 (~matrixirc@fanzine.igalia.com) |
| 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 |
| 16:19.33 | *** join/#maemo L29Ah (~L29Ah@ojab-1-pt.tunnel.tserv24.sto1.ipv6.he.net) |
| 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) |
| 16:25.30 | *** join/#maemo xorly (~xorly@ip-86-49-24-93.net.upcbroadband.cz) |
| 16:25.49 | *** join/#maemo cyteen (~cyteen@cyteen42.plus.com) |
| 16:28.13 | *** join/#maemo platicus1 (~matrixirc@fanzine.igalia.com) |
| 16:40.19 | *** join/#maemo platicus1 (~matrixirc@fanzine.igalia.com) |
| 16:56.22 | *** part/#maemo L29Ah (~L29Ah@ojab-1-pt.tunnel.tserv24.sto1.ipv6.he.net) |
| 17:01.16 | *** join/#maemo L29Ah (~L29Ah@ojab-1-pt.tunnel.tserv24.sto1.ipv6.he.net) |
| 17:12.17 | *** join/#maemo norayr (~noch@82.199.214.63) |
| 17:32.23 | *** join/#maemo cyteen (~cyteen@cyteen42.plus.com) |
| 18:19.12 | *** join/#maemo spiiroin (~spiiroin@87-93-159-188.bb.dnainternet.fi) |
| 18:39.20 | bencoh | http://maemo.org/packages/view/qmledit-qmlpreview/ seems nice :) |
| 18:41.06 | *** join/#maemo eMHa_ (~mh@p200300738E174F00267703FFFE6CC360.dip0.t-ipconnect.de) |
| 18:50.01 | *** join/#maemo xy2_ (~xy2_@mlv95-h01-176-134-46-233.dsl.sta.abo.bbox.fr) |
| 19:04.57 | *** join/#maemo auenf (David@CPE-60-229-46-143.lns9.ken.bigpond.net.au) |
| 19:12.34 | buZz | anyone have a link to try that hildon port to devuan? |
| 19:16.21 | *** join/#maemo xy2_ (~xy2_@mlv95-h01-176-134-46-233.dsl.sta.abo.bbox.fr) |
| 19:59.42 | *** join/#maemo heroux (sandroco@gateway/shell/insomnia247/x-lamggfbwspqowtjs) |
| 20:05.55 | *** join/#maemo pagurus (~user@p4FDC301B.dip0.t-ipconnect.de) |
| 20:13.29 | *** join/#maemo crazyguy` (~user@2a02:a446:8185:1:b96f:19a6:c469:7c1b) |
| 20:19.10 | *** join/#maemo florian (~fuchs@Maemo/community/contributor/florian) |
| 20:28.10 | *** join/#maemo crazyguy` (~user@ip5652d1e2.speed.planet.nl) |
| 20:39.08 | *** join/#maemo heroux (sandroco@gateway/shell/insomnia247/x-ykhfqxotpflbrnrk) |
| 20:57.06 | *** join/#maemo crazyguy` (~user@2a02:a446:8185:1:fc10:a770:f11d:cfd2) |
| 21:30.20 | DocScrutinizer05 | there's no hildon port to devuan. freemangordon works on porting parts of hildon |
| 21:31.17 | DocScrutinizer05 | tbh hildon is a eather futty term |
| 21:31.34 | DocScrutinizer05 | rather fuzzy* |
| 21:32.53 | DocScrutinizer05 | if anything, hildon is similar to KDE or gnome. A DE |
| 21:34.31 | *** join/#maemo dafox (~dafox@2a02:a448:c25a:1:7061:3b2a:37df:ded3) |
| 21:43.02 | DocScrutinizer05 | http://paste.ubuntu.com/24539137 |
| 21:43.09 | *** join/#maemo Cor-Ai (~cor-ai@c-57d071d5.06-922-7570702.cust.bredbandsbolaget.se) |
| 21:45.48 | DocScrutinizer05 | add in a lot of this: http://paste.ubuntu.com/24539159 |
| 21:46.33 | DocScrutinizer05 | an a few of these: http://paste.ubuntu.com/24539165 |
| 21:48.51 | *** join/#maemo Kabouik (~quassel@32.232.202.84.customer.cdi.no) |
| 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 ) |
| 21:53.39 | DocScrutinizer05 | checking the dependencies is real fun |
| 21:55.20 | DocScrutinizer05 | I guess you could run hildon-desktop on matchbox or even standard xorg, but... that's not really exciting |
| 21:57.53 | DocScrutinizer05 | of course you again need maemo-invoker/maemo-launcher (unless you build HD for running plain without launcher) |
| 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 |
| 22:00.22 | DocScrutinizer05 | waves and goes offline for a 25h |
| 22:11.11 | Enrico_Menotti | Bye DocScrutinizer05 , thanks for all the info. |
| 22:54.56 | *** join/#maemo cyphase (~cyphase@unaffiliated/cyphase) |