thats the funny thing about inboxes and bills. If you ignore them they dont go away, they just get bigger. There's a bunch of jokes here I refuse to make.
Marcel wrote: > That's the point - I was away from home the last week only and kinda shocked > found the om-community and debian-user-german folders with 320 mails each > when I came back which is nothing compared to your 1800 mails... :) > > -- > Marcel > > Am Monday 06 April 2009 01:08:24 schrieb Steve Mosher: >> thanks. During march I got so effin buried in other stuff that my >> community posting went to hell. I sat there looking at my community >> inbox grow and grow. And I thought "I rather open my cell phone bill >> than plow through 1800 community mails" but in the end you pay your cell >> phone bill and plow through those mails. As long as I keep the inbox >> empty every day, its a joy to read and respond. >> >> Gunnar AAstrand Grimnes wrote: >>> Nice posts Steve! This is what a community oriented company works like! >>> Frequent, on-time, interesting and well-written emails from the inside! >>> >>> Keep it up! >>> >>> - Gunnar >>> >>> Steve Mosher wrote: >>>> Good comments All. >>>> >>>> Let me inline some answers/explanations. >>>> >>>> Lothar Behrens wrote: >>>>> Hi, >>>>> >>>>> I am mostly reading and sometime writing here. If it was useful or >>>>> useless - I don't know. But anyway. >>>>> >>>>> Let me arse around with some stupid ideas :-) >>>>> >>>>> What is a open phone? >>>>> >>>>> Is it only open source software or is it also open hardware? >>>>> >>>>> If software could be developed virtually at any place and from any >>>>> person, why don't we do the same for >>>>> hardware? >>>>> >>>>> Ok I cannot buy expensive equipment to test hardware that I may have >>>>> developed, but I virtually could >>>>> develop hardware. But many developers at one subject could spend money >>>>> for a rent to let one of the >>>>> team do outstanding tests. >>>> At the begining of Sean's presentation you will see two slides: >>>> 1. a picture of Steve Ballmer ( the evil empire) >>>> 2. A picture of paul Otilinni ( intel) >>>> >>>> And the point sean made about this was as follows; If a 15 year old >>>> kid tells ballmer that he has developed a technology that will disrupt >>>> microsofts business, Ballmer would do well to listen to him. Why? >>>> because with a computer and a compiler it is possible to disrupt their >>>> business or at least make there lives uncomfortable. Long ago back in >>>> 1994 before MS had any 3D api in windows there were three small UK >>>> companies that had 3D apis for the desktop: argonaut; Rendermorphics; >>>> and Criterion ( i worked there). These were really very small companies >>>> and what we did was keep gamers in DOS, while MS wanted to move gaming >>>> to windows. We disrupted their plans to move important apps into DOS. >>>> So they paid attention to us. I remember sitting with Alex st John >>>> and eric engstrom as they discussed what was originally called the >>>> "manhatten project" later to be directX. And the phrase disruptive >>>> technologies came up over and over again. One guy even had a folder on >>>> his desktop labeled disruptive technologies. In the end, MS >>>> aquired rendermorphics and it became Direct3D The point: in the >>>> software world, a kid and an idea is potentially a powerful force. The >>>> history of this is covered in this book: >>>> >>>> Drummond, Michael (November 2000). Renegades of the Empire: How Three >>>> Software Warriors Started a Revolution Behind the Walls of Fortress >>>> Microsoft. California: Three Rivers Press. ISBN 978-0609807453. Covers >>>> the early years of DirectX development within Microsoft, including the >>>> acquisition of RenderMorphics. >>>> >>>> The bottom line on software is this: the business of software is easy >>>> to disrupt because the barriers to entry ( the cost of tools) is >>>> comparatively low. >>>> >>>> Now, lets look at hardware. If that same 15 year kid came to Paul >>>> Otillini and said he had technology that would disrupt Intels business >>>> what would paul do. He'd ask the kid who his investors were? ask what >>>> EDA tools did he use? Synopsis? did he have a cycle accurate C-SIM of >>>> the chip? Who was his fab? was he planning an ASIC flow or COT flow >>>> for the chip, what tools did they use for floor planning, routing etc. >>>> The cost of these tools and the cost of proving something in silicon >>>> are in the millions of dollars. Hardware is hard. The barriers to entry >>>> are huge, not only IP barriers but sheer cost. >>>> >>>> >>>> So, Sean's basic point in those first two slides is that >>>> entering/disrupting the software business is orders of magnitude >>>> easier than entering the hardware business. >>>> >>>> This of course is an extreme comparison, used however to make a >>>> point. We should be on guard against notions and attitudes that >>>> characterize the hardware business as easy. At OM we entered the >>>> hardware business at the system level. Not designing chips of course, >>>> but one level up from that: designing >>>> hardware systems. Here too, however, you see costs and risks that >>>> form barriers to entry. For example, the test lab we maintain for >>>> testing phones has 5Million dollars of equipment. A prototype >>>> run of an evaluation board can cost 50K USD. 20 phones: 50K. >>>> >>>> I use this analogy. You write your code in a series of units. >>>> you unit test them. Then you do your first integration. >>>> You set up your make files and I charge you 50K to hit return. would you >>>> hit the compile button? >>>> >>>> We've all sat there and said, just compile it, see if works. That's >>>> easy in software. In Sean's presentation you'll see a slide. >>>> "gcc GTA02v5 doesnt work" what that means is this. There are perhaps >>>> some unconcious attitudes people have carried over from the software >>>> world that will jump up and bite them when they start to work in the >>>> hardware world. I'll use another metaphor. Building hardware requires >>>> a "waterfall" design process, at least in my experience. In the software >>>> world, outside of DOD and NASA, we'd be hard pressed to find projects >>>> that followed a strict waterfall model. >>>> In a waterfall model you start with requirements. And you don't write >>>> a line of code until requirements are 100% done and complete and signed >>>> off. Once the requirements are done. They don't change. Then, and only >>>> then you get to do design. You are still not writing any code. when >>>> design is 100% complete, you move to implementation. If you're not >>>> familiar with this approach I can tell you it's a PITA. But it has its >>>> advantages: a requirements defect found late in the game ( in >>>> verification for example ) can cost 50-200X more to fix than if it was >>>> fixed in the requirements phase. This holds especially true for embedded >>>> software. >>>> So what's the result if you don't use a waterfall model in >>>> hardware development. Whats the cost if you find a requirements defect >>>> or a design defect ( glamo? )when you do that prototype run? 50K >>>> minimum, plus a redesign. Take the appendix out--perform a glamoectomy? >>>> ask Werner about the design implications of that on WIFI. And >>>> see my comments below about design and diving into peanut butter. >>>> >>>> That means this: if you are designing hardware or doing hardware system >>>> integration you would be well advised to follow a waterfall model. Any >>>> other approach is prone to excessive delays and costly recamps. Just >>>> read the list and see the number of people who are suggesting >>>> implementations for a new GTA03 design. The rush to implementation-- use >>>> this processor.. no use that processor, camera or no camera, resistive >>>> or capacitive, keyboard or touch.-- ALL signs to me of a lack of >>>> appreciation for the complexity and cost involved in doing hardware. I >>>> got a hammer your problem must be a nail. I'll give you >>>> another example. During the course of many discussion about GTA03 and >>>> GTA04 both here and inside OM, both before and after the demise of GTA03 >>>> I see a pattern of discussion and problem solving that is, in my mind, >>>> part of the problem. Those discussions go like this: "what if we take >>>> the GTA03 and stick it in the 02 case?" which leads to "but where will >>>> the camera go?" which leads to "do we really need a camera?" and so time >>>> and energy is spent on this "solution" In the end, marketing looks at >>>> that and says "who took the fucking camera out!" that's not an actual >>>> example, but you get the idea. >>>> >>>> The bottom line is this. To do a GTA03 right means starting with >>>> requirements. 100% complete requirements. set in stone... or quick >>>> setting cement. We had a couple of sayings in the jet fighter business. >>>> Design is like diving into a swimming pool of peanut butter. You better >>>> pick your landing zone right because there not much ability to swim >>>> around after you hit. And also, this: "engineers almost never make >>>> mistakes, the guys who set requirements do." >>>> >>>>> Isn't it possible to also develop hardware collaboratively? >>>> In one sense this is trivally true. hardware development is >>>> inherently collaborative. But I suppose you mean is it possible >>>> to do it in an open fashion. It maybe. But if the requirements process >>>> and design process is not rigorous and well defined you end up >>>> with expensive implementation problems. And if you don't have team >>>> consensus, then it's very problematic. Forking software is easy. >>>> Forking hardware is forking hard. The best example I can use is >>>> forking ASIC design. You can do a big chip with lots of functionality >>>> and then fork off 'defeatured' versions, but that forking needs to >>>> be designed in.and it may come with a cost. the same holds true >>>> for modular hardware designs. what's easy with lego blocks aint so >>>> trivial when it comes to EE design. >>>> >>>>> There are many hobby projects around in the net. These are really not >>>>> at a level as OpenMoko or in >>>>> general a device such as a mobile phone, but what is if we could get >>>>> preproduced components such >>>>> as the gsm 'plugin board'? >>>> The OM designs all used "modules" for GSM and modules for things like >>>> WIFI and BT as opposed to "down" designs or chips on PCBs. The diffculty >>>> is not in finding components or modules and system level design is >>>> fairly straight forward. The real difficulties come in areas like RF >>>> design ( a black art of sorts) and in the marriage of mechanical and EE. >>>> >>>>> I mean, if I am a crack in developing gsm stuff, but don't like to buy >>>>> a complete phone for it, I probably buy >>>>> the gsm module, say, with an interface connectable anyhow to a PC. >>>> 3G dongle >>>> >>>>> What I also think about, is why are there only PDF schematics >>>>> available? >>>> Well, we are looking at making the gerbers available under a licencing >>>> program. Stay tuned. >>>> >>>>> I have only heared about the dash derivat of openmoko device. Is it >>>>> because there is only a PDF available? >>>> No, we designed DASH electronics using Our existing design. As Sean >>>> points out in his presentation, this project proved to be a distraction >>>> from our main goals in that time period. Why? here's a solution for >>>> Dash, just take the existing design and make a few changes and recompile >>>> the hardware! >>>> >>>>> If it is possible to delegate hardware development tasks to the >>>>> comunity why isn't it done yet? >>>> I'm in the process of exploring this with a new list. However, you >>>> need to understand the process: >>>> 1. requirements: the community can help here. >>>> 2. Design: the community can help here: >>>> 3. Implementation: Build EVT boards. This is where you need money and >>>> infrastructure. So, if the community wanted to Build and buy EVT >>>> boards ( I actually suggested this to Sean) then that could happen. >>>> But an EVT board costs about 2 grand. I suppose if we had 20+ volunteers >>>> who wanted to do this, it could be done. But remember EVT boards often >>>> end up not working. Build 20, get 15. >>>> >>>> I'm not saying that it's impossible, but everyone who gets involved >>>> needs to know the mountain in front of them. >>>> >>>> And we havent even discussed ID. ID could be developed by the community. >>>> In fact, we had planned a design contest for alternative cases for the >>>> GTA03. With volunteer efforts you could probably make it through a first >>>> pass at ID and mech. here again samples are costly. early samples are >>>> done on CNC machines, later rapid prototypes (25K) and hard tooling >>>> is well over 100K. >>>> >>>>> So when also open up the real circuit 'source code' - the real CAD >>>>> files, would it give the real goal - the open mobile phone - a real >>>>> push? >>>> I'm looking into that. There is no fundamental objection to that. the >>>> terms and conditions are what I need to examine. Also, many people >>>> question the importance of gerbers. If you just want to copy the design >>>> as is and send those files out to have a PCB built, then having the >>>> gerbers saves you the time of reverse engineering from the schematics >>>> or reverse engineering from the actual board ( seen that done) but >>>> gerbers dont give you a theory of operations and design changes to a >>>> design you dont understand can have knock on effects: see the >>>> glamoectomy. >>>> >>>>> Then if there are some results that have a chance to become a real >>>>> 'next' phone, a company like openmoko could >>>>> think about producing some prototypes. So the company has a reduced >>>>> cost. >>>> without looking at actual numbers I would say 20% of the cost is >>>> in requirements and design and 80% in implementation, verification, >>>> production, test, and maintennce. Again, we are thinking down some >>>> similar paths, so your comments are welcomed. >>>> >>>>> There is one really good electronics project: The internal debug board. >>>> Ya I love werners stuff. Now, for a while, the GTA03 was going to have >>>> an internal debug board. The words flew kinda hot and heavy on that one. >>>> less than 50% of all buyers get a debug board. Should we include >>>> internal debug capability on every GTA03? I won't revisit that debate >>>> here. >>>> >>>>> This is only one sample that there are hardware developers out there. >>>>> Give them more food. >>>> That's what were are going to try to do. >>>> >>>>> My education in 1987 till 1990, was electronics engineering. I do not >>>>> any more practice in that area. So I stuck in some conflict >>>>> not to start any electronics projects, because I have the glue the >>>>> project will be a one man show and keep a hobby project. But >>>>> if there would be a collerative project I could join, I propably >>>>> would. And may it only getting more practice in laying out PCB boards >>>>> whose schematics other developers have created. >>>> Ok.. here comes a question. What layout tools? are there open source >>>> layout tools ( one hopes) and if not then what tool do we pick? >>>> Essentially, you are pitching the idea I'm going to try to get going. >>>> I'll make an announcement about it shortly, but my plate is pretty full >>>> and I can only volunteer a couple hours a day to help organize and guide >>>> it. >>>> >>>>> If that would be possible, then it would be a real open phone :-) >>>>> >>>>> End of arsing around. Is there a potential to create a hardware >>>>> development comunity? >>>> I think so. no harm in trying. >>>> >>>>> To avoid that each individual will start its own variant we could >>>>> using a vote system before any direction is done, say wich formfactor >>>>> is used, for sample. >>>> The voting approach will be discussed. Basically I dont believe in >>>> letting idiots vote. You dont want me voting on your layout and >>>> convincing everyone with my superb rhetoric that your 8 layer design >>>> can be accomplished in 2 layers.. you get my drift. The community will >>>> have to have SME ( subject matter experts) They will have to have some >>>> undemocratic powers. my view at least. >>>> >>>>> Sean: This would propably help continue GTA3 development. The risk to >>>>> produce it, would only invest some inspections of a new design >>>>> and doing integration tests. And even this could be donated. >>>> I asked sean the same. We are going to set up a mailing list at >>>> openmoko.org to get this started. >>>> >>>>> Dont let a great idea die. Delegate hardware development activities if >>>>> possible. We are a comunity. >>>>> >>>>> Lothar >>>>> >>>>> Am 05.04.2009 um 11:18 schrieb Johny Tenfinger: >>>>>> It seems like "plan B" doesn't share anything with phones and... >>>>>> Linux ;( >>>>>> >>>>>> 2009/4/5, David Reyes Samblas Martinez <[email protected]>: >>>>>>> only add that replies are quite unfair to a any free project whatever >>>>>>> it succeed or not. >>>>>>> >>>>>>> 2009/4/5 David Reyes Samblas Martinez <[email protected]>: >>>>>>>> Yes very sad wrong titular "No More OpenMoko Phone " and very >>>>>>>> discorageus comentaries :( >>>>>>>> >>>>>>>> 2009/4/5 robert lazarski <[email protected]>: >>>>>>>>> http://mobile.slashdot.org/article.pl?sid=09/04/04/228240&art_pos=2 >>>>>>>>> >>>>>>>>> Not pretty. As someone who has been lurking on this list for 1 1/2 >>>>>>>>> years, patiently waiting to buy a phone but trying to avoid buzz >>>>>>>>> fix >>>>>>>>> parties if I could help it, I suppose its not surprising. On the >>>>>>>>> positive side, I'll stick around to see what happens with plan b >>>>>>>>> - if >>>>>>>>> that is there's anyone left to develop it and its not vapor. I like >>>>>>>>> the idea of Freerunner, just not its execution. I'd like to >>>>>>>>> surprised >>>>>>>>> though and see a turn around. And yes, I'll probably buy one that >>>>>>>>> ships without hardware problems. >>>>>>>>> >>>>>>>>> - R >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> Openmoko community mailing list >>>>>>>>> [email protected] >>>>>>>>> http://lists.openmoko.org/mailman/listinfo/community >>>>>>>> -- >>>>>>>> David Reyes Samblas Martinez >>>>>>>> http://www.tuxbrain.com >>>>>>>> Open ultraportable & embedded solutions >>>>>>>> Openmoko, Openpandora, GP2X the Wiz, Letux 400, Arduino >>>>>>>> Hey, watch out!!! There's a linux in your pocket!!! >>>>>>> -- >>>>>>> David Reyes Samblas Martinez >>>>>>> http://www.tuxbrain.com >>>>>>> Open ultraportable & embedded solutions >>>>>>> Openmoko, Openpandora, GP2X the Wiz, Letux 400, Arduino >>>>>>> Hey, watch out!!! There's a linux in your pocket!!! >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Openmoko community mailing list >>>>>>> [email protected] >>>>>>> http://lists.openmoko.org/mailman/listinfo/community >>>>>> _______________________________________________ >>>>>> Openmoko community mailing list >>>>>> [email protected] >>>>>> http://lists.openmoko.org/mailman/listinfo/community >>>>> -- | Rapid Prototyping | XSLT Codegeneration | http://www.lollisoft.de >>>>> Lothar Behrens >>>>> Heinrich-Scheufelen-Platz 2 >>>>> 73252 Lenningen >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> Openmoko community mailing list >>>>> [email protected] >>>>> http://lists.openmoko.org/mailman/listinfo/community >>>> _______________________________________________ >>>> Openmoko community mailing list >>>> [email protected] >>>> http://lists.openmoko.org/mailman/listinfo/community >> _______________________________________________ >> Openmoko community mailing list >> [email protected] >> http://lists.openmoko.org/mailman/listinfo/community > > _______________________________________________ Openmoko community mailing list [email protected] http://lists.openmoko.org/mailman/listinfo/community
