Re: [Tinkerphones] Dual personality systems (was Re: ZeroPhone site offline)
Quoting Paul Boddie (2022-01-09 23:40:08) > On Saturday, 8 January 2022 22:49:19 CET Jonas Smedegaard wrote: > > > > Even current generation PinePhone might be made to run a (very) > > lightweight telephony-focused stack, on its embedded 32bit 300MHz > > AR100 processor. > > > > I maintain the needed compiler for Debian in package gcc-or1k-elf, > > and getting Linux compiled seems doable for someone with the skills > > (i.e. not me): https://linux-sunxi.org/AR100#Mainline_Kernel_Support > > The AR100 processor in the Allwinner SoCs appears to be used as a kind > of microcontroller without memory management unit, at least from what > I can understand from that wiki page, so running vanilla Linux would > be out of the question. But there are other things it could presumably > be asked to do. It was my understanding that the AR100 was unusable for running Linux - until I read that wiki page, which to me seems to explicitly mention running linux on it - in the very section header, ever: > Mainline Kernel Support I am not knowledgeable in this low-level stuff though, so I take your word for it. [...] > I suppose that if it were possible to power down the main cores and > just keep the auxiliary core operating (perhaps more feasible with the > AR100 given its apparent use with power management), the aim would be > to somehow wake up the main cores in a state where they can present > the user with an interface upon some kind of telephony event. That I know for a fact is not only theoretical speculation: It is possible to fully power down the main cores and keep only the AR100 running: The reason I maintain the gcc compiler for AR100 is for Crust, a free firmware that I have succesfully used to put my Allwinner A64-based Teres I laptop to deep sleep: https://github.com/crust-firmware/crust - or Debian package crust-firmware. That codebase has some quite informative commit messages in the git source, which I imagine that someone more skilled than me can benefit from digging through to understand much more on what has already been mapped out of the AR100 functionality. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature ___ Community mailing list Community@tinkerphones.org http://lists.goldelico.com/mailman/listinfo.cgi/community http://www.tinkerphones.org
Re: [Tinkerphones] Dual personality systems (was Re: ZeroPhone site offline)
Quoting David Boddie (2022-01-08 22:17:22) > On Wed Jan 5 01:28:49 CET 2022, Paul Boddie wrote: > > Actually, a kind of dual personality system might address some of > > the general issues with vanilla Linux on smartphones, and I suspect > > that Linux alongside real-time components is a recognised > > architectural style for some kinds of devices.�� > > Since various SoCs started to include smaller cores along with the > bigger, more powerful ones > (https://en.wikipedia.org/wiki/ARM_big.LITTLE) it makes me wonder if > it wouldn't be possible to run a lightweight telephony-focused stack > on the low power core while running full-fat Linux on the high power > core. > > That way, the Linux side of things wouldn't even need to be aware of > how the telephony is done, and could interact with those components > using more familiar mechanisms, perhaps similar to ways two hosts on a > network might talk to each other. Even current generation PinePhone might be made to run a (very) lightweight telephony-focused stack, on its embedded 32bit 300MHz AR100 processor. I maintain the needed compiler for Debian in package gcc-or1k-elf, and getting Linux compiled seems doable for someone with the skills (i.e. not me): https://linux-sunxi.org/AR100#Mainline_Kernel_Support - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature ___ Community mailing list Community@tinkerphones.org http://lists.goldelico.com/mailman/listinfo.cgi/community http://www.tinkerphones.org
Re: [Tinkerphones] ZeroPhone site offline
Quoting H. Nikolaus Schaller (2022-01-06 09:33:16) > > > > Am 06.01.2022 um 00:59 schrieb Paul Boddie : > > > > On Monday, 3 January 2022 20:12:32 CET H. Nikolaus Schaller wrote: > >> > >> It happened several times during development of the GTA04 that people > >> said: nice but look you can buy this or that. Instead of helping getting > >> GTA04 better and making it a success. > > > > Maybe if the FSF encouraged investment in the hardware that > > runs the Free Software, everyone else would be better off: hardware would > > get > > designed and made, software developers would be involved in that process > > and > > not have to reverse-engineer proprietary devices, and maybe those involved > > would also get paid for their time. > > It is a very good question what whould happen if s/Software/System/ would be > applied... > > Some examples: > > Free System Foundation > Free System Foundation Europe > Free/Libre Open Source Systems > Free and Open Source Systems > Free and Open Source Systems Developers' European Meeting > etc. Excellent point! - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature ___ Community mailing list Community@tinkerphones.org http://lists.goldelico.com/mailman/listinfo.cgi/community http://www.tinkerphones.org
Re: [Tinkerphones] Librem 5
Quoting Joseph Armbruster (2021-02-13 20:37:17) > You're lucky! > > I ordered my librem 5 in NOV2018. I have yet to receive any > hardware... Sorry to hear that. I work for Purism, and was given a phone to help test it (but the last draft revision codenamed "Dogwood", not the final "Evergreen" that you will get). I am aware there is still a backlog, but don't know more details: I work on the higher end of the software stack, integrating packages with Debian and ensuring compliance with both Debian and FSF definitions of "Free". Also, if I _did_ know more details then most likely that would be a secret I was not permitted to share here, for commercial reasons. I dearly hope you will get your phone soon - and that it lives up to your expectations. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature ___ Community mailing list Community@tinkerphones.org http://lists.goldelico.com/mailman/listinfo.cgi/community http://www.tinkerphones.org
Re: [Tinkerphones] Librem 5
Quoting H. Nikolaus Schaller (2021-02-13 14:53:00) > > > Am 13.02.2021 um 11:52 schrieb Jonas Smedegaard : > > > > Quoting michael spreng (2021-02-13 10:45:18) > >> In December I received my librem5 phone and now had some time to try > >> it out. It seems to work reasonably well, can make phone calls and > >> messages. Though there is no support yet for the camera. > > > > Seems camera support saw progress for the low-level driver part as > > recent as yesterday: > > https://source.puri.sm/Librem5/linux-next/-/merge_requests/309 > > > > User-level access to camera seems tracked here: > > https://source.puri.sm/Librem5/Apps_Issues/-/issues/6 > > > > Using the camera from sripts seems possible since 2 months (but possibly > > specific to certain revision of the phone, or maybe the devkit): > > https://source.puri.sm/Librem5/linux-next/-/merge_requests/255 > > > > The phone ships with the more stable "amber" release of PureOS. Geeks > > might wanna explore the in-progress "byzantium" release instead, to get > > and play with bleeding edge changes: > > https://developer.puri.sm/Librem5/Development_Environment/Phone/Troubleshooting/Reflashing_the_Phone.html > > > > > >> Though programs not adapted for the phone screen are rather weird, > >> like vlc. > > > > A geeky way to locate _some_ adaptive apps is to look for packages > > depending on libhandy-1-0 (or libhandy-0.0-0). That only covers GTK > > apps, though - I am unaware if any such package-level indicators exist > > for Qt-based apps like VLC. > > > > The user-friendly way is to use the appstore, which shows only adaptive > > apps - and yes, there are only very few so far... > > I am sure this will change. If by "this" you mean availability of adaptive apps, then I agree: Seems to me there is enough momentum - e.g. multiple vendors reusing code from each other, all tied to mainline Linux > Our GTA04 history shows that the basics must work and then come apps. > Unfortunately it is a sisyphos work to make the basics work and keep > them running... So manpower to keep pace with upstream kernel releases > is key. > > The main reason why we were (are) stuck with QtMoko and Replicant > is that the kernel is still not in a perfect shape like people need > so that they can focus on improving their apps. And in the meantime > nobody knows any more how to rebuild QtMoko and Replicant from scratch > on a recent build system. Seems to me the failure is directly tied to getting code pushed upstream. Obviously when upstream project is dead (as is the case for QtMoko) there is no way to upstream - apart from taking over as upstream. And I guess over-the-fence upstreams like Qt and Google can be painful to push changes to (e.g. require copyright assignment), but I am not familiar with the details of those. Purism evidently invest in pushing code to mainline Linux and u-boot (and other projects higher up the stack as well). Time will tell if they push enough, and if there continues to be enough momentum. I am optimistic. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature ___ Community mailing list Community@tinkerphones.org http://lists.goldelico.com/mailman/listinfo.cgi/community http://www.tinkerphones.org
Re: [Tinkerphones] Librem 5
Quoting michael spreng (2021-02-13 10:45:18) > In December I received my librem5 phone and now had some time to try > it out. It seems to work reasonably well, can make phone calls and > messages. Though there is no support yet for the camera. Seems camera support saw progress for the low-level driver part as recent as yesterday: https://source.puri.sm/Librem5/linux-next/-/merge_requests/309 User-level access to camera seems tracked here: https://source.puri.sm/Librem5/Apps_Issues/-/issues/6 Using the camera from sripts seems possible since 2 months (but possibly specific to certain revision of the phone, or maybe the devkit): https://source.puri.sm/Librem5/linux-next/-/merge_requests/255 The phone ships with the more stable "amber" release of PureOS. Geeks might wanna explore the in-progress "byzantium" release instead, to get and play with bleeding edge changes: https://developer.puri.sm/Librem5/Development_Environment/Phone/Troubleshooting/Reflashing_the_Phone.html > Though programs not adapted for the phone screen are rather weird, > like vlc. A geeky way to locate _some_ adaptive apps is to look for packages depending on libhandy-1-0 (or libhandy-0.0-0). That only covers GTK apps, though - I am unaware if any such package-level indicators exist for Qt-based apps like VLC. The user-friendly way is to use the appstore, which shows only adaptive apps - and yes, there are only very few so far... - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature ___ Community mailing list Community@tinkerphones.org http://lists.goldelico.com/mailman/listinfo.cgi/community http://www.tinkerphones.org
Re: [Tinkerphones] "We don't control our lives" - smartphones - tinkerphones - debian on smartphones
Quoting rhn (2020-07-31 09:51:16) > Regarding both emails, I think there's a shared concept that we have, but > it's never explicitly stated, making it really hard to argue for it. > > The value of having an explicit goal is that it can be talked about: > different aspects are visible when spelled out, as well as tradeoffs, and > people talk past each other less when they have the same idea in front of > them. > > We seem to understand that "smartphone" is worrisome, and "laptop" is better. > But each of those is made of a large number of technologies. What differences > really matter? Let me pose a few questions that can hopefully help find the > important aspects. > > 1. Would a phone without a mobile modem be free of the control issues? > 2. Would a phone where the modem can't access RAM be free of the control > issues? > 3. Would a phone without Android? > 4. Would a phone without binary blobs? > 5. Would a phone with a mobile modem but one that can't be carried outside of > home? > 6. Would a phone with a mobile modem but using a SIP account? > 7. Would a laptop with a modem have the same issues? > 8. Would a laptop with un-emulated Android have the same issues? > > All in all, both a phone and a laptop are computers, and I don't really see > much difference between them, apart from size (and how close the modem is to > CPU, although that's not universal). Using the words as a catch-all can be > useful, but it obscures the actual important things that people care about. > > Maybe another way to consider it is to imagine a tablet, given that they come > from both camps, and saying what's good/bad about it. My approach is think in behavioural traits of a machine: 1) Curiosity: What data does the machine gather? 2) Intelligence: How "aware" is the machine about its data? 3) Trust: With whom does the machine consider ok to exchange data? Each of above can be both practical and scary, at the same time, depending on who you trust (and therefore find beneficial not scary that your machine trusts as well). Some trusts noone, and wants their machines to be stealth and dumb. Some trust Mozilla but not Google, and want their machines to boost intelligence by an allegience with Mozilla, but fear one with Google. I want machines to be coherent and transparent to its user. My machines should ideally ask me high-level questions like these, initially and easily revisited: How to engage with its surroundings - shy or social? How knowledgable - amnesiac or ever remembering any little detail? How collaborative - reserved or bragging about its knowledge? Which trust circles - none or specifics or any most powerful ally? - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature ___ Community mailing list Community@tinkerphones.org http://lists.goldelico.com/mailman/listinfo.cgi/community http://www.tinkerphones.org
Re: [Tinkerphones] "We don't control our lives" - smartphones - tinkerphones - debian on smartphones
Quoting Sebastian Krzyszkowiak (2020-07-29 18:46:09) > just for the record - the Debian wiki pages you have linked to are > rather outdated and not really relevant anymore. > > Current efforts around running Debian on mobile phones (such as Librem > 5 and PinePhone) are concentrated around DebianOnMobile team, which > includes people working on PureOS and Mobian pushing their stuff to > Debian upstream. > > Recent weeks brought massive progress and Purism's Phosh environment > is now on its way to Debian Testing. > > See: > > https://wiki.debian.org/DebianEvents/internet/2020/MiniDebConfOnline?action=AttachFile&do=view&target=DebianOnMobile.pdf > > https://salsa.debian.org/DebianOnMobile-team > > https://lists.debian.org/debian-mobile/2020/05/msg0.html > > https://qa.debian.org/developer.php?login=debian-on-mobile-maintain...@alioth-lists.debian.net > > https://matrix.to/#/#mobile-debian:matrix.org I then suggest to update the wiki page with notes about those recent efforts. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature ___ Community mailing list Community@tinkerphones.org http://lists.goldelico.com/mailman/listinfo.cgi/community http://www.tinkerphones.org
Re: [Tinkerphones] makesd (was Re: [Gta04-owner] New LetuxOS Kernels and some tricks and thoughts)
Quoting Paul Boddie (2019-05-28 13:20:26) > On Monday 27. May 2019 20.46.32 H. Nikolaus Schaller wrote: > > Configuration of the LetuxOS is now completely done by some > > letux-something.deb packages. So no single file is touched (well, > > there is some fallback at the moment that should be eliminated soon) > > besides through installing a .deb package. So it can also be removed > > or replaced (there are usually preinst and postrm scripts to make > > backups). The same for the kernel package. > > This part starts to sound a bit like Jonas's Boxer tool and its > objectives. ...except done _outside_ of Debian, so more comparative to (and no doubt far more elegantly written than) my scripts for https://bix.redpill.dk/ which is tracked at https://salsa.debian.org/tinker-team/box - to goal of those scripts is to be assimilated into Boxer, i.e. become a Debian _Pure_ Blend. > I did think a bit more about the formulation of systems in makesd > yesterday, trying to understand how some of the options work, and it > occurred to me that if I were describing the partitioning scheme then > I might use a notation like this: > > > > partition debian > type: ext4 > root: debian > kboot: latest > dboot: latest > modules: latest > config: latest > > partition lxde > $debian > root: lxde > > partition lc8-boot > type: fat > size: 5 > boot: Letux-Cortex-8/latest > kernel: latest > devices: latest > > partition lc8-root > $lxde > kernel: none > devices: none > size: 95 > > system lc8 > $lc8-boot > $lc8-root > > What format is that? Looks like a custom format to me. I recommend using a common format, like ini (separating sections with [foo] lines instead of horisontal space being significant) or YAML or TOML or JSON or shell sourcable variables (i.e. the format used for /etc/default/* files so probably well-defined womewhere for that use). > This kind of notation reminds me of other things, which I suspect > might be these "orchestration" tools people use for cloud computing > and provisioning. Not sure, but I think YAML is commonly used nowadays. Boxer currently rely on "reclass" which was written for Puppet, Salt, and Ansible. > However, I think multistrap also has some similar notion of > specialising definitions: > > > > [Debian] > packages=udev busybox-static > packages=openssh-server openssh-client > ... > > Yes, multistrap uses ini format. Also, multistrap is only really a competitor for debootstrap, not an orchestration tool. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature ___ Community mailing list Community@tinkerphones.org http://lists.goldelico.com/mailman/listinfo.cgi/community http://www.tinkerphones.org
Re: [Tinkerphones] Boxer (was Re: [Gta04-owner] New LetuxOS Kernels and some tricks and thoughts)
Quoting Paul Boddie (2019-05-27 18:43:39) > On Monday 27. May 2019 15.25.00 Jonas Smedegaard wrote: > > > > Wauw! Probably the first ever review of Boxer :-) > > Probably not a fair one, though... > > > Yes, I think it is an accurate description. As for "[not] much of > > immediate use" I believe it stems from being about reusable patterns > > - so if the project at hand cannot benefit from any of the existing > > patterns (in package boxer-data) then it is _more_ work, not less, > > to use Boxer if measured by that one project alone. > > I didn't realise (or see) that there was a boxer-data package. Looking > at it again, it does seem like a framework for writing deployment > recipes by defining the nature of nodes (specific systems) in terms of > classes (kinds of systems, described in terms of physical > characteristics and other capabilities). > > It seems that the work performed is focused on installing packages, > although I also see that there are "tweaks" which allow shell commands > to be used where packages would presumably need extra configuration. I > don't have any real familiarity with "orchestration" type solutions, > but it gives me the same kind of impression. > > I imagine that Boxer would be useful in preparing images to deploy on > devices like those discussed on this list, which I suppose isn't too > far off from things like FreedomBox, presumably the original target of > this work. Thanks again for looking at Boxer. Your understanding also here is accurate (phew - I know the documentation is really bad). Correct, main use of Boxer is handling package choices. Reason is that the aim is to support "Debian Blends" - i.e. systems defined by how packages are installed not how the system is afterwards tweaked. Ideally, Boxer does the same as debian-installer but from a separate host (contrary to debian-installer which operates on the target host). Therefore "tweaks" is a discouraged concept, even though often crucial at first, because any tweak is expected to be pushed "upstream" into relevant Debian packages. When perfect - i.e. when no tweaks are needed - you have a so-called "Debian Pure Blend": https://wiki.debian.org/DebianPureBlends#Terminology Correct, Boxer began as a generic tool for bootstrapping FreedomBox and similar systems created as direct competitor to a specific-purpose shell script emerging in 2011 to bootstrap Freedombox: Some of us FreedomBox developers met in person after a year of getting nowhere concrete with the project, Bdale Garbee worked on the specific-purpose script, I set out to make a proper tool but Bdale was quite sceptical, arguing that would take years. Here we are 7.5 years later and Boxer still cannot do the tasks of the special-purpose script (which used vmdebootstrap, btw). Boxer was first used for Debian Parl, a system for independent parliamentarians used in a pilot project at the European Parliament. Boxer is most recently used for https://box.redpill.dk/ which is sort-of a stepping-stone for https://solidbox.org/ - my (future) competitor for FreedomBox. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature ___ Community mailing list Community@tinkerphones.org http://lists.goldelico.com/mailman/listinfo.cgi/community http://www.tinkerphones.org
Re: [Tinkerphones] [Gta04-owner] New LetuxOS Kernels and some tricks and thoughts
Quoting Paul Boddie (2019-05-27 12:33:53) > So, in the context of the makesd script... > > http://projects.goldelico.com/p/gta04-makesd/ > > ...I had a look at what kind of tools might also do the same job. The > tasks makesd appears to do are as follows: > > * Downloads pre-built bootloader, device tree, kernel, modules, root >filesystems > > * Partitions a disk according to device expectations > > * Formats filesystems > > * Unpacks or copies the different payloads into their destinations > > Not wanting to spend weeks looking at this, I briefly looked at the > following: [...] > Boxer - https://wiki.debian.org/Boxer > > Since Jonas is the author and maintainer of the software and Debian > package, he can correct me on my impressions. This appears to be a > framework for performing system configuration tasks, maybe even > deployment, but the Debian source package doesn't seem to contain much > of immediate use (at least to my eyes). Wauw! Probably the first ever review of Boxer :-) Yes, I think it is an accurate description. As for "[not] much of immediate use" I believe it stems from being about reusable patterns - so if the project at hand cannot benefit from any of the existing patterns (in package boxer-data) then it is _more_ work, not less, to use Boxer if measured by that one project alone. > Meanwhile, I took a closer look at makesd itself. It seems like a very > capable script but is also rather complicated. Out of curiosity, I > wanted to see if I could break it up into smaller pieces that are > easier to inspect and maintain. Consequently, I ended up rewriting > functionality, investigating some awkward issues with sfdisk, and > generally spending more time on doing all of this than is perhaps > worthwhile. > > Still, my ongoing efforts can be found here: > > https://hg.boddie.org.uk/remakesd > > Eventually, I will get round to looking at more substantial things, of > course. Quite interesting! - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature ___ Community mailing list Community@tinkerphones.org http://lists.goldelico.com/mailman/listinfo.cgi/community http://www.tinkerphones.org
Re: [Tinkerphones] [Gta04-owner] New LetuxOS Kernels and some tricks and thoughts
Quoting H. Nikolaus Schaller (2019-05-22 08:03:27) > Hi Jonas, > one more thought on this with some distance in time. > > > Am 21.05.2019 um 15:13 schrieb Jonas Smedegaard : > > > >>> My point is that that I firmly believe that to get out of the > >>> vicious circle we _first_ need to collaborate and only _then_ > >>> compete (if needed at all, but that's a different discussion). > >> > >> Well, I am waiting for years for collaboration (the first LetuxOS > >> dates back to 2006) but it seems as if other projects decided to > >> compete and start from scratch instead of building on top of > >> LetuxOS :) > > > > Yes, just as Debian had waited for years for your collaboration > > (first release dates back to 1993) but you decided to compete with > > LetuxOS instead of joining and improving Debian :-) > > The main contribution of LetuxOS since 2006 is to advocate using > Debian on embedded boards. At that time everyone was using Angstrom. > We used Debian right from the beginning. And LetuxOS is (still) making > Debian more available and better useable on some set of devices by > adding a handful packages and compatible kernels. IMHO this *is* > collaboration and not competition. You asked how to get out of that vicious circle of not gaining enough users/developers/devices. I recommend *more* collaboration an *less* competition. Waiting for others to collaborate with you in your playground is *less* collaborative than joining others in their pre-existing playground. It is all collaborative. It is all competition. It is all good. But could be better. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature ___ Community mailing list Community@tinkerphones.org http://lists.goldelico.com/mailman/listinfo.cgi/community http://www.tinkerphones.org
Re: [Tinkerphones] [Gta04-owner] New LetuxOS Kernels and some tricks and thoughts
Quoting H. Nikolaus Schaller (2019-05-21 15:48:06) > > Am 21.05.2019 um 15:13 schrieb Jonas Smedegaard : > > Quoting H. Nikolaus Schaller (2019-05-21 12:51:43) > >>> Am 21.05.2019 um 12:26 schrieb Jonas Smedegaard : > >>> Quoting H. Nikolaus Schaller (2019-05-21 12:02:06) > >>>>> Am 21.05.2019 um 11:00 schrieb Jonas Smedegaard > >>>>> : Quoting H. Nikolaus Schaller (2019-05-21 > >>>>> 10:22:50) > >>>>>> BTW, here is another trick: You may (not) know that LetuxOS > >>>>>> images created by makesd come rooted. This means you can simply > >>>>>> ssh as root into the device without password check. This is > >>>>>> quite helpful for developers and debugging. > >>>>> > >>>>> A password-less network-accesible backdoor maybe unknown to the > >>>>> system owner sounds dangerous to me: I recommend documenting > >>>>> that very clearly (at least) everywhere passwords are currently > >>>>> menioned in documentation. > >>>> > >>>> Yes, please feel free to document it in the Wiki. [...] > > You really expect users to understand and document backdoors better > > than the developers implementing them?!? > > No. But I am the developer and in this case you are the user - and you > have a better understanding where this should be documented. As quoted above, my understanding is that best place to document backdoor access is EVERY place frontdoor access is documented and whereever this-device-is-insecure-by-default warnings are suitable. > >>> Suggestion: Add a notice in /etc/motd > >> > >> Hm. Do your ever read/see that? > > > > Why on Earth would I suggest it otherwise? > > Ok, accepted. My fault. I assumed that because I am not using that that > it is rare that others use it. > > On the other hand in LetuxOS it is not enabled. And not displayed > anywhere. You have openssh/dropbear/tinysshd/lsh configured to not present MOTD when users log in via ssh? I don't mean to imply that I always carefully read the MOTD message when logging into systems, but recommend it as one of several places for users to _possibly_ notice that whoa, this system has unusually low security!!! - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature ___ Community mailing list Community@tinkerphones.org http://lists.goldelico.com/mailman/listinfo.cgi/community http://www.tinkerphones.org
Re: [Tinkerphones] [Gta04-owner] New LetuxOS Kernels and some tricks and thoughts
Quoting Paul Boddie (2019-05-21 18:33:09) > On Tuesday 21. May 2019 15.48.06 H. Nikolaus Schaller wrote: > > > Am 21.05.2019 um 15:13 schrieb Jonas Smedegaard : > > > > > > Speaking for myself, I got discouraged when we met in Bavaria and > > > it became clear to me that your avoiding OSHW certification was a > > > deliberate business choice. > > > > No it was not about avoiding it. It was about not seeing any benefit > > for anyone. Perhaps I misunderstood you back then. I sure hope so. > > My key learning came from a discussion before that meeting where > > some guys urged me to publish the schematics. I did finally say: ok > > - here are the EAGLE source files. What happened? NOTHING. Nobody > > did apparently make use of this information. The device did not > > become better. Nobody had needed this for writing software - a PDF > > of the schematics was sufficient. > > The only argument I can make excusing those asking for the schematics > (or even the layouts) was that Eagle is proprietary software. There > has been a discussion about such topics on another list I follow > recently, involving software that is also presumably expensive as well > as proprietary. > > But then again, I feel that there are people out there who just want > to "tick the box" and feel good about the hardware being "open > source". I believe that such people do not appreciate the investment > involved in getting to a point where the hardware can be made. > Something similar might also be said about how people perceive > software, thinking that "open source" means lots of free-from- cost > stuff that magically gets made, too. > > I recall Nikolaus getting quite a bit of hassle from people who > demanded full access to the materials around projects like GTA04. I > wonder if those people are currently pursuing projects in a way that > is consistent with the demands they made of Nikolaus (and others) back > then. I am one who wants to "tick the box" it seems: I prioritize OSHW not because I plan on rewiring things myself but to encourage a World where I can hire someone to rewire if I one day need it - similar to how I prioritize Free licensed software not because I to reprogram it but for the possibility of eventually maybe hiring someone some day to do that. I have spent quite some time getting an understanding of what it requires for software to be "free" and am gaining similar knowledge for hardware. And I realize that for both it is quite difficult for me to explain to friends and family with less time devoted to this geeky research what exactly they need to look out for. For software I tell them to use Debian (where others might instead refer to FSF) and for hardware I tell them to look for the OSHW brand. I buy certified organic food. I am not geeky enough to judge sustainability of unbranded food. So I recognize how it must be similarly difficult for non-technical folks to not be able to judge sustainable hardware without a brand. Yes, the brand does not concretely gain enyone - it is purely branding. But for users that branding can be helpful. For me it is, even if I personally can bypass it and check directly if hardware ships with sources for the schematics, I cannot explain my lesser geeky friends how to avoid the traps of hardware promoted and "open" or "free" with different watered down meanings than the sustainability which I consider "getting out of the vicious circle". What we were discussing here. > > > but you decided to compete with LetuxOS > > > instead of joining and improving Debian :-) > > > > Where does LetuxOS compete with Debian? It does not modify or fork > > any Debian package. It just *adds* a handful of config packages to > > Debian and builds installable packages for a handful of devices not > > supported by Debian. Or in the case of QtMoko or Replicant or > > QuantumSTEP it compiles application software. I am not the one seeing competition here: When I talk about collaboration and plural distributions, Nikolaus wants to to discuss how to "prioritize LetuxOS over other distributions" > I wouldn't mind a clarification of how LetuxOS is somehow competing. > One might claim that there are ways of doing similar things with > Debian tools, but given that the toolset seems to change constantly > with the latest fad tool for building, bootstrapping or whatever being > introduced, advertised, outdated and abandoned within the season, > perhaps there is a valid argument for just writing something that will > do the job regardless of what other people think about it today. Which of the more conserva
Re: [Tinkerphones] [Gta04-owner] New LetuxOS Kernels and some tricks and thoughts
Quoting H. Nikolaus Schaller (2019-05-21 12:51:43) > Hi Jonas, > > > Am 21.05.2019 um 12:26 schrieb Jonas Smedegaard : > > > > Quoting H. Nikolaus Schaller (2019-05-21 12:02:06) > >> Hi Jonas, > >> > >>> Am 21.05.2019 um 11:00 schrieb Jonas Smedegaard : > >>> > >>> First of all, congratulations with the progress! > >> > >> Thanks! > >> > >>> > >>> > >>> Quoting H. Nikolaus Schaller (2019-05-21 10:22:50) > >>>> BTW, here is another trick: You may (not) know that LetuxOS > >>>> images created by makesd come rooted. This means you can simply > >>>> ssh as root into the device without password check. This is quite > >>>> helpful for developers and debugging. > >>> > >>> A password-less network-accesible backdoor maybe unknown to the > >>> system owner sounds dangerous to me: I recommend documenting that > >>> very clearly (at least) everywhere passwords are currently > >>> menioned in documentation. > >> > >> Yes, please feel free to document it in the Wiki. > > > > Is the wiki the only place passwords are mentioned? There are no > > other places users could be helped get notified about this open > > access? users > > I have no idea about what users do... We need users to see the missing > information and add it themselves. So we just must enable them to do > it. Which is the Wiki. Makes sense that users document what they do. Makes sense that developers document what they do. You really expect users to understand and document backdoors better than the developers implementing them?!? > > Suggestion: Add a notice in /etc/motd > > Hm. Do your ever read/see that? Why on Earth would I suggest it otherwise? > >>>> On a very general view, we have achieved a lot, but still not > >>>> enough to get the LetuxOS eco-system into a self-sustaining mode. > >>>> What is lacking? > >>>> > >>>> * users are missing because software is not good enough for daily > >>>> use > >>>> * hardware is missing because potential users complain about > >>>> missing high-quality software > >>>> * developers to polish the software are missing, because of missing > >>>> (new) hardware > >>>> > >>>> You see the vicious circle? Ideas how to magically break it? > >>> > >>> Contributing as certified OSHW your own work on designing hardware > >>> helps encourage developers contributing to getting the devices > >>> supported in mainline linux and u-boot. > >>> > >>> Getting bootloader and kernel code mainlined encourage distributors > >>> integrate and maintain support the the devices in their > >>> distributions. > >>> > >>> Having devices supported in distributions helps users prioritize the > >>> devices over other (lesser free) options available to them. > >> > >> This seems to assume that LetuxOS is not itself a distribution. > > > > No. > > > > For comparison, I work on the Debian distribution and dearly want the > > Olimex Teres-I DIY laptop well supported there, which requires escaping > > a similar vicious circle. > > It looks as if we need someone who actively wants to get the goodies > from LetuxOS into standard Debian. We had such members in our > community in the past, but they seem to have lost interest (or more > likely time for pure volunteering). Speaking for myself, I got discouraged when we met in Bavaria and it became clear to me that your avoiding OSHW certification was a deliberate business choice. Don't get me wrong: I respect your choice, and I have not totally lost interest, but I prioritize OSHW devices higher - e.g. decided to devote time to get the Olimex Teres-I laptop in working shape instead of grabbing the already mostly working PineBook which is lesser free. > > I have appreciated the efforts done in other distributions - > > concretely I work done in Armbian and OpenSuSE was instrumental in > > getting the device supported in mainline u-boot (likely included > > with 2019.07 release), which benefits all competing distributions. > > I just came to my mind what the most successful embedded Linux PC > probably is: RasPi with Raspbian. > > It is not even open hardware or software nor supported well by > mainline which seems to contradict your suggestions. RPi isn't in a vicious circle, so no c
Re: [Tinkerphones] [Gta04-owner] New LetuxOS Kernels and some tricks and thoughts
Quoting H. Nikolaus Schaller (2019-05-21 12:02:06) > Hi Jonas, > > > Am 21.05.2019 um 11:00 schrieb Jonas Smedegaard : > > > > First of all, congratulations with the progress! > > Thanks! > > > > > > > Quoting H. Nikolaus Schaller (2019-05-21 10:22:50) > >> BTW, here is another trick: You may (not) know that LetuxOS images > >> created by makesd come rooted. This means you can simply ssh as > >> root into the device without password check. This is quite helpful > >> for developers and debugging. > > > > A password-less network-accesible backdoor maybe unknown to the > > system owner sounds dangerous to me: I recommend documenting that > > very clearly (at least) everywhere passwords are currently menioned > > in documentation. > > Yes, please feel free to document it in the Wiki. Is the wiki the only place passwords are mentioned? There are no other places users could be helped get notified about this open access? Suggestion: Add a notice in /etc/motd > >> On a very general view, we have achieved a lot, but still not > >> enough to get the LetuxOS eco-system into a self-sustaining mode. > >> What is lacking? > >> > >> * users are missing because software is not good enough for daily > >> use > >> * hardware is missing because potential users complain about > >> missing high-quality software > >> * developers to polish the software are missing, because of missing > >> (new) hardware > >> > >> You see the vicious circle? Ideas how to magically break it? > > > > Contributing as certified OSHW your own work on designing hardware > > helps encourage developers contributing to getting the devices > > supported in mainline linux and u-boot. > > > > Getting bootloader and kernel code mainlined encourage distributors > > integrate and maintain support the the devices in their > > distributions. > > > > Having devices supported in distributions helps users prioritize the > > devices over other (lesser free) options available to them. > > This seems to assume that LetuxOS is not itself a distribution. No. For comparison, I work on the Debian distribution and dearly want the Olimex Teres-I DIY laptop well supported there, which requires escaping a similar vicious circle. I have appreciated the efforts done in other distributions - concretely I work done in Armbian and OpenSuSE was instrumental in getting the device supported in mainline u-boot (likely included with 2019.07 release), which benefits all competing distributions. > So what do you think would help users to prioritize LetuxOS over other > distributions? LetuxOS being superior to its competitors, obviously :-) My point is that that I firmly believe that to get out of the vicious circle we _first_ need to collaborate and only _then_ compete (if needed at all, but that's a different discussion). - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature ___ Community mailing list Community@tinkerphones.org http://lists.goldelico.com/mailman/listinfo.cgi/community http://www.tinkerphones.org
Re: [Tinkerphones] [Gta04-owner] New LetuxOS Kernels and some tricks and thoughts
First of all, congratulations with the progress! Quoting H. Nikolaus Schaller (2019-05-21 10:22:50) > BTW, here is another trick: You may (not) know that LetuxOS images > created by makesd come rooted. This means you can simply ssh as root > into the device without password check. This is quite helpful for > developers and debugging. A password-less network-accesible backdoor maybe unknown to the system owner sounds dangerous to me: I recommend documenting that very clearly (at least) everywhere passwords are currently menioned in documentation. > On a very general view, we have achieved a lot, but still not enough > to get the LetuxOS eco-system into a self-sustaining mode. What is > lacking? > > * users are missing because software is not good enough for daily use > * hardware is missing because potential users complain about missing > high-quality software > * developers to polish the software are missing, because of missing > (new) hardware > > You see the vicious circle? Ideas how to magically break it? Contributing as certified OSHW your own work on designing hardware helps encourage developers contributing to getting the devices supported in mainline linux and u-boot. Getting bootloader and kernel code mainlined encourage distributors integrate and maintain support the the devices in their distributions. Having devices supported in distributions helps users prioritize the devices over other (lesser free) options available to them. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature ___ Community mailing list Community@tinkerphones.org http://lists.goldelico.com/mailman/listinfo.cgi/community http://www.tinkerphones.org
Re: [Tinkerphones] +++ next breakthrough for qtmoko2 +++
Quoting H. Nikolaus Schaller (2018-03-26 12:43:56) > Hi, > nobody with an idea or knowledge? > > BR, > Nikolaus > > > Am 18.03.2018 um 15:37 schrieb H. Nikolaus Schaller : > > > > Another topic: > > > > I am trying to build it on/for wheezy, but ./mkqtspec.sh fails with: > > > > dpkg-architecture: error: DEB_TARGET_ARCH is not a supported variable > > name > > > > Jessie reports: > > > > root@letux:# dpkg-architecture > > DEB_BUILD_ARCH=armhf > > DEB_BUILD_ARCH_BITS=32 > > DEB_BUILD_ARCH_CPU=arm > > DEB_BUILD_ARCH_ENDIAN=little > > DEB_BUILD_ARCH_OS=linux > > DEB_BUILD_GNU_CPU=arm > > DEB_BUILD_GNU_SYSTEM=linux-gnueabihf > > DEB_BUILD_GNU_TYPE=arm-linux-gnueabihf > > DEB_BUILD_MULTIARCH=arm-linux-gnueabihf > > DEB_HOST_ARCH=armhf > > DEB_HOST_ARCH_BITS=32 > > DEB_HOST_ARCH_CPU=arm > > DEB_HOST_ARCH_ENDIAN=little > > DEB_HOST_ARCH_OS=linux > > DEB_HOST_GNU_CPU=arm > > DEB_HOST_GNU_SYSTEM=linux-gnueabihf > > DEB_HOST_GNU_TYPE=arm-linux-gnueabihf > > DEB_HOST_MULTIARCH=arm-linux-gnueabihf > > DEB_TARGET_ARCH=armhf > > DEB_TARGET_ARCH_BITS=32 > > DEB_TARGET_ARCH_CPU=arm > > DEB_TARGET_ARCH_ENDIAN=little > > DEB_TARGET_ARCH_OS=linux > > DEB_TARGET_GNU_CPU=arm > > DEB_TARGET_GNU_SYSTEM=linux-gnueabihf > > DEB_TARGET_GNU_TYPE=arm-linux-gnueabihf > > DEB_TARGET_MULTIARCH=arm-linux-gnueabihf > > root@letux:# > > > > Wheezy reports: > > > > root@letux:/# dpkg-architecture > > DEB_BUILD_ARCH=armhf > > DEB_BUILD_ARCH_BITS=32 > > DEB_BUILD_ARCH_CPU=arm > > DEB_BUILD_ARCH_ENDIAN=little > > DEB_BUILD_ARCH_OS=linux > > DEB_BUILD_GNU_CPU=arm > > DEB_BUILD_GNU_SYSTEM=linux-gnueabihf > > DEB_BUILD_GNU_TYPE=arm-linux-gnueabihf > > DEB_BUILD_MULTIARCH=arm-linux-gnueabihf > > DEB_HOST_ARCH=armhf > > DEB_HOST_ARCH_BITS=32 > > DEB_HOST_ARCH_CPU=arm > > DEB_HOST_ARCH_ENDIAN=little > > DEB_HOST_ARCH_OS=linux > > DEB_HOST_GNU_CPU=arm > > DEB_HOST_GNU_SYSTEM=linux-gnueabihf > > DEB_HOST_GNU_TYPE=arm-linux-gnueabihf > > DEB_HOST_MULTIARCH=arm-linux-gnueabihf > > root@letux:/# > > > > So can we safely replace DEB_TARGET_ARCH by DEB_BUILD_ARCH > > in DEB_TARGET_ARCH=$(dpkg-architecture -qDEB_TARGET_ARCH) ? "man dpkg-architecture" says: > DEB_BUILD_ARCH > The Debian architecture of the build machine. and > DEB_TARGET_ARCH > The Debian architecture of the target machine (since dpkg 1.17.14). dpkg version in wheezy is too old: https://packages.debian.org/source/oldoldstable/dpkg If build machine is same architecture as target machine, then you can reuse, else not. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature ___ Community mailing list Community@tinkerphones.org http://lists.goldelico.com/mailman/listinfo.cgi/community http://www.tinkerphones.org
Re: [Tinkerphones] Fwd: [Gta04-owner] QtMoko: a dream comes true :)
Quoting Norayr Chilingarian (2018-02-23 12:28:59) > I would prefer it to be on github. > > Though usually I am the one who supports decentralization, but here are > some arguments: > > * github is a public place, where it is much more probable that your > project can be discovered by the people who potentially can get involved, > even if they did not know about the project before. > > (many different ways - accidentally, or by following your friends' > "likes", or by search, or by other means) Github is "public" in the same sense that a pub or a discoteque is "public": You are welcome as long as you comply with rules of the place. For a pub or a discoteque your dress might not fit their dresscode, or you may not consume enough of their sold beverages. For Github your choice of license might not fit their auto-licensing. > * github stimulates people to fork/make pull requests, this work is > public, and it increases people's social status, when they contribute > to the project on the public place, where it is noticeable by their > community. > > On the contrary, by keeping the separate, even public git tree, the > chances to be discovored and contributed to are much lower. I agree that Github is much more likely to to be discovered: It is called the network effect - and is totally separat from public/private: Your friendships are more likely to be discovered on Facebook which is a similarly "public" place. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature ___ Community mailing list Community@tinkerphones.org http://lists.goldelico.com/mailman/listinfo.cgi/community http://www.tinkerphones.org
Re: [Tinkerphones] Librem 5 news or progress?
Quoting H. Nikolaus Schaller (2017-12-22 08:25:35) > I looked into the Forum and it seems to be very quite inactive to me: > > https://forums.puri.sm/c/librem/phones?order=activity > > Is there a mailing list or some active news blog or irc to follow? News blog: https://puri.sm/news/ - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature ___ Community mailing list Community@tinkerphones.org http://lists.goldelico.com/mailman/listinfo.cgi/community http://www.tinkerphones.org
Re: [Tinkerphones] New tinkerphone gadgets in Goldelico shop?
Quoting j (2017-11-14 18:20:12) > you can get universal battery chargers in Ebay, they are spring loaded > and have charge pins that can be moved side to side to accommodate > most cell phone batteries Possibly, but the subthread you replied to was about FST-01 which need not accomodate any cell phone batteries ;-) - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private ___ Community mailing list Community@tinkerphones.org http://lists.goldelico.com/mailman/listinfo.cgi/community http://www.tinkerphones.org
Re: [Tinkerphones] New tinkerphone gadgets in Goldelico shop?
Quoting H. Nikolaus Schaller (2017-11-14 17:37:27) > Am 13.11.2017 um 12:05 schrieb Jonas Smedegaard : >> Quoting H. Nikolaus Schaller (2017-11-13 11:38:07) >>> Hm. I wonder if we can build/design one with multiple plugs so that >>> one-fits-all. >> >> Uhm, I withdraw my promise to buy one, until I understand if it is >> gonna be a frankenstein model: I would want something sensible to >> survive carrying in a pocket (and the pocket surviving that too). > > It looks as if the thing can be designed for three different positions > for different USB connectors. The standard USB at one end, the µUSB at > the other and the Mini-USB (GTA04) perpendicular to the board surface > so that it does not stick much away from the GTA04 body. It is like I > already do it for the Qi-Charger. > > There is no need to install them all three in parallel, so you won't > see the "Frankenstein" :) You just get the same PCB and controller > chip. Ah, understood. Sounds good! To me, "Frankenstein" means "things sticking out oddly" - so gaping holes for things that _can_ stick out is indeed not, and bonus points if covered up to not be "gaping" :-) > I am also now thinking about placing components on both sides of the > PCB to make it smaller than the original FST-01. This is a little more > tricky for production, but if we build batches of let's say 10 or 12 > it doesn't really matter. I would appreciate a more compact design, even if adding a bit to production costs (or waiting a bit longer for a larger batch to queue up). - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private ___ Community mailing list Community@tinkerphones.org http://lists.goldelico.com/mailman/listinfo.cgi/community http://www.tinkerphones.org
Re: [Tinkerphones] New tinkerphone gadgets in Goldelico shop?
Quoting H. Nikolaus Schaller (2017-11-13 11:38:07) > > > Am 13.11.2017 um 11:31 schrieb Jonas Smedegaard : > > > > Quoting H. Nikolaus Schaller (2017-11-13 08:33:45) > >> Am 04.11.2017 um 22:17 schrieb Niels : > >>> I have been wanting a FST-01 for a while, but not found any place to > >>> buy one. > >> > >> I have studied the schematics and it will take less than 1 day to > >> prepare for producing some clone... > >> > >> Cost is also reasonable, e.g. something below 30€ seems feasible for > >> tiny quantities (if produced in batches of 10). So it is possible to > >> provide permanent supply. > >> > >> What I understood is that it needs some flashing tool to be connected > >> to a jumper. Maybe someone can elaborate this. > >> > >> One thing is to be discussed about the USB interface: > >> > >> Should we keep the USB-A plug or try to replace it by an Mini-USB-A so > >> that it can be directly plugged into a GTA0x? > >> > >> Or even 3 variants with Standard-USB, MiniUSB and µUSB? Or does > >> someone have an idea if multiple sockets are feasible? > > > > I would buy a microUSB model if made - and I believe it could be made to > > work with standard Android for those using F-droid, and therefore have > > potential users among those too. > > Ah, yes. Many Android devices have an µUSB OTG port. > > Hm. I wonder if we can build/design one with multiple plugs so that > one-fits-all. Uhm, I withdraw my promise to buy one, until I understand if it is gonna be a frankenstein model: I would want something sensible to survive carrying in a pocket (and the pocket surviving that too). - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private ___ Community mailing list Community@tinkerphones.org http://lists.goldelico.com/mailman/listinfo.cgi/community http://www.tinkerphones.org
Re: [Tinkerphones] New tinkerphone gadgets in Goldelico shop?
Quoting H. Nikolaus Schaller (2017-11-13 08:33:45) > Am 04.11.2017 um 22:17 schrieb Niels : >> I have been wanting a FST-01 for a while, but not found any place to >> buy one. > > I have studied the schematics and it will take less than 1 day to > prepare for producing some clone... > > Cost is also reasonable, e.g. something below 30€ seems feasible for > tiny quantities (if produced in batches of 10). So it is possible to > provide permanent supply. > > What I understood is that it needs some flashing tool to be connected > to a jumper. Maybe someone can elaborate this. > > One thing is to be discussed about the USB interface: > > Should we keep the USB-A plug or try to replace it by an Mini-USB-A so > that it can be directly plugged into a GTA0x? > > Or even 3 variants with Standard-USB, MiniUSB and µUSB? Or does > someone have an idea if multiple sockets are feasible? I would buy a microUSB model if made - and I believe it could be made to work with standard Android for those using F-droid, and therefore have potential users among those too. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private ___ Community mailing list Community@tinkerphones.org http://lists.goldelico.com/mailman/listinfo.cgi/community http://www.tinkerphones.org
Re: [Tinkerphones] Antwort: Re: Antwort: Re: Librem 5
Quoting H. Nikolaus Schaller (2017-11-07 14:47:42) > It is less money compared to the budget Purism now has. 2 Mio USD... > We just would need to convince them to help to finish the GTA04A5... > It would be just 1% for them. > > Of course we must define what the benefit for Purism would be. > Hm. For example, they could go into the annals of open source as the > hero who rescued the GTA04A5 project to build on it. A possible incentive for Purism might be if GTA04A5 could deliver fast. The fate of Librem 5 hangs on multiple (arguably thin) threads, one of which being existence of Phone-oriented software for Mainline linux, and if geeks had access *soon* to a tinkerphone, that would likely boost developer time poured into KDE and GNOME and Enlightenment and other efforts in supporting Phone environments. Can you try estimate a timeframe of realizing GTA04A5, from the moment money is magically no longer an issue? - Jonas P.S. I am hired by Purism, but do not represent them here (expect me to very explicitly state so if I ever get the priviledge of representing Purism or any other corporation). -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private ___ Community mailing list Community@tinkerphones.org http://lists.goldelico.com/mailman/listinfo.cgi/community http://www.tinkerphones.org
Re: [Tinkerphones] [Gta04-owner] QtMoko2 again...
Quoting H. Nikolaus Schaller (2017-10-26 07:05:10) >> Am 25.10.2017 um 19:32 schrieb Jonas Smedegaard : >> Quoting H. Nikolaus Schaller (2017-10-25 17:44:50) >>> Back to the original problem: I had not expected that there is a >>> need for a configure-make-install. Since we are fully Debian. >> >> How do you mean configure-build-install isn't needed? QtMoko is >> compiled code, so will need to be compiled. > > Indeed. > > But you shouldn't have to to type configure & make to start the > dpkg-buildpackage wrapped by a makefile. > > The dpkg-buildpackage of course must do a configure & make for the > source tree, but hide that from the user. > > IMHO, something is done here upside down. > > My initial mistake was to assume that I can directly call > dpkg-buildpackage after unpacking the source tree. It turned out that > this does not work. At least not without modifications. If you expect source to be a Debian source package¹ then I agree it must be be buildable by a) simply unpacking it (dpkg-source -x *.dsc), b) cd into root of unpacked source tree, and c) build it (dpkg-buildpackage). But a large project involving embedded (likely multiple interlinked) libraries cannot sensibly² be organized as a single(!) Debian source package - each library should be a separate source package, built and tested and packaged and versioned on its own. I thought that your labeling it "upside down" meant that you think it should be adjusted to be able to compile with a single dpkg-buildpackage call. I disagree with that: I believe that the sensible way to turn such a set of essentially multiple sources is to unentangle those into multiple Debian source packages and build each of those separately. If untentangling into multiple Debian source packages was also what you talk about I do believe that untentangling into multiple Debian source packages is what Joshua intend to (eventually, when better understood) reach at. If that is also what you are talking about above, then I simply suggest to not label it as "upside down" which can be misunderstood as the _build_ routines_ need fixing when really it is more fundamentally the _source organization_ which need fixing (too). A more descriptive labeling would in my opinion be "a big mess". ¹ Source format "1.0" is upstream tarball + Debian diff + dsc file, and source format "3.0 (quilt)" is upstream tarball + Debian tarball + dsc file. ² Indeed, Chromium is *not* a sensibly organized source package! >>> It should even be possible to use apt-source -b - if we have proper >>> source packages. So it looks as if the build architecture of QtMoko >>> is upside down... >>> >>> Maybe it is historical since this is still Squeeze and Wheezy code >>> and multiarch wasn't complete back then. On Jessie or Stretch I >>> think it could be much simpler if the debian/rules are updated. >> >> I believe the reason QtMoko build routines fit badly with Debian >> style of packaging is that it does not use existing shared Qt >> libraries but instead embeds its own fork of Qt optimized for >> embedded devices: https://en.wikipedia.org/wiki/Qt_Extended > > It could be a renowned Debian citizen if it would not embed it but > just package and provide the special QtE libraries and then just use > the -dev version for dpkg-building the launcher, dialer, etc. This is > what Josua is working on: > > http://git.goldelico.com/?p=qtmoko2-qte.git;a=summary I guess that this: "if it would not embed it" expands to this: "if QtMoko project would not embed QtE libraries" and then we agree - except for the word "just": Joshua reports that there are trouble unentangling them because their interdependency seems to form a circular graph. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private ___ Community mailing list Community@tinkerphones.org http://lists.goldelico.com/mailman/listinfo.cgi/community http://www.tinkerphones.org
Re: [Tinkerphones] [Gta04-owner] QtMoko2 again...
Quoting H. Nikolaus Schaller (2017-10-25 17:44:50) > Back to the original problem: I had not expected that there is a need > for a configure-make-install. Since we are fully Debian. How do you mean configure-build-install isn't needed? QtMoko is compiled code, so will need to be compiled. > It should even be possible to use apt-source -b - if we have proper > source packages. So it looks as if the build architecture of QtMoko is > upside down... > > Maybe it is historical since this is still Squeeze and Wheezy code and > multiarch wasn't complete back then. On Jessie or Stretch I think it > could be much simpler if the debian/rules are updated. I believe the reason QtMoko build routines fit badly with Debian style of packaging is that it does not use existing shared Qt libraries but instead embeds its own fork of Qt optimized for embedded devices: https://en.wikipedia.org/wiki/Qt_Extended ...but I am a bit puzzled here: I seem to recall you reminding me of that (after Debian developer Paul Wise initially explained it to me, and helped me install QtMoko on one of my GTA02 devices - which I didn't use much because I wanted a *Debian* environment not a "bastard" like that). - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private ___ Community mailing list Community@tinkerphones.org http://lists.goldelico.com/mailman/listinfo.cgi/community http://www.tinkerphones.org
Re: [Tinkerphones] Librem 5
Quoting H. Nikolaus Schaller (2017-10-25 17:57:48) > > > Am 25.10.2017 um 12:11 schrieb Jonas Smedegaard : > > > > Quoting Rainer Dorsch (2017-10-25 10:57:38) > >> On Mittwoch, 25. Oktober 2017 09:55:24 CEST Belisko Marek wrote: > >>> I didn't pledged because I was not aware that such thing exists :) > >> > >> I think you can still preorder... > > > > Correct: Fundraising campaign is formally over, but Librem 5 can still > > be pre-ordered until available for regular sale. > > If we are talking about funding: it is also still possible to donate/fund the > tinkerphones and Letux-OS activities: > > http://shop.goldelico.com/wiki.php?page=Products&category=Project%20Support > > Maybe, this can even be made running on the Librem 5 once it becomes > available. To have even more alternatives to what is already promised. Thanks for pointing that out. I am aware that you are still actively developing, and that funding for your work is obviously always helpful, but... My impression, looking at the URL you provide here just above, is that paying money there doesn't get me a gadget - as it (maybe eventually) does paying money to Librem 5 or GTA04 fundraising. If I am mistaken and geeks wanting to sponsor your work while getting something tangible in return can do so at above URL, then I suggest you consider clarifying that. I would love for you to attract more support! - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private ___ Community mailing list Community@tinkerphones.org http://lists.goldelico.com/mailman/listinfo.cgi/community http://www.tinkerphones.org
Re: [Tinkerphones] Librem 5
Quoting Rainer Dorsch (2017-10-25 10:57:38) > On Mittwoch, 25. Oktober 2017 09:55:24 CEST Belisko Marek wrote: > > I didn't pledged because I was not aware that such thing exists :) > > I think you can still preorder... Correct: Fundraising campaign is formally over, but Librem 5 can still be pre-ordered until available for regular sale. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private ___ Community mailing list Community@tinkerphones.org http://lists.goldelico.com/mailman/listinfo.cgi/community http://www.tinkerphones.org
Re: [Tinkerphones] Librem 5
Quoting W. Martin Borgert (2017-10-24 22:43:57) > On 2017-10-24 19:09, H. Nikolaus Schaller wrote: > > Anyone here on this list who pledged for one? > > I pledged for the developer board, because I want to be sure, > that "my" Debian packages will run fine on it. Also, I will try > to use it as a landline SIP phone and XMPP terminal. > > Still, as a mobile device, I find other devices more interesting > than Librem 5. E.g. ZeroPhone, because it is cheap and simple or > Pyra, because it has a nice keyboard. > > A very good thing about Librem 5 is, IMHO, that it has the > potential to boost Linux on mobile devices in general. All other > "non-Android-Linux" devices will benefit from it. Well put, Martin! I think I already mentioned here, but in any case: Since 4 months now I am hired by Purism to help maintain their Debian-based software stack. Purism aims for high-end devices, and I still see a potential for more "raw" devices - cheaper and clunkier. Some find a $1400 Librem laptop appealing but others prefer a €240 TERES-1 laptop. I bet it is similar for phones! - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private ___ Community mailing list Community@tinkerphones.org http://lists.goldelico.com/mailman/listinfo.cgi/community http://www.tinkerphones.org
Re: [Tinkerphones] [Gta04-owner] Towards QtMoko2: building QtMoko from sources
Quoting H. Nikolaus Schaller (2017-06-04 11:41:19) > Am 04.06.2017 um 10:17 schrieb Jonas Smedegaard : >> Please read http://deb.jones.dk/ and tell me which parts of that is >> flawed or superfluous or wrong in other ways. > > That is a nice blueprint of exactly what I need and how it should be > done! > > If I get it right (just from reading and guessing what it does) it > assumes that your key is stored in debian-keyring. Correct: My instruction is simpler than yours can be: Users of Debian already implicitly trust the _identities_ of all Debian members (but trust only _releases_ signed by special release keys). I can therefore suggest users to establish a trust path by finding my key among the keys they already trust. You could instead suggest users to establish a trust path by finding my key among the keys they already trust, and then finding your key among signatures made by me. > And this requires that you are trusted by the maintainers of > debian-keyring. debian-keyring *only* contains keys from within Debian. > Then you can declare that you are trusted and others can verify before > taking your word only. you can declare all you want - that won't change anything, as you have no power over the users system. Yet... ;-) The _user_ can declare that package releases done (not only by Debian officially, but also) independently by you should be trusted. > But how does your key get into debian-keyring? By joining Debian. There is no other way for that specifically, so you need to adapt instructions to other means of establishing your identity. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature ___ Community mailing list Community@tinkerphones.org http://lists.goldelico.com/mailman/listinfo.cgi/community http://www.tinkerphones.org
Re: [Tinkerphones] [Gta04-owner] Towards QtMoko2: building QtMoko from sources
Quoting Roland Häder (2017-06-03 22:12:23) > Do not bypass secrurity! Better is to get it properly signed. Yes, establishing a trust path (which includes offering signed package release files but also other parts) are better than not doing so. Maintained packages are even better - e.g. collectively by Debian. > You should then provide the GPG public key (obviously) on your website > so people can use it for verification the apt-key-common way: > > gpg --keyserver pgpkeys.mit.edu --recv-key xx > gpg -a --export xx | sudo apt-key add - Above verifies only that the signing key exist on that public keyserver - it does not establish a trust path and is therefore not (on its own) trustworthy. Please read http://deb.jones.dk/ and tell me which parts of that is flawed or superfluous or wrong in other ways. > by xx is the long key id (don't encourage, short keys, they are > flawed as malicous people can theoretical craft a pgp key that has the > same (!) short key, like it already happened with Linus Torwalds' key. Yes, do that and also a range of other best practices: https://help.riseup.net/en/security/message-security/openpgp/best-practices - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature ___ Community mailing list Community@tinkerphones.org http://lists.goldelico.com/mailman/listinfo.cgi/community http://www.tinkerphones.org
Re: [Tinkerphones] Towards QtMoko2: building QtMoko from sources
Quoting H. Nikolaus Schaller (2017-06-03 20:46:16) >> Am 03.06.2017 um 19:38 schrieb Jonas Smedegaard : >> Quoting H. Nikolaus Schaller (2017-06-03 18:18:49) >>> b) add to /etc/apt/sources.list >>> >>>deb http://www.qtmoko.net/download/ wheezy main >>>deb-src http://www.qtmoko.net/download/ wheezy main >> [...] >>> Well, there are still some limitations I want to work on in the next >>> weeks: >>> * the repository has no GPG signatures so one has to work around >>> apt-get security complaints >> >> Simplest is probably to instead use these APT lines: >> >>deb [ trusted=yes ] http://www.qtmoko.net/download/ wheezy main >>deb-src [ trusted=yes ] http://www.qtmoko.net/download/ wheezy main > > Simplest for the user. No, simplest for the package maintainer - i.e. for you. Simplest for the user is to have the packages officially part of Debian. > Maybe I should learn how to GPG sign packages and the repository... > Probably the biggest issue is that I need a certificate that is > accepted by the Debian key ring. Only packages officially included with Debian get certified by Debian. You are quite welcome: https://www.debian.org/devel/join/ To release non-Debian .deb packages with some (lesser) degree of security, you will need to a) setup routines to sign your release files each time you add, update, or remove a package to your package pool, and b) offer a way for your users to validate that security - i.e. establish a trust path. For a) the most common way is to use the tool reprepro. For b) a common approach is to put public part of your signing keypair in a package of its own and tell your users to simply install that first - but I consider that approach flawed: You then basically ask your users to _insecurely_ grant you root access to each of their systems for that initial magic security package which (hopefully does nothing else than) add your certificate to on their system. My alternative is an inelegant but more trustworthy instruction at http://deb.jones.dk/ - since I have signed your key you could make a similar but slightly more involved instruction for a key you control. If anyone has ideas for a more user-friendly yet trustworthy approach to establishing a trust path to an unofficial .deb package pool, please do share. I am certainly also interested to hear if anyone consider my approach flawed in some way. >>> * compilation is still slow despite ccache. I should try the 200GB >>> card on a Pyra or OMAP5432EVM as soon as there becomes one available >>> for running in background >> >> Another option is to compile on an ARM device with SATA interface and >> more memory. > > Yes, the Pyra and OMAP5EVM have both (2-4GB RAM, 8-16 times as fast > CPU and SATA interface). But I still need one that is not too often > needed for something else. And, the only spare SATA hard disk I have > is broken... > > So maybe someone with suche a machine can pick up my work and report > results. My point was that any device supporting the same ARM sub-architecture (ARMv5 a.k.a. Debian "armel", or ARMv7 a.k.a. Debian "armhf") is fine - for those of us without powerful OMAP devices to spare for several days. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature ___ Community mailing list Community@tinkerphones.org http://lists.goldelico.com/mailman/listinfo.cgi/community http://www.tinkerphones.org
Re: [Tinkerphones] Towards QtMoko2: building QtMoko from sources
Quoting H. Nikolaus Schaller (2017-06-03 18:18:49) > b) add to /etc/apt/sources.list > > deb http://www.qtmoko.net/download/ wheezy main > deb-src http://www.qtmoko.net/download/ wheezy main [...] > Well, there are still some limitations I want to work on in the next weeks: > * the repository has no GPG signatures so one has to work around > apt-get security complaints Simplest is probably to instead use these APT lines: deb [ trusted=yes ] http://www.qtmoko.net/download/ wheezy main deb-src [ trusted=yes ] http://www.qtmoko.net/download/ wheezy main > * compilation is still slow despite ccache. I should try the 200GB > card on a Pyra or OMAP5432EVM as soon as there becomes one available > for running in background Another option is to compile on an ARM device with SATA interface and more memory. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature ___ Community mailing list Community@tinkerphones.org http://lists.goldelico.com/mailman/listinfo.cgi/community http://www.tinkerphones.org
Re: [Tinkerphones] [Letux-kernel] default for Debian /etc/network/interfaces
Quoting H. Nikolaus Schaller (2017-02-24 13:30:52) > Am 24.02.2017 um 11:16 schrieb Jonas Smedegaard : >> ifupdown is no longer the default: netbase 5.4 (released 2 months ago) >> stopped recommending it. [...] > I have checked what my simple debootstrap does and it seems to install > ifupdown by default for wheezy, jessie and stretch. So it appears to > belong to the core packages. Sounds like you checked that ifupdown _either_ is core _or_ got pulled in by your package selection. If your system rely on features of a specific (non-core) package, then make sure to explicitly depend on that package, because indirect dependencies may change over time! - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature ___ Community mailing list Community@tinkerphones.org http://lists.goldelico.com/mailman/listinfo.cgi/community http://www.tinkerphones.org
Re: [Tinkerphones] default for Debian /etc/network/interfaces
Quoting H. Nikolaus Schaller (2017-02-24 08:05:58) > Am 23.02.2017 um 22:49 schrieb H. Nikolaus Schaller > : >> So there is a fresh /e/n/i and /e/n/i.d created and it is set up to >> source the /e/n/i.d >> >> That is fine and like I hoped! So we can provide letux-usb0 or >> letux-eth0 network configs for single interfaces so that e.g. USB >> networking works out of the box even if you have no GUI. >> >> Next I will check if that is already a feature of Jessie or was >> introduced in Stretch. > > Ok, here is the result: > > - Wheezy only creates /e/n/i with "auto lo" > - Jessie and Stretch both create empty /e/n/i.d and /e/n/i with only > "source-directory /e/n/i.d" Those patterns match some work done in postinst script of ifupdown - applied if the file does not already exist when ifupdown is installed. In the past, debian-installer created a custom file. Not sure if it still does, and if maybe conditional to also installing ifupdown. ifupdown is no longer the default: netbase 5.4 (released 2 months ago) stopped recommending it. > So it was already introduced in Jessie. According to its changelog it was introduced in ifupdown 0.7.44 (2013-08-08). According to its changelog it was wupported in ifupdown2 since its initial release, so should not be a problem if that package (declared as providing and replacing ifupdown) automatically gets installed in a package upgrade. Not sure if netscript-2.4 (also potentially auto-replacing ifupdown) supports the "source-directory" syntax. > Since it is very unlikely that anyone still wants to use Wheezy on the > GTA04 it will work when using the default for /e/n/i and patching > letux interfaces to /e/n/i.d ...as long as ifupdown or ifupdown2 is installed, yes. > Specifically I want to make those interface configs part of the > letux-kernel, so that they are maintained in Letux/etc/network and > kept in sync with kernel interface naming (this sometimes changed in > the past). If you mean that you will include network setup snippets with a custom kernel package, then I recommend that you consider following structuring instead, by maintaining network config as a separate package - e.g. to ease users switching to another kernel package. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature ___ Community mailing list Community@tinkerphones.org http://lists.goldelico.com/mailman/listinfo.cgi/community http://www.tinkerphones.org
Re: [Tinkerphones] default for Debian /etc/network/interfaces
Quoting H. Nikolaus Schaller (2017-02-23 15:51:34) > Hi Jonas, > > > Am 23.02.2017 um 14:33 schrieb Jonas Smedegaard : > > > > Quoting H. Nikolaus Schaller (2017-02-23 13:58:23) > >> Hi Jonas, > >> despite the production issues I am working a little on improving > >> our Debian default rootfs for the GTA04. > >> > >> I just found out recently that there is a rarely known capability > >> to define /etc/network/interfaces.d/* files which can be sourced > >> by the master /e/n/i. > >> > >> This would solve the issue that we do a hard overwrite of /e/n/i > >> to configure the usb0 ethernet gadget and real ethernet on boards > >> which have hardware (BeagleBoard XM, PandaBoard, OMAP5EVM) right > >> after building the debootstrap. > >> > >> Instead, we could just add specific config files for the 2 or 3 > >> interfaces we have in our letux devices with low risk of overwriting > >> anything else. And if they interfere they can easily be removed. > >> > >> But I could not find the default version of /e/n/i installed > >> during debootstrap to check if it really sources the eni.d. > >> Debian Packages search (on the web) shows no package where it is contained. > >> > >> So how is this file created during debootstrap? > > > > I believe debootstrap does *not* create the file /etc/network/interfaces > > - like hosts.conf and a few other core files it need manual creation if > > not using debian-installer. > > Ah, ok. I see. Maybe I have to find out by experiment... It shouldn't be > difficult to debootstrap a new system on the GTA04 (I think I already have > a script for this). > > > > > Also, I believe that file is only used for _some_ networking frameworks. > > > > * ifupdown: uses /e/n/i and /etc/network/interfaces.d/*.d > > * network-manager: briefly checks /e/n/i for interfaces to ignore. > > * connman: possibly ignores /e/n/i completely > > * systemd-networkd: possibly ignores /e/n/i completely > > * ifupdown2: probably uses /e/n/i - claims to replace ifupdown... > > * netscript-2.4: not sure - claims to replace ifupdown... > > * wicd: not sure... > > * waagent: irrelevant for phones... > > Interesting. > > > > > ifupdown was used by default in the past, but no more. > > Well, it looks as if the easy-to-understand packages and functions > are becoming more and more obsolete... The downside of all the > new functions is that they may be better but are worse documented > by google search... I.e. you find a lot of examples for the old > things but rarely a howto or example for the new ones. > > And my main goal is to get a simple working setup which does not > make too many assumptions about GUI capabilities of the device (I > am quite sure that e.g. wicd can't be operated on the small touch > screen). > > Many thanks for this background info! Let's see what to make out > of it. debootstrap is the old tool. What is used in debian installer is cdebootstrap which is slightly different. Another alternative is multistrap (which is what I use currently when not debian installer). What either of these three tools do since many years is unpack a range of core packages and execute their postinst scripts. debian installer (or the gazilion unofficial hacks including your own) then after the core bootstrapping as a minimum adds a range of files not managed by any package. Multistrap mentions that at least(!) these files need custom care: /etc/inittab /etc/fstab /etc/hosts /etc/securetty /etc/modules /etc/hostname /etc/network/interfaces /etc/init.d /etc/dhcp3 That info might be outdated - but it's a start :-) - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature ___ Community mailing list Community@tinkerphones.org http://lists.goldelico.com/mailman/listinfo.cgi/community http://www.tinkerphones.org
Re: [Tinkerphones] default for Debian /etc/network/interfaces
Quoting H. Nikolaus Schaller (2017-02-23 13:58:23) > Hi Jonas, > despite the production issues I am working a little on improving > our Debian default rootfs for the GTA04. > > I just found out recently that there is a rarely known capability > to define /etc/network/interfaces.d/* files which can be sourced > by the master /e/n/i. > > This would solve the issue that we do a hard overwrite of /e/n/i > to configure the usb0 ethernet gadget and real ethernet on boards > which have hardware (BeagleBoard XM, PandaBoard, OMAP5EVM) right > after building the debootstrap. > > Instead, we could just add specific config files for the 2 or 3 > interfaces we have in our letux devices with low risk of overwriting > anything else. And if they interfere they can easily be removed. > > But I could not find the default version of /e/n/i installed > during debootstrap to check if it really sources the eni.d. > Debian Packages search (on the web) shows no package where it is contained. > > So how is this file created during debootstrap? I believe debootstrap does *not* create the file /etc/network/interfaces - like hosts.conf and a few other core files it need manual creation if not using debian-installer. Also, I believe that file is only used for _some_ networking frameworks. * ifupdown: uses /e/n/i and /etc/network/interfaces.d/*.d * network-manager: briefly checks /e/n/i for interfaces to ignore. * connman: possibly ignores /e/n/i completely * systemd-networkd: possibly ignores /e/n/i completely * ifupdown2: probably uses /e/n/i - claims to replace ifupdown... * netscript-2.4: not sure - claims to replace ifupdown... * wicd: not sure... * waagent: irrelevant for phones... ifupdown was used by default in the past, but no more. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature ___ Community mailing list Community@tinkerphones.org http://lists.goldelico.com/mailman/listinfo.cgi/community http://www.tinkerphones.org
Re: [Tinkerphones] GTA04A5: good news and bad news
Quoting H. Nikolaus Schaller (2017-02-23 06:53:03) > Am 23.02.2017 um 00:27 schrieb Jonas Smedegaard : >> Quoting H. Nikolaus Schaller (2017-02-22 17:55:30) >>> Am 22.02.2017 um 17:08 schrieb Paul Boddie : >>>> Personally, I think some flexibility about the SoC would be >>>> acceptable for Neo900, but I'm not invested in Maemo at all and >>>> have backed that project because of the form factor, open hardware >>>> aspects, and Free Software support. >>> >>> Me too. The issue is what the alternatives really are. Due to space >>> constraints it must be small chips. And PoP is the technology of >>> first choice. Not many hacker friendly ARM SoC are available as PoP. >>> >>> Snapdragon: would be fine, but unobtainable in small quantities. >>> Mediatek: afaik the same >>> RockChip: I don't know if they have PoP mobile chips >>> Allwinner: AFAIK no PoP and not power optimized for mobile operation >>> Apple A10: unobtainable >>> Exynos: AFAIK not well supported >>> >>> So TI did alway have the best support for the open/free >>> soft/hardware community (except the IMG PVR SGX). Hence the DM3730 >>> would still be a very good choice. >> >> What numbers are "power optimized for mobile operation"? > > The GTA04A5 seems to be able to reach <30mA in suspend to RAM which is > ca. 100mW. This gives only 40 hours of standby time which is still > less than other devices (which have up to 100 or 400 hours). > >> >> Relatively recent power reduction experiments for Allwinner H3 >> boards: >> https://forum.armbian.com/index.php/topic/1614-running-h3-boards-with-minimal-consumption/ >> >> Even if the numbers for H3 boards are way off, the methods used might >> still be interesting. > > "I find it already pretty nice to be able to limit consumption down to 160mA > (800mW) by disabling 3 CPU cores " > > That is almost more than the GTA04 needs in full operation. Thanks for the numbers (100mW idle and 800mW max). Please note that same author reached 400mW in other posts, and repeatedly emphasize the need for others with more accurate measuring equipment to explore further. > The key is a SoC that has been designed for power optimization. Ok. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature ___ Community mailing list Community@tinkerphones.org http://lists.goldelico.com/mailman/listinfo.cgi/community http://www.tinkerphones.org
Re: [Tinkerphones] GTA04A5: good news and bad news
Quoting H. Nikolaus Schaller (2017-02-22 17:55:30) > Am 22.02.2017 um 17:08 schrieb Paul Boddie : >> Personally, I think some flexibility about the SoC would be >> acceptable for Neo900, but I'm not invested in Maemo at all and have >> backed that project because of the form factor, open hardware >> aspects, and Free Software support. > > Me too. The issue is what the alternatives really are. Due to space > constraints it must be small chips. And PoP is the technology of first > choice. Not many hacker friendly ARM SoC are available as PoP. > > Snapdragon: would be fine, but unobtainable in small quantities. > Mediatek: afaik the same > RockChip: I don't know if they have PoP mobile chips > Allwinner: AFAIK no PoP and not power optimized for mobile operation > Apple A10: unobtainable > Exynos: AFAIK not well supported > > So TI did alway have the best support for the open/free soft/hardware > community (except the IMG PVR SGX). Hence the DM3730 would still be a > very good choice. What numbers are "power optimized for mobile operation"? Relatively recent power reduction experiments for Allwinner H3 boards: https://forum.armbian.com/index.php/topic/1614-running-h3-boards-with-minimal-consumption/ Even if the numbers for H3 boards are way off, the methods used might still be interesting. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature ___ Community mailing list Community@tinkerphones.org http://lists.goldelico.com/mailman/listinfo.cgi/community http://www.tinkerphones.org
