[14:40:48] <Soni> would quantum computers speed up the internet?
[14:40:56] <Lisimba> Not really.
[14:40:57] <Bucket> b-bu-but are you sure?
[14:41:27] <Soni> but quantum compression?
[14:41:32] <Lisimba> No.
[14:41:47] <mrkman> Ahrotahntee: morning, how goes
[14:42:05] <Lisimba> We can already compress generic data about as well as it theoretically can be compressed.
[14:42:15] <Soni> sending compressed qbits over the internet lets you have higher throughput than uncompressed qbits no?
[14:42:35] <Soni> or rather, the "quantum internet"
[14:42:35] <Lisimba> There are still advances to be made in lossy compression but it's not going to make a really big difference to general users.
[14:42:35] Derperperd [[email protected]] has quit IRC: Ping timeout: 180 seconds
[14:42:57] <Soni> Lisimba: lossless tho
[14:43:08] <Lisimba> I don't think you can send more data that way. You still have to collapse the qbits into ordinary bits.
[14:43:19] <Lisimba> Soni: losless compression is about as good as it gets already.
[14:43:19] <Soni> not if you send the qbits around
[14:43:32] <Lisimba> Yes, You have to collapse them on the receiving end.
[14:43:35] senki [[email protected]] has joined #xkcd
[14:43:38] justin [[email protected]] has joined #xkcd
[14:43:50] senki [[email protected]] has quit IRC: Quit: Textual IRC Client: www.textualapp.com
[14:43:54] <Lisimba> You're going to turn them into video or something.
[14:44:18] <Soni> yes, but you could send data for 20 subscribers with far less qbits than ordinary bits
[14:44:31] <Soni> then split and multiplex at the receiver
[14:44:40] <Lisimba> I don't think it works that way.
[14:45:29] <Soni> packet switched networks currently don't compress data across multiple ppl's packets
[14:45:37] <Soni> which is a waste of bandwidth
[14:45:51] <rcombs> Lisimba: I don't doubt we can have significant improvements in lossy compression, to the point that it makes a big difference to general users
[14:45:54] <Lisimba> Multicast is already a thing.
[14:46:05] <Ahrotahntee> morning mrkman
[14:46:12] <Ahrotahntee> guess who gets to go to the DC today!
[14:46:13] <rcombs> but I doubt that quantum computing will help
[14:46:16] <Soni> imagine if a massive flood DDoS sending the same data over and over again compressed into a single stream of DDoS and didn't affect the internet except for the sources of the DDoS and the target?
[14:46:20] <Ahrotahntee> I've never been to our DC
[14:46:26] <rcombs> and I also doubt it'll be because of any current codec
[14:46:29] <Ahrotahntee> I'm worried its going to look a lot like our wiring closet
[14:46:29] <rcombs> (HEVC is a meme)
[14:47:17] <Lisimba> rcombs: anything I'd want to receive lossy I can already receive easily at any sane bitrate. Compression will just help lower the bills for the hosting companies.
[14:47:42] <Lisimba> Of course a lot of people still have shit internet connections but that will improve over time as well.
[14:47:48] jooa [[email protected]] has quit IRC: Ping timeout: 180 seconds
[14:47:56] <mrkman> Ahrotahntee: fun, good luck there. i realyl wish i had taken a befoer picture of our DC and teleport wiring stuff. making huge strides on actually getting it colorcoded and organized
[14:47:57] <rcombs> Lisimba: smaller files or better quality or higher resolution, though
[14:48:15] <Soni> imagine if a massive flood DDoS sending the same data over and over again compressed into a single stream of DDoS and didn't affect the internet except for the sources of the DDoS and the target?
[14:48:16] <Lisimba> I don't need either better quality or higher resolution though. I'm basically capped by my monitor.
[14:48:39] <rcombs> oh, OK, I'm sure you'll never buy a new one of those
[14:48:41] <Lisimba> Soni: I don't think it works that way and even if it did you should just DDoS with random data.
[14:48:56] <Lisimba> rcombs: I expect I will but by then my connection will again be faster.
[14:49:01] <tonyb486> How much internet traffic is currently NOT compressed? HTTP requests are probably mostly gzipped text + jpegs, videos are mostly MPEG-4, AVC, or even HEVC.
[14:49:14] <rcombs> tonyb486: HTTP has built-in compression
[14:49:22] <rcombs> tonyb486: it's not required, but it's very broadly deployed
[14:49:29] Matthew-m [matthewmat@80B8EA2C:89CB669C:B298DC3D:IP] has quit IRC: Read error
[14:49:29] rymc-m [rymcmatrix@E9AF8D7D:89CB669C:B298DC3D:IP] has quit IRC: Read error
[14:49:29] Termy-m [termymatri@550606DE:89CB669C:B298DC3D:IP] has quit IRC: Read error
[14:49:29] BytesAndCoffee|Matrix [bytesandco@434E09F6:89CB669C:B298DC3D:IP] has quit IRC: Read error
[14:49:29] noname120-m [noname120m@42F9D384:89CB669C:B298DC3D:IP] has quit IRC: Read error
[14:49:29] eliudnir-m [eliudnirma@D603BAB8:89CB669C:B298DC3D:IP] has quit IRC: Read error
[14:49:29] tml-m [tmladekmat@A1138E13:89CB669C:B298DC3D:IP] has quit IRC: Read error
[14:49:34] <rcombs> (DEFLATE, which is iirc like gzip with different headers)
[14:49:34] <tonyb486> rcombs: yeah, thats what I meant by gzip
[14:49:36] <Soni> Lisimba: DDoS amplification is about sending the same data to multiple targets which then generate the same (or similar) data over and over again
[14:49:37] <tonyb486> oh
[14:49:38] <tonyb486> that too
[14:49:42] Matthew-m [matthewmat@80B8EA2C:89CB669C:B298DC3D:IP] has joined #xkcd
[14:49:45] Termy-m [termymatri@550606DE:89CB669C:B298DC3D:IP] has joined #xkcd
[14:49:49] BytesAndCoffee|Matrix [bytesandco@434E09F6:89CB669C:B298DC3D:IP] has joined #xkcd
[14:49:53] noname120-m [noname120m@42F9D384:89CB669C:B298DC3D:IP] has joined #xkcd
[14:49:53] <tonyb486> Like, browsers give the "Accept-Encoding: gzip, deflate" header
[14:49:54] <Soni> Lisimba: so, I'm pretty sure it would work
[14:49:56] rymc-m [rymcmatrix@E9AF8D7D:89CB669C:B298DC3D:IP] has joined #xkcd
[14:50:00] tml-m [tmladekmat@A1138E13:89CB669C:B298DC3D:IP] has joined #xkcd
[14:50:03] eliudnir-m [eliudnirma@D603BAB8:89CB669C:B298DC3D:IP] has joined #xkcd
[14:50:27] <Soni> Lisimba: also DDoSing is about nuking a target, disruption of everything else is supposedly a side-effect
[14:50:30] <Lisimba> Soni: amplification is about sending crap to some place and pretending you're another place so the first target sends a larger amount of data to the actual target. You don't necessarily need it to be similar or the same.
[14:50:58] <rcombs> tonyb486: also, HTTP/2 adds compression for _headers_, even
[14:50:59] <Soni> Lisimba: DNS amplification is about sending a list over and over again, it roughly never changes
[14:51:38] <tonyb486> rcombs: How does that avoid CRIME, anyway?
[14:51:39] <Lisimba> Soni: it's... not.
[14:52:33] <rcombs> tonyb486: it uses HPACK compression, which is specifically designed not to be vulnerable to that
[14:52:37] <tonyb486> neat
[14:52:38] <Soni> Lisimba: the DDoS traffic is far more than the normal requests, so at least half of all DNS amplification traffic is duplicates
[14:53:32] <Lisimba> It can be but it doesn't have to be.
[14:53:52] <Soni> it can be, and it *is*
[14:54:32] <Lisimba> In a DNS amplification attack I ask a shitty DNS server to send you the full details of a certain domain, which costs me a handful of bytes but gets perhaps several kilobytes sent to you.
[14:54:57] <Lisimba> I can request the same domain's info over and over, but I can also just go through the entire top 100k of sites or whatever.
[14:55:11] kegan [[email protected]] has quit IRC: Quit: Leaving
[14:55:14] <rcombs> works with NTP, too!
[14:55:32] <tonyb486> Soni: It can be but it doesn't *have* to be. If compression suddenly came into being that somehow mitigated a DNS-type Amplification attack based on similarity, one could probably just add some variety to the forged requests
[14:55:32] <Lisimba> Yeah NTP is even easier as the time already changes continuously.
[14:55:38] <Soni> or you can request the list of everyone who made a query, which is hopefully several megabytes instead
[14:55:51] <rcombs> mmmmmm, AXFRs
[14:56:12] <Soni> tonyb486: compression would still DDoS the target, it just wouldn't affect everything else
[14:56:29] <rcombs> how the hell is new compression gonna fix DNS amplification
[14:56:39] <rcombs> the problem is that the existing protocol is flawed
[14:56:51] <Soni> it'd compress the DDoS into a smaller DDoS and then expand it at the endpoint into the large DDoS it originally was
[14:57:03] <Lisimba> Soni: point is, if it becomes easier to mitigate because the data is the same, people will come up with various ways to make sure different data is sent.
[14:57:04] <rcombs> what are you gonna do, compress at the IP layer?
[14:57:16] <tonyb486> Soni: But if there is variety in the requests (simple), the data wouldn't even compress if you some how found a way to compress it at, like, the IP layer
[14:57:22] <Soni> compress at the internet core routers
[14:57:38] <rcombs> so now you're adding a feature to IP that everyone has to implement
[14:57:43] <Soni> nope
[14:57:46] <Soni> not even IP
[14:57:50] <rcombs> ethernet?
[14:57:51] <Bucket> ethernet is either net
[14:57:58] <Soni> yes, that would be an option
[14:58:01] <Lisimba> Just DDoS with encrypted data, then you can't compress fuck :-P
[14:58:18] <Soni> but nope, the compression would never reach the customer
[14:58:21] <Lisimba> Everything is going encrypted.
[14:58:46] <tonyb486> Ethernet packets are unpacked at each gateway, I'd imagine
[14:58:50] <Soni> it'd be compressed between internet routers
[14:59:02] ChapWithAHat-m [felixkelle@FE794AAA:89CB669C:B298DC3D:IP] has joined #xkcd
[14:59:07] <Soni> and uncompressed between the customer and ISP
[14:59:11] <rcombs> Lisimba: IPSec is a thing, even
[14:59:12] <Lisimba> That wouldn't help, you'd still overwhelm the active bits of the routers. Like tonyb486 says.
[15:00:05] <Soni> Lisimba: that's fine, it's still less likely to kill the whole internet because your 900Gbps DDoS was 900Gbps from start to finish instead of compressing that 900Gbps into something more like 100Gbps
[15:00:10] <rcombs> why spend CPU time trying to compress data that's increasingly incompressible when you can just improve your DoS detection and blackholing
[15:00:19] <rcombs> much cheaper than compressing
[15:00:59] <Lisimba> Soni: the routers that get overwhelmed *are* what kills the whole internet.
[15:01:24] <Lisimba> The whole internet is glued together by routers.
[15:01:25] <Soni> Lisimba: compressing so that they can still access the routing data without decompressing the whole thing would stop that from happening
[15:01:47] <Soni> they'd handle smaller packets with larger data
[15:01:56] <Lisimba> No, because something has to do the compressing and decompressing, and you'd overwhelm that.
[15:02:06] <Soni> implement it in hardware
[15:02:18] <Lisimba> ...it already IS implemented in hardwrae.
[15:02:23] <Soni> don't compress headers
[15:02:24] <Lisimba> That's why they are so bloody expensive.
[15:02:25] <Soni> problem solved
[15:02:25] <Bucket> 4826 new problems detected
[15:02:50] ChapWithAHat-m [felixkelle@FE794AAA:89CB669C:B298DC3D:IP] has left #xkcd: User left
[15:03:46] jooa [[email protected]] has joined #xkcd
[15:03:49] <rcombs> so we're
[15:03:56] <rcombs> - creating an extension to IP or ethernet
[15:04:04] <tonyb486> Soni: Not compressing the IP headers means we're now at the IP level, I think...
[15:04:27] <Soni> tonyb486: the routers can do the compression still, it doesn't have to be done by the computer
[15:04:48] <rcombs> - that has to be deployed across all the routers this is traveling through
[15:04:59] <Soni> rcombs: yeah, proprietarily
[15:05:01] <rcombs> - that has to compress transparently across multiple packets
[15:05:12] <Soni> that's fine
[15:05:12] <Bucket> NO IT'S NOT!!
[15:05:13] <rcombs> - for the sake of mitigating DDoS
[15:05:20] <Soni> perfect
[15:05:20] <Bucket> Just like rcombs!
[15:05:28] kegan [[email protected]] has joined #xkcd
[15:05:44] rcombs blinks several times
[15:05:56] <rcombs> and you think this is a _good_ idea
[15:05:59] <rcombs> ?
[15:06:29] <rcombs> if so, I have bad news
[15:06:55] squam [[email protected]] has joined #xkcd
[15:07:21] <Soni> since only the ISP would have to care about compression, it's fairly cheap
[15:07:29] <Soni> every other router just needs to know how to send the packets around
[15:07:32] <Soni> no decompression needed
[15:07:37] <rcombs> so this is entirely within a single ISP's network?
[15:07:48] <Soni> rcombs: it doesn't have to be, no
[15:08:05] <bassgoon> boob
[15:08:07] <rcombs> so then it has to be agreed upon by peered ISPs?
[15:08:12] <Soni> yes
[15:08:16] <Soni> which is fine
[15:08:25] justin [[email protected]] has quit IRC: Ping timeout: 180 seconds
[15:09:34] <rcombs> and this is supposed to compress across packets?
[15:09:42] <rcombs> have you considered the RAM requirements of such a thing
[15:09:48] <rcombs> at scale
[15:09:56] <Lisimba> rcombs: it'll be fixed by quantum, apparently.
[15:10:13] <Soni> yeah, no RAM requirements for internet routers
[15:10:16] <Soni> lots of RAM for ISPs
[15:10:19] <rcombs> QUANTUM RAM
[15:10:34] <Soni> easily doable
[15:10:39] sharkee gets popcorn
[15:10:59] rcombs raises hand
[15:11:00] Bucket calls on rcombs.
[15:11:05] <rcombs> as an ISP, why the hell would I implement this
[15:11:53] <Soni> so your data rates are faster and DDoS attempts don't affect your customers?
[15:12:24] <Lisimba> But they will because your gigantic ram machine still has to unpack a DDoS, which will nuke it.
[15:13:02] <Lisimba> Or you just get DDoSed by somewhere that doesn't compress.
[15:13:10] <Lisimba> Or by data that can't be compressed, like anything encrypted.
[15:13:42] <Soni> Lisimba: well you can compress encrypted data with quantum computers no?
[15:13:48] <Lisimba> No, you can't.
[15:13:49] <Bucket> http://www.youtube.com/watch?v=RpOUctySD68
[15:13:55] <Soni> why not?
[15:14:02] <Soni> quantum computers are good at detecting patterns
[15:14:10] <Lisimba> It has no patterns. That's the point.
[15:14:12] <tonyb486> If you can compress it, it's not encrypted enough
[15:14:15] <Lisimba> It's as good as purely random data.
[15:14:23] <Soni> it looks purely random
[15:14:33] <Soni> but what says a quantum computer can't see the non-randomness of it?
[15:14:44] <sharkee> then the encryption is useless
[15:14:45] <Lisimba> Theoretical computer science says.
[15:14:47] <tonyb486> It can compress it by decrypting it, and compressing the decrypted data
[15:15:00] OnVar_ [[email protected]] has quit IRC: Quit: Lost terminal
[15:15:09] <Soni> ok look
[15:15:09] <Lisimba> tonyb486: you gonna give the core routers your keys? :-P
[15:15:20] <tonyb486> Lisimba: :p
[15:15:20] <Soni> if you're using an OTP, sure
[15:15:40] <tonyb486> I meant, what Soni is proposing is equivalent to a quantum computer deriving the key
[15:15:44] <Soni> if you're using AES-256 you only have 256 bits of true randomness, called the seed
[15:16:07] <Soni> (oversimplifying)
[15:16:36] <Soni> surely a quantum computer can compress AES?
[15:16:38] <Lisimba> Yeah, you could possibly break the encryption entirely. At which point it's considered useless and people will upgrade to something you can't break.
[15:16:44] <Lisimba> So no.
[15:16:53] <sharkee> the first thing that will drop dead with quantum computing is encryption as we know it now
[15:17:00] <Xenos> Nah
[15:17:17] matsmeeus [[email protected]] has joined #xkcd
[15:17:22] <Xenos> Just public keys, symmetric keys will work fine
[15:17:31] <Xenos> And they're working around other problems as well
[15:17:36] <sharkee> ok, fair enough
[15:17:37] <tonyb486> If they're fine, then the quantum computer still couldn't compress it, probably
[15:17:47] <Xenos> Plenty of quantum safe encryption
[15:18:01] <tonyb486> You can't have it both ways, either the quantum computer sees it as randomness, or it is not a suitable encryption anymore
[15:18:11] <mercury> Xenos: isn't that something which can only be proved with time?
[15:18:33] <Xenos> mercury: We've been writing quantum algorithms and working out what's possible since the 70ies
[15:18:50] <Oterion> hmm have glass and ceramics suddenly gotten cheaper? i've noticed over the last year or so there's lots of products available in glass or terracotta pots/jars (clearly designed to only be used the once) that previously would have been sold in plastic tubs. or has some marketing firm somewhere started a fad?
[15:19:06] <Xenos> mercury: There's a limited subclass of problems that get a vast speedup with quantum computing - outside those it's no better
[15:19:12] <mercury> Xenos: how much of this is theoretical?
[15:19:18] <rcombs> Soni: are you seriously saying we should break AES on the way in and out of every ISP
[15:19:19] Derperperd [[email protected]] has joined #xkcd
[15:19:30] squam [[email protected]] has quit IRC: Ping timeout: 180 seconds
[15:19:31] <rcombs> to solve DDoS
[15:19:33] <sharkee> but for the sake of 'encrypting a DDOS to make it harder to confuse a quantum computer', current standards are useless
[15:19:38] <sharkee> ^this
[15:19:39] <Soni> look
[15:19:49] mercury looks
[15:19:52] <Soni> just because you can compress something, doesn't mean that what you compressed is breakable
[15:20:00] jooa [[email protected]] has quit IRC: Read error
[15:20:11] <Xenos> mercury: Since our most complex true quantum computer has been just a couple of qbits for a matter of minutes, nearly everything's theoretical
[15:20:19] <Soni> just because there's a pattern, doesn't mean you decoded that pattern
[15:20:29] <Soni> it's like EBCDIC really
[15:20:34] <Lisimba> Soni: what we're saying is, if you can compress it it's not encrypted properly.
[15:20:41] jooa [[email protected]] has joined #xkcd
[15:20:42] <Xenos> The "Quantum Computers" in production you may have heard about are quantum annealing computers, which is something different
[15:21:11] <rcombs> AES-256 is still comfortably secure against quantum computers
[15:21:24] <Xenos> And generally useless against these kinds of problems
[15:21:24] <rcombs> AES-128 is threatened by it, but definitely not _trivial_
[15:21:27] <Lisimba> If there is a pattern, either the pattern is always the same in which case the encryption algorithm is stupid, or the pattern changes with your input data, in which case you're leaking and your algorithm is bad.
[15:21:29] <mercury> Xenos: Thanks, reading up on this is on my todo list.
[15:21:32] SpicyLemon [[email protected]] has joined #xkcd
[15:21:33] <rcombs> certainly not "break it on the way in and out of the ISP" trivial
[15:21:34] <Soni> you might compress it, NOT get the right key, AND get a pattern that doesn't look ANYTHING like the original data
[15:21:50] <Soni> so it'd still be safe
[15:22:01] <Soni> just compressed *somehow*
[15:22:04] <Lisimba> So if you're able to find a pattern *at all*, the encryption needs to be replaced.
[15:22:17] <Xenos> mercury: I've been trying to wrap my head around what quantum computing is and isn't for years now.
[15:22:19] <rcombs> and once quantum computers are at the point where AES-128 is actually threatened by them, people will _move off of AES-128_
[15:22:20] <Soni> and the pattern isn't reusable because ov IVs
[15:22:28] <mercury> On the compression thing, aren't you going to exchange killing a services with too much traffic, with killing a service by needed too much CPU to decompress traffic?
[15:22:33] templari [[email protected]] has joined #xkcd
[15:22:41] <Soni> mercury: yeah
[15:22:47] <Soni> but it doesn't kill everyone else while at it
[15:23:06] <thunkyi> good night
[15:23:07] <Bucket> Good night, good night! Parting is such sweet sorrow.
[15:23:11] <Xenos> Nite thunkyi
[15:23:16] <mercury> g'nite
[15:23:17] <Bucket> ˙pıɐs ʇsnɾ noʎ ƃuıɥʇ ǝɥʇ ɥʇıʍ ʇɥƃıɹ ƃuıɥʇou sı ǝɹǝɥʇ
[15:23:40] <rcombs> this is stupidly expensive and requires reinventing half the internet
[15:23:47] <rcombs> and DDoS filtering is _already a thing_
[15:23:56] <rcombs> and does _not_ require stupid amounts of RAM and CPU time
[15:24:10] <Soni> rcombs: it's the good ol' tradeoff
[15:24:10] <rcombs> just some heuristics and filtering rules
[15:24:14] <Lisimba> Or breaking encryption.
[15:24:20] <Soni> you can use more RAM to save CPU time, or use more CPU time to save RAM
[15:24:36] <Xenos> Soni: Or you can do something that works instead
[15:24:39] thunkyi [[email protected]] has quit IRC: Quit: http://www.kiwiirc.com/ - A hand crafted IRC client
[15:24:40] <Soni> in this case you can use more CPU and RAM to save bandwidth, or use bandwidth to save CPU and RAM
[15:24:41] <rcombs> Soni: that is not universally true
[15:24:46] <rcombs> Soni: compression needs RAM
[15:24:54] <Soni> rcombs: V8 needs RAM
[15:24:57] <mercury> But for this to work, your attack would have to come from someone that had implimented this.
[15:24:58] <rcombs> sure, you could use _more_ RAM for some things
[15:24:59] <Soni> because it doesn't wanna waste CPU time
[15:25:05] <rcombs> or _more_ CPU time
[15:25:16] <rcombs> and some specific algorithms involved have that tradeoff
[15:25:27] <rcombs> but compression inherently requires significant amounts of RAM
[15:25:33] <rcombs> you can't just trade it all for CPU time
[15:25:36] <Xenos> And bandwidth is getting cheaper by the hour
[15:25:38] <mercury> getting anything like this implimentd universaly is practically impossible, so people will just attack from somewhere that hasn't impliment it
[15:25:38] <rcombs> and even if you could, that's also expensive
[15:25:40] <Soni> uh I mean
[15:25:50] <Lisimba> You can't compress my packets using packets I sent ten seconds ago if you only store a second worth of packets, no matter how much CPU you throw at it.
[15:25:56] <Soni> in theory you could do low-RAM compression by using 2000x as much CPU time
[15:26:03] <rcombs> no you can't
[15:26:04] <Bucket> http://www.youtube.com/watch?v=RpOUctySD68
[15:26:11] <rcombs> for the extremely obvious reason Lisimba just stated
[15:26:19] <Soni> rcombs: uh yes you can
[15:26:24] <rcombs> you can't compress across data that you don't have
[15:26:31] SpicyLemon [[email protected]] has quit IRC: Quit: http://www.mibbit.com ajax IRC Client
[15:26:42] <Soni> no but you only need enough RAM for the data you have
[15:26:58] <rcombs> plus your state, but yeah
[15:26:59] <Lisimba> Which means your compression will become shitter.
[15:27:00] <Soni> and a tiny bit of scratch space (usually in the form of registers)
[15:27:01] <rcombs> that's a _lot_
[15:27:05] <Lisimba> You can't fix that by throwing CPU at it.
[15:27:17] <rcombs> internet routers process fucktons of data
[15:27:23] <Soni> then you basically create the compressed file one bit at a time
[15:27:34] <Soni> and use the compressed file itself as the state
[15:27:44] <rcombs> that's… not how anything works
[15:27:45] <Soni> takes forever, but possible
[15:27:51] <Lisimba> Where do you store that file? In ram?
[15:27:52] <rcombs> unless you're using a fixed codebook
[15:28:05] <rcombs> which is useless at general-purpose compression
[15:28:08] <Soni> Lisimba: replace the data with the compressed file as you go processing the data
[15:28:25] <Lisimba> So now you need to fit the entire file in ram?
[15:28:32] <Soni> use the scratch space to store parts when moving them around
[15:28:45] <rcombs> I'm not convinced you know how lossless compression works
[15:28:48] <Lisimba> How the hell does this even make sense in the context of packets?
[15:28:53] <Soni> Lisimba: not really, but you do need a storage medium
[15:29:09] <Soni> Lisimba: it doesn't
[15:29:10] <Bucket> ¡ǝpnʇıʇʇɐ ʇɐɥʇ ɥʇıʍ ʇou
[15:29:21] <Soni> I'm just saying compression can work with low RAM, it'll just take forever
[15:29:37] <mercury> where do I sign? ;)
[15:29:40] <Soni> it's very low-throughput
[15:29:41] <Lisimba> But you just said you'd load the entire file in ram.
[15:29:48] <Lisimba> That's not low ram, that's really high ram.
[15:29:49] <rcombs> "lol you don't need loads of RAM if you swap all to hell"
[15:29:59] <Soni> Lisimba: technically, you don't need any RAM
[15:30:01] <Soni> you have a file
[15:30:07] <Soni> you have a bit of RAM as scratch space
[15:30:08] <rcombs> ^ this guy, who's proposing IP- or ethernet-level compression at the ISP level
[15:30:11] <Soni> make sure the file is mutable
[15:30:24] <rcombs> "who needs RAM when you can mmap()"
[15:30:28] <Soni> the file is effectively the RAM you use for the compression, the scratch space is just so you have room to work with
[15:30:39] <Lisimba> Soni: for the point of this discussion, any accessible data is counted as storage. Doesn't matter if it's ram or disk.
[15:30:46] <Soni> then you just need to slowly but surely replace the file with the compressed file
[15:30:50] <Lisimba> A low ram algorithm *does not have access to anything else*.
[15:31:09] <djh> And if I plug my UPS into itself, it'll generate power forever, right?
[15:31:11] <rcombs> oh boy, now you effectively have a ton of RAM but it's all extremely shitty
[15:31:13] matsmeeus1 [[email protected]] has joined #xkcd
[15:31:13] Clones for matsmeeus1: matsmeeus
[15:31:25] <rcombs> and, for some reason, non-volatile
[15:31:27] <Lisimba> You get fed, for example, sixteen bytes of input at once, which you have to compress and then output, and you can then no longer access either that input or output.
[15:31:43] <Soni> no, you have a buffer
[15:31:43] <rcombs> also, huzzah, we're adding latency!
[15:31:46] <Soni> it's a mutable buffer
[15:31:49] <rcombs> I love adding latency for no reason
[15:31:50] <Soni> you compress that buffer in-place
[15:31:51] <Lisimba> Your buffer is ram.
[15:31:53] <rcombs> it's my favorite pastime
[15:31:59] <Soni> no, your buffer is a buffer
[15:32:08] <Soni> you need large amounts of RAM to compress a stream in reasonable time
[15:32:10] <Lisimba> No. Any data you can access counts as ram for the algorithm.
[15:32:17] matsmeeus [[email protected]] has quit IRC: Ping timeout: 180 seconds
[15:32:25] <Soni> you need very little RAM to compress a buffer in unreasonable time
[15:32:45] <Lisimba> The buffer counts as ram.
[15:32:54] <Lisimba> Or storage in general. Whatever.
[15:32:55] <Soni> no it doesn't, prove it
[15:32:56] <mercury> sorry buffer = ram
[15:33:08] <rcombs> Soni: well where else is it
[15:33:19] <mercury> ok, if it isn't ram, then what is it?
[15:33:21] <mercury> disk?
[15:33:21] <Lisimba> Ram, disk, implementation details.
[15:33:26] <Soni> ok so
[15:33:30] <Soni> given a turing machine
[15:33:33] <djh> maybe the CPU has a really big register for buffering ;)
[15:33:34] <rcombs> are you writing to disk on your routers?
[15:33:35] <Soni> with a tape loaded with a file
[15:33:46] <Lisimba> When we talk about this sort of thing, what actually matters is how many bytes are accessible to the algorithm. You can't cheat by sticking it in a different type of storage.
[15:33:51] <rcombs> your routers don't have tape decks
[15:33:53] <mercury> rcombs: you said you like latency
[15:33:56] <rcombs> so this is right out already
[15:33:59] <Soni> your algorithm needs very little additional RAM/tape to compress that file
[15:34:02] <Soni> it'll just take forever
[15:34:11] <Lisimba> Soni: the tape *is* the ram of the turing machine.
[15:34:19] <Soni> the contents of the tape = the input, at the start of the program, and the output, at the end of the program
[15:34:26] templari [[email protected]] has quit IRC: Ping timeout: 180 seconds
[15:34:27] <mercury> I've got it. We need to add punch cards
[15:34:36] <rcombs> if we're compressing across packets we need to store those packets
[15:34:39] <Soni> Lisimba: again, this is memory mapped I/O
[15:34:43] <tonyb486> mercury: Why not mercury delay lines?
[15:34:48] <Lisimba> Soni: again, it counts as ram anyway.
[15:34:53] <rcombs> Soni: *blinks*
[15:34:53] <Soni> Lisimba: no it doesn't
[15:34:54] <Bucket> DOES TOO
[15:34:57] <Lisimba> Or storage. Whatever.
[15:35:06] <rcombs> Soni: have you ever actually used memory-mapped I/O
[15:35:11] <mercury> we then mail them to the receiving router
[15:35:23] <Soni> Lisimba: it's basically brainfuck's . and , but with a seek operation
[15:35:24] <Lisimba> Soni: when we're talking about algorithms, it does not matter how you physically store shit, all that matters is whether you have it available or not. You can't cheat by memory mapping files.
[15:35:25] <mercury> if they are a ddos, we don't load the punch card
[15:35:29] <Xenos> mercury: Using pigeons
[15:35:42] <sharkee> encrypted pigeons..
[15:35:53] <mercury> https://en.wikipedia.org/wiki/IP_over_Avian_Carriers
[15:35:56] <tonyb486> RFC 1189
[15:36:00] <mercury> an oldy but a goody
[15:36:26] <Soni> it's not suitable for compressing streams because streams would give you only a single bit of buffer
[15:36:40] <mercury> But anyone looking at this would be foolish not to go with RFC2549
[15:36:40] <Xenos> sharkee: Encrypted pigeons? You blend them before sending them off? :-p
[15:36:41] <tonyb486> 1149*
[15:36:42] <Soni> but if you have the whole file, you can compress it in-place with very little additional RAM
[15:36:45] <Lisimba> Okay, I move that Soni has no clue what the fuck they're talking about. All in favor?
[15:36:54] <mercury> OOOh, I have a good blander
[15:36:56] djh receives pigeon with HTTP status 418 and becomes further confused
[15:36:56] moonseeker [[email protected]] has joined #xkcd
[15:36:57] <rcombs> aye
[15:36:59] Xenos raises a hand
[15:36:59] <Bucket> Yes, you there in the back.
[15:37:12] <mercury> I could start a PBaaS offering
[15:37:24] <Xenos> Pigeon teapot
[15:37:28] <Lisimba> Motion carries, discussion over due to being useless.
[15:37:32] <Soni> you know how wikipedia lists algorithms as "O(logn) time complexity, O(1) additional space", etc?
[15:37:40] <mercury> Pigeon Blanding as a Service
[15:37:41] <sharkee> Xenos: yes, a quantom computer will easily put them back together, as the bits all contain DNA
[15:37:48] <mercury> *Blending
[15:38:09] <djh> they did recently store data in bacterial DNA, grow them for a few generations, then read back out the data, IIRC
[15:38:19] <The0x539> Will It Bland
[15:38:54] <Soni> you can compress a file, in-place (aka you have access to the whole file), with O(unbounded) time complexity and O(1) additional space
[15:38:55] <mercury> djh: most of the routers I've worked with were full of dust, and I assume, bacteria
[15:39:07] <djh> mercury: did any of them give rise to a Dust Puppy?
[15:39:13] <Lisimba> There are laboratory devices marketed by how well they can turn a rat into a smoothie.
[15:39:32] <Xenos> Yum
[15:39:32] The0x539 grimaces
[15:39:32] <Bucket> ಠ益ಠ
[15:39:34] <Lisimba> I assume they could handle a pigeon as well.
[15:39:53] <mercury> djh: we took turns feeding them
[15:40:02] <tonyb486> If the DDoS packets are too heavy for the pidgeon, they'll simply be dropped .. on to the street, presumably
[15:40:24] <Xenos> So you risk getting DDoSed from above outside IRL?
[15:40:32] <Xenos> This somehow doesn't seem like an improvement
[15:40:47] <mercury> Xenos: That depends on how much you like Pigeon Pie
[15:40:49] <Soni> do any of YOU know what you're talking about?
[15:41:03] <mercury> Soni: Been doing IP networks for 20 years
[15:41:08] <mercury> so I like to think so, yes
[15:41:09] <sharkee> Soni, followed your trail of random ideas from quantum networking over encrypted DDOS attacks to using tape as RAM, I think it's enough now.
[15:41:16] <sharkee> *we followed
[15:41:18] djh is looking forward to Mars colonization leading to interplanetary netowrking
[15:41:26] <rcombs> Soni: using what algorithm
[15:42:16] <rcombs> Soni: and what is our "file" in this context? An individual packet?
[15:42:26] <djh> ..I thought that discussion was ended? :P
[15:42:31] <Soni> rcombs: there are many algorithms that produce compatibly compressed data
[15:42:39] <Lisimba> Yeah. Let's continue talking about blending small animals.
[15:42:46] <Xenos> Better
[15:42:50] <rcombs> compressing an individual packet is (a) extremely difficult and (b) extremely useless
[15:42:50] <Soni> there are many ways to implement GZIP, some of them are patented while others are not
[15:43:01] Xenos blends Soni
[15:43:04] djh proposes blending a sponge and watching it regrow
[15:43:09] <Soni> and this has nothing to do with packets, it has to do with theory
[15:43:25] <mercury> Soni: I've also done /a lot/ of technical reviews for organisations you will have heard of. If you want to write a paper, I'll review it.
[15:44:15] Xenos ponders if djh will regrow if blended, and considers experimenting
[15:44:21] <mercury> but line by line on IRC, does not make for a solid or coherent argument
[15:44:32] <djh> sadly, I'm neither sponge nor Wolverine
[15:44:48] <Soni> also I wouldn't wanna write such an algorithm because it'd have a lot of compression, decompression, and recompression steps
[15:44:53] <rcombs> if we're O(1) in packet size, we're O(n) in number of packets
[15:45:00] <Soni> since it basically has to work with compressed data *as* RAM
[15:45:05] <rcombs> which is still a fuckton and still useless
[15:45:08] Xenos grabs his CRISPR-CAS9 kit and proceeds to add sponge DNA to djh
[15:45:36] <djh> ...I doubt there's many genes a sponge has that I don't, they're very primitive animals..
[15:45:42] <djh> I'm not actually sure, tho
[15:45:46] djh ponders
[15:45:47] <Bucket> Are you pondering what I'm pondering, djh?
[15:46:01] <sharkee> Blending Wolverine will dramatically shorten the lifetime of your blender.
[15:46:02] <tonyb486> He's replacing some of your more ... expressed genes with sponge ones
[15:46:05] <rcombs> did I just read "data *as* RAM"
[15:46:12] Xenos revvs the V-8 engine on his blender
[15:46:21] <Lisimba> djh: sponges have 70% in common with humans.
[15:46:27] <djh> Lisimba: huh
[15:46:37] <djh> Lisimba: their 70% or ours?
[15:46:38] <tonyb486> Does that explain why I'm so absorbant?
[15:46:39] <Lisimba> their
[15:46:45] <Lisimba> They have 30% that we don't.
[15:46:46] <Soni> rcombs: "*compressed* data as RAM"
[15:46:56] <puddle>  http://i.imgur.com/BWXtuAR.jpg "Caught this moment between my rescue cats."
[15:46:59] <puddle> http://i.imgur.com/Vl91Tlr.jpg "Look at me. I'm the laptop meow"
[15:47:07] <tonyb486> oh look its a puppy
[15:47:19] <mercury> Soni: How else does one compress, if not from data in RAM?
[15:47:30] Wurstbruch [Wurstbruch@156FFD15:E2B57F1B:2275E99D:IP] has joined #xkcd
[15:48:56] <Soni> mercury: if you treat the compressed data as the sliding window, and when searching for matches you search the compressed data...
[15:49:07] <Soni> it'll work, very slowly and painfully
[15:49:40] <rcombs> where do you put your codebook
[15:50:17] <Lisimba> In the swap file, of course.
[15:50:31] <djh> it's easy, you just *handwave* it
[15:50:38] <rcombs> and even if you ignore that, you still need to store the packets themselves in memory for this to be useful
[15:50:41] <Soni> rcombs: the codebook is in the compressed data, clearly
[15:50:56] <Soni> so, yes, it's very slow
[15:50:59] <rcombs> since as mentioned previously, this compression is useless if it's stateless
[15:51:02] <Soni> and the code is a painful mess
[15:51:05] <Xenos> Soni: And.. how do you access that without uncompressing the data into RAM?
[15:51:07] <Soni> but technically possible
[15:51:15] <Soni> Xenos: you don't need to uncompress the whole thing
[15:51:23] <puddle> http://i.imgur.com/FMVnv55.jpg "Cat."
[15:51:24] <mercury> Soni: That wasn't what I asked, also, whey would you ever do this?
[15:51:26] <Soni> you just need to partially uncompress the data you wanna access
[15:51:37] <Soni> like, uncompress a few bits or bytes at a time
[15:52:00] <Soni> mercury: "because I can"
[15:52:07] <Soni> and "because it's technically possible"
[15:52:11] <puddle> http://i.imgur.com/jvO2PT3.jpg "Cat."
[15:52:12] <rcombs> I'm pretty sure you can't
[15:52:19] <sharkee> that's not how compression works, right?
[15:52:33] <rcombs> even if, at a technical level, any of this as possible, I'm not at all convinced that _you_ can
[15:52:47] <Soni> Xenos: and if it fails you need to uncompress part of the file and recompress it using a different heuristic
[15:52:50] <djh> I'm not recongising any kind of compression I'm familiar with as one that could do what Soni wants it to
[15:52:52] <Soni> in other words, very slow
[15:53:20] <Soni> but should be doable in O(unbounded) time and O(1) additional space
[15:53:25] <moonseeker> wait, so you're decompressing data using a compressed compression algorithm?
[15:53:45] <Lisimba> A more important point is even if you do this, for algorithm analysis purposes the size of the file still counts as required storage, which makes it a very high memory algorithm.
[15:53:55] <sharkee> 'uncompress a few bits'.. so take random following bits and making them 'bigger' (turning them into more data) without context?
[15:54:07] <Xenos> Soni: I heard you like compression so I put some compression in your compression
[15:54:09] <mercury> Soni: "Because I can" is rarely a sound reason for any engineering choice
[15:54:09] <tonyb486> Is O(unbounded) literally forever?
[15:54:19] <sharkee> compression needs context
[15:54:37] <sharkee> but I digress. how about blending... whales?
[15:54:54] <Lisimba> Sperm or blue?
[15:54:55] <Palomides> depends on your definition of blend
[15:55:02] <rcombs> blend sperm
[15:55:05] <Palomides> I feel like one of those grinders used for processing cars would work okay
[15:55:13] <djh> rcombs: there are photos of that happening on the internet!
[15:55:13] <sharkee> oh god, the mess...
[15:55:15] <Palomides> or, like, explosives
[15:55:19] <rcombs> clean your blender well afterwards
[15:55:25] <rcombs> oh speaking of explosives
[15:55:27] <Lisimba> Palomides: they tried explosives, it does not work well.
[15:55:31] <rcombs> I ordered some ammonium nitrate
[15:55:37] <Soni> Lisimba: O(n) memory, O(1) ADDITIONAL memory
[15:55:38] <djh> rcombs: ..why?
[15:55:40] <rcombs> what precautions should I take to avoid accidentally losing fingers
[15:55:51] <djh> "don't order ammonium nitrate" for starters ;)
[15:55:52] <rcombs> djh: its reaction with water is endothermic
[15:55:58] <Lisimba> Soni: which is pointless.
[15:56:00] <Palomides> I dunno, don't whales explode occasionally?
[15:56:16] <mercury> rcombs: I'd start by not ordering ammonium nitrate
[15:56:18] <Soni> Lisimba: it's an example of trading CPU time for RAM
[15:56:23] <djh> burst more than explode..
[15:56:48] <Lisimba> Soni: when we talk about trading cpu time for ram we include EVERY type of storage in ram. It's just for any sane sort of implementation the ram will be actual ram and not a swap file or whatever.
[15:57:05] <Soni> Lisimba: you could do O(n^2) memory and O(nlogn) runtime, or you could do O(n) memory and O(unbounded) runtime
[15:57:06] <Lisimba> So we say ram, but we really mean memory.
[15:57:19] <djh> Lisimba: or just "storage"
[15:57:28] sharkee blends furiously
[15:57:46] <Lisimba> And as you can see you have not reduced the storage requirements (yeah that works too) at all.
[15:57:54] Wurstbruch [Wurstbruch@156FFD15:E2B57F1B:2275E99D:IP] has quit IRC: Quit: Wurstbruch
[15:58:07] <Lisimba> In fact yours is way worse than most algorithms, which can stream compress with a window of, say, a couple kilobytes to a couple megabytes.
[15:58:09] <rcombs> you could also do O(unbounded) memory and O(unbounded) time
[15:58:12] <rcombs> and it would be just as useful
[15:58:38] <Soni> it's not meant to be useful
[15:58:52] <Soni> it's meant to be an example of trading time for space
[15:59:03] <Soni> huh, trading time for space...
[15:59:06] <Lisimba> And once you count all types of storage as storage and stop trying to cheat your way out, you'll find you can't always make this tradeoff.
[15:59:10] <Soni> is that possible in physics?
[15:59:14] <rcombs> OK let me adjust my line from earlier
[15:59:31] <rcombs>  <rcombs> you can't just trade it all for CPU time
[15:59:31] <rcombs> ^ you can't just trade it all for CPU time _and still have your algorithm be useful_
[15:59:38] <rcombs> happy
[15:59:56] <Soni> rcombs: I *know*, do you know what "technically" means?
[15:59:59] <rcombs> also I'm unconvinced that you can just trade it all for CPU time and still have it be equivalently performant
[16:00:09] <rcombs> Soni: it means "I'm a fuckwit"
[16:00:17] <Soni> https://xkcd.com/1475/
[16:00:19] <Lisimba> There are things where you can't do something *at all* if you lower the storage enough.
[16:00:25] <Lisimba> No matter how much cpu you throw at it.
[16:00:37] <Palomides> make a prng that generates the data
[16:00:45] <rcombs> like, H.264 requires a particular amount of storage for the decoded picture buffer to decompress
[16:01:03] <Soni> I did say "compression", not "decompression"
[16:01:11] <rcombs> it also requires you to buffer frames
[16:01:12] <Soni> obviously you need more space if you wanna decompress something
[16:01:15] <rcombs> when compressing
[16:01:29] <rcombs> H.264 encoders use more RAM than decoders
[16:01:44] <Lisimba> You can't delta compress against previous frames if you do not have the storage to store those frames somehow.
[16:01:45] <Soni> it *requires* it, as in you can't do it without? or you can't do it in a reasonable time without?
[16:01:55] <rcombs> as in you can't do it without
[16:02:00] <Soni> prove it
[16:02:01] <Bucket> http://www.cut-the-knot.org/proofs/sq_root.shtml
[16:02:04] <Lisimba> I just did.
[16:02:05] <Bucket> I just did would be a good name for a band
[16:02:08] <rcombs> you need to buffer frames to do inter-frame compression
[16:02:12] <mercury> Yeah, what Lisimba said
[16:02:14] <Soni> no
[16:02:23] <Soni> you need to decompress frames to do inter-frame-compression
[16:02:29] <rcombs> wat
[16:02:29] <Soni> it'll just be very slow
[16:02:34] <Lisimba> You need access to those frames, whether they are compressed or not.
[16:02:34] <rcombs> the input is uncompressed
[16:02:38] <Lisimba> Which means you need storage.
[16:02:49] <Lisimba> Once again, you can't cheat by using external storage. It still counts as storage.
[16:02:51] <Soni> yes, but assuming you're replacing the input in-place, you have access to the data you just changed
[16:02:56] <rcombs> you can't do that
[16:02:57] <Bucket> I rode a donkey to Mexico!  I can do anything!
[16:02:59] <rcombs> the compression is lossy
[16:03:00] <Soni> yeah you can
[16:03:03] <Lisimba> Which adds all that storage to the requirements of the algorithm.
[16:03:04] <Soni> uh yeah
[16:03:07] <Lisimba> We're going in circles here.
[16:03:09] <Soni> you lose the original data, but you can still do it
[16:03:18] <rcombs> you need to reference the original data
[16:03:25] <rcombs> if you replace it in-place then you can't do that
[16:03:26] <Soni> uh no not really
[16:03:39] <Soni> you just won't get as good quality as a normal algorithm
[16:03:46] <Soni> which is fine
[16:03:48] <rcombs> that's my whole poingt
[16:03:51] <rcombs> *point
[16:03:52] <Soni> it's a LOSSY algorithm
[16:04:03] <rcombs> you can't get equivalent compression performance without additional RAM
[16:04:07] <djh> Soni: You appear to be arguing that there's a way to handle a situation like "The number is five. Double the number" when you only have access to the second sentence.
[16:04:08] <Soni> a very slow one and it also doesn't give good quality
[16:04:09] <rcombs> even with infinite time
[16:04:12] <Lisimba> Soni: well, so you admit you can't do *at all* what the original algorithm does?
[16:04:18] <Soni> rcombs: I never said anything about equivalent performance
[16:04:24] <Soni> just that it's doable
[16:04:36] <mercury> OK Soni, build it.
[16:05:07] <mercury> then we'll see. Otherwise this is just people giving reasons what something won't work, and you disagreeing
[16:05:11] <Soni> also, you could compress with an intermediary(?) lossless algorithm and use that to get extra RAM
[16:05:24] <rcombs> not reliably
[16:05:25] <Soni> still O(1) additional space but much higher time complexity
[16:05:34] <rcombs> your assertion appears to be that you can always build useless things
[16:05:47] DHeadshot [[email protected]] has joined #xkcd
[16:05:56] <Soni> rcombs: it's useless, but it technically does what it's supposed to do
[16:06:00] <Lisimba> We know you can make tradeoffs between time and memory. The original point is that you can't always make those tradeoffs.
[16:06:12] <rcombs> by our working definition, I can build a compressor that runs in O(0) time with O(0) memory
[16:06:17] <rcombs> it also takes up 0 bytes of space
[16:06:17] <Soni> Lisimba: you can make them, you can't always make them usefully
[16:06:42] <Lisimba> Soni: no, you can't make them at all. Swapping out the algorithm for a different algorithm that does something different does not count, that'd be silly.
[16:06:56] <rcombs> so we're not purely trading CPU for RAM
[16:07:06] <rcombs> we're trading CPU and compression efficiency for RAM
[16:07:10] <Soni> swapping out the algorithm for a different algorithm that does the same thing but much, much, MUCH slower isn't useful
[16:07:16] <bassgoon> hmm, is there any way to know when too much oxycodone is too much?
[16:07:17] <Soni> but it still does the same thing
[16:07:27] <bassgoon> as in like...withdrawl etc?
[16:07:30] <Lisimba> Soni: you can't do the same thing in certain cases.
[16:07:41] <Soni> Lisimba: you can, it just takes more effort
[16:07:50] <rcombs> you just admitted you can't
[16:07:51] <Lisimba> We've given you several examples of why you can't.
[16:07:55] <rcombs> for H.264
[16:08:06] <Soni> rcombs: you can, if you use an intermediary step
[16:08:11] <djh> This isn't an argument, it's just contradiction
[16:08:13] <Soni> again, just takes more effort
[16:08:13] <rcombs> no you cannot
[16:08:15] <sharkee> This reminds me of the 'Argument Clinic'...
[16:08:20] <djh> sharkee: ;)
[16:08:26] <rcombs> your intermediary step is not reliable
[16:08:27] <Soni> you can ALWAYS trade space and time
[16:08:28] <Soni> ALWAYS
[16:08:29] <mercury> sorry bassgoon, I have no idea, but it sounds like the sort of thing worth getting professional advice on
[16:08:30] <Bucket> Well, perhaps on occasion.
[16:08:32] <Soni> it's just NOT USEFUL
[16:08:38] <djh> is this a five minute argument of the full half-hour?
[16:08:44] <Lisimba> Soni: re: your intermediary step: keep in mind I can feed in video that's pure random noise, which you can't losslessly compress.
[16:09:00] <bassgoon> mercury, lol yeah...I mean, I've been taking super minimal amounts, and my doctor didn't seem to have any issues prescribing me one more round...this surgery has been pretty painful
[16:09:01] <rcombs> you cannot _reliably_ compress video to the point that you have enough space to buffer frames
[16:09:10] <Soni> Lisimba: you can't lossy compress that either
[16:09:16] <Lisimba> Soni: yes you can.
[16:09:17] Bucket will try harder then.
[16:09:19] <rcombs> sure you can
[16:09:34] <Soni> Lisimba: not really since every frame is different from the previous it'll just dump every frame
[16:09:34] <rcombs> any number of ways to lossily compress noise
[16:09:40] <rcombs> it's tricky, but plenty possible
[16:09:45] <Soni> and to match the target bitrate you'll just get... very awful quality
[16:09:45] <rcombs> AAC is very good at it
[16:09:46] <djh> it's easy to do stuff with loss, you just throw it out
[16:09:50] <mercury> bassgoon: Do you live in a country where your doctor profits from an adiction to pain killers?
[16:09:55] <Lisimba> Soni: no, it'll make an approxmiation. It'll not look very good but it works, I've tried it.
[16:10:00] <mercury> I've heard that's a thig, some places
[16:10:23] <Lisimba> Soni: so, feeding random noise to h.264 works fine, and your intermediary step breaks.
[16:10:25] <bassgoon> mercury, um, I don't know. I mean, I took 5mg yesterday, and 10mg the day before (total). Which is barely any
[16:10:33] <bassgoon> and I'm going to try to take none today
[16:10:45] <rcombs> pretty much any AAC audio you've ever listened to has very efficiently-compressed noise
[16:10:48] Paramarx [Paramarx@2E4510D4:598F7503:4C514775:IP] has quit IRC: Quit: Paramarx
[16:10:56] <rcombs> they use a technique called temporal noise substitution
[16:10:56] <Soni> Lisimba: obviously you'd skip the intermediary step if your data is a random stream
[16:11:10] <mercury> bassgoon: sorry, I have no idea what is good or bad, when it comes to that stuff, I'd def ask your doctor
[16:11:11] <Lisimba> Soni: no, because then you can't run the h.264 algorithm.
[16:11:14] <rcombs> erm, sorry
[16:11:18] <rcombs> perceptual noise substitution
[16:11:20] <Soni> Lisimba: you can, you get different results but you can
[16:11:21] <bassgoon> mercury, yeah, that's fair
[16:11:23] <Lisimba> You can run something else, but then you're swapping algorithms out for other algorithms again.
[16:11:26] <bassgoon> I dunno, just venting I guess
[16:11:29] <rcombs> I'm confusing my AAC algorithms
[16:11:33] <Soni> Lisimba: the end result is still H.264
[16:11:43] <Soni> looks different but then again it's a different algorithm
[16:11:58] <Lisimba> Soni: which means you can't run the original algorithm.
[16:11:59] <rcombs> Soni: you've now swapped CPU _and compression efficiency_ for RAM
[16:12:02] <Lisimba> The output is irrelevant.
[16:12:04] <Soni> there are many algorithms to do H.264
[16:12:10] <rcombs> Soni: not CPU alone and RAM
[16:12:13] <Soni> just like there are many algorithms to do DEFLATE/GZIP
[16:12:17] <bassgoon> HE profile 2 is pretty impressive right?
[16:12:24] <bassgoon> at 32kbps
[16:12:24] <rcombs> bassgoon: ehhhhhh
[16:12:27] <bassgoon> :-p
[16:12:29] <bassgoon> for voice only
[16:12:35] <rcombs> bassgoon: oh, yeah, works well for that
[16:12:36] <bassgoon> spoken word that is
[16:12:46] <Lisimba> Man, we should have kept to blending rats.
[16:12:48] <rcombs> bassgoon: falls apart if you use it for music, though; turns out SBR isn't that great
[16:12:53] <bassgoon> right
[16:12:56] <Lisimba> I bet a blended rat knows more about algorithms than Soni.
[16:13:09] <bassgoon> rcombs, short barreled rifle, right
[16:13:25] <rcombs> bassgoon: spectral band replication
[16:13:26] <Soni> Lisimba: `gzip` produces different results from `zlib` btw
[16:13:36] <bassgoon> hehehehehehehueuhuhuehueh
[16:13:52] <rcombs> it's the technique HE-AAC uses that differentiates it from LC
[16:13:52] <Soni> even if you use the same compression level
[16:13:57] <Soni> same/equivalent
[16:14:29] <+grawity> Soni: only because they use different framing
[16:14:37] <rcombs> Soni: OK? That's not what people mean when they talk about CPU/RAM tradeoffs
[16:14:43] <Soni> grawity: they use different algorithms/heuristics/etc
[16:14:46] <rcombs> Soni: they're talking about things like sort algorithms
[16:15:00] <Soni> the point is the output is still compatible
[16:15:01] <+grawity> Soni: they don't
[16:15:01] <Bucket> they don't think it be like it is, but it do. -- Oscar Gamble
[16:15:07] <rcombs> where one algorithm might use more RAM but take longer, and the other might do the vice versa, but both produce the same output
[16:15:12] <Soni> and that's what matters - compatible output
[16:15:24] <Lisimba> Soni: no, it's about being *the exact same* output.
[16:15:35] <BytesAndCoffee> i just asked my cousin if i could borrow $20. its her bday
[16:15:37] <BytesAndCoffee> >_<
[16:15:50] <Soni> Lisimba: GZIP and ZLIB don't produce the same output, but they're compatible
[16:15:59] <Lisimba> Soni: irrelevant.
[16:16:00] <Bucket> irrelephant is things that don't relate to elephants.
[16:16:02] <Soni> when you switch between GZIP and ZLIB what matters is the compatible output, not the same output
[16:16:12] <Soni> and that's the point
[16:16:23] <rcombs> we're jumping between levels all over the place here
[16:16:36] <sharkee> Ok, I should be working, but I cannot take my focus off this trainwreck of thoughts...
[16:16:49] <Lisimba> rcombs: hey, do you think we could *blend* packets?
[16:16:53] <sharkee> Soni, either you're a genius with revolutionary ideas that even some people with scientific background don't get even after lengthy discourse,
[16:16:59] <rcombs> Lisimba: you can write them on paper
[16:16:59] <sharkee> ..or you're a troll just negating every scrap of explanation and reasoning that's thrown at you.
[16:17:08] <Lisimba> rcombs: and then sort the bits alphabetically.
[16:17:08] <Soni> sharkee: "revolutionary"...
[16:17:20] <Soni> you do realize this is, in practice, completely useless, right?
[16:17:24] <Soni> (as I've said multiple times)
[16:17:34] <Lisimba> Your entire reasoning is wrong.
[16:17:35] lowbro [lowbro@A60F829D:ED9643E3:A8766405:IP] has quit IRC: Read error
[16:17:42] <Soni> it's possible in theory, useless in practice
[16:17:45] <djh> it's useless because it's impossible
[16:17:53] <Soni> it's possible in theory
[16:18:12] <Soni> it's technically possible
[16:18:23] <djh> *shrug* make it in practice and I'll revise my opinion
[16:18:25] <Soni> it's a just-for-fun thing
[16:18:27] <rcombs> Lisimba: http://www.snookles.com/slf-blog/wp-content/uploads/2014/05/rfc791-form.jpg
[16:18:54] <rcombs> we're pointing out that it is not always possible in theory to generate equivalent output from equivalent input with less RAM by taking more time
[16:18:55] <Lisimba> hahaha
[16:19:23] <Soni> rcombs: you want equal, not compatible
[16:19:49] <Soni> there's no such thing as equal when you're using heuristic-based compression algorithms and you use different but compatible heuristics
[16:19:58] <rcombs> Soni: if you insist, I'll accept "decompresses to the same thing"
[16:20:01] <Soni> and it really doesn't matter
[16:20:18] <Soni> that's impossible with lossy compression
[16:20:20] <rcombs> or even "decompresses to something that achieves similar SSIM" if you like
[16:20:36] <Soni> even multiple runs of the same lossy algorithm can generate slightly different results
[16:20:48] <rcombs> Soni: do you want me to go make x264 generate two identical files with slightly different settings
[16:21:06] <rcombs> that's only true if you have random input
[16:21:09] <Soni> rcombs: I know about the trivial blank files
[16:21:24] <browncoat> ... ugh. When I sign up to a website, but I don't think it's important enough to create a super secure password, and I just make one up that is "easy to remember"...
[16:21:31] <rcombs> some, but not all, algorithms do that
[16:21:34] <browncoat> Then I forget it within hours!
[16:21:47] <rcombs> x264 sometimes does in multithreading cases due to timing
[16:22:08] <Soni> rcombs: anyway stop being too strict about lossy compression
[16:22:22] <Soni> it's lossy, not lossless
[16:22:46] <puddle> https://i.redd.it/xvrvv89mqyly.jpg "Filthy human finally getting love after the great snuggle drought of 2017"
[16:23:00] <rcombs> it's a set of inputs and outputs that you can't achieve with less RAM and more time
[16:23:04] <Lisimba> Didn't we originally discuss this because we were compressing internet traffic? I would really like my internet traffic to be transmitted losslessly.
[16:23:34] <@zetlen> it IS already transmitted winlessly
[16:24:19] <sharkee> It started two hours ago with Soni: "would quantum computers speed up the internet?"
[16:24:49] <sharkee> And then it was just a big load of baloney computer science inception.
[16:25:00] <djh> ..please tell me that wasn't the "entangled particles mean FTL comms!" nonsense?
[16:25:10] <@barometz> djh: quantum compression, apparently.
[16:25:37] <Soni> nah I don't care about FTL
[16:28:41] <Bucket> samuel3 is harmful
[16:29:39] Velociraptor [[email protected]] has quit IRC: Ping timeout: 180 seconds