| 00:02.44 | *** join/#neo900 Xiaoman_ (~Xiaoman@unaffiliated/xiaoman) |
| 00:40.24 | Joerg-Neo900 | Harald and Zecke, those guys are truly incredible |
| 01:19.38 | *** join/#neo900 infobot (ibot@rikers.org) |
| 01:19.38 | *** topic/#neo900 is http://neo900.org | CCCAMP15 lightning talks at http://neo900.org/stuff/cccamp15/ - major: http://neo900.org/stuff/cccamp15/ccc2015talk/neo900-wpwrak_CCC2015.webm | conversations are logged to http://infobot.rikers.org/%23neo900/ and http://irclog.whitequark.org/neo900 | Welcome newest team member metacollin! https://neo900.org/news/neo900-update-2017-09-03 |
| 01:19.38 | *** mode/#neo900 [+v infobot] by ChanServ |
| 02:52.52 | *** join/#neo900 Oksana (~Wikiwide@Maemo/community/ex-council/Wikiwide) |
| 02:57.41 | *** join/#neo900 knttl (~knttl@dyndsl-091-096-237-159.ewe-ip-backbone.de) |
| 03:01.02 | *** join/#neo900 Oksana (~Wikiwide@Maemo/community/ex-council/Wikiwide) |
| 03:40.35 | *** join/#neo900 ArturSha1 (~artur-sha@212.112.100.88) |
| 03:42.39 | *** join/#neo900 pkircher_ (~pkircher@unaffiliated/pkircher) |
| 05:06.30 | *** join/#neo900 DocScrutinizer05 (~saturn@openmoko/engineers/joerg) |
| 05:06.30 | *** mode/#neo900 [+v DocScrutinizer05] by ChanServ |
| 05:06.37 | *** join/#neo900 neo900 (~office@neo900/coreteam/joerg) |
| 05:06.37 | *** mode/#neo900 [+v neo900] by ChanServ |
| 08:18.19 | *** join/#neo900 ahycka (~ahycka@collins.gmr.ssr.upm.es) |
| 08:22.20 | *** join/#neo900 ceene (~ceene@collins.gmr.ssr.upm.es) |
| 08:23.20 | *** join/#neo900 pkircher (~pkircher@unaffiliated/pkircher) |
| 08:32.01 | *** join/#neo900 ecloud (quassel@nat/qt/x-qttwlzkpcqsgxrat) |
| 09:59.48 | *** join/#neo900 ecloud_ (quassel@nat/qt/x-injuxeuwgxolqamj) |
| 10:16.09 | *** join/#neo900 chomwitt (~chomwitt@2a02:587:dc08:a00:1054:96fe:3d37:e5e9) |
| 12:09.23 | *** join/#neo900 Kero (~kero@f135090.upc-f.chello.nl) |
| 12:22.35 | *** join/#neo900 pkircher_ (~pkircher@unaffiliated/pkircher) |
| 12:30.34 | *** join/#neo900 pkircher_ (~pkircher@unaffiliated/pkircher) |
| 12:51.36 | *** join/#neo900 jkepler (~joel@2a01:e35:2f37:400:a1a7:9cd5:791b:76b5) |
| 12:58.00 | *** join/#neo900 pkill9 (~pkill9@unaffiliated/pkill9) |
| 16:23.55 | *** join/#neo900 jcarpenter2 (rofl@2601:441:8680:4631:ece9:161a:66a7:3836) |
| 16:28.54 | *** join/#neo900 Pali (~pali@Maemo/community/contributor/Pali) |
| 17:16.55 | *** join/#neo900 paul_boddie (~paul_bodd@host-37-191-186-243.lynet.no) |
| 17:19.25 | paul_boddie | With regard to FSF RYF certification, take a look at "A Light Bulb Goes Off..." in this article: |
| 17:19.32 | paul_boddie | https://www.crowdsupply.com/eoma68/micro-desktop/updates/fsf-ryf-background |
| 17:51.22 | *** join/#neo900 cc_ (~cc_laptop@2001:910:1033:0:56ee:75ff:fe00:97ac) |
| 17:54.11 | *** join/#neo900 jkepler (~joel@2a01:e35:2f37:400:bac7:21b:b552:1653) |
| 19:35.02 | DocScrutinizer05 | paul_boddie: nice. Thanks a lot! anyway visibility of hw stuff in software tools still isn't really a stringent definition of what can get RYF certified and what can't, in my book. Note that Neo900 doesn't deliver any software, by product definition. We deliver hw docs that suffuce to allow FOSS developers to develop software for our hardware. If a subsystem like (Mali) GPU is _visible_ or not isn't really a criterion for us, rather if |
| 19:35.03 | DocScrutinizer05 | we provide the hw docs for all the peripherals that are needed to operate the device. I don't see a better definition of what we can do to "respect [your] freedom" |
| 19:37.33 | DocScrutinizer05 | from another perspective based on what's been the rationale in that article, we even strongly discourage "normal users" to buy a Neo900 until our primary customer group which is FOSS developers has provided the software that meets "normal users'" requirements. Does that mean our product is not RYF certifiable since our traget group are no "normal people"? |
| 19:40.10 | DocScrutinizer05 | to put it simple: we hand all the freedom to all out customers that we possess ourselves, we have no "secret knowledge" and thus we *can not* ship any software that violates RYF rules |
| 19:48.56 | DocScrutinizer05 | paul_boddie: the distinction between "normal users" and "cmdline-savvy users" makes perfect sense as long as you consider a product shipped with software. For a *hardware* certification it seems to be the wrong approach, a trap many software devels fall for. |
| 19:50.28 | DocScrutinizer05 | it almost seems (and this article confirmed that another time for me) like RYF doesn't certify a certain HARDWARE property of a product but still a SOFTWARE property |
| 20:04.11 | DocScrutinizer05 | is the absence of all RYF-violating software a sufficient criterion to grant RYF-certification or is it not? |
| 20:04.51 | DocScrutinizer05 | I think RYF needs a massively augmented or altered definition of what it actually approves |
| 20:06.26 | DocScrutinizer05 | "could a lightbulb get RYF approved?" |
| 20:07.39 | DocScrutinizer05 | or a ASUS ISa PC motherboard, for that particular consideration |
| 20:08.02 | paul_boddie | I absolutely agree that proper documentation should be provided for anything that respects the user's freedom. |
| 20:08.38 | DocScrutinizer05 | yeah, but that isn't even a complementary criterion of RYF certification |
| 20:09.01 | paul_boddie | In practical terms, getting the sources of an ancient kernel that happens to work is not particularly enjoyable. |
| 20:09.29 | DocScrutinizer05 | actually it seems totally irrelevant what hardware gets provided, as long as just the software shipped with the product meets the RYF criteria |
| 20:10.01 | DocScrutinizer05 | makes it quite impossible to certify a product that's *only* hardware |
| 20:10.12 | paul_boddie | And it may not fully utilise the hardware, either. But having working software does at least test the practical aspects of the freedoms. |
| 20:10.30 | DocScrutinizer05 | which sort of renders RYF ad absurdum |
| 20:11.06 | paul_boddie | Yes, hardware without software almost means that there's nothing to certify. |
| 20:11.33 | DocScrutinizer05 | s/almost// and we fully agree here |
| 20:11.57 | paul_boddie | Well, I was using "almost" to cover myself. ;-) |
| 20:12.27 | DocScrutinizer05 | we provide the DOCS to make your own software, which in my book per definition meets all aspects of RYF spirit |
| 20:13.21 | paul_boddie | But on the topic of PVR/SGX, if it is optional and can be hidden, maybe the FSF are satisfied by that. |
| 20:13.23 | DocScrutinizer05 | we do so since we ourselves don't have any better docs than these |
| 20:14.26 | paul_boddie | From what I understand, a lot of their concerns are about corrupting users by offering them proprietary things. "See no evil" as it were. |
| 20:14.29 | DocScrutinizer05 | I don't know about "hiding stuff", I know the system may run from a stocl linux |
| 20:15.18 | paul_boddie | I have a MIPS CI20 that has PVR/SGX and you don't need it even to run a desktop. So I can imagine the DM3730 being a similar story. |
| 20:18.51 | paul_boddie | Personally, I regard RYF as being about software, not open hardware. "Hardware for Free Software" as it were. |
| 20:22.46 | *** join/#neo900 Kabouik (~quassel@236.34.200.37.customer.cdi.no) |
| 20:27.10 | DocScrutinizer05 | ((similar story)) yes it is |
| 20:29.16 | DocScrutinizer05 | also there are a few efforts to provide a FOSS driver for PVR, not sure how far they got. Is it a reason to not provide hardware with PVR or is ot rather a reason to exactly do provide hardware for those who develop the software for it? |
| 20:30.59 | DocScrutinizer05 | it feels like a chicken&egg problem where FSF rather smashes the egg since they don't like the existing chicken, while they don't even consider which chicken might come out of this egg |
| 20:32.46 | paul_boddie | Indeed. Interesting way of putting it! You have to work with what you've got, I guess. |
| 20:33.14 | DocScrutinizer05 | a good RYF definition for me would be: this hardware has no blockers for free software to run on it |
| 20:33.55 | paul_boddie | Some of these bundled GPUs are a lottery, and there may be no perfect SoC in a given family that has "free everything". |
| 20:34.15 | DocScrutinizer05 | alas I have to insist it's FSF's duty to verify that by finding the software they like |
| 20:34.28 | DocScrutinizer05 | there isn't |
| 20:35.04 | paul_boddie | I can understand that they don't want blobs that provide important functionality where other people get to construct those blobs but not the users. |
| 20:35.32 | DocScrutinizer05 | ;ali GPU was promising, I don't know how far they went with FOSS drivers. I pushed with the guys directly involved, so they remove their copyright from a .h file and put it under GPL. They wouldn't |
| 20:35.44 | DocScrutinizer05 | Mali that is |
| 20:35.50 | paul_boddie | So, saying that no-one gets to use the blobs does make some sense, as long as you don't need the thing the blob is powering. |
| 20:36.26 | DocScrutinizer05 | yes, absolutely |
| 20:36.40 | paul_boddie | The Mali stuff was being reverse-engineered, but the guy apparently got hounded out of his job for his trouble. |
| 20:37.17 | DocScrutinizer05 | (Mali .h file) this was ST-Ericcson Snowball board(?) with NovaThor Soc |
| 20:38.09 | DocScrutinizer05 | I worked for ST-E back when, on NovaThor |
| 20:38.22 | DocScrutinizer05 | on the modem though |
| 20:38.33 | paul_boddie | I don't know the details of the reverse-engineering, but I'm thinking of the Lima project. I know that ARM has non-free drivers that people use. |
| 20:39.26 | paul_boddie | With Lima, fairly recently, it looks like someone from AMD picked it up. So ARM, if they were playing hardball, managed to get a much more established player involved. |
| 20:39.43 | DocScrutinizer05 | afaik ST-E published an official (not a REed) Mali driver, just a .h file was not under GPL, they kept their copyright and license |
| 20:40.22 | DocScrutinizer05 | I didn't follow closely though |
| 20:40.36 | paul_boddie | OK. I didn't know about that, or I don't remember about it. |
| 20:41.26 | DocScrutinizer05 | the PVR driver source code leaked. Nobody touched it for a long while since that is totally colliding with GPL |
| 20:42.25 | DocScrutinizer05 | but anyway OMAP work with the FOSS 2D PVR drivers. 3D is blob |
| 20:42.44 | DocScrutinizer05 | the shader and whatnot stuff |
| 20:43.14 | DocScrutinizer05 | openGL-ES(-2?) 2D parts |
| 20:43.51 | paul_boddie | Yes. If you only need a framebuffer then you can ignore the 3D stuff, even the entire PVR stuff, I think. |
| 20:44.31 | DocScrutinizer05 | I'm not sure about compositor, a part of PVR |
| 20:44.36 | paul_boddie | I see that Nikolaus is trying to make the PVR stuff easier to deal with for those who have/want to. |
| 20:45.37 | paul_boddie | Actually, your points about documented hardware apply nicely to PVR. The programming manuals I've seen for products with PVR just have "white paper" details for the PVR hardware. |
| 20:45.49 | DocScrutinizer05 | yes, Nikolaus and Pandora/Pyra folks have a rich historical knowledge of PVR driver stuff |
| 20:46.07 | paul_boddie | So, if RYF were about documentation, the PVR stuff would fail on that alone. |
| 20:46.40 | DocScrutinizer05 | yes, but then you don't need it |
| 20:46.44 | enyc | did you see Wizzup etc...have some beta newer software for n900 ? |
| 20:46.46 | paul_boddie | Nikolaus did notice some more documentation about PVR not that long ago, but it was difficult to see if it changed anything about free drivers or not. |
| 20:46.53 | DocScrutinizer05 | yes |
| 20:46.54 | enyc | devuan with h-d and all that |
| 20:47.02 | enyc | using newer kernel |
| 20:47.12 | enyc | presumably be easier to get that running on neo900 similarly .... |
| 20:47.16 | DocScrutinizer05 | parazyd just pinged me about it this very moment |
| 20:47.41 | DocScrutinizer05 | what's running on N900 also runs on Neo900 |
| 20:47.42 | enyc | thats' all going to be good news.... |
| 20:49.29 | enyc | but what about layout/production help for proto_v2 ? |
| 20:50.09 | DocScrutinizer05 | enyc: we need a lot of things, see ToDo list |
| 20:50.31 | DocScrutinizer05 | more preorders is one of them, and for that prolly a kickstarter |
| 20:50.58 | enyc | DocScrutinizer05: i foresee checiken-ad-egg problem? |
| 20:51.02 | DocScrutinizer05 | we also need metacollin back |
| 20:51.28 | enyc | DocScrutinizer05: origianlly, proto_v2 success would give much more credance to project being do-able, to put out for thing slike that. |
| 20:52.23 | DocScrutinizer05 | yes, this develops again into a chik&egg prblem which I hoped I had finally solved by contracting metacollin so I could "leave the project alone" for urgently needed reconvalescence |
| 20:52.56 | enyc | whow unknown is the metacollin situation? |
| 20:53.03 | enyc | is it likely to be resolved? |
| 20:53.22 | DocScrutinizer05 | I have no funds and no energy and no time and not the mental capacities to *again* solve it |
| 20:53.42 | DocScrutinizer05 | no idea |
| 20:53.49 | DocScrutinizer05 | no answer to my email |
| 20:54.16 | DocScrutinizer05 | he might be in holiday and return tomorrow, or (God forbid) been hit by a bus |
| 20:54.28 | enyc | or blown-up on a bus, or whatever |
| 20:55.56 | DocScrutinizer05 | sorry afk |
| 21:19.55 | crox | https://electronics.stackexchange.com/users/33870/metacollin <= " Last seen 53 mins ago " |
| 21:23.16 | DocScrutinizer05 | hmmmm |
| 21:26.01 | DocScrutinizer05 | /msg nickserv info metacollin <= [Notice] -NickServ- Last seen : Dec 07 02:24:04 2017 (7w 5d 18h ago) |
| 21:26.22 | DocScrutinizer05 | sorry I really need to be afk now |
| 21:40.55 | paul_boddie | See you again, doc! |
| 23:06.01 | Oksana | metacollin's location: "Strongly inaccessible" Newest posts on electronics.stackexchange : Jan 16 |
| 23:50.24 | *** join/#neo900 luke-jr (~luke-jr@unaffiliated/luke-jr) |