Hi Sven, > Am 18.04.2019 um 15:09 schrieb Sven Dyroff <s.dyr...@phytec.de>: > > Hello Nikolaus, > > >> Neo900 planned a couple of stuff that would have domesticated that beast > >> at least up to a certain level. > >> Such smart things like measuring its power consumption and validate if > >> it's reasonable compared with > >> its current instructed actions with the option to automatically switch it > >> off. > > > > Well, I have my own opinion on this... > > It is: this stuff is useless. > > > > The reason is that nobody can test if these detectors really work. > > To test a fire alarm you must make some smoke. But how can you trigger the > > modem to make rogue activities to check if they are detected? > > I completely disagree! > > The fact that the fundamental nature of rogue activities is that they CANNOT > be triggered by you, because the roguishness persist exactly in the fact that > it will be triggered by others, consequently results in the NEED for exactly > this stuff. > > The proceeding is quite simple: You claim anything to be weird that you don't > understand. Just an ordinary trial-and-error approach. And this stuff is > exactly what you need for that!
Well, this will give 99% of the time false positives, at least initially. My key argument is that it may not be possible to learn by trial and error how to distinguish because the distinguishing information is missing... If you are not looking precisely at smoke (but e.g. sound and illumination) you can't learn when to ring a fire alarm. To give a specific example: how can a current consumption detector or RF activity measurement distinguish between a cell handover which leaks 2-3 bytes private data from one without sending that. IMHO, a good detector should be able to report exactly that. But if you claim that there is a detector you must be able to exactly tell what it detects. So there is no detector but there are devices from which it is believed (!) that they may provide enough information. That is my criticism here: there is no proof. Just a believe. And there can't be a proof because the fire alarm can't be tested at all. Therefore I believe (yes it is also a believe :-) more in encryption technology than the extra hardware planned for the Neo900. > > >> It just needs a look behind the big firewall of China. I claim the > >> situation there is already apocalyptic. > >> And it's no dream anymore. It's already damned reality. > > > > Yes, I know. But that is not a technological issue. Technology was second. > > The situation is there for 30 years or more... > > The book "The Shockwave Rider" meanwhile is more than 40 years old and the > described scenario is independent from any concrete political situation. It > rather depicts a general interplay between evolution of technology on the one > hand and degenerating of freedom of society on the other hand. So there's no > reason not to fear that this could also happen to us. In fact it's just a > question of time. > > >>> Therefore we simply must restart with something as a big team. > >> > >> Yes, indeed. But you'll get such a big team only if you can provide a > >> clear aim. > >> One of the last Sourceforge Newsletters provided a very interesting > >> article about > >> the needs how to build a good and effective Open Source team. > > > > Yes, I remember similar articles. A key aspect is that people must see a > > benefit with the results. > > Either a personal for hobbyists (could be learning something, appreciation, > > presenting as a good > > software developer) or a commercial one (saves money for the company they > > are working for). > > I heavily doubt that a pure materialistic benefit is the reason for the need > of a clear outlook. Ah, no. The clear outlook is also needed of course. But the outlook must show some benefit to contributors. On the other hand, what Outlook does the Linux kernel have? It is just a pile of everything contributors submit and maintainers accept (with quite different and contradicting policies). But it has a clear benefit for silicon vendors like Intel, TI, Broadcom, etc. so that they pay developers to contribute to Linux. Because it is still cheaper for them to pay contributions than developing and maintaining their own OS. This is where it saves the silicon companies a lot of money and that makes kernel.org a steadily growing and well financed project. > Instead of that I assume that the real need for it is a result out of the > individual fun factor of programming: You need a means for synchronizing all > the individuals in some way. So you need to place milestones and you need to > make transparent if or how much they have been reached in order to prevent > exactly that diffusing that you have here in this project. Here again, Linux kernel has no milestones if taken in total. Yes, some subprojects and development groups have their own milestones, but it does not seem widespread. Things are developed and discussed and developed over time without schedule. And at some point of time it appears to be "good enough" to the maintainers and then it is integrated to the benefit of everyone. So they have a central repository and a maintainer organization for quality gates, but that is all. I don't know how other big projects work, so this may be an exception. > Once again I claim that it was a failure to declare it as an project for > arbitrary tinkering on anything that vaguely looks or acts like a phone. > > > Well, my vision for QtMoko2 would be: > > > > * modernized base: latest kernels, latest development tools, latest Debian > > as basis > > * remove bugs - just make it work out-of-the-box > > * modularized: just apt-get install what you want to have (or even write a > > GUI app for that - sort of an Appstore) > > * runs on different hardware (existing and upcoming) > > > > IMHO a lot of aspects to work for. > > +1 > > > In the early days, the benefit of QtMoko was to get something which did not > > exist before (besides iOS 1.0 and Android 0.5). > > Ooops. Did I mess up something? As far as I know OpenMoko was the first > smartphone on the market and Apple, Google and Co. did unscrupulous > cherrypicking from its ideas. Am I wrong here? Almost (although I would prefer the opposite). Apple did develop the iPhone in parallel and did announce the iPhone 1 on 9. January 2007 just weeks after OpenMoko announced the GTA01 (November 2006). If you watch the iPhone announcement: https://www.youtube.com/watch?v=wGoM_wVrwng it shows how far ahead they already were with respect to user interface and device concept design. That such devices are to come was "almost in the air" in that year. Only Google came a little later with Android (September 2008). I also know from well informed sources that Siemens mobile did have a touch screen smartphone behind the curtain in 2006 shown to telecom operators. And not to forget that there already were Windows CE Pocket PC Phone Edition based PDA/Phone hybrids since 2003 (e.g. HP iPAQ h6315) and Sharp did experiment with integrating GSM into their Zaurus series (it was already available with external CF GSM cards - I am still in possession of one). If we are looking for the really first "smartphone" it was IMHO the Nokia 9000 communicator from 1996. But none of the modern giants did wait for OpenMoko to trigger their development. Unfortunately. The only difference which still remains is the openness. And that is where we are back to QtMoko2. It shares a lot of similarities in user interface design with iOS and Android, but is fully open! It only lacks a good AppStore - and the software quality and maintainance level. The latter is the reason why you can't give a QtMoko device to your Grandma - because it does not work smooth enough for connecting with the Grandchildren. BR, Nikolaus > > Best regards > Sven > > > > > > Von: "H. Nikolaus Schaller" <h...@goldelico.com> > An: List for communicating with real GTA04 owners > <gta04-owner@goldelico.com> > Datum: 17.04.2019 20:48 > Betreff: Re: [Gta04-owner] QtMoko2 > Gesendet von: "Gta04-owner" <gta04-owner-boun...@goldelico.com> > > > Hi Sven, > > > Am 17.04.2019 um 20:31 schrieb Sven Dyroff <s.dyr...@phytec.de>: > > > > Hello Nicolaus, > > > > > Well, I don't fear the modem. > > > > I do. And I exactly know why. > > > > > As soon as you want to make use of it you have to turn it on and accept > > > that it is not trustworthy and can't be. > > > > Neo900 planned a couple of stuff that would have domesticated that beast at > > least up to a certain level. Such smart things like measuring its power > > consumption and validate if it's reasonable compared with its current > > instructed actions with the option to automatically switch it off. > > Well, I have my own opinion on this... > It is: this stuff is useless. > > The reason is that nobody can test if these detectors really work. > To test a fire alarm you must make some smoke. But how can you trigger the > modem to make rogue activities to check if they are detected? > > > > > > As long as it is a separate one connected through e.g. USB and some AT > > > commands for control. > > > > We all agree that this is essential. But I claim that this is by far not > > enough. With the GTA04 you just had good luck with your modem choice by > > accident. > > > > > At least in the dreams of some IoT evangelists. > > ... > > > Well, I don't share your pessimism and apocalyptic view here... > > > > It just needs a look behind the big firewall of China. I claim the > > situation there is already apocalyptic. And it's no dream anymore. It's > > already damned reality. > > Yes, I know. But that is not a technological issue. Technology was second. > The situation is there for 30 years or more... > > > > Especially if it seems to end in a "we can't do anything about it". > > > I believe we can do something. It is not easy and does not go over night. > > > But small steps are small steps if they go to the right direction. > > > > Just ask Chinese activists how much they can do. > > > > > Therefore we simply must restart with something as a big team. > > > > Yes, indeed. But you'll get such a big team only if you can provide a clear > > aim. One of the last Sourceforge Newsletters provided a very interesting > > article about the needs how to build a good and effective Open Source team. > > Yes, I remember similar articles. A key aspect is that people must see a > benefit with the results. Either a personal for hobbyists (could be learning > something, appreciation, presenting as a good software developer) or a > commercial one (saves money for the company they are working for). > > In the early days, the benefit of QtMoko was to get something which did not > exist before (besides iOS 1.0 and Android 0.5). > > > Unfortunately I don't have it anymore. But I remember that a clear outlook > > was one of the basic requirements. > > Well, my vision for QtMoko2 would be: > > * modernized base: latest kernels, latest development tools, latest Debian as > basis > * remove bugs - just make it work out-of-the-box > * modularized: just apt-get install what you want to have (or even write a > GUI app for that - sort of an Appstore) > * runs on different hardware (existing and upcoming) > > IMHO a lot of aspects to work for. > > > > > Best regards > > Sven > > > > P.S.: Did I already mention at any time that I like QtMoko very much? ;-) > > Not that I am aware of :):) > > BR, > Nikolaus > > _______________________________________________ > Gta04-owner mailing list > Gta04-owner@goldelico.com > http://lists.goldelico.com/mailman/listinfo.cgi/gta04-owner > > _______________________________________________ > Gta04-owner mailing list > Gta04-owner@goldelico.com > http://lists.goldelico.com/mailman/listinfo.cgi/gta04-owner _______________________________________________ Gta04-owner mailing list Gta04-owner@goldelico.com http://lists.goldelico.com/mailman/listinfo.cgi/gta04-owner
