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

101–110 of 110 posts

Re: Why did base64 win against uuencode?

#101

Post by winterplace »

pezezin wrote: post #51
DaiPlusPlus wrote: post #25

Earlier quoted context omitted.

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…

We Linux users suffer it. Supposedly, nowadays applications should store their files under ~/.config, ~/.local and ~/.cache, but you still find a million applications that create their own folders without following any standards. But at least file browsers hide those folders by default...

Do you have a link to documentation for that?

Re: Why did base64 win against uuencode?

#102

Post by TheCleric »

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…

That's definitely true for more complex apps, but the fact that you can have the executable and all it's resources in one `.app` file is so much simpler and easier for the everyday user. (Yes I know it's a folder that the OS treats as an application, but to a user it looks like one file)

I go back and forth between Windows/Mac/Linux on the daily (right tool for the right job) and each has some strengths. App packaging is far and away one of Mac's current strengths.

I maintained Nativefier (a now defunct open source project that would package web sites as Electron apps) and the ease of packaging an app was Mac > Windows > Linux.

Re: Why did base64 win against uuencode?

#103

Post by pimlottc »

winterplace wrote: post #101
pezezin wrote: post #51

Earlier quoted context omitted.

We Linux users suffer it. Supposedly, nowadays applications should store their files under ~/.config, ~/.local and ~/.cache, but you still find a million applications that create their own folders without following any standards. But at least file browsers hide those folders by default...

Do you have a link to documentation for that?

It's in the XDG Base Directory Specification [0] maintained by freedesktop.org [1] (formerly X Desktop Group)

0: https://specifications.freedesktop.org/basedir-spec/basedir-...

1: https://en.wikipedia.org/wiki/Freedesktop.org

Re: Why did base64 win against uuencode?

#104

Post by eesmith »

t-3 wrote: post #93
eesmith wrote: post #90

Earlier quoted context omitted.

Here is a quote: "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 over the future in favor of optimisation now))?" You used "that seemed like it made sense" when you could have written "that made sense." The additional "seemed like" implies the past engineers were unable to see something they should have. Y…

Hindsight is 20/20. Something that seemed like a good decision at the time may have been a good decision for the time, but not necessarily a great decision half a century later. That has nothing to do with engineering competency, only fortune telling competency. I get that people here don't like profanity, but I don't see any slight in describing engineering decisions like optimizing for common workloads today over h…

Again, "seemed like it made sense" expresses doubt, in the way that "it seems safe" expressed doubt that it actually is safe.

If you really meant your comment now, there was no reason to add "seemed like it" in your earlier text.

> I don't see any slight

You can see things however you want. The trick is to make others understand the difference between what you say and that utterances of an ignorant blowhard, "full of sound and fury, signifying nothing."

You don't seem to understand the historical context, your issues don't make sense, your improvement seem pointless at best, and you have very firm and hyperbolic viewpoints. That does not come across as 20/20 hindsight.

Re: Why did base64 win against uuencode?

#105

Post by [deleted] »

jcranmer wrote: post #50
u801e wrote: post #40

Earlier quoted context omitted.

It's too bad yenc didn't take the place of base64 for email.

yEnc was rejected by the MIME standardization group for two main reasons, one good and one bad. The good reason was that it has some encoding pathologies, although these could have been fixed in the standardization process. The bad reason was "it's too hard to add a new Content-Transfer-Encoding because you have to change all the user agents", which given that by that time all the clients were changing to support yEn…

[deleted]

Re: Why did base64 win against uuencode?

#106

Post by LeoPanthera »

amatecha wrote: post #98
LeoPanthera wrote: post #60

Earlier quoted context omitted.

It's been a long time, but I don't think that's exactly true. The resource fork simply became optional, assisted by later versions of MacOS, which let applications open files which didn't have one.

Ahh hmm OK, I'll have to check into this some time. I feel like the filesize would stay the same (suggesting no loss of data), but it's totally possible I'm misremembering considering how long it has been, hahah :)

It's quite plausible that the "file size" simply didn't include the resource fork.

Re: Why did base64 win against uuencode?

#107

Post by cyanydeez »

layer8 wrote: post #78
OskarS wrote: post #63

Earlier quoted context omitted.

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

you can also manually replace the with urlsafe codes

Re: Why did base64 win against uuencode?

#108

Post by jibal »

jibal wrote: post #77
jibal wrote: post #59

Earlier quoted context omitted.

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…

P.S I'm not the one lying here. Not only are there lies, strawmen, and all sorts of projection, but my substantive points are ignored.

"some backwards compatibility idiocy that seemed like it made sense at some point"

Is obviously attack on their judgment.

"a compelling reason to fuck over the future in favor of optimisation now"

Talk about passive-aggressive! Of course the person who wrote this does not think that there was any such "compelling reason", which leaves us with the extremely hostile accusation.

And as I've noted, the arguments that these decisions were idiotic or effed over the future are simply incorrect.

Re: Why did base64 win against uuencode?

#109

Post by bradknowles »

ksherlock wrote: post #9
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…

Classic Macintosh files were basically 2 separate files with the same name (data fork and resource fork). Additionally, there was important meta data (Finder Info, most importantly the file type, creator type). Since other file systems couldn't handle forks or finder info, it had to be encapsulated in some other format like binhex, macbinary, applesingle, or stuffit. The other 3 were binary so they would have been sm…

What I saw most of the time was a file that was compressed with StuffIt, and then encoded with BinHex. They were usually about inverse in terms of efficiency, so what you saved with StuffIt you would then turn around and lose with BinHex. But the resulting file was roughly the same size as the original file set.

Re: Why did base64 win against uuencode?

#110

Post by EkriirkE »

amatecha wrote: post #55
LeoPanthera wrote: post #21

Earlier quoted context omitted.

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…

I could be remembering wrong, but didn't later versions of stuffit compress to a .sit file that had no resource fork, so it would stay fully-intact on any filesystem? I may be imagining that, but I remember hitting a certain version where "copying to Windows" would no longer ruin my .sit files... haha

I don't remember there ever being a resource fork, but I Think around v4 it started allowing you to drag-n-drop any file to decompress, ignoring the missing/required finder info from previous versions
Post reply on HN