News for hackers. Stuff that matters.
Re:Released and Certified: Qt Safe Renderer by aroman on Friday June 01, 2018 @09:26AM (#17205045)
Your last sentence is needlessly condescending :/
Re:Released and Certified: Qt Safe Renderer by dekhn on Friday June 01, 2018 @09:35AM (#17205130)
No, it's not. It's an accurate assessment of the current state of the web world: web frameworks that last a year before they get abandoned by their creators. jwz wrote a nice blog post about it: https://www.jwz.org/doc/cadt.html
Re:Released and Certified: Qt Safe Renderer by hood_syntax on Friday June 01, 2018 @09:41AM (#17205178)
Why do people link this dude here when you get redirected to that picture every time...
Re:Released and Certified: Qt Safe Renderer by shawnz on Friday June 01, 2018 @09:52AM (#17205290)
Yes, how ironic to criticize childlike developers and then defer to jwz
Re:Released and Certified: Qt Safe Renderer by dekhn on Friday June 01, 2018 @10:11AM (#17205454)
A guy who has maintained a secure screensaver for 20+ years. Who aptly describes how fucked up our system is. Who built the technology your browser apps are based on.
Re:Released and Certified: Qt Safe Renderer by iiiggglll on Friday June 01, 2018 @11:10AM (#17206003)
Not that he's wrong about open-source abandonware, but that's rather an overstatement. No significant amount of his code remains in any modern browser, and when the engine that eventually became WebKit and later Blink (and which now powers the majority of end-user web client browsing today) was first announced as based off KHTML and not Mozilla tech, he wrote a self-congratulatory blog post[0] that started off with "Summary: I was right", even though it had nothing to do with him or his work. Not to mention KHTML was done using C++, something he was always against (no mention of "I was right" on that part, I see). He's done some good work here and there but he really gets carried away with his blowhard opinionating at times, and I think people should turn a more critical eye towards that sort of thing.

[0] https://www.jwz.org/blog/2003/01/more-khtml/

Re:Released and Certified: Qt Safe Renderer by Mononokay on Friday June 01, 2018 @10:36AM (#17205655)
The link works for me.
Re:Released and Certified: Qt Safe Renderer by dekhn on Friday June 01, 2018 @10:56AM (#17205808)
You're probably using an ad blocker
Re:Released and Certified: Qt Safe Renderer by icebraining on Friday June 01, 2018 @10:15AM (#17205482)
Are they being abandoned by their creators, or just superseded in popularity by others?
Re:Released and Certified: Qt Safe Renderer by pknopf on Friday June 01, 2018 @03:20PM (#17209012)
Both are equally as bad.
Re:Released and Certified: Qt Safe Renderer by shawnz on Friday June 01, 2018 @09:36AM (#17205139)
It's OK, the parent will be paying the price when they're still writing native x86 code in 20 years time.
Re:Released and Certified: Qt Safe Renderer by pjc50 on Friday June 01, 2018 @09:57AM (#17205338)
shrug Nothing wrong with native code, and sometimes nothing else will get the job done. Besides, my retirement plan is to be the dinosaur brought out to fix all those 32-bit-time bugs in 2038.
Re:Released and Certified: Qt Safe Renderer by pkaye on Friday June 01, 2018 @05:22PM (#17210468)
Low level knowledge is useful at times. I rewrote a small amount of code on a project at work using SIMD instruction to reduce execution time by 60%. This is on something executes in tens of minutes so the time savings are quite noticeable.
Re:Released and Certified: Qt Safe Renderer by dekhn on Friday June 01, 2018 @10:06AM (#17205422)
most of my code is in Python (there are Qt bindings). That said, I'm interested in webassembly, and can also write javascript. I just don't think that browsers or javascript-based apps present a preferred alternative to native apps developed by teams who consider long-term API stability and getting the right regulatory boxes checked.
Re:Released and Certified: Qt Safe Renderer by ahartmetz on Friday June 01, 2018 @10:36AM (#17205653)
The free performance lunch from ever faster hardware is over and that is saving native code for applications. The few percent hardware improvement each year is easily eaten by growing requirements.