Slashback: Squashing, N'Synch, Yopy

A quick Slashback for you this evening with more on the clones who won't get to be killed onscreen, the Yopy (alas!), hacking your PVR, and a skeptical reaction to recent claims of dramatically increased compression. Read on for the goods.

Waitaminute, what happens there between the "lead" stage and the "gold" stage again? HomerSimpson writes: "Recently on /. I read of a compression scheme reported to provide huge gains for the compression of random data. New Scientist reports, however, that the claims are unlikely at best."

Perhaps we can watch some other bands be slaughtered instead? eruditorium writes: "Apparently, the negative public reaction to n'sync's appearence in episode 2 has caused lucas to drop their cameo. See it here on Scifi Wire." san1701 links to another similar posting about this important issue at TheForce.Net.

On-again, off-again is not good for electronic projects. cd_Csc writes: "CNET is reporting on Samsung's newest Windows CE based PDA and mentioned (as a side note) that, 'A Samsung representative also confirmed the cancellation of Yopy, the company's planned Linux-based PDA.'"

Update: 01/11 02:41 GMT by T : Looks like it's not quite that simple: Bill Kendrick writes "LinuxDevices.com caught wind of today's Slashback regarding the Yopy PDA's demise.

Well, fortunately for Yopy fans, they got the real scoop directly from G.Mate..." Thanks for the quick response, Bill, and sorry for spreading false information.

Imagine explaining to your kids what VCRs were. jimmcq writes: "Slashdot previously ran a story asking about Hacking the New Replay TV Units. There have been several recent breakthroughs to allow a PC to emulate a Replay 4000 so that video can be shared in both directions. The source code has been released under the GPL. There are also several variations including a java version and an Apache/PHP Server."

Comments

re: compression

[loraksus]

This may be a bit off topic, actually I posted it on the original thread but got no responses -
and I was hoping for some /.'ers who have some math skills to give me some advice / explain why it is a bad idea (TM).

I'd like some fellow /.'ers to give me some advice on an idea for a "Kick Ass Compression" - appologies in advance for the clumsy language.

Take a block of data - throw it against an algorithm that outputs a specific value ( I'm thinking of CRC, MD5 hash or what not), do that several times against several different algorithms which generate a similar kind of value. Record the two (or more) values, then encapsulate the small block of data into larger blocks - I'm thinking only 3 or 4 levels of encapsulation would be needed (because if you calculated the crc of the entire file, a program could decide which choice (in decoding a "block" if there are multiple ones, which I'm fairly sure there will be) is correct.

Now people use md5 hashes/crc checks to verify whether the file they downloaded hasn't been modified, so I'm assuming that it is fairly difficult to get the exact value (especially with a known size). Using this "property" (I'm not sure if that is a correct word) you could decode the data into one of several (hundred??thousand??) byte streams (possibilities of uncompressed data) and by comparing byte streams between algorithm A and B, the byte streams would match at one (would it be possible to have more? I suppose it depends on the algorithms used) point, which would be the proper "uncompressed" (rather derived or something) data.

Basically there are many possibilities for each type of "hash", but if you compare the many output strings, you will eventually find matches.

I'm pretty sure it would take a shitload of computing power in decompressing - be horribly inefficient - but computers are fairly fast nowadays, and I think that this could be a viable at some point. 100:1 compression probably not, and there would be a lower limit imposed on the file size based on the possible choices (I think the possible choices would stretch to near infinity pretty fast, if anything, the computing time would set a "lower limit")

Maybe I'm just plain wrong - but could something like this be useable? Any advice / abuse would be appreciated :)
Thanks!

(Hmm.. a recent moderation of one of my comments, I found it quite funny)
Moderation Totals: Redundant=2, Insightful=1, Overrated=1, Underrated=1, Total=5.

Real compression from effnet inc.

[s0l0m0n]

Here's a story on eetimes concerning the compression of VoIP packet headers that claims a 40:2 ratio. Compressed Real-Time Protocol ain't a 100:1, but this is real technology that sounds like it will be in use by cisco and motorola pretty soon.

http://www.eetimes.com/story/OEG20020108S0054

The basic idea is that the compression of the packet header becomes more and more important as the compression of the payload of the packet also increases.. since the compression ratio for the actual data is already pretty good, effnet is working on compressing the packet headers with good success. They claim an increase in traffic over a t-1 from 90 VoIP channels up to 234..

that's real.

Re:How did *you* end up with mod points?? (n/t)

[TwistedKestrel]

Holy moly, folks! He was just posting an idea, wondering if it was valid. Now he knows it's not. You don't have to rip him apart!

Unseasonably Warm

[whjwhj]

From the unseasonably-warm dept.

Warm here in Minnesota too. If you've been paying any attention whatsoever to the weather in the last 10 years you have to wonder if climate change is playing a role. I'm convinced it is.

It's going to be pretty difficult for skeptics to argue the scientific merits of the "theory" of climate change when they can walk outside on any given day and experience it firsthand.

We need to do something about this pronto. Otherwise our descendents are going to have a lot more important things to chat about than compression schemes and pop bands.