You seem to be conveniently ignoring Intel's Atom and Quark lines. They're all x86 and none of them has a TDP larger than 3w.
i'm not. intel's quark line - the one i saw announced on here last year - tops out at 400mhz. it has... nothing in the way of interfaces that can be taken seriously. it doesn't even have RGB/TTL video out. however if you are right about the latest intel atom being 3w, then now i am interested! so i am very grateful for you pointing this out, i will go check.
Here is your answer, the A20 is freakishly slow compared to anything Intel would put their name on.
Granted, you can build a tablet to do specific tasks (like decoding video codecs) around a really slow processor and some special-purpose DSPs. But perhaps the companies in that business aren't making enough profit to interest Intel.
interestingly that assumption - that allwinner is not making enough profit - is completely wrong. allwinner is now one of _the_ dominant tablet SoC manufacturers in the world. their first revision (the A10, which was a Cortex A8) actually caused a major recession in the electronics industry when it first came out, as it was only $7.50 compared to the nearest competitor at around $11 to $12. everyone *not* using the A10 at the time was left holding worthless components; contracts for supply were reneged on; the change was so quick that many factories and design houses simply went out of business.
the volumes that allwinner are shipping are simply enormous, and, along with rockchip, their nearest competitor, the tablet market is completely and utterly overwhelmingly dominated by processors of the type that you describe as "built to do specific tasks".
those "specific tasks" include "running the android OS at a pace that's good enough for the overwhelming majority of end-users".
in short, intel has a long *long* way to go before they can even remotely consider that they have a processor that can be taken seriously in this very large market, both in terms of price and also in terms of performance.
what is particularly interesting about the comment that you make is that it would seem that intel really does, just as you do, believe that "a really slow processor and some special-purpose DSPs" simply is... not enough. and, contrary to that belief, it can be quite clearly seen by the total dominance of allwinner and rockchip that "a really slow processor and some special-purpose DSPs" really *is* enough.
one of the reasons for that is because if you look at the market you find that you need:
* audio and video CODEC processing. this can be handled by a special-purpose DSP. some of these are now handling 3D 4096-bit-wide screens.
* 3D graphics. these are handled by licensing a whole range of hard macros (special-purpose DSPs) that come with proprietary libraries implementing OpenGL ES 2.0. they're good enough, and some of them are getting _really_ good.
* an (as you put it) "really slow processor" - although if you look at allwinner's latest processor the A80 it can hardly be called "slow", it's an 8 core monster - which covers the running of the general OS.
overall these processors are graded according to price: $5 will get you something dreadful but "good enough", $20 will get you something that's complete overkill for a tablet.
and you know what? the $7 1.2ghz dual-core ARM Cortex A7 Allwinner A20 is, when it's put with 2gb of RAM, actually extremely quick. i tested out 1gb of RAM running debian GNU/Linux: i fired up xrdp and i had *five* rdesktop sessions running OpenOffice and Firefox on it, onto my laptop. it didn't fall over, and it wasn't dreadfully slow.
so i think you, just like intel, are completely and entirely missing the point. and in intel's case, that means entirely missing out on a *huge* market segment.
for the rhombus-tech project i also contacted broadcom, to ask for access to one of their chips (this was before the raspberry pi). i can confirm that, just as other people are reporting, the conversation basically indicates that broadcom as a company doesn't wish to make money.
ok, so the effect of RISC vs CISC has absolutely *no* relation to power, right? so why in god's green earth is, for example, the allwinner a20 1.2ghz processor - which is still in 40nm btw - maxing out at 2.5 watts and delivering great 1080p video, reasonable 3D graphics and so on - yet intel is having to go to 14nm and, even at 14nm they STILL can't release a processor that, if you run it in a very limited configuration, is STILL listed as 3.5 watts??
there's a quad-core rockchip 28nm SoC. maximum (actual) top power consumption: below 3.0 watts. intel's haswell tablet SoC is 20nm: it's 4.5 watts "Scenario" Design Power i.e. if you only run certain apps in certain ways it *might* keep below 4.5 watts.
i really _really_ want to know why it is that intel cannot deliver an SoC that has an absolute peak limit of 2.5 watts.
> the first ones used threads, semaphores through python's multiprocessing.Pipe implementation.
I stopped reading when I came across this.
Honestly - why are people trying to do things that need guarantees with python?
because we have an extremely limited amount of time as an additional requirement, and we can always rewrite critical portions or later the entire application in c once we have delivered a working system that means that the client can get some money in and can therefore stay in business.
also i worked with david and we benchmarked python-lmdb after adding in support for looped sequential "append" mode and got a staggering performance metric of 900,000 100-byte key/value pairs, and a sequential read performance of 2.5 MILLION records. the equivalent c benchmark is only around double those numbers. we don't *need* the dramatic performance increase that c would bring if right now, at this exact phase of the project, we are targetting something that is 1/10th to 1/5th the performance of c.
so if we want to provide the client with a product *at all*, we go with python.
but one thing that i haven't pointed out is that i am an experienced linux python and c programmer, having been the lead developer of samba tng back from 1997 to 2000. i simpy transferred all of the tricks that i know involving while-loops around non-blocking sockets and so on over to python.... and none of them helped. if you get 0.5% of the required performance in python, it's so far off the mark that you know something is drastically wrong. converting the exact same program to c is not going to help.
The fact you have strict timing guarantees means you should be using a realtime kernel and realtime threads with a dedicated network card and dedicated processes on IRQs for that card.
we don't have anything like that [strict timing guarantees] - not for the data itself. the data comes in on a 15 second delay (from the external source that we do not have control over) so a few extra seconds delay is not going to hurt.
so although we need the real-time response to handle the incoming data, we _don't_ need the real-time capability beyond that point.
Take the incoming messages from UDP and post them on a message bus should be step one so that you don't lose them.
.... you know, i think this is extremely sensible advice (which i have heard from other sources) so it is good to have that confirmed... my concerns are as follows:
questions:
* how do you then ensure that the process receiving the incoming UDP messages is high enough priority to make sure that the packets are definitely, definitely received?
* what support from the linux kernel is there to ensure that this happens?
* is there a system call which makes sure that data received on a UDP socket *guarantees* that the process receiving it is woken up as an absolute priority over and above all else?
* the message queue destination has to have locking otherwise it will be corrupted. what happens if the message queue that you wish to send the UDP packet to is locked by a *lower* priority process?
* what support in the linux kernel is there to get the lower priority process to have its priority temporarily increased until it lets go of the message queue on which the higher-priority task is critically dependent?
this is exactly the kind of thing that is entirely missing from the linux kernel. temporary automatic re-prioritisation was something that was added to solaris by sun microsystems quite some time ago.
to the best of my knowledge the linux kernel has absolutely no support for these kinds of very important re-prioritisation requirements.
i am running into exactly this problem on my current contract. here is the scenario:
* UDP traffic (an external requirement that cannot be influenced) comes in * the UDP traffic contains multiple data packets (call them "jobs") each of which requires minimal decoding and processing * each "job" must be farmed out to *multiple* scripts (for example, 15 is not unreasonable) * the responses from each job running on each script must be collated then post-processed.
so there is a huge fan-out where jobs (approximately 60 bytes) are coming in at a rate of 1,000 to 2,000 per second; those are being multiplied up by a factor of 15 (to 15,000 to 30,000 per second, each taking very little time in and of themselves), and the responses - all 15 to 30 thousand - must be in-order before being post-processed.
so, the first implementation is in a single process, and we just about achieve the target of 1,000 jobs but only about 10 scripts per job.
anything _above_ that rate and the UDP buffers overflow and there is no way to know if the data has been dropped. the data is *not* repeated, and there is no back-communication channel.
the second implementation uses a parallel dispatcher. i went through half a dozen different implementations.
the first ones used threads, semaphores through python's multiprocessing.Pipe implementation. the performance was beyond dreadful, it was deeply alarming. after a few seconds performance would drop to zero. strace investigations showed that at heavy load the OS call futex was maxed out near 100%.
next came replacement of multiprocessing.Pipe with unix socket pairs and threads with processes, so as to regain proper control over signals, sending of data and so on. early variants of that would run absolutely fine up to some arbitrarry limit then performance would plummet to around 1% or less, sometimes remaining there and sometimes recovering.
next came replacement of select with epoll, and the addition of edge-triggered events. after considerable bug-fixing a reliable implementation was created. testing began, and the CPU load slowly cranked up towards the maximum possible across all 4 cores.
the performance metrics came out *WORSE* than the single-process variant. investigations began and showed a number of things:
1) even though it is 60 bytes per job the pre-processing required to make the decision about which process to send the job were so great that the dispatcher process was becoming severely overloaded
2) each process was spending approximately 5 to 10% of its time doing actual work and NINETY PERCENT of its time waiting in epoll for incoming work.
this is unlike any other "normal" client-server architecture i've ever seen before. it is much more like the mainframe "job processing" that the article describes, and the linux OS simply cannot cope.
i would have used POSIX shared memory Queues but the implementation sucks: it is not possible to identify the shared memory blocks after they have been created so that they may be deleted. i checked the linux kernel source: there is no "directory listing" function supplied and i have no idea how you would even mount the IPC subsystem in order to list what's been created, anyway.
i gave serious consideration to using the python LMDB bindings because they provide an easy API on top of memory-mapped shared memory with copy-on-write semantics. early attempts at that gave dreadful performance: i have not investigated fully why that is: it _should_ work extremely well because of the copy-on-write semantics.
we also gave serious consideration to just taking a file, memory-mapping it and then appending job data to it, then using the mmap'd file for spin-locking to indicate when the job is being processed.
all of these crazy implementations i basically have absolutely no confidence in the linux kernel nor the GNU/Linux POSIX-compliant implementation of the OS on top - i have no confidence that it can handle the load.
so i would be very interested to hear from anyone who has had to design similar architectures, and how they dealt with it.
i think one of two things happened, here. first is that it might have finally sunk in to google that even just *claiming* to have properly verified user identities leaves them open to lawsuits should they fail to have properly carried out the verification checks that other users *believe* they have carried out. every other service people *know* that you don't trust the username: for a service to claim that they have truly verified the identity of the individual behind the username is reprehensibly irresponsible.
second is that they simply weren't getting enough people, so have quotes opened up the doors quotes.
That is part of it yes. It requires a wide range of differently experienced people: low level software, high level software, circuit design, assembly, layout, component sourcing, factory liasion, DFt, Manufacturing etc.
Then you need to get them all to work together. And you have to pay them.
... ynow... one of the reasons i came up with the idea to design mass-volume hardware that would be eco and libre friendly was because, after having developed the experience to deal with both low-level software and high-level software, and having done some circuit design at both school and university, i figured that the rest should not be too hard to learn... or manage.
you wanna know the absolute toughest part [apart from managing people?] it's the component sourcing. maan, is that tough. if you want a laugh [out of sheer horror, not because it was actually funny] look up the story on how long it took to find a decently-priced mid-mount micro HDMI type D [8 months].
so anyway, i set out to find people with the prerequisite skills that i *didn't* have, offered them a chance to participate and profit. the list of people who have helped and then fallen by the wayside... i... well.... i want to succeed at this so that i can give them something in return for what they did.
the current revision 2 which i am looking for factories to produce (RFQs sent out already) we will try with 2gb of RAM. this is just a component change not a layout change so chances of success are high.
that was our "minimal test rig" which helped verify the interfaces on the first CPU Cards (and will help verify the next ones as well, with no further financial outlay needed. ever. ok, that would be true if i hadn't taken the opportunity to change the spec before we go properly live with it!! you only get one shot at designing a decade-long standard.... i'd rather get it right)
the micro-desktop chassis is very basic: VGA, 2x USB, Ethernet, Power In (5.5 to 21V DC). all the other interfaces are on the CPU Card (USB-OTG, Micro-HDMI, Micro-SD). however unlike the Micro-Engineering Board, the power is done with a view to the average end-user (as is the VGA connector which means 2 independent screens, straight out the box).
Open hardware sounds cool, but as others have noted, good hardware design is both difficult and expensive. Considering how rapidly the components advance (CPU/SoC, I/O, displays, etc.),
aaaah gotcha! that's the _whole_ reason why i designed the long-term modular standards, so that products *can* be split around the arms race of CPU/SoC on the one hand and battery life / display etc. on the other.
and the factory that we are in touch with (the big one), they _love_ this concept, because the one thing that you might not be aware of is that even the big guys cannot react fast enough nowadays.
imagine what it would mean to them to be able to buy HUGE numbers of CPUs (and related components), drop them into a little module that they KNOW is going to work across every single product that conforms to the long-term standard. in 6 months time there will be a faster SoC, more memory, less power, but that's ok, because *right now* they can get better discounts on the SoC that's available *now*.
on the other side of the interface, imagine what it would mean to them that they could buy the exact same components for a base unit for well... three to five years (or until something better came along or some component went end-of-life)?
it took them a while, but they _loved_ the idea. the problem is: as a PRC State-Sponsored company they are *prohibited* from doing anything other than following the rules... i can't tell you what those rules are: they're confidential, but it meant that we had to find other... creative ways to get the designs made.
We're in a world where a first generation Nexus 7 tablet sells for $140 or less. At Walmart.
yeah. now that prices are dropping, just like the PC price wars, the profits are becoming so small that the manufacturers are getting alarmed (or just dropping out of the market entirely). those people are now looking for something else. they're willing to try something that might get them a profit. what should we tell them?
anyway: thank you for your post, darylb, it provides a very useful starting point for some of the key insights i want to get across to people.
short version: the plan is to carry on, using the lessons learned to try again, with a crowd-funding campaign that is transparent. please keep an eye on the mailing list, i will also post here on slashdot when it begins.
the - extremely ambitious - goal set by me is to solve a huge range of issues, the heart of which is to create environmentally-conscious mass-volume appliances that software libre developers are *directly* involved in at every step of the way.
so, not to be disparaging to any project past or future, but this isn't "another beagleboard", or "another raspberry pi beater": it's a way to help the average person *own* their computer appliances and save money over the long term. software libre developers are invited to help make that happen.
by "own" we mean "proper copyright compliance, no locked boot loaders and a thriving software libre environment that they can walk straight into to help them do what they want with *their* device... if they want to".
the actual OS installed on the appliance will be one that is relevant for that appliance, be it ChromeOS, Android, even Windows or MacOSX. regardless of the pre-installed OS, the products i am or will be involved in *will* be ones that Software Libre Developers would be proud to own and would recommend even to the average person.
by "saving money over the long term" we mean "the device is split into two around a stable long-term standard with a thriving second-hand market on each side, with new CPU Cards coming along as well as new products as well. buy one CPU Card and one product, it'll be a little bit more expensive than a monolithic non-upgradeable product, but buy two and you save 30% because you only need one CPU Card. break the base unit and instead of the whole product becoming land-fill you just have to replace the base, you can transfer not just the applications and data but the *entire computer*".
it was the environmental modular aspects as well as the committment to free software *and* the desire to reach mass-volume levels that attracted aaron to the Rhombus Tech project.
perhaps unsurprisingly - and i take responsibility for this - the details of the above did not translate well into the Improv launch. the reason i can say that is because even henrik, who has been helping out and a member of the arm netbooks mailing list for quite some time, *still* has not fully grasped the full impact of the technical details behind the standards
(hi henrik, how are ya, thank you very very much for helping with the boot of the first A10 / A20 CPU card, your post on the mailing list last week was very helpful because it shows that i still have a long way to go to get the message across in a short concise way).
the level of logical deduction, the details that need to be taken into account, the number of processors whose full specifications must be known in order to make a decent long-term stable standard.... many people i know reading that sentence will think i am some sort of self-promoting egotistical dick but i can tell you right now you *don't* want to be holding in your head the kinds of mind-numbing details needed to design a long-term mass-volume computing standard. it's fun... but only in a masochistic sort of way!
anyway. i did say long, so i have an excuse, but to get to the point: now that the money is being returned, we can start again with a new campaign - using a crowdfunding site that shows numbers, and starts with a lower target (250) that offers more value for that same amount of money to everyone invo
1978, aged 8, our school had a commodore pet 3032. i typed in a simple program in BASIC, 10 for i = 1 to 40, 20 print tab(i), i 30 next i, 40 goto 10 and watched the numbers 1 to 40 scroll across the screen. i figured "huh that was obvious, i can do that" and 25 years later i was reverse-engineering NT 4.0 Domains network traffic (often literally one bit at a time) by the same kind of logical inference of observing results and deducing knowledge.
by 2006 i learned that there is something called "Advaita Vedanta" which is crudely known in the west as "espistemology". Advaita Vedanta basically classifies knowledge (there are several types: inference is just one of them), and knowing *that* allows you to have the confidence in your abilities. up until i heard about Advaita Vedanta i was "hacking blind and instinctively", basically. now i know that reverse-engineering is basically an extreme form of knowledge inference. which is kinda cool.
yeah, me! were you around in 1995-1996 by any chance? in CB1 Cafe in cambridge UK i was the person who discovered that you could put zombies into the underground phase-tunnel vehicles, then sneak behind enemy lines (the underground vehicle could see "up" into one square at a time). i would go looking for artillery because artillery by default had a reaaally nasty habit of auto-firing at close-range enemies on a huuge delay. so, what would happen was: first zombie went up, artillery would turn and begin loading, zombie would go to nearest artillery craft and suicide, blowing up several. all artillery would fire, blowing up even more. second zombie up, artillery lock-and-load, zombie makes a beeline for.... you get the idea.
anyway the idea was good enough that it ended up on the hints-and-tips page. turns out that the people who we played were some of the people who worked at activision:)
huh. this sounds very similar to the theoretical virus designs i came up with many years ago. yes, you heard right: turn it round. instead of the programs on the computer being randomised so that they are resistant to malware attacks, randomise the *malware* so that it is resistant to *anti-virus* detection. the model is basically the flu or common cold virus.
here's where it gets interesting: comparing the use of randomisation in malware vs randomisation in defense against malware, it's probably going to start being used in malware before it gets used in defending against malware. why? because malware attackers have nothing to lose. unfortunately, they are likely to keep their compilers secret. even *more* unfortunately, successful creation of anti-malware randomising compilers means that the malware attackers can use them as well.
but, that is just a risk that has to be taken, and make sure a decent job is done of it.
Whereas with a bigger engine this is less of the case and you can get equivalent mpg
ah, i wrote a diesel truck simulator in 1993 for Pi Technology: there is actually much more to it than that. with a bigger engine with higher torque it is possible to have the vehicle drive more often in its peak torque range where it has either better acceleration or better fuel economy or both.
with a smaller engine the effect you mention - that people put their foot to the floor - means that the engine has to rev its nuts off and thus operates waaay outside of its efficiency band.
before making *any* judgement you *need* to watch the program on 5th gear which covers exactly this question in some detail. basically the test was designed originally for people driving sensibly, and it was designed i think well over 20 possibly even 30 years ago. so it has a very *very* gentle acceleration and deceleration curve. gentle acceleration because that is not only fuel-efficient but also the cars of that time simply could not accelerate that much, and gentle braking because again that is more fuel-efficient but also because if you had drum brakes they would overheat.
people no longer drive sensibly: they are more aggressive with other drivers (not keeping a safe distance), they put their foot down hard on the accelerator and they put their foot down hard on the brake. also as the cars are more reliable they tend to not maintain them properly: until i watched another program on 5th gear about how badly old oil affects fuel economy and the lifetime of the engine i had absolutely no intention of changing oil regularly in the decade-year-old cars i buy.
so, in effect, people should stop complaining and start driving in more fuel-efficient ways... *regardless* of how aggressive the person behind them gets when they set off from the lights at the same acceleration rate as a 40 tonne cargo lorry. that's the other person's problem.
i love descent, and i love that it's now software libre. i hope the guy who maintains d2x has stopped being an idiot by including patched versions of standard libraries such as libsdl without providing an option to replace them and forcing the patched versions to overwrite pre-installed software, but yes - awesome.
the thing about descent was that it was the first game with 6 degrees of freedom. i actually bought a special joystick that was capable of dealing with it (one designed for flight simulators) and after 2 to 3 weeks of practicing i was competent at side-motion circular slides firing at a target at the centre. the first 2 weeks were spent mostly getting motion sickness and having the nose of the craft bashed against a corner:)
it was also fun to watch spectators swaying from watching the screen! but, again, after a couple of weeks you got used to it, both as a player and as a spectator.
yeah - to those people who set up LAN parties: i hear ya:) i did the same. i think the lowest spec i got away with was a 486 SX 25 with 12mb of RAM, setting the screen to 320x240 and it was just about tolerable. i had to use 10-Base-T with terminators for goodness sake - what the heck i was doing with 5 networked computers in my house back in 1996 with just a 28kbaud modem i _really_ don't know!
so yes, absolutely: descent (the software libre version *or* a commercial version) gets my vote... *as long as* it has a community portal similar to that of Dark Reign, with a chat room so that people can meet other players, set up a match and play. that is bizarrely what's missing from bzflag: although bzflag has an in-game chat it doesn't hatve out-game community chat, very odd.
also, it would be awesome to see planetary-surface action as well, not just in mines (no matter how large). i always felt a little claustrophobic and the attack vectors would be very different in free space... interesting to think about the possibilities here, hmmm:)
"i have never even seen a PAM module which does this trick. it would be awesome to do the same trick for ssh as well." you mean like pam_ssh for ssh keys or if you just want it to work with gpg and ssh you could also run the gnome key manager as I do. True single sign on with all ssh and gpg keys.
no not pam_ssh. not "ask for a 2nd passphrase at a 2nd prompt which is entered into the ssh system to unlock the ssh key" - have ABSOLUTELY NO login credentials AT ALL, and LITERALLY use the success/fail of the ssh passphrase (or gpg passphrase) unlocking *AS* the login. no/etc/shadow, no password field in/etc/passwd - nothing BUT unlock the gpg or ssh key.
so what's the difference between the NSA's plan and Hydra's plan in Captain America Winter Soldier? absolutely nothing as far as i can tell. can anyone tell me if i am mistaken?
depinit. written by richard lightman because he too did not trust the overcomplexity of sysv initscripts and wanted parallelism, it was adopted by linux from scratch and seriously considered for adoption in gentoo at the time. richard is extremely reclusive and his web site is now offline: you can get a copy of depinit however using archive.org.
using depinit in 2006 i had a boot to X11 on a 1ghz pentium in 17 seconds, and a shutdown time of under three. depinit has two types of services: one is the "legacy" service (supporting old style/etc/init.d/backgrounddaemon) and the other relied on stdin and stdout redirection. in depinit you can not only chain services together for their dependencies but also chain their *stdin and stout* _and_ stderr together.
that has some very interesting implications. for example: rather than have some stupid system which monitors/var/log/apache2/logfile for security alerts or/var/log/auth.log for sshd attacks, what you do is run sshd or apache2 as a *foreground* service outputting log messages to stderr, chained to a "security analysis" service which then chains to a log file service.
the "security analysis" service could then *immediately* check the output looking for unauthorised logins and *immediately* ban repeat offenders by blocking their IP address, rather than having to either poll the files (with associated delays and/or CPU untilisation) or have some insane complex monitoring of inodes which _still_ has associated delays.
also depinit catches *all* signals - not just a few - and allows services to be activated based on those signals. richard also had a break-in on one system, and they deployed the usual fork-and-continue trick, so he wrote some code which allowed the service-stopping code to up the agressiveness on hunting down and killing child processes. this also turned out to be very useful in cases where services went a bit awry.
basically the list of innovations that richard added to depinit is very very long, in what is actually an extremely small amount of code. i simply haven't the space to list them all, and no, richard was not a fan of network-manager either.
btw you might also want to look at the replacement for/bin/login that richard wrote. it was f****g awesome. basically what he did was use gpg key passphrases as the login credentials.... and ran gpg-agent automatically as part of the *login*. i have never even seen a PAM module which does this trick. it would be awesome to do the same trick for ssh as well.
it's fascinating what someone can get up to when they have the programming skill and the logical reasoning abilities to analyse existing systems that everyone else takes for granted, work out that those sytems are actually not up to scratch and can write their *own* replacements. it's just such a pity that nobody seems to have noticed what he achieved.
there is actually something which is far more useful to be able to do, more than any amount of books read, which is only really possible effectively and efficiently now that internet searches are possible (and quick, and accurate), and that is meta-learning. in its crudest most disparaging form one might mistakenly call this cut-and-paste programming but it is actually nothing of the sort.
basically what you do is treat everything as a black box, and use the principles of the 6 different types of knowledge (listed on the wikipedia page for Advaita Vedanta, which is mentioned specifically because the western word Epistemology is woefully inadequate) to basically reverse-engineer the subject matter and in effect teach yourself *on the go* by way of analysing the results achieved, even though you are starting out from quite literally zero knowledge.
it does however take a hell of a lot of balls to do this *whilst being paid* and most employers simply will not believe you when you tell them that this is something that you can do... and be *more effective* at applying this technique than people who have been explicitly trained or quotes have experience quotes in the field.
to be fair to those people who genuinely do have experience, often such people *may* have encountered the circumstances before, such that they *may* have the answer much quicker than you-who-has-no-experience-at-all, *but*, the critical critical thing that you need to tell prospective employers is: what happens when something falls *outside* of the experience of the person who quotes has experience quotes? whom then would the employer rather have (if they had to choose one or the other rather than both people) - the person who will get there in the end, regardless of what they are asked to do, or would they rather have the person who can get there *most* of the time but who does not have the skills or intelligence to work out the all-important remaining last 10% of the job, without which the contract will remain unfulfilled and the company will go bust because of it?
in short: no amount of reading will substitute for learning how to learn and applying that skill *every single moment of your life*. when i hear people say i am too old to learn it makes me cringe, and i feel sad for them - i cannot say anything so i have to remain silent - but i feel sad for them because i know that inside they have given up. the only time to give up learning is when you are actually dead, and not before!!!
ynow... there is a moral to this tale: if businesses and individuals making money from software (libre) had properly funded it, putting some of the money that they saved from not purchasing proprietary software into the hands of those software teams, would we be talking about this now? in all probability, the answer is no. the reason is because those teams would be able to expand, take on more people, pay for security audits and so on which they would otherwise, as we have discovered, not be in a position to do.
so my take on this is that it is really really simple: businesses have received what they paid for, and got what they deserved.
i have been through this experience - directly - a number of times. i worked on samba - quietly - for three years. whilst the other members of the team were receiving shares from the Redhat and VA Linux IPOs, which they were able to sell and receive huge cash sums - i was busy reverse-engineering Windows NT Domains so that businesses world-wide could save billions of dollars.... and not one single one of those businesses called me up to say thank you, have some cash. as a result, about a year after terminating work on samba i was working on a building site as a common labourer.
it was the same story with the Exchange 5 reverse-engineering, which the Open Exchange Team mirrored (copied, minus the Copyright and Credits).
there is a moral to this tale: unlike proprietary software, which has a price tag commensurate with its perceived value, the process of even *offering* payment to individuals working on a software libre project that has been downloaded, usually from a completely different location (via a distro), is completely divorced from the developers actual efforts.
even in shops in rural districts, it is understood that if the door is unlocked and the shopkeeper not there, you help yourself, open the till, sort out your own correct change and walk out. but in the software libre world there is often not even that level of expectation! the software is quotes free quotes therefore it is monetarily zero cost therefore we should not have to pay, right? and businesses are pretty pathological about taking whatever they can get without paying for it.
so the short version is: there is a huge disconnect in software libre between service provision (the software) and paying for that service, and i really cannot see a solution here. perhaps this really should be bigger news: perhaps in this openssl vulnerability we have an opportunity to make that clear.
You're assuming a lot there. How would you know if osx or windows NT kernels are 'fully parallelized'? Have you seen the source?
someone else answered about OSX. NT, based on the MACH kernel, has been fully re-entrant and multi-threaded for a looong time. also, given that the service control manager (which is a parallelised start/stop daemon service) is fully parallelised i'd be incredibly surprised if the same attention to detail wasn't also carried through on device-driver initialisation as well. although.... the only evidence against that is the "Debug Startup" mode, which initialises drivers in sequence (and shows you the sequence), but that could well be due to the request for "Debug Mode" rather than an underlying design. honest answer: don't know.
Slashdot Mirror
You seem to be conveniently ignoring Intel's Atom and Quark lines. They're all x86 and none of them has a TDP larger than 3w.
i'm not. intel's quark line - the one i saw announced on here last year - tops out at 400mhz. it has... nothing in the way of interfaces that can be taken seriously. it doesn't even have RGB/TTL video out. however if you are right about the latest intel atom being 3w, then now i am interested! so i am very grateful for you pointing this out, i will go check.
Here is your answer, the A20 is freakishly slow compared to anything Intel would put their name on.
Granted, you can build a tablet to do specific tasks (like decoding video codecs) around a really slow processor and some special-purpose DSPs. But perhaps the companies in that business aren't making enough profit to interest Intel.
interestingly that assumption - that allwinner is not making enough profit - is completely wrong. allwinner is now one of _the_ dominant tablet SoC manufacturers in the world. their first revision (the A10, which was a Cortex A8) actually caused a major recession in the electronics industry when it first came out, as it was only $7.50 compared to the nearest competitor at around $11 to $12. everyone *not* using the A10 at the time was left holding worthless components; contracts for supply were reneged on; the change was so quick that many factories and design houses simply went out of business.
the volumes that allwinner are shipping are simply enormous, and, along with rockchip, their nearest competitor, the tablet market is completely and utterly overwhelmingly dominated by processors of the type that you describe as "built to do specific tasks".
those "specific tasks" include "running the android OS at a pace that's good enough for the overwhelming majority of end-users".
in short, intel has a long *long* way to go before they can even remotely consider that they have a processor that can be taken seriously in this very large market, both in terms of price and also in terms of performance.
what is particularly interesting about the comment that you make is that it would seem that intel really does, just as you do, believe that "a really slow processor and some special-purpose DSPs" simply is... not enough. and, contrary to that belief, it can be quite clearly seen by the total dominance of allwinner and rockchip that "a really slow processor and some special-purpose DSPs" really *is* enough.
one of the reasons for that is because if you look at the market you find that you need:
* audio and video CODEC processing. this can be handled by a special-purpose DSP. some of these are now handling 3D 4096-bit-wide screens.
* 3D graphics. these are handled by licensing a whole range of hard macros (special-purpose DSPs) that come with proprietary libraries implementing OpenGL ES 2.0. they're good enough, and some of them are getting _really_ good.
* an (as you put it) "really slow processor" - although if you look at allwinner's latest processor the A80 it can hardly be called "slow", it's an 8 core monster - which covers the running of the general OS.
overall these processors are graded according to price: $5 will get you something dreadful but "good enough", $20 will get you something that's complete overkill for a tablet.
and you know what? the $7 1.2ghz dual-core ARM Cortex A7 Allwinner A20 is, when it's put with 2gb of RAM, actually extremely quick. i tested out 1gb of RAM running debian GNU/Linux: i fired up xrdp and i had *five* rdesktop sessions running OpenOffice and Firefox on it, onto my laptop. it didn't fall over, and it wasn't dreadfully slow.
so i think you, just like intel, are completely and entirely missing the point. and in intel's case, that means entirely missing out on a *huge* market segment.
for the rhombus-tech project i also contacted broadcom, to ask for access to one of their chips (this was before the raspberry pi). i can confirm that, just as other people are reporting, the conversation basically indicates that broadcom as a company doesn't wish to make money.
ok, so the effect of RISC vs CISC has absolutely *no* relation to power, right? so why in god's green earth is, for example, the allwinner a20 1.2ghz processor - which is still in 40nm btw - maxing out at 2.5 watts and delivering great 1080p video, reasonable 3D graphics and so on - yet intel is having to go to 14nm and, even at 14nm they STILL can't release a processor that, if you run it in a very limited configuration, is STILL listed as 3.5 watts??
there's a quad-core rockchip 28nm SoC. maximum (actual) top power consumption: below 3.0 watts. intel's haswell tablet SoC is 20nm: it's 4.5 watts "Scenario" Design Power i.e. if you only run certain apps in certain ways it *might* keep below 4.5 watts.
i really _really_ want to know why it is that intel cannot deliver an SoC that has an absolute peak limit of 2.5 watts.
hi mr thinly-sliced, thank you this is awesome advice, really really appreciated.
> the first ones used threads, semaphores through python's multiprocessing.Pipe implementation.
I stopped reading when I came across this.
Honestly - why are people trying to do things that need guarantees with python?
because we have an extremely limited amount of time as an additional requirement, and we can always rewrite critical portions or later the entire application in c once we have delivered a working system that means that the client can get some money in and can therefore stay in business.
also i worked with david and we benchmarked python-lmdb after adding in support for looped sequential "append" mode and got a staggering performance metric of 900,000 100-byte key/value pairs, and a sequential read performance of 2.5 MILLION records. the equivalent c benchmark is only around double those numbers. we don't *need* the dramatic performance increase that c would bring if right now, at this exact phase of the project, we are targetting something that is 1/10th to 1/5th the performance of c.
so if we want to provide the client with a product *at all*, we go with python.
but one thing that i haven't pointed out is that i am an experienced linux python and c programmer, having been the lead developer of samba tng back from 1997 to 2000. i simpy transferred all of the tricks that i know involving while-loops around non-blocking sockets and so on over to python. ... and none of them helped. if you get 0.5% of the required performance in python, it's so far off the mark that you know something is drastically wrong. converting the exact same program to c is not going to help.
The fact you have strict timing guarantees means you should be using a realtime kernel and realtime threads with a dedicated network card and dedicated processes on IRQs for that card.
we don't have anything like that [strict timing guarantees] - not for the data itself. the data comes in on a 15 second delay (from the external source that we do not have control over) so a few extra seconds delay is not going to hurt.
so although we need the real-time response to handle the incoming data, we _don't_ need the real-time capability beyond that point.
Take the incoming messages from UDP and post them on a message bus should be step one so that you don't lose them.
.... you know, i think this is extremely sensible advice (which i have heard from other sources) so it is good to have that confirmed... my concerns are as follows:
questions:
* how do you then ensure that the process receiving the incoming UDP messages is high enough priority to make sure that the packets are definitely, definitely received?
* what support from the linux kernel is there to ensure that this happens?
* is there a system call which makes sure that data received on a UDP socket *guarantees* that the process receiving it is woken up as an absolute priority over and above all else?
* the message queue destination has to have locking otherwise it will be corrupted. what happens if the message queue that you wish to send the UDP packet to is locked by a *lower* priority process?
* what support in the linux kernel is there to get the lower priority process to have its priority temporarily increased until it lets go of the message queue on which the higher-priority task is critically dependent?
this is exactly the kind of thing that is entirely missing from the linux kernel. temporary automatic re-prioritisation was something that was added to solaris by sun microsystems quite some time ago.
to the best of my knowledge the linux kernel has absolutely no support for these kinds of very important re-prioritisation requirements.
i am running into exactly this problem on my current contract. here is the scenario:
* UDP traffic (an external requirement that cannot be influenced) comes in
* the UDP traffic contains multiple data packets (call them "jobs") each of which requires minimal decoding and processing
* each "job" must be farmed out to *multiple* scripts (for example, 15 is not unreasonable)
* the responses from each job running on each script must be collated then post-processed.
so there is a huge fan-out where jobs (approximately 60 bytes) are coming in at a rate of 1,000 to 2,000 per second; those are being multiplied up by a factor of 15 (to 15,000 to 30,000 per second, each taking very little time in and of themselves), and the responses - all 15 to 30 thousand - must be in-order before being post-processed.
so, the first implementation is in a single process, and we just about achieve the target of 1,000 jobs but only about 10 scripts per job.
anything _above_ that rate and the UDP buffers overflow and there is no way to know if the data has been dropped. the data is *not* repeated, and there is no back-communication channel.
the second implementation uses a parallel dispatcher. i went through half a dozen different implementations.
the first ones used threads, semaphores through python's multiprocessing.Pipe implementation. the performance was beyond dreadful, it was deeply alarming. after a few seconds performance would drop to zero. strace investigations showed that at heavy load the OS call futex was maxed out near 100%.
next came replacement of multiprocessing.Pipe with unix socket pairs and threads with processes, so as to regain proper control over signals, sending of data and so on. early variants of that would run absolutely fine up to some arbitrarry limit then performance would plummet to around 1% or less, sometimes remaining there and sometimes recovering.
next came replacement of select with epoll, and the addition of edge-triggered events. after considerable bug-fixing a reliable implementation was created. testing began, and the CPU load slowly cranked up towards the maximum possible across all 4 cores.
the performance metrics came out *WORSE* than the single-process variant. investigations began and showed a number of things:
1) even though it is 60 bytes per job the pre-processing required to make the decision about which process to send the job were so great that the dispatcher process was becoming severely overloaded
2) each process was spending approximately 5 to 10% of its time doing actual work and NINETY PERCENT of its time waiting in epoll for incoming work.
this is unlike any other "normal" client-server architecture i've ever seen before. it is much more like the mainframe "job processing" that the article describes, and the linux OS simply cannot cope.
i would have used POSIX shared memory Queues but the implementation sucks: it is not possible to identify the shared memory blocks after they have been created so that they may be deleted. i checked the linux kernel source: there is no "directory listing" function supplied and i have no idea how you would even mount the IPC subsystem in order to list what's been created, anyway.
i gave serious consideration to using the python LMDB bindings because they provide an easy API on top of memory-mapped shared memory with copy-on-write semantics. early attempts at that gave dreadful performance: i have not investigated fully why that is: it _should_ work extremely well because of the copy-on-write semantics.
we also gave serious consideration to just taking a file, memory-mapping it and then appending job data to it, then using the mmap'd file for spin-locking to indicate when the job is being processed.
all of these crazy implementations i basically have absolutely no confidence in the linux kernel nor the GNU/Linux POSIX-compliant implementation of the OS on top - i have no confidence that it can handle the load.
so i would be very interested to hear from anyone who has had to design similar architectures, and how they dealt with it.
i think one of two things happened, here. first is that it might have finally sunk in to google that even just *claiming* to have properly verified user identities leaves them open to lawsuits should they fail to have properly carried out the verification checks that other users *believe* they have carried out. every other service people *know* that you don't trust the username: for a service to claim that they have truly verified the identity of the individual behind the username is reprehensibly irresponsible.
second is that they simply weren't getting enough people, so have quotes opened up the doors quotes.
Read "hard" as "Expensive as Hell"
That is part of it yes. It requires a wide range of differently experienced people: low level software, high level software, circuit design, assembly, layout, component sourcing, factory liasion, DFt, Manufacturing etc.
Then you need to get them all to work together. And you have to pay them.
... ynow... one of the reasons i came up with the idea to design mass-volume hardware that would be eco and libre friendly was because, after having developed the experience to deal with both low-level software and high-level software, and having done some circuit design at both school and university, i figured that the rest should not be too hard to learn... or manage.
you wanna know the absolute toughest part [apart from managing people?] it's the component sourcing. maan, is that tough. if you want a laugh [out of sheer horror, not because it was actually funny] look up the story on how long it took to find a decently-priced mid-mount micro HDMI type D [8 months].
so anyway, i set out to find people with the prerequisite skills that i *didn't* have, offered them a chance to participate and profit. the list of people who have helped and then fallen by the wayside... i... well.... i want to succeed at this so that i can give them something in return for what they did.
If only there was some way to get more information, perhaps with a sort of "link" of some kind to a more detailed description.
here is the [old] specification of the [revision 1] CPU Card:
http://rhombus-tech.net/allwin...
the current revision 2 which i am looking for factories to produce (RFQs sent out already) we will try with 2gb of RAM. this is just a component change not a layout change so chances of success are high.
here is the [old] specification of the Micro-Engineering Board:
http://rhombus-tech.net/commun...
that was our "minimal test rig" which helped verify the interfaces on the first CPU Cards (and will help verify the next ones as well, with no further financial outlay needed. ever. ok, that would be true if i hadn't taken the opportunity to change the spec before we go properly live with it!! you only get one shot at designing a decade-long standard.... i'd rather get it right)
this will be the basis of the planned crowd-funding campaign: it's more of a micro-desktop PC:
http://rhombus-tech.net/commun...
the micro-desktop chassis is very basic: VGA, 2x USB, Ethernet, Power In (5.5 to 21V DC). all the other interfaces are on the CPU Card (USB-OTG, Micro-HDMI, Micro-SD). however unlike the Micro-Engineering Board, the power is done with a view to the average end-user (as is the VGA connector which means 2 independent screens, straight out the box).
does that help answer the question?
Open hardware sounds cool, but as others have noted, good hardware design is both difficult and expensive. Considering how rapidly the components advance (CPU/SoC, I/O, displays, etc.),
aaaah gotcha! that's the _whole_ reason why i designed the long-term modular standards, so that products *can* be split around the arms race of CPU/SoC on the one hand and battery life / display etc. on the other.
and the factory that we are in touch with (the big one), they _love_ this concept, because the one thing that you might not be aware of is that even the big guys cannot react fast enough nowadays.
imagine what it would mean to them to be able to buy HUGE numbers of CPUs (and related components), drop them into a little module that they KNOW is going to work across every single product that conforms to the long-term standard. in 6 months time there will be a faster SoC, more memory, less power, but that's ok, because *right now* they can get better discounts on the SoC that's available *now*.
on the other side of the interface, imagine what it would mean to them that they could buy the exact same components for a base unit for well... three to five years (or until something better came along or some component went end-of-life)?
it took them a while, but they _loved_ the idea. the problem is: as a PRC State-Sponsored company they are *prohibited* from doing anything other than following the rules... i can't tell you what those rules are: they're confidential, but it meant that we had to find other... creative ways to get the designs made.
We're in a world where a first generation Nexus 7 tablet sells for $140 or less. At Walmart.
yeah. now that prices are dropping, just like the PC price wars, the profits are becoming so small that the manufacturers are getting alarmed (or just dropping out of the market entirely). those people are now looking for something else. they're willing to try something that might get them a profit. what should we tell them?
anyway: thank you for your post, darylb, it provides a very useful starting point for some of the key insights i want to get across to people.
short version: the plan is to carry on, using the lessons learned to
try again, with a crowd-funding campaign that is transparent. please
keep an eye on the mailing list, i will also post here on slashdot
when it begins.
http://lists.phcomp.co.uk/pipe...
long version:
this has been a hugely ambitious venture, i think henrik's post explains much:
http://lists.phcomp.co.uk/pipe...
the - extremely ambitious - goal set by me is to solve a huge range of
issues, the heart of which is to create environmentally-conscious
mass-volume appliances that software libre developers are *directly*
involved in at every step of the way.
so, not to be disparaging to any project past or future, but this isn't
"another beagleboard", or "another raspberry pi beater": it's a way to
help the average person *own* their computer appliances and save
money over the long term. software libre developers are invited
to help make that happen.
by "own" we mean "proper copyright compliance, no locked boot
loaders and a thriving software libre environment that they can
walk straight into to help them do what they want with *their*
device... if they want to".
the actual OS installed on the appliance will be one that is
relevant for that appliance, be it ChromeOS, Android, even
Windows or MacOSX. regardless of the pre-installed OS, the
products i am or will be involved in *will* be ones that Software
Libre Developers would be proud to own and would recommend
even to the average person.
by "saving money over the long term" we mean "the device is
split into two around a stable long-term standard
with a thriving second-hand market on each side, with new
CPU Cards coming along as well as new products as well.
buy one CPU Card and one product, it'll be a little bit more
expensive than a monolithic non-upgradeable product,
but buy two and you save 30% because you only need
one CPU Card. break the base unit and instead of the whole
product becoming land-fill you just have to replace the base,
you can transfer not just the applications and data but
the *entire computer*".
it was the environmental modular aspects as well as
the committment to free software *and* the desire to reach
mass-volume levels that attracted aaron to the Rhombus Tech
project.
perhaps unsurprisingly - and i take responsibility for this - the
details of the above did not translate well into the Improv
launch. the reason i can say that is because even henrik,
who has been helping out and a member of the arm netbooks
mailing list for quite some time, *still* has not fully grasped
the full impact of the technical details behind the standards
(hi henrik, how are ya, thank you very very much for helping
with the boot of the first A10 / A20 CPU card, your post on
the mailing list last week was very helpful because it shows
that i still have a long way to go to get the message across
in a short concise way).
the level of logical deduction, the details that need to be taken
into account, the number of processors whose full specifications
must be known in order to make a decent long-term stable
standard.... many people i know reading that sentence will think i
am some sort of self-promoting egotistical dick but i can tell you
right now you *don't* want to be holding in your head the
kinds of mind-numbing details needed to design a long-term
mass-volume computing standard. it's fun... but only in a
masochistic sort of way!
anyway. i did say long, so i have an excuse, but to get to the
point: now that the money is being returned, we can start again
with a new campaign - using a crowdfunding site that shows
numbers, and starts with a lower target (250) that offers more value
for that same amount of money to everyone invo
1978, aged 8, our school had a commodore pet 3032. i typed in a simple program in BASIC, 10 for i = 1 to 40, 20 print tab(i), i 30 next i, 40 goto 10 and watched the numbers 1 to 40 scroll across the screen. i figured "huh that was obvious, i can do that" and 25 years later i was reverse-engineering NT 4.0 Domains network traffic (often literally one bit at a time) by the same kind of logical inference of observing results and deducing knowledge.
by 2006 i learned that there is something called "Advaita Vedanta" which is crudely known in the west as "espistemology". Advaita Vedanta basically classifies knowledge (there are several types: inference is just one of them), and knowing *that* allows you to have the confidence in your abilities. up until i heard about Advaita Vedanta i was "hacking blind and instinctively", basically. now i know that reverse-engineering is basically an extreme form of knowledge inference. which is kinda cool.
Anybody here ever play that game?
yeah, me! were you around in 1995-1996 by any chance? in CB1 Cafe in cambridge UK i was the person who discovered that you could put zombies into the underground phase-tunnel vehicles, then sneak behind enemy lines (the underground vehicle could see "up" into one square at a time). i would go looking for artillery because artillery by default had a reaaally nasty habit of auto-firing at close-range enemies on a huuge delay. so, what would happen was: first zombie went up, artillery would turn and begin loading, zombie would go to nearest artillery craft and suicide, blowing up several. all artillery would fire, blowing up even more. second zombie up, artillery lock-and-load, zombie makes a beeline for.... you get the idea.
anyway the idea was good enough that it ended up on the hints-and-tips page. turns out that the people who we played were some of the people who worked at activision :)
huh. this sounds very similar to the theoretical virus designs i came up with many years ago. yes, you heard right: turn it round. instead of the programs on the computer being randomised so that they are resistant to malware attacks, randomise the *malware* so that it is resistant to *anti-virus* detection. the model is basically the flu or common cold virus.
here's where it gets interesting: comparing the use of randomisation in malware vs randomisation in defense against malware, it's probably going to start being used in malware before it gets used in defending against malware. why? because malware attackers have nothing to lose. unfortunately, they are likely to keep their compilers secret. even *more* unfortunately, successful creation of anti-malware randomising compilers means that the malware attackers can use them as well.
but, that is just a risk that has to be taken, and make sure a decent job is done of it.
Whereas with a bigger engine this is less of the case and you can get equivalent mpg
ah, i wrote a diesel truck simulator in 1993 for Pi Technology: there is actually much more to it than that. with a bigger engine with higher torque it is possible to have the vehicle drive more often in its peak torque range where it has either better acceleration or better fuel economy or both.
with a smaller engine the effect you mention - that people put their foot to the floor - means that the engine has to rev its nuts off and thus operates waaay outside of its efficiency band.
you need to watch that program. have you watched the program yet? what did the program get across to you, and can you put it better than i can?
before making *any* judgement you *need* to watch the program on 5th gear which covers exactly this question in some detail. basically the test was designed originally for people driving sensibly, and it was designed i think well over 20 possibly even 30 years ago. so it has a very *very* gentle acceleration and deceleration curve. gentle acceleration because that is not only fuel-efficient but also the cars of that time simply could not accelerate that much, and gentle braking because again that is more fuel-efficient but also because if you had drum brakes they would overheat.
people no longer drive sensibly: they are more aggressive with other drivers (not keeping a safe distance), they put their foot down hard on the accelerator and they put their foot down hard on the brake. also as the cars are more reliable they tend to not maintain them properly: until i watched another program on 5th gear about how badly old oil affects fuel economy and the lifetime of the engine i had absolutely no intention of changing oil regularly in the decade-year-old cars i buy.
so, in effect, people should stop complaining and start driving in more fuel-efficient ways... *regardless* of how aggressive the person behind them gets when they set off from the lights at the same acceleration rate as a 40 tonne cargo lorry. that's the other person's problem.
i love descent, and i love that it's now software libre. i hope the guy who maintains d2x has stopped being an idiot by including patched versions of standard libraries such as libsdl without providing an option to replace them and forcing the patched versions to overwrite pre-installed software, but yes - awesome.
the thing about descent was that it was the first game with 6 degrees of freedom. i actually bought a special joystick that was capable of dealing with it (one designed for flight simulators) and after 2 to 3 weeks of practicing i was competent at side-motion circular slides firing at a target at the centre. the first 2 weeks were spent mostly getting motion sickness and having the nose of the craft bashed against a corner :)
it was also fun to watch spectators swaying from watching the screen! but, again, after a couple of weeks you got used to it, both as a player and as a spectator.
yeah - to those people who set up LAN parties: i hear ya :) i did the same. i think the lowest spec i got away with was a 486 SX 25 with 12mb of RAM, setting the screen to 320x240 and it was just about tolerable. i had to use 10-Base-T with terminators for goodness sake - what the heck i was doing with 5 networked computers in my house back in 1996 with just a 28kbaud modem i _really_ don't know!
so yes, absolutely: descent (the software libre version *or* a commercial version) gets my vote... *as long as* it has a community portal similar to that of Dark Reign, with a chat room so that people can meet other players, set up a match and play. that is bizarrely what's missing from bzflag: although bzflag has an in-game chat it doesn't hatve out-game community chat, very odd.
also, it would be awesome to see planetary-surface action as well, not just in mines (no matter how large). i always felt a little claustrophobic and the attack vectors would be very different in free space... interesting to think about the possibilities here, hmmm :)
LOL
"i have never even seen a PAM module which does this trick. it would be awesome to do the same trick for ssh as well."
you mean like pam_ssh for ssh keys or if you just want it to work with gpg and ssh you could also run the gnome key manager as I do.
True single sign on with all ssh and gpg keys.
no not pam_ssh. not "ask for a 2nd passphrase at a 2nd prompt which is entered into the ssh system to unlock the ssh key" - have ABSOLUTELY NO login credentials AT ALL, and LITERALLY use the success/fail of the ssh passphrase (or gpg passphrase) unlocking *AS* the login. no /etc/shadow, no password field in /etc/passwd - nothing BUT unlock the gpg or ssh key.
so what's the difference between the NSA's plan and Hydra's plan in Captain America Winter Soldier? absolutely nothing as far as i can tell. can anyone tell me if i am mistaken?
depinit. written by richard lightman because he too did not trust the overcomplexity of sysv initscripts and wanted parallelism, it was adopted by linux from scratch and seriously considered for adoption in gentoo at the time. richard is extremely reclusive and his web site is now offline: you can get a copy of depinit however using archive.org.
using depinit in 2006 i had a boot to X11 on a 1ghz pentium in 17 seconds, and a shutdown time of under three. depinit has two types of services: one is the "legacy" service (supporting old style /etc/init.d/backgrounddaemon) and the other relied on stdin and stdout redirection. in depinit you can not only chain services together for their dependencies but also chain their *stdin and stout* _and_ stderr together.
that has some very interesting implications. for example: rather than have some stupid system which monitors /var/log/apache2/logfile for security alerts or /var/log/auth.log for sshd attacks, what you do is run sshd or apache2 as a *foreground* service outputting log messages to stderr, chained to a "security analysis" service which then chains to a log file service.
the "security analysis" service could then *immediately* check the output looking for unauthorised logins and *immediately* ban repeat offenders by blocking their IP address, rather than having to either poll the files (with associated delays and/or CPU untilisation) or have some insane complex monitoring of inodes which _still_ has associated delays.
also depinit catches *all* signals - not just a few - and allows services to be activated based on those signals. richard also had a break-in on one system, and they deployed the usual fork-and-continue trick, so he wrote some code which allowed the service-stopping code to up the agressiveness on hunting down and killing child processes. this also turned out to be very useful in cases where services went a bit awry.
basically the list of innovations that richard added to depinit is very very long, in what is actually an extremely small amount of code. i simply haven't the space to list them all, and no, richard was not a fan of network-manager either.
btw you might also want to look at the replacement for /bin/login that richard wrote. it was f****g awesome. basically what he did was use gpg key passphrases as the login credentials.... and ran gpg-agent automatically as part of the *login*. i have never even seen a PAM module which does this trick. it would be awesome to do the same trick for ssh as well.
it's fascinating what someone can get up to when they have the programming skill and the logical reasoning abilities to analyse existing systems that everyone else takes for granted, work out that those sytems are actually not up to scratch and can write their *own* replacements. it's just such a pity that nobody seems to have noticed what he achieved.
there is actually something which is far more useful to be able to do, more than any amount of books read, which is only really possible effectively and efficiently now that internet searches are possible (and quick, and accurate), and that is meta-learning. in its crudest most disparaging form one might mistakenly call this cut-and-paste programming but it is actually nothing of the sort.
basically what you do is treat everything as a black box, and use the principles of the 6 different types of knowledge (listed on the wikipedia page for Advaita Vedanta, which is mentioned specifically because the western word Epistemology is woefully inadequate) to basically reverse-engineer the subject matter and in effect teach yourself *on the go* by way of analysing the results achieved, even though you are starting out from quite literally zero knowledge.
it does however take a hell of a lot of balls to do this *whilst being paid* and most employers simply will not believe you when you tell them that this is something that you can do... and be *more effective* at applying this technique than people who have been explicitly trained or quotes have experience quotes in the field.
to be fair to those people who genuinely do have experience, often such people *may* have encountered the circumstances before, such that they *may* have the answer much quicker than you-who-has-no-experience-at-all, *but*, the critical critical thing that you need to tell prospective employers is: what happens when something falls *outside* of the experience of the person who quotes has experience quotes? whom then would the employer rather have (if they had to choose one or the other rather than both people) - the person who will get there in the end, regardless of what they are asked to do, or would they rather have the person who can get there *most* of the time but who does not have the skills or intelligence to work out the all-important remaining last 10% of the job, without which the contract will remain unfulfilled and the company will go bust because of it?
in short: no amount of reading will substitute for learning how to learn and applying that skill *every single moment of your life*. when i hear people say i am too old to learn it makes me cringe, and i feel sad for them - i cannot say anything so i have to remain silent - but i feel sad for them because i know that inside they have given up. the only time to give up learning is when you are actually dead, and not before!!!
ynow... there is a moral to this tale: if businesses and individuals making money from software (libre) had properly funded it, putting some of the money that they saved from not purchasing proprietary software into the hands of those software teams, would we be talking about this now? in all probability, the answer is no. the reason is because those teams would be able to expand, take on more people, pay for security audits and so on which they would otherwise, as we have discovered, not be in a position to do.
so my take on this is that it is really really simple: businesses have received what they paid for, and got what they deserved.
i have been through this experience - directly - a number of times. i worked on samba - quietly - for three years. whilst the other members of the team were receiving shares from the Redhat and VA Linux IPOs, which they were able to sell and receive huge cash sums - i was busy reverse-engineering Windows NT Domains so that businesses world-wide could save billions of dollars.... and not one single one of those businesses called me up to say thank you, have some cash. as a result, about a year after terminating work on samba i was working on a building site as a common labourer.
it was the same story with the Exchange 5 reverse-engineering, which the Open Exchange Team mirrored (copied, minus the Copyright and Credits).
there is a moral to this tale: unlike proprietary software, which has a price tag commensurate with its perceived value, the process of even *offering* payment to individuals working on a software libre project that has been downloaded, usually from a completely different location (via a distro), is completely divorced from the developers actual efforts.
even in shops in rural districts, it is understood that if the door is unlocked and the shopkeeper not there, you help yourself, open the till, sort out your own correct change and walk out. but in the software libre world there is often not even that level of expectation! the software is quotes free quotes therefore it is monetarily zero cost therefore we should not have to pay, right? and businesses are pretty pathological about taking whatever they can get without paying for it.
so the short version is: there is a huge disconnect in software libre between service provision (the software) and paying for that service, and i really cannot see a solution here. perhaps this really should be bigger news: perhaps in this openssl vulnerability we have an opportunity to make that clear.
You're assuming a lot there. How would you know if osx or windows NT kernels are 'fully parallelized'? Have you seen the source?
someone else answered about OSX. NT, based on the MACH kernel, has been fully re-entrant and multi-threaded for a looong time. also, given that the service control manager (which is a parallelised start/stop daemon service) is fully parallelised i'd be incredibly surprised if the same attention to detail wasn't also carried through on device-driver initialisation as well. although.... the only evidence against that is the "Debug Startup" mode, which initialises drivers in sequence (and shows you the sequence), but that could well be due to the request for "Debug Mode" rather than an underlying design. honest answer: don't know.