Hi, On Sun, May 4, 2008 at 3:30 PM, Hans J. Koch <[EMAIL PROTECTED]> wrote: > Am Sat, 03 May 2008 20:53:53 +0300 > schrieb Igor Stoppa <[EMAIL PROTECTED]>: > >> > I disagree. Any closed part in a Linux system forces developers to >> > implement stupid wrappers and workarounds somewhere. If I'm forced >> > to use a certain kernel or glibc version, it's not an open system. >> >> Probably i was not clear: i'm just saying that if a new kernel comes >> out and the only impediment in using it is that the proprietary >> module is not compliant, a new module compiuled against the new >> kernel should be made available. > > Proprietary modules are a GPL violation (though this is sometimes > tolerated) and taint the kernel. You loose the kernel community's > support if you use them. That support is more important than Nokia's > support. > > And I doubt you can supply modules for all the kernel flavors out > there. Today, I might want to use 2.6.26-rc1 (came yesterday), Linus' > git tree (changes every few hours), or linux-next (changes daily). >
Thats pretty much the key point for me in this discussion. If you really want to be able to foster an independent linux distro (or more than one), then you need/want to be able to control and upgrade your kernel. Most of the kernel and system components are open or enough is known to provide basic usage, but an 'internet tablet' with proprietary wifi firmware that is not accessible in newer kernel version is a killer. At the moment i am happy with usb networking for my experiments with newer kernels, but the basic function of the device is crippled. Not complaining, and I do not know if it is feasible to supply builds of umac.ko for later kernel versions, but I think this is a barrier to really fostering a 'community distro'. Cheers >> >> > > And I think it would be only fair that, having Nokia enjoyed the >> > > benefits of taking these shortcuts (mostly can be summarized in >> > > not using better/more open HW), now it will take also the pain of >> > > providing continued support for the closed components. >> > >> > That is just additional cost caused by the closed components. Use >> > open components and use the money for something more useful. >> >> And I thought that I was writing in good english. Poor me. I'm talking >> about the past and you want open components. Is Nokia supposed to go >> around and replace all the sold devices with open hw? > > No, certainly not. Please excuse _my_ bad English ;-) > We all made our experiences with Linux devices entering the mass market > in the last few years. Nokia played an important role here, and the > internet tablet devices and the Maemo project are definitely very > positive things I'm grateful for. > > On the other hand, the enthusiasm I had at the beginning has vanished. > I found out that I cannot do whatever I like with the device because > important parts are closed and proprietary. I will certainly never buy > such a device again. I've an N770 and would be interested in the N810, > but will not buy it for this reason. > > Of course I know that 99% of the internet tablet users don't want to do > system programming for their devices. But even they should know that > blocking programmers always means blocking (some) interesting software > alternatives. > >> >> > > >> > > This is my personal opinion - not to be taken as a promise or >> > > plan - but as an advice in what the community could do/demand to >> > > keep the old devices alive. >> > >> > I'll continue demanding open hardware. I'm really fed up with >> > so-called Linux devices where I can't make the hardware work with >> > free software. I've a similar problem ATM with the Eee PC's >> > unsupported WLAN and its buggy BIOS... >> >> And that is good, but once certain things have happened, there is no >> way back. An I think I have explained what I think are the obstacles >> in opening specs of existing hw. Not that i wouldn't be happy to be >> proven wrong. > > OK, maybe you cannot open the specs for existing hardware, I don't > know. But in general it is of course possible to design mass market > hardware in a way that allows open specs. All I want to say is that I > beg Nokia to actually do this the next time you design Linux compatible > hardware. Hardware is Linux compatible if and only if there's a GPLed > driver for it. Next time I'll check this _before_ I buy the device, I > don't want to be disappointed again. > >> >> > > Anyway note that in order to do proper low level kernel >> > > development, one needs also measuring tool and special boards >> > > that allow for precise measuring of what the sw is doing. >> > >> > Oh, please, leave that to the people who want to do kernel >> > development. >> >> Yeah, I happen to be one of them, sorry for the personal point of >> view. OTOH the fact that you don't care doesn't mean others are not >> interested. If you talk about an open device, it's the whole stack >> that should be targeted, no? > > No. If someone wants to build a new kernel for a device, it's pretty > clear that he should know what he's doing, that he might render the > device unusable, and so on. And he should also be able to judge if he > has all the skills and equipment he will need for this kind of work. > That's the personal decision of each individual programmer. > > Your note about "special boards" sounded to me like an effort to keep > people away from low-level programming. That would certainly be easier > for you, because then nobody needed open hardware specs... > >> >> > > Nobody in the community >> > > has such setup, >> > >> > How do you know that? I compile kernels for ARM devices almost every >> > day and also build the bootloaders for them. >> >> But not our own boards, i guess. If you do it would be interesting to >> know how you have obtained one. Compiling for your custom or eval >> board means very little. To give you an example, every pad must be >> checked so that it has the right idle configuration depending on what >> is connected to it, or high currents can be seen. Hard to do without >> schematics. > > If a device already comes with a working OS, then no further > information should be necessary, provided the OS is fully Open Source. > Schematics are nice to have, but not absolutely necessary. > >> >> > > so some help from Nokia for validation would still be >> > > required. >> > >> > What do you want to "validate"? I agree if my warranty is void if I >> > use my own kernel, just let me do it. >> >> Maybe i'm too idealistic, but my idea of open source is a working >> model where if one has an interesting piece of code, the code can be >> committed back to the community. >> >> Code "compile tested" or "boot tested" should not be good enough for >> being included in repositories that are meant to be used for rolling >> kernels that will be provided to less experienced users. > > Yes, of course, I completely agree. I'd really like to see many > different OS images for the internet tablets. For example, I'd like to > build a rootfs with Enlightenment instead of Maemo, and with my own > kernel. But I consider this my personal fun, and I agree that it's > dangerous to give such a thing to innocent newbies. > >> >> I don't care if you void your warranty and blow up your device, but i >> get interested if you start distributing such kernels to common users. > > Agreed. But that must not be used as an argument to take away the > freedom guaranteed by the license of the kernel you use. > Please note that what I'm asking is a completely normal thing on any > desktop PC. Yes, I know, embedded devices are special in many aspects. > Mass market hardware has to be designed in a way so that whatever you > do with it, you can always come back to some stable state, e.g. write > back the original manufacturer OS. A standard PC achieves this by > having a BIOS, you'll need something similar on an embedded device. If > you can actually damage hardware through software crashes, then this is > simply bad design. > > Thanks, > Hans > > _______________________________________________ > maemo-developers mailing list > maemo-developers@maemo.org > https://lists.maemo.org/mailman/listinfo/maemo-developers > -- Nick Loeve _______________________________________________ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
