I hate to reply to the same message more than once, but...
I have no personal need for a distributed RCS
Are you sure?
Lots of people had no personal need for a GUI until they actually tried using one. Lots of coders claim they don't really need atomic commits (and thus either SVN, Arch, or any of the non-CVS alternatives) until they've used a RCS that supports them for a while.
"I don't need that feature", when that feature is something you've never personally experienced, is a statement it's easy to make in error. After using Arch, I find its distributed architecture and history-sensitive merging to be killer features. Are you so sure you'd never use them?
Yes, I'm aware of SVK. You'll note my disclaimer ("...with wide enough userbases to really trust them for production-level software").
Arch has a much larger user community and set of 3rd-party tools available. To me, that's important -- more important than having a polite Tom-equivalent.
SSH (particularly, sftp), or HTTP or WebDAV (with SSL support available), or plain FTP or raw filesystem access. Not sure about Solaris 2.9, but it should work there (or anywhere else that's a proper POSIX environment).
Particularly if you're interested in heavy branching or merging, Arch has a lot going for it. (And yes, I know about CVS's anemic recording of branch/merge history -- I was for a long while maintainer of CSCVS, a tool for intuiting changeset information from CVS archives).
Arch supports storing symlinks, and it supports moving bits of your trees around without having to munge history. What exactly is it you do with these symlinks you think might be hard to port?
(As for rsync, Arch has its own built-in mirroring support, which is arguably much better).
Arch has been forked once before. It didn't do much good. Search arch-users for Walter Landry, or ArX.
I like revision libraries, myself -- they can be used for things other than just making Arch commands work faster, and caches don't provide all their performance advantages for Arch commands, either. Correspondingly -- yes, we could use caching, but that's as a suppliment to revision libraries, not as a replacement for them. Using greedy libraries (hence optimal hardlink creation) on reiserfs (hence cheap directories and no inode limit), they're not as expensive in terms of disk usage as one might expect.
I disagree that tagline operation is broken. (Well, not intrinsicly. There's been some breakage in Tom's tree, but that's implementation, not concept).
Anyhow -- worst case performance sucks, yes. Best-case performance is better than almost all of the competition, with the likely exception of p4.
Well, yes, but there are only two distributed revision control systems with wide enough userbases to really trust them for production-level software, and both of them are developed by people who are arguably asshats.
Unless you're willing to compromise on major functionality in order to have a tool developed by an undisputedly friendly team, thus, you're (we're) kind of up a crick.
The flame war seems to be over, though certainly nobody won. I can't honestly say that either party appeared to behaving entirely admirably... *sigh*.
WRT performance, though, it's hard to talk without knowing more about your setup. I've seen some *exceedingly* good numbers wrt performance of mainline Arch on hardlinked trees (ideally backed by a greedy revlib), particularly on ReiserFS. Of course, that also varies by tagging method... so the performance-relevant factors include, at least:
- Revision libraries in use? - Hardlinked working directories in use? - Tagging method - Filesystem
Given how much of a difference some of these (particularly the first two) make, it's hard to talk much about performance without knowing more about your setup.
I thought that a readthrough of both "Diagnosing SVN" (one of Tom's screeds) and "Undiagnosing SVN" (a rebuttal by a SVN dev) makes for a very good composite understanding of the differences betweeen Arch and Subversion.
From my perspective as an end-user, however, there are really two features I can't live without that distinguish the two: Distributed operation, and history-sensitive merging. SVK has these -- but it's immature, and frankly I like Arch's design more (for reasons I can't go into here and still finish up at work today).
and I'd like to see it on my OS X/Linux machines as well.
It's entirely trivial to do on Linux, and I can't see why it wouldn't be similar on OS X. Heck, in most cases, you have to take assertive action to allow users mount and use their own USB devices in the first place.
If not, you can remove the usb-storage driver, or the hotplug config file entry, or the fstab entry, or... etc.
There's too much wastage for every additional session added to a CD -- you wouldn't be able to fit very many votes at all on one.
Anyhow, one of the advantages of the "paper tail in lockbox" proposal is that the paper can be reviewed by the voter (behind glass) before it's approved and fed into the lockbox, whereas there's no way to tell if what's being written to the CD represents your vote accurately or not.
Sure, I can know what JVM bytecodes come out of the compiler -- but I don't (and can't, unless I control the JVM) know what OS-level syscalls and CPU-level instructions that collection of bytecode will evaluate to, and occasionally it matters. The JVM may hide the lower levels most of the time, but it certainly doesn't do so flawlessly.
Practically speaking, I've never had CPU-related issues with Java -- but I *have* had OS-related problems leak through the JVM, and plenty of them. (I'm liable to get more of those than most, though -- I'm "dev support" at my company, a Java shop, meaning I field the toolage problems the developers and the sysadmins can't handle unassisted). Recently, for instance, I ended up debugging an issue revolving around heavily threaded Java code not playing nice on a system with a NPTL-enabled libc but a pre-NPTL kernel; I've also seen more than my share of JNI-related issues, and not a few based on filesystem semantics differences that the JVM's abstractions just couldn't hide.
In short: Targeting the JVM just doesn't give the same low-level control (and, consequently, debugging capabilities) that targeting the OS and CPU does -- but then, you knew that already, right?
Sorry, no slam against Ximian meant -- it's Rasterman's code I've historically had problems with.
Be curious to find out if the code's any cleaner.
on
Enlightenment Lives
·
· Score: -1, Offtopic
Last I knew (~4 years ago), Evolution had some of the ugliest, most unportable code I'd had the misfortune to look upon -- the sort of thing that gives Java coders and their ilk an excuse to look down upon C.
Since when did spammers care about legal limits? Very few of them are on the right side of every "easily enforced legal limit" that applies to them right now, so I hardly see how a few more will make any difference.
Let's say I'm a spammer. Let's say that for every spam I'm getting paid to send out, I send out another advertising a site that isn't paying me and (for that matter) wants nothing to do with me.
Now, how can the ISPs shut down the sites that pay me without also harming hundreds of legitimate sites in the process? Consequently, in order to avoid doing harm to innocents, they'll (presumably) eventually end up canning their plans to cut of service to my customers.
Sure, I'm doubling my costs -- but those are negligible anyhow. Have a solution? (As a non-spammer, I certainly *hope* so).
The thing is, one could take that "my code" comment to the extreme and say that it is no longer "my code" when it is run through a compiler that might optimize it, or, to take it even further, it is no longer "my code" when it is not written in zeros and ones. You're dealing with abstraction wherever you turn, so let's not pretend that intepreters are so different from compilers.
I'll generally have a pretty good feel for what assembly a compiler will spit out when I'm writing C, and if I need to poke into what the Python interpreter is doing under-the-hood (and I *have* needed to do that before), I can. I'm not saying there's a difference between interpreted and compiled languages -- in either case it's sometimes important to have access to the underlying implementation, and in either case (of compiled C or interpreted Python), such access is available.
First, I'll grant you that the 85th-percentile parser rule needs to be relaxed -- but I'm still inclined to hold that there's a grain of truth in there, as the percentage of the language rules that (for instance) an 85th-percentile C programmer knows is assuredly greater than the percentage known by an 85th-percentile Perl coder. In any event, that's a side issue -- it's just my own, personal guideline -- while the core issue is what languages are suitable for Real World (which, to me, is commercial) software development.
English is also a TIMTOWTDI language, yet nobody disputes that it's a good thing when it comes to English, because when we use English, we want to be expressive, not uniform. If you are a good writer, having options gives you the flexibility to choose what works for your given situation.
Yes, but one rarely has a team of 30 (or even 5) people working on a novel, with the expectation that that novel will be handed off to a set of different authors with completely different backgrounds to write extended versions later. Commercial software development has different requirements than writing novels -- and some of these involve containing the damage that is done by people who aren't good writers, as I've gone into in my parent post.
I need to go in to work now, so pardon if I'm leaving some threads unanswered.
Sometimes I want to know, as I'm writing my code, exactly what low-level operations will occur when that code gets run. My code, not the libraries I'm calling. Java doesn't even let me do that.
It's a pretty rare "sometimes", though -- I don't do so much low-level work these days. As far as the why of the matter, I think someone wrote a paper about leaky abstractions that explains it pretty well.
I just don't get the recent animosity towards perl. It's honestly one of the most powerful languages I've used. The unreadable code argument falls apart when you've seen some of the COMPLEATLY unreadable Java, Python, Lisp (although I personally think that language is unreadable by design) code I've seen. Any language can and will be abused.
Yes, but Perl is worse than the others, simply because the language spec itself has so many rules and edge cases that nobody can ever remember them all. (Putting regular expressions into the syntax rather than the standard library is, IMHO, one of the major mistakes along these lines). Here's a test I use to determine whether a language syntax is too complex: Can an 85th-percentile coder write a parser for it from memory?
TIMTOWTDI is a liability more than an asset: It means that no two skilled Perl coders will ever write the same solution, whereas two good Python coders (who are fully familiar with the standard library, available language features, etc) are much more likely to write similar code. As anyone who's actually worked on a large team (in which code is passed around between team members, inherited from those who leave or are fired[1], and otherwise has "ownership" as only a transient idea) can attest, consistancy is good. There are plenty of documents published about The Right Way to do a given thing in Java; likewise, Python has a consistent philosophy that it nudges everyone towards by design. Perl? A bloody mismash.
[1] - Bad Java, like bad Python, is typically bad by design -- it's not just that the implementation itself has no-op error handling or uses a ridiculously inefficient algorithm, but the actual internal interfaces are broken and wrong. In a corporate setting where interfaces are reviewed by someone known to be competant before they're implemented, this kind of evil can be contained -- so the problems that remain are implementation level, where the very strictness you complain "punishes the programmer" lets components be swapped out with sanely-written replacements one by one. I suppose you also think that policies requiring everyone to implement unit tests punish the folks who get their code right the first time?
Sure, it's easy to tell how your Java code operates within the bounds of the JVM. However, it's basically impossible to know how your Java code maps to actual syscalls (and similar low-level operations), in no small part because this varies by JVM implementation. For most people, this is fine -- the JVM is a black box, put bytecode in, get correct output out.
It's not fine for everyone, though. The fellow you're replying to is onesuch, and he has a valid point.
And yes, you are full of bull shit. Just because you don't like his lic. does not mean that it's not distributable and such. Get a life.
No, it's not because I don't like the license -- it's because he never grants a license at all permitting uses beyond those unregulated by copyright law. I have a life -- a good chunk of it belongs to a small startup that needs to be sure that its software redistribution practices are fully legal.
Sitting around on slashdot, trolling folks with blatant lies (ie. "it has a BSD lic") and insulting those who correct you -- that is having no life.
People wouldn't bereimplementingDJB'stools under less restrictive licensing (BSD in the case of ipsvd and runit, GPL in the case of libowfat) if he used a reasonable license in the first place, instead of giving out his software with no license to redistribute whatsoever.
I'm using runit rather than daemontools at work because we can't comply with DJB's non-license. Please be a bit more careful before calling bullshit.
Slashdot Mirror
Lots of people had no personal need for a GUI until they actually tried using one. Lots of coders claim they don't really need atomic commits (and thus either SVN, Arch, or any of the non-CVS alternatives) until they've used a RCS that supports them for a while.
"I don't need that feature", when that feature is something you've never personally experienced, is a statement it's easy to make in error. After using Arch, I find its distributed architecture and history-sensitive merging to be killer features. Are you so sure you'd never use them?
Yes, I'm aware of SVK. You'll note my disclaimer ("...with wide enough userbases to really trust them for production-level software").
Arch has a much larger user community and set of 3rd-party tools available. To me, that's important -- more important than having a polite Tom-equivalent.
SSH (particularly, sftp), or HTTP or WebDAV (with SSL support available), or plain FTP or raw filesystem access. Not sure about Solaris 2.9, but it should work there (or anywhere else that's a proper POSIX environment).
Particularly if you're interested in heavy branching or merging, Arch has a lot going for it. (And yes, I know about CVS's anemic recording of branch/merge history -- I was for a long while maintainer of CSCVS, a tool for intuiting changeset information from CVS archives).
Arch supports storing symlinks, and it supports moving bits of your trees around without having to munge history. What exactly is it you do with these symlinks you think might be hard to port?
(As for rsync, Arch has its own built-in mirroring support, which is arguably much better).
Arch has been forked once before. It didn't do much good. Search arch-users for Walter Landry, or ArX.
I like revision libraries, myself -- they can be used for things other than just making Arch commands work faster, and caches don't provide all their performance advantages for Arch commands, either. Correspondingly -- yes, we could use caching, but that's as a suppliment to revision libraries, not as a replacement for them. Using greedy libraries (hence optimal hardlink creation) on reiserfs (hence cheap directories and no inode limit), they're not as expensive in terms of disk usage as one might expect.
I disagree that tagline operation is broken. (Well, not intrinsicly. There's been some breakage in Tom's tree, but that's implementation, not concept).
Anyhow -- worst case performance sucks, yes. Best-case performance is better than almost all of the competition, with the likely exception of p4.
Well, yes, but there are only two distributed revision control systems with wide enough userbases to really trust them for production-level software, and both of them are developed by people who are arguably asshats.
Unless you're willing to compromise on major functionality in order to have a tool developed by an undisputedly friendly team, thus, you're (we're) kind of up a crick.
The flame war seems to be over, though certainly nobody won. I can't honestly say that either party appeared to behaving entirely admirably... *sigh*.
WRT performance, though, it's hard to talk without knowing more about your setup. I've seen some *exceedingly* good numbers wrt performance of mainline Arch on hardlinked trees (ideally backed by a greedy revlib), particularly on ReiserFS. Of course, that also varies by tagging method... so the performance-relevant factors include, at least:
- Revision libraries in use?
- Hardlinked working directories in use?
- Tagging method
- Filesystem
Given how much of a difference some of these (particularly the first two) make, it's hard to talk much about performance without knowing more about your setup.
Hrm?
I thought that a readthrough of both "Diagnosing SVN" (one of Tom's screeds) and "Undiagnosing SVN" (a rebuttal by a SVN dev) makes for a very good composite understanding of the differences betweeen Arch and Subversion.
From my perspective as an end-user, however, there are really two features I can't live without that distinguish the two: Distributed operation, and history-sensitive merging. SVK has these -- but it's immature, and frankly I like Arch's design more (for reasons I can't go into here and still finish up at work today).
Why? Tom's a bit abrasive, but Arch is damn good software.
and I'd like to see it on my OS X/Linux machines as well.
It's entirely trivial to do on Linux, and I can't see why it wouldn't be similar on OS X. Heck, in most cases, you have to take assertive action to allow users mount and use their own USB devices in the first place.
If not, you can remove the usb-storage driver, or the hotplug config file entry, or the fstab entry, or... etc.
There's too much wastage for every additional session added to a CD -- you wouldn't be able to fit very many votes at all on one.
Anyhow, one of the advantages of the "paper tail in lockbox" proposal is that the paper can be reviewed by the voter (behind glass) before it's approved and fed into the lockbox, whereas there's no way to tell if what's being written to the CD represents your vote accurately or not.
Sure, I can know what JVM bytecodes come out of the compiler -- but I don't (and can't, unless I control the JVM) know what OS-level syscalls and CPU-level instructions that collection of bytecode will evaluate to, and occasionally it matters. The JVM may hide the lower levels most of the time, but it certainly doesn't do so flawlessly.
Practically speaking, I've never had CPU-related issues with Java -- but I *have* had OS-related problems leak through the JVM, and plenty of them. (I'm liable to get more of those than most, though -- I'm "dev support" at my company, a Java shop, meaning I field the toolage problems the developers and the sysadmins can't handle unassisted). Recently, for instance, I ended up debugging an issue revolving around heavily threaded Java code not playing nice on a system with a NPTL-enabled libc but a pre-NPTL kernel; I've also seen more than my share of JNI-related issues, and not a few based on filesystem semantics differences that the JVM's abstractions just couldn't hide.
In short: Targeting the JVM just doesn't give the same low-level control (and, consequently, debugging capabilities) that targeting the OS and CPU does -- but then, you knew that already, right?
Sorry, no slam against Ximian meant -- it's Rasterman's code I've historically had problems with.
Last I knew (~4 years ago), Evolution had some of the ugliest, most unportable code I'd had the misfortune to look upon -- the sort of thing that gives Java coders and their ilk an excuse to look down upon C.
Please, someone -- tell me it's gotten better!
Since when did spammers care about legal limits? Very few of them are on the right side of every "easily enforced legal limit" that applies to them right now, so I hardly see how a few more will make any difference.
Let's say I'm a spammer. Let's say that for every spam I'm getting paid to send out, I send out another advertising a site that isn't paying me and (for that matter) wants nothing to do with me.
Now, how can the ISPs shut down the sites that pay me without also harming hundreds of legitimate sites in the process? Consequently, in order to avoid doing harm to innocents, they'll (presumably) eventually end up canning their plans to cut of service to my customers.
Sure, I'm doubling my costs -- but those are negligible anyhow. Have a solution? (As a non-spammer, I certainly *hope* so).
The thing is, one could take that "my code" comment to the extreme and say that it is no longer "my code" when it is run through a compiler that might optimize it, or, to take it even further, it is no longer "my code" when it is not written in zeros and ones. You're dealing with abstraction wherever you turn, so let's not pretend that intepreters are so different from compilers.
I'll generally have a pretty good feel for what assembly a compiler will spit out when I'm writing C, and if I need to poke into what the Python interpreter is doing under-the-hood (and I *have* needed to do that before), I can. I'm not saying there's a difference between interpreted and compiled languages -- in either case it's sometimes important to have access to the underlying implementation, and in either case (of compiled C or interpreted Python), such access is available.
Compare to Java.
First, I'll grant you that the 85th-percentile parser rule needs to be relaxed -- but I'm still inclined to hold that there's a grain of truth in there, as the percentage of the language rules that (for instance) an 85th-percentile C programmer knows is assuredly greater than the percentage known by an 85th-percentile Perl coder. In any event, that's a side issue -- it's just my own, personal guideline -- while the core issue is what languages are suitable for Real World (which, to me, is commercial) software development.
English is also a TIMTOWTDI language, yet nobody disputes that it's a good thing when it comes to English, because when we use English, we want to be expressive, not uniform. If you are a good writer, having options gives you the flexibility to choose what works for your given situation.
Yes, but one rarely has a team of 30 (or even 5) people working on a novel, with the expectation that that novel will be handed off to a set of different authors with completely different backgrounds to write extended versions later. Commercial software development has different requirements than writing novels -- and some of these involve containing the damage that is done by people who aren't good writers, as I've gone into in my parent post.
I need to go in to work now, so pardon if I'm leaving some threads unanswered.
You're attacking a strawman.
Sometimes I want to know, as I'm writing my code, exactly what low-level operations will occur when that code gets run. My code, not the libraries I'm calling. Java doesn't even let me do that.
It's a pretty rare "sometimes", though -- I don't do so much low-level work these days. As far as the why of the matter, I think someone wrote a paper about leaky abstractions that explains it pretty well.
I just don't get the recent animosity towards perl. It's honestly one of the most powerful languages I've used. The unreadable code argument falls apart when you've seen some of the COMPLEATLY unreadable Java, Python, Lisp (although I personally think that language is unreadable by design) code I've seen. Any language can and will be abused.
Yes, but Perl is worse than the others, simply because the language spec itself has so many rules and edge cases that nobody can ever remember them all. (Putting regular expressions into the syntax rather than the standard library is, IMHO, one of the major mistakes along these lines). Here's a test I use to determine whether a language syntax is too complex: Can an 85th-percentile coder write a parser for it from memory?
TIMTOWTDI is a liability more than an asset: It means that no two skilled Perl coders will ever write the same solution, whereas two good Python coders (who are fully familiar with the standard library, available language features, etc) are much more likely to write similar code. As anyone who's actually worked on a large team (in which code is passed around between team members, inherited from those who leave or are fired[1], and otherwise has "ownership" as only a transient idea) can attest, consistancy is good. There are plenty of documents published about The Right Way to do a given thing in Java; likewise, Python has a consistent philosophy that it nudges everyone towards by design. Perl? A bloody mismash.
[1] - Bad Java, like bad Python, is typically bad by design -- it's not just that the implementation itself has no-op error handling or uses a ridiculously inefficient algorithm, but the actual internal interfaces are broken and wrong. In a corporate setting where interfaces are reviewed by someone known to be competant before they're implemented, this kind of evil can be contained -- so the problems that remain are implementation level, where the very strictness you complain "punishes the programmer" lets components be swapped out with sanely-written replacements one by one. I suppose you also think that policies requiring everyone to implement unit tests punish the folks who get their code right the first time?
Wrong level.
Sure, it's easy to tell how your Java code operates within the bounds of the JVM. However, it's basically impossible to know how your Java code maps to actual syscalls (and similar low-level operations), in no small part because this varies by JVM implementation. For most people, this is fine -- the JVM is a black box, put bytecode in, get correct output out.
It's not fine for everyone, though. The fellow you're replying to is onesuch, and he has a valid point.
And yes, you are full of bull shit. Just because you don't like his lic. does not mean that it's not distributable and such. Get a life.
No, it's not because I don't like the license -- it's because he never grants a license at all permitting uses beyond those unregulated by copyright law. I have a life -- a good chunk of it belongs to a small startup that needs to be sure that its software redistribution practices are fully legal.
Sitting around on slashdot, trolling folks with blatant lies (ie. "it has a BSD lic") and insulting those who correct you -- that is having no life.
So? Just because someone else is doing doesn't mean that it's okay for me to.
(1) They may be operating without a license, and DJB has simply not chosen to stop them.
(2) DJB may have chosen to grant them special dispensation to redistribute, without providing a general license to the public at large.
Oh, really?
What license to redistribute does he grant? Where is it? What are the terms?
Can I redistribute binaries? Show me the document that says that I can -- otherwisee, it's unusable for my employer's (and thus, my) purposes.
Go on, I'm waiting.
People wouldn't be reimplementing DJB's tools under less restrictive licensing (BSD in the case of ipsvd and runit, GPL in the case of libowfat) if he used a reasonable license in the first place, instead of giving out his software with no license to redistribute whatsoever.
I'm using runit rather than daemontools at work because we can't comply with DJB's non-license. Please be a bit more careful before calling bullshit.