Step 1: gems, npm, pip, etc.
Step 2: "containers".
Step 3: this.
Are tarballs obsolete?
61–70 of 85 posts
Re: Are tarballs obsolete?
#62Consider using core OS tools (wget/fetch, tar, etc.) versus the dependency tree required to run git on your system. Do you need curl? Do you need perl? Do you need a XML parser and a regex runtime engine?
Re: Are tarballs obsolete?
#63Earlier quoted context omitted.
Unrelated, but this reminds me of 10 years ago and the horrors of running configure && make; And watching it implode most of the time. Running a configure script to generate a makefile to build software makes me glad for binary distributions.
I have been very happy with how will this has worked over the last few years. These days it's a rare surprise when I download software and it doesn't compile easily. Of course I much prefer to use an up-to-date binary from the package manager, if one is available.
That's largely because you still have the package manager to resort to in order to take care of most dependencies. Prior to that, you'd still have to install (a lot of) dependencies by hand. Not all of them used autotools, not all of them used standard install locations by default... it was pretty atrocious.
In fact, I remember that one thing which kept me on Debian for a long time was that it had so many available packages. Back then Debian was even slower than today and many of those packages were a little old, but it didn't really matter to someone who was just discovering things.
It's easy to forget about them, but package maintainers are incredibly important in today's Linux (and *nix-inspired in general) world. There's a lot of hard work behind the fact that you can just apt-get whatever new program you found out about.
Re: Are tarballs obsolete?
#64Earlier quoted context omitted.
> Why place something on a shelf, behind an agent that demands a learning curve, when it could also be available to a browser? wget git clone What is the difference in learning curve ? > With a single file, available by HTTP, any platform can get to it, so if your machine dies, and you have to call a friend for help, and they don't use the same OS, they won't have to install a special tool, or hope an intervening thi…
> git can be considered a pretty basic tool so what about CVS, svn, Mercurial and fossil? Git is hip right now, but including it in an initrd seems excessive. Furthermore git downloads the entire repo, all the history/commits, this isn't always what you want or can handle or want to pay for.
> so what about CVS, svn, Mercurial and fossil
Why, these are pretty basic too. Especially if what you want is just to get the code. Having a bit of experience with any VCS will let you skim the relevant manpage and use another VCS in minutes tops.
> including it in an initrd seems excessive.
True...
> Furthermore git downloads the entire repo
Not necessarily? I think you can download just the source files, without any git metadata, turning git into SVN essentially. I'm not 100% sure though, but I'd be really surprised was it not the case.
---
I started my VCS adventure with RCS, then (quickly) moved to CVS, then (even more quickly) to SVN. As soon as DVCS started to appear I switched to bazaar (bzr), then git. These are the VCS I used for my own projects; I probably used a couple more VCSes in a situation where I needed latest code for some project which used something like Mercurial, or Darcs, etc.
In general, I think it's fair to say that Version Control, as a whole, is a basic tool.
Re: Are tarballs obsolete?
#65Earlier quoted context omitted.
I have been very happy with how will this has worked over the last few years. These days it's a rare surprise when I download software and it doesn't compile easily. Of course I much prefer to use an up-to-date binary from the package manager, if one is available.
That's largely because you still have the package manager to resort to in order to take care of most dependencies. Prior to that, you'd still have to install (a lot of) dependencies by hand. Not all of them used autotools, not all of them used standard install locations by default... it was pretty atrocious. In fact, I remember that one thing which kept me on Debian for a long time was that it had so many available p…
What I find hardest (as a manual installer) is those packages which were designed with a package manager in mind and end up depending on many third party packages rather than incorporating the needed functionality.
As an example, program X might need to compute a statistic like the skewness of a distribution. A stats package might implement the skewness calculation, so the author of X adds the dependency and calls the right function.
However, building the stats package might require a Fortran compiler and some matrix libraries, since the stats package does much more than compute skewness.
Another approach would be for the author of X to incorporate the few tens of lines needed for the skewness as part of X. This is of course more work for the author X, so I can well understand the desire to simply declare it as a dependency.
Re: Are tarballs obsolete?
#66The problem tarballs solve is bundling files together. That use-case will probably be with us for awhile even if it has fallen out of favor for source code.
The article is discussing whether it is worth to provide tarballs for software releases, not tarballs in general. The title might be misleading.
Re: Are tarballs obsolete?
#67Earlier quoted context omitted.
> git can be considered a pretty basic tool so what about CVS, svn, Mercurial and fossil? Git is hip right now, but including it in an initrd seems excessive. Furthermore git downloads the entire repo, all the history/commits, this isn't always what you want or can handle or want to pay for.
> so what about CVS, svn, Mercurial and fossil Why, these are pretty basic too. Especially if what you want is just to get the code. Having a bit of experience with any VCS will let you skim the relevant manpage and use another VCS in minutes tops. > including it in an initrd seems excessive. True... > Furthermore git downloads the entire repo Not necessarily? I think you can download just the source files, without a…
>Not necessarily? I think you can download just the source files, without any git metadata, turning git into SVN essentially. I'm not 100% sure though, but I'd be really surprised was it not the case.
Partially possible. You're always fetching diffs, not files, with git. You can get close to what you said with `git clone --depth 1`, which tells git to only get history for the latest revision, but you still get some git metadata about available branches. Depending on the version of git you're using, you may also have to pass --single-branch in order to only fetch one branch's revision.
Re: Are tarballs obsolete?
#68No! Things like package managers and git, however pervasive, are agents and not the testable, serialized representation of data. Why wouldn't you make the same file set available as a single download via plain, old HTTP(S)? What's so hard about that? Why place something on a shelf, behind an agent that demands a learning curve, when it could also be available to a browser? You CAN'T hash a tree of files quickly by ha…
> Why place something on a shelf, behind an agent that demands a learning curve, when it could also be available to a browser? wget git clone What is the difference in learning curve ? > With a single file, available by HTTP, any platform can get to it, so if your machine dies, and you have to call a friend for help, and they don't use the same OS, they won't have to install a special tool, or hope an intervening thi…
wget
more like
wget
Re: Are tarballs obsolete?
#69Re: Are tarballs obsolete?
#70No! Things like package managers and git, however pervasive, are agents and not the testable, serialized representation of data. Why wouldn't you make the same file set available as a single download via plain, old HTTP(S)? What's so hard about that? Why place something on a shelf, behind an agent that demands a learning curve, when it could also be available to a browser? You CAN'T hash a tree of files quickly by ha…
> Why place something on a shelf, behind an agent that demands a learning curve, when it could also be available to a browser? wget git clone What is the difference in learning curve ? > With a single file, available by HTTP, any platform can get to it, so if your machine dies, and you have to call a friend for help, and they don't use the same OS, they won't have to install a special tool, or hope an intervening thi…
If you want a stable version, you can't necessarily just git clone. (Maybe if the default branch is kept stable, but I wouldn't trust that by default.) You also have to find the right branch/tag and do a checkout.