gst

In addition to the other software already listed here Materialize does this too: https://github.com/MaterializeInc/materialize/blob/main/LICE...

What would be the advantage of doing that? We're currently researching CO2 sequestration to remove CO2 from the atmosphere and store it somewhere outside of the atmosphere. So what would we gain by burning plastics? Even if they are not recycled - having those plastics in a landfill is a lot better than burning them and putting CO2 into the atmosphere.

Yes, but if a metal with a lower melting point is in fluid state inside another solid metal that's not better than having both in a fluid (or solid) state.

Here's a related Quora discussion: https://www.quora.com/If-you-smelted-a-varied-mix-of-scrap-m...

> This is different with metals where you can "just" melt everything and separate the metals.

How would you separate the metals after melting them? My understanding is that you can extract some high valuable metals via different processes, but otherwise it's technologically and economically not feasible to separate molten metals.

In Europe you have SEPA transfers where the reversibility after a transfer is comparable to a wire transfer. You can't really avoid them because they are the standard way of transferring money (if you don't pay by card or use direct debit).

But all of that complexity seems to be added with good intentions. Just look at the "Coronavirus Tax Relief" as the latest example which by itself has a long FAQ page describing all of the details: https://www.irs.gov/newsroom/coronavirus-related-relief-for-.... Adding that to the tax code was probably the best short-term approach to quickly ship something (and lots of people are probably in favor of those changes), but that complexity adds up over time.

To me this looks somewhat like the broken windows fallacy: In countries where the tax code is simple and allow for "automated" taxes nobody is going to advocate for a new law if it makes filing taxes a lot more complicated. But in countries where the tax code is already complex adding one more complex law doesn't make too much of a difference.

The US system is more complex, but I wouldn't attribute this to malice.

The reason why it's so easy to file taxes in lots of European countries is because the tax system (for the general population) is a lot simpler. For example in Austria you pay the same amount of taxes no matter if you're single or married, capital gains are taxed at a flat rate and directly withheld by brokers, and "social benefits" are typically handled outside of the tax system instead of being folded into the tax system.

In the United States the tax code is a lot more complex. You pay different taxes if you're married compared to if you're single, capital gains tax rate depends on your other taxes so brokers can't automatically withhold taxes, and there are a lot of edge-cases for certain other situations that can't be easily automated. Like tax credits if you're affected by natural disasters, different tax handling for railroad worker pensions, and so on.

With that complexity it is a lot harder to automate taxes, but it's also hard to retroactively reduce that complexity, as any changes will negatively financially impact some of the affected groups. Also I think that it might be easier in the US to handle those aspects as part of the tax system (instead of handling them independently), as the federal government has the authority to collect taxes, but direct payments (outside of the tax system) to individual groups might be harder? (But I'm not sure if that's true).

The bootloaders of the devices that Google sells in its own store are already unlocked. The only exception are Google phones that are bought from some mobile carriers such as Verizon.

> I think the real question is what "usernames" will look like. There were hints dropped that this could be stronger than a typical username (like what HN has).

Quite a bit of code related to usernames has already been checked into Signal. Here's the username regexp and the method that checks if a username is valid: https://github.com/signalapp/Signal-Android/blob/a5e5a735800...

Are you sure that Cloudflare supports ARC? Last time I checked they used SRS for sender rewriting (that's why SPF doesn't fail), but didn't support ARC yet.

The expensive price of the tests is actually a whole different problem. For the last tests that I bought at Walgreens (InteliSwab) I paid around $25 for two tests.

Meanwhile I'm currently in Europe and as a consumer I can buy Antigen tests for around 3 Euro per test (would be less than 2 Euro if bought in bulk). As far as I know those prices are not subsidized.

Materialize definitely looks interesting. I'd have a few questions regarding the current product:

Does Materialize provide a commercial non-cloud version where workers can run on multiple nodes in a cluster? On the website I only see references to the BSL-licensed single-node version and to the cloud version that is hosted at Materialize. Would a company be able to run Materialize on their own Kubernetes cluster?

Also is it possible to add custom code for data sources (for example Kafka, but with a different format than what Materialize currently expects) or is Materialize limited to the pre-defined sources?

That would work. But then there's also the question if the received transaction counts as taxable income in the jurisdiction of the receiver. If that's the case and if they received a very significant amount they would be forced to sell some of the coins so that they can pay the tax for them.

> Seems like the only answer for Tile is to get integrated with Apple's solution.

Tile is planning to use Amazon Sidewalk: https://www.thetileapp.com/en-us/blog/announcing-tile-joins-...

> Monetize the live stream too.

Don't forget to sell the containers as NFTs.

Simple was one of the few US-based checking accounts that required US citizenship in order to open a new account (a Visa or a Green Card was not sufficient): https://medium.com/@bartclaeys/simple-bank-discriminates-aga... (this has only been an issue since BBVA acquired them).

> [Edit] When I delete my account I'm going to lose old conversations, but that doesn't bother me anymore because I already recently lost them once when I switched from Android to iOS... WhatsApp has no way of keeping your history in that case. And otherwise there's really no friction to deleting an account, since you can always recreate it.

There are several third-party tools that allow to convert the history from Android to iOS. I recently switched and was able to keep all of my history.

> Quick note: Google's Advanced Protection program disallows sideloading apps, so you can't install F-droid.

It's still possible to sideload apps if they are installed with ADB.

The original Ripple site was available for a while under https://classic.ripplepay.com/. I just noticed that Ryan is now operating it under the new domain https://rumplepay.com/.

