Slashdot Mirror

i'm an alien, and i got a disruptive particle physics theory - no really! http://erm.lkcl.net/ - proving the point that you don't have to be an alien to be completely ignored for introducing disruptive theories of physics...

but seriously, much of this is covered in numerous sci-fi books. and also in star trek ("the prime directive"). ian banks "the culture" series was the most noteworthy set of books that explored the introduction (discovery or theft) of technology above the level / maturity of the species to cope with it. strict rules were put in place... one very interesting book explored "shell worlds"... well worth reading.

at least the author didn't mention anal probing [film Paul, "what IS it with you humans and the anal probing?? are we harvesting farts??"]

2.4ghz with 5GB of RAM is insanely quick, and an insane amount of RAM. it's only the fact that modern OSes are so stuffed with eye candy, adware and freeware that you've been hood-winked into BELIEVING that the OS *is* the computer. the only thing that will make a HUGE difference to speed is if you get yourself a GOOD SSD. by that i mean one with an Intel chipset i.e. not the 3700 series which is made *by* intel but using a shitty consumer-grade controller IC from Marvell. you want an S3500 or basically hunt around for anything that has "Intel Power-loss Protection". see here for full details http://lkcl.net/reports/ssd_an...

the actual OS doesn't techincally matter, none of them will make a blind bit of difference, you have such a fast machine, you might as well pick one that will make your life easiee.

all apps will work perfectly fine as long as you don't do what i do which is try to run qemu, two web browsers, 3D Graphics Editors, videos, IRC, 2D CAD Packages *and* try to compile the linux kernel all at the same time. this tends to bring even a machine with 16GB of 2400mhz DDR4 RAM to its knees. don't do it :) keep an eye on things, but libreoffice and a few tabs open in browsers should be fine.

your main concern is web browsers, which is one application, and you should try to keep the size of the window to the minimum that you can tolerate. i manage fine with chromium running at around 1024x800 and underneath that firefox with 200 tabs open ar around 1024x700 or so (i use a 3000 x 1600 resolution laptop screen).

someone else here suggested fvwm2: i too love it, because the startup time is well under half a second. for everyone else i recommend XFCE as it's based on the older gnome2 infrastructure so does well at auto-detecting drives and so on. the other desktop i love and thoroughly recommend for end-users is Trinity Desktop.

the only other thing i recommend is that you NOT install systemd as it actually slows boot times DOWN (as well as making your life geneerally hell). you can either install debian and then install sysvinit, which will "disable systemd but still leave it hanging around like a bad smell" or you can go the whole hog, add http://angband.pl/deban and actually get rid of it entirely, going back to udisk2, policykit, consolekit and other packages that debian's developers rather foolishly removed.

bottom line is, the threshold for "good enough computing" was crossed many many years ago, and it's only the marketing teams DELIBERATELY making the proprietary OSes do more so that your machine APPEARS so slow that you feel you HAVE to buy a new one... you see where that's going? anyway, welcome to the freedom that comes with being able to choose your own OS, you're one of the few people that actually has control of their computing hardware back, now.

I use pip install all the time...well pip3 install

pypl is great but they could increase their security at bit and still keep the same level of functionality.

