Why do you not make the code available under a 'source code repository'?(live555.com)
live555.com
Why do you not make the code available under a 'source code repository'?
http://www.live555.com/liveMedia/faq.html#no-source-code-repository
98 comments
Think you're correct - this has been his gig for 20 years, before that apple and sun for ~5 years, before that, academia.
Either that or he's using VSS and is mortally embarrassed.
Either that or he's using VSS and is mortally embarrassed.
[deleted]
I remember the infrequent releases and not-very-collaborative development from the GNU Project once upon a time -- you get a new release with an announcement on an announce list and availability on the FTP site, a couple of times a year or sometimes less often. And that's about it, because it's the maintainer's responsibility to maintain the code. (Of course, you can contribute patches which the maintainer can accept or reject, and you can fork the program if you want. And some of the projects did have public discussion lists, but not all of them, and not at first.)
This is still the way that NetHack development works. :-)
It feels like something of an anachronism now, but it highlights the existence of a distinction between free and open source code (you can exercise certain freedoms with respect to any release) and collaborative development (you can potentially help create the release without having a formal relationship with the developers). I know Google has also been criticized around AOSP for being less transparent and collaborative than the present-day norm. Maybe they should defend themselves by comparing themselves to the NetHack Dev Team!
This is still the way that NetHack development works. :-)
It feels like something of an anachronism now, but it highlights the existence of a distinction between free and open source code (you can exercise certain freedoms with respect to any release) and collaborative development (you can potentially help create the release without having a formal relationship with the developers). I know Google has also been criticized around AOSP for being less transparent and collaborative than the present-day norm. Maybe they should defend themselves by comparing themselves to the NetHack Dev Team!
I have a source code repository for the code I write on my computer to track changes, and then I upload tar.xz's of the project for each "release". I can't see much benefit in opening a source code repository; if someone finds a bug, he can e-mail me a patch or even notify me about it.
Having a repository where many people can come and open issues puts a burden on my shoulders - I'll look at the page and see that I need to fix <some number> of issues, otherwise I'll look bad, or people will stop using my code.
Releasing my code in releases (so that everyone is on one release, or not on any release at all) means that I don't have to deal with people who've cloned the code half-way through the implementation of something large and complained that it won't run, or that it's full of bugs.
Releasing releases has been a solid model for me, especially as I work alone, or with a maximum of two or three other people at once.
If I was going to use a public repository, I think I'd end up using CVS.
Having a repository where many people can come and open issues puts a burden on my shoulders - I'll look at the page and see that I need to fix <some number> of issues, otherwise I'll look bad, or people will stop using my code.
Releasing my code in releases (so that everyone is on one release, or not on any release at all) means that I don't have to deal with people who've cloned the code half-way through the implementation of something large and complained that it won't run, or that it's full of bugs.
Releasing releases has been a solid model for me, especially as I work alone, or with a maximum of two or three other people at once.
If I was going to use a public repository, I think I'd end up using CVS.
If it's a personal project, it's largely a matter of taste, I think. I did tarball-upload style myself before.
I just like to comment that having public repo doesn't necessarily mean you suddenly have to deal with issues piled up by others, although in recent trend repo providers do encourage that kind of open communication (On github, I can turn off issue tracker but I don't know how to turn off pull requests).
Even using private repo, you still get bug reports, feature requests and patches via email, or (worse) stumble upon a blog or tweet complaining something isn't working for somebody. The reason I moved to public repo for my projects was that I got tired of dealing with patches manually - sometimes people sent patches against the release which was already fixed in my repo or had conflict with HEAD; sometimes I couldn't reproduce the problem so I had to send provisional patches to the user reported a bug to check out if that would address the issue. With public repo, I could just say "give me a patch against HEAD" or "I push a potential fix on a branch so check it out". It's so much easier. But again, this all depends on what kind of feedback you're getting, or how often your releases are, etc.
I just like to comment that having public repo doesn't necessarily mean you suddenly have to deal with issues piled up by others, although in recent trend repo providers do encourage that kind of open communication (On github, I can turn off issue tracker but I don't know how to turn off pull requests).
Even using private repo, you still get bug reports, feature requests and patches via email, or (worse) stumble upon a blog or tweet complaining something isn't working for somebody. The reason I moved to public repo for my projects was that I got tired of dealing with patches manually - sometimes people sent patches against the release which was already fixed in my repo or had conflict with HEAD; sometimes I couldn't reproduce the problem so I had to send provisional patches to the user reported a bug to check out if that would address the issue. With public repo, I could just say "give me a patch against HEAD" or "I push a potential fix on a branch so check it out". It's so much easier. But again, this all depends on what kind of feedback you're getting, or how often your releases are, etc.
> if someone finds a bug, he can e-mail me a patch or even notify me about it.
A source code repository can help someone find a bug more easily, and "preprocess" the bug report with more info for you, like "Hey, you broke such back on December 3, 2014---all you have to do is revert that commit's change to foo.c, and keep the other changes."
Users can run "blame" to find out which commit touched what line of any file.
Of course, you can debug a flat tarball, but it's sometimes better with the history. Particularly in cases when something previously used to work (users are running into a regression). If all they have is the previous release tarball and the new one, there are too many changes which could be responsible for the breakage.
> then I upload tar.xz's of the project for each "release".
All I do is push the release's git tag to my public repo, and the CGIT web front end automatically creates .tar.gz, .tar.bz2 and .zip download links for that tag:
> If I was going to use a public repository, I think I'd end up using CVS.
Thus, exposing a public version control repo is too uncool for old school, but if you use some unfashionably crappy old version control system, then it's acceptable.
A source code repository can help someone find a bug more easily, and "preprocess" the bug report with more info for you, like "Hey, you broke such back on December 3, 2014---all you have to do is revert that commit's change to foo.c, and keep the other changes."
Users can run "blame" to find out which commit touched what line of any file.
Of course, you can debug a flat tarball, but it's sometimes better with the history. Particularly in cases when something previously used to work (users are running into a regression). If all they have is the previous release tarball and the new one, there are too many changes which could be responsible for the breakage.
> then I upload tar.xz's of the project for each "release".
All I do is push the release's git tag to my public repo, and the CGIT web front end automatically creates .tar.gz, .tar.bz2 and .zip download links for that tag:
$ git tag frumly-widgets-2.3
$ git push --tags
> If I was going to use a public repository, I think I'd end up using CVS.
Thus, exposing a public version control repo is too uncool for old school, but if you use some unfashionably crappy old version control system, then it's acceptable.
You politely and clearly explained why you're unconvinced a repo would benefit you. You got a couple replies pointing out some advantages, which maybe you hadn't considered or at least some other people might not have known about.
Result? Nice discussion. Opportunity for folks to learn something new.
And yet, your comment is gray from down votes. Since it would look bad for you to complain about that, I will: That sucks.
Result? Nice discussion. Opportunity for folks to learn something new.
And yet, your comment is gray from down votes. Since it would look bad for you to complain about that, I will: That sucks.
Just look at the website itself... It's straight out of 1995, is it any wonder his views on source control are from 1990?
Git bisect is only available for git and (at least) subversion has no comparable command, so unless you are willing to force everybody to use git (and that may not be bad) you aren't guaranteed to get anything useful out of it.
Heck git allows you to edit the history pretty widely, right (I have only limited experience with git myself)? So in this case he could maintain a separate upstream repository which only contains the releases, with all the intermediate commits sanitized.
Heck git allows you to edit the history pretty widely, right (I have only limited experience with git myself)? So in this case he could maintain a separate upstream repository which only contains the releases, with all the intermediate commits sanitized.
I know it's svn is just an example but:
http://git-scm.com/docs/git-svn
The svn plugin to git let's have a git repo that is a clone /client of an svn repo. Very handy if you have an svn upstream but need to work offline.
http://git-scm.com/docs/git-svn
The svn plugin to git let's have a git repo that is a clone /client of an svn repo. Very handy if you have an svn upstream but need to work offline.
Git, Mercurial, Darcs, Monotone, and Baazar all have a built-in bisect and for svn there are well used external scripts (like svn-bisect).
git bisect automates the process, but the underlying technique should work with any VCS. and i've scripted it up in SVN several times to good effect
Git has bisect because Torvalds and co. did the same thing outside of version control using kernel tarballs.
"Hmm, it still worked in 2.2.13, but not in 2.2.37. Let's try 2.2.25."
"Hmm, it still worked in 2.2.13, but not in 2.2.37. Let's try 2.2.25."
I've been in situations where I was desperate enough to do it by hand. 20+ builds and manual tests later, I found a really nasty bug in some 3rd party code that manifested with the most bizarre repro that had no obvious connection even in hindsight, and symptoms involving cleanly exit(3)ing out of the program from a totally unrelated bit of code.
> Your bogus rationalizations sound like you haven't held a software job working with other developers in twenty-five years, if ever.
Video codec people are kind of weird as developers. Consider ffmpeg and libav. They're certainly competent, just weird.
Video codec people are kind of weird as developers. Consider ffmpeg and libav. They're certainly competent, just weird.
Interesting point, and I happen to have worked with the internals of ffmpeg on the job, so I understand. (I gave it a plugin architecture, supporting dynamically loaded AVParser and AVCodec objects, supporting hardware acceleration.)
I dunno. Statements like in the link make me question if someone is actually competent.
someone's grasp of best practices in vcs is in no way an indicator of their programming or cs abilities
But it could still be an indicator of competence.
To reason about software, it's a useful cognitive tool to be able to simplify gigantic systems down to interfaces and black boxes.
Carrying that notion of isolating components too far, such that you don't consider human cooperation as part of the system? It happens often, but we also often distinguish this with statements about EQ versus IQ rather than summing it all up as competence.
(Yes, you used the word indicator. I'm speaking to the community more than you specifically.)
Carrying that notion of isolating components too far, such that you don't consider human cooperation as part of the system? It happens often, but we also often distinguish this with statements about EQ versus IQ rather than summing it all up as competence.
(Yes, you used the word indicator. I'm speaking to the community more than you specifically.)
I don't see an issue with this (am I supposed to? Do we demand everyone use git or similar now?). They can give you the source however they want.
On another topic, did anyone see the license section?
---
If you distribute a product (whether software or hardware; whether free or for pay) that uses the LIVE555 library code, then you must - when requested by either a customer, or Live Networks, Inc. - upgrade it as soon as possible to use the latest version of the LIVE555 library code (or else provide a way for your customers to perform this upgrade themselves). Similarly, you must allow any of your customers to - at their discretion - replace the LIVE555 libraries used by your product with their own version (that uses the same API). (Note that in particular, because Apple restricts which iOS apps are made available on their 'App Store', you cannot use the LIVE555 library code in an iOS app that's distributed through Apple's 'App Store'.)
---
Does the LGPL enforce this, or is this some extra requirement?
On another topic, did anyone see the license section?
---
If you distribute a product (whether software or hardware; whether free or for pay) that uses the LIVE555 library code, then you must - when requested by either a customer, or Live Networks, Inc. - upgrade it as soon as possible to use the latest version of the LIVE555 library code (or else provide a way for your customers to perform this upgrade themselves). Similarly, you must allow any of your customers to - at their discretion - replace the LIVE555 libraries used by your product with their own version (that uses the same API). (Note that in particular, because Apple restricts which iOS apps are made available on their 'App Store', you cannot use the LIVE555 library code in an iOS app that's distributed through Apple's 'App Store'.)
---
Does the LGPL enforce this, or is this some extra requirement?
The issue isn't that they don't want to have a repository. The issue is that the rationale for not having one is pants on head idiotic.
The LGPL says no such thing about forcing you to distribute updates but the FAQ implies it does. I wonder how this squares with the part of the GPL that says:
>If the Program as you received it, or any part of it, contains a notice stating that it is governed by this License along with a term that is a further restriction, you may remove that term.
>If the Program as you received it, or any part of it, contains a notice stating that it is governed by this License along with a term that is a further restriction, you may remove that term.
The LGPL requires that end users are able to replace LGPL libraries with new builds. The App Store creates a bit of an issue, but it's possible to update app libraries if your phone is jailbroken. You might also be able to modify and re-sign, but I'm not sure.
The LGPL doesn't require the developer to use a new version or provide updates at anyone's request.
The LGPL doesn't require the developer to use a new version or provide updates at anyone's request.
Well, what they say:
> If you distribute a product (whether software or hardware; whether free or for pay) that uses the LIVE555 library code, then you must - when requested by either a customer, or Live Networks, Inc. - upgrade it as soon as possible to use the latest version of the LIVE555 library code (or else provide a way for your customers to perform this upgrade themselves).
That's a very strained reading of the LGPL, but the way the LGPL is written, they must provide a way for customers to updgrade the LIVE555 code used to whatever version they want to, including the latest version. It doesn't have to WORK, necessarily, but the ability to replace LGPL code in a work with one's own code is part of the license.
TL;DR: I think they're wrong but not so far wrong as to be crazy, and what they insist on happening is a consequence of following the terms of the LGPL (customers being able to upgrade to the latest version).
> If you distribute a product (whether software or hardware; whether free or for pay) that uses the LIVE555 library code, then you must - when requested by either a customer, or Live Networks, Inc. - upgrade it as soon as possible to use the latest version of the LIVE555 library code (or else provide a way for your customers to perform this upgrade themselves).
That's a very strained reading of the LGPL, but the way the LGPL is written, they must provide a way for customers to updgrade the LIVE555 code used to whatever version they want to, including the latest version. It doesn't have to WORK, necessarily, but the ability to replace LGPL code in a work with one's own code is part of the license.
TL;DR: I think they're wrong but not so far wrong as to be crazy, and what they insist on happening is a consequence of following the terms of the LGPL (customers being able to upgrade to the latest version).
Theoretically, could you just say "the newest version of this software is licensed under the LGPL; for any other version, I retain copyright and grant no rights to it, and revoke any rights previously granted."? So it becomes an infringement of their copyright to not be running the newest version, whatever the LGPL says.
The iOS App Store disallows dynamic libraries. Libraries are statically linked into the final executable, so they're not easy to replace.
In that case, the LGPL requires you distribute source or relinkable object files.
I know a lot of folks don't (because i do M&A due diligence), but that's a very clear license violation if you don't.
(also note that IOS 8+ allows dynamic linking, but replacement may still be an issue).
I know a lot of folks don't (because i do M&A due diligence), but that's a very clear license violation if you don't.
(also note that IOS 8+ allows dynamic linking, but replacement may still be an issue).
As of iOS 8 you can use dynamic libraries, but the user can't replace them without invalidating the code signature for the app.
Ross may have tacked this on after this exchange with Foscam regarding an IP camera line streaming RTSP with an ancient (and buggy) live555 release:
http://foscam.us/forum/a-reported-problem-with-your-fi9821w-...
http://foscam.us/forum/a-reported-problem-with-your-fi9821w-...
The user-replaceable part is standard fare, but I've never heard about the forced upgrading part. That sounds pretty crazy. I guess if you follow the LGPL and allow a user to swap out the library you're covered, since they say "or". Maybe it's "LPGL or release updates until you die"?
It seems to me that they don't actually WANT anyone to use it, and definitely not modifying the code... Really makes you wonder why they bothered to make it open source and LGPL licensed
I'd like to think the first part is talking about making extensions to the code, that you should be writing subclasses to add new functionality for your own use, not maintaining a series of patches.
That is, dependency injection for your extensions, not alterations to the core.
The whole project reeks of anachronistic development practices, though.
That is, dependency injection for your extensions, not alterations to the core.
The whole project reeks of anachronistic development practices, though.
That's a pretty strained interpretation of "open source" on their part.
> when requested by either a customer, or Live Networks, Inc. - upgrade it as soon as possible to use the latest version of the LIVE555 library code
This is not a requirement of the LGPL, the rest is. A user must be able to replace a LGPL portion of a program. Dynamic linking is the way this is usually accomplished.
This is not a requirement of the LGPL, the rest is. A user must be able to replace a LGPL portion of a program. Dynamic linking is the way this is usually accomplished.
the "upgrade it as soon as possible" part is an extra requirement
> 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.
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.
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!
(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!
I don't get where the downvotes came from. All the downvotes in the world can't fix the past, sadly.
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.
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.
Conversely, GitHub is full of low quality software.
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.)
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]
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.
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.
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?
Subclassing for versioning, eh? I remember talking to a friend in the early 90s who was doing that at the company he worked at.
I was reading about SCCS at the time, and wanted to convince my management to use that, but couldn't get them away from the "directory tree per release version" method.
My next job in the mid 90s used RCS, and I've never worked at a job since that didn't use some kind of version control / archive software. Hard to fathom that some organizations still avoid version/revision control. How do you "undo" to yesterday when you change your mind about something???
I was reading about SCCS at the time, and wanted to convince my management to use that, but couldn't get them away from the "directory tree per release version" method.
My next job in the mid 90s used RCS, and I've never worked at a job since that didn't use some kind of version control / archive software. Hard to fathom that some organizations still avoid version/revision control. How do you "undo" to yesterday when you change your mind about something???
> How do you "undo" to yesterday when you change your mind about something???
One might argue that developer time is valuable enough to ensure that it's spent on things that won't be "undone".
One might argue that developer time is valuable enough to ensure that it's spent on things that won't be "undone".
That's totally unrealistic. Often it's not the dev. that changes his mind, but the client. And since they have the $$$ you will be "undoing" previous work.
Exactly. Any good development process and software architecture must be responsive to change without enduring huge problems trying.
What happens when you introduce a bug that isn't discovered for 6 months? What happens if you think of a better way to do something? What happens if you're working on something and the power goes out, leaving you with partially-completed and saved work with no editor history? And so on...
[deleted]
Modifying behavior only by subclassing rather than changing the code was the original idea of the open/closed principal. Of course, the idea has drifted a bit since then since everyone discovered that in practice it worked terribly.
Not really sure I understand the problem here? I'm willing to bet that most people ready to excoriate the developer over their lack of version control will probably never even directly use the library.
They are still offering the library as open source in an easily-downloadable form. It is a gift. You can take a gift or you can leave a gift, but you don't whine about how the gift isn't the one you wanted.
They are still offering the library as open source in an easily-downloadable form. It is a gift. You can take a gift or you can leave a gift, but you don't whine about how the gift isn't the one you wanted.
A "gift" that comes with conditions that obligate you to do work (e.g. upgrading your own code to the newest release of their library whenever they make one) is not usually considered a gift.
Of course there are still people who don't understand what repositories are and how they work. That's really a pity with such a big, well known project, because then others have to do that work for them. (And this kind of project usually has many repos because people don't talk to each other)
Example: https://github.com/hackeron/live555
Example: https://github.com/hackeron/live555
The quality of their code looks pretty terrible too. For starters, just look at their genMakefiles script (something of a WTF itself - y u no configure?):
https://github.com/hackeron/live555/blob/master/genMakefiles
It should be more like:
https://github.com/hackeron/live555/blob/master/genMakefiles
It should be more like:
os=$1
modules="liveMedia groupsock ..."
for module in $modules
do
/bin/rm -f $module/Makefile
cat $module/Makefile.head config.$os $module/Makefile.tail > $module/Makefile
chmod a-w $module/Makefile
done> y u no configure?
Because autoconf is a huge disgusting mess and if you can generate your Makefiles as simply as that, for the love of God DO IT!
Because autoconf is a huge disgusting mess and if you can generate your Makefiles as simply as that, for the love of God DO IT!
That's a pretty weak example to argue that their code quality is poor.
They didn't bother to set up a for loop, for only 8 iterations. Their version is still perfectly legible, and you don't have to worry as much about shell argument expansion, which nobody really understands fully.
They didn't bother to set up a for loop, for only 8 iterations. Their version is still perfectly legible, and you don't have to worry as much about shell argument expansion, which nobody really understands fully.
I'm sure they would welcome contributors!
I wonder if the classic excuse for not open sourcing software applies here - that the developer is ashamed of their source, that they think it is messy and no one will like it, applies here?
Either way, one shouldn't really overtly negatively criticize - it probably wouldn't encourage such a developer if they do have that thought.
I wonder if the classic excuse for not open sourcing software applies here - that the developer is ashamed of their source, that they think it is messy and no one will like it, applies here?
Either way, one shouldn't really overtly negatively criticize - it probably wouldn't encourage such a developer if they do have that thought.
1. It sounds like they do not want outside contributors.
2. They might not use one internally or using something old that does not expose to the internet well.
2. They might not use one internally or using something old that does not expose to the internet well.
From #mercurial in Freenode where I found this, "I hope he has some [VCS] internally. He still releases archives with the odd random file or line of testing code in though."
If you ever see someone release file.c.bak, it's just sad.
To be fair, seeing .bak or .config or private key files, etc. accidentally pushed to github is not exactly uncommon.
.config sure, but .bak? That's what revision control software is for! :D
People can still add them accidentally to the repository unless they have configured properly .gitignore/.hgignore/... By the way GitHub has a repository of .gitignore files for various tools and languages [1].
[1]: https://github.com/github/gitignore
[1]: https://github.com/github/gitignore
That was my thought as well (regarding 1). That they treat this almost like a code dump of their latest version, take it and use it, or don't.
I actually managed to contribute to it once, via the mailing list. This doesn't really invalidate (1), but maybe they just don't want GitHub-style forks ("modifying the supplied code 'in place' is something that we discourage").
It's unavoidable with open source. Take any project with daily tarballs and mailing list diffs and you can probably even code a solution that will transform it to a git repo. Actually a git repo is not that different from a tarball webshare with a shell client for diffs etc.
You mean in theory it will happen. I think the real question is, "Does it work in practice?" We'd have to look at software like these to see how many got forked versus similar software with repo's and such. My guess: I bet it does work for a good many of them because of developers being too lazy to go through the trouble. If the functionality is useful enough, then it won't work because the maintenance is easier than duplicating their work.
Still, I'm not sure of the value in doing this kind of thing. The licensing schemes where you can't use the projects name in derivatives made sense: poor knockoffs can hurt image and adoption. Yet, people not wanting code to be used so easily probably shouldn't be open licensing it in the first place. These people are weird lol...
Still, I'm not sure of the value in doing this kind of thing. The licensing schemes where you can't use the projects name in derivatives made sense: poor knockoffs can hurt image and adoption. Yet, people not wanting code to be used so easily probably shouldn't be open licensing it in the first place. These people are weird lol...
Of course for small projects it won't happen. But for big ones it happens for sure. And then it doesn't matter if that (or these) repos are by the original author or not. If you can rely on regular updates to that repo then people will use it just as if it would be the original source and will spread just as far as any other repo based FOSS project. So I think for major projects the limitation you can achieve that way is minimal.
I agree.
[deleted]
AFL "fuzz" is also delivered like that (http://lcamtuf.coredump.cx/afl/). It's a smart tool to do fuzzing with a genetic algorithm.
You are, of course, free to set up your own public source code repository. Many have done so:
https://github.com/search?utf8=%E2%9C%93&q=live555
https://github.com/search?utf8=%E2%9C%93&q=live555
My experience is that for a
software development project of
just a few people, for a
code repository fairly obvious use of
the hierarchical
file system on a shared server
is just fine.
No, it isn't. Especially since it's so damn easy to setup a git or mercurial server.
Whats worse is most of the labor saving benefits like rollbacks, bisection, branch/merge all work just fine if you never type git push. Even just "what have I changed so far, oh git status". The client alone has many benefits.
Time for old guy rant that in the bad old days I just had a box I could ssh into and that was enough, or should I say, that was better than subversion. Don't forget to init the remote repo before pushing into it, as I forgot seemingly every single time. There was life before gitolite, gitlab, and github.
Time for old guy rant that in the bad old days I just had a box I could ssh into and that was enough, or should I say, that was better than subversion. Don't forget to init the remote repo before pushing into it, as I forgot seemingly every single time. There was life before gitolite, gitlab, and github.
I certainly thought that for a long time. Then I learned how to use version control.
I suddenly don't want to know how the source looks like.
Dude's old ass 1994 website and coding practices gave me enough of a cross-section as to who he really is. Lazy.
Ugh, what people will do for job security.
"As the software is open source, however, hobbyists are also free to use it, but to post to this mailing list, they are expected to demonstrate at least a minimal level of 'cluefulness' by using an email address with their own domain name - not just a generic "@gmail", "@yahoo", etc.-type email address."
Makes sense.
Makes sense.
This assumption, like just about everything on that site, is about 15 years out of date. A whole lot of "clueful" people have given up on running their own mail servers for their personal email accounts. They either use Google Apps, if they want their own domain, or they just use Gmail. The spam problem is too great otherwise.
Apparently I am no longer a 'clueful' user then. Makes me chokle.
Nobody with a clue waste hours setting up their own email server when gmail can do it for you in a few minutes.
Nobody with a clue waste hours setting up their own email server when gmail can do it for you in a few minutes.
I pay Fastmail what's currently going for $40/year for an "Enhanced" personal account that includes using my own personal domain.
Having my own domain avoids problems like, oh, Google going mad about true names with Google+ and shutting down my Gmail account.
Having my own domain avoids problems like, oh, Google going mad about true names with Google+ and shutting down my Gmail account.
I have a Gmail hosted address at a personal domain. Took ten minutes to set up.
I set up my own email server, and I consider myself to have a clue.
Mailgun + Cloudflare + Gmail
Who still bothers to do that?
Every address I give out is one of my own domains. Mostly they redirect to my gmail account, but this way I can change to a different provider or suddenly spin up my own mail server and no one has to update their address book.
Edit to add: My point not withstanding, yeah, that's an arbitrary "cluefullness" test.
Edit to add: My point not withstanding, yeah, that's an arbitrary "cluefullness" test.
I've never bothered. Hotmail or Yahoo email addresses were embarrassing back in the day, but I guess the hype around Gmail changed that 10 years ago. I've never felt awkward putting a gmail address on a business card.
You don't find that a gmail address on a business card conveys that it's a 1-2 person operation or very loosely organized? Given the low barrier to entry for setting up hosted email (google apps being $5/mo/user) I personally get the impression the person doesn't take their business seriously, on par with business cards with perforated edges from home printing.
I know my gut reaction when I get a (semi-)professional email from a gmail account is "ok.. what's the scam angle on this one?"
I know my gut reaction when I get a (semi-)professional email from a gmail account is "ok.. what's the scam angle on this one?"
When I was a 1 person operation, and worked as a consultant doing dev work and consulting, I had no problem using my Gmail account. Of course when I started a small company we used a hosted domain.
But before the Gmail days it was weird and unprofessional for even a 1 person operation to have a Webmail address.
But before the Gmail days it was weird and unprofessional for even a 1 person operation to have a Webmail address.
Anyone who is serious about any open source project today has a repository.
Your bogus rationalizations sound like you haven't held a software job working with other developers in twenty-five years, if ever. Hey, putting tarballs on the sunsite.unc.edu FTP site worked in 1990---why change a process that works?
Exposing a version history doesn't imply that you're supporting old baselines. What is or is not supported is declared separately from version control.
You cannot stop people from merging their local changes to your upstream by not having a repository. Linux didn't have a repository for years, yet people maintained and shared complex patches outside of the official tree anyway. (And with tools like Quilt, refined that to an art form.) People will take your snapshots, import them on into an upstream branch and do their own ad-hoc version control on your code.