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

21–30 of 110 posts

Re: Why did base64 win against uuencode?

#21

Post by LeoPanthera »

DaiPlusPlus wrote: post #6

On a related note, I'm getting flashbacks to being on the web in the late-1990s, back when "Downloads!" was a reason to visit a particular website; and noticing that Windows users like myself could just download-and-run an .exe file, while the same downloads for Mactintosh users would be a BinHex file that'd also be much larger than the Windows equivalent - and this wasn't over FTP or Telnet, but an in-browser HTTP d…

The most common Macintosh archive format was (eventually) StuffIt, but StuffIt Expander couldn't open a .sit file which was missing its resource fork, and when you downloaded a file from the internet, it only came with a data fork.

So a common hack was to binhex the .sit file. Binhex was originally designed to make files 7-bit clean, but had the side effect that it bundled the resource fork and the data fork together.

Later versions of StuffIt could open .sit files which lacked the resource fork just fine, but by then .zip was starting to become more common.

Re: Why did base64 win against uuencode?

#22

Post by LukeShu »

ggm wrote: post #15

Having lived through the transition, I can say personally it comes down to "packaging" -if MIME had adopted UUENCODE format, I probably would have used it but as materials emerged to me which depended on base64 decode, it became compelling to use it. Once it was ubiquitously available in e.g ssl, it became trivial to decode a base64 encoded thing, no matter what. Not all systems had a functioning uudecode all the tim…

> We were also obsessed with efficiency. base64 was "sold" as denser encoding. I can't say if it was true overall

uuencode has file headers/footers, like MIME. But the actual content encoding is basically base64 with a different alphabet; both add precisely 1/3 overhead (plus up to 2 padding bytes at the end).

Re: Why did base64 win against uuencode?

#23

Post by cratermoon »

LukeShu wrote: post #22
ggm wrote: post #15

Having lived through the transition, I can say personally it comes down to "packaging" -if MIME had adopted UUENCODE format, I probably would have used it but as materials emerged to me which depended on base64 decode, it became compelling to use it. Once it was ubiquitously available in e.g ssl, it became trivial to decode a base64 encoded thing, no matter what. Not all systems had a functioning uudecode all the tim…

> We were also obsessed with efficiency. base64 was "sold" as denser encoding. I can't say if it was true overall uuencode has file headers/footers, like MIME. But the actual content encoding is basically base64 with a different alphabet; both add precisely 1/3 overhead (plus up to 2 padding bytes at the end).

uuencode has some additional overhead, namely 2 additional bytes per line, that means it varies from 60-70%, the latter being best case, while base64 is 75% efficient in all cases.

Re: Why did base64 win against uuencode?

#24

Post by ekidd »

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 used as part of MIME.

Re: Why did base64 win against uuencode?

#25

Post by DaiPlusPlus »

demondemidi wrote: post #19
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.

The one annoying thing macOS apps do is pollute /Library. Even apps that don’t explicitly write to this area end up with dozens of permafiles. Tons of stuff is spewed in there when you install an application that actually uses it. It’s like a directory version of a registry kitchen sink.

Spare a thought for us Windows users - we went from our pristine and oddly beautiful home directories in Windows 7, where everything was neatly squared-away to either AppData\Roaming or AppData\Local - to our post-Electron, lazily-ported software world where my home directory now has no-less than twenty Unix-style dot-directories littering my %USERPROFILE%

Incidentally, the worst offender is Microsoft themselves: it all got worse with .nuget, .vs, .azcopy, .azdata, .azure, .azuredatastudio, .dotnet, etc. I just don't understand it.

Re: Why did base64 win against uuencode?

#26

Post by Clamchop »

tornato7 wrote: post #16
DaiPlusPlus wrote: post #6

On a related note, I'm getting flashbacks to being on the web in the late-1990s, back when "Downloads!" was a reason to visit a particular website; and noticing that Windows users like myself could just download-and-run an .exe file, while the same downloads for Mactintosh users would be a BinHex file that'd also be much larger than the Windows equivalent - and this wasn't over FTP or Telnet, but an in-browser HTTP d…

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 inscrutable installers for macOS software. DRM-riddled bullshit and enterprise crapware are a disease.

But yeah, the simple case is quite nice.

Re: Why did base64 win against uuencode?

#27

Post by wkat4242 »

mjevans wrote: post #18
ggm wrote: post #15

Having lived through the transition, I can say personally it comes down to "packaging" -if MIME had adopted UUENCODE format, I probably would have used it but as materials emerged to me which depended on base64 decode, it became compelling to use it. Once it was ubiquitously available in e.g ssl, it became trivial to decode a base64 encoded thing, no matter what. Not all systems had a functioning uudecode all the tim…

After a given point usenet was nearly 8-bit clean, and thus https://en.wikipedia.org/wiki/YEnc was also developed to convolve all the octets (I + 42 (decimal)) and escape the results that happened to still match reserved characters (CR, LF, 0x0, = (yEnc escape)) - it seems that if the result character was among that set, then = was output and new output determined by O = (I+64) % 256 instead.

Yenc is still used a lot actually, for the purpose of what Usenet has de facto become, a piracy network :)

Re: Why did base64 win against uuencode?

#29

Post by jjeaff »

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.

Re: Why did base64 win against uuencode?

#30

Post by demondemidi »

DaiPlusPlus wrote: post #25
demondemidi wrote: post #19

Earlier quoted context omitted.

The one annoying thing macOS apps do is pollute /Library. Even apps that don’t explicitly write to this area end up with dozens of permafiles. Tons of stuff is spewed in there when you install an application that actually uses it. It’s like a directory version of a registry kitchen sink.

Spare a thought for us Windows users - we went from our pristine and oddly beautiful home directories in Windows 7, where everything was neatly squared-away to either AppData\Roaming or AppData\Local - to our post-Electron, lazily-ported software world where my home directory now has no-less than twenty Unix-style dot-directories littering my %USERPROFILE% Incidentally, the worst offender is Microsoft themselves: it…

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