it's actually incredibly comprehensive and extremely involved. for a completely separate team, i'm just in the process of writing up the requirements (following software engineering practices) which cover exactly this scenario: you can read them here if you like (note: they're in development and undergoing review): http://lkcl.net/reports/wot/

basically from that MASSIVE list - a whopping EIGHTEEN separate and distinct requirements and that's not even getting into implementation details - you should be getting that familiar sinking feeling that what you're asking for is simply... too much for the pypi team to handle on their own. to expect them to be able to do a full verification of each and absolutely every single one of the packages - in fact to even keep their *own website* secure from attack - is simply too much.

what *would* work is if the pypi team told all uploaders that the entire pypi infrastructure is converting over to a secure web-of-trust: that it is now following standard best practices followed for decades now by absolutely every single distro. namely: that uploaders are required to engage in key-signing parties and to register in a web-of-trust; that uploaders must then digitally GPG-sign their packages; and that pypi will only authorise a package as being online in the pypi index when they have GPG-signed a SHA2 checksum of the complete and full listing of every single package available for download on the entire pypi site.

new package uploaders would then also need to be "approved" - it would need to become impossible for just any arbitrary-named package to be uploaded, as their GPG key would need to be verified as being part of the web-of-trust. this would then stop dead in its tracks the exact sort of thing that's come up (but also provide the level of trust and reassurance in every single package which is completely missing right now).

basically, pypi needs to follow the exact same standard practices as any GNU/Linux Distro, and, to be absolutely bluntly honest, anyone who downloads arbitrarily untrusted software (like they do with windows, and including people who use ubuntu and download arbitrary .deb files, bypassing the entire purpose of the GPG web-of-trust behind apt-get and aptitude), gets precisely and exactly what they deserve. yes i have had acquaintances who have blithely downloaded a trojan'ed .deb package because it happened to have the same name. no he didn't bother to check its provenance.

so, justin, may i respectfully recommend that if peace of mind is important to you, and you also wish to not have to do a full audit of the source code that you're downloading, that you use a GNU/Linux Distro only, and STOP using pip and pypi? if you're using a mac or using windows, you could at least have a mirror-machine where you do (if it's debian) "apt-get install python-mysqldb" or "apt-get source python-mysqldb" and then copy that over?

at least in that way you will save yourself some time but also you know that someone - somewhere has staked their public reputation and career on a very public declaration that they have at least done _some_ sort of checking on the source code that they have GPG-signed and uploaded into a distro's package repository. if it's too out-of-date or is just not included, *then* you can use pip or just grab the .tgz source archive for yourself, and do some sort of auditing.

Sounds interesting, but I'd have to see a complete proposal before I'd chip in. I'd want to see the schedule, the budget, the resources, and the success criteria to know if the project succeeded.

most of the information you've asked for, because this is a *genuinely* open and transparent project, is on http://rhombus-tech.net/crowds... - including the BOM, a full risk analysis, and much more. having been around for a long time, long enough to have seen the openmoko fail, and the pi-top team break their promises, and the shit-storm that resulted from the purism team's deceptive marketing, and the difficulties that the openpandora team had with R.F. and firmware: if you have any specific advice, TELL ME. i WANT TO KNOW. best place to do that is the mailing list because then other people can help evaluate your proposals and questions - http://lists.phcomp.co.uk/pipe...

The summary sounds way too grand, so I think I'd want to see it broken down into pieces that are small enough to understand, too.

it's been five years: that's a lot of time to think, plan and get everything lined up. if you're interested in the background as to *why* i am tackling this, it may help to read the background section (first question) http://lkcl.net/articles/eoma6...

"breaking it down into small pieces" it turns out is extraordinarily difficult. the simplest i've found is, "you know like a pause memory pause card? yeah? well this is a pause computer pause card. same benefits as memory cards except now you move the *whole computer*". but even that often is not conceptually enough. after repeating things about 200 to 250 times at hope2016 (and losing my voice on the first day) there's a live video which you can find at https://www.crowdsupply.com/eo... - i managed to get it down to *only* 3 minutes, to cover *a few* of the benefits. the rest (that i have been able to think of over the past five years) are covered here in the "scenarios" section: http://rhombus-tech.net/whitep...

Also important to make sure nothing is overlooked, such as sufficient testing. Be fine if the same organization that helped check the proposal evaluated and reported on the results (perhaps holding the money, too).

well - it's just me, self-auditing with an "always transparent GENUINELY open approach learned from software libre project management of 20 years" unless other people pop up to help. so, you and everyone else on the mailing list will just have to keep an eye on me. and help out with the testing... because it's a software libre project, and i can't do everything, so *need help*. funny and really cool story: a guy called albert contacted me last month, asked if there was any plans to do a french keyboard. i went (internally), "argh, haven't got time, let's point him at the git repo and tell him about the STM32F072 nucleo boards, see what happens" and surpriiise! turns out he's an embedded hardware engineer... so guess what? he's now joined the mailing list and is helping to do french keyboard firmware and much more! https://www.crowdsupply.com/eo... and you can check the mailing list archives as well.

P.S. I think this is a solution to the general problems with all of the crowdfunding systems that I have examined. No accountability or adequate planning.

you're telling me. i spoke to a battery manufacturer last year: we had a bit of a laugh as he explained that a *FUNDED* project for a head-wearable device contacted them and asked him to violate the laws of physics. they'd used a high

Path Intelligence (reference)

Then you don't know Debian either. 4583 packages depend on "systemd" - see http://lkcl.net/reports/removi...

Apparently I know a shit more about Debian that lkcl does. He claims those are packages that depend on libsystemd0, which largely exists to make sure packages don't depend on systemd. And he gets it wrong!

Just take the first example on that list, "0ad":

# apt-cache show 0ad | grep systemd
[ crickets ]

If you want to know what depends on libsystemd (but why care?)

# apt-cache rdepends libsystemd0 | wc -l
71

Alarming? Not.

Then you don't know Debian either. 4583 packages depend on "systemd" - see http://lkcl.net/reports/removi...

From brief overview the arguments it does everything is fud

fud, as well as strawman. GP didn't say it does everything, GP said it takes over all of system management.

SystemD is no different than the other event driven alternatives

4583 package depend on it. Much much fewer depended on other "event driven alternatives". So you are wrong. http://lkcl.net/reports/removi...

That is my answer to the grandparents argument there was no need for change

Another strawman. They didn't say there was no need for change. They said "for many if not most an alternative to init was neither needed nor desired".

There are CONSTANT statements that if you do not use systemd you will not be able to use primary Linux distros in the future, because all software will supposedly be gobbled up by it as a dependency... To try and now make out like those dont exist is pretty silly.

not "supposedly" - *really*. if you run apt-rdepends -r libsystemd0 | a bit of awk | sort | uniq there are four *THOUSAND* five hundred packages that, if you were ever to do "apt-get --purge remove libsystemd0" you would NEVER be able to install. that's a whopping FIFTEEN PERCENT of the entire debian package repository that you are prevented and prohibited from installing, should you ever make the decision that you wish to keep libsystemd0 off of machines that you manage!

the reason for this insane level of *hard* dependency is because lennart pottering is both the developer of libsystemd0 *and* many other packages such as pulseaudio... so of *course* he decided that pulseaudio had to include - as a hard dependency - one of his projects, libsystemd0. libsdl likewise also uses it as a hard compile-time dependency, along with about 100 other applications and libraries.

those applications and libraries then quickly spread as further hard dependencies to include the gimp, apache2-dev, php5 (??!), erlang, libreoffice, cups, bluez/bluetooth (because of the links to pulseaudio), *all* the games that use libsdl (i.e. pretty much all of them), *all* the music software available for GNU/Linux (because of the link to pulseaudio), openjdk7, the eclipse IDE, apache tomcat, the android SDK, i mean.... the list is a _real_ eye-opener. you can review it here for yourself:

      http://lkcl.net/reports/removi...

so yeah, not even _close_ to "supposedly", mate!

whilst i find the practices of apple absolutely deplorable - forcing people to sign up for an ID in order to use hardware products that they have paid for, taking so much information that even *banks* won't work with them - bizarrely the amount of money that people pay them is sufficient for apple to spend considerable resources on high-quality components and design.

i have bought a stack of laptops in the past (and always installed Debian on them - see http://lkcl.net/reports/) and have found them to be okay, but always within 2 to 3 years they are showing their age or in some cases completely falling apart. the 2nd Acer TravelMate C112 i bought i actually wore a hole through the left shift key with my fingernail after 2 years of use. hard drives died, screen backlights failed, an HP laptop had such bad design on the power socket that it shorted out one day and almost caught fire. i had to scramble for a good few seconds to pull the battery out, smoke pouring out of the machine as the PMICs glowed.

about 6 years ago my partner had the opportunity to buy both an 18in and a 24in iMac at discounted prices. i immediately installed Debian on it: it took 4 days because grub2-efi was highly undocumented and experimental at the time. so i had a huge 1920x1200 24in screen (which over the next few years actually damaged my eyes because i was too close: my eyesight is now "prism" - i've documented this here on slashdot in the past), a lovely dual-core XEON, 2gb of RAM and it was *quiet*. there is a huge heatsink in the back, and the design uses passive cooling (vertical air convection).

awesome... except not very portable. and no spying or registration of confidential data with some arbitrary company that you *KNOW* is providing your details to the NSA, otherwise there's this conversation which begins "y'know it's *real* hard to get that export license for your products, if you know what i mean, mr CEO".

so, when i moved to holland i had to leave the 24in iMac behind - apart from anything, 2gb of RAM was just not enough. i leave firefox open for 4-7 days (basically until it crashes), opening over 150 sometimes even as many as 250 tabs in a single window. it gets to about 4gb of RAM and starts to become a problem: that's when i kill it. on the iMac, it was consuming most of the resident RAM. i compile programs: 2gb of RAM is barely enough for the linker phase of applications like webkit (which requires 1.6gb of RESIDENT memory in order to complete within a reasonable amount of time). i run VMs with OSes for study.

so i was used to the 1900x1200 screen now, where i could get *five* xterms across a single window. i run fvwm2 with a 6x4 virtual screen, and run over 30 xterms in different places, 3 different web browsers; as i am now developing hardware i run CAD programs in one fvwm2 virtual screen, PDFs in the ones next to it, i run Blender in one virtual screen, OpenSCAD in another, firefox in another, chromium in yet another, then i have to view and manage client machines so i use rdesktop to connect to those (move over to a free virtual window area to do it) - the list goes on and on.

so i figured, "hmmm laptop... but with good screen. must have lots of RAM too, minimum 8gb, must have decent processor". i then began investigating, and found the Lenovo Ideapad. great! let's buy it! .... except their web site crashed. so i then - reluctantly - began investigating iMac laptops. 2560x1600 LCD, 8gb of RAM, dual-core dual-threaded processor: $USD 1500 and *in the UK*, with a U.S. keyboard so nobody was buying it. researched it, saw the success reports of people installing debian on it, knew it could be done: sold, instantly.

so now i am extremely happy with this machine - not with apple themselves - but with the hardware that i have. it's light, it's fast, it's a sturdy aluminum case, the fan only comes on if i swish large OpenSCAD models around in 3D (or if firefox gets overbloated as usual).

the only downsi

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.

As far as I can discern without reading TFA, this is just some new ARM system-on-a-chip

No, it's much sillier than that. This is the latest in a long-running series of Slashvertisements by the submitter, lkcl. They chronicle his journey towards creating an "industry standard" for swappable processors for tablets based on the PCMCIA form factor. Nobody asked for this, nobody wants it, and lkcl has next to no experience with hardware development, but he's convinced it's going to change the world! To help the world along, he's working on-- actually, it looks like various Chinese companies are doing all the work. Anyway, lkcl is the funding conduit for an example card based on an existing ARM SoC. Today's story is about getting the first samples of the "2nd revision" of this card. Future samples are approved for sale as a standalone product because "they boot", which obviously qualifies them to ship.

In our last episode, lkcl digressed from his main project to announce a funding drive for a totally unrealistic project to build a free software-friendly SoC with a custom CPU in six months without doing any "design" work. Except for speeding up the processor, adding a bunch of peripherals, and implementing it on a cutting-edge semiconductor process. And then getting to market by Christmas. Just a small side project, right?

lkcl is pretty prolific on his own stories, so I'm sure his dozens of comment responses will answer all of your questions.

Previous episodes:
Live Interview: Luke Leighton of Rhombus Tech Dec 11, 2012: Live interview that nobody saw. There doesn't seem to be a transcript.

Rhombus Tech A10 EOMA-68 CPU Card Schematics Completed Sept 7, 2012: PCB schematics (for the first revision -- prototype?) completed.

PCMCIA Computer Project Aims Even Higher (and Cheaper) Than Raspberry Pi Dec 17, 2011: Project announced? This is as far back as the Rhombus Tech news page goes.

If you have a better plan for long-term control of carbon emissions than cutting our dependency on the internal combustion (and diesel) engine, I'd love to hear it.

yes. i do. the details are here http://lkcl.net/ev and the plan is to create a parallel hybrid 4-seat vehicle weighing only 350kg, with a drag coefficient below 0.15 and using a 2-stroke diesel engine based around the bourke design, producing only about 5kW along-side a 10kW electric motor.

the reason for only 350kg is because it's the E.U Category L7e maximum limit - "Heavy Quadricycle". the reduction in materials gives a two-fold benefit: reduced production cost but also reduced running costs (less friction and less weight to accelerate or overcome gravity).

the 0.15 drag coefficient can be achieved using a special bodywork design that i've come up with, which does *not* compromise passenger safety by requiring them to be squished into an unattractive lethal bullet-shaped vehicle that would fall over sideways at the first corner.

the reason for the parallel hybrid is because it's a lower cost than series hybrid.

the reason for putting in an ultra-efficient diesel engine is because expecting people to get away from fossil fuels in the immediate future is asking for trouble. you need a transition technology that bridges the gap until the infrastructure can handle the replacement.

all of this makes a fuel economy target of 200mpg+ really quite straightforward to achieve. that alone reduces carbon emissions and smog.

if you'd like to support this project please do contact me. i live in hope that people reading this are more than just curious that someone is designing something like this and is prepared to help fund it as well.

there's something very very wrong with converting pre-existing ICE cars to electric. look up the phrase "mass decompounding" for a clue, but in essence it's that a ICE vehicle is designed around carrying one very large heavy object which is typically 15% of the mass of the vehicle: the engine.

the *correct* thing - ecologically - is to design and build a vehicle that's right for the environment, based around the most efficient kind of drivetrain: parallel hybrid. it's possible then to get below 350kg, still carry 4 passengers, and only need about 15kW (20HP) even to reach 65 to 70mph. the problem is that for the average person, designing an entirely new vehicle from scratch is pretty much beyond their time and resources. the problem for manufacturers is, as anyone who has read "The Other side of Innovation" knows, to throw away the entire "efficient business production model" which has been highly optimised to make ICE vehicles and start from scratch - this is virtually impossible for them. (then there is the problem of laws regarding spare parts - but all of this is outlined here http://lkcl.net/ev/hybridcars_article.html)

so we are left with a rather shitty situation in which the only way in which the average person may make themselves "feel better about the environment" is to purchase an above-average amount of one rare earth metal (lithium), purchase an above-average amount of another rare earth metal whose extraction methods are seriously environmentally questionable (neodymium), purchase an excessive amount of a metal which is increasingly becoming in short supply (copper), throw far more of these materials into an excessively-heavy and over-engineered vehicle than should really be necessary, and call this utter waste of resources "progress".

even manufacturers trying to make us "feel better about the environment" by designing parallel hybrids - they're doing so by taking pre-existing 1.5 tonne vehicle designs and shoe-horning in expensive batteries and expensive motors (which adds to the weight and the cost) and everyone wonders why they stop making the vehicles when the government subsidies stop.

all-electric cars are a DEFINITE no - regardless of whether they're made by the average person or made by a manufacturer. we simply don't have enough lithium or other battery material to go round, for everyone in the world to have an all-electric vehicle. we also don't have enough copper or neodymium for everyone in the world to have 1.5 tonne (average weight) vehicles. we also don't have the Grid Infrastructure in cities to cope with the extra power. major cities in 3rd world and emerging markets are *ALREADY* on brown-outs, overload, or 3-day weeks.

the bottom line is that we *have* to get the power usage down, resource usage down (less weight equals less materials), and the best way to do that is with a 10kW electric motor in combination with a 2-stroke 5kW diesel engine as a Parallel Hybrid. the size of each of those two engines can be made absolutely tiny, yet there's enough power to do 70mph (eventually).

and if this all sounds like "talk" - it's not. my vehicle's also listed on evalbum.com. the main web site: http://lkcl.net/ev. i have a 2nd design in the planning phase: it's a 4-seater. given the issues and challenges involved in getting vehicles out there, if you'd *really* like to help the environment, then help me make sure these designs get put into production - please don't spend $14,000 on converting a pre-existing vehicle: consider spending $8,000 on a light-weight vehicle that's designed to be efficient in the first place.

there's something very very wrong with converting pre-existing ICE cars to electric. look up the phrase "mass decompounding" for a clue, but in essence it's that a ICE vehicle is designed around carrying one very large heavy object which is typically 15% of the mass of the vehicle: the engine.

the *correct* thing - ecologically - is to design and build a vehicle that's right for the environment, based around the most efficient kind of drivetrain: parallel hybrid. it's possible then to get below 350kg, still carry 4 passengers, and only need about 15kW (20HP) even to reach 65 to 70mph. the problem is that for the average person, designing an entirely new vehicle from scratch is pretty much beyond their time and resources. the problem for manufacturers is, as anyone who has read "The Other side of Innovation" knows, to throw away the entire "efficient business production model" which has been highly optimised to make ICE vehicles and start from scratch - this is virtually impossible for them. (then there is the problem of laws regarding spare parts - but all of this is outlined here http://lkcl.net/ev/hybridcars_article.html)

so we are left with a rather shitty situation in which the only way in which the average person may make themselves "feel better about the environment" is to purchase an above-average amount of one rare earth metal (lithium), purchase an above-average amount of another rare earth metal whose extraction methods are seriously environmentally questionable (neodymium), purchase an excessive amount of a metal which is increasingly becoming in short supply (copper), throw far more of these materials into an excessively-heavy and over-engineered vehicle than should really be necessary, and call this utter waste of resources "progress".

even manufacturers trying to make us "feel better about the environment" by designing parallel hybrids - they're doing so by taking pre-existing 1.5 tonne vehicle designs and shoe-horning in expensive batteries and expensive motors (which adds to the weight and the cost) and everyone wonders why they stop making the vehicles when the government subsidies stop.

all-electric cars are a DEFINITE no - regardless of whether they're made by the average person or made by a manufacturer. we simply don't have enough lithium or other battery material to go round, for everyone in the world to have an all-electric vehicle. we also don't have enough copper or neodymium for everyone in the world to have 1.5 tonne (average weight) vehicles. we also don't have the Grid Infrastructure in cities to cope with the extra power. major cities in 3rd world and emerging markets are *ALREADY* on brown-outs, overload, or 3-day weeks.

the bottom line is that we *have* to get the power usage down, resource usage down (less weight equals less materials), and the best way to do that is with a 10kW electric motor in combination with a 2-stroke 5kW diesel engine as a Parallel Hybrid. the size of each of those two engines can be made absolutely tiny, yet there's enough power to do 70mph (eventually).

and if this all sounds like "talk" - it's not. my vehicle's also listed on evalbum.com. the main web site: http://lkcl.net/ev. i have a 2nd design in the planning phase: it's a 4-seater. given the issues and challenges involved in getting vehicles out there, if you'd *really* like to help the environment, then help me make sure these designs get put into production - please don't spend $14,000 on converting a pre-existing vehicle: consider spending $8,000 on a light-weight vehicle that's designed to be efficient in the first place.

Sorry, I have an x86/amd64 + DEC alpha historical bias, and don't really know a lot about ARM.

As a user, having the "southbridge" stuff integrated onto the CPU card means that you're essentially getting a whole new motherboard when you replace this CPU card. I always view a whole new motherboard as a whole new set of problems, in terms of potentially buggy hardware and drivers.

yes. absolutely. you've put your finger on the problem. i've mentioned this before, and... hang on, i think i even wrote a message to linus torvalds but of course, he's far too busy to read it :) 1sec let me see if i can find it.... hard to find hints, try this http://lkcl.net/linux/eoma.initiative.txt but also go (briefly!) over some of the others: http://lkcl.net/linux

the point is that each ARM processor is *wildly* different from all other ARM processors. linus doesn't understand this. he was at a meeting of all the arch maintainers and said "over half of you are from the ARM arch. go away! get yourselves sorted out!" and what he doesn't understand is that that's an impossible task. not even "device tree" will help solve it.

because all these ARM (and MIPS) processors are so heavily-integrated, there can NEVER BE a "common BIOS", and the level of commonality between each of the processors is so small that it forces the linux kernel to *become* the BIOS, effectively. i actually recommended at one point that the linux kernel be split down into separate projects: core, architecture support and device drivers. and i do _mean_ separate projects, each with their own separate source tree and maintainers.

then, not only is there virtually no common code between each of the processors (hundreds of them... and increasing) but then, precisely because of this total lack of commonality, and precisely because of the practice of "integrating" the CPU onto the motherboard, each device that *uses* one of these CPUs is UTTERLY UNIQUE.

let that sink in for a second.

every single piece of hardware which has an ARM or MIPS processor has UTTERLY UNIQUE code which *HARD-CODES* the ENTIRE device driver layout.

no wonder they're pushing this thing called "device tree" so hard, as it's believed that it will solve the problem: it won't. all it will do is move the problem out of *some* of the linux kernel source code, and will move the problem into the device-tree specification files, whilst also at the same time complicating the development of the device drivers themselves. ... but it doesn't end there. whereas in the x86 world, there's a BIOS which sorts out the boot process, there's... nothing in the ARM or MIPS world. so someone decided it would be a good idea, instead of using kexec, to create "u-boot". u-boot is a bastardisation of libc and bits of the linux kernel, combined into one application, allowing you to write very basic c applications, enough to initialise the low-level hardware and give you a few options. the problem is: it pulls in "bits of the linux kernel", in order to start up the hardware. can you spell "code duplication" and "maintenance nightmare?".

so this is one of the real reasons why we've come up with the EOMA initiative: to solve not only the GPL violations problem but also to help reduce the "device-driver nightmare" to manageable levels. think about it: rather than it being a "N CPUs" *times* "M hardware products", by splitting the products into modules along a series of "Bus-level" interfaces (SATA, USB, Eth, I2C), the linux kernel source code to support EOMA can be a "N CPUs" *plus* "M hardware products" *plus* a little bit of library overhead.

you see how powerful that is? we recognise that x86 is much, much easier to develop linux kernel support for, mostly because of common BIOS support but more because of the common dynamic "Buses" like PCI, PCIe, USB2, Firewire etc. all of which provide a clean bre

Sorry, I have an x86/amd64 + DEC alpha historical bias, and don't really know a lot about ARM.

As a user, having the "southbridge" stuff integrated onto the CPU card means that you're essentially getting a whole new motherboard when you replace this CPU card. I always view a whole new motherboard as a whole new set of problems, in terms of potentially buggy hardware and drivers.

yes. absolutely. you've put your finger on the problem. i've mentioned this before, and... hang on, i think i even wrote a message to linus torvalds but of course, he's far too busy to read it :) 1sec let me see if i can find it.... hard to find hints, try this http://lkcl.net/linux/eoma.initiative.txt but also go (briefly!) over some of the others: http://lkcl.net/linux

the point is that each ARM processor is *wildly* different from all other ARM processors. linus doesn't understand this. he was at a meeting of all the arch maintainers and said "over half of you are from the ARM arch. go away! get yourselves sorted out!" and what he doesn't understand is that that's an impossible task. not even "device tree" will help solve it.

because all these ARM (and MIPS) processors are so heavily-integrated, there can NEVER BE a "common BIOS", and the level of commonality between each of the processors is so small that it forces the linux kernel to *become* the BIOS, effectively. i actually recommended at one point that the linux kernel be split down into separate projects: core, architecture support and device drivers. and i do _mean_ separate projects, each with their own separate source tree and maintainers.

then, not only is there virtually no common code between each of the processors (hundreds of them... and increasing) but then, precisely because of this total lack of commonality, and precisely because of the practice of "integrating" the CPU onto the motherboard, each device that *uses* one of these CPUs is UTTERLY UNIQUE.

let that sink in for a second.

every single piece of hardware which has an ARM or MIPS processor has UTTERLY UNIQUE code which *HARD-CODES* the ENTIRE device driver layout.

no wonder they're pushing this thing called "device tree" so hard, as it's believed that it will solve the problem: it won't. all it will do is move the problem out of *some* of the linux kernel source code, and will move the problem into the device-tree specification files, whilst also at the same time complicating the development of the device drivers themselves. ... but it doesn't end there. whereas in the x86 world, there's a BIOS which sorts out the boot process, there's... nothing in the ARM or MIPS world. so someone decided it would be a good idea, instead of using kexec, to create "u-boot". u-boot is a bastardisation of libc and bits of the linux kernel, combined into one application, allowing you to write very basic c applications, enough to initialise the low-level hardware and give you a few options. the problem is: it pulls in "bits of the linux kernel", in order to start up the hardware. can you spell "code duplication" and "maintenance nightmare?".

so this is one of the real reasons why we've come up with the EOMA initiative: to solve not only the GPL violations problem but also to help reduce the "device-driver nightmare" to manageable levels. think about it: rather than it being a "N CPUs" *times* "M hardware products", by splitting the products into modules along a series of "Bus-level" interfaces (SATA, USB, Eth, I2C), the linux kernel source code to support EOMA can be a "N CPUs" *plus* "M hardware products" *plus* a little bit of library overhead.

you see how powerful that is? we recognise that x86 is much, much easier to develop linux kernel support for, mostly because of common BIOS support but more because of the common dynamic "Buses" like PCI, PCIe, USB2, Firewire etc. all of which provide a clean bre

well... i'm designing an engine, at the moment: http://lkcl.net/engine for this project http://facebook.com/UltraEfficientVehicles. the actual complexity of the maths required to do a proper job is waay beyond my abilities, so i am using iterative programming with python, as a temporary substitute.

to give you an example of the kinds of things i need to do: the design is a cross between a revetec and a bourke. if you've not heard of either of those: the revetec uses counter-rotating multi-lobate cams instead of a crank (2 tri-lobe cams shared across 6 cylinders), and the bourke used a scotch yoke to get a perfect sine wave. both designs have extended dwell time at TDC.

so basically, the "bang" is longer, hotter and quicker than a standard crank. what that means is that the exhaust gases are *not* burning as the piston goes away from TDC. and, with the cams, it's possible to arrange them so that as the piston falls away, the pressure against the cam face is turned into a *continuous* torque. so then, the advantage of the cams therefore is not just that you can get a torque pressure for over 120 degrees (as opposed to only 40 for a crank), but that you can do *anything* - including tricks like the above.

so the equation that i need to solve is that the rate of change of the face of the cam, acting as a lever to produce torque, where the lever is itself shrinking in length (because the cam face is dropping towards the centre of the spinning cam), equalises the torque as the amount of pressure falls off due to the expansion of the hot gases. luckily - and i say luckily - because "detonation" is being used (above 1800F you get the hydrogen burning as well as the carbon, so it's all over in under a microsecond) there's no burning gases so it's not as complex as it could be.

as i simply haven't got the level of maths to express the equation properly, nor do i know what sort of pressures will actually be involved in a 70cc cylinder, nor do i yet know exactly what compression ratio it's going to run at (i've made some adjustments to the cylinder's stroke), i am having to do the best i can.

so to calculate a first version of the cam, i ended up using a spline curve to roughly match a sine wave and then altered it slightly. even here, however, my first attempt to calculate the cam face was an O(N-cubed) algorithm, and i had to look up "line through circle" which is y=mx+c into y-squared + x-squared = r-squared and use that to reduce it to a more accurate O(N-squared) algorithm.

bottom line is: hell yes you lucky bastard if you've got an opportunity to learn some more maths for god's sake do so. you're damn lucky: you could probably solve the equations needed to sort this stuff out in a couple of hours, whereas it's taken me two weeks of thought and experimentation to get as far as i have, not having access to the right level of expertise.

btw, to the guy who said "instead of calculus, use linear algebra" - you're dead wrong. the iterative loops i'm using are a very poor substitute. when i zoomed in on the critical sections of the results (the DXF output) of what i'd produced, i found that they were wrong. i had to increase the number of steps around the 360 degree circle to 1,440 and the inner loop steps to 14,400 in order to get a level of accuracy that looked acceptable, and i don't actually know if it's going to be good enough.

if instead i had the right maths, i could have used it to calculate the tangent of the roller-bearing as it drops against the face of the cam, and worked out properly, with an O(N) loop, what the cam face should be. the O(N-squared) loop is because i have to "simulate" a CNC milling tool the exact radius of the bearing going round, "shaving" the cam face away, taking a minimum distance (hence the line meeting the circle) as the bearing rotates through 360 degrees (inner loop, 14400 steps) as the cam rotates through 360 degrees (outer loop, 1440 steps). this iterative technique is *not* as accurate as using calculus.

So, basically, hybrids aren't cost effective enough for people buying primarily on cost, and they're not green enough for people buying primarily on environmental friendliness. As all-electrics continue to improve, the age of the hybrid will come to an end.

the CURRENT design of hybrids aren't cost-effective enough nor are they green enough.

the reason is very very simple: if the car has the same size as an ICE equivalent, has the same aerodynamics as an ICE equivalent, has the same weight as an ICE equivalent, has the same tyres as an ICE equivalent, and has an on-board charging system that's still basically no more or no less than an ICE (with a generator attached to it in the case of Series Hybrid), where the bloody hell do you imagine that *any* significant energy savings could possibly be realised?

the energy savings have to come from somewhere. the one biggest saving by a long long margin is aerodynamics. the second is weight (rolling resistance, friction, intertia and gravity). it's basic physics, and it's completely unavoidable!

i don't know why anybody's surprised that if you don't reduce energy losses, you don't make any savings, regardless of the components that go into the vehicle. which is why i've been doing a "money where mouth is" thing and actually designed an ultra-efficient hybrid electric vehicle - http://lkcl.net/ev. it's 350kg, it's a Category L7E, and the target is 5kW energy consumption at 60mph. it's not hard to do. the key is in the aerodynamics.

well... y'know what? even brownian motion gets it right if there's enough molecules. the trick is in being able to spot the one molecule that pops out at the right place at the right time, and this is no different, really.

out of hundreds of articles on climate theory predictions, at least _one_ of them had to get it right. the problem is this, however: that correctness could only be spotted in retrospect, and so doesn't actually help us *unless* the article goes on to predict a bit further into the future, and even then it *still* doesn't really help us to solve the problem (which is that action needs to be taken) because, once again, people really won't listen until it's yet *again* too late.

all of which goes to just highlight that the problem is not the predictions, but that nothing's been done *about* those predictions. so that just leaves it to us to DO something, as individuals. which is why i'm actually doing something, in two areas that i am interested in: cars - http://lkcl.net/ev - and computers - http://rhombus-tech.net./ what are _you_ doing, slashdot reader?

hey fuck you too, google+! http://lkcl.net/SANY0051.JPG

ok, i've written about this on a number of occasions, such as this one http://lkcl.net/linux/ideal-vs-reality.of.product.development.html but it's definitely worthwhile repeating things here, in this context.

GPL violations occur because the lowest-cost hardware is made by china factories who simply have zero software expertise. they just don't know enough to even *ask* for the GPL source code: they wouldn't know what to do with it if they received it: it's scarily-large, would consume vast amounts of their time and money (thus making them uncompetitive against all the other factories who will have also bought the exact same Reference Design), and there is a severe educational and economic shortage of software engineers in China anyway.

so, they ask an ODM for a ready-made solution, and they get one. any companies trying to deviate from the "solution" typically ship built-in webcams and microphones that don't even work because the binary-only firmware supplied by the ODM never had support for webcams or microphones!

but, you don't buy hardware from a china factory (because you can't "trust" them not to rip you off, right? and you don't want to deal with Customs and Import Tax, do you?) so you go to a retail store. but the retail store didn't get the hardware directly from china, they got it from a wholesale importer.

you see where this is going? neither the retailer, nor the wholesale importer, nor the factory that actually made the product ever saw, or understood, or even knew of the existence of, the GPL source code. yet, in strict accordance with the GPL you *have* to go "down the chain" of suppliers - you *cannot* go directly to the factory or even to the ODM - not least because you don't even know who they are!

second part of the answer is that each and every single device is radically different from any other device. there is no BIOS. there is no "commonality" between devices even with the same CPU! the GPL Linux Kernel is the *only* place where the information about the hardware is codified, in the form of "GPIO pin 12 fires up the WIFI in this tablet sold by this manufacturer" but "GPIO pin 87 fires up the WIFI in this completely different tablet, using the exact same CPU, from a different or even the same manufacturer".

this situation is causing absolute hell on earth for russell king, who is becoming increasingly despondent and depressed, as he has been "in the middle" of this for several years now: he's getting completely overwhelmed by the proliferation of ARM CPUs (over 1,000 now) multiplied by the number of devices using those CPUs (tens of thousands of designs). i have written up a sensible solution but getting through to linus and russell is somewhat challenging - http://lkcl.net/linux/linux-selfish.vs.cooperation.html

the other thing is that Android, which is a *userspace* set of applications *not* an "Operating System", is *not* GPL-based, it's Apache-2 licensed. then, also, there is a heavily-modified version of the Linux Kernel required for Android, and this version of the Linux Kernel *is* GPL-licensed. there is, understandably, considerable confusion and ignorance over this issue, right across the board.

so the problem really is the GPL violations on the Linux Kernel (including the one that is modified for use in Android, which is of course GPL-licensed), and also the GPL violations on the U-Boot Source Code, because this is where the hardware layout is "codified". without that information, it really is absolute hell on earth to find out what's going on. going back to about 2004, i've done reverse-engineering of about 12 ARM-based devices, now, so i know what it takes. you can't even compile up certain userspace applications, because the linux kernel header files are missing (/usr/include/linux).

then, you want to wipe the device and install debian? ok, so where in the NAND flash

ok, i've written about this on a number of occasions, such as this one http://lkcl.net/linux/ideal-vs-reality.of.product.development.html but it's definitely worthwhile repeating things here, in this context.

GPL violations occur because the lowest-cost hardware is made by china factories who simply have zero software expertise. they just don't know enough to even *ask* for the GPL source code: they wouldn't know what to do with it if they received it: it's scarily-large, would consume vast amounts of their time and money (thus making them uncompetitive against all the other factories who will have also bought the exact same Reference Design), and there is a severe educational and economic shortage of software engineers in China anyway.

so, they ask an ODM for a ready-made solution, and they get one. any companies trying to deviate from the "solution" typically ship built-in webcams and microphones that don't even work because the binary-only firmware supplied by the ODM never had support for webcams or microphones!

but, you don't buy hardware from a china factory (because you can't "trust" them not to rip you off, right? and you don't want to deal with Customs and Import Tax, do you?) so you go to a retail store. but the retail store didn't get the hardware directly from china, they got it from a wholesale importer.

you see where this is going? neither the retailer, nor the wholesale importer, nor the factory that actually made the product ever saw, or understood, or even knew of the existence of, the GPL source code. yet, in strict accordance with the GPL you *have* to go "down the chain" of suppliers - you *cannot* go directly to the factory or even to the ODM - not least because you don't even know who they are!

second part of the answer is that each and every single device is radically different from any other device. there is no BIOS. there is no "commonality" between devices even with the same CPU! the GPL Linux Kernel is the *only* place where the information about the hardware is codified, in the form of "GPIO pin 12 fires up the WIFI in this tablet sold by this manufacturer" but "GPIO pin 87 fires up the WIFI in this completely different tablet, using the exact same CPU, from a different or even the same manufacturer".

this situation is causing absolute hell on earth for russell king, who is becoming increasingly despondent and depressed, as he has been "in the middle" of this for several years now: he's getting completely overwhelmed by the proliferation of ARM CPUs (over 1,000 now) multiplied by the number of devices using those CPUs (tens of thousands of designs). i have written up a sensible solution but getting through to linus and russell is somewhat challenging - http://lkcl.net/linux/linux-selfish.vs.cooperation.html

the other thing is that Android, which is a *userspace* set of applications *not* an "Operating System", is *not* GPL-based, it's Apache-2 licensed. then, also, there is a heavily-modified version of the Linux Kernel required for Android, and this version of the Linux Kernel *is* GPL-licensed. there is, understandably, considerable confusion and ignorance over this issue, right across the board.

so the problem really is the GPL violations on the Linux Kernel (including the one that is modified for use in Android, which is of course GPL-licensed), and also the GPL violations on the U-Boot Source Code, because this is where the hardware layout is "codified". without that information, it really is absolute hell on earth to find out what's going on. going back to about 2004, i've done reverse-engineering of about 12 ARM-based devices, now, so i know what it takes. you can't even compile up certain userspace applications, because the linux kernel header files are missing (/usr/include/linux).

then, you want to wipe the device and install debian? ok, so where in the NAND flash

the article is entirely missing the point. range extension doesn't help if the vehicle into which the range extension is placed is massively inefficient. that means that you need to fix the problems associated with standard vehicle designs (box and wedge shapes) in order to get the aerodynamics losses cut by at least 50%, and you need to cut the weight by over 70% (1.5 to 2.0 tonnes down to 350kg) in order to be able to take advantage of hard compound "ECO" tyres, which would otherwise rapidly wear out on a "standard" car. once the aerodynamics are efficient and the weight is low, "range extension" actually provides enough power to run the vehicle pretty much directly. see http://lkcl.net/ev for details.

First, adjust your view of what it means to get the best aerodynamics. The Mercedes Boxfish car (http://www.google.com/search?client=ubuntu&channel=fs&q=mercedes+boxfish+car&ie=utf-8&oe=utf-8) does better than nearly any car out there for fuel efficiency - especially when compared in the same engine type, and would not meet what you say - it's very boxy in front and wedge-like in back.

Second, if you want to reduce weight then you need to use stronger materials. Those materials are likely going to be more expensive than the heavier but cheap materials currently being used. If you don't do that, then safety is out the window and the vehicle won't be able to be sold.

Third, Range Extension is important. Yes, most of the time you may not drive more than 40 miles both ways to work. But it's easy to put on 100 miles a day when running errands - even 150 miles, and you might do that all without going back home or stopping to recharge the vehicle if you started out with full tank/capacity. So certainly having at least a 200 mile range would be required for 90% of the vehicular uses. However, you still need to extend that so allow people to travel the full day easily, and this is where Range Extension comes in - making that 400, 800, or 1000 mile trip in a single day - e.g. for a funeral or medical emergency on short notice, seeing family for the holidays, or simply traveling to school (e.g. college students - I've known some to travel a couple thousand miles in a short time-frame, stopping only when required; so range extension would be vital).

Does Range Extension need to be efficient? Not extremely so, but certainly more efficient the better.

Personally, I take the stance that a vehicle that cannot travel upwards of 1000 miles a day is useless to me; but then, I do travel long distances (950 miles a day) in a day at times to see friends and family for special occasions (e.g. weddings, holidays). However, I have no problem with a system where I could travel 400-500 miles and then stop for a meal and recharge over the course of the meal (e.g. between 30 and 90 minutes depending on the restaurant); but what is most useful is a pure electric vehicle with an assistant motor (e.g. gas, etc.) to recharge the batteries relatively efficiently (e.g. 1 gallon of gas to go from low charge to full capacity while the vehicle is fully operating) - Chevy Volt comes close, but still misses the mark just a bit - but it's better than nearly all the others (e.g. Toyota Prius) in their approaches by a magnitudes.

the article is entirely missing the point. range extension doesn't help if the vehicle into which the range extension is placed is massively inefficient. that means that you need to fix the problems associated with standard vehicle designs (box and wedge shapes) in order to get the aerodynamics losses cut by at least 50%, and you need to cut the weight by over 70% (1.5 to 2.0 tonnes down to 350kg) in order to be able to take advantage of hard compound "ECO" tyres, which would otherwise rapidly wear out on a "standard" car. once the aerodynamics are efficient and the weight is low, "range extension" actually provides enough power to run the vehicle pretty much directly. see http://lkcl.net/ev for details.

debian installer is very much misunderstood or at least underappreciated. i did a very very large (significant deviation / automated installation) system for automated customised installs of KDE desktop. some people said i would have been better off creating debian packages with postinst and preinst scripts, but i liked the convenience of being able to edit the shell scripts etc. etc. *without* having to run a debian package-create command. the results of the work are still here: http://lkcl.net/d-i/

anyway, you could quite easily use debian installer over PXE netboot - you just put the target repository that you want things to be loaded from into the standard kernel boot params (into the PXE config file) and debian installer will go "oh, i'm supposed to run in automated mode and to pick up scripts from http://lkcl.net/d-i let's do that then, eh?"

then you could have one automated installer which does the "wipe" process and another which does the "backup", and another which does the "reinstall". all specified via simple editing of PXE config files. just don't get them wrong, eh? :)

btw, in 2001 i was part of a team that did this sort of thing, entirely automated from a database. it was very cool. we even solved booting up and reinstalling NT systems (fast), by having a sysprep-enabled part-completed boot image that just needed finishing off.

debian installer is very much misunderstood or at least underappreciated. i did a very very large (significant deviation / automated installation) system for automated customised installs of KDE desktop. some people said i would have been better off creating debian packages with postinst and preinst scripts, but i liked the convenience of being able to edit the shell scripts etc. etc. *without* having to run a debian package-create command. the results of the work are still here: http://lkcl.net/d-i/

anyway, you could quite easily use debian installer over PXE netboot - you just put the target repository that you want things to be loaded from into the standard kernel boot params (into the PXE config file) and debian installer will go "oh, i'm supposed to run in automated mode and to pick up scripts from http://lkcl.net/d-i let's do that then, eh?"

then you could have one automated installer which does the "wipe" process and another which does the "backup", and another which does the "reinstall". all specified via simple editing of PXE config files. just don't get them wrong, eh? :)

btw, in 2001 i was part of a team that did this sort of thing, entirely automated from a database. it was very cool. we even solved booting up and reinstalling NT systems (fast), by having a sysprep-enabled part-completed boot image that just needed finishing off.

gbrmh, thank you for these really valuable comments and links.

regarding the aerodynamics: it's because i had to place absolutely every single point and triangle using mm3d by hand! crazed as that sounds, it means i had to pay attention to every single aspect and detail, but yet it is still slowly morphing into something that resembles, at the base, a 2-seater canoe, and on the top a classic delta-wing.

also bear in mind that it came out of point-matching around photographs (front, side, top, back) where the original cardboard model had literally been sliced and hacked with an ultra-sharp serrated-edge tomato kitchen knife, and bits of replacement cardboard stuck on with tape! it's surprisingly effective.

regarding the cars, i think it's essential that i review those separately: i'll add them to http://lkcl.net/ev/comparison.html shortly.

thank you!

after 150 years, the design of the lead-acid cell has not really been improved on. rainer partenan's nanotech aluminium-based battery which has (had) a 5x storage capacity improvement for its weight over NiMh was thoroughly discredited. research grants 15 years ago by the U.S. Govt were *only* given for batteries with a voltage over 2.0 volts, in order, one can only assume, to prevent and prohibit the funding and discovery of aluminium-based battery technology.

we therefore have to work with what we've got: it's no good saying "oh we have to wait yet _another_ decade or two until someone comes up with the goods" FUCK that, there are more ways than one to skin a cat, ok?

so the alternatives are to skin the vehicle down to an absolute minimum required, then make it *look* from the outside (for social acceptance as well as driving safety reasons) like it's a "full-on square back-sided car" jobbie. in other words, you stuff a massively-streamlined body inside an empty outer shell. this is the principle behind what i'm working on - http://lkcl.net/ev

it's _not_ all about the batteries. we _have_ all the pieces of the puzzle already - have done for over 5 years now. it's just that nobody's put them all together... yet.

read "the other side of innovation" also see article here http://www.hybridcar.com/index.php?option=com_content&task=view&id=822&Itemid=122 you may need to get the text version here - http://lkcl.net/ev/curious_state_of_hybrids.txt

innovation is virtually impossible for mass-production companies to "slot in" to the "efficiency engine". they literally can't do it. there are also legal issues that need to be taken into account, such as a guaranteed 7-year-supply of parts *after* the vehicle's *last* mass-production run is finished.

the article above goes into detail.
http://lkcl.net/ev

read "the other side of innovation" also see article here http://www.hybridcar.com/index.php?option=com_content&task=view&id=822&Itemid=122 you may need to get the text version here - http://lkcl.net/ev/curious_state_of_hybrids.txt

innovation is virtually impossible for mass-production companies to "slot in" to the "efficiency engine". they literally can't do it. there are also legal issues that need to be taken into account, such as a guaranteed 7-year-supply of parts *after* the vehicle's *last* mass-production run is finished.

the article above goes into detail.
http://lkcl.net/ev

why am i not surprised! it's funny (not really) but this accident vindicates what i've been talking about. you _can't_ put a material that spontaneously catches fire when exposed to air and water (lithium) into a car! so you have to use "safe" non-explosive materials such as gasoline or diesel (no, you cannot set light to gasoline even with a naked flame, you have to vapourise it, mix it with air and hit it with a spark), and lead-acid for the batteries. that means that you have to go back to the drawing board, use a smaller battery pack, use less energy and so on. it's the driving force behind the design i'm working on - details here: http://lkcl.net/ev

for mountain driving, fuel economy understandably critically depends on the weight. if you have a 550kg vehicle (including passengers) and a 25% gradient, then even at 50mph you still get almost 60mpg. if however on the other hand the weight is 1550kg, then that fuel economy drops staggeringly quick: expect to get best case 20mpg.

i'll add "gradient" in a moment to the simulator i'm writing, so you can try it out here: http://lkcl.net/ev/vehicle_simulator/output/Simulator.html

yes, they are exclamation mark one exclamation mark :) but that really doesn't go down too well. hybrids on the other hand work very well: they're a compromise - a best-of-both-worlds compromise. which is why i'm designing an ultra-efficient one, having looked at the maths, done the simulations etc. http://lkcl.net/ev

it's so strange to have access to some basic maths, to have done vehicle simulations and also have an environmentally-friendly hat on, it catches me unawares when i see things like this. i have to double-take for a second, because it's so incredibly strange for EVs to have on-board either high-explosive materials (lithium) or highly toxic metals (nickel) in such huge quantities, i really can't understand why people don't understand that batteries are a storage mechanism not a power source, and don't design vehicles accordingly.

Huh?

Is the Lithium in LiIon batteries as explosive as other common fuels used in cars? (i.e. gasoline, natural gas)

I wasn't aware that Nickel metal was considered highly toxic since it's widely used to make coins and jewelry (and yes, some people are sensitive to Nickel, but it's still in wide use)

In the context of a car, how is a battery not a power source? Likewise, how is my gas tank not an energy storage mechanism? My car needs some source of stored energy to run - the battery and/or gas tank provide a source for that energy.

How would you design a car to accommodate a power source as opposed to a storage mechanism?

there's quite a lot involved, so please forgive me dear slashdot reader for not cut/pasting it all here - here's a link http://lkcl.net/ev to relevant articles and so on. some insights are also on http://hybridcar.com/

How about giving us a hint about what your point is? The http://hybridcar.com/ link is down.

it's so strange to have access to some basic maths, to have done vehicle simulations and also have an environmentally-friendly hat on, it catches me unawares when i see things like this. i have to double-take for a second, because it's so incredibly strange for EVs to have on-board either high-explosive materials (lithium) or highly toxic metals (nickel) in such huge quantities, i really can't understand why people don't understand that batteries are a storage mechanism not a power source, and don't design vehicles accordingly.

there's quite a lot involved, so please forgive me dear slashdot reader for not cut/pasting it all here - here's a link http://lkcl.net/ev to relevant articles and so on. some insights are also on http://hybridcar.com/

there is a common misconception that it's necessary to have a large ultra-expensive highly-polluting rare-earth-metal battery pack. you don't. the conditions for not needing a $25,000 battery pack (worth stealing) are as follows:

* the vehicle weight must be under 550kg (400kg EU Category L7E is perfect)
* low-rolling resistance tyres are essential
* you must be happy with a top speed of 60mph and a top cruising speed of about 55mph
* the frontal area of the vehicle must be no more than 1.5 sqm
* the drag coefficient must be 0.30 or less
* the full drivetrain efficiency must be no less than 80%

under these circumstances, which are perfectly reasonable for most peoples "commuting" needs, you can get away with putting in an off-the-shelf 240/120V AC 5kW or 6kW Diesel Generator and a "Fast Charger" with about 50 Amp output, and that is enough to keep the batteries continuously "topped up" or in fact just to directly drive the Electric Vehicle.

if you try to go BEYOND these circumstances (even putting in a 700kg vehicle) then you get into trouble, because the "Range Extender" now has to be an 8-10kW Diesel Generator, which now weighs 250kg not 100kg, doesn't pull the same level of fuel economy as a 5-6kW Generator (which work out at about 1 Litre per hour), and the exercise is a complete waste. so you have to stick to those conditions, and the maths works out very very well. almost... "too well", to the point where it's hard to believe the MPG figures.

the maths, principle and links to various sites is here: http://lkcl.net/hybrid_electric_vehicle/design_principle.html

and there's a discussion here:
http://www.diyelectriccar.com/forums/showthread.php/why-there-no-board-generatorsi-p261099.html

which if you look back about a week, you'll find a link to a LibreOffice spreadsheet where you can play and plug in your own "vehicle" line and confirm the maths i did, above.

the point is: *if* you do this sort of thing, then yes, large battery packs become irrelevant: you can treat that $500 lead-acid battery pack as a disposable (recyclable) item, and yes, you could even consider running the diesel generator to plug back into the National Grid. personally i think that'd be a bit of a waste of perfectly good Diesel, i'd say, but you could do it.

the article has missed out some important information, which is that they are planning two versions of the CPU. the first is a Quad-Core 65nm, and the second is a 16-core 28nm, which will use the same amount of power (about 12-15 watts). hopefully they will also do a Single-Core 28nm which would be under 1 watt, because at 1ghz the SIMD units are so powerful they can do 1080p at 100 frames per second. really, this CPU design is a game-changer. i've been advocating their use for some time - http://lkcl.net/laptop.html

he issue that you've got is that a) microsoft is not going to have windows for ARM until 2013, and even then it is impossible to get third party developers to do total rewrites of drivers b) emulation of x86, even with hardware assistance (similar to jazelle) only provides something like 30% equivalent performance. so you have a great processor, maybe 2ghz dual-core if you get the one from nufront, you smash its capabilities down to a staggering and mundane 700mhz, and you can only get up to about 1.5 gb of RAM because you need at least some memory for the Host OS.

now, yes you could instead use the ICT's "Godson" upcoming GS464V Quad-Core MIPS processor, which will have over 200+ hardware-accelerated assistance emulation instructions, but this CPU is designed to target the Chinese Government's desire to have the fastest supercomputer in the world - it would just also so happen to make a great Desktop / Server product, too, and the target power consumption is just a tad higher than any ARM processor.

overall, then, this is, very unfortunately, just pure wishful thinking on the part of every single taiwanese manufacturer. it's quite simple: to emulate another OS, the performance hit is so high that to compensate you might as well stick with the x86 processors, even if the higher performance ARM or MIPS processors were available they are actually significantly more expensive.

so instead, why not accept the fact that much much cheaper systems can be made, based around such low-power high-integrated embedded ARM and MIPS processors, and let the buyers decide?

http://lkcl.net/laptop.html

http://lkcl.net/laptop.html - i am advocating a hardware design approach which would fulfil the criteria of being upgradeable as-and-when. using, for example, the recently-announced "Bloom Laptop" concept for the casework, and Embedded SoC CPUs for the hardware, as a modular design. this approach simply is not possible with Intel or AMD CPUs.

There are a couple of easily debunked arguments :

The iPhone and iPad notwithstanding, Flash is beginning to show up on other mobile device platforms.

Exactly 1 single other platform : Android.
All the rest are only promises for some time in the future.

Meanwhile, HTML5 is an open standard meaning that everyone is free to implement it, including opensource implementations like Webkit and Gecko, and closed source like Opera's Presto and... huh... well... maybe IE's engine. Some day. Eventually.

But it's already available today on a huge number of platform and could be implemented on any new platform withouth needing to wait for Adobe to agree to port it.

Flash is used for more than just video delivery on the Web.

You know what ? So are HTML5 / CSS / JavaScript.

Flash's content protection/DRM appeals to content producers.

And is a total joke. RTMPE doesn't even use a secret to encrypt the streams, only some publicly available data and scrambling. Read about it in the Analysis section of RTMPdump's docs.

Even a HTTPS server serving the data stream for the VIDEO HTML5 tag could provide better protection, simply because at least non logged-in users can't get the content.

Flash remains popular with online advertisers.

Sorry ? And that's a good argument how ?

So the only good arguments in favor of Flash are :
- Video codec patents problems (and that's about to change as the "as much close to H264 as possible but with the patented bit left out" WebM format has been introduced by On2 and Google)
- Good tool suite to develop (and that's a really good argument, but could one day change if better tool for HTML5/CSS/Javascript are developed)
That's probably the single only good argument in favour of flash. If developer and artist are given nice tools they will produce content. Flash has the nicest tools, so for now, Flash is preferred by the people who create the content and thus more Flash content is created.

There are a couple of easily debunked arguments :

The iPhone and iPad notwithstanding, Flash is beginning to show up on other mobile device platforms.

Exactly 1 single other platform : Android.
All the rest are only promises for some time in the future.

Meanwhile, HTML5 is an open standard meaning that everyone is free to implement it, including opensource implementations like Webkit and Gecko, and closed source like Opera's Presto and... huh... well... maybe IE's engine. Some day. Eventually.

But it's already available today on a huge number of platform and could be implemented on any new platform withouth needing to wait for Adobe to agree to port it.

Flash is used for more than just video delivery on the Web.

You know what ? So are HTML5 / CSS / JavaScript.

Flash's content protection/DRM appeals to content producers.

And is a total joke. RTMPE doesn't even use a secret to encrypt the streams, only some publicly available data and scrambling. Read about it in the Analysis section of RTMPdump's docs.

Even a HTTPS server serving the data stream for the VIDEO HTML5 tag could provide better protection, simply because at least non logged-in users can't get the content.

Flash remains popular with online advertisers.

Sorry ? And that's a good argument how ?

So the only good arguments in favor of Flash are :
- Video codec patents problems (and that's about to change as the "as much close to H264 as possible but with the patented bit left out" WebM format has been introduced by On2 and Google)
- Good tool suite to develop (and that's a really good argument, but could one day change if better tool for HTML5/CSS/Javascript are developed)
That's probably the single only good argument in favour of flash. If developer and artist are given nice tools they will produce content. Flash has the nicest tools, so for now, Flash is preferred by the people who create the content and thus more Flash content is created.

With one big exception: DRM (or as the article calls it "Content Protection"). While I don't think it's impossible, I think it's a pretty big effort to produce DRM that content owners (like the MPAA or RIAA) are satisfied with as an open standard. I think they perceive open standards to be inherently insecure (despite several cases of the opposite like OpenSSL).

And in fact it's the exact opposite :
Flash's DRM is a stupid joke - in short the key to decode the encrypted RTPME streams is a a couple of filestats of the ".swf" player application, i.e.: something publicly available. No password or crypto key involved (for a longer description, look for a mirror of RTMPDump). So there's no real encryption happening and as such, Flash' DRM might even not be covered by the DMCA or local clones.

HTTP's Authentication or Session and/or HTTPS provide already enough content protection at the hosting/serving level of the video. No need to add more DRM shit on the player level.

http://lkcl.net/reports/bing.censorship.attempt - additional mirrors will be added as i find them.

Sure there are multiple specifications involved, but there's demonstrably open source work, so it can't be _that_ hard:

VLC is an open source media player and can play FLVs.

The Open source media player XBMC has some support for playing RTMP streams.

Not to mention rtmpdump

And Gnash claims to support most SWF v7 and v8 features.

There is also an open-source Action script compiler called MTASC

If we have open source tools to actually generate the bytecode... is it not a reasonable thought that tools could have been developed to actually run that bytecode?

http://lkcl.net/rtmp

torrent also available.

a copy of rtmpdump 1.6 is available here:
http://lkcl.net/rtmp

also a torrent has been made available at the same location.

get_iplayer has been removed because it encourages people to download copyrighted material. i'm interested in ensuring that implementations of RTMP and understanding of this protocol are available.