This isn't very different from the West selling guns, tanks and police equipment to allied 3rd world countries. You hope they'll be used for good causes(preventing crime and terrorism) but knowing that these governments tend to be corrupt, you acknowledge the risk that these weapons will be used by bad elements too.
> It's too easy for a bad actor to artificially create "leftover" doses to give to friends and family
How? If X people made appointments in a day, then exactly X vaccines should be distributed for that day. Leftover vaccines will only be distributed after all those appointments are over, so it is impossible for any of the X people(assuming they arrived on time) to lose their vaccine.
In Israel, before vaccines were made available to the entire public, people created Facebook groups reporting clinics which had spare vaccines, nurses would even go outside and offer random passerbys an option to get vaccinated.
You're talking about the runtime aspects of executing concurrent code (OS threads vs green threads) but these are orthogonal to the idea of async APIs, which are one way of modelling concurrent programming flows.
For example, futures in Rust can be used with both OS threads and lightweight tasks. Tokio is mostly agnostic about the choice of the executor.
It definitely takes some time to grok async Rust (even if you come from C#/JS), but I think it really shines once you get to know it, similar to the benefits you get from learning
about iterators & higher level functions as opposed to plain loops.
For instance, I've recently implemented the Raft protocol as part of a distributed algorithms course. Using Tokio and a single threaded executor made the implementation fairly readable, mostly relying on few async constructs(futures, tasks, channels and select loops) to model fairly complex behavior (bidirectional messaging, multiple states, timeouts, etc..)
Doing so in a more traditional callback oriented style would've required maintaining a very complex state machine(in addition to the state machine of the algorithm itself)
Also, Async/Await originated in C#, a language which already supports threads(and many other concurrency models), not JavaScript which historically relied on callbacks
That's not piracy. Youtube is sending you packets, out of their own choice. It's my own right to save those packets(without re-distributing) them and watch them in any form I like.
Playing in the background is not a "feature", it's a basic device capability, the fact that YouTube went out of their way to prevent it does not make it right, imagine if the browser client had stopped playing when you went out of focus - that'd be completely unacceptable. The fact that somehow this is accepted on smartphones probably says more about consumers lack of technological competence and awareness (and maybe historical reasons, as earlier versions of Android/iOS didn't have proper multi-tasking)
In most cases (my experience comes from working in broadcast industry but not specifically YouTube), those restrictions are there due to creators wanting to be paid for background playback (this is in 99% cases for music, where not adding this restriction would essentially make creators and the might copyright holders unpaid).
So bypassing the wishes of copyright holder / creator and getting the content for free is pretty much textbook definition of piracy.
Now, we can debate whether piracy is ethical in some cases (and I think it is in many cases, especially due to how cancerous the copyright lobby is these days). But let's not pretend that having a service provider say "hey, pay us 10$ a month for this feature" and then making an app that gives that paid feature for free is some kind of right.
With Android, I believe you could always run anything you wanted in the background, provided you had enough memory. Starting with versions 5-6, restrictions have been put in to prevent abuses and battery draining with the user unaware of it. The two OSs converged towards a mean point from opposite directions in this case.
They're inconsistent. On Firefox Android you can't play in the background using the mobile site but if you switch to the desktop site all of a sudden background play starts working.
That's because Google deliberately prevents background playback on mobile devices, bringing mobile browsers down to the same level of the YouTube app using shady JavaScript APIs. This add-on should fix it: https://addons.mozilla.org/en-US/firefox/addon/video-backgro...
That's not what piracy means, and that's not how the law works. If I state that the terms of service of reading this comment are that you must hop on one leg for the rest of your life, and you continue to walk on two, you won't be violating any laws.
I didn't say you're violating laws (but you may well be violating DMCA sections), I said you're violating terms of service. The expectation could be that they halt your use of the service, block access to their other service, and may disable your account.
OP claimed, "It's my own right to save those packets(without re-distributing) them and watch them in any form I like." That is not accurate. He doesn't magically GAIN COPYRIGHT over content, just because he downloaded it. His use MAY be covered by Fair Use Laws, but it may also still be a violation of YouTube's Terms of Service.
Google is willfully sending the data. If they want stricter access controls it's their job to implement them. TOS isn't a binding contract since one side never gets a chance to negotiate terms.
Yes, and if they start identifying Google accounts that share the IP of a device violating YouTube TOS and disabling those accounts, some people will be very sad.
They should at least consider the possibility. Go in with open eyes, so to say.
> Yes, and if they start identifying Google accounts that share the IP of a device violating YouTube TOS and disabling those accounts, some people will be very sad.
If this happens, even more people will take their eggs out of Google's basket. I've already migrated my email to another provider and use Searx[1] for search.
If you do use it, please don't violate the TOS, because it increases the chances you'll screw it up for everyone else (me). People who violate TOS are why we can't have nice things.
Nowhere did I imply that I'd gain copyright over the content.
What's the difference between downloading and streaming a video? It's OK for the bytes to stay in main memory/network cache, but not in HDD? Would taking a memory dump of the RAM break their TOS?
Assuming this is true(that there's a clause against viewing YouTube with a third party client), then they're free to ban users like me from their service(and suffer the PR backlash),
that doesn't mean that breaking that clause is unethical or illegal(I'm not from the US, we don't have draconian internet laws here)
Under the heading, "Permissions and Restrictions":
> The following restrictions apply to your use of the Service. You are not allowed to:
> 1. access, reproduce, download, distribute, transmit, broadcast, display, sell, license, alter, modify or otherwise use any part of the Service or any Content except: (a) as expressly authorized by the Service; or (b) with prior written permission from YouTube and, if applicable, the respective rights holders;
> 2. circumvent, disable, fraudulently engage with, or otherwise interfere with any part of the Service (or attempt to do any of these things), including security-related features or features that (a) prevent or restrict the copying or other use of Content or (b) limit the use of the Service or Content;
> 3. access the Service using any automated means (such as robots, botnets or scrapers) except (a) in the case of public search engines, in accordance with YouTube’s robots.txt file; or (b) with YouTube’s prior written permission;
The users using 3rd party apps don't violate any of these terms (I'm sure you could argue it both ways depending on the specific legal terms depending on the context; IANAL). The app itself is probably violating some of these terms, but for the end users, they are not doing any of the things described, they are just using the app.
I think this is just one of those cases where copyright/IP law moves too slowly compared to the technology it tries to cover.
> They are "accessing ... part of the Service or Content [without being] expressly authorized."
Are they though? AFAIK, law is very pedantic, and technically speaking, a human is physically incapable of accessing Youtube; we use tools to do so. We use some kind of software to access youtube.com, in this case, we are using an app that accesses youtube.com and relays the content on that page back to us. Similar to say, using Chrome or Firefox to access youtube.com and relay the contents on the page back to us.
Note, the APP accesses youtube.com, not the user. The app is (potentially) in violation, the user using the app is not. In fact, the user may not even know that the app is actually accessing youtube. Again, IANAL and I'm sure this is argued both ways, but I'm just saying this is an interpretation of the terms.
I mean hey the NRA has argued this successfully about guns (or maybe their money argued it successfully) so why not? Lets start a rock lobby to allow more rock freedom
> KeepassXC does have a browser extension for Firefox & Chrome.
Yeah, but IIRC it doesn't on iOS? I dunno, it hasn't been a big pain point.
My solution has to use the Firefox password manager for low value things (like Hacker News), and manually c/p for the higher value (bank, retirement account, etc).
(Maybe I'm overly paranoid but I don't like to put high value passwords into the cloud)
And many developers loathe C++. Why should I have to use such a low level and antiquated language for developing a GUI?
Nowadays you don't even have to use JS/TS, there are many languages that target JS and have decent bindings to its ecosystem, such as Scala, Purescript, Clojure. This doesn't seem to be the case with Qt which lacks decent bindings to languages other than Python.
> It is all a matter of actually knowing how to write proper C++, or just using a C++ compiler to compile code that looks like C.
You might wanna read that back to yourself. Now replace it with any language you hate, and then tell me how that statement makes any form of argument at all (it doesn't...).
Some formats don't need to be read as plaintext by the average person.
Would the average person edit a .svg by hand? No, he'd use Adobe Illustrator or anything else.
Would he edit a .docx file by treating it as a zip archive and edit content.xml? No, he'd use MS Word/LibreOffice Writer...
Suppose Sqlite used XML/JSON instead of binary files, would you modify them with notepad? No, you'd probably use a SQLite browser software.(Or an application that is more tailored to the domain)
> Some formats don't need to be read as plaintext by the average person.
Fair point, and in fact, I'd go further - most of the time most people, do not need to directly edit or view most files in most formats. Even if you took 'most' to mean 99% or higher, I'd be comfortable with that statement.
Where I differ is that I think the essence of the argument is really whether or not a binary file format offers enough value to be worth entirely eliminating the direct edit/view possibility for everybody all the time. Even if it's not a common case, it can be game-changingly useful when you need it.
Just to illustrate, you give three examples, and I have counter examples for each:
> Would the average person edit a .svg by hand? No, he'd use Adobe Illustrator or anything else.
I've modified bounding boxes by directly editing SVG, as well as read SVG directly to analyze some plots a library was generating for me.
> Would he edit a .docx file by treating it as a zip archive and edit content.xml? No, he'd use MS Word/LibreOffice Writer...
I've done this recently to extract out embedded documents on OSX (where the native versions of Office do not directly support this.)
> Suppose Sqlite used XML/JSON instead of binary files, would you modify them with notepad?
HSQLDB can use text based SQL scripts to store data, and I've modified and edited them directly for several reasons.
