| |||||||||||||
Shuttleworth: Quality has a new nameShuttleworth: Quality has a new namePosted Apr 24, 2012 20:04 UTC (Tue) by misc (subscriber, #73730)In reply to: Shuttleworth: Quality has a new name by jspaleta Parent article: Shuttleworth: Quality has a new name
It doesn't seems so for apache
http://packages.ubuntu.com/precise/amd64/apache2.2-common...
but there is for ssh :
Upstart jobs are stored in /etc/init/. There is lots of them on a lucid lynx system :
But that's mostly replacement for the old /etc/rcS.d/ system.
In fact, the real issues is not "using upstart vs using systemd".
Switching to systemd is not just a upgrade when coming from upstart, since you cannot just replace upstart jobs by systemd jobs. So I can see why the Ubuntu team thought it would not be worth. They seems to have suffered from switching ( http://undacuvabrutha.wordpress.com/2011/04/29/why-ubuntu... ). So I can see why they prefer to focus their resources to more differentiating features than a init system.
I do not think this will be a huge burden on Canonical since Google also use it and they have enough people to take care of that.
(Log in to post comments)
Shuttleworth: Quality has a new name Posted Apr 24, 2012 21:33 UTC (Tue) by HelloWorld (guest, #56129) [Link]
> Switching to systemd is not just a upgrade when coming from upstart, since you cannot just replace upstart jobs by systemd jobs.
systemd units for most interesting services have already been written, and writing them isn't even difficult. So I doubt that this would be a major problem.
Shuttleworth: Quality has a new name Posted Apr 24, 2012 22:42 UTC (Tue) by rahvin (subscriber, #16953) [Link]
This is the price Canonical pays for being the first to the party. They were the first (distro) to jump head first into upstart, now that the rest of the community is reworking upstart into systemd they are given the option to either convert and spend the resources twice or to hang on and handle the old code problem. That's the risk of being an early adopter. They're choosing the wrong option in my opinion, I agree with Pottering that they are going to be stuck maintaining a bunch of code like udev that they've never planned or budgeted for and will likely result in total stagnation for them.
If they are counting on Google pulling the weight they are making a mistake (unless they have intimate knowledge of Google's plans that is). Because IMO trusting Google to do anything is asking for trouble. They've got to be the most bi-polar company in existence. The only part of their business that's consistently the same is the advertising arm (and we don't see the internal on that so it could be equally troublesome as the rest). Personally I'm not sure how I would bet on a wager of Google throwing out all previous work and starting over in some radically different direction.
|
|||||||||||||