As this works only for people who use browser to watch YouTube, it might be useless for me watching videos as videos should be watched (mpv/smplayer/iina (for mac) and youtube-dl just for URL extraction in my case).
But it’s also useless for anyone using mobile clients as well. You can say “why do you want to use mobile client app if you already don’t like ads?” and it’s fine. The thing is that official YT client on Android for example, is very “patchable” and there are some forks of it who already lock down the ads. Also there’s a NewPipe which does more or less the same thing I do on my desktop/laptop (mentioned above).
Going to the conclusion I would like to see that to be offered not in a form of “extensions” (i mean, single bullet you install & forget) but more like public API where you can register (or even better just use it anonymously with these hashed IPs mentioned on the website) and then read/add/vote on “sponsor” data. Adding a support for mpv (which has Lua scripting built in) or NewPipe or even patched YT (both made in Kotlin IIRC) would be just a few lines of HTTP requests.
The whole project is open source and you are free to download the sqlite database of sponsorship timestamps, so I bet you could make a sponsorblock plugin for mpv or similar video players. Since youtube-dl names files with the id from youtube, you could lookup the video in the database that way.
This seems like it would be pretty easy for google to defeat once they become aware of it. I typically use something like hooktube.com (or IIRC there being something better now?), which seems to circumvent the google ad stuff entirely.
I don’t think Google has any incentive to try to attack this extension. YouTube earns nothing from sponsored ad reads in videos. Content producers will probably be upset if this becomes popular, but they don’t have much sway when it comes to how YouTube operates.
Pretty sure I learn better and faster through projects. Theoretical learning just doesn’t have the same “stickiness”.
I’ve actually thought about this quite a bit because some theoretical learning is needed and it’s great to have.
Here’s what seems to work for me (learning a new framework, language etc.).
1) Learn just enough to get started. (Or copy something without fully
understanding the nuances to hack on).
2) Start (This is part many theoreticians never get to.
Even less get to Finish).
3) Find the pain points. Look up the answer. Rinse and repeat for a bit.
4) In many cases (if thing is important or needed):
Finally give up and methodically read the docs or take the class.
Now the information is pertinent rather than just words and
disembodied concepts and it seems to take hold.
Doing it in the reverse order just doesn’t seem to work nearly as well.
That’s basically the same process I go through. Steps 1-2 quickly provide a mental model for understanding the subject. Once you have that model, it’s easier to do a proper reading of the documentation and incorporate that information by relating it to a project you’ve already started.
Slightly off-topic, but I bet someone could make a business out of auditing npm packages for malicious or obviously harmful code. Your company can send me the package.lock.json for your app, and I’ll go through and check every single package at a rate of X dollars per thousand lines of code, using a combination of automated tooling and manual review. Every time you do an update, I’ll review the packages and how they’ve changed. Any malicious stuff that I find gets posted publicly in the node security alerts.
Sure, someone could write some really clever code that avoids detection, but you can rest easy knowing that at least one person has looked at that pile of code in your node_modules folder before it was shipped to production.
I’m not sure I agree with the author. Or, rather, I agree with part of his article, and I think he falls short when talking about farming simulators and the like.
A very large portion of a farming sim is the tending: watering the crops, watching them grow, feeding the livestock, gathering what they produce, etc. That’s not a downside of the genre, it’s a core feature.
Many times over the last three decades, I’ve repeatedly heard comments that amount to “I love SimCity/Civ/etc, but it would be better if there were no disasters/other civs/barbarians/etc”. That speaks to a real desire to do the slow work of tending and building something. And that should be recognized as something very different than the willingness to grind in order to reach an unrelated goal.
In other words, I’m pretty sure the author doesn’t understand those games he’s criticizing. For many if not most players of those games, it’s not about the rewards, it’s about the “mindless work being glorified at every turn”.
“Having something to do” does not mean that it’s also something worthwhile or interesting — especially not in games. And wanting to simply “pass the time” may not be too reasonable of an approach, given it is a highly limited resource. Maybe questioning the circumstances that make you want to “switch off your brain” in the first place would be a worthwhile endeavor.
And I tend to agree. Farming simulators are less about enjoying a finite story and more about escaping from your real life for an unbounded amount of time.
He comes into the article saying “grind is bad”, follows it up by “even for games where the grind is the point”, and ends with “wanting this isn’t reasonable, and you should do some introspection to fix it”.
I think he does get it, but wants us to reflect on how we pass the time when we play these games.
And personally I agree with the author.
There are better ways to spend my time than grinding in a game and I hate it. I’ll gladly drop the difficulty if it means I can get through the game’s story mode in 4 hours less.
And the farming simulators? I play those in real life with real plants. No need for a game to do that.
I mean, “He gets it, and he’s right: people should like different things” is a pretty roundabout way of saying “he doesn’t get it”.
It’s okay if you and the author don’t like these things. That doesn’t mean that people who do like these things are wrong. That doesn’t mean that your definition of “better ways to spend time” are universal.
I think “built for Docker” really just means “we made a Dockerfile, send logs to stdout in a reasonable manner, and tried to keep the distribution size small”. It also implies that the application doesn’t require direct interaction with certain kernel features or modification of network interfaces, but web servers shouldn’t be doing that anyway.
Nginx could claim that they’re “made for Docker” to an equal degree.
If applications specifically need to target Linux for ease of use with it, doesn’t it mean Linux failed up to live to its promise of POSIX compatibility? ;)
This “Majestic 12” bot actually looks like an interesting project. According to https://www.majestic12.co.uk/ it was started around 2005 as a distributed search engine. From what I can tell it’s more of a “distributed crawler” that feeds info to a centralized search/analytics tool at https://majestic.com. However, it’s cool that there’s still a little community of people running nodes for the project, even if it’s awful software.
Is it really more tacky than in a GUI app?
I’m not fond of it, and I wouldn’t do it in my own programs, but you need to keep the project afloat. It has 77 contributors, which is much better than average, but according to github, it’s used by 398000 other project. That means user/contributor ratio is 0.02%.
Most people using it may never know about the donation option unless you show it conspiciously. Even then of 398000, maybe 3980 will donate something a buck or two.
To get a corporate user to donate something or sponsor your project, you need to be very lucky. I’ve been in situations when switching from certain proprietary alternative to my project fixed companies a number of problems and saved them thousands dollars, but when I offered them support at a small fraction of their former licensing costs, they refused because a single developer could not provide an already unrealistic wished for SLA. We have switched to a “pay for binaries” model since then, but for a project like webpack it wouldn’t work.
A donation link in the man pages would be perfect. However, tools have been putting it in their postinstall scripts. This means that whenever you install a project that uses webpack-cli or core-js or another open collective project you get an ad in your install log, no matter how deep in the dependency tree it is. Sometimes it even runs on CI servers, adding ASCII art and donation links to your build logs.
I get that donations would help out the project, and putting ads in the places where the most people see them is probably effective, but it’s annoying and the trend worries me.
imho the only tacky thing is having the advertisement show up based on a day of the week. It doesn’t really matter what the message is so long as it is consistent.
As this works only for people who use browser to watch YouTube, it might be useless for me watching videos as videos should be watched (
mpv/smplayer/iina (for mac)andyoutube-dljust for URL extraction in my case).But it’s also useless for anyone using mobile clients as well. You can say “why do you want to use mobile client app if you already don’t like ads?” and it’s fine. The thing is that official YT client on Android for example, is very “patchable” and there are some forks of it who already lock down the ads. Also there’s a NewPipe which does more or less the same thing I do on my desktop/laptop (mentioned above).
Going to the conclusion I would like to see that to be offered not in a form of “extensions” (i mean, single bullet you install & forget) but more like public API where you can register (or even better just use it anonymously with these hashed IPs mentioned on the website) and then read/add/vote on “sponsor” data. Adding a support for
mpv(which has Lua scripting built in) or NewPipe or even patched YT (both made in Kotlin IIRC) would be just a few lines of HTTP requests.The whole project is open source and you are free to download the sqlite database of sponsorship timestamps, so I bet you could make a sponsorblock plugin for mpv or similar video players. Since youtube-dl names files with the id from youtube, you could lookup the video in the database that way.
This seems like it would be pretty easy for google to defeat once they become aware of it. I typically use something like hooktube.com (or IIRC there being something better now?), which seems to circumvent the google ad stuff entirely.
I don’t think Google has any incentive to try to attack this extension. YouTube earns nothing from sponsored ad reads in videos. Content producers will probably be upset if this becomes popular, but they don’t have much sway when it comes to how YouTube operates.
Ah I didn’t realize youtube/google earns nothing from sponsored ads in videos.. thanks for clarifying.
Speaking only for myself:
Pretty sure I learn better and faster through projects. Theoretical learning just doesn’t have the same “stickiness”.
I’ve actually thought about this quite a bit because some theoretical learning is needed and it’s great to have.
Here’s what seems to work for me (learning a new framework, language etc.).
Doing it in the reverse order just doesn’t seem to work nearly as well.
That’s basically the same process I go through. Steps 1-2 quickly provide a mental model for understanding the subject. Once you have that model, it’s easier to do a proper reading of the documentation and incorporate that information by relating it to a project you’ve already started.
Slightly off-topic, but I bet someone could make a business out of auditing npm packages for malicious or obviously harmful code. Your company can send me the package.lock.json for your app, and I’ll go through and check every single package at a rate of X dollars per thousand lines of code, using a combination of automated tooling and manual review. Every time you do an update, I’ll review the packages and how they’ve changed. Any malicious stuff that I find gets posted publicly in the node security alerts.
Sure, someone could write some really clever code that avoids detection, but you can rest easy knowing that at least one person has looked at that pile of code in your node_modules folder before it was shipped to production.
Already a business! I know a few companies offering what you suggest: npm itself, GitHub, Snyk…
I’m not sure I agree with the author. Or, rather, I agree with part of his article, and I think he falls short when talking about farming simulators and the like.
A very large portion of a farming sim is the tending: watering the crops, watching them grow, feeding the livestock, gathering what they produce, etc. That’s not a downside of the genre, it’s a core feature.
Many times over the last three decades, I’ve repeatedly heard comments that amount to “I love SimCity/Civ/etc, but it would be better if there were no disasters/other civs/barbarians/etc”. That speaks to a real desire to do the slow work of tending and building something. And that should be recognized as something very different than the willingness to grind in order to reach an unrelated goal.
In other words, I’m pretty sure the author doesn’t understand those games he’s criticizing. For many if not most players of those games, it’s not about the rewards, it’s about the “mindless work being glorified at every turn”.
I think he addresses that:
And I tend to agree. Farming simulators are less about enjoying a finite story and more about escaping from your real life for an unbounded amount of time.
He comes into the article saying “grind is bad”, follows it up by “even for games where the grind is the point”, and ends with “wanting this isn’t reasonable, and you should do some introspection to fix it”.
That still sounds like he doesn’t get it, to me.
I think he does get it, but wants us to reflect on how we pass the time when we play these games. And personally I agree with the author.
There are better ways to spend my time than grinding in a game and I hate it. I’ll gladly drop the difficulty if it means I can get through the game’s story mode in 4 hours less.
And the farming simulators? I play those in real life with real plants. No need for a game to do that.
I’m also playing that way, but have been finding the random events are frequently not much fun.
Just blame it on the “false sense of accomplishment” that many games provide.
I mean, “He gets it, and he’s right: people should like different things” is a pretty roundabout way of saying “he doesn’t get it”.
It’s okay if you and the author don’t like these things. That doesn’t mean that people who do like these things are wrong. That doesn’t mean that your definition of “better ways to spend time” are universal.
If applications need to specifically target docker for ease of use with it, doesn’t it mean docker failed to live up to its promise? ;)
I think “built for Docker” really just means “we made a Dockerfile, send logs to stdout in a reasonable manner, and tried to keep the distribution size small”. It also implies that the application doesn’t require direct interaction with certain kernel features or modification of network interfaces, but web servers shouldn’t be doing that anyway.
Nginx could claim that they’re “made for Docker” to an equal degree.
If applications specifically need to target Linux for ease of use with it, doesn’t it mean Linux failed up to live to its promise of POSIX compatibility? ;)
While that was tongue in cheek, I seriously do think Docker is not nearly as “easy and just works” solution as its proponents claim.
Since when programs need to specifically target Linux? I’m still to see a program that uses only fully standardized POSIX APIs and fails to work.
This “Majestic 12” bot actually looks like an interesting project. According to https://www.majestic12.co.uk/ it was started around 2005 as a distributed search engine. From what I can tell it’s more of a “distributed crawler” that feeds info to a centralized search/analytics tool at https://majestic.com. However, it’s cool that there’s still a little community of people running nodes for the project, even if it’s awful software.
Advertising within your CLI tool is just plain tacky.
Is it really more tacky than in a GUI app? I’m not fond of it, and I wouldn’t do it in my own programs, but you need to keep the project afloat. It has 77 contributors, which is much better than average, but according to github, it’s used by 398000 other project. That means user/contributor ratio is 0.02%.
Most people using it may never know about the donation option unless you show it conspiciously. Even then of 398000, maybe 3980 will donate something a buck or two.
To get a corporate user to donate something or sponsor your project, you need to be very lucky. I’ve been in situations when switching from certain proprietary alternative to my project fixed companies a number of problems and saved them thousands dollars, but when I offered them support at a small fraction of their former licensing costs, they refused because a single developer could not provide an already unrealistic wished for SLA. We have switched to a “pay for binaries” model since then, but for a project like webpack it wouldn’t work.
I don’t see a problem with putting a donation link in
--helpor the manual or something.A donation link in the man pages would be perfect. However, tools have been putting it in their postinstall scripts. This means that whenever you install a project that uses webpack-cli or core-js or another open collective project you get an ad in your install log, no matter how deep in the dependency tree it is. Sometimes it even runs on CI servers, adding ASCII art and donation links to your build logs.
I get that donations would help out the project, and putting ads in the places where the most people see them is probably effective, but it’s annoying and the trend worries me.
imho the only tacky thing is having the advertisement show up based on a day of the week. It doesn’t really matter what the message is so long as it is consistent.