From paul at boddie.org.uk Tue Dec 4 20:12:01 2018 From: paul at boddie.org.uk (Paul Boddie) Date: Tue, 04 Dec 2018 21:12:01 +0100 Subject: [Arm-netbook] What do 1,000 EOMA68-A20 PCBs look like? Message-ID: <3518671.gX2FLSBOfK@jeremy> Hello, Nice to see the progress being made in the recent update: https://www.crowdsupply.com/eoma68/micro-desktop/updates/what-do-1-000-eoma68-a20-pcbs-look-like It's a shame that you have to redo your Parabola bootstrapping. I experimented with bootstrapping Parabola on MIPS a few months ago using two different approaches - (1) try and cross-compile packages, (2) try and native build in another environment - and it was rather frustrating either way. Ultimately, I didn't regard it as a great way to spend my time. Paul From doark at mail.com Wed Dec 5 03:25:53 2018 From: doark at mail.com (David Niklas) Date: Tue, 4 Dec 2018 22:25:53 -0500 Subject: [Arm-netbook] libre-riscv, first update In-Reply-To: References: Message-ID: <20181204222553.614a3e92@Phenom-II-x6.niklas.com> On Thu, 29 Nov 2018 10:34:12 +0000 Luke Kenneth Casson Leighton wrote: > https://www.crowdsupply.com/libre-risc-v/m-class/updates/why-make-a-quad-core-64-bit-soc-surely-there-are-enough-already > > in case anyone's interested, do subscribe to updates. i'll post links > here anyway. > luke, the kazan project says that it is a driver, whereas you say that it is a GPU "Onboard the Libre RISC-V M-Class is the Kazan GPU,..." at: https://www.crowdsupply.com/libre-risc-v/m-class I accessed the link on the kazan git page to see the risc-v GPU at: https://libre-riscv.org/3d_gpu/ I noticed that you began a paragraph without mentioning what the heck the RVV thing is that you're talking about: "one of the things that's lacking from RVV..." Then you go off into "wonderland" explaining to us that gcc needs to have something (???) done to it to support RVV. Then you say that such a job would never have to be done again after Simple-V is through the "Extension Proposal Process" for "one single parallel / vector / SIMD instruction" without telling us why that would be the case and why no one has done such a thing before to make supporting GPUs, or are we still talking about RVV?, through gcc easier. I also see no mention of llvm in there, would we need to add support in both, only gcc, or what? Thanks! From lkcl at lkcl.net Wed Dec 5 03:38:59 2018 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Wed, 5 Dec 2018 03:38:59 +0000 Subject: [Arm-netbook] What do 1,000 EOMA68-A20 PCBs look like? In-Reply-To: <3518671.gX2FLSBOfK@jeremy> References: <3518671.gX2FLSBOfK@jeremy> Message-ID: On Tue, Dec 4, 2018 at 8:12 PM Paul Boddie wrote: > Hello, > > Nice to see the progress being made in the recent update: > > https://www.crowdsupply.com/eoma68/micro-desktop/updates/what-do-1-000-eoma68-a20-pcbs-look-like > > It's a shame that you have to redo your Parabola bootstrapping. I experimented > with bootstrapping Parabola on MIPS a few months ago using two different > approaches - (1) try and cross-compile packages, (2) try and native build in > another environment - and it was rather frustrating either way. Ultimately, I > didn't regard it as a great way to spend my time. :) it was quite hilarious to get up and running. https://wiki.parabola.nu/MIPS_Installation - oh. discontinued. that's not going to help *sigh*. basically it's a hell of a lot easier if you have a native x86 parabola install, as you can then use the equivalent of debian foriegn arch debootstrap, and the --second-stage you run a qemu emulator to finish off the install. that's basically exactly what i did... except because i didn't have native x86 parabola i ran in qemu. it worked really well and makes for a hilarious story. l. From lkcl at lkcl.net Wed Dec 5 03:51:41 2018 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Wed, 5 Dec 2018 03:51:41 +0000 Subject: [Arm-netbook] libre-riscv, first update In-Reply-To: <20181204222553.614a3e92@Phenom-II-x6.niklas.com> References: <20181204222553.614a3e92@Phenom-II-x6.niklas.com> Message-ID: --- crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68 On Wed, Dec 5, 2018 at 3:27 AM David Niklas wrote: > > On Thu, 29 Nov 2018 10:34:12 +0000 > Luke Kenneth Casson Leighton wrote: > > https://www.crowdsupply.com/libre-risc-v/m-class/updates/why-make-a-quad-core-64-bit-soc-surely-there-are-enough-already > > > > in case anyone's interested, do subscribe to updates. i'll post links > > here anyway. > > > > luke, the kazan project says that it is a driver, whereas you say that it > is a GPU "Onboard the Libre RISC-V M-Class is the Kazan GPU,..." at: > https://www.crowdsupply.com/libre-risc-v/m-class > > I accessed the link on the kazan git page to see the risc-v GPU at: > https://libre-riscv.org/3d_gpu/ > I noticed that you began a paragraph without mentioning what the heck > the RVV thing is that you're talking about: > "one of the things that's lacking from RVV..." > Then you go off into "wonderland" explaining to us that gcc needs to have > something (???) done to it to support RVV. Then you say that such a job > would never have to be done again after Simple-V is through the > "Extension Proposal Process" for "one single parallel / vector / SIMD > instruction" without telling us why that would be the case and why no one > has done such a thing before to make supporting GPUs, or are we still > talking about RVV?, through gcc easier. yep, sorry, many of the pages there are memory-aides / notes, so as not to lose track of what is an extremely complex project. RVV is the vectorisation extension for RISC-V: https://github.com/riscv/riscv-v-spec/blob/master/v-spec.adoc the updates (2nd in editorial, 3rd in draft) are intended to be much more the public conversation: unlike the eoma68 project there's just not been time yet to get a discussion list up and running. > I also see no mention of llvm in there, yes, i hadn't got round to updating that page. there's actually another one somewhere https://libre-riscv.org/shakti/m_class/libre_3d_gpu/ > would we need to add support in > both, only gcc, or what? ideally both. we're currently evaluating ways to make a multi-issue microarchitecture including branch-prediction, where if you don't use SV, at least performance will be half-way decent, even at 800mhz. the key areas of focus are the inner loops for GPU and VPU. these initially will be written in inline assembler. *once* both gcc and llvm have support for whatever is found to be the best design, then performance of standard code will catch up. http://lists.libre-riscv.org/pipermail/libre-riscv-dev/2018-December/000198.html l. From paul at boddie.org.uk Wed Dec 5 16:40:29 2018 From: paul at boddie.org.uk (Paul Boddie) Date: Wed, 05 Dec 2018 17:40:29 +0100 Subject: [Arm-netbook] What do 1,000 EOMA68-A20 PCBs look like? In-Reply-To: References: <3518671.gX2FLSBOfK@jeremy> Message-ID: <2316671.UOBgKsZiV5@jeremy> On Wednesday 5. December 2018 03.38.59 Luke Kenneth Casson Leighton wrote: > > it was quite hilarious to get up and running. > https://wiki.parabola.nu/MIPS_Installation - oh. discontinued. > that's not going to help *sigh*. Yes, it seems that people got enthusiastic when Stallman started using that Lemote laptop, but when he stopped using it, they all dropped MIPS as soon as they could. So, gNewSense and Parabola both supported the MIPS architecture on some level, and Guix still does, I think, although since the Lemote stuff supported mips64el, any remaining support in these distributions is not useful for 32-bit devices, amongst which is the Ingenic SoC that you were looking at. Of course, Debian supports everything of interest, but then there has to be a process of weeding out non-free packages and content. Since your EOMA68 campaign, PureOS has become a candidate for a suitable Debian-based FSF- endorsed distribution (ignoring systemd concerns). If Trisquel hadn't switched to Ubuntu as its base, it would also have been a candidate, but instead it suffers from Ubuntu's arbitrary architecture selection policy. > basically it's a hell of a lot easier if you have a native x86 > parabola install, as you can then use the equivalent of debian foriegn > arch debootstrap, and the --second-stage you run a qemu emulator to > finish off the install. > > that's basically exactly what i did... except because i didn't have > native x86 parabola i ran in qemu. > > it worked really well and makes for a hilarious story. I guess you are able to rely on the existing ARM port of Arch, though. What I found was that for building packages from scratch you have to combine Parabola and Arch repositories, and the mechanisms for doing this are not very coherent. I ended up having to write tools to look up packages in different packaging repositories, first trying one place, then another, and so on. Some of these tools I ran in an appropriate x86 Parabola installation because they won't work in a "portable" way in other environments. What I learned is that there is a considerable difference between genuine multi-architecture distributions and the kind of architecture-and-a-half distribution that Arch seems to be, with Parabola being under that umbrella. I think Arch has already thrown i386 over the side, so I wonder whether Parabola will also have to do so in time as well. Generally, I think that the Arch maintainers make some pretty questionable decisions: switching the default version of Python to version 3 very early on in the 3.x lifespan being one notable example. But having the choice is good for people who can get along with such decisions, I guess. Paul P.S. It is also pretty frustrating that people seem to need Richard Stallman to tell them what to do. When I asked people supposedly interested in porting the Hurd to L4-based systems about such matters, one of the responses indicated that Stallman didn't think that working on operating system fundamentals was worthwhile compared to doing other things. But if something is worth doing, even if not everyone agrees, why does anyone need some kind of "sign off" from someone they've heard of? Just do what you think is right or interesting or enjoyable or useful, already! I honestly don't know why anyone would follow a mailing list on a topic if they didn't already know it was worthwhile. From lkcl at lkcl.net Wed Dec 5 20:58:55 2018 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Wed, 5 Dec 2018 20:58:55 +0000 Subject: [Arm-netbook] What do 1,000 EOMA68-A20 PCBs look like? In-Reply-To: <2316671.UOBgKsZiV5@jeremy> References: <3518671.gX2FLSBOfK@jeremy> <2316671.UOBgKsZiV5@jeremy> Message-ID: On Wed, Dec 5, 2018 at 4:41 PM Paul Boddie wrote: > But if something is worth doing, even if not everyone agrees, why does anyone > need some kind of "sign off" from someone they've heard of? Just do what you > think is right or interesting or enjoyable or useful, already! I honestly > don't know why anyone would follow a mailing list on a topic if they didn't > already know it was worthwhile. interesting insights that you raise, paul (all of them), this one caught my attention in particular. occasionally i encounter people who follow some logical conclusion that i, personally, have reached... *without* themselves having reviewed the facts / data and associated logic. this completely freaks me out. the second part is: i think that people know / feel that without "sign-off", the person (e.g. dr stallman) acting as a diplomatic gateway / channel to other resources and other people will not put them in touch with other people / resources if that person doesn't believe the proposal is workable. given that large projects succeed based on collaboration, the high-profile person, who will have a lot more experience than them, becomes not just a "reviewer" of the proposal, but a channel and potential advocate as well. put another way: if someone's not strongly convinced of the value of their idea, they're not going to stand up and make it happen when faced with someone who says "no", are they? :) l. From valhalla-l at trueelena.org Thu Dec 6 08:58:51 2018 From: valhalla-l at trueelena.org (Elena ``of Valhalla'') Date: Thu, 6 Dec 2018 09:58:51 +0100 Subject: [Arm-netbook] What do 1,000 EOMA68-A20 PCBs look like? In-Reply-To: <2316671.UOBgKsZiV5@jeremy> References: <3518671.gX2FLSBOfK@jeremy> <2316671.UOBgKsZiV5@jeremy> Message-ID: <20181206085850.ttjuydldgf2lx4yc@manillaroad.local.home.trueelena.org> On 2018-12-05 at 17:40:29 +0100, Paul Boddie wrote: > Of course, Debian supports everything of interest, but then there has to be a > process of weeding out non-free packages and content. Note that this "process" simply involves not adding the 'non-free' repository to /etc/apt/sources.list. It's not silently added by default, the user/admin needs to make an explicit choice to add it. -- Elena ``of Valhalla'' From paul at boddie.org.uk Thu Dec 6 16:57:24 2018 From: paul at boddie.org.uk (Paul Boddie) Date: Thu, 06 Dec 2018 17:57:24 +0100 Subject: [Arm-netbook] What do 1,000 EOMA68-A20 PCBs look like? In-Reply-To: <20181206085850.ttjuydldgf2lx4yc@manillaroad.local.home.trueelena.org> References: <3518671.gX2FLSBOfK@jeremy> <2316671.UOBgKsZiV5@jeremy> <20181206085850.ttjuydldgf2lx4yc@manillaroad.local.home.trueelena.org> Message-ID: <1650151.vv4WxCpgx3@jeremy> On Thursday 6. December 2018 09.58.51 Elena ``of Valhalla'' wrote: > On 2018-12-05 at 17:40:29 +0100, Paul Boddie wrote: > > Of course, Debian supports everything of interest, but then there has to > > be a process of weeding out non-free packages and content. > > Note that this "process" simply involves not adding the 'non-free' > repository to /etc/apt/sources.list. It's not silently added by default, > the user/admin needs to make an explicit choice to add it. Sorry, I meant in the context of being free enough for FSF endorsement. Otherwise, there would be no need for distributions like PureOS, gNewSense, and so on. Discussion can be had about the FSF criteria, of course, but since Luke is actually seeking such endorsement, the only thing that might be helpful for him is to indicate to him that various FSF concerns are now addressed in the more mainstream distributions, such as there not being random firmware binaries in kernel packages, and so on. Since I don't track what Debian's policy on such things is, bringing any new developments to his attention could be useful and save him a lot of time and effort. I tend to be wary about making any statements about Debian policy these days since it tends to get me flamed by random people. Paul From lkcl at lkcl.net Thu Dec 6 18:39:34 2018 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Thu, 6 Dec 2018 18:39:34 +0000 Subject: [Arm-netbook] What do 1,000 EOMA68-A20 PCBs look like? In-Reply-To: <1650151.vv4WxCpgx3@jeremy> References: <3518671.gX2FLSBOfK@jeremy> <2316671.UOBgKsZiV5@jeremy> <20181206085850.ttjuydldgf2lx4yc@manillaroad.local.home.trueelena.org> <1650151.vv4WxCpgx3@jeremy> Message-ID: On Thu, Dec 6, 2018 at 4:58 PM Paul Boddie wrote: > Discussion can be had about the FSF criteria, of course, but since Luke is > actually seeking such endorsement, the only thing that might be helpful for > him is to indicate to him that various FSF concerns are now addressed in the > more mainstream distributions, such as there not being random firmware > binaries in kernel packages, and so on. the RYF Criteria are extremely specific: it's not enough to have a non-free section that's "disabled", it must be *not possible* for an average end-user to *accidentally* end up installing non-free software by complete accident such as "running a GUI and arbitrarily clicking random buttons". the absolute worst-case is where an inexperienced end-user, running e.g. synaptics, goes "i have no idea what this does, i'm just gonna click it" and it happens to enable the "non-free" section, happens to silently and happily perform an apt-get update, and wow, suddenly there's binary firmware available... all WITHOUT warning the user of the consequences. the "convenience" scripts that download mstruetypefonts. the "convenience" script that gets the latest adobe flash player. the broadcom wifi firmware extractor scripts my feeling is, here, that if aptitude, apt, synaptics and other apt front-ends added a simple warning dialog "hello you are adding the non-free section, this can have severe consequences as the source is not available for review", that would quite likely eliminate one of the FSF's major concerns. l. From onpon4 at riseup.net Fri Dec 7 02:38:43 2018 From: onpon4 at riseup.net (Julie Marchant) Date: Thu, 6 Dec 2018 21:38:43 -0500 Subject: [Arm-netbook] What do 1,000 EOMA68-A20 PCBs look like? In-Reply-To: References: <3518671.gX2FLSBOfK@jeremy> <2316671.UOBgKsZiV5@jeremy> <20181206085850.ttjuydldgf2lx4yc@manillaroad.local.home.trueelena.org> <1650151.vv4WxCpgx3@jeremy> Message-ID: <92ac3429-0f0b-b78e-d6d4-bf2fa83a8bb1@riseup.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 12/06/2018 01:39 PM, Luke Kenneth Casson Leighton wrote: > On Thu, Dec 6, 2018 at 4:58 PM Paul Boddie > wrote: > >> Discussion can be had about the FSF criteria, of course, but >> since Luke is actually seeking such endorsement, the only thing >> that might be helpful for him is to indicate to him that various >> FSF concerns are now addressed in the more mainstream >> distributions, such as there not being random firmware binaries >> in kernel packages, and so on. > > the RYF Criteria are extremely specific: it's not enough to have a > non-free section that's "disabled", it must be *not possible* for > an average end-user to *accidentally* end up installing non-free > software by complete accident such as "running a GUI and > arbitrarily clicking random buttons". > > the absolute worst-case is where an inexperienced end-user, > running e.g. synaptics, goes "i have no idea what this does, i'm > just gonna click it" and it happens to enable the "non-free" > section, happens to silently and happily perform an apt-get update, > and wow, suddenly there's binary firmware available... all WITHOUT > warning the user of the consequences. > > the "convenience" scripts that download mstruetypefonts. > > the "convenience" script that gets the latest adobe flash player. > > the broadcom wifi firmware extractor scripts > > my feeling is, here, that if aptitude, apt, synaptics and other apt > front-ends added a simple warning dialog "hello you are adding the > non-free section, this can have severe consequences as the source > is not available for review", that would quite likely eliminate one > of the FSF's major concerns. Just a note, the only way to add the non-free section in Debian involves typing the word "non-free" into a particular spot on a text file, or if using the GUI interface, to edit the entry for the Debian repo to type "non-free" into the "Components" textbox in the "Edit Source" dialog box. So it's not really possible to accidentally enable the non-free repository. I honestly tend to disagree with the FSF's classification of Debian for this reason. That being said, it's the FSF's rules, so Parabola is the only real option regardless of what one might think of the FSF's classification. And as for 32-bit MIPS... just outta luck, I guess, at least until an FSF-approved distro starts supporting it. - -- Julie Marchant http://onpon4.github.io Encrypt your emails with GnuPG: https://emailselfdefense.fsf.org -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJcCd0yAAoJEObQhGZrE45FGdEQAJEz6C4zJVQxpw/6Vukf/4mX hudsDdjEeublmAyzDhXbbWa5esalcsU1N78jK3Jcf+7J9wXsn1f41XQY39mAQFCq 9h+uWxm3kKON6c3Of/MQvKUSwB9T68Kno8QGbshlPMfRJvlxACu9vNxs83x2wm1U Z+JJ0UFpOKMg0qLZJkMzw+6ewT8sNqShuiv3dltBfweAILACcqJXbIP95wgCpXWX E0sDa+2LJqVzu/YKtLEPK3agDrJzb/Kwlc4MMo0+7xZSp8FHUqE0Qkg4KCjg/Vv1 B2lkdDvj/uVQKZEWcSQ2JXoUvBpho5CnOeqFJQpoIEuL/TFX1WNlN1XE0iNJMubC keydF+8tDnc7rUhXwtuDLBQRlkrxLOZx8pqd1onY/vcuz6pjYmOtT4GfyQzOhIVd m8ArLzLwgfu2ycyMHoNo97MyOUCzIbX/Ru1BESeG0ey5hY0VBxqMpUgJ7ZK9yVFW gioJe446M6hZD7Owxz3CDQHNEUOFC39sbosPfjixk1muvGF2aICllHShggmBeZUa m0TLJHK6ucPIfon7MfL3KUijJlKZqaV/0meVtMqhfnsR4PSkiqSm3ceBN5EdZ20T HGlHamFLLsR+34cY3a7qcEaG6CFz8zIDON7aPO9SCPq0h9gQHCMWDc+X7acpI2EC IhcEnoihFruV9z8l58eF =tAm/ -----END PGP SIGNATURE----- From laserhawk64 at gmail.com Fri Dec 7 04:22:33 2018 From: laserhawk64 at gmail.com (Christopher Havel) Date: Thu, 6 Dec 2018 23:22:33 -0500 Subject: [Arm-netbook] Questioning The Holy War Message-ID: Okay. Forgive me, Luke, for inciting what will inevitably be a stake-burning that will be of such grand proportion as to be visible in space... ...but... ...I have to admit that I just don't "get it". When I write, I save my documents in Word 97-2003 *.doc format. Sometimes I even make a PDF copy. When I listen to music, it's inevitably an MP3. When I go shopping, I like to sit in the Subway at the local Walmart and mooch off the wifi- to the point that, specifically because it has no wifi, I won't go to the Wendy's across the parking lot even though I like their food better. And not having access to Flash is always an annoyance when it occurs. Even my phone is a Samsung Galaxy S7 - not exactly flying the flag of happy freedom-ness. All the stuff I do and rely on daily in my computer is closed-source. I prefer Linux as an operating system primarily because (a) it is a standalone setup which does not require third-party applications for ordinary daily operation, the way Windows does, (b) it's incredibly modular, (c) it doesn't think I'm stupid (much), and (d) I can't beat the price. In using both Linux and Windows (and, to a somewhat lesser extent, DOS and whatever's in a Commodore 64) over the roughly two-and-a-half decades of my life in which I've had my own computer, the only applications I've ever had that actually shot the cat (metaphorically) were applications designed for that purpose, i.e. malware - and in all instances, that was on Windows. (There is one exception that was me being a dummy and turning off a vital system component and then rebooting, the result of which was an unavoidable reinstall -- but that was quite early on and something far more along the lines of a moderately entertaining learning experience than anything else.) ...and that's kind of where I usually draw the line. If a guven application doesn't 'shoot the cat' -- cause obvious system instability or exhibit other overtly malicious activity during use -- and it performs the task(s) it was designed for, it seems to me it ought to be considered just fine, at least for the most part. Yet, almost every message on this list seems to carry with it the implication -- if not express statement -- that if a given application can't be openly audited on a remarkably low level by a random layperson at a random time and place -- leaving alone the fact that most ordinary individuals severely lack the knowledge and education required for that task -- it must therefore be evil and untrustworthy and oh god we can't have any of that sort of thing around here, shoo shoo... Maybe I'm just too ordinary (although that's one thing I've never been accused of!) but I just don't understand. If a program demonstrably does its job, keeps its pants up, and doesn't 'shoot the cat', at least in everyday use, it's got to be, at worst -- as Douglas Adams would say -- "mostly harmless "... right...? From cand at gmx.com Fri Dec 7 07:31:02 2018 From: cand at gmx.com (Lauri Kasanen) Date: Fri, 7 Dec 2018 09:31:02 +0200 Subject: [Arm-netbook] Questioning The Holy War In-Reply-To: References: Message-ID: <20181207093102.e944c028c68ba2039d24cb3e@gmx.com> Hi, There's lots of ways for your current uses to "shoot the cat"; perhaps you've been lucky so far. Or perhaps you accept what they do behind the scenes. First, MS Office. They deliberately add incompatibilities, forcing you to upgrade (ie. pay them again) so you can open that Word 20xx file from your client/employer/tax man/whatever. Nowadays they're moving to a subscription model, so you'll have to pay monthly to be able to edit and view documents. Having Flash installed may lead to compromising your bank details, your system, or any other data you care for. Your phone will likely stop getting updates, or it will get an update making it slower that you cannot remove. All cases leading to planned obsolescence -> buy a new phone. The OS and apps you run spy on you, selling all data they can gather to the highest bidder. If you're lucky, this only results in more ads for you. We have plenty of examples of closed software being malicious, but not in an overt way. Perhaps they call home. Perhaps they spy on your activities, to make sure you're not trying to cheat or do anything they won't approve of. Perhaps that so chic note-taking app is trying to steal your bank credentials in the background. If you haven't yet been bitten by anything, you won't be as careful or think of what might happen. Had you had a book of yours removed off your Kindle, your Steam account blocked because you had a debugger installed, your battle.net account blocked because you ran a game in Wine, an important piece of software stop working and demand an upgrade, or numerous other examples of closed sw being not-so-friendly... All this is just the negative aspects too. How will you fix a bug or add a feature to closed sw? What if the company making it has gone bankrupt, and you cannot even get them to do so? - Lauri From lkcl at lkcl.net Fri Dec 7 08:49:57 2018 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Fri, 7 Dec 2018 08:49:57 +0000 Subject: [Arm-netbook] What do 1,000 EOMA68-A20 PCBs look like? In-Reply-To: <92ac3429-0f0b-b78e-d6d4-bf2fa83a8bb1@riseup.net> References: <3518671.gX2FLSBOfK@jeremy> <2316671.UOBgKsZiV5@jeremy> <20181206085850.ttjuydldgf2lx4yc@manillaroad.local.home.trueelena.org> <1650151.vv4WxCpgx3@jeremy> <92ac3429-0f0b-b78e-d6d4-bf2fa83a8bb1@riseup.net> Message-ID: On Fri, Dec 7, 2018 at 2:39 AM Julie Marchant wrote: > And as for 32-bit MIPS... just outta luck, I guess, at least until an > FSF-approved distro starts supporting it. all 32-bit OSes are on the ropes, but not for the reason that most people think. it's down to the linker phase of binutils *running out of memory*, due to a default option to keep the object files and the binary being linked in memory: https://marc.info/?l=binutils-bugs&m=153030202426968&w=2 https://sourceware.org/bugzilla/show_bug.cgi?id=22831 unfortunately this is quotes not anyone's responsibility quotes, it's one of those little-known syndrome / underlying / indirect causes. please please for goodness sake could people spread awareness about this more widely, try out some very large builds including comprehensive debug build options, adding the option advised in that bugreport, and report back on the bugreport if it was successful or not. *without* that option, the fact that firefox now needs SEVEN GIGABYTES of resident RAM in order to complete the linker phase (which is obviously impossible on a 32-bit processor), armhf, mips32, and many other 32-bit architectures are just going to get... dropped by distros... *for no good reason*. l. From pablo at parobalth.org Fri Dec 7 11:02:12 2018 From: pablo at parobalth.org (Pablo Rath) Date: Fri, 7 Dec 2018 12:02:12 +0100 Subject: [Arm-netbook] What do 1,000 EOMA68-A20 PCBs look like? In-Reply-To: <92ac3429-0f0b-b78e-d6d4-bf2fa83a8bb1@riseup.net> References: <3518671.gX2FLSBOfK@jeremy> <2316671.UOBgKsZiV5@jeremy> <20181206085850.ttjuydldgf2lx4yc@manillaroad.local.home.trueelena.org> <1650151.vv4WxCpgx3@jeremy> <92ac3429-0f0b-b78e-d6d4-bf2fa83a8bb1@riseup.net> Message-ID: <20181207110212.gckwve44oic4cyxq@cherry> On Thu, Dec 06, 2018 at 09:38:43PM -0500, Julie Marchant wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > >> On 12/06/2018 01:39 PM, Luke Kenneth Casson Leighton wrote: > > the RYF Criteria are extremely specific: it's not enough to have a > > non-free section that's "disabled", it must be *not possible* for > > an average end-user to *accidentally* end up installing non-free > > software by complete accident such as "running a GUI and > > arbitrarily clicking random buttons". > > > > the absolute worst-case is where an inexperienced end-user, > > running e.g. synaptics, goes "i have no idea what this does, i'm > > just gonna click it" and it happens to enable the "non-free" > > section, happens to silently and happily perform an apt-get update, > > and wow, suddenly there's binary firmware available... all WITHOUT > > warning the user of the consequences. > > [...] > > Just a note, the only way to add the non-free section in Debian > involves typing the word "non-free" into a particular spot on a text > file, or if using the GUI interface, to edit the entry for the Debian > repo to type "non-free" into the "Components" textbox in the "Edit > Source" dialog box. So it's not really possible to accidentally enable > the non-free repository. I honestly tend to disagree with the FSF's > classification of Debian for this reason. I have just checked synaptics on my Debian stable Laptop with only main repos enabled and could not find a button to enable non-free with just one (or a few) clicks. But according to the points here: https://www.gnu.org/distros/common-distros.en.html there are other concerns besides "number of clicks" and "accidents of Joe Average Enduser". So in the foreseeable future FSF endorsement of Debian is unlikely. Has anyone on this list attended: https://www.fsf.org/events/molly-deblanc-john-sullivan-20180803-hsinchucity-debconf The user group of the first (crowd supply) computer cards will split into subgroups running the distributions mentioned in the campaign rewards (Debian, Devuan, Parabola, Fedora). Some will try to stay as close to the vanilla state of a fresh install. Some will use a state working with linux-sunxi-kernel (as previously discussed on this list). I think we can expect a lot of diversity. I am going to be in the Debian group. > > That being said, it's the FSF's rules, so Parabola is the only real > option regardless of what one might think of the FSF's classification. I agree. kind regards Pablo From pelzflorian at pelzflorian.de Fri Dec 7 11:11:45 2018 From: pelzflorian at pelzflorian.de (pelzflorian (Florian Pelz)) Date: Fri, 7 Dec 2018 12:11:45 +0100 Subject: [Arm-netbook] Questioning The Holy War In-Reply-To: References: Message-ID: <20181207111145.ti35yuxdwpwlb4zd@pelzflorian.localdomain> On Thu, Dec 06, 2018 at 11:22:33PM -0500, Christopher Havel wrote: > Yet, almost every message on this list seems to carry with it the > implication -- if not express statement -- that if a given application > can't be openly audited on a remarkably low level by a random layperson at > a random time and place -- leaving alone the fact that most ordinary > individuals severely lack the knowledge and education required for that > task -- it must therefore be evil and untrustworthy and oh god we can't > have any of that sort of thing around here, shoo shoo... > There are many independent developers laypeople can pay to port, inspect and change free software. Regards, Florian From pablo at parobalth.org Fri Dec 7 11:59:44 2018 From: pablo at parobalth.org (Pablo Rath) Date: Fri, 7 Dec 2018 12:59:44 +0100 Subject: [Arm-netbook] Questioning The Holy War In-Reply-To: References: Message-ID: <20181207113442.3mwssajwmoep7fsw@cherry> On Thu, Dec 06, 2018 at 11:22:33PM -0500, Christopher Havel wrote: > Okay. Forgive me, Luke, for inciting what will inevitably be a > stake-burning that will be of such grand proportion as to be visible in > space... > > ...but... > > ...I have to admit that I just don't "get it". Let us try to stay civil :) > > And not having access to Flash is always an annoyance when it > occurs. Isn't flash already dead? I am quite happy that it gets less and less relevant each day as it appeared to be such a pain in the neck and caused a lot of troubles when switching to Linux years ago. >Even my phone is a Samsung Galaxy S7 - not exactly flying the flag > of happy freedom-ness. > Altough I type this reply from a Libreboot T400 (RYF certified) running Debian stable with only the main repo enabled I also own and use a smartphone and a tablet running android. > ...and that's kind of where I usually draw the line. If a guven application > doesn't 'shoot the cat' -- cause obvious system instability or exhibit > other overtly malicious activity during use -- and it performs the task(s) > it was designed for, it seems to me it ought to be considered just fine, at > least for the most part. How do you know if the source is closed? :) There are many (valid) reasons to reject closed source software ranging from "because I can", "I am just curious", "scientific and research", "security", "bad past experience with closed source", "forced upgrades" and so on. I believe that the FLOSS-model is better but it is not the holy grail either. Apparently FLOSS has bugs, security holes and unexpected problems. Errors are a part of our human existence. The internet is full of discussions, essays, blogposts and free books on this topic so I think there is no need to repeat these sources. In the end you have to make this decision for yourself based on your knowledge and critical evalation of your sources. > Yet, almost every message on this list seems to carry with it the > implication -- if not express statement -- that if a given application > can't be openly audited on a remarkably low level by a random layperson at > a random time and place -- leaving alone the fact that most ordinary > individuals severely lack the knowledge and education required for that > task -- it must therefore be evil and untrustworthy and oh god we can't > have any of that sort of thing around here, shoo shoo... Well, this is a libre centered mailing list and in my opinion a quite friendly one. I have been burned by projects that were "open source" and turned out to require blobs. It can be so hard to find out if certain hardware will require blobs so I find the strict libre approach of eoma68 and this mailing list quite liberating. kind regards Pablo From monnier at iro.umontreal.ca Fri Dec 7 13:11:15 2018 From: monnier at iro.umontreal.ca (Stefan Monnier) Date: Fri, 07 Dec 2018 08:11:15 -0500 Subject: [Arm-netbook] What do 1,000 EOMA68-A20 PCBs look like? References: <3518671.gX2FLSBOfK@jeremy> <2316671.UOBgKsZiV5@jeremy> <20181206085850.ttjuydldgf2lx4yc@manillaroad.local.home.trueelena.org> <1650151.vv4WxCpgx3@jeremy> <92ac3429-0f0b-b78e-d6d4-bf2fa83a8bb1@riseup.net> Message-ID: > Just a note, the only way to add the non-free section in Debian > involves typing the word "non-free" into a particular spot on a text > file, or if using the GUI interface, to edit the entry for the Debian > repo to type "non-free" into the "Components" textbox in the "Edit > Source" dialog box. So it's not really possible to accidentally enable > the non-free repository. I honestly tend to disagree with the FSF's > classification of Debian for this reason. I'm not happy about the Debian<->FSF situation either, but note that if you want your Emacs install to include all the online doc with which it should normally be accompanied, you have to add the `emacs-common-non-dfsg` package from the `non-free` section. So, the FSF ends up wanting to encourage Debian users to add the `non-free` section to access the docs of several important GNU packages. There's also the fact that the wiki.debian.org includes several places where they encourage users to install `non-free` packages. I wish the two associations could take a more pragmatic look at the situation to resolve these disagreements. Stefan From monnier at iro.umontreal.ca Fri Dec 7 13:19:50 2018 From: monnier at iro.umontreal.ca (Stefan Monnier) Date: Fri, 07 Dec 2018 08:19:50 -0500 Subject: [Arm-netbook] Questioning The Holy War References: Message-ID: > Yet, almost every message on this list seems to carry with it the > implication -- if not express statement -- that if a given application > can't be openly audited on a remarkably low level by a random > layperson at a random time and place -- ... -- it must therefore be > evil and untrustworthy If a president refuses to show his tax records, I consider it as evidence that I can't trust him/her. Same goes for software. Stefan From lkcl at lkcl.net Fri Dec 7 13:24:26 2018 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Fri, 7 Dec 2018 13:24:26 +0000 Subject: [Arm-netbook] What do 1,000 EOMA68-A20 PCBs look like? In-Reply-To: References: <3518671.gX2FLSBOfK@jeremy> <2316671.UOBgKsZiV5@jeremy> <20181206085850.ttjuydldgf2lx4yc@manillaroad.local.home.trueelena.org> <1650151.vv4WxCpgx3@jeremy> <92ac3429-0f0b-b78e-d6d4-bf2fa83a8bb1@riseup.net> Message-ID: On Fri, Dec 7, 2018 at 1:11 PM Stefan Monnier wrote: > There's also the fact that the wiki.debian.org includes several places > where they encourage users to install `non-free` packages. ohh. yeah. that won't help :) that would be viewed as "endorsement of the installation of non-free software", for sure. > I wish the two associations could take a more pragmatic look at the > situation to resolve these disagreements. well, one simple practical way would be to follow the trick deployed by devuan. what they did is extremely nifty: they created a proxy apt service that, for the most part, is just a "pass-through" to the standard debian mirrors. one of the issues associated normally with maintaining a debian-augmented distro is: it takes considerably deep pockets to maintain a 160GB+ debian mirror. a pass-through proxy that pre-vetted the repos, filtering out the entirety of the non-free section, would actively prevent and prohibit unintentional mistaken installations of non-free software by end-users blindly following online documentation, "authoritative" wiki pages and so on. ultimately, their nightmare scenario is where *uninformed* end-users en-masse end up installing proprietary software *without* being aware of the consequences. they genuinely don't care about the *intelligent* end-users that make informed decisions and smash through all and any barriers to bypass all and any limitations and restrictions placed in their path to get at the non-free firmware [or whatever]. l. From lkcl at lkcl.net Fri Dec 7 13:25:31 2018 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Fri, 7 Dec 2018 13:25:31 +0000 Subject: [Arm-netbook] Questioning The Holy War In-Reply-To: References: Message-ID: On Fri, Dec 7, 2018 at 1:20 PM Stefan Monnier wrote: > If a president refuses to show his tax records, I consider it as > evidence that I can't trust him/her. and yet... people still vote for them... :) From paul at boddie.org.uk Fri Dec 7 14:24:41 2018 From: paul at boddie.org.uk (Paul Boddie) Date: Fri, 07 Dec 2018 15:24:41 +0100 Subject: [Arm-netbook] What do 1,000 EOMA68-A20 PCBs look like? In-Reply-To: References: <3518671.gX2FLSBOfK@jeremy> <92ac3429-0f0b-b78e-d6d4-bf2fa83a8bb1@riseup.net> Message-ID: <2229941.IZRfILL806@jeremy> On Friday 7. December 2018 08.49.57 Luke Kenneth Casson Leighton wrote: > On Fri, Dec 7, 2018 at 2:39 AM Julie Marchant wrote: > > And as for 32-bit MIPS... just outta luck, I guess, at least until an > > FSF-approved distro starts supporting it. >From what people have said about Debian, I can envisage getting PureOS to work on mipsel. It is just that I haven't dedicated any time to really looking into it yet. > all 32-bit OSes are on the ropes, but not for the reason that most > people think. it's down to the linker phase of binutils *running out > of memory*, due to a default option to keep the object files and the > binary being linked in memory: > > https://marc.info/?l=binutils-bugs&m=153030202426968&w=2 > https://sourceware.org/bugzilla/show_bug.cgi?id=22831 > > unfortunately this is quotes not anyone's responsibility quotes, it's > one of those little-known syndrome / underlying / indirect causes. It is a consequence of people not really valuing the longevity of hardware. A decade or so ago, people still cared about whether GNU/Linux worked on old hardware: it was even a selling point. Now people are probably prioritising the corporate space where you can just request a new laptop with double the memory from your manager and pretend that it was a cheap way of solving the problem. > please please for goodness sake could people spread awareness about > this more widely, try out some very large builds including > comprehensive debug build options, adding the option advised in that > bugreport, and report back on the bugreport if it was successful or > not. It's interesting to search for the suggested linker options... -Wl,--no-keep-memory ...to see where they also came up: https://bugzilla.redhat.com/show_bug.cgi?id=117868 I like the way the reporter gets an internal compiler error. These things, including linker assertion errors which the user shouldn't see, don't seem to get adequately diagnosed or remedied in my experience: you just get told that "you're holding it wrong" and WONTFIX. Still, since 2004 there should be some test cases by now. ;-) I see that you have been working hard to persuade people, though: https://bugzilla.redhat.com/show_bug.cgi?id=117868 It really sounds like a classic database problem, and I wonder what the dataset size is. Of course data processing is faster if you can shove everything into memory, but the trick is to manage volumes that are larger than memory. Cross-building would be a workaround, but Debian appears fundamentally opposed to that, even though the alternative is the abandonment of architectures. And you even have the new and shiny arm64 support in jeopardy because the appropriate server hardware never seems to get to market (or stick around). > *without* that option, the fact that firefox now needs SEVEN > GIGABYTES of resident RAM in order to complete the linker phase (which > is obviously impossible on a 32-bit processor), armhf, mips32, and > many other 32-bit architectures are just going to get... dropped by > distros... > > *for no good reason*. Well, it sounds like the usual practice of greasing up a hippo and hoping that the result will be as lean and as fast as a cheetah. The Web gets ever more complicated and yet many of the tasks we need it for remain the same. Still, the usual advocates of disposable computing would have us continually upgrade to keep being able to do even the simplest things, finding a way of selling us what we already have, as always. Paul From lkcl at lkcl.net Fri Dec 7 15:36:33 2018 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Fri, 7 Dec 2018 15:36:33 +0000 Subject: [Arm-netbook] What do 1,000 EOMA68-A20 PCBs look like? In-Reply-To: <2229941.IZRfILL806@jeremy> References: <3518671.gX2FLSBOfK@jeremy> <92ac3429-0f0b-b78e-d6d4-bf2fa83a8bb1@riseup.net> <2229941.IZRfILL806@jeremy> Message-ID: On Fri, Dec 7, 2018 at 2:25 PM Paul Boddie wrote: > I like the way the reporter gets an internal compiler error. These things, > including linker assertion errors which the user shouldn't see, don't seem to > get adequately diagnosed or remedied in my experience: you just get told that > "you're holding it wrong" and WONTFIX. Still, since 2004 there should be some > test cases by now. ;-) you know how lobsters will sit in a pot that's boiling because the temperature differential is not big enough? well... it's like that. unfortunately, over the past decade+, nobody predicted that the linker phase would go *anywhere near* 4GB in size. that would be INSANE!! so of *course* they ripped out all of the historic archaic techniques that dealt efficiently with linking when there's less memory than can be addressed even by adding Virtual Memory. regarding cross-compiling: if you've seen how openembedded uses bitbake to do cross-compiling (which includes setting an automatic qemu redirect of autoconf script running and even qemu-emulated gcc running), you start to get a deep appreciation for the dangers of cross-compiling. the key one is, you have absolutely no idea if the host correctly generated the autoconf settings correctly or not. even running under qemu is not accepted, because of the risks of qemu giving the wrong information when compared to native hardware. L. From wookey at wookware.org Fri Dec 7 16:28:24 2018 From: wookey at wookware.org (Wookey) Date: Fri, 7 Dec 2018 16:28:24 +0000 Subject: [Arm-netbook] What do 1,000 EOMA68-A20 PCBs look like? In-Reply-To: <2229941.IZRfILL806@jeremy> References: <3518671.gX2FLSBOfK@jeremy> <92ac3429-0f0b-b78e-d6d4-bf2fa83a8bb1@riseup.net> <2229941.IZRfILL806@jeremy> Message-ID: <20181207162823.jqdsstsudeezp3yj@mail.wookware.org> On 2018-12-07 15:24 +0100, Paul Boddie wrote: > Cross-building would be a workaround, but Debian appears fundamentally opposed > to that, Do you mean 'as buildds'? Debian's support from cross-building has improved hugely over the last 8 years, and you can now crossbuild a _lot_ of debian. Helmut told me 'nearly 2/3rds' a while ago, although I'm not sure if that's 2/3rds of _everything_, or some subset. There is lots more that could be done (not least educating upstreams that like to do 'uncrossable things'), but we are the opposite of 'fundamentally opposed to it'. > even though the alternative is the abandonment of architectures. And > you even have the new and shiny arm64 support in jeopardy because the > appropriate server hardware never seems to get to market (or stick around). In what way is arm64 'in jeopardy'? I don't think it's going anywhere. Wookey -- Principal hats: Linaro, Debian, Wookware, ARM http://wookware.org/ From paul at boddie.org.uk Fri Dec 7 17:28:55 2018 From: paul at boddie.org.uk (Paul Boddie) Date: Fri, 07 Dec 2018 18:28:55 +0100 Subject: [Arm-netbook] What do 1,000 EOMA68-A20 PCBs look like? In-Reply-To: <20181207162823.jqdsstsudeezp3yj@mail.wookware.org> References: <3518671.gX2FLSBOfK@jeremy> <2229941.IZRfILL806@jeremy> <20181207162823.jqdsstsudeezp3yj@mail.wookware.org> Message-ID: <5149014.3PO69m1aqu@jeremy> On Friday 7. December 2018 16.28.24 Wookey wrote: > On 2018-12-07 15:24 +0100, Paul Boddie wrote: > > Cross-building would be a workaround, but Debian appears fundamentally > > opposed to that, > > Do you mean 'as buildds'? I don't know. If that is the way the Debian archive is built then perhaps the answer is "yes". > Debian's support from cross-building has improved hugely over the last 8 > years, and you can now crossbuild a _lot_ of debian. Helmut told me 'nearly > 2/3rds' a while ago, although I'm not sure if that's 2/3rds of _everything_, > or some subset. It is certainly easier to perform cross-building activities, although I will admit that I am not typically cross-building packages these days. I've probably said before that when the cross-toolchains became available, it helped a great deal with the things I tend to do, so I really appreciate them. One thing that I do find frustrating, however, is the trail of pages on various sites (wikis, typically) that describe the state of progress at different points in time. It isn't particularly coherent and undermines the impression of the progress that has been made. > There is lots more that could be done (not least educating upstreams > that like to do 'uncrossable things'), but we are the opposite of > 'fundamentally opposed to it'. Perhaps I should have clarified that Debian appears fundamentally opposed to using cross-building as the means of building the archive for an architecture. I understand that the aim is to ensure that people can run systems that are able to build their own packages, but it seems that we will arrive at a point where the imperfect result of natively-built packages needing to be complemented by cross-built packages will become unavoidable. > > even though the alternative is the abandonment of architectures. And > > you even have the new and shiny arm64 support in jeopardy because the > > appropriate server hardware never seems to get to market (or stick > > around). > > In what way is arm64 'in jeopardy'? I don't think it's going anywhere. Maybe I got the wrong impression from this message: https://groups.google.com/d/msg/linux.debian.devel.release/meYaIZR7Sm0/GtHUxlbGAQAJ I guess that the main concerns are that some arm64 products aren't supporting arm32 (of whichever flavour), that there are lots of "development board" products but not so many "data centre" products, making automation and management difficult. I might also add that when looking at ARM server offerings, they seem to be pretty expensive (maybe to differentiate themselves from existing offerings on traditional server architectures), and it probably doesn't help that companies don't follow through on their roadmaps, meaning that people end up waiting forever for something that might have been a usable product. But maybe there is no shortage of usable arm64 hardware for archive-building purposes and that my perceptions of such shortages for other architectures are also incorrect, too. If so, I stand corrected. Paul From hendrik at topoi.pooq.com Fri Dec 7 21:52:22 2018 From: hendrik at topoi.pooq.com (Hendrik Boom) Date: Fri, 7 Dec 2018 16:52:22 -0500 Subject: [Arm-netbook] Questioning The Holy War In-Reply-To: <20181207113442.3mwssajwmoep7fsw@cherry> References: <20181207113442.3mwssajwmoep7fsw@cherry> Message-ID: <20181207215222.v5obxybjieidjvef@topoi.pooq.com> On Fri, Dec 07, 2018 at 12:59:44PM +0100, Pablo Rath wrote: > > How do you know if the source is closed? :) Let's assume this is a real question. If you try to get a copy of the source and are refused without signing a nondisclosure afgreement, there's good chance that it's closed. -- hendrik From rekado at elephly.net Fri Dec 7 22:42:21 2018 From: rekado at elephly.net (Ricardo Wurmus) Date: Fri, 07 Dec 2018 23:42:21 +0100 Subject: [Arm-netbook] What do 1,000 EOMA68-A20 PCBs look like? In-Reply-To: <92ac3429-0f0b-b78e-d6d4-bf2fa83a8bb1@riseup.net> References: <3518671.gX2FLSBOfK@jeremy> <2316671.UOBgKsZiV5@jeremy> <20181206085850.ttjuydldgf2lx4yc@manillaroad.local.home.trueelena.org> <1650151.vv4WxCpgx3@jeremy> <92ac3429-0f0b-b78e-d6d4-bf2fa83a8bb1@riseup.net> Message-ID: <87pnudez76.fsf@elephly.net> Julie Marchant writes: > That being said, it's the FSF's rules, so Parabola is the only real > option regardless of what one might think of the FSF's classification. The EOMA68-A20 is an armhf board, isn’t it? Since GuixSD is available for armhf, porting it to this board should not be too difficult. GuixSD is also one of the FSF-endorsed GNU+Linux distributions. [I don’t know if any Guix hackers have received an A20 board for porting (I don’t have one), and if they have I don’t know what the status is.] -- Ricardo From lkcl at lkcl.net Fri Dec 7 23:31:52 2018 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Fri, 7 Dec 2018 23:31:52 +0000 Subject: [Arm-netbook] What do 1,000 EOMA68-A20 PCBs look like? In-Reply-To: <87pnudez76.fsf@elephly.net> References: <3518671.gX2FLSBOfK@jeremy> <2316671.UOBgKsZiV5@jeremy> <20181206085850.ttjuydldgf2lx4yc@manillaroad.local.home.trueelena.org> <1650151.vv4WxCpgx3@jeremy> <92ac3429-0f0b-b78e-d6d4-bf2fa83a8bb1@riseup.net> <87pnudez76.fsf@elephly.net> Message-ID: On Fri, Dec 7, 2018 at 10:42 PM Ricardo Wurmus wrote: > [I don’t know if any Guix hackers have received an A20 board for porting i donated one to the key developers when i encountered them at fosdem 2017. l. From doark at mail.com Sat Dec 8 03:00:09 2018 From: doark at mail.com (David Niklas) Date: Fri, 7 Dec 2018 22:00:09 -0500 Subject: [Arm-netbook] Questioning The Holy War In-Reply-To: References: Message-ID: <20181207220009.6bfe1751@Phenom-II-x6.niklas.com> On Fri, 7 Dec 2018 13:25:31 +0000 Luke Kenneth Casson Leighton wrote: > On Fri, 07 Dec 2018 08:19:50 -0500 > Stefan Monnier wrote: > > > Yet, almost every message on this list seems to carry with it the > > > implication -- if not express statement -- that if a given > > > application can't be openly audited on a remarkably low level by a > > > random layperson at a random time and place -- ... -- it must > > > therefore be evil and untrustworthy. There are actually 3 arguments to favor this view point: 1. You learn by experience. Picture young children. They break things to learn how they work. No introspection means severely limited understanding. 2. If schools and libraries would *actually* teach programming, as opposed to MS-word Macros which enslave the person to a product (yes, here in the US), then there would be less people who would be incompetent when it comes to CS. The source being readily accessible lends itself to this goal. 3. "Many eyes make all bugs shallow." -- Linus Torvalds (Never said they were all geniuses or something.) > > If a president refuses to show his tax records, I consider it as > > evidence that I can't trust him/her. > > > > Same goes for software. > > > > and yet... people still vote for them... :) > And buy the software. "Who is the more foolish, the fool or the fool who [buys stuff from] [votes for] him?" -- Obi-wan Kenobi (Star Wars) purposefully misquoted. David From doark at mail.com Sat Dec 8 03:23:47 2018 From: doark at mail.com (David Niklas) Date: Fri, 7 Dec 2018 22:23:47 -0500 Subject: [Arm-netbook] What do 1,000 EOMA68-A20 PCBs look like? In-Reply-To: References: <3518671.gX2FLSBOfK@jeremy> <92ac3429-0f0b-b78e-d6d4-bf2fa83a8bb1@riseup.net> <2229941.IZRfILL806@jeremy> Message-ID: <20181207222347.6ebdc74a@Phenom-II-x6.niklas.com> On Fri, 7 Dec 2018 15:36:33 +0000 Luke Kenneth Casson Leighton wrote: > regarding cross-compiling: if you've seen how openembedded uses > bitbake to do cross-compiling (which includes setting an automatic > qemu redirect of autoconf script running and even qemu-emulated gcc > running), you start to get a deep appreciation for the dangers of > cross-compiling. > > the key one is, you have absolutely no idea if the host correctly > generated the autoconf settings correctly or not. even running under > qemu is not accepted, because of the risks of qemu giving the wrong > information when compared to native hardware. > > L. Yuk. You saved me a lot of time. I trusted qemu too! David From doark at mail.com Sat Dec 8 03:45:13 2018 From: doark at mail.com (David Niklas) Date: Fri, 7 Dec 2018 22:45:13 -0500 Subject: [Arm-netbook] Huge RAM requirements (was: What do 1, 000 EOMA68-A20 PCBs look like?) In-Reply-To: References: <3518671.gX2FLSBOfK@jeremy> <2316671.UOBgKsZiV5@jeremy> <20181206085850.ttjuydldgf2lx4yc@manillaroad.local.home.trueelena.org> <1650151.vv4WxCpgx3@jeremy> <92ac3429-0f0b-b78e-d6d4-bf2fa83a8bb1@riseup.net> Message-ID: <20181207224513.01f1df23@Phenom-II-x6.niklas.com> On Fri, 7 Dec 2018 08:49:57 +0000 Luke Kenneth Casson Leighton wrote: > On Fri, Dec 7, 2018 at 2:39 AM Julie Marchant wrote: > > > And as for 32-bit MIPS... just outta luck, I guess, at least until an > > FSF-approved distro starts supporting it. > > all 32-bit OSes are on the ropes, but not for the reason that most > people think. it's down to the linker phase of binutils *running out > of memory*, due to a default option to keep the object files and the > binary being linked in memory: > > https://marc.info/?l=binutils-bugs&m=153030202426968&w=2 > https://sourceware.org/bugzilla/show_bug.cgi?id=22831 > > unfortunately this is quotes not anyone's responsibility quotes, it's > one of those little-known syndrome / underlying / indirect causes. > > please please for goodness sake could people spread awareness about > this more widely, try out some very large builds including > comprehensive debug build options, adding the option advised in that > bugreport, and report back on the bugreport if it was successful or > not. > > *without* that option, the fact that firefox now needs SEVEN > GIGABYTES of resident RAM in order to complete the linker phase (which > is obviously impossible on a 32-bit processor), armhf, mips32, and > many other 32-bit architectures are just going to get... dropped by > distros... > > *for no good reason*. > > l. > HOLY COW! Luke, there has been no progress on this for ~6 months. I could test 2 systems of my own and comment on the bug report. It would not be soon, probably at least a week, but what's a week if you wait 6 months? I have an RK3399 board by firefly and an HP Stream Notebook with unupgreadable or replaceable RAM and disk. Perfect candidates for this test. I would preferably use Gentoo Linux, does it matter? However, luke, have you, or anyone else, tried to trigger this with llvm's gold linker? I've no idea how to enable the gold linker in projects, or if it's a "safe" thing to do. It was beta when last I looked. FYI: You should see what happens with gcc and graph-tool? ... # bug 453544 CHECKREQS_DISK_BUILD="6G" ... # most machines don't have enough ram for parallel builds python_foreach_impl run_in_build_dir emake -j1 ... Yes, that's right, 6GB for 1 gcc process! And I've seen gcc use 7GB! And that's not all, have a bunch of files to back up? Dar-2.5.17 (Disk ARchiver)(latest). Using bzip2 -9, NOT XZ -9! compression single threaded! RSS (part way through!) 14.8GB I have to talk to the dar devs. RAM is not cheap, what is this FLOSS world coming to? Sincerely, David From ericbavier at centurylink.net Sat Dec 8 04:25:22 2018 From: ericbavier at centurylink.net (Eric Bavier) Date: Fri, 7 Dec 2018 22:25:22 -0600 Subject: [Arm-netbook] What do 1,000 EOMA68-A20 PCBs look like? In-Reply-To: References: <3518671.gX2FLSBOfK@jeremy> <2316671.UOBgKsZiV5@jeremy> <20181206085850.ttjuydldgf2lx4yc@manillaroad.local.home.trueelena.org> <1650151.vv4WxCpgx3@jeremy> <92ac3429-0f0b-b78e-d6d4-bf2fa83a8bb1@riseup.net> Message-ID: <20181207222522.366088b9@centurylink.net> On Fri, 7 Dec 2018 08:49:57 +0000 Luke Kenneth Casson Leighton wrote: > On Fri, Dec 7, 2018 at 2:39 AM Julie Marchant wrote: > > > And as for 32-bit MIPS... just outta luck, I guess, at least until an > > FSF-approved distro starts supporting it. Until recently, GuixSD supported MIPS (specifically for yeelong laptops, iirc). I believe the support has unfortunately lapsed due to a lack of developer effort, but it could probably be resurected with some more attention. > > all 32-bit OSes are on the ropes, but not for the reason that most > people think. it's down to the linker phase of binutils *running out > of memory*, due to a default option to keep the object files and the > binary being linked in memory: > > https://marc.info/?l=binutils-bugs&m=153030202426968&w=2 > https://sourceware.org/bugzilla/show_bug.cgi?id=22831 > > unfortunately this is quotes not anyone's responsibility quotes, it's > one of those little-known syndrome / underlying / indirect causes. > > please please for goodness sake could people spread awareness about > this more widely, try out some very large builds including > comprehensive debug build options, adding the option advised in that > bugreport, and report back on the bugreport if it was successful or > not. I recently added this flag to Guix's qtwebkit build, and it seems to work well so far. https://git.savannah.gnu.org/cgit/guix.git/commit/?id=ebdb15bc3540b1901f223bc0689bae51a2f88fc4 Unfortunately, an possibly unrelated error is causing the build to fail for i686 and dependency failures are preventing the armhf builds from going through, currently: https://hydra.gnu.org/job/gnu/master/qtwebkit-5.212.0-alpha2.i686-linux https://hydra.gnu.org/job/gnu/master/qtwebkit-5.212.0-alpha2.armhf-linux While the Guix projects has a nice build farm to provide users with pre-built packages, I try to, when I can, make it less painful for folks to build their packages locally. > *without* that option, the fact that firefox now needs SEVEN > GIGABYTES of resident RAM in order to complete the linker phase (which > is obviously impossible on a 32-bit processor), armhf, mips32, and > many other 32-bit architectures are just going to get... dropped by > distros... > > *for no good reason*. I might do some exploration to see if this can fix some of Guix's current build failures for i686 and armhf. `~Eric From lkcl at lkcl.net Sat Dec 8 05:36:36 2018 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Sat, 8 Dec 2018 05:36:36 +0000 Subject: [Arm-netbook] Huge RAM requirements (was: What do 1, 000 EOMA68-A20 PCBs look like?) In-Reply-To: <20181207224513.01f1df23@Phenom-II-x6.niklas.com> References: <3518671.gX2FLSBOfK@jeremy> <2316671.UOBgKsZiV5@jeremy> <20181206085850.ttjuydldgf2lx4yc@manillaroad.local.home.trueelena.org> <1650151.vv4WxCpgx3@jeremy> <92ac3429-0f0b-b78e-d6d4-bf2fa83a8bb1@riseup.net> <20181207224513.01f1df23@Phenom-II-x6.niklas.com> Message-ID: --- crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68 On Sat, Dec 8, 2018 at 3:46 AM David Niklas wrote: > HOLY COW! > Luke, there has been no progress on this for ~6 months. I could test 2 > systems of my own and comment on the bug report. It would not be soon, > probably at least a week, but what's a week if you wait 6 months? > I have an RK3399 board by firefly and an HP Stream Notebook with > unupgreadable or replaceable RAM and disk. Perfect candidates for this > test. > I would preferably use Gentoo Linux, does it matter? not in the slightest. the more the better > However, luke, have you, or anyone else, tried to trigger this with llvm's > gold linker? no. > Yes, that's right, 6GB for 1 gcc process! And I've seen gcc use 7GB! gcc is fine as (ok this is what i was told 15 years ago) there's detection built-in to utilise available resident RAM, dynamically. > And that's not all, have a bunch of files to back up? > Dar-2.5.17 (Disk ARchiver)(latest). > Using bzip2 -9, NOT XZ -9! compression single threaded! > RSS (part way through!) > 14.8GB > I have to talk to the dar devs. > > RAM is not cheap, what is this FLOSS world coming to? the assumption is, you're on an x86 64-bit system, with 32-64GB of RAM and a 3200mbytes/sec NVMe SSD, so why should you care? l. From lkcl at lkcl.net Sat Dec 8 05:39:02 2018 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Sat, 8 Dec 2018 05:39:02 +0000 Subject: [Arm-netbook] What do 1,000 EOMA68-A20 PCBs look like? In-Reply-To: <20181207222347.6ebdc74a@Phenom-II-x6.niklas.com> References: <3518671.gX2FLSBOfK@jeremy> <92ac3429-0f0b-b78e-d6d4-bf2fa83a8bb1@riseup.net> <2229941.IZRfILL806@jeremy> <20181207222347.6ebdc74a@Phenom-II-x6.niklas.com> Message-ID: --- crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68 On Sat, Dec 8, 2018 at 3:46 AM David Niklas wrote: > > the key one is, you have absolutely no idea if the host correctly > > generated the autoconf settings correctly or not. even running under > > qemu is not accepted, because of the risks of qemu giving the wrong > > information when compared to native hardware. > > > > L. > > Yuk. You saved me a lot of time. I trusted qemu too! well... on the other hand... i heard archlinux and the parabola team use the technique all the time, for building officially-released packages. l. From cand at gmx.com Sat Dec 8 07:58:24 2018 From: cand at gmx.com (Lauri Kasanen) Date: Sat, 8 Dec 2018 09:58:24 +0200 Subject: [Arm-netbook] Huge RAM requirements (was: What do 1, 000 EOMA68-A20 PCBs look like?) In-Reply-To: References: <3518671.gX2FLSBOfK@jeremy> <2316671.UOBgKsZiV5@jeremy> <20181206085850.ttjuydldgf2lx4yc@manillaroad.local.home.trueelena.org> <1650151.vv4WxCpgx3@jeremy> <92ac3429-0f0b-b78e-d6d4-bf2fa83a8bb1@riseup.net> <20181207224513.01f1df23@Phenom-II-x6.niklas.com> Message-ID: <20181208095824.42d1fa87e7ebffa7560b5857@gmx.com> On Sat, 8 Dec 2018 05:36:36 +0000 Luke Kenneth Casson Leighton wrote: > > Yes, that's right, 6GB for 1 gcc process! And I've seen gcc use 7GB! > > gcc is fine as (ok this is what i was told 15 years ago) there's > detection built-in to utilise available resident RAM, dynamically. I've hit OOM with GCC 5 and 7, building Webkit with LTO (on 64-bit). - Lauri From lkcl at lkcl.net Sat Dec 8 11:33:02 2018 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Sat, 8 Dec 2018 11:33:02 +0000 Subject: [Arm-netbook] Huge RAM requirements (was: What do 1, 000 EOMA68-A20 PCBs look like?) In-Reply-To: <20181208095824.42d1fa87e7ebffa7560b5857@gmx.com> References: <3518671.gX2FLSBOfK@jeremy> <2316671.UOBgKsZiV5@jeremy> <20181206085850.ttjuydldgf2lx4yc@manillaroad.local.home.trueelena.org> <1650151.vv4WxCpgx3@jeremy> <92ac3429-0f0b-b78e-d6d4-bf2fa83a8bb1@riseup.net> <20181207224513.01f1df23@Phenom-II-x6.niklas.com> <20181208095824.42d1fa87e7ebffa7560b5857@gmx.com> Message-ID: On Sat, Dec 8, 2018 at 7:56 AM Lauri Kasanen wrote: > I've hit OOM with GCC 5 and 7, building Webkit with LTO (on 64-bit). hmmm that's new.... gcc 4 was fine. From pablo at parobalth.org Sat Dec 8 12:07:15 2018 From: pablo at parobalth.org (Pablo Rath) Date: Sat, 8 Dec 2018 13:07:15 +0100 Subject: [Arm-netbook] Questioning The Holy War In-Reply-To: <20181207215222.v5obxybjieidjvef@topoi.pooq.com> References: <20181207113442.3mwssajwmoep7fsw@cherry> <20181207215222.v5obxybjieidjvef@topoi.pooq.com> Message-ID: <20181208120715.o64rtojc5ynqdbwy@cherry> On Fri, Dec 07, 2018 at 04:52:22PM -0500, Hendrik Boom wrote: > On Fri, Dec 07, 2018 at 12:59:44PM +0100, Pablo Rath wrote: > > > > How do you know if the source is closed? :) > > Let's assume this is a real question. Hendrik, I am sorry. I see, I have phrased my (rhetoric) question poorly. What I meant and should have written is mor like: "How can you know if a software behaves well and doesn't shoot the cat when you can't audit the source code?" > If you try to get a copy of the source and are refused without signing > a nondisclosure afgreement, there's good chance that it's closed. Software should be distributed with a license and the source or with instructions where the source is publicly available. If a file or program lacks a license we have to assume it is proprietary. Of course asking helps in case of doubt. kind regards Pablo From chris at tylers.info Sat Dec 8 15:28:18 2018 From: chris at tylers.info (Chris Tyler) Date: Sat, 8 Dec 2018 10:28:18 -0500 Subject: [Arm-netbook] Questioning The Holy War In-Reply-To: <20181208120715.o64rtojc5ynqdbwy@cherry> References: <20181207113442.3mwssajwmoep7fsw@cherry> <20181207215222.v5obxybjieidjvef@topoi.pooq.com> <20181208120715.o64rtojc5ynqdbwy@cherry> Message-ID: On Sat, Dec 8, 2018 at 7:07 AM Pablo Rath wrote: > On Fri, Dec 07, 2018 at 04:52:22PM -0500, Hendrik Boom wrote: > > On Fri, Dec 07, 2018 at 12:59:44PM +0100, Pablo Rath wrote: > > > > > > How do you know if the source is closed? :) > > > > Let's assume this is a real question. > > Hendrik, I am sorry. I see, I have phrased my (rhetoric) question > poorly. What I meant and should have written is mor like: "How can you > know if a > software behaves well and doesn't shoot the cat when you can't audit the > source code?" > I must point out an error here: Ken Thompson proved that auditing source code (of software and the toolchain used to build it) is meaningless in his paper "Reflections on Trusting Trust". That paper/talk was released 34 years ago, and it wasn't theoretical -- it was based on malware that he'd successfully released into the wild many years before. (That said, I still prefer to be able to read the source -- just saying we shouldn't attribute disproven benefits to source reading!). -Chris From hendrik at topoi.pooq.com Sat Dec 8 16:19:43 2018 From: hendrik at topoi.pooq.com (Hendrik Boom) Date: Sat, 8 Dec 2018 11:19:43 -0500 Subject: [Arm-netbook] Questioning The Holy War In-Reply-To: References: <20181207113442.3mwssajwmoep7fsw@cherry> <20181207215222.v5obxybjieidjvef@topoi.pooq.com> <20181208120715.o64rtojc5ynqdbwy@cherry> Message-ID: <20181208161943.chbtbzwuidlh4or4@topoi.pooq.com> On Sat, Dec 08, 2018 at 10:28:18AM -0500, Chris Tyler wrote: > On Sat, Dec 8, 2018 at 7:07 AM Pablo Rath wrote: > > > On Fri, Dec 07, 2018 at 04:52:22PM -0500, Hendrik Boom wrote: > > > On Fri, Dec 07, 2018 at 12:59:44PM +0100, Pablo Rath wrote: > > > > > > > > How do you know if the source is closed? :) > > > > > > Let's assume this is a real question. > > > > Hendrik, I am sorry. I see, I have phrased my (rhetoric) question > > poorly. What I meant and should have written is mor like: "How can you > > know if a > > software behaves well and doesn't shoot the cat when you can't audit the > > source code?" > > > > I must point out an error here: Ken Thompson proved that auditing source > code (of software and the toolchain used to build it) is meaningless in his > paper "Reflections on Trusting Trust". That paper/talk was released 34 > years ago, and it wasn't theoretical -- it was based on malware that he'd > successfully released into the wild many years before. I remember reading that talk -- Wasn't it a Turing lecture? -- and I don't recall him saying he actually did release that malware -- he just explained what he *could* have done. But he didn't deny it either. Or do you have firther information on this? If so I'd like to hear it. Let me be pleased there is more than one C compiler in existence. And that it is undecidable whether an arbitrary piece of code actually compiles C, so that his malware, should it exist, is limited in scope. What I've heard on this topic is a mere rumour about the IBM Fortran H compiler -- that there was a bug in the optimisation of bitwise logic operations that was present in the object code but not in the source code. Apparently those bitwise logic operations were used in the optimiser, and there was, unfortunately, a fixed point other than the intended one. And I think we are getting close (but we're not there yet) to the general philosophical question whether we can actually know anything at all. -- hendrik > > (That said, I still prefer to be able to read the source -- just saying we > shouldn't attribute disproven benefits to source reading!). > > -Chris > _______________________________________________ > 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 GNUtoo at no-log.org Sat Dec 8 16:48:13 2018 From: GNUtoo at no-log.org (Denis 'GNUtoo' Carikli) Date: Sat, 8 Dec 2018 17:48:13 +0100 Subject: [Arm-netbook] What do 1,000 EOMA68-A20 PCBs look like? In-Reply-To: References: <3518671.gX2FLSBOfK@jeremy> Message-ID: <20181208120851.12b0ca86@primary_laptop.localdomain> On Wed, 5 Dec 2018 03:38:59 +0000 Luke Kenneth Casson Leighton wrote: > it was quite hilarious to get up and running. > https://wiki.parabola.nu/MIPS_Installation - oh. discontinued. > that's not going to help *sigh*. You also have an ARM installation guide[1], however in your case that's probably not the easiest way to deal with it. There is a way to use LXC to do a cross-pacstrap, however it's a bit tricky. If you don't have Parabola installed already, install it on your GNU/Linux distribution. It should be something like that (I didn't test that though): 1) First install and setup virt-manager 2) Create a disk image that you can mount externally: # cd /var/lib/libvirt/images/ # qemu-img create -f raw parabola.raw 1G 3) Run the installation with the install media 4) boot the installed rootfs and run # pacstrap /mnt 5) power off the vm and copy the /mnt outside of the vm, then setup a loop device # udisksctl loop-setup \ -f /var/lib/libvirt/images/parabola.raw 6) Copy the /mnt outside of the rootfs 7) Setup LXC through virt-manager to be able to use systemd 8) Install and setup the OpenSSH server inside the LXC system vm 9) Install the required packages: # pacman -S qemu-user-static-binfmt libretools Then trick is to: 1) export the /proc/sys/fs/binfmt_misc/ from the host to the /proc/sys/fs/binfmt_misc/ from the target in virt-manager. 2) run /usr/lib/systemd/systemd-binfmt by hand (I didn't manage to make the binfmt systemd service start) Once that is done you can then create a chroot for building packages[2]: $ sudo librechroot -A armv7h -n parabola-armv7h make # arch-chroot /var/lib/archbuild/parabola-armv7h Or you could create an installation rootfs: # mkdir parabola-armv7h # pacstrap -C /usr/share/pacman/defaults/pacman.conf.armv7h \ parabola-armv7h/ # arch-chroot /var/lib/archbuild/parabola-armv7h If you want to use a different kernel (like a deblobbed Allwinner Linux kernel) that is way older it would be best to: 1) Make a PKGBUILD for it. That can be integrated in Parabola very easily 2) libremakepkg is an abstraction on top of makepkg which enables you to build in a chroot, including chroot of different architectures. $ cd /path/to/directory/that/has/a/PKGBUILD $ sudo libremakepkg -n parabola-armv7h 3) You will need to use OpenRC if systemd doesn't support your old kernel version I've verified that with librechroot under a Parabola LXC under a Parabola host and I got: # file[...]/usr/bin/bash [...]/usr/bin/bash: ELF 32-bit LSB shared object, ARM, EABI5 version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux-armhf.so.3, for GNU/Linux 3.2.0, BuildID[sha1]=2ed90c858f8b750764b9ef6ebf6e23499640e3c9, stripped If you need serial console with OpenRC, I've written some documentation for it with another device in mind here: https://libreplanet.org/wiki/Group:Hardware/Freest/e-readers/Aura_H2O_Edition_2#Serial_console_with_OpenRC I hope that it's still useful, especially if you need to build things. Also note that I'm new to Parabola development, so there might be even easier ways that I don't know of yet. References: ----------- [1]https://wiki.parabola.nu/ARM_Installation_Guide [2]There is no Linux image in it. You can use libremakepkg to build packages in this chroot[3] [3]https://wiki.parabola.nu/Package_maintainer_guide Denis. From adam at vany.ca Sat Dec 8 17:00:31 2018 From: adam at vany.ca (Adam Van Ymeren) Date: Sat, 08 Dec 2018 12:00:31 -0500 Subject: [Arm-netbook] Questioning The Holy War In-Reply-To: References: <20181207113442.3mwssajwmoep7fsw@cherry> <20181207215222.v5obxybjieidjvef@topoi.pooq.com> <20181208120715.o64rtojc5ynqdbwy@cherry> Message-ID: <0D2E0BC7-0960-4BBB-BC7A-F0EF98B015DC@vany.ca> On December 8, 2018 10:28:18 AM EST, Chris Tyler wrote: >On Sat, Dec 8, 2018 at 7:07 AM Pablo Rath wrote: > >> On Fri, Dec 07, 2018 at 04:52:22PM -0500, Hendrik Boom wrote: >> > On Fri, Dec 07, 2018 at 12:59:44PM +0100, Pablo Rath wrote: >> > > >> > > How do you know if the source is closed? :) >> > >> > Let's assume this is a real question. >> >> Hendrik, I am sorry. I see, I have phrased my (rhetoric) question >> poorly. What I meant and should have written is mor like: "How can >you >> know if a >> software behaves well and doesn't shoot the cat when you can't audit >the >> source code?" >> > >I must point out an error here: Ken Thompson proved that auditing >source >code (of software and the toolchain used to build it) is meaningless in >his >paper "Reflections on Trusting Trust". His talk didn't show that it's meaningless but that its not always sufficient. > That paper/talk was released 34 >years ago, and it wasn't theoretical -- it was based on malware that >he'd >successfully released into the wild many years before. > >(That said, I still prefer to be able to read the source -- just saying >we >shouldn't attribute disproven benefits to source reading!). > >-Chris >_______________________________________________ >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 pelzflorian at pelzflorian.de Sat Dec 8 19:02:08 2018 From: pelzflorian at pelzflorian.de (pelzflorian (Florian Pelz)) Date: Sat, 8 Dec 2018 20:02:08 +0100 Subject: [Arm-netbook] Questioning The Holy War In-Reply-To: <20181208161943.chbtbzwuidlh4or4@topoi.pooq.com> References: <20181207113442.3mwssajwmoep7fsw@cherry> <20181207215222.v5obxybjieidjvef@topoi.pooq.com> <20181208120715.o64rtojc5ynqdbwy@cherry> <20181208161943.chbtbzwuidlh4or4@topoi.pooq.com> Message-ID: <20181208190207.seouycmpwjx7l2ei@pelzflorian.localdomain> On Sat, Dec 08, 2018 at 11:19:43AM -0500, Hendrik Boom wrote: > On Sat, Dec 08, 2018 at 10:28:18AM -0500, Chris Tyler wrote: > > On Sat, Dec 8, 2018 at 7:07 AM Pablo Rath wrote: > > > > > On Fri, Dec 07, 2018 at 04:52:22PM -0500, Hendrik Boom wrote: > > > > On Fri, Dec 07, 2018 at 12:59:44PM +0100, Pablo Rath wrote: > > > > > > > > > > How do you know if the source is closed? :) > > > > > > > > Let's assume this is a real question. > > > > > > Hendrik, I am sorry. I see, I have phrased my (rhetoric) question > > > poorly. What I meant and should have written is mor like: "How can you > > > know if a > > > software behaves well and doesn't shoot the cat when you can't audit the > > > source code?" > > > > > > > I must point out an error here: Ken Thompson proved that auditing source > > code (of software and the toolchain used to build it) is meaningless in his > > paper "Reflections on Trusting Trust". That paper/talk was released 34 > > years ago, and it wasn't theoretical -- it was based on malware that he'd > > successfully released into the wild many years before. > > I remember reading that talk -- Wasn't it a Turing lecture? -- and I don't > recall him saying he actually did release that malware -- he just explained > what he *could* have done. But he didn't deny it either. > > Or do you have firther information on this? If so I'd like to hear it. > > Let me be pleased there is more than one C compiler in existence. And that > it is undecidable whether an arbitrary piece of code actually compiles C, so > that his malware, should it exist, is limited in scope. > This problem is one of the reasons why bootstrappable.org, GNU Mes and such things exist so it is easier to detect when object code does not correspond to source code. Regards, Florian From chris at tylers.info Sat Dec 8 19:33:26 2018 From: chris at tylers.info (Chris Tyler) Date: Sat, 8 Dec 2018 14:33:26 -0500 Subject: [Arm-netbook] Questioning The Holy War In-Reply-To: <20181208161943.chbtbzwuidlh4or4@topoi.pooq.com> References: <20181207113442.3mwssajwmoep7fsw@cherry> <20181207215222.v5obxybjieidjvef@topoi.pooq.com> <20181208120715.o64rtojc5ynqdbwy@cherry> <20181208161943.chbtbzwuidlh4or4@topoi.pooq.com> Message-ID: On Sat, Dec 8, 2018 at 11:20 AM Hendrik Boom wrote: > On Sat, Dec 08, 2018 at 10:28:18AM -0500, Chris Tyler wrote: > > On Sat, Dec 8, 2018 at 7:07 AM Pablo Rath wrote: > > > > > On Fri, Dec 07, 2018 at 04:52:22PM -0500, Hendrik Boom wrote: > > > > On Fri, Dec 07, 2018 at 12:59:44PM +0100, Pablo Rath wrote: > > > > > > > > > > How do you know if the source is closed? :) > > > > > > > > Let's assume this is a real question. > > > > > > Hendrik, I am sorry. I see, I have phrased my (rhetoric) question > > > poorly. What I meant and should have written is mor like: "How can you > > > know if a > > > software behaves well and doesn't shoot the cat when you can't audit > the > > > source code?" > > > > > > > I must point out an error here: Ken Thompson proved that auditing source > > code (of software and the toolchain used to build it) is meaningless in > his > > paper "Reflections on Trusting Trust". That paper/talk was released 34 > > years ago, and it wasn't theoretical -- it was based on malware that he'd > > successfully released into the wild many years before. > > I remember reading that talk -- Wasn't it a Turing lecture? -- and I don't > recall him saying he actually did release that malware -- he just > explained > what he *could* have done. But he didn't deny it either. > >From text of the talk: "The actual bug that I planted in the compiler..." and discussion at the time indicated that this... feature... had been present for years. I think it was safe for him to mention in '84 because many (though not all) were migrating off the original toolchain by that point. -Chris From calmstorm at posteo.de Sat Dec 8 19:54:04 2018 From: calmstorm at posteo.de (zap) Date: Sat, 8 Dec 2018 14:54:04 -0500 Subject: [Arm-netbook] Huge RAM requirements (was: What do 1, 000 EOMA68-A20 PCBs look like?) In-Reply-To: References: <3518671.gX2FLSBOfK@jeremy> <2316671.UOBgKsZiV5@jeremy> <20181206085850.ttjuydldgf2lx4yc@manillaroad.local.home.trueelena.org> <1650151.vv4WxCpgx3@jeremy> <92ac3429-0f0b-b78e-d6d4-bf2fa83a8bb1@riseup.net> <20181207224513.01f1df23@Phenom-II-x6.niklas.com> Message-ID: <75bd1695-9112-9ed7-d3e9-9dd758021e1e@posteo.de> On 12/08/2018 12:36 AM, Luke Kenneth Casson Leighton wrote: > --- > crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68 > > On Sat, Dec 8, 2018 at 3:46 AM David Niklas wrote: > >> HOLY COW! >> Luke, there has been no progress on this for ~6 months. I could test 2 >> systems of my own and comment on the bug report. It would not be soon, >> probably at least a week, but what's a week if you wait 6 months? >> I have an RK3399 board by firefly and an HP Stream Notebook with >> unupgreadable or replaceable RAM and disk. Perfect candidates for this >> test. >> I would preferably use Gentoo Linux, does it matter? > not in the slightest. the more the better Any plans to use rk3399 for a 2nd revision of the eoma68 standard? or any alternative arm processor? Since risc-v is maybe 3+ years out of the way? From eaterjolly at gmail.com Sat Dec 8 21:07:47 2018 From: eaterjolly at gmail.com (Jean Flamelle) Date: Sat, 8 Dec 2018 16:07:47 -0500 Subject: [Arm-netbook] Reframing The Holy War Message-ID: Don't forget free CULTURE. Too much focus on illusions of grander security, minimizing the minimal black swans, then we forget we want a clean mental environment furthermore to have as well as give meaningful challenges with outcomes expressing the spirits of the souls experiencing the prerequisite difficulty and more. We want diversity AND isolation to have a creative society. That requires redundancy, which requires excluding exclusive proprieties. Libre Propriety. From rekado at elephly.net Sat Dec 8 22:14:09 2018 From: rekado at elephly.net (Ricardo Wurmus) Date: Sat, 08 Dec 2018 23:14:09 +0100 Subject: [Arm-netbook] Questioning The Holy War In-Reply-To: References: <20181207113442.3mwssajwmoep7fsw@cherry> <20181207215222.v5obxybjieidjvef@topoi.pooq.com> <20181208120715.o64rtojc5ynqdbwy@cherry> Message-ID: <87a7lffyz2.fsf@elephly.net> Chris Tyler writes: > I must point out an error here: Ken Thompson proved that auditing source > code (of software and the toolchain used to build it) is meaningless in his > paper "Reflections on Trusting Trust". That’s why it’s important to have trustable tools and reproducible builds. For trustable tools there’s ongoing work on a complete source bootstrap from an auditable source/binary hybrid all the way to a modern GNU system. See [1] and [2]. Reproducible builds guarantee that a given binary actually corresponds to source code. Having both of these properties does allow us to reason about the properties of our binaries. [1] https://savannah.nongnu.org/projects/stage0/ [2] https://www.gnu.org/software/mes/ -- Ricardo From rekado at elephly.net Sat Dec 8 22:16:48 2018 From: rekado at elephly.net (Ricardo Wurmus) Date: Sat, 08 Dec 2018 23:16:48 +0100 Subject: [Arm-netbook] What do 1,000 EOMA68-A20 PCBs look like? In-Reply-To: References: <3518671.gX2FLSBOfK@jeremy> <2316671.UOBgKsZiV5@jeremy> <20181206085850.ttjuydldgf2lx4yc@manillaroad.local.home.trueelena.org> <1650151.vv4WxCpgx3@jeremy> <92ac3429-0f0b-b78e-d6d4-bf2fa83a8bb1@riseup.net> <87pnudez76.fsf@elephly.net> Message-ID: <878t0zfyun.fsf@elephly.net> Luke Kenneth Casson Leighton writes: > On Fri, Dec 7, 2018 at 10:42 PM Ricardo Wurmus wrote: > >> [I don’t know if any Guix hackers have received an A20 board for porting > > i donated one to the key developers when i encountered them at fosdem 2017. Ah, great. I just chatted with that person and we’re tracking progress on this in the Guix bug tracker at: https://issues.guix.info/issue/33676 -- Ricardo From lkcl at lkcl.net Sun Dec 9 05:07:51 2018 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Sun, 9 Dec 2018 05:07:51 +0000 Subject: [Arm-netbook] Huge RAM requirements (was: What do 1, 000 EOMA68-A20 PCBs look like?) In-Reply-To: <75bd1695-9112-9ed7-d3e9-9dd758021e1e@posteo.de> References: <3518671.gX2FLSBOfK@jeremy> <2316671.UOBgKsZiV5@jeremy> <20181206085850.ttjuydldgf2lx4yc@manillaroad.local.home.trueelena.org> <1650151.vv4WxCpgx3@jeremy> <92ac3429-0f0b-b78e-d6d4-bf2fa83a8bb1@riseup.net> <20181207224513.01f1df23@Phenom-II-x6.niklas.com> <75bd1695-9112-9ed7-d3e9-9dd758021e1e@posteo.de> Message-ID: On Sat, Dec 8, 2018 at 7:54 PM zap wrote: > Any plans to use rk3399 for a 2nd revision of the eoma68 standard? or > any alternative arm processor? Since risc-v is maybe 3+ years out of the > way? yes. bear in mind it's around USD $5k-10k per design effort. i *may* be able to recover the RK3288 PCB i did. the RK3399 would be nicer. l. From pablo at parobalth.org Sun Dec 9 21:09:02 2018 From: pablo at parobalth.org (Pablo Rath) Date: Sun, 9 Dec 2018 22:09:02 +0100 Subject: [Arm-netbook] Questioning The Holy War In-Reply-To: References: <20181207113442.3mwssajwmoep7fsw@cherry> <20181207215222.v5obxybjieidjvef@topoi.pooq.com> <20181208120715.o64rtojc5ynqdbwy@cherry> Message-ID: <20181209210902.m3xuhnuveyhwssgv@cherry> On Sat, Dec 08, 2018 at 10:28:18AM -0500, Chris Tyler wrote: > On Sat, Dec 8, 2018 at 7:07 AM Pablo Rath wrote: > > > On Fri, Dec 07, 2018 at 04:52:22PM -0500, Hendrik Boom wrote: > > > On Fri, Dec 07, 2018 at 12:59:44PM +0100, Pablo Rath wrote: > > > > > > > > How do you know if the source is closed? :) > > > > > > Let's assume this is a real question. > > > > Hendrik, I am sorry. I see, I have phrased my (rhetoric) question > > poorly. What I meant and should have written is mor like: "How can you > > know if a > > software behaves well and doesn't shoot the cat when you can't audit the > > source code?" > > > > I must point out an error here: Ken Thompson proved that auditing source > code (of software and the toolchain used to build it) is meaningless in his > paper "Reflections on Trusting Trust". Chris, I have to admit that I find your reply a bit unfair as we were not (yet) discussing such sophisticated details. Especially as the initial question was more in the direction of a comparison of proprietary, open source (with blobs) and completely libre systems and why everyone on this list is so focussed on "libre". I did some reading on the "trusting trust" topic and want to share what I found: I have never heard of that paper before so I had to look that up. A blogpost by Bruce Schneier led me to David A. Wheeler's 2009 PhD dissertation "Fully Countering Trusting Trust through Diverse Double-Compiling". The dissertation and a lot of additional information can be found at [1]. The dissertation explains how to fully counter the "trusting trust" attack by using the “Diverse Double-Compiling” (DDC) technique. "DDC, in contrast, uses additional compilers as a check on the first. This fundamentally changes things, because now an attacker must simultaneously subvert both the original compiler, and all of the compilers used in DDC. Subverting multiple compilers is much harder than subverting one, especially since the defender can choose which compilers to use in DDC and can choose the compilers used in DDC after the attack has been performed." ([1], section "DDC’s use of trusted compiler(s) fundamentally increases trustworthiness") I also recommend the section "Reproducible (deterministic) builds" in [1]: "Deterministic builds aren’t enough if the compiler executable is subverted, but thankfully, DDC enables multi-party verification of compiler executables (you still have to check the source, but that is a much easier problem)." So according to David A. Wheeler the "trusting trust" attack can be fully countered and we are back in a state where auditing source is not meaningless. Source: [1] https://dwheeler.com/trusting-trust/ > (That said, I still prefer to be able to read the source -- just saying we > shouldn't attribute disproven benefits to source reading!). There are many attack vectors that make checking the source look ridiculous (compromised hardware, evil maid attack, ...). We can also question if the auditing process is working well enough but I think thats is not the point of this thread as it doesn't help to answer the initial questions. kind regards Pablo From calmstorm at posteo.de Sun Dec 9 21:30:43 2018 From: calmstorm at posteo.de (zap) Date: Sun, 9 Dec 2018 16:30:43 -0500 Subject: [Arm-netbook] Huge RAM requirements (was: What do 1, 000 EOMA68-A20 PCBs look like?) In-Reply-To: References: <3518671.gX2FLSBOfK@jeremy> <2316671.UOBgKsZiV5@jeremy> <20181206085850.ttjuydldgf2lx4yc@manillaroad.local.home.trueelena.org> <1650151.vv4WxCpgx3@jeremy> <92ac3429-0f0b-b78e-d6d4-bf2fa83a8bb1@riseup.net> <20181207224513.01f1df23@Phenom-II-x6.niklas.com> <75bd1695-9112-9ed7-d3e9-9dd758021e1e@posteo.de> Message-ID: <76bf76c4-a34d-ad18-a635-da5a343c0c8d@posteo.de> On 12/09/2018 12:07 AM, Luke Kenneth Casson Leighton wrote: > On Sat, Dec 8, 2018 at 7:54 PM zap wrote: > >> Any plans to use rk3399 for a 2nd revision of the eoma68 standard? or >> any alternative arm processor? Since risc-v is maybe 3+ years out of the >> way? > yes. bear in mind it's around USD $5k-10k per design effort. i > *may* be able to recover the RK3288 PCB i did. the RK3399 would be > nicer. My bad for responding to you directly and now too, but yeah, I think RK3399 would be better for meltdown spectre protection, etc... Also, it is faster :) > 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 eaterjolly at gmail.com Sun Dec 9 22:24:14 2018 From: eaterjolly at gmail.com (Jean Flamelle) Date: Sun, 9 Dec 2018 17:24:14 -0500 Subject: [Arm-netbook] Reframing The Holy War In-Reply-To: References: Message-ID: I want to clarify my illusion comment. One cannot guarantee security unless they study their computer's entire operation including how each other program. Open source helps against unintentional glitches, only some designed defects, as well as bloatware, from a security front. Linux's amplifying complexity hampers security. Any excess instructions on the machine amplifies complexity, hampering security. Open source enables free culture thereby enabling remix or customizing one's mental environment. On 12/8/18, Jean Flamelle wrote: > Don't forget free CULTURE. > > Too much focus on illusions of grander security, minimizing the > minimal black swans, then we forget we want a clean mental environment > furthermore to have as well as give meaningful challenges with > outcomes expressing the spirits of the souls experiencing the > prerequisite difficulty and more. > > We want diversity AND isolation to have a creative society. > That requires redundancy, which requires excluding exclusive proprieties. > Libre Propriety. > -- CC0 From eaterjolly at gmail.com Sun Dec 9 22:26:35 2018 From: eaterjolly at gmail.com (Jean Flamelle) Date: Sun, 9 Dec 2018 17:26:35 -0500 Subject: [Arm-netbook] Reframing The Holy War In-Reply-To: References: Message-ID: On 12/9/18, Jean Flamelle wrote: > I want to clarify my illusion comment. > > One cannot guarantee security unless they study their computer's > entire operation including how each other program. Open source helps how each program affects each other program, individually as well as in combination.* From paul at boddie.org.uk Sun Dec 9 23:45:42 2018 From: paul at boddie.org.uk (Paul Boddie) Date: Mon, 10 Dec 2018 00:45:42 +0100 Subject: [Arm-netbook] Reframing The Holy War In-Reply-To: References: Message-ID: <1655730.QxfXetRmoA@jeremy> On Sunday 9. December 2018 17.24.14 Jean Flamelle wrote: > > Linux's amplifying complexity hampers security. Of course, one could look more closely at microkernel-based systems for a possible remedy. Sadly, ever since the famous Torvalds versus Tanenbaum discussion, plenty of people cling to the remarks of the former as he sought to ridicule the work of the latter, oblivious to the fact that... 1. Microkernel performance was always a tradeoff (acknowledged by the DMERT work done by Bell Labs in the 1970s and in other contemporary work). 2. Performance has improved substantially over the years and in some cases wasn't that bad to begin with, either. 3. Billions of devices have shipped with microkernels. Some people also probably cling to the idea that Torvalds "won" his debate. Now that MINIX 3 runs in every Intel CPU supporting Management Engine functionality, it is clear who actually won, at least in terms of the "bottoms on seats" measure of success that the Linux kernel developers tend to emphasise over things like GPL compliance by vendors (some of those vendors being Linux Foundation members, of course). Paul P.S. I wasn't going to dignify this thread because of the inflammatory terminology used in the subject suggesting some kind of irrational fervour. In fact, demanding and ensuring complete control over the technologies we use is a pragmatic and entirely justified strategy for anyone who cares about their data, their computing capabilities, and even their quality of life. From monnier at iro.umontreal.ca Mon Dec 10 03:38:32 2018 From: monnier at iro.umontreal.ca (Stefan Monnier) Date: Sun, 09 Dec 2018 22:38:32 -0500 Subject: [Arm-netbook] Reframing The Holy War References: <1655730.QxfXetRmoA@jeremy> Message-ID: > In fact, demanding and ensuring complete control over the technologies > we use is a pragmatic and entirely justified strategy for anyone who > cares about their data, their computing capabilities, and even their > quality of life. I think it goes much further than that: the control Apple/Google/Facebook/... have over a large proportion of devices can give them sufficient leverage to make it possible for them to control you as well even if you don't use their services (e.g. by them arranging to have people elected which in turn introduce legislation or executive orders that impact you). You might argue we're not there yet, but the Cambridge Analytica affair makes it pretty obvious that it's a real possibility. Stefan From hendrik at topoi.pooq.com Mon Dec 10 13:48:56 2018 From: hendrik at topoi.pooq.com (Hendrik Boom) Date: Mon, 10 Dec 2018 08:48:56 -0500 Subject: [Arm-netbook] Reframing The Holy War In-Reply-To: <1655730.QxfXetRmoA@jeremy> References: <1655730.QxfXetRmoA@jeremy> Message-ID: <20181210134856.oxotnitzofh5oxwg@topoi.pooq.com> On Mon, Dec 10, 2018 at 12:45:42AM +0100, Paul Boddie wrote: > > Of course, one could look more closely at microkernel-based systems for a > possible remedy. Sadly, ever since the famous Torvalds versus Tanenbaum > discussion, plenty of people cling to the remarks of the former as he sought > to ridicule the work of the latter, oblivious to the fact that... > > 1. Microkernel performance was always a tradeoff (acknowledged by the DMERT > work done by Bell Labs in the 1970s and in other contemporary work). > 2. Performance has improved substantially over the years and in some cases > wasn't that bad to begin with, either. > 3. Billions of devices have shipped with microkernels. > > Some people also probably cling to the idea that Torvalds "won" his debate. > Now that MINIX 3 runs in every Intel CPU supporting Management Engine > functionality, it is clear who actually won, at least in terms of the "bottoms > on seats" measure of success that the Linux kernel developers tend to > emphasise over things like GPL compliance by vendors (some of those vendors > being Linux Foundation members, of course). Just curious -- what microkernel systems are available to run on modern home computers just in case one is tired of Linux and wanting to try something else? -- hendrik From adam at vany.ca Mon Dec 10 14:02:57 2018 From: adam at vany.ca (Adam Van Ymeren) Date: Mon, 10 Dec 2018 09:02:57 -0500 Subject: [Arm-netbook] Reframing The Holy War In-Reply-To: <20181210134856.oxotnitzofh5oxwg@topoi.pooq.com> References: <1655730.QxfXetRmoA@jeremy> <20181210134856.oxotnitzofh5oxwg@topoi.pooq.com> Message-ID: <8115DD83-000D-4D17-9130-2D9E3CBA5A22@vany.ca> On December 10, 2018 8:48:56 AM EST, Hendrik Boom wrote: >On Mon, Dec 10, 2018 at 12:45:42AM +0100, Paul Boddie wrote: >> >> Of course, one could look more closely at microkernel-based systems >for a >> possible remedy. Sadly, ever since the famous Torvalds versus >Tanenbaum >> discussion, plenty of people cling to the remarks of the former as he >sought >> to ridicule the work of the latter, oblivious to the fact that... >> >> 1. Microkernel performance was always a tradeoff (acknowledged by >the DMERT >> work done by Bell Labs in the 1970s and in other contemporary >work). >> 2. Performance has improved substantially over the years and in some >cases >> wasn't that bad to begin with, either. >> 3. Billions of devices have shipped with microkernels. >> >> Some people also probably cling to the idea that Torvalds "won" his >debate. >> Now that MINIX 3 runs in every Intel CPU supporting Management Engine > >> functionality, it is clear who actually won, at least in terms of the >"bottoms >> on seats" measure of success that the Linux kernel developers tend to > >> emphasise over things like GPL compliance by vendors (some of those >vendors >> being Linux Foundation members, of course). > >Just curious -- what microkernel systems are available to run on modern > >home computers just in case one is tired of Linux and wanting to try >something else? MINIX and GNU Hurd both exist and work. Hardware support isn't great however, might not work on the specific machine you have. > >-- hendrik > >_______________________________________________ >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 paul at boddie.org.uk Mon Dec 10 16:40:40 2018 From: paul at boddie.org.uk (Paul Boddie) Date: Mon, 10 Dec 2018 17:40:40 +0100 Subject: [Arm-netbook] Microkernel-based systems (was Re: Reframing The Holy War) In-Reply-To: <8115DD83-000D-4D17-9130-2D9E3CBA5A22@vany.ca> References: <20181210134856.oxotnitzofh5oxwg@topoi.pooq.com> <8115DD83-000D-4D17-9130-2D9E3CBA5A22@vany.ca> Message-ID: <11882380.48Bdzu1sGj@jeremy> On Monday 10. December 2018 09.02.57 Adam Van Ymeren wrote: > On December 10, 2018 8:48:56 AM EST, Hendrik Boom wrote: > > > >Just curious -- what microkernel systems are available to run on modern > >home computers just in case one is tired of Linux and wanting to try > >something else? > > MINIX and GNU Hurd both exist and work. Hardware support isn't great > however, might not work on the specific machine you have. Dave may have mentioned this previously on this list, but here are his articles about trying out the Hurd: "Exploring Alternative Operating Systems – GNU/Hurd" http://www.boddie.org.uk/david/www-repo/Personal/Updates/2016/2016-08-08.html "Back to the Hurd" http://www.boddie.org.uk/david/www-repo/Personal/Updates/2017/2017-06-30.html He also looked at Inferno, which isn't a microkernel-based system as far as I know, but it has some interesting characteristics: "Exploring Alternative Operating Systems – Inferno" http://www.boddie.org.uk/david/www-repo/Personal/Updates/2016/2016-09-01.html Another interesting general-purpose system is HelenOS: http://www.helenos.org/ This is apparently microkernel-based and should work on modern home computers. My mini-rant a few days ago discussed a tentative revival of the Hurd using L4-related technologies. Although the Hurd eventually got going by using the Mach microkernel (also seen in OSF/1, IBM Workplace OS, NeXTSTEP, Mac OS X, and so on), there have always been things in it that have been regarded as less than satisfactory. As far as I know now, there are certain limitations that conspire to produce pathological system behaviour, and this appears to have been difficult to remedy: https://www.sceen.net/the-end-of-the-thundering-hurd/ The principal reason given for no longer pursuing things like Hurd-on-L4 seems to be that "we already have GNU/Linux" and that device drivers would need writing, alongside the suggestion that people could instead be working on other, supposedly more urgent things. The latter suggestion should be ignored: if someone wants to work on operating system fundamentals, they aren't necessarily going to find working on PDF reader software satisfying, especially if no-one is likely to be paying them for their volunteering, anyway. I'm not going to claim that writing device drivers, driver frameworks, filesystems, and all the other things are easy enough. However, they do seem to get written over and over again, in alternative operating systems (of which there are many if you start looking) and in the Linux world itself. Moreover, it should be a more approachable activity in the microkernel world precisely because drivers are normal programs, not glued-in parts of the kernel framework that are subject to continual churn. My current perception of the weaknesses of various microkernel technologies is that their developers mostly seem to be chasing niches, not general-purpose computing. That may be making some people good money, but it doesn't necessarily help the average computer user. Indeed, with things like Intel Management Engine, it can actually be harmful to users instead. Paul From lkcl at lkcl.net Tue Dec 11 01:46:29 2018 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Tue, 11 Dec 2018 01:46:29 +0000 Subject: [Arm-netbook] microkernels In-Reply-To: <20181210134856.oxotnitzofh5oxwg@topoi.pooq.com> References: <1655730.QxfXetRmoA@jeremy> <20181210134856.oxotnitzofh5oxwg@topoi.pooq.com> Message-ID: On Mon, Dec 10, 2018 at 1:49 PM Hendrik Boom wrote: > > On Mon, Dec 10, 2018 at 12:45:42AM +0100, Paul Boddie wrote: > > > > Of course, one could look more closely at microkernel-based systems for a > > possible remedy. Sadly, ever since the famous Torvalds versus Tanenbaum > > discussion, plenty of people cling to the remarks of the former as he sought > > to ridicule the work of the latter, oblivious to the fact that... > > > > 1. Microkernel performance was always a tradeoff (acknowledged by the DMERT > > work done by Bell Labs in the 1970s and in other contemporary work). > > 2. Performance has improved substantially over the years and in some cases > > wasn't that bad to begin with, either. > > 3. Billions of devices have shipped with microkernels. > > > > Some people also probably cling to the idea that Torvalds "won" his debate. > > Now that MINIX 3 runs in every Intel CPU supporting Management Engine > > functionality, it is clear who actually won, at least in terms of the "bottoms > > on seats" measure of success that the Linux kernel developers tend to > > emphasise over things like GPL compliance by vendors (some of those vendors > > being Linux Foundation members, of course). > > Just curious -- what microkernel systems are available to run on modern > home computers just in case one is tired of Linux and wanting to try > something else? SE/L4. one research group actually created a complete minimum-compliant POSIX subsystem on top of SE/L4, absolutely nothing to do with any operating system "per se", and then successfully ported an entire qt-based webkit browser *and all its dependencies* to run on it. the "filesystem" was entirely flat. no subdirectories. so when i say "minimally compliant" it really really was "minimally compliant". l. From laserhawk64 at gmail.com Tue Dec 11 02:11:49 2018 From: laserhawk64 at gmail.com (Christopher Havel) Date: Mon, 10 Dec 2018 21:11:49 -0500 Subject: [Arm-netbook] microkernels In-Reply-To: References: <1655730.QxfXetRmoA@jeremy> <20181210134856.oxotnitzofh5oxwg@topoi.pooq.com> Message-ID: So, as I (poorly) understand it, the idea of a "microkernel" is that each process/thread/application (I'm not quite sure which) gets its own kernel, sort of, and that this kernel is somewhat modular in that it only provides what functionality the application needs from it. If I'm understanding that correctly -- which I very easily might not, I only have a somewhat abstract understanding of kernels to begin with, at best -- it seems to me that things like memory management suddenly become cooperative efforts, and that could very easily lead to what is typically non-technically referred to as a massive clusterf***. Wouldn't it be easier/better, if you're going to rewrite code, to look at how the code is written now and find ways to make it more compact (or less sloppy, perhaps, as the case may be) while still providing the same functionality? I recognize that we've come a quite long way from things like an Atari 2600, but when you consider the system resources of /that/ machine -- 4k ROM, 128 *bytes* of memory, a rather nastily-tempered, strict, and uncooperative graphics controller, and a CPU running at ~1MHz with no interrupt capability whatsoever -- and what all was done with it by coding tightly (and the occasional dirty trick or three) -- it seems to me, admittedly as a non-programmer, that there's a lot that could be done to streamline the behavior of modern operating systems and the applications that run within them. For example, I'm typing this on a 32bit Win7 based HP Mini netbook with an Atom N450 CPU and 2gb RAM. It seems to me that playing Pandora Internet Radio in one browser window, with another browser window of nine tabs (and three of those are static JPEG images retrieved from a search engine, not proper webpages or anything), and with the file manager having one window open and another image displayed in an OS-resident image viewer -- that the described load ought not to very nearly lock the machine up entirely. And yet, it does -- which, it seems to me, indicates that the gentlefolk they're hiring over there in Redmond these days, simply do not understand how to code. But, then, neither do I... From hendrik at topoi.pooq.com Tue Dec 11 02:35:52 2018 From: hendrik at topoi.pooq.com (Hendrik Boom) Date: Mon, 10 Dec 2018 21:35:52 -0500 Subject: [Arm-netbook] microkernels In-Reply-To: References: <1655730.QxfXetRmoA@jeremy> <20181210134856.oxotnitzofh5oxwg@topoi.pooq.com> Message-ID: <20181211023552.iesmfxzovxv45sda@topoi.pooq.com> On Mon, Dec 10, 2018 at 09:11:49PM -0500, Christopher Havel wrote: > So, as I (poorly) understand it, the idea of a "microkernel" is that each > process/thread/application (I'm not quite sure which) gets its own kernel, > sort of, and that this kernel is somewhat modular in that it only provides > what functionality the application needs from it. > > If I'm understanding that correctly -- which I very easily might not, I > only have a somewhat abstract understanding of kernels to begin with, at > best -- it seems to me that things like memory management suddenly become > cooperative efforts, and that could very easily lead to what is typically > non-technically referred to as a massive clusterf***. The idea of a microkernel is that it's the only thing running in a hardware-privileged mode, and that it does only what it absolutely has to do for the system to work. A big part of that is to manage the privileges given to other processes in the machine. File systems, networking, etc, etc, all operate outside the microkernel, and are protected against incursions from each other. It's a security-based architecture. To a fair extent the system is protected against its own bugs. > > Wouldn't it be easier/better, if you're going to rewrite code, to look at > how the code is written now and find ways to make it more compact (or less > sloppy, perhaps, as the case may be) while still providing the same > functionality? That would be good too, but is independent of whether you want to protect the system against its own errors. Making code less sloppy will of course also reduce the number of bugs there are to defend against. > > I recognize that we've come a quite long way from things like an Atari > 2600, but when you consider the system resources of /that/ machine -- 4k > ROM, 128 *bytes* of memory, a rather nastily-tempered, strict, and > uncooperative graphics controller, and a CPU running at ~1MHz with no > interrupt capability whatsoever -- and what all was done with it by coding > tightly (and the occasional dirty trick or three) -- it seems to me, > admittedly as a non-programmer, that there's a lot that could be done to > streamline the behavior of modern operating systems and the applications > that run within them. > > For example, I'm typing this on a 32bit Win7 based HP Mini netbook with an > Atom N450 CPU and 2gb RAM. It seems to me that playing Pandora Internet > Radio in one browser window, with another browser window of nine tabs (and > three of those are static JPEG images retrieved from a search engine, not > proper webpages or anything), and with the file manager having one window > open and another image displayed in an OS-resident image viewer -- that the > described load ought not to very nearly lock the machine up entirely. And > yet, it does -- which, it seems to me, indicates that the gentlefolk > they're hiring over there in Redmond these days, simply do not understand > how to code. I agree, it shouldn't lock up. -- hendrik From lkcl at lkcl.net Tue Dec 11 03:05:45 2018 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Tue, 11 Dec 2018 03:05:45 +0000 Subject: [Arm-netbook] microkernels In-Reply-To: References: <1655730.QxfXetRmoA@jeremy> <20181210134856.oxotnitzofh5oxwg@topoi.pooq.com> Message-ID: On Tue, Dec 11, 2018 at 2:12 AM Christopher Havel wrote: > So, as I (poorly) understand it, the idea of a "microkernel" is that each > process/thread/application (I'm not quite sure which) gets its own kernel, > sort of, and that this kernel is somewhat modular in that it only provides > what functionality the application needs from it. not quite: a microkernel provides the absolute absolute minimum functionality to manage tasks and communication _between_ tasks. as a result they're typically extremely small, and usually are the only place where assembly code is needed. L4ka ports of the linux kernel basically turn the entire linux "kernel" effectively into a user-space-like "application". you now have *three* levels: L4ka microkernel, linux "kernel", GNU/Linux OS. the GNU/Hurd's microkernel inter-process communication is actually sufficiently abstracted such that processes may actually be run *off-machine*, by dropping in a full-on network-based RPC (remote procedure call) mechanism. hypothetically this would allow full migration of processes from one machine to another, without any interruption in the running of the user applications as they migrate. l. From lkcl at lkcl.net Tue Dec 11 03:13:12 2018 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Tue, 11 Dec 2018 03:13:12 +0000 Subject: [Arm-netbook] microkernels In-Reply-To: References: <1655730.QxfXetRmoA@jeremy> <20181210134856.oxotnitzofh5oxwg@topoi.pooq.com> Message-ID: --- crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68 On Tue, Dec 11, 2018 at 2:12 AM Christopher Havel wrote: > For example, I'm typing this on a 32bit Win7 based HP Mini netbook with an > Atom N450 CPU and 2gb RAM. It seems to me that playing Pandora Internet > Radio in one browser window, with another browser window of nine tabs (and > three of those are static JPEG images retrieved from a search engine, not > proper webpages or anything), and with the file manager having one window > open and another image displayed in an OS-resident image viewer -- that the > described load ought not to very nearly lock the machine up entirely. And > yet, it does -- which, it seems to me, indicates that the gentlefolk > they're hiring over there in Redmond these days, simply do not understand > how to code. they do... they're "hampered" by some design decisions that relate to strategically significant "convenience", at the MSRPC (more specifically the DCOM) level. DCOM is a way to transparently treat remote objects as if they were local. however it requires that the entire function call be serialised (marshalled) and unserialised (unmarshalled). for *local* systems (local procedure calls, over a transport named "ncalrpc"), someone came up with the brilliant and simple idea of using shared memory. instead of doing a full serialisation, instead the data structures would be in shared memory, at a globally-fixed address. the problem is: the *amount* of shared memory required effectively consumes a whopping 50% of available memory. on 32-bit systems they subdivided the memory into 2 halves, which in turn meant that *all* 32-bit applications were hard-limited to a maximum of 2GB of physical RAM, where the other 2GB absolutely had to be hard-reserved onto *real* RAM. as you only have 2GB of RAM, and are running a modern web browser, a massive chunk of that physical 2GB will be reserved for global fixed-address shared memory, which in turn leaves pretty much absolutely nothing left as far as running web browsers is concerned. thus, that netbook will be absolutely thrashing its nuts off, on swap-space. bottom line: what the f*** are you doing running windows!! :) l. From laserhawk64 at gmail.com Tue Dec 11 04:54:14 2018 From: laserhawk64 at gmail.com (Christopher Havel) Date: Mon, 10 Dec 2018 23:54:14 -0500 Subject: [Arm-netbook] microkernels In-Reply-To: References: <1655730.QxfXetRmoA@jeremy> <20181210134856.oxotnitzofh5oxwg@topoi.pooq.com> Message-ID: @ All - thank you for a better understanding of microkernels. I learned more than a few things there. @ Luke, re Win - it is one of two Win boxes I maintain. The other is a Dell XPS 15Z with the more odious Windows 10, which I need because I use a graphics application called CorelDRAW. I have attempted the use of Inkscape - but, "bless their hearts" (as one often says, in my geographic location) they have no idea how to make a human-usable UI. The one time I tried it, it gave me fits and left me with far more questions than answers... I maintain the Win7 netbook because of a promise I made to a close friend - he spent his childhood in front of various computers with the Commodore logo on them - and he recently gave me that collection, with tge request that I image the rather extensive disk library that it came with, so that if he ever wanted to fire up an emulator and muck around like a kid again, he could. Normally this requires a real DOS computer, and specialized software and cabling - as Commodore's disk drives used a different encoding scheme, at the magnetic level, from what PC drives use - but I recently acquired a device called a "ZoomFloppy", which enables the use of more modern equipment to do the PC side of the job - you still need a Commodore drive, mind you, but you are no longer mired in the world of the early 1990s (at the latest!) otherwise, which dramatically reduces the number of potential points of failure. ...as for why I'm using the netbook for anything else - that comes down to three things. One, I like sitting in my front room right now better than spending all day at the desk in the bedroom - which I desperately need to clean off. Two, one of my DIY laptops recently died spectacularly, and I'm awaiting parts for a rebuild. Three, the netbook offers a convenient stand-in for the dead laptop and is easily set up in my front room, whereas relocating the much larger, remaining DIY laptop from the bedroom desk would be a considerable effort indeed. Also - I do not, in the given context, understand the term "marshalling" as you used it - could you elaborate, please...? From doark at mail.com Tue Dec 11 17:44:51 2018 From: doark at mail.com (doark at mail.com) Date: Tue, 11 Dec 2018 12:44:51 -0500 Subject: [Arm-netbook] microkernels In-Reply-To: References: <1655730.QxfXetRmoA@jeremy> <20181210134856.oxotnitzofh5oxwg@topoi.pooq.com> Message-ID: <20181211103051.710505f0@Phenom-II-x6.niklas.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On Tue, 11 Dec 2018 03:05:45 +0000 Luke Kenneth Casson Leighton wrote: > On Tue, Dec 11, 2018 at 2:12 AM Christopher Havel > wrote: > > > So, as I (poorly) understand it, the idea of a "microkernel" is that > > each process/thread/application (I'm not quite sure which) gets its > > own kernel, sort of, and that this kernel is somewhat modular in that > > it only provides what functionality the application needs from it. > > not quite: a microkernel provides the absolute absolute minimum > functionality to manage tasks and communication _between_ tasks. as a > result they're typically extremely small, and usually are the only > place where assembly code is needed. > > L4ka ports of the linux kernel basically turn the entire linux > "kernel" effectively into a user-space-like "application". you now > have *three* levels: L4ka microkernel, linux "kernel", GNU/Linux OS. > > the GNU/Hurd's microkernel inter-process communication is actually > sufficiently abstracted such that processes may actually be run > *off-machine*, by dropping in a full-on network-based RPC (remote > procedure call) mechanism. hypothetically this would allow full > migration of processes from one machine to another, without any > interruption in the running of the user applications as they migrate. > > l. > That sounds really cool. No more FF pocket, or cloud, just use MicroLinux. Sincerely, David -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEL2N7+xWmVOJDQxWGm3XCrhg2YP8FAlwP95MACgkQm3XCrhg2 YP+MuBAAhf6w8CdUda5ihMtcdU+vjeYUnPKSIO08dxIj3s5BGXydCOAv7x3Cqq/D XlA3BB1T61bIlOJ8YCsHrKyx3rmRtJayvAARIKoOfgLau86lHpaVx8fha6UjuvML JUDlahj8c1wCbsvh72rmUfE/E710Og4xXuXxzI+5D49Vc2mTQpQNTPcGTq7NtrK3 kwhcoQwFo+WmJnBapcYJu2SEc5/Gxv7AauGhC/Q0VvurfEfKixM4/G4yeq/nDY9f j/tBenMZgYeoOc+ZyiN5zuPqJmtIeO6bIaVl9VlkR4edREoOQpljaXL9n0MkfH3t mBs7JW7GPfV5pPE0fqdtEiFv+m02WIPgNnSCBL8XgR8KA3IMW6QvgjaXhGBep3/g eskC7zAgSXX8DUet5oSfNPlSsuyoTzh2awCWBGlqD6bYL1RG+rItm5gCCo8tQJgJ 8540yLcC0k0VzCHlERzjntP8qM1vIvlrAC+9mnpcQmZThDpMeuX1ZmI8TtWXgIFo 5KXRqTzHe0hDoiKs6FGlV1XYUrj0BERndZA7cYZxZjCH3u/8YRqCcj5bI7jXpT+c VZdX75sRwg6Kc4KajDq+A1So1X/GqiRvCiwcOFWSuwOvAmDT/KJOWzLK0EWeAn9D KFuOxV28JbkzglhD/SwmQmKj32XTa07s0+RVAzwzQ3WitItgh7c= =zHb7 -----END PGP SIGNATURE----- From doark at mail.com Tue Dec 11 17:44:26 2018 From: doark at mail.com (doark at mail.com) Date: Tue, 11 Dec 2018 12:44:26 -0500 Subject: [Arm-netbook] Reframing The Holy War In-Reply-To: References: <1655730.QxfXetRmoA@jeremy> Message-ID: <20181211124411.5bbf0093@Phenom-II-x6.niklas.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On Sun, 09 Dec 2018 22:38:32 -0500 Stefan Monnier wrote: > > In fact, demanding and ensuring complete control over the technologies > > we use is a pragmatic and entirely justified strategy for anyone who > > cares about their data, their computing capabilities, and even their > > quality of life. > > I think it goes much further than that: the control > Apple/Google/Facebook/... have over a large proportion of devices can > give them sufficient leverage to make it possible for them to control > you as well even if you don't use their services (e.g. by them arranging > to have people elected which in turn introduce legislation or executive > orders that impact you). > > You might argue we're not there yet, but the Cambridge Analytica affair > makes it pretty obvious that it's a real possibility. > > > Stefan > > Everyone remembers CA, but I remember when the local news (ABC,NBC, someone), reported on Obama doing the same thing. I have not watched through all the reporting on youtube to locate the segment (and I did not have internet access back then, so no chance of Conservative talk show/news room poisoning), so I did a quick search: https://nypost.com/2018/03/20/obamas-former-media-director-said-facebook-was-once-on-our-side/ It is wholly cited. https://www.politifact.com/truth-o-meter/statements/2018/mar/22/meghan-mccain/comparing-facebook-data-use-obama-cambridge-analyt/ As is this one. Together they paint a picture a lot larger than CA and the Republican party, a lot larger than Obama and the Democratic party. Here are some more: https://yro.slashdot.org/story/18/07/02/2057256/google-allows-outside-app-developers-to-read-peoples-gmails-says-report https://www.wired.com/story/our-minds-have-been-hijacked-by-our-phones-tristan-harris-wants-to-rescue-them/ https://www.theguardian.com/technology/2017/oct/05/smartphone-addiction-silicon-valley-dystopia A poor excuse: https://www.cnn.com/2018/03/26/opinions/data-company-spying-opinion-schneier/index.html Just how far it has gone: https://tech.slashdot.org/story/18/03/23/1811230/my-cow-game-extracted-your-facebook-data When will the world wake up? It's not just A, it's A and B through Z! Sincerely, David -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEL2N7+xWmVOJDQxWGm3XCrhg2YP8FAlwP93oACgkQm3XCrhg2 YP+Hdg/9H5cnr186YtZJYEIWcDizrZthK7/ljUxZYNAFyeGbKe907/+IPftmnj3s d+6LKIDPxqTpba+1wEr0OyifilXWRnSfred4V+J+qPWqlIeCMC6ANYXmCuFoMIRS kcDmx2zeUJxw3kFNwln3agTHiwfCHpfAkHp34AbHvV8srQH1mmuVIpJj18Rz0Uak WH+no+AbSj3JPBFXbAR20cgneEzVACjfbRrLOcJeRPbYUjHtA6CZraJw4H+cjj/R Jke9RNXlrrPVawRcATIwaJG7s7xluwgqs7uWtXNAZAu1NHrvom8zLo/qjraB1TKR ANUX85ZezZEKaSF1GKRaaQcoAwo2U3La6tE2gXcGn6OHKyf9NBmNC3hwQcWivVmx x0HeZ4vxtgqn7EY1V5mIhaXQ2BNhd6/4aaalEP6o4nLgMcyJAocdm6+bsnQWeS4e mKx7Uv3YQg9vhazt+O9wTrUz8Os/aXZ40FRLwo/zzKH0Ys8AsQBIGCWaJ1hf/TQU DUF2q4UI7t4Lo8LT0hXWBcSzjNDDGcQbRHyZb86qqp1EUmpuanikucBgqzxEJlHc 26u7qhlk/4BwGQpmkpgpGe/s+qf8yVhYjRPS4YvCF3GhC174gmdLEe2+IkjpYLU+ xj/1tvUCDELVlQbuVHyoXZbIbvUuPkUBccLif/prXyJ5f2fHQgA= =G8FX -----END PGP SIGNATURE----- From paul at boddie.org.uk Tue Dec 11 18:11:47 2018 From: paul at boddie.org.uk (Paul Boddie) Date: Tue, 11 Dec 2018 19:11:47 +0100 Subject: [Arm-netbook] microkernels In-Reply-To: References: <20181210134856.oxotnitzofh5oxwg@topoi.pooq.com> Message-ID: <64358161.fvHnMdfSgD@jeremy> On Tuesday 11. December 2018 01.46.29 Luke Kenneth Casson Leighton wrote: > > SE/L4. one research group actually created a complete > minimum-compliant POSIX subsystem on top of SE/L4, absolutely nothing > to do with any operating system "per se", and then successfully ported > an entire qt-based webkit browser *and all its dependencies* to run on > it. Was this related to Genode or something else? I know that Genode supports/supported a WebKit browser - maybe Arora - and that it supports a range of microkernels, although the focus seems to be on using their favoured Nova microkernel instead these days [*]. > the "filesystem" was entirely flat. no subdirectories. so when i say > "minimally compliant" it really really was "minimally compliant". That would be an odd decision to make given that it would need to have a filesystem of some kind and that beyond a rudimentary memory-based temporary filesystem, pretty much all of the ones out there have directories. If they'd gone to the trouble of porting a WebKit browser, porting an established filesystem would surely have been straightforward. L4Re has virtual filesystem support, but it seems pretty limited in a number of ways, and the bulk of the heavy lifting needed to support dynamic linking seems to be left to a "rom" filesystem. But even that supports directories. (Of course, L4Re is not aimed at seL4, but there are fairly comparable things for seL4, I believe.) Paul [*] As is increasingly customary with various projects, I hesitate to depict Genode in any particular way, even after digging through the copious promotional/educational materials so that I might precipitate a coherent impression, in case it gets perceived as misrepresenting something or someone. From eaterjolly at gmail.com Wed Dec 12 17:01:59 2018 From: eaterjolly at gmail.com (Jean Flamelle) Date: Wed, 12 Dec 2018 12:01:59 -0500 Subject: [Arm-netbook] Free culture Message-ID: Biases as well as lack thereof distinguish individuals. Whatever one believes might get muted by what one cannot choose to not receive exposure. Colloquially "free to speak; free to not listen". This existential health issue related to FLOSS in my opinion should take priority over the information security issue. -- CC0 From paul at boddie.org.uk Wed Dec 12 18:39:15 2018 From: paul at boddie.org.uk (Paul Boddie) Date: Wed, 12 Dec 2018 19:39:15 +0100 Subject: [Arm-netbook] Huge RAM requirements (was: What do 1, 000 EOMA68-A20 PCBs look like?) In-Reply-To: References: <3518671.gX2FLSBOfK@jeremy> <75bd1695-9112-9ed7-d3e9-9dd758021e1e@posteo.de> Message-ID: <1680791.TzMeuWtaqD@jeremy> On Sunday 9. December 2018 05.07.51 Luke Kenneth Casson Leighton wrote: > On Sat, Dec 8, 2018 at 7:54 PM zap wrote: > > Any plans to use rk3399 for a 2nd revision of the eoma68 standard? or > > any alternative arm processor? Since risc-v is maybe 3+ years out of the > > way? > > yes. bear in mind it's around USD $5k-10k per design effort. i > *may* be able to recover the RK3288 PCB i did. the RK3399 would be > nicer. Although it's not a 64-bit CPU and is MIPS-based not ARM-based, wasn't the JZ4775 board almost done? And didn't it have 2GB RAM already, before the A20 2GB RAM (and HDMI) rework effort? Of course there is the software distribution issue (if you want FSF endorsement), but there seems to be some demand for similar products. I follow the Dingoonity scene at a distance and although there is plenty of gadget chasing - people seem to throw themselves at random handhelds with poor screens and obsolete JZ variants - there are some that still wonder about successors to the GCW-Zero handheld or even getting one of the original ones, particularly as it seems that not everyone managed to receive one in that campaign. The enthusiasm is presumably something to do with MIPS-based stuff being used in various consoles of a certain era. Paul From lkcl at lkcl.net Wed Dec 12 19:19:43 2018 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Wed, 12 Dec 2018 19:19:43 +0000 Subject: [Arm-netbook] Huge RAM requirements (was: What do 1, 000 EOMA68-A20 PCBs look like?) In-Reply-To: <1680791.TzMeuWtaqD@jeremy> References: <3518671.gX2FLSBOfK@jeremy> <75bd1695-9112-9ed7-d3e9-9dd758021e1e@posteo.de> <1680791.TzMeuWtaqD@jeremy> Message-ID: --- crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68 On Wed, Dec 12, 2018 at 6:39 PM Paul Boddie wrote: > > On Sunday 9. December 2018 05.07.51 Luke Kenneth Casson Leighton wrote: > > On Sat, Dec 8, 2018 at 7:54 PM zap wrote: > > > Any plans to use rk3399 for a 2nd revision of the eoma68 standard? or > > > any alternative arm processor? Since risc-v is maybe 3+ years out of the > > > way? > > > > yes. bear in mind it's around USD $5k-10k per design effort. i > > *may* be able to recover the RK3288 PCB i did. the RK3399 would be > > nicer. > > Although it's not a 64-bit CPU and is MIPS-based not ARM-based, wasn't the > JZ4775 board almost done? pretty much - i just couldn't get beyond u-boot, as i had put a 24mhz XTAL in rather than a 48mhz, and i couldn't get the PLLs right to get beyond the SPL loader. > And didn't it have 2GB RAM already, before the A20 > 2GB RAM (and HDMI) rework effort? yes. > Of course there is the software distribution > issue (if you want FSF endorsement), but there seems to be some demand for > similar products. > > I follow the Dingoonity scene at a distance and although there is plenty of > gadget chasing - people seem to throw themselves at random handhelds with poor > screens and obsolete JZ variants - there are some that still wonder about > successors to the GCW-Zero handheld or even getting one of the original ones, > particularly as it seems that not everyone managed to receive one in that > campaign. The enthusiasm is presumably something to do with MIPS-based stuff > being used in various consoles of a certain era. ok - well, i've still got 2 of the cards around somewhere, and i can order some 48mhz XTALs: i have a heat gun so should be ok to put them in. i have no idea what kinds of volumes to expect. l. From paul at boddie.org.uk Wed Dec 12 21:15:24 2018 From: paul at boddie.org.uk (Paul Boddie) Date: Wed, 12 Dec 2018 22:15:24 +0100 Subject: [Arm-netbook] Huge RAM requirements (was: What do 1, 000 EOMA68-A20 PCBs look like?) In-Reply-To: References: <3518671.gX2FLSBOfK@jeremy> <1680791.TzMeuWtaqD@jeremy> Message-ID: <3288322.YZFBzzdUad@jeremy> On Wednesday 12. December 2018 19.19.43 Luke Kenneth Casson Leighton wrote: > > On Wed, Dec 12, 2018 at 6:39 PM Paul Boddie wrote: > > > > Although it's not a 64-bit CPU and is MIPS-based not ARM-based, wasn't the > > JZ4775 board almost done? > > pretty much - i just couldn't get beyond u-boot, as i had put a 24mhz > XTAL in rather than a 48mhz, and i couldn't get the PLLs right to get > beyond the SPL loader. Yes, 48MHz seems to be the EXCLK frequency for this particular generation of JZ SoCs: the JZ4780 uses that frequency for the CI20. As for the PLLs, the clock configuration seems to change from SoC to SoC, but they are probably similar, and documentation, kernel and U-Boot support should be out there for perusal. [Dingoo, GCW-Zero, MIPS-based consoles and emulation] > ok - well, i've still got 2 of the cards around somewhere, and i can > order some 48mhz XTALs: i have a heat gun so should be ok to put them > in. > > i have no idea what kinds of volumes to expect. Demand or supply volume? As for demand, it is difficult to say, but I thought some reporting of things from the wider world might help you decide what might be worthwhile doing in future, especially if most of the work is done. Paul From richard.wilbur at gmail.com Sat Dec 15 01:46:49 2018 From: richard.wilbur at gmail.com (Richard Wilbur) Date: Fri, 14 Dec 2018 18:46:49 -0700 Subject: [Arm-netbook] Free the (Intel) FSP? Message-ID: This looked interesting--like Intel is starting to feel pressure from RISC-V, et cetera. Regardless, I'm still very interested in security, efficiency, configurability, and other aspects of libre design of RISC-V. https://www.phoronix.com/scan.php?page=news_item&px=Intel-Open-Source-FSP-Likely From eaterjolly at gmail.com Wed Dec 19 02:40:53 2018 From: eaterjolly at gmail.com (Jean Flamelle) Date: Tue, 18 Dec 2018 21:40:53 -0500 Subject: [Arm-netbook] Libre "New Art" Message-ID: I believe the term software should get avoided when talking about libre development styles, in lieu of the patent requirement definition "new art" or "a new artifact for all history". Likewise I've substituted out "best" for '"Most Effective"..."for"...', so-as not to claim absolute morality. Memetics infrastructure, implies an infrastructure for generating serialized morality for complexifying interpersonal interactions. We cannot promise a series of guidelines thereof because we can't nor should subsidize the moral requirements of the world. http://rhombus-tech.net/proposed_best_practices/ P.S. Tip: The page still won't automatically update with the source. I very much want to continue updating this page. We could theoretically compile quite some interesting data. I also want to keep writing http://rhombus-tech.net/Economics/ . -- CC0