5 ms·

> I don't see an issue with this (am I supposed to? Do we demand everyone use git or similar now?). That depends on your job. If you are a software developer,

by zeeed 11y ago

> I don't see an issue with this (am I supposed to? Do we demand everyone use git or similar now?). That depends on your job. If you are a software developer, -engineer or similar, I would argue that you should. There are good arguments for version control. - divide & conquer for bugfinding - reconstruction of history - being able to revert back to an older version if/while operations require it - it allows tracking of changes over time - it is the best way of understanding what changed since the last version (for people actually using the library) - finding complex faults - branching and merging (but the author is opposed to this) So, well, what concerns live555, IMHO it's a huge red flag for people considering to actually use the library. When it comes to "not seeing an issue with not using source control", I believe that one can state without a doubt that it is a good and proven practice.

sfk 11y ago
Obviously source control has its benefits, but ironically often tarball-only developers produce very high quality software (the most prominent example is djb at cr.yp.to). Conversely, GitHub is full of low quality software.
- navait 11y ago
  You're cherry picking a few example of tarball only developers and then comparing it to the entirety of github? How is that a fair comparison at all?
- geofft 11y ago
  djb's software is pretty low-quality for very many metrics of "quality". Lots of it is not elegantly interoperable with existing UNIX systems, because he has his own idea of how UNIX systems should work. There's the entire qmail backscatter thing. There are pieces of crypto code written in a custom assembler. Curve25519 has its own reimplementation from Chrome's Adam Langley, and all of NaCl its own repackaging in the form of the libsodium project, because the official distributions are difficult to use. NaCl has been promising certain features in the "next release" for years (notably Ed25519 signatures), but no release has been seen. All the downloads are over plaintext HTTP with no cryptographic signatures: I've always interpreted this as implying that if you're not qualified to audit the entire tarball you downloaded, the software isn't for you. None of this is to claim that he's a bad cryptographer, or even a bad software engineer. But pure code output is far from the only important metric for software. GitHub makes it easy to do release engineering well, or to let other people help you with that if it's not your forte. (libsodium, for instance, is on GitHub.)
  - deleted 11y ago
    [deleted]
- sfk 11y ago
  Wow, -3 for this horrible comment. HN is full of idiots. Now go on, make it another -10; it will be the only thing in your day that makes you feel that you have any influence.
to3m 11y ago
It's usual to just put stuff like this in your own version control. Each time you get an update, delete old version, copy new version on top, then sort it out. Perforce has a "Reconcile Offline Work" for exactly this sort of situation; with git or svn, a simple commit will probably do exactly the right thing. This doesn't give you full history, but you get enough to revisit and bisect old versions. (With a touch more work, you can also maintain your own changes, and have them 3-way merged in automatically.) As for not using source control - if they don't use it internally, that's a bit weird, but maybe there's just one person working on the code, and they take a backup every hour, and they're happy. (It's their time, not mine.) But not exposing their source control to the outside world is absolutely standard. I worked as a programmer for software companies for ten years and never once saw 3rd-party code distributed any way other than zipped up source drops. (And this includes times where we were working with the 3rd party on the same project! - we just did the thing I mentioned at the start when they sent us updates, and they did the same thing at their end. It's much less of a bother than you'd think, though the first couple of merges can be a bit painful.) If you want to claim they're being unhelpful, the insistence that you upgrade at a moment's notice is much worse. Upgrading 3rd party libraries is one thing you never, ever want to do, unless your hands are absolutely tied!
- to3m 11y ago
  I don't get where the downvotes came from. All the downvotes in the world can't fix the past, sadly.
mgold 11y ago
Some of the arguments may seem plausible in theory, but as soon as I contemplate doing my 9-to-5 dev work without source control (specifically git)-- yeah, no, not happening.

by zeeed 11y ago

sfk 11y ago

Obviously source control has its benefits, but ironically often tarball-only developers produce very high quality software (the most prominent example is djb at cr.yp.to). Conversely, GitHub is full of low quality software.

navait 11y ago
You're cherry picking a few example of tarball only developers and then comparing it to the entirety of github? How is that a fair comparison at all?
geofft 11y ago
djb's software is pretty low-quality for very many metrics of "quality". Lots of it is not elegantly interoperable with existing UNIX systems, because he has his own idea of how UNIX systems should work. There's the entire qmail backscatter thing. There are pieces of crypto code written in a custom assembler. Curve25519 has its own reimplementation from Chrome's Adam Langley, and all of NaCl its own repackaging in the form of the libsodium project, because the official distributions are difficult to use. NaCl has been promising certain features in the "next release" for years (notably Ed25519 signatures), but no release has been seen. All the downloads are over plaintext HTTP with no cryptographic signatures: I've always interpreted this as implying that if you're not qualified to audit the entire tarball you downloaded, the software isn't for you. None of this is to claim that he's a bad cryptographer, or even a bad software engineer. But pure code output is far from the only important metric for software. GitHub makes it easy to do release engineering well, or to let other people help you with that if it's not your forte. (libsodium, for instance, is on GitHub.)
- deleted 11y ago
  [deleted]
sfk 11y ago
Wow, -3 for this horrible comment. HN is full of idiots. Now go on, make it another -10; it will be the only thing in your day that makes you feel that you have any influence.

to3m 11y ago

It's usual to just put stuff like this in your own version control. Each time you get an update, delete old version, copy new version on top, then sort it out. Perforce has a "Reconcile Offline Work" for exactly this sort of situation; with git or svn, a simple commit will probably do exactly the right thing. This doesn't give you full history, but you get enough to revisit and bisect old versions. (With a touch more work, you can also maintain your own changes, and have them 3-way merged in automatically.) As for not using source control - if they don't use it internally, that's a bit weird, but maybe there's just one person working on the code, and they take a backup every hour, and they're happy. (It's their time, not mine.) But not exposing their source control to the outside world is absolutely standard. I worked as a programmer for software companies for ten years and never once saw 3rd-party code distributed any way other than zipped up source drops. (And this includes times where we were working with the 3rd party on the same project! - we just did the thing I mentioned at the start when they sent us updates, and they did the same thing at their end. It's much less of a bother than you'd think, though the first couple of merges can be a bit painful.) If you want to claim they're being unhelpful, the insistence that you upgrade at a moment's notice is much worse. Upgrading 3rd party libraries is one thing you never, ever want to do, unless your hands are absolutely tied!

to3m 11y ago
I don't get where the downvotes came from. All the downvotes in the world can't fix the past, sadly.

mgold 11y ago

Some of the arguments may seem plausible in theory, but as soon as I contemplate doing my 9-to-5 dev work without source control (specifically git)-- yeah, no, not happening.