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.
Why do you not make the code available under a 'source code repository'?
41–50 of 99 posts
Re: Why do you not make the code available under a 'source code repository'?
#42The 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: 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-…
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.
Are you being serious? They intentionally don't host a source repo. What could be more hostile to a potential new developer.
Re: Why do you not make the code available under a 'source code repository'?
#43A source code repository lets me see what bugs you have fixed, and lets me do things like "git bisect" to discover the identity of the commit where you broke something six months ago that wasn't discovered because it's not covered by tests. Helping others find your bugs helps you. Anyone who is serious about any open source project today has a repository. Your bogus rationalizations sound like you haven't held a soft…
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.
Re: Why do you not make the code available under a 'source code repository'?
#44Dude's old ass 1994 website and coding practices gave me enough of a cross-section as to who he really is. Lazy.
Re: Why do you not make the code available under a 'source code repository'?
#45"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.
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.
Re: Why do you not make the code available under a 'source code repository'?
#46I 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…
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 iOS App Store disallows dynamic libraries. Libraries are statically linked into the final executable, so they're not easy to replace.
Re: Why do you not make the code available under a 'source code repository'?
#47Earlier quoted context omitted.
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 iOS App Store disallows dynamic libraries. Libraries are statically linked into the final executable, so they're not easy to replace.
As of iOS 8 you can use dynamic libraries, but the user can't replace them without invalidating the code signature for the app.
Re: Why do you not make the code available under a 'source code repository'?
#48Earlier quoted context omitted.
> 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…
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.
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.)
Re: Why do you not make the code available under a 'source code repository'?
#49A source code repository lets me see what bugs you have fixed, and lets me do things like "git bisect" to discover the identity of the commit where you broke something six months ago that wasn't discovered because it's not covered by tests. Helping others find your bugs helps you. Anyone who is serious about any open source project today has a repository. Your bogus rationalizations sound like you haven't held a soft…
> 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.
I dunno. Statements like in the link make me question if someone is actually competent.
Re: Why do you not make the code available under a 'source code repository'?
#50I 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…
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.