IRC #olimex 2018-01-02

[11:14:39] <leon-anavi> hi :) best wishes for 2018 :)
[11:18:08] <adj__2> leon-anavi, best wishes to you too
[11:18:20] <adj__2> thanks for maintaining the activity in this channel
[11:26:55] <leon-anavi> adj__2, hehe :) may the open source be with us again in 2018 :)
[11:30:35] <adj__2> :
[11:30:37] <adj__2> :)
[11:32:31] <lukas2511> :)
[13:41:39] <Yauheni> Hi all! Looking for correct link to pre-build Debian rootfs for Olinuxino-micro. Link form seems doesn't work. Where can I find a correct one? Thanks in advance.
[13:56:02] <lukas2511> Yauheni: i'd recommend
[13:56:28] <lukas2511> oh
[13:56:36] <lukas2511> imx233 micro, not a20
[13:56:40] <Yauheni> yep
[13:56:43] <lukas2511> mh
[13:58:35] <lukas2511> that board has really low power, i wouldn't recommend going with debian... do you really need debian? or would you be willing to give archlinux a try? from experience that works a lot better on low-power boards :)
[13:59:21] <lukas2511> this should work
[14:03:30] <Yauheni> Frankly speaking, i'm looking for any prebuild linux image for my imx233 Olinuxino-micro board :) Will check you link, thanks a lot.
[14:06:12] <lukas2511> prebuild... uff...
[14:06:37] <lukas2511> here is a debian image, but it's probably extremely outdated:
[14:08:04] <braunr> Yauheni: i use buildroot for thatr
[14:08:15] <braunr> Yauheni: i can build you an image if you want
[14:08:33] <lukas2511> yea, those boards are really not meant for full distros, a buildroot image would probably be the best idea
[14:08:45] <braunr> takes about 15 mins on my machine :p
[14:09:03] <lukas2511> woah, that's a long time! ;)
[14:09:16] <Yauheni> Oh... no need, thanks...
[14:10:03] <Yauheni> Will try lukas2511's links first.
[14:10:46] <braunr> you know what, i'll build an image just in case ;)
[14:11:41] <Yauheni> Ok :) Thank you
[14:18:20] <braunr> Yauheni: lunch time, bbl
[14:35:01] <braunr> $ time make
[14:35:05] <braunr> real 18m58.133s
[14:37:00] <braunr> Yauheni:
[14:38:18] <Yauheni> Thank you, really appreciate
[14:38:22] <braunr> lukas2511: what's your argument against debian concerning low power ?
[14:38:39] <braunr> Yauheni: ;)
[14:39:48] <lukas2511> braunr: mainly apt-get and dpkg with all its hooks being a bit fat, also a "standard" installation comes with a lot of unnecessary stuff. it's a lot better now with stretch, but it's still extremely slow
[14:40:00] <braunr> slow ?
[14:40:24] <braunr> how does having more stuff make it use more power (except at install time) ?
[14:40:40] <braunr> and how does having more data on the sdcard slow the processor ?
[14:40:43] <lukas2511> comes with a lot of ... running ... stuff
[14:40:48] <braunr> it does ?
[14:41:04] <braunr> because i have debian on an amd geode, and honestly, there is almost nothing running with a standard install
[14:41:33] <lukas2511> really? i can remember rpcbind and some other stuff running in "Standard system" installations
[14:41:35] <braunr> same on the olimex actually
[14:41:46] <lukas2511> but okay, i mean for arm it's mostly debootstraped anyway and there it doesn't happen
[14:42:18] <lukas2511> still, the apt-get experience on those boards is really.. not so nice, that's actually my main reason
[14:42:23] <braunr> debian is really ok, the only "drawback" is that, since it's binary, you don't optimize the code for your target, and yes you may have more packages to install
[14:42:34] <braunr> it got a lot better too
[14:42:39] <lukas2511> especially for people who just want to play around it's really bad, if you already have an application in mind it's not that bad
[14:42:51] <braunr> i would say the contrary actually :)
[14:42:57] <braunr> people who want to try want binaries that work
[14:43:04] <braunr> people who have an application in mind want to custom tailor
[14:43:07] <lukas2511> i mean, best would be buildroot / yocto / whatever
[14:43:17] <braunr> sure but it requires learning the tool
[14:43:30] <braunr> although once you know it's really only two commands for buildroot
[14:43:51] <lukas2511> but debian brings the advantage that you can develop on your local machine, install the necessary dependencies, and you'll have 1:1 the same versions and your code will (probably) just work
[14:44:12] <braunr> that's also true with cross compiling
[14:44:12] <lukas2511> buildroot is a bit more complicated
[14:44:29] <lukas2511> well yea if you are building static binaries, okay
[14:44:35] <lukas2511> that'll work either way
[14:44:50] <lukas2511> but you can't always do that
[14:44:57] <lukas2511> e.g. your application might be a python script
[14:45:15] <lukas2511> not really possible to build a static python script binary with everything baked in
[14:45:28] <braunr> hum
[14:45:33] <braunr> i don't see how making it static helps
[14:45:52] <braunr> in buildroot, you build the entire distribution, so static or dynamic doesn't change much, you control all your versions
[14:46:55] <lukas2511> yea but see, if you are developing on a normal system, running debian, and you have e.g. boost 1.62 or whatever, and then you install buildroot on your target, but buildroot brings boost 1.60, and there have been bugfixes or even major changes between those versions, you might run into problems later on
[14:47:12] <braunr> that's why you use the buildroot generated sdk to cross compile
[14:47:16] <lukas2511> but with debian on target and dev machine, you have the same versions of those libraries, just built for different architectures
[14:47:56] <lukas2511> braunr: but your testing might be local on your dev machine, for speed and other reasons
[14:48:15] <braunr> which is usually done with an emulator like qemu
[14:48:26] <lukas2511> i never actually did that...
[14:49:03] <braunr> while building natively and then crosscompiling for releases can work, and it's good for portability
[14:49:04] <lukas2511> most of my testing is really just building it against my dev machines libraries and trying stuff, and when it nears being finished i continue (long-time) testing on my target
[14:49:17] <braunr> simple differences like word size or endianness can get many developers confused
[14:49:31] <lukas2511> and there i'm often using debian because it allows for security updates which in most cases don't break anything else
[14:50:01] <braunr> well, that's not something i'd personally recommend, but we digress here
[14:50:21] <lukas2511> but i'm mainly writing python, my C code is only for interacting with the hardware and is replaced by a dummy on my devmachine
[14:50:48] <braunr> nice to hear people are using python more on embedded machines :)
[14:53:19] <lukas2511> yea, but in the last months i've been mostly writing C because i was working with cortex m3 and similar controllers, currently working on a optical barrier for bat tracking :)
[19:53:22] <mathiasx> lukas2511: if you don’t mind, where do you work that you get to work on projects like that?
[19:54:21] <lukas2511> mathiasx: unfortunately it's just a hobby (for now)
[19:57:48] <lukas2511> im working together with a member of BAFF ( a group in my city for protecting bats) and we have access to a few caves where we can mount our hardware
[20:06:13] <mathiasx> Nice! That is a cool project.
[20:15:11] <lukas2511> mathiasx: i have a writeup about our old light barrier experiment on my blog (it's in german, if you don't speak german google translate may help)
[20:16:58] <lukas2511> other than the light barrier we are also experimenting with ultrasonic recorders, bat call classification and connecting existing hardware to new systems that give more information (e.g. triggering a ultrasonic recording and capturing a photograph on light barrier event)
[20:20:44] <lukas2511> but on those i mainly just helped getting things rolling and fixing ugly bugs. my main experiment is the light barrier, but it's going slowly as i have a few other projects (dehydrated, a bash based let's encrypt client) and bad time management skills ^^'
[20:21:40] <mathiasx> Too many side projects and not enough time for them all => me too, and many others.
[20:22:09] <lukas2511> exactly