Bear in mind that in the UK, a large chunk of the populations lives in either rented accommodation, high-rise flats, or both. And also, standard housing policy in London is for new developments to have fewer parking spaces than homes (to encourage public transport use over cars).
For many people in the UK, having an EV charging port on the side of your house isn't possible, because they don't have a house, or they don't have a parking space near their house.
FWIW, rental rates are very similar between the UK & the USA.
For central London, where I've lived for most of the last decade, yeah, there aren't a lot of parking spots per household, but that's also going to be true in NYC or any other built up older city. As for newer developments, I suspect they get more parking than older ones. My Victorian block has none.
As always, London is not the UK. Outside London it seems good in well off areas for EVs, and, of course, bad in the neglected rest of the UK.
Lots of local authorities are installing on-street charging.
Basically, the vast majority of people in the UK do have off-street parking. Running a cable to a garage or from a street-lamp isn't overly expensive. Those who park on public streets also have lots of options for charging.
That's fair, but also, a plurality of households have off-street parking, so the amount we need to solve for is already lower.
We DO need to solve for it though, because it's ridiculously cheap to drive an EV in the UK if you can have an L2 charger installed (2p per mile versus 20p per mile for even an efficient diesel/petrol car) and that should be made available to all.
Is the solution chargers in every lamp post? Or on every off-street parking, with billing tied back to your energy provider (allowing you to use smart tariffs like Intelligent Octopus Go)?
> EV charging port on the side of your house isn't possible, because they don't have a house, or they don't have a parking space near their house.
By a process of elimination, we determine that they must be using on-street parking other than near their house. Which is one of those sneaky subsidies that people don't even realise is a subsidy, a little area of publicly owned land that you can use without having to pay rent on.
Then the proposal doesn't affect them one way or the other.
But as public transport is electrified, it is perfect to be incorporated into the grid. Vehicles follow predicted schedules, they are used in a predictable way from the depots, so charging can be optimized, and knowing their schedule, the charge on the battery can be kept optimized as well.
That looks like a US version of Faster Payments* (UK) or SWIFT (Eurozone) that enables instant wire transfers between bank accounts. I doubt very much it is suitable as an alternative to credit/debit cards for retail payments. For one thing, there's zero fraud protection, it's the electronic equivalent to paying for something with a cashier's check. For another, it's a pretty laborious process - you have to sign in to your online banking, enter the recipient's bank account details and the correct transaction reference, probably do some kind of 2FA.
For a third thing, while in the UK banks generally don't charge anything for transfers, the Bank of England charges a few pennies (£0.07 last I heard) per transaction. If people were routinely making several of those payments every day the way they do with cards, I'm sure banks would start charging fees.
* By the way, Faster Payments went live in the UK in 2008, but it still took a couple of years for all consumer banks to adopt it.
Britain used to have Paym, which would have made the process simple — except the banks never promoted it for business use, and barely promoted it for individual use.
In Denmark we have MobilePay, and similar systems exist in several other countries. I rarely use it in-person in businesses if I can pay with a card instead, but since McDonald's and Burger King both accept it I think it's popular with teenagers. I most often use it at very tiny shops and bars, who accept either MobilePay or cash.
The other comment about a small $5 transfer reminds me I recently paid 10kr ($1.50) for a cloakroom fee using MobilePay.
It varies depending on how much the business has spent integrating the system, but essentially you scan a QR code and swipe to transfer the money.
The lack of fraud protection isn't a big deal, as it's replacing smaller cash purchases.
(I also use it transferring money between friends, and sometimes when ordering online as it's a smoother process than paying by card.)
In Poland a lot of stores accept BLIK payments now which are instant online payments from your account. You open your banking app on your phone, it shows you the BLIK code, you give that to the merchant who types it on their terminal, then within couple seconds you get a popup on your phone saying "Merchant X is requesting payment of Y PLN, do you agree?" if you press yes then the payment is sent instantly to them, both sides get a confirmation.
It's also fantastic for payments over the phone because you no longer have to give anyone your card number/expiration/cvv(how this is still acceptable practice in UK is literally beyond me), the code is single use only and you see who you're paying and how much.
Sure, but vast majority of day to day transactions that people make do not need this kind of protection - I don't need the ability to reverse my payment when buying groceries at Lidl or paying for petrol. When buying a laptop or a phone, I would use a normal card exactly because it offers certain protections - but most day to day transactions are absolutely fine with what is an equivalent of a direct bank transfer.
In the UK you can still do things that way, but that's more common for paying bills etc, although it's a little less laborious than that.
For more casual usage, you can just use your mobile bank app to generate a payment request for a given amount, pass it to the other person (can do via QR code or link), it opens up in their own bank app, they click approve (or deny). It works pretty well between a variety of different banks, well I've not experienced it fail yet...
(There was also a payment system for a while that went via mobile telephone number, but it didn't get great uptake and was decommissioned after a few years).
> I doubt very much it is suitable as an alternative to credit/debit cards for retail payments. For one thing, there's zero fraud protection, it's the electronic equivalent to paying for something with a cashier's check. For another, it's a pretty laborious process - you have to sign in to your online banking, enter the recipient's bank account details and the correct transaction reference, probably do some kind of 2FA.
It's already solved, just point your app to the QR code generated by the same terminal you use for CC.
I've always felt one of the main reasons for this is that we never really got true microtransactions on the web. Pretty much all payment processors charge at least $0.20-30 per transaction.
My theory is that if there was a way to frictionlessly pay, say, $0.02 to access a piece of content ad-free, most people would be pretty okay with it. They key part is making the transaction frictionless - no more than 1-click/1000ms.
What's the challenge in already having this? There could be an aggregator service that has all the news sites joined with it and pays out on your visits to those news sites? Is it that it would be hard to get all news sites or content providers to accept this single one universal service?
They'll never do this because it dispels the illusion of independent media. It's the same reason cable news buys and shows ads: they want you to think the rest of the content isn't for sale. The truth is that the news is paid for by people who want to control the narrative, whether it's Logan Paul or Uncle Sam.
Old Flattr was something along those lines. You had to click though. (Like the old embedded Facebook likes. Are they old? Haven't seen them in a while, could be because of uBlock though.)
I really liked it. A view Blogs, Podcasts and the KeePass-Homepage had it. Then they sold to Chines investors and pivoted to god knows what.
If publisher accounts can be billed by the payment processor every month instead of every transaction and processor charges based on a percentage of monthly transaction.
I feel this is a business negotiation instead of a tech issue. But then I may be just clueless.
Yeah, I'd like to see a really good microtransactions implementation.
Including some way to keep that from marginalizing people in the current very inequitable capitalist environment.
A non-technical challenge is that you'd need someone to lead this in good faith, and they'd need both principles and clout. The first 5 candidates I thought of just now seemed much better candidates in the past, than currently.
On the same basis, most home routers are powerful enough to run a basic webserver, and they are much more likely to have a consistent internet connection. They probably aren't behind CG-NAT, and most of them have Dynamic DNS support even if they don't have a static IP.
I remember that way back when, Deutschebank standardised on SuSE because they were a major shareholder in the company. DB had an IT department bigger than most entire companies, so I'm sure that had a pretty big effect on the ecosystem.
Have you ever tried accessing the modern web with a Windows 95 computer using Netscape Navigator?
Even if that computer had up-to-date certificates, basically nothing about it would be compatible with the modern internet. It's not just a question of of "expiry dates", it's that you cannot make any forward progress if you have to maintain backwards compatibility forever.
Internet protocols, file formats, hardware standards... all these things need to be able to change over time. Hell, with the old phone example, your biggest problem with a sufficiently old phone is whether it can even connect to the network - I recently tried using a retro Nokia as a backup phone, but realised that the SIM card I'd put in it was for a network which didn't offer 2G coverage. Phone couldn't even make calls or send texts because it wasn't 3G compatible.
Yes, and it worked hilariously well, because we've worked on bridge technologies for things like this: whether it's local proxies to strip or modify SSL or even just render an entire page as an image and transport it to the old browser as-is.
Solutions will come and go. Hell, what's stopping someone from building an on-device VPN that does the SSL translation itself?
Based on their published user numbers and revenue, Selig estimated that reddit's revenue per user is about $0.12.
They are asking for $0.24 per 1,000 API calls. Apollo averages ~345 calls per-user per-day (although some users are much higher), but Reddit claims that other apps are "more efficient" and only use about 100 calls/day.
If we assume 100 calls/day/user, then that's 36,500 calls/year/user, and a user is worth $0.12/year, so to break-even, reddit should be charging about $0.003 per 1,000 API calls, instead of $0.24.
> I guess there's an analogy um the way Reddit notifications work just for your inbox like you got a message or something um they work in so far as if I the developer of the app want to um say make sure that you get that notification within 10 seconds I have to be checking Reddit every 10 seconds to go like is there anything new is there anything new? is there anything new? is there anything new? okay. There is okay I'll tell is there anything new and then just repeating that at nauseam so you can imagine if you get a message once a week I'm checking every 10 seconds and then once during that whole week I get that message and then I can send it to you um so 99.99 of those API calls were wasted so we've talked to Reddit like that my friend who works on my server um and myself and I've said like what would be so much better is if we could just kind of keep like a port open with Reddit and say like you just tell us when there's a notification ready and we'll beam it off we don't have to bug you all the time and it's logical right and that's how a lot of services do it it's like an event-based API and um that's just not something reddit's ever uh given us
> The mobile front end does about 345 calls/user/day
> The push notification server does 8640 calls/user/day (one call every 10 seconds).
I've seen you parroting this around in every thread, and don't understand why.
First of all, none of the math checks out with your theory. But I'll break down why. Here[0] he says Apollo has over 100k DAUs (I noticed you've also stopped using that link...). He also says
> At 100,000+ users, that's in the realm of 60 million requests per hour that my server would have to handle, not to mention parsing the results, coordinating tokens, etc. I really can't do that for nothing, so the plan was to offer push notifications with a small fee associated to cover these ongoing server costs.
> I also offer a completely free system that does not use a server so those who don't want to have to pay can have their device function as the server and use local notifications (which are slightly delayed as it uses Background Fetch and using the device uses more battery), but remote notifications necessitate a server.
> If there's nothing that can be done, Apollo won't be able to offer push notifications unfortunately.
He has stated here[1] that API pricing would cost him "almost $2m per month."
So let's check the math.
345 + 8640 API calls / user / day = 8985 / user / day
8,985 API calls x 100,000 users = 898,500,000 / day
Or in API pricing $6,563,542.50 / month, which is almost 3x as much as he said it would cost.
> Note that it does a request every 10 seconds for each user. At the API rate that would be about $0.25 every 3 hours (for each user) to support it.
They only do that for each user, that has paid for and has an active Apollo Ultra ($5/mo) subscription. That's going to remove a significant chunk of users.
If you want to verify any of this for yourself, the backend code is also now fully readable[2]. But it looks like from their backend code, they do a maximum of 100 users[3] every 5 seconds[4].
Additionally, that's Reddit just being stupid not them. Reddit offers no alternative way to get real-time notifications from their API, and with the paid API won't as well.
The 100k users is the total username when he released 1.3 if he were to have that entire user base get push notifications.
He didn't do that - he set up a new subscription tier for the app to handle that. Not everyone in the 100k user base bought a subscription.
The 100k number was also from 5 years ago and is likely not accurate for today. The main value from that quote is as a description of how he was architecting the notification system then and the YouTube video is how showing that this is how he is still doing it.
Unfortunately, we're going from incomplete numbers that are being interpreted different provided by different entities. The best we can do is set floor and ceilings for the numbers. And I'll admit that my math may be off in places too.
What we can do is identify how much it would cost for one account with the push notification server request as part of the API cost (noting that one subscription may set up multiple accounts - see https://apolloapp.io/notifications-faq/ How many accounts/devices does this work with? ).
The estimate I have is that as the push notification server is written, it would cost about $2/day/account (8640 requests/day x $0.24 / 1000 requests).
$2M/month would suggest that he has about 33k users with push notifications. At about 1.5M monthly users that's 4% that signed up for a subscription.
That's a ceiling as I'm not counting the "how many requests per day come from an average user with the 900k daily active users claimed".
And yes, I will certainly agree that Reddit, lacking an event based notification system is an oversight in how their API was used.
The push notification server needs to be considered as part of the API load and it is really easy to get that number to grow.
If you scale back the notifications from 1 every 10 seconds to 1 every 5 minutes, it becomes a much more reasonable number with only 288 requests per day per user - which gets into very different numbers when dealing with a subscription.
Let's call it on average 600 request per day per user overall then, and you're at 18k/month/user and that's $5 of API use cost. Up the subscription from its current $4.99 to $9.99 and you've paid Apple's 30% (or 15% if more than a year) and Reddit's API costs and made a profit.
> If you scale back the notifications from 1 every 10 seconds to 1 every 5 minutes, it becomes a much more reasonable number with only 288 requests per day per user - which gets into very different numbers when dealing with a subscription.
Except you're still making up fake numbers. He was giving an example, not quoting a dedicated solution.
I even linked to their server code in my previous comment where you can see they do batches of 100 users every 5 seconds. Unless they only have 200 users, then it will not ever be “1 every 10 seconds” like you keep claiming.
The reddit API serves no ads. The Apollo app is ad free and only asks for a one-time payment for posting and a subscription to support development which comes with a lot of nifty but ultimately completely useless features. No third party app is blocking any ads from reddit because there's nothing to block
Presumably because if you are a party to a lawsuit, you generally shouldn't say anything about it without it being cleared by your legal counsel. Their lawyers might have advised them not to say anything publicly, or they might not have the budget to get lawyers to approve public statements.
ARM is a CPU ISA. A MacBook is a whole computer. A general purpose OS to be really useful needs to support the CPU, yes, but also the boot hardware, the bus, the video devices, keyboard, pointing devices, speakers, mic, line in, line out, the network hardware, internal storage, external storage, and preferably any peripheral through the USB ports or wirelessly that's USB or Bluetooth with a standard profile.
Also remember that M1 is not only ARM. It's a SOC which combines ARM cores with GPU cores and AI-targeted cores. Targeting just that is a lot more work than just porting the ARM portion from a Raspberry Pi or an Android phone. I'm sure just getting a framebuffer up was a lot of new work. Fully supporting the GPU cores will be necessary for a lot of people's use cases. Once that and most of the peripherals are sorted, maybe the AI cores will be addressed.
ARM is just an instruction set architecture specification. It is not any specific CPU; there are many different implementations (different chip designs). They can differ to various degrees, and often have at least a few non-standard features.
Hence, each ARM chip/platform often needs at least a little bit of special support (or drivers) to fully work in Linux, besides the standard ARM stuff.
Apple's platform is actually very different, with much more non-standard stuff, compared to other ARM implementations. Hence, much more extensive work was required to support them, than would be typical for other ARM platforms.
Even some of the really low-level features are different. For example, Apple have their own Interrupt Controller. Supporting it (in place of ARM's standard General Interrupt Controller) was a prerequisite to even be able to boot the linux kernel. Another weird thing about this platform is the bus configuration.
Also, Power management is something that is virtually always chip-specific, and the Apple M1 has some unusual quirks on top of that.
For many people in the UK, having an EV charging port on the side of your house isn't possible, because they don't have a house, or they don't have a parking space near their house.