I would like Google to actually search for the terms I asked for, and not what it thinks I should be asking for --- I fight that bloody autocorrect feature daily. Search for any programming term and chances are you'll get a tiny message saying 'Searching for FOO instead (unless you really meant BAR)', and then irrelevant search results.
If you go look at their forums, they're full of complaints about this. Including people saying that their company name can't be found at all, because it gets autocorrected to something else if people try to search for it!
I understand why this feature's there, but please, please, provide a way to turn it off...
Yes, that is a neat trick --- the most obvious way I can think of of doing that is to do all the ssh processing on the client, and make the daemon a simply proxy; but a quick look at the source code shows you don't appear to be doing that. Or at least, I couldn't find it.
Unfortunately the platform I'd really like this to work on, my Kindle, doesn't support WebSockets (of any kind)...
I have, in fact, been vaguely thinking about trying to recompile a Java ssh client library under GWT and trying to make this work, but finding such a library that uses message-passing only and not threads is quite hard. Java likes threads.
You need a daemon to proxy between the WebSocket connection (which, remember, isn't a straight TCP stream) and the ssh server proper. Although it appears this doesn't need to be on the machine that the ssh server is running on, so it doesn't look like too much of a hardship. Also, I can't find any reference of which of the umpteen different WebSocket variants it supports.
There's actually a number of these things out already, such as ConsoleFish or ShellInABox. There's also an HTML5 VNC client, which looks very interesting.
This requires separate landing systems for each stage of the rocket. This is a lot more added mass. And the worst thing to add to a rocket is more mass. Simple reusable systems like parachutes (as were used by the shuttle's solid rocket boosters) are one thing, but full-out rocket powered landing will weigh a lot more, will require a lot of additional fuel, and will add all sorts of technical requirements.
Does it?
Don't forget, those Merlin engines are restartable (something NASA never went in for much). So the first two stages land on the engines they took off with. And now they're empty, so they're very light. The second stage needs an heat shield, but other than that the only extra mass you need are the landing gear, avionics and attitude control, and the fuel. And even some of the fuel comes for free too, as there's a hefty safety margin in both stages, which you can eat into when landing.
So yeah, you are going to need more mass to do this, which will eat into the payload, but not as much as you might think. If the cost advantages of being able to recycle the stages outweighs the decrease in payload, then it'll be worth it. (Which, of course, for the shuttle it wasn't.)
9. Built-in PDF reader --- no crappy plugins, it just works.
10. Does not have a panic attack when it sees a self-signed SSL certificate. This was what made me finally jump ship away from Firefox: I spend a lot of time browsing mailing list archives trying to dig up obscure information, and there's a common software package people use for this that prefers to use https via a self-signed certificate. Trying to read these via Firefox was horrible. Yes, I do want to be told when the certificate is invalid, but Firefox's behaviour is way over the top. Plus, it actively encourages the user to add the certificate to their trusted list (facepalm).
Surely you mean 3: the warm Earth-like world we're currently standing on (well, in my case, sitting), plus Mars, plus Venus. Both of which are pretty easy to get at using current technology. Some of the gas giant moons probably count too, but they're a special case as they're not in Sol's habitable zone.
Just because the planet's the right mass and about the right distance from its primary doesn't necessarily mean we'd find it habitable...
Been there, tried that --- this was on an old CATS ARM box. Turns out that there's a lot of ia32 code in ROM on the graphics card which, of course, ARMs and Alphas are totally unable to run.
The CATS box managed to at least initialise the card into text mode by running the graphics card ROM via the world's slowest ia32 emulator; the keyboard lights would flash for ten seconds on bootup and then you'd get the graphics card's POST message. I don't know what Alpha boxes do.
I have tried to make PCI graphics cards work on an embedded system that didn't have such an emulator, and discovered that xorg relies heavily on the BIOS having initialised the card to a sane state on startup. Without that initialisation you're pretty much out of luck (particularly since it's all undocumented). That said, if you're already using an ATI card on the Alpha then there must be some mechanism to make it work, so... good luck!
'Not kind' is an understatement. The RISC OS kernel is a really unpleasant pile of kludges.
A few years back I wrote an experimental RISC OS kernel workalike (obligatory link). In the process I found myself delving way too deeply into the core of how RISC OS worked and it's really not pretty. It's got such misfeatures as: a memory allocator that allows you to allocate small blocks of memory from inside interrupt handlers --- it does this by tracing the stack to try and figure out whether it's been called reentrantly; hardware-specific hacks built into what should be generic operating system modules (FileSwitch runs programs by fiddling with the supervisor-mode registers); no real device driver model; about half a microkernel to address the fact that there's no real driver model; global variables everywhere (pretty much everything expects to read a byte at 0x00000108 in order to test interrupt status); APIs which pass flag bits in the upper two bits of addresses; and hysterical raisins everywhere, such as having multiple concurrent system heaps. Plus of course, the whole thing is an unreadable mess of uncommented ARM machine code.
That said, it does all work, and some dedicated lunatics have RISC OS running on the BeagleBoard, so a Raspberry Pi port shouldn't be too hard. (Bear in mind that RISC OS is not open source, though; it's got a look-but-don't-touch shared source license.)
What most people think of when they talk about RISC OS is the GUI, which is a work of genius, although now very dated. (There's no keyboard accessibility, for example. Without a mouse you don't use it. This is something Microsoft got right from the very first, and the early versions of Windows were a joy to use with the keyboard.) I wish that modern systems were half as consistent and elegant as the RISC OS GUI. There have been a few attempts to recreate it with modern systems --- ROX Desktop, for example --- but they never got anywhere, alas...
RS232 would be more complex, and therefore more expensive, because it requires additional hardware (the level converter from TTL voltages to RS232 voltages). The world has moved on, I'm afraid, and high-speed USB connectivity really is the cheapest option...
Yes, Lisp's awesome, and has got all sorts of fascinating and powerful features such as continuations and hygienic macros, but the sad fact is that it's just not accessible. Any programmer with modern training is going to be familiar with Algol languages, specifically C family languages, and is going to take one look at the incomprehensible mass of free-form parentheses that's a Lisp program and simply won't be interested.
This is one of the reasons Javascript's so successful --- although I agree with the author that it's a terrible language. Someone with C or Java training can look at Javascript and read the structure; the learning curve is shallow enough to get people hooked. Guile's learning curve starts with a cliff. Why should someone looking for an extension language pick Guile when languages like Python or Lua are available that people already know?
(As a secondary note, the LGPL's not really a very friendly license for an extension language, as it makes it hard to embed in anything that's not GPLd. I realise that the FSF is doing this deliberately to try and encourage people to write GPL software, but it is a factor affecting Guile's popularity.)
I find myself a little perturbed by the fact that they're using code verification and sandboxing. If the sandboxing is solid --- which isn't actually that hard; any modern operating system already does this as a matter of course as part of the process model --- then the verification shouldn't be necessary.
So factory reset it and associate it with a different account. I do Android development and we do this as a matter of course to switch to different accounts. Am I missing something? What's the problem?
What does this mean? There has to be some sort of ignition system
Nope!
Diesel engines ignite the fuel/air mixture by compressing it. As the mixture is squeezed, the temperature rises, and if you squeeze it enough, it goes bang. No external ignition systems such as spark plugs are needed.
Old-fashioned diesel engines did not, in fact, have any electrical system other than the starter motor --- once they were running, you could disconnect the battery and it would continue running fine. In fact, they were pretty hard to stop, and there had to be a special mechanism to shut off the fuel safely otherwise it would keep running indefinitely. One nasty hack I've seen was to power a boat off an old truck engine. All the cooling was stripped off it, a propeller attached directly to the drive shaft, and it was slung off the back of the boat. After being started in the shop, the boat was put in the water, with the engine entirely submerged (except for the air intake, of course). It was fine.
On the minus side, the extra compression means they're really hard to turn over; you can't start an old-fashioned diesel with a crank. It's just too hard. (Of course, you can't start a modern petrol engine for the same reason.)
Note that modern turbo diesels are totally different beasts and are computerised beyond all belief, and are largely indistinguishable from petrol engines to drive.
By that, I mean that G+ is on the pages I use as a matter of course. It's easy to get to. I don't need to remember to go to some third party website and enter a different set of login details to go and get stuff. The notifications and controls are on the search page, the RSS reader page, all the standard Google tools I know and am familiar with. This reduces the barrier to entry --- and ease of use --- enormously.
There's a special term used for orbiting on land. It's called 'lithobraking'. I believe that Mars Climate Orbiter was one of the most famous spacecraft that used this technique.
The OpenBSD technology is amazing; I'd recommend that any Linux user gives it a try to see how a Unix is supposed to work. Simple, flexible, consistent, robust, and superbly documented (there are man pages for everything, including the internal kernel APIs needed to write device drivers!). I just wish it had apt, that's all. (And better non-PC support. My main server's an ARM.)
It's even more amazing if you've ever interacted with the OpenBSD community, who are basically dickheads. Admittedly, it's been a while since I gave up on the -misc, but the last time I was there there was some poor guy trying to discuss virtualisation and the lead developers (including Theo) were simply hurling childish abuse at him rather than, say, actually trying to communicate. And of course all their groupies were joining in. It was incredibly unpleasant.
I suppose it's possible that they've grown up since then. I really wish they would; OpenBSD deserves a lot more attention and use. But I was so turned off by the total lack of anything resembling professionalism in the community (which is weird, because the actual docs are brilliant) that I haven't felt like going back.
Instead of building a colony ship that can travel a minimum of 4 ly to the next star system, you can build one that only needs to go 0.1 ly (or so, depending on the density of these things). That's a vastly simpler job, requiring much less time and energy, and possibly only taking a decade or so --- well within a human lifespan. Once you get to the brown dwarf, you colonise. Even a small brown dwarf like Jupiter has an insane amount of resources. Sure, there's no starlight, but if you've got hydrogen you can make your own. Eventually, when the population is big enough, it builds another colony ship to the next dwarf star.
So eventually you end up with a chain of thriving colonies from Sol to whereever your target star is. You don't have to rely on your ship carrying enough supplies to maintain a biosphere and civilisation for the whole, multi-hundred-year journey because you never go that far.
Of course, by then so much of your population will be living in deep space that the idea of setting up home next to a star (nasty, hot, dangerous things) probably isn't appealing any more...
Chronomancer (and Chronicle, which it uses) is a debugger that will let you step backwards through your code. Want to know why your app seg faulted? Step back and it'll show you where and what all the registers contained before they get overwritten. It'll let you undo memory corruption, find out what happened before you overwrote vital pieces of data, and it makes debugging problems that are insanely hard trivial.
How it works is that Chronicle is a specialised version of valgrind which writes the result of every instruction to a (highly, highly compressed) database. Once it's run, Chronomancer is an Eclipse-based query tool that lets you study the contents of this database. Apart from being able to step forwards and backwards it supports things like search queries so you can ask it 'when was the last write to location X before time T' and it'll tell you. It is very, very cool.
It's also almost completely unknown, and seems to have been abandoned for years, which is a huge shame as it's an utterly awesome tool. Even building it is hard; Chronicle exists as a patch to valgrind 3.3.1 which doesn't work on modern libcs (3.6 is current). This is a tool that's crying out for some love...
This seems totally bogus to me. How could someone possibly crack WEP in two weeks? I suppose if you didn't read the instructions you might be able to stretch it to a few hours, but two weeks? What was he doing all that time?
I believe it's possible to show statistically that TSA searches cause enough people to opt to drive instead of flying that about an extra 737-load of people die in road accidents... every year.
I'm not terribly reassured by the way he keeps going on and on and on about how it's a 16-bit device, and yet seems to have specced an ARM for the processor. And I'm really not convinced by his costings --- yes, you can get a SoC ARM device for about $6, but once you factor in external RAM, display, battery, wifi transceiver, wifi *antenna*, custom PCB manufacture, assembly etc, I really don't think he's going to get it for $10.
Slashdot Mirror
I would like Google to actually search for the terms I asked for, and not what it thinks I should be asking for --- I fight that bloody autocorrect feature daily. Search for any programming term and chances are you'll get a tiny message saying 'Searching for FOO instead (unless you really meant BAR)', and then irrelevant search results.
If you go look at their forums, they're full of complaints about this. Including people saying that their company name can't be found at all, because it gets autocorrected to something else if people try to search for it!
I understand why this feature's there, but please, please, provide a way to turn it off...
One byte is about 0.000000000000045 Libraries of Congress, which means that Turbo Pascal is a whole 0.0000000014 LOCs.
Hope this helps. Have a nice day!
Yes, that is a neat trick --- the most obvious way I can think of of doing that is to do all the ssh processing on the client, and make the daemon a simply proxy; but a quick look at the source code shows you don't appear to be doing that. Or at least, I couldn't find it.
Unfortunately the platform I'd really like this to work on, my Kindle, doesn't support WebSockets (of any kind)...
I have, in fact, been vaguely thinking about trying to recompile a Java ssh client library under GWT and trying to make this work, but finding such a library that uses message-passing only and not threads is quite hard. Java likes threads.
You need a daemon to proxy between the WebSocket connection (which, remember, isn't a straight TCP stream) and the ssh server proper. Although it appears this doesn't need to be on the machine that the ssh server is running on, so it doesn't look like too much of a hardship. Also, I can't find any reference of which of the umpteen different WebSocket variants it supports.
There's actually a number of these things out already, such as ConsoleFish or ShellInABox. There's also an HTML5 VNC client, which looks very interesting.
I like the way you're thinking, but I'd suggest about 7000.
This requires separate landing systems for each stage of the rocket. This is a lot more added mass. And the worst thing to add to a rocket is more mass. Simple reusable systems like parachutes (as were used by the shuttle's solid rocket boosters) are one thing, but full-out rocket powered landing will weigh a lot more, will require a lot of additional fuel, and will add all sorts of technical requirements.
Does it?
Don't forget, those Merlin engines are restartable (something NASA never went in for much). So the first two stages land on the engines they took off with. And now they're empty, so they're very light. The second stage needs an heat shield, but other than that the only extra mass you need are the landing gear, avionics and attitude control, and the fuel. And even some of the fuel comes for free too, as there's a hefty safety margin in both stages, which you can eat into when landing.
So yeah, you are going to need more mass to do this, which will eat into the payload, but not as much as you might think. If the cost advantages of being able to recycle the stages outweighs the decrease in payload, then it'll be worth it. (Which, of course, for the shuttle it wasn't.)
9. Built-in PDF reader --- no crappy plugins, it just works.
10. Does not have a panic attack when it sees a self-signed SSL certificate. This was what made me finally jump ship away from Firefox: I spend a lot of time browsing mailing list archives trying to dig up obscure information, and there's a common software package people use for this that prefers to use https via a self-signed certificate. Trying to read these via Firefox was horrible. Yes, I do want to be told when the certificate is invalid, but Firefox's behaviour is way over the top. Plus, it actively encourages the user to add the certificate to their trusted list (facepalm).
Surely you mean 3: the warm Earth-like world we're currently standing on (well, in my case, sitting), plus Mars, plus Venus. Both of which are pretty easy to get at using current technology. Some of the gas giant moons probably count too, but they're a special case as they're not in Sol's habitable zone.
Just because the planet's the right mass and about the right distance from its primary doesn't necessarily mean we'd find it habitable...
Been there, tried that --- this was on an old CATS ARM box. Turns out that there's a lot of ia32 code in ROM on the graphics card which, of course, ARMs and Alphas are totally unable to run.
The CATS box managed to at least initialise the card into text mode by running the graphics card ROM via the world's slowest ia32 emulator; the keyboard lights would flash for ten seconds on bootup and then you'd get the graphics card's POST message. I don't know what Alpha boxes do.
I have tried to make PCI graphics cards work on an embedded system that didn't have such an emulator, and discovered that xorg relies heavily on the BIOS having initialised the card to a sane state on startup. Without that initialisation you're pretty much out of luck (particularly since it's all undocumented). That said, if you're already using an ATI card on the Alpha then there must be some mechanism to make it work, so... good luck!
(Come back, Open Firmware. All is forgiven...)
Which one, BTW? I'm looking for one and could use recommendations.
A few years back I wrote an experimental RISC OS kernel workalike (obligatory link). In the process I found myself delving way too deeply into the core of how RISC OS worked and it's really not pretty. It's got such misfeatures as: a memory allocator that allows you to allocate small blocks of memory from inside interrupt handlers --- it does this by tracing the stack to try and figure out whether it's been called reentrantly; hardware-specific hacks built into what should be generic operating system modules (FileSwitch runs programs by fiddling with the supervisor-mode registers); no real device driver model; about half a microkernel to address the fact that there's no real driver model; global variables everywhere (pretty much everything expects to read a byte at 0x00000108 in order to test interrupt status); APIs which pass flag bits in the upper two bits of addresses; and hysterical raisins everywhere, such as having multiple concurrent system heaps. Plus of course, the whole thing is an unreadable mess of uncommented ARM machine code.
That said, it does all work, and some dedicated lunatics have RISC OS running on the BeagleBoard, so a Raspberry Pi port shouldn't be too hard. (Bear in mind that RISC OS is not open source, though; it's got a look-but-don't-touch shared source license.)
What most people think of when they talk about RISC OS is the GUI, which is a work of genius, although now very dated. (There's no keyboard accessibility, for example. Without a mouse you don't use it. This is something Microsoft got right from the very first, and the early versions of Windows were a joy to use with the keyboard.) I wish that modern systems were half as consistent and elegant as the RISC OS GUI. There have been a few attempts to recreate it with modern systems --- ROX Desktop, for example --- but they never got anywhere, alas...
RS232 would be more complex, and therefore more expensive, because it requires additional hardware (the level converter from TTL voltages to RS232 voltages). The world has moved on, I'm afraid, and high-speed USB connectivity really is the cheapest option...
...and Lisp is weird.
Yes, Lisp's awesome, and has got all sorts of fascinating and powerful features such as continuations and hygienic macros, but the sad fact is that it's just not accessible. Any programmer with modern training is going to be familiar with Algol languages, specifically C family languages, and is going to take one look at the incomprehensible mass of free-form parentheses that's a Lisp program and simply won't be interested.
This is one of the reasons Javascript's so successful --- although I agree with the author that it's a terrible language. Someone with C or Java training can look at Javascript and read the structure; the learning curve is shallow enough to get people hooked. Guile's learning curve starts with a cliff. Why should someone looking for an extension language pick Guile when languages like Python or Lua are available that people already know?
(As a secondary note, the LGPL's not really a very friendly license for an extension language, as it makes it hard to embed in anything that's not GPLd. I realise that the FSF is doing this deliberately to try and encourage people to write GPL software, but it is a factor affecting Guile's popularity.)
I find myself a little perturbed by the fact that they're using code verification and sandboxing. If the sandboxing is solid --- which isn't actually that hard; any modern operating system already does this as a matter of course as part of the process model --- then the verification shouldn't be necessary.
So factory reset it and associate it with a different account. I do Android development and we do this as a matter of course to switch to different accounts. Am I missing something? What's the problem?
Nope!
Diesel engines ignite the fuel/air mixture by compressing it. As the mixture is squeezed, the temperature rises, and if you squeeze it enough, it goes bang. No external ignition systems such as spark plugs are needed.
Old-fashioned diesel engines did not, in fact, have any electrical system other than the starter motor --- once they were running, you could disconnect the battery and it would continue running fine. In fact, they were pretty hard to stop, and there had to be a special mechanism to shut off the fuel safely otherwise it would keep running indefinitely. One nasty hack I've seen was to power a boat off an old truck engine. All the cooling was stripped off it, a propeller attached directly to the drive shaft, and it was slung off the back of the boat. After being started in the shop, the boat was put in the water, with the engine entirely submerged (except for the air intake, of course). It was fine.
On the minus side, the extra compression means they're really hard to turn over; you can't start an old-fashioned diesel with a crank. It's just too hard. (Of course, you can't start a modern petrol engine for the same reason.)
Note that modern turbo diesels are totally different beasts and are computerised beyond all belief, and are largely indistinguishable from petrol engines to drive.
Because it's over here. Facebook is over there.
By that, I mean that G+ is on the pages I use as a matter of course. It's easy to get to. I don't need to remember to go to some third party website and enter a different set of login details to go and get stuff. The notifications and controls are on the search page, the RSS reader page, all the standard Google tools I know and am familiar with. This reduces the barrier to entry --- and ease of use --- enormously.
There's a special term used for orbiting on land. It's called 'lithobraking'. I believe that Mars Climate Orbiter was one of the most famous spacecraft that used this technique.
I'm hoping they just say 'screw it', divert to the backup landing strip in the Azores, and head for the beach.
The OpenBSD technology is amazing; I'd recommend that any Linux user gives it a try to see how a Unix is supposed to work. Simple, flexible, consistent, robust, and superbly documented (there are man pages for everything, including the internal kernel APIs needed to write device drivers!). I just wish it had apt, that's all. (And better non-PC support. My main server's an ARM.)
It's even more amazing if you've ever interacted with the OpenBSD community, who are basically dickheads. Admittedly, it's been a while since I gave up on the -misc, but the last time I was there there was some poor guy trying to discuss virtualisation and the lead developers (including Theo) were simply hurling childish abuse at him rather than, say, actually trying to communicate. And of course all their groupies were joining in. It was incredibly unpleasant.
I suppose it's possible that they've grown up since then. I really wish they would; OpenBSD deserves a lot more attention and use. But I was so turned off by the total lack of anything resembling professionalism in the community (which is weird, because the actual docs are brilliant) that I haven't felt like going back.
Instead of building a colony ship that can travel a minimum of 4 ly to the next star system, you can build one that only needs to go 0.1 ly (or so, depending on the density of these things). That's a vastly simpler job, requiring much less time and energy, and possibly only taking a decade or so --- well within a human lifespan. Once you get to the brown dwarf, you colonise. Even a small brown dwarf like Jupiter has an insane amount of resources. Sure, there's no starlight, but if you've got hydrogen you can make your own. Eventually, when the population is big enough, it builds another colony ship to the next dwarf star.
So eventually you end up with a chain of thriving colonies from Sol to whereever your target star is. You don't have to rely on your ship carrying enough supplies to maintain a biosphere and civilisation for the whole, multi-hundred-year journey because you never go that far.
Of course, by then so much of your population will be living in deep space that the idea of setting up home next to a star (nasty, hot, dangerous things) probably isn't appealing any more...
Chronomancer (and Chronicle, which it uses) is a debugger that will let you step backwards through your code. Want to know why your app seg faulted? Step back and it'll show you where and what all the registers contained before they get overwritten. It'll let you undo memory corruption, find out what happened before you overwrote vital pieces of data, and it makes debugging problems that are insanely hard trivial.
How it works is that Chronicle is a specialised version of valgrind which writes the result of every instruction to a (highly, highly compressed) database. Once it's run, Chronomancer is an Eclipse-based query tool that lets you study the contents of this database. Apart from being able to step forwards and backwards it supports things like search queries so you can ask it 'when was the last write to location X before time T' and it'll tell you. It is very, very cool.
It's also almost completely unknown, and seems to have been abandoned for years, which is a huge shame as it's an utterly awesome tool. Even building it is hard; Chronicle exists as a patch to valgrind 3.3.1 which doesn't work on modern libcs (3.6 is current). This is a tool that's crying out for some love...
This seems totally bogus to me. How could someone possibly crack WEP in two weeks? I suppose if you didn't read the instructions you might be able to stretch it to a few hours, but two weeks? What was he doing all that time?
I believe it's possible to show statistically that TSA searches cause enough people to opt to drive instead of flying that about an extra 737-load of people die in road accidents... every year.
I'm not terribly reassured by the way he keeps going on and on and on about how it's a 16-bit device, and yet seems to have specced an ARM for the processor. And I'm really not convinced by his costings --- yes, you can get a SoC ARM device for about $6, but once you factor in external RAM, display, battery, wifi transceiver, wifi *antenna*, custom PCB manufacture, assembly etc, I really don't think he's going to get it for $10.