Re: I have to say
I was hoping that someone would explain the reference because obviously "damp squid" cannot be allowed to stand. Cheers!
1346 posts • joined 8 Nov 2007
it was probably while watching The IT Crowd :)
You know, you're probably right :)
"BECAUSE SHE'S DEAD!!"
Sorry for your loss. Move on.
Damp squib is the one you want. Squids should be damp, squibs should not.
Pshaw. I know English good: I'll continue to say "damp squid" irregardless.
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...
As a series brilliant, totally brilliant. The last episode hmmmmmm
Pretty much have to agree. That last episode was a bit of a damp squid, IMO.
Where's H. P. Lovecraft when you need him?
I'll have you know that my doctorate at Miskatonic University has given me fine preparation for such a thing.
Now where did I leave my Petri dish, length of wire and Bunsen burner? ...
Humans are funny. They'll fiddle as Rome burns
Rome didn't burn in a day, you know. You've got to something to while the hours away. Why not this?
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.
Ergot, we should install filtering or something?
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?
... faster than a ninja making origami cranes.
or my personal favourite, "Superman on laundry day".
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?
Statitics are often hard to interprate
Wow. I don't think I've seen a post with worse spelling here. Is to "interprate" to interject prattling?
But pi.e = 8.539734223, so I think they've got their maths wrong if they're celebrating from 3rd to 9th of March...
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.
The old "but those drugs were just resting in my pocket" defence. Now where have I heard that one before?
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)
A bit tricky, but I've seen Pis with attached touchscreens.
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.
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.
The Kiwis say it as "dub dub dub" which is a b[i]t faster.
I've been trying for years (unsuccessfully) to convince people that it's pronounced "sextuple-u".
edit: didn't notice the other poster making a similar point above. So there are two of us at least :)
- Allo madmoiselle, ah av come to fix ze washing machine
Unfortunately, I can't watch those Calgon ads on TV without thinking about tacky porn films. In my mind the dialogue (translated from German, I guess) would go something like "there's your problem right there! I'm going to have to whip it out ..." (and so on)
I didn't realise until now that George Foreman is one of the saviours of the human race.
Whenever I use the George Foreman grill at home I remember how it's supposed to be good at fat-free/fat-reduced cooking. Then I slather* the outside of two bits of bread with butter and put a good melty cheese (like brie*) inside with some processed meats (chorizo* + something else, usually; chorizo goes great with anything) and toast up a delicious, fatty grilled sandwich. The contents of the drip tray** can be drizzled over subsequent sarnies* eaten in the same sitting.
Purported health benefits of the grill: easily and tastily subverted. Stick that in your metaphorical pipe, George :)
* for some reason Firefox is putting wiggly red lines under these words. I'd call it a conspiracy (to unword only delicious and unhealthy things), but since it also redlines "Firefox", "unword" and "redlines" but not "epicurean", the reason for the omissions is probably plain boring(ness).
** any of the brie that oozes goes a bit like crispy Czech Smažený sýr, another delicious invention. I dare say that the GF grill would be good at making that too.
a) Fermat was pulling the old "hence it is obvious from the diagram" stunt that was roundly rejected as sound reasoning or excuse-making by my Applied Maths teacher in '73.
Oh, I don't know. I think that Pythagoras' theorem is self-evident from this diagram
2 [sic]) It is *NEVER* appropriate to point to a Wikipedia page to dodge explaining something mathematical to the non-hard-sums-numpties out there
Oops. I appear to have linked to a wikipedia page. Oh noes!
In all fairness, though, I do agree with you that Wikipedia pages on maths are generally bad. They're definitely failing in their attempts to explain most concepts to the general reader, and often even to those who aren't frightened by and/or have a modest level of maths ability.
If you look at the +1 and -1 values as steps in a random walk over the number line, then there must be some subsequence of steps that moves you arbitrarily far from the origin. It seems intuitively obvious: on the one hand, it's kind of like an infinite monkey argument or, say, that if you take all the digits of pi in some number base and squint at them in the right way (cherry picking some subsequence), you'll find some pattern that looks meaningful. Actually, Pi, the film uses this as its premise, now that I think of it.
The other way it seems intuitively obvious is that if the sequence is actually random and you start slicing it up, you're bound to be able to find some sequence that has lower entropy than expected. It shouldn't matter, though, because the entropy of the entire sequence is fixed (so using Kolmogorov complexity to define the entropy, the fact that there are some signs of structure, it doesn't mean that this negentropy is useful for compressing the entire string). That's the way I see it, anyway. I just don't know what the point is of looking for structure in unstructured (random) strings.
Wanty wanty no getty and getty getty no wanty.
Did the reg remember to ask him whose shirts he wears? Or does he wears capes instead?
Is another folk singer like I need a hole in my head.
The air forms a cushion that lets the head get close, but not too close to the platter. It will dampen a small amount of vibration and avoid the head crashing into the platter. At least, that's as I understand it... I think that I've read somewhere that one of the challenges of using helium is that it's going to leave the head closer to the platter because it's not as viscous as air, so they have to work with lower tolerances.
presumably engineering the spinny bits gets harder the wider and heavier the platters
I think you're on the right track (no pun intended). Larger disks have higher moments of inertia, which is a measure of how hard it is to turn (or stop, once it's going). Higher moments of inertia require more powerful motors, longer spin-up/spin-down time and have poorer speed control response. Also, as you move out towards the edge of the disk, the speed of the platter relative to the head is proportional to the radius (obviously it travels a distance of 2pi r every revolution) so another limiting factor will be the speed at which the read/write heads can encode/decode information. If the platter is moving too fast, either the electronics won't be fast enough to keep up or the arc length needed for writing a block (or convenient unit) of data at the speed the heads can manage will be too long to justify simply increasing the radius indefinitely (IOW, areal density will eventually scale in proportion to 1/2pi.r once you reach the limit of the head's en/decoding circuitry).
Thirdly, larger disks are more susceptible to vibrations and wobbles (perhaps due to imperfections in the manufacturing process). The disk heads have to float on a cushion of air (ground effect, I think it is) and you increase the risk of head crashes as you scale up the radius and angular momentum. As the disk is effectively a big gyroscope, it resists changing its pitch if the drive is tilted (dropped), whereas the disk head and mounting doesn't have a similar moment of inertia, so again it's going to cause torsional stresses and more possibility for head crashes if the whole disk pitches or vibrates in the wrong way.
Like the one you were in when writing your post?
(McKean's Law and all that)
No. That's my baby.
re: This looks like just the tip of the iceberg.....
Yes, next step is to calculate cos to 3 decimal places. It's not very bright, though---you can only use it for dim sums.
Great for active-high circuits
Maybe active low. Lettuce contains narcotics/soporifics. (fun fact: that's why lettuce wine is not advised)
Step 1: pick a tune that you can play on a piano keyboard
Step 2a: assign one key to each piano key /or/
Step 2b: count whole notes/semitones from some starting position
Step 3: hum the tune or come up with some mnemonic to remind yourself of the association
Step 4: wait until someone makes a dictionary with common melodies
To be honest, this is probably just as bad as something like picking/encoding sections from $INSERT_ONE_AND_ONLY_HOLY_BOOK_HERE.
You said when we embarked on this great adventure together, that lots of laughter was essential in a relationship.
You also made the point that a great deal of sex was of equal importance.
Again, I agreed. Wholeheartedly.
In fact I remember your exact words: laughter and sex are the barometers of a relationship. This was the statement you made, if I remember correctly.
Don't get me wrong. I couldn't agree more. But no at the same time, ya fuckin cow.
... apparently not much intelligence here in the forums, either. Stick that in your equation!
Q: How do they tell the difference between encrypted data, and a capture of a few seconds pink noise from a quiet part of the FM spectrum?
I think you just answered your own question there. An encrypted file will sound like white noise, whereas pink is 1/f.
All in-range humans would be good. Plus an auto-freeze when they come into range, to give me time to formulate my evil plan...
Might I suggest some sort of remotely-controlled device that emits a waft of bacon to entice people into range? In fact, it could probably dispense actual, real bacon. Much easier, technologically-speaking, than a freeze ray, and almost as good at preventing humans from escaping---kind of like the olfactory equivalent of a monkey trap.
(sadly, those glyphs on hand driers don't actually mean "receive bacon", which is why humans eventually give up and leave the bathroom)
I wonder whether one could get away with "Dark Cashian"? Or would we be subject to the lawyers' malaprops?
Damn. I can remember a time when rap music was all about the cash.
but I immediately thought of the Magnet Fields song "Fido, your leash is too long".
By which I mean sticking with the one-dimensional layout. As you up the number of cores and (as they're doing here) introducing more speculative pre-fetching on either side of a branch you're putting more and more strain on the memory bandwidth. It's all well and good scaling your compute cores up to 12, but the memory bandwidth just isn't keeping pace. Wouldn't it make more sense to look at going to 2-d or some other architecture (maybe even use a projective plane like the Fano plane and let apps build custom topologies on top of it)? Even the PS3 had two ring-shaped memory buses (though main memory itself wasn't laid out like that), so it's not beyond the realm of possibility to get novel memory buses in consumer/general purpose machines.
Maybe this is something we can expect to come along eventually thanks to the SeaMicro purchase? Or is that purely for inter-system connections?
Once you've learned to recognize your birch from quite a long way away
Don't you mean "the larch"?
Hmm... there seems to be quite a few commenters here today who thought this was a pretty lousy article. And yes, I also used the "send corrections" link...
will make more people more punctilious about making, securing, and testing their backups
I think you mean something more like "diligent" or "meticulous". "Punctilious" conjures up the same sort of negative connotations as "officious" does for me...
Just make sure your backup machine isn't infected! Oh, and a database of hashes for integrity-checking is a pretty good idea, too.