Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why did base64 win against uuencode?

retrocomputing.stackexchange.com

Post reply on HN
Print view View original

71–80 of 110 posts

Re: Why did base64 win against uuencode?

#71

Post by wruza »

vbezhenar wrote: post #49
tornato7 wrote: post #16

Earlier quoted context omitted.

Funny because today I find the install process for Mac much simpler. Most installs are "drag this .app file to your Applications folder", meanwhile on Windows you download an installer that downloads another installer that does who-knows-what to your system and leaves ambiguously-named files and registry modifications all over the place.

There are plenty of portable windows applications (distributed as a zipped directory) and there are plenty of pkg macOS installers. I don't really understand why macOS users like this "simple" installation, because when you "uninstall" the app, it leaves all the trash in your system without a chance to clean up. And implying that macOS application somehow will not do "who-knows-what" to your system is just wrong. Doc…

Windows uninstallers also leave all the trash in %AppData%. There’s no generic way to clean all the folders that a program decided to create. Only some uninstallers ask if you want to delete settings and caches.

Given that, dragging a ready-to-run file (folder) to /Apps symlink is much more convenient than “setting up your system for preparation of initializing of downloading of the installation process starter manager, please wait and press next sometimes”.

Re: Why did base64 win against uuencode?

#72

Post by wruza »

DaiPlusPlus wrote: post #36
demondemidi wrote: post #30

Earlier quoted context omitted.

Pristine? You mean the same home directory that contains the 80 character NTUSER files? ;)

Or the back-compat symlinks for NetHood, Start, Recent, SendTo, ah yes. I had a post-install VBScript that cleaned those out. My current sad-thing I’m unhappy about is how the “My Documents” folder ended up being a second AppData folder, with lots of software storing settings, templates, project files, etc in that dir instead of AppData. Windows absolutely needs application-silos to protect users from lazy apps. I ha…

My solution is to create another folder like “~/Documents/Projects” (because I have no free-standing documents really) and use it as “my” dir. All other paths are known to apps and will be abused.

Re: Why did base64 win against uuencode?

#73

Post by masklinn »

BiteCode_dev wrote: post #66
eastbound wrote: post #57

Earlier quoted context omitted.

So there are 7 base64 encodings, one with “+ / =“, one with “- _ =“, one with “+,” and no “=“… https://en.wikipedia.org/wiki/Base64#Variants_summary_table

TIL. And Python uses RFC 4648

Python might say that, but as often it’s not really true: it really mostly works off of 2045

- the “default” encoder (“b64encode”) will pad the output

- although it will not linebreak (“encodebytes”) does that)

- the default decoder will error if the input is not padded

- the default decoder will ignore all non-encoding characters by default

Also both b64encode and encodebytes actually use binascii.b2a_base64, which claims conformance to RFC 3548, which attempts to unify 1421 and 2045. Except RFC 3548 requires rejecting non-encoding data, whereas (again) Python accepts an ignores it by default, in 2045 fashion.

Re: Why did base64 win against uuencode?

#74

Post by [deleted] »

teo_zero wrote: post #64
Aardwolf wrote: post #38

A thing I wonder: why is using = padding required in the most common base64 variant? It's redundant since this info can be fully inferred from the length of the stream. Even for concatenations it is not necessary to require it, since you must still know the length of each sub stream (and = does not always appear so is not a separator). There's no way that using the = instead of per-byte length-checking gains any spee…

Without padding, how would you encode, for example, a message with just a single zero? To be more precise, how do you distinguish it from two zeroes and three zeroes?

[deleted]

Re: Why did base64 win against uuencode?

#75

Post by Aardwolf »

teo_zero wrote: post #64
Aardwolf wrote: post #38

A thing I wonder: why is using = padding required in the most common base64 variant? It's redundant since this info can be fully inferred from the length of the stream. Even for concatenations it is not necessary to require it, since you must still know the length of each sub stream (and = does not always appear so is not a separator). There's no way that using the = instead of per-byte length-checking gains any spee…

Without padding, how would you encode, for example, a message with just a single zero? To be more precise, how do you distinguish it from two zeroes and three zeroes?

Both for encoding and decoding the padding is not needed. Without ='s, you get a uniquely different base64 encoding for NULL, 2 NULLs and 3 NULLs.

This shows the binary, base64 without padding and base64 with padding:

NULL --> AA --> AA==

NULL NULL --> AAA --> AAA=

NULL NULL NULL --> AAAA --> AAAA

As you can see, all the padding does is make the base64 length a multiple of 4. You already get uniquely distinguishable symbols for the 3 cases (one, two or three NULL symbols) without the ='s, so they are unnecessary

Re: Why did base64 win against uuencode?

#76

Post by rendaw »

eastbound wrote: post #57
jjeaff wrote: post #29

Earlier quoted context omitted.

