http://hackaday.com/2017/02/05/olimex-announces-their-open-source-laptop/
Rip 'em up, Luke... you know you want to... the quotes wouldn't be in the subject header otherwise...
:P
On Sun, Feb 5, 2017 at 6:18 PM, Christopher Havel laserhawk64@gmail.com wrote:
http://hackaday.com/2017/02/05/olimex-announces-their-open-source-laptop/
Rip 'em up, Luke... you know you want to... the quotes wouldn't be in the subject header otherwise...
it's ok chris - i know about this one. appreciated you for mentioning it as this is a list named "arm netbooks" after all.
l.
Aren't you often blowing up at Olimex tho...? ;) I just thought this a good opportunity for more of that. Besides. I brought popcorn.
...sorry, just trying to tease/taunt in a funny-haha way. I'll stop.
My opinion on the subject, for what it's worth: "the perfect is the enemy of the good". Something from Olimex that's "sorta kinda" open-source, may not be "pure", but is *considerably* better than say my Thinkpad X220 with its BIOS whitelist for WiFi cards. I bought a Lenovo WiFi card on eBay a few days ago... mostly because I'm not convinced that my USB floppy drive is still in working order and I didn't feel like finding out with a BIOS flash utility! (Gee whiz, Lenovo, did you HAVE to put the bloody thing under the palmrest...?!) Not my hardest repair, by far (Mom has an HP Compaq TC4400... I swear there's no way to remove the keyboard that doesn't result in breaking the power button bezel in half!) but there's more than a little room for improvement there. An open source laptop means that I can provide feedback on that sort of thing and it'll be heard... right? ;)
Basically, I'm saying, it might not be the whole journey to a truly open-source system -- but it's a step in the right direction and should be recognized and (to an extent) applauded as such. At least they're /trying/.
Meh. I'm actually making my own little laptop-like contraption -- a keyboard with a folding screen, basically. I can describe it, if anyone's at all interested (I'm guessing probably not, which is why I deleted that part out of this particular message). It's based around a Pi Zero (sorry, Luke). Building custom computers is fun :D
--- crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68
On Sun, Feb 5, 2017 at 7:11 PM, Christopher Havel laserhawk64@gmail.com wrote:
Aren't you often blowing up at Olimex tho...? ;) I just thought this a good opportunity for more of that. Besides. I brought popcorn.
sorry - i've not been well (for several months) and simply don't have the time or energy. if people want to fundamentally misunderstand what it is i'm doing so that they can continue with their unethical behaviour, they're entirely at liberty to "explore that space".
...sorry, just trying to tease/taunt in a funny-haha way. I'll stop.
no problem chris - i'm just too exhausted to do so, i have other priorities.
My opinion on the subject, for what it's worth: "the perfect is the enemy of the good". Something from Olimex that's "sorta kinda" open-source, may not be "pure", but is considerably better than say my Thinkpad X220 with its BIOS whitelist for WiFi cards.
... etc. etc. yes.
Basically, I'm saying, it might not be the whole journey to a truly open-source system -- but it's a step in the right direction and should be recognized and (to an extent) applauded as such. At least they're /trying/.
he's being supported (financially) by people who also don't quite fully understand the ethical consequences of their decisions and actions. and that's fine. collectively they're perfectly entitled to "explore that space".
l.
Replying from my phone, in the kitchen trying to troubleshoot a failing disk drive on my Osborne 1. I hope you feel better soon, Luke, and I apologize for taunting you while sick. If I'd known...
Whatever you do, don't work yourself to death. That's not cool.
--- crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68
On Sun, Feb 5, 2017 at 7:36 PM, Christopher Havel laserhawk64@gmail.com wrote:
Replying from my phone, in the kitchen trying to troubleshoot a failing disk drive on my Osborne 1.
ooo an osbouuurne. aawesooome
I hope you feel better soon,
that's gonna take a while... and a lot of research. ongoing.
Luke, and I apologize for taunting you while sick. If I'd known...
... which is why i haven't told anyone: it's been about.... three years so far, with symptoms dating back over thirty?
Whatever you do, don't work yourself to death. That's not cool.
tell me about it :)
l.
Ouch.
Good luck :D
(Off topic, but you seem interested. I'll post this one and then stop unless there's a lot of engagement.)
I have a diagnosis on the Osborne. It has two full-height 5.25" floppy drives ("Mommy, what's a hard drive...?") -- this particular example has one each of the two that Osborne used, Siemens and MPI. The MPI one (a Model 51) has a defective spindle motor... it spins by hand, but not by electricity, so I suspect the windings have shorted out inside. As luck would have it, eBay has exactly one full-height floppy drive, and it's the exact make and model of the deceased one I have! I'll have to save up a little and hope it doesn't get bought out from under me... but I might be able to get it. Time will tell.
On Sun, Feb 5, 2017 at 7:59 PM, Christopher Havel laserhawk64@gmail.com wrote:
each of the two that Osborne used, Siemens and MPI. The MPI one (a Model 51) has a defective spindle motor... it spins by hand, but not by electricity, so I suspect the windings have shorted out inside.
check the spring-loaded contacts (brushes). you'll probably find they've worn to nothing over time.
On Sun, Feb 5, 2017 at 8:19 PM, Christopher Havel laserhawk64@gmail.com wrote:
I'm not opening that motor. It's older than I am.
that's f*****g funny :)
I'm from 1986. It's from 1981 or 1982. Amusingly, the company that made it is at least slightly local... we're in the same state. /If/ they're still around. Unfortunately, I don't see model info for the motor proper, and I really don't fancy replacing it. This is a belt-drive spindle, and I'm really not interested in surgery on that level if I can at all avoid it.
A pity I can't get a loan from somewhere to cover the cost of the replacement drive. I'd buy it right now if I had the money... but I don't :(
On Sunday 5. February 2017 20.25.42 Luke Kenneth Casson Leighton wrote:
On Sun, Feb 5, 2017 at 7:11 PM, Christopher Havel laserhawk64@gmail.com
wrote:
Basically, I'm saying, it might not be the whole journey to a truly open-source system -- but it's a step in the right direction and should be recognized and (to an extent) applauded as such. At least they're /trying/.
he's being supported (financially) by people who also don't quite fully understand the ethical consequences of their decisions and actions. and that's fine. collectively they're perfectly entitled to "explore that space".
I actually thought I'd ask about the software in the comments on their blog post:
https://olimex.wordpress.com/2017/02/01/teres-i-do-it-yourself-open-source- hardware-and-software-hackers-friendly-laptop-is-complete/#comment-24787
I'm guessing that Thomas, the guy responding, might be the guy from Free Electrons, but maybe it isn't. Nevertheless, he seems knowledgeable about the state of play with the A64. (Not that you'd get a particularly coherent message by looking at the linux-sunxi wiki.)
I guess that the sticking point is arguably the "software isn't our problem" attitude, which allows people to claim that something is "open source" (or "software hacker's [sic] friendly" in this case) and then retreat from substantiating the claim. It will be interesting to see if Olimex supplies SD cards with images on them and what kind of source code you can get. They appear to provide such cards for their other products.
Given the post-sales problems with various SoCs and boards, actually delivering a top-to-bottom Free Software distribution should be the minimum just to demonstrate any particular device's credentials in the "openness" department. That's not just an ideological requirement but very much a practical one: no-one wants to have to troubleshoot, say, an overheating system because the software support involves proprietary pixie dust that may or may not be available.
Anyway, look after yourself out there, Luke!
Paul
Lol proprietary pixie dust. Give that man an internet hug.
On February 5, 2017 11:27:14 PM GMT+03:00, Paul Boddie paul@boddie.org.uk wrote:
On Sunday 5. February 2017 20.25.42 Luke Kenneth Casson Leighton wrote:
On Sun, Feb 5, 2017 at 7:11 PM, Christopher Havel
laserhawk64@gmail.com wrote:
Basically, I'm saying, it might not be the whole journey to a truly open-source system -- but it's a step in the right direction and
should
be recognized and (to an extent) applauded as such. At least
they're
/trying/.
he's being supported (financially) by people who also don't quite fully understand the ethical consequences of their decisions and actions. and that's fine. collectively they're perfectly entitled
to
"explore that space".
I actually thought I'd ask about the software in the comments on their blog post:
https://olimex.wordpress.com/2017/02/01/teres-i-do-it-yourself-open-source- hardware-and-software-hackers-friendly-laptop-is-complete/#comment-24787
I'm guessing that Thomas, the guy responding, might be the guy from Free Electrons, but maybe it isn't. Nevertheless, he seems knowledgeable about the state of play with the A64. (Not that you'd get a particularly coherent
message by looking at the linux-sunxi wiki.)
I guess that the sticking point is arguably the "software isn't our problem" attitude, which allows people to claim that something is "open source" (or "software hacker's [sic] friendly" in this case) and then retreat from substantiating the claim. It will be interesting to see if Olimex supplies SD cards with images on them and what kind of source code you can get. They appear to provide such cards for their other products.
Given the post-sales problems with various SoCs and boards, actually delivering a top-to-bottom Free Software distribution should be the minimum just to demonstrate any particular device's credentials in the "openness" department. That's not just an ideological requirement but very much a practical one: no-one wants to have to troubleshoot, say, an overheating system because the software support involves proprietary pixie dust that may or may not be available.
Anyway, look after yourself out there, Luke!
Paul
arm-netbook mailing list arm-netbook@lists.phcomp.co.uk http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook Send large attachments to arm-netbook@files.phcomp.co.uk
Given the post-sales problems with various SoCs and boards, actually delivering a top-to-bottom Free Software distribution should be the minimum just to demonstrate any particular device's credentials in the "openness" department. That's not just an ideological requirement but very much a practical one: no-one wants to have to troubleshoot, say, an overheating system because the software support involves proprietary pixie dust that may or may not be available.
Not only that: if the machine doesn't run a vanilla Linux kernel, there's a terribly good chance that 3 years down the road, you'll still be stuck with the same outdated kernel.
Stefan
Not only that: if the machine doesn't run a vanilla Linux kernel, there's a terribly good chance that 3 years down the road, you'll still be stuck with the same outdated kernel.
Aye, that's my biggest issue with most of these little ARM devices. They don't have mainline support, so try running a device from 3 years ago and you'll find that it's already outdated. Why is that a problem? Well just take a look at the CVE list...
The A20 card should hopefully be a welcome relief from this insanity: https://wiki.debian.org/DebianKernel/ARMMP
On Tuesday 7. February 2017 15.01.51 Stefan Monnier wrote:
Not only that: if the machine doesn't run a vanilla Linux kernel, there's a terribly good chance that 3 years down the road, you'll still be stuck with the same outdated kernel.
Right. Even when vendors actually release the corresponding source code and don't drop in binary blobs, due to the phenomenon I call "the Linux speedboat", if they've forked an old kernel and done things their way, and if someone doesn't get on the case immediately, there's the unenviable task of forward-porting that code to whatever it is that the Linux kernel developers happen to like today. If the vendor didn't manage to throw their code aboard the speedboat at the right time, everyone is left floating in the wake.
An example of this that Luke mentioned before was the Skytone Alpha netbook which has an Ingenic SoC that just happens to be the one that there really is no documentation for, although assumptions can be made that it is similar to others that are documented publicly. You can get the sense of how things are by going through the sources for the shipped *2.6* kernel derivative, but it's an exercise in itself to figure out how all that should be redone for today's kernels.
Maybe such forward-porting is not too hard: I actually had a go, not being a kernel hacker, but I didn't sense any genuine interest from anyone who might be better equipped to help such work along. Shinier things take precedence over sustainability and longevity for such people, I guess. Add in weird bootloader and kernel init tricks and you have to be fond of kernel hacking to be bothered. Plus, I don't really see Linux-the-kernel as the future, anyway.
Paul
On Tuesday 7. February 2017 15.29.59 Matt Campbell wrote:
On 2/7/2017 8:19 AM, Paul Boddie wrote:
Plus, I don't really see Linux-the-kernel as the future, anyway.
Why not? It has such momentum now; it would be a lot of work to port all the drivers to anything else.
There's so much hardware and software churn these days that the driver availability argument probably isn't as important as it once was. So much stuff is probably being done for individual products that people are undoubtedly having to write code for new hardware, anyway. I guess Linux still has the advantages of being something people know and having driver frameworks that people can use.
However, various driver frameworks inside Linux seem to have changed over the years, hopefully for the better, meaning that unless the drivers of interest are on the speedboat (and maybe they were but fell off the back at some point), they're unusable now. Linux doesn't have a monopoly on such frameworks, though: there's nothing to stop other solutions offering something much better.
Meanwhile, all the bravado about monolithic kernels being best and there being no tolerance for any performance decrease whatsoever (not even 15% or whatever the number was) seems absurd in this age of endless exploits and after-the- fact mitigations, with a lot of Linux deployments being done on top of microkernels/hypervisors now, anyway.
Paul
On Tue, Feb 7, 2017 at 3:10 PM, Paul Boddie paul@boddie.org.uk wrote:
Meanwhile, all the bravado about monolithic kernels being best and there being no tolerance for any performance decrease whatsoever (not even 15% or whatever the number was) seems absurd in this age of endless exploits and after-the- fact mitigations, with a lot of Linux deployments being done on top of microkernels/hypervisors now, anyway.
i reaally wish that linus torvalds wasn't such a fuckwit about microkernels (L4Ka) and device-driver projects such as OSKit.
the linux kernel *really* should be the linux kernel i.e. the source code that's *IN* the kernel/src subdirectory of what's in the linux source tree and presently incorporates millions of lines of *driver* source code.
if the device drivers were actually split into their *own* project, a different attitude would be had towards l4ka, oskit and projects like it. u-boot, which has to *constantly* steal code (maintaining it utterly separately) from the linux source tree, could just use oskit or an oskit-like derivative instead. the l4ka project could maintain a SMALL tree of source code instead of having to forward-port its patches year after year (for about a decade so far) because linus's attitude is summarised as "go fuck yourself" if anyone mentions "microkernels" on the linux kernel mailing list.
there would also stand a high probability that the core would remain stable, making it much easier to drop different device-driver flavours on top, and that research project for "real-time-non-shutdown-upgrading-of-drivers" would actually stand a chance of being incorporated mainline as a result.
instead we have efforts like devicetree which have completely failed in their goals of stopping device driver proliferation. with nobody stepping up to unequivocably state that a dtb file is a GUARANTEED fixed device configuration that will, in 25 years, be GUARANTEED to work with a future updated linux kernel source file, all that's happened is that the device driver proliferation problem has moved from c and h files to .dts and dtsi files.
the one upside of dtb files however is a patch (yet to be incorporated) which allows dynamic runtime patching of devicetree to switch in completely new hardware with utterly different specifications.
anyway.
'nuff.
and yes, we have the problem that the EOMA68-A20 has to be released with the sunxi 3.4 kernel because it's the only one that supports all the hardware out-of-the-box.
l.
There's so much hardware and software churn these days that the driver availability argument probably isn't as important as it once was. So much stuff is probably being done for individual products that people are undoubtedly having to write code for new hardware, anyway.
Sure, but is that a result of the hardware actually being that different or is it just because manufacturers aren't actually upstreaming their code? In the latter case, everyone would have to keep rewriting driver code, but not because it doesn't already exist - just because they can't cooperate.
--- crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68
On Tue, Feb 7, 2017 at 4:01 PM, Jonathan Frederickson silverskullpsu@gmail.com wrote:
There's so much hardware and software churn these days that the driver availability argument probably isn't as important as it once was. So much stuff is probably being done for individual products that people are undoubtedly having to write code for new hardware, anyway.
Sure, but is that a result of the hardware actually being that different or is it just because manufacturers aren't actually upstreaming their code? In the latter case, everyone would have to keep rewriting driver code, but not because it doesn't already exist - just because they can't cooperate.
it's a byproduct of the N (designs) times M (processors) problem. Fabless Semi A flatly refuses to mainline their kernel because it costs them too much time and money to do so, passes it OEM B who just compiles it maybe makes a few (GPL-violating modifications) and chucks product out the door.
so we have A muppets chucking out M processors for which there are B dumbasses times N throw-away products and we as software libre developers are left utterly gobsmacked by the dog's dinner mess but also hardly surprised when surveys like this turn out a 98% copyright-violating rate:
https://mjg59.dreamwidth.org/8991.html http://mjg59.livejournal.com/132339.html http://www.codon.org.uk/~mjg59/android_tablets/
the whole reason, then (or one of the whole reasons) why the EOMA68 project exists as far as the linux kernel and software libre compliance is concerned is that it INCENTIVISES collaboration and cooperation between N designers of Cards ***PLUS*** M designers of products-compatible-with-cards.
note that's N *PLUS* M products ***NOT*** N **TIMES** M products.
this is utterly crucial and it's an entirely deliberate strategy.
l.
On Tuesday 7. February 2017 17.17.14 Luke Kenneth Casson Leighton wrote:
On Tue, Feb 7, 2017 at 4:01 PM, Jonathan Frederickson
Sure, but is that a result of the hardware actually being that different or is it just because manufacturers aren't actually upstreaming their code? In the latter case, everyone would have to keep rewriting driver code, but not because it doesn't already exist - just because they can't cooperate.
it's a byproduct of the N (designs) times M (processors) problem. Fabless Semi A flatly refuses to mainline their kernel because it costs them too much time and money to do so, passes it OEM B who just compiles it maybe makes a few (GPL-violating modifications) and chucks product out the door.
Interestingly, although Ingenic (mentioned earlier) have always seemed to target older kernels - you can't really blame them if it's what their engineers know, they can get stuff out the door easily, and the Linux speedboat is not exactly their fault, anyway - at least they released all the code, and the various jz47xx SoCs appear to be supported pretty well in the mainline, thanks to various people forward-porting those code drops.
(I recently promised to test mainline kernels on the Ben NanoNote, and I mustn't forget to get back to that.)
So although there's limited libre operating system distribution support for those SoCs, mostly because of a lack of commitment from those distributions, fuelled by a perceived lack of available hardware to build them natively, the kernel support is probably pretty good. Of course, you can't guarantee that stuff won't be thrown out of the speedboat, but the situation has been surprisingly good for a couple of years at least, I'd say.
Paul
On Tue, 07 Feb 2017 16:10:43 +0100, Paul Boddie wrote:
Meanwhile, all the bravado about monolithic kernels being best and there being no tolerance for any performance decrease whatsoever (not even 15% or whatever the number was) seems absurd in this age of endless exploits and after-the- fact mitigations, with a lot of Linux deployments being done on top of microkernels/hypervisors now, anyway.
Are we waiting for the Hurd?
-- hendrik
On Tuesday 7. March 2017 03.53.26 Hendrik Boom wrote:
Are we waiting for the Hurd?
I don't know what level you're aiming for with that question, but the Hurd is available today. However, as I noted, a lot of deployments of Linux are being done in microkernel/hypervisor environments, so nobody is waiting for anything, really.
Paul
On Sunday 5. February 2017 21.27.14 Paul Boddie wrote:
I actually thought I'd ask about the software in the comments on their blog post:
https://olimex.wordpress.com/2017/02/01/teres-i-do-it-yourself-open-source- hardware-and-software-hackers-friendly-laptop-is-complete/#comment-24787
There's more about the software in the update about the laptop from after FOSDEM:
https://olimex.wordpress.com/2017/02/07/fosdem-and-teres-i-update/
"For the moment the only working Linux Kernel which supports all A64 features is the Allwinner Android Kernel. This Kernel is full of binary blobs, but the only one which could be used for demo. Beside the binary blobs many other things are broken, like the power management, different drivers like the LCD backlight PWM, wake up from suspend, eDP converter is not set properly and works just in 15 bit color mode etc etc. We have the hardware for 50 laptops ready (developer edition), but we do not want to ship before we take care for the software. At other hand we do not want to ship TERES I with Android or RemixOS also which are complete with binary blobs and will never be Open Source."
So the story is a bit different from the answer I got before, which was here:
https://olimex.wordpress.com/2017/02/01/teres-i-do-it-yourself-open-source- hardware-and-software-hackers-friendly-laptop-is-complete/#comment-24795
"You can look at the Linux build scripts at Github and address your software related questions to Linux-Sunxi developers who work on Allwinner devices Linux support, as we are not experts in this field. To the best of my knowledge If you need video with hardware acceleration binary blobs are unavoidable for the moment with A64, but otherwise all other hardware features have sources with no blobs."
Maybe they realised that people will be very upset if they have some weird, GPL-violating vendor distro on their new purchase. Meanwhile, on discussions about alternative SoCs, the EOMA68 campaign update describing the different SoC choices got a mention. Since Olimex already make Rockchip-based products, it surprises me slightly that they aren't pursuing that route as well (or instead).
Paul
arm-netbook@lists.phcomp.co.uk
-
Allan Mwenda -
Christopher Havel -
Hendrik Boom -
Jonathan Frederickson -
Luke Kenneth Casson Leighton -
Matt Campbell -
Paul Boddie -
Stefan Monnier