rev_d

Shortly afterwards, they rolled out a local non-cloud API for any non v1 devices.

Unfortunate that older devices didn't get it, but at least they're following future-proof best practices going forward.

The government is well-aware of how inflation erodes reporting thresholds. If you look at the obligation to report non-US bank accounts to FinCEN, they've indexed the penalties ($10,000 per line item) to inflation but not the $10,000 aggregate reporting threshold.

As a recently recognised Italian citizen, I have to agree--it's not the appropriate place to form a startup.

There's a surprising number of things that involve the legal system, and the legal system moves at a glacial pace--in some cases, taking months between when a ruling becomes final and when it becomes enforceable. Encounter any one of those situations, and it's going to be a huge time & resource drain for the company.

Perhaps it'd make sense to headquarter the startup in a more favourable country (Estonia?) and then have a major branch office in Italy (for climate and talent reasons).

There's a USENIX article from a year or two ago about the "Biscuit" research OS, which was written in golang.

There were clear compromises & performance degradations related to using a GC'ed language, but it definitely was interesting enough that you hope for more.

I wonder if the high prices you're seeing are because you're looking at black & white film.

B&W film is quite forgiving of under/over-exposure, and it allows for push processing. On the flip side, every type of film has its own developing time & some mild chemical preference.

Color film isn't very DIY friendly, but it does have the benefit of being very consistent from a processing perspective.

From what I've seen, it's usually a difference of 2x or 3x in price for black and white vs. color (C41).

You should take a look into OpenCore Legacy Patcher

I recently did my 2013 MBP, and while it was a massive pain that left my hands hurting afterwards, I was able to do it without solvents or having to dismantle the entire system like iFixit said I would need to.

Probably spent about 20 to 30 minutes using some old sacrificial credit cards to break the glue & pry the cells out.

This paper lays it out pretty well. There’s a parallel tax code that is more complicated, and that’s before the nuances of tax treaties factor in.

https://papers.ssrn.com/sol3/papers.cfm?abstract_id=3795480

The big thing with the multinationals is that they're able to pull stunts like corporate inversions & royalty payments to their foreign entity to reduce their profit under the (more heavily taxed) US entity.

Then you have measures intended to rein them in like GILTI & Transition Tax, which end up mostly affecting smaller businesses.

What's also quite gross about this is that we have large multinationals paying zero in taxes to the US government, but there are small businesses owned by overseas US citizens that are being subjected to both resident country & US tax due to the US being "unique" in its practice of taxing overseas citizens.

If you're small, you get hit by the tax. If you're big enough for creative structuring, you're fine.

It's just as disgusting when you get down to individual tax. Larger companies are for the most part taxed territorially (where they make the money) while individuals are fully (and often in ways that are incompatible with local market practice) liable for US taxes, even if they live outside the US.

I'm not sure I'd describe it as fascinating, so much as abusive.

The really complicated and intricate bits are the web of Tax Treaties, Tax Treaty Protocols, Revenue Procedures, and memos that redefine how a foreign concept maps on to US tax code.

All of this complexity (and the accounting cost that goes with it) is because the United States is the only developed country in the world that taxes nonresident citizens. You end up with so many situations where it's hundreds to thousands of dollars to compliantly report foreign income, even though the total tax owed is $0.

That seems a little incorrect, considering that Ireland is non-English only on paper.

Sounds like a reason to avoid this product.

The Pinebook Pro is pretty temperamental when it comes to things like battery management & performance.

The Pi has more memory, more computing power, and is more reliable.

Get him a Pi, and if he needs a laptop, pick up a used Thinkpad to go with the Pi.

Source: I own both a Pi 4 & a PBP.

Some of the registrars are pretty picky about their rules.

I have a .es (Spanish) domain, and it wasn't until quite recently that they stopped asking you to include your passport number or SSN in the WHOIS entry.

A number of registrars wouldn't let you buy the domain without residence in Spain either... Ended up going with a horrible registrar, and I transferred to Namecheap the moment they supported .es domains.

I'm not too familiar with the local rules in Lithuania, but the EU has two different possible classifications for E-Bikes:

* EU-Spec E-Bike: Up to 25kph, No license / special equipment is required * Speed Pedelec: Up to 45 kph, Requires licensing, insurance, and a special helmet. In the Netherlands, you can't drive these on bike paths / may have to mingle with cars. * US-Spec E-Bikes: Up to 32kph, unregulated / illegal

In general, all three categories are capable of easily sustaining reasonably high 25 to 35kph speeds for 40 to 150km on a flat surface.

If you're dealing with hills or wind resistance, you'll need the beefier motor & battery of a pedelec, or you'll need a slightly more specialised E-Bike, but there's no reason why you couldn't make it work by throwing a bit more bike at the problem. I've taken E-Bikes around some of the medium sized hills in San Francisco before, and apart from having to pedal slightly harder and my battery usage doubling, cycling on a hill wasn't that much different than cycling along Market Street.

I'm wondering if the solution to this involves shipping more software via something like the AUR (Arch User Repository) rather than in binary packages.

It's not necessarily sane to maintain binaries for each and every device flavour, but as long as the code is reasonably portable & each manufacturer keeps their LLVM IR/JVM bytecode backends in order, that might be enough to overcome some of the pain.

I've always found Arch distributions to be more usable on ARM systems than Debian distros simply because they user-friendly ways of building & installing from source. Building from intermediate representation might be the right mix of obfuscation, performance, friendliness, and portability for the consumer space.

To the contrary. Of the three closest grocery stores, only one of them has a single cash line. One of the stores is cards only, and one of them doesn't even have any live employees.

Wouldn't it make a lot of sense to just use Pyspark with RDDs? Latency would be relatively high, but it'd also bypass the GIL while also being more modern.