from the description
It just sounds like some kind of octree library. That's hardly a difficult thing to knock together, though maybe there's more to it than it sounds. Hmmm... "animated smoke"... maybe it's just a Perlin noise generator, then...
2662 publicly visible posts • joined 8 Nov 2007
The previous-generation iMac with built-in DVD drive was more functional.
It's called progress! The next model won't even need a keyboard.
underwear woven from nettles.
Actually, you can get surprisingly good fibre from nettle plants. I just did a quick search for 'nettle fibre' and turned up this amusing page which by chance happens to have a section titled "STUDENT SHOWS OFF NETTLE KNICKERS" (with pic). So not quite in the same class as chocolate teapots and such...
I didn't know Sheffield was in China...
I thought it actually might have been, until I discovered it was just an urban myth. Hooray for the Internet!
for Natsume Souseki..
'You seem to do quite a lot of wandering about from place to place. This is so that you paint, is it?'
'Yes. All I take with me is my colour-box, but whether I actually produce a picture or not doesn't worry me.'
'So these trips are half for pleasure, are they?'
'Yes, I suppose you could say that. The fact is, I don't like having people count how many times I break wind.'
Zen priest though he was, this was one metaphor that apparently the abbot could not understand.
'What do you mean by "counting how many times you break wind"?'
'If you live in Tokyo for any length of time, you have your farts reckoned up.'
'How do you mean?'
'If that were all it wouldn't be so bad, but they do such unwarranted things as examining your backside to see whether your anus is triangular or square.'
From 'The Three-Cornered World', 1906.
It's good, but, not as good as an iPhone.
I'm reminded of that ad that Apple ran not so long ago that bigged up Siri in particular. One female user asked the phone whether her brother had arrived yet at a stadium or something, and was told that [insert Brother's name] was here. And you talk about how Android phones spy on you?
Actually, it's pretty safe to say [Earth] does [have a top]
I'm looking forward to us contacting extraterrestrial life so that we can decide which side of the "topist" and "bottomist" divide we lie on. Or to put it another way, whether we root more for turnwise or widdershins.
I've only one niggling doubt: wasn't this already played out in Gulliver's Travels?
On balance, it seems to me that most of the accusations levelled at autoconf here are more to do with how it's used than the software itself. It is a pretty horrendous bit of software in itself, thanks to the pretty steep learning curve, and I've been hit a few times by some of its idiosyncrasies (incompatible versions, missing m4 macros and the way it sometimes runs differently if you run 'sh ./configure' or './configure', mainly) but on the whole if you've got a project beyond a certain size and you care about portability, I think it's usually a no-brainer: use autoconf.
As I already said, the problem is often more to do with how the software is used. It's not a magic bullet that will automatically make your program portable. You still have to do all the work in your source code to account for all the different flavours of *nix or whatever, like whether they have certain library functions available to them (and which version), what system include files are needed, as well as, sometimes, lower level concerns like the machine's endianness, word sizes, data alignment characteristics, and especially the right architecture (or compiler)-specific flags to use. The other thing about autoconf, besides being an aid to achieving portability is that modern software generally has a multitude of dependencies, and without something like autoconf (and supporting tools/standards like pkg-config) any homebrew configure/make system is apt to get very complex very fast, and worse than that, they're (relatively speaking) very difficult to maintain and often not very portable in themselves. Most problems with building (besides problems with dependencies) tend to be with the author not writing portable code in the first place or simply not knowing about the foibles of your particular system or toolchain. Again, that's not autoconf's fault, but it is what it's designed to help the coder with.
and that's why I end up just using shell scripts for my projects.
There's nothing wrong with rolling your own configure/build system, but for the end user (ie, the person building the system), I think that familiarity with the autoconf system usually makes it easier to handle cases where things go wrong for some reason. Once you've compiled a few dozen apps it becomes pretty easy to figure out where the build is going wrong and how to fix it. Maybe that's just my personal preference, though.
At the precise moment, the phrase "Personally I believe this will lead to a better world." (muttered by Rick Rashid to the assembled delegates, which for some strange reason was carried by a freak wormhole in space back in time to the farthest regions of the universe where the G'Gugvuntts and the Vl'hurgs lived) filled the air over the conference table, which in the Vl'hurg tongue was the most dreadful insult imaginable. It left them no choice but to declare war on the G'Gugvuntts, which went on for a few thousand years and decimated their entire galaxy.
Sure, the MP sketch is a nice link to include, but wouldn't an omnigot link be more relevant to the topic? Still, I guess you have one now.
RiscOS was ARM Archimedes, not the 6502 based BBC Micro. It just happened to have the similar BASIC.
Oops. I just assumed that it was the same BBC Basic on both BBC Micro/Archimedes. I got that impression from this (excellent) guide to ARM assembly:
http://www.peter-cockerell.net/aalp/html/ch-4.html
we still don’t have any reported incidents of confirmed security breaches with them.
With respect to bugs and backdoors in voting systems: absence of evidence is not evidence of absence.
This is particularly true with closed, proprietary black box systems that are not double-checked after the election. That's even if it's possible to validate it after the fact, and the box didn't just silently change things without leaving a permanent record.
I was curious about this so I did a little test. Opened up an incognito tab to point at el Reg, then hit home, then recent applications. The result? The list shows a thumbnail screenshot of the "incognito" page.
I didn't really expect any other behaviour--apps can't tell the OS they don't want the snapshot when they leave the main activity, but they could blank the screen first in response to the task switch/leave activity message (or whatever they call it). I know it's a very minor oversight, but beware of not closing the incognito tab before going back to the home screen!
I second that. In fact, it's not even clear whether it's in the range of 3x more likely or 4x. My reasoning? If it were 100% more likely then we're talking twice as likely, or 100% for the baseline + 100% extra. So is "314% more likely" supposed to mean it's about 3.14 times as likely, or 4.14 times (100% + 314%)?
Whatever it is, the whole sentence (including the "whopping" part) is too confusing.
My copy of Watchmen has a copyright date of 1986. I'm thinking, of course, of Ozymandias' s multi-screen display allowing him to absorb a multitude of information streams at once.
I wish I had a secret Antarctic lair :(
You can choose to have an alternate opinion and you can choose to believe that screen size is relevant factor in this.
You mean like "big screen size is so important that we're not going to make small ones" to "we made a small screen size (with crappy resolution/dpi) and it's brilliant" to "big screen size is everything, man", to ... (you get the picture).
Any link to a doc that describes what these new capabilities are? I'd dearly love to see a CPU that could do arithmetic over GF(2) fields, as used in AES, among other schemes. It doesn't even take much to do this in silicon, though I guess chip designers probably think it's too specialised to bother. There's always FPGA, though, I suppose...
The open source (usually libdvdcss2-based) solutions usually fail spectacularly when the DVD publisher has included some arsey extra copy protection measure that makes the movie appear to be 99 titles, or makes it so open source players break unless you skip the first megabyte or so of the disk.
Agreed. I could never figure out why the default players/libs on Linux don't disregard the TOC info if it disagrees with the physical information on the disk. I had a look at the source code myself and figured out what would need to be changed in order to defeat any of the standard copy protection schemes from among DVDs that I own, so that I can transcode them and have them available on my DLNA server. I think there are probably two reasons. First, these bits of software are generally written so that they comply with the standards and they don't deal very well with the copy protection schemes, which deliberately throw in junk. This often leads to disks that work fine in a DVD player but won't play on a computer. Second, I suspect that there might not be the collective will to get around the "copy protection" (in quotes because almost all of these schemes are laughable in how they operate--essentially, as I said, adding junk so that that faithful implementations of the specs, as on computers, won't be able to read/play the disk) because of fear of litigation. Even though it's trivial to get around the copy protection schemes I've seen (and I'm not even an expert), I'm sure the big media companies have patents on exactly how they fuck with the standards (and break them--I don't think they should get away with using the DVD mark on these) so I'm sure any open source distro would get slapped with a patent infringement suit if they implemented the changes needed to ignore the copy protection mechanisms.
It's all a bit sad really, especially considering how technically stupid DVD copy protection is...
And full ACLs throughout from the ground up - not as an after thought - like for instance in UNIX type OSs.
I don't know what you have in mind when you say that Unix only has security as an afterthought. It was built from the ground up to be multi-user, with strict separation among those users (both for in-memory applications and on the file system). It also had the novel setuid mechanism and associated su and chgrp functionality pretty much from the outset. I think that the creators actually got a patent on the setuid mechanism, possibly combined with its use with the passwd program which effectively allowed each user to change their own password in a single system file while not allowing it to change anything else there.
Almost anything that can be implemented using ACLs can also be implemented using the user/group and setuid/setgid mechanisms. About the only area that I can think of where Unix is perhaps more permissive than it should be (for a paranoid sysadmin) is in allowing network access for all users (*). But then again, Unix wouldn't have been such a resounding success without networking, I think. If the designers had wanted to include some sort of "access rights" for the network, then they'd basically end up with something like VMS's security model instead. But then, it obviously wouldn't be the Unix that we know and love :)
* Actually, I realise that this can be done in modern Linux using an iptables command to drop traffic based on userid. I don't actually know how early Unix implementations implemented network access. For all I know, all the network access functions might have actually used a device file at the lowest level. If so, then it actually would have been possible to restrict net access on a per-user basis using the standard user/group security mechanisms...
Whereas with ARM there is no opcode translation to do at all!
No, but there is still a decoding stage, so there's still something there to "get hot". As ARM CPUs have a fairly orthogonal instruction set, though, this stage is vastly less complex than the decode stage on CISC CPUs. This also allows, for example, reserving a few bits to encode for conditional execution and a few more for whether and how to rotate one of the instruction operands. These features are available with most, if not all instructions and effectively come "for free" from the programmer's perspective.
As you might have guessed, I quite like the ARM architecture. It's one of the nicest CPUs I've coded for, though 68000 is really nice too, and I've also got a soft spot for the PS3's Cell architecture. All of these are a complete joy to write for compared to the abomination that is the x86 architecture!
Within 6 months it will be cracked wide open...
That's not a given. It's possible to have a DRM system with mathematically provable security. That doesn't mean that they're easy to implement, though, and the state of the cryptographic arts always gets better while your DRM has to stay static.
The biggest problem with DRM (from a technical standpoint) is key exchange and key management. You could theoretically make a perfectly secure DRM system, but it means that every user or device has to have their own personal key, and the hardware has to be resistant to tampering. In practice, this makes it totally impractical.
The biggest problem with DRM in 3D printers (as in this case) is that it's impossible to prevent them from making a new printer that simply doesn't have any DRM in it :)
And we are RIGHT IN THE MIDDLE?
Unlikely. That's just an effect of isotropy. If everything is receding at an equal pace from everything else then every place seems to be the centre of the universe. No doubt many other planets have astronomers that are still struggling with heliocentricity, so I wouldn't feel too bad about the mistake you made :)
I can only imagine you've never tried to code against [X11] Kafka couldn't have done better.
I don't know. The client-server paradigm they use is pretty cool (even if they decide to swap the names around). I think if you really want Kafkaesque then you have to be an iphone user. Your arms and legs may no longer be in the place you expect them to be and and you're experiencing difficulty coordinating your extremities to perform what should be a mundane task, but still all you have in mind is asking Siri whether you can make the next train in time for work.
Newsworthy because its a load of kernel and other code ...
Yep. I haven't looked yet, but it seems that they'll have fixes for two problems I ran across...
1. No native kernel driver/firmware for some quite popular (read: cheap) wireless dongles.
2. Fix for excessive interrupt rate (dwc_otg.fiq_fix_enable=1 now the default) as mentioned in last paragraph.
I managed to find the fix for these myself thanks to the excellent forum and blog posts that people are making about the Pi, but it's certainly to be welcomed to have these baked in for less technically skilled users. As for the overclocking, the rpi version of xbmc has been overclocking to 800Ghz for quite a while (and there's been the option to do it in the /boot/config.txt in regular pi distros too). Nice to see that there's room to push the envelope even further and still be safe.
simultaneous events are ones which occur at the same time according to an observer
Hmm.. I was going to pounce on this and ask "yes, but relative to what observer?" My point being that simultaneity is a relative concept. Then I reread what you'd written and realised that you hadn't made the mistake I thought you had (when working in a relativistic framework).
Still, at least I get to post a link that explains it a little bit better
http://en.wikipedia.org/wiki/Ladder_paradox