I don't know, maybe I'm just weird myself but I don't think Javascript's scope rules are that hard to grasp...
Oh, they're not. They're just not what the syntax suggests they ought to be. Every other braces-and-blocks language on the planet uses block scope, so anyone who's been brought up on C, C++ or Java and sees code like this:
if (b) { var i = 1; fnord(i); }
...will naturally assume that i is local to the block. It's not something that they think about, it's pure hindbrain reflex. I've been bitten by this loads of times. The only way I can write serviceable Javascript is to keep double-checking everything I've done to make sure I haven't done stuff like this.
I think that Javascript is a perfectly serviceable if unexciting language --- modulo the gross insanities like the behaviour of this, inability to manipulate object prototypes, no way to hash objects, the whole business behind constructors, etc --- but it's really, badly let down by the syntax, which promises all sorts of stuff that it fails to deliver on. Block scopes, arrays (a[1] = 2 doesn't do what it looks like it does!), the fact that multiple variable declarations in the same scope aren't flagged... and semicolon insertion, shudder. It'd be so much better if it just looked different. Hence CoffeeScript, I suppose, but that's got a whole bunch of issues of its own.
I live in the UK, and have done all my life, and the only time I use non-metric units is when on the road --- speed limit signs and the numbers on my speedometer. Even the satnav's set to kilometres.
It's always a huge relief when I go to another country and find myself driving in kilometres, and I really wish we'd finally do the switch.
I've been (very slowly) doing something a bit similar with the moon --- see here --- although differently; I've been trying to render everything and producing ground-level views rather than producing a painted sphere like TFA. (His looks better from a distance. Mine looks better close up.) I've been trying to use procedural texturing and atmospheric effects. The pictures above are rather out of date; rendering your own from SVN will look better.
Unfortunately rendering things the size of planets from very close up runs into big problems with floating point precision. The only renderer I've found which will do it at all is Povray, and even then there are loads of bugs --- volumetric effects for things like clouds is well buggered at this sort of scale. See this picture for an example. Plus Povray's is really slow at procedural surfaces.
Right now I really need to start again from scratch using higher-resolution terrain and gravity data from some of the recent lunar probes, and I also probably want to switch to a different renderer which works at higher precision. Any suggestions of a fast raytracer that does procedural isosurfaces, volumetric effects and works at double precision will be gratefully appreciated...
I will also share this test render with you, which I think is delightfully surreal...
Most operating systems these days don't run device driver interrupt handling code directly in the interrupt handler --- it's considered bad practice, as not only do you not know what state the OS is in (because it's just been interrupted!), which means you have an incredibly limited set of functionality available to you, but also while the interrupt handler's running some, if not all, of your interrupts are disabled.
So instead what happens is that you get out of the interrupt handler as quickly as possible and delegate the actual work to a lightweight thread of some description. This will usually run in user mode, although it's part of the kernel and still not considered a user process. This thread is then allowed to do things like wait on mutexes, allocate memory, etc. The exact details all vary according to operating system, of course.
This means that you nearly always have an extra couple of context switches anyway. The extra overhead in a well designed microkernel is negligible. Note that most microkernels are not well designed.
L4 is well designed. It is frigging awesome. One of its key design goals was to reduce context switch time --- we're talking 1/30th the speed of Linux here. I've seen reports that Linux running on top of L4 is actually faster than Linux running on bare metal! L4 is a totally different beast to microkernels like Mach or Minix, and a lot of microkernel folklore simply doesn't apply to L4.
L4 is ubiquitous on the mobile phone world; most featurephones have it, and at least some smartphones have it (e.g. the radio processor on the G1 runs an L4-based operating system). But they're mostly using it because it's small (the kernel is ~32kB), and because it provides excellent task and memory management abstraction. A common setup for featurephones is to run the UI stack in one task, the real-time radio stack in another task, with the UI stack's code dynamically paged from a cheap compressed NAND flash setup --- L4 can do this pretty much trivially.
This is particularly exciting because it looks like the first genuinely practical L4-based desktop operating system around. There have been research OSes using this kind of security architecture for decades, but this is the first one I've seen that actually looks useful. If you haven't watched the LiveCD demo video, do so --- and bear in mind that this is from a couple of years ago. It looks like they're approaching the holy grail of desktop operating systems which, is to be able to run any arbitrary untrusted machine code safely. (And bear in mind that Genode can be run on top of Linux as well as on bare metal. I don't know if you still get the security features without L4 in the background, though.)
This is, basically, the most interesting operating system development I have seen in years.
Are you using the rootbeer Java->GPU compiler, by any chance? If not, how are/i> you doing it? (I'm interested in running JVM languages on a GPU myself.)
Ah, I didn't gather you just wanted the standard functionality. Even so --- can you use the tablet as a remote without having a console? If it's just a dumb terminal it may require the console running to do anything.
I'd wait until there's more information about the protocols involved. It's almost certain that the video being displayed on the tablet is being broadcast via radio from the console --- which means it's entirely feasible that the tablet is dumb as rocks and isn't programmable; and that all the logic is actually happening on the console.
If that were the case, the only way you'd be able to repurpose the tablet would be to clone the no-doubt proprietary radio link that the console used, which is probably going to be hard.
In any event I expect the first reverse-engineering reports to come out approximately thirty seconds after this thing ships in the US, so it's not as if we'd have to wait very long.
(Clue allows C to be compiled, badly, into a variety of scripting languages including Lua, Javascript and Perl as well as Java. Some nutter even contributed a Common Lisp backend. It was an experiment to see whether exploiting certain vaguenesses in the ANSI C spec concerning pointer representation was useful. Unlike Enscripten, Clue doesn't have a big array of bytes representing the C memory; instead pointers are represented as object-offset tuples. It worked really well, but unfortunately nearly all existing code out there doesn't work right on a system where sizeof(int)==sizeof(double)==sizeof(char)==1 and sizeof(void*)==2. Plus, the compiler frontend I was using had a number of major issues. But it works well enough to run benchmarks.)
(And before you ask, yes, compiling C into Perl 5 is a total, utter, complete waste of time.)
You're underestimating the amount of innuendo a skilled operator can extract from a slide rule. They are, after all, far more phallic than your average calculator.
Just don't try it with one of those newfangled circular slide rules.
But calling in when it's going on: first off, they have to deal with the increase in bandwidth, the abuse of the server, virtual service, or multi-hosted box you occupy and hence affects on other customers, getting someone or a team of someones involved to start the mitigation process and move your incoming traffic to the systems which perform this protection, amongst other issues.
Yes, but they're going to have to do this anyway. The DDoS won't affect just one customer, it'll affect lots of people at Rackspace, and will cost Rackspace money. Whether this one customer pays Rackspace or not won't make any difference to Rackspace's costs.
That's what makes Rackspace's behaviour here so dubious. Your example of it being like car insurance after the accident is invalid. It's more like a car accident that blocks the road. (Yes, yes, a car analogy on Slashdot, just deal with it, okay?) Whether you pay emergency services to move your car is irrelevant, because they either way they're still going to move it... because otherwise the road is blocked.
What makes you think they're going to keep their word? You're not signing a contract here, these are criminals! All you're doing is showing you're a soft touch. They'll be back, and they'll demand more money. They'll probably tell their friends, too. Not to mention the moral aspect that by giving in to these people you are directly funding crime.
No, you ignore them entirely. Don't even reply to the emails (but keep them safe). If they DDoS you, live with it. Remember that these guys rent their botnet from other criminals, so every second they're DDoSing you is costing them money. As soon as they realise that they're not going to get anything out of you they'll give up and move on to the next target. Yes, you'll probably be knocked offline for a while but (a) with a bit of marketing nous you can make this work for you, by issuing thundering press releases going on about not giving in the terrorist demands, issuing 'apologies' to your customers and giving them discounts to make up for it so driving sales, etc --- basically, free PR, make the most of it; and (b) your internet-facing servers should be coping anyway. Of course, given that they aren't, that last doesn't help right now. But beef them up because it'll help next time.
Rackspace's behaviour is contemptible, though. I'd suggest looking for a different provider.
After looking at those pictures, all I can say is: eeeeee. 128kB RAM maximum and a 16-bit processor? And they were trying to do real work on it? In 1998? What were they thinking? Even in those days, you trivially could do an indistinguishable emulation in software on a low-end PC...
I remember hearing from one of the last real engineers at SCO. He said that one day he arrived at work and realised that he was the only person in the entire building who wasn't wearing a suit. It was then, he said, that he knew that SCO was dead.
A while back I was working on site with a customer... a major featurephone manufacturer, who will remain nameless so as to protect the incompetent. We discovered that the phone would crash if our software ran the CPU flat-out, even if it was at a lower priority thread than anything else.
It turns out that the sorry excuse for an operating system this thing ran was doing system-critical tasks in the idle thread, so if the CPU didn't idle some message queues would overflow and the OS would reboot. When I asked if there was a way around this, the response was that it was deliberate because the hardware would overheat if the CPU ran continuously for more than about thirty seconds at a time.
(This OS, BTW, was such an epic failure that when it was cancelled the entire staff went with it... and so did the building.)
...I'm particularly thinking of White Light here, in which our hero travels, literally, to infinity and beyond. And it is just as screwed up and hallucinogenic as you might imagine.
I can't get over how fast that client is... after sitting through broadcast Teletext and waiting for pages to cycle round, it's interesting to see how much more usable the system becomes when it's responsive. Those 40x24ish pages actually contain a reasonable amount of text to take in at one glance. (Although of course I can't actually read the Dutch version.) I think people are right, and the brevity required by the small pages is actually an advantage.
(When I was small we had one of those modern Fasttext sets, with 4kB of memory. This allowed it to cache three pages in addition to the one the user was looking at. It would load the ones referred to by the coloured buttons. This made it vastly easier to navigate... although those damned cycling pages were as annoying as ever.)
Before you go congratulating them on a great job, remember this is the second time they did this. The original attempt was called Robust File System. It was an abortion based on FAT16/32 with a duplicated file allocation table and some sort of journalling hacked on top.
*twitches*
Damn you, thegarbz! Damn you to heck! I had nearly managed to forget about RFS today before you reminded me. Now I'm going to have to attempt to wipe my memory with methylated spirits and Friends reruns. Again.
...I have it on dubiously reliable authority that the utter disaster that was RFS was one of the reasons why Google clamped down so hard on what modifications vendors could make to Android and still get the official Google apps. Which is why most modern Android devices are all so similar.
Slashdot Mirror
Oh, they're not. They're just not what the syntax suggests they ought to be. Every other braces-and-blocks language on the planet uses block scope, so anyone who's been brought up on C, C++ or Java and sees code like this:
if (b) { var i = 1; fnord(i); }
...will naturally assume that i is local to the block. It's not something that they think about, it's pure hindbrain reflex. I've been bitten by this loads of times. The only way I can write serviceable Javascript is to keep double-checking everything I've done to make sure I haven't done stuff like this.
I think that Javascript is a perfectly serviceable if unexciting language --- modulo the gross insanities like the behaviour of this, inability to manipulate object prototypes, no way to hash objects, the whole business behind constructors, etc --- but it's really, badly let down by the syntax, which promises all sorts of stuff that it fails to deliver on. Block scopes, arrays (a[1] = 2 doesn't do what it looks like it does!), the fact that multiple variable declarations in the same scope aren't flagged... and semicolon insertion, shudder. It'd be so much better if it just looked different. Hence CoffeeScript, I suppose, but that's got a whole bunch of issues of its own.
I live in the UK, and have done all my life, and the only time I use non-metric units is when on the road --- speed limit signs and the numbers on my speedometer. Even the satnav's set to kilometres.
It's always a huge relief when I go to another country and find myself driving in kilometres, and I really wish we'd finally do the switch.
Yes, but if it's commercial I can't hack it, which it's basically just not interesting to me. Sorry.
Terragen is commercial, unfortunately.
I've been (very slowly) doing something a bit similar with the moon --- see here --- although differently; I've been trying to render everything and producing ground-level views rather than producing a painted sphere like TFA. (His looks better from a distance. Mine looks better close up.) I've been trying to use procedural texturing and atmospheric effects. The pictures above are rather out of date; rendering your own from SVN will look better.
Unfortunately rendering things the size of planets from very close up runs into big problems with floating point precision. The only renderer I've found which will do it at all is Povray, and even then there are loads of bugs --- volumetric effects for things like clouds is well buggered at this sort of scale. See this picture for an example. Plus Povray's is really slow at procedural surfaces.
Right now I really need to start again from scratch using higher-resolution terrain and gravity data from some of the recent lunar probes, and I also probably want to switch to a different renderer which works at higher precision. Any suggestions of a fast raytracer that does procedural isosurfaces, volumetric effects and works at double precision will be gratefully appreciated...
I will also share this test render with you, which I think is delightfully surreal...
sea levels to rise almost a meter more than present over the next century ... hardly a doomsday scenario
I believe you don't realise quite how many people live within a vertical metre of sea level.
I have some of his science fiction novels. They are truly, truly awful. Highly recommended.
Most operating systems these days don't run device driver interrupt handling code directly in the interrupt handler --- it's considered bad practice, as not only do you not know what state the OS is in (because it's just been interrupted!), which means you have an incredibly limited set of functionality available to you, but also while the interrupt handler's running some, if not all, of your interrupts are disabled.
So instead what happens is that you get out of the interrupt handler as quickly as possible and delegate the actual work to a lightweight thread of some description. This will usually run in user mode, although it's part of the kernel and still not considered a user process. This thread is then allowed to do things like wait on mutexes, allocate memory, etc. The exact details all vary according to operating system, of course.
This means that you nearly always have an extra couple of context switches anyway. The extra overhead in a well designed microkernel is negligible. Note that most microkernels are not well designed.
L4 is well designed. It is frigging awesome. One of its key design goals was to reduce context switch time --- we're talking 1/30th the speed of Linux here. I've seen reports that Linux running on top of L4 is actually faster than Linux running on bare metal! L4 is a totally different beast to microkernels like Mach or Minix, and a lot of microkernel folklore simply doesn't apply to L4.
L4 is ubiquitous on the mobile phone world; most featurephones have it, and at least some smartphones have it (e.g. the radio processor on the G1 runs an L4-based operating system). But they're mostly using it because it's small (the kernel is ~32kB), and because it provides excellent task and memory management abstraction. A common setup for featurephones is to run the UI stack in one task, the real-time radio stack in another task, with the UI stack's code dynamically paged from a cheap compressed NAND flash setup --- L4 can do this pretty much trivially.
This is particularly exciting because it looks like the first genuinely practical L4-based desktop operating system around. There have been research OSes using this kind of security architecture for decades, but this is the first one I've seen that actually looks useful. If you haven't watched the LiveCD demo video, do so --- and bear in mind that this is from a couple of years ago. It looks like they're approaching the holy grail of desktop operating systems which, is to be able to run any arbitrary untrusted machine code safely. (And bear in mind that Genode can be run on top of Linux as well as on bare metal. I don't know if you still get the security features without L4 in the background, though.)
This is, basically, the most interesting operating system development I have seen in years.
Are you using the rootbeer Java->GPU compiler, by any chance? If not, how are/i> you doing it? (I'm interested in running JVM languages on a GPU myself.)
I don't think I have ever seen an ARM processor in a socket (discounting my old Archimedes, that is).
Ah, I didn't gather you just wanted the standard functionality. Even so --- can you use the tablet as a remote without having a console? If it's just a dumb terminal it may require the console running to do anything.
I'd wait until there's more information about the protocols involved. It's almost certain that the video being displayed on the tablet is being broadcast via radio from the console --- which means it's entirely feasible that the tablet is dumb as rocks and isn't programmable; and that all the logic is actually happening on the console.
If that were the case, the only way you'd be able to repurpose the tablet would be to clone the no-doubt proprietary radio link that the console used, which is probably going to be hard.
In any event I expect the first reverse-engineering reports to come out approximately thirty seconds after this thing ships in the US, so it's not as if we'd have to wait very long.
Anyone can compile C into Javascript. Only I can compile C into... Perl.
See cluecc.
(Clue allows C to be compiled, badly, into a variety of scripting languages including Lua, Javascript and Perl as well as Java. Some nutter even contributed a Common Lisp backend. It was an experiment to see whether exploiting certain vaguenesses in the ANSI C spec concerning pointer representation was useful. Unlike Enscripten, Clue doesn't have a big array of bytes representing the C memory; instead pointers are represented as object-offset tuples. It worked really well, but unfortunately nearly all existing code out there doesn't work right on a system where sizeof(int)==sizeof(double)==sizeof(char)==1 and sizeof(void*)==2. Plus, the compiler frontend I was using had a number of major issues. But it works well enough to run benchmarks.)
(And before you ask, yes, compiling C into Perl 5 is a total, utter, complete waste of time.)
You're underestimating the amount of innuendo a skilled operator can extract from a slide rule. They are, after all, far more phallic than your average calculator.
Just don't try it with one of those newfangled circular slide rules.
If I were to ask what 'the age of the quantified self' means, would I regret it?
But calling in when it's going on: first off, they have to deal with the increase in bandwidth, the abuse of the server, virtual service, or multi-hosted box you occupy and hence affects on other customers, getting someone or a team of someones involved to start the mitigation process and move your incoming traffic to the systems which perform this protection, amongst other issues.
Yes, but they're going to have to do this anyway. The DDoS won't affect just one customer, it'll affect lots of people at Rackspace, and will cost Rackspace money. Whether this one customer pays Rackspace or not won't make any difference to Rackspace's costs.
That's what makes Rackspace's behaviour here so dubious. Your example of it being like car insurance after the accident is invalid. It's more like a car accident that blocks the road. (Yes, yes, a car analogy on Slashdot, just deal with it, okay?) Whether you pay emergency services to move your car is irrelevant, because they either way they're still going to move it... because otherwise the road is blocked.
What makes you think they're going to keep their word? You're not signing a contract here, these are criminals! All you're doing is showing you're a soft touch. They'll be back, and they'll demand more money. They'll probably tell their friends, too. Not to mention the moral aspect that by giving in to these people you are directly funding crime.
No, you ignore them entirely. Don't even reply to the emails (but keep them safe). If they DDoS you, live with it. Remember that these guys rent their botnet from other criminals, so every second they're DDoSing you is costing them money. As soon as they realise that they're not going to get anything out of you they'll give up and move on to the next target. Yes, you'll probably be knocked offline for a while but (a) with a bit of marketing nous you can make this work for you, by issuing thundering press releases going on about not giving in the terrorist demands, issuing 'apologies' to your customers and giving them discounts to make up for it so driving sales, etc --- basically, free PR, make the most of it; and (b) your internet-facing servers should be coping anyway. Of course, given that they aren't, that last doesn't help right now. But beef them up because it'll help next time.
Rackspace's behaviour is contemptible, though. I'd suggest looking for a different provider.
After looking at those pictures, all I can say is: eeeeee. 128kB RAM maximum and a 16-bit processor? And they were trying to do real work on it? In 1998? What were they thinking? Even in those days, you trivially could do an indistinguishable emulation in software on a low-end PC...
I remember hearing from one of the last real engineers at SCO. He said that one day he arrived at work and realised that he was the only person in the entire building who wasn't wearing a suit. It was then, he said, that he knew that SCO was dead.
A while back I was working on site with a customer... a major featurephone manufacturer, who will remain nameless so as to protect the incompetent. We discovered that the phone would crash if our software ran the CPU flat-out, even if it was at a lower priority thread than anything else.
It turns out that the sorry excuse for an operating system this thing ran was doing system-critical tasks in the idle thread, so if the CPU didn't idle some message queues would overflow and the OS would reboot. When I asked if there was a way around this, the response was that it was deliberate because the hardware would overheat if the CPU ran continuously for more than about thirty seconds at a time.
(This OS, BTW, was such an epic failure that when it was cancelled the entire staff went with it... and so did the building.)
One day I must try putting a chlorine water purification tablet into a can of Bud Light.
After all, it can't make it any worse, and there's a reasonable chance it might make it drinkable.
...I'm particularly thinking of White Light here, in which our hero travels, literally, to infinity and beyond. And it is just as screwed up and hallucinogenic as you might imagine.
I can't get over how fast that client is... after sitting through broadcast Teletext and waiting for pages to cycle round, it's interesting to see how much more usable the system becomes when it's responsive. Those 40x24ish pages actually contain a reasonable amount of text to take in at one glance. (Although of course I can't actually read the Dutch version.) I think people are right, and the brevity required by the small pages is actually an advantage.
(When I was small we had one of those modern Fasttext sets, with 4kB of memory. This allowed it to cache three pages in addition to the one the user was looking at. It would load the ones referred to by the coloured buttons. This made it vastly easier to navigate... although those damned cycling pages were as annoying as ever.)
They just choose not to use them. In an emergency, being thrown across the bridge is much safer than being strapped to one of those consoles.
*twitches*
Damn you, thegarbz! Damn you to heck! I had nearly managed to forget about RFS today before you reminded me. Now I'm going to have to attempt to wipe my memory with methylated spirits and Friends reruns. Again.
...I have it on dubiously reliable authority that the utter disaster that was RFS was one of the reasons why Google clamped down so hard on what modifications vendors could make to Android and still get the official Google apps. Which is why most modern Android devices are all so similar.