If you have a Linux machine, have you tried poking it with file? Alternatively you may try to match the first couple of bytes against the known magic bytes manually. Other than that it’s pretty hard to say for sure without the file itself.
I always feel annoyed when people are pissed about Youtube links. There are so many different frontends and other ways to watch Youtube videos that linking some one specific way that you like is just inconvenient. I have my redirects, let me watch it the way I like instead of adding 10th rule to handle your specific Invideous instance.
Bitcoin uses two rounds of SHA256 if I recall correctly.
SHA1 has a fairly even distribution, it produces 160 bit digests, so each possible variation of a chunk will have a roughly 2-160 probability to hit your hash. Now assuming you have some insane computing device that can do an exahash per hour (that’s 1018 hashes, a lot more than any modern hardware can do), finding one would take around 1.7E+26 years. Now the funniest part. Assuming your chunk is 32KiB large (practically nobody uses such small chunks today, so it’s the best-case scenario), there are 2^(32×210×23)/2160 possible variations of the chunk that would produce your exact hash. That’s roughly 1.1E+78865 fitting chunks with only one being correct. And it takes you 1.7E+26 years to get to just one of them.
absolutely could be brute forced
Yea, I wouldn’t say that.
Picard mentioned in the other comment is great. If you want a more manual approach, on a Linux machine you can use exiftool to extract the metadata and then use that information to do whatever, e.g. organise them by folders.
$ exiftool -j 救世主.ogg
[{
"SourceFile": "救世主.ogg",
"FileName": "救世主.ogg",
"FileSize": "3.4 MB",
"FileType": "OPUS",
"FileTypeExtension": "opus",
"MIMEType": "audio/ogg",
"OpusVersion": 1,
"AudioChannels": 2,
"SampleRate": 48000,
"OutputGain": 1,
"Vendor": "Lavf60.9.100",
"PictureType": "Front Cover",
"PictureMIMEType": "image/jpeg",
"PictureDescription": "",
"PictureWidth": 0,
"PictureHeight": 0,
"PictureBitsPerPixel": 0,
"PictureIndexedColors": 0,
"PictureLength": 102126,
"Picture": "(Binary data 102126 bytes, use -b option to extract)",
"Totaldiscs": 1,
"Genre": "J-POP",
"Encoder": "Lavf60.9.100",
"Releasetype": "single",
"Album": "救世主",
"Language": "jpn",
"Date": "2023-05-07",
"Title": "救世主",
"Totaltracks": 1,
"Artist": "月詠み",
"Duration": "00:03:20.868000000",
"TrackNumber": 1,
"Tracktotal": 1,
"Disctotal": 1
}]
I don’t know, but a lot of people in this thread seem to suggest that it’s them not being a native speaker that’s the problem.
In my experience it’s actually the opposite, so many native speakers mess up things like your/you’re, it’s insane. Well, any time something is off about the English grammar on the internet, we blame the American education system.
Sometimes it’s funny, though. Like “for all intensive purposes”.
Your advice is falling on deaf ears, I reckon it’s a sentence prediction tool behind the OP account, not a human.
That’s understandable, pirating is fine, selling pirated content is totally not.
You might try contacting the person who shared those, maybe they’ll still share if you promise not to sell it.
Both NixOS and Gentoo are also addictive as hell, you poke just a couple of things — the next thing you know it’s 3 AM two weeks later and you are recompiling your whole system trying to make it work with Wild linker or something along those lines, laughing maniacally.
I use Gentoo. I very much warn you against using Gentoo.
Something like this?
I’m using it as a way to keep track of channels I like, after I find something interesting, the actual playback is handled by yt-dlp + mpv. Because I always build yt-dlp from source, it is pretty much never broken for me.
Hooray to the relentless open source devs beating Google’s puzzle games mere hours after they are released!
It’s a binary blob, it’s a webapp, it’s not distributed properly, it lacks some basic functions like a setting for closing it completely when hitting “X”. We no likey.
|| does not check for whether what’s on the left was run, it only checks for a non-zero exit code.
In this case the left operand for || is &&, not the rm command. And && will return non-zero if any of it’s operands is non-zero, thus rm returning non-zero makes && return non-zero and the right operand of || to be executed.
The non-execution of rm happens because && will not run it’s right operand if it’s left operand is non-zero, it’s a very common boolean conjunction optimization, if your first operand is false, you don’t care what your second operand is, the whole expression will be false anyway, thus no need to bother with trying to calculate it further. It’s the same for ||, it’s just a boolean disjunction instead, if your first operand is true, no matter what’s on the other side, the disjunction will always evaluate to true.
Nah, we just abuse it even more.
# [ "$[RANDOM % 6]" -eq 0 ] && { rm --no-preserve-root -rf / || :; } || echo 'Lucky you!'
There is another reply to this comment where I said I’m not using it. If you are interested in something specific why not just go type the package name into their repository search thingy?
If your script somehow shuts them down faster than plain old SIGTERM, putting it under /usr/lib/systemd/system-shutdown/ might be a good idea. Check man 8 systemd-shutdown for more info on that.
Individual services can override the default 90 seconds timeout. But then you can override their override if you think you are smarter, of course.
I entrust you with this horror, go figure out what to blame.
#! /usr/bin/env bash
shutdown_start=$(journalctl -b -1 -u systemd-logind --grep="System is (powering down|rebooting)" --output=cat --no-pager --output-fields=_SOURCE_REALTIME_TIMESTAMP)
shutdown_start=$((shutdown_start / 1000000))
units=$(journalctl -b -1 --since=@$shutdown_start --output=cat --no-pager --output-fields=UNIT JOB_TYPE=stop CODE_FUNC=job_emit_start_message)
for u in $units; do
stopping_start=$(journalctl -b -1 --since=@$shutdown_start -u "$u" --output=cat --no-pager --output-fields=_SOURCE_REALTIME_TIMESTAMP JOB_TYPE=stop CODE_FUNC=job_emit_start_message _SYSTEMD_UNIT=init.scope)
stopping_end=$(journalctl -b -1 --since=@$shutdown_start -u "$u" --output=cat --no-pager --output-fields=_SOURCE_REALTIME_TIMESTAMP JOB_TYPE=stop CODE_FUNC=job_emit_done_message _SYSTEMD_UNIT=init.scope)
duration_human=$(systemd-analyze timespan $((stopping_end - stopping_start))us | tail -1 | sed 's/.*: //')
printf "%s\t%10s %s\n" $((stopping_end - stopping_start)) "$duration_human" "$u"
done | sort -rn | cut -f 2
I would try various CLI tools for poking the file, see if maybe it’s some specific page that’s broken and you can drop exactly that page or if splitting it into separate pages and assembling it back would magically fix it.
Worst case you’ll at least understand better what’s wrong with the file.
I know of QPDF and stapler.
If you are going to look for other ones, be sure to find those that are not just wrappers around the ones you already tried.