you need to look at those a little closer. 1) the iMX515 has a hard limit of 512mb RAM 2) if you've never used a 10,1in 1024x600 LCD, you are in for a bit of a shock.
but yes, the efika mx is getting an upgrade - soon - to the 1ghz iMX53. and, also, i think genesi have been doing "dogfood eating" and have found, just as i told them it would be, that 1024x600 LCDs are completely unusable. their developer, matt, treated my ideas like shit (i was approaching them to see if they'd like to collaborate on a faster, more flexible product). he told me there was no market for high-end ARM-based laptops. and then "oh look!" surpriise, the next version of the efika laptop will have a 1280x768 LCD as standard. hmm...:)
Zacate is 18 watts! that means you have to have a heatsink or heatpipe, fan and other moving parts, as well as much larger power components. by contrast, with something like the NuSmart 2816 if you run it at 1.6ghz then you can get away with 4 watts and that's *including* the ECC 1066mhz DDR3 RAM. a voltage regulator for a stable 4 watt power supply is approximately a $0.50 cents part. it's a whole different ballgame. so the EOMA Initiative, we've set a 5 watt absolute maximum limit, and are sticking to it. http://elinux.org/Embedded_Open_Modular_Architecture/PCMCIA sadly, not even intel's latest 1.2ghz 45nm CPU, the one that's designed for Meego, is suitable, because the CPU's 2.5 watts, the Northbridge IC is 2 watts, whoops there's not enough room to run the RAM ICs.
even the Z510 shows that this northbridge-southbridge strategy is unacceptable. you *have* to go "totally integrated", in order to reach the required power target. once Intel and AMD start doing that, then and only then will they produce a winner.
well, fortunately there's soon going to be things like the NuSmart 2816, which will have the best of both worlds: Dual-Core 1.6 to 2ghz, 4gb of ECC DDR3 1033mhz RAM... and only about 4 watts for a system (at the 1.6ghz speed).
it's a long story, but i've been working to get ARM-powered desktop machines and laptops into the hands of free software developers for some time.
one of the key problems are that the chinese and taiwanese factories have absolutely no software expertise whatsoever. some guy decides he got caught out by the USA and UK Governments placing embargos and tariffs on imported clothes a couple years back: his business was affected, so he goes "i know, i'll diversify, i'll make tablets, those are popular". so off he goes, he gets supplied with a GPL-violating Android OS right from the word "go" by a limited number of Chinese ODMs who are having a really hard time keeping hold of their software engineers, and it just goes downhill from there.
the other problem is, as can be seen from the insane amount of money spent by the openpandora group, that case-work for laptops etc. can well be in excess of $100,000. that means that anything like the "pegatron netbook" has to be bought in volumes of 250,000 and above in order for the R&D costs to be amortised over a reasonable period.
by reversing everything on its head, and getting free software developers a modular architecture which _could_ be dropped into a mass-volume product, the tables are turned: those Chinese Factories can be supplied *by us* - Free Software Developers - with a completed ready-to-ship OS.
so, yes there's a board which is available that is similar in size and function to the pandaboard, origen exynos board, beagleboard, IMX53QSB etc., but unlike those boards, by complying to the EOMA/PCMCIA Open Standard it would be possible to literally drop that hardware-software combination straight into a mass-volume product, with the development effort of the required motherboard being nothing more than a low-cost 2 to 4 layer board that even KiCAD, Eagle or gEDA could do.
funny... i was just writing up a post to the http://openhardwaresummit.org/ mailing list about a way to accelerate the process by which enthusiasts can work with the latest mass-produced embedded hardware.
the initiative, which has a specification here - http://elinux.org/Embedded_Open_Modular_Architecture/PCMCIA - is based around the fact that, just as mentioned above, the development of processor "speeds" is slowing down. this funnily enough allows so-called "embedded" processors to catch up, and it's these embedded CPUs which are low-power enough to base an entire computer around that is still desirable yet consumes between 0.5 and 3 watts instead of 10 to 500 watts.
actually, there are people in China who are becoming allergic to rice.... which turns out to be the mono-crop mass-produced Genetically-Modified variety that is, thanks to its lower price, not only making it difficult to re-establish native varieties, but is also killing people in the process. well, i guess that solves several problems all at once, then, doesn't it.
so tell me... why is Genetic Modification of food allowed? what's a direct consequence of introducing or removing genes from food that we eat? (answer: RTA). so how are we to know that Genetic Modified food will not have unintended consequences, as a direct result of the removal or insertion of genes that would otherwise never have gotten there?
it's been shown years ago that gut bacteria adopt the genetically-modified soya bean genes into their own RNA. what happens when someone decides to "leverage" food crops to produce drugs, and those accidentally cross-pollinate with the world's food supply? that would be an incredibly stupid and irresponsible thing to do, right? oh wait - i see it's already been implemented. complete insanity, and this research goes to show how much is being put at risk: our lives.
such a trite, annoying phrase... yet, even more annoyingly, it damn well turns out to be true! i remember seeing this mural, done by some ayurvedic indian guru thousands of years ago. it depicted a tiger mauling its prey violently, and eating it. underneath was an obese man, mouth open and wide-eyed in the same expression as the tiger. i thought at the time, "yes very interesting" and really didn't give it much more thought. yet here we are, in 2011, and "modern science" now backs up "ancient wisdom" yet again. how annoying.
that's funny, because i found that when supplying people with GNU/Linux systems, they destroyed the O.S. and installed Windows XP on it. ok, they _tried_ to install Windows XP, but it turned out that there was something strange about the filesystem partitioning carried out by fdisk. the end-result was that these idiots ended up with absolutely no O.S. on their machines, because they'd destroyed what i'd delivered to them, and Windows XP would just sit there trying to do a "disk analysis", with the hard drive light spinning permanently. the solution turned out to be that they needed to completely wipe the front of the disk, to destroy the partition table. whoops...
the most important thing is to have techniques that allow you to find your way. the language doesn't actually matter, but it does definitely definitely help if the code is documented in some fashion. i tried, for example, to work on fontforge with my usual techniques, and the code was so incredibly dense and uncommented that it was absolutely impossible to understand. but, exceptions aside, here's a starting point for getting into large projects:
* use vi. do not use graphical editors. do not use emacs * get a damn big monitor (or 2 monitors). open xterms at 80x60, as many wide as you can get. * use a multi-window desktop manager (i use fvwm2 and i run a 6x4 grid: that's 24 desktops. * be prepared to open (and background) up to 200 simultaneous files, across multiple windows. * make sure that you open the files from the *root* of the project. * open the files "by name", explicitly, so that you can do "jobs | grep {filename}" * run "ctags -R" - it is your friend. then use ctrl-] on a function you don't know, and read about it. * remember to use:e # to go _back_ to the file you were originally editing (after using ctrl-]) * be prepared to print out the ENTIRE codebase, and flip through it, off-line, very very quickly. * be prepared to do page-down, page-down, very very quickly, through as many files as you can stand
the main thing to do is to get a vague map of the code into your subconscious, as quickly as possible. then you will go "i've seen that before..." and you stand a chance of being able to hunt for it and find it.
you *don't* have to memorise the entire codebase - you *don't* have to even understand all of it. but you *do* need to at least have the techniques which will allow you to jump to wherever it is that you want to go.
ultimately, though, you need a goal. what, exactly, is it that you want to achieve? if you have no goal, you are pissing in the wind.
i added NT Domains Security to freedce - that's a good, simple goal. FreeDCE is 250,000 lines of code, and very well laid-out. it was therefore quite straightforward to add 6,000 lines of code to do NTLMSSP. took a couple of weeks.
i added python bindings to webkit - that's a good simple goal (ok, it was horrendous, requiring over 12 different skillsets, including c, c++, python, perl, autoconf, gtk, python c modules, IDL files parsing - the list just went on and on). webkit is a massive project, and also very well laid-out and structured. the first version of the python bindings took about 8 weeks, and the 2nd (faster, better) version took only 2. the reason why the 2nd version took only 2 weeks is because i hunted down the mozilla xulrunner IDL file parser, hunted down python-gobject's code generator, adapted the xulrunner IDL file parser to understand the webkit IDL file-format (2 days), then spent the rest of the time hacking codegen.py to spew out the data types from webkit, and to create a standard python c module.
so you say "you don't know how to get familiar with a free software project", well, i am not - i wasn't familiar with webkit, but that didn't stop me. i wasn't familiar with xulrunner, but that didn't stop me. i wasn't familiar with python-gobject's codegen, but that didn't stop me. i just got on with it, and just trusted that the surrounding code would do its job, and trusted that the bit of code that i picked up could be adapted.
so in many ways, tackling a large codebase is more about overcoming your own fear and feelings of inadequacy. sometimes not even i can do that, and sometimes i can.
they should run linux on their servers, it's more secure! oh wait... whoops. ho hum, i suppose it's no good saying that they should run a FreeBSD Bastion Server, is it?
i wonder how much this buggers up any companies doing patents on 3D GPUs? the reason i ask is this: one of the problems that the ARM embedded SoC vendors face is that they are stuck on choice for GPUs, from companies who have had to design very low-power 3D engines (Vivante etc). these companies are quite young, and their relationship with the "big boys", who have had over a decade to establish their "arms-race" arsenal of patents, is unclear. so the embedded SoC 3D companies are LESS likely to release free software drivers. but if the very foundation of key parts of 3D patents is undermined through prior art.... i dunno...
there's a much better explanation, based on someone who quotes cured quotes her son of autism. she hypothesised that autism was caused by excessive toxins reaching the brain.
she hypothesised and then proved through simply looking up existing medical research that the toxins get there because of strong antibiotics and the practice of immunisation killing "good" bacteria as well as bad, leaving a body that is completely devoid of bacteria that then re-grows, and re-forms "pockets" of bad bacteria that are both stronger and harder for the body to get rid of.
there are a few other things that she hypothesised and then empirically proved as well, but they boil down to a combination of factors of "accepted western medical science" doing untold damage through sheer arrogance. of course, you are entirely free to completely ignore the above, because this is slashdot, it's the internet, and there's so much crap about i'm sure that there are many more people who will want to believe what they want to hear, instead of "whoops, we brought this on ourselves by trusting the accepted medical science of today"...
i've just written this to the blog-writer: Please use the "Estoppel" Legal Defense. There's no way that Atari have not known of the existence for 12 years of the atari2600.org domain name.
The "Estoppel" defense states that if you ignore something, it is tantamount to "acquiescence" - i.e. "silent consent".
thus it can be claimed that Atari has "Silently Consented" to the use of this domain name, by virtue of them not having done anything for well over a decade.
ahh, but aren't we supposed to be all buying ARM 64-bit systems right now, in order to save power in those data centres, ehn? like the phytec module using the spear1310 where you can get 8 Dual-Core Cortex A9s with 1gb ECC DDR3 RAM on each, and 8 SATA drives (one each) which are the major power drain in the 19in 1U rack-mounted server? http://www.phytec.com/news/ZT-Systems-R1801e-Server.html
the thing is that absolutely nobody has come up with any solutions. the only solution i've heard is the one that i recommended, and there's been no reaction or response to it, as of yet.
the problem is the sheer overwhelming diversity. therefore, the solution is to prioritise linux kernel patches that come from hardware syndicates or specifications that cover more than just the one hardware device. for example, a patch to add in ARM USB3 support would instantly be accepted, because it covers multiple hardware devices. for example, a reference board would be instantly accepted, because it allows companies plural to develop platforms based around it.
what people are forgetting is that because there is no BIOS in the ARM world and no "common hardware platform" (PCI, PCIe, Northbridge, Southbridge - in most cases all of those things are gone. ARM CPUs with PCIe are exceptionally rare). and often there are massive differences between CPUs even on a minor upgrade from the same manufacturer, each hardware device has to have a custom-tailored device layout, and that means a custom-tailored linux kernel.
Can a redistributor just point to the original source under the GPL if they don't modify it? I assume they can
You assume wrong, if the redistributor is doing it commercially. In that case they need to either include the source with the binary or else provide a written offer to give the source to anyone that asks.
For noncommercial distribution, providing a link to the original source is sufficient.
that's incorrect. commercial or non-commercial has nothing to do with it. re-read the GPL license. the only commercialisation allowed by the GPL is that it's ok to offer a warranty (and charge for it) or to charge for the distribution (sending a CD). that's all. there's absolutely no mention of differences between commercial or non-commercial redistributors.
correct answer: yes, a redistributor can just point to the original source if they distribute binaries which were compiled without modifications to that original GPL'd source code. it's actually a very good way for the redistributor to keep costs down.
unfortunately your assumptions are incorrect. many of the chinese tablet manufacturers are ignorant of software: they have to get a specialist in, to help them, as they are hardware-manufacturers only, in most cases. so they don't even HAVE the source code! i've repeatedly found this to be the case when dealing with chinese factories. there are many other things that are incorrect about what you've said, and i've cover them here, as well as providing some insight into what exactly is going on: http://news.slashdot.org/comments.pl?sid=2380756&op=Reply&threshold=1&commentsort=0&mode=thread&pid=37100038
again, you're completely ignorant of the situation surrounding the actual makeup of the android source code. the core android OS which was released BY GOOGLE is completely apache2 source code. it runs on top of a modified Linux Kernel, which has had patches made to it to add in, apart from anything else, the android security model. for more info see the post i made here: http://news.slashdot.org/comments.pl?sid=2380756&op=Reply&threshold=1&commentsort=0&mode=thread&pid=37100038
bob, you really really need to get better informed about the GPL before making random comments like the ones you've just made, ok?
please moderate the parent comment down as completely misleading. a quick google search "HTC GPL Violation Android" shows a consistent and willful track record of GPL violations by HTC. the GPL violations rate, even on a simple non-authoritative survey, is well-known to be 90% or above. http://www.codon.org.uk/~mjg59/android_tablets/
there is a lot of misinformation about this topic, because many people do not realise that chinese manufacturers simply have absolutely no software skills - at all - and get supplied with GPL-violating binary firmware from a very limited pool of software specialist companies in china, completely by mistake. they then turn to those software specialists when asked for GPL compliance, and you typically get a very distorted and standard answer which indicates a complete lack of knowledge of the GPL.
but on top of that, the android source code that comes out of google simply is not enough, on its own. firstly: android is NOT just apache2-licensed applications: it sits on top of a GPL'd Linux Kernel which has had some very specific modifications made to it (mostly in the form of the android "security model"). secondly: many CPU manufacturers have to add hardware-accelerated video and 3D graphics engines in order to meet "cunsumaah dimarnd". these are backed up by proprietary software libraries that qualify - usually - as "System Libraries" under GPL exemption clauses. thirdly: android simply doesn't have a built-in video player nor a video player "API" so it is up to the vendors to put in applications which *do not* come from the android "stock" that comes out of google, and they usually do this by grabbing the nearest GPL source code they can find. fourthly: many software-builders for the OEMs / ODMs simply throw away portions of android source code and utilise the GPL equivalents (such as the GPL version of busybox, not the version that google implemented from scratch just to be able to "cleanse" the core android OS From All Gee Pee Ell code).
so this is the situation. and, as a result, yes, the vast majority of android devices in the world are GPL violating. let's go through a few coments that have made it past slashdot moderation.
baloroth states that google provides the GPL parts of android and that they are "freely available". well, yeah, but re-read the above and you'll see that that's completely irrelevant. he then states that he assumes that any licensee would just point to that if asked for the code. well, yeah, but re-read the above and you'll see that that's again completely irrelevant - not least because the licensee is required to provide the code that THEY have distributed, and it's usually been heavily modified by somebody else that they got in to do the software. he then states that "most licensees don't modify the GPL portions" which is wrong: it is absolutely essential to create an android-specific linux kernel which will support the android OS, on a per-CPU and even a per-device basis.
jeffmeden then goes on to try to state that we should all think that multi-billion-dollar companies like motorola, samsung and HTC don't bother to check if things are kosher? jeff - even a few seconds of checking on the gpl-violations mailing list or even just searching "HTC GPL Violation" would show you at least three GPL violations by HTC within the past year! samsung you're actually right about, and motorola i haven't kept up with but they are just in the process of being acquired by google, which is something that needs to be kept an eye on. it could be good, or it could be bad.
jeff also states "hmm no actually most manufacturers comply with the redistribution clause in the GPL". this is completely wrong. actually, according to an off-the-cuff survey of android tablets done six months ago by a redhat employee, he found that 95% of the 80+ tablets were GPL violating. he's maintaining the list here: http://www.codon.org.uk/~mjg59/android_tablets/
this list is so long it would overwhelm the Software Freedom Law Centre's resources to tackle them all at once.
so... yeah. it would appear that there is a hell of a lot of ignorance surrounding android. the mistake that google made was to try to combine apache-licensed code with GPL code. apart from anything, this gives people the impression that all
Slashdot Mirror
you need to look at those a little closer. 1) the iMX515 has a hard limit of 512mb RAM 2) if you've never used a 10,1in 1024x600 LCD, you are in for a bit of a shock.
but yes, the efika mx is getting an upgrade - soon - to the 1ghz iMX53. and, also, i think genesi have been doing "dogfood eating" and have found, just as i told them it would be, that 1024x600 LCDs are completely unusable. their developer, matt, treated my ideas like shit (i was approaching them to see if they'd like to collaborate on a faster, more flexible product). he told me there was no market for high-end ARM-based laptops. and then "oh look!" surpriise, the next version of the efika laptop will have a 1280x768 LCD as standard. hmm... :)
Zacate is 18 watts! that means you have to have a heatsink or heatpipe, fan and other moving parts, as well as much larger power components. by contrast, with something like the NuSmart 2816 if you run it at 1.6ghz then you can get away with 4 watts and that's *including* the ECC 1066mhz DDR3 RAM. a voltage regulator for a stable 4 watt power supply is approximately a $0.50 cents part. it's a whole different ballgame. so the EOMA Initiative, we've set a 5 watt absolute maximum limit, and are sticking to it. http://elinux.org/Embedded_Open_Modular_Architecture/PCMCIA sadly, not even intel's latest 1.2ghz 45nm CPU, the one that's designed for Meego, is suitable, because the CPU's 2.5 watts, the Northbridge IC is 2 watts, whoops there's not enough room to run the RAM ICs.
even the Z510 shows that this northbridge-southbridge strategy is unacceptable. you *have* to go "totally integrated", in order to reach the required power target. once Intel and AMD start doing that, then and only then will they produce a winner.
not if it's got 4gb of ECC DDR3 1066mhz RAM, it's not. the NuSmart 2816 is a 1.6 to 2ghz Dual-Core Cortex A9 with two versions - one 32-bit memory addressing and the other 64-bit. they're sampling, now. i'm working to get them plugged in to the EOMA initiative:
http://elinux.org/Embedded_Open_Modular_Architecture/PCMCIA
http://www.openhardwaresummit.org/forum/viewtopic.php?f=5&t=502
well, fortunately there's soon going to be things like the NuSmart 2816, which will have the best of both worlds: Dual-Core 1.6 to 2ghz, 4gb of ECC DDR3 1033mhz RAM... and only about 4 watts for a system (at the 1.6ghz speed).
i'm working towards getting these - and other such beefy low-power CPUs - plugged in to the EOMA initiative:
http://www.openhardwaresummit.org/forum/viewtopic.php?f=5&t=502
http://elinux.org/Embedded_Open_Modular_Architecture/PCMCIA
it's a long story, but i've been working to get ARM-powered desktop machines and laptops into the hands of free software developers for some time.
one of the key problems are that the chinese and taiwanese factories have absolutely no software expertise whatsoever. some guy decides he got caught out by the USA and UK Governments placing embargos and tariffs on imported clothes a couple years back: his business was affected, so he goes "i know, i'll diversify, i'll make tablets, those are popular". so off he goes, he gets supplied with a GPL-violating Android OS right from the word "go" by a limited number of Chinese ODMs who are having a really hard time keeping hold of their software engineers, and it just goes downhill from there.
the other problem is, as can be seen from the insane amount of money spent by the openpandora group, that case-work for laptops etc. can well be in excess of $100,000. that means that anything like the "pegatron netbook" has to be bought in volumes of 250,000 and above in order for the R&D costs to be amortised over a reasonable period.
this is where the EOMA initiative comes in: http://elinux.org/Embedded_Open_Modular_Architecture/PCMCIA
by reversing everything on its head, and getting free software developers a modular architecture which _could_ be dropped into a mass-volume product, the tables are turned: those Chinese Factories can be supplied *by us* - Free Software Developers - with a completed ready-to-ship OS.
so, yes there's a board which is available that is similar in size and function to the pandaboard, origen exynos board, beagleboard, IMX53QSB etc., but unlike those boards, by complying to the EOMA/PCMCIA Open Standard it would be possible to literally drop that hardware-software combination straight into a mass-volume product, with the development effort of the required motherboard being nothing more than a low-cost 2 to 4 layer board that even KiCAD, Eagle or gEDA could do.
one key part of this strategy is to leverage arduino-like boards, like the leafpad Maple:
http://elinux.org/Embedded_Open_Modular_Architecture/PCMCIA/MiniEngineeringBoard
anyway i think that's enough for one slashdot post. bit of background and some additional links, here:
http://www.openhardwaresummit.org/forum/viewtopic.php?f=5&t=502
funny... i was just writing up a post to the http://openhardwaresummit.org/ mailing list about a way to accelerate the process by which enthusiasts can work with the latest mass-produced embedded hardware.
the initiative, which has a specification here - http://elinux.org/Embedded_Open_Modular_Architecture/PCMCIA - is based around the fact that, just as mentioned above, the development of processor "speeds" is slowing down. this funnily enough allows so-called "embedded" processors to catch up, and it's these embedded CPUs which are low-power enough to base an entire computer around that is still desirable yet consumes between 0.5 and 3 watts instead of 10 to 500 watts.
if anybody would like to participate in this initiative, please do join the arm-netbook mailing list - http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
it doesn't matter: the amount of energy that goes into the production of those panels is a significant fraction of the energy they generate over their lifetime. whoops... http://answers.yahoo.com/question/index?qid=20090201062719AATwL62
actually, there are people in China who are becoming allergic to rice.... which turns out to be the mono-crop mass-produced Genetically-Modified variety that is, thanks to its lower price, not only making it difficult to re-establish native varieties, but is also killing people in the process. well, i guess that solves several problems all at once, then, doesn't it.
so tell me... why is Genetic Modification of food allowed? what's a direct consequence of introducing or removing genes from food that we eat? (answer: RTA). so how are we to know that Genetic Modified food will not have unintended consequences, as a direct result of the removal or insertion of genes that would otherwise never have gotten there?
it's been shown years ago that gut bacteria adopt the genetically-modified soya bean genes into their own RNA. what happens when someone decides to "leverage" food crops to produce drugs, and those accidentally cross-pollinate with the world's food supply? that would be an incredibly stupid and irresponsible thing to do, right? oh wait - i see it's already been implemented. complete insanity, and this research goes to show how much is being put at risk: our lives.
such a trite, annoying phrase... yet, even more annoyingly, it damn well turns out to be true! i remember seeing this mural, done by some ayurvedic indian guru thousands of years ago. it depicted a tiger mauling its prey violently, and eating it. underneath was an obese man, mouth open and wide-eyed in the same expression as the tiger. i thought at the time, "yes very interesting" and really didn't give it much more thought. yet here we are, in 2011, and "modern science" now backs up "ancient wisdom" yet again. how annoying.
that's funny, because i found that when supplying people with GNU/Linux systems, they destroyed the O.S. and installed Windows XP on it. ok, they _tried_ to install Windows XP, but it turned out that there was something strange about the filesystem partitioning carried out by fdisk. the end-result was that these idiots ended up with absolutely no O.S. on their machines, because they'd destroyed what i'd delivered to them, and Windows XP would just sit there trying to do a "disk analysis", with the hard drive light spinning permanently. the solution turned out to be that they needed to completely wipe the front of the disk, to destroy the partition table. whoops...
i know what! let's go back to releasing "when it's ready"! that would be great! oh wait... that's what debian do.
the most important thing is to have techniques that allow you to find your way. the language doesn't actually matter, but it does definitely definitely help if the code is documented in some fashion. i tried, for example, to work on fontforge with my usual techniques, and the code was so incredibly dense and uncommented that it was absolutely impossible to understand. but, exceptions aside, here's a starting point for getting into large projects:
* use vi. do not use graphical editors. do not use emacs :e # to go _back_ to the file you were originally editing (after using ctrl-])
* get a damn big monitor (or 2 monitors). open xterms at 80x60, as many wide as you can get.
* use a multi-window desktop manager (i use fvwm2 and i run a 6x4 grid: that's 24 desktops.
* be prepared to open (and background) up to 200 simultaneous files, across multiple windows.
* make sure that you open the files from the *root* of the project.
* open the files "by name", explicitly, so that you can do "jobs | grep {filename}"
* run "ctags -R" - it is your friend. then use ctrl-] on a function you don't know, and read about it.
* remember to use
* be prepared to print out the ENTIRE codebase, and flip through it, off-line, very very quickly.
* be prepared to do page-down, page-down, very very quickly, through as many files as you can stand
the main thing to do is to get a vague map of the code into your subconscious, as quickly as possible. then you will go "i've seen that before..." and you stand a chance of being able to hunt for it and find it.
you *don't* have to memorise the entire codebase - you *don't* have to even understand all of it. but you *do* need to at least have the techniques which will allow you to jump to wherever it is that you want to go.
ultimately, though, you need a goal. what, exactly, is it that you want to achieve? if you have no goal, you are pissing in the wind.
i added NT Domains Security to freedce - that's a good, simple goal. FreeDCE is 250,000 lines of code, and very well laid-out. it was therefore quite straightforward to add 6,000 lines of code to do NTLMSSP. took a couple of weeks.
i added python bindings to webkit - that's a good simple goal (ok, it was horrendous, requiring over 12 different skillsets, including c, c++, python, perl, autoconf, gtk, python c modules, IDL files parsing - the list just went on and on). webkit is a massive project, and also very well laid-out and structured. the first version of the python bindings took about 8 weeks, and the 2nd (faster, better) version took only 2. the reason why the 2nd version took only 2 weeks is because i hunted down the mozilla xulrunner IDL file parser, hunted down python-gobject's code generator, adapted the xulrunner IDL file parser to understand the webkit IDL file-format (2 days), then spent the rest of the time hacking codegen.py to spew out the data types from webkit, and to create a standard python c module.
so you say "you don't know how to get familiar with a free software project", well, i am not - i wasn't familiar with webkit, but that didn't stop me. i wasn't familiar with xulrunner, but that didn't stop me. i wasn't familiar with python-gobject's codegen, but that didn't stop me. i just got on with it, and just trusted that the surrounding code would do its job, and trusted that the bit of code that i picked up could be adapted.
so in many ways, tackling a large codebase is more about overcoming your own fear and feelings of inadequacy. sometimes not even i can do that, and sometimes i can.
they should run linux on their servers, it's more secure! oh wait... whoops. ho hum, i suppose it's no good saying that they should run a FreeBSD Bastion Server, is it?
i wonder how much this buggers up any companies doing patents on 3D GPUs? the reason i ask is this: one of the problems that the ARM embedded SoC vendors face is that they are stuck on choice for GPUs, from companies who have had to design very low-power 3D engines (Vivante etc). these companies are quite young, and their relationship with the "big boys", who have had over a decade to establish their "arms-race" arsenal of patents, is unclear. so the embedded SoC 3D companies are LESS likely to release free software drivers. but if the very foundation of key parts of 3D patents is undermined through prior art.... i dunno...
there's a much better explanation, based on someone who quotes cured quotes her son of autism. she hypothesised that autism was caused by excessive toxins reaching the brain.
she hypothesised and then proved through simply looking up existing medical research that the toxins get there because of strong antibiotics and the practice of immunisation killing "good" bacteria as well as bad, leaving a body that is completely devoid of bacteria that then re-grows, and re-forms "pockets" of bad bacteria that are both stronger and harder for the body to get rid of.
there are a few other things that she hypothesised and then empirically proved as well, but they boil down to a combination of factors of "accepted western medical science" doing untold damage through sheer arrogance. of course, you are entirely free to completely ignore the above, because this is slashdot, it's the internet, and there's so much crap about i'm sure that there are many more people who will want to believe what they want to hear, instead of "whoops, we brought this on ourselves by trusting the accepted medical science of today"...
i've just written this to the blog-writer: Please use the "Estoppel" Legal Defense. There's no way that Atari have not known of the existence for 12 years of the atari2600.org domain name.
The "Estoppel" defense states that if you ignore something, it is tantamount to "acquiescence" - i.e. "silent consent".
thus it can be claimed that Atari has "Silently Consented" to the use of this domain name, by virtue of them not having done anything for well over a decade.
ahh, but aren't we supposed to be all buying ARM 64-bit systems right now, in order to save power in those data centres, ehn? like the phytec module using the spear1310 where you can get 8 Dual-Core Cortex A9s with 1gb ECC DDR3 RAM on each, and 8 SATA drives (one each) which are the major power drain in the 19in 1U rack-mounted server? http://www.phytec.com/news/ZT-Systems-R1801e-Server.html
linus's views sound very similar to what i've written about, at some length on this subject: https://lkml.org/lkml/2011/7/1/473
the thing is that absolutely nobody has come up with any solutions. the only solution i've heard is the one that i recommended, and there's been no reaction or response to it, as of yet.
the problem is the sheer overwhelming diversity. therefore, the solution is to prioritise linux kernel patches that come from hardware syndicates or specifications that cover more than just the one hardware device. for example, a patch to add in ARM USB3 support would instantly be accepted, because it covers multiple hardware devices. for example, a reference board would be instantly accepted, because it allows companies plural to develop platforms based around it.
what people are forgetting is that because there is no BIOS in the ARM world and no "common hardware platform" (PCI, PCIe, Northbridge, Southbridge - in most cases all of those things are gone. ARM CPUs with PCIe are exceptionally rare). and often there are massive differences between CPUs even on a minor upgrade from the same manufacturer, each hardware device has to have a custom-tailored device layout, and that means a custom-tailored linux kernel.
did facebook and yahoo ask permission of all these users before rifling through their profiles?
Can a redistributor just point to the original source under the GPL if they don't modify it? I assume they can
You assume wrong, if the redistributor is doing it commercially. In that case they need to either include the source with the binary or else provide a written offer to give the source to anyone that asks.
For noncommercial distribution, providing a link to the original source is sufficient.
that's incorrect. commercial or non-commercial has nothing to do with it. re-read the GPL license. the only commercialisation allowed by the GPL is that it's ok to offer a warranty (and charge for it) or to charge for the distribution (sending a CD). that's all. there's absolutely no mention of differences between commercial or non-commercial redistributors.
correct answer: yes, a redistributor can just point to the original source if they distribute binaries which were compiled without modifications to that original GPL'd source code. it's actually a very good way for the redistributor to keep costs down.
unfortunately your assumptions are incorrect. many of the chinese tablet manufacturers are ignorant of software: they have to get a specialist in, to help them, as they are hardware-manufacturers only, in most cases. so they don't even HAVE the source code! i've repeatedly found this to be the case when dealing with chinese factories. there are many other things that are incorrect about what you've said, and i've cover them here, as well as providing some insight into what exactly is going on: http://news.slashdot.org/comments.pl?sid=2380756&op=Reply&threshold=1&commentsort=0&mode=thread&pid=37100038
again, you're completely ignorant of the situation surrounding the actual makeup of the android source code. the core android OS which was released BY GOOGLE is completely apache2 source code. it runs on top of a modified Linux Kernel, which has had patches made to it to add in, apart from anything else, the android security model. for more info see the post i made here: http://news.slashdot.org/comments.pl?sid=2380756&op=Reply&threshold=1&commentsort=0&mode=thread&pid=37100038
bob, you really really need to get better informed about the GPL before making random comments like the ones you've just made, ok?
please moderate the parent comment down as completely misleading. a quick google search "HTC GPL Violation Android" shows a consistent and willful track record of GPL violations by HTC. the GPL violations rate, even on a simple non-authoritative survey, is well-known to be 90% or above. http://www.codon.org.uk/~mjg59/android_tablets/
there is a lot of misinformation about this topic, because many people do not realise that chinese manufacturers simply have absolutely no software skills - at all - and get supplied with GPL-violating binary firmware from a very limited pool of software specialist companies in china, completely by mistake. they then turn to those software specialists when asked for GPL compliance, and you typically get a very distorted and standard answer which indicates a complete lack of knowledge of the GPL.
but on top of that, the android source code that comes out of google simply is not enough, on its own. firstly: android is NOT just apache2-licensed applications: it sits on top of a GPL'd Linux Kernel which has had some very specific modifications made to it (mostly in the form of the android "security model"). secondly: many CPU manufacturers have to add hardware-accelerated video and 3D graphics engines in order to meet "cunsumaah dimarnd". these are backed up by proprietary software libraries that qualify - usually - as "System Libraries" under GPL exemption clauses. thirdly: android simply doesn't have a built-in video player nor a video player "API" so it is up to the vendors to put in applications which *do not* come from the android "stock" that comes out of google, and they usually do this by grabbing the nearest GPL source code they can find. fourthly: many software-builders for the OEMs / ODMs simply throw away portions of android source code and utilise the GPL equivalents (such as the GPL version of busybox, not the version that google implemented from scratch just to be able to "cleanse" the core android OS From All Gee Pee Ell code).
so this is the situation. and, as a result, yes, the vast majority of android devices in the world are GPL violating. let's go through a few coments that have made it past slashdot moderation.
baloroth states that google provides the GPL parts of android and that they are "freely available". well, yeah, but re-read the above and you'll see that that's completely irrelevant. he then states that he assumes that any licensee would just point to that if asked for the code. well, yeah, but re-read the above and you'll see that that's again completely irrelevant - not least because the licensee is required to provide the code that THEY have distributed, and it's usually been heavily modified by somebody else that they got in to do the software. he then states that "most licensees don't modify the GPL portions" which is wrong: it is absolutely essential to create an android-specific linux kernel which will support the android OS, on a per-CPU and even a per-device basis.
jeffmeden then goes on to try to state that we should all think that multi-billion-dollar companies like motorola, samsung and HTC don't bother to check if things are kosher? jeff - even a few seconds of checking on the gpl-violations mailing list or even just searching "HTC GPL Violation" would show you at least three GPL violations by HTC within the past year! samsung you're actually right about, and motorola i haven't kept up with but they are just in the process of being acquired by google, which is something that needs to be kept an eye on. it could be good, or it could be bad.
jeff also states "hmm no actually most manufacturers comply with the redistribution clause in the GPL". this is completely wrong. actually, according to an off-the-cuff survey of android tablets done six months ago by a redhat employee, he found that 95% of the 80+ tablets were GPL violating. he's maintaining the list here:
http://www.codon.org.uk/~mjg59/android_tablets/
this list is so long it would overwhelm the Software Freedom Law Centre's resources to tackle them all at once.
so... yeah. it would appear that there is a hell of a lot of ignorance surrounding android. the mistake that google made was to try to combine apache-licensed code with GPL code. apart from anything, this gives people the impression that all