Le 08.11.2013 12:55, Marko Randjelovic a écrit :
On Sun, 3 Nov 2013 14:33:27 +0000 Jonathan Dowland <jmtd@debian.org> wrote:On Sun, Nov 03, 2013 at 10:23:02AM +0100, Marko Randjelovic wrote:> I find shell scripts the most efficient way to automate system adin> tasks. It could be because I am a programmer, but at least init> scripts are already provided, and small modifications should not be a > problem even for non-programmers. For new scripts you have 'skeleton'> file that can be easily adjusted for a particular work. Amongst other problems, how do you (or the package system) reconcile when you have made a local modification to an init script and the upstream package has made another in an update?It depends, but if you could do it then I don't see why couldn't you doanything that is needed later. Besides, configuration files can also change, just like init scripts. A don't have a feeling that upstart/systemd configuration is so simple (not so much about syntax, I was looking at their documentation and there are things such as 'events' and such things have to be properly defined), so it can also make problems, not just change in init scripts.
The point here was probably that maintaining a "patch-fork" implies lot of work ( by "patch-fork" I mean that you try to stay as close as possible to upstream's versions but you keep a set of patches ) when time goes on, because those patches becomes harder and harder to maintain, since upstream's code changes might imply reworking your patch set, piece after piece.
> There is nothing more standard/portable in Unix-like systems then > POSIX shell.…which wasn't fully supported on Solaris 9 so you had to use a subset(e.g. no $(subshell) syntax). Writing truly portable shell scripts across multiple UNIX families was a terrible pain and one could not simply rely on the POSIX feature-set. I know this from bitter experience. I suspect C89 is/was more portable in practice, but the point OP ismaking here isn't the scripting language, for portability, it's the factinit scripts do little to abstract the differences between OSes, so portable init scripts are very hard to achieve. E.g. Debian uses /etc/default for overrides, Redhat-esque systems use various schemes under /etc/sysconfig;We are talking about Debian init system. init scripts do not need to support Red Hat because they are on systemd
But if it was possible, it would be nice, do not you think so?Not reinventing the wheel without reasons is a noble objective for me. ( Learning how to do the wheel, or trying to make it lighter or faster are two good reasons to reinvent the wheel anyway, but they are not the most frequent ones )
That's what systemd offers.
and Solaris is not a Linux distro and it's not realistic to expect scripts could be portable between Debian and Solaris.
Debian is not only a linux distribution, it is a free software operating systems which can use the linux kernel. So, having script compatible across kernels ( you said solaris is not a linux distribution, so I thought you only mean it does not uses the linux kernel, nothing less and nothing more ) would be useful. And I think it is doable, if those scripts are really specialized in doing one and only one thing, relying on script libraries to do lower level things. Another thing needed to make something portable is to remove hard-coded data from the main program, being by moving them in other, specialized scripts, or in configuration files. Unfortunately, doing so makes things slower to have something which really works (but easier to maintain indeed) so it is rarely done. And I do think that script writers does it more rarely than software writers ( in the average, of course, and I have no data other than my feeling on that topic ).
> I don't think UNIX philosophy is not so important. First of all, the> principle of all-might is by nature authoritarian. All-in-one> "solutions" are a characteristic of big companies that want to impress> their users, while not giving them enough real benefit.It's a principle near and dear to much of the rest of our F/OSS stack,however. The Linux kernel is monolithic (and enormous) rather than a microkernel. GLibc is enormous rather than a family of smaller libraries. And so on.I agree with it, but it's because people choose to join existing projects instead of to start a new one. We are lacking entrepreneur spirit :) .
I do not think so.My opinion is that the problem is the lack of fixed and clear objectives, so new features are added which are in the vague borders. Doing so often extends those vague borders. You probably already have seen a pretty good software becoming a memory black hole by time when features where added one after the other: that's what I am talking about, and it is not a open-source-only issue. There is also the problem that current developers usually likes to use only one library to do everything ( calling it a framework ) like Qt or .NET. I can find some excuses for that, but no valid ones. One of them is that it allows to not have to worry about collision names ( but seriously, with good libraries using namespaces - or a substitute for C since it does not support them - this is very unlikely to happen ), or having less search to do to find what library to choose ( but is not the choice of softwares a strong advantage of free operating systems? ). Using frameworks which does everything encourages people to build softwares which does everything. Since frameworks are a kind of software, we are in a vicious circle, imo.
This probably does not apply for the kernel, of course ( the things I wrote about frameworks at least ), but I have a complete lack of comprehension about how a kernel can be designed. The only non-monolithic one I know about is Hurd, and I have never read about it being something one can really use. But maybe it is ok for day to day activities: writing pieces of code, browsing the web and some playing is not necessarily something which needs a lot of stability. In the past, windows proved it :p