<    March 2017    >
Su Mo Tu We Th Fr Sa  
          1  2  3  4  
 5  6  7  8  9 10 11  
12 13 14 15 16 17 18  
19 20 21 22 23 24 25  
26 27 28 29 30 31
00:12 dirac1 joined
00:19 avih joined
00:20 laj joined
00:27 <darkfader> sry, i had a long disconnect
00:27 <darkfader> one thing i wanted to add
00:27 <darkfader> since the default is to use grsec, you don't end up as a fringe user for having a secuirty component active
00:27 <darkfader> that's what makes detection of issues likely
00:27 <darkfader> and also helps in general
00:28 <darkfader> noone will suggest "turn it off" like people do for selinux if you ask in the wrong place
00:28 <darkfader> people might ask you to boot into vanilla to verify if something is a grsec issue
00:28 <darkfader> but noone expects you to turn it off to make their thinking easier
00:29 <darkfader> and that's a nice thing
00:29 <Xe> the fact that you need to change how the system boots is good iMO
00:29 <Xe> IMO*
00:34 hairyhenderson joined
00:49 czart joined
01:12 minimalism joined
01:14 blueness joined
01:15 mikeee_ joined
01:21 blueness joined
01:46 minimalism joined
02:42 CcxWrk joined
02:47 s33se joined
03:25 ogres joined
03:33 Ayyad joined
03:55 Emperor_Earth joined
03:57 czart_ joined
04:02 wicoa joined
04:21 ahrs_ joined
04:43 ahrs joined
06:03 fabled joined
06:19 wonton joined
06:46 cyteen joined
07:14 mdillon joined
07:15 gogoprog joined
07:15 grrrkit joined
07:22 nanohest joined
07:46 fireglow joined
08:02 ncopa joined
08:02 ncopa joined
08:20 <rollniak> Hello everyone :)
08:25 grrrkit joined
08:31 Ayyad joined
08:36 t0mmy joined
08:39 volleyper joined
08:43 volleyper joined
08:47 volleyper joined
08:54 grrrkit joined
09:00 t0mmy joined
09:13 s33se joined
09:37 fekepp joined
09:52 volleyper joined
10:49 Kruppt joined
11:10 chapui_s joined
11:38 cyborg-one joined
12:16 fekepp joined
12:17 farosas joined
12:17 fnljk joined
12:23 sirnaysayer joined
13:45 wicoa joined
13:46 Skele joined
13:46 <TBB> arrrgh, invalid opcode is back
13:49 <TBB> I've had to roll my own version of hplip as the one in testing is basically featureless... the last time I did this was about one year ago and I hit the same issue but was able to get past it by changing compiler optimization settings
13:49 <TBB> well, that fix was only temporary, it seems; one .so seems to trigger an invalid opcode trap
13:50 volleyper joined
13:51 <TBB> at least I can never complain that my job doesn't allow me to keep learning about things, I guess :)
13:54 Ayyad joined
14:10 ncopa joined
14:10 ncopa joined
14:43 <TBB> seems many places online seem to attribute that specific problem to intel bugs fixable with firmware updates, but somehow I doubt that's the explanation in this case
14:46 <zhasha> Seems more likely that they hand rolled some asm without checking if the processor supports it properly
14:46 <zhasha> maybe made it contingent on some #define that doesn't actually cover it
14:48 <TBB> that would make sense, but that unfortunately goes beyond my skillset; I'm the kind of guy who refuses to learn C knowing he'd only shoot himself and several others in the foot by coding C for a living :)
14:48 Ez joined
14:48 <TBB> however, I've got a guy or two in my team who should be capable of investigating that possibility
14:51 vidr joined
14:52 Ayyad joined
14:56 minimalism joined
14:57 <zhasha> TBB: even more likely (provided Alpine compiles with stack-protector) is that it's intentional and it's catching a bug
14:57 nanohest joined
15:01 debiansid joined
15:05 debiansid joined
15:28 thunfisch joined
15:34 minimalism joined
15:40 fnljk joined
15:41 fcolista joined
15:50 fnljk joined
15:55 nanohest joined
16:07 ogres joined
16:09 bozonius joined
16:13 dlaube joined
16:37 stateless joined
16:38 nanohest joined
17:04 transhuman joined
17:04 <transhuman> how do I recall a command from the history !233 for example doesnt work but thats for bash
17:10 <Kruge_> Has anyone ever managed to install 3.5 onto Hyper-V?
17:10 <Kruge_> By any chance...
17:15 rollniak joined
17:35 nanohest joined
17:44 <TBB> zhasha: I thought about that but I have the feeling that if SSP for example catches it then the error will be something else. but I'll have to dig deeper into this tomorrow. Thanks for the ideas :)
17:45 preyalone joined
17:46 <preyalone> configuration error in go package: /usr/lib/go/pkg/tool/linux_amd64/pprof exists, but go tool pprof fails to find it
17:46 <transhuman> is there a best practice for settings for the kernel for running docker containers somewhere?
17:46 <transhuman> i know grsec interferes with things in strange ways
17:51 gopar joined
18:02 nanohest joined
18:04 BitL0G1c joined
18:05 mouthbreather joined
18:29 sergey joined
18:56 fekepp joined
18:56 nanohest joined
19:21 cyborg-one joined
19:52 rollniak joined
19:55 StarWarsFan|afk joined
19:57 grrrkit joined
20:03 blueness joined
20:09 <StarWarsFan> hi@all
20:10 <StarWarsFan> i've upgraded a machine from 3.4 to 3.5
20:10 <StarWarsFan> update runs without any problems
20:10 <StarWarsFan> but after reboot lvm is not working
20:10 <StarWarsFan> http://sprunge.us/RBfS
20:11 <StarWarsFan> any ideas?
20:11 scadu left
20:12 <TBB> yes
20:13 <TBB> not on Alpine at the moment, but it's a device mapper related problem - you've lost one device-mapper package in upgrade (happens by itself)
20:13 <TBB> and that results in an incomplete initramfs
20:14 <StarWarsFan> which means?
20:15 <TBB> I don't remember what the exact packages are but in your package database there are packages like device-mapper, device-mapper-libs, device-mapper-event-libs and such
20:15 <TBB> the upgrade causes one of them to be missing -> bang
20:15 <StarWarsFan> :-(
20:15 blueness joined
20:16 <TBB> so it takes booting with the old kernel+initramfs or boot media, chrooting in and fixing that
20:16 <StarWarsFan> argh...
20:17 <StarWarsFan> sounds very bad
20:17 <TBB> it's not that bad; at least I, when starting with Alpine, had to do that all the time :)
20:17 <avih> TBB: is the old kernel still there after such update?
20:17 <StarWarsFan> the machine is about 200km away, so i have only ssh access
20:17 <avih> (using default procedures)
20:18 <TBB> avih - as far as I know Alpine's kernel upgrade doesn't cause an operationg like cp /boot/vmlinuz-grsec /boot/vmlinuz-grsec.old
20:19 <avih> that could be useful in general IMO. i.e. to allow booting with the previous kernel after a kernel update.
20:19 <TBB> so basically before you perform a kernel upgrade it's a good idea to do that manually... it could be useful to have the upgrade perform that
20:19 <StarWarsFan> so i do not have any chance to fix this remotely?
20:19 <avih> StarWarsFan: is it a vps? does it provide direct terminal access? can you ssh into it?
20:20 <StarWarsFan> as i said, i have only ssh to this box
20:20 <avih> and does it work now?
20:20 <StarWarsFan> yes
20:20 <StarWarsFan> i'm on it an missing my lvm... ;-)
20:21 <TBB> I wonder if you could get the device-mapper* apks there and install them to the early filesystem
20:21 <TemptorSent> If you're in, you should be able to install the required packages, run update-kernel, an be good.
20:22 <StarWarsFan> so the first step would be to determine which packages are required...
20:23 <TBB> device-mapper, device-mapper-libs, device-mapper-event-libs
20:24 <StarWarsFan> [x] done
20:24 <StarWarsFan> and now update-kernel?
20:25 <StarWarsFan> # update-kernel ~
20:25 <StarWarsFan> update-kernel: Module loopback device not mounted
20:25 <StarWarsFan> #
20:25 <TBB> I would personally just activate the vg, mount the root to /sysroot and ctrl-D
20:25 <TBB> dunno how complicated your partitioning scheme is
20:26 <TBB> encrypted setup?
20:26 <TBB> that is, lvm-on-luks?
20:26 <StarWarsFan> no, nothing encrypted
20:27 <TBB> okay, then you could just try lvm vgchange -a y and see if your logical volumes appear to /dev/mapper
20:28 <StarWarsFan> great! works again
20:28 <StarWarsFan> everything's fine
20:28 <StarWarsFan> thx a lot guys
20:28 <TBB> o>
20:29 <TBB> now remember to install those packages again :)
20:29 <StarWarsFan> did a lot of updates but this was the first one with this problem...
20:30 <TBB> yeh, I had it happen at work; I have a couple of guys using Alpine exclusively for their work so I had to make sure the upgrade works before letting them do the same
20:30 xsteadfastx joined
20:32 sparklyballs joined
20:38 xsteadfastx joined
20:40 xsteadfastx joined
20:42 nanohest joined
20:44 xsteadfastx joined
20:45 <TBB> hum... what do you guys think, am I wasting my time learning Vala?
20:46 xsteadfastx joined
20:46 <scv> yes
20:46 <scv> vala is a dead language
20:46 <scv> their own devs even say the same
20:47 xsteadfastx joined
20:51 <avih> +1
20:51 <zhasha> Vala was always dead
20:51 <avih> even if it wasn't dead, it's only gnome. what good is that?
20:53 <zhasha> Consider that the reason it exists is because someone wrote a C ecosystem that's too painful to use for mortals
20:53 mouthbreather joined
20:55 radhus joined
20:58 radhus joined
21:03 lesion joined
21:03 <TBB> I consider C too painful to use for mortals :)
21:04 <TBB> I don't mind shooting myself in the foot, but other people's feet... *shrug* don't know, it seemed like a fairly decent language as such
21:08 blackwind_123 joined
21:12 <avih> TBB: start with c. it's a very very good base to have. and it's actually a rather simple language on its own.
21:13 czart joined
21:14 ogres joined
21:14 <avih> probably easier to learn than most modern languages out there, since modern languages have tons of implicit stuff which you need to wrap your head around
21:15 <avih> in c everything is explicit. and the language and its feature set are quite limited. it's relly a good base.
21:15 <avih> +a
21:18 blueness joined
21:20 <TBB> no
21:21 <TBB> I've had enough of C already, and since every day I witness what kind of garbage needs constant fixing just because of C being what it is, I'll never support it in the form of writing it
21:22 <TBB> although, that statement does put my two-day effort to figure out Vala somewhat strange :D
21:22 <avih> it's not about how complex it is to maintain a complex project. it's about how simple it is to learn _programming_ . once you have a useful grasp of programing, then you can move to different languages
21:22 <TBB> oh, I know programming allright, I just find C repulsive
21:23 t0mmy joined
21:23 <TBB> yet I need to add something useful for system level programming into my repertoire
21:41 blueness joined
21:57 Skele joined
22:17 <ericnoan> is apk-tools a front-end or is it the pkg manager?
22:21 Nobabs27 joined
22:22 Ayyad joined
22:31 sparklyballs joined
22:37 Diftraku joined
22:39 <programmerq> ericnoan▸ are you asking whether there's some other thing running other than apk (presumably like yum->rpm ?)
22:42 LouisA joined
22:42 Diftraku_ joined
22:55 <ericnoan> yes, like apt-get is a front-end to dpkg
22:56 <darkfader> ericnoan: apk is the lowest level afaik
22:56 <darkfader> apk-tools-static is best to keep around if yu go into some risk period, like fixing things in a chroot or for cross-versions upgrades
22:56 <darkfader> that's why it's also just different package
22:56 <darkfader> but apk does all stuff i think, and it shows - as in: less race conditions
22:57 <ericnoan> ok thx. is alpine intended to be used on the desktop?
22:57 <darkfader> intended is streching it? you can do it, if you like it, and it'll be ok
22:57 <ericnoan> or rather, is it suitable?
22:57 <darkfader> i'd not
22:58 <ericnoan> so its more intented for servers and embedded systems?
22:58 <darkfader> but i long gave in and use a macbook to just have sane default instead of choice
22:58 <darkfader> it is excellent for embedded/networking and great for servers, unless you need to run say SAP
22:59 <darkfader> desktop is okish but no more comfy than any strict unix-like distro
22:59 <ericnoan> i mean, all i need is xfce
22:59 <darkfader> so think of a bit easier to handle than openbsd, but no fedora
22:59 <darkfader> yeah
22:59 <darkfader> then you'll be ok i think
22:59 <darkfader> it doesn't work if one can't setup a menu item
23:00 <ericnoan> anyone here use alpine on the desktop?
23:00 <darkfader> and if one knows how to do set up a desktop for real then it's fine and fucking fast.
23:01 <ericnoan> well... no xfce package
23:08 <avih> ericnoan: i have a desktop setup with xfce, but in a vm so not full time and no need for gpu drivers, since i mostly use it with forwarded x. it's as decent as i expect an xfce desktop to be. i.e. perfectly fine.
23:09 <ericnoan> ok thx
23:12 <avih> only issue, which is not limited to desktop, is that due to missing glibc, some packages which mostly distribute as binaries are likely to not work due to expecting glibc but getting musl. like vscode. but if you can build it yourself then it would be fine
23:13 <avih> (and alpine is a perfectly fine build env)
23:13 <dalias> i'd love to have a well-engineered approach to be able to run glibc-linked stuff
23:13 <avih> +1
23:14 <dalias> i suspect it'd work to build glibc with a custom --prefix and put it and some libs there
23:14 <dalias> and just ld-linux in /lib
23:15 <dalias> if the ld-linux was configured for the custom --prefix it should look for config files, libs there
23:16 <avih> i think the current approach to that is using docker and effectively installing a big chunk of ubuntu for that. i don't really like this appproach TBH (and regardless, couldn't get it to work, but that's probably my fault somehow)
23:18 <avih> also, i'm guessing steam falls into this category too.
23:20 <avih> dalias: would somehow building glibc (and deps), putting it in a dedicated dir and using LD_LIBRARY_PATH suffice?
23:22 LouisA joined
23:24 <dalias> avih, no
23:24 <dalias> the key point is that you have a different ldso
23:25 <avih> ok, i need to google ldso :)
23:25 <dalias> also LD_LIBRARY_PATH would break if it runs any subprocesses using other programs linked to the system libc
23:25 blueness joined
23:26 <avih> right.
23:27 <avih> though, i thought one of musl's goals was to allow static linking. so i'm guessing alpine doesn't use static linking with libc?
23:28 <dalias> you can static-link programs
23:28 <dalias> but for a distro you don't want to do mosst
23:28 <avih> s/allow/promote or make easier or more viable/
23:28 <dalias> it is easy
23:28 <dalias> but doesn't make sense for distro packages
23:28 <dalias> fixing bugs in dependencies is more work for the distro
23:28 <avih> yeah
23:29 <dalias> and if you install a nontrivial amount of stuff it will use a lot more disk/ram
23:29 transhuman joined
23:29 gopar joined
23:29 <avih> how much overhead would static linking add to, say, some core utils programs?
23:30 <hiro> avih: define some :)
23:30 <hiro> some programs have negative overhead from static linking
23:31 <avih> let's say ls for starters :)
23:31 <dalias> asymptotically (as you add lots of programs and attain near-full coverage for libc) dynamic linking saves
23:31 <dalias> for most individual programs, static linking saves a lot
23:32 <avih> so on very rough average (and ignoring a big stddev). static linking adds (to the executable), say, 10% ?
23:32 <hiro> no, you can't generalize this
23:33 <hiro> if all your programs are shit probably dynamic linking saves you something
23:33 <dalias> for a given executable, static linking is much smaller than the executable + libs
23:33 <avih> yes, for sure.
23:33 <hiro> if your programs are generally high quality and *never* using horrible bloated shit libraries, then static linking should be just fine
23:34 <dalias> hiro, i wouldn't say that
23:34 <dalias> there are non-bloated, non-shit things that fundamentally have nontrivial size
23:34 <dalias> for instance iconv()
23:35 <hiro> dalias: there are only two valid encodings and they need no iconv
23:35 <hiro> dalias: ascii
23:35 <dalias> musl takes the approach that if you static link, you actually _want_ the binary to work anywhere, without depending on other library/data files in the filesystem, so all the tables needed to convert are there
23:35 <hiro> dalias: utf-8
23:35 <dalias> hiro, that doesn't really work if you want to read email/web/etc.
23:36 <hiro> dalias: then run *one* statically linked program on all of your data that comes from horrible people and converts it into utf-8
23:36 <dalias> email will be in whatever encoding the sender's MUA chose
23:36 <dalias> yes but now you're back to the same limitations of dynamic linking
23:36 <hiro> dalias: this means there will be only one program using your code, so there's no sense in making a dynamic library for it
23:36 <dalias> depending on an ecosystem of installed files
23:36 <dalias> rather than a single program file
23:37 <hiro> ecosystem?
23:37 <avih> dalias: so if i statically link a program with musl, it ends up depending only on the linux kernel, and as such would likely run on other distros with same arch?
23:39 <hiro> debian
23:39 <hiro> $ ls -l `which ls`
23:39 <hiro> -rwxr-xr-x 1 root root 114032 Jan 26 2013 /bin/ls
23:39 <hiro> proper statically linked OS
23:39 <hiro> % ls -l /bin/ls
23:39 <hiro> --rwxrwxr-x M 274 glenda sys 87050 Feb 13 21:19 /bin/ls
23:39 <hiro> even the DYNAMIC binary is bigger than the statically linked binary.
23:39 <hiro> without counting any of the libs
23:47 <avih> sbase's ls on alpine is 22k. alpine's ls is 120k
23:47 <avih> though initially i guess it's busybox's ls
23:48 <avih> (i do have coreutils installed)
23:51 <hiro> in practice few people care about size anyway, so for them dynamic linking also makes no sense, they just want their shit to work no matter what.
23:51 <avih> you might not care about size per app, but static linking also means updating all bins when libc updates
23:51 <hiro> and the few that care *a real big deal* about size would benefit from a hand-woven high-quality userland (ecosystem) with no big dependencies.
23:52 <hiro> static linking also means that all bins don't suddenly break because one lib got updated.
23:52 <avih> true
23:52 <hiro> people pretend way too often that updating shit is the prime directive
23:53 <hiro> sometimes not updating is *just fine*.
23:53 <dalias> these days less so
23:53 <avih> considering the rate of new VCE's, updating _is_ impottant
23:53 <avih> CVE*
23:53 <dalias> almost any sw facing data from outside sources has multiple serious vulns if it's out of date :(
23:53 <hiro> avih: if you care about security you'll just run less software
23:53 <hiro> avih: which makes updating possible in the first place.
23:54 <avih> hiro: that's one approach, but many times it's not really applicable
23:54 <hiro> avih: if it becomes too many dynamic linking won't help at all, because shit breaks *always* once you reach this complexity.
23:54 <avih> i don't disagree. i just see both sides. though i don't have the background to weight them against eachother
23:55 <hiro> avih: of course the typical apt-get install secure-wordpress doesn't work in any viable way
23:55 <hiro> avih: and that's completely orthogonal to static linking.
23:56 <avih> it is, but i said static linking requires bigger updates, wrt to your statement that size doesn't matter much
23:56 <hiro> almost any sw facing data from outside sources has multiple serious vulns even if it's not out of date.
23:56 <hiro> having a cve is not a requirement for being shit software.
23:56 <dalias> hiro, the difference is the # of parties who know the vuln
23:57 <dalias> nobody's going to blow a 0day on "random user hiro"
23:57 <dalias> they're going to sell it or save it for use on a serious target
23:57 <avih> someone might :)