r00ty @ r00ty @kbin.life

I'm the administrator of kbin.life, a general purpose/tech orientated kbin

---

Read more

Posts

2

Comments

1,265

Joined

2 yr. ago

The thing is, they do already have lock-in in some ways at least. Otherwise I cannot imagine a restaurant wanting to give away 30% of each sale this way. Unless the other option is virtually no traffic.

Now see, I kinda had the idea for a syndicated delivery service (not online orders, but the internet would have been used to create the order data that would assign drivers) decades ago. I did some part time work delivering food back in the late 90s/early 2000s, and I always thought it was so inefficient. The place I was at, was very busy, he had a very large delivery area but even so. There would be times he was paying people to sit outside talking shit to eachother in their cars.

I thought it would make sense to have a larger pool of drivers that service multiple restaurants/take-aways. Adding the economies of scale to the problem to ensure that people were being utilised and lowering the cost to each place using the service. Of course also paying some money to the person running the business that brought it all together.

I don't think I ever considered paying less than this guy did (which wasn't a lot, but would likely translate to $5 or so an hour in the 90s/2000s).

One thing I find really interesting about uber eats/door dash (US)/Deliveroo (UK/EU). When you add up their fees, they take a delivery fee from the user, a service fee from the user, an even bigger service fee from the restaurant and pay the lowest possible fee that will keep drivers interested. Yet I always hear the services are losing money too. How is that even possible?

