the problem that you've got is the resentment of several years - decades - of abusively-high pricing. people feel that they've been ripped off, so they have no qualms about copying. *UNFORTUNATELY* that mind-set is now entrenched, and an independent artist selling their own creative material is, sadly, going to get hit by that.

whom can the finger be "pointed at" for this situation? well, some would say the record labels for being greedy. but there's a counter-example which illustrates that that's not *entirely* the case. in japan, they love anime. so much so that the fans actually support the directors in every way possible. when a film comes out, the director distributes it first on bittorrent. the fans copy it, enjoy it, buy the t-shirts, buy the merchandise. they distribute it, they translate it, they produce their own dubbed soundtracks, and redistribute them freely.

but here's the kicker: when the official DVDs come out, they PULL THE BITTORRENTs AND GO OUT AND BUY THE DVD.

bear in mind that this is japan, but that's still absolutely stunning. and it puts us westerners lamenting a situation where our poor artists cannot make a living in this day and age to absolute shame. food for thought.

the typical example that i give here is "python htmltmpl". htmltmpl was written to solve a very specific problem: minimalist templating of HTML by allowing dictionaries of key-value pairs to substitute into HTML (value text replaces the key when named) and to do likewise for lists of dictionaries in order to e.g. create tables.

very very simple.

the problem is this: the actual scope of the work required means that the actual programming required was extremely straightforward. i.e. it was done, completed - problem solved. the scope of the work required is clear; the scope of the work required does not change; the scope of the work required does not *NEED* to change.

therein lies the problem, namely that the fact that python-htmltmpl has quotes not had any development quotes means that, as far as sourceforge is concerned, the project is "dead". look at the release dates - 2001 for god's sake!
  http://htmltmpl.sourceforge.net/

the point is: just because a project hasn't had any development done on it, that DOES NOT automatically mean that it doesn't do the job. correlation != causation. python-htmltmpl *clearly* does the job it's intended to do.

