[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: [ANN] The LEM Project
- From: Sean Conner <sean@...>
- Date: Tue, 27 May 2014 23:47:41 -0400
It was thus said that the Great Jay Carlson once stated:
> On May 27, 2014 9:20 PM, "Sean Conner" <firstname.lastname@example.org> wrote:
> > One problem:
> > what if LuaRocks did :
> > f = io.open("config.lua","r+")
> > which opens f in read/write mode. Does that imply the file is updated in
> > the LEM file?
> I think you will drive .lem distributors (and yourself) crazy with bug
> reports against mysterious failures modes, ones which are hard to name or
> specify. The sha256sum of a distributed file, especially an executable
> one, should not change. If it does, I have to keep the downloaded .tar.xz
> file around if for no other reason than to re-extract to reset.
So I take that as a "no" then. Okay.
> Consider the xdg-basedir spec for paths, by the way.
That's fine for Linux. What about other systems though? XDG_DATA_HOME
defaults to "$HOME/.local/share" which doesn't sound like it would play well
> Speaking of "driving crazy with bug reports" there are a bunch of things
> which sift through archives besides developers. Antivirus software can
> freak out at not-quite-normal archives, especially when they appear to be
> internally damaged. I can freak out when an unzip into a fresh directory
> prompts me about overwrites. Please do not ship archives with multiple
> members with the same name. You can pretend there are platform-appropriate
> directory symlinks when your resolver code runs.
The intent is to run Lua code directly from this file. Yes, it's a ZIP
format, and it follows the standard. I can't help it if, by following the
standard, some fool anti-viral program chokes on it.
> : I still say "md5" as slang for a cryptographic hash when I mean, you
> know, an actual general-purpose cryptographic hash. Saying "md5" is a bad
> habit, and it makes me sound old. Anyway, if you disturb an md5 you will
> also disturb sha256 and any HMAC. You won't necessarily disturb jar signing
> but I'm trying not to turn this into "steal all the jar infrastructure by
> avoiding incompatibility unless really important." Well, maybe I am a
Hmm ... I only know jar files by concept. I don't actually work with them
all that much.