<     May 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:05 <Shiz> jirutka: they're going to completely revamp the interface
00:05 <Shiz> so....
00:06 <jirutka> Shiz: uh, really?
00:06 <Shiz> yes
00:06 <Shiz> https://www.mail-archive.com/misc@opensmtpd.org/msg03332.html
00:09 <jirutka> “this is what people started using while we warned them not to.” … omfg, he’s working on filters for *years* and in my case OpenSMTPD was useless for me, for the particular use case I had, without it…
00:11 <jirutka> “We're going to be working towards this way but now that we have an
00:11 <jirutka> experience in how providing the code early turned into a nightmare
00:11 <jirutka> for me, we'll work in a private branch then show the diff when the
00:11 <jirutka> code is working enough that it can be part of snapshots :-)”
00:11 <jirutka> oh great, so no filters for next many years…
00:11 <jirutka> this approach is total idiocy
00:12 <jirutka> sensible way is to just say that it’s API version 1.0 or something and make it clear that there might me 2.0 without backward compatibility in some next release… all users should accept this without problem, cause that’s how it normally works
00:14 <jirutka> it turned into a nightmare b/c he explicitly refused to provide any form of documentation, but since it’s very important feature, ofc people kept asking again and again…
00:15 <jirutka> including me, I was bothering him until he finally revealed some information so I was able to write my five lines of python code filter that was very essential for me, otherwise I cannot use OpenSMTPD at all
00:18 <jirutka> I like OpenSMTPD and appreciate his very strong focus on quality, but at the same time it seems for me like he has no idea how OSS world works… implementing something in private branch, wtf?!
00:21 <jirutka> good night! o/
00:40 tmh1999 joined
01:06 tmh1999 joined
01:51 gromero joined
01:56 s33se joined
01:57 tmh1999 joined
02:23 tmh1999 joined
03:11 czart_ joined
05:07 fabled joined
05:16 tmh1999 joined
06:28 blueness joined
06:29 D630 joined
07:00 t0mmy joined
08:09 fekepp joined
08:12 vakartel joined
08:13 tty` joined
08:22 blueness joined
08:23 <clandmeter> doing some maintenance to nl infra. downtime should be limited.
08:29 blueness joined
08:33 <_ikke_> wheej
08:36 <_ikke_> apparently the downtime includes their IRC connection too :P
08:43 clandmeter joined
08:43 <clandmeter> crap, router does not reboot correctly... nl infra down until further notice.
08:44 <_ikke_> :-(
08:47 <_ikke_> http://ikke.info/alpinelinux_status.png
09:08 <^7heo> _ikke_: did you make a png-generating script?
09:11 consus joined
09:17 <_ikke_> ^7heo: zabbix generates it
09:22 <^7heo> yeah ok
09:22 <^7heo> SVG would be pretty awesome, but that's already cool
09:22 <_ikke_> Right, I think they want to add svg generation eventually, but it's not supported yet
09:46 D630 joined
09:48 freedomrun joined
09:48 freedomrun_ joined
09:52 <^7heo> _ikke_: ah dang; ok :)
10:17 clandmeter joined
10:50 cyteen joined
10:50 blueness joined
10:52 cyteen joined
11:00 cyteen joined
11:14 gromero joined
11:51 <clandmeter> sigh, i think most of services are up again. please highlight me if something is still not operational.
11:54 LouisA joined
12:01 <_ikke_> clandmeter: \o/
12:01 <algitbot> \o/
12:13 ncopa joined
12:13 clandmeter63 joined
12:13 clandmeter joined
12:22 farosas joined
12:41 <_ikke_> cve-2017-8301
12:41 <_ikke_> on HN right now
12:51 <jirutka> :)
12:52 minimalism joined
12:52 <pickfire_> Alpine is down?
12:52 <pickfire_> Oh, it is up now.
12:54 <_ikke_> odd, from my vps it's still down
12:56 <clandmeter> _ikke_, can you check why?
12:56 <_ikke_> doing a traceroute
12:57 <_ikke_> last hop reachable is 88.159.2.162
12:57 <_ikke_> clandmeter: http://tpaste.us/Dk0e
12:58 <clandmeter> ping is disabled
12:58 <clandmeter> well, not enabled yhet
12:58 <_ikke_> hehe, dejavu :P
12:59 <clandmeter> _ikke_ and now?
13:00 <_ikke_> still down
13:01 <_ikke_> working
13:01 <clandmeter> PRESS APPLY CHANGES!!!
13:01 <clandmeter> :)
13:01 <_ikke_> :-)
13:07 <clandmeter> im going home, if something is broken msg me please.
13:09 rnalrd joined
13:13 minimalism joined
13:14 YoursTruly joined
13:14 mjeanson joined
13:14 jcloud joined
13:15 jcloud joined
13:21 minimalism joined
13:24 cyteen joined
13:26 mjeanson joined
13:26 cyteen joined
13:37 t0mmy joined
14:31 leitao joined
14:35 cyteen joined
16:43 <Shiz> hi
16:50 <jirutka> hi
17:14 <_ikke_> hi
17:15 <jirutka> afk
17:46 __0xAX joined
17:49 <TBB> how does "apk policy" determine which URL a package was installed from?
17:49 LouisA joined
17:52 <TBB> going through every package with apk policy in a fully installed system is so slow I'd rather just parse /lib/apk/db/installed but that only hints on repo tags
18:04 <Shiz> it matches the repo urls with repo tags
18:05 <Shiz> https://git.alpinelinux.org/cgit/apk-tools/tree/src/policy.c#n50
18:07 <TBB> yeah, that much I figured out. for untagged repos I suppose it runs through cached APKINDEX files?
18:11 cyteen joined
18:23 cyteen joined
18:25 tty` joined
18:39 blueness joined
18:57 D630 joined
19:28 blueness joined
19:32 blueness joined
19:55 <Shiz> i've been thinking about a very very lightweight equivalent to eclasses for abuild...
19:55 <Shiz> basically, something that just boils down to a source statement of another file
19:55 <Shiz> no more, as eclasses are quite... involved
19:55 <Shiz> but to preven duplication for e.g. py2/3 apkbuilds
19:58 <jirutka> Shiz: yeah, I’ve been thinking about it multiple times
19:58 <jirutka> Shiz: we really need something
20:04 <Shiz> neat, email from CERT/CC
20:04 <Shiz> would it be an idea to have a security@ email (list)?
20:06 <Shiz> cc ncopa kaniini
20:09 <przemoc> there is one already: http://lists.alpinelinux.org/alpine-security/summary.html
20:09 <Shiz> neat
20:09 <Shiz> but they're asking for a private mail
20:10 <przemoc> I think it could become private, as it was barely used so far
20:15 <jirutka> Shiz: CERT/CC??
20:15 <Shiz> jirutka: see alpine-devel
20:15 <Shiz> https://en.wikipedia.org/wiki/CERT_Coordination_Center
20:16 <jirutka> Shiz: aha, I see know
20:17 <jirutka> Shiz: well, this is up to ncopa; i’d prefer to have special address/alias for it, like security@alpinelinux.org
20:33 cyteen joined
20:38 <ncopa> re security email
20:38 <ncopa> yes we need one
20:39 <ncopa> im open to suggestions how we solve it
20:39 <ncopa> shoudl we have a shared gpg or should we have multiple individual emails
20:39 <ncopa> it needs to be a group of ppl
20:40 <ncopa> i wonder how other distros solves it
20:40 <ncopa> looks like all except s390x 3.6 builders are done!
20:40 <ncopa> so we have rc1 early next week
20:41 <Shiz> a system could be where some incoming daemon takes the mail, decrypts it using the security@ key, and then re-encrypts using individual gpg keys and sends to ppl on the sec list
20:41 <Shiz> to prevent the need for a shared gpg key
20:41 <ncopa> would still be nice to know what other distros does
20:41 <ncopa> might be we could provide a list of ppl
20:41 <Shiz> yeah
20:41 <Shiz> i'll check what debian does :P
20:42 <Shiz> and gentoo
20:42 <ncopa> thanks!
20:42 <jirutka> ghc is still in testing, we probably need fabled to handle it, cause of bootstrapping
20:42 <_ikke_> git.git has a private google groups
20:42 <ncopa> whats the status of php7.1?
20:42 <ncopa> it got moved to community right?
20:43 <jirutka> ncopa: i’ve fixed it last weekend
20:43 <jirutka> yes, it’s in community
20:46 <ncopa> jirutka: you rock!
20:47 <Shiz> debian and ubuntu teams seem to use a shared gpg key from what i can see, but i'll confirm manuall
20:47 <Shiz> y
20:47 <Shiz> gentoo uses multiple contacts with their own gpg key and a private bugzilla section
20:52 <kaniini> Shiz: yes
20:55 <Shiz> someone on #debian-security pointed me to what seems to be an implementation of my idea above
20:55 <Shiz> https://github.com/fbb-git/gpg-remailer
20:56 <Shiz> no confirmation if that's what they use though
21:19 YoursTruly joined
21:27 <ncopa> Shiz d you think we should set up something like that?
21:27 <ncopa> i think its a good idea
21:27 <Shiz> yeah it seems nice
21:28 <Shiz> prevents from having to do a key rollover when someone leaves the team
21:28 <ncopa> but it also means that the people who have access to the remailer has access to the gpg key
21:28 <Shiz> have to be careful about the security of the server it runs on though
21:28 <Shiz> yes :P
21:28 <ncopa> so basically a shared gpg
21:28 <ncopa> but i still like it
21:28 <Shiz> well, nobody has to have access to the remailer
21:28 <Shiz> except the server admin for it
21:28 <ncopa> admins
21:29 <ncopa> someone needs to babysit it
21:29 <Shiz> yeah
21:29 <Shiz> ideally that would be someone in the security team anyway
21:29 <Shiz> ;p
21:29 <Shiz> and preferably a single person
21:29 <ncopa> exactly
21:29 <ncopa> i'd say its better with a couple of persons
21:30 <ncopa> which ofc is on the sec team
21:50 <jirutka> well, for gpg-remailer we need to create pkgs also for libbobcat, icmake, and yodl
21:50 <jirutka> and it’s GPL3
21:51 <ncopa> we can run the gpl3 in isolated container so it does not touch anything else :)
21:52 <Shiz> :P
21:52 <Shiz> i'm gonna work on apkbuilds/gpg-remailer setup, gonna see what exactly is required
21:53 <ncopa> thanks!
21:53 <jirutka> Shiz: libbobcat, icmake, and yodl :) it’s listed in gpg-remailer/required
21:53 <Shiz> jirutka: recursive deps are a thing
21:53 <Shiz> :p
21:54 <jirutka> Shiz: yeah, ofc :) …and deps of them :)
22:05 <ncopa> have a nice weekend everyone
22:06 <Shiz> you too!
22:08 <jirutka> you too! o/
22:13 nmatt joined
22:22 <TBB> okay, got the complete package origin resolver done in Bash, and got a 20x performance increase compared to the old one that parsed apk policy output
22:31 blueness joined
22:33 <jirutka> TBB: what exactly are you trying to achieve?
22:33 <TBB> repository subsets for restricted installs and environments
22:34 <jirutka> TBB: if you want to just find origin for any pkgname, then `apk search --origin --exact --quiet PKGNAME`
22:34 <jirutka> repository subsets?
22:35 <TBB> basically I perform an Alpine install and after it gather together all packages in it into a smaller repository
22:36 <TBB> there's a reason I do that, but I can't go to the specifics... I'll have to test that line you just wrote tomorrow
22:37 <jirutka> TBB: `apk info | xargs apk search --origin --exact --quiet | sort -u`
22:38 <jirutka> TBB: if i understand you correctly, then this command should return what you want
22:38 <TBB> you're breaking my heart, I just wrote a hundred lines of shell script for that :(
22:38 gromero joined
22:38 <jirutka> TBB: sry :( why you haven’t asked before writing it…?
22:38 <TBB> (and enjoyed it, which makes it even sadder)
22:39 <TBB> I kind of asked some 4 hours ago, but I probably didn't formulate my question clearly
22:40 <TBB> let it be said tho, I've only spent something like 30 minutes on that script, the rest were spent in a pub sipping excellent beer...
22:42 <jirutka> TBB: well, I also wrote a shell script for resolving origins some time ago, when I didn’t know about this… https://gist.github.com/jirutka/6717f68c7f76c9425b21d0cbe2eaa007#file-abuild-origin
22:44 <jirutka> TBB: at the time you’ve asked I was in a car :/ also you’ve started with "apk policy", that was kinda misleading :)
22:45 <TemptorSent> Hmm, are we talking about the same concept of 'origin' here? policy gives the repo origin.
22:47 <TBB> yeh, at first glance apk policy was the only thing that came to my mind with regards to finding the exact URL a package was fetched from
22:48 <TBB> that's what I mean by package origin
22:48 <TemptorSent> Ahh, in apk parlance, 'package origin' means source APKBUILD package if I understand correctly.
22:49 minimalism joined
22:49 <jirutka> TBB: aha, we’re talking about two different things :)
22:50 <TemptorSent> TBB: So your time was not wasted, and I would be interested to see your script, as I'm trying to finish up the necessary reworks to make it possible to fetch an atomic set of packages.
22:50 <jirutka> TBB: origin means the base package of a subpackage, as TemptorSent wrote
22:51 <TemptorSent> I built a revdep tree builder that could be refed all the way to the URL if so inclined.
22:51 <jirutka> TBB: why exactly do you need URL of repository…?
22:52 <TemptorSent> Subsetting specific revs of specific packages I suspect.
22:52 <TBB> TemptorSent: it's never really wasted if the effort helps in gaining a deeper understanding of how things work. Okay, sometimes time could be more efficiently spent, but the learning is worth a bit of inefficiency
22:52 <jirutka> TemptorSent: ??
22:52 <TemptorSent> Quite true :)(
22:54 <TemptorSent> To build a specific, supportable set of packages that have been audited and verified to interoperate properly, and create a subset repository allowing such to be fetched by a client machine without regard to the current rev in Alpine
22:54 <TemptorSent> At least that's the impression I got and how my use-cases work.
22:54 <TBB> jirutka, I install packages from maybe 7 different repositories into a system; these are the official Alpine repos and some in-house ones. Once I have the install finished, I gather the installed apk packages into a repository that can be used in a restricted environment that has no access to any of those repositories, so that the install can be repeated
22:55 <TBB> that's pretty much exactly the case, TemptorSent
22:56 <TemptorSent> TBB: I've got much of the rest of the support system for that already in place in the 'mkalpine' branch of mkimage.
22:56 <TemptorSent> Speaking of which jirutka, can we split of the mkalpine branch into its own repo now without modifiying the rest, and migrate the remainder at a later date, or is that too messy?
22:57 <TemptorSent> er mkimage-refactor-scripts branch rather.
22:58 <TBB> TemptorSent, I think we've discussed this earlier; I also wrote my own installing and imaging system some 2 years ago because why not, and I've been maintaining it ever since. I was working in one specific project that switched to Alpine as the base OS, but then needs arose to support several distributions, so I basically scripted the whole thing from scratch after spending some time with mock and finding it inadequate
22:58 <TemptorSent> the 'apkroottool' and 'kerneltool' components are essentially functional now, although I'm working on improving the dep solver.
22:59 <TBB> (make that "several distributions and projects")
23:00 <TemptorSent> Right, I'd love to be able to support arbitrary packaging by simply adding a support file.
23:01 <TemptorSent> The kerneltool functionality is already setup for custom builds, and could easily support other dist kernel packaging, which may be useful on alpine too in some casese.
23:02 <TBB> I can currently produce Alpine and CentOS 6/7 installs and build packages for both using the same source repo; there are two projects currently using it but only one of me, although, I've just gotten a second developer who's more familiar with Debian and its derivatives, so hopefully he'll implement support for those
23:02 <jirutka> TemptorSent: yes, I can split it without modifying the aports repo
23:02 <TemptorSent> apkroottool uses fkrt with persistent state stored to allow multiple commands to be run before building an archive.
23:03 <jirutka> TemptorSent: please don’t tell me that you’re writing deps solver in shell…
23:03 <TemptorSent> jirutka: What should I do on my end to make it easy?
23:03 <TemptorSent> awk actually :)
23:03 <jirutka> TemptorSent: omfg
23:03 <TBB> /o\
23:03 <TemptorSent> But yes, it will be rewritten in C.
23:04 <jirutka> TemptorSent: first, apk already implements deps solver (probably classic SAT, but I haven’t read it)
23:04 <TemptorSent> Even the existing code with full recursion isn't horribly slow.
23:04 <jirutka> TemptorSent: second, it’s fucking crazy to do any complex things like computing deps in shell/awk/…
23:04 <TemptorSent> jirutka: Not for the libs/files
23:04 <TemptorSent> Actually, computing deptrees is simple!
23:05 <TemptorSent> A couple dozen lines of awk.
23:05 <jirutka> TemptorSent: Lua or C would be surely more faster, reliable and maintainable
23:05 <TBB> I can only personally say that Bash is my hammer, and you know what they say about people whose only tool is a hammer :)
23:06 <TBB> (okay, I'm proficient in TCL as well, but that's possibly even less fashionable than Bash)
23:06 <jirutka> TBB: I’m afraid that TemptorSent is the same, except he at least use POSIX shell, not Bash
23:07 <jirutka> TemptorSent: about split, just tell me how the final files structure should look like
23:08 <TBB> I don't mind plain sh either (I've actually implemented the whole tool in plain sh just to see if it's possible), but I like associative arrays a bit too much to do that full time :D
23:08 <jirutka> TBB: then use real language, not Bash…
23:09 <jirutka> TBB: for example Lua is very easy to learn and like infinitely better than Bash
23:09 <TemptorSent> Oh, I can code C quite happily, but I generally make sure the logic works out using bash becasuse ANYONE can read it.
23:10 <przemoc> TBB: I was going to write that most people writing in bash actually barely use bash features, simply using [[ or == for instance, but apparently you're an exception, as associative arrays have no easy POSIX-ification ;)
23:10 <TBB> I do have TCL for that already, but learning Lua would definitely be useful
23:10 <TemptorSent> Also, for extensive string handling, awk is a pretty good tool, while C requires quite a bit of memory management.
23:10 <jirutka> TemptorSent: I’m not sure about “anyone”… very complex shell scripts are usually not easy to reason about…
23:10 <TemptorSent> Rust is actually an interesting option, but they haven't stabilized it.
23:11 <TemptorSent> jirutka: True, but when each function can be tested individually, it's much easier.
23:11 <jirutka> TemptorSent: ofc Rust would be awesome option!
23:11 <jirutka> TemptorSent: that’s not true, Rust is already stable
23:12 <TBB> Rust and Go both look interesting
23:12 <TemptorSent> Stable in terms of language development and APIs.
23:12 <jirutka> TBB: please not go…
23:12 <TemptorSent> Agreed, go needs to go :)
23:12 <jirutka> TemptorSent: Rust lang and APIs are stable, since 1.0.0
23:12 <jirutka> TemptorSent: they are *very* careful about this
23:12 <TemptorSent> The rust toolchain is also messy, as you well know, but it looks like that is improving.
23:13 <jirutka> TemptorSent: I know… I don’t like cargo too
23:13 <TemptorSent> jirutka: Okay, so no more suprises with language features suddenly changing semantics?
23:13 <Shiz> i object to the notion that lua is good
23:13 <Shiz> :P
23:14 <jirutka> TemptorSent: no more surprises, unless you use unstable features, I mean those that are available only in nightly and explicitly marked as unstable
23:14 <TemptorSent> I'd do it in lisp, but then I'd probably be one of three here who could even read it, let alone debug it.
23:14 <Shiz> yeah and as one of those i wouldn't WANT to read it
23:14 <Shiz> let alone debug
23:14 <Shiz> so that leaves two
23:14 <Shiz> :P
23:15 <TemptorSent> jirutka: And the language is fully usable without said unstable features now? Last I checked nearly everything was relying on nightly.
23:15 <Shiz> some cool stuff still relies on nightly
23:15 <Shiz> but a lot of stuff works on stable now
23:15 <TemptorSent> Shiz: Can't say I blame you - lisp isn't plesant reading in many casese.
23:15 <jirutka> TemptorSent: actually I’d be looking forward to read it if written in Lisp… I don’t know Lisp, but it’s one of the langs I’d like to learn
23:16 <Shiz> jirutka │ TBB: please not go… <-- after experiencing Rust as a developer (not packaging for alpine, just writing something in it), i may actually prefer go
23:16 <TemptorSent> Cool, looks like I'll revisit rust then.
23:16 <Shiz> rust is such a pain...
23:16 <jirutka> TemptorSent: yes, it’s fully usable, if you don’t insist on using bleeding edge features
23:16 <jirutka> Shiz: Rust build system…
23:16 <Shiz> im talking about the language :)
23:17 <Shiz> that's why i explicitly said as a developer, not alpine packager
23:17 <jirutka> Shiz: and you haven’t seen Go build system, have you? so can’t compare ;)
23:17 <Shiz> ...
23:17 <TemptorSent> jirutka: Cool.
23:17 <Shiz> do i have to repeat myself or
23:17 <Shiz> lol
23:17 <jirutka> Shiz: aha, what do you dislike about the lang? :(
23:17 <Shiz> i have two main issues with it
23:17 <Shiz> 1) it is way too complex, growing to C++ levels
23:17 <Shiz> 2) the development experience is still too much 'fight the compiler by changing semi-random things until your lifetimes work'
23:18 <TemptorSent> 1 - Agreed, 2 - Ouch! Yeah, that's what I was hoping was fixed.
23:19 <Shiz> and a third issue stemming from the first: there is no viable alternative implementation right now
23:19 <Shiz> which is the same for some other langs, hence a more minor one
23:19 <Shiz> but still something that's not a good sign
23:19 <TemptorSent> jirutka: The only problem with writing stuff in lisp for alpine is then we need to have yet another binary installed to use it.
23:20 <jirutka> ad 1) unfortuntely I have to kinda agree, ad 2) this is just a matter of time, it’s the hardest part of Rust, but it’s worth it, if you want to write efficient low-level code
23:20 <TBB> if Lisp was good enough for JPL, it is good enough for Alpine
23:20 <TBB> (on the other hand, if Lisp was good enough for JPL, why did they switch to Java at some point?...)
23:21 <TemptorSent> It's actually a wonderful language, but the paradigm is different enough to make it difficult to follow for many.
23:21 <Shiz> i was never a lisp fan
23:21 <jirutka> Shiz: Rust is not easy to learn, that’s the fact; but still it’s IMO easier than to learn how to write secure and reliable C or C++…
23:21 <Shiz> jirutka: C++, possibly
23:21 <Shiz> C, i vehemently disagree
23:22 <TemptorSent> And there are several incompatible versions, which really makes things irritating at times.
23:22 <jirutka> Shiz: and it’s non-sense to compare it with Go, this is totally different land, Go is not a low-level lang, it has huge runtime and GC
23:22 <Shiz> rust's runtime is larger than go's
23:22 <jirutka> Shiz: ok I should add write secure, reliable and big project in C or C++…
23:22 <TemptorSent> C is difficult to write secure software in using the existing APIs at the least.
23:23 <jirutka> Shiz: no, it’s not, not the runtime that is compiled into every binary
23:23 <Shiz> oho yes it is
23:23 <jirutka> Shiz: no, it’s not
23:23 <jirutka> Shiz: I’m 100% sure about this
23:24 <TemptorSent> Anyway, if anyone has a suggestion for a replacement for TAWK, I'd be greatly appreciative :)
23:25 <jirutka> Shiz: just write some small program in Rust and Go, compile them in release mode, strip binaries and compare size
23:25 <jirutka> Shiz: the whole point of Rust is zero-cost abstraction and very minimal runtime
23:26 <Shiz> but it fails at that
23:26 <jirutka> Shiz: it does not ship full GC and other bloat of shits with every built binary
23:26 <jirutka> Shiz: it does not from my testing
23:26 <Shiz> did you test with the correct rust flags?
23:26 <jirutka> Shiz: hello world in Rust has around 180 kiB stripped? how big is that in Go? 1 MiB?
23:26 <jirutka> Shiz: ofc I did
23:26 <Shiz> because my rustc outputs a 2.1mb binary
23:27 <jirutka> Shiz: unstripped
23:27 <jirutka> Shiz: contains A LOT of debugging symbols
23:27 <jirutka> Shiz: compile in *release mode* (!) and strip the binary
23:27 <Shiz> also, please do not highlight me every line
23:27 <jirutka> okay, sry
23:27 <Shiz> anyway
23:27 <Shiz> yes, stripped the runtime is smaller
23:28 <Shiz> but 180kb is still by no means a very minimal runtime
23:28 <jirutka> you should remember that I’ve dropped jemalloc even after you’ve fixed it b/c it increased binary size and I’ve also wrote to the apkbuild exact sizes…
23:29 <jirutka> 180 kiB is imo reasonably small… and it’s *definitely* a magnitude smaller than Go
23:29 <jirutka> maybe it’s 160 kiB, I don’t remember the exact number
23:29 <TemptorSent> 180kb is reasonably small? For hello world? WTF?
23:30 <jirutka> hello world is ofc far from real-world examples… it’s a constant, it does not get much bigger with more code
23:30 <Shiz> actually
23:30 <Shiz> the product i did in rust had a 20mb binary in --release after stripping
23:30 <Shiz> so
23:30 <TemptorSent> Yeah, but seriously, 180k to print a handful of characters using stdio?
23:30 <Shiz> :P
23:30 <Shiz> 15-20mb iirc
23:31 <jirutka> show my any other lang that provides at least similar guarantees as Rust and produces smaller binaries…
23:31 <jirutka> then you had probably a lot of deps…?
23:31 <Shiz> and also, the go runtime also doesn't increase significantly with program complexity
23:31 <Shiz> so you're kind of mooting your own point here
23:32 <jirutka> I’m not, cause i know the numbers
23:32 <TemptorSent> I'm not saying there is anything better currently, but that reeks of unnecessary code inclusion.
23:32 <jirutka> TemptorSent: how often do you build hello world…?
23:32 Mr_H joined
23:32 <Shiz> how often do i build small programs, all the time
23:32 <Shiz> because small programs are best programs
23:33 <jirutka> it’s non-sense to putting effort to strip support code that is needed by almost all programs except simplest hello world
23:34 <jirutka> still, when you compare these two as languages, with some knowledge about langs, it’s very clear that Go is total crap and Rust is very innovative and well designed
23:34 <TemptorSent> jirutka: I don't often build hello world, but I do often write code that does nothing but do simple math and print the result.
23:34 <jirutka> I’m not saying that it’s perfect, I’m also kinda disappointed how complex it become
23:36 <jirutka> TemptorSent: btw we’re comparing binaries produced for x86_64 with stdlib… you can use Rust for embedded too, there you usually don’t include stdlib and the size of produced code is very different
23:37 <TemptorSent> I liked the original concept - simple, deterministic, and safe-by-default --- it's way beyond that now, to the point of being hard to understand the implications of a given code block in cases.
23:37 <jirutka> and the best part for me is that Rust is actually functional lang, at least as functional as it can be as a low-level lang
23:38 <jirutka> this is incomparable with Go, C, C++ and similar
23:38 <Shiz> rust is not functional
23:39 <TemptorSent> true, although there seem to be some gotchas in the functional usage compared to 'true' functional languages (like lisp :) )
23:39 <jirutka> it is, but not purely functional
23:39 <jirutka> and does not support lazy evaulation
23:39 <Shiz> lazy evaluation is one of the things it does support
23:39 <jirutka> it’s not black/white with FP
23:39 <Shiz> through iter()
23:39 <jirutka> not lazy evaluation as you have in Haskell…
23:40 <jirutka> lazy evaluation through iter() has even Lua
23:40 <Shiz> anyway, rust has some functional aspects, but it's not overall functional
23:40 <Shiz> purely or otherwise
23:40 <jirutka> that said I’d love to see the best concepts of Rust implemented in truly minimalistic language, something like Lua, but low-level
23:40 <Shiz> 'something like Lua' is something I'd run far way from
23:41 <Shiz> :P
23:41 <jirutka> as I said, it’s not purely functional, yes
23:41 <jirutka> but it doesn’t make much sense to talk about purely functional…
23:41 <jirutka> most FP langs are not pure
23:41 <Shiz> 01:40:44 Shiz │ purely or otherwise
23:41 <Shiz> you're the only one going on about pure
23:41 <Shiz> :P
23:42 <Shiz> jirutka │ still, when you compare these two as languages, with some knowledge about langs, it’s very clear that Go is total crap and Rust is very innovative and well designed
23:42 <Shiz> and this is of course laughable at best
23:42 <jirutka> I’m just saying that “functional language” != “purely functional language” and Rust is a functional language
23:42 <Shiz> yes, and i'm saying rust is not a functional language
23:42 <Shiz> pure or otherwise
23:42 <jirutka> actually it’s not…
23:43 <jirutka> and I can prove that statement
23:43 <jirutka> but not now, need to go sleep
23:43 <Shiz> you can't prove a subjective statement like "is total crap" and "is well designed"
23:44 <jirutka> ofc…
23:44 <jirutka> don’t read it literally :)
23:44 Mr_H joined
23:44 <TemptorSent> If a function is treated as a first-class entity that can be used anywhere a variable is, you have the minimal requirements for a 'functioal' language.
23:45 <Shiz> now that is absolute nonsense
23:45 <Shiz> by that measure both C and assembly are functional languages
23:45 <jirutka> since when function is a first class citizen in C? XD
23:45 <TemptorSent> No, you can't pass a FUNCTION in either of those, you can only pass a POINTER to a function.
23:45 <nmeum> *cough* #alpine-offtopic *cough*
23:46 <jirutka> and since when assembly has functions? XD
23:46 <Shiz> TemptorSent: you don't actually pass function blocks around in haskell either, that's irrelevant
23:46 <Shiz> but i'm going to continue with my apkbuilds
23:46 <jirutka> no it’s not irrelevant
23:47 <TemptorSent> It's the semantics that is important, not the implementation.
23:47 <Shiz> and as a final note: functional languages are about being declarative instead of imperative, pure input-output functions and the avoidance of state
23:47 <Shiz> it has nothing to do with wheter functions are first-class data or not
23:47 <Shiz> and now i'm going to get back to my apkbuilds
23:48 <jirutka> you’re right with that, but as I said, it’s not black and white and FP is a set of concepts, not something exact
23:49 <jirutka> actually I’ve been arguing with one speaker at InstallFest about Rust being OOP…
23:49 <TemptorSent> You're not wrong Shiz, but those abilities stem from functions themselves being first-class entities.
23:49 <jirutka> I thnk that it’s not, he that it is… I asked one of langs teacher at uni and according to the most formal definition of OOP, most of common OOP langs like Java are actually not OOP at all…
23:50 <TemptorSent> Remove that, and you can't write functional programs cleanly.
23:50 <jirutka> the conclusion was that Rust has some aspects of OOP
23:51 <TemptorSent> Java is an ugly hack that has some OOP concepts, but manages to fail horribly.
23:51 <jirutka> agree
23:51 <Shiz> as nmeum mentioned, #alpine-offtopic
23:51 <jirutka> oh, sry
23:51 <jirutka> as I mentioned, sleep :)
23:51 <TemptorSent> Goodnight jirutka.
23:51 <jirutka> and I’ll try to forget about this discussion
23:58 blueness joined