But his mistake was easy to make and should have resulted in an "access denied" error message. If you give a five year old a hammer and say "don't whack shit with this", and they whack shit with it, you're the one done goofed.
We've had very different experiences. The startups I've been at have been packed with smart, competent, diligent coworkers. I've had much worse luck with large corporations where employment was effective for-life and it was so easy to blameshift that no one ever got fired for anything.
You raise a lot of perfectly valid points that I'd expect the storyteller to have caught and reacted to. That is, if it weren't their first job out of school.
I'm senior, but I've taken jobs at places where I was given a few pages of setup instructions that could've been a shell script, and I had to work through the steps one at a time. I didn't know how their environments were arranged, or what systems called "cat-kicker" were supposed to do, or why on Earth their git repos were carved up like they were, but I slogged through and got stuff going. I have enough experience to fill in the missing pieces and tell when things don't feel right.
If you or I saw "Step 3: run sudo rm -rf/", we'd stop and ask someone. But if it was literally our first day at work ever, and we didn't have the experience to know that just because someone started before you doesn't mean they know what they're doing, it might not even register. You or I see "echo 'drop table users;' | psql --host prod", we're finding a coworker to see what's up. New guy sees "echo... | psql --host rds-32494032" instead of "--host rds-1005828322", he might not think anything of it as he plows ahead. That no one looked over his shoulder to make sure he didn't actually use the dang ol' prod creds they gave him is entirely, 100% on them.
So much this. It's a major PITA requiring permission from a director for me to get access to a machine that can access a production database. I am perfectly fine with this arrangement!
I don't think he did. I actually RTFA this time, and the guy was following the onboarding directions he was given. Where it went south was that he copied-and-pasted the wrong database credentials. He was supposed to use the username and password that a command had spit out, but he instead used the ones from the onboarding docs.
I'll pause for a moment to let that sink in.
Some jackass had put actual prod root creds in the onboarding docs, then gave them to a new graduate fresh on his first day of his first job, then walked away while he onboarded himself without supervision.
This poor kid did absolutely nothing wrong except misreading some instructions. The engineering team responsible for the chain of events that led to this colossal fuck are completely and wholly to blame.
But that 32-bit computers would you be installing Windows 10 on? I can see them providing 32-bit patches for older still-supported OSes, but for new stuff today? That does seem goofy.
Absolutely. I think people underestimate how perfectly you need to represent anything human-related for it to be plausible. You can't handwave away "actor, male, mid-20s" and hope the details are fungible.
..and a tiny fraction of that is interesting, and those that are interesting are so because they arent random noise.
Yes, but it's still going to be ludicrously resource expensive to explore enough of a math space to find a suitable replacement for a given chunk of image. And given the example of fractal compression, you'll have to explore a fair amount of that space because the output is so sensitive to initial conditions. It'd be nice if you could say "this part of the fractal looks kind of like what I'm looking for, so it's zoom in and it'll be even better", but it's more likely that zooming in will make it worse instead.
They get away with it because adjacent frames of a movie are likely to be substantially identical (modulo a little translation of portions of it). If I pick an arbitrary frame from "Apocalypse Now", I could probably compress the hell out of the next frame. I bet there wouldn't be much similarity between any frame from that movie and another from "Weekend at Bernie's", though.
In this case, the compressed files would need to be around 22kB.
...in addition to the 20TB worth of dictionary data that it would take to hold 5,000 4GB movie files to use as the snippet library. I could get outstanding compression if I ship a Redbox machine to your house and send you the symbol "Sharknado".
I think you represent the idea reasonably well, but right now I'm looking at an Apple TV screensaver showing Tokyo at night. That looks nothing at all like anything else in the world, so it would have to go into the dictionary. Now, my right foot and yours might be similar enough that a picture of yours on a sandy beach would be a reasonable substitute for mine in the same setting. Maybe one chihuahua licking its balls while crouching on a red and black oriental rug, viewed from the front and illuminated by a carbon arc lamp 23 degrees to the right of the scene, looks the same as any other.
But consider how freakishly good humans are at distinguishing faces. You can't compress "The Shining" by using snippets of Leonardio DiCaprio in place of Jack Nicholson because it wouldn't stand up to a moment's scrutiny. Even Googlebot would be able to quickly tell the difference these days. It's my suspicion that the lower bounds on that kind of lossy compression would still be freaking enormous, and that maybe you'd be able to save 2-3% of the total library size by cleverly reusing things like "picture of the moon" or "Caribbean beach, minus people, at noon on a clear day".
The problem is that I can't imagine a 370MB blob containing enough information to accurately render "Gone With The Wind", "Jaws", and "The Matrix". I just don't think they'd have much overlap in primitives.
Great answer, and I think you're likely right. I can at least imagine a movie that's shipped as a Blender file that gets rendered in realtime, or maybe a collection of object hashes ("you don't have cylinder #837 yet. Let me fetch it! Also standard longhair cat #294.") where you build of a local cache over time. That seems practical, or at least possible. But I agree it's not too similar to Sloot's idea once you move past a one-sentence description of the two ideas.
There are hard limits to how much you can compress stuff, especially losslessly. It's always possible to construct an input to any particular algorithm that compresses to be larger than it started. It has to be that way! Suppose that you have an algorithm that can compress any number between 1 and 100 to the range of numbers between 1 and 10. That means that any number in the output [1..10] range maps to an average of 10 numbers in the input [1..100] range. If you see the output number "7", which input does it represent? 1? 23? 37? 42? Etc.
An 8x8x24-bit rectangle has 10^462 possibilities, and fractals are hella sensitive to initial conditions. Finding an approximately match is going to be less painful than naive brute force searching, but it still laughs in the face of a little teraflop GPU.
Since you're basically just storing inputs to the equation, you can get very small compression.
Oh, for sure. But it could be that you have to use a lot of digits of precision to describe the parameters that yield the results you want. Maybe render(3, 5, 23) gets you a blue/orange gradient across a rectangle, but render(3+1/2^193, 5+87/2^432,053, 23+5943/2^1,404,504,305) gives you a cat holding a sign saying "eat more chicken".
So, you want to replace every frame in a movie with a collection of images or snippets that correspond to each part of the frame, right? And you're going to store a dictionary of snippets, referenced by number, then say "this frame takes snippet 1234, 6543, and 9274". The problem is that the number of snippets you'd have to store is enormous, and that each snippet itself is going to be a ginormous number (like the bits of the string of bytes in that snippet).
See where this is going? You're basically establishing a mapping of small numbers to much larger numbers. Either that set of big numbers is tiny (in which case you can only represent a small number of frames in the output video and picture quality is awful) or it's huge, in which case the index numbers themselves become roughly as big as the numbers they're referring to, and oh yeah, good luck searching through that space bunches of times per frame.
The idea isn't inherently bad if you have a small number of states you want to represent. For instance, Zstandard lets you precompute a dictionary of common strings you want to shorten. Imagine if you trained it on HTML so that each tag or other common string just takes a few bits, then you can distribute that dictionary to the whole world so that you can save the bandwidth of transmitting it alongside the compressed data each and every time (like we do with Zip, Gzip, etc.). That's a nice thing! But the search space of "things you can display on a screen" is a hell of a lot bigger than "things you can sent in an HTTP header".
It is if you're doing it right. So you're paying people to manually tend hardware that you probably can't buy replacement parts for, and which is orders of magnitude more power hungry (therefore hot therefore likely to break) per unit of work done than a modern system. That's OK, mind you, if you're talking about one machine that has an EISA card that you simply have to support to keep the business running - and if you have a stack of warehoused replacements you can drop it into. It's also probably OK if it's an ancient mainframe running your accounting system and you're willing to pay HP / IBM / whomever $$$$$ to keep it limping along, and you don't mind having your jobs run 20 times longer than they would on modern hardware.
Of course, neither of those circumstances are relevant to the subject of Apple deprecating old APIs (because the odds of you trying to run a business on a mission-critical Quadra card, or caring about desktop hardware if you're a mainframe wrangler, are approximately zero). The more likely options are that either you're "supporting" ancient PCs because your boss is penny wise and pound foolish, or you just really felt the need to rag on Apple and wanted to boost your credibility before you went in for the attack.
When pointed out they could easily get up and change all these things, they will pretty much reply [...]
"[...] do you also avoid remote control TVs, painandgreed, or do you only like being inconvenienced by other appliances? Also, buy your own beer next time."
I can basically already pretty much accomplish this with my iPad or iPhone, using airplay to my own speakers connected to my relatively cheap third-gen Apple TV or relatively cheap Airport Express.
Not really. We have an Echo, and you definitely can't replicate it with a combo of tablets/phones and accessories. The biggest difference is that the Echo (and all other devices in the arena) have specialized microphones that are good at directional listening. If you're in my living, say "Alexa" and its lights will glow in your direction as it listens to your next words, not those of someone on the other side of the room. You won't get that level of listening accuracy unless you're speaking directly toward an iPad that happens to be facing exactly in your direction.
That's not to say you can't get something close, of course! But Echo is a vastly better listener than my cell phone is, and I'd expect Apple's version to be at least as good.
Slashdot Mirror
But his mistake was easy to make and should have resulted in an "access denied" error message. If you give a five year old a hammer and say "don't whack shit with this", and they whack shit with it, you're the one done goofed.
We've had very different experiences. The startups I've been at have been packed with smart, competent, diligent coworkers. I've had much worse luck with large corporations where employment was effective for-life and it was so easy to blameshift that no one ever got fired for anything.
You raise a lot of perfectly valid points that I'd expect the storyteller to have caught and reacted to. That is, if it weren't their first job out of school.
I'm senior, but I've taken jobs at places where I was given a few pages of setup instructions that could've been a shell script, and I had to work through the steps one at a time. I didn't know how their environments were arranged, or what systems called "cat-kicker" were supposed to do, or why on Earth their git repos were carved up like they were, but I slogged through and got stuff going. I have enough experience to fill in the missing pieces and tell when things don't feel right.
If you or I saw "Step 3: run sudo rm -rf /", we'd stop and ask someone. But if it was literally our first day at work ever, and we didn't have the experience to know that just because someone started before you doesn't mean they know what they're doing, it might not even register. You or I see "echo 'drop table users;' | psql --host prod", we're finding a coworker to see what's up. New guy sees "echo ... | psql --host rds-32494032" instead of "--host rds-1005828322", he might not think anything of it as he plows ahead. That no one looked over his shoulder to make sure he didn't actually use the dang ol' prod creds they gave him is entirely, 100% on them.
So much this. It's a major PITA requiring permission from a director for me to get access to a machine that can access a production database. I am perfectly fine with this arrangement!
Okay, the guy fucked up ROYALLY.
I don't think he did. I actually RTFA this time, and the guy was following the onboarding directions he was given. Where it went south was that he copied-and-pasted the wrong database credentials. He was supposed to use the username and password that a command had spit out, but he instead used the ones from the onboarding docs.
I'll pause for a moment to let that sink in.
Some jackass had put actual prod root creds in the onboarding docs, then gave them to a new graduate fresh on his first day of his first job, then walked away while he onboarded himself without supervision.
This poor kid did absolutely nothing wrong except misreading some instructions. The engineering team responsible for the chain of events that led to this colossal fuck are completely and wholly to blame.
They got you to comment on one, so it served its purpose.
But that 32-bit computers would you be installing Windows 10 on? I can see them providing 32-bit patches for older still-supported OSes, but for new stuff today? That does seem goofy.
Calm down and have a cookie, son. There's no need to get whipped up over this.
Absolutely. I think people underestimate how perfectly you need to represent anything human-related for it to be plausible. You can't handwave away "actor, male, mid-20s" and hope the details are fungible.
What part of that was wrong?
..and a tiny fraction of that is interesting, and those that are interesting are so because they arent random noise.
Yes, but it's still going to be ludicrously resource expensive to explore enough of a math space to find a suitable replacement for a given chunk of image. And given the example of fractal compression, you'll have to explore a fair amount of that space because the output is so sensitive to initial conditions. It'd be nice if you could say "this part of the fractal looks kind of like what I'm looking for, so it's zoom in and it'll be even better", but it's more likely that zooming in will make it worse instead.
Well, OK, I'll let you have that one.
They get away with it because adjacent frames of a movie are likely to be substantially identical (modulo a little translation of portions of it). If I pick an arbitrary frame from "Apocalypse Now", I could probably compress the hell out of the next frame. I bet there wouldn't be much similarity between any frame from that movie and another from "Weekend at Bernie's", though.
In this case, the compressed files would need to be around 22kB.
...in addition to the 20TB worth of dictionary data that it would take to hold 5,000 4GB movie files to use as the snippet library. I could get outstanding compression if I ship a Redbox machine to your house and send you the symbol "Sharknado".
I think you represent the idea reasonably well, but right now I'm looking at an Apple TV screensaver showing Tokyo at night. That looks nothing at all like anything else in the world, so it would have to go into the dictionary. Now, my right foot and yours might be similar enough that a picture of yours on a sandy beach would be a reasonable substitute for mine in the same setting. Maybe one chihuahua licking its balls while crouching on a red and black oriental rug, viewed from the front and illuminated by a carbon arc lamp 23 degrees to the right of the scene, looks the same as any other.
But consider how freakishly good humans are at distinguishing faces. You can't compress "The Shining" by using snippets of Leonardio DiCaprio in place of Jack Nicholson because it wouldn't stand up to a moment's scrutiny. Even Googlebot would be able to quickly tell the difference these days. It's my suspicion that the lower bounds on that kind of lossy compression would still be freaking enormous, and that maybe you'd be able to save 2-3% of the total library size by cleverly reusing things like "picture of the moon" or "Caribbean beach, minus people, at noon on a clear day".
The problem is that I can't imagine a 370MB blob containing enough information to accurately render "Gone With The Wind", "Jaws", and "The Matrix". I just don't think they'd have much overlap in primitives.
Great answer, and I think you're likely right. I can at least imagine a movie that's shipped as a Blender file that gets rendered in realtime, or maybe a collection of object hashes ("you don't have cylinder #837 yet. Let me fetch it! Also standard longhair cat #294.") where you build of a local cache over time. That seems practical, or at least possible. But I agree it's not too similar to Sloot's idea once you move past a one-sentence description of the two ideas.
There are hard limits to how much you can compress stuff, especially losslessly. It's always possible to construct an input to any particular algorithm that compresses to be larger than it started. It has to be that way! Suppose that you have an algorithm that can compress any number between 1 and 100 to the range of numbers between 1 and 10. That means that any number in the output [1..10] range maps to an average of 10 numbers in the input [1..100] range. If you see the output number "7", which input does it represent? 1? 23? 37? 42? Etc.
Pretty much, yeah.
An 8x8x24-bit rectangle has 10^462 possibilities, and fractals are hella sensitive to initial conditions. Finding an approximately match is going to be less painful than naive brute force searching, but it still laughs in the face of a little teraflop GPU.
Since you're basically just storing inputs to the equation, you can get very small compression.
Oh, for sure. But it could be that you have to use a lot of digits of precision to describe the parameters that yield the results you want. Maybe render(3, 5, 23) gets you a blue/orange gradient across a rectangle, but render(3+1/2^193, 5+87/2^432,053, 23+5943/2^1,404,504,305) gives you a cat holding a sign saying "eat more chicken".
So, you want to replace every frame in a movie with a collection of images or snippets that correspond to each part of the frame, right? And you're going to store a dictionary of snippets, referenced by number, then say "this frame takes snippet 1234, 6543, and 9274". The problem is that the number of snippets you'd have to store is enormous, and that each snippet itself is going to be a ginormous number (like the bits of the string of bytes in that snippet).
See where this is going? You're basically establishing a mapping of small numbers to much larger numbers. Either that set of big numbers is tiny (in which case you can only represent a small number of frames in the output video and picture quality is awful) or it's huge, in which case the index numbers themselves become roughly as big as the numbers they're referring to, and oh yeah, good luck searching through that space bunches of times per frame.
The idea isn't inherently bad if you have a small number of states you want to represent. For instance, Zstandard lets you precompute a dictionary of common strings you want to shorten. Imagine if you trained it on HTML so that each tag or other common string just takes a few bits, then you can distribute that dictionary to the whole world so that you can save the bandwidth of transmitting it alongside the compressed data each and every time (like we do with Zip, Gzip, etc.). That's a nice thing! But the search space of "things you can display on a screen" is a hell of a lot bigger than "things you can sent in an HTTP header".
Supporting 10-20 year old hardware isn't tough.
It is if you're doing it right. So you're paying people to manually tend hardware that you probably can't buy replacement parts for, and which is orders of magnitude more power hungry (therefore hot therefore likely to break) per unit of work done than a modern system. That's OK, mind you, if you're talking about one machine that has an EISA card that you simply have to support to keep the business running - and if you have a stack of warehoused replacements you can drop it into. It's also probably OK if it's an ancient mainframe running your accounting system and you're willing to pay HP / IBM / whomever $$$$$ to keep it limping along, and you don't mind having your jobs run 20 times longer than they would on modern hardware.
Of course, neither of those circumstances are relevant to the subject of Apple deprecating old APIs (because the odds of you trying to run a business on a mission-critical Quadra card, or caring about desktop hardware if you're a mainframe wrangler, are approximately zero). The more likely options are that either you're "supporting" ancient PCs because your boss is penny wise and pound foolish, or you just really felt the need to rag on Apple and wanted to boost your credibility before you went in for the attack.
It didn't work.
Theres a lot of coders that'll need to scramble to get their stuff off carbon and onto cocoa
Yes, they will need to scramble to upgrade from that API that was just now deprecated five years ago.
If an app is still using Carbon in 2017, it's effectively been dead for ages.
When pointed out they could easily get up and change all these things, they will pretty much reply [...]
"[...] do you also avoid remote control TVs, painandgreed, or do you only like being inconvenienced by other appliances? Also, buy your own beer next time."
I can basically already pretty much accomplish this with my iPad or iPhone, using airplay to my own speakers connected to my relatively cheap third-gen Apple TV or relatively cheap Airport Express.
Not really. We have an Echo, and you definitely can't replicate it with a combo of tablets/phones and accessories. The biggest difference is that the Echo (and all other devices in the arena) have specialized microphones that are good at directional listening. If you're in my living, say "Alexa" and its lights will glow in your direction as it listens to your next words, not those of someone on the other side of the room. You won't get that level of listening accuracy unless you're speaking directly toward an iPad that happens to be facing exactly in your direction.
That's not to say you can't get something close, of course! But Echo is a vastly better listener than my cell phone is, and I'd expect Apple's version to be at least as good.