cbzoiav

Most credit cards in the UK at least (same cap) have no standard account fee. Those that do come with other perks / beyond the 'world elite' etc side Mastercard/visa aren't seeing that money - its going to the issuing bank. Bank accounts also generaly have no standard fees (and a lot of other things we take forgranted - faster payments (if I send money to a friend/business I can do it instantly for free without needing a third party solution), standing orders, direct debit etc. - that make banking far easier than in the US).

There is also regulation in place that restricts predatory fee practices, getting customers into revolving debt and protection that makes card issuers liable for purchases (Section 75 - e.g. if I order something paying with my credit card and the merchant doesn't pay, the card issuer is legally liable / I can claim from them and its on them to get it from the merchant)

A fork can be many things.

I've maintained in house forks of major code bases with a handful of minor code changes while we've tried to convince upstream to accept them.

I'm not saying otherwise - my comment reaffirms this. There are two separate things going on here -

- You can buy a reasonable wheelchair for moving people relatively short distances across flat surfaces for less than $1000. E.g those used in hospitals and for the partially mobile.

- You cannot currently buy a reasonable self propelled wheelchair for full time use for less than $1000 (give or take the manufacturer in the article).

Difference being it doesn't fail and if it does you know exactly how it was made and under which process. There will be an investigation to see what went wrong - was it the screws fault or was more force placed on it than it was certified for.

Vs the one from the hardware store could have come from Alibaba and be a plastic core with a thin coating of metal for all you know.

Except the wheelchairs used in hospitals are to push patients short distances across hard flat floors.

You just need to ask Chat GPT then ask Gemini and CoPilot if the answer is right.

We've gone over a month without burning any coal, but then the Ukraine war happened and we were at risks of blackouts. That 1.1% is likely heavily concentrated as a much higher percentage on a relatively small days over winter and/or where wind levels were low.

We probably want to be sure if gas imports are heavily hit again or a major interconnector goes down we'll be fine before entirely demolishing it.

It's not a case of can they be. It's a case of can they cheaply be.

The camera app on your smartphone likely searches for them by default. That means feeding at least 1-2 frames a second through it.

Basic pattern matching for the position markers is a rounding error overhead vs processing a video feed. Fancy computer vision is not - on lower end devices you may not have enough resources to do both and on higher end devices it'll still impact power usage.

Even just crashing the device has significant impact.

A bank robber, terrorist or totalitarian state could benefit significantly from bringing down all cell phones in the area for a few minutes (or even just crashing them in a loop as they boot up).

We're talking something the size of a cell phone that can be powered for days on a battery. Hide it near the cell tower and leave. It takes specialist equipment to locate it so by the time someone has figured out what has happened and either got that equipment in or just done a manual search it's been hours to several days.

Or for some mayhem just stick a few of them under seats on public busses / trains set to activate at the same time.

The only thing I can think of is if it was widespread it would be a security risk. Not exactly difficult to broadcast a stronger signal with the wrong time.

Similar problem with GPS being used for clock sync in mobile/cell base stations in much of the US. You can buy an (illegal) jammer off Ali express and bring down a tower for very little money.

"We recommended you went for X and listed SMS security problems as the reasons - here is the email chain"

You need to cover your ass, but you don't want to actively push back and risk losing the sale.

There are a huge number of app based solutions. Enterprises are against them because they can't expect their employees to install 20 different apps for 20 different vendors + the cost of reviewing and onboarding them.

So you either need to support SMS or several of the major 2FA app providers including the crappier implementations like Microsoft authenticator.

Yes, which is what I said.

But now you have a released lock and a client that thinks they have the lock.

As the other guy says the lock is released by the server. If you don't have a mechanism to release it after a timeout, what happens if a node fails?

The customer upset staff so they were cut off to protect staff welfare is a valid business reason.

Or even the older setups where you had a relatively small battery in the device and a bigger wedge shaped battery that could clip on the bottom.

Or there were a couple of devices with dual battery slots so you could hot swap.

Then on odd occasions when you need it just take the extra battery/ies.

Not at all. You get web apps, services for providing them etc.

As far as I'm aware ICANN/Google (owners) put no restrictions on use case.

There is a restriction requiring TLS.

I'd view it more similarly to the whole Reddit fiasco.

There is a valid problem. The business has tried to solve that immediate problem without worrying about the knock on.

In this case blocking large funded competitors ripping off your work is valid. The way they've approached it has cut off a large number of valid use cases that have arguably driven adoption of RHEL in the first place.

In Reddits case for profit firms were hammering APIs and costing Reddit significant amounts. 3rd party apps also cut off ad revenue. A flat high fee cuts off those 3rd party apps entirely when your own product has significant deficiencies it upsets your most valuable users (contributors and mods).

In both cases there was potential for a more nuanced change that works for both sides.

From my comment.

HTTP/2 reduces the problem with multiplexing but it still doesn't go away

Even multiplexed you hit initial TCP window limits + all the response header overhead.

And many cases you have dependencies - need the first HTML content to issue the JS request to issue the Auth request to issue the API call to issue the dependent API call...

Multiplexing isn't a golden bullet. You still hit limits.

The initial TCP window is usually around 4KB so you have the handshake SYN RT (+ another two for TLS) followed by at most 4KB of request data. Cookies, auth headers etc. can make that a relatively low number of requests before you need to wait for the next RT. You also have the TCP window on the responses and again headers for large numbers of requests eat into that.

And then as you say dependencies - load the HTML to load the CSS and JS to Auth the user to make the API calls (sometimes with their own dependency chains)...

You dropped the API calls bit.

As it stands your site has to go through a TCP handshake then send the request and get the start of the response - at minimum that's 2 round trips. It then gets the JS and CSS tags in the head of the HTML and has to request those - let's assume HTTP/2 so that's another single RT of latency (on HTTP it's at least two depending on if you queue requests or send in parallel).

