| 1 |
On Mar 18, 2012 9:44 AM, "Joshua Murphy" <poisonbl@×××××.com> wrote: |
| 2 |
> |
| 3 |
> On Sat, Mar 17, 2012 at 10:12 PM, Nikos Chantziaras <realnc@×××××.com> |
| 4 |
wrote: |
| 5 |
> > On 18/03/12 03:45, Canek Peláez Valdés wrote: |
| 6 |
> >> |
| 7 |
> <snip> |
| 8 |
> >> [...] |
| 9 |
> >> |
| 10 |
> >> * It tries to unify Linux behaviour among distros (some can argue that |
| 11 |
> >> this is a bad thing): Using systemd, the same |
| 12 |
> >> configurations/techniques work the same in every distribution. No more |
| 13 |
> >> need to learn /etc/conf.d, /etc/sysconfig, /etc/default hacks by |
| 14 |
> >> different distros. |
| 15 |
> > |
| 16 |
> > |
| 17 |
> > Out of the things you listed, this strikes me as the most important. |
| 18 |
Linux |
| 19 |
> > really needs standards. When I install software on Windows, it knows |
| 20 |
how to |
| 21 |
> > add its startup services. On Linux, this is all manual work if your |
| 22 |
distro |
| 23 |
> > isn't supported, especially on Gentoo. If there's no ebuild for it, you |
| 24 |
> > spend your whole day trying to make it work. |
| 25 |
> > |
| 26 |
> > |
| 27 |
> |
| 28 |
> My day job's on the windows side of things... and as true as it is |
| 29 |
> that the application developer knows the approach they're going to use |
| 30 |
> today to get their piece of software to start when windows does (as |
| 31 |
> often as not, doing so without the knowledge of the user), there's a |
| 32 |
> *massive* range of ways to do just that, and they *do* vary as you |
| 33 |
> move from one version of windows to the next... and tracking down |
| 34 |
> what's actually starting at boot (and why) without tools explicitly |
| 35 |
> created to give that information is an incredible amount of work on |
| 36 |
> the side of the user and even the usual admin. I'm not sure I'd cite |
| 37 |
> that as a positive benefit on the windows side of things... |
| 38 |
> |
| 39 |
|
| 40 |
True, that. |
| 41 |
|
| 42 |
Case in point : a couple of months back, I had great trouble trying to |
| 43 |
start the server service *after* the iSCSI service. Finally have to resort |
| 44 |
on a script starting using Windows Scheduler (post-boot event) |
| 45 |
|
| 46 |
On Linux, I *know* where services are started. The locations might be |
| 47 |
different from one distro to another, but within one distro, there's |
| 48 |
(usually) only 2 ways a service get started. |
| 49 |
|
| 50 |
Plus, as a server guy, I don't really care if the boot up process is |
| 51 |
faster; I need deterministic boot process, with as succinct instrumentation |
| 52 |
as possible. |
| 53 |
|
| 54 |
Rgds, |
Archives