Posts by Frumious Bandersnatch

"Your home is your safe haven"

Pshaww! It's my castle, and nothing less.

I will not have you denigrating the sanctity of my ancestral demesne, replacing it with the fig leaf of this "Safe Haven", as you call it.

(Gaston, fetchez la vache)

This particular FOI request

needed more chokey-points.

What's m2m?

moo to moo?

insanity

What big content want is end-to-end control of the entire distribution channel. This includes them having the ability to run arbitrary code on your machines. No doubt they will also continue lobbying until they get the next piece of the puzzle: namely, being able to bring you to court if you try to circumvent these "protections" on devices that you and you alone own.

Notwithstanding the fact that I'm sure that these "protections" will be easily defeated by simply lying to the EME code (supplying them with fixed DNS, time and random number generator) and replaying a valid authorisation exchange, nobody wants the kind of DRM that lets big media run whatever sort of code they want on their own machines. The only way that this scheme will not be easily defeated by an emulation-based environment is if the DRM hooks invasively into your OS. Remember the Sony rootkit fiasco? Well, maybe they said sorry, not our fault, but in their heart of hearts, this sort of invasive spyware is exactly the sort of thing that big media execs have wet dreams over.

Shame on Tim Berners-Lee.

Useless scientific factoids?

Well, a bell is a cup, until it's struck.

while meanwhile in a "proper" western democracy

The head honcho^Hhombre^Hstud is rolling back on anti-bribery regulations.

(example link, not vetted):

https://www.theguardian.com/us-news/2017/feb/14/donald-trump-anti-corruption-rules-dodd-frank-oil-companies

44 million years to get there at the speed of a standard jet aircraft

But how long by bus?

did he just ...

spin that Kodos and Kang bit from The Simpsons out to 6,000 words?

but tonight I say, we must move forward, not backward; upward, not forward; and always twirling, twirling, twirling towards freedom!

the undecideability problem

Dr. Fred Cohen talked about this way back at the start of the history of computer viruses. Simply put, if the virus writer has access to the scanner, they can detect it and abort doing something that will identify its presence. You still see that in modern malware, such as when it detects that it is running under a VM (common practice when trying to analyse the buggers), it will do something different than it normally would.

Putting a Post-It labelled "AI" on the black box that does the scanning does not change the fundamental nature of the setup. So long as the virus/malware (or its author) has access to the box, it can use it as an oracle and keep trying different behaviours until it finds something that isn't detected.

Not new, AFAIK

I'm pretty sure that I remember seeing reports of this before. Either that or it happened to me once (allegedly).

4d interferometry

AFAIK, pretty much all video codecs assume that the video to be compressed is 2D and intermediate frames only take account of the difference between one frame and the next. Both are reasonable simplifications if you want something that's fast to encode or decode, but they mean that a lot of exploitable structure is ignored. Another feature common to most codecs is that self-similarity within a frame is mostly ignored, with most focus being put on motion estimation as a way to compress inter-frame differences in common cases (eg, panning, moving objects within the frame).

If you think about algorithms that can turn images (or objects in them) into 3D approximations, this is a lot easier to do if you have a video camera attached to a vehicle (or carried) than if you present the algorithm with an unordered collection of stills of the same target from different vantage points. It's easier to reason about the relative motion of the camera between frames. It's going to be more smooth, and looking at a sequence of images it's going to be easier to divide up areas between static (modified only by relative viewpoint) and transient (moving objects passing through the frame).

If the cost of encoding isn't so much of a problem, you could apply interferometric analysis to a sequence of images. For the relatively fixed objects, you could build up a 3d approximation of those objects and generate a pixmap to skin them. Taking a sequence of images like this might also help to sharpen the image, hence cutting down on the amount of noise, leading to better compression. You can't sharpen single images, but you can with multi-sampling over time or slightly different viewpoints. To make interferometry work, you'd have to be able to adapt to things like focus and motion blur, detecting it on the way in (and tagging affected regions per frame) and adding it on the way out.

Videos also have various spatial self-similarities, besides the time-based ones. The most easily-exploitable option for compression is to assume that self-similar blocks will be neighbouring each other, and that's now most codecs work (mostly through compressing the palette across neighbouring blocks, AFAIK). If the codec tried representing areas as simple 3d meshes with pixmaps, then it could maintain a cache of these over an extended period. An algorithm would explicitly compress these mesh+pixmap objects based on their self-similarity. If a transient object moves across a surface, it wouldn't necessarily mean that the data about what's currently invisible due to the occlusion gets kicked out of the cache, meaning that once the transient object has passed, it should be cheap for the decoder to repair the "damage". Likewise with things like fast cuts, where the data for one bunch of frames can be re-used when the camera comes back to them a few seconds later rather than starting with a new key frame each time.

If encoding cost is no object, then you can try to reverse engineer lighting information from the original stream. When the contribution from lighting is removed from each area, you can compress the forest of mesh+pixmap cache objects much more efficiently. Or, you can use it to refine your idea of what a surface is by tesselating its original mesh and throwing out a lot of the pixmap data (which takes up a lot of space relative to a mesh + lighting model).

Going from (effectively) a simple block-based compressor to one with meshes, textures and lighting does, of course, make things a lot more costly for the decoder. Still, if there aren't too many light sources or reflectance, I could imagine a next-gen GPU managing to handle this. (Too much reflected light turns it into a generic ray tracer, which has very poor locality of memory references)

This sort of thing could handle fairly static objects, but there's also the problem of how to compress deformable objects like faces or the silhouettes of transient objects that aren't spatially modelled. Probably some completely different approach is warranted there.

This all sounds pretty pie in the sky, but getting an extra 30%-50% out of existing approaches probably won't be easy, IMO.

why

are they filtering text messages in the first place?

I know the article mentions "spam", but you don't filter spam by simple keyword searches.

(Reverend Bayes would be unimpressed)

Another option

Just adding an observation: git allows for shallow clones with 'git clone --depth 1'

For big projects, this won't have the same level of bandwidth saving as a custom lazy file system (as here) but it can still have huge savings over doing a full clone of a repo with a long history.

Doesn't seem very feasible

Initial big/little implementations basically hid the fact that there were 8 ARM cores running at the high (application) level, but later iterations let you use all cores at full tilt if you wanted, leaving the pairing of big/little cores (and transparent migration of processes between them) as more of a secondary option.

So that's how big/little seems to have panned out in practical terms in a purely ARM system.

The article suggests that somehow there can be transparent migration of workloads from high-draw Intel cores to low-draw ARM cores. This between systems that don't share an ABI or machine code or whatever. So how is that supposed to work? Some sort of qemu-like emulation of the workload? Even if it's only doing the translation once, I can't see how emulation is going to be power-efficient enough to warrant sticking in a new CPU.

I guess the other option is that there is no migration and that the hardware uses all native big/little ARM code. Sounds a bit like winmodems, and I don't mean that in a good way.

obligitory cultural references

#1 Zappa's Valley Girl

"You know me, I'm like into like the clean stuff. Like PAC-MAN and like, I don't know?"

#2 Marcus Bridgstocke's (him an his misplaced 'e') Fringe-worthy joke:

“If Pac-Man had affected us as kids, we'd all be running around in dark rooms, munching pills and listening to repetitive electronic music.”

a dearth of Scottish artists

I wonder was Arab Strap invited? Probably no, given the "Arab" in their name.

even a stopped clock

tells the right time three times a day