SoylentNews is people
SoylentNews
Over the years I have viewed many a video on YouTube. I quickly noticed an "ID" string that appeared in each video URL. Here's an example: https://www.youtube.com/watch?v=ShvnDSgjfXw -- see that string "ShvnDSgjfXw"? What characters are permitted? How long is it?
Along the way, I came upon an amazingly useful utility: youtube-dl. I accidentally discovered that it will happily download a YouTube video given just the Video ID. (Don't let the name of the utility mislead you; it seems to work fine with Instagram, Twitter, Sound Cloud... it's amazing!)
Now with my curiosity suitably piqued, I started a genuine search for what the parameters were that defined a valid YouTube Video ID. This question on "Web Applications Stack Exchange" was most helpful. Especially this response.
It appears that the Video ID (and the Channel ID) are modified base64 encodings of 64-bit (and 128-bit) integers. The primary change is that the base64 encoding produces two characters that are verboten in URLs. A generated "/" is replaced with "-" and a generated "+" is replaced with a "_".
There is no official documentation claiming that the ID lengths are guaranteed to always be 11 or 22 characters long, but empirical evidence suggests that is the current, de-facto standard.
There is even mention of " the maximally-constrained regular expression (RegEx) for the videoId" being:
[0-9A-Za-z_-]{10}[048AEIMQUYcgkosw]
Things get even more interesting if you are using Windows. Under NTFS, file names default to be case-preserving, but case-insensitive. Say I create a file called "Foo.txt" and then get a directory listing. Sure enough, I see: "Foo.txt" displayed. The fun comes if I do "DIR foo.txt" or "DIR FOO.TXT" or any other variation... they all find the same file: "Foo.txt"; this is counter to Unix where filenames are case-sensitive and each of those variations would be treated as separate and distinct files. Though it is possible to make an NTFS volume case-sensitive, it is not for the faint of heart!
One could, therefore, reverse-engineer the integer that produced the Video ID and use that in addition (or for the adventuresome: instead of) the Video ID.
The whole discussion was well-worth the read and highly recommended for anyone who would like more information on where it came from and how it came about.
(Score: 0) by Anonymous Coward on Saturday July 20 2019, @07:28AM (2 children)
UNIX/Linux/BSD had a very different linage than Windows.
Windows had to work with DOS/CMS style disks. Not 'oh it would be ok if', *had to* as in hard requirement. To be used by people spending money and wanted the software they already paid for to continue to work. Backwards compatibility was a huge deal to windows. They spend a lot of effort and money making it happen.
UNIX on the other hand takes the approach of re-write it and damned backwards compatibility. API compat was where it was at. That worked because you would buy your computer and the OS that came along with it would be custom for your computer. In many cases you would compile it then install it. Some software you would buy would be the same way.
DOS had none of that. It had to fit in 640k (usually less). It had to fit on a 360k disk. Upper lower case not happening. To do that compromises were made. The UNIX way only works with a much more rich environment where wasting hundreds of K is no big deal. If you look at the old systems they would bitpack things to save space. These days inventing something new you would have a json descriptor and not worry too much about the wasted space.
We live today with choices made in the mid 80s to fit things into a borderline embedded computer that did not cost 20,000 just to get in the door with. Remember a computer with a 2MB of RAM and 5MB drive was wildly expensive. Computers would come with 2 floppy drives just so you did not have buy more hard drive or memory. Because floppies were comparatively cheaper than both. Simpler is not always best. Cost maters a lot too. I am sure my 15 year old self would have loved to have a 'technically simple system' and would have lorded that over anyone who did not have it. But my 15 year old selfs parents would have looked at the sticker price and said 'yeah thats not happening ever'.
Case insensitivity is annoying sometimes. But then again so is case sensitivity. You can look at a file Myfile.txt and MyfIle.txt and miss the case very easy depending on font choice. Insensitivity makes it more usable. But it does come at a cost in both directions. UNIX works the way you think it would work. Windows uses the way people actually use a computer.
All systems with a bit of age on them have some warts. ls instead of catalog or dir. cp instead of copy spring to mind right away. mv instead of move. That was because of the UNIX lineage of being on a teletype. Where less characters meant you got more done. But came with a cognitive load of having to basically learning random 2 char string phrases to do anything. Remember these were timeshare style systems. Every second counts and the bill is running.
Understand your systems, where they come from, and you can work those limitations and even know how to bend them to your will.
I expect soon that windows will have native built in ext4 mounting options and at that point the whole thing is a non issue. You will pick which way you want it.
(Score: 2) by digitalaudiorock on Saturday July 20 2019, @03:07PM (1 child)
Wow...any citation as to these even being on any road map? Personally, I'll believe that one when I see it. NTFS is a complete piece of shit that should have been replaced by just about anything years ago, but like so much of Windows, I'd say the OS if married to that cluster fuck forever, just like drive letters.
(Score: 0) by Anonymous Coward on Saturday July 20 2019, @06:01PM
Why would they *not* put it in? They are shipping the linux kernel in the next version https://www.theverge.com/2019/5/6/18534687/microsoft-windows-10-linux-kernel-feature [theverge.com]
It is not that big of leap of logic that windows users can native mount ext4 and all of the other linux style file systems.
NTFS should have had many major fixes (and it has). But it is showing its age. It was designed in a time where HD space cost a bit more than it does now. The central MFT is one of the stumbling blocks. Where as the place anywhere inode style OS's seem to be working better. Both come at a cost. For the time NTFS came out it was the best there was for the price.
The NT driver system is not some special magic sauce that only MS has access to. https://www.paragon-drivers.com/en/lfswin/ [paragon-drivers.com] https://sourceforge.net/projects/ext2fsd/ [sourceforge.net] They have an option here buy/build.
They will probably want a way to do it such that they do not have to open source windows (yet). Which I suspect they will eventually do anyway. The problem they have is the amount of 3rd party software they bought and plugged into windows. For example their defragment library is a 3rd party program. They will have to either re-negotiate those bits or strip them out if they want that. For example the last line of this https://devblogs.microsoft.com/oldnewthing/20121218-00/?p=5803 [microsoft.com] https://devblogs.microsoft.com/oldnewthing/20181221-00/?p=100535 [microsoft.com] and that is just an ad on game! They are doing some bits where they can https://github.com/microsoft/calculator [github.com]