On 215ms RT latency that is an absolute minimum of 645ms before your JS has even started to be parsed. For a large bundle with a load of vendor code at the top in practice were talking several seconds to getting to the code that makes the API calls to get the content needed to render the first page.

And this is before we talk about any Auth, images, opening a websocket or two and people using microservices as an excuse to require a request for nearly every field on the page... (Or worse multiple requests and applying some logic to them...).

There is a fundamental minimum RT bound to a static JS based web app that is a multiple of a server rendered page. If you cache the HTML and JS bundle it can be worth it but you still need to aggregate data sources for the page on a backend and/or host it in multiple regions.

Size isn't even the worst of it. It's number of requests.

You need to go through a TCP handshake for every connection you open. You can reuse the connection but that means queuing requests and hitting the latency as a multiplier. Browsers also have a cap on parallel connections so when you get enough requests it queues either way. HTTP/2 reduces the problem with multiplexing but it still doesn't go away.

If your app has to make 40 requests pulling in js files, CSS files fonts, API calls etc. to show something useful that will be visibly slow the moment a user is out of region. If it's a single server rendered piece of html it's a single request.

Then for real fun be in an enterprise environment with Kerberos Auth adding a load more round trips to the server. For even more fun add in a mobile browsing solution that only has ingress in a far region when the site is hosted locally!

So release a handful of budget models and support them well instead of 60+ per year.

I'm on a pixel 6A. It cost me under £200 factoring in the trade in deal that let me trade in a 10 year old phone (if you don't have one eBay one for £5).

And there are plenty of reasonable smart phones for less than £100 these days. You can get something like a Motorola E13 for under £70 that will do everything most people use their phones for well (beyond the camera being nothing special, but we're comparing to a dumb phone).

The ship failed. What we don't know yet is whether the carbon fiber hull is why.

The price isn't listed because it depends on bulk, anticipated support and support contracts (ongoing revenue), anticipated future sales etc.

If an independent shop wants 2 cameras you charge them enough to make a profit on the overhead of dealing with them (or point them to a retailer if they want less than a pallet).

If Walmart want 2 cameras to try out you give them (or loan them) to them for free knowing if they like them you'll be shipping them by the pallet for years.

Depends how you phrase it.

"Jessica is the reason we hired you - she says you'll be great here and when she says that she's always right" technically says "we weren't going to hire you", but also "we all believe in you".

Challenger Deep is exponentially more difficult than this - 10km Vs 4km so over double the pressure.

While it may still be an entirely unsuitable material for 4km, not being suitable for 10km doesn't prove that.

You just need resources to burn on destroying enough hulls for the data.

Unmanned submersibles have plenty of market value. You may still be losing money, but you can strap sensors and cameras to the thing / undercut on price for research missions and substantially reduce the cash burn while building investor confidence.