... those technically literate children haven't heard of proxying ...
Sounds like a business opportunity for someone. I might set up my own "lolicon" server. Short for "LOL Internet Condenser", don't you know ...
1403 posts • joined 8 Nov 2007
... those technically literate children haven't heard of proxying ...
Sounds like a business opportunity for someone. I might set up my own "lolicon" server. Short for "LOL Internet Condenser", don't you know ...
that pornography leads to sex, and sex is bad.
Wait, what? I don't even think that the first part holds water. Run that argument by me again, please?
I think it is missing.
... unless he tells you that he shined something, of course ... like maybe a jeweller or window cleaner?
shoot at a drone or a normal aircraft.
No, Dougal, let's go through this one more time: those are small (pointing at drone, obviously), and those are very far away (you should be able figure which I'm pointing at now, hopefully).
Agreed... sub head could have been improved on ... he's got 100 problems (now the bits are one)
Hmm... any news on whether that will be coming out in pink? You know---"for her."
Microsoft have to choose between Surface RT becoming a cheap Linux box without Office or landfill RT.
Well the first is not going to happen. MS was never going to let you install another OS on this thing. Just why they thought selling a locked-down ARM tablet with no software ecosystem to speak of (having "Office" hardly counts, given the licensing terms and the fact that's it's restricted in other ways) was going to work is a mystery to me. Just who was it supposed to appeal to? Perhaps they made all those silly ads first and the various departments heads got carried away with how cool it seemed (to them) that they just had to go and build the damned thing.
There could have been a third option, and that would have been to announce a new cross-platform layer in Windows 8 and guarantee that all apps developed within the framework would work seamlessly across both ARM and x86 systems (and call it "Windows 8 Anywhere" or even use "Windows One" as an umbrella term to indicate the stuff will run on any of the MS/W8 platforms, including the new XBox) . Technically, the three main options for doing it would be (a) machine code translation like qemu (which the ARM/RT platform isn't up to doing well enough), (b) fat binaries that compile to both target platforms (like Apple did when it migrated between hardware platforms, twice), and (c) compile everything into a platform-agnostic bytecode that can be JIT-compiled into native code on the target platform at near-native speeds (eg, like Dalvik on Android). A consequence of this would have been no backwards compatibility on the RT platform, but if MS was really serious about it, they could totally have pushed everyone to adopt this "Windows One" (or whatever you want to call it) approach as part and parcel of taking the Windows 8 pill.
Unfortunately, as we can see from history (eg, .NET, Silverlight), even (or should that be "especially?") a behemoth like MS finds it very hard to do portability/interoperability. And anyway, even though it often pays lip service to these goals, in reality that's not what it wants. Rather, it wants to lock you in to its own proprietary solutions while spreading FUD about patents and whatnot to actively prevent interoperable implementations (which is why, for example, Mono on Linux is seen as such a bad idea for so many people). Besides the technical challenges, for this to be a success would require a large amount of bravery on the parts of the team tasked with developing Windows 8 all the way up to Ballmer. I simply think that there's no way they'd have to stomach to bet the farm so heavily on this sort of "Windows One" concept and risk making Windows 8 even more hated than it already is. The evidence for that is there: just look at the split personality that the Windows 8 desktop has as the prime example.
So I think I'll have to agree that landfill is probably the most likely final destination for most of these machines. In a few years time, my guess is that the App store will go away as the machine is quietly end-of-lifed so RT won't even be much use as a museum piece.
if the guy isn't into gadgets then power tools may well be the way to go
I found myself wondering about the blurry line between gadgets and real tools. For example, how should you feel if your gift was a set of three miniature chainsaws ... and a juggling instruction DVD?
If it's 58 metres in width, then how does it fit into a 10m2 area? Is it managing to fold space and time, Tardis-like?
And as to Leonardo, chances are he'd be looking up from below: his craft never stood a chance of taking off. But still, he would no doubt be chuffed.
re: sudo echo $'The Register on Pi-Lite' > /dev/ttyAMA0 won't work
For those that don't know, when you mix redirection with sudo, it's your (non-root) shell that tries to do the redirection (>) part and if you don't have write access to the target the whole command will fail.
You need to use this idiom instead:
echo 'something' | sudo tee target
Rewrite the original line and if becomes:
echo $'The Register on Pi-Lite' | sudo tee /dev/ttyAMA0
Also, I'm not sure what that $ is doing in that line. Typo?
And mentioning "climate" puts you on another watch list. Oops. Now I'm on it :(
Eh, that's the one they way to keep higher. The bit in ellipsis (cost/performance/watt) is, as you say, something they want to keep lower. So minimise Watt/GFlops and €$£/GFlop/Watt.
Personally, I'd love to see some of this stuff making its way out of the data centre and becoming something that someone could buy as a desktop/workstation replacement. The low-end ARM-based systems (Pi, ODROID and so on) are all severely lacking when it comes to I/O bandwidth and interconnection options. I'd love to see more of this on-die high-speed networking stuff make it into consumer products, preferably with similar buses/interconnects for accessing GPUs using something standard like OpenCL. I know that's unrealistic given that the desktop market is tanking and nobody wants to risk ARM in that kind of system right now, but if such personal mini clusters of ARM machines were available, I'd jump ship from x86-based systems in a heartbeat. I guess there's always Parallella, but it remains to be seen when that will become readily available, how easy it will be to program for, how much software support there will be for it and so on.
As I said, it's all a bit of a dream scenario, but at least it's good to see the ARM platform developing into something that you can do some serious processing on. Give it a few years and I reckon I might just get my wish.
You can also can try to effect a change, though it mightn't have the effect you wanted. If it doesn't work, you might affect an air of not caring. Of course, some might say that being on Facebook is all about affect[ation] anyway.
or is it Cadavero?
It's pronounced FRONKENSTEEN!
I think you miss my point. If I have to fiddle with a plastic cover every time I want to charge the thing, then being waterproof is just an annoyance rather than a benefit to me. Also, how easy is it going to be to break or lose the cover over the lifetime of the device?
The review didn't mention if it has this, so I assume not. A pity really, since without it I imagine that fiddling around with the port cover would get annoying pretty quickly. Waterproof may be nice for some, but messing around with port covers could turn this into a negative for many others.
I'm not sure exactly what you're trying to point out as being wrong, apart from what I said about rewriting full pages. To be honest, as I started to write I had a different idea about what the article's author was asking us, and by the end of it I figured he was asking about something slightly different, which I answered with my last paragraph of "gibberish".
The essential idea I was trying to get across at the start was that with flash-based systems you need different strategies for updating data on disk than with traditional block-based storage. You can't just update a structure like a B-Tree or a directory entry in situ because of the penalty that flash memory as a medium imposes on you. I don't disagree with what you say that we don't use a naive approach for updating a single block in this case---you're totally right to say that instead we group updates and write them all in a single page. But this has implications for filesystem integrity. If you can't mark the original data as obsolete and you can't just erase that whole page, then how do you (a) know which copy is the correct one, and (b) how do you handle problems like loss of power while writing the update? That's why I mentioned timestamps and periodic compaction. That's all I can really say on that because I'm not really sure where I went wrong in explaining it.
Maybe it's the last two paragraphs, but the last one paragraph is, I think, the key point I was trying to make. Up to that I was trying to explain the problems with error recovery at the flash level (which implements its own log-structured storage system at the firmware level, as you say), but what I think this Kaminario system is describing is more like Fawn-KV[pdf] and SILT. [abstract]. Those approaches use relatively large in-memory indexes to find data values on flash, and store all the data (including indexes) in a log-structured storage system on flash. FAWN-KV, in particular, looks a lot like the diagram, which shows each block spread across multiple nodes. The way this is usually done (and is done in FAWN-KV) is to use consistent hashing to spread the data across several nodes/silos. FAWN-KV also includes replication, so that a single hash key is stored to more than one node/silo. That's the essential point I was trying to make regarding node failure and recovery from it: FAWN-KV can recover from this quickly in the short term because an alternate node/silo is there to provide a backup copy of the data, although repartitioning the hash scheme (with associated costs of moving the actual data across nodes) will be necessary in the longer term if a node is really dead.
The SILT paper has a section on extending their scheme to include crash tolerance/crash recovery, which, again, I think is what our author here was really trying to get his head around.
We can't see why this has anything to do with sustaining a level of performance during a system failure, but maybe Reg readers can.
Have a look at the wikipedia page for "write amplification" to get an idea what the problem with traditional uses of flash storage is. In a nutshell, writers and updaters of the memory tend to treat it as a normal random-access memory. However, since flash needs to be updated many blocks at a time (in a unit called a "page", I think they call them), if you've just changed one block, then you need to read in all the other blocks in that page, update it and write it back out to a fresh place on the disk. If the power fails in the middle of all of this then it can be tricky to figure out exactly which blocks are now good. Worse, since the R/W pattern tends to be random, other files can be sharing the same page, so any corruption will not necessarily be limited to just the file (or chunk of a database table, etc.) that was being updated at the time.
With log-structured databases, you just imagine the whole disk to be like a circular list. In the simplest case, you just push stuff on the end of it and if there's a power failure, you just rescan the whole list from start to finish and delete any uncommitted writes. Of course, it's more complicated than that since O(n) traversal just to find some bit of info on the disk isn't practical, so most log-structured dbs will have some sort of compaction and indexing threads going in the background. Also, updates are generally timestamped so that later writes in the list override previous values. They'll also generally keep as much of the indexes in RAM as possible so that (notwithstanding initial delay when reading this in from the flash at startup) it's efficient to find the data you're looking for (and writes/updates generally simply involve writing to the head of the circular list, so it's O(1)).
A quick search for log-structured databases and file systems throws up examples such as Log-Structured Merge Tree (LSM-Tree), Riak's Bitcask, Logbase, Fawn-KV and SILT (Single Index, Large Table, IIRC). Any of the technical papers describing those will most likely explain why log-structured is the way to go with flash-based storage. Maybe my explanation above is enough, though... but definitely read the wiki page on write amplification and things should make a lot more sense.
Oh, just one other point... your actual question was to do with performance after a failure. Chances are they use something like Fawn-KV or SILT: some redundancy is built in, so that there will be backup "silos" for storing the data (much like RAID replication). Using a Distributed Hash (DHT) lets all the silos effectively share a common key space, and if one of them goes down, then collectively they can switch over to the alternates, while in the background they'll repartition the DHT space to account for genuine hardware failures (as opposed to transient errors). You'd have to delve into some of the papers of the above systems and (if they exist) the ones describing kaminario's implementation in particular, but I'd guess that's what they're doing and what they're talking about "sustaining performance during system failure".
I wish this whole patent litigation thing was something more like it's portrayed in Spiral (Engrenages) from the telly (BBC). I'd love to see what would happen if a case like this landed on Judge Roban's desk. All this litigation definitely waxes vexatious.
Sending him to prison for 20 years is only dealing with the symptoms of rampant drug abuse in the US. It solves nothing, and in fact often ends up making things much worse. Drug addiction and the war on drugs is a closed, vicious cycle. Until society starts dealing with with the causes and start implementing proper political, educational and treatment policies, there's really no light at the end of this tunnel.
I don't know if your calling for a 20-year sentence is because of some fucked-up absolutist sense of morality or because you're some sort of sadist who enjoys piling suffering on top of suffering. The two are probably not mutually exclusive. I do know that for as long as the current system continues in the same stupid, vicious cycle, we'll always have people like you offering up these gems of "wisdom".
Wait. Why the downvote? We are talking about hackers, right?
... and will be handed his prize by Britain's ambassador in the US.
Excellent, once he's inside the embassy, we can nab him, bag him and ship him off to a secret detention centre. Oh wait... Britain's ambassador. Sorry, never mind (I think).
Well, you have to consider that gravity doesn't just get cancelled out just because you're under water. Don't forget that you need to add up the total weight of the atmosphere *and* the liquid water above you. Some forms of life on Earth can tolerate extremes of pressure, but who knows if life could actually have started under such conditions.
Also, to be totally pedantic, just saying the planet is 10 times more massive isn't the whole picture. We also need to know what the planet's radius is. If it's large enough, the surface might have a tolerable gravitational force.
I already read this article in my crystal ball yesterday.
Careful with that crystal ball! Allow me to dredge up to a link to an old Reg article: Crystal ball torches woman's flat . As the sub-head there was "didn't see that coming", and to answer a previous commenter here, no, "That one never gets old".
He (as a self confessed fake) beat the two "genuine" psychics.
Reminds me of the story from quite a few years ago that pitted Microsoft's technical helpline against some "psychic" hotline for fixing some Windows-related problems. The result was that they were both (surprisingly) relatively on a par with each other in their ability to fix the problems.
The point? I guess that anecdotal evidence is fun, but of little use otherwise.
I already invented one of these years ago, though I never built a prototype. It's a pretty obvious design, though, and I'm sure it's been "invented" many times before.
To be honest, laziness played a large part in my not building the thing, although lack of experience in electronics was also a large factor. I'd wanted to incorporate two features that, after a bit of thinking, it was clear that I'd have to learn a non-trivial amount of electronic circuit design (and source the necessary components) to implement, so I never went any further than the imagining stage.
First, I wanted to use a standard radio controller, but I wanted the ball to have a network of receivers (at least 4 arranged in a tetrahedron, but an inscribed cube, other platonic solids or buckyballs would work too). My thinking was that as each of the (directional) antennae would be at a different orientation to the incoming radio signal, each of them would be receiving the signal at a different strength, so it should be possible to triangulate, roughly, where the RC signal was coming from. The point of this was so that if I pushed the RC stick towards the ball, it would travel away from me, and vice-versa. All motion would basically be relative to a line between the centres of the controller and the ball. That seemed to make most sense in the absence of some kind of external positioning system (like GPS, but finer-grained). It would mean you'd have to know roughly where the ball is in relation to your position if you want to steer it meaningfully, though.
The other tricky bit would have been coordinating the movement of the weights within the ball. It's (fairly) trivial to shift the weights(*) in the right sequence if you want the thing to move in a distinct set of "steps" (with it settling down to a new centre of gravity before applying the next movement), but if you want it to act more like a ball and move smoothly you need to factor in all the moments of inertia in three dimensions as well as the characteristics of the motors that move your weights in and out relative to the centre of the ball (how fast and how accurately they can move, where they are at any given moment, and even the lag between sending the movement command and being able to act on it). If you want variable speed control you need to be able to measure the current moments of inertia (using accelerometers that weren't that cheap or readily available at the time) and adjust how far you shift the weights when you're already going fast (like an ice skater can move their arms in and out to adjust speed when spinning). Mathematically, it's fairly complicated, but doable. Unfortunately, as I said, I lacked the skill in electronics to be able to translate the maths into a proper control circuit. The various feedbacks among inertial sensors, current and projected centre of gravity and the sensor array used to triangulate where the user is makes it all very complicated, particularly if the thing is moving at high speed. Depending on the size of the ball, you might have gone through a significant fraction of complete revolution by the time the circuit has figured out what it should do next, by which time that calculation is completely wrong for the current state. Quality, high-speed sensors is a big part in overcoming that problem, but at the time I didn't have access to them. Nowadays, I guess a mobile phone has most of the sensors needed for this kind of thing though it still needs something better than GPS for telemetry.
So, anyway, I've got to tip my hat to these guys. I'm not sure how they've implemented their telemetry or whether they've cracked the problem of controlling the ball at high speeds, but it's really nice to see that someone has had a proper go at implementing this kind of thing.
*a note on weights: another alternative form of locomotion would be to have various pistons spread around the surface of the sphere. By pushing them out and retracting them in the right order (and with the right amount of force) it should be quite easy to get the thing to move quite quickly. It does sound like a fairly industrial-level implementation, though, since you'd need more pistons than you would internal weights. There's also the problem of legs breaking off or getting stuck on/in things that doesn't happen if the ball is self-contained and only contains weights and motors. On the plus side, if you have pressure (weight) sensors on the ends of the legs, that's a pretty useful sensor to have for detecting not only which side is up, but also for collision detection.
The other form of locomotion that I considered, and I'm quite proud of, is to use two-way memory metal to construct the shell of the bot. The idea is that in one state each of the wires forms a strut of a platonic solid (eg, a dodecahedron), while in the other state the overall shape of the ball is deformed at the bottom and it tips over onto the next face. By alternatively lengthening and shortening struts in the right order, it should be possible to get it to roll in whatever direction we want. The beauty of this sort of bot (provided it could actually be built, and I haven't overlooked some crucial problem) is that the shell (and a few sensors, power sources and other electronics distributed evenly around the shell) essentially is the robot. Taken to the extreme, it should also potentially be possible to use the memory metal itself as the communications network medium so there'd be no unsightly wires or internal circuits even visible. If someone wanted to try this, they could build it as a set of nodes (vertices) containing the processing parts and then the user could build it simply by training the metal struts and building up the dodecahedron out of nodes and memory metal struts. That's one variation of this idea that I would really love to see someone implement!
Donuts---is there anything they can't do?
Wow... chill. Nobody's saying that entanglement allows instantaneous information transfer. The way this works is (roughly) that we send some photons using a recorded polarisation, the receiver sets up some polarising filters at random and then both parties communicate the results using standard (non-FTL) communication channels. The quantum magic happens because an eavesdropper can't know both the initial polarisation and the polarisation setting at the detector and any attempt to "copy" the photon in flight has at least a 50/50 chance of getting the polarisation wrong (assuming only two polarisation settings), thus alerting Alice and Bob to Eve's presence.
The whole system (from emitter to detector) is the quantum entanglement "experiment", so it's easy to see how an eavesdropper will prematurely collapse the probability waveform, ruining the values that Bob sees. But again, even though in normal operation, without an eavesdropper, the collapse is instantaneous with the measurement at the detector end, Alice and Bob still need to communicate their results before they actually know what that measurement means, so there's no FTL information transfer... so it's actually not Hokum.
Ah, but that's no mere cat you have there!
That massive amount of current needed to shift an elevator car ends up producing immense amounts of heat
Well if there's that much hot air, why not tether a hot air balloon to the lift and use that to lift the cargo? You'd have to have the balloon "outside the box" (ie the building) which would definitely lead to challenges on windy days, but at least you might be able to use other waste heat from the building to keep it topped up. Sounds much nicer if you take the gondola to the 50th floor instead of a regular old "lift".
spice the flavour up with some fried bacon, and sausages, and ...
then hold the soylent, cos you've already got your meal right there.
Cue Kodos and Kang: "It's true, we are aliens. But what are you going to do about it? It's a two-party system. You have to vote for one of us."
According to the bar graph in the second picture, Microsoft's Windows Phone users are more satisfied with their thingies than Android users.
MICROSOFT FAIL FAIL.
Hmm... If he still wanted to stay in the US, he could always aim for Cicely, AK.
It really all boils down to what the definition of gore is.
Let's not go there. We'll only end up debating manbearpig if we do. (*wink wink*, *nudge nudge*)
You can get Graffiti on Android. It does predictive text.
It's called steganography. Nothing to see here, move along now.
I haven't read the paper, but I don't think it's stego. According to the article, such inputs are used to trigger an existing infection rather than being used as a carrier for code or new information beyond the "trigger me now" signal. In this case, it's probably just another example of the use of "oblivious agents": an "agent" continuously monitors whatever sensor data it has available, produces a hash of some kind and if the hash matches a trigger condition, it activates. The "oblivious" part is that the agent doesn't "know" in advance (and examining the code won't reveal) what specific combination of inputs are needed for it to activate which function.
To prove it's fusion you need to see what is in the box.
Not necessarily. If you seal the apparatus up and you have a really accurate scales (or a long enough time scale) to measure the mass of the thing, you should see a gradual reduction in mass. That would probably be enough to prove there's fusion going on. Or fission, but we have to take it at their word that there aren't any fissile materials in the box providing the extra energy output.
at Apple trying to patent "bounce-back" in user interfaces ("on a mobile device")?
Simply feed the maggots that infest sheep to the livestock themselves.
(anyone who's dipped sheep will probably know where I'm coming from)
Just use Beethoven's First Movement.
Ah, yes... his little-known "Meconium".
There's a phrase in Japanese (see title) that literally means "word-processor idiot". It refers to a problem that people are becoming less and less proficient at actually writing Kanji. The way this works on computer, people type in the words phonetically and then it gives them a choice of possible kanji. So while you still need to be able to recognise what the correct kanji is/are, it's actually deleterious to your ability to write those kanji from memory.
Although it's not as extreme a problem in English, I think this push to downgrade the importance of (hand-)written language in favour of typing things on a computer does have similar consequences. It's not exactly that handwriting itself is that big a deal, but I think that things like auto-completion and automatic spell-checking tend to make people lazy when it comes to learning how to spell things correctly and how to distinguish between homonyms like "their" and "they're". A spell-checker alone can't help you learn these things, and most grammar checkers aren't really up to snuff.
Den dares de problum wiv ppl using "is a computa" as an excuse not to even bovver wid writing "propurly"...
Maybe this guy's argument is more nuanced than I'm giving him credit for, but overall I'd have to say I'm against it. I'm all for increasing tech literacy, but if the price is to sacrifice literacy in general, it's not worth it.