i mention this case specifically because i have seen a large number of HTML "templating" languages come and go. the php-inspired one which used syntax. zope with the dreadful and insane embedding of python in templates and templates in python. many many more, all of which caused me to despair when i saw them, so much so that i was inspired to talk at one UKUUG conference at some length about best practices of keeping programming languages declarative i.e. *never* embedding programming languages into HTML (even if it's php).

and once you follow the sanity-restoring rule of keeping a programming language declarative (e.g. in the php case beginning the file with as the last two characters and AT NO POINT EVER NOT FOR ANY REASON WHATSOEVER FALLING BACK TO OR PERMITTING STATIC HTML TO BE OUTPUT IMPLICITLY)... ... once you follow that rule, then you find that you need a templating system such as php-htmltmpl or any of the others that exist. and, once you've looked closely at what you actually need out of an HTML templating language, then actually, htmltmpl provides a *really* good very simple system which covers pretty much everything you'll need. need to do an expression which is a mixture of variables and HTML? generate it explicitly in php, put it into the array - don't for god's sake try to use a god-awful mix of print, echo, dots and christ knows what else. just.. don't.

so i'm putting this out there because in certain cases, what you find is that the code that you need appears "dead", but that's not actually the case: the failure of sourceforget and github by their "metrics" have relegated perfectly good and *completed* code to obscurity.

you are therefore encouraged to participate in *unfinished* projects, with their constant changes, moving targets and massive contributions which may or may not be correctly managed, because it is those projects that have "99% activity". does that sound like a good thing to you?

the one thing that would help enormously would be to have git be *truly* peer-to-peer distributed. not "yeah shure mate you can always git pull and git push, that's distributed, and you're a peer, right, so... so... git is peer-to-peer and distributed, so what are you talking about you moron??" but "at the network level, git pull and git push have a URL type that is **TRULY** peer-to-peer distributed. to illustrate what i mean, i would like to be able to do the following - with all that it implies:

git clone magnet://abcdefg0123456789/gittorrent.git

if you're familiar with magnet links, you'll know that there is *no* central location: a DHT lookup is used to find the peers.

now, what wasn't clear to the people on the git mailing list when i last looked at this, was that it is possible to use bittorrent to do git pack objects, by creating a file named after the pack object itself. and what wasn't clear to sam (the last person who tried to put git over bittorrent) was that you *MUST NOT* make use of bittorrent's "multiple file in a torrent" feature, because bittorrent divides up its data into equal-sized blocks that *do not* line up with the files that are in them, which is why when you download one file in a torrent you almost always end up with the end of its preceding file and the start of the one after it, as well.

the idea i came up with is that you create *multiple* torrents - one per git object (or git pack object). if you want to pull a tree, you create a torrent containing *one file* which is the list of objects in that tree; gittorrent would then know to map each of those objects onto yet *another* torrent (one per object), repeat until all downloading happily. gittorrent objects are of course named after the hash, so you can pretty much guarantee they'll be unique.

and, adding in a DHT (a la magnet links), you are now no longer critically dependent on something like e.g. github, or in fact any server at all.

to answer your question in a non-technical way, mr anonymous, i think you can see that i feel it would be much more useful to have development tools that use bittorrent-like protocols to share files-as-revision-controlled-data (and, if you've seen what joey hess is doing with bittorrent you'll know that that's a hell of a lot - including storing home directories in git and doing automatic distributed backups)

:) Mini ARM computer, Mini x86 computer (when we get access to ValleyView), Mini MIPS computer (Ingenic jz series), Mini {insert CPU model here} computer, mini FPGA card, mini pass-through card.

the EOMA-68 standard is *not* limited to a particular CPU - it's not even in fact limited to a CPU *at all*. take a look at this for example:
http://elinux.org/Embedded_Open_Modular_Architecture/EOMA-68/Passthrough

that's what we call a "pass-through" card. it has HDMI/DVI **INPUT**. not HDMI output from a processor. it has HDMI *IN*. that input gets converted to RGB/TTL and is "passed through" to the EOMA-68 connector.

what's the purpose of that?

well, imagine that you buy an EOMA-68-compliant LCD Monitor. it comes with a "pass through" card. it costs the same as a standard LCD monitor. it has an HDMI input. except this monitor, you can press a button on the side, pop out the pass-through card, and insert an EOMA-68 Computer Card.

voila - the monitor has instantly been transformed into an all-in-one computer!!!

how absolutely cool is that?

you could turn it into a TV by popping out the Computer Card and putting in a TV card.

you could take that same TV Card and pop it into your 7in tablet "chassis" and you have a portable TV!

are you starting to appreciate just quite how powerful this concept really is?

PADS 9.3. it's absolutely awesome. i'd thoroughly, thoroughly recommend it. it's intuitive, it's obvious, the menus are simple yet powerful, and a heck of a lot of effort and thought has gone into the design and useability, to make sure that the context menus adjust to provide you what you *need*, at the time that you need it.

by contrast, if you've ever seen Allegro PCB design software, it's a nightmare. the menu bar has 25 options across the top!! that's just absolutely insane, and you can tell that the software team basically haven't thought about uesability - at all. you're expected to just... "know" what menu option is needed, you're expected to "know" what "mode" you're in - i can't even BEGIN to get started.

i started using PADS, and i didn't even need a tutorial in order to start doing something. sure, i made mistakes, and there were a couple of frustrating moments when i thought "ok, this isn't obvious, let's look it up" such as "what the hell is ECO mode" and it's a button that stops you from accidentally modifying the PCB from becoming out-of-sync with the schematics. if you click that button, then the software will save any differences that you make [to the netlist] from that point on, so that you can "back-import" them into the schematics.

so i was basically up-and-running in about a month. every time i look at Allegro, i just... i can't even begin to get started. big big difference.

and yeees, i really want to use KiCAD, but it simply cannot cope with these types of tasks *plus* my ignorance of PCB layout :) if i was a trained engineer with 20 years of experience in PCB design i *might* be able to use KiCAD for these tasks, but it would still be very very frustrating even with 20 years experience because KiCAD doesn't have anything like a built-in autorouter, or the Design Rules checks, or differential-pair routing or in fact anything that you'd expect to have in a professional-grade PCB design package.

now you're getting it. the cloud's a fad. this is hardware. it's *your* hardware, and it's *your* data.

but yes: typically a media centre chassis would have terabyte storage, which, obviously, you'd not have on a tablet, but that's ok: that's the way it should be.

the bit that's going to be interesting is how the OS reconfigures to cope with the differences. that's why i'm interested to work with the KDE Team, and also why they're excited about the possibilities here. KDE Plasma Active's underlying core is designed to dynamically completely reconfigure the applications - right down to the size of the menus and what's *on* the menus - depending on the capabilities of the device (screen size and so on).

