Many of these systems are added to digital wallets due to legal requirements or fraudulent cases. For example, one case of fraud that I’m aware of happened in Chile, where citizens were able to open bank accounts digitally with just their ID. But since there is no good biometric information, many criminals took the IDs of homeless people to open accounts and move money around.
Sadly, these shitting things happen, then companies use these services to avoid the liability, and then these services abuse the information they have.
People don’t have much choice unless their representatives in government do something; it’s not about apathy: you can stop using one bank app, but not all of them otherwise you’ll be out of the financial system.
I recall at an old place of work, the security office having a poster on the wall that said something to the effect of "if your facial biometrics get compromised, you must change your face".
Silly as they were trying to be, the concept still holds -
Facial biometrics can and do get compromised too. Your example of IDs taken from the homeless - what the heck prevents organized criminals from taking pictures or recordings of their faces too?
Already there's malware out there stealing facial recognition data from infected devices (ESET reported on this nearly two years ago). Unlike changeable passwords, once your facial recognition data is compromised then that's it. Scammers can now impersonate you on top of having defeated this additional layer of fraud prevention.
Deno has many of those things now, but my past experience wasn’t good. The first versions of Deno had a lot of friction; Bun however was more or less useful from day 1.
There are still some points of friction, but I'm content with it otherwise. The problems Deno resolves for me far outweigh the problems it introduces these days. I think the inflection point was roughly a year ago for me. Prior to that I really wanted to love it, but I ran into too many issues with the tooling I used most often. It was pretty frustrating. These days I rarely encounter anything at all, and I miss it a lot when I use other runtimes.
I'm a happy Apple ecosystem user. However, there are many more Windows and Android users worldwide.
I think that the appeal of this product is that the Wintel monopoly of years ago is dying. If the Googlebook is well executed (as the Apple M1 line was), it can be an option for Android users who wish to move away from Windows but are not knowledgeable enough to use Linux. I think the only problem here is Google's track record of abandoning product ideas. A new product like this requires multiple iterations to get it right, but if Google abandons it as soon as the results are not what was expected, it will not have the time to mature in areas like gaming or app support.
FYI: aluminium-os.com is an independent information platform. We are not officially connected with Google, Alphabet Inc., or any related organisations.
An alternative take on the section: “Why teams keep building tours anyway”.
Teams keep building product tours because the other option is to invest heavily in trial-and-error user research to optimize the onboarding experience. That is not only more expensive in terms of time and resources, but also requires greater alignment of priorities.
In my experience (I work in product design), introducing product tours is usually a band-aid for deeper UX problems.
Products with an excellent onboarding experience that goes beyond the “click next” pop-up tend to have an excellent user experience too, because they take the time to think about the usage story.
Mainly for web browser plugin authors implementing AI assistants (Gemini/Claude/OpenAI/Copilot).
Instead of parsing or screen-shooting the current page to understand the context, an AI agent running in the browser can query the page tools to extract data or execute actions without dealing with API authentication.
It's a pragmatic solution. An AI agent, in theory, can use the accessibility DOM to improve access to the page (or some HTML data annotation); however, it doesn't provide it with straightforward information about the actions it can take on the current page.
I see two major roadblocks with this idea:
1. Security: Who has access to these MCPs? This makes it easier for browser plugins to act on your behalf, but end users often don't understand the scope of granting plugins access to their pages.
2. Incentive: Exposing these tools makes accessing website data extremely easy for AI agents. While that's great for end users, many businesses will be reluctant to spend time implementing it (that's the same reason social networks and media websites killed RSS... more flexibility for end users, but not aligned with their business incentives)
But think about it. Will you do it for your web property?
Is someone else going to do it for my web property when I have clearly blocked robots?
Will I do it for another web property for my agent to work and hope they don’t update their design or protect themselves against it?
However, I’ve been subscribed to it since its inception because it is the best way to have games that my kid can play without shady ads or engagement practices.
I know that is not going to last, as my kid is now a pre-teen and likes other types of games (like Hollow Knight) that are not available on Apple Arcade.
But the current state of the gaming industry is terrible, especially on mobile. Indy companies producing games like Dead Cells, Hollow Knight, and Stray are good, and there is the extremely rare case of Larian. But other than that, the market is full of dark-UX patterns to promote app purchases. Mobile apps are a minefield of gacha games that should be forbidden for kids.
Just forget that mobile gaming exists? I think one of the cheapo Linux retro handhelds offer a better portable gaming experience than 99% of mobile games, ads or no.
I rather like the Anbernic RG35XXSP for the form factor. It is missing analog sticks, which does cut down on playable games a little but it's cute and tiny and is decently powerful for the price and has good community support. The rest of the RGYYXX line(where YY is the screen size) uses the same hardware but have different form factors so you can pick what you like best.
Sure, but in another time you'd have paid ~$2.99 for the ad-free version one-time, and carried on using it. They intentionally deleted that version of the game, screwing over everyone who did so, then quietly launched the same game again, removing the ad-free one time purchase option.
Taste is subjective. I get it. There are Triple A games on Arcade. Things like Civilization 7, for example. I don't know what the current standalone price is because we use Apple One Family, however, it used to cost $5/mo.
Apple one is a steal IMO. Apple TV, Fitness+, 2TB, Arcade, and other smaller perks like News+ make it an easy sell. Compared to something like Netflix? Netflix is $25/mo for their top tier streaming alone. Apple TV consistently has higher quality content. So does Apple Arcade and Apple Fitness...then you get 2TB of storage to back your crap up to.
Ask Google or Samsung what they are doing for the cost of an Apple One subscription.
Not a fanboy or anything. I'm basically critical of all tech companies, however, Apple is doing something that is working well for them.
Have you thought of getting your kid a nintendo console of some kind? A jailbroken 3DS seems like it'd be great for avoiding that kind of slop since the 3DSs app store died a few years ago
There is no doubt that a product’s community culture and the maintainer’s attitude have a significant influence.
However, I used Perl and stopped using it without knowing anything about its internal politics or community. PHP, ASP, Java JSP and later Rails were much better than Perl for web development.
* I know that for some the mention of JSP will be rare, as it was ugly… However in the 2000s it was the state of the art
The issue with Eclipse and that approach is the complexity of mixing plugins to do everything, which kills the UX.
When VSCode started, the differentiator from Atom and Eclipse was that the extension points were intentionally limited to optimize the user experience. But with the introduction of Copilot that wasn’t enough, hence the amount of forks.
I think that the Zed approach of having a common protocol to talk with agents (like a LSP but for agents) is much better. The only thing that holds me from switching to Zed is that so far my experience using it hasn’t been that good (it still has many rough edges)
Microsoft just fork Atom, and Atom had already good and a lot of extensions.
Before Microsoft buy Github, there was no reason to switch to VSCode instead of Atom.
When Microsoft buy Github, it received Atom from the Github team, and Microsoft stops the development of Atom.
VSCode was just Atom with the Microsoft brand, and some little tweaks from Microsoft, never a game changer compared to Atom, like Atom was in it's time.
Now Antigravity is again a fork with some little tweaks from VSCode, no game changer, just with the Google branding.
I guess we have different perspectives and information about the “rise” of VSCode.
I was an Atom user. Even before the acquisition of GitHub the major feature of VSCode was its speed and TS integration. AFAIK, the only common part between Atom and VSCode is Electron. Other than that, VSCode started with a different codebase based on TypeScript, while Atom was originally written in CoffeeScript.
Multiple design decisions helped VSCode to thrive (btw Erich Gamma was also part of Eclipse):
- The creation of the LSP. Each release of VSCode is also tied to TypeScript releases and improvements. There is a lot of collaboration between the two teams. That gave VSCode the best support for TS and JS. I used Atom and WebStorm regularly when VSCode came out, and VSCode auto-complete and TS support were orders of magnitude better. Everybody caught up since then, but I guess many users like me switched because of that.
- Unlike Atom, VSCode was designed with web integration in mind. A lot of sites started to use Monaco for code editing, and a lot of web-based IDEs use parts of it (CodeSandbox, StackBlitz, etc).
- Gradual rollout of plugin integration. While Atom has the philosophy of everything is pluggable, VSCode was intentionally limited. Which was a good thing given the poor loading performance of Atom.
By the time MS acquired GitHub, Atom usage was already in decline.
* Note: my side of the history, comes from my experience of working in a company that did a custom Eclipse IDE. We evaluated Atom and then VSCode as alternatives to “modernize” our IDE. So I have experience in looking at both Atom and VSCode code bases: they are totally different. Also, the main problem with VSCode for us was the limited extensibility.
> By the time MS acquired GitHub, Atom usage was already in decline.
I wanted to second this: I compared both, with Atom experience starting before the first VSC release. Atom had performance and stability problems continuously through that period, and never really won any of my coworkers over. A lot of that was simple performance: I remember using Is It Snappy? to test my subjective impression and finding that input latency was a full order of magnitude worse, which is the kind of thing which really colors your impression of an editor.
Given their extensive expertise in browser and OS plugins, I understand this move.
You can foresee a challenging future for the Grammarly product for a long time. Now that the "improve writing with AI" feature is everywhere, there are fewer reasons to pay for their subscription (e.g., I didn't renew this year because I have multiple AI subscriptions, and Grammarly was the least critical of them).
However, for me, the main advantage of Grammarly was the user experience of having mistakes and suggestions inline and just a click away while editing, as well as the quality of the suggestions (with an LLM chat, there's a lot of trial and error and junk you need to filter out).
I understand their move, but I wish they had developed a good minimalist native text editor with the same Grammarly suggestions and click-to-correct interface.
That is my number one issue with startups. They all start minimalist and end up bloated, some sooner than others, and what made them great disappears behind all this bloat. See: tyranny of the marginal user.
Many of these systems are added to digital wallets due to legal requirements or fraudulent cases. For example, one case of fraud that I’m aware of happened in Chile, where citizens were able to open bank accounts digitally with just their ID. But since there is no good biometric information, many criminals took the IDs of homeless people to open accounts and move money around.
Sadly, these shitting things happen, then companies use these services to avoid the liability, and then these services abuse the information they have.
People don’t have much choice unless their representatives in government do something; it’s not about apathy: you can stop using one bank app, but not all of them otherwise you’ll be out of the financial system.
reply