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

Are tarballs obsolete?

esr.ibiblio.org

Post reply on HN
Print view View original

31–40 of 85 posts

Re: Are tarballs obsolete?

#31

Post by tritium »

No! 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 hand. You need a program to help test the integrity of a tree with some recursive problem solving. Take tarballs away from people, and you're putting things on a shelf, out of reach, taking away a level of safety and reliability from a certain cross-section of your audience.

Not only that, but EVERY platform has a web browser, even if it's curl or wget. 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 third-party web service provides coverage.

If we're simply talking file formats, and possibly exchanging the tarball for zips, ISOs or what-have-you, as alternative serial representations of the same data, that's not even a discussion.

If you're worried about practical utility, load, bandwidth and/or availability (or even, perhaps, culling the dull, dumb, toxic and obnoxious from the herd, terrible as that sounds) then changing the agent permitted to access the resource might be one solution, but not necessarily the right solution.

Re: Are tarballs obsolete?

#32

Post by statictype »

nuxi7 wrote: post #14

The distributed form of a project (especially one based on GNU autotools) is often not merely a tarball of the upstream repository. Often the author has pre-run some stages of the build that she feels would impose unnecessary or esoteric dependencies. Typically this involves pre-generating Makefile.in from Makefile.am and configure from configure.ac. Another common one is for the maintainer to pre-generate the docume…

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.

Re: Are tarballs obsolete?

#33

Post by ubernostrum »

dajohnson89 wrote: post #20
discreditable wrote: post #2

Correct me if I'm wrong but doesn't a git clone involve downloading the project's entire git history as well as $CURRENT_VERSION? That seems a little excessive.

And what if you find a bug, and want to regress to a previous version? What is so cumbersome about downloading a project's history?

Well, some projects have been around for a while. "All the history" can be a LOT of history.

Re: Are tarballs obsolete?

#35

Post by Gracana »

statictype wrote: post #32
nuxi7 wrote: post #14

The distributed form of a project (especially one based on GNU autotools) is often not merely a tarball of the upstream repository. Often the author has pre-run some stages of the build that she feels would impose unnecessary or esoteric dependencies. Typically this involves pre-generating Makefile.in from Makefile.am and configure from configure.ac. Another common one is for the maintainer to pre-generate the docume…

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.

Re: Are tarballs obsolete?

#36

Post by eru »

ubernostrum wrote: post #33
dajohnson89 wrote: post #20

Earlier quoted context omitted.

And what if you find a bug, and want to regress to a previous version? What is so cumbersome about downloading a project's history?

Well, some projects have been around for a while. "All the history" can be a LOT of history.

Actually, even for the Linux kernel, it's only a few hundred megabyte.

Re: Are tarballs obsolete?

#37

Post by eru »

deathanatos wrote: post #19

The article seems to mean "tarballs are obsolete for source distribution", not obsolete on the whole. > Here’s an advantage of the clone/pull distribution system; every clone is implicitly validated by its SHA1 hash chain. Given that TLS does not consider SHA1 secure[1] anymore… I'm not sure that's an assumption I'd be making. [1] in the sense that it's being rapidly deprecated; even if it doesn't trigger validation…

SHA1 is still good as a checksum against random errors.

Re: Are tarballs obsolete?

#38

Post by voltagex_ »

Jasper_ wrote: post #18
nuxi7 wrote: post #14

The distributed form of a project (especially one based on GNU autotools) is often not merely a tarball of the upstream repository. Often the author has pre-run some stages of the build that she feels would impose unnecessary or esoteric dependencies. Typically this involves pre-generating Makefile.in from Makefile.am and configure from configure.ac. Another common one is for the maintainer to pre-generate the docume…

This becomes more complex when distributions want to patch configure.ac or Makefile.am -- they need to patch the included Makefile.in files as well. Trying to balance these two forces is the reasoning behind the AM_MAINTAINER_MODE flag. These days, I prefer to simply use git archive for a tarball and make users run autogen.sh themselves. See https://blogs.gnome.org/desrt/2011/09/08/am_maintainer_mode-... and the asso…

To the newcomer, autoconf looks really scary. Are there any good tutorials and are there clear advantages of using autoconf over CMake, waf, scons, ninja or other hipster-language-build-systems?

I'm going to start looking at CMake to build HTML and javascript based projects soon.

Re: Are tarballs obsolete?

#39

Post by voltagex_ »

gizmo686 wrote: post #23
scrollaway wrote: post #16

Earlier quoted context omitted.

> Offline use Tarballs are just as offline as git repositories... > Permission restrictions (Internal git networks) What? > True-persistent versioning (Can always delete and update a tag) Why is that of concern regarding "tarballs vs git"? If anything it's a win for git. > Can restrict extra garbage that may not be need to be shipped Only valid point you presented, and it's better discussed elsewhere in this thread.

>Tarballs are just as offline as git repositories... Tarballs are easier to shoenet into an offline machine. To do this with git repositories, you would either need to deal with transfering a directory structure or, more likely, pack the respository into some sort of tarball.

`git bundle create` will do what you want.

Re: Are tarballs obsolete?

#40

Post by TheDong »

tuna wrote: post #11

docker brought back the frenzy of delivering software in a tarball just like slackware in the past. Long live patrick volkerdig and tar -zxvf ... -C / !

Even though Docker's disk and transport format are technically tar, I think that this is still a wrong statement.

tarballs are ubiquitous already. Docker actively hides that it uses tarballs (it abstracts away all interactions with them, to the point that it really is an implementation detail excluding docker export/import).

Post reply on HN