Agree. That said, I think that the situation you describes is not specific to./.
I learned that perception of the reality in only a single possibility among a large number of biased perceptions, and it's hard to have a complete and actuate perception anyway. So discussion is required to agree on a common perception, but some comments did not help going in that direction.
Can make a big difference between projects. For example LibreOffice was forked from OpenOffice because to much potential contributors was frustrated by the way the OpenOffice maintainers was with them in the past. The libav fork from libFFmpeg was also a way to solve different way of maintaining the project at some point in time. And I am certain that there is a lot of others examples.
There nothing wrong with this process. Better having two peaceful projects than a single one with frustration against it.
8) Yes there is kind of language barrier as I usually speak French. Now the fact that you react with so much emotions and use rhetorical question don't help either our mutual understanding.
We obviously have each confidence in a different model of what the architecture of a distribution must look like. Probably that the use case we assume each for our analysis are very different too, and that could explain why we have some contradictions. If for you the shell very important, for me this is not the case.
3) I don't want to open an other conflict but I do observe that the leading Linux distributions make effort to make users able to manage there machine as much as possible without required to display a shell to the users. This story is about Ubuntu first release with systemd, a distribution that is popular for peoples that have no clue about the shell. On this distribution a typical user will let NetworkManager try to configure the network automatically as much as possible, and if a manual setting is to be enter, the user most likely will do it using the NetworkManager GUI. The Arch procedure you looked at is hard to fit in the same users context.
6) I don't think that Linux try to adhere to the opposite of the 'unix philosophy' and I don't observe that shell scripts play an important role in unix outside of the stack on top of system V init. After all, a lot of unix tools are written in C. I also don't think that the distributions make futile and stupid choice especially regarding the challenge of the experience there try to give to users without any shell knowledge.
7) I referred to you text: "the one Linux server that we do have (for automated installation of the desktops, nightly maintenance etc) needs more hand-holding than basically the remaining two dozen BSD servers need combined." I still wonder why you use Linux for this particular task if Linux cause so much problem for you and that you are happy with BSD.
1) So you admit to have purposely chosen the procedure that use shell scripts only to complain that it, err... use 2 shell scripts???
2) Diversity is an advantage up to the point where the added complexity is not too big. Sometimes it better to normalize to a common parts to simplify.
3) While making a good an complete enough GUI is fare from simple, this don't imply that this is impossible. NetworkManager is now mature enough to be used in a very large use case. This is the primary user interface for a lot of users. Most of them don't have a clue about shell script, so it's impossible to say to them that a shell script is there primary user interface. This is very factual: nor users, nor NetworkManager use script. I can only concede that commands in a shell (no script) are a possible fallback solution in case of problem impossible to solve with the GUI. But I disagree that a possible fallback that most users will never use is defined as a primary user interface.
6) Linux is not so UNIX anymore in the sense that it integrate more and more features compared than any others UNIX kernel. More and more Linux syscalls are not related to any UNIX standards. This is a new world emerging from UNIX but not bound to it anymore. Goodbye to anyone that like to stay with the UNIX way. This can make a lot of sens for some situations, and nobody will prevent them to do so. This is there respectable choice, and there could make an effort to respect the choice of others that want to follow the Linux way, unbound to the UNIX limitations. udev and systemd are required evolution steps to solve problems that have found no better solution using the UNIX traditional way.
7) Then I don't understand why you still use a Linux machine if BSD is so better for you. Really strange that your uptime is so small. I usually only reboot for hardware maintenance. One of the Linux servers actually show a uptime of 2121 days has soft RAID-1 and several virtual machines running on it. I plan to change it this year because some hardware parts are over 10 years old, but from the software point of view it run just fine.
1) This is my definition is the context of this discussion. If you don't like it we can agree to name it differently. This will not change the reality that the procedure you mentioned did not use the usual infrastructure found on distribution to setup a static IP address.
2) Fine that we agree on this. But system V init in a C code that do exec(). The fact that it's usually a script is not required by system V init. But the main problem is not really script vs binary, the main problem is precisely the lack of normalization because anything on top of the bare minimal original system V init code is distribution specific.
3) The fact is that on most leading modern Linux distribution, this is not a script that call a command that setup the IP address of a network interface, because there use the NetworkManager package. Again you might not like it, but this will not change this reality. If you think that I don't understand your point, please try a least to repeat it. Actually you only deny some point.
4) Certainly not the system administrator according to http://training.linuxfoundatio... . I don't see the point calling a user system administrator regarding network operation when there simply let the dhcp client automatically configure an interface. Nor in the case where there select a SSID and enter a key. Nor when there use the NetworkManager GUI to select the Manual method on the IPv4 tab of an interface. In all those examples there is no scripts and no command involved.
5) It's perfectly possible to manage a very large number network situations with NetworkManager GUI without using any shell, script, or command. This is the primary interface for most of the users, including myself, even after working for years in a company that build routers. As a side note, this kind of GUI was all the customers constantly asked for, liked and used. Only the engineer and support used command to verify the state of the system. In the embedded systems I build today, the customer ask to configure the network from a web UI that push the configuration on a SQL database on the target, to illustrate how far is you idea of script and command.
6) Agree on the fact that scripts cover a more generic knowledge. Sadly this is not so useful on a system that use less and less scripts. I understand that you regret this evolution, but as the complexity of the system increase, scripts that are different in each distributions have reach a limit for many maintainers. Thing could have been different if the original system V init package would have normalized the script stack early. There failed to do that, now the time is probably over for them as systemd not only normalize the situation across the distributions but also bring a lot of new features on the table.
7) I wonder what's your work environment to be exposed to such 'shitstorm'. I have see time to time worker having to ask there superior to have the right to install a Linux system, but I never see the network administrator complaining.
8) All the last points is to show that your laugh are strange because all points can be independently verified true. There is no rhetorical nature in any of them, this is just a list of facts.
I manage multiple projects, once per line of virtual desktop except for the top line where I have all the social applications, general browsing, music, and unrelated stuff. On a typical project line I have desktop with the documentation, the schematics, the routing, the source code, the compilation, the console on the target, usually multiple times when there are more than on application to do. Some project have multiples machines involved and to be monitored. There a document to fill for the client, there are some experiment to do. This quickly take a lot of windows and desktops.
Now why did I not close the windows as soon as I don't need them and re-open them when required? Because I can simply just leave them as there are without any problem. If I have an idea on a project I can check it very quickly. If someone ask something about a project I just have to switch to the related virtual desktop where I will find the windows arranged in there usual way with documentation ready to be read, code ready to be edited and console connected to the target ready to take input.
In this situation, I really don't like to close my session or reboot. I need a system as stable as possible. I rebooted about 3 months ago to install a GPU, but I remember having passed a full year without any reboot.
1) What's wrong calling a helper script a script that help you to do something in a more simple way? Now if it's not from you the script came from something else. In the context of this discussion this is from the distribution.
3) The problem is to configure an interface automatically when the system boot. In most distribution the users don't even have to use the real command to setup the interface to do this. And you are completely wrong about your ifconfig and script theory: the vast majority of network interfaces are today setup by a dhcp client, or an application like NetworkManager according to DBUS messages coming for example from a GUI application, all written in C or C++, or maybe something other, but for certain shell scripts play a marginal role here. The shell is NOT the primary interface for the vast majority of the users, sysadmin is not the dominant specie in the Linux world.
4) Systemd is really simpler to learn that shell script. I switched some months ago to systemd and found all the documentation is needed in the usual man pages. I took me less than 1 hour to learn the basic commands and I was able to convert the custom part of the system less than one day.
5) You can laugh as you want, this will not change the reality: * Sysadmins are a minority of Linux users. * Distributions like Debian support/etc/network/interfaces with systemd. * There are sysadmin already using systemd. * To date there is no enough maintainers against systemd to have successfully make an serious alternative available and ready to use by the distribution. * Systemd transition is now done by Fedora, Ubuntu and Debian and there are still there. * Still, a lot of forum get post from 'sysadmin' complaining.
1) The procedure you mentioned precisely do not use any helper script. This why it take 4 files
...two of which are helper scripts...
No, by definition helper scripts must already be part of the distribution.
, exactly the same amount of file on system V init.
Not quite, but whatever.
Exactly the same amount, if you don't use the system V init helper scripts.
2) The/usr/local/bin/net-up.sh and/usr/local/bin/net-down.sh are absolutely not related to systemd at all. You will use exactly the same scripts with system V init if you don't use helper scripts.
...except for those two helper scripts, yes... They are/not/ required in sysvinit. There's nothing to stop you from doing something like that on system V, but the canonical way would be to do that in the init script.
At least you recognize that (almost) the same procedure will apply to system V init if someone don't want to use his helper script. Please understand that the normal way to configure a simple static IP address with systemd is to use either systemd-networkd or the distribution specific file to do this like/etc/network/interfaces in Debian.
So regarless of whether the helper scripts are an unrelated or an integral part of systemd, using systemd in Arch for the highly complex use-case "static IP address" apparently means one way or another, they have to appear. Stop trying to excuse that away.
The fact that Arch Linux don't provides anything is strange. Think what would be the usability of a system V init without all the scripts on top of it. This is not an excuse, others distributions that use systemd simply don't require the procedure you mentioned, and event Arch document how to use systemd-networkd for a simple static IP.
The fact that this 2 scripts use a configuration file is neither relater to systemd.
Sure, there's nothing wrong with a configuration file. What you're trying to say here, not so sure.
Simply: this is not because of systemd.
3) Yes this is pointless to compare systemd over system V init by showing an example that is nothing related to systemd.
I don't even know what to reply to this... odd... statement. I'll grant you the benefit of the doubt and assume you live in some twisted sort of parallel universe where 'nothing related' means 'entirely related' or so..
You have perfectly understand me. You find, maybe by hazard, a very strange and unusual procedure to setup a static IP interface. The procedure use a systemd service file to call two scripts that use a configuration file and you make it a point about claiming that systemd require too complex procedure for a such simple static IP configuration. Now think is you have found the same procedure that use a system V init/etc/init.d/* script to call the very exact same scripts that use the very exact same configuration file, I beat that you will instantaneously found this procedure too complex because you can simply configure a static IP by just edit an already existing configuration file dedicated for this purpose in you distribution of choice.
4) I also claim to have ton of experience in C. From the distribution maintainers point of view, scripts or C applications are exactly the same problem: when there have to fix something, there need to publish a new package
You're missing the point. I wasn't talking about the point of view of distro maintainers, but the case when you, a sysadmin, first encounter a problem with a script or program. Please, with that in mind, reconsider that part of what i wrote
1) The procedure you mentioned precisely do not use any helper script. This why it take 4 files, exactly the same amount of file on system V init.
2) The/usr/local/bin/net-up.sh and/usr/local/bin/net-down.sh are absolutely not related to systemd at all. You will use exactly the same scripts with system V init if you don't use helper scripts. The fact that this 2 scripts use a configuration file is neither relater to systemd.
3) Yes this is pointless to compare systemd over system V init by showing an example that is nothing related to systemd.
4) I also claim to have ton of experience in C. From the distribution maintainers point of view, scripts or C applications are exactly the same problem: when there have to fix something, there need to publish a new package, the fact that it require a compilation is a detail, especially given how ubiquitous is a C compiler on a maintainer machine. Well written scripts or C applications must log debug messages to help tracing problems. Now take a look at the reality: there is very few scripts that are well written, mainly because the authors assume that it's easy to read the script. On the contrary many C applications a well written because the authors know that the users will have nothing to show in case of a problem. The 'set -x' is not a magic trick that allow to find any problem a stack of scripts might have. The dependencies problem of the init scripts is one of them.
5) Because I usually wrote French and in that language we put a whitespace in front of question marks. I did not notice that it's not the same in English. http://fr.wikipedia.org/wiki/P...
The evolution from FVWM/FVWM95/IceWM/Scwm/Sawfish (in my case) to Metacity was a big progress because The windows management API goes normalized and was separated from all the others goodies provided by a desktop. At this time Gnome 2 was a superb improvement (KDE too) for the users without losing really used features from the previous projects. XFCE, MATE and Cinnamon continue on this track, with some success. Gnome 3 WM Mutter was a different kind of evolution, more like an experimental project. There nothing wrong to try experiment, but closing Gnome 2 WM Metacity project so early was a bad choice. The most obvious prove of this is the fact that the developers of Mutter ported Metacity to GTK3+ instead of adding Metacity features into Mutter: http://ftp.gnome.org/pub/GNOME...
From my point of view, Metacity should have been ported to GTK3+/Gnome 3, first and then Mutter could have started as a new experiment, not the contrary. The actual situation is just the natural correction of this error that have taken a lot too much attention than if it was done the right way.
Debian Jessie, just released, is AFAIK the first leading distribution that allow to select the desktop of choice directly from the installer. This is a welcome move, because before, yes some user like me did't have so much choice, unless you install manually a desktop (hard to do), or switch to an other distribution (I use Mint on a laptop). Part of the problem is that XFCE and MATE take some years to get the high quality there provides today. What's interesting is that XFCE and MATE have get this quality precisely because so many peoples was frustrated with the Gnome 3 experience.
The way the Gnome project managed the transition will stay for long as an example of bad practice. The main error was to abandon the Gnome 2 code while the code Gnome 3 did not allow most of the users to make the transition based on there own motivation because at some point there will found that Gnome 3 is better. The reality is still that Gnome 3 did not reach this point for enough users that the venerable XFCE project gain support like never before and the MATE project started from the abandoned Gnome 2 code.
And there is the Cinnamon project that try to bring the MATE feature on a Gnome 3 base. All of this show how much frustration the Gnome 3 project have created early. Now the situation is far better and in a near future I beat that the winning project will be the one that will be the fastest to integrate in a nice way the beast features of all the projects. I suspect that Gnome 3 is not in a good condition to win the race, as his evolution since a couple of years in anemic compared to MATE for example.
I also found Gnome 3 a bad choice for my use, but Debian Jessie is the first release to propose a lot of alternative directly from the installer, so regarding this subject I found it a improvement compared to the previous release. I personally will select MATE instead of Gnome 3.
The systemd transition is an other subject. I personally found it preferable to the stack of scripts on top of system V init. Ok it require to learn something new, but the basic is very simple and most of the stuff need just a bit of practice. I don't think that the alternatives of systemd will be in position to stay competitive for long, as the architectural change bring a too much advantages to maintainers that do the real work.
I have multiples machines, each with a different Desktop: Gnome 3, Unity, XFCE and MATE.
My biggest problem with Gnome 3 is the fact it's not designed to work well with multiple windows overlapping and spread on a lot of virtual desktops. I usually have more than 100 windows on about 40 virtual desktops. This kind of use is a nightmare with Gnome 3 or Unity because the respective position of the virtual desktops change dynamically so it's impossible to map in the brain. The second problem is the upper left corner switch that place each widows in a random order impossible to memorize, so totally useless for me. The next problem is the animations and effect that make everything slow and distracting. The next problem is the panel extension that are difficult to select because of big catalog of similar entries, and rarely a good quality both in term of usability and in term of look. Finally the menu really hurt on big screen like 4K because it open from the left of the screen but the sub-menus are on the right of the screen. This menu take so much place that it require a lot of mouse translation to do almost anything. Whats totally ridicule is that even by displaying so few items on a 4K screen, this menu is not even able to display the full name of all application because it truncate it to the size of the icon. So no, I really don't like Gnome 3 (and Unity that share a lot of same bad design).
XFCE and MATE are extremely efficient and blazing fast for my use case. There make easy to map in my brain the respective position of a lot of virtual desktops. The panel widget are coherent and easy to select in a small list of entries but with a lot of features of each entries. The menu is the most simplest possible, but display the full name of all the applications, require a minimum of space so it's fast to use with the mouse and is easy to customize. No animation, no effect, just maximal speed. Finally there perfectly scale on a 4K screen without any disadvantage. And i like the windows tab menu with a useful text into each tab describing precisely what's is in each related window.
Put simply, Gnome 3 idea is big graphic and small or no text. What I need is small icon and a lot of text.
I was pointing out that I'm more than qualified to do so (and I didn't even put in any of the Microsoft systems stuff, nor the hardware design)
I can pretend to be equally qualified than you. You don't impress me, nor you add credit to your recommendations.
secondly, I can't be bothered either recovering the old accounts (email addresses - even servers, associated with them are long gone, figments of history..)
How can I trust your recommendations if you are not even able to administrate your very own accounts ?
Because, unlike the accounts I have kept going for a long time (e.g. the email address I've had for 22 years) these accounts are trivial/transient..the universe didn't ouzelum the day I could no longer log in using any of them, there was not a wailing and gnashing of teeth.. There's this thing called 'sense of proportion'.
So if it's not proportional enough, why did you mention it is the first place ?
Maybe there is a reason why you find any leading modern Linux distribution too complicated for you.
Oh, for sure...leading...modern..complicated... dotage is a wonderful thing..
Wonderful to avoid the word "too" "for" and "you". This show how you ignore what you don't like.
Oh, neat. So instead of writing two scripts (all w/ bashisms), a configuration file and a unit file, the "next best" way is to run yet another 13.000-lines C program (cat src/network/network[cd]*.[ch] | wc -l).
I can't even tell if you're trolling or just a good example of demonstrating what's wrong with systemd mindset.
I don't understand you, really. The procedure you mentioned was the bare minimum if you don't want to use any helper scripts or applications and is almost identical to what you need with system V init to get the same functionality: the configuration file and the two scripts are absolutely not related to systemd at all. The difference is that with system V init you need to write a script with a start) and stop) method while with systemd you have to write a service file. At the end this is exactly the same number of files, so what your problem ?
systemd-networkd is only an alternative. Personally I largely prefer C code over scripts, mainly because C code projects tend to be adopted by many distributions while scripts tend to remain specific to each distribution. The systemd vs system V story is an very good illustration of this difference.
You see, I already have two good solutions and this little experimental journey into the Arch world just made clear that if I hadn't moved to the BSDs back in the day, I'd do it now. Thanks, though.
So why did you post on a Ubuntu systemd specific discussion if you use *BSD and have only tried Arch ? AFAIK Debian still provides support for/etc/network/interfaces with systemd so basically nothing changed for the users.
What did you try to prove by showing that you are just a few years older than me ?
secondly, I can't be bothered either recovering the old accounts (email addresses - even servers, associated with them are long gone, figments of history..)
How can I trust your recommendations if you are not even able to administrate your very own accounts ?
Maybe there is a reason why you find any leading modern Linux distribution too complicated for you.
systemd-analyze and his commands will give you the answers very quickly. I found that systemd by itself is blazing fast and play an insignificant role in the performance as all depend on the services you require to be started.
System V init was simpler because it was designed at his time to satisfy the demand of the system user at that time. We are talking about the early 1980 here. Since then a quarter of century passed and now the computer technology have evolved in a gigantic scale. The most simplest smartphone sold today is many more complex that anything imaginable at the system V time. This complexity have to be managed by some code in the system. The system V init idea was that it only have to provides the absolute minimal and that all the complex stuff should be managed by something external of the init project. So many incompatible scripts emerged up to the point that it's now impossible to normalize the situation. Project maintainers and distributions maintainers get more and more annoyed, especially since users ask for more and more dynamic systems. System V init failed to evolve and the layer on top of it became a unsustainable mess that even the system V init fail to support in a better way in there anemic reactionary projects.
Upstart proved that something way better can be build to replace system V init and his ugly stack of scripts, and now systemd is good enough to definitively turn the page of system V init for the eternity.
I used system V init on embedded system since late 1990 and I just delivered my first system using systemd this week. This was a easy move that saved me days of works because systemd service file are way simpler than any init script and far more reliable. I can right now remotely monitor the system in production using systemctrl and journalctrl command like never before with system V init.
Complete lie. If you have read the debian-devel mailing-list you will find many many many times the demonstration that the move to systemd was done by technical motivation only, and started many years before a minority (of auto-proclaimed representative of the majority of the users) make an over-sized big mess up to the point a multiple vote was done to go back to real work. The claimed gigantic dependency implication of systemd proved to be a full hoax that destroyed thousand of workday by itself alone.
Actually, this is precisely because the upstart project successfully proved most of his goals that something far better than system V init can be build that the systemd project was started. Even more, at the early stage the idea was rather to fix the upstart inverted dependency logic by a more natural one. But upstart license was an unavoidable limitation for external contributors, so there started an other project called systemd with a more standard license.
Slashdot Mirror
Fully agree. Fork allow to concentrate on real coding instead than on useless controversies.
Exactly. I wish that your sage way of thinking will find more place on the media.
Agree. That said, I think that the situation you describes is not specific to ./.
I learned that perception of the reality in only a single possibility among a large number of biased perceptions, and it's hard to have a complete and actuate perception anyway. So discussion is required to agree on a common perception, but some comments did not help going in that direction.
Can make a big difference between projects. For example LibreOffice was forked from OpenOffice because to much potential contributors was frustrated by the way the OpenOffice maintainers was with them in the past. The libav fork from libFFmpeg was also a way to solve different way of maintaining the project at some point in time. And I am certain that there is a lot of others examples.
There nothing wrong with this process. Better having two peaceful projects than a single one with frustration against it.
8) Yes there is kind of language barrier as I usually speak French. Now the fact that you react with so much emotions and use rhetorical question don't help either our mutual understanding.
We obviously have each confidence in a different model of what the architecture of a distribution must look like. Probably that the use case we assume each for our analysis are very different too, and that could explain why we have some contradictions. If for you the shell very important, for me this is not the case.
3) I don't want to open an other conflict but I do observe that the leading Linux distributions make effort to make users able to manage there machine as much as possible without required to display a shell to the users. This story is about Ubuntu first release with systemd, a distribution that is popular for peoples that have no clue about the shell. On this distribution a typical user will let NetworkManager try to configure the network automatically as much as possible, and if a manual setting is to be enter, the user most likely will do it using the NetworkManager GUI. The Arch procedure you looked at is hard to fit in the same users context.
6) I don't think that Linux try to adhere to the opposite of the 'unix philosophy' and I don't observe that shell scripts play an important role in unix outside of the stack on top of system V init. After all, a lot of unix tools are written in C. I also don't think that the distributions make futile and stupid choice especially regarding the challenge of the experience there try to give to users without any shell knowledge.
7) I referred to you text: "the one Linux server that we do have (for automated installation of the desktops, nightly maintenance etc) needs more hand-holding than basically the remaining two dozen BSD servers need combined." I still wonder why you use Linux for this particular task if Linux cause so much problem for you and that you are happy with BSD.
1) So you admit to have purposely chosen the procedure that use shell scripts only to complain that it, err... use 2 shell scripts???
2) Diversity is an advantage up to the point where the added complexity is not too big. Sometimes it better to normalize to a common parts to simplify.
3) While making a good an complete enough GUI is fare from simple, this don't imply that this is impossible. NetworkManager is now mature enough to be used in a very large use case. This is the primary user interface for a lot of users. Most of them don't have a clue about shell script, so it's impossible to say to them that a shell script is there primary user interface. This is very factual: nor users, nor NetworkManager use script. I can only concede that commands in a shell (no script) are a possible fallback solution in case of problem impossible to solve with the GUI. But I disagree that a possible fallback that most users will never use is defined as a primary user interface.
6) Linux is not so UNIX anymore in the sense that it integrate more and more features compared than any others UNIX kernel. More and more Linux syscalls are not related to any UNIX standards. This is a new world emerging from UNIX but not bound to it anymore. Goodbye to anyone that like to stay with the UNIX way. This can make a lot of sens for some situations, and nobody will prevent them to do so. This is there respectable choice, and there could make an effort to respect the choice of others that want to follow the Linux way, unbound to the UNIX limitations. udev and systemd are required evolution steps to solve problems that have found no better solution using the UNIX traditional way.
7) Then I don't understand why you still use a Linux machine if BSD is so better for you. Really strange that your uptime is so small. I usually only reboot for hardware maintenance. One of the Linux servers actually show a uptime of 2121 days has soft RAID-1 and several virtual machines running on it. I plan to change it this year because some hardware parts are over 10 years old, but from the software point of view it run just fine.
8) As you have said to me 'Hahahahaha'...
1) This is my definition is the context of this discussion. If you don't like it we can agree to name it differently. This will not change the reality that the procedure you mentioned did not use the usual infrastructure found on distribution to setup a static IP address.
2) Fine that we agree on this. But system V init in a C code that do exec(). The fact that it's usually a script is not required by system V init. But the main problem is not really script vs binary, the main problem is precisely the lack of normalization because anything on top of the bare minimal original system V init code is distribution specific.
3) The fact is that on most leading modern Linux distribution, this is not a script that call a command that setup the IP address of a network interface, because there use the NetworkManager package. Again you might not like it, but this will not change this reality. If you think that I don't understand your point, please try a least to repeat it. Actually you only deny some point.
4) Certainly not the system administrator according to http://training.linuxfoundatio... . I don't see the point calling a user system administrator regarding network operation when there simply let the dhcp client automatically configure an interface. Nor in the case where there select a SSID and enter a key. Nor when there use the NetworkManager GUI to select the Manual method on the IPv4 tab of an interface. In all those examples there is no scripts and no command involved.
5) It's perfectly possible to manage a very large number network situations with NetworkManager GUI without using any shell, script, or command. This is the primary interface for most of the users, including myself, even after working for years in a company that build routers. As a side note, this kind of GUI was all the customers constantly asked for, liked and used. Only the engineer and support used command to verify the state of the system. In the embedded systems I build today, the customer ask to configure the network from a web UI that push the configuration on a SQL database on the target, to illustrate how far is you idea of script and command.
6) Agree on the fact that scripts cover a more generic knowledge. Sadly this is not so useful on a system that use less and less scripts. I understand that you regret this evolution, but as the complexity of the system increase, scripts that are different in each distributions have reach a limit for many maintainers. Thing could have been different if the original system V init package would have normalized the script stack early. There failed to do that, now the time is probably over for them as systemd not only normalize the situation across the distributions but also bring a lot of new features on the table.
7) I wonder what's your work environment to be exposed to such 'shitstorm'. I have see time to time worker having to ask there superior to have the right to install a Linux system, but I never see the network administrator complaining.
8) All the last points is to show that your laugh are strange because all points can be independently verified true. There is no rhetorical nature in any of them, this is just a list of facts.
Actually 42, and I used to have 64 of them.
I manage multiple projects, once per line of virtual desktop except for the top line where I have all the social applications, general browsing, music, and unrelated stuff. On a typical project line I have desktop with the documentation, the schematics, the routing, the source code, the compilation, the console on the target, usually multiple times when there are more than on application to do. Some project have multiples machines involved and to be monitored. There a document to fill for the client, there are some experiment to do. This quickly take a lot of windows and desktops.
Now why did I not close the windows as soon as I don't need them and re-open them when required? Because I can simply just leave them as there are without any problem. If I have an idea on a project I can check it very quickly. If someone ask something about a project I just have to switch to the related virtual desktop where I will find the windows arranged in there usual way with documentation ready to be read, code ready to be edited and console connected to the target ready to take input.
In this situation, I really don't like to close my session or reboot. I need a system as stable as possible. I rebooted about 3 months ago to install a GPU, but I remember having passed a full year without any reboot.
1) What's wrong calling a helper script a script that help you to do something in a more simple way? Now if it's not from you the script came from something else. In the context of this discussion this is from the distribution.
2) It's not the central part of system V init. The most obvious prof of this is that each distribution family have a different set of helpers scripts. Just take a look at the reality:
https://packages.debian.org/je...
https://packages.debian.org/je...
https://packages.debian.org/je...
If you list the source patch archive http://http.debian.net/debian/... you will see that ALL the initscripts are Debian specific and not part of the original sysvinit http://http.debian.net/debian/... .
Configuring the network is not the same in Fedora an in Debian. On of the long term goal of systemd is to normalize the situation.
3) The problem is to configure an interface automatically when the system boot. In most distribution the users don't even have to use the real command to setup the interface to do this. And you are completely wrong about your ifconfig and script theory: the vast majority of network interfaces are today setup by a dhcp client, or an application like NetworkManager according to DBUS messages coming for example from a GUI application, all written in C or C++, or maybe something other, but for certain shell scripts play a marginal role here. The shell is NOT the primary interface for the vast majority of the users, sysadmin is not the dominant specie in the Linux world.
4) Systemd is really simpler to learn that shell script. I switched some months ago to systemd and found all the documentation is needed in the usual man pages. I took me less than 1 hour to learn the basic commands and I was able to convert the custom part of the system less than one day.
5) You can laugh as you want, this will not change the reality: /etc/network/interfaces with systemd.
* Sysadmins are a minority of Linux users.
* Distributions like Debian support
* There are sysadmin already using systemd.
* To date there is no enough maintainers against systemd to have successfully make an serious alternative available and ready to use by the distribution.
* Systemd transition is now done by Fedora, Ubuntu and Debian and there are still there.
* Still, a lot of forum get post from 'sysadmin' complaining.
1) The procedure you mentioned precisely do not use any helper script. This why it take 4 files
...two of which are helper scripts...
No, by definition helper scripts must already be part of the distribution.
, exactly the same amount of file on system V init.
Not quite, but whatever.
Exactly the same amount, if you don't use the system V init helper scripts.
2) The /usr/local/bin/net-up.sh and /usr/local/bin/net-down.sh are absolutely not related to systemd at all. You will use exactly the same scripts with system V init if you don't use helper scripts.
...except for those two helper scripts, yes... They are /not/ required in sysvinit. There's nothing to stop you from doing something like that on system V, but the canonical way would be to do that in the init script.
At least you recognize that (almost) the same procedure will apply to system V init if someone don't want to use his helper script. Please understand that the normal way to configure a simple static IP address with systemd is to use either systemd-networkd or the distribution specific file to do this like /etc/network/interfaces in Debian.
So regarless of whether the helper scripts are an unrelated or an integral part of systemd, using systemd in Arch for the highly complex use-case "static IP address" apparently means one way or another, they have to appear. Stop trying to excuse that away.
The fact that Arch Linux don't provides anything is strange. Think what would be the usability of a system V init without all the scripts on top of it. This is not an excuse, others distributions that use systemd simply don't require the procedure you mentioned, and event Arch document how to use systemd-networkd for a simple static IP.
The fact that this 2 scripts use a configuration file is neither relater to systemd.
Sure, there's nothing wrong with a configuration file. What you're trying to say here, not so sure.
Simply: this is not because of systemd.
3) Yes this is pointless to compare systemd over system V init by showing an example that is nothing related to systemd.
I don't even know what to reply to this ... odd ... statement. I'll grant you the benefit of the doubt and assume you live in some twisted sort of parallel universe where 'nothing related' means 'entirely related' or so..
You have perfectly understand me. You find, maybe by hazard, a very strange and unusual procedure to setup a static IP interface. The procedure use a systemd service file to call two scripts that use a configuration file and you make it a point about claiming that systemd require too complex procedure for a such simple static IP configuration. Now think is you have found the same procedure that use a system V init /etc/init.d/* script to call the very exact same scripts that use the very exact same configuration file, I beat that you will instantaneously found this procedure too complex because you can simply configure a static IP by just edit an already existing configuration file dedicated for this purpose in you distribution of choice.
4) I also claim to have ton of experience in C. From the distribution maintainers point of view, scripts or C applications are exactly the same problem: when there have to fix something, there need to publish a new package
You're missing the point. I wasn't talking about the point of view of distro maintainers, but the case when you, a sysadmin, first encounter a problem with a script or program. Please, with that in mind, reconsider that part of what i wrote
1) The procedure you mentioned precisely do not use any helper script. This why it take 4 files, exactly the same amount of file on system V init.
2) The /usr/local/bin/net-up.sh and /usr/local/bin/net-down.sh are absolutely not related to systemd at all. You will use exactly the same scripts with system V init if you don't use helper scripts. The fact that this 2 scripts use a configuration file is neither relater to systemd.
3) Yes this is pointless to compare systemd over system V init by showing an example that is nothing related to systemd.
4) I also claim to have ton of experience in C. From the distribution maintainers point of view, scripts or C applications are exactly the same problem: when there have to fix something, there need to publish a new package, the fact that it require a compilation is a detail, especially given how ubiquitous is a C compiler on a maintainer machine. Well written scripts or C applications must log debug messages to help tracing problems. Now take a look at the reality: there is very few scripts that are well written, mainly because the authors assume that it's easy to read the script. On the contrary many C applications a well written because the authors know that the users will have nothing to show in case of a problem. The 'set -x' is not a magic trick that allow to find any problem a stack of scripts might have. The dependencies problem of the init scripts is one of them.
5) Because I usually wrote French and in that language we put a whitespace in front of question marks. I did not notice that it's not the same in English. http://fr.wikipedia.org/wiki/P...
Right.
The evolution from FVWM/FVWM95/IceWM/Scwm/Sawfish (in my case) to Metacity was a big progress because The windows management API goes normalized and was separated from all the others goodies provided by a desktop. At this time Gnome 2 was a superb improvement (KDE too) for the users without losing really used features from the previous projects. XFCE, MATE and Cinnamon continue on this track, with some success. Gnome 3 WM Mutter was a different kind of evolution, more like an experimental project. There nothing wrong to try experiment, but closing Gnome 2 WM Metacity project so early was a bad choice. The most obvious prove of this is the fact that the developers of Mutter ported Metacity to GTK3+ instead of adding Metacity features into Mutter:
http://ftp.gnome.org/pub/GNOME...
From my point of view, Metacity should have been ported to GTK3+/Gnome 3, first and then Mutter could have started as a new experiment, not the contrary. The actual situation is just the natural correction of this error that have taken a lot too much attention than if it was done the right way.
Debian Jessie, just released, is AFAIK the first leading distribution that allow to select the desktop of choice directly from the installer. This is a welcome move, because before, yes some user like me did't have so much choice, unless you install manually a desktop (hard to do), or switch to an other distribution (I use Mint on a laptop). Part of the problem is that XFCE and MATE take some years to get the high quality there provides today. What's interesting is that XFCE and MATE have get this quality precisely because so many peoples was frustrated with the Gnome 3 experience.
The way the Gnome project managed the transition will stay for long as an example of bad practice. The main error was to abandon the Gnome 2 code while the code Gnome 3 did not allow most of the users to make the transition based on there own motivation because at some point there will found that Gnome 3 is better. The reality is still that Gnome 3 did not reach this point for enough users that the venerable XFCE project gain support like never before and the MATE project started from the abandoned Gnome 2 code.
And there is the Cinnamon project that try to bring the MATE feature on a Gnome 3 base. All of this show how much frustration the Gnome 3 project have created early. Now the situation is far better and in a near future I beat that the winning project will be the one that will be the fastest to integrate in a nice way the beast features of all the projects. I suspect that Gnome 3 is not in a good condition to win the race, as his evolution since a couple of years in anemic compared to MATE for example.
I also found Gnome 3 a bad choice for my use, but Debian Jessie is the first release to propose a lot of alternative directly from the installer, so regarding this subject I found it a improvement compared to the previous release. I personally will select MATE instead of Gnome 3.
The systemd transition is an other subject. I personally found it preferable to the stack of scripts on top of system V init. Ok it require to learn something new, but the basic is very simple and most of the stuff need just a bit of practice. I don't think that the alternatives of systemd will be in position to stay competitive for long, as the architectural change bring a too much advantages to maintainers that do the real work.
I have multiples machines, each with a different Desktop: Gnome 3, Unity, XFCE and MATE.
My biggest problem with Gnome 3 is the fact it's not designed to work well with multiple windows overlapping and spread on a lot of virtual desktops. I usually have more than 100 windows on about 40 virtual desktops. This kind of use is a nightmare with Gnome 3 or Unity because the respective position of the virtual desktops change dynamically so it's impossible to map in the brain. The second problem is the upper left corner switch that place each widows in a random order impossible to memorize, so totally useless for me. The next problem is the animations and effect that make everything slow and distracting. The next problem is the panel extension that are difficult to select because of big catalog of similar entries, and rarely a good quality both in term of usability and in term of look. Finally the menu really hurt on big screen like 4K because it open from the left of the screen but the sub-menus are on the right of the screen. This menu take so much place that it require a lot of mouse translation to do almost anything. Whats totally ridicule is that even by displaying so few items on a 4K screen, this menu is not even able to display the full name of all application because it truncate it to the size of the icon. So no, I really don't like Gnome 3 (and Unity that share a lot of same bad design).
XFCE and MATE are extremely efficient and blazing fast for my use case. There make easy to map in my brain the respective position of a lot of virtual desktops. The panel widget are coherent and easy to select in a small list of entries but with a lot of features of each entries. The menu is the most simplest possible, but display the full name of all the applications, require a minimum of space so it's fast to use with the mouse and is easy to customize. No animation, no effect, just maximal speed. Finally there perfectly scale on a 4K screen without any disadvantage. And i like the windows tab menu with a useful text into each tab describing precisely what's is in each related window.
Put simply, Gnome 3 idea is big graphic and small or no text. What I need is small icon and a lot of text.
I was pointing out that I'm more than qualified to do so (and I didn't even put in any of the Microsoft systems stuff, nor the hardware design)
I can pretend to be equally qualified than you. You don't impress me, nor you add credit to your recommendations.
secondly, I can't be bothered either recovering the old accounts (email addresses - even servers, associated with them are long gone, figments of history..)
How can I trust your recommendations if you are not even able to administrate your very own accounts ?
Because, unlike the accounts I have kept going for a long time (e.g. the email address I've had for 22 years) these accounts are trivial/transient..the universe didn't ouzelum the day I could no longer log in using any of them, there was not a wailing and gnashing of teeth..
There's this thing called 'sense of proportion'.
So if it's not proportional enough, why did you mention it is the first place ?
Maybe there is a reason why you find any leading modern Linux distribution too complicated for you.
Oh, for sure...leading...modern..complicated...
dotage is a wonderful thing..
Wonderful to avoid the word "too" "for" and "you". This show how you ignore what you don't like.
Now if you just need a simple static address I would suggest to use systemd-networkd: https://wiki.archlinux.org/ind...
Oh, neat. So instead of writing two scripts (all w/ bashisms), a configuration file and a unit file, the "next best" way is to run yet another 13.000-lines C program (cat src/network/network[cd]*.[ch] | wc -l).
I can't even tell if you're trolling or just a good example of demonstrating what's wrong with systemd mindset.
I don't understand you, really. The procedure you mentioned was the bare minimum if you don't want to use any helper scripts or applications and is almost identical to what you need with system V init to get the same functionality: the configuration file and the two scripts are absolutely not related to systemd at all. The difference is that with system V init you need to write a script with a start) and stop) method while with systemd you have to write a service file. At the end this is exactly the same number of files, so what your problem ?
systemd-networkd is only an alternative. Personally I largely prefer C code over scripts, mainly because C code projects tend to be adopted by many distributions while scripts tend to remain specific to each distribution. The systemd vs system V story is an very good illustration of this difference.
You see, I already have two good solutions and this little experimental journey into the Arch world just made clear that if I hadn't moved to the BSDs back in the day, I'd do it now. Thanks, though.
So why did you post on a Ubuntu systemd specific discussion if you use *BSD and have only tried Arch ? AFAIK Debian still provides support for /etc/network/interfaces with systemd so basically nothing changed for the users.
is still quite a mystery how systemd was used as the default so soon.
You call it a mystery because you ignore the fact that all the process has been discussed openly, voted, and archived in a way anyone can access it.
Well, there is probably a lot of even more complicated methods.
Now if you just need a simple static address I would suggest to use systemd-networkd: https://wiki.archlinux.org/ind...
I hope this one is simple enough for your use case.
What did you try to prove by showing that you are just a few years older than me ?
secondly, I can't be bothered either recovering the old accounts (email addresses - even servers, associated with them are long gone, figments of history..)
How can I trust your recommendations if you are not even able to administrate your very own accounts ?
Maybe there is a reason why you find any leading modern Linux distribution too complicated for you.
systemd-analyze and his commands will give you the answers very quickly. I found that systemd by itself is blazing fast and play an insignificant role in the performance as all depend on the services you require to be started.
Recommendation from an Anonymous Coward...
System V init was simpler because it was designed at his time to satisfy the demand of the system user at that time. We are talking about the early 1980 here. Since then a quarter of century passed and now the computer technology have evolved in a gigantic scale. The most simplest smartphone sold today is many more complex that anything imaginable at the system V time. This complexity have to be managed by some code in the system. The system V init idea was that it only have to provides the absolute minimal and that all the complex stuff should be managed by something external of the init project. So many incompatible scripts emerged up to the point that it's now impossible to normalize the situation. Project maintainers and distributions maintainers get more and more annoyed, especially since users ask for more and more dynamic systems. System V init failed to evolve and the layer on top of it became a unsustainable mess that even the system V init fail to support in a better way in there anemic reactionary projects.
Upstart proved that something way better can be build to replace system V init and his ugly stack of scripts, and now systemd is good enough to definitively turn the page of system V init for the eternity.
I used system V init on embedded system since late 1990 and I just delivered my first system using systemd this week. This was a easy move that saved me days of works because systemd service file are way simpler than any init script and far more reliable. I can right now remotely monitor the system in production using systemctrl and journalctrl command like never before with system V init.
Complete lie. If you have read the debian-devel mailing-list you will find many many many times the demonstration that the move to systemd was done by technical motivation only, and started many years before a minority (of auto-proclaimed representative of the majority of the users) make an over-sized big mess up to the point a multiple vote was done to go back to real work. The claimed gigantic dependency implication of systemd proved to be a full hoax that destroyed thousand of workday by itself alone.
Actually, this is precisely because the upstart project successfully proved most of his goals that something far better than system V init can be build that the systemd project was started. Even more, at the early stage the idea was rather to fix the upstart inverted dependency logic by a more natural one. But upstart license was an unavoidable limitation for external contributors, so there started an other project called systemd with a more standard license.