that's *really* fascinating and a perfect match. whoops, i woke up and found my screen has changed - err should i reboot? no, damnit! should i terminate the app and restart it? no, damnit! should i run a completely different app, one that's designed for the small (or big) screen size? no!!

KDE Plasma Active is about the only OS that even remotely has the capability to reconfigure right now in this way. everything else is like hard-configured for a particular device size. it's gonna be.... interesting, to say the least :)

yup

no problem. the only correlation is that the ethics that i've settled on which drive me to do things like rtmpdump you *know* that i will apply those exact same ethics to this new venture. that means that when i say "all products will be GPL compliant", i ABSOLUTELY MEAN IT. when i say "i want free software developers to be involved and to benefit from this synergy with china mass-volume factories", i ABSOLUTELY MEAN IT.

i do, but the price is *very* compelling. quotes i'm seeing are around $3.80 which is *half* that even of the Allwinner A10... and it's got PCI-Express, Gigabit Ethernet, SATA and USB-3. incredible. so, i can't turn the opportunity down.

what i'll do once a lot of money comes in is put some of that towards full-time payment of someone to do the reverse-engineering of powervr.

so i should not have any goals, should i? i should do what you want, i should listen to you, i should bow to your demands and i should go away and be the failure that you want, yes?

i think you need to be clear that you do not own me, you do not control me. you do your thing, and i'll do mine ok? have some respect for people's desire to keep going and to encourage others to succeed.

because that's what this is really about, adam, isn't it. you can't stand other people who are willing to keep on tackling failures and problems until they succeed.

i think you really need to get yourself sorted out. i don't expect you to react well to being told that, because that's the kind of vehement vicious petty-minded person that you are. in public no less.

did you ever stop to think about how your posts may be viewed by others in public? i do - and i'm happy with that. you on the other hand, i get the impression that you want to invite failure and you want to be seen going "har har this person's a faiiilure, this person's a faaailure".

well... you're a bully! and people don't like bullies! and you've declared to the world - because comments on the internet don't go away - that you're a bully!

yes. for the better. and thoughts make a difference. if you don't imagine you'll make a difference, you won't. maybe you're happy with the way things are. i'm not, therefore i do something about it. got a problem with that? then FUCK OFF and stay out of my way. you do your thing, with your thoughts; i'll do mine. let's not get together and compare notes in 4 years time.

the rbpi people are targetting education with a proprietary product which is restricted by the SoC vendor. you can be "educated" so far, but if you want to learn *really* how the device works then you can fuck right off - this is the core of the message that broadcom wants to give to young people.

i don't think that's an appropriate message to be sending to young people - that they can only learn within set limits. nor do i feel that it's appropriate for young people to be told that if they want to play videos they have to pay money for the privilege. that's absolutely disgraceful.

here's a more detailed article about that: http://whitequark.org/blog/2012/09/25/why-raspberry-pi-is-unsuitable-for-education/

the rhombus tech initiative's goals happen to indirectly encompass those of the raspberry pi foundation, in a different way and from a different angle. it will just so happen that every product will be lower-cost by virtue of being mass-produced; it will just so happen (for sound business reasons) that the products will be fully GPL compliant and open. therefore it will just so happen that those mass-volume open products will be suitable for use in educational settings.

and, unlike the raspberry pi, the CPUs being used will be current and up-to-date. it's only because we've been bootstrapping ourselves up from zero cash and zero investment, and that finding suppliers for the very unusual mid-mount and low-profile parts at the tail end of a standard's life has proven extreeemely challenging. but, now that we've found all the parts and suppliers, and got the PCB CAD/CAM libraries created for them, new CPU cards could potentially be done in about 3 weeks flat.

not yet!!! we have a plan, here, if it all goes to hell in a hand-basket: we use Cardbus (the gold-covered Type II). the gold-coloured shielding is earthed in 8 places directly to the PCB.

if you look closely at the PCB layouts i've done, you'll see e.g. on the A31 PCB that the SATA (1.5gbit/sec) and Ethernet (100mbit/sec spread-spectrum) are within 10mm of the connector. i believe the length of the SATA and Ethernet tracks are about 6 to 8mm in length.

we'll find out, eh? :) it's all so exciting, not having access to $250m of funding and having to wing it!

http://lkcl.net/articles/tiny.computers.txt

the above article may help also to give you some background about where this came from and where it's going.

this is precisely what we're setting out to show the mass-volume appliance industry, that there are people who *want* to buy product that is upgradeable and eco-conscious. strategically, what we're counting on is the fact that the "chassis" and "cpu cards" will be made separately in such high volume that the overhead of EOMA-68 (which is currently about $6 on the BOM in the 10k volumes range) will come down significantly and, also, that people will begin to recognise the value of the upgradeable approach and will actively seek out products and be prepared to pay the extra overhead, precisely because they DON'T have to shell out for an entire new product - just one or other half that they want, and they can even share the CPU Card between products, thus reducing the cost *overall* of buying multiple products.

i don't know if you've seen the cost of a motorola atrix lapdock: you can get them for around $70 [get the revision 1 don't buy the revision 2 they're locked to a specific USB device id!]. that gives you some idea of the extra cost of the CPU, RAM, NAND flash etc. which would normally go into a full "one PCB" style laptop. if you can share that cost across multiple products by only buying one really great CPU Card and three low-cost "Chassis" products, think how much money you saved rather than having to buy 3 products with 3 CPUs and 3 sets of RAM that you're never going to use all at once.

food for thought, huh?

let me answer the profitability issue first. we chose to re-use legacy housings, sockets and assemblies precisely because to do otherwise *would* result in this becoming a profitable venture only at cycle 3. there's a company in the U.S.+Taiwan which has had $USD 100m investment to create a 100mm x 70mm x 10mm modular PC standard. we've had *zero* investment.... and haven't needed it! the CPU Card development cost us under $10k. the tablet: $6k. getting new plastic done for the card because we're re-using PCMCIA metal casework from a product that's been made for the past 10 years straight: $6k.

so you're thinking inside-the-box, i feel compelled to point out :) we'll go into "profitability" with the first 10k order!! everyone involved has been working on a commission-only basis for the past 4 years on the project. there *are* no investors or banks to pay off. the first lot of profits will go straight back into the project and will begin to fund and reward the free software developers and other people who have been helping us out over the years, and that will happen pretty much immediately.

regarding the upgradeability and the durability of the standard: there's one factor that you've not taken into consideration, and it's the power requirements of faster interfaces. 10GbE over copper takes SIX WATTS, just to push the signals over those 4 twisted-pairs that's just... insane. as people have wanted faster and higher resolution screens, VGA has fallen by the wayside because at 75 ohms impedance, driving 3 lines at 200mhz and above in *analog* is just way waaay too power-hungry.

but look closely at the interfaces selected for EOMA-68. RGB/TTL (24-pin), I2C, USB3, Gigabit Ethernet and SATA. are any of those particularly critical that they be ultra-ultra-ultra-ultra-ultra fast? no not really. what are they connected to? well, they're connected to peripherals i.e. I/O. do you really really really really need an 8096x5000 resolution LCD panel on a 7in tablet? no not really. do you need a 10000Mbytes/second SATA hard drive on a 10in $150 laptop? no, not really. do you need 10 Gigabit Ethernet on a portable device where battery life is important? no, you don't.

so you're thinking of upgradeability as being all-important and the be-all and end-all of computing appliances, and i think you'll find that it really, really isn't that critical. at the apple end of the market? sure, there will be people who will always go after apple products, and the great thing is: just like microsoft's absolute-insane-latest-and-greatest processing and memory requirements have pushed the price of RAM down to $4 for 1GByte of 800mhz DDR3 RAM, so will apple's R&D costs *also* drive down the cost of parts for the rest of us who are happy to sell in much higher volume, quietly, to the rest of the world market including China which is 10x the size of the rest of the world's markets PUT TOGETHER and nobody knows it even exists.

summary: the strategy we've pursued immediately pays off, and the EOMA-68 standard's designed around a different market focus which i believe is sound for at least the next decade. we could always develop new standards that take advantage of the latest-and-greatest innovations, but they would be limited to the latest-and-greatest products. we're going after the bigger volumes - the cash cow markets - and helping the Factories to stabilise their products, take advantage of the latest-and-greatest as it filters down.

does that make sense?

i've learned from hunting around in one of the firmware packs for an RTD1186 HTDV product that the GPU is a PowerVR SGX 531.