zelly

> But a native app with seamless integration? No way.

https://developer.apple.com/documentation/apple_silicon/runn...

Most Linux users would prefer a well-designed curses application over a GUI. You don't have to ask me, just look at what Linux users actually run and share screenshots of. I'm talking about real Linux distro users not Chromebook users.

IMO the worst part about this is not the pricing change but the fact that they advertise using CMake as a selling point.

It's not simply about speed. The page looks like spam.

> Apparently web standards folks in the early 2000s thought the future was XML all the way down.

It should have been, but just like the masses rejected LISP for its parens, the masses rejected XML for the closing tag. We could have avoided PHP and the zoo of MVC frameworks.

> I'm waiting to see how Copperspice (A Qt fork that cuts off support for older C++ versions and uses STL and UTF-8 aggressively) turns out

It's been around for 7 years and is maintained by two people as opposed to a publicly traded corporation (Qt) with hundreds of employees. It has already turned out.

There is no alternative to Qt. It is the best in its class.

But you don't need it. You don't need Electron either. Just build a .NET application for Windows, a SwiftUI one for Mac, and a ncurses one for Linux. They can all share the same business logic code (if it has any), either via C ABI, IPC, or RPC. Your application will always be at the bleeding edge with the latest security patches and accessibility this way, as opposed to waiting for the next Qt/Electron release which is guaranteed to be later than the OS bugfix. Imagine if desktop OSes release, in addition to dark mode, a pink mode. Do you want your application to stand out as the ugly duckling?

There is no alternative. No one other than Qt will expend the massive amount of effort to maintain such a thing. Everyone sees the writing on the wall with the new ARM Macs if it wasn't already apparent. Desktop applications are on their last leg. You will just write a mobile app and that will be backwards compatible with desktop automatically.

Spotify is CEF (Chromium Embedded Framework) as is the Adobe CC desktop application.

CEF is geared toward native C++ and is probably more of a Qt alternative than Electron in that regard.

People bring up this misconception every time Qt is mentioned. It is free as in beer (LGPL) at least on desktop. You can sell a proprietary commercial application using Qt without paying a dime as long as you dynamically link Qt (which can be included in the installation bundle).

(But you shouldn't. There is little need to distribute closed source software anymore. If you are shipping a binary with valuable trade secrets, then it won't be secret for very long. You can do server-side rendering of all the UI like all the large cap tech companies do then it won't matter if the client application at the edge is open source.)

RIP SEO

Buy hard drives, do frequent backups, store redundant backups remotely, use RAID. At the end of the day someone must pay for the hard drives and they could just stop paying for it one day. There is no such thing as permanent and free.

It's not portable. It looks really bad on a terminal emulator that does not support emojis (at least half of the ones out there esp on Linux). There are dozens of emoji fonts which all look different. You never know what your user is going to see. If your users are only using macOS and Terminal.app, then it may not be so bad, but if you are building a command line application, then I should be able to use it from a text-only console on an old system, VM, or embedded device. Don't assume all your users are going to be using it from a Macbook Pro or Ubuntu.

My advice as a user of CLI:

- no emojis please, ever

- if you want to make it look nice, use ANSI escape codes for color rather than emojis. even then, don't use color alone to convey meaning because it will most likely get destroyed by whatever you're piping it to.

- please take the time to write detailed man pages, not just a "--help" screen

- implement "did you mean?" for typos (git style) and potentially dangerous commands

- separate the interface into a tree of subcommands (Go/Docker/AWS style) rather than a flat assortment of flags

- if you are displaying tabular data, present an ncurses interface

- (extremely important) shell completion for bash and zsh

The business case for native apps (whether on desktop or mobile) is that it's not just another tab people can X out of. Installing a native app feels like a commitment. The icon is there. It might be sitting in the tray/taskbar. It commands attention. It can push notifications that most users wouldn't turn off.

Most users do not know what a PWA is and won't install it unless it was done for them. Even then a PWA is at the mercy of the host browser's configuration and addons which can degrade the experience. (And on Apple devices it won't even work.)

Synthesis: native mobile app

Yes, modern cards are basically YubiKeys. You can't trust people (such as bank employees) to maintain private keys. That would never work.

Maybe some kind of USB/Bluetooth device that can authorize your physical debit card can let online merchants debit bank accounts securely. I know they have had something similar in the UK for decades.

Plaid is more of a monopoly than Visa is.

Plaid is literally the only way to do ACH without microdeposit verification. There is no reason Plaid should have a monopoly on this. If banks opened up APIs for bank account verification, then anyone could compete with Plaid.

As usual the Justice Department doesn't know what they're talking about.

this but unironically

Most "REST" APIs are just RPC. Many "REST" URLs are just the names of the methods they call on the remote endpoint.

REST is good for things like downloading and uploading documents or media to a web server. GET, PUT, POST, DELETE, etc. were designed for documents/media. Because it's available from a web browser, like JavaScript, people started using it even on native apps because it's familiar. That doesn't mean it's the best or most productive protocol.

Great idea, hopefully this helps nail the coffin on "everything should be in the cloud"

Pay for your own hard drives

Thrift and gRPC can "push" until the cows come home (streaming). Use the correct tool for the job. HTTP is for hypertext documents, not APIs or RPC.

Build your own AWS

You will get your Apple Developer account terminated if they ever find out.

Live by the walled garden die by the walled garden

What about employees stealing time from the employer?

Because then you're forcing clients to use malloc rather than their own allocator

Eventually someone will find a coincidental or unintended aspect of your API and then depend on it. This article is the ultimate exemplar of this rule.

Someone needs to implement Go in the JVM so it can finally have a good GC

Stick to OCI-compatible images and there should not be a problem

It's compatible with cgroups v2 unlike the standard Docker. If you're using Fedora, you have to add a kernel parameter to Grub to use cgroups v1 instead.

RedHat seems to be pushing a standard ecosystem for Linux: systemd, Wayland, SELinux, GNOME, and now maybe podman. I've been on Linux for a while; it's a welcome change from all the fragmentation I'm used to. Whereas others try to work around the kernel and implement their own things in parallel (see: Canonical's AppArmor, LXC, OpenZFS), RedHat just goes with what Linux already has like SELinux/cgroups v2/btrfs, which I think is more likely to last and just feels better. If RedHat goes away, I'm fine since I'm ultimately only relying on Linux features. If Canonical goes away, then I'd have to switch to a different stack. That's probably why government, enterprises, Amazon, etc. still prefer RedHat.