Re: Bring a megalith party
Fine.. I'll leave menhir then.
2662 publicly visible posts • joined 8 Nov 2007
Has been around for a while and will generate 3d models from regular photographs. Obviously, laser scanning is going to be much better for precision work and cutting down on the amount of post-processing work (less noise and higher resolution), but I doubt that photos can be totally replaced (within reasonable cost limits) when it comes to surface "texture" mapping (by "texture", I mean in the sense of a colour map rather than an actual texture, obviously).
While it's nice to see this new project, I think it's unnecessarily restrictive. Sure, there are plenty of applications where you just want to scan in a 3d object, so having a controlled shot (such as with a fixed camera and turntable, possibly with a set background for calibration) makes sense there. In fact, these kinds of object scanners have been around for many years. But they can't handle lots of real world scanning tasks that would also be nice, eg, scanning room interiors and larger objects that can't physically fit in the control frame like furniture, vehicles, etc. Being able to track location as you enter an object's interior would also be pretty useful (think of the opening tracking shot in, IIRC, Vertigo, for example--the one where the camera tracks through a sign and into a building).
I think that latter kind of scanning (of larger and enclosing objects) is much more interesting from the point of view of developing new virtual reality and augmented reality applications. It's akin to the shift from still photography to films, with the ability to move around in space and time. Think of robots that can locate obstacles (or goal objects) in a 3d space, or terrain/object mapping based on aerial video recordings, inferring an object's motion relative to other scene elements, or even just as a quick and easy way to knock up quick scenes for first-person shooters (eg, Runtfest map for Quake 3) or 3rd-person interactive puzzle games (modern versions of the old Monkey Island style of game). Digitising small objects is all well and good, but it's really more of a time saver than a game changer, IMO.
Loved playing ... Asteroids (and later Thrust on C64), Moon Patrol (2 player version), Double Dragon (backwards elbow strike FTW), Bubble Bobble (relaxing, but great powerups), Ghosts and Goblins (hard!), Rampage (smashing and eating) and Outrun (bike racing games were great too).
In another really fun game that I came across in later years (probably in Thailand, or somewhere in East Asia at any rate) you had to control a flying balloon by cycling and steering with a set of handlebars. No idea what it was called.
As a result I can't get it into its native mode of 1280 x 1024
Sounds like it's probably a problem with the monitor's EDID information being screwed up or the monitor itself reporting invalid data, although there's always a chance that some xorg update broke something. The latter problem is a lot less common these days, and actually I think that the developers deserve a lot of respect for the work they've put into auto-detection of graphics cards and monitors. These days 99% (or a high percentage, anyway) of users won't need to edit (or even create) the xorg.conf file. Such an advance from the early days when you basically had to manually put in modelines on pretty much any system you were working on, probably followed by using xvidtune to deal with overscan and image centring ...
Anyway, for your problem, you might want to look at the xrandr command to see what X thinks the available modes are and bypass any of the layers of gunk that unity/compiz puts on top of things. It might not be the solution, but you never know... it might help. There should also be a command to dump the monitor's edid information, though I'm not sure if it's available in Ubuntu without compiling it from source yourself.
Or a combination of the ps and kill commands, if you're a command
The pidof command is quite useful too, if you know what you want to kill (or check whether it's running). Internally, it's the same command as killall, which, unlike the Solaris version, gives you command help when run without any arguments instead of killing every single process that it can...
Hmm... I don't think that coffee makes servers go any faster. Maybe some Wash and Go? (with the emphasis on the "Go" part")
10^9 core MPP systems are now viable. At that scale we can drop the Turing Machine model,
Not really. We're still stuck with the Turing model in an abstract sense and the Von Neumann model in more practical terms. We just have to adapt them to be more aware of multi-core and multi-processor systems. And in fact, we pretty much have done so years ago and there hasn't been any great paradigm shift.
and progress to an Object Machine, where every element of data is an active processing element
It sounds like you're talking about agent-based programming. Again, it hasn't caught on, except in writing botnets and perhaps back-ends for massively-multiplayer online games.
generating random sequences of logic and see if they do anything useful
And just how do you decide what's "useful"? Or as Robert Pirsig put it in Zen and The Art of Motorcycle Maintenance, "And what is good, Phaedrus, And what is not good—Need we ask anyone to tell us these things?" You'd probably enjoy reading that since it's really about philosophy, not hard computer science.
because all software will be written by software(*)
Of course. And the Singularity will arrive and bathing in Unicorn Milk will keep us young forever.
do not just binary digital processing but higher-base hardware processing ... feed a base-3 digital processor a compatible pair of base-2 & base-3 instructions
Hmm... Are you really amanfrommars in disguise? If so I claim my £5.
But seriously, do you even know what Turing-complete means? In particular, a Turing machine can be re-expressed in terms of Gödel numbers, which it turn can be mapped onto the set of natural numbers. Crucially, all practical number bases are isomorphic to each other, so binary, ternary or base 10 (or balanced ternary or whatever) all have the same expressive power so there's no theoretical reason to favour one over the other. It only comes down to issues of practicality. For most purposes binary is good enough, and it's only if you want to represent certain numbers with a finite number of digits that you might want to consider other bases (the string to represent 1/10 is infinitely long it binary, for example, while it's just "0.1" in decimal or binary coded decimal, for example). And in case you're wondering, going from the natural numbers to the reals doesn't magically grant your computer new powers either: the naturals are perfectly sufficient for "universal" computation, so, eg, a phinary-based computer can't do anything more than a binary one can, except be a pain to build and program. Another book recommendation for you: you might like Godel, Escher, Bach, and Eternal Golden Braid...
(*) Actually, there is one kind of "program that writes programs" that can benefit from having massive amount of cores to work with, though I mean "program" in the kind of mathematical sense that Turing did, rather than the way you think of it (eg, a word-processing package). I'm thinking of something like Turbo Codes, which are effectively bit-level programs that tell a receiving computer how to reconstruct some embedded data even if some of the bits are dropped or corrupted in transit.
Another, similar type of application is data compression, since you can treat the compressed data as a "program" that tells the decoder how to unpack the message. I think that that's the most interesting possible application in this realm: given enough computing power, we should be able to try out many different ways of compressing some given data and output a compressed string and a decompressor. Obviously, this still isn't going to be able to magically compress incompressible data and it's quite impractical as a replacement for general-purpose compression schemes like gzip, bzip and so on (since there is an infinite--or worse, transfinite--number of "languages" to consider, and the best compression ratio possible is sensitive to the choice of language) but it still could be quite useful for discovering good compression schemes for certain types of data. See Kolmogorov Complexity for background details.
I just don't get where you get the idea that you can't backup ARM servers, or even why it's a stumbling block to deployment. If you want them, there are plenty of backup solutions you can compile from source, or you can use the venerable rsync if you don't have any special requirements like snapshotting a filesystem so that it's in a consistent state during the backup (though I understand that LVM can do this).
The second point is to consider whether you really need backups in the first place. I think you may be misunderstanding the use case of (most?) ARM server deployments. You're probably more used to thinking of having a variety of servers each doing different things, or running a number of VMs, perhaps? I see the use case of ARM servers more in terms of grid or cluster computing. Looked at in that way, there's probably nothing on any of the nodes that you'll actually want to back up explicitly. The system image (or a large chunk of it, anyway) will probably reside on an NFS server and will be shared among several nodes. If you're using them for "OLTP" type applications, then your database is definitely going to be distributed, with replication of data across several nodes. The upshot of both of these points is that if something goes wrong with one of the nodes, it's not important: you just replace it or reimage it. If your database is already distributed and replicated across nodes, it can survive some number of failures like this, so again, there should be no need to backup individual nodes. You will want to make sure that you've got some way of backing up your entire database, but that's a whole different kettle of fish, and nothing to do with what you say is the problem here.
what exactly is "rotating at speed X" here?
The accretion disk. The article says that "the outer edges of the NGC 1365 black hole are spinning at 84 percent of light-speed or more."
Infalling matter follows the rules of relativity, so that in a relatively flat spacetime, by definition it can't travel at c or more, while in a degenerately curved spacetime (like falling into a black hole) it's red-shifted to such a degree that it will disappear from our relative view before it even appears to approach or exceed c (even before it hits the event horizon). It's just cosmic censorship in action.
re: I thought that we had a system for tracking and watching dangerous objects in space. Why didn't that system warn us?
Why not? Probably because their budget isn't big enough. I thought I read that it was $5.4 million, but I'm not 100% sure of that figure. It's certainly only a few million (3--6) spent on the problem. Less than what a typical Hollywood disaster movie costs, anyway.
RE: Remember your assertion: "Thinking about better algorithms is never a bad idea."
While you should probably "never say never", I'm siding more with the original poster. Although there is often a balancing act involved in how much time you can spend on finding a better solution and bearing Knuth's "premature optimisation is the root of all evil" quotation in mind, there's still often a good case to be made for looking for a fairly efficient algorithm right from the start.
I don't think that anyone is saying that we should go to excess in looking for the best solution, but for what we're talking about here (processing big data sets), we should really be aware of how expensive and time consuming each possible solution might be. It's the mindset that's important: do you just write the most basic SQL query, or do you take care to minimise expensive join operations or defer them to be operated over a reduced data set, for example? Also, experienced coders will of course realise that there's no point in blindly trying to optimise every single aspect of the code. They'll use a profiler (or equivalent) to identify where their efforts stand to reap the most benefit.
Speaking of programmer effort, I think that in many cases, it can be false economy to use inefficient algorithms. If your algorithm is bad enough, you can end up spending more time waiting for results when you're coding and testing the thing (on real data, as opposed to just a small amount of test data) than you would if you'd just thought about the problem a bit more from the outset. Granted, you can multitask and do other stuff while you're waiting, but it's not ideal to have too many context switches or your productivity will suffer. Plus, what happens when you finally realise (or have to be told) that the solution isn't good enough? Most often, you have to go back to the drawing board and do what you should have done in the first place and implement a half-way decent algorithm.
re: ground...
Be that as it may, it doesn't stop us from building up a fair charge on carpets and the like. I'm guessing that the plant itself is acting as an insulator and it's the bees' rubbing against the pollen/stamen is what sets up the differential. Kind of like a mini Van De Graaf generator.
If they don't bring Office to Android, somebody else is going to eat their lunch on the tablets
It still doesn't seem likely. They may have got some of the way there with the cut-down version of Office for Surface RT, but it is exactly that: cut-down. I've read lots of unsubstantiated comments here that the Office code base is such a mess of x86 assembly for things like macro support is unlikely to be ported any time soon. Also, I read here on the Register that there seem to be political problem within Microsoft as to whether they should even develop and release an ARM version (or a Surface RT version, to be precise) of Outlook. If that's to be believed, then there's probably a considerable faction within MS that would never accede to releasing a Linux (or Android) version of any of their desktop tools.It would completely go against the whole philosophy of maintaining customers through locking them into the Windows ecosystem. And even if they do go down that route, it may, as you say, already be too late .
On a slightly unrelated note, I think that there is definitely a niche there for a "good enough" (which incidentally is a phrase you used to hear at MS to describe their development/release philosophy) office suite. I've been thinking for quite a while now that a suite that had the 80% of features that most people actually need and use could easily capture a significant chunk of the market for "office"/productivity software. People are fed up with massive, bloated systems with tons of arcane features that they'll never use. By paring it down and providing good interoperability between components and across platforms, it should be "good enough" to satisfy all but the most hardcore/insane of users. In keeping with the 80% of functionality idea, I'd suggest calling it "Pareto" (if such a thing doesn't already exist). So long as developers were ruthless about not implementing features just for the sake of it, I think it could go a long way.
This is just my opinion, though. Personally, I've not used Word in many years and I have no need for it unless someone demands a document in that format. If I need something professional looking, I'll plump for LaTeX every time (edited in emacs, naturally :), or just use XML and CSS if I want to mess with layouts and fancy stuff. In either case, I prefer to concentrate on the content rather than formatting (which gets done at the end and is abstracted away from the actual content). This seems to be the opposite of the way that most Word users (and developers) work--style over substance, you might say.
Don't get me wrong... it was a fine attempt at making a joke, and I'm all for that, but the part of me that holds maths in such amazement(*) just flat out refuses to even consider Pi being some other value, even in an alternative universe. I literally just doesn't compute. A universe where e**(pi*i) isn't -1 is as unimaginable as one in which effects precede their causes or don't have causes at all, or where entropy doesn't grind everything down. Besides, even "non-Euclidean" geometries (eg, geometries without the parallel postulate) don't mean that they don't use and need Pi. If you take a plane journey through three points on the globe, the triangle you trace out has >180 degrees, so it's non-Euclidean, but it's obvious that if you go up a dimension from the 2-D Cartesian representation to the earth as a 3d sphere that everything still works and revolves around Pi ...
(*) http://en.wikipedia.org/wiki/The_Unreasonable_Effectiveness_of_Mathematics_in_the_Natural_Sciences
re: How quaintly Euclidean...
I see what you're trying to do, but any of these "alternative universe" theories are rooted in maths. Even if they exist, there will be no universe where 2+2 = 4.1 or Pi isn't both a constant and an irrational number. The fundamental rules describing the geometry of alternative universes has to be the same as ours according to all the theories. The most likely scenario is that physical constants like ratios of fundamental forces or binding energies needed for chemical bonds or decay rates or the like could be subtly different, though it's vaguely possible (in a mathematical sense) that if a particular string theory happens to describe the Whole Sort of General Mishmash that is the multiverse, and the alternative universe has slightly different parameters, then we might actually be able to see extra dimensions there on a macroscopic scale. That would probably be the weirdest possibility. Even so, the metric spaces of our universe would also apply there, so Euclidean distance would still apply on some scales while a Minkowski space metric (which still requires Pi!) would be more natural in others.
I see that a previous poster got a downvote for suggesting alternative lead-based lifeforms. You'd have to tweak the fundamental physical constants by a massive amount before that would even be a remote possibility. Before you'd even managed to get there, you'd find that the stars had gone out due to not being able to self-sustain their fusion reaction. Then we'd have a lot more to worry about than alien invaders. Something like Ice-9 would be a lot more plausible than Pb-based life.
the previous Python-related copyright snafu involving Twisted and (val)grind. Guido and friends seem to be on similarly strong grounds here.
I found a link to that effect. Apparently all the national papers ran with a similar story around the same time.
I think he's over-egging things for sure. I mean there's no mention of shifting [gears], hugging curves, burning rubber, [lug] nuts popping, [cam] shaft action, driving stick, sucking [diesel], the point of no return, or even throbbing pistons.I'm sure that if "salacious" was the goal, he could have done a much better job.
Was never much of a fan of [Dec] Wars. [Vax] Trek was more my thing.
I assume its fast enough to write data to the non-volatile part before the power dies away completely.
That's not a good assumption. Power failure when writing to SSDs can trash even bits of data that weren't currently being written to thanks to the possibility of wear-levelling algorithms effectively moving random blocks around whenever you make a write. See "write amplification" on wikipedia for a pretty good description.
You'd be caching the most-used data,
Alternatively/additionally, you'd probably find it useful to hold indexes in RAM, and implement some sort of ageing/caching algorithm that keeps new and frequently-used data in flash and the rest out on spinning disks. If you use a log-based structure for the flash storage and periodically rewrite out to disk (perhaps redundantly, depending on whether new indexing constraints are required) then you can optimise both reads and writes across all storage layers. Something like SILT or log-structured merge trees, but with spinning disks as the final storage layer, optimised to reduce fragmentation and extra seeks.
New chip design would be needed anyway
I see lots of interesting comments here, your own being particularly interesting. So anyway, this is a response to quite a few of those posts...
I think that if we're going to see more of this sort of thing (storage that blurs the boundaries between RAM, flash and disk storage as well as the ability to completely power off components when not in use) then we're going to need a fundamentally different architecture to take advantage of it. This goes beyond just new chip design (where even today cores can be started up and shut down at a whim) and into having some sort of "power arbitration" bus, with the entire system backed up with a small, finite battery. For the instant-on/instant-off scenarios using flash as hibernate/sleep storage, you need to be able to guarantee that it's going to be able to finish writing the OS state data in case of loss of mains power. For the scenario of being able to, eg, keep power routed to the GPU while it's doing some computation task, but shutting down other non-essential stuff (but probably keeping, say, Ethernet alive to enable a kind of wake-on-lan feature) you probably want to be able to budget how much you can do while on internal battery power and also have the ability to suspend gracefully when you're approaching its limit. Not trivial stuff at all.
Of course, it's very unusual these days for us to have battery power built onto the motherboard (as opposed to being in an external UPS). If these devices/ideas become commonplace, though, we're sure to see many innovations in power management overall. I shudder to think of all the new failure cases when we stick in a new device (be it faulty or malicious) in machines in future, though...
Interestingly, I read an article a while back about the US military working on building microbots that could be scattered over a battlefield to be used for gathering images and sussing the lay of the land. The software and radios that they had were capable of self-configuring into an ad-hoc mesh network, so that part of it should be easy to sort out, even if a significant fraction of the machines don't survive the landing or fail in some other way.
As Helena points out, though, these things aren't really of any use as roving devices. There's a limit to how small you can make remotely-controlled bots while still giving them useful locomotion and other more practical sensors and actuated abilities.
Still, I think the microbot idea could still be pretty useful for future missions as a means of getting an initial idea of local terrain and even provide telemetry data for later, more fully-featured rover landings. The thought of sending an Internet to Mars is pretty cool too, especially if it can self-organise and do a kind of terrain "interferometry" (a fancy word for building a map from multiple viewpoints) locally instead of having to pipe everything back to Earth first. Think about it... Martian Internet! What's not to like about that?