XPost: alt.comp.os.windows-11
On Thu, 5/15/2025 7:10 PM, Lawrence D'Oliveiro wrote:
So, here’s a roundup of download options from video sites, from the viewpoint of someone who’s scared of anything remotely technical <https://www.zdnet.com/home-and-office/home-entertainment/how-to-download-youtube-videos-for-free-2-ways-including-my-favorite/>.
Fun fact: ClipGrab is available as open-source for Linux-only, not for
Mac or Windows. (Wise developer, I think, who doesn’t want a flood of
bug reports from Mac/Windows noobs who can’t figure out the basics of building something from source.)
But I check the site, and its YouTube support only seems to go up to
1080 HD. This in spite of the fact that many videos are available in
4K or even 8K resolution.
Also, ClipGrab doesn’t seem to support over 100 different sites, like youtube-dl and its offspring do.
The author’s excuse for avoiding the command-line-based Linux tools:
Both youtube-dl and yt-dlp offer a very, very wide range of
features if you need them. Personally, I'm going to stick with
ClipGrab, because I don't have time to turn YouTube downloading
into a third full-time job.
Yes, they have a lot of options. But they default to downloading the
best quality available, without you having to specify any options at
all. The options are there just to fine-tune the details of what you
want.
The author of the article, should have used Wikipedia :-)
Or maybe they did.
https://en.wikipedia.org/wiki/Comparison_of_YouTube_downloaders
A YT-dlp invocation, can be as simple as
yt-dlp
https://www.somesite.com/somevideo.htm
Since proper handling of video is a technical topic,
you would have to be an abject hopeless Wally, to
think that amount of effort is the "peak effort"
for the whole project. There are going to be much
harder things to do, later (transcode for your streaming
server in the livingroom).
For the person writing that article, yt-dlp must be
kept updated, to continue working. Which might be
too much for them to handle. I know I don't keep my
copies up to date (as I don't regularly use them!).
And with the latest AI propaganda video in Youtube,
I don't think I care to take copies of the content, anyway.
*******
Now, you've made a comment, that Windows users would not
look at a source tree, if shown one. I have built copies
of Firefox and Thunderbird, both in Windows and Linux.
I don't do this very often. The ability to actually
build from the source provided, has varied over time.
The latest Mozilla recipes might require you to use
Mercurial, and the tarball offered is "purely proof
of purchase" and not really ready to go.
The ones for smaller projects on Windows are worse.
Some jackass will offer "source" and then just
one of the source files is missing. This allows
them to use a FOSS site for hosting, where in fact
if anyone tried, they could not build the package
no matter how much they grunted and groaned. Because
a file is missing, and it is on purpose. Usually the
missing file is technical (plumbing, not GUI), and
working around it, you might as well just re-write the
software.
Other projects, may be missing a Makefile, or a .proj
file for easy Visual Studio ingestion. Of course
the author of the material, has those files, and has
not included them on purpose.
Other projects, they claim to have source, when you go
to that part of the site, the folder is *empty*.
It's not often, you find a person who is on the level,
and offers materials that can actually be built. Some
people use a half dozen environments, and there
is no master script to do a build. Do they have
that master script in their own private tree ?
Of course they do. Who they hell works on complex
projects, and executes all the necessary commands
for each one by hand, over and over and over again.
Get a clue.
When I find FOSS materials today, I do a quick overview.
There are key indicators, as to how practical a project
is, and once I see those key indicators, I drop the
idea like a rock. I NO LONGER expect a FOSS tree to be
a FOSS tree. The number of disingenuous efforts, is
really staggering.
When I deliver one of my "special" 60 line programs,
I include the gcc or g++ invocation that compiled
and linked the project. I don't write big packages,
but if I did, I would offer you the same Makefile
I was using. No screwing around.
The "./configure" era, was the height of transferable
FOSS materials. Some of those scripts were
simply excellent, offering comments about how or if
optional libraries should be included or what the
impacts would be if they were missing. The ./configure
method is no longer popular. Some packages though,
continue to use it, because it's been a part of their
tree since the very beginning. Maybe FFMPEG, there
is a ./configure to help you. That would be followed
by a "make", a "sudo make install", or similar. You would
look forward to working on a tree that had
README.md
INSTALL.txt
configure
Today you get a folder full of uncommented garbage.
Why not include a file "suckit.txt" as a flag your
intentions are not honorable :-/
Paul
--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)