Something I didn't see in the other comments is users who are using the startup's service for work, as an employee.
Why wouldn't you choose the simplicity of "sign in with Google" if your work email is on Google Workspace, using the entire Google suite of business tools for everything (gmail, chat, meet, docs, drive, auth, etc) any everything you do at work is known to Google anyway?
Making an email/password account with your work Gmail is just extra steps, one more password to store, and perhaps the inconvenience of one more 2FA thing. Google gets the same information either way.
Similarly why wouldn't you choose the "sign in Microsoft" if your work is all in on the Microsoft suite of business tools (teams, office, onedrive, auth, etc.) and everything you do at work is known to Microsoft anyway?
Both available choices "share the information with Google" for most people. The majority of email account creations use a Gmail or Google Workspace address, so Google gets the information either way, and in Europe most use Android so can't sign in with Apple.
Because they don't want to have those experiences where they sigh, roll their eyes, then try and remember a password they made months ago just so they can continue using this thing they signed up for. So they just skip the service altogether.
.COM binaries yes, but a.out binaries do have a header, similar in size to ELF.
When ELF was added to Linux, I think it used a bit less RAM than a.out.
ELF made it easier to build and deploy shared libraries, and the design was more consistent at keeping code sections read-only despite run-time linking (the PLT stuff), so more RAM pages ended up automatically shared between processes by the kernel, compared with a.out.
> They do it so they don't have to stand up their own push servers
I don't agree with this dependency on being in good standing with Google either.
But there is a technical reason that isn't wanting to avoid using their push servers. It is about battery usage and radio bandwidth.
Keeping open an idle connection over WebSocket, long-poll HTTP or TCP/IP needs regular pings (typically 30 seconds are used), one ping per connection. Otherwise your app can't be sure to receive messages from the server in real time, as the connection can disappear into CGNAT or similar hole where it doesn't receive messages sent by the server. To an app not using pings to check, such a blackholed connection is indisinguishable from an idle connection with no pending messages.
Waking the radio every 30 seconds, times 2 (back and forth), times the number of registered applications, would be quite battery draining. It drains battery both for background CPU usage and radio processing. Those pings in aggregate can even amount to a significant amount of data usage for users on smaller plans.
So there is a battery and radio advantage in using a shared push service, which only need a single idle connection to be kept live with 30 second pings.
There's another level to this, not available to regular developers using TCP/IP, HTTP or WebSockets.
The mobile network itself has to maintain handset connection liveness to the nearest tower, at a lower level than IP pings, and this is obviously optimised for battery and radio performance, and always running.
With arrangements in place with the mobile networks (which Google and Apple have), the mobile OS can leverage that for more reliable, lower power push notifications, by either guaranteeing the network will send something technically similar to a low-level SMS when there's an outstanding message, or by guaranteeing their special push IP connection will stay live by itself (no CGNAT blackhole) or be notified if something happens to it.
This allows the mobile OS to offer a shared push service that's fairly reliable at real-time notifications, with zero continuous CPU and radio power overhead for the idle connection.
My comment was about push service sharing generally, not banks, from a technical point of view that many people aren't aware of but may find interesting.
Clearly, real-time notifications are useful with many apps, notably real-time messaging, even if you don't think they have a place with bank apps.
For bank and credit card apps, I find their push notifications to be very useful. They are among the most useful notifications I get, because they tell me about things I find important, which I wouldn't notice otherwise.
They tell me things about transactions that have gone through, sometimes after a long delay, transactions that need confirmation right now or they will be blocked, balance being too low, or too high (credit cards), payments that are required today, refunds that came through after a product was returned, transfers that completed on the receiving said, payment received from a client, direct debits that are going out tomorrow so I will need to make sure there's enough in the account, customer service messages that require a response from me or they will eventually close the account, and so forth.
"Just open the app" doesn't work: All of those, except transaction confirmations, are things where I wouldn't know to open the app if I didn't get a message of some kind to tell me.
These days, in some juristictions it's also required to send real-time notification to confirm some purchases, because the phone's security is considered better than card details alone. Depending on how the purchase is made (e.g. in-person vs online, different payment terminals), you might not know the reason a transaction is blocked or held is because it's waiting for you to confirm in the app, so the notification is useful for this.
All these used to be done by SMS, and that was useful too. But SMSs are just push notificatons with a worse UI and worse visual cues.
I'm on Android, and SMS notifications look exactly like every other notification (with one caveat I'll mention below), so I don't know what this guy is on about.
> ...SMSs are just push notificatons with a worse UI...
By this, does OP mean that shit where programs can put buttons and bigass images into their notifications? If yes, I don't want that shit. That's just more opportunity to accidentally trigger unwanted behavior with one's fat fingers, and more screen space gobbled up by overly-self-important software.
The thing that's shitty about SMS is that it's "worst^Wbest effort" delivery... which means that messages can (and will) get delivered late, out of order, or never. Don't use SMS; use email. Email is also best-effort, but -based on my personal experience- far more email server operators give a shit about delivering your messages than SMS relay operators.
That is clearly not the opinon of the product owners and business people. They believe that they own your device, data, and location of when you use it and how you use it. If they want to tell you about their new terrible financial product they will try to force it on you.
> when you can just open the thing in a website anyway. I can use my bank on some linux distro
Unfortunately not.
I'm in the UK. Two of my personal banks, all four business banks that I need to use, and several credit cards, require authentication using their phone app to confirm login on their website.
None of those I've seen are using TOTP or SMS, for which I could use a general security service. All use their own phone or tablet app. One does something interesting where the website shows a unique QR code on each login, the phone app reads it with the phone camera, and then website login proceeds instantly without clicking anything.
Oh, and some of them also require phone app confirmation for card purchase transactions.
When my last phone's screen stopped working, I called one bank's "phone banking" line (using another phone of course) to make an urgent transaction, and they told me they can't do that, as only service they offer by phone is registering a new phone or tablet. They told me explicitly that it's not possible to login to their web-based banking service without using their app for authentication, and on a registered device.
It's the reason I have my current phone. I had to buy a cheap-ish Android in a hurry from a local shop, in order to proceed with my bank transaction.
Back to the main topic: I love the idea of a properly open source phone, I used to own not one but two Nokia N900s, and I once toyed with the idea of building my own Linux phone from scratch, big project though that is.
But the security ecosystem around logins has changed, and so have the services I depend on. These days I use many bank and other financial-service related apps, and I'm not, in practice, free to switch providers. So I couldn't use a Nokia N900 or modern equivalent any more as my only mobile device. I'd have to carry a second phone as well.
(Banking and other service authentications are also the only reason I have my current passport. I resented having to pay to renew my expired passport, given I had no plans to travel (small children) and the expired passport used to be accepted, but I found some banks, credit cards and even government services increasingly requiring to see a non-expired passport from time to time. When I asked one of them what do they do for the large number of people who don't have one, they simply told me they close those people's accounts and that's ok, they don't need to serve everyone. But that's another story.)
Good point, though you have to beware that text-aware image enhancement sometimes replaces characters with what it thinks is a more likely character from context.
I've seen my phone camera's real-time viewfinder show text on a sign with one letter different from the real sign. If I wasn't looking at the sign at the same time, I might not have noticed the synthetic replacement.
That's because flat structures are often, or often turn into, "flat-in-name-only" structures.
I don't think the Tyranny of Structurelessness is arguing in favour of hierarchy, or against other forms of organization than hierarchy.
I don't think it's arguing against "flat" or "anarchy" style organizations either.
In essence, I think it's asking us to do whatever we're doing better, more honestly, more effectively, and less stressfully. By acknowledging, clarifying, communicating, and seeking to understand the real operating structures, what's really going on. And then to improve them, using that understanding.
An actually flat organization might be good, I don't know. I've never seen one. I've been in some that claimed to be flat, and became stressful places to work, for the same usual reasons hierarchies can be unpleasant, including incompetent bosses (not called bosses). But I've also had some pleasant experiences in flat organizations, and I prefer it that way, if it's designed and run well.
It depends which key combination or trackpad gesture is used to trigger the desktop switch, because they use different animation curvdes. It looks like they have different application focus or redraw behaviour too.
- Control-Left/Right takes about 1 second.
- Four-finger swipe left/right takes about 1 second.
- Alt-Tab to an app on another desktop takes about 0.25 seconds.
I'm using Sonoma 14.8.3, but from the comments it sounds like the timing distinction is similar on other versions.
I've worked on a hobby database that did something like this, but instead of "flat" dictionary compression over columns, it used a tree of compression contexts - trillions of them.
Data was compressed in interior and exterior trees, where interior trees were the data structure inside blocks (similar to B-tree block contents), and exterior trees were the structure between blocks (similar to B-tree block pointers, but it didn't use a B-tree, it was something more exotic for performance).
Each node provided compression context for its children nodes, while also being compressed itself using its parent's context.
As you can imagine, the compression contexts had to be tiny because they were everywhere. But you can compress compression contexts very well :-)
Using compression in this way removed a few special cases that are typically required. For example there was no need for separate large BLOB storage, handling of long keys, or even fixed-size integers, because they fell out naturally from the compression schema instead.
The compression algorithms I explored had some interesting emergent properties, that weren't explicitly coded, although they were expected by design. Some values encoded into close to zero bits, so for example a million rows would take less than a kilobyte, if the pattern in the data allowed. Sequence processing behaved similar to loops over fast, run-length encodings, without that being actually coded, and without any lengths in the stored representation. Fields and metadata could be added to records and ranges everywhere without taking space when not used, not even a single bit for a flag, which meant adding any number of rarely-used fields and metadata was effectively free, and it could be done near instantly to a whole database.
Snapshots were also nearly free, with deltas emerging naturally from the compression context relationships, allowing fast history and branches. Finally, it was able to bulk-delete large time ranges and branches of historical data near instantly.
The design had a lot of things going for it, including IOPS performance for random and sequential access, fast writes as well as reads, and excellent compression.
I'd like to revive the idea when I have time. I'm thinking of adding a neural network this time to see how much it might improve compression efficient, or perhaps implementing a filesystem with it to see how it behaves under those conditions.
That's the addressing problem, although I have some bad news on that: NAT is used with IPv6 in some places.
The reachability problem is, even with public addresses, sometimes you have to do the same thing to "configure port forwarding" with stateful IPv6 firewalls as with double or triple NAT IPv4.
Why wouldn't you choose the simplicity of "sign in with Google" if your work email is on Google Workspace, using the entire Google suite of business tools for everything (gmail, chat, meet, docs, drive, auth, etc) any everything you do at work is known to Google anyway?
Making an email/password account with your work Gmail is just extra steps, one more password to store, and perhaps the inconvenience of one more 2FA thing. Google gets the same information either way.
Similarly why wouldn't you choose the "sign in Microsoft" if your work is all in on the Microsoft suite of business tools (teams, office, onedrive, auth, etc.) and everything you do at work is known to Microsoft anyway?
reply