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

Warp – self-contained, single binary applications

github.com

Post reply on HN
Print view View original

151–157 of 157 posts

Re: Warp – self-contained, single binary applications

#151

Post by rkeene2 »

jjnoakes wrote: post #135
wahern wrote: post #116

Earlier quoted context omitted.

The implication is that statically linked binaries make it easier to throw in dependencies because you neither need to worry about how to ship them nor bother with re-using the shared libraries on the system. If there's a bug in Go's TLS implementation, you need to identify, recompile, and redistribute every Go application you use. Whereas if it were using the system's OpenSSL library everything would magically be fi…

Is this always true? If the shared library you linked to uses symbol versions and the bug fix requires a new version of a symbol, the application has to be relinked anyway. Same as static linking, except now it is not obvious you need to relink to get the bug fix.

Only if the fix involves breaking the old semantics entirely. It's possible in some cases to support old semantics in a safe way at the cost of performance, or in the case that it's not you can disable that call in such a way that the program aborts if it is called, thus indicating that the user should relink that program. This is why integration projects such as Linux distributions are hard, and useful.

Re: Warp – self-contained, single binary applications

#152

Post by interfixus »

rkeene2 wrote: post #149
interfixus wrote: post #94

Earlier quoted context omitted.

Typing me some Nim and shaking my head. Passing -static to the linker, I get neat, robust, non-dynamic executables, typically in the low MB or even kB size-range. const varname = staticRead"filename" embeds a given resource at compile time - to make the project completely selfcontained if need be, and just for the hell of it. I know you can do this in several other languages, but the Nim way is - unsurprisingly - the…

Tcl beats it in terms of both transparency and ready-made-ness. In Tcl, all filesystem access goes through the Tcl Virtual Filesystem (VFS) layer. This is a layer of indirection that allows for the interpreter, including at the script-level, to intercept filesystem calls and replace them with their own data. The default (and catch-all) driver is called "native" that just passes things to the native OS, but you can wr…

Tcl is still a breath of fresh air, here 30 years after it first appeared. Such a pity all the minshare it has lost.

Re: Warp – self-contained, single binary applications

#153

Post by rkeene2 »

sandGorgon wrote: post #120

The best of breed here is zeroinstall - https://0install.net/ . The software catalog is here - http://0install.de/catalog/ comes with its own SAT solver for dependency resolution. zeroinstall is what Canonical was considering before it created Snap Packages.

AppFS ( http://appfs.rkeene.org/ ) is an extension of the idea proposed originally by 0install (in their original LazyFS approach).

Re: Warp – self-contained, single binary applications

#154

Post by rkeene2 »

interfixus wrote: post #152
rkeene2 wrote: post #149

Earlier quoted context omitted.

Tcl beats it in terms of both transparency and ready-made-ness. In Tcl, all filesystem access goes through the Tcl Virtual Filesystem (VFS) layer. This is a layer of indirection that allows for the interpreter, including at the script-level, to intercept filesystem calls and replace them with their own data. The default (and catch-all) driver is called "native" that just passes things to the native OS, but you can wr…

Tcl is still a breath of fresh air, here 30 years after it first appeared. Such a pity all the minshare it has lost.

And it can now be compiled to machine code (TclQuadCode), an amazing feat which should have further information presented at this year's Tcl conference (already underway).

Re: Warp – self-contained, single binary applications

#155

Post by interfixus »

rkeene2 wrote: post #154
interfixus wrote: post #152

Earlier quoted context omitted.

Tcl is still a breath of fresh air, here 30 years after it first appeared. Such a pity all the minshare it has lost.

And it can now be compiled to machine code (TclQuadCode), an amazing feat which should have further information presented at this year's Tcl conference (already underway).

Seriously? (well, yes, I did a search). Clearly, I haven't been paying the attention I should, so thank you, this is super exciting.

Re: Warp – self-contained, single binary applications

#156

Post by AnIdiotOnTheNet »

rkeene2 wrote: post #150
AnIdiotOnTheNet wrote: post #139

Earlier quoted context omitted.

Package managers come with their own limitations. You can't have multiple versions of the same application, packages are often out of date, packages sometimes conflict, you can't choose where applications are installed, etc. And storage is ridiculously cheap. You can get an 8TB HDD for $150[0]. Or a 1TB SSD for the same price[1]. [0] https://www.amazon.com/Seagate-Expansion-Desktop-External-ST... [1] https://www.amaz…

> You can't have multiple versions of the same application In many package managers you can have multiple versions of the same application without a big deal -- in most cases you don't want to SUPPORT multiple versions of the same application, so there's always a trade-off.

> In many package managers you can have multiple versions of the same application without a big deal

In my experience, only if the distro has specifically set things up to allow that (Python2/3), or you find a PPA maintained by someone. Otherwise, time to compile from source I guess.

Re: Warp – self-contained, single binary applications

#157

Post by TimTheTinker »

TimJYoung wrote: post #85
TimTheTinker wrote: post #74

Earlier quoted context omitted.

I think this represents a fundamental (and rather annoying) difference between Linux and Windows. On Windows, the only platform-supported global library format is COM, and that requires a very specific programming style--HRESULTs and all the rest. True, registered COM DLLs can be linked to without separate header/symbol files, and installing new programs/libraries never requires local compilation, but the extra overh…

Windows has C-style, shared libraries just like Linux - DLLs. The entire Win32 API that is the backbone of Windows is implemented in system DLLs. Every compiler that produces native binaries for Windows links with these DLLs (C, C++, Go, FreePascal/Delphi, etc.), either statically or dynamically, using C calling conventions. COM is the Component Object Model, which is implemented in DLLs, but is something different:…

Thanks for the corrections.
Post reply on HN