411–420 of 515 posts
I 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.
Earlier 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?
People aren't ignoring Apple hard enough. Why americans bother with it is way beyond me.
Switching ecosystems is nowhere near that trivial.
Ecosystem choices are dependent on content and tool investments, other devices owned, product groups, integrated technologies, network effects between people, between companies, customer relationships, existing phone payments, existing ecosystem familiarity and skills, on and on.
As for developers, they often need to be on the top 2-3 platforms to be a serious choice for customers.
Nothing wrong with highlighting different pros and cons of different ecosystems.
But a suggestion to switch ecosystems, without a very deep understanding of someone's particular situation, just isn't helpful advice.
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…
Good platforms allow you to build on newer versions whilst targeting older versions. Developers often run newer platform releases than their users, because they want to develop software that optionally uses newer features, because they're power users who like to upgrade, they need toolchain fixes or security patches or many other reasons. So devs need a "--release 12" type flag that lets them say, compile my software so it can run on platform release 12 and verify it will run.
On any platform designed by people who know what they're doing (literally all of the others) this is possible and easy. On Linux it is nearly impossible because the entire user land just does not care about supporting this feature. You can, technically, force the GNU ld to pick a symbol version that isn't the latest, but:
• How to do this is documented only in the middle of a dusty ld manual nobody has ever read.
• It has to be done on a per symbol basis. You can't just say "target glibc 2.25"
• What versions exist for each symbol isn't documented. You have to discover that using nm.
• What changes happened between each symbol isn't documented, not even in the glibc source code. The header, for example, may in theory no longer match older versions of the symbols (although in practice they usually do).
• What versions of glibc are used by each version of each distribution, isn't documented.
• Weak linking barely works on Linux, it can only be done at the level of whole libraries whereas what you need is symbol level weak linking. Note that Darwin gets this right.
And then it used to be that the problems would repeat at higher levels of the stack, e.g. compiling against the headers for newer versions of GTK2 would helpfully give your binary silent dependencies on new versions of the library, even if you thought you didn't use any features from it. Of course everyone gave up on desktop Linux long ago so that hardly matters now. The only parts of the Linux userland that still matter are the C library and a few other low level libs like OpenSSL (sometimes, depending on your language). Even those are going away. A lot of apps now are being statically linked against muslc. Go apps make syscalls directly. Increasingly the only API that matters is the Linux syscall API: it's stable in practice and not only in theory, and it's designed to let you fail gracefully if you try to use new features on an old kernel.
The result is this kind of disconnect: people say "the user land is unstable, I can't make it work" and then people who have presumably never tried to distribute software to Linux users themselves step in to say, well technically it does work. No, it has never worked, not well enough for people to trust it.
[1] Here's a guide to writing shared libraries for Linux that I wrote in 2004: https://plan99.net/~mike/writing-shared-libraries.html which apparently some people still use!
[2] Here's a script that used to help people compile binaries that worked on older GNU userspaces: https://github.com/DeaDBeeF-Player/apbuild
Earlier quoted context omitted.
> VSCode is better than XCode or Android Studio That’s just your opinion though isn’t it
That's just an opinion. Not only his. It's shared by many.
My opinion is my best friend. It is my life. I must master it as I must master my life.
Without me, my opinion is useless. Without my opinion, I am useless."
Earlier quoted context omitted.
The thing that makes me crazy is that the thing that we do on computers are basically the same each year, yet software are more and more heavy. For example just in 2010 a Linux distribution with a DE just started did consume 100Mb of RAM, an optimized version 60Mb of RAM. I remember it perfectly. I had 2Gb of RAM and did not have even a swap partition. Now just a decade later, a computer with less than 8Gb of RAM is…
Back in my day websites didn't have "dark mode" and we liked it. We didn't trust the compiler to do our optimizations in the snow (both ways). etc.
Earlier quoted context omitted.
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…
> They keep copies of every program running on a Mac, so they can do clustering > 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.
https://developer.apple.com/support/terms/apple-developer-pr...
Section 5.3: "By uploading Your Application to Apple for this digital notary service, You agree that Apple may perform such security checks on Your Application for purposes of detecting malware or other harmful or suspicious code or components, and You agree that Apple may retain and use Your Application for subsequent security checks for the same purposes."
Earlier quoted context omitted.
They ultimately need money, not apps or platforms, so this is exactly how they achieve that ultimate benefit, no top-level logic will just justify free here
>no top-level logic will just justify free here Not true. The technical term for "ultimately need money" is discounted future cash flow. It is impossible to know for sure what price you have to charge for any particular item at any given time in order to optimise for this metric. Realistically, the answer depends on the state of competition between platforms. We all know what that state is.
so it is true, you can't provide any top-level logic to justify 0, you need some facts
Earlier quoted context omitted.
Nope. Or at least, never happened to me. This comment section is starting to read like a "Bad Times" virus warning https://web.archive.org/web/20060925013545/http://www.making...
And having re-read "Bad Times" for the first time in years, the "screw-up your VHS tracking" is a testament to its age.
https://www.youtube.com/watch?v=zvfD5rnkTws
Seriously, though, I've had the Windows Defender thing happen to freshly compiled binaries I made. The only way to prevent it from happening is to sign your binaries, or submit them individually to Microsoft using your Microsoft account for malware analysis.
It flagged the binary as being some sort of trojan (which name I looked up and found that it was a Windows Defender designation for "I don't know the provenance of this binary so I'm going to assume it's bad") and quarantined it.
Earlier quoted context omitted.
> Customers refusing to upgrade on-premises software After a certain period of time, that software worked just fine for those customers. Photoshop is a great example. Sure, you won’t get the flashiest features, but CS4 will still work for you on a Win7 machine without any additional fees paid.
Once I commit to buying a version of Software X, I'm happy with it. As a user I expect Software X to work as-installed for decades to come. I don't want new features. I don't want the UX to change on me all of a sudden. I don't want it to get slower. Bugfixes and security fixes are fine, as long as everything else remains the same. I wish more developers understood and respected this.
Devs absolutely do not enjoy backporting bug fixes to 5 different LTS versions of their software and then getting user complaints because there's inevitably an important customer who is six versions back. It's inefficient with expensive dev time and it's better for the business to use that time to create new features.
edanm is correct, a lot of this is historical caused by very loud and angry tech users around the turn of the millennium. Want to know why Chrome won? When telling that story people tend to focus on performance or security, but that's not really it. Chrome won because Larry Page overrode all the internal screaming about silent web-style auto update for desktop apps. Oh boy, a whole lot of people really hated that idea, in fact Google had to develop their own software update engine from scratch to make it happen. Page didn't care. He understood that the ability to release a new version of web apps every week without the user noticing was a huge competitive advantage for the web, IE also updated in the background as part of the OS, and he wanted Google's desktop apps to have that same advantage.
Meanwhile Firefox stuck with the old model of rare releases and letting users choose whether to upgrade or not. It was a disaster. Old Firefoxes constantly annoyed web devs by preventing them from using new features. Security patches got reverse engineered and exploited. Still, Firefox's passionate fanbase loudly rejected the Chrome approach because they felt it took away their control.
Eventually the Mozilla guys accepted that they were wrong, their fans were wrong and Larry Page was correct. But it took years and in that time Chrome had built up a huge reputational advantage.
Earlier quoted context omitted.
> Let's ask the question differently: what problems were solved? A few more: * Seamless internationalization. If you're a native English speaker you probably never experienced the "fun" of dealing with French and Russian in the same text document. Pre-Unicode supported English + one other language, if that other language wasn't too weird. * Lots of tiny life quality improvements. Eg, not seeing windows repaint costs…
I don’t know about nextstep but macOS had all this stuff when I first used it 20+ years ago. It featured compositing rendering, had the apps, supported ppc/x64 in an app image, had a microkernel. I even remember it got an emulator for running ppc code on an x64. The newest macOS still needs more memory and suffer bloat but 8GB is still perfectly useable if you avoid google chrome. 8GB is also perfectly usable for Lin…