Much Apple
So Now. Actually old, redone.
2662 publicly visible posts • joined 8 Nov 2007
Six years ago ...
Damn it! You beat me to it:
An excellence-oriented '80s male does not wear a regular watch. He wears a Rolex watch, because it weighs nearly six pounds and is advertised only in excellence-oriented publications such as Fortune and Rich Protestant Golfer Magazine. The advertisements are written in incomplete sentences, which is how advertising copywriters denote excellence.
(Dave Barry, In Search of Excellence)
VideoLAN (and no doubt others) can do true multicast so that several screens can be tuned into the same video stream. If you've got a segmented network topology (several different subnets), you have to be aware that most routers/gateways won't forward multicast packets by default, so you need to explicitly enable it and run something like pimd to do the actual forwarding (Linux kernel, for example, does all the lower-level handling of UDP multicast networking, but you need something like pimd at the higher level to implement the network topology).
A couple of handy commands for testing this:
iperf -c 224.0.50.50 -u -T 2 # sender
iperf -s -B 224.0.50.50 -u -T 2 # receiver
(replacing the 224/* address with whatever multicast address you're using)
So this virus (presumably written by pot smokers) infected a machine which then stopped working, without even 'taking care of business' first. Why am I not surprised?
Nah, it worked. It's just that it lived so close to the top of memory that the stack area overlapped the area for the stored message (so regular subroutine calls and interrupts garbled it). For something that couldn't even "take care of business" as you put it, it was remarkably successful, bugs and all.
(this comment based on actually disassembling the code and figuring out how it worked; I'm sure I have a copy of this still filed away somewhere)
"why is MSE even searching for Stoned when it is ineffective on systems these days?"
For a few reasons:
* because, as someone pointed out above, it's cheap to add more signatures (things are much better than O(n) complexity we had in the very early days). If you can scan for it, and it's cheap to do so, then why not?
* because it's one of those viruses that your scanner is expected to pick up (and virus scanner manufacturers used to use number of viruses detected as a marketing tool)
* there are such things as virus droppers that will install all sorts of malware. The blockchain (or any random data file) mightn't be (isn't) a virus in itself, but if it contains the virus (which it doesn't) a dropper can pull it out and use it to infect something (so if I had an SQL database with lots of virus code, it would be nice if the av software could detect it in the db file)
* who says that it's ineffective? Some people still use floppies. (true, its not much of a risk, but the infection mechanism still works)
* by catching the floppy-only variant, you might also catch derived versions (like NoInt) that can infect hard disk boot sectors
Mostly, though, it's probably just a combination of inertia and anti-virus writers liking to keep old signatures around for historical/completist reasons. Maybe they should drop these old signatures, but imagine the embarrassment should one of these apparently "extinct" viruses have a high-profile outbreak and MS's program failed to detect it?
If you're building your own board, there's an Adafruit through connector on the Farnell website for £1.14 apiece. I think the Adafruit stuff tends to be pretty good quality, but I haven't used this particular item.
There are stackable add-ons for the Pi as well. This solution is a bit of an abomination, but it looks like it can take any of the add-on cards so long as they don't have conflicting requirements for GPIO pins. This other supplier seems to have a saner approach, with single-purpose modules being stackable using I2C, I guess, so GPIO conflicts shouldn't happen provided everything has a unique I2C bus address.
Then, there's GrovePi (as mentioned in the latest MagPi, also this link) that does away with physical stacking and does everything through wiring up modules with a standard 4-wire connector. I think that's probably the neatest implementation for stuff like robots because you can route your sensors to where they make sense physically.
I think you were saying that in the Arduino world, it's quite common to have pass-through connectors for stacking. Using a Gertduino would let you build up a stack of such Arduino modules, with a Pi controlling the whole show on the bottom.
There's no point in acting all surprised about it. All the planning charts and demolition orders have been on display at your local planning department in Alpha Centauri for fifty of your Earth years so you've had plenty of time to lodge any formal complaints and its far too late to start making a fuss about it now.
The 64 core parallella chip seems to be about to start production
Actually, it's not. The original Kickstarter campaign included the 64-core boards as a stretch goal, which was not met. Those 64-core boards they've been testing are engineering prototypes, only going to backers who came in at a certain level.
The whole Parallella project has been something of a disappointment, IMO. I think they over-promised (at least the 16-core machine isn't really a "supercomputer for everyone") and struggled to deliver. At least we know they've been plugging away at trying to make it a success and I do have sympathy for them in terms of the unforeseen problems they ran into. They have delivered at least some 16-core boards and hopefully they'll get around to delivering the rest to all the Kickstarter and pre-order customers within the next month. I'm one of the pre-order customers, so I'm hoping that they'll clear their commitments to everyone who ordered one within that time frame.
After that, and people have the boards in hand, hopefully people will still have enough interest in the platform for them to be able to make money by ramping up to full-scale production of the 16-core boards... I'm sure they're still doing work on the 64-core (and higher, up to 1024-core) and if they can get the funding for it, that's where they do want to go. I just don't expect it any time soon...
As for your idea of neural nets, I'm sure that it's pretty feasible to run them on the Epiphany cores. There's a pretty long thread about it on their forums somewhere. It's nowhere near the level of brain simulation, of course, but you can always cluster them and even single boards should be pretty efficient, given the right algorithms and such.
The story is about a narrow minded judge using a very broad interpretation of a USA-ian law to try to do an end run around international law and treaties
It's not the first time this has happened. From an old article here: Kentucky judge OKs 141-site net casino land grab. It's almost as if concepts like non-USA law and territoriality doesn't exist.
<sound of ambulance and large coves wearing white jackets>
Not about ipv6, but the whole concept of Internet of Things.
I think that there are plenty of companies out there salivating at the thought of making a lot of net-connected gizmos. Most of them will be junk, but they'll be able to charge a premium for them. That's not the real issue, though. The real issue is how many of these gizmos basically won't work unless you use the manufacturer's servers for data collection and control. Like many other readers here, I would never buy a product that worked like that, regardless of how useful or desirable the gizmo was. It's this element of being able to spy on users (or simply being able lock them into a subscription service for the lifetime of the device) that I fear will be quite appealing for many companies.
This, in my opinion is the single greatest factor that is stopping (or will stop) the advance of this IoT thing. OK, I said I wouldn't mention IPv4/IPv6, but ...
I know that IPv4 and NAT issues are also another technical limitation. You can't easily connect to your server without either renting a VM or server from a hosting provider (which also might have privacy/legal issues surrounding it), can coax your ISP to do port forwarding for your incoming traffic, or simply shell out for a (scarce) public IPv4 address.
IoT device manufactures really need to provide two options for the user: first, they need to let you configure the devices so that you use your own server (and provide the server software), and secondly, they also need to make their stuff IPv6-capable. The latter is a bit of gamble considering it adds cost for a feature that not many people are using yet (and it's unknown if/when they will). On the other hand, if they don't support IPv6 then all these devices will go straight to landfill if/when the switchover happens...
As for NAT, IP was not originally designed for address translation and some internet protocols do not work with it, notably active FTP and SIP
Maybe it's ignorance on my part, but I don't think that's true.
As I see it, it's not NAT that's the problem, but the fact that it's generally a one-way only operation (eg, sNAT to modify your outgoing packets so that they appear to come from the router rather than whatever your local address is). I'd thought that any program that operates from behind the firewall should work fine so long as it restricts itself to only making outgoing connections, with incoming packets for the session being correctly identified by the router as belonging to that session and so routed back inwards correctly. Am I wrong on this?
If you're talking about running an FTP or SIP server inside your NAT'd network, then obviously you're out of luck unless whoever runs your NAT'ing firewall (most likely your ISP, because they realise the value of public IP addresses and usually charge extra for them, with everyone else behind NAT) agrees to do traffic forwarding of incoming connections. That being so, it's not a problem of FTP/SIP (or any other server that's designed to accept incoming requests) is incompatible with NAT, but rather that ISP's NAT policies dictate that regular users can't just request port forwarding so that their mail server or whatever appears to be "on the Internet" (at least not without paying). Again, that's the situation as I understand it.
The really big problem with NAT is that if ISPs allowed users to run servers behind the NAT box, you'd very quickly run into conflicts about the assignment of port numbers. Some services (like http) are quite happy moving from the default ports (80/443) so long as the client machine puts the right port address in the URL. Other applications are much more picky about what port they listen or talk on, and the clients (or peers, if we're talking about something like an online game like World of Warcraft, which I think uses a p2p system for downloading updates) simply don't have the option of trying to connect to a different port. I assume that SIP works with a fixed port number for receiving incoming calls (unless you have an external directory where you can look up ip:port for a number?), so if that's the case then you can only have a maximum of one user behind the firewall who "owns" that incoming port. This technical limitation (and, I guess, any privacy/security concerns arising from making a mistake and routing to the wrong user) makes me suspect that ISPs will generally not even entertain your request for port forwarding if you're a regular NAT user ...
As much as I hate this restriction with NAT, I'm still not sure that I like the alternative of flat routing (no hiding behind NAT) in IPv6. I know people will say that I can just use a router and drop packets like I used to be able to do in IPv4. At least I assume that's the case. My problem is basically that IPv6 is so complex that I'm not sure I trust myself to even do this routing correctly and be sure that none of my IPv6 devices can't be accessed from random machines on the 'net somewhere.
I'm replying to my own post above purely in the interest of accuracy.
Typing 'beard second' into Google gives the suggestion '= 5nm', so if Google is right, then 15nm is actually 3 beard-seconds. Google's answer may be controversial, though.
So they've gone to a 0.125 beard-second fab process? Very impressive. I think this could be a very handy unit for measuring things that are very much sub-linguine in length (pasta's too hard to cut up that small). Editor?
玉. is either 'tama' (kun-yomi) or 'gyoku' (on-yomi). If it's in a compound it's much more likely to use kun-yomi (Japanese style reading) and mean "ball" or a round thing. Like 'eyeball' is 'medama' (with tama undergoing a sound change, becoming dama). The on-yomi (Chinese style reading) by itself would mean "jewel" or "jade" (the material). There might be some compound words (eg, 玉石, ぎょくせき, gems and stones) that use the on-yomi, but I think that the tama/ball reading is much more usual (eg, 玉石 also has the reading たまいし, a pebble/boulder/round stone).
How about "inu no kintama" for the Japanese translation. 犬の金玉. Literally "dogs gold balls".
I have a copy of "Japanese Street Slang" at home. As you might imagine, it has a whole section devoted to testicles :) Kintama is the #1 word they recommend, but (as with many of the words in the book) I've never heard it spoken. It does seem to have a good pedigree, though (no pun intended).
The other word that I was actually going to suggest is in there too: O-inari. The 'o' at the start is an honorific prefix. Look up the web to see pictures of "Inari sushi" (contracted to "inarizushi"). For example, this one. From the resemblance to scrota, it should be obvious that people could understand its slang use. The only thing about using it with kitsune (as opposed to inu) as some people have suggested is that there's also a kami (somewhere between a spirit and a god) named Inari, and the kitsune are his messengers. If you said something like 'kitsune no inari", people might thing you were referring to the kami and get confused. You'd just have to try it out on a native Japanese speaker.
On another related point, I'm sure loads of you have heard the story about how the dog's bollocks could have come from Meccano sets and the "Box Deluxe". I'm sure that's pure bollocks. I always thought that the idea came because there must (self-evidently) be something good about them (the dog's bollocks) because they like to lick them so much. I've always wondered if the phrase translated literally into other languages because it would be strong support for the "self-evident" etymology theory. When I heard 'la puta madre' in Spanish I thought it literally meant 'dog's bollocks' (madra being the Irish word for dog, but that's a false friend). Alas, although it does translate to it in English, it's not a literal translation.
Anyway, this is all vital research, and I'm glad that el Reg is championing it in its pages. Thumbs up!
Definitely my favourite pulse. I make tomato-based stews fairly regularly... mostly with split yellow peas or chickpeas. Makes for a very hearty and cheap meal. I used to be vegetarian, but these days if I'm making such a thing, I'll chop up some chorizo and put it in the pot at the start to crisp it up a bit and release the oils (which stay in the pot and give a really nice flavour to the rest of the dish---it's crazy, but I sometimes see recipes telling to to throw out these delicious oils after cooking ii!). I take the chorizo bits out at that point and float a few of them on top of the stew when serving it, but sometimes I leave them in. In fact, I had a version of this for dinner today and yesterday, but I poached a ray wing in the stew for about 5 min at the end of cooking, then added some pre-packed crayfish.
I guess what I'm getting at is that it's actually dead simple to make (recipes for this sort of thing abound, but I've evolved my own as I went along) a very tasty and nutritious dinner very cheaply using simple ingredients: mainly onions, garlic, spices, tomato, celery, carrots, potatoes and pulses. I haven't calculated it, so maybe it's not a pound-a-day cheap, but I'd say it's close and probably a lot better for you than some of the things people are suggesting (like Mars bars!).
But taking a samovar to work would be even more hassle than a teapot.
You could always try making and selling a brew on your train to work. Or maybe barter the tea for chocolatey snacks your fellow passengers might have. I think it would probably be within the spirit of the exercise, if not the letter.
Yanks in space? Russkies on the Moon? Same thing, just different different docking music.
(yes, there definitely is an IT angle!)
Thanks for the link, Peter. I would have thought my attempt at irony would have been obvious based on how egregiously my English was wrong.
I was hoping that someone would explain the reference because obviously "damp squid" cannot be allowed to stand. Cheers!
I found the subtitles for the episode on the net (dialogue between Negative One and Moss):
"Heard you been catching some nice letters."
"I get the same letters as everyone else."
"Good when they fall in the right order, though, innit?"
The Countdown episode was definitely one of the best. The secret club reminded me of the Seinfeld episode where George pretends to have a dead supermodel wife, which opens the door to another secret club (of course, George being George, his lies are found out and when he goes back, the club is a meat locker).
Also, who doesn't like Countdown (trivia: Channel 4's first ever broadcast)? It's great to see them taking the piss out of themselves. Likewise, I think the 8/10 cats does Countdown episodes are pretty excellent. I laughed myself silly watching one the other night (the one with the Countdown stuntman). I can't recall the last time I had so much fun watching a tv programme...
In my day, when Humpty Dumpty cracked his shell, not even all the king's horses and all the king's men could put him back together again. The big bad wolf ate Little Red Riding Hood, and even in a tale with a happy ending (Hansel and Gretel), the witch gets burned alive in her own oven. We also played Cowboys and Indians and Cops and Robbers. Nowadays, Humpty Dumpty can be rebuilt, the huntsman saves Little Red Riding Hood (or maybe the wolf only came for tea) and Hansel and Gretel would have been adopted by the kindly witch.
What is this world coming to?
You start off with high-speed trading (well, just arbitrage, as you said), then talk about how price of one commodity affects particular stock values. Then you say "Being able to cross-calculate these price changes also takes us a little closer to being able to plan the economy". But which price changes? The differences in prices that arbitrage exploits, or the correlations between fluctuations in one commodity and some other figures? It should be clear that the first kind of fluctuation essentially holds no information: I'd liken it to quantum fluctuations in a vacuum---it's meaningless, random, with any apparent information content just being an artefact of quantisation effects (in fact you can use the same language and say that arbitrage works because it exploits quantisation artefacts in different stock markets).
Lots of people, myself included, would argue that arbitrage doesn't really add value to an economy. You can argue for the "invisible hand", and that it's bringing the market in line with the ideal of perfect information flow but it's obviously not perfect or (a) people wouldn't be making money on arbitrage (how can it be perfect information flow if only some people are able to exploit stock/commodity data?), and (b) you've already mentioned that all this HFT can have bad effects as feedback loops (or "flocking"*) behaviour causes markets to go completely out of whack from time to time.
If, instead, you're talking about the web of connections and correlations between various stock and commodity prices, then you haven't established the connection between arbitrage or HFT algorithms and the ability to plan the economy. Quite frankly, that's a ludicrous postulation. Yes, I understand that you try to make the link by mentioning how algorithms are evolved, but consider:
* these algorithms aren't designed to build up an understanding of the economic system as a whole, but to exploit short-term fluctuations (including impulses deliberately injected into the system by buying and selling with a view to sending various stock prices in one direction or another). You literally can't see the wood for the trees.
* experiments with new models or new impulse triggers cost money--real money. You might argue that we can "evolve" better models this way, but in reality it's no different from a gambling addict pouring money into ever more complex (and fraught) betting systems. The only difference is that high-frequency traders generally aren't using their own money to fund these experiments.
* you can't account for (or predict) delays between an impulse and an observed effect. Eddie Murphy might have been right in his reasoning for when to buy/sell concentrated frozen orange juice in Trading Places, but he could just as easily have been wrong (it was just a film, after all). There's too much elasticity in time and in perceived value.
* there are too many hidden variables. If you can't even count the number of hidden variables, then how can you build a statistical model?
* all these mechanical traders are working in secrecy, so how are we to trust this as a means of economic planning (the "invisible hand" becomes a "shadowy hand").
* all these mechanical traders are also competing against each other, and they have no way of knowing (short of widespread industrial espionage) whether the observed changes are a result of "the market" responding, or simply a knee-jerk reaction by other trading bots. Again, hardly a sound basis for economic planning
Taking all this into account, your whole argument just falls apart. There definitely is something to be said for economic modelling that takes into account the whole web of ownership, profit and loss statements, bills of material, futures markets, taxation systems, shipping costs and so on. But to try to link this to arbitrage and HFT is a pure nonsense.
Then again, this sort of speculative (and flawed) thinking is just what economists do, right?
*re flocking: looks more like murmuration, but that's almost beside the point. I say "almost" because while you may be able to predict flocking behaviour pretty well, you've got practically zero chance of predicting behaviour in a murmuration. As with markets, there are too many free variables.
Really? Ships have diesel engines. Diesel engines become more efficient the bigger you build them. This wikipedia page rates fuel efficiency "of rail and ship transport [as] generally much more efficient than trucking, and air freight is much less efficient".
So do you have any argument to back up that claim? Or are you really trying to say that transporting stuff is the problem? What's the solution, if not using the most efficient transport systems (ie, rail and ship) possible?
The banks should allow you to set up "aliases" for your bank account. They generate a new account number that is linked to your main bank account and then you give that account number to your employer or whoever needs to transfer money into your account. Make the account only available for inwards funds transfer, so that if the account details are stolen, they're of precious little use to anyone. (sort of like how you can get disposable, pre-pay credit card numbers)
At a stroke, this would solve the problem that these data breaches cause. They should also extend the "alias" idea so that you could set up separate payment accounts that you use for different recurring bills.
It seems simple and effective, but am I missing some obvious gotcha?
You could try bringing a court case claiming that your fundamental human rights were being violated. The Universal Declaration of Human Rights states:
Everyone has the right freely to participate in the cultural life of the community, to enjoy the arts and to share in scientific advancement and its benefits
Alternatively, just re-enact the "help, I'm being oppressed" bit from the Pythons' Quest for the Holy Grail.
Just following up on this because I think all your questions are valid.
How do I plug my hardware crypto cards into a rPI, or any other microcontroller come to that?
If it's supplied on a PCI card, then you're probably screwed. I simply don't know what sort of crypto hardware goes into these things. It begs the question, though, of what algorithms the thing is implementing, and whether it's based on open standards or whether it's just provided as a black box by some supplier on a "trust us, it's secure" basis. I think it's been shown time and time again that security through obscurity doesn't work, so if you can't get your supplier to give details of the encryption that's implemented or provide a board that can work over I2C or something else that the Pi/microcontroller can handle then there is something seriously wrong and the question of whether the ATM is built around a PC architecture or not is probably the least of your worries.
How do I run a properly secure filesystem on a microcontroller?
For read-only stuff, microcontrollers can be inherently secure as stuff is stored in ROM. On ARM platforms, there is a thing called TrustZone, that's intended to harden the boot process and make the machine more secure from tampering or running unauthorised code/OS. The Pi doesn't make use of this, as far as I know. It can, however, use the standard Linux crypto modules to provide for transparent encryption of all the filesystems it uses. I'm not too sure how useful this will be in an ATM, say, as opposed to a laptop or desktop PC. For the latter, for the security to be effective, you need a user to enter a password at boot time to access the disk. You obviously can't do that in an ATM that's intended to run unattended. I'm sure there's some way to make this work (such as the service engineer typing in the password after every boot, or some sort of challenge-response protocol done between the ATM and the bank's network where the Pi has to prove that the SD card hasn't been tampered with before getting the token required to securely boot off it---something like that). In any event, I'm not sure how vital boot security is on the machine when a service engineer can probably find ways to subvert it anyway. As for secure storage of logs, you can use the standard encrypted filesystem modules or use public key crypto to store sensitive details (so that the Pi can write the log data, but not read it back).
How does an rPI (of which I am a big fan) even start to run at the speed required?
Sure, why not? I mean, an ATM is basically like a kiosk or vending machine. It only has to handle one transaction at a time, and the UI stuff is pretty simple. Even if you want a complicated, flashy UI, have a look at what the Pi can do with xbmc. It's pretty impressive (and xbmc is a bit of a dog, so you could build something that's even more responsive).
The only (non-user) interface problem that the Pi might have is that it's not real-time, so it's not very suited for communicating with hardware that requires a low-level, bit-banged interface. So that's why I suggested you might need to offload this to a microcontroller or daughter board. (Microcontrollers have features that let you do this a lot easier, by triggering interrupts when interface lines change state, plus they're inherently real-time since they don't run a preemptive OS).
Why would I program up a whole load of microcontrollers, or use linux on microcontrollers when I already have the OS and drivers available for Windows (and yes, Linux too, should my bespoke app have been coded for that) on the existing hardware and have the benefit of knowing that all those bits of the software stack will work and I don't have to employ OS/microcontroller specialists in my banking business.
If you were talking with your banking friends, I don't doubt that this argument would go down quite well, even though I think it's erroneous (for reasons I'll get to anon, anon). This is a tech site. We're encouraged (and encourage others) to think about how things work "under the hood". The fact that you seem to be opposed to this (and don't seem to be giving any technical reasons why the XP solution is "better") is probably why you've been getting so many downvotes.
But anyway, I see two main problems with your argument for sticking with the status quo. First, there's the software side. Granted, if your app is making calls to a proprietary device driver, and you go and change the underlying hardware, then you will need to make changes. But (two big "buts"): (a) your software should already have been written in such a way as to separate business logic from hardware details, so to make it work on the new platform, you should only need to rewrite your interface library, and (b) If you're not writing portable code, then you're doing something terribly wrong, so I assume that porting the business logic won't be a significant problem. I'm assuming that the way you interface the ATM with the outside world is done via text-based command consoles (or similar, like SNMP), so all your external management software should continue to work. If you've got a dependency on something like using Windows RDP to manage the machines, then again, I think you're doing something seriously wrong. (plus: ATMs catching windows malware? wtf?)
Second, on the hardware front, I wonder if your complaint about needing microcontroller specialists is a bit of a red herring? By that I mean, do you actually even have the in-house competence to build and/or tinker with the PC/XP-based architectures that are in the current ATMs? I'm sure that building ATMs is a pretty lucrative business for those engaged in the market, and I also suspect that they simply provide black boxes and the banks have to take it on trust that the internals really work the way they say they do. I may be wrong on that, but even if you do have internal hardware expertise (not just developers that can code to the supplier's APIs) then I don't see how using open, off-the-shelf components (like Pis and Arduinos) is in any way inferior to the PC-like/XP platform.
Since it is a niche market, of course there will be a need for some bespoke (thought not necessarily proprietary) modules, such as for the card reader, though I'm sure there are enough applications for this that there are COTS hardware modules available. In fact, with the exception of your hardware crypto module (which I strongly feel should be based on open, rather than secret, protocols anyway), I don't see why the whole platform shouldn't be based on open, freely-available components. So if you do feel like you need hardware expertise, building the custom boards to connect all of these together should be child's play to any half-way decent electronic engineer. That's why I think that your comments about needing hardware expertise is probably a red herring.
Sorry for the length of the post. I hope my comments were useful :)
ATMs do far more under the hood than you think
I read the OP as meaning something more like a Raspberry Pi than (say) an Arduino. I happened to think the same thing myself when reading the article. Let's go through your complaints ...
UI isn't minimal
So what? You can build a UI in X or on the console. Button presses can be registered directly through GPIO or perhaps that part of the system can communicate over USB (pretending to be a keyboard)
touchscreens
A bit tricky, but I've seen Pis with attached touchscreens.
custom printing
No different from "printing". Hardly difficult.
cash counting hardware, card readers
Which are no doubt separate modules. Pi has several options for communicating with them (USB, SPI, I²C or a bit-banged GPIO interface).
hardware encryption modules
I don't know where these come in, so I can't comment except to say that if they're external devices then the same interface options are available as for cash counting/dispensing and card reader modules.
sound cards (well, chips)
Pi has on-board sound capabilities.
network stacks
Built-in, as is the ethernet port on Model Bs.
has to support remote control and remote update
Last I checked, Pis can run sshd.
it's well out of the realm of C coded microcontrollers.
I suppose it's where you draw the line. Maybe (only maybe) it's more than an Arduino can handle, but I'm sure a Pi is more than enough. I do see some problems with it, but I don't think any of them are insurmountable. For example:
* SD card failure
* not very tamper-resistant (service engineer could swap out SD card or entire Pi easily)
* may need custom circuits (or something like a Gertduino:) to offload some hardware-related tasks (eg, provide an I²C interface for an exotic crypto chip)
Hell, at the price point, you could afford to have several Pi (at least 3) systems all connected internally in a network in the box and build a fault-tolerant, self-checking system. Even accounting for custom hardware, it should totally be possible to build this thing for peanuts compared to the XP boxes. I'd be a lot more confident in the security of the thing, too,
The Web is the toilet, the Internet is the sewer!
That may still be too complicated for some people. Many times I've heard people confusing "sewage" and "sewerage".
On another topic, I can remember the first time I got into using the web. We weren't allowed direct access to the net, so I had to use usenet to get the address of a web remailer. You'd send a mail message somewhere and you'd get a set of uuencoded emails back containing the content of the page you requested. It was the need to piece the mails back together in the right order and decode them that started me learning Perl (though I probably wrote the thing in Awk first). Then fire up Mosaic (ugh) to view the decoded HTML file locally. Come to think of it, there was probably no Internet involved in delivering web pages in this way (mail probably being delivered by uucp over dedicated x.25 links).
When I was trying to figure out how the whole thing worked, I assumed that the whole web worked like a store-and-forward network (like usenet or fidonet), with intervening nodes caching any requested pages. I was wrong about that, but not totally because caching proxies did come later and are a pretty essential thing in many places.