101–110 of 157 posts
PCI express is ~100 gbit/sec, much faster than any network interface. Internally, a GPU can resize these images by an order of magnitude faster than that, see the fillrate columns in the GPU spec.
Earlier quoted context omitted.
The downvote is probably because the comment implied that the issue is that the image processing is done in "unsafe" C++ and that another language should have been used. However, there isn't much choice. Performance is very important in image processing, so much that many libraries contain hand-written assembly. In the article, it says that 90% of processing power is dedicated to it. Using a safer language in a safe…
How much does a hack of all your data and/or a major outage cost? I also recommended a mitigation strategy for unsafe code. Complaining that security is too hard is the reason for the situation we find ourselves in as an industry.
How much indeed ? What was the last time ? Ah, yes, Equifax. What happened ? Nothing.
Earlier quoted context omitted.
agree on 3) most browsers just use linear interpolation when resizing images, which makes sense from a performance point of view, but looks terrible. Better to use a bi-linear or cubic resize, more computing up front, but better images, this is probably the reason they do it
But soon you can do any type of resizing through WASM on the browser.
Earlier quoted context omitted.
I think that's a bit reductionist, no? There are many reasons they may have been searching for moving to Go. Off the top of my head I can think of: 1. Static typing increasing confidence and velocity 2. Better developer-facing tooling increasing velocity 3. More employees knowledgeable about Go than Python 4. More enthusiasm (and therefore faster velocity) around Go development. The blog post was about the engineerin…
It might be, then again I see a lot of wheel reinvention in tech / NIH syndrome. I'm the kind of hacker who if a service runs out of memory every 2 hours, writes a crontab to restart it every hour after X random minutes so they don't all restart at the same time. It gets a lot of eye rolls from the other engineers searching for perfection, but it tends to produce services quickly that are highly reliable. And look no…
1. Add profiling and telemetry to their Python code. Refactor the codebase based on insights from this.
2. Write a CPython interop for their image libraries.
I can't see the cost of #2 being any different than the cost they paid on writing it in Go. As for #1, depending on how the code is structured, a rewrite may have been less time than profiling spaghetti code. At that point, it depends on how much Go experience the team has.
Nice, but why? https://cloudinary.com , https://www.imgix.com , or https://www.filestack.com already exist and are well worth it for 99% of apps. Even at scale, it really doesn't cost that much to have someone else do it. You can use a thin proxy through your existing CDN if you want to save on their bandwidth fees. Also http://thumbor.org and https://imageresizing.net if you want a library to host yourself which are…
I agree. Offloading this type of work to a third party who does it really well is a smart move. Why manage additional code when it's not even core to what you do?
Also, it is totally core to what they do. Images are a huge part of the Discord UX.
Earlier quoted context omitted.
Discord makes most of their revenue from selling user data so they probably want to keep as much as possible.
Do you have a source? That's a pretty bold claim, and I haven't seen anything else to back that up.
Earlier quoted context omitted.
I agree. Offloading this type of work to a third party who does it really well is a smart move. Why manage additional code when it's not even core to what you do?
In this case, it was perhaps cheaper for them to do in-house, and it's not rocket science? They wrote a bleeding edge library for it - sounds like they have the expertise just fine. Minimizing external dependencies can be a big deal if you have the developers to manage it. Also, it is totally core to what they do. Images are a huge part of the Discord UX.
How is the security? Any sort of image processing is a potential exploitation point. I see it says it uses the 'mature' libjpeg-turbo and libpng libraries,along with giflib for .gifs, but even with full trust of those, the C code, patches, and changes ontop could be more exploitation points. You can look through Imagemagick alone to see all the fun things possible when seemingly basic processing turns into exploits.…
Wow really? Is there room for another image processing library? Is ImageMagic poorly written or is image manipulation inherently risky?
Additionally, image manipulation is inherently challenging - not even due to the actual manipulation of image pixel data, but due to the proliferation of complex image container formats which require binary data manipulation and byte copying in performance-critical code. This is a minefield for secure programming practices because it puts at direct odds performance and sanity checking, as well as encouraging pointer and memory arithmetic and unsafe access.
Earlier quoted context omitted.
Do you have a source? That's a pretty bold claim, and I haven't seen anything else to back that up.
pretty sure they've directly stated that they're not selling user data