81–90 of 157 posts
Earlier quoted context omitted.
Sorry, I'm not following. Granted pricing schemes have changed, but adjusting for that, are you claiming that disk is not dramatically cheaper than it was ~20 years ago? Not trying to be a dick, just not following your point.
Point is, "disk" in the cloud is not the same thing as the disk in your PC.
Earlier quoted context omitted.
I'm not sure if I understand correctly. Are you saying that you run venv commands as part of the build step for your containers (i.e. a RUN line in you Dockerfile) and then pip installing modules in another build step?
No, we use pipenv instead of pip, and pipenv manages a venv. There are `--system` flags, but I guess support for installing things to the system is a little buggy or idiosyncratic or something so we use the venv behavior. I'm not sure why we tell pipenv to install the venv in the project directory though. We do the pipenv install as a RUN line in our Dockerfile. Does this answer your question?
Earlier quoted context omitted.
Sorry if I'm a little dense; that doesn't seem like it solves any problems. It just says "use virtualenv and/or docker". I guess I was hoping for "how to manage dependencies in a localdev-friendly way for a Python/Docker app" or something.
Have you tried pipenv? It creates a lock file that hashes all your dependencies so it makes sure you get the right one when you deploy.. And it automatically creates the virtualenv if its nog there when you install them.
Earlier quoted context omitted.
No, we use pipenv instead of pip, and pipenv manages a venv. There are `--system` flags, but I guess support for installing things to the system is a little buggy or idiosyncratic or something so we use the venv behavior. I'm not sure why we tell pipenv to install the venv in the project directory though. We do the pipenv install as a RUN line in our Dockerfile. Does this answer your question?
Yeah, I think I have an understanding now. We use tagged Docker base images with the app dependencies baked in so you can just use a FROM your Dockerfile and know you have the dependencies in the image and you just add and run your app code.
Earlier quoted context omitted.
I'm ambivalent about this. It is cool to distribute a single binary, but years ago there was serious vulnerability in a very common open source library library whose name escapes me (it wasn't libgcc, someone help a brother here). It was used in multiple programs in both Windows and Linux. On Windows there was a rush of individual updates as each application was fixed... on Linux, simply upgrading that library fixed…
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…
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:
https://en.wikipedia.org/wiki/Component_Object_Model
COM, or some form of it, is used heavily with .NET and the new UWP runtime, but those are newer runtimes that sort of sit on top of the Win32 API (to some extent, UWP is actually integrated into the OS itself, but, AFAIK, still uses the underlying Win32 APIs).
Earlier quoted context omitted.
> This is not take anything away from this project, just making an observation. The programming field often feels like it's in a giant loop constantly re-discovering what went before. I think part of this comes from various tradeoffs becoming more or less important at different times. Processing power goes up so you move to fat clients, then people move to battery powered devices and heavy lifting makes more sense on…
It's not really processing power so much as storage and RAM that used to be seen as the disadvantages of static binaries. The advantages of the static binary model are that it avoids "DLL hell" and makes sourcing dependencies a bit better, which are indeed laudable aims. But nowadays it has terrible security (and to some extent reliability) trade-offs - if everything is a static binary and there's a security issue in…
Also, if you're talking about native, highly-distributed desktop/server applications, then the problem with using shared libraries is even worse. The only exception is system-level libraries that are updated automatically by the OS/distribution.
Finally, on Windows, with static binaries you can be sure that the binary is a particular version/build and is signed (this ensures that the binary version/build is valid). You don't get much better peace of mind than that. We've been distributing our installations and other binaries like that for over a decade, and it works great.
Earlier quoted context omitted.
Yeah, I think I have an understanding now. We use tagged Docker base images with the app dependencies baked in so you can just use a FROM your Dockerfile and know you have the dependencies in the image and you just add and run your app code.
Yeah, we do the same thing. This seems to work pretty well, except right now we build these images out of band of our normal build process (if you change these base images, you're expected to kick off another CI job that builds/pushes new versions and updates the versions in the FROM statements in our production Dockerfiles (and our docker-compose.ymls). I'm not sure why we're doing this, since the build cache is act…
We use Kubernetes to trigger rolling restarts with new images when we release a change to the base image, and so far it's been painless, but a lot of work went into it. We use Gitlab, but any CI/CD should allow you to do it.
Based on the readme, this is basically an SFX archive, which runs a binary upon completion of extraction to temporary folder, much like winzip & the like have created for ages.
Im using a SQLite btree file as backend, working basically as a key-value store. On the header i define what target triples are supported (the ones the dev built the binaries), and on the runtime open, see if the current host is supported and unpack the bynary payload always checking the hash before running it. (If its on the filesystem already see of the hash matches with the one saved before on the DB as a record)
Giving its a db the owner of the public-key signature(the creator of the file), can modify and add others binaries latter.
Im not disclosing it now, because its just part of a bigger platform, and you dont distribute only the apps, but a whole "container"(not in a Docker sense, but as a multiplatform container more focused on final users instead of cloud backends).
I hope i can launch it soon here on HN.