There's a lot of public documentation available that describes how those systems work. Even on Cellebrite's own website: For example on https://www.cellebrite.com/en/blog/android-acquisition-simpl... and https://www.cellebrite.com/en/blog/iphone-extractions-5-ques....

There are definitely some workarounds for encryption available. For example, it appears that even for some newer phones Cellebrite supports an approach of brute-forcing the PIN without locking the phone due to too many retries. But those workarounds don't seem to be the primary benefit / use-case of Cellebrite: It seems that in lots of cases people surrender their passwords when asked and the main benefit of Cellebrite is in extracting and presenting information from a phone once it's unlocked.

Once unlocked data from iPhones is relatively easy to extract with a local backup. Android is much more limited in terms of which data is available as backup and the common approach appears to be to use ADB for extraction. Either by downgrading an application or by automated screen-scraping of the data (or by using exploits on outdated Android versions). For WhatsApp it appears that the "downgrade" approach might be used, which downgrades to an earlier version that makes extraction easier. That's the same approach that's also used by consumer backup tools such as Wondershare Dr.Fone.

Regarding the more complicated approach to extract data from Android: Starting with Android 11 and API level 30 Android is starting to ignore the allowBackup manifest attribute, thereby allowing to locally extract data from applications via ADB even if the applications don't allow that (source: https://www.xda-developers.com/android-11-force-app-local-ba...). While definitely a benefit for users, I wonder if another motivation for that change was to simplify data extraction for law enforcement.

Quoting from https://github.com/microg/GmsCore/wiki:

> This is alpha-grade software and not yet ready for production use. Do not use if you don't know what you're doing.

Personally I'd also be concerned that Google's bot detection code might mark accounts that use microg as suspicious (as they're going to behave differently than phones using the official software) which could increase the risk of Google banning the account.

> IntelliJ is working on porting the JetBrains Runtime to Apple Silicon. The apps currently work through Rosetta 2, however building via Gradle is extremely slow. Gradle creates code at runtime, which seems a particular bad combination with the Rosetta 2 ahead-of-time translation logic.

Java does not need to be run through emulation. Azul already published ARM64 Zulu builds for OpenJDK (here: https://www.azul.com/downloads/zulu-community/?package=jdk) and they work great on the M1. I'm currently using IntelliJ running in emulation mode (an official release for the M1 was originally expected by the end of November) and but build/run my projects on a local Zulu JVM with ARM64 support.

On one hand I wonder if it makes sense to get an old Pixel 1 from eBay so that I can continue to upload free photos forever (or at least until the Google Photos APK is not updated anymore for the old Android version running on the Pixel 1).

On the other hand I wouldn't be surprised if Google just closes the accounts of people who upload large amounts of pictures and videos (taken on another phone) with the Pixel 1.

One benefit of blocking sideloading is that it prevents people who have brief access to your phone (border agents, police, etc.) from installing spyware apps on the phone. On iOS those people can extract your data as local backup, but they won't be able to install any unapproved apps that run in the background and that monitor you. On Android it's trivial to install spyware apps via sideloading and regular users most likely aren't able to detect or uninstall them.

One fact not mentioned yet here in the comments is that a very similar approach already exists in the United States: If you don't pay off your phone your IMEI is blacklisted and (as far as I know) those blacklists are shared between the major providers in the United States. Therefore the device lock discussed here won't make a large difference in the United States.

The primary use-cases are probably:

* If used in the United States prevent fraud where someone uses a stolen identity to obtain a phone and then sells it in another market (that doesn't use IMEI blacklists) once it arrives.

* If used in other countries that don't have IMEI blacklists to provide a similar functionality as those blacklists. One benefit of that is that it could reduce the credit requirements and make it easier for people with no or a poor credit to obtain a phone.

> This is a nice benefit of Google Fi. Since swap attacks are not possible with it, as customers support agents aren't able to do sim swaps.

Are you sure that this is the case? According to https://support.google.com/fi/thread/761170 there was at least one case where support agents moved a Fi number from a locked account to a newly reopened account, without the user being able to access the locked account:

> I call Google Support and the amazing Google Support rep I spoke to (The only good one I’ve talked to so far during this whole process) stayed with me for over an hour and worked with tier 2 support in getting my Project Fi number transferred to Account 2.

A SIM swap with Fi might be harder to accomplish than with a regular provider, but it looks like there's still the risk that someone manages to convince a support agent to move the number to a different account.

> Back then and still now, I think Google need to make it easier to handle this situation. Strong end-user support in these situations is hard because genuine fraudsters will happily file support tickets and socially engineer support to get their accounts back - I even witnessed auto-generated pleas to support once.

How much are accounts currently worth on the market? It seems that making the recovery procedure more expensive than the worth of the account should resolve that issue. At the same time legitimate users are probably willing to invest some money in order to recover their account.

For example offer a $20 option to send a registered letter to an address provided by the user. Then Google can check if: 1) The name on the credit card matches the name on the account, 2) a given address hasn't been used too often, 3) the identity check done by the postal service (checking if the recipient actually has a given name) succeeded.

This won't be a perfect solution and there are definitely edge cases for which it won't work (in countries without registered mail, if someone doesn't have a credit card, etc.). But it should be able to cover the majority of cases where legitimate accounts have been locked.

The word "Beamer" is a German word that isn't really used (in that context) in any other language. Same as with "Handy" for smartphones.

Enabling the reader view in Safari also shows the whole article.

My impression is that in Germany (and lots of other European countries) people just directly send money via SEPA. Usually that's free and all you need is the IBAN number of the recipient. And with banks that participate in SEPA Instant a transfer doesn't take longer than a few seconds.