Earlier quoted context omitted.
Once I get a project to "actual customers" I don't mind paying and signing my binaries.
How about "actual users" rather than "actual customers?" We should not normalize this because it eats away at free software. It is totally unreasonable to have to pay the operating system's manufacturer in order for person A to simply distribute software to person B, outside of manufacturer's infrastructure. The manufacturer has nothing to do with that distribution, and has no business "warning" the user about this s…
Did we lose our way in making efficient software?
441–450 of 515 posts
Re: Did we lose our way in making efficient software?
#442Earlier quoted context omitted.
Apple should really provide free codesigning for free/open source software.
What does software being signed signify? Does it mean it's vetted? Can a malware author pay the $X and have their malware signed?
Re: Did we lose our way in making efficient software?
#443Earlier quoted context omitted.
You don’t have to do any of that for native apps either. What on earth is happening in this comment section?
I think on macOS it's kinda a requirement, even if you ship outside of the AppStore, to be trusted by consumers. Because I think the app needs to be signed by Apple, in order to start the app without a warning and I think in order for Apple to perform the signing, you'd need a developer account. I might be wrong here as I have been focused pretty much only on mobile, so feel free to correct me.
Re: Did we lose our way in making efficient software?
#444I want to make native apps but Apple and Microsoft seem to be trying really hard to stop me. I have to buy developer accounts, buy certificates for signing binaries, share 30% of my revenue with them for barely any reason and so on. Not to mention the mess they've introduced in their APIs - especially Microsoft. So of course we choose the much simpler, much cheaper way of the web.
whenever I do native (native as in, compiled without going through some bytecode / VM / interpreter ...) apps for mac / windows / linux I don't have to do any of this, I just use Qt
Re: Did we lose our way in making efficient software?
#445Doogle Docs is mentioned in the article, but Google Drive is way worse. Try to upload a folder with 20+ small files(say a picture galley) it takes a lot of time to process and upload them. If you add a new file to the folder and try to upload the folder, it will need to upload the whole thing again.
It was slow as molasses - unusable, really, and we're not talking about huge amounts of data either.
At least then, it seemed to be the google drive i/o that was the bottleneck, and the solution was to upload the training files to the colab session / VM.
Re: Did we lose our way in making efficient software?
#446Again and again people complain about this. But it remains a fact that essentially nobody actually wants this. Developers certainly like to have their completely integrated, connected and universal computing platform (the web). And users do not seem to particularly care about performance as long as it is good enough . And that is exactly the standard that is set, software is allowed to be so bad that it doesn't reall…
I suspect a few things are going on here. This is not exactly a new phenomena. People have been complaining about software bloat since at least the mid-1990's. I suspect someone older than myself would gleefully explain that the complaint's went back to the mid-1980's, mid-1970's, etc.. Eventually it gets to the point where only outliers will complain. Everyone else will simply upgrade, put up with the bloat, or stic…
Apps today are no more bloated than they were last century, while we gained a lot of functionalities that would have been considered witchcraft in the days of Win98.
Re: Did we lose our way in making efficient software?
#447- how much computing power is needed to present a single useful bit of information to the user;
- how much computing power is needed to process a single useful bit of information;
- how much total data transfer is needed to transfer a single useful bit of information.
of course to answer the above questions you need to give the definition to the term "useful single bit". And the hint here is: if we agree that - say - rainbow has 7 colors then the information about all 7 colors would take just 3 bits of data, wouldn't it?..
long story below:
this questions pops up at least twice every year by someone completely frustrated by the current state of things in the computer industry. And if you think it is limited to only software side of things, then well... ignorance is bliss.
Think of it from the incentives and rationale perspective.
Whenever you encounter a bloated piece of software or an over-engineered hardware box put yourself into the shoes of the author of this. Once you delve into the details of why and how was any specific tool or technology created you can understand why it looks so bad.
Some notorious examples of most hated programming languages were created in a very short period of time without any strategic thinking involved by people who had not had any experience with designing programming languages.
And people continue with this pattern in all types of software driven by business requirements rather than their engineering and scientific aspirations and talent (or lack thereof) most of the time.
In other words, bloated software is the result of time limitations imposed on developers. Efficiency, size, quality, stability and security go out of the window when you need to pursue other, more "important" goals.
"We need to go ahead of the competition and the time to market is our priority. We'll cut corners and burn cash. No thorough think through, just do it."
Another perspective is resource limitation. You as a developer have access to virtually unlimited computing, networking and storage resources. Remember this "memory is cheaper than developer's time" mantra?
Now put yourself in the shoes of a NES game developer. You need to squeeze in the whole universe into 32kb, with graphics, music and gameplay that will look attractive and responsive running on a 1.8MHz single-core 8-bit CPU.
Or put yourself into the shoes of the Voyager 1/2 team whose objectives are to keep a small piece of metal afloat in hostile environment for the next 50 years. With remote debugging capabilities, over-the-air software updates and continuous telemetry transmission back to Earth.
If Brendan Eich had not been given just 10 days to draft the javascript specs would we see something different in the frontend world today? Or we'd still see the 10MB garbage being downloaded by every other website just for the sake of keeping the cables busy?
And here is one of my favorite quotes by Alan Kay:
"Think about it. HTML and the Internet has gone back to the dark ages because it presupposes that there should be a browser that should understand its formats. This has to be one of the worst ideas since ms-dos, this is really a shame. it's maybe what happens when physicists decide to play with computers."
Re: Did we lose our way in making efficient software?
#448Earlier quoted context omitted.
Source?
For the Carmack quote? His interview with Lex Fridman. This excerpt has it: https://www.youtube.com/watch?v=rczu8kc8JZA I think the meat starts around 6:50, but really watch the whole thing. It's Carmack talking about what Carmack does best.
Re: Did we lose our way in making efficient software?
#449Earlier quoted context omitted.
What does software being signed signify? Does it mean it's vetted? Can a malware author pay the $X and have their malware signed?
No, Apple will detect and suppress malware as part of the vetting process.
Re: Did we lose our way in making efficient software?
#450It is interesting to see most people lay the blame at the feet of developers. The reality is that these are all business decisions: 1) Move to the cloud because the business likes the steady payout of subscriptions. Business customers love not having to hire IT teams and demand six 9s of uptime because it is someone else’s responsibility. But performance needs to just be acceptable to end users. 2) Customers refusing…