451–460 of 530 posts
Earlier quoted context omitted.
So many developers do this, and it's infuriating. I have a device sitting there on my perfectly good LAN, yet if I want to remote control it, the brilliant software decides to send the commands to the Internet, then back to my device, then the response gets routed to the Internet, and back to my phone. Device developers, stop doing this! You people realize that LANs exist, don't you?
I was doing firmware + mobile a at large-ish startup a decade ago. Same story as Sonos; there was a push to go all cloud instead of our local network implementation that worked great. I argued breathlessly against it for days. I’ll never forget the sales chad raising his voice to shut me down with a cop-out:“This is the way the industry is going!”. It’s not the developers making these changes.
Earlier quoted context omitted.
Without content addressing how do I know that whoever holds the cache hasn't tampered with the content?
The integrity attribute of the element lets you provide a hash to ensure the content has not been tampered with.
Earlier quoted context omitted.
Sites can be fast with PHP and JavaScript. The slowness you see is mostly coming from all the frameworks too many developers "include" willy nilly with code that can only be described as bloat because 99% of it is completely unused, yet being loaded and computed by the browser on every load. That's what you're experiencing on too many websites.
Funnily enough, since most JS frameworks are utter junk, developers are better off instructing LLMs to write pure JS instead. Fun story, I was writing some 3D graphics animations for a website, and the only dependency I allowed was three.js. It ran well, but the site was loading slightly too slow so I told the LLM to optimize. It essentially hit a hard wall and told me something along the lines of "I can't optimize f…
Earlier quoted context omitted.
A browser isn't really a program any more but a platform for running other programs. Like how javaw.exe is really Minecraft, firefox.exe is really YouTube. Go to about:processes to find more detail.
The point is, if I want to edit a text file, I don't need to use eclipse. I can use something that hasn't added loads of features. I don't need to use whatever Adobe product, I can use some paint app. If I want to watch streaming videos, I don't have a choice about how I do that. Fine Firefox is basically a bloated YouTube app. That doesn't change the fact that it is inefficient (from the pov of my CPU) for doing tha…
One of the biggest causes of slowness is just waiting for web requests. The fact that so much software is either online or built using the same stack even if it isn't, puts all that software in this blocked/waiting state constantly while using it. Anyone not in the US feels this even more since so much online is US hosted, 300ms for every little interaction adds up quick. If your software has the affordance of a wait…
This is an incomplete and quite superficial view of what is going on out there, in my opinion. I've worked on plenty of projects where the assumption was that since the round-trip to the server is going to take almost 100ms that'll dwarf anything that's going to happen on the server itself, justifying poor choices that lead to potentially adding a whopping 100ms onto that number. These numbers only get larger with a…
Non-tautological rephrasing: When optimizing code, first actually just de-slowify it, and that should most often be plenty enough.
Earlier quoted context omitted.
Let them sue you if they want to.
They literally unlicense the product out from under you as part of windows update. You’re the one having to sue, unless you never connect your machine to the internet anyway.
Or just pirate the software and let them sue you for pirating, which you will win since you have a license, even though the computer thinks you don't.
One of the biggest causes of slowness is just waiting for web requests. The fact that so much software is either online or built using the same stack even if it isn't, puts all that software in this blocked/waiting state constantly while using it. Anyone not in the US feels this even more since so much online is US hosted, 300ms for every little interaction adds up quick. If your software has the affordance of a wait…
I agree and see this as a side effect of a subtler thing. As people shall be replacable, software is designed and subtly mimics the organization's communication patterns. Features are cut up into the tiniest pieces with clear separation from the start (at least its claimed), and over time whatever change or feature seems overly complicated, won't be done or won't be done in a sane manner because its uneconomical. You…
“…the structure of a designed system mirrors the communication structure of the organization that built it”
No there's a simple reasons actually: we have surrendered entirely to web based apps & the resulting ad bloat. You used to buy a computer, install an OS, buy apps and run them. Neither the OS nor the apps didn't suddenly degraded themselves with "free update" that were developed targeting newer & newer machines. You bought a new computer when new software you wanted to buy wouldn't run fast enough on it, OR the compu…
This is, in my experience, not a thing on Linux.
But if you're going to be relying on the LLM to do all the final-stage implementation work, and you've already got all the guardrails in place to ensure that the final output is performant, secure, correct, etc., then why would you still target TypeScript, which is entirely a kludge to shoehorn type safety into JS for the benefit of human programmers?
But then why target JS, if it's just going to sit on top of a complex runtime like Node? Why not just target the language the runtime interpreter itself is written in, and just output clean C? But then C needs to be compiled down to assembly anyway, so why not skip that step and just output assembly?
LLMs still have a lot of pitfalls and risk factors, and will always need human oversight, but in this case, what's on the horizon is something that can eventually eliminate all the intermediary bloat that only exists to optimize the development process when human programmers are doing all the grunt work. Eventually, we might be able to do away with the tradeoff between development velocity and runtime performance.