I am French and I took the definition of "huh" from the article:
> Huh is a very specific repair strategy that does not target some part of the statement but rather the statement as a whole.
... and I misread it :). I missed the word repair.
You are absolutely correct with the definition of "euh" - I usually use it when I have doubts or do not agree in a soft way (it then sounds more like heeuuuu...pfff).
Parisian native here, studied linguistics and specifically French/English in college, it's been many years. In my experience there is no equivalent to the use of "huh" in a single word in French so this article title made me a bit skeptical. Couldn't find any corroboration in the linked article. Only hinging that there "rough" equivalents to "huh" in all languages.
As you two suggested, "huh" is tricky to adapt to as a native French speaker learning English, especially American English, because "huh" is not equivalent to any single easily muttered statements in French as far as I know. I would convey the meaning of "huh" in French with:
- "ah ouais" (express that I didn't realize something)
- "bah dis donc" (express soft surprise or shock)
- "mouais" (express soft skepticism or disapproval)
Even those don't quite feel like the encompass the uses cases for "huh".
One thing that stuck out to me in the article is that they only mention one meaning of "huh". As you have pointed out, there are multiple meanings of "huh". You have "huh?" meaning "I don't understand, please repeat and clarify". There is "huh???" for "express soft skepticism or disapproval". And "huh!" for "express soft surprise or shock". Or "huh." for "express that I didn't realize something". Even "huh..." for "I need to think about this more".
Just a guess but I assume this was done by starting an upload with the API which gave the guy the ID but then not streaming the actual video file until it was recorded.
Looking at an example of the API in use ( https://developers.google.com/youtube/v3/docs/videos/insert#... ) that certainly seems plausible although I would imagine that there would be a timeout making it difficult.
edit: after looking at the other guy mentioning the time machine reference, my theory would be that he just spammed this API until he got a plausible URL and only then recorded and uploaded the video, probably would take a while but not forever considering how loose the URL actually is to delorean
Edit: I don't know the answer but I assume from all the APIs I worked with in the past, but if you get the URL before the upload is completed then yeah it's pretty easy to "fake".
Maybe with this API, but when uploading a YouTube video through YouTube, you definitely get the URL before the actual upload finishes. I don't imagine it'd be terribly hard to reverse-engineer that API.
My guess is that you can start an upload, get the ID, and then stream unimportant and non-comitall video headers and chunks (e.g. subtitle tracks or other metadata) slowly enough to keep the server from closing the connection on you. Then you can just record your video and start uploading actual video chunks once ready.
Or maybe YouTube doesn't have a huge timeout for starting your upload, so you don't even have to do all of that.
Not for me. When I'm uploading a video even when it's at 0% I see "The URL of your uploaded video will be: blah"
So it seems you can get the URL immediately... maybe then stop the upload mess with the video and then resume the upload... but I assume the resume feature takes a hash or something to make sure it's the same file..
Yes, I thought I saw this too many years ago when I was making youtube videos, and uploading would be slow or broken. Although I never tried changing the video after getting the URL.
Have you confirmed this? In the example the ID is retrieved from the finished upload response, but on the actual YouTube website does tell you the video link with the ID in advance, and the API parameter 'part' does appear to allow you to get the ID.
Start uploading a video, pause the upload, you could already get the ID of the vid, render rest of the video and then continue the upload that now contains the ID of the video :D
Here's a guess: upload from a browser running on Linux, and create a FUSE filesystem that blocks read() calls until you've generated the video.
I tried it with a named pipe ("mknod /tmp/foo.mp4 p") and it gave me an error, but before the error, the web page blocked during upload, but it showed me the URL that will be used (before I gave it a single byte of data).
My first guess is that new versions of videos can be uploaded if they're similar enough (not sure how it would judge that? visually???) and/or are updated shortly enough after upload.
Edit: Oh, I didn't even see the time travel reference in the ID. Maybe the ID is generated from metadata, and there's some endpoint where he was able to throw random metadata at it in an automated process until it came out looking somewhat like "delorean". Or he was able to get ahold of the algorithm locally for a quicker version of that process. In any case, I doubt he backwards-engineered anything.
It's more complicated than that, an LDA clusters documents into topics but it's non-trivial to determine what the topic is. You can use the head words of a tf.idf analysis but those still don't necessarily equate to topics. For what you're looking for I think you'd need ontology tagging so a bunch of tweets mentioning soccer players would give a topic word like 'soccer'. The problem then becomes the granularity to ascribe topic to, for example, should it be soccer or sports? Should it be more specific still. Then there's the non-obvious things like a plane goes down and the topic would likely be aviation, but that hardly gives any new information. Representing 20 topics on twitter is very difficult problem. Someone dies and the topic of "death" shows up, not very useful. I'm not disagreeing with you but rather saying that what you're suggesting is a very difficult problem to do in any useful and meaningful way.
Neither is working. Some speculation that it is an OTA issue. AT&T rep told me to try to redo update through iTunes. Requires downloading the .ipsw. I'm giving that a try now. Hopefully they will have a more sensible fix out soon.
> a bruteforce over the MAC space wouldn't take long
Indeed, best supercomputers are running today around 10 petaFLOPS (= 10^16 FLoating-point Operations Per Second) and there are 2^48 ~= 10^15 possible MAC addresses.
A FLOP is quite a lot simpler than a SHA-1 hash, however.
The Bitcoin network might be a better comparison since it uses doubled SHA-256; currently it's at around 3e16 hashes per second, or 6e16 SHA-256 operations per second. That's enough to hash all possible MACs in less than a second.
