Live data from Hacker News

Airpass – Easily overcome WiFi time limits

airpass.tiagoalves.me

261–270 of 278 posts

Re: Airpass – Easily overcome WiFi time limits

#261
post #208

Earlier quoted context omitted.

Worst offender being Google, who toggled on VP8 / VP9 decoding on YouTube despite the vast majority of devices only having h264 hardware decode. The aggregate waste in battery wear and watts spent is pretty staggering when you think about it, all so google could spend a few cents less per 100 streams.

Or they could just send the video uncompressed and then it would take even less hardware resources to decode on the client side. Why, in a sense it would be a lot more like decoding analog television signals at that point. (Not least of which since few clients would have the network bandwidth to handle more than 360-480p of that ;)

VP9 is not more bandwidth efficient than H.264. You’re thinking of AV1 here, which is only encoded by YouTube for VERY popular videos.

Re: Airpass – Easily overcome WiFi time limits

#262

Earlier quoted context omitted.

It's hard work writing free stuff for others, much easier to criticise stuff instead of getting your hands dirty.

It's hard work learning programming tools and optimizing, much easier to use a one-size-fits all framework that wastes the end-user's resources.

What's the incentive to spend a lot of time to optimize for something you're giving away for free?

Re: Airpass – Easily overcome WiFi time limits

#263
post #17

Earlier quoted context omitted.

What exactly is that doing? Is there some backend limitation for WiFi interfaces that making it think it’s Ethernet is faster?

It just resets the MAC address, making the router believe it's a new device, thus not subject to the "x minute" free WiFi.

I've never seen "x minute free wifi". What countries is that common in?

Re: Airpass – Easily overcome WiFi time limits

#264

Earlier quoted context omitted.

It's hard work writing free stuff for others, much easier to criticise stuff instead of getting your hands dirty.

It's hard work learning programming tools and optimizing, much easier to use a one-size-fits all framework that wastes the end-user's resources.

It's NOT intelectually challenging. Software engineers love to learn new things, but they do not love 10 different syntaxes for displaying stuff. Figure it out.

Re: Airpass – Easily overcome WiFi time limits

#265
post #41
post #29

Earlier quoted context omitted.

If you want a frontend for you app, you probably just use Electron and get it over with in a few minutes instead of digging through the docs for Qt or some other framework. Is it worth it? Probably not, since this is a single-platform app to start with, but JS+HTML are easy to theme and customize, and Qt is... not quite as simple.

Where did you get Qt from? This is, again, a Mac-only app that doesn’t even have any windows. It’s just a menu bar icon and a notification. That’s incredibly simple to build with plain old Cocoa and Swift.

Did you forget XCode? How many GBs is it these days?

Re: Airpass – Easily overcome WiFi time limits

#266

Earlier quoted context omitted.

It just resets the MAC address, making the router believe it's a new device, thus not subject to the "x minute" free WiFi.

I've never seen "x minute free wifi". What countries is that common in?

I’ve seen it at a few places in the US, typically somewhere they have a paid unlimited/fast plan but a free tier for a limited time to be able to say they offer “free wifi”. So places it costs money to offer wifi. Maybe a flight, cruise, etc

Re: Airpass – Easily overcome WiFi time limits

#267

Earlier quoted context omitted.

Those people could be driving from 20 minutes away or on their way home from work, or running other errands or picking kids up from school or any number of things. Good for you though.

Fortunately trains and buses exist.

Not where I live. Not where a lot of people live.

Re: Airpass – Easily overcome WiFi time limits

#268
post #138

Earlier quoted context omitted.

So the cost is there, it's just not paid (directly) by the developer. But we all end up paying someone else's externalized cost, included said developer that is paying some other developers' externalized costs.

Consider also the missed market opportunity: my personal devices are 13yo laptop and 9yo phone. If an app isn’t compatible or makes it lag, I delete it and download a competing one. I’m not alone, and yes: I have money to spend on your app. I just don’t want/need to upgrade hardware that often.

Kudos for keeping your devices for so long, I also try to have mine last as long as it's practical, but so far i didn't manage to have them last so long. Unfortunately, you're in a minority. Most people would change their phone once the apps they're using aren't compatible with it anymore. So devs don't consider this aspect much.

Re: Airpass – Easily overcome WiFi time limits

#269
post #46

Earlier quoted context omitted.

Modern app bloat in one analogy: Business logic size: ~20 bytes Total app size: ~47 MB = 47,000,000 bytes Bloat factor: 47,000,000 / 20 = 2,350,000 Let’s scale this up and say the business logic is 1 pound. Then the whole app would weigh: 1 lb × 2,350,000 = 2,350,000 pounds What weighs ~2.35 million pounds? - A fully loaded Boeing 747-8: ~987,000 lbs - Another fully loaded 747-8: ~987,000 lbs - A blue whale: ~330,000…

How many 747's can the average person fit on the 128GB+ smartphone in their pocket?

The commenter messed up on mentioning that a flash drive can be 1 pound, this would be more so the weight of a hard drive.

Re: Airpass – Easily overcome WiFi time limits

#270
post #208

Earlier quoted context omitted.

Worst offender being Google, who toggled on VP8 / VP9 decoding on YouTube despite the vast majority of devices only having h264 hardware decode. The aggregate waste in battery wear and watts spent is pretty staggering when you think about it, all so google could spend a few cents less per 100 streams.

Or they could just send the video uncompressed and then it would take even less hardware resources to decode on the client side. Why, in a sense it would be a lot more like decoding analog television signals at that point. (Not least of which since few clients would have the network bandwidth to handle more than 360-480p of that ;)

It wouldn't have taken less hardware resources, because would you look at that.. we find h264 hardware decode even in bottom-of-the-barrel mobile CPUs. Pure CPU and even GPU decoding of video codecs is enormously expensive powerbudget-wise.

Not to mention the fact that a mobile radio would have to be kept on high power constantly to pull in that 1Gbit/s stream.

You can be snarky all you want, it was a terrible move by Google.

;)

Post reply on HN