and yet, Internet protocols (http, at least) don't play well with equal signs which are part of base64, sometimes. That little issue has caused lots of intermittent bugs for me over the years, either from forgetting to urlencode it or not urldecoding it at the right time.

So there are 7 base64 encodings, one with “+ / =“, one with “- _ =“, one with “+,” and no “=“… https://en.wikipedia.org/wiki/Base64#Variants_summary_table

And decoders typically aren't interoperable, requiring you to use the specific decoder for that combination.

Re: Why did base64 win against uuencode?

#77

Post by jibal »

jibal wrote: post #59
t-3 wrote: post #2

Base64 is very bizarre in general. Why did they use such a weird pattern of symbols instead of a contiguous section, or at least segments ordered from low->high (on that note, ASCII is also quite strange, I'm guessing due to some backwards compatibility idiocy that seemed like it made sense at some point (or maybe changing case was super important to a lot of workloads or something, making a compelling reason to fuck…

Base64 and ASCII both made perfect sense in terms of their requirements, and the future, while not fully anticipated at the time, is doing just fine, with ASCII being now incorporated into largely future-proof UTF-8. Considerably stranger in regard to contiguity was EBCDIC, but it too made sense in terms of its technological requirements, which centered around Hollerith punch cards. https://en.wikipedia.org/wiki/EBCD…

P.S. He absolutely did attack the competence of past engineers. And "questioning" backwards compatibility with ASCII is even worse ... there was no point in time when a conversion would not have been an impossible barrier.

And the performance claims are absurd, e.g.,

"A simple and extremely common int->hex string conversion takes twice as many instructions as it would if ASCII was optimized for computability."

WHICH conversion, uppercase hex or lowercase hex? You can't have both. And it's ridiculous to think that the character set encoding should have been optimized for either one or that it would have made a measurable net difference if it had been. And instruction counts don't determine speed on modern hardware. And if this were such a big deal, the conversion could be microcoded. But it's not--there's no critical path with significant amounts of binary to ASCII hex conversion.

"There are also inconsistencies like front and back braces/(angle)brackets/parens not being convertible like the alphabet is."

That is not a usable conversion. Anyone who has actually written parsers knows that the encodings of these characters is not relevant ... nothing would have been saved in parsing "loops". Notably, programming language parsers consume tokens produced by the lexer, and the lexer processes each punctuation character separately. Anything that could be gained by grouping punctuation encodings can be done via the lexer's mapping from ASCII to token values. (I have actually done this to reduce the size of bit masks that determine whether any member of a set of tokens has been encountered. I've even, in my weaker moments, hacked the encodings so that , {}, [], and () are paired--but this is pointless premature optimization.)

Again, this fellow's profile is accurate.

Re: Why did base64 win against uuencode?

#78

Post by layer8 »

OskarS wrote: post #63
jjeaff wrote: post #29

Earlier quoted context omitted.

and yet, Internet protocols (http, at least) don't play well with equal signs which are part of base64, sometimes. That little issue has caused lots of intermittent bugs for me over the years, either from forgetting to urlencode it or not urldecoding it at the right time.

And slashes as well, which is a magic character in both urls and file systems. Means you can't reliably use normal base64 for filenames, for instance. That might seem like a niche use-case, but it's really not, because you can use it for content-based addressing. Git does this, names all the blobs in the .git folder after their hash, but you can't encode the hash with regular base64.

There’s the URL- and filename-safe variant of Base64 [0]. Decoders can support it simultaneously and transparently.

[0] https://www.rfc-editor.org/rfc/rfc4648.html#section-5

Re: Why did base64 win against uuencode?

#79

Post by layer8 »

rendaw wrote: post #76
eastbound wrote: post #57

Earlier quoted context omitted.

So there are 7 base64 encodings, one with “+ / =“, one with “- _ =“, one with “+,” and no “=“… https://en.wikipedia.org/wiki/Base64#Variants_summary_table

And decoders typically aren't interoperable, requiring you to use the specific decoder for that combination.

Which is silly, because there’s no good reason to, except for strict validation.

Re: Why did base64 win against uuencode?

#80

Post by afiori »

jjeaff wrote: post #29
ekidd wrote: post #24

One reason that uuencode lost out to Base64 was that uuencode used spaces in its encoding. It was fairly common for Internet protocols in those days to mess with whitespace, so it was often necessary to patch up corrupted uuencode files by hand. Base64, on the other hand, was carefully designed to survive everything from whitespace corruption to being passed through non-ASCII character sets. And then it became widely…

and yet, Internet protocols (http, at least) don't play well with equal signs which are part of base64, sometimes. That little issue has caused lots of intermittent bugs for me over the years, either from forgetting to urlencode it or not urldecoding it at the right time.

all three symbols are some of the worst possible choices for compatibility with urls and many other things

.-_ would have been a better choice tha +/=

Post reply on HN