"Lennart Sorensen" <lsore...@csclub.uwaterloo.ca> writes: > On Fri, Feb 01, 2013 at 12:38:16PM -0800, Russ Allbery wrote:
>> I hope that's not generally true, because that would be horribly >> depressing. I don't believe that's true of the Perl community in >> general. It's certainly not true of the C or Java community! > Not all C libraries are distributed from one central site and they > certainly don't expect you to use a central package installation system. So much more the shame for C. Those are *improvements* that Perl came up with (well, actually, that the TeX community came up with and Perl copied) that made the ecosystem much nicer. > I personally consider Java a bad joke that won't go away. Look, if other people like something and use it heavily, that's probably because it solves their problems. Saying that it doesn't solve *your* problems, or even that it creates problems for you, does not change the fact that it solves *their* problems. I have some personal experience with Java on both the systems administration side and on the developer side. It's an awful language for deployment, and it's a great language to write code in, with an incredibly rich ecosystem of well-tested and reliable components for nearly anything you'd want to do. In particular, it is far better at APIs and code boundaries than Perl is, and therefore scales to large teams of developers more naturally and more easily than Perl does. And I say this as someone who loves Perl and maintains core Perl modules. The same Java infrastructure that makes it so incredibly painful to construct a consistent system with separated and separately-upgradable parts makes it a wonderful system in which to develop and to create applications with reliably consistent behavior. Particularly if, as is the case in a depressing number of environments, the system administrators are in some other group from the developers, they're not allowed to coordinate, and the system administrators have all sorts of rules and restrictions the developers have to go through to update anything in production. You talk about reproducible systems as one of your primary goals. Well, that's exactly why Java does those things that make it such a pain in a Debian context. If you bundle together all the exact JARs that were tested and known to work and don't change any of them, you get exactly that: a reproducible system that works exactly like it did in the test environment. You of course also have a system that has some real problems when it comes time to do security upgrades, and one that tends to be very difficult to upgrade to the latest version of the JARs when you need some new feature. But those are *tradeoffs*. That is not an absolute flaw in Java. The flaws in Java are more obvious in a devops environment. Most sites aren't devops. If you're in a traditional "develop, test, and throw it over the fence to the production guys" shop, Java's ability to roll up your application into one file that is completely self-contained is a *godsend*. You may feel that all non-devops shops should get the religion. I'd even agree with you. But all the stuff we're talking about are artifacts that exist in the real world and have to deal with how that world currently works, not how we want it to work at some theoretical point in the future. > If I want something updated that is newer than what debian provides, > then I will make the .deb myself. I want everything consistently > installed. Sure. Me too. I've also been making Debian packages for years, so this is a matter of an hour or two of work, or less if I don't care about doing it properly. > I like my system to stay working and maintainable. I still have one > system that was installed with Debian 2.1, and upgraded ever since and > is still doing fine. You don't generally get there by taking shortcuts > that seem convinient now, even though long term they are a bad idea. Sure. I have that religion too. The other way that you don't get to having a system that's been continuously upgraded from Debian 2.1 is if you got fired somewhere around Debian 3 because you couldn't deploy things fast enough for your boss, who didn't give a shit about whether things were in Debian packages or not. Tradeoffs. > Making a debian package is generally very easy, so if you need something > on your system, make a package for it. I would love this to be the case. It just isn't. *I* find it easy. I know lots of other people who find it easy. And, in fact, we make doing this mandatory within my group. But because we made it mandatory, I've trained a lot of sysadmins and developers in how to do this. I've seen the problems they ran into, I've helped them out of blind corners, I've cleaned up some of the messes, and I've helped them find better tools. It's not easy. It's really not easy for quite a few people. I do think it pays off in the long run. If one has the luxury of a long run, teaching people proper packaging is great. In the short run, for at least the first few packages people make, it is almost certainly the case that they would have gotten their problem solved and their system deployed much faster if they had not tried to make a proper package. I'm a long-run guy too. I love to focus on the long run. But it's a luxury and a privilege to be able to do that. Projects, deadlines, and management priorities normally don't much care about the long run. That's something that we often have to teach the people who are pushing to get something done, and sometimes that sticks, and sometimes that doesn't. As upstream, I want my software to feel right, to feel elegant and comfortable, to people who want to take the long-run approach and do things right. But I also want my software to be usable by people who have a crash project that has to be done by tomorrow and who are reaching desperately for my software because it does something that's mandatory for that project and they don't have time to figure out another way to do it. If that means that using cpan install gets them working software faster, then three cheers for cpan install! > For cpan there is even dh-make-perl. The solution then is to make > equivelant scripts for other languages. The solution is NOT to use some > other package installation system. dh-make-perl is great, don't get me wrong, but the problem with this sort of automation is that it works 90% of the time and then 10% of the time there's some weird oddity or corner case. And if you don't know anything about Debian packaging and you don't know how any of the pieces work, if you only know how to use the automated tool, then when you hit that 10% case, you are completely lost. That's a demoralizing place to be. That's when people switch back to cpan install, which is a rather thinner wrapper around a bunch of commands one can run manually, and which the upstream whose code you're trying to deploy probably already understands and can help you with. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/> -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/874nhvpvx2....@windlord.stanford.edu
