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

51–60 of 85 posts

Re: Are tarballs obsolete?

#51

Post by vacri »

scrollaway wrote: post #42
vacri wrote: post #30

Earlier quoted context omitted.

> Why is that of concern regarding "tarballs vs git"? If anything it's a win for git. Git tags (and branches) are mutable. Tarballs technically are, but don't move around as much. Unless someone's being actively malicious, you can be confident that no-one's going to put new code in an old-versioned tarball.

The exact same can be said of git. You're reaching. Git has builtin verification of absolutely everything it holds (tags included) since it uses sha1 for objects and commit messages, and they include the previous state... so a point in a git tree in that way is a hell of a lot more immutable than a tarball.

My colleagues complain of people moving tags and sometimes branches around, or fucking things up with a bad merge. I haven't heard the same criticisms of tarballs.

I'm not a tarball warrior, I'm just going off what I hear people saying.

Re: Are tarballs obsolete?

#54

Post by detaro »

eru wrote: post #36
ubernostrum wrote: post #33

Earlier quoted context omitted.

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.

"Only" a few hundred megabyte is "really a lot" in many situations.

Re: Are tarballs obsolete?

#55

Post by fsiefken »

tarballs which are also usually compressed (gz, bz2, 7z, xz) may have the benefit of being more efficient to download over bandwidth constraint or size constrained links. Also being 1 file, it's only one request and it works over zmodem or modern derivatives.

Re: Are tarballs obsolete?

#56

Post by JoachimSchipper »

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…

SHA-1 is clearly imperfect, but not that big a problem here. The writing is on the wall for SHA-1's collision resistance. A break in collision resistance would allow a malicious software maintainer to distribute different tarballs to people of interest than to the internet at large, but would not allow a third party to replace a honestly-generated tarball with some other tarball ("second pre-image").

Since you almost certainly need to trust the maintainer not to insert backdoors anyway (a well-hidden backdoor will not be detected by the normal packaging process), trusting the maintainer not to maliciously distribute different software to a small number of people of interest isn't that unreasonable.

Re: Are tarballs obsolete?

#58

Post by madawan »

simula67 wrote: post #44
tritium wrote: post #31

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 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…

> 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.

Re: Are tarballs obsolete?

#59

Post by lucb1e »

madawan wrote: post #58
simula67 wrote: post #44

Earlier 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.

> 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.

That's the default behavior, but with `git clone --depth 1` you can apparently download only the latest version of all files: https://news.ycombinator.com/item?id=10449157

Googling around, most pages confirm it. Found this one also informative: http://stackoverflow.com/q/6941889/1201863

Re: Are tarballs obsolete?

#60

Post by scrollaway »

vacri wrote: post #51
scrollaway wrote: post #42

Earlier quoted context omitted.

The exact same can be said of git. You're reaching. Git has builtin verification of absolutely everything it holds (tags included) since it uses sha1 for objects and commit messages, and they include the previous state... so a point in a git tree in that way is a hell of a lot more immutable than a tarball.

My colleagues complain of people moving tags and sometimes branches around, or fucking things up with a bad merge. I haven't heard the same criticisms of tarballs. I'm not a tarball warrior, I'm just going off what I hear people saying.

You haven't heard the same criticisms of tarballs because tarballs aren't used as a version control system. These issues are specific to (fairly bad) VCS usage, not packaging usage.
Post reply on HN