TE
科技回声
首页24小时热榜最新最佳问答展示工作
GitHubTwitter
首页

科技回声

基于 Next.js 构建的科技新闻平台,提供全球科技新闻和讨论内容。

GitHubTwitter

首页

首页最新最佳问答展示工作

资源链接

HackerNews API原版 HackerNewsNext.js

© 2025 科技回声. 版权所有。

Run More Stuff in Docker

199 点作者 psxuaw超过 4 年前

49 条评论

systemvoltage超过 4 年前
Let&#x27;s not. I don&#x27;t want to install Chrome which is already 73 MB, now bloated up with a whole lotta bullshit that&#x27;s 500 MB+ image. Imagine downloading every application as a docker container. WTF.<p>Docker is for distribution of applications when deploying them to servers. As a developer, it&#x27;s amazing at that and have brought peace and joy in devops. Let&#x27;s leave it there, shall we?
评论 #25550435 未加载
评论 #25550178 未加载
评论 #25549569 未加载
评论 #25549626 未加载
评论 #25547845 未加载
评论 #25549768 未加载
the_duke超过 4 年前
For end user devices, I much prefer Nix&#x2F;NixOS [1] for this kind of thing.<p>With Flakes [2] (experimental feature), you get full reproducibility.<p>The documentation is spotty and there is a considerable learning curve, but I&#x27;ve switched to NixOS on my laptop and desktop early this year and am mostly very happy with it.<p>That doesn&#x27;t cover sandboxing though. I would actually agree that sandboxing &#x2F; restricting applications (Mac OS style) would be sorely needed on Linux desktop.<p>Flatpak and Snap are trying to do this. A much saner approach than trying to find or maintain up to date, trustworthy Docker files for applications.<p>[1] <a href="https:&#x2F;&#x2F;nixos.org&#x2F;" rel="nofollow">https:&#x2F;&#x2F;nixos.org&#x2F;</a><p>[2] <a href="https:&#x2F;&#x2F;nixos.wiki&#x2F;wiki&#x2F;Flakes" rel="nofollow">https:&#x2F;&#x2F;nixos.wiki&#x2F;wiki&#x2F;Flakes</a>
评论 #25547830 未加载
评论 #25548668 未加载
评论 #25548046 未加载
评论 #25548506 未加载
评论 #25547634 未加载
评论 #25547578 未加载
hendry超过 4 年前
Just some counter arguments to @jbergknoff&#x27;s well put together page!<p>Docker is the best medium for distributing - A static file is far easier to share &#x2F; distribute.<p>Cross-platform - You need an arguably complex and unstable Linux interface to run Docker images, cgroups et al<p>Sandboxed - security claims about Docker have always been controversial. Simple Unix&#x2F;BSD constructs like chroot&#x2F;jails are far simpler and they are reliable<p>Version pinning - a binary can embed a version and you can stick with it<p>Reproducible - Everyone gets confused about Docker image checksums. `sha1sum static-binary` is far far simpler.<p>Minimizes global state - wouldn&#x27;t be a problem is people built static binaries.
评论 #25550133 未加载
评论 #25547684 未加载
评论 #25548686 未加载
评论 #25549588 未加载
评论 #25549596 未加载
lrossi超过 4 年前
The advantage of running apps in docker is that you avoid the risk of breaking your system by adding 3rd party package repos or even worse, curl | sudo bash. Cleanup&#x2F;uninstall is very simple as well.<p>However, I don’t agree with using it for sandboxing for security. Especially if you are giving it access to the X11 socket, as the author does in the examples. It might not be obvious, but the app will have access to all your other open windows.
评论 #25547833 未加载
ridiculous_fish超过 4 年前
Docker is intimately tied to Linux. It it only &quot;cross platform&quot; in that it can use a VM (Mac, WSL2) or flaky compat layers (FreeBSD). If software embraces Docker, it effectively excludes other OSes, like Windows, BSDs, Haiku, Fuschia, etc.
评论 #25548716 未加载
评论 #25549056 未加载
评论 #25549758 未加载
physicsgraph超过 4 年前
A few years ago I set a goal to minimize the number of applications installed bare-metal on my laptop. Everything is containerized, just as the blog describes. There is some initial overhead, and some extra work associated with maintaining the infrastructure, but overall I can report improved reproducibility (due to an isolated and static environment per app).<p>I use a bash alias for each common application. For example, &quot;jup&quot; launches a jupyter notebook. I have a container with the Python package &quot;Black&quot; which runs using a git hook to clean up my code prior to commits.
评论 #25552461 未加载
评论 #25547575 未加载
评论 #25547486 未加载
评论 #25550448 未加载
TimTheTinker超过 4 年前
&gt; On a Mac, there is a major performance hit whenever you do disk IO in a bind mount (i.e. voluming a directory of the host system into the container). Working without bind mounts is extremely limiting.<p>In my opinion, this is a big enough issue as to throw the whole idea of “Docker as cross-platform platform&#x2F;target” into major question.<p>When running more than a few containers on macOS, the performance is so bad it becomes almost unusable.
评论 #25549286 未加载
评论 #25549615 未加载
siscia超过 4 年前
I am trying to go in the opposite direction offering a read-only, mountable file system that offer a well crafted set-up of tools and utilities.<p>The idea is that you mount the filesystem and you got all the tools you need, and more, well installed, and that are lazily pulled from the network.<p>You win on the space side, but you need a bit more of trust.<p>You can find more info here: <a href="http:&#x2F;&#x2F;packages.redbeardlab.com" rel="nofollow">http:&#x2F;&#x2F;packages.redbeardlab.com</a><p>On the GitHub repo where you can ask for more packages to be installed:<p><a href="https:&#x2F;&#x2F;github.com&#x2F;RedBeardLab&#x2F;packages.redbeardlab.com&#x2F;" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;RedBeardLab&#x2F;packages.redbeardlab.com&#x2F;</a><p>And in this pair or articles for specific languages<p>Golang: <a href="https:&#x2F;&#x2F;redbeardlab.com&#x2F;2020&#x2F;12&#x2F;21&#x2F;packages-redbeardlab-com-for-golang&#x2F;" rel="nofollow">https:&#x2F;&#x2F;redbeardlab.com&#x2F;2020&#x2F;12&#x2F;21&#x2F;packages-redbeardlab-com-...</a><p>And for JavaScript&#x2F;node: <a href="https:&#x2F;&#x2F;redbeardlab.com&#x2F;2020&#x2F;12&#x2F;23&#x2F;packages-redbeardlab-com-for-node-js-community&#x2F;" rel="nofollow">https:&#x2F;&#x2F;redbeardlab.com&#x2F;2020&#x2F;12&#x2F;23&#x2F;packages-redbeardlab-com-...</a>
harryruhr超过 4 年前
Docker for every application? If you create and maintain the Docker image or Dockerfile for every applucation yourself, you must have plenty of time. If you rely on public images from Docker Hub, you must have plenty of trust in the creators of those images.
评论 #25547617 未加载
评论 #25547619 未加载
评论 #25548403 未加载
评论 #25547643 未加载
pavlus超过 4 年前
TLDR: 1. You already have that on Linux. 2. Make your builds portable.<p>If you are running mainstream Linux(Debian-based&#x2F;Arch-based, probably other), most of the Docker profits can be achieved with already installed and configured systemd and your distro&#x27;s package manager.<p>Sandboxed? systemd.<p>Simple, uniform interface? Your distro has packages, and most likely services that can and should be sandboxed already run in systemd after installation, you can tune unit-file if you want, and systemd has security checker, that shows you what application in the sandbox can and can not do, without proxying things the Docker way.<p>Versions pinning? Pin version with your package manager. Want multiple versions? Check out DebianAlternatives system.<p>Reproducible? Fix your build&#x2F;install configs, not the environment. If it builds on your machine, but not on the other, or run flawlessly on one, but not the other, it means you have implicit dependency on the environment, or wrong dependency versions constraints, which you likely don&#x27;t know about. If you don&#x27;t know your dependencies, you are definitely shooting blind.<p>Minimizes global state. Repo-based distros minimize global state by providing software that has most dependencies compatible, so you can have your minimal state and update your software too. Meanwhile with docker you need all dependencies and hope that they will match between images, so you can save on layers reusage. And if someone decides to update base image, and others dont... well, too bad, you have to have both versions of the base image.
评论 #25552009 未加载
评论 #25551440 未加载
评论 #25551477 未加载
johnsoft超过 4 年前
I appreciate the sentiment, but I wouldn&#x27;t be able to put up with the slow container boot time for regular use. The author mentions this at the bottom. He claims 1sec delay. Last month I benchmarked it on new-ish hardware at 560ms, or 290ms if you disable namespaces (and so disable isolation).<p>I wanted to also benchmark bocker[1] (docker written in bash) for a baseline comparison, but it no longer runs and I threw in the towel after ~30 mins of tinkering.<p>Anyways, if you run something like `curl | jq | grep | less` you could be waiting a fair bit for all those containers to start. Package managers are pretty good these days. I think I can trust it to install `jq` properly.<p>[1]: <a href="https:&#x2F;&#x2F;github.com&#x2F;p8952&#x2F;bocker" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;p8952&#x2F;bocker</a>
评论 #25548465 未加载
ogre_codes超过 4 年前
&gt; Running a program in a container is a lot like running it normally, but the user doesn’t need to jump through hoops to configure the system, build and install.<p>Docker is itself a complex build tool which requires a bunch of install steps. If you are going to ship software to end users <i>there is almost always a better way to bundle and ship than send someone a Docker container</i>.<p>Docker is not a distribution tool, if you are expecting your end users to install Docker, you&#x27;ve already screwed up.<p>&gt; Downloading a pre-compiled binary is almost like this, except with worse odds. Maybe there’s a build for your architecture. If it was statically linked, you’re golden. Otherwise, use ldd to reverse engineer the fact that you need to install libjpeg.<p>On Mac and Windows this is almost never an issue. Even on Linux, it&#x27;s pretty straight forward to statically link your binary if you aren&#x27;t sure about the environment it&#x27;s going to be run on. Statically linked binaries are a bit bloated... but not as bloated as a damned Docker image which contains entire dependency trees.<p>In no case is &quot;Making it into a Docker Image&quot; a simpler&#x2F; better distribution mechanic.
评论 #25550424 未加载
评论 #25550160 未加载
评论 #25550598 未加载
karlding超过 4 年前
The blog post links to Jessie Frazelle&#x27;s GitHub repo [0].<p>Jessie also has a blog post about this [1] from back in 2015. If you prefer video format, Jessie also has a talk at DockerCon SF 2015 [2].<p>[0] <a href="https:&#x2F;&#x2F;github.com&#x2F;jessfraz&#x2F;dockerfiles" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;jessfraz&#x2F;dockerfiles</a><p>[1] <a href="https:&#x2F;&#x2F;blog.jessfraz.com&#x2F;post&#x2F;docker-containers-on-the-desktop&#x2F;" rel="nofollow">https:&#x2F;&#x2F;blog.jessfraz.com&#x2F;post&#x2F;docker-containers-on-the-desk...</a><p>[2] <a href="https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=cYsVvV1aVss" rel="nofollow">https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=cYsVvV1aVss</a>
Macha超过 4 年前
I&#x27;ve actually gone the opposite direction in my home lab to run less in docker - unless you&#x27;re building your own images it&#x27;s hard to know what&#x27;s in them, which images are built on out of date OS images or dependencies, what else is running etc.
harryruhr超过 4 年前
Docker has its use cases. But running everything possible in a docker container just for the sake of &quot;dockerizing&quot; seems a little bit excessive.<p>One must basically maintain a (more or less) complete userland environment for every application. The idea of shared libraries is taken to absurdity this way. It would be better to build all static.<p>Then there is the waste of resources. I&#x27;m sure with plenty GB RAM, TB of SSD space and GBit of bandwith available nowadays many people don&#x27;t notice. But for what?
评论 #25547956 未加载
zaptheimpaler超过 4 年前
I prefer to just make a big &quot;devbox&quot; docker with all the utilities I need installed, and the home directory as a docker volume.<p>The advantage is i don&#x27;t have to fiddle with containers for every little program, no startup delay for every program, and my base ubuntu install stays clean and stable (which runs a VM and other services so stability is important).<p>It does have a few warts, the main one being you can&#x27;t have the entire container root volume be a docker volume, so to install new programs persistently inside the devbox i have to rebuild the image (if they don&#x27;t live completely in the home volume). But logically its an okay tradeoff because the only way to make the whole environment reproducible is to specify things at build time.
评论 #25548995 未加载
freebuju超过 4 年前
Were it not for docker, I probably would have never learned about Linux. I&#x27;ll share why. I was excited to find docker. It was neat and could be setup to update your applications without manual interaction. So I had it run my media server apps on a seedbox I had rented. Fast forward years later got a form factor pc that came with the free version of Windows. Try as a might, I couldn&#x27;t get docker to work on it. Required the Pro version or something like that. I remember thinking, well that sure is stupid! That was the beautiful beginning of my affair with Linux as an OS for my desktop&#x2F;server needs.
alphachloride超过 4 年前
I find that the time taken to get everything working means I have less time to get work done. The busywork does give me a sense of achievement, but that is not the achievement that matters. It&#x27;s premature optimization to sandbox an application by default unless there is a pressing reason to do so.<p>For e.g. zoom and hugo don&#x27;t really change the filesystem or OS settings beyond the folders they output to. I don&#x27;t see a reason the have them sandboxed personally.
评论 #25549376 未加载
gigel82超过 4 年前
I wish there were real &#x2F; usable Windows containers out there. I&#x27;d love to spin up a quick sandbox to run a MSVC &#x2F; MSBuild, but the smallest &quot;image&quot; in Windows-land for that is 12Gb.<p>Still use Docker alongside WSL2 for purely-Linux stuff like some node.js scripts or python things that don&#x27;t need GPU.
评论 #25551189 未加载
评论 #25549238 未加载
wa1987超过 4 年前
&gt; On a Mac, there is a major performance hit whenever you do disk IO in a bind mount (i.e. voluming a directory of the host system into the container). Working without bind mounts is extremely limiting. [..] If you’re using Docker on a Mac and you’ve never tried it on Linux, you owe it to yourself to try it on Linux.<p>Or use named volumes. I&#x27;m running a dockerized WordPress dev environment on my MacBook with average TTFB&#x27;s of 40 ms.
评论 #25547785 未加载
评论 #25547851 未加载
mkl95超过 4 年前
My personal computer doubles as my workstation. I manage my Python virtual environments with virtualenvwrapper, and I install all the other stuff -mostly OpenGL and gamedev related tools- with apt or from source.<p>Many developers would consider this Ubuntu 20.04 install that I run on a 9 year old computer to be an accident waiting to happen. But I&#x27;m finding this Ubuntu release to be extremely stable even at 3000+ packages.
sdepablos超过 4 年前
I&#x27;m in the same situation: until I figure (if ever) how to use NixOS and control version my OS, I tend to use Docker for any application with lots of dependencies, specially Python related ones
评论 #25547533 未加载
评论 #25547479 未加载
评论 #25547467 未加载
timhigins超过 4 年前
Just want link to Whalebrew, which achieves a lot of what this article mentions but IMO is more user-friendly. <a href="https:&#x2F;&#x2F;github.com&#x2F;whalebrew&#x2F;whalebrew" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;whalebrew&#x2F;whalebrew</a>
chaitanya超过 4 年前
If you are on a Mac or Windows, this approach only works for utilities that can run on Linux. If you need to run a native Mac program for example, docker won&#x27;t be able to run that.<p>Perhaps Nix might help here, but I&#x27;ve never used it, so can&#x27;t say for sure.
sclevine超过 4 年前
Many comments here point out how difficult it is to manage a separate dependency stack for each container when you use Dockerfiles to build them. This problem is just as difficult, time-intensive, and security-critical for microservice apps running on K8s as it is for CLI tools and graphical apps.<p>Worth pointing out that there is an incubating CNCF project that tries to solve this problem by forgoing Dockerfiles entirely: Cloud Native Buildpacks (<a href="https:&#x2F;&#x2F;buildpacks.io" rel="nofollow">https:&#x2F;&#x2F;buildpacks.io</a>)<p>CNB defines safe seams between OCI image layers so that can be replaced out of order, directly on any Docker registry (only JSON requests), and en-mass. This means you can, e.g., instantly update all of your OS packages for your 1000+ containers without running any builds, as long as you use an LTS distribution with strong ABI promises (e.g., Ubuntu 20.04). Most major cloud vendors have quietly adopted it, especially for function builds: <a href="https:&#x2F;&#x2F;github.com&#x2F;buildpacks&#x2F;community&#x2F;blob&#x2F;main&#x2F;ADOPTERS.md" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;buildpacks&#x2F;community&#x2F;blob&#x2F;main&#x2F;ADOPTERS.m...</a><p>You might recognize &quot;buildpacks&quot; from Heroku, and in fact the project was started several years ago in the CNCF by the folks who maintained the Heroku and Cloud Foundry buildpacks in the pre-Dockerfile era.<p>[Disclaimer: I&#x27;m one of the founders of the project, on the VMware (formerly Cloud Foundry) side.]
评论 #25558487 未加载
Arch-TK超过 4 年前
I get that doing APIs right is hard and that when you&#x27;re trying to release a proprietary product having to worry about what libraries every system comes with may be a struggle and that if you&#x27;re developing a webapp you may want everyone to have a consistent test environment regardless of what flavour of archlinux they&#x27;re running but I really do NOT want to have to spend 2 hours downloading 300GiB of software updates when OpenSSL wets the bed and has a critical vulnerability. The nice thing about libraries and shared objects is that when I get an email saying: &quot;Critical CVE found in something important that may actually affect you&quot; I want to be able to run an update command which fetches a few libraries including the vulnerable one, reboot and be back in business.<p>I also don&#x27;t really care for the &quot;we have so much space now&quot; argument. I certainly don&#x27;t, I don&#x27;t put in expensive 2TB SSDs in my laptop because I don&#x27;t need them, and I don&#x27;t want half of my 500GiB disk to be taken up by giant blobs of unoptimized docker images for the same reason that I don&#x27;t want to run 10 copies of chrome at the same time to use a text editor, an email client, a web browser, a media player, a debugger, the thing I&#x27;m writing, three chat clients, and a partridge in a pear tree. I have extra space and extra processing power on my computer so that a: I can use it for the things I actually want to use it for and b: so that I have a snappy machine which can take an unexpected load (be it disk load or processing load) without problems.
OCISLY超过 4 年前
I prefer zero-dependency single file executables. Elegant and easy to comprehend. Docker only adds another layer of abstraction and its advantages are questionable.
masa331超过 4 年前
This brings only mess and another indirection layers to your system which is hardly an advantage in my opinion. It will take more time to setup, more space on disk, it will be slower and harder use. And all the normal tools(like awk and others in the article) are easily instalable in all distros. I will rather spend time learning these tools directly instead of infinitely fiddling with docker.
gorgoiler超过 4 年前
If you are reading this with interest then I encourage you to give it a go.<p>However, Docker is like a kitchen machine: good for getting something done in a particular way (stand mixer for kneading dough) but less useful for understanding what’s actually happening (when is pizza dough ready?)<p>On Linux, picking apart LXC stuff at the command line is very much worth your time if you’re interested in how things work. (Not LXD though which is more useful as a tool than as a teaching aid.)<p>If you have some IPv6 allocation to play with you can make some interesting infrastructure and have it do something useful on the Internet without relying on the lxc-net crutches of an automatically built bridge with NAT. It all feels very well designed as a bag of tools to let one make things rather than a complete system that guides you in only one particular direction.<p>I use stand mixers and Docker all the time; sometimes it’s fun to get into the details too.
knur超过 4 年前
This reminded me of a proof of concept thing I wrote months ago, that facilitates this kind of work.<p><a href="https:&#x2F;&#x2F;github.com&#x2F;casidiablo&#x2F;macondo" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;casidiablo&#x2F;macondo</a><p>I don&#x27;t even know what it is I built, but it has been useful in some contexts.<p>It basically allows you to easily wrap and distribute scripts (or more complex apps) that have specific dependencies that might not always be installed in the host. It does so by wrapping the script in a docker image.<p>It also automates the annoying part of docker: mounting local paths for apps that need to interact with the host&#x27;s file system.<p>I need to write a blog post on this if anything to gather feedback. I&#x27;m still not 100% sold on the idea and there are some edge cases. Still, a fun experiment.
anonymoushn超过 4 年前
&gt; If you’re using Docker on a Mac and you’ve never tried it on Linux, you owe it to yourself to try it on Linux.<p>So ultimately the recommendation is to install Linux and use it as my daily driver. But Linux does not run on my machine yet.
评论 #25547483 未加载
mongol超过 4 年前
I am surprised that systemd portable services is so little known. It solves many of the same problems as Docker does but is comparatively simpler. It also requires more plumbing on top but I prefer it.
tracker1超过 4 年前
I&#x27;m not sure I&#x27;d reach for this in some of the use cases over snap&#x2F;flatpak&#x2F;appimage for GUI applications. For <i>some</i> terminal apps, maybe, but even then I usually just user my dockerfile or docker-compose file to manage these needs.<p>What&#x27;s really needed are better&#x2F;more articles about how to clean off the cruft left by docker after running your builds locally. Especially when you do things like update your base image versions from node:12 to node:14 etc.
KoenDG超过 4 年前
I recall someone building a docker image specifically for the purpose of setting up a development environment.<p>A large amount of inter-connected projects for a SaaS-like service, all mounted inside the docker container, with some very specific libraries pre-compiled in the docker image, that used to take 30+ minutes to build.<p>And now they&#x27;re just in a docker image, that will work on linux and mac and I guess windows too.<p>Nice idea in theory.
nyellin超过 4 年前
I&#x27;ve been looking at startup ideas in this space, either as a Citrix replacement (run applications locally in a secure enclave instead of running them in the cloud and paying for vms) or as a way of bringing the benefits of containers to desktop apps and traditional IT (build containers for deployments not images). Would love to hear from anyone with use cases or pain points.
jasoneckert超过 4 年前
I run most of my apps in containers on my developer workstation as well. Once containers became popular and I noticed that a few of my apps were available as container images on DockerHub, it just made sense from a resource and security point of view. This is the first post I&#x27;ve seen advocating it, but I think it is sage advice for anyone.
评论 #25547777 未加载
ChicagoDave超过 4 年前
This might lead to developers not knowing or understanding their environment and I have a problem with that.
lenkite超过 4 年前
My Macbook fans rev up to the max after starting the Docker VM. And battery life falls like water running downhill.<p>No, thanks - I shudder at the existential nightmare at being forced to do all development via Docker. Use Docker for deployment, exit the VM and get back to your work.
0x445442超过 4 年前
Because of various org restrictions I attempted to create a developers image on Windows 10. I got the container running but mounting the volumes back to my host workspace was not performant. A build that took 10 seconds on the host took 90 seconds in the container.
X6S1x6Okd1st超过 4 年前
Ugh at work the edit-compile-run loop only needs to be ~1 second (it&#x27;s a fairly small go project), but our build system uses docker for everything, so now it&#x27;s ~1 minute a 60x increase to pay for the constant costs associated with docker.<p>Docker has tradeoffs.
sweeneyrod超过 4 年前
Docker has on the order of 1 second startup time doesn&#x27;t it? I don&#x27;t understand why someone would willingly subject themselves to that for things being manually run multiple times per day without an extremely compelling reason.
djhworld超过 4 年前
I&#x27;d be interested to know if Jess Frazelle, linked in the post still maintains her Dockerize-everything setup. I remember a few years ago her write-up on that stuff.<p>Would be good to hear her thoughts a few years on
pjmlp超过 4 年前
Docker is the NoSQL of 2020.
评论 #25547482 未加载
评论 #25547552 未加载
评论 #25548259 未加载
blunte超过 4 年前
TFA could make a small paid course walking a dev through the process of setting all this up and using it effectively. I would buy it.
juancn超过 4 年前
Docker is ok. But please do not over use it.<p>It&#x27;s not really portable, it only runs decently on Linux, on other platforms it&#x27;s a kludge.
harrisonjackson超过 4 年前
&gt; slight startup delay<p>On a mac this is a complete deal breaker for anything you need to run frequently. It is more than slight.
eptcyka超过 4 年前
Instead of using docker, why not use podman? I prefer my containers in userspace with user privileges.
alexpapworth超过 4 年前
No thanks.
akhilcacharya超过 4 年前
I think the reasoning is perfectly sound for doing this but the performance penalty is too much to bear for most use cases - what&#x27;s preventing nixpkg&#x2F;guix from being used fully for this use case? Lack of available packages?