There's a (TED talk?) reel been doing the rounds the last couple of days. One of those "interest dies down, someone finds it again, shares it, there's a new bloom of viral interest, repeat until heat death" things.
If you built it FOR someone(a business), you are already on the wrong path. You should have built it WITH someone(a business) and you'd already have feedback and real world usage. Maybe next time around start with a real problem (confirmed by a business) rather than how you want the world to work.
The critique of metadata being hard is fair, the claim that sealed sender is “totally useless” is not. It’s a small, incremental hardening step in a very messy design space, not a magic invisibility cloak, and judging it as the latter sets the bar unrealistically high for anything that still wants to be a drop-in WhatsApp replacement.
Just because it's not perfect, does not mean it useless.
A central signal message service receives millions of messages, I've seen claims of 40M active users a month. If each user sends 25 messages a day, that's 12,000 ish a second.
Drawing conclusions about who is talking to each other out of a 12,000 message per second stream is far from trivial since both signal users are just sending and receiving encrypted packets to a central service. Much depends on how much you believe about how signal handles things on the server size.
Not sure federation or pure p2p would improve things, especially since some fraction of the service could be malicious.
But it doesn't make the claims OP says are broken. Op makes several logical leaps and because each leap is a reasonable leap, he assumes it must be THE leap. Which isnt true and it's simple to come up with counterfactuals, and it's a common pitfall in analysis (he's confirming his bias)
I think this is close, and the video touches on that as a characteristic that’s contributing to this, but there’s a motivation left unaddressed by the video that needs to be called out:
Reducing depth of field reduces the render resolution, which reduces the costs of digital processing and generation.
The simplest way to demonstrate this on a desktop computer is with the photography mode in games like Minecraft or Satisfactory or Elite Dangerous or No Man’s Sky, where the user can modify the Render Distance and Depth of Field at will. Load up the game viewing some planetary scene and enable the fps counter, then start changing the render distance; the closer you set it, the faster each frame will be generated. But the background will look defective and empty, so add depth of field, and now it doesn’t look so cheap — and when you take the photo, depending on the game, it may override your realtime render distance because it can take five seconds (!) rather than 1/60th of a second to generate that frame at 20 megapixels.
I think that the shift towards low depth of field in movies is, in part, a reflection of cost pressures, especially in 99.9% CG movies like Quantumania. And I think this is where Avatar beats out the competition for pure CG worlds in this video, because it renders at full resolution. It must have cost significantly more to produce than Quantumania (yep, $250m > $180m). I wonder how much of that difference was due to rendering the entire movie with a cheapness DoF blur. If nothing else, shadow rendering is so much of the difficulty of CG, that it could plausibly alone be the reason.
(I think that low depth of field is also currently popular because mobile phones lack it, and so producers are consciously or unconsciously selecting for an experience that is distinct from what they might film on their own. Depth of field is a very cheap form of escape.)
I think that is the wrong lesson to take away from the video. As the video emphasizes, DoF is a tool that can be used to achieve an intended effect in story telling.
Main thrust of the video is that these days these tools are predominantly being used for convenience of post-production and cost cutting at the expense of immersion and story telling.
I use a regular 3kg 17” macbook pro from ~2007. Beautiful keyboard, good enough resolution, wifi off(not much use on the internet anyway). Still modern ux and good trackpad.
You have to understand where we came from. Development for iOS and macOS (then MacOS) meant you had to pluck source files from random places on the internet and weave them into your Xcode build. Xcode and xcodebuild didn't really shine in the department of extensibility.
Eloy designed CocoaPods to be the absolute minimum we needed to deal with dependencies for the projects we were working on. So that meant:
* Rely on GitHub for hosting so nobody would get bankrupted running the repo, with the option to switch over to self-hosted in case that ever became necessary.
* Use Git and existing project tools on GitHub to deal with external contributions for pods.
* Use Ruby for scripting because that was what people used most at that time.
* Use Ruby for pod definitions for flexibility and reduced development time (ie. so CocoaPods didn't need a parser).
For a long time this was a one-person effort.
All of those decision obviously have downsides, even more obvious now you have to power of hindsight given years of incremental improvements on speed and security of dependency managers.
I think Eloy did a great job in general and the popularity gained speaks for itself.
I am going to start sounding like a dinosaur but I really hate this dev tendency to trash the old way as soon as the new way comes out. I am seeing it with all the devs advocating for mise over asdf, and a year ago they were all singing asdf’s praises. I think we can advocate for better while still thanking those we are building upon. Long winded way of saying: thanks to the cocoapods maintainers, you made iOS dev better for a lot of people.
Not sure what you mean exactly, but what I assume happens is someone finds the new thing and the old things deficiencies become more apparent because they are both called out by creators of the new thing and probably a major reason the new thing exists. The devs that found new thing start advocating for it while bashing the old thing. Like I said I think it is fine and healthy to advocate for and want to improve tooling, it just bugs me when it is done while bashing what was likely a fairly thankless labor of love.
Yes! I'm a little biased as someone who worked briefly on CocoaPods, but it was an indispensable tool for many years. This is evident by its massive popularity.
Like with NPM, many people ran into issues ultimately rooted in not understanding the tool. CocoaPods had the extra constraint that correctly setting up a Ruby environment was hard. If you used Ruby with a fixed ruby version, bundler with a Gemfile.lock and then CocoaPods it worked well.
As a very occasional iOS developer, I never enjoyed it. I preferred Carthage and jumped over SPM the moment it became available. I understand SPM didn't or even still doesn't meet the needs of many professional iOS developers, but for my hobby needs, it was the simplest and easiest to use.
I preferred Carthage in theory, but every time I tried using it in anger I hit enormous stumbling blocks with projects not actually living up to its exacting standards, then spent hours faffing about before going back to CocoaPods.
I'm happy to see the back of CocoaPods, but it kickstarted the library package ecosystem on the Apple platforms, where there was nothing like it before.
reply