Take deliveroo in the UK. Looking now I can see (I don't live in a city, so most places are some distance away). A place 4.5 miles away is charging £4.29 for delivery. Let's make up an imaginary order:

Order total: £20 (including sales tax/VAT) User's service fee: £2.39 (it seems to be 11% including the VAT with a maximum set of which I am not sure how much) User's delivery fee: £4.29 (including VAT, since they need to charge VAT on a service) Restaurant service fee: £6 (30% on the VAT included total). I am really unsure how this works entirely in terms of tax though... Total for user: £26.68

Total deliveroo service revenue: Net: £10.57 VAT: £2.11 Total: £12.68

Reading between the lines from what I can see delivery riders are paid between £3 and £6 per delivery. Now, in the cities this is probably great. I do wonder how they do it in the towns and villages. When I look at the list of places available to me most are 3 miles or more away, with some up to 6 miles away. I do wonder how £6 compensates someone doing a 10+ mile round trip at times.

But OK the price they pay drivers doesn't include any tax. So it comes from the Net total. This means per delivery in revenue they are always making £4.50 or more per delivery.

Yes, they need to pay support staff, but they are in low cost geographies. Yes, they need to keep development staff and the usual management overhead And yes, they need servers/cloud time to host this stuff.

Looking this up (not sure how good the source is) their revenue in 2023 was £2.7billion, which I believe. However they lost £38million. Where all the costs come from, I am not sure.

I wonder how these numbers compare to US based operators?

Well, I mean if you want to go down the 1984 route (I hope not), a VPN license is a great tool for achieving such things.

I'll give you an example, I have an amateur radio license in the UK. Part of the terms are that I must allow anyone authorised by Ofcom (the radio telecommunications agency over here) access to inspect my equipment and setup.. Now ideally it would be in a building other than my house. But for most people, it would probably be in their house. So you need to let them in.

VPN License? Well probably it would have the same terms. "Excuse me sir, we have detected the use of VPN traffic at these premises. We are warranted to enter the premises for the purpose of ensuring this traffic is related to the primary business as noted on your VPN license, please step aside from your computing devices"

Alright, it won't happen in reality. But, a lot of countries really have wanted to crack down on the use of encryption for some time now.

I think it'll be a "we'll see" situation. This was the main concern for y2k. And I don't doubt there's some stuff that was partially patched from y2k still around that is still using string dates.

But the vast majority of software now works with timestamps and of course some things will need work. But with y2k the vast majority of business software needed changing. I think in this case the vast majority will be working correctly already and it'll be the job of developers (probably in a panic less than a year before as is the custom) too catch the few outliers and yes some will escape through the cracks. But that was also the case last time round too.

You're right on every point. But, I'm not sure how that goes against what I said.

Most applications now use the epoch for date and time storage, and for the 2038 problem the issues will be down to making sure either tiime_t or 64bit long values (and matching storage) which will be a much smaller change then was the case for y2k. Since more people also use libraries for date and time handling it's also likely this will be handled.

Most databases have datetime types which again are almost certainly already ready for 2038.

I just don't think the scale is going to be close to the same.

Really? None. I suspect one or two of the literally 100s of non partisan candidates were actually there to do good? I think the point being made (and this goes for all democratic systems), is that 99% of the population could not name more than 5 names on the ballot. Let alone consider voting for them.

People vote for parties and ALL of the parties are funded by someone. Ultimately, we do it to ourselves.

Not really processor based. The timestamp needs to be ulong (not advised but good for date ranges up to something like 2100, but cannot express dates before 1970). Or llong (long long). I think it's a bad idea but I bet some people too lazy to change their database schema will just do this internally.

The type time_t in Linux is now 64bit regardless. So, compiling applications that used that will be fine. Of course it's a problem if the database is storing 32bit signed integers. The type on the database can be changed too and this isn't hard really.

As for the Y10K problem. It will almost entirely only be formatting problems I think. In the 80s and 90s, storage was at a premium, databases were generally much simpler and as such dates were very often stored as YYMMDD. There also wasn't so much use of standard libraries. So this meant that to fix the Y2K problem required quite some work. In some cases there wasn't time to make a proper solution. Where I was working there was a two step solution.

One team made the interim change to adjust where all dates were read and evaluate anything <30 (it wasn't 30, it was another number but I forget which) to be 2000+number and anything else 1900+number. This meant the existing product would be fine for another 30 years or so.

The other team was writing the new version of the software, which used MSSQL server as a back-end, with proper datetime typed columns and worked properly with years before and after 2000.

I suspect this wasn't unusual in terms of approach and most software is using some form of epoch datatype which should be fine in terms of storing, reading and writing dates beyond Y10K. But some hard-coded date format strings will need to be changed.

Source: I was there, 3000 years ago.

I thought the web page layout looked familiar.

1999. I was part of the ADSL trial in the UK and have been on a form of broadband ever since.

Resistance alone doesn't cause heat. Drawing current through resistance causes heat at the point (or points) of resistance. Which is why I clarified that it's not likely so much a problem on small loads.

This is why resisters come in different physical sizes. Because they have differing abilities to dissipate power as heat.

A good example is of dummy loads in radio use. Which needs to dissipate the power output of a radio. That can be anything from milliwatts to a kilowatt. Up to probably 50w they will have a basic heatsink. I've seen huge drums filled with oil as 50ohm resisters to handle up to a kilowatt of dissipation.

Yeah, I think in this case there's a lot more tiny conductors sharing what can add up to pretty high current loads on PD connections. Adding extra connectors adding resistance to low (5-20v) voltage high current connections is adding an extra failure point and increasing resistance on the whole cable run.

Not inherently unsafe, but just not a good idea to promote because you know someone will try to run a 200w charging cable for 30m with like 5 connected cables.

I think a lot of people are mostly on the money here. It's to do with resistance. Now, I'm not a qualified electrician, but I'm an amateur radio license holder and a lot of what you learn for that is applicable here.

The main problem as many have said is resistance. This comes about from both the length of the conductors but also from every plug/socket connection adds resistance. Also in the case of the non extension socket multipliers, as you add more the weight bearing down would also likely start to make the connections less secure causing more resistance and possibly adding to the problem through arcing.

Now the resistance alone on small loads likely wouldn't be a huge problem. But if you had a large enough load (specifically at the end of the stacked connectors/extensions), or a fault that caused a larger than expected load the current would cause the resistance to generate heat.

There's a lot of ifs and maybes involved, but really why do it? There's really no real world situation to need to have a dangerous amount of extensions like this though.

For larger loads here in the UK there's some very specific other concerns when dealing with ring mains. But really you'd need to do really weird/unusual things for that to become a problem.

Instance level censorship isn't much for the user to worry about (I run my own, so it's zero problem for me). Most censorship happens at the group level by group owners, and the admins on the instance the group is hosted.

I still don't have a problem with it though. You subscribe to a group on a certain instance, you cannot be too surprised if you get censored there.

Yeah but they're a cheat. They're lithium cells regulated down to 1.5v. Good ones are rare, when you find good ones they're generally expensive and because they're regulated down you generally get 100% battery showing until just before they fail.

I used them for some voltage sensitive stuff, but finding a brand that held a good charge for more than even 50-100 charges was hard.

Nimh is much better for anything that won't be upset about the voltage too much.

Aha OK. Then yeah I misread it. That makes a lot more sense.

To be fair, I bought a really good mini pc for a home server. The problem is, it was marketed as a gaming pc. But with the on chip Intel HD graphics.

I can understand why this would upset people. For my uses though it was perfect. Sits in the TV cabinet, is quiet yet still quite powerful (intel 12900).

How I read it, they want to use a domain to validate the use of a handle. With the huge variety of tlds the same domain part could be registered many many times.

If I did misunderstand, then sorry. It's how I read it.

There's a lot of tlds. Do they explain the policy when two people have the same domain on different tlds? I mean oldest registered makes sense to me. But not without problems.

Well. When you're on the wrong side of the supply vs demand situation, you need to pay the piper, I mean miner.

Just to expand on this. The app likely isn't always running in the background listening (since that's what it seems the op thinks). The push message causes the android system to wake the app to deal with the message. Otherwise it's not actively running (and you can limit background running in android settings per app).