331–340 of 515 posts
Earlier quoted context omitted.
This doesn't matter. Notarization doesn't do anything against a dedicated attacker willing to commit illegal acts. Notarization is supposed to deter malware by a combination of static/dynamic analysis and attaching some real-world legal entity to any signed binary so law enforcement can follow up on if malicious activity is happening. Analysis is not bulletproof and can be worked around. The legal entity requirement…
Notarization does do things against attackers, yes. Firstly, stolen CCs tend to get reported especially if you make a big purchase. If you use a stolen CC to buy a developer certificate then it's going to get revoked the moment the real owner notices, and then your apps will be killed remotely by Apple before they've even been detected as malicious. Still, the big win of notarization is that Apple can track down vari…
> analysis server side.
Are you sure about this ? I did not give apple permission to keep a copy of my software that I am writing.
Web apps are much faster to install and update. 1) Your browser is always open, whereas you need to close your current app and open the app store app 2) Google Search is better at giving you what you want in the fewest number of keystrokes than any search from any other company including app store search boxes 3) installing a "web app" is one click after the google search results or if someone posts a link. As you mi…
That seems to be contrary to the general opinion (at least on HN): google has become utterly irrelevant, serving mostly content farm AI generated junk type of blogspam, and google is more concerned about ad revenue than anything else (including results quality)
Earlier quoted context omitted.
I dont agree, there is way more help in terms of writing efficient code today than there was back in time, ive seen horrible code from that time which would not have been produced today.
What we don't teach or reward today is the behaviors and engineering process to write high quality code. A surprising number of inexperienced developers do the following: "once I get any working solution I should immediately open a PR" and let the senior engineers tell them what's wrong with it. When the big money leaves this field I hope there will be more pressure for people to adopt good engineering practices. I l…
In my 13 years in the industry, I’ve never worked at a place that valued that. More features faster, how many points this sprint is all that mattered. It’s put me off software engineering altogether.
Earlier quoted context omitted.
> A lot of that is due to coordination problems. The dumpster fire at the bottom of that is libc and the C ABI. Practically everything is built around the assumption that software will be distributed as source code and configured and recompiled on the target machine because ABI compatibility and laying out the filesystem so that .so's could even be found in the right spot was too hard .
To quote Wolfgang Pauli, this is not just not right, it's not even wrong ... The "C ABI" and libc are a rather stable part of Linux. Changing the behaviour of system calls ? Linus himself will be after you. And libc interfaces, to the largest part, "are" UNIX - it's what IEEE1003.1 defines. While Linux' glibc extends that, it doesn't break it. That's not the least what symbol revisions are for, and glibc is a huge us…
We aren't making software. Where making features (and bugs) for the next Friday deadline.
The rest of us and the vast majority of professional SE work for a marketing/sales person and “number of new features released this Friday” as you said.
It's interesting: minimal software is out there, but folks don't tend to choose it. I spend a fair amount of time thinking about how to be conservative in my dependencies, and this encourages a lightweight stack that tends to perform pretty well. These days, I'm favoring tools like Lua, SQLite, Fennel[0], Althttpd[1], Fossil[2], and the Mako Server[3] and find that great, lightweight, stable, efficient software is to…
Earlier quoted context omitted.
Devil's advocate: you now get a lot of tooling for 'free', which used to cost hundreds or thousands of dollars.
Counter offer: the tooling is ultimately for their benefit. They need the apps to make their platform what it is.
Again 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…
Do we really though? Web developers do of course, but I've hardly touched web development myself. Web interfaces etc., are a choice, but I think it's driven by commercial needs-- a desire for subscription revenue instead of one-time sales, etc. Much of the modern cloud-based or half-online world is quite unnatural from a user perspective, and where there is no need for monetisation-- for example with OpenOffice, the…
This is certainly a big part of it, but it's not the whole story.
For one thing, there were ways to achieve those business models with native software too - "web-based=subscription" isn't actually a requirement, or the only way to go.
But users in the early 2000s, many of them more technical than users today, rejected this idea. It felt like native apps had to cost money one time, and doing otherwise would be wrong. But with Web, since users understood that it was hosted elsewhere, it "made sense" for it to be a subscription, so users went with it.
This also affected the technical things as well. Auto-updating was incredibly frowned upon in the 2000s - you bought it, you got to keep it as-is. So companies had to work very hard to keep multiple versions working all the time.
Most of these biases by technical users have gone away. We now have auto-updating subscription native apps, e.g. Photoshop works that way today. But these technical biases drove the usage of the web, because it was so much technically easier for businesses, and allowed much better business models.
(And, and this isn't even getting into the whole "installing software was really hard for users" thing!)