From lkcl at lkcl.net Mon Jul 3 08:52:59 2017 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Mon, 3 Jul 2017 08:52:59 +0100 Subject: [Arm-netbook] severe systemd bugs (two of them) Message-ID: https://it.slashdot.org/story/17/07/03/0343258/severe-systemd-bug-allowed-remote-code-execution-for-two-years two years. that's how long one of these bugs has been in systemd. *via a remote network*. what the hell is an init system doing being accessible *via DNS queries*? for anyone who still believes that systemd is okay to use and deploy, and that there exist "great advantages that outweigh the risks", are you *finally* getting the message now? dozens of distros, millions of people, all affected by the irresponsible act of switching "en-masse" to a single over-reaching init system which is developed in a fashion that is not being properly managed or controlled. i do not understand why people do not understand this. l. From phil at hands.com Mon Jul 3 09:26:51 2017 From: phil at hands.com (Philip Hands) Date: Mon, 03 Jul 2017 10:26:51 +0200 Subject: [Arm-netbook] severe systemd bugs (two of them) In-Reply-To: References: Message-ID: <87a84mj584.fsf@whist.hands.com> Luke Kenneth Casson Leighton writes: > https://it.slashdot.org/story/17/07/03/0343258/severe-systemd-bug-allowed-remote-code-execution-for-two-years > > two years. that's how long one of these bugs has been in systemd. > *via a remote network*. what the hell is an init system doing being > accessible *via DNS queries*? If you read the summary of the article to the second line, you'll note that it is talking about 'systemd-resolved' -- so not the init at all. Yes, I know that it was stupid to call all these disparate bits of the SystemD project systemd-$whatever, becuase it's just asking for people to do what you just did, but I really expect _you_ to understand that there is more than one executable involved in systemd, and that not all of them can possibly run as process 1, all at once. On my fairly default stretch laptop, systemd-resolved is not running. On free.hands.com, to which you have access, it is also not running. So, to answer your qustion, well, it isn't ... obviously. Might I ask in response: What the hell are you doing not fact checking this before repeating it? It's not as though this is the first time that an anti-systemd story has been spun to the point of becoming nonsense. I'd imagine that this has managed to go undetected for so long because most people have no interest in running this program on anything but containers (which is what it's for AFAIK) and that anyone sensible is firewalling those containers to make sure that the only DNS server they talk to is the one they control that is running on the physical host. Cheers, Phil. -- |)| Philip Hands [+44 (0)20 8530 9560] HANDS.COM Ltd. |-| http://www.hands.com/ http://ftp.uk.debian.org/ |(| Hugo-Klemm-Strasse 34, 21075 Hamburg, GERMANY From lkcl at lkcl.net Mon Jul 3 09:40:06 2017 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Mon, 3 Jul 2017 09:40:06 +0100 Subject: [Arm-netbook] severe systemd bugs (two of them) In-Reply-To: <87a84mj584.fsf@whist.hands.com> References: <87a84mj584.fsf@whist.hands.com> Message-ID: On Mon, Jul 3, 2017 at 9:26 AM, Philip Hands wrote: > Might I ask in response: What the hell are you doing not fact checking > this before repeating it? because in the scheme of programs-that-constitute-systemd it really doesn't matter, phil. the slashdot report also includes a link to this second discovered flaw: https://ma.ttias.be/giving-perspective-systemds-usernames-start-digit-get-root-privileges-bug/ once those have been fixed, there will be more severe bugs discovered. and after those, yet more discovered. it's never going to end... and that's just the security aspect. the situation before systemd was that we had quotes imperfect quotes disparate programs that were managed by completely different teams. the actual init system(s) that used those programs did not "develop" significantly because... basically they did not *need* actual development. now we have the most dangerous situation where power is concentrated into the hands of a few *known* irresponsible developers who simply *do not know when to stop*. i cannot think of anything more dangerous to the entire software libre eco-system than 98% of GNU/Linux distros having abdicated power and responsibility into the hands of lennart pottering and his team. l. From vkontogpls at gmail.com Mon Jul 3 09:47:32 2017 From: vkontogpls at gmail.com (Bill Kontos) Date: Mon, 3 Jul 2017 11:47:32 +0300 Subject: [Arm-netbook] severe systemd bugs (two of them) In-Reply-To: References: Message-ID: On Mon, Jul 3, 2017 at 10:52 AM, Luke Kenneth Casson Leighton wrote: > for anyone who still believes that systemd is okay to use and deploy, > and that there exist "great advantages that outweigh the risks", are > you *finally* getting the message now? Because the only distro that uses systemd-resolved by default is ubuntu. Nobody else has been affected by this. Have you ever wondered why we see the kernel everywhere but every other part of the desktop stack is irrelevant outside the desktop users ? Because there is too much variance. And yet people keep breaking abis and support the idea of multiple inits that do the same thing in slightly different ways requiring the maintenance of multiple init scripts over and over again. From lkcl at lkcl.net Mon Jul 3 10:06:06 2017 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Mon, 3 Jul 2017 10:06:06 +0100 Subject: [Arm-netbook] severe systemd bugs (two of them) In-Reply-To: References: Message-ID: On Mon, Jul 3, 2017 at 9:47 AM, Bill Kontos wrote: > much variance. And yet people keep breaking abis and support the idea > of multiple inits that do the same thing in slightly different ways > requiring the maintenance of multiple init scripts over and over > again. when i was looking at taking over maintenance of depinit one of the first tasks was to add full automated compatibility for initscripts. signiicant advantages of depinit were lost in the process but there was no loss when compared to sysvinit itself. individual initscripts could then be replaced to provide a much better way of handling services (safe_mysqld for example could be dispensed with entirely). even with that in mind i see no down-side to the additional workload that you refer to when you consider the upside that diversity brings. no monoculture, no centralised control, and a need for people managing *different* projects - the components that systemd has [irresponsibly] made quotes redundant quotes - to communicate, discuss and agree interoperable standards. the abdication of responsibility by all distros has taken away the opportunity for diverse and disparate teams to work together, shunting aside all the safeguards that are normally in place and allowing lennart pottering and his team to arbitrarily and unilaterally decide how GNU/Linux should work. this, then, primarily is what i do not understand that people do not understand. l. From phil at hands.com Mon Jul 3 10:06:31 2017 From: phil at hands.com (Philip Hands) Date: Mon, 03 Jul 2017 11:06:31 +0200 Subject: [Arm-netbook] severe systemd bugs (two of them) In-Reply-To: References: <87a84mj584.fsf@whist.hands.com> Message-ID: <8737adkhyg.fsf@whist.hands.com> Luke Kenneth Casson Leighton writes: > On Mon, Jul 3, 2017 at 9:26 AM, Philip Hands wrote: > >> Might I ask in response: What the hell are you doing not fact checking >> this before repeating it? > > because in the scheme of programs-that-constitute-systemd it really > doesn't matter, phil. ... Are you aware of confirmation bias? Might I recommend this book to you: http://www.pinterandmartin.com/irrationality.html (I see there's a new edition, which I've just ordered as the update is almost certainly as interesting as the original. So, thanks for giving me a reason for looking up the canonical URL -- I look forward to re-reading it :-) ) Cheers, Phil. -- |)| Philip Hands [+44 (0)20 8530 9560] HANDS.COM Ltd. |-| http://www.hands.com/ http://ftp.uk.debian.org/ |(| Hugo-Klemm-Strasse 34, 21075 Hamburg, GERMANY From lkcl at lkcl.net Mon Jul 3 10:17:53 2017 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Mon, 3 Jul 2017 10:17:53 +0100 Subject: [Arm-netbook] severe systemd bugs (two of them) In-Reply-To: <8737adkhyg.fsf@whist.hands.com> References: <87a84mj584.fsf@whist.hands.com> <8737adkhyg.fsf@whist.hands.com> Message-ID: On Mon, Jul 3, 2017 at 10:06 AM, Philip Hands wrote: > Are you aware of confirmation bias? you're talking to a reverse-engineer, so you know that i am. the problem is that there are so many different "signs" from so many different directions that it becomes completely overwhelming to enumerate them all, track them all down, and describe them all. but, worse than that, if i *was* to enumerate them all there would be not a single person on the planet willing to read everything that i wrote. more than that, it would take such a long time that i would run out of patience well before i completed any such "report". this is a *systemic* problem, phil. the actual source code - and the flaws *in* that source code - are merely symptoms of an underlying "illness" within the software libre community that has absolutely nothing to do with technical mastery. remember, you're talking to someone who notices far more than they can actually describe in words, who takes in sparse and disparate information from a huge array of sources (and draws correct conclusions that other people simply cannot achieve... or, unfortunately, accept). we can get hung up on the details if you like, but that will not help (at all). l. From vkontogpls at gmail.com Mon Jul 3 10:19:49 2017 From: vkontogpls at gmail.com (Bill Kontos) Date: Mon, 3 Jul 2017 12:19:49 +0300 Subject: [Arm-netbook] severe systemd bugs (two of them) In-Reply-To: References: Message-ID: On Mon, Jul 3, 2017 at 12:06 PM, Luke Kenneth Casson Leighton wrote: > even with that in mind i see no down-side to the additional workload > that you refer to when you consider the upside that diversity brings. > no monoculture, no centralised control, and a need for people managing > *different* projects - the components that systemd has [irresponsibly] > made quotes redundant quotes - to communicate, discuss and agree > interoperable standards. Because it adds cost technical debt blah blah blah and it is one of the many reasons as to why applications in gnu/linux systems break all the time when the maintainer drops them. But I completely disagree with the idea that adding more people to the mix when they are not needed is a good thing. It is the fate of everything IT related to eventually be automated or made redundant and for people to move on to the next thing. That's just how it is. It used to be office suits being ported to multiple architectures in the 80s, it's init systems now. The problem I see with those criticizing systemd is that the vast majority of them do not even try to make something better that retains the features that make systemd valuable. Instead they just make a distro where they purge anything that has systemd in it's name even when it's a dummy package so packages who expect systemd but can't find it will work. Also I don't consider going from a variety of options each with it's disadvantages to a single option essentially standardizing it a bad thing. It's just a lost opportunity to make a real standard for sure, but I don't think that's monoculture. From auerswal at unix-ag.uni-kl.de Mon Jul 3 11:00:48 2017 From: auerswal at unix-ag.uni-kl.de (Erik Auerswald) Date: Mon, 3 Jul 2017 12:00:48 +0200 Subject: [Arm-netbook] severe systemd bugs (two of them) In-Reply-To: <87a84mj584.fsf@whist.hands.com> References: <87a84mj584.fsf@whist.hands.com> Message-ID: <20170703100048.GA1867@unix-ag.uni-kl.de> Hi, On Mon, Jul 03, 2017 at 10:26:51AM +0200, Philip Hands wrote: > Luke Kenneth Casson Leighton writes: > > > https://it.slashdot.org/story/17/07/03/0343258/severe-systemd-bug-allowed-remote-code-execution-for-two-years > > > > two years. that's how long one of these bugs has been in systemd. > > *via a remote network*. what the hell is an init system doing being > > accessible *via DNS queries*? > > If you read the summary of the article to the second line, you'll note > that it is talking about 'systemd-resolved' -- so not the init at all. > > Yes, I know that it was stupid to call all these disparate bits of the > SystemD project systemd-$whatever, becuase it's just asking for people > to do what you just did, but I really expect _you_ to understand that > there is more than one executable involved in systemd, and that not all > of them can possibly run as process 1, all at once. An init system comprises many processes. System V init e.g. uses shell scripts to start services. The whole system is called System V init. Systemd is supposed to replace the complete init system, not just the process with PID 1. In addition, it adds lots of other functionality (DNS resolver, DCHP client, network configuration, desktop session management, ...), all of which existed and worked before the systemd replacements. Thanks, Erik -- If it ain't broke, don't fix it. From lkcl at lkcl.net Mon Jul 3 12:02:45 2017 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Mon, 3 Jul 2017 12:02:45 +0100 Subject: [Arm-netbook] severe systemd bugs (two of them) In-Reply-To: <20170703100048.GA1867@unix-ag.uni-kl.de> References: <87a84mj584.fsf@whist.hands.com> <20170703100048.GA1867@unix-ag.uni-kl.de> Message-ID: On Mon, Jul 3, 2017 at 11:00 AM, Erik Auerswald wrote: > Systemd is supposed to replace the complete init system, not just the > process with PID 1. In addition, it adds lots of other functionality (DNS > resolver, DCHP client, network configuration, desktop session management, > ...), all of which existed and worked before the systemd replacements. .. and which have now been replaced by a monoculture which is focussed specifically on one OS (GNU/Linux), on one GNU/Linux distro (redhat), on one *type* of distro (redhat desktops), on one *desktop* (redhat gnome desktop), with *ZERO* wider consultation with other teams as to what they might want or need. there has even been talk that FreeBSD and so on *MUST* convert over to systemd and associated fascist-developed support infrastructure "because that's how it's done, now". and if they do not, then, well, to hell with them: they can go bit-rot in hell as far as the supporters of systemd are concerned. all of which illustrates that it's not about the code, it's not about the quality of the code, it's the entire attitude and the over-concentration of power into the hands of such a small and highly irresponsible team. and the fact that the distros are either complicit with this or are completely blind to how dangerous this situation really is to the health of the software libre community as a whole. l. From lkcl at lkcl.net Mon Jul 3 12:05:59 2017 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Mon, 3 Jul 2017 12:05:59 +0100 Subject: [Arm-netbook] severe systemd bugs (two of them) In-Reply-To: References: Message-ID: On Mon, Jul 3, 2017 at 10:19 AM, Bill Kontos wrote: > Also I don't consider going from a variety of options each with it's > disadvantages to a single option essentially standardizing it a bad > thing. It's just a lost opportunity to make a real standard for sure, > but I don't think that's monoculture. it's the very definition of a monoculture, bill. a standard has multiple implementations: full documentation, stable APIs, a reference design plus alternative implementations (and/or people willing *to* implement alternative implementations). where is the standard fully documented? where is the definition of the stable APIs which have been set as "gold" and not subject to change for the next 10-20 years? where is the reference design (with associated proper documentation)? where are the alternative implementations? l. From silverskullpsu at gmail.com Mon Jul 3 15:00:41 2017 From: silverskullpsu at gmail.com (Jonathan Frederickson) Date: Mon, 3 Jul 2017 10:00:41 -0400 Subject: [Arm-netbook] severe systemd bugs (two of them) In-Reply-To: References: <87a84mj584.fsf@whist.hands.com> Message-ID: On Mon, Jul 3, 2017 at 4:40 AM, Luke Kenneth Casson Leighton wrote: > the situation before systemd was that we had quotes imperfect quotes > disparate programs that were managed by completely different teams. > the actual init system(s) that used those programs did not "develop" > significantly because... basically they did not *need* actual > development. > > now we have the most dangerous situation where power is concentrated > into the hands of a few *known* irresponsible developers who simply > *do not know when to stop*. But we still have that situation. As Phil said, systemd-resolved is not used by default on (at least) Debian Stretch, and from the sound of things it's not used on most other distros either. The systemd developers wrote a local caching resolver daemon, and distros can either choose to use it, or not. You can still use dnsmasq, or not have a caching resolver at all, or... etc. There's nothing stopping you! It's true that the systemd developers have also written replacements for existing software that *have* been widely adopted, notably systemd-logind in favor of ConsoleKit. But ConsoleKit's original developer(s) have stopped maintaining it, which I'd imagine is part of the reason distros started moving to logind. (There is the ConsoleKit2 fork, but I'm not sure how much traction that's gotten.) From lkcl at lkcl.net Mon Jul 3 15:24:53 2017 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Mon, 3 Jul 2017 15:24:53 +0100 Subject: [Arm-netbook] severe systemd bugs (two of them) In-Reply-To: References: <87a84mj584.fsf@whist.hands.com> Message-ID: On Mon, Jul 3, 2017 at 3:00 PM, Jonathan Frederickson wrote: > It's true that the systemd developers have also written replacements > for existing software that *have* been widely adopted, notably > systemd-logind in favor of ConsoleKit. But ConsoleKit's original > developer(s) have stopped maintaining it, which I'd imagine is part of > the reason distros started moving to logind. (There is the ConsoleKit2 > fork, but I'm not sure how much traction that's gotten.) there's a misconception that software that does its job actually needs "development". good stable software that does a job and does it well (the unix philosophy) often simply needs "maintenance" only - keeping up-to-date with dependency changes, tool changes, 64-bit ports and architecture ports and so on. the problem is: maintenance is a really boring job. so after a few years, people... stop doing it. at that point the software is often considered "abandonware". sadly it sounds like consolekit suffers (suffered) such abandonment... ironically by virtue of having become stable (and thus boring to work on). so i'm not really sure what to say, particularly as consolekit is something that is pretty damn necessary. it's a bizarre situation. l. From silverskullpsu at gmail.com Mon Jul 3 15:38:46 2017 From: silverskullpsu at gmail.com (Jonathan Frederickson) Date: Mon, 3 Jul 2017 10:38:46 -0400 Subject: [Arm-netbook] severe systemd bugs (two of them) In-Reply-To: References: <87a84mj584.fsf@whist.hands.com> Message-ID: On Mon, Jul 3, 2017 at 10:24 AM, Luke Kenneth Casson Leighton wrote: > there's a misconception that software that does its job actually > needs "development". good stable software that does a job and does it > well (the unix philosophy) often simply needs "maintenance" only - > keeping up-to-date with dependency changes, tool changes, 64-bit ports > and architecture ports and so on. the problem is: maintenance is a > really boring job. so after a few years, people... stop doing it. at > that point the software is often considered "abandonware". Right, and notably also security fixes. But my point is I don't think it's useful to demonize the systemd developers for writing their own version of software for which the alternatives are no longer maintained. (Or even software which still has actively maintained alternatives, honestly!) systemd-resolved is just another caching resolver, systemd-logind is just another session manager, etc. People have always done this, it's just that the systemd folks are writing their own versions of lots of different services. And that's okay! You're free to use them, or not, as you choose. (Granted in most cases it's the distro maintainer's choice, as it is for all the other default software in their distro.) From hozer at hozed.org Mon Jul 3 15:43:31 2017 From: hozer at hozed.org (Troy Benjegerdes) Date: Mon, 3 Jul 2017 14:43:31 +0000 Subject: [Arm-netbook] severe systemd bugs (two of them) In-Reply-To: References: Message-ID: <20170703144331.GF4885@hostname.unassigned> On Mon, Jul 03, 2017 at 12:05:59PM +0100, Luke Kenneth Casson Leighton wrote: > On Mon, Jul 3, 2017 at 10:19 AM, Bill Kontos wrote: > > > > Also I don't consider going from a variety of options each with it's > > disadvantages to a single option essentially standardizing it a bad > > thing. It's just a lost opportunity to make a real standard for sure, > > but I don't think that's monoculture. > > it's the very definition of a monoculture, bill. > > a standard has multiple implementations: full documentation, stable > APIs, a reference design plus alternative implementations (and/or > people willing *to* implement alternative implementations). > > where is the standard fully documented? > > where is the definition of the stable APIs which have been set as > "gold" and not subject to change for the next 10-20 years? > > where is the reference design (with associated proper documentation)? > > where are the alternative implementations? Gee, it's as if you're talking about bitcoin-core.... Developing all this stuff you speak of takes resources and time to develop, test, deploy, support, maintain. Do you have time to do it, or, at some point, do you have to take work that pays? So if you want to monoculture problem, then start figuring out how to build a **business model** based on a diverse ecosystem. My first suggestion would be start accepting something like http://grantcoin.org as payment for your work, and for hardware, for at least if that works, we might have developers that can sign up for a basic income guarantee and work on whatever they feel like working on, rather than code that will get them paid. Or sell me a piece of libre-hardware that's pre-installed **and QA tested** with a stack of libre-software that includes all the designs so I can go down to my local silicon fab and PCB house and have them make a derivative work. From lkcl at lkcl.net Mon Jul 3 16:02:23 2017 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Mon, 3 Jul 2017 16:02:23 +0100 Subject: [Arm-netbook] severe systemd bugs (two of them) In-Reply-To: References: <87a84mj584.fsf@whist.hands.com> Message-ID: On Mon, Jul 3, 2017 at 3:38 PM, Jonathan Frederickson wrote: > People have always done this, it's just that the systemd folks are > writing their own versions of lots of different services. And that's > okay! You're free to use them, or not, as you choose. ... actually... we (the users) are in no way "free". constraints such as time, effort, money and risk (which are usually offset by collaborative effort) all come into play and take precedence over whether the *source code* happens to be libre. > (Granted in most > cases it's the distro maintainer's choice, as it is for all the other > default software in their distro.) ... exactly. this is what particularly pisses me off about how systemd has been deployed: all possible alternatives across 98% of distros - particularly the major ones - have ripped up and burned pretty much all and any possibility of **CONVENIENT** choice. for example, until i discovered that angband.pl actively maintains systemd-less debian packages for xorg, udev, pulseaudio and several critical pre-systemd packages (including consolekit), i was forced to make an extremely risky *MANUAL* removal of systemd. that included REMOVING udev entirely and MANUALLY maintaining entries in /dev (!) i also had to add a hundred entries into /etc/modules - some of which i could not determine so had to actually not have access to critical hardware for a considerable amount of time. you *really* want to tell me that i am quotes free quotes to make such unbelievably risky decisions, on a live-running mission-critical system that has no regular backups? this one example underscores that "freedom" - having access to the source - is no longer the only factor, meaning that we are heavily and critically deependent on decisions made by distro maintainers. unfortunataly, many people who committed to a particular distro, and implicitly trusted the distro maintainers, have been betrayed. the choice (or expectation)? f*** off and find yourself another distro. except that too is a betrayal of trust: the amount of effor it takes to convert a live-running mission-critical system over to a completely new distro? that people would even consider suggesting that users should convert live-running systems is... words fail me. l. From richard.wilbur at gmail.com Mon Jul 3 16:31:40 2017 From: richard.wilbur at gmail.com (Richard Wilbur) Date: Mon, 3 Jul 2017 09:31:40 -0600 Subject: [Arm-netbook] Arm Netbook, Saw the update, In-Reply-To: References: <729312675.2922981.1498019518849.ref@mail.yahoo.com> <729312675.2922981.1498019518849@mail.yahoo.com> <594A892D.6040009@posteo.de> <74fd6c20-725d-5eac-1057-1a4be035ddea@aross.me> <1DAA53E0-C7C8-4DED-8E62-087C2B20AFE6@gmail.com> Message-ID: <87485148-2167-45A7-8298-FDE1A6C66B6F@gmail.com> Sent from my iPhone > On Jun 29, 2017, at 20:45, Luke Kenneth Casson Leighton wrote: > On Fri, Jun 30, 2017 at 3:32 AM, Richard Wilbur > wrote: >> Have you identified which signals are affected? > > no - i do not have access to equipment which will allow me to make > such a determination. I'll check to see whether I can get some lab time up at the university (where I took the lion's share of my electrical engineering coursework). >> Have you been able to determine which signals are leaking into the affected signals? > > ditto... basically this is all guess-work and experimentation. Well congratulations on many good guesses and what sounds like a relatively successful experiment! The fact that I don't know the layer stack for the board throws in some more uncertainty. I don't know whether those differential pairs were spending a lot of time over a ground plane. When the differential pairs crossed paths did they do so over separate ground planes, et cetera? > ok, so what i'm planning to do, richard, is a redesign of this entire > area, starting by widening the PCB by 1mm. Does that still meet your design goal for EOMA68 form factor? I wouldn't sacrifice an important design goal, yet. I wouldn't be surprised if we can pack a working layout into your original outline. On the other hand, more space can make the layout easier. > this should allow me to put several diff-pairs on the same layer > (i'll start by trying to put them all on layer 3, see how that goes). You said the board has 6 layers. Does that mean layer 3 is in the midst of the stack or on the outside? If it's inside, you could use striplines for the differential pairs. It'll require three layers (two of them ground) but it is about as close to a TEM waveguide as you can get in a PCB. > > would you be happy to advise before it goes to pre-production? I would be overjoyed to put this somewhat arcane knowledge to some good use. In other words, "Yes!" Reading an application note on HDMI from Texas Instruments[*] I noticed they mentioned a clock rate of 340 MHz and Reference: [*] _HDMI Design Guide_, http://e2e.ti.com/cfs-file/__key/telligent-evolution-components-attachments/00-138-01-00-00-10-65-80/Texas-Instruments-HDMI-Design-Guide.pdf [2] SLLA324 February 2012 Application Report, "TPD12S016 PCB Layout Guidelines for HDMI ESD" From calmstorm at posteo.de Mon Jul 3 16:33:23 2017 From: calmstorm at posteo.de (zap) Date: Mon, 3 Jul 2017 11:33:23 -0400 Subject: [Arm-netbook] severe systemd bugs (two of them) In-Reply-To: References: Message-ID: <2cf1d89a-6b8b-a3f0-9374-9ec629bf25f2@posteo.de> On 07/03/2017 03:52 AM, Luke Kenneth Casson Leighton wrote: > https://it.slashdot.org/story/17/07/03/0343258/severe-systemd-bug-allowed-remote-code-execution-for-two-years > > two years. that's how long one of these bugs has been in systemd. > *via a remote network*. what the hell is an init system doing being > accessible *via DNS queries*? > > for anyone who still believes that systemd is okay to use and deploy, > and that there exist "great advantages that outweigh the risks", are > you *finally* getting the message now? > > dozens of distros, millions of people, all affected by the > irresponsible act of switching "en-masse" to a single over-reaching > init system which is developed in a fashion that is not being properly > managed or controlled. i do not understand why people do not > understand this. > > l. I got your message a while ago, and thank you for bringing this up, because systemd actually is not only less secure, but it is slower (for me anyways) and the people who made that software are hostile to people wanting to remove systemd. I use devuan ascii with openrc and I quite enjoy devuan. Just know, your words on systemd got me off of debian and onto devuan. So thank you! > > _______________________________________________ > arm-netbook mailing list arm-netbook at lists.phcomp.co.uk > http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook > Send large attachments to arm-netbook at files.phcomp.co.uk From silverskullpsu at gmail.com Mon Jul 3 16:34:29 2017 From: silverskullpsu at gmail.com (Jonathan Frederickson) Date: Mon, 3 Jul 2017 11:34:29 -0400 Subject: [Arm-netbook] severe systemd bugs (two of them) In-Reply-To: References: <87a84mj584.fsf@whist.hands.com> Message-ID: > this one example underscores that "freedom" - having access to the > source - is no longer the only factor, meaning that we are heavily and > critically deependent on decisions made by distro maintainers. Again, this has always been the case! Unless you're packaging things yourself, you're dependent on the distro maintainers (or sometimes the upstream developers) to package them for you, or you have to install them outside the package manager which carries its own set of risks. The distro maintainers have to manage their (often limited and unpaid) time wisely. In Debian's case, choosing systemd as the init system means that package maintainers only have to write much shorter systemd service files instead of longer sysvinit-style startup scripts. As a developer, I can certainly understand that decision. Perhaps software freedom alone is no longer enough, and in some cases I agree. But in this case, I don't think I can fault Debian (as a volunteer project) for not wanting to do work they don't have to. From calmstorm at posteo.de Mon Jul 3 16:37:52 2017 From: calmstorm at posteo.de (zap) Date: Mon, 3 Jul 2017 11:37:52 -0400 Subject: [Arm-netbook] severe systemd bugs (two of them) In-Reply-To: References: Message-ID: <675297f6-4a70-e1cb-7e13-2f57d2ccd1ee@posteo.de> when i was looking at taking over maintenance of depinit one of the first tasks was to add full automated compatibility for initscripts. signiicant advantages of depinit were lost in the process but there was no loss when compared to sysvinit itself. individual initscripts could then be replaced to provide a much better way of handling services (safe_mysqld for example could be dispensed with entirely). even with that in mind i see no down-side to the additional workload that you refer to when you consider the upside that diversity brings. no monoculture, no centralised control, and a need for people managing *different* projects - the components that systemd has [irresponsibly] made quotes redundant quotes - to communicate, discuss and agree interoperable standards. the abdication of responsibility by all distros has taken away the opportunity for diverse and disparate teams to work together, shunting aside all the safeguards that are normally in place and allowing lennart pottering and his team to arbitrarily and unilaterally decide how GNU/Linux should work. this, then, primarily is what i do not understand that people do not understand. l. You absolutely have a point. we shouldn't be putting all our eggs into the same basket. What will happen if that basket gets holes in it? This is the case of systemd. I prefer not to trust systemd for this, security issues, stability issues and also my laptop runs slower with it. I compared the difference between debian and devuan and I was sorely dissapointed by debian. From richard.wilbur at gmail.com Mon Jul 3 17:03:44 2017 From: richard.wilbur at gmail.com (Richard Wilbur) Date: Mon, 3 Jul 2017 10:03:44 -0600 Subject: [Arm-netbook] Arm Netbook, Saw the update, In-Reply-To: <87485148-2167-45A7-8298-FDE1A6C66B6F@gmail.com> References: <729312675.2922981.1498019518849.ref@mail.yahoo.com> <729312675.2922981.1498019518849@mail.yahoo.com> <594A892D.6040009@posteo.de> <74fd6c20-725d-5eac-1057-1a4be035ddea@aross.me> <1DAA53E0-C7C8-4DED-8E62-087C2B20AFE6@gmail.com> <87485148-2167-45A7-8298-FDE1A6C66B6F@gmail.com> Message-ID: On Jun 29, 2017, at 20:45, Luke Kenneth Casson Leighton wrote: > On Fri, Jun 30, 2017 at 3:32 AM, Richard Wilbur > wrote: >> Have you identified which signals are affected? > > no - i do not have access to equipment which will allow me to make > such a determination. I'll check to see whether I can get some lab time up at the university (where I took the lion's share of my electrical engineering coursework). >> Have you been able to determine which signals are leaking into the affected signals? > > ditto... basically this is all guess-work and experimentation. Well congratulations on many good guesses and what sounds like a relatively successful experiment! The fact that I don't know the layer stack for the board throws in some more uncertainty. I don't know whether those differential pairs were spending a lot of time over a ground plane. When the differential pairs crossed paths did they do so over separate ground planes, et cetera? > ok, so what i'm planning to do, richard, is a redesign of this entire > area, starting by widening the PCB by 1mm. Does that still meet your design goal for EOMA68 form factor? I wouldn't sacrifice an important design goal, yet. I wouldn't be surprised if we can pack a working layout into your original outline. On the other hand, more space can make the layout easier. > this should allow me to put several diff-pairs on the same layer > (i'll start by trying to put them all on layer 3, see how that goes). You said the board has 6 layers. Does that mean layer 3 is in the midst of the stack or on the outside? If it's inside, you could use striplines for the differential pairs[1]. It'll require three layers (two of them ground) but it is about as close to a TEM waveguide as you can get in a PCB. > > would you be happy to advise before it goes to pre-production? I would be overjoyed to put this somewhat arcane knowledge to some good use. In other words, "Yes!" Reading an application note on HDMI from Texas Instruments[2] I noticed they mentioned a clock rate of 340 MHz and with a data rate of 3.4 Gb/s. In the interest of characterizing the problem at hand I would like to find a reference that describes the signals of this standard (HDMI v1.4). Sorry for the noise. My last two posts were prematurely sent when I was trying to type (on my phone keyboard) and accidentally hit a/an conveniently/inconveniently placed "Send" button. I am trying to make peace with this user interface. My wife gave me a tip: remove the "To:" address until you are ready to send the message as without a destination address the "Send" button is disabled. -- Richard References: [1] _HDMI Design Guide_, http://e2e.ti.com/cfs-file/__key/telligent-evolution-components-attachments/00-138-01-00-00-10-65-80/Texas-Instruments-HDMI-Design-Guide.pdf [2] SLLA324 February 2012 Application Report, "TPD12S016 PCB Layout Guidelines for HDMI ESD" From adam at vany.ca Mon Jul 3 17:35:00 2017 From: adam at vany.ca (Adam Van Ymeren) Date: Mon, 03 Jul 2017 12:35:00 -0400 Subject: [Arm-netbook] severe systemd bugs (two of them) In-Reply-To: (Jonathan Frederickson's message of "Mon, 3 Jul 2017 11:34:29 -0400") References: <87a84mj584.fsf@whist.hands.com> Message-ID: <877ezpzdfv.fsf@vany.ca> Jonathan Frederickson writes: >> this one example underscores that "freedom" - having access to the >> source - is no longer the only factor, meaning that we are heavily and >> critically deependent on decisions made by distro maintainers. > > Again, this has always been the case! Unless you're packaging things > yourself, you're dependent on the distro maintainers (or sometimes the > upstream developers) to package them for you, or you have to install > them outside the package manager which carries its own set of risks. > > The distro maintainers have to manage their (often limited and unpaid) > time wisely. In Debian's case, choosing systemd as the init system > means that package maintainers only have to write much shorter systemd > service files instead of longer sysvinit-style startup scripts. As a > developer, I can certainly understand that decision. It's unfortunate that systemd is seen as necessary to get these shorter service files for service declaration. Or that sysvinit requires you to write long complicated init scripts. Rather than replacing the init system, it would be possible to write a standalone tool to interpret service files that sysvinit can call. This works because sysvinit and other early UNIX init systems are written as separate components, that interact by running other exectuables/commands. This is the opposite to how systemd is architected where it moves more functionality into the same executable, making it less flexible and extensible as a result. From silverskullpsu at gmail.com Mon Jul 3 18:14:48 2017 From: silverskullpsu at gmail.com (Jonathan Frederickson) Date: Mon, 3 Jul 2017 13:14:48 -0400 Subject: [Arm-netbook] severe systemd bugs (two of them) In-Reply-To: <877ezpzdfv.fsf@vany.ca> References: <87a84mj584.fsf@whist.hands.com> <877ezpzdfv.fsf@vany.ca> Message-ID: On Mon, Jul 3, 2017 at 12:35 PM, Adam Van Ymeren wrote: > It's unfortunate that systemd is seen as necessary to get these shorter > service files for service declaration. Or that sysvinit requires you to > write long complicated init scripts. > > Rather than replacing the init system, it would be possible to write a > standalone tool to interpret service files that sysvinit can call. > > This works because sysvinit and other early UNIX init systems are > written as separate components, that interact by running other > exectuables/commands. This is the opposite to how systemd is > architected where it moves more functionality into the same executable, > making it less flexible and extensible as a result. Of course that's possible! It's just that (AFAIK) nobody has done it yet. I'm sure the users of non-systemd init systems would appreciate such a tool, given the increasing number of projects that ship with only systemd service files upstream. The question remains: who's going to write it? From tzafrir at cohens.org.il Mon Jul 3 18:12:18 2017 From: tzafrir at cohens.org.il (Tzafrir Cohen) Date: Mon, 3 Jul 2017 19:12:18 +0200 Subject: [Arm-netbook] severe systemd bugs (two of them) In-Reply-To: References: <87a84mj584.fsf@whist.hands.com> Message-ID: <20170703171217.p3qpva7sybnyeiai@lemon.cohens.org.il> I'm not going to join this pro/anti systemd discussion as it is pointless at this point, but, On Mon, Jul 03, 2017 at 04:02:23PM +0100, Luke Kenneth Casson Leighton wrote: > for example, until i discovered that angband.pl actively maintains > systemd-less debian packages for xorg, udev, pulseaudio and several > critical pre-systemd packages (including consolekit), i was forced to > make an extremely risky *MANUAL* removal of systemd. that included > REMOVING udev entirely and MANUALLY maintaining entries in /dev (!) i > also had to add a hundred entries into /etc/modules - some of which i > could not determine so had to actually not have access to critical > hardware for a considerable amount of time. Hang on, is this for the images for the EOMA68? I figure you don't have systemd there because the kernel is < 3.12. But no udev? Or is this for an unrelated system? -- Tzafrir Cohen | tzafrir at jabber.org | VIM is http://tzafrir.org.il | | a Mutt's tzafrir at cohens.org.il | | best tzafrir at debian.org | | friend From lkcl at lkcl.net Mon Jul 3 18:27:33 2017 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Mon, 3 Jul 2017 18:27:33 +0100 Subject: [Arm-netbook] severe systemd bugs (two of them) In-Reply-To: <20170703144331.GF4885@hostname.unassigned> References: <20170703144331.GF4885@hostname.unassigned> Message-ID: On Mon, Jul 3, 2017 at 3:43 PM, Troy Benjegerdes wrote: > Gee, it's as if you're talking about bitcoin-core.... bitcoin-core is not a critical and essential dependency which has been forced onto 98% of GNU/Linux users without their informed consent. l. From lkcl at lkcl.net Mon Jul 3 19:08:46 2017 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Mon, 3 Jul 2017 19:08:46 +0100 Subject: [Arm-netbook] Arm Netbook, Saw the update, In-Reply-To: <87485148-2167-45A7-8298-FDE1A6C66B6F@gmail.com> References: <729312675.2922981.1498019518849.ref@mail.yahoo.com> <729312675.2922981.1498019518849@mail.yahoo.com> <594A892D.6040009@posteo.de> <74fd6c20-725d-5eac-1057-1a4be035ddea@aross.me> <1DAA53E0-C7C8-4DED-8E62-087C2B20AFE6@gmail.com> <87485148-2167-45A7-8298-FDE1A6C66B6F@gmail.com> Message-ID: On Mon, Jul 3, 2017 at 4:31 PM, Richard Wilbur wrote: > > > Sent from my iPhone >> On Jun 29, 2017, at 20:45, Luke Kenneth Casson Leighton wrote: >> On Fri, Jun 30, 2017 at 3:32 AM, Richard Wilbur >> wrote: >>> Have you identified which signals are affected? >> >> no - i do not have access to equipment which will allow me to make >> such a determination. > > I'll check to see whether I can get some lab time up at the university (where I took the lion's share of my electrical engineering coursework). > >>> Have you been able to determine which signals are leaking into the affected signals? >> >> ditto... basically this is all guess-work and experimentation. > > Well congratulations on many good guesses and what sounds like a relatively successful experiment! > > The fact that I don't know the layer stack for the board 6 layer FR4 1.2mm, top gnd sig, pwr, gnd, bot. > throws in some more uncertainty. I don't know whether those differential pairs were spending a lot of time over a ground plane. When the differential pairs crossed paths did they do so over separate ground planes, et cetera? i'm now restricting the dff pairs to top and bottom. the majority of time is bottom. space at the edge is now sufficient to do that. >> ok, so what i'm planning to do, richard, is a redesign of this entire >> area, starting by widening the PCB by 1mm. > > Does that still meet your design goal for EOMA68 form factor? yes. actually without the expansion the plastic surround flops about and the casework can drop off. with the extra size the plastic edges stay in place and the catches along the metal case then also stay in place. >> this should allow me to put several diff-pairs on the same layer >> (i'll start by trying to put them all on layer 3, see how that goes). > > You said the board has 6 layers. Does that mean layer 3 is in the midst of the stack or on the outside? yes but next to the power plane, where i have run 5V power and 3.3v (and can't move them). > If it's inside, you could use striplines for the differential pairs. It'll require three layers (two of them ground) but it is about as close to a TEM waveguide as you can get in a PCB. > >> >> would you be happy to advise before it goes to pre-production? > > I would be overjoyed to put this somewhat arcane knowledge to some good use. In other words, "Yes!" yay! > Reading an application note on HDMI from Texas Instruments[*] I noticed they mentioned a clock rate of 340 MHz and 340mhz is not as bad as i was expecting. l. From calmstorm at posteo.de Mon Jul 3 19:26:20 2017 From: calmstorm at posteo.de (zap) Date: Mon, 3 Jul 2017 14:26:20 -0400 Subject: [Arm-netbook] severe systemd bugs (two of them) In-Reply-To: <20170703171217.p3qpva7sybnyeiai@lemon.cohens.org.il> References: <87a84mj584.fsf@whist.hands.com> <20170703171217.p3qpva7sybnyeiai@lemon.cohens.org.il> Message-ID: On 07/03/2017 01:12 PM, Tzafrir Cohen wrote: > I'm not going to join this pro/anti systemd discussion as it is > pointless at this point, but, For the most part I agree with you, but I must admit I trust someone with as much experience like Luke far more than systemd. But you are free to avoid this conversation altogether if you wish. meh... From valhalla-l at trueelena.org Mon Jul 3 19:45:28 2017 From: valhalla-l at trueelena.org (Elena ``of Valhalla'') Date: Mon, 3 Jul 2017 20:45:28 +0200 Subject: [Arm-netbook] severe systemd bugs (two of them) In-Reply-To: References: <87a84mj584.fsf@whist.hands.com> Message-ID: <20170703184527.uzj3t2zoajwnnbxf@manillaroad.local.home.trueelena.org> On 2017-07-03 at 11:34:29 -0400, Jonathan Frederickson wrote: > The distro maintainers have to manage their (often limited and unpaid) > time wisely. In Debian's case, choosing systemd as the init system > means that package maintainers only have to write much shorter systemd > service files instead of longer sysvinit-style startup scripts. As a > developer, I can certainly understand that decision. for the sake of accuracy, I'd like to point out that Debian's developers are still adding sysvinit startup scripts, or at least maintaining the existing ones (altought "patches welcome" is very much the approach in the case of new ones). sysvinit is still a supported init system in Debian (and still the default on the non-linux port, which are not release architectures but are still pretty maintained); the main reason why this may change in the future is if there is no longer anybody who cares about it enough to at least report bugs, but ideally also support the developement¹. what is not supported is having a system that is completely purged of any reference to the systemd libraries, even if they just point to shim code, because that would require distributing multiple binary packages for a lot of source packages, and that is not really suitable to the way debian works. The main victim to debian choosing to default on systemd, up to now, has been upstrart, and that only because upstream (Canonical) stopped supporting it. However, from the point of view of independence from a single corporation that would have been even worse. > Perhaps software freedom alone is no longer enough, and in some cases > I agree. But in this case, I don't think I can fault Debian (as a > volunteer project) for not wanting to do work they don't have to. Indeed, volunteer time is seriously limited, and there are things that are just beyond what can be expected from them. E.g. if a mayor DE would start requiring systemd to work, Debian would not be in the position to fork it, but that doesn't mean that non-systemd users will be forced to migrate to systemd, just that they would have to use one of the many other DE available in Debian. ¹ this is not that unlikely, however: there have been a number of calls for help because the numbers of complaints on the mailing list is much higher than the number of people actually giving even a tiny bit of help in ensuring that sysvinit continues to be tested and supported in Debian, and if nobody tests it, eventually it will bitrot and stop working. -- Elena ``of Valhalla'' From calmstorm at posteo.de Mon Jul 3 23:32:00 2017 From: calmstorm at posteo.de (zap) Date: Mon, 3 Jul 2017 18:32:00 -0400 Subject: [Arm-netbook] severe systemd bugs (two of them) In-Reply-To: <20170703184527.uzj3t2zoajwnnbxf@manillaroad.local.home.trueelena.org> References: <87a84mj584.fsf@whist.hands.com> <20170703184527.uzj3t2zoajwnnbxf@manillaroad.local.home.trueelena.org> Message-ID: > Indeed, volunteer time is seriously limited, and there are things that > are just beyond what can be expected from them. > > E.g. if a mayor DE would start requiring systemd to work, Debian would > not be in the position to fork it, but that doesn't mean that > non-systemd users will be forced to migrate to systemd, just that they > would have to use one of the many other DE available in Debian. > > ¹ this is not that unlikely, however: there have been a number of calls > for help because the numbers of complaints on the mailing list is much > higher than the number of people actually giving even a tiny bit of help > in ensuring that sysvinit continues to be tested and supported in > Debian, and if nobody tests it, eventually it will bitrot and stop > working. > That is why, runit and openrc are badly needed as options but no matter what, the developers of debian had no right to force all packages to require systemd if they are calling their distro "universally free or free software" because that is the opposite of how free software is supposed to work. We really shouldn't put all are eggs in the same basket. Due to the number of holes that may exist. also, this makes it easier I am sure for the NSA and other corporate firms I am sure to hack into us. but meh go ahead and support a broken init especially the same one that many other distros use that if people figure a way out to hack in a specific way... has a domino effect... This may be hypothetical, but I am unnerved by this idea that's all. I may lack information but I am sure Luke knows far more terrifying details than I am suggesting... That's my last thought on this hopefully for a while. ;) From laserhawk64 at gmail.com Mon Jul 3 23:35:01 2017 From: laserhawk64 at gmail.com (Christopher Havel) Date: Mon, 3 Jul 2017 18:35:01 -0400 Subject: [Arm-netbook] severe systemd bugs (two of them) In-Reply-To: References: <87a84mj584.fsf@whist.hands.com> <20170703184527.uzj3t2zoajwnnbxf@manillaroad.local.home.trueelena.org> Message-ID: TBH I'd remove systemd from my copy of Mint, but I'd be afraid to break it. No, not because of systemd itself -- because of me. Things tend to break when I tinker with them, lol, especially when they're as complicated as a modern OS is. So I guess I'll live with it for now. From hendrik at topoi.pooq.com Tue Jul 4 02:41:07 2017 From: hendrik at topoi.pooq.com (Hendrik Boom) Date: Mon, 3 Jul 2017 21:41:07 -0400 Subject: [Arm-netbook] Doing without systemd In-Reply-To: References: <87a84mj584.fsf@whist.hands.com> Message-ID: <20170704014107.GA10936@topoi.pooq.com> On Mon, Jul 03, 2017 at 04:02:23PM +0100, Luke Kenneth Casson Leighton wrote: > > for example, until i discovered that angband.pl actively maintains > systemd-less debian packages for xorg, udev, pulseaudio and several > critical pre-systemd packages (including consolekit), i was forced to > make an extremely risky *MANUAL* removal of systemd. that included > REMOVING udev entirely and MANUALLY maintaining entries in /dev (!) i > also had to add a hundred entries into /etc/modules - some of which i > could not determine so had to actually not have access to critical > hardware for a considerable amount of time. For the record, I feel called on to point out that Devuan has done most of that for you, but I suspect that you already know that, and it wasn't ready at the time. So you other guys: If you're removing systemd from Debian, just use Devuan instead -- it's already (mostly) been done for you! Why do I say mostly? There are a few vestigial traces in the system -- such as libsystemd0, which provides a few systemd interfaces in a form that just reports that systemd is not present. I think that package should really be called something like nosystemd. -- hendrik From lkcl at lkcl.net Tue Jul 4 02:55:09 2017 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Tue, 4 Jul 2017 02:55:09 +0100 Subject: [Arm-netbook] Doing without systemd In-Reply-To: <20170704014107.GA10936@topoi.pooq.com> References: <87a84mj584.fsf@whist.hands.com> <20170704014107.GA10936@topoi.pooq.com> Message-ID: On Tue, Jul 4, 2017 at 2:41 AM, Hendrik Boom wrote: > For the record, I feel called on to point out that Devuan has done most > of that for you, but I suspect that you already know that, and it > wasn't ready at the time. i do - that's not quite it. i have such a high dependency on debian that i can't take the risk of converting. instead i've deployed anganbd.pl's packages and they _do_ get rid - entirely - of libsystemd1. the reason that they do that is to test packages that are ostensibly listed as not depending on sytemd actually *really* do not depend on systemd. angband.pl's approach means that i can stay on debian, and there's no risk of jeapordising this project. l. From lkcl at lkcl.net Tue Jul 4 02:57:22 2017 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Tue, 4 Jul 2017 02:57:22 +0100 Subject: [Arm-netbook] severe systemd bugs (two of them) In-Reply-To: <20170703171217.p3qpva7sybnyeiai@lemon.cohens.org.il> References: <87a84mj584.fsf@whist.hands.com> <20170703171217.p3qpva7sybnyeiai@lemon.cohens.org.il> Message-ID: On Mon, Jul 3, 2017 at 6:12 PM, Tzafrir Cohen wrote: > Hang on, is this for the images for the EOMA68? no. > I figure you don't have > systemd there because the kernel is < 3.12. But no udev? Or is this for > an unrelated system? correct. my main laptop. From tzafrir at cohens.org.il Tue Jul 4 07:55:41 2017 From: tzafrir at cohens.org.il (Tzafrir Cohen) Date: Tue, 4 Jul 2017 08:55:41 +0200 Subject: [Arm-netbook] severe systemd bugs (two of them) In-Reply-To: References: <87a84mj584.fsf@whist.hands.com> <20170703184527.uzj3t2zoajwnnbxf@manillaroad.local.home.trueelena.org> Message-ID: <20170704065540.kbeapvi3n3yp47hd@lemon.cohens.org.il> On Mon, Jul 03, 2017 at 06:32:00PM -0400, zap wrote: > > > Indeed, volunteer time is seriously limited, and there are things that > > are just beyond what can be expected from them. > > > > E.g. if a mayor DE would start requiring systemd to work, Debian would > > not be in the position to fork it, but that doesn't mean that > > non-systemd users will be forced to migrate to systemd, just that they > > would have to use one of the many other DE available in Debian. > > > > ¹ this is not that unlikely, however: there have been a number of calls > > for help because the numbers of complaints on the mailing list is much > > higher than the number of people actually giving even a tiny bit of help > > in ensuring that sysvinit continues to be tested and supported in > > Debian, and if nobody tests it, eventually it will bitrot and stop > > working. > > > That is why, runit and openrc are badly needed as options but no matter > what, the developers of debian had no right to force all packages to > require systemd if they are calling their distro "universally free or > free software" because that is the opposite of how free software is > supposed to work. Openrc is included in Debian. If anybody asked me to add support for its configs for whatever packages I maintain, I guess the approach would likewise be "patches are wellcomed", but there are also no packaging tools for that, which makes the required patches larger, I believe. I would probably also not be able to easily be able to debug those. -- Tzafrir Cohen | tzafrir at jabber.org | VIM is http://tzafrir.org.il | | a Mutt's tzafrir at cohens.org.il | | best tzafrir at debian.org | | friend From tzafrir at cohens.org.il Tue Jul 4 08:17:00 2017 From: tzafrir at cohens.org.il (Tzafrir Cohen) Date: Tue, 4 Jul 2017 09:17:00 +0200 Subject: [Arm-netbook] Doing without systemd In-Reply-To: <20170704014107.GA10936@topoi.pooq.com> References: <87a84mj584.fsf@whist.hands.com> <20170704014107.GA10936@topoi.pooq.com> Message-ID: <20170704071700.mlaii6kcmdbxuxai@lemon.cohens.org.il> On Mon, Jul 03, 2017 at 09:41:07PM -0400, Hendrik Boom wrote: > On Mon, Jul 03, 2017 at 04:02:23PM +0100, Luke Kenneth Casson Leighton wrote: > > > > for example, until i discovered that angband.pl actively maintains > > systemd-less debian packages for xorg, udev, pulseaudio and several > > critical pre-systemd packages (including consolekit), i was forced to > > make an extremely risky *MANUAL* removal of systemd. that included > > REMOVING udev entirely and MANUALLY maintaining entries in /dev (!) i > > also had to add a hundred entries into /etc/modules - some of which i > > could not determine so had to actually not have access to critical > > hardware for a considerable amount of time. > > For the record, I feel called on to point out that Devuan has done most > of that for you, but I suspect that you already know that, and it > wasn't ready at the time. > > So you other guys: > If you're removing systemd from Debian, just use Devuan instead -- it's > already (mostly) been done for you! In another thread someone mentioned trusting people. I trust the maintainer of angband.pl generally more than maintainers of Devuan, from observed behavior. -- Tzafrir Cohen | tzafrir at jabber.org | VIM is http://tzafrir.org.il | | a Mutt's tzafrir at cohens.org.il | | best tzafrir at debian.org | | friend From phil at hands.com Tue Jul 4 08:51:54 2017 From: phil at hands.com (Philip Hands) Date: Tue, 04 Jul 2017 09:51:54 +0200 Subject: [Arm-netbook] systemd nonsense ad-infinitum In-Reply-To: References: <87a84mj584.fsf@whist.hands.com> <20170703184527.uzj3t2zoajwnnbxf@manillaroad.local.home.trueelena.org> Message-ID: <8760f8iqqt.fsf@whist.hands.com> zap writes: >> Indeed, volunteer time is seriously limited, and there are things that >> are just beyond what can be expected from them. >> >> E.g. if a mayor DE would start requiring systemd to work, Debian would >> not be in the position to fork it, but that doesn't mean that >> non-systemd users will be forced to migrate to systemd, just that they >> would have to use one of the many other DE available in Debian. >> >> ¹ this is not that unlikely, however: there have been a number of calls >> for help because the numbers of complaints on the mailing list is much >> higher than the number of people actually giving even a tiny bit of help >> in ensuring that sysvinit continues to be tested and supported in >> Debian, and if nobody tests it, eventually it will bitrot and stop >> working. >> > That is why, runit and openrc are badly needed as options but no matter > what, the developers of debian had no right to force all packages to > require systemd if they are calling their distro "universally free or > free software" because that is the opposite of how free software is > supposed to work. WTAF? There is no "forcing" or "requiring" involved, and people spouting this bullshit is getting _really_ old now. If any such radical change had actually been enacted then: a) well, we'd be in a different universe, where Debian was run by some sort of overlord who was prone to making snap decisions on a whim. b) there would have been a mass bug filing for all these packages that did not require systemd, to somehow add that requirement. c) there would have then been a vast wave of new package uploads with the new packages, encumbered with those requirements. NONE OF THIS HAPPENED. Debian didn't even make it so that other inits were somehow downgraded, except for the fact that sysvinit is no longer the default on those platforms where systemd actually exists (so on other platforms it's not even the default, and most packages happily build on _all_ platforms, so how does that sit in the same universe as one where systemd is "required"?) In fact Debian instead made efforts (much of the effort being done by the Debian systemd maintainers) to make sure that is was actually rather easier to switch between inits. The systemd folk even wrote extra code to make sure that sysvinit and other inits could continue to support programs where the upstreams have decided that they want to depend on the services that systemd provides. That strikes me as above and beyond the call of duty. What thanks do they get for it? They get unending inchoate screaming about how they are part of some sort of global conspiracy, until they started burning out. The result being that they no longer have time, and certainly have no inclination, to support systemd-shim, and the useless wankers that did all the screaming of course cannot be arsed to put any effort into it, so it's now rotting, and the chances of being able to continue using other inits in Debian are now beginning to diminish. This is NOT because anyone forced anyone to do anything. If people were to decide not to post another anti-systemd rant, and instead do something as trivial as reporting a single bug where non-systemd-as-init was causing a problem, then there would be some hope of making sure that other inits continue to work, but from what I can see that is not happening. Instead people are spreading lies and scuttling off to the likes of Devuan (who are also not addressing the issues, because they are not improving application portability, because it's impossible to have Devuan _with_ systemd). Also, note that Debian is still going to the effort of making choice possible -- other ditros that switched have made the rather more sensible choice of supporting only systemd, and thus saving themselves the effort of supporting the minority inits. I imagine that's why people are still bothering to attack Debian on this since they imagine that there's a slim chance that we might switch again, but what you have now is definitely the best you're going to get. As a parent of two small children I can tell you that screaming never gets rewarded, and my children if they scream long enough will either both lose the toy they are fighting over, or have something they like even less happen to them -- I think that's pretty much the mindset that most Debian Developers have adopted to people howling about systemd, so be warned: Life can always get worse, and if you don't want that, stop screaming and put some effort into building the world as you'd like it to exist. Cheers, Phil. -- |)| Philip Hands [+44 (0)20 8530 9560] HANDS.COM Ltd. |-| http://www.hands.com/ http://ftp.uk.debian.org/ |(| Hugo-Klemm-Strasse 34, 21075 Hamburg, GERMANY From lkcl at lkcl.net Tue Jul 4 09:27:05 2017 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Tue, 4 Jul 2017 09:27:05 +0100 Subject: [Arm-netbook] Arm Netbook, Saw the update, In-Reply-To: References: <729312675.2922981.1498019518849.ref@mail.yahoo.com> <729312675.2922981.1498019518849@mail.yahoo.com> <594A892D.6040009@posteo.de> <74fd6c20-725d-5eac-1057-1a4be035ddea@aross.me> <1DAA53E0-C7C8-4DED-8E62-087C2B20AFE6@gmail.com> <87485148-2167-45A7-8298-FDE1A6C66B6F@gmail.com> Message-ID: ok richard i've redone the layout, and published 3 images here: http://rhombus-tech.net/allwinner_a10/news/ the 3rd one - showing the full extent of the 4 diff pairs - is enormous (right-mouse-button, view image) as it's a screenshot from this laptop's 3000x1800 LCD. so you should be able to zoom in without losing resolution. unfortunately since taking the screenshot i noticed that the GND runners between the diff-pairs have been removed: i will restore these. PADS has a bug where when you switch off "locking" of tracks / nets it can suddenly decide "ohhh i'll just re-analyse this lot and remove anything i don't like the look of" which in this case involved removing several shielding GND vias and some of the manual GND tracks that help with shielding, in places where flood-fill could not reach due to the small size. anyway i'll add back in the 5mil tracks between the diff-pairs, if you're wondering why they're missing (they're not). to make it easier to view i switched off layers 2-4, leaving top and bottom only. the HDMI tracks are only *on* top and bottom, anyway. they're all length-matched diff-pairs to within 0.1mm, the clock lines are something like 52.8 mm and i think the shortest one, Tx2, is 48.5mm something like that. l. From lkcl at lkcl.net Tue Jul 4 10:04:03 2017 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Tue, 4 Jul 2017 10:04:03 +0100 Subject: [Arm-netbook] severe systemd bugs (two of them) In-Reply-To: <20170704065540.kbeapvi3n3yp47hd@lemon.cohens.org.il> References: <87a84mj584.fsf@whist.hands.com> <20170703184527.uzj3t2zoajwnnbxf@manillaroad.local.home.trueelena.org> <20170704065540.kbeapvi3n3yp47hd@lemon.cohens.org.il> Message-ID: On Tue, Jul 4, 2017 at 7:55 AM, Tzafrir Cohen wrote: > Openrc is included in Debian. that's new (and fantastic to hear) - it appears that openrc is interoperable with initscripts so in theeorryyy there shouldn't be any need to submit new configs (start/stop scripts for services). l. From lkcl at lkcl.net Tue Jul 4 10:09:45 2017 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Tue, 4 Jul 2017 10:09:45 +0100 Subject: [Arm-netbook] Doing without systemd In-Reply-To: <20170704071700.mlaii6kcmdbxuxai@lemon.cohens.org.il> References: <87a84mj584.fsf@whist.hands.com> <20170704014107.GA10936@topoi.pooq.com> <20170704071700.mlaii6kcmdbxuxai@lemon.cohens.org.il> Message-ID: On Tue, Jul 4, 2017 at 8:17 AM, Tzafrir Cohen wrote: > In another thread someone mentioned trusting people. I trust the > maintainer of angband.pl generally more than maintainers of Devuan, from > observed behavior. *sigh* i love what the devuan team have done: they've achieved a hell of a lot. the only thing is: their stated mission statement is "to give people free choice over their init service". and... err... the lack of support for systemd makes that mission statement a false statement. devuan is therefore a backlash *against* systemd. if they were true to their mission statement they would add the option to include it. what would be really *really* handy is if someone modified angband.pl's packaging so that it compiled *both* systemd *and* systemd-less packages, making the systemd-less variants e.g. of udev as "udev-nosystemd" and using "Provides: udev" (or whatever appropriate debian control magic is necessary). the reason for that would be that the angband.pl variants could then actually be proposed for inclusion in debian. l. From valhalla-l at trueelena.org Tue Jul 4 10:42:37 2017 From: valhalla-l at trueelena.org (Elena ``of Valhalla'') Date: Tue, 4 Jul 2017 11:42:37 +0200 Subject: [Arm-netbook] severe systemd bugs (two of them) In-Reply-To: References: <20170703184527.uzj3t2zoajwnnbxf@manillaroad.local.home.trueelena.org> <20170704065540.kbeapvi3n3yp47hd@lemon.cohens.org.il> Message-ID: <20170704094237.mgvdeockbwoiujrw@manillaroad.local.home.trueelena.org> On 2017-07-04 at 10:04:03 +0100, Luke Kenneth Casson Leighton wrote: > On Tue, Jul 4, 2017 at 7:55 AM, Tzafrir Cohen wrote: > > > Openrc is included in Debian. > > that's new (and fantastic to hear) - it appears that openrc is > interoperable with initscripts so in theeorryyy there shouldn't be any > need to submit new configs (start/stop scripts for services). It was one of the candidates considered when deciding what init system to adopt, altought it had much less support than systemd or upstart (and I suspect it's even less tested than sysvinit). But, most maintainers are going to be happy to receive patch to improve support for it (just like they are for sysvinit), even if they may not be interested in creating them themselves. I've found that the first traces of it are in 2012: https://lists.debian.org/debian-devel/2012/04/msg00547.html -- Elena ``of Valhalla'' From lkcl at lkcl.net Tue Jul 4 11:44:33 2017 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Tue, 4 Jul 2017 11:44:33 +0100 Subject: [Arm-netbook] severe systemd bugs (two of them) In-Reply-To: <20170704094237.mgvdeockbwoiujrw@manillaroad.local.home.trueelena.org> References: <20170703184527.uzj3t2zoajwnnbxf@manillaroad.local.home.trueelena.org> <20170704065540.kbeapvi3n3yp47hd@lemon.cohens.org.il> <20170704094237.mgvdeockbwoiujrw@manillaroad.local.home.trueelena.org> Message-ID: On Tue, Jul 4, 2017 at 10:42 AM, Elena ``of Valhalla'' wrote: >> > Openrc is included in Debian. > It was one of the candidates considered when deciding what init system > to adopt, altought it had much less support than systemd or upstart (and > I suspect it's even less tested than sysvinit). yeahh it was a pity it hadn't had as much mindshare: i've installed it by default on the parabola gnu/linux-libre eoma68-a20 images and, whilst it works well, it feels a little... odd. perhaps that's down to being unfamiliar with it, or that parabola / archlinux requires that if you install e.g. openssh you have to remember to install openssh-openrc and then also run a manual command to make sure it's enabled at boot time (pacman lacks the postinst functionality of dpkg, and archlinux itself seems to lack the concept of setting up "default configured behaviour" for services, leaving that to the user themself). one good thing: i wasn't aware that openrc could be parallelised: it's as simple as adding rc_parallel="YES" to /etc/openrc.conf which i will try out very shortly. back when the openmoko came out, you remember you bought one phil, and told me that it was terribly unresponsive? they used an ARM9 processor, which has a very poorly-designed 1st level cache. on the ARM9, thread/process context-switching results in COMPLETELY throwing away the contents of the 1st level cache. so any context-switch - x11, d-bus, parallel startup, whatever - resulted in performance that was last seen when sysvinit was initially designed, because it *was* designed [N decades ago] to start services *in series* so that context-switching could be minimised as much as possible. unfortunately, developers who primarily use x86/amd64 forget that it is only intel / AMD processors that have heavily-optimised context switching: hyperthreading, 4 or more cores / hardware-threads (usually, these days), 1st level cache that's often larger than the 2nd level cache of embedded processors and so on... ... so they design software that really only works well on x86. i remember around 2004 running opie / familiar on 600mhz Intel ARM PXA 270 processors (before PXA was sold to marvell) and the boot time was often in the *TWO MINUTE* range. god only knows what would happen if systemd was deployed on such processors. systemd unfortunately makes heavy use of d-bus for message-passing. unlike most client-server RPC architectures, d-bus acts as an INTERMEDIARY. that makes for DOUBLE context-switching. client SWITCH d-bus-as-intermediary SWITCH server. for *each part of a round-trip*. that means *FOUR* context-switches for a simple "request-response" as opposed to just two for any other client-server RPC architecture. the heavy usage of d-bus for the openmoko OS basically was part of what killed the project. it would not surprise me at all to find that d-bus is similarly slowing systemd down when compared to other init systems. anyway i'll dig the parabola microsd card out again, switch to parallel openrc and boot it up. it might be a bit much for the A20 to handle, but we'll soon see. l. From lkcl at lkcl.net Tue Jul 4 12:15:23 2017 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Tue, 4 Jul 2017 12:15:23 +0100 Subject: [Arm-netbook] severe systemd bugs (two of them) In-Reply-To: References: <20170703184527.uzj3t2zoajwnnbxf@manillaroad.local.home.trueelena.org> <20170704065540.kbeapvi3n3yp47hd@lemon.cohens.org.il> <20170704094237.mgvdeockbwoiujrw@manillaroad.local.home.trueelena.org> Message-ID: On Tue, Jul 4, 2017 at 11:44 AM, Luke Kenneth Casson Leighton wrote: > anyway i'll dig the parabola microsd card out again, switch to > parallel openrc and boot it up. it might be a bit much for the A20 to > handle, but we'll soon see. ok we're looking at a 21 second boot time to the lightdm login manager with rc_parallel="YES" in /etc/rc.conf and around 25-26 seconds without. to the serial console prompt is around 16 seconds with rc_parallel="YES" and around 20-21 without. for a 1ghz dual-core embedded processor either isn't bad, and performance does appear to be improved. the amount of time spent by the 3.4.104 kernel in initialising hardware (and informing me about it) does seem to be considerable: around 5-8 seconds of the entire boot time! l. From eaterjolly at gmail.com Tue Jul 4 12:20:22 2017 From: eaterjolly at gmail.com (Jean Flamelle) Date: Tue, 4 Jul 2017 07:20:22 -0400 Subject: [Arm-netbook] systemd nonsense ad-infinitum In-Reply-To: <8760f8iqqt.fsf@whist.hands.com> References: <87a84mj584.fsf@whist.hands.com> <20170703184527.uzj3t2zoajwnnbxf@manillaroad.local.home.trueelena.org> <8760f8iqqt.fsf@whist.hands.com> Message-ID: I think the driving point no one wants to argue about and therefore has been lapdancing around, is one way or another systemd is developed by a very ambitious company. Not even speaking to the morals of said company or it's constitutents, it's sustainable existence depends on monopolizing volunteer support for subsystems that it finds to be marketable. This isn't a conflict of interest, necessarily. However, people are Afraid there might be if there hasn't been already been underhanded tactics, exploiting their income to rapidly expand development for an ultra specific however most leverage-able component of the GNU/Linux system, implementing more features, faster, and with fewer bugs than can possibly be audited for by volunteers. If no one can replace systemd because they simply can't code as well as them nearly as fast as them, because they lack the income to survive doing so, it means that the strength of desire to advance humanity will soon no longer be the most significant force enabling the development of linux, as, regardless of the morals and vision the redhat team have, others will follow their example. At the end of the day, this is an improper means to get to goals that for all intensive purposes are simultaneously uncertain and hard to argue with. What happens when other organisations realize they can build leverage over the linux community by ultra-specializing, and massively accelerating the development of a very tiny component of the system with very rapid bug-free feature creeps, effectively making it bloatware that functions REALLY WELL and encouraging people to either expand it according to their vision or feel deprived of it. Right now, it's very difficult to say whether or not this is an intention of the redhat team and it would be very reasonable to call it unintentional, but their behavior is suggesting to others that this is an acceptable practice regardless of intentions. I sincerely understand these are people trying to make the world a sweeter place albeit in a "ends are more important than means"-kinda-unintentional-way. These aren't super-villains like PR would have us believe, in fact quite likely very much the opposite. This isn't really the poster-example of a healthy way of settling differences inside a community. Maybe the redhat team should have done more to trying reaching out to the most informed systemd critics, and maybe those critics should have done more to beat down the flames their words fanned. This whole debacle seems far from civil and I don't understand why, fully yet. Hope, I'm helping with perspective :d From tzafrir at cohens.org.il Tue Jul 4 13:08:03 2017 From: tzafrir at cohens.org.il (Tzafrir Cohen) Date: Tue, 4 Jul 2017 14:08:03 +0200 Subject: [Arm-netbook] severe systemd bugs (two of them) In-Reply-To: References: <20170703184527.uzj3t2zoajwnnbxf@manillaroad.local.home.trueelena.org> <20170704065540.kbeapvi3n3yp47hd@lemon.cohens.org.il> <20170704094237.mgvdeockbwoiujrw@manillaroad.local.home.trueelena.org> Message-ID: <20170704120803.fgahkbeiynk3rzzg@lemon.cohens.org.il> On Tue, Jul 04, 2017 at 11:44:33AM +0100, Luke Kenneth Casson Leighton wrote: > On Tue, Jul 4, 2017 at 10:42 AM, Elena ``of Valhalla'' > wrote: > > >> > Openrc is included in Debian. > > > It was one of the candidates considered when deciding what init system > > to adopt, altought it had much less support than systemd or upstart (and > > I suspect it's even less tested than sysvinit). > > yeahh it was a pity it hadn't had as much mindshare: i've installed > it by default on the parabola gnu/linux-libre eoma68-a20 images and, > whilst it works well, it feels a little... odd. perhaps that's down > to being unfamiliar with it, or that parabola / archlinux requires > that if you install e.g. openssh you have to remember to install > openssh-openrc and then also run a manual command to make sure it's > enabled at boot time (pacman lacks the postinst functionality of dpkg, > and archlinux itself seems to lack the concept of setting up "default > configured behaviour" for services, leaving that to the user > themself). > > one good thing: i wasn't aware that openrc could be parallelised: > it's as simple as adding rc_parallel="YES" to /etc/openrc.conf which i > will try out very shortly. Likewise is Debian's variant of sysvinit (and systemd, of course). -- Tzafrir Cohen | tzafrir at jabber.org | VIM is http://tzafrir.org.il | | a Mutt's tzafrir at cohens.org.il | | best tzafrir at debian.org | | friend From lkcl at lkcl.net Tue Jul 4 15:05:07 2017 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Tue, 4 Jul 2017 15:05:07 +0100 Subject: [Arm-netbook] systemd nonsense ad-infinitum In-Reply-To: References: <87a84mj584.fsf@whist.hands.com> <20170703184527.uzj3t2zoajwnnbxf@manillaroad.local.home.trueelena.org> <8760f8iqqt.fsf@whist.hands.com> Message-ID: On Tue, Jul 4, 2017 at 12:20 PM, Jean Flamelle wrote: > I think the driving point no one wants to argue about and therefore > has been lapdancing around, is one way or another systemd is developed > by a very ambitious company. this reminds me: when kde received $10m in EU funding, what they developed was a copy of the worst ever variant of windows [vista] and it shocked a lot of people. plasma took years to develop, was more complex and really didn't do anything better than what the existing python bindings to KDE's underlying architecture already did. the point being: when money gets involved, people can drop whatever they were doing and can focus full-time on "coding". but the downside of that is that they *do* focus full-time on "coding"... and less time on thinking, talking, relaxing, designing, communicating and creativity. i've seen it happen so many times: when the pace of development is slower - because it's done part-time - naturally what results is... better code. why? because people spent more of their down-time *actually thinking* and mulling things over. the rapid pace of the projects funded by redhat are near-consistently causing grief and aggravation. one of the ones _not_ causing grief [from redhat-funded developers] is the linux kernel project and that is a huge exception because it has so many contributors that it has a totally different development track. i thought this might help as i don't believe that redhat is *deliberately* intending to piss people off by rushing ahead, but that's what's happening as a direct result of redhat trying to justify its existence in a commercial world. > I sincerely understand these are people trying to make the world a > sweeter place albeit in a "ends are more important than > means"-kinda-unintentional-way. i'm reminded of bob podolski's words (actually probably john david garcia's): ethical ends can *never* be achieved by unethical means.... > Hope, I'm helping with perspective :d always. thank you jean. l. From hendrik at topoi.pooq.com Tue Jul 4 15:29:47 2017 From: hendrik at topoi.pooq.com (Hendrik Boom) Date: Tue, 4 Jul 2017 10:29:47 -0400 Subject: [Arm-netbook] Doing without systemd In-Reply-To: References: <87a84mj584.fsf@whist.hands.com> <20170704014107.GA10936@topoi.pooq.com> <20170704071700.mlaii6kcmdbxuxai@lemon.cohens.org.il> Message-ID: <20170704142947.GB19542@topoi.pooq.com> On Tue, Jul 04, 2017 at 10:09:45AM +0100, Luke Kenneth Casson Leighton wrote: > On Tue, Jul 4, 2017 at 8:17 AM, Tzafrir Cohen wrote: > > > In another thread someone mentioned trusting people. I trust the > > maintainer of angband.pl generally more than maintainers of Devuan, from > > observed behavior. > > *sigh* i love what the devuan team have done: they've achieved a hell > of a lot. the only thing is: their stated mission statement is "to > give people free choice over their init service". and... err... the > lack of support for systemd makes that mission statement a false > statement. > > devuan is therefore a backlash *against* systemd. if they were true > to their mission statement they would add the option to include it. The official line is that, if you want Devuan with systemd you should simply install Debian, which *is* Devuan with systemd. Thus you have choice, which you wouldn't have with Debian alone. It doesn't enable you to simply boot with systemd on even-numbered days and without it on odd-numbered days, but it is a reasonable compromise, given their lack of resources. -- hendrik P.S. Technically, Debian itself does make it possible to have a system without systemd, but you have to install with systemd and then replace it. And there are a lot of packages that depend on systemd, but don't in Devuan, so the option isn't as viable as it is presented. > > what would be really *really* handy is if someone modified > angband.pl's packaging so that it compiled *both* systemd *and* > systemd-less packages, making the systemd-less variants e.g. of udev > as "udev-nosystemd" and using "Provides: udev" (or whatever > appropriate debian control magic is necessary). > > the reason for that would be that the angband.pl variants could then > actually be proposed for inclusion in debian. It would have been good of Debian to have adopted a policy like that. Instead they didn't even make systemd a choice at installation time. -- hendrik From richard.wilbur at gmail.com Tue Jul 4 16:15:39 2017 From: richard.wilbur at gmail.com (Richard Wilbur) Date: Tue, 4 Jul 2017 09:15:39 -0600 Subject: [Arm-netbook] Arm Netbook, Saw the update, In-Reply-To: References: <729312675.2922981.1498019518849.ref@mail.yahoo.com> <729312675.2922981.1498019518849@mail.yahoo.com> <594A892D.6040009@posteo.de> <74fd6c20-725d-5eac-1057-1a4be035ddea@aross.me> <1DAA53E0-C7C8-4DED-8E62-087C2B20AFE6@gmail.com> <87485148-2167-45A7-8298-FDE1A6C66B6F@gmail.com> Message-ID: On Jul 4, 2017, at 02:27, Luke Kenneth Casson Leighton wrote: > > ok richard i've redone the layout, and published 3 images here: > http://rhombus-tech.net/allwinner_a10/news/ Thanks for letting me know. I took an initial peek at the images and they look like you addressed the points I mentioned. I'm going to be a day or two getting back with more detailed questions as today is a holiday here and we have family visiting till Thursday. A couple questions that spring immediately to mind: 1. How continuous are the ground planes under the differential pairs? (Are there voids in the ground planes under the differential pairs?) 2. The intra-pair length sounds well-matched, my understanding of the inter-pair skew is that the requirement is in terms of the clock speed Δt <= 0.2 Tcharacter. For 225 MHz clock the application note spoke of 888ps. So we'll be interested in determining the maximum clock rate and speed of propagation. I'll also have some questions about dimensions and geometry. Thank you for the opportunity to participate. -- Richard From lkcl at lkcl.net Tue Jul 4 16:50:05 2017 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Tue, 4 Jul 2017 16:50:05 +0100 Subject: [Arm-netbook] Arm Netbook, Saw the update, In-Reply-To: References: <729312675.2922981.1498019518849.ref@mail.yahoo.com> <729312675.2922981.1498019518849@mail.yahoo.com> <594A892D.6040009@posteo.de> <74fd6c20-725d-5eac-1057-1a4be035ddea@aross.me> <1DAA53E0-C7C8-4DED-8E62-087C2B20AFE6@gmail.com> <87485148-2167-45A7-8298-FDE1A6C66B6F@gmail.com> Message-ID: On Tue, Jul 4, 2017 at 4:15 PM, Richard Wilbur wrote: > On Jul 4, 2017, at 02:27, Luke Kenneth Casson Leighton wrote: >> >> ok richard i've redone the layout, and published 3 images here: >> http://rhombus-tech.net/allwinner_a10/news/ > > Thanks for letting me know. I took an initial peek at the images and they look like you addressed the points I mentioned. yay > I'm going to be a day or two getting back with more detailed questions as today is a holiday here and we have family visiting till Thursday. nice > A couple questions that spring immediately to mind: > 1. How continuous are the ground planes under the differential pairs? (Are there voids in the ground planes under the differential pairs?) no. layers 2 and 5 are solid ground planes. vias obviously go through those , full vias only. non-GND vias also obviously create small interruptions but that's all > 2. The intra-pair length sounds well-matched, my understanding of the inter-pair skew is that the requirement is in terms of the clock speed Δt <= 0.2 Tcharacter. For 225 MHz clock the application note spoke of 888ps. So we'll be interested in determining the maximum clock rate and speed of propagation. 3e8 m/sec * 888e-12 = 0.2664 metres.... which is 266.4 mm... way beyond anything which would indicate some kind of problem if the board is 78mm long and the skew is only 2mm. > I'll also have some questions about dimensions and geometry. ack. > Thank you for the opportunity to participate. always appreciate the help. l. From calmstorm at posteo.de Tue Jul 4 17:28:00 2017 From: calmstorm at posteo.de (zap) Date: Tue, 4 Jul 2017 12:28:00 -0400 Subject: [Arm-netbook] systemd nonsense ad-infinitum In-Reply-To: <8760f8iqqt.fsf@whist.hands.com> References: <87a84mj584.fsf@whist.hands.com> <20170703184527.uzj3t2zoajwnnbxf@manillaroad.local.home.trueelena.org> <8760f8iqqt.fsf@whist.hands.com> Message-ID: Sorry but I have to challenge you on this, it isn't right for systemd to be the only init that can be used on debian by default. > There is no "forcing" or "requiring" involved, and people spouting this > bullshit is getting _really_ old now. > > If any such radical change had actually been enacted then: > > a) well, we'd be in a different universe, where Debian was run by some > sort of overlord who was prone to making snap decisions on a whim. > > b) there would have been a mass bug filing for all these packages that > did not require systemd, to somehow add that requirement. > > c) there would have then been a vast wave of new package uploads with > the new packages, encumbered with those requirements. > > NONE OF THIS HAPPENED. Incorrect sorry but I am not sure where you get your info from. > Debian didn't even make it so that other inits were somehow downgraded, > except for the fact that sysvinit is no longer the default on those > platforms where systemd actually exists (so on other platforms it's not > even the default, and most packages happily build on _all_ platforms, so > how does that sit in the same universe as one where systemd is "required"?) > > In fact Debian instead made efforts (much of the effort being done by > the Debian systemd maintainers) to make sure that is was actually rather > easier to switch between inits. The systemd folk even wrote extra code > to make sure that sysvinit and other inits could continue to support > programs where the upstreams have decided that they want to depend on > the services that systemd provides. That strikes me as above and beyond > the call of duty. > > What thanks do they get for it? > > They get unending inchoate screaming about how they are part of some > sort of global conspiracy, until they started burning out. > > The result being that they no longer have time, and certainly have no > inclination, to support systemd-shim, and the useless wankers that did > all the screaming of course cannot be arsed to put any effort into it, > so it's now rotting, and the chances of being able to continue using > other inits in Debian are now beginning to diminish. > > This is NOT because anyone forced anyone to do anything. > > If people were to decide not to post another anti-systemd rant, and > instead do something as trivial as reporting a single bug where > non-systemd-as-init was causing a problem, then there would be some hope > of making sure that other inits continue to work, but from what I can > see that is not happening. > > Instead people are spreading lies and scuttling off to the likes of > Devuan (who are also not addressing the issues, because they are not > improving application portability, because it's impossible to have > Devuan _with_ systemd). > > Also, note that Debian is still going to the effort of making choice > possible -- other ditros that switched have made the rather more > sensible choice of supporting only systemd, and thus saving themselves > the effort of supporting the minority inits. I really would like to see evidence of that. I tried to remove systemd on debian like three months ago for openrc and it dragged every bit of software off. So your thoughts are invalid sadly. > > I imagine that's why people are still bothering to attack Debian on this > since they imagine that there's a slim chance that we might switch > again, but what you have now is definitely the best you're going to get. > > As a parent of two small children I can tell you that screaming never > gets rewarded, and my children if they scream long enough will either > both lose the toy they are fighting over, or have something they like > even less happen to them -- I think that's pretty much the mindset that > most Debian Developers have adopted to people howling about systemd, so > be warned: > > Life can always get worse, and if you don't want that, stop screaming > and put some effort into building the world as you'd like it to exist. > > Cheers, Phil. >From your response, you seem to think I am anti systemd, and that anyone who disagrees with systemd is a child. That is an invalid argument. I don't want systemd to be my only option that's all. I will say it again, I have only known about systemd controversy for a few months, but I will tell you this, it seems like a dangerous idea for all distros to use the same init in case something goes wrong. and the code is taken advantage of. Aka, one distro gets hacked because of it, a domino effect if you would will happen. By the way, I can feel your anger from your response. I am quite calm right now. Just relax, you use what you want, we will use what we want. That is the code of open source and even more so, free software. From vkontogpls at gmail.com Tue Jul 4 18:01:54 2017 From: vkontogpls at gmail.com (Bill Kontos) Date: Tue, 4 Jul 2017 20:01:54 +0300 Subject: [Arm-netbook] systemd nonsense ad-infinitum In-Reply-To: References: <87a84mj584.fsf@whist.hands.com> <20170703184527.uzj3t2zoajwnnbxf@manillaroad.local.home.trueelena.org> <8760f8iqqt.fsf@whist.hands.com> Message-ID: On Tue, Jul 4, 2017 at 7:28 PM, zap wrote: > Sorry but I have to challenge you on this, it isn't right for systemd to > be the only init that can be used on debian by default. This doesn't make any sense. The default is what it is, a single option from a set of options that is the default one. There can only be one default. Not all sets of options can be selected on setup otherwise installing Debian would take longer than compiling gentoo. Systemd is apparently just the default option. And my problem is, people like you seem to believe that debian is some sort of organization that decides for the shake of their users. Wrong. Debian is a community first, if users want something, they can add it. There are alternative inits available but apparently nobody cares enough to maintain and script them. Which begs the question, why are systemd haters so vocal but do nothing about it ? It seems like those who actually did the work scripting for inits chose to work for systemd only, and now it's just a bunch of people who demand stuff without offering anything in return( i.e. work). From calmstorm at posteo.de Tue Jul 4 18:06:46 2017 From: calmstorm at posteo.de (zap) Date: Tue, 4 Jul 2017 13:06:46 -0400 Subject: [Arm-netbook] systemd nonsense ad-infinitum In-Reply-To: References: <87a84mj584.fsf@whist.hands.com> <20170703184527.uzj3t2zoajwnnbxf@manillaroad.local.home.trueelena.org> <8760f8iqqt.fsf@whist.hands.com> Message-ID: On 07/04/2017 01:01 PM, Bill Kontos wrote: > On Tue, Jul 4, 2017 at 7:28 PM, zap wrote: >> Sorry but I have to challenge you on this, it isn't right for systemd to >> be the only init that can be used on debian by default. > This doesn't make any sense. The default is what it is, a single > option from a set of options that is the default one. There can only > be one default. Not all sets of options can be selected on setup > otherwise installing Debian would take longer than compiling gentoo. Yes that didn't make sense my bad. I meant it shouldn't be the only one usable on debian. > Systemd is apparently just the default option. And my problem is, > people like you seem to believe that debian is some sort of > organization that decides for the shake of their users. Wrong. Debian > is a community first, if users want something, they can add it. There > are alternative inits available but apparently nobody cares enough to > maintain and script them. Which begs the question, why are systemd > haters so vocal but do nothing about it ? It seems like those who > actually did the work scripting for inits chose to work for systemd > only, and now it's just a bunch of people who demand stuff without > offering anything in return( i.e. work). > Openrc and Runit are better. In my humble opinion. again I am not anti-systemd I am for choice. > _______________________________________________ > arm-netbook mailing list arm-netbook at lists.phcomp.co.uk > http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook > Send large attachments to arm-netbook at files.phcomp.co.uk From laserhawk64 at gmail.com Tue Jul 4 18:07:33 2017 From: laserhawk64 at gmail.com (Christopher Havel) Date: Tue, 4 Jul 2017 13:07:33 -0400 Subject: [Arm-netbook] systemd nonsense ad-infinitum In-Reply-To: References: <87a84mj584.fsf@whist.hands.com> <20170703184527.uzj3t2zoajwnnbxf@manillaroad.local.home.trueelena.org> <8760f8iqqt.fsf@whist.hands.com> Message-ID: With all due respect, some people can't code. Do they not deserve a voice? From laserhawk64 at gmail.com Tue Jul 4 18:29:18 2017 From: laserhawk64 at gmail.com (Christopher Havel) Date: Tue, 4 Jul 2017 13:29:18 -0400 Subject: [Arm-netbook] systemd nonsense ad-infinitum In-Reply-To: References: <87a84mj584.fsf@whist.hands.com> <20170703184527.uzj3t2zoajwnnbxf@manillaroad.local.home.trueelena.org> <8760f8iqqt.fsf@whist.hands.com> Message-ID: To clarify... by "some people can't code" -- I not only mean the people who, in a literal sense, cannot write or read any programming language and therefore are unable to contribute, but also people like me who are truly awful at it and honestly should, for the sake of sanity in those who can program well, stay well away from anything even vaguely resembling a programming language. My, er, crowning achievement is an eight-room text adventure *that has no parser* -- it compares entire input strings without attempting to manipulate them. I wrote it in MS QuickBASIC PDS 7.1 on a 486 Toshiba about three or four years ago... mostly to see if I could actually do it. It took me *multiple weeks* to get it completely written and debugged, and it kind of pushed the envelope of what I could do with programming. If anyone actually wants the source code for it, I'll gladly put it up on PasteBin or any other suggested similar place, although I'll warn you, it'll probably give you hives. So, Mr Kontos *et al.*, what would you have me maintain, other than my distance from any mission-critical chunk of code...? ;) From njansen1 at gmail.com Tue Jul 4 18:43:11 2017 From: njansen1 at gmail.com (Neil Jansen) Date: Tue, 4 Jul 2017 13:43:11 -0400 Subject: [Arm-netbook] systemd nonsense ad-infinitum In-Reply-To: References: <87a84mj584.fsf@whist.hands.com> <20170703184527.uzj3t2zoajwnnbxf@manillaroad.local.home.trueelena.org> <8760f8iqqt.fsf@whist.hands.com> Message-ID: On Tue, Jul 4, 2017 at 1:07 PM, Christopher Havel wrote: > > With all due respect, some people can't code. Do they not deserve a voice? As far as Linux is concerned, no, they usually don't get a voice in how the software is written. Why would they? Volunteer programmers usually work on what *they* want, not what *others* want. If others find it useful, then great, and if they find bugs, then even better. But I don't think that very many loner programmers writing FOSS software these days are doing user studies and UX whiteboarding and all that. They're the exception, not the rule. Linux has always been a "my way or the highway (to look for another OSS alternative / distro)" type thing. In the past this worked pretty great, if people didn't like distro A it lost popularity to distro B, and life was good. I think the problem is that the ecosystem has gotten so big and so corporate that there's a bigger inequality between distros and software that have corporate support, and those that don't. That's a wild-ass generalization, but stop to think for a second at how many of the most popular distros right now are corporately backed or are using important bits of corporately backed software. Then look at how many Linux users are loading binary blobs like video drivers, wifi drivers, etc. I'd bet that the no-programming-experience end-user is MORE likely to load binary blobs, and they're MORE likely to run systemd without even knowing what the fuck a systemd is. Look at the Raspberry Pi as a primary example. I've got senior level principle engineers at my job that think that the Raspberry Pi is 100% open source, PCB's and all. Obviously not true but they've not even looked. They're living in a false reality, but that's OK for them, as long as they can use it as a Kodi server they're happy. These aren't dumb people. These are just people with a different set of priorities in life. So tl;dr, 'no-programming-experience' users don't get a voice in what gets written, but do get a voice in what software they run. But most don't really care, they just want free software that works, and aren't really in it for the philosophy that others espouse. ymmv. herding cats and all that. From laserhawk64 at gmail.com Tue Jul 4 18:53:36 2017 From: laserhawk64 at gmail.com (Christopher Havel) Date: Tue, 4 Jul 2017 13:53:36 -0400 Subject: [Arm-netbook] systemd nonsense ad-infinitum In-Reply-To: References: <87a84mj584.fsf@whist.hands.com> <20170703184527.uzj3t2zoajwnnbxf@manillaroad.local.home.trueelena.org> <8760f8iqqt.fsf@whist.hands.com> Message-ID: I think you and I will have to respectfully disagree. *Everyone* should have a voice. I may not be able to code, but I can still contribute in some way. Here's my other crowning achievement (IMO) -- a bug report where I got something major repaired. Partially I was lucky, because it was one of those 'this is boring' situations (faulty code was accepted without being properly examined, leading to a break in support), except someone stepped in externally, because they could, and sort of took over things and fixed them. https://bugs.freedesktop.org/show_bug.cgi?id=91966 Oh, right, length warning there. It took multiple *months* to get that thing untangled and working. Oh -- and, much to my chagrin, it still hasn't been picked up *to this day* by Debian, Ubuntu, and derivatives -- the very OSes it affects. Anything from about 2014 on has the defective version. (Last known-good config was Ubuntu Precise Pangolin!) It's been a year or two, you'd think they'd've gotten around to it by now... oh well, it's for a very particular set of rather-unpopular species of 32bit gear, so it probably won't matter much longer... support for 32bit gear is dropping like flies in a winter barn... From njansen1 at gmail.com Tue Jul 4 19:14:59 2017 From: njansen1 at gmail.com (Neil Jansen) Date: Tue, 4 Jul 2017 14:14:59 -0400 Subject: [Arm-netbook] systemd nonsense ad-infinitum In-Reply-To: References: <87a84mj584.fsf@whist.hands.com> <20170703184527.uzj3t2zoajwnnbxf@manillaroad.local.home.trueelena.org> <8760f8iqqt.fsf@whist.hands.com> Message-ID: On Jul 4, 2017 1:53 PM, "Christopher Havel" wrote: I think you and I will have to respectfully disagree. *Everyone* should have a voice. I never said whether those people "deserve" to have a voice or not. All I tried to explain was whether they actually have had one, matter of fact factly. And I don't think that I'm the least bit wrong in what I wrote. I have no business guessing what people "deserve", that's completey subjective. In philosophy, there's a huge difference between an "ought" and an "is", and objective reality will almost always end up leaning towards the latter. From laserhawk64 at gmail.com Tue Jul 4 19:20:24 2017 From: laserhawk64 at gmail.com (Christopher Havel) Date: Tue, 4 Jul 2017 14:20:24 -0400 Subject: [Arm-netbook] systemd nonsense ad-infinitum In-Reply-To: References: <87a84mj584.fsf@whist.hands.com> <20170703184527.uzj3t2zoajwnnbxf@manillaroad.local.home.trueelena.org> <8760f8iqqt.fsf@whist.hands.com> Message-ID: Fair enough... although it seems to me that, as (I would hope) good-natured humans, we should all endeavor to bring the "is" at least a little closer to the "ought"... From vkontogpls at gmail.com Tue Jul 4 19:20:43 2017 From: vkontogpls at gmail.com (Bill Kontos) Date: Tue, 4 Jul 2017 21:20:43 +0300 Subject: [Arm-netbook] systemd nonsense ad-infinitum In-Reply-To: References: <87a84mj584.fsf@whist.hands.com> <20170703184527.uzj3t2zoajwnnbxf@manillaroad.local.home.trueelena.org> <8760f8iqqt.fsf@whist.hands.com> Message-ID: On Tue, Jul 4, 2017 at 8:29 PM, Christopher Havel wrote: > > So, Mr Kontos *et al.*, what would you have me maintain, other than my > distance from any mission-critical chunk of code...? ;) I'm in the same boat as you. Money. Something that you want to happen isn't happening, ask around gouge interest and invest in development of the alternatives you like. From laserhawk64 at gmail.com Tue Jul 4 19:23:33 2017 From: laserhawk64 at gmail.com (Christopher Havel) Date: Tue, 4 Jul 2017 14:23:33 -0400 Subject: [Arm-netbook] systemd nonsense ad-infinitum In-Reply-To: References: <87a84mj584.fsf@whist.hands.com> <20170703184527.uzj3t2zoajwnnbxf@manillaroad.local.home.trueelena.org> <8760f8iqqt.fsf@whist.hands.com> Message-ID: Money? I ain't got that. Somebody else wants to pay, that's different... but me, well... let's just say that the moth in my wallet up and died. From valhalla-l at trueelena.org Tue Jul 4 19:36:37 2017 From: valhalla-l at trueelena.org (Elena ``of Valhalla'') Date: Tue, 4 Jul 2017 20:36:37 +0200 Subject: [Arm-netbook] systemd nonsense ad-infinitum In-Reply-To: References: <20170703184527.uzj3t2zoajwnnbxf@manillaroad.local.home.trueelena.org> <8760f8iqqt.fsf@whist.hands.com> Message-ID: <20170704183637.3lfjmwjaigixqqzp@manillaroad.local.home.trueelena.org> On 2017-07-04 at 13:07:33 -0400, Christopher Havel wrote: > With all due respect, some people can't code. Do they not deserve a voice? In the past, the FLOSS community was pretty bad at only valuing contributions that involved writing code, and ignoring pretty much everything else. Nowadays, it depends a lot on which community you are involved with: some are still of the idea that only code matters, but many more recognise that software alone has limited usefulness, and that many other kinds of contributions are just as important. Debian these days is one such community (see e.g. https://www.debian.org/intro/diversity and https://contributors.debian.org/ and http://www.enricozini.org/blog/2012/debian/more-diversity-in-skills/ for some background on the latter), and while being somewhat technically minded is helpful in finding something to contribute on, actual writing of code is a minority of the available tasks. One think that is *very* helpful is testing stuff, especially when using rare configurations, and opening bugs when something isn't working as expected. It is true that does not always mean that they are going to be fixed, but it is still useful. * if there is no open bug on the bugtracker you can be 99% that it won't be fixed, opening the bug significantly raises the chances for a fix, even if it's not a guantee. * by opening the bug you are showing that somebody is actually using that program/feature: sometimes minor stuff that the maintainers don't really care about are taking lots of their effort, and if they don't even know if anybody cares about it they are much more likely to just drop worrying about it. * Not just the package maintainers see the bugs on their packages: sometimes other people notice them and may get involved and provide a patch, even if they are not the bug opener themselves. While doing so, remember that (in the case of Debian) you're probably requesting somebody to do something in their spare time, so they may not answer immediately (or in the next week), and maybe the answer will be that they can't fix the bug unless somebody else comes with a patch, but being nice in the request usually leads to receiving nice answers. I agree that it's not a task suitable to anybody as it does require at least a bit of proficiency in using linux systems and the ability to follow instructions (probably involving the command line) to provide more data if needed, but the set of people being able to to so should be much bigger than the set of people who are able to succefully patch some random code. -- Elena ``of Valhalla'' From hendrik at topoi.pooq.com Tue Jul 4 19:39:17 2017 From: hendrik at topoi.pooq.com (Hendrik Boom) Date: Tue, 4 Jul 2017 14:39:17 -0400 Subject: [Arm-netbook] systemd nonsense ad-infinitum In-Reply-To: References: <20170703184527.uzj3t2zoajwnnbxf@manillaroad.local.home.trueelena.org> <8760f8iqqt.fsf@whist.hands.com> Message-ID: <20170704183917.GA23522@topoi.pooq.com> On Tue, Jul 04, 2017 at 08:01:54PM +0300, Bill Kontos wrote: > It seems like those who > actually did the work scripting for inits chose to work for systemd > only, and now it's just a bunch of people who demand stuff without > offering anything in return( i.e. work). As I heard it, the disputes about systemd on the Debian mailing lists got so vicious that those who didn't want systemd left and went elsewhere to contribute. --- hendrik From valhalla-l at trueelena.org Tue Jul 4 21:03:34 2017 From: valhalla-l at trueelena.org (Elena ``of Valhalla'') Date: Tue, 4 Jul 2017 22:03:34 +0200 Subject: [Arm-netbook] systemd nonsense ad-infinitum In-Reply-To: <20170704183917.GA23522@topoi.pooq.com> References: <20170703184527.uzj3t2zoajwnnbxf@manillaroad.local.home.trueelena.org> <8760f8iqqt.fsf@whist.hands.com> <20170704183917.GA23522@topoi.pooq.com> Message-ID: <20170704200334.sfkrfn73ep5ze2nd@manillaroad.local.home.trueelena.org> On 2017-07-04 at 14:39:17 -0400, Hendrik Boom wrote: > On Tue, Jul 04, 2017 at 08:01:54PM +0300, Bill Kontos wrote: > > It seems like those who > > actually did the work scripting for inits chose to work for systemd > > only, and now it's just a bunch of people who demand stuff without > > offering anything in return( i.e. work). > > As I heard it, the disputes about systemd on the Debian mailing > lists got so vicious that those who didn't want systemd left and > went elsewhere to contribute. well, the disputes got vicious, and I admit that I skipped reading most of it for my own sanity. At least on IRC, however, most of the viciousness seemed to come from the non-systemd camp; it can be true that they alienated the people who may have wanted to help supporting other systems, but making them not want to be on the same side of those people, but blaming the systemd-supporting debian community for their actions doesn't sound right. I say seemed, however, because at least in the worst cases the pattern of behaviour were more suggestive of a troll trying to stir up controversy for its own sake (or for some other reason) rather than somebody honestly concerned with systemd, and that surely helped muddle things further. -- Elena ``of Valhalla'' From phil at hands.com Tue Jul 4 22:50:34 2017 From: phil at hands.com (Philip Hands) Date: Tue, 04 Jul 2017 23:50:34 +0200 Subject: [Arm-netbook] systemd nonsense ad-infinitum In-Reply-To: References: <87a84mj584.fsf@whist.hands.com> <20170703184527.uzj3t2zoajwnnbxf@manillaroad.local.home.trueelena.org> <8760f8iqqt.fsf@whist.hands.com> Message-ID: <87wp7nhnx1.fsf@whist.hands.com> zap writes: > Sorry but I have to challenge you on this, it isn't right for systemd to > be the only init that can be used on debian by default. >> There is no "forcing" or "requiring" involved, and people spouting this >> bullshit is getting _really_ old now. >> >> If any such radical change had actually been enacted then: >> >> a) well, we'd be in a different universe, where Debian was run by some >> sort of overlord who was prone to making snap decisions on a whim. >> >> b) there would have been a mass bug filing for all these packages that >> did not require systemd, to somehow add that requirement. >> >> c) there would have then been a vast wave of new package uploads with >> the new packages, encumbered with those requirements. >> >> NONE OF THIS HAPPENED. > > Incorrect sorry but I am not sure where you get your info from. I'm not sure what you're expecting me to say. I pay attention to the uploads. I've been a Debian Developer for over 2 decades. I was there since before all this started on the mailing lists. I'm vaguely aware of the extent to which things depend on things. Actually, let's try a very rough estimate on "stretch" (the new release): for p in systemd libsystemd0 libselinux1 libc6 ; \ do apt-cache rdepends \ --no-suggests --no-conflicts --no-breaks --no-replaces $p \ | grep '^ ' | sort -u | wc -l ; \ done 34 144 133 19816 Note that libselinux1 (which is pretty much equivalent to libsystemd0 in its purpose) is almost as widely depended upon as libsystemd0, and that they are both two orders of magnitude less depended upon than libc6. _That_ is why I reacted badly to your "forced to require" assertion. I'll admit that there are recursive dependencies that spread that net quite a lot wider, but also those numbers include the likes of sogo where the dependency is: Depends: libc6 (>= 2.14), libcurl3-gnutls (>= 7.16.2), libgcc1 (>= 1:3.0), libglib2.0-0 (>= 2.14.0), libgnustep-base1.24 (>= 1.24.7), libgnutls30 (>= 3.5.0), liblasso3 (>= 2.5.0), libmemcached11, libobjc4 (>= 4.6), libsbjson2.3, libsope1 (>= 3.2.6), init-system-helpers (>= 1.18~), tmpreaper | systemd, sogo-common (= 3.2.6-2), adduser, zip, lsb-base (>= 3.0-6) so here systemd is depended upon only as an alternative to tmpreaper. If you want better numbers, feel free to work them out yourself, but I'd hope that you'll manage to understand from this that there has not been a policy change to "force" packages to "require" (or as we'd call it "depend") upon systemd, or even libsystemd0. Oh, and not that it matters, as I wasn't there when the Debian Technical Committee made its decision to choose systemd as the default, but I would have made the same decision if I had been on the committee then, and these days I am: https://www.debian.org/intro/organization#tech-ctte so, if that doesn't qualify me to comment on happenings in Debian in your eyes, I'm not quite sure what would. Cheers, Phil. -- |)| Philip Hands [+44 (0)20 8530 9560] HANDS.COM Ltd. |-| http://www.hands.com/ http://ftp.uk.debian.org/ |(| Hugo-Klemm-Strasse 34, 21075 Hamburg, GERMANY From calmstorm at posteo.de Wed Jul 5 01:43:12 2017 From: calmstorm at posteo.de (zap) Date: Tue, 4 Jul 2017 20:43:12 -0400 Subject: [Arm-netbook] systemd nonsense ad-infinitum In-Reply-To: <87wp7nhnx1.fsf@whist.hands.com> References: <87a84mj584.fsf@whist.hands.com> <20170703184527.uzj3t2zoajwnnbxf@manillaroad.local.home.trueelena.org> <8760f8iqqt.fsf@whist.hands.com> <87wp7nhnx1.fsf@whist.hands.com> Message-ID: <032ece02-42db-d79f-7149-1b3bee9cd940@posteo.de> > I'm not sure what you're expecting me to say. > > I pay attention to the uploads. > > I've been a Debian Developer for over 2 decades. > > I was there since before all this started on the mailing lists. > > I'm vaguely aware of the extent to which things depend on things. > > Actually, let's try a very rough estimate on "stretch" (the new release): > > for p in systemd libsystemd0 libselinux1 libc6 ; \ > do apt-cache rdepends \ > --no-suggests --no-conflicts --no-breaks --no-replaces $p \ > | grep '^ ' | sort -u | wc -l ; \ > done > 34 > 144 > 133 > 19816 > > Note that libselinux1 (which is pretty much equivalent to libsystemd0 in > its purpose) is almost as widely depended upon as libsystemd0, and that > they are both two orders of magnitude less depended upon than libc6. > > _That_ is why I reacted badly to your "forced to require" assertion. > > I'll admit that there are recursive dependencies that spread that net > quite a lot wider, but also those numbers include the likes of sogo > where the dependency is: > > Depends: libc6 (>= 2.14), libcurl3-gnutls (>= 7.16.2), libgcc1 (>= > 1:3.0), libglib2.0-0 (>= 2.14.0), libgnustep-base1.24 (>= 1.24.7), > libgnutls30 (>= 3.5.0), liblasso3 (>= 2.5.0), libmemcached11, libobjc4 > (>= 4.6), libsbjson2.3, libsope1 (>= 3.2.6), init-system-helpers (>= > 1.18~), tmpreaper | systemd, sogo-common (= 3.2.6-2), adduser, zip, > lsb-base (>= 3.0-6) > > so here systemd is depended upon only as an alternative to tmpreaper. > > If you want better numbers, feel free to work them out yourself, but I'd > hope that you'll manage to understand from this that there has not been > a policy change to "force" packages to "require" (or as we'd call it > "depend") upon systemd, or even libsystemd0. > > Oh, and not that it matters, as I wasn't there when the Debian Technical > Committee made its decision to choose systemd as the default, but I > would have made the same decision if I had been on the committee then, > and these days I am: > > https://www.debian.org/intro/organization#tech-ctte > > so, if that doesn't qualify me to comment on happenings in Debian in > your eyes, I'm not quite sure what would. > > Cheers, Phil. Well, it least you were more civil about it. I do think that openrc or runit should have at least been on the table for a vote. Although, I am curious why you think that runit-init is no longer a package on debian. I am curious to why that package was taken down. I will stick to devuan though and you I am sure will stick to debian. That's about it. From james6.28318530 at gmail.com Wed Jul 5 05:48:31 2017 From: james6.28318530 at gmail.com (James L) Date: Wed, 5 Jul 2017 00:48:31 -0400 Subject: [Arm-netbook] Init Freedom In-Reply-To: References: <87a84mj584.fsf@whist.hands.com> <20170704014107.GA10936@topoi.pooq.com> <20170704071700.mlaii6kcmdbxuxai@lemon.cohens.org.il> Message-ID: <5ba9e211-c058-dffd-e130-ac0848ff2a85@gmail.com> > their stated mission statement is "to give people free choice over > their init service". and... err... the lack of support for systemd > makes that mission statement a false statement. I wondered about this, so I am going to try a comprehensive analysis of their website (irrelevant analysis is cut) Main page mentions the "Exodus declaration in 2014" The original declaration says "produce a reliable and minimalist base distribution that stays away from the... lock-in promoted by systemd." The original goal was to prevent lock-in, huh? Also: "Among the priorities are: enable diversity... for the existing Debian downstream *willing to preserve Init Freedom*." That implies systemd is not part of "Init Freedom," since, according to that, if downstream stayed with Debian (and systemd) they would not be preserving Init Freedom The main page mentions "the right to Init Freedom" and has a link... "Init Freedom is about restoring a sane approach to PID1, **one that respects diversity and freedom of choice**." The rest of the page is irrelevant. I wish they would define "Init freedom." The closest thing to a definition is the last quote (above) So it seems that systemd is explicitly excluded from Init Freedom (which is *defined* as respecting freedom of choice) and therefore I cannot disagree with your statement > if they were true to their mission statement they would add the > option to include it. Unfortunately, I have to agree Here is a question: Is a false (in any way) mission statement enough to totally dismiss something? Even if their actions (providing a reasonable alternative) are seemingly good? >From what I have observed, you seem to have two "codes" that you live by, your ethics and your intuition. Your ethics seems to mostly involve your influence over others, so what does your intuition say about Devuan? From lkcl at lkcl.net Wed Jul 5 06:00:39 2017 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Wed, 5 Jul 2017 06:00:39 +0100 Subject: [Arm-netbook] systemd nonsense ad-infinitum In-Reply-To: <20170704200334.sfkrfn73ep5ze2nd@manillaroad.local.home.trueelena.org> References: <20170703184527.uzj3t2zoajwnnbxf@manillaroad.local.home.trueelena.org> <8760f8iqqt.fsf@whist.hands.com> <20170704183917.GA23522@topoi.pooq.com> <20170704200334.sfkrfn73ep5ze2nd@manillaroad.local.home.trueelena.org> Message-ID: On Tue, Jul 4, 2017 at 9:03 PM, Elena ``of Valhalla'' wrote: > I say seemed, however, because at least in the worst cases the pattern > of behaviour were more suggestive of a troll trying to stir up > controversy for its own sake (or for some other reason) rather than > somebody honestly concerned with systemd, and that surely helped muddle > things further. yyeah this is the most unfortunate / fortunate aspect of what happened. a massive proportion of people in the software libre community (particularly debian) knew that something felt... wrong... but were completely ill-equipped to *both* identify it *and* express it. where the primary focus was on engineering, where you *absolutely must* be capable of expressing precisely and exactly what is wrong, a "this doesn't feel right" feeling would *of course* be outright rejected with "please provide evidence / proof". not only that but people would have felt totally uncomfortable expressing their true views and feelings (even if they truly had a way to express them without causing upset / offense / whatever). "i feel totally betrayed by your democratic majority-vote-style decision [which e.g. forces me to spend hundreds of hours converting live-running systems to a new distro]" is not something that can be bug-fixed. so yes, the end-result, elena, would have been what you witnessed. why describe this as "fortunate"? because it identifies a flaw within the software libre community that, one might hope, everyone can learn from. l. From lkcl at lkcl.net Wed Jul 5 06:35:06 2017 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Wed, 5 Jul 2017 06:35:06 +0100 Subject: [Arm-netbook] systemd nonsense ad-infinitum In-Reply-To: <87wp7nhnx1.fsf@whist.hands.com> References: <87a84mj584.fsf@whist.hands.com> <20170703184527.uzj3t2zoajwnnbxf@manillaroad.local.home.trueelena.org> <8760f8iqqt.fsf@whist.hands.com> <87wp7nhnx1.fsf@whist.hands.com> Message-ID: --- crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68 On Tue, Jul 4, 2017 at 10:50 PM, Philip Hands wrote: > zap writes: > >> Sorry but I have to challenge you on this, it isn't right for systemd to >> be the only init that can be used on debian by default. >>> There is no "forcing" or "requiring" involved, and people spouting this >>> bullshit is getting _really_ old now. >>> >>> If any such radical change had actually been enacted then: >>> >>> a) well, we'd be in a different universe, where Debian was run by some >>> sort of overlord who was prone to making snap decisions on a whim. >>> >>> b) there would have been a mass bug filing for all these packages that >>> did not require systemd, to somehow add that requirement. >>> >>> c) there would have then been a vast wave of new package uploads with >>> the new packages, encumbered with those requirements. >>> >>> NONE OF THIS HAPPENED. >> >> Incorrect sorry but I am not sure where you get your info from. > > I'm not sure what you're expecting me to say. > > I pay attention to the uploads. > > I've been a Debian Developer for over 2 decades. > > I was there since before all this started on the mailing lists. > > I'm vaguely aware of the extent to which things depend on things. > > Actually, let's try a very rough estimate on "stretch" (the new release): > > for p in systemd libsystemd0 libselinux1 libc6 ; \ > do apt-cache rdepends \ > --no-suggests --no-conflicts --no-breaks --no-replaces $p \ > | grep '^ ' | sort -u | wc -l ; \ > done > 34 > 144 > 133 > 19816 > > Note that libselinux1 (which is pretty much equivalent to libsystemd0 in > its purpose) is almost as widely depended upon as libsystemd0, and that > they are both two orders of magnitude less depended upon than libc6. i've mentioned it a number of times: the difference between libsystemd0 and libselinux1 (both of which remain "dormant" if not actually utilised) is that selinux is developed under the auspices of the NSA's guidance according to an extremely stable and trustworthy process. by complete contrast systemd is *literally* developed under the complete and total opposite ethos in *every* single way conceivable [only one aspect of which is the actual resultant "code"]. i believe it's safe to say that the NSA can actually be trusted in its core area of expertise: security. they began by sponsoring a university research initiative, which came up with the FLASK model. a roadmap and a series of papers were developed long before any code was written, allowing interested people with a particular interest in high security to comment and contribute. the scope of the project was well-defined right from the beginning and *has not changed*. any extensions that are added (such as the xorg extensions) are done so in a non-intrusive and optional fashion. more than that: the developers who are involved in it are sensible, highly competent, respectful, respect-worthy and, from the evidence of their ongoing behaviour, clearly trust-worthy people. manoj srivastava and stephen smalley are just two that, with my vague memory being what it is, that i can remember their names after never having spoken to them for over ten years should underscore how much of a lasting impression just those two peoples' competence has made on me. now, for everything in that paragraph above, write something in your own mind that takes every positive statement and replace it with the total opposite. then substitute "pottering" for "NSA". i won't do it for you, because i don't wish to be the one writing what could easily be interpreted as utter hateful vitriol. *this* is why people do not wish to have code written by and being actively developed by pottering on their systems. i keep emphasising: it's not actually about the code: it's about much, much more than that. and that's why (phil) when you say things along the lines of "give me one good reason why..." and it involves an *actual specific code-related issue*, i feel compelled to point out that it's the wrong question to be asking / wrong approach to be taking. so this is why people - who do not have sufficient expertise to "code their way out of the problem", and/or do not have the expertise to package alternative init-systems and/or who do not have the time/resources to risk converting to a totally new distro - still want to be able to *completely* remove systemd i.e do "apt-get --purge remove libsystemd0" and still retain a fully-functional *debian* system [not a devuan system] because of all the advantages, cost-savings and so on of doing so. this is so hard to explain succinctly. l. From lkcl at lkcl.net Wed Jul 5 06:37:39 2017 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Wed, 5 Jul 2017 06:37:39 +0100 Subject: [Arm-netbook] systemd nonsense ad-infinitum In-Reply-To: <032ece02-42db-d79f-7149-1b3bee9cd940@posteo.de> References: <87a84mj584.fsf@whist.hands.com> <20170703184527.uzj3t2zoajwnnbxf@manillaroad.local.home.trueelena.org> <8760f8iqqt.fsf@whist.hands.com> <87wp7nhnx1.fsf@whist.hands.com> <032ece02-42db-d79f-7149-1b3bee9cd940@posteo.de> Message-ID: --- crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68 On Wed, Jul 5, 2017 at 1:43 AM, zap wrote: > Well, it least you were more civil about it. zap, phil, et al: i must apologise, the less-than-civil tone is my fault. i began this thread from a position of frustration and pissed-off-ness. slowly over time however these discussions are helping me to be able to both understand and vocalise things without the frustration and pissed-off-ness. so i apologise, and at the same time am extremely grateful for everyone's participation. l. From lkcl at lkcl.net Wed Jul 5 06:48:08 2017 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Wed, 5 Jul 2017 06:48:08 +0100 Subject: [Arm-netbook] Init Freedom In-Reply-To: <5ba9e211-c058-dffd-e130-ac0848ff2a85@gmail.com> References: <87a84mj584.fsf@whist.hands.com> <20170704014107.GA10936@topoi.pooq.com> <20170704071700.mlaii6kcmdbxuxai@lemon.cohens.org.il> <5ba9e211-c058-dffd-e130-ac0848ff2a85@gmail.com> Message-ID: --- crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68 On Wed, Jul 5, 2017 at 5:48 AM, James L wrote: >> if they were true to their mission statement they would add the >> option to include it. > > Unfortunately, I have to agree i spoke to one of the people in devuan, who turned out to be an amazingly wise person, and i was able to point out this discrepancy to them without over-reaction. i suggested to them that it might be a good idea to properly honour the mission statement by including systemd in devuan. their response was that in their opinion it simply would never happen, ever. devuan was *geniunely* born out of a back-lash reaction *against* systemd.. *not* out of a desire to genuinely honour their mission statement. > Here is a question: Is a false (in any way) mission statement enough to > totally dismiss something? Even if their actions (providing a reasonable > alternative) are seemingly good? *sigh* i love what they've done, but the best way to illustrate it is with a story from mother theresa. she was invited to an anti-war rally, once. she declined... and told them that if they ever wanted to hold a *peace* rally, she would be delighted to attend. that really says it all, i think. > From what I have observed, you seem to have two "codes" that you live > by, your ethics and your intuition. ha. to clarify: i use my intuition to identify those things which are ethical [and then follow up with as much rational / logical reasoning as i can stand]. where i really didn't even have a definition of what is actually ethical until i encountered bob podolski, only last year. ironic or what... :) > Your ethics seems to mostly involve > your influence over others, so what does your intuition say about Devuan? jury's still out. i'm hopeful that one day they'll be able to resolve the conflict and truly honour their mission statement. for myself i... i simply cannot bring myself to endorse or support things where there exists a huge cognitive dissonance. call it an ISO9001 "fail" if you will. l. From calmstorm at posteo.de Wed Jul 5 12:50:50 2017 From: calmstorm at posteo.de (zap) Date: Wed, 5 Jul 2017 07:50:50 -0400 Subject: [Arm-netbook] systemd nonsense ad-infinitum In-Reply-To: References: <87a84mj584.fsf@whist.hands.com> <20170703184527.uzj3t2zoajwnnbxf@manillaroad.local.home.trueelena.org> <8760f8iqqt.fsf@whist.hands.com> <87wp7nhnx1.fsf@whist.hands.com> <032ece02-42db-d79f-7149-1b3bee9cd940@posteo.de> Message-ID: <1ee06f5f-27af-3c58-d081-e9a9d4532f2a@posteo.de> On 07/05/2017 01:37 AM, Luke Kenneth Casson Leighton wrote: > --- > crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68 > > > On Wed, Jul 5, 2017 at 1:43 AM, zap wrote: > >> Well, it least you were more civil about it. > zap, phil, et al: i must apologise, the less-than-civil tone is my > fault. i began this thread from a position of frustration and > pissed-off-ness. > > slowly over time however these discussions are helping me to be able > to both understand and vocalise things without the frustration and > pissed-off-ness. > > so i apologise, and at the same time am extremely grateful for > everyone's participation. > > l. Well, I wasn't talking about you that time, but yeah we all need to just calm down and look carefully at what is going on here without eyes of hate. If possible I mean. From phil at hands.com Wed Jul 5 18:49:11 2017 From: phil at hands.com (Philip Hands) Date: Wed, 05 Jul 2017 19:49:11 +0200 Subject: [Arm-netbook] severe systemd bugs (two of them) In-Reply-To: References: <20170703184527.uzj3t2zoajwnnbxf@manillaroad.local.home.trueelena.org> <20170704065540.kbeapvi3n3yp47hd@lemon.cohens.org.il> <20170704094237.mgvdeockbwoiujrw@manillaroad.local.home.trueelena.org> Message-ID: <87r2xuhizs.fsf@whist.hands.com> Luke Kenneth Casson Leighton writes: > On Tue, Jul 4, 2017 at 10:42 AM, Elena ``of Valhalla'' ... > the heavy usage of d-bus for the openmoko OS basically was part of > what killed the project. it would not surprise me at all to find that > d-bus is similarly slowing systemd down when compared to other init > systems. The way that d-bus was used in OpenMoko was astonishing, and is really not something one can use to criticise d-bus in general. Not that I'm trying to say that d-bus is particulalry lovely, but what you're doing here is like saying that micrometer screw guages are rubbish becuase you once saw someone using one as a hammer, and they hurt their thumb. The program that ran most of OpenMoko was written on the assumption that it would be very soon replaced by separate components that would all pass messages around via d-bus (a stupid design, given the hardware), then time ran out and that prototype was what shipped. The result being that if one got an incoming call, it would provoke a cascade of (IIRC 7) d-bus interactions that were all being answered by call-backs in the single program that was doing everything. Each one went via a kernel context switch (or two?), dumping the cache, and that meant that it would take at least 5 seconds for the ringer to start ringing after a call came in, a few more seconds to show you the screen with the answer button, a second or two for your mad tapping to be noticed, during which the accelerometer would realise that it needed to swap portrait for landscape (repainting the "cancel" button where the "answer" used to be) and then finally it would process your demented attempts to answer the sodding thing as a call rejection. Marvelous. Enrico Zini worked all that out, and then knocked up a very short script that waited for calls, made the ringer ring, and looked out for a button press on the physical button -- that allowed it to behave quite like a phone with no fuss. If anyone wants an OpenMoko, I have one going cheap :-/ Cheers, Phil. -- |)| Philip Hands [+44 (0)20 8530 9560] HANDS.COM Ltd. |-| http://www.hands.com/ http://ftp.uk.debian.org/ |(| Hugo-Klemm-Strasse 34, 21075 Hamburg, GERMANY From lkcl at lkcl.net Thu Jul 6 06:21:50 2017 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Thu, 6 Jul 2017 06:21:50 +0100 Subject: [Arm-netbook] severe systemd bugs (two of them) In-Reply-To: <87r2xuhizs.fsf@whist.hands.com> References: <20170703184527.uzj3t2zoajwnnbxf@manillaroad.local.home.trueelena.org> <20170704065540.kbeapvi3n3yp47hd@lemon.cohens.org.il> <20170704094237.mgvdeockbwoiujrw@manillaroad.local.home.trueelena.org> <87r2xuhizs.fsf@whist.hands.com> Message-ID: On Wed, Jul 5, 2017 at 6:49 PM, Philip Hands wrote: > The program that ran most of OpenMoko was written on the assumption that > it would be very soon replaced by separate components that would all > pass messages around via d-bus ah! 12+ years i'm glad someone remembers. i got the trolltech greenphone, not an openmoko > The result being that if one got an incoming call, it would provoke a > cascade of (IIRC 7) d-bus interactions that were all being answered by > call-backs in the single program that was doing everything. Each one > went via a kernel context switch (or two?), dumping the cache, and that > meant that it would take at least 5 seconds for the ringer to start > ringing after a call came in, a few more seconds to show you the screen > with the answer button, ... which was painted with x11 so that meant many more more context-switches and cache-dumps because x11 is a client-server architecture... > a second or two for your mad tapping to be > noticed, during which the accelerometer would realise that it needed to > swap portrait for landscape (repainting the "cancel" button where the > "answer" used to be) and then finally it would process your demented > attempts to answer the sodding thing as a call rejection. Marvelous. ... didn't you have call-forwarding such that there wasn't enough time to actually answer the call anyway? :) > Enrico Zini worked all that out, and then knocked up a very short script > that waited for calls, made the ringer ring, and looked out for a button > press on the physical button -- that allowed it to behave quite like a > phone with no fuss. dang. *sigh* nokia's low-cost mobile phone OS (symbian?) at least was well-designed (or, designed for purpose). > If anyone wants an OpenMoko, I have one going cheap :-/ ah that would be good to use for the GTA04 motherboard replacement oh wait damnit that didn't go so well, they used a package-on-package TI SoC and DDR sandwich, where the processor was only designed for very specialist mass-volume manufacturing, was made too thin (to save cost) and warps under standard PCB assembly (ovens)... they got something like a SEVENTY SEVEN PERCENT failure rate during a pre-production manufacturing run. http://laforge.gnumonks.org/blog/20170306-gta04-omap3_pop_soldering/ l. From lkcl at lkcl.net Thu Jul 6 06:21:50 2017 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Thu, 6 Jul 2017 06:21:50 +0100 Subject: [Arm-netbook] severe systemd bugs (two of them) In-Reply-To: <87r2xuhizs.fsf@whist.hands.com> References: <20170703184527.uzj3t2zoajwnnbxf@manillaroad.local.home.trueelena.org> <20170704065540.kbeapvi3n3yp47hd@lemon.cohens.org.il> <20170704094237.mgvdeockbwoiujrw@manillaroad.local.home.trueelena.org> <87r2xuhizs.fsf@whist.hands.com> Message-ID: On Wed, Jul 5, 2017 at 6:49 PM, Philip Hands wrote: > The program that ran most of OpenMoko was written on the assumption that > it would be very soon replaced by separate components that would all > pass messages around via d-bus ah! 12+ years i'm glad someone remembers. i got the trolltech greenphone, not an openmoko > The result being that if one got an incoming call, it would provoke a > cascade of (IIRC 7) d-bus interactions that were all being answered by > call-backs in the single program that was doing everything. Each one > went via a kernel context switch (or two?), dumping the cache, and that > meant that it would take at least 5 seconds for the ringer to start > ringing after a call came in, a few more seconds to show you the screen > with the answer button, ... which was painted with x11 so that meant many more more context-switches and cache-dumps because x11 is a client-server architecture... > a second or two for your mad tapping to be > noticed, during which the accelerometer would realise that it needed to > swap portrait for landscape (repainting the "cancel" button where the > "answer" used to be) and then finally it would process your demented > attempts to answer the sodding thing as a call rejection. Marvelous. ... didn't you have call-forwarding such that there wasn't enough time to actually answer the call anyway? :) > Enrico Zini worked all that out, and then knocked up a very short script > that waited for calls, made the ringer ring, and looked out for a button > press on the physical button -- that allowed it to behave quite like a > phone with no fuss. dang. *sigh* nokia's low-cost mobile phone OS (symbian?) at least was well-designed (or, designed for purpose). > If anyone wants an OpenMoko, I have one going cheap :-/ ah that would be good to use for the GTA04 motherboard replacement oh wait damnit that didn't go so well, they used a package-on-package TI SoC and DDR sandwich, where the processor was only designed for very specialist mass-volume manufacturing, was made too thin (to save cost) and warps under standard PCB assembly (ovens)... they got something like a SEVENTY SEVEN PERCENT failure rate during a pre-production manufacturing run. http://laforge.gnumonks.org/blog/20170306-gta04-omap3_pop_soldering/ l. From lkcl at lkcl.net Thu Jul 6 06:21:50 2017 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Thu, 6 Jul 2017 06:21:50 +0100 Subject: [Arm-netbook] severe systemd bugs (two of them) In-Reply-To: <87r2xuhizs.fsf@whist.hands.com> References: <20170703184527.uzj3t2zoajwnnbxf@manillaroad.local.home.trueelena.org> <20170704065540.kbeapvi3n3yp47hd@lemon.cohens.org.il> <20170704094237.mgvdeockbwoiujrw@manillaroad.local.home.trueelena.org> <87r2xuhizs.fsf@whist.hands.com> Message-ID: On Wed, Jul 5, 2017 at 6:49 PM, Philip Hands wrote: > The program that ran most of OpenMoko was written on the assumption that > it would be very soon replaced by separate components that would all > pass messages around via d-bus ah! 12+ years i'm glad someone remembers. i got the trolltech greenphone, not an openmoko > The result being that if one got an incoming call, it would provoke a > cascade of (IIRC 7) d-bus interactions that were all being answered by > call-backs in the single program that was doing everything. Each one > went via a kernel context switch (or two?), dumping the cache, and that > meant that it would take at least 5 seconds for the ringer to start > ringing after a call came in, a few more seconds to show you the screen > with the answer button, ... which was painted with x11 so that meant many more more context-switches and cache-dumps because x11 is a client-server architecture... > a second or two for your mad tapping to be > noticed, during which the accelerometer would realise that it needed to > swap portrait for landscape (repainting the "cancel" button where the > "answer" used to be) and then finally it would process your demented > attempts to answer the sodding thing as a call rejection. Marvelous. ... didn't you have call-forwarding such that there wasn't enough time to actually answer the call anyway? :) > Enrico Zini worked all that out, and then knocked up a very short script > that waited for calls, made the ringer ring, and looked out for a button > press on the physical button -- that allowed it to behave quite like a > phone with no fuss. dang. *sigh* nokia's low-cost mobile phone OS (symbian?) at least was well-designed (or, designed for purpose). > If anyone wants an OpenMoko, I have one going cheap :-/ ah that would be good to use for the GTA04 motherboard replacement oh wait damnit that didn't go so well, they used a package-on-package TI SoC and DDR sandwich, where the processor was only designed for very specialist mass-volume manufacturing, was made too thin (to save cost) and warps under standard PCB assembly (ovens)... they got something like a SEVENTY SEVEN PERCENT failure rate during a pre-production manufacturing run. http://laforge.gnumonks.org/blog/20170306-gta04-omap3_pop_soldering/ l. From lkcl at lkcl.net Thu Jul 6 06:21:50 2017 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Thu, 6 Jul 2017 06:21:50 +0100 Subject: [Arm-netbook] severe systemd bugs (two of them) In-Reply-To: <87r2xuhizs.fsf@whist.hands.com> References: <20170703184527.uzj3t2zoajwnnbxf@manillaroad.local.home.trueelena.org> <20170704065540.kbeapvi3n3yp47hd@lemon.cohens.org.il> <20170704094237.mgvdeockbwoiujrw@manillaroad.local.home.trueelena.org> <87r2xuhizs.fsf@whist.hands.com> Message-ID: On Wed, Jul 5, 2017 at 6:49 PM, Philip Hands wrote: > The program that ran most of OpenMoko was written on the assumption that > it would be very soon replaced by separate components that would all > pass messages around via d-bus ah! 12+ years i'm glad someone remembers. i got the trolltech greenphone, not an openmoko > The result being that if one got an incoming call, it would provoke a > cascade of (IIRC 7) d-bus interactions that were all being answered by > call-backs in the single program that was doing everything. Each one > went via a kernel context switch (or two?), dumping the cache, and that > meant that it would take at least 5 seconds for the ringer to start > ringing after a call came in, a few more seconds to show you the screen > with the answer button, ... which was painted with x11 so that meant many more more context-switches and cache-dumps because x11 is a client-server architecture... > a second or two for your mad tapping to be > noticed, during which the accelerometer would realise that it needed to > swap portrait for landscape (repainting the "cancel" button where the > "answer" used to be) and then finally it would process your demented > attempts to answer the sodding thing as a call rejection. Marvelous. ... didn't you have call-forwarding such that there wasn't enough time to actually answer the call anyway? :) > Enrico Zini worked all that out, and then knocked up a very short script > that waited for calls, made the ringer ring, and looked out for a button > press on the physical button -- that allowed it to behave quite like a > phone with no fuss. dang. *sigh* nokia's low-cost mobile phone OS (symbian?) at least was well-designed (or, designed for purpose). > If anyone wants an OpenMoko, I have one going cheap :-/ ah that would be good to use for the GTA04 motherboard replacement oh wait damnit that didn't go so well, they used a package-on-package TI SoC and DDR sandwich, where the processor was only designed for very specialist mass-volume manufacturing, was made too thin (to save cost) and warps under standard PCB assembly (ovens)... they got something like a SEVENTY SEVEN PERCENT failure rate during a pre-production manufacturing run. http://laforge.gnumonks.org/blog/20170306-gta04-omap3_pop_soldering/ l. From lkcl at lkcl.net Thu Jul 6 06:21:50 2017 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Thu, 6 Jul 2017 06:21:50 +0100 Subject: [Arm-netbook] severe systemd bugs (two of them) In-Reply-To: <87r2xuhizs.fsf@whist.hands.com> References: <20170703184527.uzj3t2zoajwnnbxf@manillaroad.local.home.trueelena.org> <20170704065540.kbeapvi3n3yp47hd@lemon.cohens.org.il> <20170704094237.mgvdeockbwoiujrw@manillaroad.local.home.trueelena.org> <87r2xuhizs.fsf@whist.hands.com> Message-ID: On Wed, Jul 5, 2017 at 6:49 PM, Philip Hands wrote: > The program that ran most of OpenMoko was written on the assumption that > it would be very soon replaced by separate components that would all > pass messages around via d-bus ah! 12+ years i'm glad someone remembers. i got the trolltech greenphone, not an openmoko > The result being that if one got an incoming call, it would provoke a > cascade of (IIRC 7) d-bus interactions that were all being answered by > call-backs in the single program that was doing everything. Each one > went via a kernel context switch (or two?), dumping the cache, and that > meant that it would take at least 5 seconds for the ringer to start > ringing after a call came in, a few more seconds to show you the screen > with the answer button, ... which was painted with x11 so that meant many more more context-switches and cache-dumps because x11 is a client-server architecture... > a second or two for your mad tapping to be > noticed, during which the accelerometer would realise that it needed to > swap portrait for landscape (repainting the "cancel" button where the > "answer" used to be) and then finally it would process your demented > attempts to answer the sodding thing as a call rejection. Marvelous. ... didn't you have call-forwarding such that there wasn't enough time to actually answer the call anyway? :) > Enrico Zini worked all that out, and then knocked up a very short script > that waited for calls, made the ringer ring, and looked out for a button > press on the physical button -- that allowed it to behave quite like a > phone with no fuss. dang. *sigh* nokia's low-cost mobile phone OS (symbian?) at least was well-designed (or, designed for purpose). > If anyone wants an OpenMoko, I have one going cheap :-/ ah that would be good to use for the GTA04 motherboard replacement oh wait damnit that didn't go so well, they used a package-on-package TI SoC and DDR sandwich, where the processor was only designed for very specialist mass-volume manufacturing, was made too thin (to save cost) and warps under standard PCB assembly (ovens)... they got something like a SEVENTY SEVEN PERCENT failure rate during a pre-production manufacturing run. http://laforge.gnumonks.org/blog/20170306-gta04-omap3_pop_soldering/ l. From dumblob at gmail.com Thu Jul 6 11:04:17 2017 From: dumblob at gmail.com (dumblob) Date: Thu, 6 Jul 2017 12:04:17 +0200 Subject: [Arm-netbook] Technoethical - a good-looking seller of HW with Libre SW & firmware (Technoethical holds RYF certification) Message-ID: Hi, I just came across Technoethical (https://tehnoetic.com/ ) and was surprised by the range of libre products they sell. Technoethical is also RYF (https://ryf.fsf.org/ ) certified. Luke, it might be worth contacting them with EOMA notebooks. Cheers, -- Jan From calmstorm at posteo.de Thu Jul 6 11:57:32 2017 From: calmstorm at posteo.de (zap) Date: Thu, 6 Jul 2017 06:57:32 -0400 Subject: [Arm-netbook] Technoethical - a good-looking seller of HW with Libre SW & firmware (Technoethical holds RYF certification) In-Reply-To: References: Message-ID: <9d6c5713-5e33-0ee7-1918-1f7d4ce911e1@posteo.de> On 07/06/2017 06:04 AM, dumblob wrote: > Hi, > > I just came across Technoethical (https://tehnoetic.com/ ) and was > surprised by the range of libre products they sell. Technoethical is > also RYF (https://ryf.fsf.org/ ) certified. > > Luke, it might be worth contacting them with EOMA notebooks. > > Cheers, > > -- Jan Alas, the owner of that company says that eoma68-a20 is not libre hardware... so I doubt he would be easy to convince... no maybe impossible even... meh... From calmstorm at posteo.de Thu Jul 6 12:08:24 2017 From: calmstorm at posteo.de (zap) Date: Thu, 6 Jul 2017 07:08:24 -0400 Subject: [Arm-netbook] Technoethical - a good-looking seller of HW with Libre SW & firmware (Technoethical holds RYF certification) In-Reply-To: <9d6c5713-5e33-0ee7-1918-1f7d4ce911e1@posteo.de> References: <9d6c5713-5e33-0ee7-1918-1f7d4ce911e1@posteo.de> Message-ID: <3c28218f-24a9-4fcf-6a09-ca97e53a8a48@posteo.de> On 07/06/2017 06:57 AM, zap wrote: > > On 07/06/2017 06:04 AM, dumblob wrote: >> Hi, >> >> I just came across Technoethical (https://tehnoetic.com/ ) and was >> surprised by the range of libre products they sell. Technoethical is >> also RYF (https://ryf.fsf.org/ ) certified. >> >> Luke, it might be worth contacting them with EOMA notebooks. >> >> Cheers, >> >> -- Jan > Alas, the owner of that company says that eoma68-a20 is not libre > hardware... > > so I doubt he would be easy to convince... no maybe impossible even... > > meh... Sorry if this sounds pessimistic, but he, tct, has been acting a bit odd of late... I wish tct well but, even more so for Luke for being so much more reasonable and chris from thinkpenguin for sponsoring Luke. From pablo at parobalth.org Thu Jul 6 12:21:56 2017 From: pablo at parobalth.org (Pablo) Date: Thu, 6 Jul 2017 13:21:56 +0200 Subject: [Arm-netbook] Side-Topic: Liberating PocketCHIP In-Reply-To: References: <20170510142356.GB8937@pabbook> <20170511141511.GC4716@pabbook> Message-ID: <20170706112156.GA2719@avocado> This is a quite late reply to some Emails on this list from May. I took some time to research and test. John, do you still work on liberating Pocketchip? Good news is that I managed to install Debian Stretch (current stable) with Debian Installer on a USB-stick. The CHIP OS based on Debian by NextThing is completely left alone. I plan to write a tutorial to document my approach and will put it on the Debian Wiki. On Sat, May 13, 2017 at 01:13:39AM -0400, John Luke Gibson wrote: > On 5/12/17, Louis Pearson wrote: > > I don't know if you know about this or not, but there is a community > > wiki at http://www.chip-community.org/index.php/Main_Page > > It has examples on using buildroot to flash images to chip > > http://www.chip-community.org/index.php/Flashing_Buildroot_Image_from_Ubuntu I knew about the community wiki. In my opinion Chip has a great, friendly and helpful community. I am not going to blame the community - especially because I have not yet found the time to contribute to the community wiki. My critique was directed at the manufacturer NextThing Co. John mentioned that he will have a look at the kernel first and later at U-boot. I have found some additional documents. To replace the existing kernel there is no need to reflash. A very good tutorial can be found here: http://www.raspibo.org/wiki/index.php/Compile_the_Linux_kernel_for_Chip:_my_personal_HOWTO#My_config_file ...and also a way to test a new kernel in a save way. Keep your USB-to-serial-cable ready in case things go wrong: http://www.raspibo.org/wiki/index.php/Chip9%24_U-Boot:_how_to_test_a_new_kernel_%28in_a_safe_way%29 > > Found the wiki up there through some searching. This is my > > first foray into working with embedded linux devices as well. > > I knew about the wiki, then again I believe someone else was asking > about one earlier. Yes, it was me. > I'm still wrapping my head around these make scripts to make sure > nothing proprietary is hidden anywhere they don't theoretically need > to be. > Probably a good idea to use mainline libre-linux, but first want to > make a diff file comparing their fork with libre to make sure their > aren't any drivers which are libre that we might need (or any > bug-fixes). There is a deblob script used by Parabola Linux to liberate a mainline kernel. It is used to create a libre-linux kernel from mainline. > Best bet is to use libre-linux mainline and besides that just attempt > to deblob ntc's components by hand, which shouldn't be a problem long > term cause it doesn't look like they maintain any of this stuff at all > anyway and it's very likely the only blobs are in the kernel anyway > however not a sure one. I ditched all the custom NTC stuff and went for vanilla Debian. I have managed to install Debian Stretch (current Stable) on a USB stick using Debian Installer. I am using a self-compiled mainline U-Boot via sunxi-fel to circumvent the U-Boot version on NAND provided by the manufacturer which can not boot from USB. I had some problems to boot the rootfs after completing installation and solved it with help from the debian-arm mailing list (see this thread for additional information: https://lists.debian.org/debian-arm/2017/06/msg00027.html) I am only using Debians main repos and connect to the Internet via USB-OTG with the g_ether kernel module and a network bridge on my desktop. This is libre enough for me. I am running Chip headless via ssh and have not tested video and sound yet. There may be some hidden quirks I am not yet aware of but so far it looks good. kind regards Pablo From pablo at parobalth.org Thu Jul 6 12:23:02 2017 From: pablo at parobalth.org (Pablo Rath) Date: Thu, 6 Jul 2017 13:23:02 +0200 Subject: [Arm-netbook] Side-Topic: Liberating PocketCHIP In-Reply-To: References: <20170508201754.GB7033@pabbook> <20170510142356.GB8937@pabbook> <20170511141511.GC4716@pabbook> Message-ID: <20170706112302.GB2719@avocado> On Thu, May 11, 2017 at 04:48:28PM -0400, Stefan Monnier wrote: > If you want sound information, indeed, such forums tend to be pretty > hard to use. The linux-sunxi website and mailing lists are a lot better > (and a lot more technical as a consequence). Thank you for the recommendations, Stefan. I am now subscribed to the linux-sunxi mailing list. Pablo From lkcl at lkcl.net Thu Jul 6 12:29:11 2017 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Thu, 6 Jul 2017 12:29:11 +0100 Subject: [Arm-netbook] Technoethical - a good-looking seller of HW with Libre SW & firmware (Technoethical holds RYF certification) In-Reply-To: <9d6c5713-5e33-0ee7-1918-1f7d4ce911e1@posteo.de> References: <9d6c5713-5e33-0ee7-1918-1f7d4ce911e1@posteo.de> Message-ID: On Thu, Jul 6, 2017 at 11:57 AM, zap wrote: > Alas, the owner of that company says that eoma68-a20 is not libre > hardware... this does not surprise me. if he has been talking to the guy known as "francis", who is best known for selling thinkpad x200 libre laptops, but is less well-known for causing a hell of a lot of problems, then yes he will be badly misled and misinformed. it happens. l. From calmstorm at posteo.de Thu Jul 6 13:10:34 2017 From: calmstorm at posteo.de (zap) Date: Thu, 6 Jul 2017 08:10:34 -0400 Subject: [Arm-netbook] Technoethical - a good-looking seller of HW with Libre SW & firmware (Technoethical holds RYF certification) In-Reply-To: References: <9d6c5713-5e33-0ee7-1918-1f7d4ce911e1@posteo.de> Message-ID: On 07/06/2017 07:29 AM, Luke Kenneth Casson Leighton wrote: > On Thu, Jul 6, 2017 at 11:57 AM, zap wrote: > > >> Alas, the owner of that company says that eoma68-a20 is not libre >> hardware... > this does not surprise me. if he has been talking to the guy known > as "francis", who is best known for selling thinkpad x200 libre > laptops, but is less well-known for causing a hell of a lot of > problems, then yes he will be badly misled and misinformed. > > it happens. > Actually no, he is now known as Leah. Your thinking of tct from trisquel forums... Francis who is known as Leah now, owns minifree not tehnoetic... From pelzflorian at pelzflorian.de Thu Jul 6 14:35:11 2017 From: pelzflorian at pelzflorian.de (pelzflorian (Florian Pelz)) Date: Thu, 6 Jul 2017 15:35:11 +0200 Subject: [Arm-netbook] Technoethical - a good-looking seller of HW with Libre SW & firmware (Technoethical holds RYF certification) In-Reply-To: <9d6c5713-5e33-0ee7-1918-1f7d4ce911e1@posteo.de> References: <9d6c5713-5e33-0ee7-1918-1f7d4ce911e1@posteo.de> Message-ID: <20170706133511.GB2797@eduroam-ipv4-4-0348.triple-a.uni-kl.de> On Thu, Jul 06, 2017 at 06:57:32AM -0400, zap wrote: > On 07/06/2017 06:04 AM, dumblob wrote: > > Hi, > > > > I just came across Technoethical (https://tehnoetic.com/ ) and was > > surprised by the range of libre products they sell. Technoethical is > > also RYF (https://ryf.fsf.org/ ) certified. > > > > Luke, it might be worth contacting them with EOMA notebooks. > > > > Cheers, > > > > -- Jan > Alas, the owner of that company says that eoma68-a20 is not libre > hardware... > > so I doubt he would be easy to convince... no maybe impossible even... > > meh... > I believe tct’s reasons for saying EOMA68-A20 isn’t libre will no longer matter once it is released. Please don’t dismiss tct just for having a different definition of libre. From calmstorm at posteo.de Thu Jul 6 14:36:13 2017 From: calmstorm at posteo.de (zap) Date: Thu, 6 Jul 2017 09:36:13 -0400 Subject: [Arm-netbook] Technoethical - a good-looking seller of HW with Libre SW & firmware (Technoethical holds RYF certification) In-Reply-To: <20170706133511.GB2797@eduroam-ipv4-4-0348.triple-a.uni-kl.de> References: <9d6c5713-5e33-0ee7-1918-1f7d4ce911e1@posteo.de> <20170706133511.GB2797@eduroam-ipv4-4-0348.triple-a.uni-kl.de> Message-ID: On 07/06/2017 09:35 AM, pelzflorian (Florian Pelz) wrote: > On Thu, Jul 06, 2017 at 06:57:32AM -0400, zap wrote: >> On 07/06/2017 06:04 AM, dumblob wrote: >>> Hi, >>> >>> I just came across Technoethical (https://tehnoetic.com/ ) and was >>> surprised by the range of libre products they sell. Technoethical is >>> also RYF (https://ryf.fsf.org/ ) certified. >>> >>> Luke, it might be worth contacting them with EOMA notebooks. >>> >>> Cheers, >>> >>> -- Jan >> Alas, the owner of that company says that eoma68-a20 is not libre >> hardware... >> >> so I doubt he would be easy to convince... no maybe impossible even... >> >> meh... >> > I believe tct’s reasons for saying EOMA68-A20 isn’t libre will no > longer matter once it is released. Please don’t dismiss tct just for > having a different definition of libre. Well, I hope your right, he has been acting odd if you use trisquel forums... you will see what I mean... > > _______________________________________________ > arm-netbook mailing list arm-netbook at lists.phcomp.co.uk > http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook > Send large attachments to arm-netbook at files.phcomp.co.uk From lkcl at lkcl.net Thu Jul 6 15:27:35 2017 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Thu, 6 Jul 2017 15:27:35 +0100 Subject: [Arm-netbook] Technoethical - a good-looking seller of HW with Libre SW & firmware (Technoethical holds RYF certification) In-Reply-To: References: <9d6c5713-5e33-0ee7-1918-1f7d4ce911e1@posteo.de> <20170706133511.GB2797@eduroam-ipv4-4-0348.triple-a.uni-kl.de> Message-ID: On Thu, Jul 6, 2017 at 2:36 PM, zap wrote: > Well, I hope your right, he has been acting odd if you use trisquel > forums... you will see what I mean... i know what to expect - i've seen it happen before. people get it into their heads that i'm a threat (or in this case that chris is a threat), and they will do absolutely anything - twist, evade, deliberately misunderstand and outright lie - *anything* as long as they can justify, in their minds, staying away from me or anything that i'm doing (or in this case what chris does). you also have to remember that tct's WIFI products are based on chris's work (2 years of walking qualcomm through the process of releasing the atheros 9271 firmware source code). that will be a source of embarrassment for him. luckily, the majority of people who do business with chris (and e.g. populate the trisquel forums) know the story. l. From pelzflorian at pelzflorian.de Thu Jul 6 15:32:40 2017 From: pelzflorian at pelzflorian.de (pelzflorian (Florian Pelz)) Date: Thu, 6 Jul 2017 16:32:40 +0200 Subject: [Arm-netbook] Technoethical - a good-looking seller of HW with Libre SW & firmware (Technoethical holds RYF certification) In-Reply-To: References: <9d6c5713-5e33-0ee7-1918-1f7d4ce911e1@posteo.de> <20170706133511.GB2797@eduroam-ipv4-4-0348.triple-a.uni-kl.de> Message-ID: <20170706143240.GA3343@eduroam-ipv4-4-0348.triple-a.uni-kl.de> On Thu, Jul 06, 2017 at 09:36:13AM -0400, zap wrote: > On 07/06/2017 09:35 AM, pelzflorian (Florian Pelz) wrote: > > On Thu, Jul 06, 2017 at 06:57:32AM -0400, zap wrote: > >> On 07/06/2017 06:04 AM, dumblob wrote: > >>> Hi, > >>> > >>> I just came across Technoethical (https://tehnoetic.com/ ) and was > >>> surprised by the range of libre products they sell. Technoethical is > >>> also RYF (https://ryf.fsf.org/ ) certified. > >>> > >>> Luke, it might be worth contacting them with EOMA notebooks. > >>> > >>> Cheers, > >>> > >>> -- Jan > >> Alas, the owner of that company says that eoma68-a20 is not libre > >> hardware... > >> > >> so I doubt he would be easy to convince... no maybe impossible even... > >> > >> meh... > >> > > I believe tct’s reasons for saying EOMA68-A20 isn’t libre will no > > longer matter once it is released. Please don’t dismiss tct just for > > having a different definition of libre. > > Well, I hope your right, he has been acting odd if you use trisquel > forums... you will see what I mean... > I suppose you are talking about discussions like this: https://trisquel.info/en/forum/technoethical-t400s-now-available It seems tct often participates in unfriendly discussions (be they on the Trisquel forum or the Parabola mailing list), but to me it seems this sometimes is the right approach (and sometimes is not). Anyway, we two seem to agree that talking to Tehnoetic is worth a try when EOMA68-A20 is ready. From lkcl at lkcl.net Thu Jul 6 16:01:54 2017 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Thu, 6 Jul 2017 16:01:54 +0100 Subject: [Arm-netbook] Technoethical - a good-looking seller of HW with Libre SW & firmware (Technoethical holds RYF certification) In-Reply-To: <20170706143240.GA3343@eduroam-ipv4-4-0348.triple-a.uni-kl.de> References: <9d6c5713-5e33-0ee7-1918-1f7d4ce911e1@posteo.de> <20170706133511.GB2797@eduroam-ipv4-4-0348.triple-a.uni-kl.de> <20170706143240.GA3343@eduroam-ipv4-4-0348.triple-a.uni-kl.de> Message-ID: On Thu, Jul 6, 2017 at 3:32 PM, pelzflorian (Florian Pelz) wrote: > Anyway, we two seem to agree that talking to Tehnoetic is worth a try > when EOMA68-A20 is ready. mmm.... no. i'm not going to initiate any conversations: i know enough to know that doing so would not be a good idea. effort which would centre around trying to disabuse someone of what *appears* on the face of it to be preconceptions but in fact is a deliberate effort to rubbish a "competing" product, such that once you had knocked down one straw man they would simply.... create a new one... could instead be focussed on much more productive areas and on much more receptive people. if however they contact _me_, then that would be an indication that they're ready to listen. l. From lkcl at lkcl.net Thu Jul 6 16:06:13 2017 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Thu, 6 Jul 2017 16:06:13 +0100 Subject: [Arm-netbook] Technoethical - a good-looking seller of HW with Libre SW & firmware (Technoethical holds RYF certification) In-Reply-To: References: <9d6c5713-5e33-0ee7-1918-1f7d4ce911e1@posteo.de> <20170706133511.GB2797@eduroam-ipv4-4-0348.triple-a.uni-kl.de> <20170706143240.GA3343@eduroam-ipv4-4-0348.triple-a.uni-kl.de> Message-ID: btw what i suspect is that tch is expecting to blithely copy the entire EOMA68-A20 hardware, with the expectation of spongeing off of the time and effort put into it. just like he did by spongeing off of chris's work with the AR9271 chain of devices. what he doesn't realise is that it's dangerous to do that (hardware interoperability) if he screws it up in even the smallest way it brings the entire EOMA68 project into disrepute. you only have to look at how chinese clones of USB3 cables are screwing up the power provision and damaging people's devices to know that hardware is not something you mess about with. l. From pelzflorian at pelzflorian.de Thu Jul 6 17:16:03 2017 From: pelzflorian at pelzflorian.de (pelzflorian (Florian Pelz)) Date: Thu, 6 Jul 2017 18:16:03 +0200 Subject: [Arm-netbook] Technoethical - a good-looking seller of HW with Libre SW & firmware (Technoethical holds RYF certification) In-Reply-To: References: <9d6c5713-5e33-0ee7-1918-1f7d4ce911e1@posteo.de> <20170706133511.GB2797@eduroam-ipv4-4-0348.triple-a.uni-kl.de> <20170706143240.GA3343@eduroam-ipv4-4-0348.triple-a.uni-kl.de> Message-ID: <20170706161603.GC3343@eduroam-ipv4-4-0348.triple-a.uni-kl.de> On Thu, Jul 06, 2017 at 04:06:13PM +0100, Luke Kenneth Casson Leighton wrote: > btw what i suspect is that tch is expecting to blithely copy the > entire EOMA68-A20 hardware, with the expectation of spongeing off of > the time and effort put into it. just like he did by spongeing off of > chris's work with the AR9271 chain of devices. > > what he doesn't realise is that it's dangerous to do that (hardware > interoperability) if he screws it up in even the smallest way it > brings the entire EOMA68 project into disrepute. you only have to > look at how chinese clones of USB3 cables are screwing up the power > provision and damaging people's devices to know that hardware is not > something you mess about with. > > l. > Sounds like the divisions sadly are deeper than I thought. Thank you for the clarification and all your work. Regards, Florian From kyle at free2.ml Thu Jul 6 23:16:07 2017 From: kyle at free2.ml (Kyle) Date: Thu, 6 Jul 2017 18:16:07 -0400 Subject: [Arm-netbook] Technoethical - a good-looking seller of HW with Libre SW & firmware (Technoethical holds RYF certification) In-Reply-To: References: Message-ID: According to dumblob: # I just came across Technoethical (https://tehnoetic.com/ ) and was # surprised by the range of libre products they sell. Looking at the laptops, they're all refurbished Thinkpads with Intel inside. I would perform a libre installation on such hardware if someone already owned it, but I would certainly never consider selling it as anything close to libre hardware. It has been said that the software makes all the difference, but Intel ucode really is a thing, and the stuff they have hidden in their CPU's for years makes libre software pretty much moot. Just my 2 Satoshi. Sent from the end From isacdaavid at isacdaavid.info Fri Jul 7 00:01:42 2017 From: isacdaavid at isacdaavid.info (Isaac David) Date: Thu, 06 Jul 2017 18:01:42 -0500 Subject: [Arm-netbook] Side-Topic: Liberating PocketCHIP In-Reply-To: <20170706112156.GA2719@avocado> References: <20170510142356.GB8937@pabbook> <20170511141511.GC4716@pabbook> <20170706112156.GA2719@avocado> Message-ID: <1499382102.4768.0@plebeian.isacdaavid.info> Pablo : >> Probably a good idea to use mainline libre-linux, but first want to >> make a diff file comparing their fork with libre to make sure their >> aren't any drivers which are libre that we might need (or any >> bug-fixes). > > There is a deblob script used by Parabola Linux to liberate a > mainline kernel. It is used to > create a libre-linux kernel from mainline. just chiming in to clarify that Parabola actually uses Linux-libre as provided by the FSFLA. they're the ones maintaining and running the deblob script and we just grab their pre-cleaned sources. needless to say, nothing prevents you or us from applying the script to linux mainline ourselves. i'm not familiar with Debian, but i've heard a number of times that their kernel (and rest of the system indeed) is also equally clean by default. -- Isaac David GPG: 38D33EF29A7691134357648733466E12EC7BA943 Tox: 0C730E0156E96E6193A1445D413557FF5F277BA969A4EA20AC9352889D3B390E77651E816F0C From lkcl at lkcl.net Fri Jul 7 04:38:18 2017 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Fri, 7 Jul 2017 04:38:18 +0100 Subject: [Arm-netbook] Technoethical - a good-looking seller of HW with Libre SW & firmware (Technoethical holds RYF certification) In-Reply-To: <20170706161603.GC3343@eduroam-ipv4-4-0348.triple-a.uni-kl.de> References: <9d6c5713-5e33-0ee7-1918-1f7d4ce911e1@posteo.de> <20170706133511.GB2797@eduroam-ipv4-4-0348.triple-a.uni-kl.de> <20170706143240.GA3343@eduroam-ipv4-4-0348.triple-a.uni-kl.de> <20170706161603.GC3343@eduroam-ipv4-4-0348.triple-a.uni-kl.de> Message-ID: On Thu, Jul 6, 2017 at 5:16 PM, pelzflorian (Florian Pelz) wrote: > Sounds like the divisions sadly are deeper than I thought. it's not "divisions", it's very simple: the EOMA68 Certification Mark requires that people Certify the products that they intend to manufacture and sell, for safety reasons. i am not just blithely going to let people randomly create hardware, slap an EOMA68 logo on it and then be sued or imprisoned because somebody was killed in a lithium battery fire. this is *really serious*, and must take absolute precedence over *any* kind of "freedoms" offered by libre hardware and libre software licenses. l. From vkontogpls at gmail.com Fri Jul 7 23:16:12 2017 From: vkontogpls at gmail.com (Bill Kontos) Date: Sat, 8 Jul 2017 01:16:12 +0300 Subject: [Arm-netbook] Potential new mali driver Message-ID: I just spotted this https://people.freedesktop.org/~cbrill/dri-log/?channel=lima&date=2017-06-23 It seems like there is a new person working on a driver for mali hardware, specifically the mali-400, and apparently it is an amd employee. From lkcl at lkcl.net Sat Jul 8 06:30:45 2017 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Sat, 8 Jul 2017 06:30:45 +0100 Subject: [Arm-netbook] Potential new mali driver In-Reply-To: References: Message-ID: --- crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68 On Fri, Jul 7, 2017 at 11:16 PM, Bill Kontos wrote: > I just spotted this > > https://people.freedesktop.org/~cbrill/dri-log/?channel=lima&date=2017-06-23 > > > It seems like there is a new person working on a driver for mali > hardware, specifically the mali-400, and apparently it is an amd > employee. cool! https://github.com/yuq/mesa-lima wow look at that README. license headers are MIT so that's okay. he's basing things on gallium3d - the MALI architecture doesn't really fit the gallium3d model, but at least it's a start. and he has the expertise to work on the shader compiler. hurrah. l. From doark at mail.com Fri Jul 7 23:19:29 2017 From: doark at mail.com (David Niklas) Date: Fri, 7 Jul 2017 18:19:29 -0400 Subject: [Arm-netbook] Side-Topic: Liberating PocketCHIP In-Reply-To: <20170706112156.GA2719@avocado> References: <20170510142356.GB8937@pabbook> <20170511141511.GC4716@pabbook> <20170706112156.GA2719@avocado> Message-ID: <20170707181929.05eeacb1@ulgy_thing> On Thu, 6 Jul 2017 13:21:56 +0200 pablo at parobalth.org wrote: > This is a quite late reply to some Emails on this list from May. I took > some time to research and test. > John, do you still work on liberating Pocketchip? > > Good news is that I managed to install Debian > Stretch (current stable) with Debian Installer on a USB-stick. The CHIP > OS based on Debian by NextThing is completely left alone. > I plan to write a tutorial to document my approach and will put it on > the Debian Wiki. Please pass us a link when you do so. > On Sat, May 13, 2017 at 01:13:39AM -0400, John Luke Gibson wrote: > > I'm still wrapping my head around these make scripts to make sure > > nothing proprietary is hidden anywhere they don't theoretically need > > to be. > > Probably a good idea to use mainline libre-linux, but first want to > > make a diff file comparing their fork with libre to make sure their > > aren't any drivers which are libre that we might need (or any > > bug-fixes). > > There is a deblob script used by Parabola Linux to liberate a mainline > kernel. It is used to create a libre-linux kernel from mainline. > Actually, my PC has a kernel fault (It's a long story of ntc's evil doing), and the Linux kernel claims that it is not tainted. I don't know if that covers firmware, but at least there are no modules that are non-free. > > Best bet is to use libre-linux mainline and besides that just attempt > > to deblob ntc's components by hand, which shouldn't be a problem long > > term cause it doesn't look like they maintain any of this stuff at all > > anyway and it's very likely the only blobs are in the kernel anyway > > however not a sure one. > > I ditched all the custom NTC stuff and went for vanilla Debian. I have > managed to install Debian Stretch (current Stable) on a USB stick using > Debian Installer. I am using a self-compiled mainline U-Boot via > sunxi-fel to circumvent the U-Boot version on NAND provided by the > manufacturer which can not boot from USB. I've found two faults that cannot be traced without a postmortem and I'm really sick of accidentally causing this thing to manifest said problems and then loosing all the work that I did in between my backup periods. I'm in need of a way to boot PC without flashing the NAND I there a way to do this? So far my search results have been unsuccessful. Thanks, David From doark at mail.com Fri Jul 7 23:35:16 2017 From: doark at mail.com (David Niklas) Date: Fri, 7 Jul 2017 18:35:16 -0400 Subject: [Arm-netbook] Init Freedom In-Reply-To: References: <87a84mj584.fsf@whist.hands.com> <20170704014107.GA10936@topoi.pooq.com> <20170704071700.mlaii6kcmdbxuxai@lemon.cohens.org.il> <5ba9e211-c058-dffd-e130-ac0848ff2a85@gmail.com> Message-ID: <20170707183516.21f11d95@ulgy_thing> On Wed, 5 Jul 2017 06:48:08 +0100 Luke Kenneth Casson Leighton wrote: > On Wed, Jul 5, 2017 at 5:48 AM, James L > wrote: > >> if they were true to their mission statement they would add the > >> option to include it. > > > > Unfortunately, I have to agree > > i spoke to one of the people in devuan, who turned out to be an > amazingly wise person, and i was able to point out this discrepancy to > them without over-reaction. i suggested to them that it might be a > good idea to properly honour the mission statement by including > systemd in devuan. > > their response was that in their opinion it simply would never > happen, ever. devuan was *geniunely* born out of a back-lash reaction > *against* systemd.. *not* out of a desire to genuinely honour their > mission statement. > > > Here is a question: Is a false (in any way) mission statement enough > > to totally dismiss something? Even if their actions (providing a > > reasonable alternative) are seemingly good? > > *sigh* i love what they've done, but the best way to illustrate it is > with a story from mother theresa. she was invited to an anti-war > rally, once. she declined... and told them that if they ever wanted > to hold a *peace* rally, she would be delighted to attend. > > that really says it all, i think. > > > From what I have observed, you seem to have two "codes" that you live > > by, your ethics and your intuition. > > ha. to clarify: i use my intuition to identify those things which > are ethical [and then follow up with as much rational / logical > reasoning as i can stand]. where i really didn't even have a > definition of what is actually ethical until i encountered bob > podolski, only last year. ironic or what... :) > > > Your ethics seems to mostly involve > > your influence over others, so what does your intuition say about > > Devuan? > > jury's still out. i'm hopeful that one day they'll be able to > resolve the conflict and truly honour their mission statement. for > myself i... i simply cannot bring myself to endorse or support things > where there exists a huge cognitive dissonance. call it an ISO9001 > "fail" if you will. > > l. > Luke I became involved about three weeks after the project started. I'm still on the ML but had no time to keep up or contribute much. I saw some of the most cordial behaviour that I have had the privilege to witness on a mailing list from most of (all?) the members! I really believe that they will meet with success in their toiling. Not to justify by pointing to lesser examples, but contrast it with the behaviour of Mr. Pottering. Insta-bug-close. Taking every available short cut. No Portability to clang/bsd/etc. I really think that Devuan is just taking an obvious short cut in the above case. That is to say, if devuan and debian devs got together to merge then devuan would get support for system and debian would support other inits. I do not and did not see any resentment to debian on the list by the devuan devs. Sincerely, David From lkcl at lkcl.net Sat Jul 8 15:24:23 2017 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Sat, 8 Jul 2017 15:24:23 +0100 Subject: [Arm-netbook] Init Freedom In-Reply-To: <20170707183516.21f11d95@ulgy_thing> References: <87a84mj584.fsf@whist.hands.com> <20170704014107.GA10936@topoi.pooq.com> <20170704071700.mlaii6kcmdbxuxai@lemon.cohens.org.il> <5ba9e211-c058-dffd-e130-ac0848ff2a85@gmail.com> <20170707183516.21f11d95@ulgy_thing> Message-ID: On Fri, Jul 7, 2017 at 11:35 PM, David Niklas wrote: > Luke I became involved about three weeks after the project started. I'm > still on the ML but had no time to keep up or contribute much. not a problem. > I saw some > of the most cordial behaviour that I have had the privilege to witness on > a mailing list from most of (all?) the members! huh. despite quite a lot of "venting", that's really appreciated to hear. > I really believe that they > will meet with success in their toiling. Not to justify by pointing to > lesser examples, but contrast it with the behaviour of Mr. Pottering. > Insta-bug-close. Taking every available short cut. No Portability to > clang/bsd/etc. *cringes*... i see you noticed his behaviour. > I really think that Devuan is just taking an obvious short cut in the > above case. That is to say, if devuan and debian devs got together to > merge then devuan would get support for system and debian would support > other inits. I do not and did not see any resentment to debian on the > list by the devuan devs. the devuan team have a really nice team spirit, and their work is of significant interest beyond just debian/devuan. the technique of HTTP-redirect-cloning distros has useful implications for other libre (e.g. FSF-Endorseable) distros that wish to remove certain packages but do not wish to host a hundred gigabytes worth of tens of thousands of files to do so, not least because it would be insanely impractical to do so, just for the purposes of e.g. removing nonfree firmware or trademarked images and words. l. From doark at mail.com Sat Jul 8 19:47:11 2017 From: doark at mail.com (David Niklas) Date: Sat, 8 Jul 2017 14:47:11 -0400 Subject: [Arm-netbook] OT: What is maker geeks filament like Message-ID: <20170708144711.3d819def@ulgy_thing> Luke, You have mentioned the need for better quality PLA and I just noticed this deal: http://www.makergeeks.com/mafigrbag2kg.html Not that I'm about to buy, but do you know anything about this company? Thanks, David From lkcl at lkcl.net Sat Jul 8 20:21:36 2017 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Sat, 8 Jul 2017 20:21:36 +0100 Subject: [Arm-netbook] OT: What is maker geeks filament like In-Reply-To: <20170708144711.3d819def@ulgy_thing> References: <20170708144711.3d819def@ulgy_thing> Message-ID: --- crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68 On Sat, Jul 8, 2017 at 7:47 PM, David Niklas wrote: > Luke, > You have mentioned the need for better quality PLA and I just noticed > this deal: > > http://www.makergeeks.com/mafigrbag2kg.html > > Not that I'm about to buy, but do you know anything about this company? not a thing. i usually ask other people's advice and stick to it. heard nightmare stores for years of people buying shit quality filament, then tried it once and it completely f*****d up an entire project: wasted months of work and jeapordised a $2,500 project. l. From hendrik at topoi.pooq.com Sun Jul 9 02:53:55 2017 From: hendrik at topoi.pooq.com (Hendrik Boom) Date: Sat, 8 Jul 2017 21:53:55 -0400 Subject: [Arm-netbook] Init Freedom In-Reply-To: References: <20170704014107.GA10936@topoi.pooq.com> <20170704071700.mlaii6kcmdbxuxai@lemon.cohens.org.il> <5ba9e211-c058-dffd-e130-ac0848ff2a85@gmail.com> Message-ID: <20170709015355.GA28139@topoi.pooq.com> On Wed, Jul 05, 2017 at 06:48:08AM +0100, Luke Kenneth Casson Leighton wrote: > --- > crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68 > > > On Wed, Jul 5, 2017 at 5:48 AM, James L wrote: > > >> if they were true to their mission statement they would add the > >> option to include it. > > > > Unfortunately, I have to agree > > i spoke to one of the people in devuan, who turned out to be an > amazingly wise person, and i was able to point out this discrepancy to > them without over-reaction. i suggested to them that it might be a > good idea to properly honour the mission statement by including > systemd in devuan. > > their response was that in their opinion it simply would never > happen, ever. devuan was *geniunely* born out of a back-lash reaction > *against* systemd.. *not* out of a desire to genuinely honour their > mission statement. The mission statement came later. But they do mean it's about choice. That said, they do have practial limitations as to what alternatives they can offer themselves, and they have focussed on important alternatives that are not provided by Debian. This is how they provide choice. I don't see how this si oncompatible with their mission statement, though I can see how it may appear so. They also care that system owners be in control of their own systems. Choice is a means to this end. But some subsystems make this kind of control difficult, and it's reasonable not to spend effort in this direction. Especially when there's a well-known and reasonably compatible distro that already does that. -- hendrik > > > Here is a question: Is a false (in any way) mission statement enough to > > totally dismiss something? Even if their actions (providing a reasonable > > alternative) are seemingly good? > > *sigh* i love what they've done, but the best way to illustrate it is > with a story from mother theresa. she was invited to an anti-war > rally, once. she declined... and told them that if they ever wanted > to hold a *peace* rally, she would be delighted to attend. > > that really says it all, i think. > > > From what I have observed, you seem to have two "codes" that you live > > by, your ethics and your intuition. > > ha. to clarify: i use my intuition to identify those things which > are ethical [and then follow up with as much rational / logical > reasoning as i can stand]. where i really didn't even have a > definition of what is actually ethical until i encountered bob > podolski, only last year. ironic or what... :) > > > Your ethics seems to mostly involve > > your influence over others, so what does your intuition say about Devuan? > > jury's still out. i'm hopeful that one day they'll be able to > resolve the conflict and truly honour their mission statement. for > myself i... i simply cannot bring myself to endorse or support things > where there exists a huge cognitive dissonance. call it an ISO9001 > "fail" if you will. > > l. > > _______________________________________________ > arm-netbook mailing list arm-netbook at lists.phcomp.co.uk > http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook > Send large attachments to arm-netbook at files.phcomp.co.uk From lkcl at lkcl.net Sun Jul 9 05:15:04 2017 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Sun, 9 Jul 2017 05:15:04 +0100 Subject: [Arm-netbook] Init Freedom In-Reply-To: <20170709015355.GA28139@topoi.pooq.com> References: <20170704014107.GA10936@topoi.pooq.com> <20170704071700.mlaii6kcmdbxuxai@lemon.cohens.org.il> <5ba9e211-c058-dffd-e130-ac0848ff2a85@gmail.com> <20170709015355.GA28139@topoi.pooq.com> Message-ID: On Sun, Jul 9, 2017 at 2:53 AM, Hendrik Boom wrote: > The mission statement came later. But they do mean it's about choice. > That said, they do have practial limitations as to what alternatives > they can offer themselves, and they have focussed on important > alternatives that are not provided by Debian. This is how they provide > choice. I don't see how this si oncompatible with their mission > statement, though I can see how it may appear so. because i've spoken directly with them (privately), and received an emphatic opinion that their state of mind is so firmly in the "anti-systemd" camp that to even *contemplate* the mere *suggestion* - in an open fashion - that systemd really should be included in order to properly honour their mission statement would be outright rejected. the sad thing is that if they actually did make it possible to choose to use systemd in devuan, the means and method by which that needs to be done would most likely result in the possibility of a complete merge between devuan and debian some in the future. l. From eaterjolly at gmail.com Mon Jul 10 11:34:39 2017 From: eaterjolly at gmail.com (Jean Flamelle) Date: Mon, 10 Jul 2017 06:34:39 -0400 Subject: [Arm-netbook] Side-Topic: Liberating PocketCHIP In-Reply-To: <20170706112156.GA2719@avocado> References: <20170510142356.GB8937@pabbook> <20170511141511.GC4716@pabbook> <20170706112156.GA2719@avocado> Message-ID: On 7/6/17, Pablo wrote: > This is a quite late reply to some Emails on this list from May. I took some > time to research and test. > John, do you still work on liberating Pocketchip? Got distracted trying to install parabola on an asus c201 (nothing can write a sane gpt header to emmc it seems). Actually learned about the deblob scripts seeing a script use them on the chrome kernel, so I was thinking about running deblob in a u-boot directory and seeing what happens. My understanding (which isn't too reliable) is that the universal in universal bootloader is that u-boot handles some operations that would normally be handled by linux, including passing microcode and handling some firmware. > Good news is that I managed to install Debian > Stretch (current stable) with Debian Installer on a USB-stick. The CHIP > OS based on Debian by NextThing is completely left alone. > I plan to write a tutorial to document my approach and will put it on the > Debian Wiki. Yeah! >> I knew about the wiki, then again I believe someone else was asking >> about one earlier. > > Yes, it was me. heh.. Sorry ,xD I didn't know the exact url by heart and never got around to posting it on da list as a ref later. > I ditched all the custom NTC stuff and went for vanilla Debian. I have > managed to install Debian Stretch (current Stable) on a USB stick > using Debian Installer. I am using a self-compiled mainline U-Boot via > sunxi-fel to > circumvent the U-Boot version on NAND provided by the manufacturer which > can not boot from USB. I'm not sure if you mean version "of" NAND, but otherwise it sounds like your saying they hardcoded it not boot that way? Feature-not-a-bug? > I had some problems to boot the rootfs after completing installation and > solved it with help from the debian-arm mailing list (see this thread > for additional information: > https://lists.debian.org/debian-arm/2017/06/msg00027.html) > I am only using Debians main repos and connect to the Internet via > USB-OTG with the g_ether kernel module and a network bridge on my > desktop. That whole thing sounds like it was painful to get operating. > This is libre enough for me. > I am running Chip headless via ssh and have not tested video and > sound yet. There may be some hidden quirks I am not yet aware of but so > far it looks good. I would be very interested to know if GPIO functions okay like that. kudos Pablo! From pablo at parobalth.org Tue Jul 11 11:10:21 2017 From: pablo at parobalth.org (Pablo Rath) Date: Tue, 11 Jul 2017 12:10:21 +0200 Subject: [Arm-netbook] Side-Topic: Liberating PocketCHIP In-Reply-To: <20170707181929.05eeacb1@ulgy_thing> References: <20170510142356.GB8937@pabbook> <20170511141511.GC4716@pabbook> <20170706112156.GA2719@avocado> <20170707181929.05eeacb1@ulgy_thing> Message-ID: <20170711101021.GA4378@pabbook> On Fri, Jul 07, 2017 at 06:19:29PM -0400, David Niklas wrote: > On Thu, 6 Jul 2017 13:21:56 +0200 > > Actually, my PC has a kernel fault It took me a moment to guess that you abbreviate PocketChip as "PC". My mind went like: "What? Why is he talking about his Personal Computer now?" :) > (It's a long story of ntc's evil > doing), Why do you believe that ntc is evil? > and the Linux kernel claims that it is not tainted. > I don't know if that covers firmware, but at least there are no modules > that are non-free. I don't understand the paragraph above. Do you talk about mainline linux kernel, ntc's kernel fork for Chip, ... Can you please clarify? > > > Best bet is to use libre-linux mainline and besides that just attempt > > > to deblob ntc's components by hand, which shouldn't be a problem long > > > term cause it doesn't look like they maintain any of this stuff at all > > > anyway and it's very likely the only blobs are in the kernel anyway > > > however not a sure one. > > > > I ditched all the custom NTC stuff and went for vanilla Debian. I have > > managed to install Debian Stretch (current Stable) on a USB stick using > > Debian Installer. I am using a self-compiled mainline U-Boot via > > sunxi-fel to circumvent the U-Boot version on NAND provided by the > > manufacturer which can not boot from USB. > > > I've found two faults that cannot be traced without a postmortem and I'm > really sick of accidentally causing this thing to manifest said problems > and then loosing all the work that I did in between my backup periods. How can you be sure it is a kernel bug and not another problem? Can you give us some details. Did you ask on ntc's user forum or did you file a bug report Can't you improve you backup strategy - for example commit to an external git repo; or synchronize with another stable working computer? > I'm in need of a way to boot PC without flashing the NAND I there a way > to do this? So far my search results have been unsuccessful. 1. Well, you can take your Chip out of the housing and install the distro of you choice on a USB-stick and use it as a regular Chip. 2. Can you get PocketChip into fel-mode without taking it out of the enclosure? Ntc's documentation claims it is not possible but there is a forum thread about a reboot option into fel-mode. I have no PoketChip and leave it up to you to research the answers to this questions. Another point is if the distro of you choice on a USB-stick will support PocketChips hardware (e.g. Keyboard, LCD-Screen) out of the box. Do you have a serial-to-usb-cable to interact with PocketChip? kind regards Pablo From pablo at parobalth.org Tue Jul 11 11:14:34 2017 From: pablo at parobalth.org (Pablo Rath) Date: Tue, 11 Jul 2017 12:14:34 +0200 Subject: [Arm-netbook] Side-Topic: Liberating PocketCHIP In-Reply-To: <1499382102.4768.0@plebeian.isacdaavid.info> References: <20170510142356.GB8937@pabbook> <20170511141511.GC4716@pabbook> <20170706112156.GA2719@avocado> <1499382102.4768.0@plebeian.isacdaavid.info> Message-ID: <20170711101434.GB4378@pabbook> On Thu, Jul 06, 2017 at 06:01:42PM -0500, Isaac David wrote: > Pablo : > >There is a deblob script used by Parabola Linux to liberate a mainline > >kernel. It is used to > >create a libre-linux kernel from mainline. > > just chiming in to clarify that Parabola actually uses Linux-libre as > provided by the FSFLA. they're the ones maintaining and running the > deblob script and we just grab their pre-cleaned sources. needless to > say, nothing prevents you or us from applying the script to linux > mainline ourselves. Thank you for correcting my error and giving proper credit to the FSFLA. I even visited the homepage of FSFLA a few weeks ago and took a look at the deblop script but did not get that Parabola uses the pre-cleaned sources provided by the FSFLA. kind regards Pablo From pablo at parobalth.org Tue Jul 11 11:35:12 2017 From: pablo at parobalth.org (Pablo Rath) Date: Tue, 11 Jul 2017 12:35:12 +0200 Subject: [Arm-netbook] Side-Topic: Liberating PocketCHIP In-Reply-To: References: <20170510142356.GB8937@pabbook> <20170511141511.GC4716@pabbook> <20170706112156.GA2719@avocado> Message-ID: <20170711103512.GC4378@pabbook> On Mon, Jul 10, 2017 at 06:34:39AM -0400, Jean Flamelle wrote: > Actually learned about the > deblob scripts seeing a script use them on the chrome kernel, so I was > thinking about running deblob in a u-boot directory and seeing what > happens. My guess is that nothing useful is going to happen because there is a deblob script tailored for every kernel release. I would be quite surprised if it works on the source of a completely unrelated project. But I have been wrong before so go ahead if you want and tell us what happens. > > I ditched all the custom NTC stuff and went for vanilla Debian. I have > > managed to install Debian Stretch (current Stable) on a USB stick > > using Debian Installer. I am using a self-compiled mainline U-Boot via > > sunxi-fel to > > circumvent the U-Boot version on NAND provided by the manufacturer which > > can not boot from USB. > > I'm not sure if you mean version "of" NAND, but otherwise it sounds > like your saying they hardcoded it not boot that way? > Feature-not-a-bug? I have to admit that I don't understand your first question probably because I am not a native speaker. Is "of NAND" or "on NAND" a semantic or a technical question? I think NextThing forked U-Boot before USB boot went mainline. I remember a forum thread where someone from NextThing wrote there are two options; first to backport USB boot into NextThings U-Boot fork or second to wait until certain features of NextThings U-Boot are mainlined. So in my opinion feature-not-a-bug is not the case here. > > I had some problems to boot the rootfs after completing installation and > > solved it with help from the debian-arm mailing list (see this thread > > for additional information: > > https://lists.debian.org/debian-arm/2017/06/msg00027.html) > > I am only using Debians main repos and connect to the Internet via > > USB-OTG with the g_ether kernel module and a network bridge on my > > desktop. > > That whole thing sounds like it was painful to get operating. I don't give up easily. It was more like solving a puzzle where all parts fit once you have gotten them out of several different boxes. I did not write a single line of code so I am standing on the shoulders of giants (linux-sunxi community, debian developers, U-Boot developers). > > > I am running Chip headless via ssh and have not tested video and > > sound yet. There may be some hidden quirks I am not yet aware of but so > > far it looks good. > > I would be very interested to know if GPIO functions okay like that. Do you have an easy test to verify GPIO functions? > kudos Pablo! Thank you! kind regards Pablo From dumblob at gmail.com Wed Jul 12 10:25:17 2017 From: dumblob at gmail.com (dumblob) Date: Wed, 12 Jul 2017 11:25:17 +0200 Subject: [Arm-netbook] Technoethical - a good-looking seller of HW with Libre SW & firmware (Technoethical holds RYF certification) In-Reply-To: References: Message-ID: Hi Kyle, > Looking at the laptops, they're all refurbished Thinkpads with Intel inside. > I would perform a libre installation on such hardware if someone already > owned it, but I would certainly never consider selling it as anything close > to libre hardware. It has been said that the software makes all the > difference, but Intel ucode really is a thing, and the stuff they have > hidden in their CPU's for years makes libre software pretty much moot. Correct. I should have used the official term "libre-friendly" instead of "libre". Cheers, -- Jan From pablo at parobalth.org Wed Jul 12 11:36:03 2017 From: pablo at parobalth.org (Pablo Rath) Date: Wed, 12 Jul 2017 12:36:03 +0200 Subject: [Arm-netbook] Standards Organization as a Potentially Universal Free/Libre Software Developement Sustenance Model In-Reply-To: References: Message-ID: <20170712103603.GA16243@pabbook> On Tue, Jun 06, 2017 at 05:51:33AM +0100, Luke Kenneth Casson Leighton wrote: ... > the first step *really is* to quite literally copy - verbatim - the > gnu devel.html page and "generify" it. > > where it says "we recommend savannah" put instead "we recommend the > use of a Libre Hosting Service which has a minimum criteria of an A, > as defined by the FSF's Hosting Criteria". > > where it says "we recommend mailing lists on gnu.org" put instead "we > recommend the use of software libre hosted mailing lists". a later > revision should go into further detail as to *why* "announce", > "users", "dev" etc. is recommended. > > etc. etc. > As it seems to me the above points are done. Thank you Luke for fixing my mishappened sentence. There is now a point for version control, mailing lists and web pages at the wiki (http://rhombus-tech.net/proposed_best_practices/). Regarding the goal of a general standard for libre projects I don't think it is necessary to cover the quite specific further points of the gnu devel.html page: "FTP", "Login accounts", "Hydra: Continuous builds and portability testing" and "platform-testers: Manual portability testing". I have read a good part of the Maintainer's Guide: https://www.gnu.org/prep/maintain/maintain.txt and wonder how to best incorporate it into the draft for best practices. For example from gnu devel.html page we took the point about web pages and generalised it: "we recommend to host the webpages for the project using resources that meet the FSF's Hosting Criteria" Chapter 12 Web Pages of the Maintainer's Guide covers a lot of details. Some questions: Has anyone else started to work on it (offline)? How long shall the first draft of the standard be (e.g. 10 pages, 100 pages, as long as necessary)? As you can see I am looking for guidance and some kind of roadmap to prevent working in the wrong direction. kind regards Pablo From lkcl at lkcl.net Wed Jul 12 14:12:33 2017 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Wed, 12 Jul 2017 14:12:33 +0100 Subject: [Arm-netbook] Standards Organization as a Potentially Universal Free/Libre Software Developement Sustenance Model In-Reply-To: <20170712103603.GA16243@pabbook> References: <20170712103603.GA16243@pabbook> Message-ID: --- crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68 On Wed, Jul 12, 2017 at 11:36 AM, Pablo Rath wrote: > On Tue, Jun 06, 2017 at 05:51:33AM +0100, Luke Kenneth Casson Leighton wrote: > ... > >> the first step *really is* to quite literally copy - verbatim - the >> gnu devel.html page and "generify" it. >> >> where it says "we recommend savannah" put instead "we recommend the >> use of a Libre Hosting Service which has a minimum criteria of an A, >> as defined by the FSF's Hosting Criteria". >> >> where it says "we recommend mailing lists on gnu.org" put instead "we >> recommend the use of software libre hosted mailing lists". a later >> revision should go into further detail as to *why* "announce", >> "users", "dev" etc. is recommended. >> >> etc. etc. >> > > As it seems to me the above points are done. Thank you Luke for > fixing my mishappened sentence. > There is now a point for version control, mailing lists and web pages at > the wiki (http://rhombus-tech.net/proposed_best_practices/). > Regarding the goal of a general standard for libre projects I don't > think it is necessary to cover the quite specific further points of the > gnu devel.html page: "FTP", "Login accounts", "Hydra: Continuous builds and portability > testing" and "platform-testers: Manual portability testing". if mentioned at all there should be some documented "upload / download" method (upload for developers, download for users) but nothing quite as specific as "You Must Use FTP" or even saying how to set up FTP. "use libre hosting service" pretty much covers what needs to be done here. build-testing? other than "if it is needed, using libre source build and test programs so that people can duplicate the test and build results for themselves" is *partially* covered under the terms of the GNU GPL(s).... but *not* if people say use the Apache License. so... yes, my feeling is that build and test procedures *if used and/or needed* should really be specified in a general way. > Some questions: > Has anyone else started to work on it (offline)? been too busy here > How long shall the first draft of the standard be (e.g. 10 pages, 100 pages, as long as > necessary)? short... but as long as necessary. i don't see any reason it should be longer than 10 pages. > As you can see I am looking for guidance and some kind of roadmap to > prevent working in the wrong direction. great! From eaterjolly at gmail.com Thu Jul 13 14:11:08 2017 From: eaterjolly at gmail.com (Jean Flamelle) Date: Thu, 13 Jul 2017 09:11:08 -0400 Subject: [Arm-netbook] Standards Organization as a Potentially Universal Free/Libre Software Developement Sustenance Model In-Reply-To: References: <20170712103603.GA16243@pabbook> Message-ID: Meh, I don't really think myself ready to write this kind of a document. I really don't know as much as I'd like to on the topic. From lkcl at lkcl.net Thu Jul 13 15:19:49 2017 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Thu, 13 Jul 2017 15:19:49 +0100 Subject: [Arm-netbook] Standards Organization as a Potentially Universal Free/Libre Software Developement Sustenance Model In-Reply-To: References: <20170712103603.GA16243@pabbook> Message-ID: On Thu, Jul 13, 2017 at 2:11 PM, Jean Flamelle wrote: > Meh, I don't really think myself ready to write this kind of a document. > I really don't know as much as I'd like to on the topic. well... would you like to help evaluate some of the long-standing well-known free software projects out there? i vaguely recall making a list a few weeks ago. we need a table showing what "features" each of them has. do they use mailing lists, do they have a forum, do they have a charter, do they have a "code of conduct" *shudder*, do they properly honour free software licenses or do they have some sort of unethical "forced contributor agreement" (oracle in particular). a comparison of pre and post forks for major projects such as x11 / xorg, openoffice / libreoffice, mysql / mariadb, and so on, would be really *really* interesting and informative. l. From eaterjolly at gmail.com Fri Jul 14 14:18:10 2017 From: eaterjolly at gmail.com (Jean Flamelle) Date: Fri, 14 Jul 2017 09:18:10 -0400 Subject: [Arm-netbook] Standards Organization as a Potentially Universal Free/Libre Software Developement Sustenance Model In-Reply-To: References: <20170712103603.GA16243@pabbook> Message-ID: On 7/13/17, Luke Kenneth Casson Leighton wrote: > On Thu, Jul 13, 2017 at 2:11 PM, Jean Flamelle wrote: >> Meh, I don't really think myself ready to write this kind of a document. >> I really don't know as much as I'd like to on the topic. > > well... would you like to help evaluate some of the long-standing > well-known free software projects out there? i vaguely recall making > a list a few weeks ago. we need a table showing what "features" each > of them has. do they use mailing lists, do they have a forum, do they > have a charter, do they have a "code of conduct" *shudder*, do they > properly honour free software licenses or do they have some sort of > unethical "forced contributor agreement" (oracle in particular). > > a comparison of pre and post forks for major projects such as x11 / > xorg, openoffice / libreoffice, mysql / mariadb, and so on, would be > really *really* interesting and informative. > > l. I would be glad to do that! I think it would be very important to focus on projects that create software or firmware, which are of particular relevance to non-programmers. I think this because they'll likely be under significantly disproportionate proportionate pressure compared to the amount of contributions to code that they receive. Blender, Gimp, and Aperture, are just a few that come to mind immediately, but projects like RISC-V and Kicad would arguably also count since there are still large portions of their audiences likely specialize very far away from the type of software programming knowledge required to contribute. I think for most people the inclination to donate to any software projects fiscally, would be predictable (with a high confidence value) by the the ratio of technical programming knowledge and their dependence on the software created by that project. For that reason you could also say, it would be a higher priority to evaluate gnome as as a software project than debian, because ubuntu is more often pitched to a less technical audience. Of course, the fsf already evaluates distributions and doesn't endorse ubuntu anyway, so it would probably be perceived in really bad taste if the libre community started listing reasons why they gave gnome a poor evaluation score if that was the outcome, so I suppose it would be best to avoid it all together and only evaluate desktop environments as software projects if the are made available in an fsf-endorsed distribution by default. (I know I've heard people say trisquel is based on ubuntu, but I don't know what desktop environment it uses by default). All in all, for a base, I think aperture would be a good starting point, since GIMP and Blender get a lot of flack that aperture doesn't atm. I realize most of what they are doing is hardware, but their is a lot of firmware involved. Also, I haven't heard very many complaints about inkscape, so that would be a decent one to start with. I'm hesitant to talk about OpenShot or libreoffice early on, because they are (as we like to say in the wikipedia community) POV-forks than independent projects. In other words, it's impossible to honestly and sincerely evaluate LibreOffice as a project without comparing it to OpenOffice and likewise OpenShot to Blender and in small part Audacity. Since I don't feel especially confident in my ability handling this topic, I would probably sooner get feedback through this thread than add any "evaluations" I make straight to the wiki. Because of this, I think it's important I start by documenting on which ever of the "good candidate" projects attracts the most interest in this thread, at least on the philosophical level of how they "go about their business" if not on a fundamental level of "I really like this project". From lkcl at lkcl.net Fri Jul 14 16:36:49 2017 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Fri, 14 Jul 2017 16:36:49 +0100 Subject: [Arm-netbook] Standards Organization as a Potentially Universal Free/Libre Software Developement Sustenance Model In-Reply-To: References: <20170712103603.GA16243@pabbook> Message-ID: On Fri, Jul 14, 2017 at 2:18 PM, Jean Flamelle wrote: >> well... would you like to help evaluate some of the long-standing >> well-known free software projects out there? i vaguely recall making > I would be glad to do that! yay! > I think it would be very important to focus on projects that create > software or firmware, which are of particular relevance to > non-programmers. I think this because they'll likely be under > significantly disproportionate proportionate pressure compared to the > amount of contributions to code that they receive. Blender, Gimp, and > Aperture, are just a few that come to mind immediately, but projects > like RISC-V and Kicad would arguably also count since there are still > large portions of their audiences likely specialize very far away from > the type of software programming knowledge required to contribute. oo good point. yeah feel free to add some to the list. doing the samba one, it really didn't take long. took about... 4 minutes? looked to see if they have a charter (they don't), looked at their "dev" page to see if they have a VCS (they do: git), etc. etc. oh - i forgot one column: IRC channels! http://rhombus-tech.net/proposed_best_practices/ added. > I think for most people the inclination to donate to any software > projects fiscally, would be predictable (with a high confidence value) > by the the ratio of technical programming knowledge and their > dependence on the software created by that project. For that reason > you could also say, it would be a higher priority to evaluate gnome as > as a software project than debian, because ubuntu is more often > pitched to a less technical audience. ok the first phase is: get the info. evaluation comes later. > Of course, the fsf already > evaluates distributions not like this they don't. they evaluate them for *freedom* related (ethical) criteria. the purpose of this exercise is to first compile a list of projects and then "distil" the best and most efffective *development* practices, by demonstrating provably that, of the top NN% most highly respected projects, this is what they do. that's very very different... and means that the FSF's development practices (ok actually the GNU projects') are "on the list for evaluation". > and doesn't endorse ubuntu anyway, so it would > probably be perceived in really bad taste if the libre community > started listing reasons why they gave gnome a poor evaluation score if > that was the outcome, so I suppose it would be best to avoid it all > together and only evaluate desktop environments as software projects > if the are made available in an fsf-endorsed distribution by default. > (I know I've heard people say trisquel is based on ubuntu, but I don't > know what desktop environment it uses by default). > > All in all, for a base, I think aperture would be a good starting > point, since GIMP and Blender get a lot of flack that aperture doesn't > atm. well.... we would get to find that out as part of having a look at exactly what each of those projects do, and then seeing if there's a correlation, yes? but first we need to collect the information. oh. also, we need to make some sort of measure of the "effectiveness" of the project. whether it's caused people hassle (taken up inordinate amounts of time), whether the developers are liked or despised, whether they are welcoming and supportive of contributors (or not), how many people use it, and so on. it'll actually be quite a fascinating study. > I realize most of what they are doing is hardware, but their is a > lot of firmware involved. Also, I haven't heard very many complaints > about inkscape, so that would be a decent one to start with. I'm > hesitant to talk about OpenShot or libreoffice early on, because they > are (as we like to say in the wikipedia community) POV-forks than > independent projects. In other words, it's impossible to honestly and > sincerely evaluate LibreOffice as a project without comparing it to > OpenOffice and likewise OpenShot to Blender and in small part > Audacity. that's *exactly* the point of the exercise.... but that should not be done *right now*. at the moment all i would like there to be is a collation of "info". 3-4 minutes per project, "do they have a charter yes no do they use version control yes no is their infrastructure libre-hosted yes no". that's all. > Since I don't feel especially confident in my ability handling this > topic, I would probably sooner get feedback through this thread than > add any "evaluations" I make straight to the wiki. right now all that needs to be done is find the website for the project, and record what you find. take a look at the samba one as a starting point. > Because of this, I > think it's important I start by documenting on which ever of the "good > candidate" projects attracts the most interest in this thread, at > least on the philosophical level of how they "go about their business" > if not on a fundamental level of "I really like this project". we can discuss that later. and make sure that ideas on how to evaluate / compare projects are recorded in the wiki. but... later. l. From eaterjolly at gmail.com Fri Jul 14 17:02:59 2017 From: eaterjolly at gmail.com (Jean Flamelle) Date: Fri, 14 Jul 2017 12:02:59 -0400 Subject: [Arm-netbook] Standards Organization as a Potentially Universal Free/Libre Software Developement Sustenance Model In-Reply-To: References: <20170712103603.GA16243@pabbook> Message-ID: rhombus-tech.net appears to be down for me atm lol From lkcl at lkcl.net Fri Jul 14 18:51:54 2017 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Fri, 14 Jul 2017 18:51:54 +0100 Subject: [Arm-netbook] Standards Organization as a Potentially Universal Free/Libre Software Developement Sustenance Model In-Reply-To: References: <20170712103603.GA16243@pabbook> Message-ID: On Fri, Jul 14, 2017 at 5:02 PM, Jean Flamelle wrote: > rhombus-tech.net appears to be down for me atm lol http://downforeveryoneorjustme.com/rhombus-tech.net it's just you :) From eaterjolly at gmail.com Sat Jul 15 18:04:39 2017 From: eaterjolly at gmail.com (Jean Flamelle) Date: Sat, 15 Jul 2017 13:04:39 -0400 Subject: [Arm-netbook] Standards Organization as a Potentially Universal Free/Libre Software Developement Sustenance Model In-Reply-To: References: <20170712103603.GA16243@pabbook> Message-ID: That was weird, but anyways I updated the table by reorganizing it, cleaned the source a bit, added data for apertus and projects on the list. Let me know what you think of the formating changes. From eaterjolly at gmail.com Sat Jul 15 18:05:21 2017 From: eaterjolly at gmail.com (Jean Flamelle) Date: Sat, 15 Jul 2017 13:05:21 -0400 Subject: [Arm-netbook] Standards Organization as a Potentially Universal Free/Libre Software Developement Sustenance Model In-Reply-To: References: <20170712103603.GA16243@pabbook> Message-ID: put some more projects on the list* From lkcl at lkcl.net Sat Jul 15 19:07:09 2017 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Sat, 15 Jul 2017 19:07:09 +0100 Subject: [Arm-netbook] Standards Organization as a Potentially Universal Free/Libre Software Developement Sustenance Model In-Reply-To: References: <20170712103603.GA16243@pabbook> Message-ID: On Sat, Jul 15, 2017 at 6:04 PM, Jean Flamelle wrote: > That was weird, but anyways I updated the table by reorganizing it, > cleaned the source a bit, added data for apertus and projects on the > list. *well-known* :) is urbit actually... well-known?? > Let me know what you think of the formating changes. liked some, didn't like others. "etiquette guidelines" doesn't have the same toxic punch as "code of conduct" is well-known for. liked the idea of including the VCS and if it's libre-hosted (likewise for bugtracker) but *not* the wording you chose ("self-hosted"). self-hosted could mean "proprietary and therefore unethical" and people would put "yeah it's GR8 maaan!" so i changed it back *specifically* to "is it libre hosted yes or no" because that's really important. basically we're collating info - evidence - that ethical (or unethical) practices support a project's lifecycle... and other obseervations. what practices make a project both ethical *and* long-term successful. also i turned the table round by 90 degrees as i could see it getting far too long, and then broke them down into related groups. still some TODO. l. From calmstorm at posteo.de Sat Jul 15 20:57:07 2017 From: calmstorm at posteo.de (zap) Date: Sat, 15 Jul 2017 15:57:07 -0400 Subject: [Arm-netbook] Standards Organization as a Potentially Universal Free/Libre Software Developement Sustenance Model In-Reply-To: References: <20170712103603.GA16243@pabbook> Message-ID: > liked some, didn't like others. "etiquette guidelines" doesn't have > the same toxic punch as "code of conduct" is well-known for. liked > the idea of including the VCS and if it's libre-hosted (likewise for > bugtracker) but *not* the wording you chose ("self-hosted"). > self-hosted could mean "proprietary and therefore unethical" and > people would put "yeah it's GR8 maaan!" so i changed it back > *specifically* to "is it libre hosted yes or no" because that's really > important. > > basically we're collating info - evidence - that ethical (or > unethical) practices support a project's lifecycle... and other > obseervations. what practices make a project both ethical *and* > long-term successful. > > also i turned the table round by 90 degrees as i could see it getting > far too long, and then broke them down into related groups. still > some TODO.b > > l. I think any distro that is at devuan standards or better should be on the list. I would have said debian standard, but, I thought you might want me to stay clear of that... so yeah... as for repositories for hosting libre packages, notabug and gogs are good ones. From calmstorm at posteo.de Sat Jul 15 21:14:45 2017 From: calmstorm at posteo.de (zap) Date: Sat, 15 Jul 2017 16:14:45 -0400 Subject: [Arm-netbook] Do you think when the new LTS kernel comes out, Message-ID: <2b164509-82b3-af54-cefe-d8d906c6db7d@posteo.de> that it will support a20 in the near future? whether linux libre or not? I was curious because you said the processor a20 doesn't support linux 4.9 am I right? In september, I plan to order one. This will determine how much I want it. I use devuan ascii currently so... yeah. I don't really know when you will make the 2nd revision or whatever you call it of eoma68/? ? meaning the processor you choose which I believe you said was the rk3388 right? From eaterjolly at gmail.com Sun Jul 16 06:58:56 2017 From: eaterjolly at gmail.com (Jean Flamelle) Date: Sun, 16 Jul 2017 01:58:56 -0400 Subject: [Arm-netbook] Standards Organization as a Potentially Universal Free/Libre Software Developement Sustenance Model In-Reply-To: References: <20170712103603.GA16243@pabbook> Message-ID: On 7/15/17, Luke Kenneth Casson Leighton wrote: > liked some, didn't like others. "etiquette guidelines" doesn't have > the same toxic punch as "code of conduct" is well-known for. The word "code" in "code of conduct" does usually implies formal membership, so I thought it might be confusing to some people if the phrase became popular in closed circles. Etiquette guidelines isn't perfect either, because samba technically actually has a page called "Etiquette" however that refers to trimming mailing list posts and not in any way how people ought to treat each other. Perhaps "Contributor Conduct Guidelines"? liked > the idea of including the VCS and if it's libre-hosted (likewise for > bugtracker) but *not* the wording you chose ("self-hosted"). I opted to separate it like that to make it more unambiguous, since there are two possible definitions of libre in regard to websites: open-source/free scripts and open-source/free server code. Most browsers provide no practical way to prove the source code belongs to the scripts actually sent by the server, without running them, and because of this it might be argued that the server code should also be libre so that anyone could run an offline mirror. If we say arbitrarily that a website is libre it could mean one of three things: functions w/o script, open-source/free scripts, or open-source/free server code. The assumption is that if the server code is libre, then self-hosting should make by extension the repositories libre. Though, I suppose there would be nothing hindering someone from just omitting that part of the server code, on second thought. It's a tricky situation. > also i turned the table round by 90 degrees as i could see it getting > far too long, and then broke them down into related groups. still > some TODO. Thanks, much less cluttered! I use cut-and-paste to convert the spaces to tabs just now to clean the source. Also, on a side note, I put urbit on there because they are unorthodox and because they have an unusually high ratio interest compared to people actually able to contribute, much like you would expect from RISC or KiCAD, but not 'another' replacement for apache. From lkcl at lkcl.net Sun Jul 16 07:27:45 2017 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Sun, 16 Jul 2017 07:27:45 +0100 Subject: [Arm-netbook] Standards Organization as a Potentially Universal Free/Libre Software Developement Sustenance Model In-Reply-To: References: <20170712103603.GA16243@pabbook> Message-ID: --- crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68 On Sat, Jul 15, 2017 at 8:57 PM, zap wrote: > I think any distro that is at devuan standards or better should be on > the list. agreed. > I would have said debian standard, but, I thought you might want me to > stay clear of that... so yeah... ... hadn't occurred to me at all, but now that you mention it, let's think about it... yes i would, because each project stands on its own merits and is responsible for its own management. > as for repositories for hosting libre packages, notabug and gogs are > good ones. are they well-known, well-established and prominent? l. From lkcl at lkcl.net Sun Jul 16 07:41:20 2017 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Sun, 16 Jul 2017 07:41:20 +0100 Subject: [Arm-netbook] Standards Organization as a Potentially Universal Free/Libre Software Developement Sustenance Model In-Reply-To: References: <20170712103603.GA16243@pabbook> Message-ID: --- crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68 On Sun, Jul 16, 2017 at 6:58 AM, Jean Flamelle wrote: > On 7/15/17, Luke Kenneth Casson Leighton wrote: >> liked some, didn't like others. "etiquette guidelines" doesn't have >> the same toxic punch as "code of conduct" is well-known for. > > The word "code" in "code of conduct" does usually implies formal > membership, so I thought it might be confusing to some people if the > phrase became popular in closed circles. no - it's well-known that "code of conduct" is a dangerous, toxic and highly unethical system of "control" over contributors. *i* didn't know that, so i did a comprehensive analysis here on the list about 6-8 months ago, and emphatically agreed with the assessment. unfortunately there are many many projects that have absolutely no idea of the dangers of "codes of conduct" so continue to deploy them. so the idea is to *specifically* identify those projects that have one of these dangerous "codes of conduct" in order to see if there is a correlation between harm done to developers and end-users and the use of such toxic documents. > Etiquette guidelines isn't perfect either, because samba technically > actually has a page called "Etiquette" however that refers to trimming > mailing list posts and not in any way how people ought to treat each > other. okaaay.... sooo.... that should probably go on a "/" mailing list / ML-etiquette > Perhaps "Contributor Conduct Guidelines"? no. sorry. explained above. > liked >> the idea of including the VCS and if it's libre-hosted (likewise for >> bugtracker) but *not* the wording you chose ("self-hosted"). > > I opted to separate it like that to make it more unambiguous, since > there are two possible definitions of libre in regard to websites: > open-source/free scripts and open-source/free server code. hmmm.... *thinks*... is the distinction important? don't know. so it should probably go on the list. it might be statistically significant. so a column "Web site source available / License" and now that i think about it "Documentation source available / License" should be added > Most > browsers provide no practical way to prove the source code belongs to > the scripts actually sent by the server, without running them, someone somewhere will run librejs to determine that > and > because of this it might be argued that the server code should also be > libre so that anyone could run an offline mirror. more importantly they can *fork* the project.... but only if the full source of the web site server source is available and does not critically depend on proprietary components. > If we say arbitrarily that a website is libre it could mean one of > three things: functions w/o script, open-source/free scripts, or > open-source/free server code. true. > The assumption is that if the server code is libre, then self-hosting > should make by extension the repositories libre. Though, I suppose > there would be nothing hindering someone from just omitting that part > of the server code, on second thought. It's a tricky situation. > > >> also i turned the table round by 90 degrees as i could see it getting >> far too long, and then broke them down into related groups. still >> some TODO. > > Thanks, much less cluttered! > > I use cut-and-paste to convert the spaces to tabs just now to clean the source. yuck. please don't: i use 4-spaces-per-tab where other people will use 8. also, the reason for using spaces is because you can just put your editor into "replace" mode and the formatting remains stable. please put it back. > Also, on a side note, I put urbit on there because they are unorthodox > and because they have an unusually high ratio interest compared to > people actually able to contribute, much like you would expect from > RISC or KiCAD, but not 'another' replacement for apache. hmmm, ok, cool. hmm... reminds me, established date should be added. l. From eaterjolly at gmail.com Sun Jul 16 12:26:02 2017 From: eaterjolly at gmail.com (Jean Flamelle) Date: Sun, 16 Jul 2017 07:26:02 -0400 Subject: [Arm-netbook] Standards Organization as a Potentially Universal Free/Libre Software Developement Sustenance Model In-Reply-To: References: <20170712103603.GA16243@pabbook> Message-ID: On 7/16/17, Luke Kenneth Casson Leighton wrote: >> The word "code" in "code of conduct" does usually implies formal >> membership, so I thought it might be confusing to some people if the >> phrase became popular in closed circles. > > no - it's well-known that "code of conduct" is a dangerous, toxic and > highly unethical system of "control" over contributors. *i* didn't know > that, so i did a comprehensive analysis here on the list about 6-8 > months ago, and emphatically agreed with the assessment. Ah - I see. I think I see it as more a representation of what moderators will probably do regardless of if said document exists or not. I think it very toxic if they try to hurt project forks that do things differently, but moderators inevitably will try to establish a certain culture within their project and documenting the moderators behaviors will set the right expectations in people. Inevitably, and especially as the open-source and free software communities grow, there will be project forks based simply on certain people that can't cooperate with each other. I think this kind of conflict can breed a healthy diversity in people, so, if a small group of contributors write up a small "code of conduct" on how they like to be treated, I think that can be healthy depending on the circumstances. I see it that such a doc could mean "don't talk to me, if you do X" or it could mean "you can't have my code, if you do X". The former is all well and fine, but the later I'd agree is toxic. >> I opted to separate it like that to make it more unambiguous, since >> there are two possible definitions of libre in regard to websites: >> open-source/free scripts and open-source/free server code. > > hmmm.... *thinks*... is the distinction important? don't know. so > it should probably go on the list. it might be statistically > significant. > > so a column "Web site source available / License" > and now that i think about it "Documentation source available / License" > > should be added I'm starting to really feel the usefulness of collecting this data :> > > yuck. please don't: i use 4-spaces-per-tab where other people will > use 8. also, the reason for using spaces is because you can just put > your editor into "replace" mode and the formatting remains stable. > > please put it back. > I got this error trying to revert the change back "Error: Failed to revert commit 27584a06584f4942b6d24bda08511cedd3f867d3 'git revert --no-commit 27584a06584f4942b6d24bda08511cedd3f867d3' failed: " Hm, the web editor uses a proportional-pitch font, so it's impossible to tell the number of spaces in a table to get alignment. (didn't realize you could use git to edit it, so I thought you also saw this.) I'm not in on the spaces v. tabs holy war. lol From lkcl at lkcl.net Sun Jul 16 14:12:29 2017 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Sun, 16 Jul 2017 14:12:29 +0100 Subject: [Arm-netbook] Standards Organization as a Potentially Universal Free/Libre Software Developement Sustenance Model In-Reply-To: References: <20170712103603.GA16243@pabbook> Message-ID: On Sun, Jul 16, 2017 at 12:26 PM, Jean Flamelle wrote: > I got this error trying to revert the change back "Error: Failed to > revert commit 27584a06584f4942b6d24bda08511cedd3f867d3 'git revert > --no-commit 27584a06584f4942b6d24bda08511cedd3f867d3' failed: " yep you'll need to do it manually: i edited the page in the meantime. sorry. > Hm, the web editor uses a proportional-pitch font, so it's impossible > to tell the number of spaces in a table to get alignment. stuff it into a text editor with a fixed-width font. From lkcl at lkcl.net Sun Jul 16 14:14:26 2017 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Sun, 16 Jul 2017 14:14:26 +0100 Subject: [Arm-netbook] Standards Organization as a Potentially Universal Free/Libre Software Developement Sustenance Model In-Reply-To: References: <20170712103603.GA16243@pabbook> Message-ID: On Sun, Jul 16, 2017 at 2:12 PM, Luke Kenneth Casson Leighton wrote: > On Sun, Jul 16, 2017 at 12:26 PM, Jean Flamelle wrote: > >> I got this error trying to revert the change back "Error: Failed to >> revert commit 27584a06584f4942b6d24bda08511cedd3f867d3 'git revert >> --no-commit 27584a06584f4942b6d24bda08511cedd3f867d3' failed: " > > yep you'll need to do it manually: i edited the page in the meantime. sorry. > >> Hm, the web editor uses a proportional-pitch font, so it's impossible >> to tell the number of spaces in a table to get alignment. > > stuff it into a text editor with a fixed-width font. ... or... get the previous version, work out what i did, go the previous-previous version, restore that (manually) then hand-add what i added... ah y'know what? sod it - i have access to git: i'll do it :) l. From lkcl at lkcl.net Sun Jul 16 14:19:07 2017 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Sun, 16 Jul 2017 14:19:07 +0100 Subject: [Arm-netbook] Standards Organization as a Potentially Universal Free/Libre Software Developement Sustenance Model In-Reply-To: References: <20170712103603.GA16243@pabbook> Message-ID: On Sun, Jul 16, 2017 at 2:14 PM, Luke Kenneth Casson Leighton wrote: >>> Hm, the web editor uses a proportional-pitch font, so it's impossible >>> to tell the number of spaces in a table to get alignment. >> >> stuff it into a text editor with a fixed-width font. > > ... or... get the previous version, work out what i did, go the > previous-previous version, restore that (manually) then hand-add what > i added... > > ah y'know what? sod it - i have access to git: i'll do it :) done. there's no "war" on tabs/spaces, there's just "one is more appropriate for the circumstances than the other". for c i always use tabs. for python i *always* follow PEP8. it always depends on circumstances. l. From calmstorm at posteo.de Sun Jul 16 17:26:40 2017 From: calmstorm at posteo.de (zap) Date: Sun, 16 Jul 2017 12:26:40 -0400 Subject: [Arm-netbook] Standards Organization as a Potentially Universal Free/Libre Software Developement Sustenance Model In-Reply-To: References: <20170712103603.GA16243@pabbook> Message-ID: >> as for repositories for hosting libre packages, notabug and gogs are >> good ones. > are they well-known, well-established and prominent? > > l. Notabug is used for libreboot so it cannot be a bad idea. as for gogs, librecmc uses gogs. > _______________________________________________ > arm-netbook mailing list arm-netbook at lists.phcomp.co.uk > http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook > Send large attachments to arm-netbook at files.phcomp.co.uk From richard.wilbur at gmail.com Mon Jul 17 07:26:57 2017 From: richard.wilbur at gmail.com (Richard Wilbur) Date: Mon, 17 Jul 2017 00:26:57 -0600 Subject: [Arm-netbook] Arm Netbook, Saw the update, In-Reply-To: References: <729312675.2922981.1498019518849.ref@mail.yahoo.com> <729312675.2922981.1498019518849@mail.yahoo.com> <594A892D.6040009@posteo.de> <74fd6c20-725d-5eac-1057-1a4be035ddea@aross.me> <1DAA53E0-C7C8-4DED-8E62-087C2B20AFE6@gmail.com> <87485148-2167-45A7-8298-FDE1A6C66B6F@gmail.com> Message-ID: <936CCB09-9310-4405-A7B6-C85CA4944309@gmail.com> >> On Jul 4, 2017, at 09:50, Luke Kenneth Casson Leighton wrote: >> >> On Tue, Jul 4, 2017 at 4:15 PM, Richard Wilbur wrote: > […] >> A couple questions that spring immediately to mind: >> 1. How continuous are the ground planes under the differential pairs? (Are there voids in the ground planes under the differential pairs?) > > no. layers 2 and 5 are solid ground planes. vias obviously go > through those , full vias only. non-GND vias also obviously create > small interruptions but that's all Wonderful! That's music to my ears. No major obstacles on return current path except the vias. So when we change signal layers, we'll need adjacent ground plane-to-ground plane vias to provide a nice low-impedance path for the return current in the ground planes. >> 2. The intra-pair length sounds well-matched, my understanding of the inter-pair skew is that the requirement is in terms of the clock speed Δt <= 0.2 Tcharacter. For 225 MHz clock the application note spoke of 888ps. So we'll be interested in determining the maximum clock rate and speed of propagation. > > 3e8 m/sec * 888e-12 = 0.2664 metres.... which is 266.4 mm... way > beyond anything which would indicate some kind of problem if the board > is 78mm long and the skew is only 2mm. You're on the right track and that is a good calculation for propagation in free space (vacuum). It turns out with relative permittivity of FR-4 fiberglass substrate our signal actually travels significantly slower which tightens our design parameters a little. >> I'll also have some questions about dimensions and geometry. > > ack. Not too awful. Just a few questions about how you are routing to control the impedance. 1. Are you using a 2-D field solver to determine the impedance and adjust design parameters accordingly(trace width, intra-pair spacing, inter-pair spacing, etc.)? 2. Are you working with your board fabricator to determine the design parameters mentioned above b From richard.wilbur at gmail.com Mon Jul 17 07:45:14 2017 From: richard.wilbur at gmail.com (Richard Wilbur) Date: Mon, 17 Jul 2017 00:45:14 -0600 Subject: [Arm-netbook] Arm Netbook, Saw the update, In-Reply-To: <936CCB09-9310-4405-A7B6-C85CA4944309@gmail.com> References: <729312675.2922981.1498019518849.ref@mail.yahoo.com> <729312675.2922981.1498019518849@mail.yahoo.com> <594A892D.6040009@posteo.de> <74fd6c20-725d-5eac-1057-1a4be035ddea@aross.me> <1DAA53E0-C7C8-4DED-8E62-087C2B20AFE6@gmail.com> <87485148-2167-45A7-8298-FDE1A6C66B6F@gmail.com> <936CCB09-9310-4405-A7B6-C85CA4944309@gmail.com> Message-ID: Sorry, that last post was far from complete and I'm working on a more complete set of questions and recommendations which I hope to get off to you tomorrow. Any answers will be appreciated, as usual. I've been working on this primarily in the evenings over the last week or so and found 64 pages of "light, bed-time" reading. We are back from a weekend without electricity, internet service, or cellular telephone service. -- Richard From lkcl at lkcl.net Mon Jul 17 08:14:07 2017 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Mon, 17 Jul 2017 08:14:07 +0100 Subject: [Arm-netbook] Arm Netbook, Saw the update, In-Reply-To: References: <729312675.2922981.1498019518849.ref@mail.yahoo.com> <729312675.2922981.1498019518849@mail.yahoo.com> <594A892D.6040009@posteo.de> <74fd6c20-725d-5eac-1057-1a4be035ddea@aross.me> <1DAA53E0-C7C8-4DED-8E62-087C2B20AFE6@gmail.com> <87485148-2167-45A7-8298-FDE1A6C66B6F@gmail.com> <936CCB09-9310-4405-A7B6-C85CA4944309@gmail.com> Message-ID: --- crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68 On Mon, Jul 17, 2017 at 7:45 AM, Richard Wilbur wrote: > > Sorry, that last post was far from complete and I'm working on a more complete set of questions and recommendations which I hope to get off to you tomorrow. Any answers will be appreciated, as usual. i've done some improvements since, i'm just about to update them. > I've been working on this primarily in the evenings over the last week or so and found 64 pages of "light, bed-time" reading. > > We are back from a weekend without electricity, internet service, or cellular telephone service. niiiice :) From lkcl at lkcl.net Mon Jul 17 08:16:46 2017 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Mon, 17 Jul 2017 08:16:46 +0100 Subject: [Arm-netbook] Arm Netbook, Saw the update, In-Reply-To: <936CCB09-9310-4405-A7B6-C85CA4944309@gmail.com> References: <729312675.2922981.1498019518849.ref@mail.yahoo.com> <729312675.2922981.1498019518849@mail.yahoo.com> <594A892D.6040009@posteo.de> <74fd6c20-725d-5eac-1057-1a4be035ddea@aross.me> <1DAA53E0-C7C8-4DED-8E62-087C2B20AFE6@gmail.com> <87485148-2167-45A7-8298-FDE1A6C66B6F@gmail.com> <936CCB09-9310-4405-A7B6-C85CA4944309@gmail.com> Message-ID: --- crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68 On Mon, Jul 17, 2017 at 7:26 AM, Richard Wilbur wrote: >>> On Jul 4, 2017, at 09:50, Luke Kenneth Casson Leighton wrote: >>> >>> On Tue, Jul 4, 2017 at 4:15 PM, Richard Wilbur wrote: >> […] >>> A couple questions that spring immediately to mind: >>> 1. How continuous are the ground planes under the differential pairs? (Are there voids in the ground planes under the differential pairs?) >> >> no. layers 2 and 5 are solid ground planes. vias obviously go >> through those , full vias only. non-GND vias also obviously create >> small interruptions but that's all > > Wonderful! That's music to my ears. No major obstacles on return current path except the vias. So when we change signal layers, we'll need adjacent ground plane-to-ground plane vias to provide a nice low-impedance path for the return current in the ground planes. i've added as many of these as i can fit. space is... very very tight. >>> 2. The intra-pair length sounds well-matched, my understanding of the inter-pair skew is that the requirement is in terms of the clock speed Δt <= 0.2 Tcharacter. For 225 MHz clock the application note spoke of 888ps. So we'll be interested in determining the maximum clock rate and speed of propagation. >> >> 3e8 m/sec * 888e-12 = 0.2664 metres.... which is 266.4 mm... way >> beyond anything which would indicate some kind of problem if the board >> is 78mm long and the skew is only 2mm. > > You're on the right track and that is a good calculation for propagation in free space (vacuum). It turns out with relative permittivity of FR-4 fiberglass substrate our signal actually travels significantly slower which tightens our design parameters a little. oh! duh! i forgot about that > Not too awful. Just a few questions about how you are routing to control the impedance. > 1. Are you using a 2-D field solver to determine the impedance and adjust design parameters accordingly(trace width, intra-pair spacing, inter-pair spacing, etc.)? PADS can calculate impedance based on board stack, track width and track-to-track spacing... i'm... relying on that, and the fact that the tracks are 50mm long. > 2. Are you working with your board fabricator to determine the design parameters mentioned above b nnaahh. From pablo at parobalth.org Mon Jul 17 11:26:04 2017 From: pablo at parobalth.org (Pablo Rath) Date: Mon, 17 Jul 2017 12:26:04 +0200 Subject: [Arm-netbook] Standards Organization as a Potentially Universal Free/Libre Software Developement Sustenance Model In-Reply-To: References: <20170712103603.GA16243@pabbook> Message-ID: <20170717102604.GA11067@pabbook> On Fri, Jul 14, 2017 at 04:36:49PM +0100, Luke Kenneth Casson Leighton wrote: > > oh - i forgot one column: IRC channels! > > http://rhombus-tech.net/proposed_best_practices/ > > added. Should we also add a line and check if the projects have a wiki. Personally I get a ton of information from Debian and Arch wikis and they a good way for collaboration between developers and users. kind regards Pablo From lkcl at lkcl.net Mon Jul 17 11:27:27 2017 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Mon, 17 Jul 2017 11:27:27 +0100 Subject: [Arm-netbook] Standards Organization as a Potentially Universal Free/Libre Software Developement Sustenance Model In-Reply-To: <20170717102604.GA11067@pabbook> References: <20170712103603.GA16243@pabbook> <20170717102604.GA11067@pabbook> Message-ID: On Mon, Jul 17, 2017 at 11:26 AM, Pablo Rath wrote: > On Fri, Jul 14, 2017 at 04:36:49PM +0100, Luke Kenneth Casson Leighton wrote: >> >> oh - i forgot one column: IRC channels! >> >> http://rhombus-tech.net/proposed_best_practices/ >> >> added. > > Should we also add a line and check if the projects have a wiki. > Personally I get a ton of information from Debian and Arch wikis and > they a good way for collaboration between developers and users. good point - "wiki / license" From salatkabel+armnetbooks at mailbox.org Mon Jul 17 11:40:34 2017 From: salatkabel+armnetbooks at mailbox.org (Christian Pietsch) Date: Mon, 17 Jul 2017 12:40:34 +0200 Subject: [Arm-netbook] Standards Organization as a Potentially Universal Free/Libre Software Developement Sustenance Model In-Reply-To: References: <20170712103603.GA16243@pabbook> Message-ID: <2CA17EE0-79FC-4395-A6CC-68FB6FB5AEBE@mailbox.org> Hi EOMA68 community, the Free Software Foundation Europe chose Gitea, a gogs fork, for their new source code hosting service: https://git.fsfe.org/ Cheers, Christian Am 16. Juli 2017 18:26:40 MESZ schrieb zap : > >>> as for repositories for hosting libre packages, notabug and gogs are >>> good ones. >> are they well-known, well-established and prominent? >> >> l. > >Notabug is used for libreboot so it cannot be a bad idea. as for gogs, >librecmc uses gogs. From richard.wilbur at gmail.com Tue Jul 18 18:16:22 2017 From: richard.wilbur at gmail.com (Richard Wilbur) Date: Tue, 18 Jul 2017 11:16:22 -0600 Subject: [Arm-netbook] Arm Netbook, Saw the update, In-Reply-To: References: <729312675.2922981.1498019518849.ref@mail.yahoo.com> <729312675.2922981.1498019518849@mail.yahoo.com> <594A892D.6040009@posteo.de> <74fd6c20-725d-5eac-1057-1a4be035ddea@aross.me> <1DAA53E0-C7C8-4DED-8E62-087C2B20AFE6@gmail.com> <87485148-2167-45A7-8298-FDE1A6C66B6F@gmail.com> <936CCB09-9310-4405-A7B6-C85CA4944309@gmail.com> Message-ID: On Mon, Jul 17, 2017 at 1:16 AM, Luke Kenneth Casson Leighton wrote: > On Mon, Jul 17, 2017 at 7:26 AM, Richard Wilbur > wrote: >> Wonderful! That's music to my ears. No major obstacles on return current path except the vias. So when we change signal layers, we'll need adjacent ground plane-to-ground plane vias to provide a nice low-impedance path for the return current in the ground planes. > > i've added as many of these as i can fit. space is... very very tight. For our differential pairs we should only need one return-current-path via per signal via (and hopefully relatively adjacent to it) since we are using ground planes for our reference planes. It is basically trying to provide a relatively low-impedance path for the RF (radio-frequency) return current in the reference planes (since when we switch signal layers between top and bottom, our reference plane changes). > PADS can calculate impedance based on board stack, track width and > track-to-track spacing... i'm... relying on that, and the fact that > the tracks are 50mm long. >From what I'm reading this looks easiest (and best) to tackle in segments of no more than 15mm at a time. Can PADS work with you on one section of the path at a time? More details in next message. 1. Are you specifying the track width, track-to-track spacing, and board stack or is PADS determining that for you? 2. What are you using for the ... a. microstrip differential pair track widths, b. intra-pair track spacing, c. differential-pair-to-other track spacing? 3. What is your copper thickness on top and bottom layers? 4. What is the height of insulator between top layer and adjacent ground reference layer? 5. What is the height of insulator between bottom layer and adjacent ground reference layer? -- Richard From richard.wilbur at gmail.com Wed Jul 19 06:52:41 2017 From: richard.wilbur at gmail.com (Richard Wilbur) Date: Tue, 18 Jul 2017 23:52:41 -0600 Subject: [Arm-netbook] rhombus-tech.net 'Server not found' Message-ID: Anybody else see rhombus-tech.net right now? I'm thankful I saved the images of the PCB I'm reviewing to the local computer. -- Richard From desttinghimgame at gmail.com Wed Jul 19 07:11:12 2017 From: desttinghimgame at gmail.com (Louis Pearson) Date: Wed, 19 Jul 2017 01:11:12 -0500 Subject: [Arm-netbook] rhombus-tech.net 'Server not found' In-Reply-To: References: Message-ID: http://rhombus-tech.net/ is up for me. From lkcl at lkcl.net Wed Jul 19 07:13:31 2017 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Wed, 19 Jul 2017 07:13:31 +0100 Subject: [Arm-netbook] rhombus-tech.net 'Server not found' In-Reply-To: References: Message-ID: blergh, the dns appears to have gone wonky. sorted now with a temporary hack. --- crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68 On Wed, Jul 19, 2017 at 6:52 AM, Richard Wilbur wrote: > Anybody else see rhombus-tech.net right now? I'm thankful I saved the > images of the PCB I'm reviewing to the local computer. > > -- > Richard > > _______________________________________________ > arm-netbook mailing list arm-netbook at lists.phcomp.co.uk > http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook > Send large attachments to arm-netbook at files.phcomp.co.uk From richard.wilbur at gmail.com Wed Jul 19 07:29:30 2017 From: richard.wilbur at gmail.com (Richard Wilbur) Date: Wed, 19 Jul 2017 00:29:30 -0600 Subject: [Arm-netbook] rhombus-tech.net 'Server not found' In-Reply-To: References: Message-ID: On Wed, Jul 19, 2017 at 12:13 AM, Luke Kenneth Casson Leighton wrote: > blergh, the dns appears to have gone wonky. sorted now with a temporary hack. Luke: Thank you for whatever you did as I can again see the rhombus-tech.net server. From lkcl at lkcl.net Thu Jul 20 17:07:27 2017 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Thu, 20 Jul 2017 17:07:27 +0100 Subject: [Arm-netbook] Arm Netbook, Saw the update, In-Reply-To: References: <729312675.2922981.1498019518849.ref@mail.yahoo.com> <729312675.2922981.1498019518849@mail.yahoo.com> <594A892D.6040009@posteo.de> <74fd6c20-725d-5eac-1057-1a4be035ddea@aross.me> Message-ID: On Tue, Jun 27, 2017 at 4:56 AM, Richard Wilbur wrote: > In the interest of solving the challenge of integrating the HDMI connector, I have a few questions: > 1. Is there a publicly-accessible spot from which I can download the schematics and pcb files? (I found http://rhombus-tech.net/allwinner_a10/pcb/ is that the correct place?) not yet. > 2. How many copper layers does this board have? 6 > 3. What is the minimum trace size? 5mil > 4. What is the minimum trace spacing? 5mil. > 5. Is the minimum plated through hole diameter 6 mil? yes. with a 12mil surround. > 6. Did this message (composed on my iPhone E-mail client) come through in HTML or simple text? no idea. > The Amphenol part has 0.15mm clearance between lands for even row of pins and board edge in cutout while Molex 468753011 has 0.9mm clearance in the same spot. i'll be using the JAE DC3 because the pins are exposed, meaning that standard oven baking can be used. the amphenol part the pins are covered over, meaning that a second pass of solder reflow is needed. that costs money... and sometimes doesn't work anyway. From lkcl at lkcl.net Thu Jul 20 17:20:44 2017 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Thu, 20 Jul 2017 17:20:44 +0100 Subject: [Arm-netbook] Arm Netbook, Saw the update, In-Reply-To: References: <729312675.2922981.1498019518849.ref@mail.yahoo.com> <729312675.2922981.1498019518849@mail.yahoo.com> <594A892D.6040009@posteo.de> <74fd6c20-725d-5eac-1057-1a4be035ddea@aross.me> <1DAA53E0-C7C8-4DED-8E62-087C2B20AFE6@gmail.com> <87485148-2167-45A7-8298-FDE1A6C66B6F@gmail.com> <936CCB09-9310-4405-A7B6-C85CA4944309@gmail.com> Message-ID: --- crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68 On Tue, Jul 18, 2017 at 6:16 PM, Richard Wilbur wrote: > On Mon, Jul 17, 2017 at 1:16 AM, Luke Kenneth Casson Leighton > wrote: >> On Mon, Jul 17, 2017 at 7:26 AM, Richard Wilbur >> wrote: >>> Wonderful! That's music to my ears. No major obstacles on return current path except the vias. So when we change signal layers, we'll need adjacent ground plane-to-ground plane vias to provide a nice low-impedance path for the return current in the ground planes. >> >> i've added as many of these as i can fit. space is... very very tight. > > For our differential pairs we should only need one return-current-path > via per signal via (and hopefully relatively adjacent to it) since we > are using ground planes for our reference planes. It is basically > trying to provide a relatively low-impedance path for the RF > (radio-frequency) return current in the reference planes (since when > we switch signal layers between top and bottom, our reference plane > changes). as best i can i've put the vias as close as possible. here's some new images http://hands.com/~lkcl/eoma/a20_hdmi_review/ i've also lined the bottom edge with vias, and there are a lot along the top of the diff-pairs, separating other signals. >> PADS can calculate impedance based on board stack, track width and >> track-to-track spacing... i'm... relying on that, and the fact that >> the tracks are 50mm long. > > From what I'm reading this looks easiest (and best) to tackle in > segments of no more than 15mm at a time. Can PADS work with you on > one section of the path at a time? mmm.. don't think so. i can select a pin pair and it tells me that the impedance is 89 ohms. > More details in next message. > > 1. Are you specifying the track width, minimum 5mil. specified in groups. > track-to-track spacing, 5mil minimum > and board stack board thickness 47.3 (1.2mm), 1oz copper, 6.4mil on FR4. > or is PADS determining that for you? how would it know? > 2. What are you using for the ... > a. microstrip differential pair track widths, 5 mil > b. intra-pair track spacing, 5 mil > c. differential-pair-to-other track spacing? 5 mil > 3. What is your copper thickness on top and bottom layers? 1oz > 4. What is the height of insulator between top layer and adjacent > ground reference layer? 6.4 mil > 5. What is the height of insulator between bottom layer and adjacent > ground reference layer? 6.4 mil. standard 6 layer stack basically. l. From richard.wilbur at gmail.com Thu Jul 20 22:35:35 2017 From: richard.wilbur at gmail.com (Richard Wilbur) Date: Thu, 20 Jul 2017 15:35:35 -0600 Subject: [Arm-netbook] Arm Netbook, Saw the update, In-Reply-To: References: <729312675.2922981.1498019518849.ref@mail.yahoo.com> <729312675.2922981.1498019518849@mail.yahoo.com> <594A892D.6040009@posteo.de> <74fd6c20-725d-5eac-1057-1a4be035ddea@aross.me> Message-ID: On Thu, Jul 20, 2017 at 10:07 AM, Luke Kenneth Casson Leighton wrote: > On Tue, Jun 27, 2017 at 4:56 AM, Richard Wilbur > wrote: > >> In the interest of solving the challenge of integrating the HDMI connector, I have a few questions: [...] >> 2. How many copper layers does this board have? > > 6 Okay, that didn't change since the last time you answered this. (You just answered the more complete version of my reply sent back on 27 Jun. I accidentally sent it before I finished writing it--and then sent the complete version after I finished writing it. You replied in June to the incomplete version of the message and today to the complete version. Sorry for causing any confusion as I am still making peace with the user interface of my smart phone E-mail client--which I'm thankfully not using right now.) >> 3. What is the minimum trace size? > > 5mil > >> 4. What is the minimum trace spacing? > > 5mil. Did you change pcb fabricators recently? In June you said the minimum trace size and spacing were 3.5mil. Just want to be sure I'm working with the right numbers. >> 5. Is the minimum plated through hole diameter 6 mil? > > yes. with a 12mil surround. > [...] >> The Amphenol part has 0.15mm clearance between lands for even row of pins and board edge in cutout while Molex 468753011 has 0.9mm clearance in the same spot. > > i'll be using the JAE DC3 because the pins are exposed, meaning that > standard oven baking can be used. the amphenol part the pins are > covered over, meaning that a second pass of solder reflow is needed. > that costs money... and sometimes doesn't work anyway. Sounds like an improvement in manufacturability. Which part are you using? These are all mid-mount micro-HDMI receptacles. part number mounting depth Shell DIP length(mm) DC3R019JA1R1500 0.95mm 1.2 DC3R019JA5R1500 0.95mm 0.8 DC3R019JA7R1500 0.65mm 0.65 From ml.eoma68 at eml.cc Thu Jul 20 23:07:26 2017 From: ml.eoma68 at eml.cc (Vincent) Date: Fri, 21 Jul 2017 00:07:26 +0200 Subject: [Arm-netbook] Existential 3D Printing Moments In-Reply-To: References: Message-ID: <53df99d5-6a9c-8880-3508-673d2886791b@eml.cc> Any status update on the 3D printing issues? On 05/19/2017 07:03 AM, Luke Kenneth Casson Leighton wrote: > --- > crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68 > > > On Fri, May 19, 2017 at 5:08 AM, Neil Jansen wrote: > >>> and now you can use a 24v heater you can spend another extra $5 on an >>> E3Dv6 volcano clone, now you can get *another* 20% increase in speed >>> for only a 2.5% increase in budget. >> >> As you can see from the pics, we ran on the cheapest 12V power supplies that >> we could find. Before that I tested 24V, it wasn't worth the cost. Again, >> brickwall economics here. We went cheap. The 12V power supplies were >> purchased in bulk and were maybe $14 USD each? > > yeh meanwell's my favourite and there's no difference between 12 and > 24v prices. > >> The 3D printed mounts and >> the little PCB's were practically free and it would turn the supply on and >> off between jobs whereas our 24V bricks were on all the time. The ONLY >> thing that we splurged on at the time was the E3D nozzles and that was more >> of a crapshoot. I would have done better to cheap out on those as well, I >> could have printed more reliably with the cheaper J-Heads. > > i wonder what was going on as the only time i've had problems with an > E3Dv6 is when the fan on the heatsink wasn't running. that was bad. > heat travelled up the tube and melted the filament *above* the hotend > entry point. all bets were off at that point. > >> Don't bother minimizing extrusion if you do end up redesigning (gah!). It's >> cheap as dirt nowadays if you're buying the generic stuff. If you want >> rigid, well there you go. > > i do - and i know how it's achieved. i've had an excellent 3D visual > manipulation ability for like... 35 years. > >> I have a junk box full of Melzi's, they were horrible, but it was all >> manufacturing defects from a crappy Chinese company. The Chinese version >> took some artistic leeway that the original (British IIRC?) designer >> probably never intended. > > aiyaaa... > >> I've used both as I've said. Mine never stalled out. I used cheap-as-dirt >> A4998's. Of course, I was running them < 100mm/sec and they were happy >> there. > > yehyeh. > >>> i just... i can't bring myself to spend backers' money on stuff that >>> i know is crud, neil. >> >> You're starting to sound like a German engineer now :) They're not crud if >> you use them within the constraints that I outlined. No need to turn your >> nose at them. What I'm trying to get at is that you've got this huge point >> of diminishing returns, you can place yourself on either side of it. > > i will stop when the speed/$ improvement is parity. anything that > gives a 1:1 ratio (or less, obviously) is not worth it and is "out"... > *unless* an improvement can in turn have a cascade effect of allowing > *another* improvement that *does* increase the speed/$ ratio. > >>> sso i've been spending some time tracking down board designs and so >>> on. Arduino Due: https://world.taobao.com/item/539393961702.htm RMB >>> 75 so that's around $12. >> >> Dang those Due's are getting cheaper, back in my day those were a pretty >> penny. > > yehyeh - my favourite's the STM32F072 as it has a built-in crystal (a > not very good one) but then the PLL can phase-lock to the USB bus from > whatever it's connected to, compensating for crystal inaccuracies. > price? $1.70. STM32F072-NUCLEO board? $10 on digikey. > > mad. absolutely mad. > >>> and TRAMS uses TMC2100s, where their Reference Design has full PCB >>> and schematics available: if i'm doing 10+ i can just send that to >>> mike and he can make them. TRAMS is *real* basic. 4 steppers, 2 >>> beefy power MOSFETs (extruder, printbed), 2 smaller ones for fans. >> >> <3 TMC2100's. Our PnP was going to use TMC2130's. Great German drivers. >> However #1 they're hard as shit to import into China, which sucked for us at >> the time. You can get damn near anything in China but this was one of those >> parts that just isn't really something that they use. It was, to this day, >> the only part that I could not find on Taobao. We may have smuggled our >> samples in from Hong Kong. > > dang. > > well.. https://world.tmall.com/item/551108503978.htm?spm=a312a.7700714.0.0.3zdhiQ > RMB 23. about $4. > > so that looks prooobably like it's sorted... > >> #2 they're only really necessary if you want to >> squeeze performance out of your stepper motors. For our farm we never did >> that, we didn't need to. > > $200 for a 50-100mm/sec printer with low-cost steppers... > $300 for a 200-250mm/sec printer with only-slightly-higher-cost steppers... > > a 2x or greater speed improvement for only a 1.5x cost... that's an > opportunity i can't ignore > > >> >>> MGN9C rails so that the problems associated with rods go away. >>> triple lead screws (i might consider quadruple) on the printbed, NO >>> CANTILEVERING. >> >> You're a madman. You sure like to over-engineer things, don't you? :) > > no, i simply like to properly and comprehensively assess all six > degrees of freedom, which i am honestly constantly amazed that 3d > printer designers don't do, and i like to properly and i do _mean_ > properly research what the best mechanical options are. but... that's > taken me about... 2-3 years to do (!) > > >>> well, here's the thing: i actually quite like trying out things that >>> other people aren't doing. but also taking calculated risks. >> >> Sounds like you've already got your mind made up. > > i've got an _approach_ (an assessment criteria) where my mind's made > up, but nothing else. the one thing that i might add is "risk". as > in it would *really* piss me off to have a chain of improvements that, > at the end of the design process, there's something i missed which > made the whole exercise totally frickin useless. > > i had that happen once before. not a huge fan of it happening again :) > >> I'm not here to tell you >> what to do. I'm just sharing my experience and what worked for me. > > appreciated. > >> Like >> many technical problems, it's all about the approach. There are as many >> different approaches as there are engineers and business men. You know what >> is ultimately best for your situation. If it were me in your shoes though >> .. well, I'd never put myself in that position again, haha. Nope, one and >> done, thank you very much. > > :) > >> Any of my future products I make will be CNC >> machined, laser cut, or injection molded, and then outsourced. As long as >> it's a durable product, it's not really any worse than the energy expended >> to setup a printer farm. > > yehh we're not quite at the medium-volume phase yet, i don't want > 10,000 people dropping by the forum expecting "user support" on "how > to compile and patch linux kernel drivers" > > >> >> ...annd from your previous-previous email, I forgot to reply to this little >> bit: >> >>> love it. well let's get you on the list for a pre-production prototype >>> ok? >> >> Yea, hook a brother up. The pre-production is the A20 > > yes. > >> or is it the older >> one? Are there any basic breakout boards or dev boards for it to plug into? > > yeah i have a breakout board PCB done (one component - the PCMCIA > socket) and am also planning to get early devs a microdesktop as well. > >> If you need an address or anything like that just let me know. > > later. i just need numbers initially. > > l. > > _______________________________________________ > arm-netbook mailing list arm-netbook at lists.phcomp.co.uk > http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook > Send large attachments to arm-netbook at files.phcomp.co.uk > From ml.eoma68 at eml.cc Thu Jul 20 23:09:21 2017 From: ml.eoma68 at eml.cc (Vincent) Date: Fri, 21 Jul 2017 00:09:21 +0200 Subject: [Arm-netbook] early access EOMA68 to hardware for parabola ARM maintainers? In-Reply-To: References: <20170427045240.GA1882@parabola-pocket.localdomain> <20170504134015.GA12968@parabola-pocket.localdomain> <20170511063426.GA4252@parabola-pocket.localdomain> <20170621182348.GA3926@parabola-pocket.localdomain> <525f9cea-0cb5-f8ad-9bc0-0d94517810be@eml.cc> Message-ID: <7e4438bb-0c39-fa04-bae2-53e3b2305e0f@eml.cc> Yes, unfortunately I did press "reply" without noticing I was sending it to you directly instead of the list. However, I did send another email to the list as reply just a few seconds later. Yes, I'm interested in the a20 pre-production boards. You can add me with the following details: Vincent, Germany, my-email-address On 07/20/2017 07:42 PM, Luke Kenneth Casson Leighton wrote: > --- > crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68 > > > On Thu, Jul 20, 2017 at 6:14 PM, Vincent wrote: >> Hi everybody, > > you sent this to me only! > >> Please also add me to the early access list. >> >> Since the project is experiencing some delays and I would like to move >> on with my i.MX7 design, it would be really helpful to have an early >> version as reference. > > ... of the a20? edit this and add some contact details / identifying > info that i will be able to reach you by > http://rhombus-tech.net/allwinner_a10/ > > >> Thank you very much. >> >> Best regards, >> Vincent >> >> On 06/21/2017 08:46 PM, Luke Kenneth Casson Leighton wrote: >>> --- >>> crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68 >>> >>> >>> On Wed, Jun 21, 2017 at 7:23 PM, Andreas Grapentin >>> wrote: >>>> >>>> Hi Luke, >>>> >>>> On Tue, Jun 20, 2017 at 11:20:25AM +0100, Luke Kenneth Casson Leighton wrote: >>>>> when endeavouring to do an update there were two key conflicts, >>>>> related to udev, systemd and mesa-gl attempting to be upgraded. the >>>>> upgrade could therefore not proceed. >>>> >>>> could you give us access to the image you used? that would make it >>>> easier to find the issues. >>> >>> can do. one ironic thing: i cannot remember how i got eudev >>> installed! i.e. from which repo. >>> >>> 1.7gb upload... *shudder*. ok. i have space. it's going to take... >>> 10 hours @ 40k/sec. will get back to you in a a few days as i do not >>> expect it to complete first time (rsync is my best friend here). >>> >>>> However, due to some changes in arch, there is currently no clean >>>> upgrade path from 2016 images that does not require manual intervention. >>>> See here: >>>> https://www.archlinux.org/news/ca-certificates-utils-20170307-1-upgrade-requires-manual-intervention/ >>> >>> yuck. >>> >>> ok. >>> >>> _______________________________________________ >>> arm-netbook mailing list arm-netbook at lists.phcomp.co.uk >>> http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook >>> Send large attachments to arm-netbook at files.phcomp.co.uk >>> From lkcl at lkcl.net Fri Jul 21 04:38:36 2017 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Fri, 21 Jul 2017 04:38:36 +0100 Subject: [Arm-netbook] Existential 3D Printing Moments In-Reply-To: <53df99d5-6a9c-8880-3508-673d2886791b@eml.cc> References: <53df99d5-6a9c-8880-3508-673d2886791b@eml.cc> Message-ID: http://forums.reprap.org/read.php?177,767087,778191#msg-778191 --- crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68 On Thu, Jul 20, 2017 at 11:07 PM, Vincent wrote: > Any status update on the 3D printing issues? > > > On 05/19/2017 07:03 AM, Luke Kenneth Casson Leighton wrote: >> --- >> crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68 >> >> >> On Fri, May 19, 2017 at 5:08 AM, Neil Jansen wrote: >> >>>> and now you can use a 24v heater you can spend another extra $5 on an >>>> E3Dv6 volcano clone, now you can get *another* 20% increase in speed >>>> for only a 2.5% increase in budget. >>> >>> As you can see from the pics, we ran on the cheapest 12V power supplies that >>> we could find. Before that I tested 24V, it wasn't worth the cost. Again, >>> brickwall economics here. We went cheap. The 12V power supplies were >>> purchased in bulk and were maybe $14 USD each? >> >> yeh meanwell's my favourite and there's no difference between 12 and >> 24v prices. >> >>> The 3D printed mounts and >>> the little PCB's were practically free and it would turn the supply on and >>> off between jobs whereas our 24V bricks were on all the time. The ONLY >>> thing that we splurged on at the time was the E3D nozzles and that was more >>> of a crapshoot. I would have done better to cheap out on those as well, I >>> could have printed more reliably with the cheaper J-Heads. >> >> i wonder what was going on as the only time i've had problems with an >> E3Dv6 is when the fan on the heatsink wasn't running. that was bad. >> heat travelled up the tube and melted the filament *above* the hotend >> entry point. all bets were off at that point. >> >>> Don't bother minimizing extrusion if you do end up redesigning (gah!). It's >>> cheap as dirt nowadays if you're buying the generic stuff. If you want >>> rigid, well there you go. >> >> i do - and i know how it's achieved. i've had an excellent 3D visual >> manipulation ability for like... 35 years. >> >>> I have a junk box full of Melzi's, they were horrible, but it was all >>> manufacturing defects from a crappy Chinese company. The Chinese version >>> took some artistic leeway that the original (British IIRC?) designer >>> probably never intended. >> >> aiyaaa... >> >>> I've used both as I've said. Mine never stalled out. I used cheap-as-dirt >>> A4998's. Of course, I was running them < 100mm/sec and they were happy >>> there. >> >> yehyeh. >> >>>> i just... i can't bring myself to spend backers' money on stuff that >>>> i know is crud, neil. >>> >>> You're starting to sound like a German engineer now :) They're not crud if >>> you use them within the constraints that I outlined. No need to turn your >>> nose at them. What I'm trying to get at is that you've got this huge point >>> of diminishing returns, you can place yourself on either side of it. >> >> i will stop when the speed/$ improvement is parity. anything that >> gives a 1:1 ratio (or less, obviously) is not worth it and is "out"... >> *unless* an improvement can in turn have a cascade effect of allowing >> *another* improvement that *does* increase the speed/$ ratio. >> >>>> sso i've been spending some time tracking down board designs and so >>>> on. Arduino Due: https://world.taobao.com/item/539393961702.htm RMB >>>> 75 so that's around $12. >>> >>> Dang those Due's are getting cheaper, back in my day those were a pretty >>> penny. >> >> yehyeh - my favourite's the STM32F072 as it has a built-in crystal (a >> not very good one) but then the PLL can phase-lock to the USB bus from >> whatever it's connected to, compensating for crystal inaccuracies. >> price? $1.70. STM32F072-NUCLEO board? $10 on digikey. >> >> mad. absolutely mad. >> >>>> and TRAMS uses TMC2100s, where their Reference Design has full PCB >>>> and schematics available: if i'm doing 10+ i can just send that to >>>> mike and he can make them. TRAMS is *real* basic. 4 steppers, 2 >>>> beefy power MOSFETs (extruder, printbed), 2 smaller ones for fans. >>> >>> <3 TMC2100's. Our PnP was going to use TMC2130's. Great German drivers. >>> However #1 they're hard as shit to import into China, which sucked for us at >>> the time. You can get damn near anything in China but this was one of those >>> parts that just isn't really something that they use. It was, to this day, >>> the only part that I could not find on Taobao. We may have smuggled our >>> samples in from Hong Kong. >> >> dang. >> >> well.. https://world.tmall.com/item/551108503978.htm?spm=a312a.7700714.0.0.3zdhiQ >> RMB 23. about $4. >> >> so that looks prooobably like it's sorted... >> >>> #2 they're only really necessary if you want to >>> squeeze performance out of your stepper motors. For our farm we never did >>> that, we didn't need to. >> >> $200 for a 50-100mm/sec printer with low-cost steppers... >> $300 for a 200-250mm/sec printer with only-slightly-higher-cost steppers... >> >> a 2x or greater speed improvement for only a 1.5x cost... that's an >> opportunity i can't ignore >> >> >>> >>>> MGN9C rails so that the problems associated with rods go away. >>>> triple lead screws (i might consider quadruple) on the printbed, NO >>>> CANTILEVERING. >>> >>> You're a madman. You sure like to over-engineer things, don't you? :) >> >> no, i simply like to properly and comprehensively assess all six >> degrees of freedom, which i am honestly constantly amazed that 3d >> printer designers don't do, and i like to properly and i do _mean_ >> properly research what the best mechanical options are. but... that's >> taken me about... 2-3 years to do (!) >> >> >>>> well, here's the thing: i actually quite like trying out things that >>>> other people aren't doing. but also taking calculated risks. >>> >>> Sounds like you've already got your mind made up. >> >> i've got an _approach_ (an assessment criteria) where my mind's made >> up, but nothing else. the one thing that i might add is "risk". as >> in it would *really* piss me off to have a chain of improvements that, >> at the end of the design process, there's something i missed which >> made the whole exercise totally frickin useless. >> >> i had that happen once before. not a huge fan of it happening again :) >> >>> I'm not here to tell you >>> what to do. I'm just sharing my experience and what worked for me. >> >> appreciated. >> >>> Like >>> many technical problems, it's all about the approach. There are as many >>> different approaches as there are engineers and business men. You know what >>> is ultimately best for your situation. If it were me in your shoes though >>> .. well, I'd never put myself in that position again, haha. Nope, one and >>> done, thank you very much. >> >> :) >> >>> Any of my future products I make will be CNC >>> machined, laser cut, or injection molded, and then outsourced. As long as >>> it's a durable product, it's not really any worse than the energy expended >>> to setup a printer farm. >> >> yehh we're not quite at the medium-volume phase yet, i don't want >> 10,000 people dropping by the forum expecting "user support" on "how >> to compile and patch linux kernel drivers" >> >> >>> >>> ...annd from your previous-previous email, I forgot to reply to this little >>> bit: >>> >>>> love it. well let's get you on the list for a pre-production prototype >>>> ok? >>> >>> Yea, hook a brother up. The pre-production is the A20 >> >> yes. >> >>> or is it the older >>> one? Are there any basic breakout boards or dev boards for it to plug into? >> >> yeah i have a breakout board PCB done (one component - the PCMCIA >> socket) and am also planning to get early devs a microdesktop as well. >> >>> If you need an address or anything like that just let me know. >> >> later. i just need numbers initially. >> >> l. >> >> _______________________________________________ >> arm-netbook mailing list arm-netbook at lists.phcomp.co.uk >> http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook >> Send large attachments to arm-netbook at files.phcomp.co.uk >> > > _______________________________________________ > arm-netbook mailing list arm-netbook at lists.phcomp.co.uk > http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook > Send large attachments to arm-netbook at files.phcomp.co.uk From lkcl at lkcl.net Fri Jul 21 05:16:46 2017 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Fri, 21 Jul 2017 05:16:46 +0100 Subject: [Arm-netbook] Arm Netbook, Saw the update, In-Reply-To: References: <729312675.2922981.1498019518849.ref@mail.yahoo.com> <729312675.2922981.1498019518849@mail.yahoo.com> <594A892D.6040009@posteo.de> <74fd6c20-725d-5eac-1057-1a4be035ddea@aross.me> Message-ID: --- crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68 On Thu, Jul 20, 2017 at 10:35 PM, Richard Wilbur wrote: > On Thu, Jul 20, 2017 at 10:07 AM, Luke Kenneth Casson Leighton > wrote: >> On Tue, Jun 27, 2017 at 4:56 AM, Richard Wilbur >> wrote: >> >>> In the interest of solving the challenge of integrating the HDMI connector, I have a few questions: > [...] >>> 2. How many copper layers does this board have? >> >> 6 > > Okay, that didn't change since the last time you answered this. (You > just answered the more complete version of my reply sent back on 27 > Jun. I accidentally sent it before I finished writing it--and then > sent the complete version after I finished writing it. You replied in > June to the incomplete version of the message and today to the > complete version. Sorry for causing any confusion as I am still > making peace with the user interface of my smart phone E-mail > client--which I'm thankfully not using right now.) i had a pre-prepared response which i'd not sent. saw the questions, answered them, hit send... then realised i'd seen them before :) >>> 3. What is the minimum trace size? >> >> 5mil >> >>> 4. What is the minimum trace spacing? >> >> 5mil. > > Did you change pcb fabricators recently? no. > In June you said the minimum > trace size and spacing were 3.5mil. yep that's another board. > Just want to be sure I'm working > with the right numbers. 5mil. >>> 5. Is the minimum plated through hole diameter 6 mil? >> >> yes. with a 12mil surround. >> > [...] >>> The Amphenol part has 0.15mm clearance between lands for even row of pins and board edge in cutout while Molex 468753011 has 0.9mm clearance in the same spot. >> >> i'll be using the JAE DC3 because the pins are exposed, meaning that >> standard oven baking can be used. the amphenol part the pins are >> covered over, meaning that a second pass of solder reflow is needed. >> that costs money... and sometimes doesn't work anyway. > > Sounds like an improvement in manufacturability. Which part are you using? > These are all mid-mount micro-HDMI receptacles. correct. > DC3R019JA7R1500 0.65mm 0.65 this one lines up with the micro-hdmi and usb-otg connector. l. From lkcl at lkcl.net Fri Jul 21 05:18:12 2017 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Fri, 21 Jul 2017 05:18:12 +0100 Subject: [Arm-netbook] early access EOMA68 to hardware for parabola ARM maintainers? In-Reply-To: <7e4438bb-0c39-fa04-bae2-53e3b2305e0f@eml.cc> References: <20170427045240.GA1882@parabola-pocket.localdomain> <20170504134015.GA12968@parabola-pocket.localdomain> <20170511063426.GA4252@parabola-pocket.localdomain> <20170621182348.GA3926@parabola-pocket.localdomain> <525f9cea-0cb5-f8ad-9bc0-0d94517810be@eml.cc> <7e4438bb-0c39-fa04-bae2-53e3b2305e0f@eml.cc> Message-ID: On Thu, Jul 20, 2017 at 11:09 PM, Vincent wrote: > Yes, unfortunately I did press "reply" without noticing I was sending it > to you directly instead of the list. whoops :) > However, I did send another email > to the list as reply just a few seconds later. check archives. doesn't look like it made it. > Yes, I'm interested in the a20 pre-production boards. > > You can add me with the following details: > Vincent, Germany, my-email-address http://rhombus-tech.net/allwinner_a10/ is a publicly-editable wiki, can you please add yourself. thanks. l. From lkcl at lkcl.net Fri Jul 21 05:23:40 2017 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Fri, 21 Jul 2017 05:23:40 +0100 Subject: [Arm-netbook] early access EOMA68 to hardware for parabola ARM maintainers? In-Reply-To: References: <20170427045240.GA1882@parabola-pocket.localdomain> <20170504134015.GA12968@parabola-pocket.localdomain> <20170511063426.GA4252@parabola-pocket.localdomain> <20170621182348.GA3926@parabola-pocket.localdomain> <525f9cea-0cb5-f8ad-9bc0-0d94517810be@eml.cc> <7e4438bb-0c39-fa04-bae2-53e3b2305e0f@eml.cc> Message-ID: dang i do not do mornings. feel like i've been dragged through a hedge backwards and then had to stand upright in a force 10 gale. means i'm not really thinking straight for at least a couple of hours. ouaff. ok. there are 9 available 2.7.5 samples in this round, they need to be put to a use which will provide immediate benefit to the project and to the users who have pledged for the crowdfunding. vincent can you guarantee that you will aid and assist with promotion, software development (on the A20 board) or anything else which would immediately help the backers? if not then apologies it will be necessary to wait for a less urgent round (couple of months). or, i might be able to see if i still have a 2.7.4 or earlier board. l. From richard.wilbur at gmail.com Fri Jul 21 16:59:17 2017 From: richard.wilbur at gmail.com (Richard Wilbur) Date: Fri, 21 Jul 2017 09:59:17 -0600 Subject: [Arm-netbook] Arm Netbook, Saw the update, In-Reply-To: References: <729312675.2922981.1498019518849.ref@mail.yahoo.com> <729312675.2922981.1498019518849@mail.yahoo.com> <594A892D.6040009@posteo.de> <74fd6c20-725d-5eac-1057-1a4be035ddea@aross.me> <1DAA53E0-C7C8-4DED-8E62-087C2B20AFE6@gmail.com> <87485148-2167-45A7-8298-FDE1A6C66B6F@gmail.com> <936CCB09-9310-4405-A7B6-C85CA4944309@gmail.com> Message-ID: On Thu, Jul 20, 2017 at 10:20 AM, Luke Kenneth Casson Leighton wrote: > On Tue, Jul 18, 2017 at 6:16 PM, Richard Wilbur wrote: >> For our differential pairs we should only need one return-current-path >> via per signal via (and hopefully relatively adjacent to it) since we >> are using ground planes for our reference planes. It is basically >> trying to provide a relatively low-impedance path for the RF >> (radio-frequency) return current in the reference planes (since when >> we switch signal layers between top and bottom, our reference plane >> changes). > > as best i can i've put the vias as close as possible. here's some new images > > http://hands.com/~lkcl/eoma/a20_hdmi_review/ Thanks for the new pictures. I'll re-target my comments to address the newest layout. > i've also lined the bottom edge with vias, and there are a lot along > the top of the diff-pairs, separating other signals. Thanks for all the dimensions. From lkcl at lkcl.net Sat Jul 22 09:43:50 2017 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Sat, 22 Jul 2017 09:43:50 +0100 Subject: [Arm-netbook] Arm Netbook, Saw the update, In-Reply-To: References: <729312675.2922981.1498019518849.ref@mail.yahoo.com> <729312675.2922981.1498019518849@mail.yahoo.com> <594A892D.6040009@posteo.de> <74fd6c20-725d-5eac-1057-1a4be035ddea@aross.me> <1DAA53E0-C7C8-4DED-8E62-087C2B20AFE6@gmail.com> <87485148-2167-45A7-8298-FDE1A6C66B6F@gmail.com> <936CCB09-9310-4405-A7B6-C85CA4944309@gmail.com> Message-ID: On Fri, Jul 21, 2017 at 4:59 PM, Richard Wilbur wrote: >> http://hands.com/~lkcl/eoma/a20_hdmi_review/ > > Thanks for the new pictures. I'll re-target my comments to address > the newest layout. appreciated. apologies for being curt the past couple days, long days, very draining. l. From richard.wilbur at gmail.com Sun Jul 23 06:42:53 2017 From: richard.wilbur at gmail.com (Richard Wilbur) Date: Sat, 22 Jul 2017 23:42:53 -0600 Subject: [Arm-netbook] Arm Netbook, Saw the update, In-Reply-To: References: <729312675.2922981.1498019518849.ref@mail.yahoo.com> <729312675.2922981.1498019518849@mail.yahoo.com> <594A892D.6040009@posteo.de> <74fd6c20-725d-5eac-1057-1a4be035ddea@aross.me> <1DAA53E0-C7C8-4DED-8E62-087C2B20AFE6@gmail.com> <87485148-2167-45A7-8298-FDE1A6C66B6F@gmail.com> <936CCB09-9310-4405-A7B6-C85CA4944309@gmail.com> Message-ID: <5EE0CE51-8F5C-4F7E-8011-9941C641A0C0@gmail.com> On Jul 22, 2017, at 02:43, Luke Kenneth Casson Leighton wrote: > > apologies for being curt the past couple days, long > days, very draining. Thank you for spearheading this project, for keeping at it when things got more complicated (because you now understood the problem better than at the outset), and for not giving up in the face of seemingly insurmountable obstacles (those are the problems we don't yet understand well enough to solve). I especially enjoy working on hard problems because they are so rewarding to solve! Thank you for the opportunity to collaborate on a project whose goals serve to advance the cause of freedom. -- Richard From lkcl at lkcl.net Sun Jul 23 08:37:39 2017 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Sun, 23 Jul 2017 08:37:39 +0100 Subject: [Arm-netbook] Arm Netbook, Saw the update, In-Reply-To: <5EE0CE51-8F5C-4F7E-8011-9941C641A0C0@gmail.com> References: <729312675.2922981.1498019518849.ref@mail.yahoo.com> <729312675.2922981.1498019518849@mail.yahoo.com> <594A892D.6040009@posteo.de> <74fd6c20-725d-5eac-1057-1a4be035ddea@aross.me> <1DAA53E0-C7C8-4DED-8E62-087C2B20AFE6@gmail.com> <87485148-2167-45A7-8298-FDE1A6C66B6F@gmail.com> <936CCB09-9310-4405-A7B6-C85CA4944309@gmail.com> <5EE0CE51-8F5C-4F7E-8011-9941C641A0C0@gmail.com> Message-ID: --- crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68 On Sun, Jul 23, 2017 at 6:42 AM, Richard Wilbur wrote: > On Jul 22, 2017, at 02:43, Luke Kenneth Casson Leighton wrote: >> >> apologies for being curt the past couple days, long >> days, very draining. > > Thank you for spearheading this project, for keeping at it when things got more complicated (because you now understood the problem better than at the outset), and for not giving up in the face of seemingly insurmountable obstacles (those are the problems we don't yet understand well enough to solve). > > I especially enjoy working on hard problems because they are so rewarding to solve! i know, right? :) this is why i picked it - there are a lot of people doing things that can be done... > Thank you for the opportunity to collaborate on a project whose goals serve to advance the cause of freedom. any time, very glad (and relieved) for your help. l From saitdude at hotmail.com Sun Jul 23 18:53:21 2017 From: saitdude at hotmail.com (Joseph Lira) Date: Sun, 23 Jul 2017 17:53:21 +0000 Subject: [Arm-netbook] Eoma68 update Message-ID: Hello >From your last update I havent seen an update as to how the os will be delivered/installed can you give an update? Will it be an SD card? Also when do you plan to start shipping boards the crowdfunding says nov of this year is that still correct? Im asking becuase i wanted to use the eoma68 to be a little low power stream box actually can this be done? Or i wanted to replace my original pi that runs pi-hole I been very temped to buy a new raspberry pi 3 for streaming or a tiny intel nuc to do the same, but i held of because i truly want to support your project From saitdude at hotmail.com Sun Jul 23 19:03:37 2017 From: saitdude at hotmail.com (Joseph Lira) Date: Sun, 23 Jul 2017 18:03:37 +0000 Subject: [Arm-netbook] Cell phone question Message-ID: <123cbb780e694f679daa0548b5b05c16CY4PR17MB11418AABFC2D1B1F594B0435D0BA0@CY4PR17MB1141.namprd17.prod.outlook.com> Hello So I read in one of your updates about the raspberry zero phone, it sound really cool and for some time i wanted to get a smartphone but i see that they all have sort shelf lives meaning you buy the lastest samsung and it will get maybe updates for 2 years which at that point its viewed as obsolete, not to mention all the lock downs from the vendor/manufacture. I have looked at copperhead os but they still have the issue with shelf life 3 years tops, so im wondering what phone do you guys use? I just want a phone that let me listen to my music, use the gps without any ties, control the camera, some apps, that i can keep updating and patching until its truelly obsolete and all will still respecting my privacy, does such a phone exist? From lkcl at lkcl.net Sun Jul 23 22:28:06 2017 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Sun, 23 Jul 2017 22:28:06 +0100 Subject: [Arm-netbook] Eoma68 update In-Reply-To: References: Message-ID: --- crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68 On Sun, Jul 23, 2017 at 6:53 PM, Joseph Lira wrote: > Hello > > From your last update I havent seen an update as to how the os will be delivered/installed can you give an update? Will it be an SD card? Also when do you plan to start shipping boards the crowdfunding says nov of this year is that still correct? Im asking becuase i wanted to use the eoma68 to be a little low power stream box actually can this be done? Or i wanted to replace my original pi that runs pi-hole hi eric these are answered by the last updates, the answers don't change, they're not time-dependent, they're "goal" dependent, where the goals are in turn dependent on *other people* completing certain tasks. so it's flat-out impossible to answer any question that starts with "when" :) there's no NAND any more so micro-sd card it is. i asked for some help from people about how and what to ship... no response. 2,500 people and nobody made any off-the-wall suggestions: i must have asked in an unclear way. (p.s. thank you to the person who suggested places to look for low-cost micro-sd cards). i've been in 3D design head-space for almost a month, it's... "deep rabbit-hole" territory.... driving me nuts but finally the last batch of critical parts are arriving tomorrow, i'll be able to start assembly of the experimental 3D printer. near-100%-focus on that is why i've not been talking much. http://forum.openscad.org/ANN-pyopenscad-spline-surface-generator-td21838.html i reaally meant "deep down the rabbit hole" stuff... :) some fantastic shapes just completed tonight, a very exotic fan duct which takes twin 25mm fans from the *top* of the carriage holder, goes through twin ducts made from spiined "legs" that morph from squares to crescent moon shapes, which are joined back-to-back to create the outer and inner circle surrounding the extruder hot-end. a hollow arc-sphere duct is dropped on top of that and vanes added to create vortices but also act as duct support. if you've seen the mendel90 fan duct the effeect is a bit like that but without the "support" problems (due to the vanes). i wanted the air to come out evenly all the way round the extruder but i also want to try it as a vortex ("tornado"). overall it's a fascinating and beautiful shape, in a startling and exotic way. > I been very temped to buy a new raspberry pi 3 for streaming or a tiny intel nuc to do the same, but i held of because i truly want to support your project thanks eric, really appreciated. From laserhawk64 at gmail.com Sun Jul 23 22:39:38 2017 From: laserhawk64 at gmail.com (Christopher Havel) Date: Sun, 23 Jul 2017 17:39:38 -0400 Subject: [Arm-netbook] Eoma68 update In-Reply-To: References: Message-ID: I can offer one very emphatic suggestion regarding the MicroSD cards -- NOT EBAY. I've not been bit personally, but I've heard the stories. Flash media of any meaningful capacity is usually worth about half the capacity advertised, with dodgy firmware to compensate. I always buy from Newegg[dot]com but they don't really do volume pricing and they're not a wholesaler which is what you really need. Maybe one of your factory contacts over there has a pal at eg SanDisk? or maybe it might be worth a trip (back?) to Akihabara Market? (Didn't you go there at some point? I can't remember.) From maillist_arm-netbook at aross.me Sun Jul 23 23:48:03 2017 From: maillist_arm-netbook at aross.me (Alexander Ross) Date: Sun, 23 Jul 2017 23:48:03 +0100 Subject: [Arm-netbook] mSD Card Sourcing (Was Eoma68 update) In-Reply-To: References: Message-ID: <9d2fb725-9321-3635-4b76-019d2f241f40@aross.me> On 23/07/17 22:28, Luke Kenneth Casson Leighton wrote: > there's no NAND any more so micro-sd card it is. i asked for some > help from people about how and what to ship... assumed you wanted china suppliers preferably but... there is uk based moby memory. i think they will help clients acquire bulk sdcards: I have bought sdcards and cables from them, over the years. ..... oh drat! "Newbay Trading LTD (Moby Memory) has ceased trading. With great dismay, the directors have taken steps to put the company into liquidation. We ask you to direct all queries to the instructed insolvency practicioners moby at cmbukltd.co.uk" so much for that option! was wondering why they did some recent flash sales.... (those cables where very good price ;).) or today email only offer from gearbest samsung 65gb U3 $23 http://www.gearbest.com/memory-cards/pp_279099.html?wid=21&utm_source=mail_api&utm_medium=mail&utm_campaign=special.0721&eo=0fp0Cgy95kwKRHSa&email=b2t8bW9uZXlfZ2VhcmJlc3RAYXJvc3MubWV8MTY2OTc= oow £17 most tempting! while im at if you don’t know then there is: apps for testing there is flashbench for speed tests and f3 (f3read f3write) for capacity testing. http://dev.laptop.org/~martin/flashbench/ theres a wiki page for flashbench somewhere. i think f3 is in the Debian repo’s. From chadvellacott at sasktel.net Mon Jul 24 02:07:02 2017 From: chadvellacott at sasktel.net (chadvellacott at sasktel.net) Date: Sun, 23 Jul 2017 19:07:02 -0600 Subject: [Arm-netbook] Eoma68 update In-Reply-To: References: Message-ID: On 17.7.23 15:28, Luke Kenneth Casson Leighton wrote: > --- > crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68 ~~~ > there's no NAND any more so micro-sd card it is. i asked for some > help from people about how and what to ship... no response. 2,500 > people and nobody made any off-the-wall suggestions: i must have asked > in an unclear way. (p.s. thank you to the person who suggested places > to look for low-cost micro-sd cards). (for reference, I noticed that this topic was discussed somewhat with the subject-line "[Arm-netbook] Arm Netbook, Saw the update,", until 2017.6.26.) here is a quote from https://www.crowdsupply.com/eoma68/micro-desktop/updates/274-eoma68-a20-cards-arrived QUOTE > 1,000 microSD cards would need to be bought, prepared and tested. Some of the OS > images are too large to fit onto a 4 GB Card: that means 8 or 16 GB is needed. 8 > GB and 16 GB microSD cards are actually quite expensive, ~. Any estimate of how much cost it'd add, per unit, to buy big-enough microSD-cards for the bigger distributions pledged for, and prepare and test the cards? Personally, I'm definitely fine with paying more for this. How about total cost for that? Depending on the amount, one or more persons might wish to make a donation to cover, or help cover, this cost for everyone. > > So I am considering instead to simply provide download scripts for people, Upon me receiving an "EOMA68-A20" (yeah, yeah, i still need to decide which colour or such of the "Libre-Tea" card to order), it might be the only "Linux-GNU" system I have at the time. (Migrating from "Windows" is taking time, sadly.) As far as I understand, if I just get download-scripts with it, then I'd need to either (1) "install" a "Linux-GNU"-distribution onto a computer OTHER than the EOMA-68 lap-top, or (2) use a "live" version of some "Linux-GNU"-distribution, just so that I could (3) download the OS for the "EOMA68-A20"-card. And my current lap-top, seems to not like the libre distributions which I have tried on it (at least, endless "sleep" with "Trisquel"). Maybe other backers or persons planning to back this, are likely to have the same problem if merely given download-scripts? I guess that a different way to put this problem, is- how "important" is it at this stage of EOMA68, to "include" persons who are not already running Linux-GNU? (Maybe this question is going to only be true for the "A20"-cards, because maybe others like "RK3388" shall not have this problem. And the "A20"-cards might not see many production-runs. But I still plan to back at least one "A20"-card.) > and/or to offer much smaller 128 MB or 256 MB microSD cards which have an > absolute bare minimum OS on them, with scripts that will download an OS onto I have tried hard to practice safe "Internet"-use with the systems which I have and previously had (yes, moving from "Microsoft" to a libre "OS", should be a quantum leap on that "issue"). How secure would this "bare minimum OS" be, for both down-loading AND installing onto a microSD-card (supplied by me)? Ideally, I hope that (1) it does not permit any connections other than downloading one of several particular "OS"-images, via "URLs" which are white-listed as part of the "bare minimum OS", and (2) it afterwards checks the image to see whether the crypto-graphic hash (better than MD5) matches the hash which the "bare minimum OS" says is valid for that image. > their own (self-supplied) 4 GB, 8 GB or 16 GB or other sized microSD card. ~ > because the unanticipated iterations have eaten into the available budget. ~ > > ~ this is something that needs to be discussed, how people would feel about the > need to save on cost of production vs convenience and expectations. Some people, > for example, may not have a reliable Internet connection or may not be expecting > to connect their EOMA68-A20 Card to the Internet at all, for my case, I'd plan to (1) configure the "OS" to my satisfaction, and next (2) download a satisfactory browser and configure that, and ONLY LATER (3) use "Internet" otherwise. but like Luke wrote, some persons might plan to not connect at all. > or for whatever reason > may not actually have the means to download a 1.7 GB file off the Internet. QUOTE'S end (I manually added the > and the breaks. Hmm, is that going to work?) is it feasible to offer several options to backers, like- (1) scripts to download an offered distribution onto backer's self-supplied microSD-card (for persons willing and able to do the rest themselves). (2) low-capacity microSD-card with mini-OS and the same scripts as option #1 (for persons comfortable and willing and able to supply their own several-GB-microSD-card and at a command-line type "download" and "install"). (3) 4GB-card with one of the smaller distribution(s) which were offered. (4) 8GB-card with one of the bigger distributions, perhaps for an additional fee. (5) 16GB-card with one of the bigger distributions, perhaps for an additional fee. if enough persons choose cheaper options, then that may "subsidize" the cases of some backers choosing costlier options. From bluey at smallfootprint.info Mon Jul 24 04:01:04 2017 From: bluey at smallfootprint.info (Bluey) Date: Mon, 24 Jul 2017 13:01:04 +1000 Subject: [Arm-netbook] Cell phone question In-Reply-To: <123cbb780e694f679daa0548b5b05c16CY4PR17MB11418AABFC2D1B1F594B0435D0BA0@CY4PR17MB1141.namprd17.prod.outlook.com> References: <123cbb780e694f679daa0548b5b05c16CY4PR17MB11418AABFC2D1B1F594B0435D0BA0@CY4PR17MB1141.namprd17.prod.outlook.com> Message-ID: > On 24 Jul 2017, at 4:03 AM, Joseph Lira wrote: > > Hello > > So I read in one of your updates about the raspberry zero phone, it sound really cool and for some time i wanted to get a smartphone but i see that they all have sort shelf lives meaning you buy the lastest samsung and it will get maybe updates for 2 years which at that point its viewed as obsolete, not to mention all the lock downs from the vendor/manufacture. I have looked at copperhead os but they still have the issue with shelf life 3 years tops, so im wondering what phone do you guys use? I just want a phone that let me listen to my music, use the gps without any ties, control the camera, some apps, that i can keep updating and patching until its truelly obsolete and all will still respecting my privacy, does such a phone exist? > Hi Joseph, to my knowledge, your best option might be to purchase a second-hand Samsung Galaxy II, III, or Note 2 and install Replicant OS (http://www.replicant.us/) on it. Unfortunately, that won’t completely cover your requirements, as GPS won’t be available unless you use non-libre software. Also, if you want to use WiFi then you will need to use an external USB adaptor such as: https://tehnoetic.com/tehnoetic-wireless-adapter-gnu-linux-libre-tet-n150 https://www.thinkpenguin.com/gnu-linux/penguin-wireless-n-usb-adapter-gnu-linux-tpe-n150usb Protection of privacy is another completely different question. How you view the privacy offered by a phone and the system it interacts with (advertisers, nation-state actors, etc.) depends on your threat modelling as well as the information you have available to you about that system. Libre software and hardware allows for a higher degree of trustworthiness but does not specifically provide any additional security or privacy advantages over proprietary systems. Although the more eyes on something principle generally valid (greater opportunities to find flaws), the nature of security and privacy engineering is such that they are a highly specialised disciplines and just having information available in the public domain does not necessarily mean that the few specialists capable of improving libre systems to make them more secure or more private are free, able, and willing to do so. - Bluey From laserhawk64 at gmail.com Mon Jul 24 04:04:38 2017 From: laserhawk64 at gmail.com (Christopher Havel) Date: Sun, 23 Jul 2017 23:04:38 -0400 Subject: [Arm-netbook] Cell phone question In-Reply-To: References: <123cbb780e694f679daa0548b5b05c16CY4PR17MB11418AABFC2D1B1F594B0435D0BA0@CY4PR17MB1141.namprd17.prod.outlook.com> Message-ID: I should note, having had a Galaxy SIII up until quite recently, that Samsung no longer makes batteries for it, and the counterfeits are truly awful -- as are "remanufactured" batteries. I now have an S5 with no complaints -- but persistent battery issues were one of two big reasons I got rid of the SIII I had. (The other reason was that the microphone had begun to give me issues.) From ronwirring at Safe-mail.net Sun Jul 23 19:28:50 2017 From: ronwirring at Safe-mail.net (ronwirring at Safe-mail.net) Date: Sun, 23 Jul 2017 14:28:50 -0400 Subject: [Arm-netbook] Cell phone question Message-ID: -------- Original Message -------- From: Joseph Lira Apparently from: arm-netbook-bounces at lists.phcomp.co.uk To: "arm-netbook at list.phcomp.co.uk" Subject: [Arm-netbook] Cell phone question Date: Sun, 23 Jul 2017 18:03:37 +0000 > Hello > >does such a phone exist? I think a common phone will get lineageos compatible. By default lineageos comes with no google applications. If lineageos apart from that gives you enough privacy and security, I also would want to know? From lkcl at lkcl.net Mon Jul 24 06:38:40 2017 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Mon, 24 Jul 2017 06:38:40 +0100 Subject: [Arm-netbook] Eoma68 update In-Reply-To: References: Message-ID: --- crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68 On Mon, Jul 24, 2017 at 2:07 AM, wrote: > Any estimate of how much cost it'd add, per unit, to buy big-enough > microSD-cards for the bigger distributions pledged for, and prepare and test > the cards? i'd need to do it. times a thousand. which is why i'm not hugely keen on the idea. > Personally, I'm definitely fine with paying more for this. > How about total cost for that? Depending on the amount, one or more > persons might wish to make a donation to cover, or help cover, this cost for > everyone. that would be great > computer OTHER than the EOMA-68 lap-top, or (2) use a "live" version of some > "Linux-GNU"-distribution, just so that I could (3) download the OS for the > "EOMA68-A20"-card. one option is to get a very small card (512mb, 1gb) and put a "loader" OS on that. if they're $0.25 or $0.50 in qty 1000 then that's worth considering. instead of $4 for an 8GB card. say. > And my current lap-top, seems to not like the libre > distributions which I have tried on it (at least, endless "sleep" with > "Trisquel"). Maybe other backers or persons planning to back this, are > likely to have the same problem if merely given download-scripts? exactly. > I guess that a different way to put this problem, is- > how "important" is it at this stage of EOMA68, to "include" persons who > are not already running Linux-GNU? honestly as this is early-phase anyone should expect to have things that they'll need to deal with... *but* for those people not able to cope i expect *you guys* (those with technical knowledge) to help them out. > (Maybe this question is going to only be > true for the "A20"-cards, because maybe others like "RK3388" shall not have > this problem. And the "A20"-cards might not see many production-runs. But > I still plan to back at least one "A20"-card.) yay. thank you. >> and/or to offer much smaller 128 MB or 256 MB microSD cards which have an >> absolute bare minimum OS on them, with scripts that will download an OS >> onto > > I have tried hard to practice safe "Internet"-use with the systems which > I have and previously had (yes, moving from "Microsoft" to a libre "OS", > should be a quantum leap on that "issue"). :) > How secure would this "bare minimum OS" be, for both down-loading AND > installing onto a microSD-card (supplied by me)? if it's designed properly, none. > Ideally, I hope that (1) it does not permit any connections other than > downloading one of several particular "OS"-images, via "URLs" which are > white-listed as part of the "bare minimum OS", not whitelisted: hard-coded. > and (2) it afterwards checks > the image to see whether the crypto-graphic hash (better than MD5) matches > the hash which the "bare minimum OS" says is valid for that image. bittorrent would automatically do that. command-line version is btdownloadheadless. very tired. stopping here. sorry. please do carry on the conversation. i'll pick it up later. l . From vkontogpls at gmail.com Mon Jul 24 14:26:27 2017 From: vkontogpls at gmail.com (Bill Kontos) Date: Mon, 24 Jul 2017 16:26:27 +0300 Subject: [Arm-netbook] Cell phone question In-Reply-To: <123cbb780e694f679daa0548b5b05c16CY4PR17MB11418AABFC2D1B1F594B0435D0BA0@CY4PR17MB1141.namprd17.prod.outlook.com> References: <123cbb780e694f679daa0548b5b05c16CY4PR17MB11418AABFC2D1B1F594B0435D0BA0@CY4PR17MB1141.namprd17.prod.outlook.com> Message-ID: On Sun, Jul 23, 2017 at 9:03 PM, Joseph Lira wrote: > i can keep updating and patching until its truelly obsolete and all will still >respecting my privacy, does such a phone exist? > No. Mobile networks require closed-source firmware by law and gps requires proprietary software too. Personally as long as the phone does not use the camera or the microphone without my permission it's fine by me, since the technology underlying it means the network company will be able to track you anyway when you make calls. I'm using an LG G3 which from a durability point of view has been stellar. Been using it for exactly what you described more or less, dropped it from the first floor with no protective case multiple times, still works flawless. Additionally, and unfortunately this is not granted these days it has removable battery. With a new battery it can easily last an entire day, after 2.5 years it still lasts a day if you don't stress it much. With 4g open and web browsing it will die after ~4-5h. Listening to spotify via 4g with the screen turned off still lasts 8+h. Charging is relatively fast. A bit of overheating issues if you stress it though. I haven't done it myself but there are ways to flash it, so you are not stuck with the default lg skin. Just don't accept the legal notice at boot so the lg apps won't launch and hog your battery. From richard.wilbur at gmail.com Mon Jul 24 15:36:49 2017 From: richard.wilbur at gmail.com (Richard Wilbur) Date: Mon, 24 Jul 2017 08:36:49 -0600 Subject: [Arm-netbook] Arm Netbook, Saw the update, In-Reply-To: References: <729312675.2922981.1498019518849.ref@mail.yahoo.com> <729312675.2922981.1498019518849@mail.yahoo.com> <594A892D.6040009@posteo.de> <74fd6c20-725d-5eac-1057-1a4be035ddea@aross.me> <1DAA53E0-C7C8-4DED-8E62-087C2B20AFE6@gmail.com> <87485148-2167-45A7-8298-FDE1A6C66B6F@gmail.com> <936CCB09-9310-4405-A7B6-C85CA4944309@gmail.com> Message-ID: On Jul 22, 2017, at 02:43, Luke Kenneth Casson Leighton wrote: > > On Fri, Jul 21, 2017 at 4:59 PM, Richard Wilbur > wrote: >> >> >> Thanks for the new pictures. I'll re-target my comments to address >> the newest layout. > > appreciated. What form would you prefer my recommendations take to make them most useful? text, Open Document Text (Open/Libre Office), PDF I have been writing them in Open Document Text format (Open/Libre Office). The references are taken from freely available websites, several of them documents in PDF (with helpful diagrams). From calmstorm at posteo.de Mon Jul 24 16:12:44 2017 From: calmstorm at posteo.de (zap) Date: Mon, 24 Jul 2017 11:12:44 -0400 Subject: [Arm-netbook] Eoma68 update In-Reply-To: References: Message-ID: <069007de-dae3-76df-537d-dea9e81c2551@posteo.de> >> I been very temped to buy a new raspberry pi 3 for streaming or a tiny intel nuc to do the same, but i held of because i truly want to support your project > thanks eric, really appreciated. > > ___ I may wait to see what people say about your laptop once they have it, before buying, I hope you understand, I still want to support your cause, I just want to know the difficulty of putting the pieces together and also, the stability/sturdiness. I will in 2018. I wish you the best Luke. May you be blessed for your ethics. :) From isacdaavid at isacdaavid.info Mon Jul 24 17:27:42 2017 From: isacdaavid at isacdaavid.info (Isaac David) Date: Mon, 24 Jul 2017 11:27:42 -0500 Subject: [Arm-netbook] Cell phone question In-Reply-To: References: <123cbb780e694f679daa0548b5b05c16CY4PR17MB11418AABFC2D1B1F594B0435D0BA0@CY4PR17MB1141.namprd17.prod.outlook.com> Message-ID: <1500913662.11073.0@plebeian.isacdaavid.info> Bill Kontos : > the technology underlying it means the network > company will be able to track you anyway when you make calls. afaik not only then, but whenever network radio is turned on and transmitting; which for existing mobile protocols sadly means all the time. -- Isaac David GPG: 38D33EF29A7691134357648733466E12EC7BA943 Tox: 0C730E0156E96E6193A1445D413557FF5F277BA969A4EA20AC9352889D3B390E77651E816F0C From vkontogpls at gmail.com Mon Jul 24 20:49:02 2017 From: vkontogpls at gmail.com (Bill Kontos) Date: Mon, 24 Jul 2017 22:49:02 +0300 Subject: [Arm-netbook] Cell phone question In-Reply-To: <1500913662.11073.0@plebeian.isacdaavid.info> References: <123cbb780e694f679daa0548b5b05c16CY4PR17MB11418AABFC2D1B1F594B0435D0BA0@CY4PR17MB1141.namprd17.prod.outlook.com> <1500913662.11073.0@plebeian.isacdaavid.info> Message-ID: On Mon, Jul 24, 2017 at 7:27 PM, Isaac David wrote: > afaik not only then, but whenever network radio is turned > on and transmitting; which for existing mobile protocols > sadly means all the time. Yep. Essentially if you are going to use a phone you will have to do that tradeoff. From lkcl at lkcl.net Tue Jul 25 09:18:52 2017 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Tue, 25 Jul 2017 09:18:52 +0100 Subject: [Arm-netbook] Arm Netbook, Saw the update, In-Reply-To: References: <729312675.2922981.1498019518849.ref@mail.yahoo.com> <729312675.2922981.1498019518849@mail.yahoo.com> <594A892D.6040009@posteo.de> <74fd6c20-725d-5eac-1057-1a4be035ddea@aross.me> <1DAA53E0-C7C8-4DED-8E62-087C2B20AFE6@gmail.com> <87485148-2167-45A7-8298-FDE1A6C66B6F@gmail.com> <936CCB09-9310-4405-A7B6-C85CA4944309@gmail.com> Message-ID: On Mon, Jul 24, 2017 at 3:36 PM, Richard Wilbur wrote: > What form would you prefer my recommendations take to make them most useful? > text, text is great ( to list here ) with online links to PDFs if there are any. thanks richard. l. From lkcl at lkcl.net Tue Jul 25 10:17:35 2017 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Tue, 25 Jul 2017 10:17:35 +0100 Subject: [Arm-netbook] Eoma68 update In-Reply-To: <069007de-dae3-76df-537d-dea9e81c2551@posteo.de> References: <069007de-dae3-76df-537d-dea9e81c2551@posteo.de> Message-ID: --- crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68 On Mon, Jul 24, 2017 at 4:12 PM, zap wrote: > >>> I been very temped to buy a new raspberry pi 3 for streaming or a tiny intel nuc to do the same, but i held of because i truly want to support your project >> thanks eric, really appreciated. >> >> ___ > > I may wait to see what people say about your laptop once they have it, > before buying, I hope you understand, I still want to support your > cause, I just want to know the difficulty of putting the pieces together > and also, the stability/sturdiness. i'll be using the first 10 to create videos and documentation. the prototype i have here is pretty sturdy, not least because it's very light (1.1kg), but also because i went to a lot of trouble to design shapes with internal structural support. one piece 160mm long, it actually got to be dangerous to try to bend / snap it, i was applying so much force i was concerned that shards might fly off. applying a *lot* of pressure - enough to make marks on my fingers - only bent it about 2-3mm out of shape. > I will in 2018. I wish you the best Luke. May you be blessed for your > ethics. thx zap :) From vincent.legoll at gmail.com Tue Jul 25 12:12:02 2017 From: vincent.legoll at gmail.com (Vincent Legoll) Date: Tue, 25 Jul 2017 13:12:02 +0200 Subject: [Arm-netbook] Eoma68 update In-Reply-To: References: <069007de-dae3-76df-537d-dea9e81c2551@posteo.de> Message-ID: On Tue, Jul 25, 2017 at 11:17 AM, Luke Kenneth Casson Leighton wrote: > it actually got to be dangerous to try to bend / snap it, i was applying > so much force i was concerned that shards might fly off. applying a > *lot* of pressure - enough to make marks on my fingers - only bent it > about 2-3mm out of shape. Did you also try some fall tests, because that's more likely to happen in real life. Especially as the case design is not monilithic (if I remember correctly), the shock forces will get applied to the weakest parts. Hey, it's OK if you actually didn't ;-) You could test with pieces that had 3d printing problems, so as not to destroy any good ones. And then label the project as being Eco-consciously tested ! -- Vincent Legoll From lkcl at lkcl.net Tue Jul 25 13:29:34 2017 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Tue, 25 Jul 2017 13:29:34 +0100 Subject: [Arm-netbook] Eoma68 update In-Reply-To: References: <069007de-dae3-76df-537d-dea9e81c2551@posteo.de> Message-ID: --- crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68 On Tue, Jul 25, 2017 at 12:12 PM, Vincent Legoll wrote: > On Tue, Jul 25, 2017 at 11:17 AM, Luke Kenneth Casson Leighton > wrote: >> it actually got to be dangerous to try to bend / snap it, i was applying >> so much force i was concerned that shards might fly off. applying a >> *lot* of pressure - enough to make marks on my fingers - only bent it >> about 2-3mm out of shape. > > Did you also try some fall tests, because that's more likely to happen > in real life. on the one prototype being used for the crowd-funding?? naah! > Especially as the case design is not monilithic (if I remember > correctly), the shock forces will get applied to the weakest parts. > > Hey, it's OK if you actually didn't ;-) well... honestly... if people do drop it, they're on their own, and get to keep all the pieces. buuuut... that's no different from any mass-volume product... the difference being: you get to be able to 3D-print your *own* replacement parts, and repair it yourself. as opposed to "throw the whole thing out" > You could test with pieces that had 3d printing problems, so as not to > destroy any good ones. > > And then label the project as being Eco-consciously tested ! mmm... yyeahh not today :) From lkcl at lkcl.net Tue Jul 25 15:32:57 2017 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Tue, 25 Jul 2017 15:32:57 +0100 Subject: [Arm-netbook] screwed up the Riki200 plotter design Message-ID: http://forums.reprap.org/read.php?177,767087,779977#msg-779977 ok so i screwed up. i didn't do a full force-analysis of the plotter design concept, and it was only when i tried turning each of the motors that i realised that with a double pulley system the force on one is double that of the other. with the two pulleys being separated by 320mm that means that just turning the motor *will* cause the X/Y-ends to "shear". this is... bad :) fortunately someone posted a few days ago that they have a concept which they've named "Edge-XY" - similar to CoreXY except the single X-Gantry (the horizontal bar of an "H") is replaced with *dual* X/Y (cross) rods. now, what's particularly fascinating about Edge-XY is that an important and previously under-appreciated design flaw of CoreXY is completely sorted! also very fortunately, the EdgeXY concept is very very similar to what i was trying for the Riki200 plotter concept... so i can convert over to EdgeXY with very little extra work. about 16 hours of re-printing parts but about... a week's worth of CAD design effort. which isn't too bad for correcting a major design cock-up :) i will try to work in the double-pulley system into the redesign: due to the fact that the belts are fixed onto the moving X/Y-ends of the EdgeXY it would be a 3x force multiplier not a 4x one, but also the forces (the pulleys) would be *on the same blocks* (separated by about 20mm) and would be force-balanced. made that mistake once already.... not doing it again :) l. --- crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68 From benson.mitchell+arm-netbook at gmail.com Tue Jul 25 18:20:09 2017 From: benson.mitchell+arm-netbook at gmail.com (Benson Mitchell) Date: Tue, 25 Jul 2017 13:20:09 -0400 Subject: [Arm-netbook] screwed up the Riki200 plotter design In-Reply-To: References: Message-ID: On Tue, Jul 25, 2017 at 10:32 AM, Luke Kenneth Casson Leighton < lkcl at lkcl.net> wrote: > fortunately someone posted a few days ago that they have a concept > which they've named "Edge-XY" Actually, they called it EtchXY -- probably in reference to the etch-a-sketch toy. similar to CoreXY except the single > X-Gantry (the horizontal bar of an "H") is replaced with *dual* X/Y > (cross) rods. now, what's particularly fascinating about Edge-XY is > that an important and previously under-appreciated design flaw of > CoreXY is completely sorted! > I'm not convinced it's so much better -- think you've overlooked something in your analysis. (I'm going to register and post a reply in that reprap forum thread.) But even if I'm wrong about the rigidity... why bother? The thing that made CoreXY special is the combination of non-moving motors with a simple (thus cheap and lightweight) gantry. Once you've committed to the more complex (thus expensive/heavy) dual-gantry setup, as seen in both your Riki200 design and Etch-XY, I don't see any benefit to be had from long timing belts wrapping around a half-dozen pulleys; there's a much simpler way to drive each axis independently with non-moving motors. For the X-axis, you put two shafts parallel to the Y-axis, at the left and right sides. They each have two timing belt pulleys (at the top/bottom ends), supporting one loop of timing belt to drive each green block. One shaft is coupled to the motor, the other is an idler. For the Y-axis, exactly the same thing, rotated 90 degrees. Or perhaps you've considered this and aren't doing it because of construction details. Etch-XY has 8 short shafts (idlers on the fixed chassis -- not counting the motors or idlers on the moving gantries), all with parallel axes (Z-axis), while the simple solution has 4 long shafts in pairs (X-axis and Y-axis) -- it seems simpler and easier to me, but then I'm a machinist by trade, so I'm not used to thinking in the constraints of 3d-printed and/or laser-cut construction... Benson Mitchell From lkcl at lkcl.net Tue Jul 25 19:28:11 2017 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Tue, 25 Jul 2017 19:28:11 +0100 Subject: [Arm-netbook] screwed up the Riki200 plotter design In-Reply-To: References: Message-ID: On Tue, Jul 25, 2017 at 6:20 PM, Benson Mitchell wrote: > I'm not convinced it's so much better -- think you've overlooked something > in your analysis. (I'm going to register and post a reply in that reprap > forum thread.) that would be superb > But even if I'm wrong about the rigidity... why bother? pulley system - doubling. mass is also equal for x and y. corexy has the weight of the x-gantry. moving in Y has more inertia that X. speed for this design i intend to try 500mm/sec and greater. that's TEN times what most people would ever conceive of running a 3D printer at. the ultimaker-2 is only rated for a maximum of 250-300mm/sec. > The thing that made > CoreXY special is the combination of non-moving motors with a simple (thus > cheap and lightweight) gantry. Once you've committed to the more complex > (thus expensive/heavy) dual-gantry setup, as seen in both your Riki200 > design and Etch-XY, I don't see any benefit to be had from long timing > belts wrapping around a half-dozen pulleys; there's a much simpler way to > drive each axis independently with non-moving motors. not "and guarantee rigidity and add a pulley doubling system and also guarantee equal mass distribution" as well. > For the X-axis, you put two shafts parallel to the Y-axis, at the left and > right sides. They each have two timing belt pulleys (at the top/bottom > ends), supporting one loop of timing belt to drive each green block. One > shaft is coupled to the motor, the other is an idler. i know the sort of thing: i've seen it in use: it's used in the ultimaker-2 and also in an open design pick-and-place amachine. the amount of force on the belt is considerable. with the EtchXY design the force on the belt is halved due to the pulley system. > For the Y-axis, exactly the same thing, rotated 90 degrees. by the time it's all assembled, the 2 belts, 4 pulleys, 4 shafts, then 4 sets of rails/rods, it really does add up very quick in terms of ccomplexity. then you have to CAD design it, make sure that everything fits, that's a month's work right there... > > Or perhaps you've considered this and aren't doing it because of > construction details. Etch-XY has 8 short shafts (idlers on the fixed > chassis M5 16mm bolts, 2 M5x18mm washers. $0.02 each. 625 bearings. saves a lot. > -- not counting the motors or idlers on the moving gantries), all > with parallel axes (Z-axis), while the simple solution has 4 long shafts in > pairs (X-axis and Y-axis) plus 4 pulleys and 4 sets of rods/rails > -- it seems simpler and easier to me, but then > I'm a machinist by trade, so I'm not used to thinking in the constraints of > 3d-printed and/or laser-cut construction... pick-and-place, cnc, etc it's all the same principle. except CNC needs huge force and precision, whereas 3D filament deposition needs speed and precision. CNC typically uses backlash-free screw-drives, low pitched, with planetary gearboxes to get the forcee and accuracy. i'm looking for a trade-off which maximises mm/sec/$ so a weird combination of ways to increase speed without compromising rigidity, using components that are considered "budget" but are not "cheap and nasty", they're just "cheap" :) so adding pulleys to reduce the force on a standard "cheap" 6mm GT2 timing belt, that's important, because now you can try going twice as fast but still use... cheap 6mm GT2 timing belt. otherwise you would need to use GT3 and 8 to 10mm, that's no longer "cheap". make sense? l. From benson.mitchell+arm-netbook at gmail.com Tue Jul 25 21:27:45 2017 From: benson.mitchell+arm-netbook at gmail.com (Benson Mitchell) Date: Tue, 25 Jul 2017 16:27:45 -0400 Subject: [Arm-netbook] screwed up the Riki200 plotter design In-Reply-To: References: Message-ID: On Tue, Jul 25, 2017 at 2:28 PM, Luke Kenneth Casson Leighton wrote: > > But even if I'm wrong about the rigidity... why bother? > > pulley system - doubling. > Okay, but you aren't getting that with EtchXY (see below). And you can add it to my proposal just as easy. > > mass is also equal for x and y. > Which is also true for my proposal. > corexy has the weight of the x-gantry. moving in Y has more inertia that > X. > Yeah, I'm not suggesting CoreXY -- I do get why that's quite unsuitable for what you're doing. > The thing that made > > CoreXY special is the combination of non-moving motors with a simple > (thus > > cheap and lightweight) gantry. Once you've committed to the more complex > > (thus expensive/heavy) dual-gantry setup, as seen in both your Riki200 > > design and Etch-XY, I don't see any benefit to be had from long timing > > belts wrapping around a half-dozen pulleys; there's a much simpler way to > > drive each axis independently with non-moving motors. > > not "and guarantee rigidity and add a pulley doubling system and also > guarantee equal mass distribution" as well. > The mass distribution seems fine; motors, shafts, and pulleys are all non-moving. The moving parts are the gantries and extruder platform, all just the same as you have them. Likewise rigidity seems pretty solid, with one belt per block. As for pulley doubling, it's simple to add. I just didn't go into details because I'd assumed you were willing to give it up, since you're talking about using EtchXY which lacks it. Instead of anchoring the ends of the loop directly to the moving blocks, just put pulleys there, and bring the end back to the fixed chassis to anchor it. Going back to your original diagram for the Riki200, it's just like the bottom 20% of that diagram, but the belt wraps 180 instead of 90 degrees around those chassis-mounted idlers. (And of course, it's rotated 90 degrees out of the page.) If that was unclear, say so -- I'll come up with a sketch. > For the X-axis, you put two shafts parallel to the Y-axis, at the left and > > right sides. They each have two timing belt pulleys (at the top/bottom > > ends), supporting one loop of timing belt to drive each green block. One > > shaft is coupled to the motor, the other is an idler. > > i know the sort of thing: i've seen it in use: it's used in the > ultimaker-2 and also in an open design pick-and-place amachine. > Ah, good. > the amount of force on the belt is considerable. with the EtchXY design > the force on the belt is halved due to the pulley system. > But the force is only halved for the Y-axis in EtchXY. Look closely -- the X-axis is anchored directly to the green blocks, so the accelerating force is just the sum of red and blue belt tension. (The distribution of force between the red/blue belts (50/50 at center, progressively worse towards limits of travel) does help vs some other designs, but that benefit applies to the parallel-shafts system, too.) And given you seem to be building a square printer, you should be accelerating pretty much the same amount of mass around in X and Y -- so you have to design (choose belts and/or limit acceleration) based on the axis without mechanical advantage. (It would be different if your build volume is way out of square, such that the yellow-block gantry masses twice the green-block gantry -- then you have mechanical advantage right where you need it, so the same acceleration in X or in Y give similar cable tension -- but AFAIK you're not doing that sort of build.) by the time it's all assembled, the 2 belts, 4 pulleys, 4 shafts, > then 4 sets of rails/rods, it really does add up very quick in terms > of ccomplexity. then you have to CAD design it, make sure that > everything fits, that's a month's work right there... > Yeah, but you've got all the rails and rods, exactly the same -- it's really just 4 short belts vs. 2 long belts, 4 long shafts vs. many short shafts, and especially the pulleys. I think as a result of whatever misunderstanding has you thinking I'm adding extra rails, you're also overestimating the design work involved to redo it -- it should only be a little more radical than redesigning for EtchXY. > Etch-XY has 8 short shafts (idlers on the fixed chassis > > M5 16mm bolts, 2 M5x18mm washers. $0.02 each. 625 bearings. saves a > lot. > Wait, 6 of those 8 are tooth-side-in -- and you're still wrapping them around bearings instead of timing belt pulleys? I wouldn't have thought you could get away with that! But if so, that does make a bunch of the savings/simplification I thought I was getting illusory. > > -- not counting the motors or idlers on the moving gantries), all > > with parallel axes (Z-axis), while the simple solution has 4 long shafts > in > > pairs (X-axis and Y-axis) > > plus 4 pulleys Actually 8, really (2 per shaft, 2 shafts per axis, 2 axes), whereas I thought you had 10 pulleys all told (two on the yellow blocks, 6 fixed, and 2 on the motors), based on where the belt wraps tooth-side in, whereas really you have... just the two on the motors? Although, now that I think... hey, if you can wrap timing belts around bearings, so can I! Keep the drive side (per axis) one long shaft + 2 pulleys on the drive side, but for the idler side use M5 screws/625 bearings just like you're talking about -- so it is just 4 pulleys after all. (Oh, and a couple flexible couplings, or yet more timing belt pulleys, to couple the motors to the drive shafts.) > and 4 sets of rods/rails > Again, you've already got all the rods and rails -- that stuff would really be _exactly_ like you have it. You're "only" redesigning the 4 green/yellow blocks to put the idler axes horizontal rather than vertical (pretty simple, I think), and completely redoing the motor/pulley mount brackets at the 4 corners of the frame (not really simple) -- point is, all the linear rails and rods stay in exactly the same places they are. I don't think the shafts should be a big deal (Sure, not as cheap as M5 screws, but still can be pretty cheap... nothing fancy, just cold-drawn rods), but I see where the pulleys add up. The one thing that might make it worthwhile is that it dodges the skew problem completely -- each block is completely controlled by one belt. Perhaps the best answer is to modify EtchXY to give you pulley reduction on both axes? That change is pretty straightforward. But I don't see what to do about the skew problem... so adding pulleys to reduce the force on a standard "cheap" 6mm GT2 > timing belt, that's important, because now you can try going twice as > fast but still use... cheap 6mm GT2 timing belt. otherwise you would > need to use GT3 and 8 to 10mm, that's no longer "cheap". > > make sense? Yeah, absolutely. I'm sure there are reasons not to gang two or three 6mm GT2 belts on an extended pulley to get more strength? Benson Mitchell From lkcl at lkcl.net Wed Jul 26 07:39:26 2017 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Wed, 26 Jul 2017 07:39:26 +0100 Subject: [Arm-netbook] screwed up the Riki200 plotter design In-Reply-To: References: Message-ID: --- crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68 On Tue, Jul 25, 2017 at 9:27 PM, Benson Mitchell wrote: > On Tue, Jul 25, 2017 at 2:28 PM, Luke Kenneth Casson Leighton > wrote: > >> > But even if I'm wrong about the rigidity... why bother? >> >> pulley system - doubling. >> > Okay, but you aren't getting that with EtchXY (see below). And you can add > it to my proposal just as easy. i keep getting *really* confused by the pulleys in the EtchXY :) example: right motor turns one revolution, left-side-belt from motor gear leading to yellow block is doubled-back... therefore it's a pulley arrangement. green block moves 1/2 speed. >> >> mass is also equal for x and y. >> > Which is also true for my proposal. indeed. >> The thing that made >> > CoreXY special is the combination of non-moving motors with a simple >> (thus >> > cheap and lightweight) gantry. Once you've committed to the more complex >> > (thus expensive/heavy) dual-gantry setup, as seen in both your Riki200 >> > design and Etch-XY, I don't see any benefit to be had from long timing >> > belts wrapping around a half-dozen pulleys; there's a much simpler way to >> > drive each axis independently with non-moving motors. >> >> not "and guarantee rigidity and add a pulley doubling system and also >> guarantee equal mass distribution" as well. >> > The mass distribution seems fine; motors, shafts, and pulleys are all > non-moving. The moving parts are the gantries and extruder platform, all > just the same as you have them. Likewise rigidity seems pretty solid, with > one belt per block. > > As for pulley doubling, it's simple to add. I just didn't go into details > because I'd assumed you were willing to give it up, since you're talking > about using EtchXY which lacks it. see above.... > Instead of anchoring the ends of the loop directly to the moving blocks, > just put pulleys there, and bring the end back to the fixed chassis to > anchor it. Going back to your original diagram for the Riki200, it's just > like the bottom 20% of that diagram, but the belt wraps 180 instead of 90 > degrees around those chassis-mounted idlers. (And of course, it's rotated > 90 degrees out of the page.) > > If that was unclear, say so -- I'll come up with a sketch. yes please - can we discuss it on the reprap forum? it's easier as they have the means to upload (and inline) images. upload the file then hit "create link in message" button, hit "preview" to check it... >> For the X-axis, you put two shafts parallel to the Y-axis, at the left and >> > right sides. They each have two timing belt pulleys (at the top/bottom >> > ends), supporting one loop of timing belt to drive each green block. One >> > shaft is coupled to the motor, the other is an idler. >> >> i know the sort of thing: i've seen it in use: it's used in the >> ultimaker-2 and also in an open design pick-and-place amachine. >> > Ah, good. > >> the amount of force on the belt is considerable. with the EtchXY design >> the force on the belt is halved due to the pulley system. >> > But the force is only halved for the Y-axis in EtchXY. Look closely -- the > X-axis is anchored directly to the green blocks, so the accelerating force > is just the sum of red and blue belt tension. nom, nom, nom, nom.... ah ha! yes! ok so now i know why i was so totally confused: if i looked at one axis i would see a double-pulley system, then looking at the other it wouldn't have one. ah ha! yes - i know how to fix that: you'd need to put idlers on the green blocks, and have the belt-mount points fixed in each corner (not to the green blocks) > by the time it's all assembled, the 2 belts, 4 pulleys, 4 shafts, >> then 4 sets of rails/rods, it really does add up very quick in terms >> of ccomplexity. then you have to CAD design it, make sure that >> everything fits, that's a month's work right there... >> > > Yeah, but you've got all the rails and rods, exactly the same -- it's > really just 4 short belts vs. 2 long belts, 4 long shafts vs. many short > shafts, and especially the pulleys. I think as a result of whatever > misunderstanding has you thinking I'm adding extra rails, you're also > overestimating the design work involved to redo it -- it should only be a > little more radical than redesigning for EtchXY. i've come up overnight with an alternative, which i'll post on the forum. >> Etch-XY has 8 short shafts (idlers on the fixed chassis >> >> M5 16mm bolts, 2 M5x18mm washers. $0.02 each. 625 bearings. saves a >> lot. >> > > Wait, 6 of those 8 are tooth-side-in -- and you're still wrapping them > around bearings instead of timing belt pulleys? yyyup :) > I wouldn't have thought you > could get away with that! you can ... just about :) surprisingly. it starts to get pretty noisy at high speed though. ... can we move this entirely to the forum? [snipped rest] > Yeah, absolutely. I'm sure there are reasons not to gang two or three 6mm > GT2 belts on an extended pulley to get more strength? cost and space. seen it done - but on an all-aluminium design (CNC machined) where the parts were strong enough to withstand the extra height (double stack of pulleys). l. From benson.mitchell+arm-netbook at gmail.com Wed Jul 26 11:14:16 2017 From: benson.mitchell+arm-netbook at gmail.com (Benson Mitchell) Date: Wed, 26 Jul 2017 06:14:16 -0400 Subject: [Arm-netbook] screwed up the Riki200 plotter design In-Reply-To: References: Message-ID: On Wed, Jul 26, 2017 at 2:39 AM, Luke Kenneth Casson Leighton wrote: > ... can we move this entirely to the forum? > You bet. It may be a couple hours before I have a chance to sketch things up, but I'll see ya there. Benson Mitchell From lkcl at lkcl.net Wed Jul 26 13:20:01 2017 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Wed, 26 Jul 2017 13:20:01 +0100 Subject: [Arm-netbook] screwed up the Riki200 plotter design In-Reply-To: References: Message-ID: --- crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68 On Wed, Jul 26, 2017 at 11:14 AM, Benson Mitchell wrote: > On Wed, Jul 26, 2017 at 2:39 AM, Luke Kenneth Casson Leighton > wrote: > >> ... can we move this entirely to the forum? >> > You bet. It may be a couple hours before I have a chance to sketch things > up, but I'll see ya there. ok :) i do lots of free-hand drawings with the gimp. honestly if it was easier to sketch it and photograph it i would do that... but i can't be arsed to keep swapping out the memory card.... and put my daughter's colouring pens back in their box :) l. From rekado at elephly.net Thu Jul 27 09:45:01 2017 From: rekado at elephly.net (Ricardo Wurmus) Date: Thu, 27 Jul 2017 10:45:01 +0200 Subject: [Arm-netbook] CNC milling of plastic lumber instead of 3D printing? Message-ID: <87y3ra5kvm.fsf@elephly.net> Heya, this idea is too late for the current batches of laptops, but I was wondering if it wouldn’t be easier and faster to mill the laptop plastic parts out of recycled blocks of plastic (“plastic lumber”) with a CNC mill. The advantages are as follows: * suitable plastic lumber can be made from a wider range of plastics than 3d printer filament * plastic lumber can be made from readily available plastic waste. HDPE from plastic bags make for cheap sturdy blocks of material. * a CNC mill cares much less about the melting point of the work piece during operation than a 3d printer * there are fewer concerns about material shrinkage at construction time, because the work piece isn’t partially liquid at any time of the CNC operations. * processing the work piece is faster because it doesn’t require as much motion as printing sturdy zig zag patterns. * even rather unsophisticated CNC mills can be used as the work piece is rather soft compared to the usual CNC mill work pieces such as aluminium. The most obvious disadvantages are: * there seem to be much fewer vendors of plastic lumber than there are vendors of high quality 3d printer filament * this approach isn’t quite as common, so it may be harder to find good advice from experienced people. What do you think? (I’m currently in the process of setting up a plastic recycling work space for my plastic lumber needs.) -- Ricardo GPG: BCA6 89B6 3655 3801 C3C6 2150 197A 5888 235F ACAC https://elephly.net From lasich at gmail.com Thu Jul 27 10:13:01 2017 From: lasich at gmail.com (Hrvoje Lasic) Date: Thu, 27 Jul 2017 11:13:01 +0200 Subject: [Arm-netbook] CNC milling of plastic lumber instead of 3D printing? In-Reply-To: <87y3ra5kvm.fsf@elephly.net> References: <87y3ra5kvm.fsf@elephly.net> Message-ID: just a few notes below On 27 July 2017 at 10:45, Ricardo Wurmus wrote: > Heya, > > this idea is too late for the current batches of laptops, but I was > wondering if it wouldn’t be easier and faster to mill the laptop plastic > parts out of recycled blocks of plastic (“plastic lumber”) with a CNC > mill. > > The advantages are as follows: > > * suitable plastic lumber can be made from a wider range of plastics > than 3d printer filament > > > * plastic lumber can be made from readily available plastic waste. HDPE > from plastic bags make for cheap sturdy blocks of material. > > * a CNC mill cares much less about the melting point of the work piece > during operation than a 3d printer > actually during milling you also develop heat, potentially much higher then during 3d printing. You will need to test speeds, bits etc... > > * there are fewer concerns about material shrinkage at construction > time, because the work piece isn’t partially liquid at any time of the > CNC operations. > > * processing the work piece is faster because it doesn’t require as much > motion as printing sturdy zig zag patterns. > > * even rather unsophisticated CNC mills can be used as the work piece is > rather soft compared to the usual CNC mill work pieces such as > aluminium. > Actually, first of all not all parts can be milled. It totally depend on specific parts, so each part is separate problem.Also, if plastics are soft it does not mean that you need unsophisticated milling machine. You still need some range of precision and depend on parts 4 or 5 axes. So, it may turn to be very expensive. Also you are talking quite small parts that you need to hold&process somehow. I would say it is a project within a project. Then, if all these is doable in theory. Then you need a person who is very knowledgeable about processing materials (specifically plastics), one need to know a lot about processing speeds, depth cuts, tooling types etc and must be able to create tool paths on some kind of CAM software and this include trial & error process for each part. Then, lets imagine you found person that have that kind of machines, knowledge to do it, I guess it would be cheaper to create mold tooling from aluminum for each part and easily produce each part in thousands. > > The most obvious disadvantages are: > > * there seem to be much fewer vendors of plastic lumber than there are > vendors of high quality 3d printer filament > > * this approach isn’t quite as common, so it may be harder to find > good advice from experienced people. > > What do you think? > > (I’m currently in the process of setting up a plastic recycling work > space for my plastic lumber needs.) > > -- > Ricardo > > GPG: BCA6 89B6 3655 3801 C3C6 2150 197A 5888 235F ACAC > https://elephly.net > > > _______________________________________________ > arm-netbook mailing list arm-netbook at lists.phcomp.co.uk > http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook > Send large attachments to arm-netbook at files.phcomp.co.uk From lkcl at lkcl.net Thu Jul 27 10:57:41 2017 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Thu, 27 Jul 2017 10:57:41 +0100 Subject: [Arm-netbook] CNC milling of plastic lumber instead of 3D printing? In-Reply-To: <87y3ra5kvm.fsf@elephly.net> References: <87y3ra5kvm.fsf@elephly.net> Message-ID: On Thu, Jul 27, 2017 at 9:45 AM, Ricardo Wurmus wrote: > Heya, > > this idea is too late for the current batches of laptops, it isn't > but I was > wondering if it wouldn’t be easier and faster to mill the laptop plastic > parts out of recycled blocks of plastic (“plastic lumber”) with a CNC > mill. ok, so some of the parts are only 0.7mm thick in places: i'd be concerned about fibre chunks / variations. also it would mean a lot of software work writing a library (backend) for pyopenscad that outputted formats suitable for CNC machining. also it would be quite likely that the actual machining time would be far, far longer than 3D filament printing. i very much appreciate the idea though. l. From rekado at elephly.net Fri Jul 28 14:50:32 2017 From: rekado at elephly.net (Ricardo Wurmus) Date: Fri, 28 Jul 2017 15:50:32 +0200 Subject: [Arm-netbook] CNC milling of plastic lumber instead of 3D printing? In-Reply-To: References: <87y3ra5kvm.fsf@elephly.net> Message-ID: <87bmo4657b.fsf@elephly.net> Hrvoje Lasic writes: >> * a CNC mill cares much less about the melting point of the work piece >> during operation than a 3d printer >> > > actually during milling you also develop heat, potentially much higher then > during 3d printing. You will need to test speeds, bits etc... That’s right, but that’s a solved problem (for a given material and a range of tool speeds). The bit obviously shouldn’t rest and it should not rotate nearly as quickly as required for metals. >> * even rather unsophisticated CNC mills can be used as the work piece is >> rather soft compared to the usual CNC mill work pieces such as >> aluminium. >> > > […].Also, if plastics are soft > it does not mean that you need unsophisticated milling machine. You still > need some range of precision That’s right. I just meant that it doesn’t have to be these fancy industrial CNC machines. The requirements for the milling tool itself are much more reasonable when dealing with plastics compared to aluminium. > and depend on parts 4 or 5 axes. So, it may > turn to be very expensive. Also you are talking quite small parts that you > need to hold&process somehow. I would say it is a project within a project. Possibly. I haven’t taken a look at the parts myself. Obstructed cut outs won’t be possible with a simple CNC mill, obviously, but I wouldn’t expect one to use the designs that were made to target 3d printers to produce parts on a CNC mill. But you are right, that it wouldn’t be a simple decision to “switch” from 3d printers to CNC mills, which is also why I think that the idea came a bit late. -- Ricardo GPG: BCA6 89B6 3655 3801 C3C6 2150 197A 5888 235F ACAC https://elephly.net From doark at mail.com Fri Jul 28 15:37:22 2017 From: doark at mail.com (doark at mail.com) Date: Fri, 28 Jul 2017 10:37:22 -0400 Subject: [Arm-netbook] Init Freedom In-Reply-To: References: <87a84mj584.fsf@whist.hands.com> <20170704014107.GA10936@topoi.pooq.com> <20170704071700.mlaii6kcmdbxuxai@lemon.cohens.org.il> <5ba9e211-c058-dffd-e130-ac0848ff2a85@gmail.com> <20170707183516.21f11d95@ulgy_thing> Message-ID: <20170728103722.65a5d2c3@ulgy_thing> I'm replying very late because I needed to find the right words and they were not coming to me, till now. Feel free to return the favour (: On Sat, 8 Jul 2017 15:24:23 +0100 Luke Kenneth Casson Leighton wrote: > On Fri, Jul 7, 2017 at 11:35 PM, David Niklas wrote: > > I saw some > > of the most cordial behaviour that I have had the privilege to > > witness on a mailing list from most of (all?) the members! > > huh. despite quite a lot of "venting", that's really appreciated to > hear. What I am about to write aught to be interpreted with respect to my understanding of people and myself and I make no guarantee that my understanding is correct; only that I believe it is correct. "Venting", when not directed against a person is an expression of disgust with a situation. A constructive use "Venting" is the writing about a problem, whether someone actually notices or the situation improves helps the person by expressing there thoughts and feelings on the matter instead of keeping it bottled up inside of them. A person "vents" because a situation would have to be important to them, not because it necessarily is (consider gov. spying or proprietary hardware, how many people "Vent" against those vs. say, protecting the environment). Typically just not contradicting a "venting" person will leave them calmer than when they started. Therefore, I did not and do not consider "Venting" in and of itself an evil, rather as a means to and end. And there were times when those on the Devuan mailing list would seem to head towards the "I hate Poettering" side, but we would all engage them (except, maybe me because I would miss most of the discussion), to thinking about the enemy we were fighting, which was systemd, not Poettering, and it would work 100% of the time, at least as far as I remember. To be fair, I don't think anyone on the list would want to hire him or be his best friend, but that is personal preference or disgust, not hate. > > I really believe that they > > will meet with success in their toiling. Not to justify by pointing to > > lesser examples, but contrast it with the behaviour of Mr. Pottering. > > Insta-bug-close. Taking every available short cut. No Portability to > > clang/bsd/etc. > > *cringes*... i see you noticed his behaviour. I only wish I understood why. If you read Mr. Poettering's blog on systemd[1], he points out several technical merits. One of the biggest arguments against portability is made by telling people that daemons can't be trusted to stop and must, therefore be tracked by the init system so that they don't misbehave. He then goes on with how to write a daemon that utilizes systemd more effectively, thus daemons which were behaving under other init's stop working properly and function only on systemd unless they are written and tested on both systemd and not systemd init systems, thus doubling the work that needs to be done by the developers. Why must systemd do what it does the way it does? That is to say, if systemd must have unusual access to the kernel why not use a modular design so that BSD support could be implemented? Or even add a switch to the kernel to tell it to track a certain process so that it does not misbehave. That would work for both systemd and not systemd inits. The same could be done for socket activation. Have the daemon itself tell the kernel that it wants the socket to be opened with the expectation that another process will attach later. The incompatibility with clang seems to be mostly an attempt at not wanting to do memory management, why not use rust? Or sh ...... (: Sincerely, David [1] http://0pointer.de/blog/projects/systemd.html From doark at mail.com Fri Jul 28 16:08:16 2017 From: doark at mail.com (doark at mail.com) Date: Fri, 28 Jul 2017 11:08:16 -0400 Subject: [Arm-netbook] Side-Topic: Liberating PocketCHIP In-Reply-To: <20170711101021.GA4378@pabbook> References: <20170510142356.GB8937@pabbook> <20170511141511.GC4716@pabbook> <20170706112156.GA2719@avocado> <20170707181929.05eeacb1@ulgy_thing> <20170711101021.GA4378@pabbook> Message-ID: <20170728110816.03497692@ulgy_thing> On Tue, 11 Jul 2017 12:10:21 +0200 Pablo Rath wrote: > On Fri, Jul 07, 2017 at 06:19:29PM -0400, David Niklas wrote: > > On Thu, 6 Jul 2017 13:21:56 +0200 > > > > Actually, my PC has a kernel fault > > It took me a moment to guess that you abbreviate PocketChip as "PC". My > mind went like: "What? Why is he talking about his Personal Computer > now?" :) The pocketchip community uses that abbreviation frequently, it confuses me sometimes too. > > (It's a long story of ntc's evil > > doing), > > Why do you believe that ntc is evil? When you boot a normal Linux computer you are presented with a plymouth boot screen and can hit escape to exit and see the boot messages. I pocketchip's case you are presented (serendipity), with a boot screen that somehow references a file listed in /home/chip (I forget the exact name, it starts with a period), that invokes feh on pocketchip's logo boot screen from which there is no escape. If you uninstall plymouth and delete the file that invokes feh in /home/chip you are just presented with a black screen. Once pocketchip finishes booting you cannot use Alt-F[0-9][0-9] to switch tty's, nor can you use Ctrl-Alt-F[0-9][0-9], so if the boot fails for any reason you are stuck with never being able to fix or diagnose it (though you might get the last few messages of some error, which you might have read in full if the screen was not black). I asked in to forums about how to solve this and it's been weeks without any answer (I only ever got one, and that user told me not to side load software (which I explained that I never did or even thought of)). > > and the Linux kernel claims that it is not tainted. > > I don't know if that covers firmware, but at least there are no > > modules that are non-free. > > I don't understand the paragraph above. Do you talk about mainline linux > kernel, ntc's kernel fork for Chip, ... Can you please clarify? The kernel is the default and it's name is: 4.4.13 ntc mlc > > > > Best bet is to use libre-linux mainline and besides that just > > > > attempt to deblob ntc's components by hand, which shouldn't be a > > > > problem long term cause it doesn't look like they maintain any of > > > > this stuff at all anyway and it's very likely the only blobs are > > > > in the kernel anyway however not a sure one. > > > > > > I ditched all the custom NTC stuff and went for vanilla Debian. I > > > have managed to install Debian Stretch (current Stable) on a USB > > > stick using Debian Installer. I am using a self-compiled mainline > > > U-Boot via sunxi-fel to circumvent the U-Boot version on NAND > > > provided by the manufacturer which can not boot from USB. > > > > > > I've found two faults that cannot be traced without a postmortem and > > I'm really sick of accidentally causing this thing to manifest said > > problems and then loosing all the work that I did in between my > > backup periods. > > How can you be sure it is a kernel bug and not another problem? Can't, that's why I'm in this predicament. All I know is the last few messages that say that the kernel is not syncing with the rootfs (and I have not touched the partition table, or init, or those scripts and files (like fstab), which would alter the mounting process). > Can you > give us some details. Did you ask on ntc's user forum or did you file a > bug report 2. Asked on the forum (I was a bit exasperated at the time since FLOSS software is no good to me if I can't debug it). Here are the post (hmm, seems that email notification of new replies is not working: https://bbs.nextthing.co/t/pocketchip-boots-to-black-screen/14643 https://bbs.nextthing.co/t/kernel-panic-not-syncing/17525 > Can't you improve you backup strategy - for example commit > to an external git repo; or synchronize with another stable working > computer? 3. Not really. I use pocketchip on-the-go and typically what I'm doing on the go is offline and I'm physically separated from my other machines. > > I'm in need of a way to boot PC without flashing the NAND I there a > > way to do this? So far my search results have been unsuccessful. > > 1. Well, you can take your Chip out of the housing and install the > distro of you choice on a USB-stick and use it as a regular Chip. I thought chip could not boot via usb? > 2. Can you get PocketChip into fel-mode without taking it out of the > enclosure? Ntc's documentation claims it is not possible but there is a > forum thread about a reboot option into fel-mode. I have no PoketChip > and leave it up to you to research the answers to this questions. I think I could but then what? I know repetitively little about FEL mode (though I'm willing to learn). > Another point is if the distro of you choice on a USB-stick will support > PocketChips hardware (e.g. Keyboard, LCD-Screen) out of the box. Do you > have a serial-to-usb-cable to interact with PocketChip? I don't think so. But it's confusing when people write things like that because USB stands for Universal *Serial* Bus (so USB is a serial cable and no conversion is needed!). > > kind regards > Pablo > Thanks Pablo, David t From lkcl at lkcl.net Sat Jul 29 13:53:55 2017 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Sat, 29 Jul 2017 13:53:55 +0100 Subject: [Arm-netbook] python coding help needed (sin, cosine, blah blah) Message-ID: http://hands.com/~lkcl/foldable3dsandwich200/belts.py ok, i could use some algorithm help, here, if anyone's interested. the key function is add_bearing in class Belt. basically what i have done is create a class which completely specifies a belt path, by starting out with the angle that the belt is wrapped around so far, plus the position, plus the diameter of the bearing (a fake bearing initially). subsequent bearings need only be added specifying their position, radius, and whether the belt is to go on the INTERIOR or the EXTERIOR of the bearing. the swapping-from-interior-to-exterior is where i'm having difficulties. i've made a half-assed approximation so far, i will upload a quick video about it... https://youtu.be/AV5yRz6GPX0 the problem i have is that the flip-over between interior and exterior is a little bit too complicated for my tiny brain to handle. i know that it involves twin offsets. i think it might be possible to work out the first angle between the bearings, then pretend that there's another bearing added on the *other* side (in the opposite configuration), then work out the angle of *that* (fake) bearing to the one before it... anyway if anybody would like to have a go at tackling this i would be really grateful. l. From benson.mitchell+arm-netbook at gmail.com Sat Jul 29 14:51:03 2017 From: benson.mitchell+arm-netbook at gmail.com (Benson Mitchell) Date: Sat, 29 Jul 2017 09:51:03 -0400 Subject: [Arm-netbook] python coding help needed (sin, cosine, blah blah) In-Reply-To: References: Message-ID: On Sat, Jul 29, 2017 at 8:53 AM, Luke Kenneth Casson Leighton wrote: > http://hands.com/~lkcl/foldable3dsandwich200/belts.py > > ok, i could use some algorithm help, here, if anyone's interested. > the key function is add_bearing in class Belt. > I don't really speak python, but I'm happy to put my two cents in. You've got three of the four cases defined, but to start with I only looked at the simple one (invert==0, oldinvert==0) which you seem to think is solved. Unless I'm missing something, it's not really solved at all -- it looks like it completely ignores any difference in radius when figuring the contact angles. And I think when you fix that, the hard cases will mostly explain themselves (you'll basically negate the radius in that calculation, and maybe also add/subtract the belt thickness). So, given the old bearing has radius R1 and the new bearing has radius R2, separated horizontally (or at any other angle) by a distance D, we can find the deviation from horizontal (or in the general case, the deviation from the angle connecting their centers): arcsin((R1-R2)/D) And of course, negate that if they're both inverted (rather than both noninverted). (Not entirely clear on your sign convention, so this may be exactly backwards, but you can figure that out faster than I could puzzle through it.) And if you're crossing over, with belt thickness T, that should just become arcsin((R1+R2+T)/D) (again, this is going from noninverted to inverted -- negate for inverted to noninverted, or maybe the opposite.) But of course in this case, you leave the first bearing at one angle, and contact the second bearing at the opposite angle; if you actually redefine R2=-(R2+T), this takes care of itself, so you might not need all the cases. (Though the part where you wrap the arc around the old bearing will need to be careful about clockwise/counterclockwise.) Hope that helps. Benson Mitchell From njansen1 at gmail.com Sat Jul 29 15:22:31 2017 From: njansen1 at gmail.com (Neil Jansen) Date: Sat, 29 Jul 2017 10:22:31 -0400 Subject: [Arm-netbook] screwed up the Riki200 plotter design In-Reply-To: References: Message-ID: On Tue, Jul 25, 2017 at 2:28 PM, Luke Kenneth Casson Leighton wrote: > > pick-and-place, cnc, etc it's all the same principle. OK, forgive me for going slightly off-topic here, but this whole time, I've been sitting here wondering if you're batshit crazy, or if your 3D printer design will work as well as you say it will work. That's mainly because I do think it's crazy to be designing a machine in 2017 when there are so many existing designs out there that work. I remember your arguments from before as to why, so my purpose of writing this isn't to bring the motivation back up. Originally I didn't really have a leg in the fight, but as I've been looking at the CAD screenshots and build pictures from your recent work, it is actually starting to take the shape of something that I had started to design about a year or so back, for the purposes of SMT pick and place. Looking at the pics at http://forums.reprap.org/file.php?177,file=96492 and http://forums.reprap.org/file.php?177,file=96491 it looks alarmingly similar to what I had originally intended to design. The only differences are what gets mounted on the head, and I probably would have went with Hiwin rails instead of pulleys. There's enough room on that head for cameras, a Juki nozzle or two, and a height touch-off probe. Differences in 3D printing philosophy aside, I think that this design could possibly be useful for an SMT pick and place frame. At this point I'm just going to sit here and patiently wait with popcorn in hand and wait until the whole thing plays out. I'm not in any real rush so it wouldn't even be in 2017 before I would start building one. Anyway, good luck with the whole thing. I still think you're batshit crazy, but in some evil genius way, if you can pull it off. From lkcl at lkcl.net Sat Jul 29 15:49:21 2017 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Sat, 29 Jul 2017 15:49:21 +0100 Subject: [Arm-netbook] python coding help needed (sin, cosine, blah blah) In-Reply-To: References: Message-ID: --- crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68 On Sat, Jul 29, 2017 at 2:51 PM, Benson Mitchell wrote: > On Sat, Jul 29, 2017 at 8:53 AM, Luke Kenneth Casson Leighton > wrote: > >> http://hands.com/~lkcl/foldable3dsandwich200/belts.py >> >> ok, i could use some algorithm help, here, if anyone's interested. >> the key function is add_bearing in class Belt. >> > I don't really speak python, but I'm happy to put my two cents in. python's pretty clear and human-readable. > You've got three of the four cases defined, yes. the last case - which is when 2 or more inverted-belt bearings are added - i skipped, on the basis that i would not really use it (if ever). > but to start with I only looked > at the simple one (invert==0, oldinvert==0) which you seem to think is > solved. it is... but explaining how it works is not something i can easily do. i tend to work by intuition and guess-work. i was terribly surprised when a series of random and semi-arbitrary code-modifications actually produced the desired result. > Unless I'm missing something, it's not really solved at all -- it > looks like it completely ignores any difference in radius when figuring the > contact angles. ah. ok you see the loop "+= 360"? i vaguely figured that any change would have to result in a positive increase in angle. any change that went over 360 could be made modulus 360 for the *next* change. staggeringly this actually works. > And I think when you fix that, the hard cases will mostly > explain themselves (you'll basically negate the radius in that calculation, > and maybe also add/subtract the belt thickness). ok the problem of actually creating the belt is passed to that SurfaceFromCurves function. you give it a set of points (actually two sets) and a "thickness" parameter, and it *automatically* creates the full 3D polygon set needed to create a complete 3D surface of thickness "thickness". > So, given the old bearing has radius R1 and the new bearing has radius R2, > separated horizontally (or at any other angle) by a distance D, we can find > the deviation from horizontal (or in the general case, the deviation from > the angle connecting their centers): > arcsin((R1-R2)/D) yep this case is not covered at all. however given that i am only using radii of 6 and 7 or 8 and 9, with long separation between them and also where there is a huge discrepancy the angles are 180 degrees and dead-straight (lined up by eye), the differences caused by not taking into account the case R1 != R2 are either actually zero or negligeably small. it's a visual aid and approximation anyway, but i would really like it to actually be complete and accurate, as i will be doing more complex belt layouts later. > And if you're crossing over, with belt thickness T, that should just become > arcsin((R1+R2+T)/D) > (again, this is going from noninverted to inverted -- negate for inverted > to noninverted, or maybe the opposite.) if i can be absolutely honest, my mind isn't one that can cope with or follow accurate mathematical calculations. when working with the spline-generating function i had to leave *six years* in between modifications and it took me 2 days of experimentation to get even a reaasonably-approximate version of "normalised vectors" up and running. that was from a lot of google searches, as well :) so if i may, i'd like to leave it to others to discuss this, if they want to: i'll chip in if necessary. l. From lkcl at lkcl.net Sat Jul 29 16:04:56 2017 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Sat, 29 Jul 2017 16:04:56 +0100 Subject: [Arm-netbook] screwed up the Riki200 plotter design In-Reply-To: References: Message-ID: On Sat, Jul 29, 2017 at 3:22 PM, Neil Jansen wrote: > OK, forgive me for going slightly off-topic here, but this whole time, I've > been sitting here wondering if you're batshit crazy, or if your 3D printer > design will work as well as you say it will work. That's mainly because I > do think it's crazy to be designing a machine in 2017 when there are so > many existing designs out there that work. *sigh* i know it seems that way but i am not kidding when i say that literally every single 3D printer i've seen has some form of design flaw or is made from materials and parts that are just... too far-out expensive, given that the requirements are to maximise mm / sec / $. maximising mm / sec / $ has some very _very_ specific implications, that you can either minimise $ or you can maximise mm/sec (or both). unfortunately many of the "minimal $ 3D printers" are so shit that to try to increase mm / sec results in f*****g worse-than-useless quality. aaand unfortunately, many of the high-end 3D printers where $ is high, the amount of $ that went into their construction is completely insufficient to compensate for their $, such that the "mm / sec / $" metric is *WORSE* than that of a cheaper crappy 3D printer! thus i am therefore looking for something *in between* those two extremes... and i absolutely kid you not, there is *literally* not a single one. the ultimaker-2: absolute stellar mechanical design, i give it a 100% score for mechanical design rigidity... except it's $2,000 and uses a bowden tube. if you know about bowden tubes (latency/play requiring 4-5mm of retract to compensate!) or have ever had nightmare problems with bowden tubes, you'll know what i'm referring to. prusa i3 and prusa i3 clones: vertical carriages (almost 100% of them), which are just too shit to even remotely consider. vertical carriages result in the entire head mechanism twisting and bending the rods and the X-ends so badly that the head can actually bounce around, causing both Z and Y variation. the list just goes on and on, eliminating every single pre-existing design out there. > I remember your arguments from > before as to why, so my purpose of writing this isn't to bring the > motivation back up. oh, ok :) > Originally I didn't really have a leg in the fight, > but as I've been looking at the CAD screenshots and build pictures from > your recent work, it is actually starting to take the shape of something > that I had started to design about a year or so back, for the purposes of > SMT pick and place. Looking at the pics at > http://forums.reprap.org/file.php?177,file=96492 and > http://forums.reprap.org/file.php?177,file=96491 it looks alarmingly > similar to what I had originally intended to design. very funny :) well, it's GPLv3+ licensed parametric (python) source code, so you're more than welcome. > The only differences > are what gets mounted on the head, and I probably would have went with > Hiwin rails instead of pulleys. there's MGN9C Hiwin rails underneath the X and Y ends. two MGN9C blocks. actually MGN9 was a mistake: i should have made it MGN12 - the MGN9s are actually only about 6.5 to 7mm wide where the 2020 slot is 5.5mm with a 0.5mm curve on each edge.... damn things keep *dropping into the slot* and end up at an angle, pretty much no matter what i do. this is a pain in the ass, to say the least. but... *sigh*.... it's what i got now. > There's enough room on that head for > cameras, a Juki nozzle or two, and a height touch-off probe. ... just. if you don't need fans. which you shouldn't. there's about... 50x50mm of clear space without hitting any bearings or rods, and there's also space in between the bearings @ 25mm x 25mm to give a maltese-cross style amount of space to put "stuff". > Differences in 3D printing philosophy aside, I think that this design could > possibly be useful for an SMT pick and place frame. yehyeh it could. > At this point I'm just going to sit here and patiently wait with popcorn in > hand and wait until the whole thing plays out. I'm not in any real rush so > it wouldn't even be in 2017 before I would start building one. well give me a shout as i do want to make one at some point > Anyway, good luck with the whole thing. I still think you're batshit > crazy, but in some evil genius way, if you can pull it off. :) From kahl at cas.mcmaster.ca Sat Jul 29 17:51:46 2017 From: kahl at cas.mcmaster.ca (Wolfram Kahl) Date: Sat, 29 Jul 2017 12:51:46 -0400 Subject: [Arm-netbook] screwed up the Riki200 plotter design In-Reply-To: References: Message-ID: <20170729165146.GB4539@ritchie.cas.mcmaster.ca> On Sat, Jul 29, 2017 at 04:04:56PM +0100, Luke Kenneth Casson Leighton wrote: > thus i am therefore looking for something *in between* those two > extremes... Just because it looks sufficiently different that I am surprised to not have seen it mentioned here yet: http://www.snapmaker.com/ (However still at pre-order stage, ``Estimated Delivery: November 2017''.) Wolfram From njansen1 at gmail.com Sat Jul 29 18:38:29 2017 From: njansen1 at gmail.com (Neil Jansen) Date: Sat, 29 Jul 2017 13:38:29 -0400 Subject: [Arm-netbook] screwed up the Riki200 plotter design In-Reply-To: References: Message-ID: On Sat, Jul 29, 2017 at 11:04 AM, Luke Kenneth Casson Leighton < lkcl at lkcl.net> wrote: > > *sigh* i know it seems that way but i am not kidding when i say that > literally every single 3D printer i've seen has some form of design > flaw or is made from materials and parts that are just... too far-out > expensive, given that the requirements are to maximise mm / sec / $. Ehh... How many months have you been at this design so far? You could have bought some crappy printers, taken a few months to print the parts, and could have moved on with the other (arguably more important) EOMA68 development and manufacturing stuff. As it sits right now, you've not printed a single production frame, because you're too busy designing a 3d printer. Even after you've made your first one, there are still some sizable risks before you go out and build a fleet of them. Your "existential 3D printing moments" blog post was on May 16, where you said that with 10 printers, it would take four months of 8 hours a day printing to make these parts. Assume 16 hours per day, that's two (2) months with the same amount of machines. Or, for 24 hours a day (3 shifts), it's now down to 1.3 months. If I were you, I'd literally be done by now. That's because I would have used "status quo" 3D printers that would have been running and happily turning out parts back in the month of May (possibly even before that). If that 'four month' estimate was for the "fast" machines, then yea, maybe I'd be only halfway done? But then again that's still further than where you are right now. Labor is cheap where you're at. I'd have no issue running a small operation 24/7 if that's what it took. Hell, we did that in China when I was out there. Maybe you're over-thinking it. Just sayin' ;) From lkcl at lkcl.net Sat Jul 29 19:37:22 2017 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Sat, 29 Jul 2017 19:37:22 +0100 Subject: [Arm-netbook] screwed up the Riki200 plotter design In-Reply-To: <20170729165146.GB4539@ritchie.cas.mcmaster.ca> References: <20170729165146.GB4539@ritchie.cas.mcmaster.ca> Message-ID: --- crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68 On Sat, Jul 29, 2017 at 5:51 PM, Wolfram Kahl wrote: > On Sat, Jul 29, 2017 at 04:04:56PM +0100, Luke Kenneth Casson Leighton wrote: >> thus i am therefore looking for something *in between* those two >> extremes... > > Just because it looks sufficiently different that I am surprised > to not have seen it mentioned here yet: > > http://www.snapmaker.com/ PRINT HEAD TRAVEL SPEED Up to 100 mm/s i'm doing 150mm/sec print speed and 200mm/sec travel speed even on the cheap taobao clone. l. From lkcl at lkcl.net Sat Jul 29 20:04:01 2017 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Sat, 29 Jul 2017 20:04:01 +0100 Subject: [Arm-netbook] screwed up the Riki200 plotter design In-Reply-To: References: Message-ID: --- crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68 On Sat, Jul 29, 2017 at 6:38 PM, Neil Jansen wrote: > Ehh... How many months have you been at this design so far? although i've pretty massively lost track of time, i think it's been 5 weeks (including parts ordering) which is pretty damn fast for an entirely new 3D printer. for comparison, i was forced to spend an emergency 3 weeks recovering the shit-for-brains taobao clone. the level of ignorance that's propagated throughout the 3D printing world is stupendously high, neil. and, worse, the fucking idiots who supply 3D printers over here don't fucking well respect the GPL, and, even worse than that, are quite likely to ship you a TOTALLY DIFFERENT SET OF PARTS from the ones you paid money for! i can't risk even buying some arbitrary off-the-shelf pile-of-crap from a china supplier - done it twice already here and it was utterly pointless. this really is the only safe way to do it: take advantage of the low cost of parts, and do the design right. it's the only way i'll know i'll get something that will work, not least because if there *is* something wrong i don't have to fucking well reverse-engineer 80% of the fucking parts like i was forced to with this fucking shit-for-brains taobao clone even before *getting started* with fixing the damn problem. nnnnggggh :) > printer. Even after you've made your first one, there are still some > sizable risks before you go out and build a fleet of them. ... which is why i'm happy to take my time doing it. > Your "existential 3D printing moments" blog post was on May 16, where you > said that with 10 printers, it would take four months of 8 hours a day > printing to make these parts. Assume 16 hours per day, that's two (2) > months with the same amount of machines. Or, for 24 hours a day (3 > shifts), it's now down to 1.3 months. > > If I were you, I'd literally be done by now. you wouldn't... because the laptop's design is still at the prototype phase. there's several months including redesigning and prototyping the laptop PCBs before that casework redesign work can even begin. > Maybe you're over-thinking it. i'm not: there's also the fact that the unanticipated costs have eaten into the available budget, making it impossible to entirely fufil the promises made (if this is news to anyone, it's not news: i've mentioned this many times, many many months ago). also mentioned months ago, i am also therefore working on a staggered delivery strategy, and also mentioned months ago i am looking at other projects in order to raise extra funds. one of those strategies mentioned is to have a second set of designs on a second crowdsupply campaign *using the exact same PCBs and using the exact same LCD as will go into the laptop* (an all-in-one PC). that thus increases the ordering quantities for those parts and thus *reduces* costs [for both campaigns], as well as reduces risk and development costs for both projects. the 3D printer is an extra arm in that same strategy. it's *not* just being done "because i feel like it". l. From lkcl at lkcl.net Mon Jul 31 08:10:25 2017 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Mon, 31 Jul 2017 08:10:25 +0100 Subject: [Arm-netbook] Arm Netbook, Saw the update, In-Reply-To: References: <729312675.2922981.1498019518849.ref@mail.yahoo.com> <729312675.2922981.1498019518849@mail.yahoo.com> <594A892D.6040009@posteo.de> <74fd6c20-725d-5eac-1057-1a4be035ddea@aross.me> <1DAA53E0-C7C8-4DED-8E62-087C2B20AFE6@gmail.com> <87485148-2167-45A7-8298-FDE1A6C66B6F@gmail.com> <936CCB09-9310-4405-A7B6-C85CA4944309@gmail.com> Message-ID: hiya richard, i'd like to send off a test PCB to the factory with just the DC3 micro-hdmi on it, whilst you're happily doing the review, can i ask you the favour of checking to see if there's anything glaringly-obvious about the DC3 layout (just the DC3 footprint really). i am aware that pins 8 and 12 are so close to the edge of the board (with the 2 VIAs) that it's impossible to get GND shielding round them... and that they're also doing a U-turn 180 degrees which is bad for R.F.... but there's really not a lot of choice here. at least they're surrounded by GND and vias... and... technically... where the vias come up the pins for those signals are directly above them (also surrounded by pins that are also GND)... so it's kiiinda okay... thoughts appreciated. l. From vkontogpls at gmail.com Mon Jul 31 11:22:35 2017 From: vkontogpls at gmail.com (Bill Kontos) Date: Mon, 31 Jul 2017 13:22:35 +0300 Subject: [Arm-netbook] Broadcom BCM2837 100% libre now ? Message-ID: Open firmware seems to be available here for a minimal boot. I have no idea if this is reverse engineered or provided by Broadcom, it seems like broadcom has at least released all the headers under some bsd-like license. The firmware here is gplv2+. https://github.com/christinaa/rpi-open-firmware Here is a report of someone booting using only the free firmware dated Jan 2017 while the most recent commits are from April. http://crna.cc/b/11 If I recall correctly the kernel driver was already open-sourced in 2014. The VC4 mesa driver made and upstreamed by a broadcom emploee here. I'm kind of confused since the vpu has to be used for the rpi to boot even if you don't want video acceleration, but this is an foss drm driver for the vc4 silicon only... what's going on with the part of the blob that used to do the initialization? https://github.com/anholt/mesa/wiki/VC4 And some documentation https://www.kernel.org/doc/html/latest/gpu/vc4.html Is this enough ? Or close to enough for a fully libre BCM2837 system to make it worth taking a look ? It seems like with the community around the rpi any bugs etc would be very easy to spot and squash in the future. I still don't know what's going on with the wifi in that SoC and I won't pretend that I understand everything I just wrote, but it certainly seems like there has been some movement from the "the 2mb userland blob does everything" stage. I found somewhere that board schematics still require an nda though. From lkcl at lkcl.net Mon Jul 31 11:45:44 2017 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Mon, 31 Jul 2017 11:45:44 +0100 Subject: [Arm-netbook] Broadcom BCM2837 100% libre now ? In-Reply-To: References: Message-ID: On Mon, Jul 31, 2017 at 11:22 AM, Bill Kontos wrote: > Is this enough ? Or close to enough for a fully libre BCM2837 system > to make it worth taking a look ? https://www.theinquirer.net/inquirer/news/2362800/hardkernel-cancels-raspberry-pi-like-odroid-w-after-broadcom-stops-supplying-soc unfortunately just the firmware being entirely libre isn't enough if the company itself operates as a totally unethical cartel. broadcom is at heart a completely unethical company. the only reason they have released firmware is because they're absolutely deluged with complaints, because of the popularity of the raspberry pi products. now, if that situation ever changes and you hear of a way to *guarantee* getting hold of BCM2837 processors... and get hold of the schematics and get hold of the datasheet and get hold of a PCB CAD Reference Design... *ALL WITHOUT AN NDA*.... .... *then* it can be considered. l. From richard.wilbur at gmail.com Mon Jul 31 13:42:51 2017 From: richard.wilbur at gmail.com (Richard Wilbur) Date: Mon, 31 Jul 2017 06:42:51 -0600 Subject: [Arm-netbook] Arm Netbook, Saw the update, In-Reply-To: References: <729312675.2922981.1498019518849.ref@mail.yahoo.com> <729312675.2922981.1498019518849@mail.yahoo.com> <594A892D.6040009@posteo.de> <74fd6c20-725d-5eac-1057-1a4be035ddea@aross.me> <1DAA53E0-C7C8-4DED-8E62-087C2B20AFE6@gmail.com> <87485148-2167-45A7-8298-FDE1A6C66B6F@gmail.com> <936CCB09-9310-4405-A7B6-C85CA4944309@gmail.com> Message-ID: <4A9370BF-E753-4D6F-8FD2-1040722927BC@gmail.com> On Jul 31, 2017, at 01:10, Luke Kenneth Casson Leighton wrote: > > hiya richard, i'd like to send off a test PCB to the factory with just > the DC3 micro-hdmi on it, whilst you're happily doing the review, can > i ask you the favour of checking to see if there's anything > glaringly-obvious about the DC3 layout (just the DC3 footprint > really). Sure! Sorry I haven't gotten my recommendations off to you earlier. I was hoping to finish a second draft of the document today after adding some discussion of the motivation for why I'm recommending certain things and not worrying about others. Then I was planning on firing it off to the list. So I'll see how quickly I can change this from a waiting game to a technical discussion (dealing with DC3 pins 8 and 12 among other things). -- Richard From lkcl at lkcl.net Mon Jul 31 13:55:27 2017 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Mon, 31 Jul 2017 13:55:27 +0100 Subject: [Arm-netbook] Arm Netbook, Saw the update, In-Reply-To: <4A9370BF-E753-4D6F-8FD2-1040722927BC@gmail.com> References: <729312675.2922981.1498019518849.ref@mail.yahoo.com> <729312675.2922981.1498019518849@mail.yahoo.com> <594A892D.6040009@posteo.de> <74fd6c20-725d-5eac-1057-1a4be035ddea@aross.me> <1DAA53E0-C7C8-4DED-8E62-087C2B20AFE6@gmail.com> <87485148-2167-45A7-8298-FDE1A6C66B6F@gmail.com> <936CCB09-9310-4405-A7B6-C85CA4944309@gmail.com> <4A9370BF-E753-4D6F-8FD2-1040722927BC@gmail.com> Message-ID: --- crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68 On Mon, Jul 31, 2017 at 1:42 PM, Richard Wilbur wrote: > On Jul 31, 2017, at 01:10, Luke Kenneth Casson Leighton wrote: >> >> hiya richard, i'd like to send off a test PCB to the factory with just >> the DC3 micro-hdmi on it, whilst you're happily doing the review, can >> i ask you the favour of checking to see if there's anything >> glaringly-obvious about the DC3 layout (just the DC3 footprint >> really). > > Sure! Sorry I haven't gotten my recommendations off to you earlier. I was hoping to finish a second draft of the document today after adding some discussion of the motivation for why I'm recommending certain things and not worrying about others. Then I was planning on firing it off to the list. > > So I'll see how quickly I can change this from a waiting game to a technical discussion (dealing with DC3 pins 8 and 12 among other things). appreciated. it's been about six weeks now, and there will be about 2 weeks estimated time on the test PCB before a 2.7.5 pre-production test run could go ahead. l.