Posts by David Given 433 publicly visible posts • joined 4 Aug 2008
Is this supported yet?
Last time I tried Unity, the global menus were absolutely hostile to focus-follows-mouse of any form. This is an absolute deal-breaker for me; I need this to work.
Given that I would have to ditch Unity and install an alternative desktop UI anyway, I have switched to Debian; but I do miss the general just-workingness of Ubuntu...
Does anyone know what happened to the first stage after separation? I assume it splashed down somewhere. Will it be recoverable? Because I'll bet that there are a number of SpaceX engineers who want to go over that thing with tweezers.
Also, when they finally get the first stages landing vertically using the rocket engines, it will be hella impressive.
I use WindowMaker. (http://windowmaker.org/, Debian package wmaker). It's old-school enough to be efficient --- it's a window manager, dammit, not a file browser/global event bus/integrated indexed search agent/graphical compositor/desktop experience expediter --- while also being modern enough to look decent and have a GUI configuration tool that actually works. It's surprisingly customisable, and all *easily* --- either by just clipping icons together on the desktop or using the config tool.
To me, it falls right in the sweet spot between the just-work-dammit behemoths like the Gnome window managers and the hard-core uberconfigurable world of ratpoison and fvwm.
Wouldn't it be far more sensible to simply use conventional rechargeables (or disposables) in a caddy that produces USB power, like this? http://www.amazon.co.uk/Battery-Extender-Pack-Takes-Batteries/sim/B002PHC1XU/2
AAs are cheap, high capacity, and available everywhere, and there are a bajillion different varieties depending on precisely what it is you're wanting to do. I can go camping with a handful in a bag which will continue to provide power even when a bespoke battery like one of these has gone flat.
And if you *really* want maximum power, use C or D batteries. Those things store a scary amount of energy.
I think I managed to get NEXT down to one instruction on the ARM --- ldr pc, [ip, #4]!, maybe? It's been a very long time.
I was deeply impressed by Forth, from its design to its philosophy to the utterly minimalist implementations. Can I actually do anything useful with it? Can I hell. I'm far too fond of things like type checking, and variables, and syntax that can be checked at compile time, and little stuff like that.
An HLL that compiles into Forth would be a very nice thing to have, but producing good code from Algol-alikes like C would be hard because of differing stack semantics. JVM bytecode, perhaps --- it's already stack-based, after all...
If you know a little Forth, it's worth grabbing an emulator (there's a whole bunch on http://www.jupiter-ace.co.uk/emulators_unix.html) and giving it a go. It's a humbling experience. Where a ZX81 feels like a toy, an Ace with 3kB feels like a real computer --- something you can actually genuinely write useful programs in. Their Forth, extended to allow words to be redefined, provides one of the most minimalist yet real development environments I've ever seen, providing both low level and high level features at the same time.
The implementation was a work of art, too, using all kinds of strange Z80 features to achieve maximum code density. There's a disassembly here: http://www.wearmouth.demon.co.uk/ace.htm If you want a (now rather old fashioned, but still useful) Z80 Forth implementation, you could do a lot worse.
And if you don't know any Forth, LEARN SOME. It's pretty much useless in real life, but knowing Forth will make you a much better programmer in other languages. And it is the go-to language for really low-end embedded devices.
If anyone's interested, I have a rather prototype Java to C++ translator: https://chiselapp.com/user/dg/repository/cowjac/home
It works well enough to run benchmarks but is decidedly unfinished. I'm taking a rather different approach to Google --- I'm starting with Java bytecode, while they're starting with Java source. I'd hazard that mine is theoretically capable of producing better code (as I'm using a proper Java compiler/analysis framework underneath). OTOH, theirs is actually useful, if that's relevant to anyone...
...will it play my GameCube and Wii games in HD?
I mean, properly, at 1080p resolution, rather than just upscaling the SD framebuffer. It's perfectly possible to do so; the emulators have been doing it for years (and it looks freaking *awesome*). If the WiiU did this, I'd be inclined to get one purely so I can play all my existing games at higher res.
Yup. This isn't really a hybrid by any useful meaning of the word; it's a diesel-powered 4WD with electric transmission. Which is no bad thing --- the electric transmission is lightweight and gives lots of useful torque down at the bottom end. (I'm personally waiting for a front-wheel-drive econobox with electric transmission from a diesel engine.)
But yeah, in real life you're always intended to be running the engine when you're using the electric motor.
Oh, I loved Wind Waker --- I used to spend hours sailing around that huge open ocean, exploring the little islands and strange things that popped up in the open sea. The way it seamlessly managed to merge all the islands into one huge zone was great.
Twilight Princess, by comparison, felt tiny and claustrophobic: the world was chopped up into discrete zones, all quite small, and too many of them involved running around in what amounted to tunnels. And of Skyward Sword, the less said the better --- this is less Zelda and more Banjo & Kazooie. Which was a shame, as the Wii hardware can do so much better. Go play Xenoblade Chronicles if you want to see how to handle wipe-open outdoor areas *properly*...
...of this is to send back live pictures. I mean, forget trivial stuff like GPS or system status telemetry --- 340 bytes is big enough for a 52x52 monochrome bitmap, or if you really want to push the boat out, 36x36 at 2bpp or 18x18 at 4bpp. And that's without compression, too.
I know the robotic missions use the wake-up call tradition, but at least for Spirit and Opportunity the music was played to the humans on the ground, rather than being uplinked to the rovers themselves. (It's actually kind of hard to find a definitive statement on this.)
I would be really, really surprised if they would waste precious uplink bandwidth and buffer space sending a few megabytes of compressed music to a rover if there wasn't a really good engineering reason to do so. Needing to test the uplink system on a daily basis is a perfectly adequate reason, of course; the nature of a robotic mission is that it will downlink far more than it will uplink, and so it could well be important to keep pushing data over the uplink.
I've found lots of sources talking about downlink (apparently they got 30MB to 250MB a day, depending), but nothing on the uplink...
Grumble grumble stupid frickin' huge downloads grumble grumble.
Here's a single-page version, with cleaned up formatting, of the online HTML version of the book: https://docs.google.com/document/d/1XTVLIkwoAEf5mZnSwRFCHaW1_PZ4gG4d15NWd2arvtA/edit
There's still some work left to do --- tidying up the boxes and figures, indenting quoted text, etc --- but it's *vastly* easier to read like that. I haven't managed to make an ebook version yet, though, as calibre seems to choke on Google Docs' output.
Google Docs so does not like documents that big.
Can you point us at a decent ebook version? archive.org has either a dodgy half-gigabyte PDF scan or an even dodgier OCR of it. There's a decent HTML version here:
http://www.hq.nasa.gov/pao/History/computers/Compspace.html
...but goddamn it, I want a copy for my Kindle.
Looks like the fuse is generating quite a lot of gas, judging by the buildup on the inside of the perspex lid.
Is the vacuum pump capable of keeping the pressure inside the chamber low enough during the period between the fuse ignition and main engine start? If not, then the pressure inside will build up and render the test unrepresentative.
I can also strongly recommend Neal Stephenson's _Mother Earth, Mother Board_, a thoroughly engrossing (yes, really!) essay on cable laying (yes, really!): http://www.wired.com/wired/archive/4.12/ffglass.html
I believe a lot of the research for the essay found its way into _Cryptonomicon_, but the essay is an excellent read all on its own.
Originally Android had internal storage, which wasn't user visible, and the SD card. Apps got installed to the internal storage and kept their data in databases there. The SD card was optional; if an app needed lots of space, or needed access to actual files (such as videos, photos, MP3 etc) they could look there.
Except that the early Android devices didn't have much internal storage, so apps got used to storing anything that was even slightly big on the SD card, which meant that having one was mandatory. (My elderly phone only has 170MB of internal storage.) The iPhone avoided this by speccing reasonable amounts of internal storage in the first place, and not allowing any external storage at all.
Fast forward to now: internal storage is now 16GB or so and is loads faster than the SD card (even if there's a socket available). So in order to use it effectively they have to split it up into two parts, one for internal storage and one for *fake* external storage, which is presented to apps as an SD card. Which is really stupid, but that's hysterical raisins for you.
I don't know how big iOS apps are, but the biggest app on my phone is Google+, which is 28MB installed; Google Maps is 11MB; Dropbox is 4MB; the Android Market is 4MB; the third-party home screen is 2MB; Youtube is 1.5MB; a Z-code interpreter is 400kB. The smallest real app is the terminal emulator, at 64kB.
If you want to see this sort of thing done well, go read on of the Marine Accident Investigation Board's accident reports (http://www.maib.gov.uk/home/index.cfm). The primary goal of these --- which is printed in large letters at the top of every report --- is to determine what happened and how to stop it happening again. Also --- and again, this is printed in large letters --- the reports are inadmissible as evidence in any judicial proceeding that's attempting to apportion blame.
The reports themselves are a miracle of brevity and clarity, stating clearly and simply what happened, what went wrong, and what needs fixing. They're also not shy about pointing out the mistakes people make, but the point is always that people always make mistakes, and the system needs to be designed to cope.
I recommend them to anybody who wants to see how an accident report should read. (I gather it's possible to subscribe to a tiny four-page flyer containing summaries of the accident reports; I've seen them, and they're fascinating reading, but have been unable to find this on their website.)
Hm.
The iPad has a 25 Wh battery, which is 25*60*60 = 90kJ. Assuming we charge it from flat every two days, that's 90kJ * 180 = 16.2 MJ. Assume charging efficiency of (wild guess here) 10:1, that's 160 MJ over a year.
Electricity cost is about 10p per kWh, so that's 10 / 1000*60*60 = ~3x10^6 pence per joule.
So over the year, our 160MJ is costing roughly (*very* roughly!) 480 pence.
Given how many numbers I made up, the fact it comes out at the same order of magnitude as the poster does suggest that their figures are at least plausible.
Things that raise *my* blood pressure when booking flights:
(0) The total absence of any kind of universal transport management system. Want to make a connection from a flight to a train? SUCKS TO BE YOU.
(1) The terrible, terrible user interface. Fill in outward journey, press search. Oh, look, I haven't filled in the return journey, so instead of assuming I want a one way journey it just fails with an error. Select the 'one way' checkbox. Outward journey details get cleared. Fill in outward journey again... sigh. Plus, of course, you have to use a selection of badly-designed custom widgets and drop down boxes to do all this, and no two airlines' work the same, and frequently they don't work at all. Tip to UI designers: drop-down boxes for day of month is *stupid*.
(Still, the airlines do this better than the railway companies. The only way to find out whether a given London-Inverness sleeper train has vacancies is to actually try to make a booking.)
Oh, and the session timeout is usually way too small, so if you try to compare two flights in different tabs, the details all vanish when you're not looking. I think Easyjet's is something ludicrous like five minutes.
Deselecting all the extras I actually don't mind too badly --- it's just something I've got used to. Doesn't mean I like it, of course.
(2) The stupidity that is Mastercard Secure / Verified by Visa.
I've never been a fan of git; just the other day, I forked a github project, checked it out, and then a few days later upstream changed something in the past which meant that my fork now conflicted with the same release I forked it from... or something. I spent about a week fiddling with rebase trying to pull in their changes and eventually gave up and just reset my repository to their head. That's not impressive.
I do use Mercurial, though, and like it: much saner syntax and semantics that actually make sense. Plus it'll even interoperate with github (although hg-git is painfully slow for large projects; just for a stunt, I tried pulling in a linux kernel tree from github with it, and the checkout took 50 hours.)
The DVCS I'm thoroughly intrigued by, though, is fossil. Written by the sqlite guys, it's a tiny single executable that is a combined DVCS, bug tracker, wiki, web server, CGI script and GUI (via the built-in web server). No installation needed. Just the one executable basically gives you your own private github in a box. DVCS-wise it does immutable history and no rebasing, which I approve of. It also supports both decentralised mode (traditional DVCS) and centralised mode (traditional VCS). The only problem is that there's not much vendor support --- no Sourceforge of Google Projects support, for example, although it will import and export to git.
At work we use SVN. It's okay but is really slow, and merges lose history. I'd much rather use a DVCS, but there is more scope for shooting yourself in the foot that way.
Yeah, the VMU had 128kB of flash, a 48x32 monochrome screen (yes, those numbers are two digits each), and used an incredibly obscure 8-bit microprocessor called the LC8670.
When plugged into the Dreamcast controller it acted as save game storage and a slave screen for the Dreamcast game, but you could also download standalone games onto the VMU itself and play them disconnected --- it had the world's smallest dpad and some game buttons. Search for VMU on youtube for thousands of videos of people doing this.
If you're into exotic assembler programming, they're easy to hack, and you can get new ones off ebay for silly money; although in order to get games onto the damn things you either need to use the Dreamcast web browser or else buy a Chinese off-brand VMU emulation device with PC connectivity. This all happened a decade ago, so the hacking communities have largely imploded, but there's some info here: http://www.deco.franken.de/myfiles/myfiles.html
Can anyone who's on one of these ISPs try it and tell us how it's implemented?
For example, the classic minimum-compliance-with-bone-headed-court-order level of compliance is to spoof the DNS to return a specific IP address for the blocked domain. This, of course, is trivially workaroundable by just using a different DNS server (such as Google's 8.8.8.8).
Blocking IP addresses is rather more work --- as you have to keep up-to-date with TPB's IP address changes, plus of course the risk of collatoral damage by other uses on a shared address --- and if I were an ISP being legally required to do something I didn't want to, I'd probably consider doing this to be too much effort if the easy approach satisfied the requirements.
I have an Alcatel OT-808! It's a very nice phone. Annoyingly pink, but it's incredibly small, extremely robust (I keep it in the pocket with the keys and coins!), the battery lasts for a week, and the keyboard is very usable.
What it's not is a smartphone, and I've been on the hunt for a similar form factor Android device. The only one I've found so far is the Motorola Flipout. Unfortunately that has a battery life of a day, if you're lucky, and has been abanded by Motorola and so only runs Eclair. Yes, not even Froyo. But it does have a FIVE row keyboard, which if you're doing anything shell-related makes a vast, vast difference.
I'm a little surprised that clamshells are so out of fashion. Apparently nobody these days makes small Android phones.
One of the Falcon's nice features is that the vehicle is clamped to the ground until the computers decide that all the engines are running reliably. So it's possible to start all the main engines, throttle them up, *then* realise something's wrong and cleanly shut everything down again, resulting in an intact, reusable rocket standing on the launch pad.
In most other designs, once you start up the engines, your main failure mode is 'fireball'...
Here's an off-the-wall idea:
Launch before dawn. When the balloon rises sufficiently far above the surface, it'll see the sun over the curve of the Earth. (Or a satellite, or the moon, or some other easily detected object.) You'll have to compensate for the Earth's rotation as the balloon takes time to ascend, but the calculations needed to determine at what altitude the sun becomes visible are pretty well understood.
The disadvantage is that you won't get a good view during ascent (because it's dark). But you might get some really good views during launch in the dawn light.
I have a Mele A1000, an A10-based set-top-box what I ordered from China; it's being used by Rhombus Tech as an A10 sample device while they work on the EOMA68 device. I'm going to use mine as the house server, replacing my current elderly SheevaPlug.
It's got some nice features: the big one for me is that it has real SATA, which a lot of these devices don't (the TrimSlice, for example, has its SATA connection hooked up via an internal USB bus which makes it slow and CPU heavy). Plus the A10 will autonomously boot off the SD card, which makes the device unbrickable, and is therefore ideal for hacking purposes. The internal flash is 4GB, which is big enough to get a real OS on, too.
Best of all the whole thing was under $70. Plus, I got a free World's Worst Infrared Remote Control. I might be able to get some use out of it as a door wedge.
A large number of years ago I bought a Konica Minolta PP1400W laser for about fifty quid. I plugged it in to my Ubuntu box and it just worked, and it's worked brilliantly ever since: cheap to buy, cheap to run, excellent output, warms up in about five seconds, and a sheet feeder that actually works. It's not fast but for the kind of light print jobs I do, it's ideal.
Does Konica Minolta produce an equivalent modern printer?
Oh, and BTW, I turn it on, print something, then turn it off again. No standby power loads.
What the article doesn't mention is the BBC's operating system. Unusually for most micros of the age, which mostly consisted of a CPU and some RAM in a box with just enough Basic to let you write programs, the BBC actually had one. It was simple and elegant and very modular: the OS ROM lived in the top 16kB of address space, then you had a paged bank of application ROMs living in the next 16kB section, and the bottom 32kB was shared RAM.
Application ROMs could consist of standalone utilities, proper applications (like the excellent BBC Basic, or word processors like Wordwise or View), file systems (like the fast and simple DFS, the slower but much more sophisticated ADFS, the network file system NFS, etc), and so on. The OS would seamlessly page from one to the other, so an application ROM could make file system calls which would get delegated to the currently selected file system even though they both lived in the same place at the same time. It was even possible to open file descriptors to more than one file system at a time and copy from one to the other!
The OS system call API was fast, capable, well-documented and sufficiently abstract to allow some really neat things: the Tube second processor interface allowed system calls to be executed via RPC from a *completely different computer*. Tube second processors really were CPUs in a box; no I/O other than the connection to the BBC, no ROM other than the RPC stub. So you got 64kB of RAM and maximum perforfmance, with all the fiddly I/O overhead handled by the BBC itself, now acting as a dedicated and extremely capable I/O processor.
And the Tube wasn't limited to 6502s --- they also made Z80, 32016, 68000 second processors, all using that same system call interface. Even the ARM chip, now a juggernaut taking over the world, started life as a second processor connected to a BBC micro!
(I don't believe they ever tried system call RPC via Econet, but it would have been an interesting experiment.)
It's a shame that Acorn's master plan fell through. After the Electron debacle, they regrouped and produced the BBC Master, which was an excellent machine in many ways but not a patch on the machine that *could* have been. With better marketing, we could by now be using BBC-descended multiprocessor systems instead of PCs...
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
