Re: And another thing
<sound of ambulance and large coves wearing white jackets>
1360 posts • joined 8 Nov 2007
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.
玉. 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.
Have an upvote. I can't see any reason why someone would downvote your original post, since what you say is perfectly fine (even using "real estate", which makes for a good analogy). The detractors should take a look at FPGA programming (eg, this free introductory course) if they don't understand (or want to know) why "wider isn't always better" as you put it.
What, a complete nutjob?
I think it's probably the hookers and
coke "bath salts*" lifestyle that people aspire to ...
* I dunno. Maybe the hip people are doing "alloy wheel cleaner" these days.
even Executives should be able to figure this out now!
I don't know. The problem with idiots, as someone once said, is that they're so damned ingenious. I'm sure they'll find some way to stick the thing in the wrong way!
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.