User: Password:
|
|
Subscribe / Log in / New account

Bazaar on the slow track

Bazaar on the slow track

Posted Sep 13, 2012 21:15 UTC (Thu) by zooko (guest, #2589)
In reply to: Bazaar on the slow track by dlang
Parent article: Bazaar on the slow track

bzr predated git just as upstart predated systemd. Now, maybe one could argue that, having already paid the cost of creating bzr, Canonical should be quicker to cut its losses and switch to git, but that's a lot different from accusing them of unnecessarily creating an alternative. bzr and upstart were first!


(Log in to post comments)

Bazaar on the slow track

Posted Sep 14, 2012 14:30 UTC (Fri) by smurf (subscriber, #17840) [Link]

I didn't say that Canonical were not first w/ bazaar and upstart (if my wording implied that, this was not my intent). At least not in absolute terms.

But you need to look at the actual use cases.

Take git. Linus developed the thing for the kernel. git supported *large* source repositories quite well, right from the start. All the others were "OK it works for ten files and ten revisions, I'm done with the basics. 10000 files and 1000 revisions? Oops, need to take our lunch break now, hopefully it'll be done when I get back." So git was the first DVCS that aktually worked for the "impatioen kernel developer" use case.

Or take systemd. Init's job, as Lennart has shown, isn't done after starting jobs: reliably discovering when a job has *stopped*, and hopefully not interrupting the service it provides while restarting it, is a worthwhile goal too.
Compared to upstart, sysv-init is good enough for me -- so why bother to switch to it? Compared to systemd, it no longer is. Conclusion: all my systems now boot with systemd. It's not the first init replacement out there, but it's the first worth switching to if you've done it the "/etc/init.d/foo start" way for the last 20 years (which, surprise, continues to work just fine with Debian's systemd).

I am not the only person out there who has written a whole bunch of software (some of whichtook a significant heap of my time+effort+money), which was "good enough" -- but then somebody else took a look at it, said "cool, but I can do better", did better -- and shared their code with me. So why should I not toss my code into the Great Bitbucket in the Sky, and use theirs (and then improve *that* instead of playing catch-up)?

I'm not going to let my ego get in the way of getting things done. Life's too short for that.

Bazaar on the slow track

Posted Sep 14, 2012 14:51 UTC (Fri) by paulj (subscriber, #341) [Link]

Init's job, as Lennart has shown, isn't done after starting jobs: reliably discovering when a job has *stopped*, and hopefully not interrupting the service it provides while restarting it, is a worthwhile goal too.

Though, there's no pressing reason why that job must be done by init…

Bazaar on the slow track

Posted Sep 14, 2012 16:23 UTC (Fri) by apoelstra (subscriber, #75205) [Link]

> Though, there's no pressing reason why that job must be done by init…

Well, init is the job's parent, so it's uniquely positioned to notice when a job crashes -- and since init started the job, it's also uniquely qualified to /re/start it.

Bazaar on the slow track

Posted Sep 14, 2012 17:51 UTC (Fri) by paulj (subscriber, #341) [Link]

Well, no, you can trivially have other process managers in between init and your service processes. You could have one that was dedicated to network services, hey it could even handle opening the sockets, watching them and only launching the actual services if there was activity (sound familiar?). You could have another that was specialised to watch TTY lines (Novell UnixWare had one of those I think). You could have another one for whatever.

Or you can have a kitchen-sink system, where you put all this into init, and it has to support every possible need any kind of service will ever have.

Bazaar on the slow track

Posted Sep 14, 2012 18:27 UTC (Fri) by bronson (subscriber, #4806) [Link]

Oo, hey! A micro vs. monolithic argument! Let's all voice our meaningless opinions.

Bazaar on the slow track

Posted Sep 14, 2012 20:07 UTC (Fri) by paulj (subscriber, #341) [Link]

FWIW, I'm not taking a side. Just noting that both ways are possible. :)

Bazaar on the slow track

Posted Sep 16, 2012 3:16 UTC (Sun) by bronson (subscriber, #4806) [Link]

Oh, ok. Can't disagree with that!

QotW material

Posted Sep 18, 2012 22:04 UTC (Tue) by man_ls (guest, #15091) [Link]

I would like to nominate your comment for "Quote of the week" for distributions, if it is not too late. It is sarcastic, it has the LOL factor, and it is true as life.

Bazaar on the slow track

Posted Sep 17, 2012 9:11 UTC (Mon) by pboddie (guest, #50784) [Link]

Take git. Linus developed the thing for the kernel. git supported *large* source repositories quite well, right from the start. All the others were "OK it works for ten files and ten revisions, I'm done with the basics. 10000 files and 1000 revisions? Oops, need to take our lunch break now, hopefully it'll be done when I get back."

I'm pretty sure Mercurial was developed for working with the kernel sources.


Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds