[arch-general] Arch Linux and systemd
There has been much ado on the arch-general mailing list about the move to systemd. I participated in part of it, but like others finally tired of "seeing a dead horse kicked" over and over and over. So much so that the last dev who really paid attention to the list said goodbye. Yet the free for all continues. I think a comment on Allan's blog post might illustrate how I perceive this situation. Are We Removing What Defines Arch Linux? Allan McRae posted to Arch Planet on August 13, 2012 03:59 PM It's not about a single file, ie rc.conf (well not completely), it's about the simplicity of the system. Controversy #2 – The demise of /etc/rc.conf While the single rc.conf is highlighted as major feature of Arch Linux, reading the reviews makes you notice that configuration of an Arch install was never down to a single file. Other files mentioned included… But lets take a step back here… How about some quotes from Judd, the founder of Arch Linux: “In Arch “simple” is different what other distros are considering. The learning is more important than getting something easily done.” “Relying on GUIs to build/use your system is just going to hurt a user in the end. At some point in time a user will need to know all that some GUIs hide.” My question becomes, are we trading the simplicity and ease of setting up a single individuals computer, not corporate or work machine, or a set of two or three home machines for the trappings of the corporate desktop? Are we trading learning the shell (bash or otherwise) and learning to write bug free shell scripts, for learning a set or arbitrary and possibly arcane rules, decided upon in a building somewhere in the world, by someone who knows how to use your computer better than you do? We've already seen the likes of those already seen with polkit and consolekit. Even with udev moving into systemd, an individual on the systemd mailing list has already stated his desire to finally be rid of udev altogether. He considers it an abomination. As to the standardization mentioned, does not such standardization remove one's freedom? I'm not an RMS fan, so don't go there. However, I am old enough to remember when there was no choice for home computers, and a commercial by Apple for the first Mac using the idea of breaking out of 1984 and the dull boring corporate world. Now here we are moving the one OS that's stayed somewhat of a maverick into the stable, then out to pasture to graze with with the rest of the corporate world. At least IMHO. It's not about changing Arch, it's about becoming part of the corporate structure and playing nice with everyone else. You can read that line with the knowledge "Old hippies die hard. And I still don't trust the establishment as far a I can throw my house!" Interoperability is necessary in today's world, but I think it can be done with out sacrificing the heart and soul of Linux. When it comes to the move of lib and lib64 to /usr/lib, I'm basically ambivalent. I still don't like not being able to put /usr on a separate partition, I know there's a mkinitcpio hook to cover that, but I can see the logic in cleaning up the system. I've never really cared for the mess of the LSB. IMHO systemd is for administrators who, unlike Judd Vinet, want to hide the system setup from the user with fancy gui's and not allow anyone but the sysadmin to make any changes. I laud the devs who are working on this project, but I ask you to consider "Is it better for Arch to lead one of the last bastion's of freedom when using Linux into lock step with the the PTB's, or would it be better to develop an alternative that keeps, not just Arch Linux, but Linux a viable alternative to OSX, Windows, any Unix/BSD environment, and the corporate world?" I know it's the simpler, and probably less stressfull solution, but is it the better solution? I firmly believe more discussions like this on the ml would be more productive than the brawls we've seen lately. It also might provide the dev's an opportunity to participate more instead of throwing their hands up in the air and saying never again. To me the mailing list has become reactive. Too many responses, I've been guilty of this, come from predetermined ideas which may or may not be rooted in fact. They may be rooted in the users experience which may have been affected by other circumstances such as the dependency hell being created by the tighter and tighter upstream integration by KDE and Gnome. This again signals the move towards a "corporate desktop environment". A wise unix guru, can't remember the name right now, said something to the effect "the system should be a set of well written programs loosely connected programs, each doing one thing and doing it well". Something many of today's programs don't accomplish. As I said on the arch-general mailing list. These are the battles that have spawned many a linux distro and there is always LFS, even though they moved to use udev inside systemd. Myra Nelson To those who I bcc'd this to; I would like to humbly appologize if I intruded on your personal space, but I wanted to make sure it would be read by you in your own private space without the need to filter through the BS that's likely to occur on the ml. -- Life's fun when your sick and psychotic!
On Thu, Aug 16, 2012 at 4:22 PM, Myra Nelson <myra.nelson@hughes.net> wrote:
There has been much ado on the arch-general mailing list about the move to systemd. I participated in part of it, but like others finally tired of "seeing a dead horse kicked" over and over and over. So much so that the last dev who really paid attention to the list said goodbye. Yet the free for all continues. I think a comment on Allan's blog post might illustrate how I perceive this situation.
Are We Removing What Defines Arch Linux? Allan McRae posted to Arch Planet on August 13, 2012 03:59 PM
It's not about a single file, ie rc.conf (well not completely), it's about the simplicity of the system.
Controversy #2 – The demise of /etc/rc.conf While the single rc.conf is highlighted as major feature of Arch Linux, reading the reviews makes you notice that configuration of an Arch install was never down to a single file. Other files mentioned included…
But lets take a step back here… How about some quotes from Judd, the founder of Arch Linux: “In Arch “simple” is different what other distros are considering. The learning is more important than getting something easily done.” “Relying on GUIs to build/use your system is just going to hurt a user in the end. At some point in time a user will need to know all that some GUIs hide.”
My question becomes, are we trading the simplicity and ease of setting up a single individuals computer, not corporate or work machine, or a set of two or three home machines for the trappings of the corporate desktop? Are we trading learning the shell (bash or otherwise) and learning to write bug free shell scripts, for learning a set or arbitrary and possibly arcane rules, decided upon in a building somewhere in the world, by someone who knows how to use your computer better than you do? We've already seen the likes of those already seen with polkit and consolekit. Even with udev moving into systemd, an individual on the systemd mailing list has already stated his desire to finally be rid of udev altogether. He considers it an abomination. As to the standardization mentioned, does not such standardization remove one's freedom? I'm not an RMS fan, so don't go there. However, I am old enough to remember when there was no choice for home computers, and a commercial by Apple for the first Mac using the idea of breaking out of 1984 and the dull boring corporate world. Now here we are moving the one OS that's stayed somewhat of a maverick into the stable, then out to pasture to graze with with the rest of the corporate world. At least IMHO. It's not about changing Arch, it's about becoming part of the corporate structure and playing nice with everyone else. You can read that line with the knowledge "Old hippies die hard. And I still don't trust the establishment as far a I can throw my house!"
Interoperability is necessary in today's world, but I think it can be done with out sacrificing the heart and soul of Linux. When it comes to the move of lib and lib64 to /usr/lib, I'm basically ambivalent. I still don't like not being able to put /usr on a separate partition, I know there's a mkinitcpio hook to cover that, but I can see the logic in cleaning up the system. I've never really cared for the mess of the LSB. IMHO systemd is for administrators who, unlike Judd Vinet, want to hide the system setup from the user with fancy gui's and not allow anyone but the sysadmin to make any changes.
I laud the devs who are working on this project, but I ask you to consider "Is it better for Arch to lead one of the last bastion's of freedom when using Linux into lock step with the the PTB's, or would it be better to develop an alternative that keeps, not just Arch Linux, but Linux a viable alternative to OSX, Windows, any Unix/BSD environment, and the corporate world?" I know it's the simpler, and probably less stressfull solution, but is it the better solution?
I firmly believe more discussions like this on the ml would be more productive than the brawls we've seen lately. It also might provide the dev's an opportunity to participate more instead of throwing their hands up in the air and saying never again. To me the mailing list has become reactive. Too many responses, I've been guilty of this, come from predetermined ideas which may or may not be rooted in fact. They may be rooted in the users experience which may have been affected by other circumstances such as the dependency hell being created by the tighter and tighter upstream integration by KDE and Gnome. This again signals the move towards a "corporate desktop environment".
A wise unix guru, can't remember the name right now, said something to the effect "the system should be a set of well written programs loosely connected programs, each doing one thing and doing it well". Something many of today's programs don't accomplish.
As I said on the arch-general mailing list. These are the battles that have spawned many a linux distro and there is always LFS, even though they moved to use udev inside systemd.
Myra Nelson
To those who I bcc'd this to;
I would like to humbly appologize if I intruded on your personal space, but I wanted to make sure it would be read by you in your own private space without the need to filter through the BS that's likely to occur on the ml.
-- Life's fun when your sick and psychotic!
That seems to be one of the more well thought out (not pro), responces to systemd,
On Thu, Aug 16, 2012 at 4:34 PM, Nicholas MIller <nick.kyky@gmail.com>wrote:
On Thu, Aug 16, 2012 at 4:22 PM, Myra Nelson <myra.nelson@hughes.net> wrote:
There has been much ado on the arch-general mailing list about the move to systemd. I participated in part of it, but like others finally tired of "seeing a dead horse kicked" over and over and over. So much so that the last dev who really paid attention to the list said goodbye. Yet the free for all continues. I think a comment on Allan's blog post might illustrate how I perceive this situation.
Are We Removing What Defines Arch Linux? Allan McRae posted to Arch Planet on August 13, 2012 03:59 PM
It's not about a single file, ie rc.conf (well not completely), it's about the simplicity of the system.
Controversy #2 – The demise of /etc/rc.conf While the single rc.conf is highlighted as major feature of Arch Linux, reading the reviews makes you notice that configuration of an Arch install was never down to a single file. Other files mentioned included…
But lets take a step back here… How about some quotes from Judd, the founder of Arch Linux: “In Arch “simple” is different what other distros are considering. The learning is more important than getting something easily done.” “Relying on GUIs to build/use your system is just going to hurt a user in the end. At some point in time a user will need to know all that some GUIs hide.”
My question becomes, are we trading the simplicity and ease of setting up a single individuals computer, not corporate or work machine, or a set of two or three home machines for the trappings of the corporate desktop? Are we trading learning the shell (bash or otherwise) and learning to write bug free shell scripts, for learning a set or arbitrary and possibly arcane rules, decided upon in a building somewhere in the world, by someone who knows how to use your computer better than you do? We've already seen the likes of those already seen with polkit and consolekit. Even with udev moving into systemd, an individual on the systemd mailing list has already stated his desire to finally be rid of udev altogether. He considers it an abomination. As to the standardization mentioned, does not such standardization remove one's freedom? I'm not an RMS fan, so don't go there. However, I am old enough to remember when there was no choice for home computers, and a commercial by Apple for the first Mac using the idea of breaking out of 1984 and the dull boring corporate world. Now here we are moving the one OS that's stayed somewhat of a maverick into the stable, then out to pasture to graze with with the rest of the corporate world. At least IMHO. It's not about changing Arch, it's about becoming part of the corporate structure and playing nice with everyone else. You can read that line with the knowledge "Old hippies die hard. And I still don't trust the establishment as far a I can throw my house!"
Interoperability is necessary in today's world, but I think it can be done with out sacrificing the heart and soul of Linux. When it comes to the move of lib and lib64 to /usr/lib, I'm basically ambivalent. I still don't like not being able to put /usr on a separate partition, I know there's a mkinitcpio hook to cover that, but I can see the logic in cleaning up the system. I've never really cared for the mess of the LSB. IMHO systemd is for administrators who, unlike Judd Vinet, want to hide the system setup from the user with fancy gui's and not allow anyone but the sysadmin to make any changes.
I laud the devs who are working on this project, but I ask you to consider "Is it better for Arch to lead one of the last bastion's of freedom when using Linux into lock step with the the PTB's, or would it be better to develop an alternative that keeps, not just Arch Linux, but Linux a viable alternative to OSX, Windows, any Unix/BSD environment, and the corporate world?" I know it's the simpler, and probably less stressfull solution, but is it the better solution?
I firmly believe more discussions like this on the ml would be more productive than the brawls we've seen lately. It also might provide the dev's an opportunity to participate more instead of throwing their hands up in the air and saying never again. To me the mailing list has become reactive. Too many responses, I've been guilty of this, come from predetermined ideas which may or may not be rooted in fact. They may be rooted in the users experience which may have been affected by other circumstances such as the dependency hell being created by the tighter and tighter upstream integration by KDE and Gnome. This again signals the move towards a "corporate desktop environment".
A wise unix guru, can't remember the name right now, said something to the effect "the system should be a set of well written programs loosely connected programs, each doing one thing and doing it well". Something many of today's programs don't accomplish.
As I said on the arch-general mailing list. These are the battles that have spawned many a linux distro and there is always LFS, even though they moved to use udev inside systemd.
Myra Nelson
To those who I bcc'd this to;
I would like to humbly appologize if I intruded on your personal space, but I wanted to make sure it would be read by you in your own private space without the need to filter through the BS that's likely to occur on the ml.
-- Life's fun when your sick and psychotic!
That seems to be one of the more well thought out (not pro), responces to systemd,
Thank you. My intent was to start an intelligent discussion. The rants and raves are going no where. I'm not necessarily against systemd, just the PTB's upstream dictating how Linux is and can be used. To me Linux is about choice, unlike the OS I used for so many years. My other goal is to get the devs involved to think about how to help the Arch community in general. If Arch is what you make of it, don't take that choice away. Yes, Tom, I've backed off a little. I've started reading the systemd mailing list and although Arch likes to lead the way into the future, I'm not sure systemd is the future any more than upstart, polkit, consolekit, gnome3, kde4, ad nauseum. This last line may elicit the wrong responses, but I hope not. It wasn't meant to slam any one particular idea. Just point out that:
From Alan Kay:
Simple things should be simple. Complex things should be possible. Most software today is very much like an Egyptian pyramid with millions of bricks piled on top of each other, with no structural integrity, but just done by brute force and thousands of slaves. We in the Linux community rest on the shoulders of giants all the way down to Torvalds and GKH. We should act like it. Myra -- Life's fun when your sick and psychotic!
On 2012/8/17 Myra Nelson <myra.nelson@hughes.net> wrote:
On Thu, Aug 16, 2012 at 4:34 PM, Nicholas MIller <nick.kyky@gmail.com>wrote:
That seems to be one of the more well thought out (not pro), responces to systemd,
Thank you. My intent was to start an intelligent discussion. The rants and raves are going no where. I'm not necessarily against systemd, just the PTB's upstream dictating how Linux is and can be used. To me Linux is about choice, unlike the OS I used for so many years. My other goal is to get the devs involved to think about how to help the Arch community in general. If Arch is what you make of it, don't take that choice away.
The tools dictate how to use the system. Archlinux has never dictated which tools to use, and the "move to systemd" is not more a dictation about which tool to use than anything before. Arch is still what you make of it, some tools just don't have alternatives and you are welcome to develop one of them to help that choice. Nobody is "removing an alternative" here, it's just cleaning up the dead, the community is free to revive them. I don't see how this discussion is different from the other ones. Most of the discussions are based on the assumption that we currently have working boot scripts in bash. This one is too. Rémy.
On Sat, Aug 18, 2012 at 2:37 AM, Rémy Oudompheng <remyoudompheng@gmail.com>wrote:
On Thu, Aug 16, 2012 at 4:34 PM, Nicholas MIller <nick.kyky@gmail.com wrote:
That seems to be one of the more well thought out (not pro), responces to systemd,
Thank you. My intent was to start an intelligent discussion. The rants and raves are going no where. I'm not necessarily against systemd, just the PTB's upstream dictating how Linux is and can be used. To me Linux is about choice, unlike the OS I used for so many years. My other goal is to get
On 2012/8/17 Myra Nelson <myra.nelson@hughes.net> wrote: the
devs involved to think about how to help the Arch community in general. If Arch is what you make of it, don't take that choice away.
The tools dictate how to use the system. Archlinux has never dictated which tools to use, and the "move to systemd" is not more a dictation about which tool to use than anything before. Arch is still what you make of it, some tools just don't have alternatives and you are welcome to develop one of them to help that choice.
Nobody is "removing an alternative" here, it's just cleaning up the dead, the community is free to revive them. I don't see how this discussion is different from the other ones. Most of the discussions are based on the assumption that we currently have working boot scripts in bash. This one is too.
Rémy.
Remy: Culling the herd never hurts and I'm not a firm believer that the current bash scripts are perfect. My goal was to entice a lower tone, more rational, not have to sort through all the bull shit conversations. As I pointed out somewhere earlier, my brain doesn't process information the same way most do and I get bore quickly sorting through the other posts for real information. Hard data is true information, information equals power, and distilled information is the best there is, but trying to sort through the rants and raves it completely beyond me. I have to map things out like logic gates: If xyz then blah blah else if jkl etc end if In other words, why oop still eludes me to this day. There are certain transtions in my transitors that are broken and I need intelligent responses like yours, Tom's, and the blog Allan posted to Planet Arch to wend my way through things. Sorry if I seemed to have caused offending and extra noise. Myra -- Life's fun when your sick and psychotic!
On Thu, 16 Aug 2012 16:22:56 -0500 Myra Nelson <myra.nelson@hughes.net> wrote: <snip> I agree. I have read all the current threads and the few words which struck me with greatest force were in a post from Marti Raudsepp, where he said that an advantage of systemd is "... less fragmentation between Linux distribution". I have been full time on linux for nearly 13 years now, with the most recent five of those on Arch, and for me one of the principal attractions of the OS has always been fragmentation between distributions. The recent changes to Arch (and I dare say other distros which I do not monitor), all seem to me to point in the direction of drab ecumenism - eventually "One distro to rule them all ...." Sooner or later Arch will be distinguished only by its excellent rolling release model and the wonderful pacman. Perhaps all this was inevitable. I do not intend anything I say as a criticism of the devs - it is their distro and they are entitled to do what they choose with it. But it does make me sad. Geoff
On Fri, Aug 17, 2012 at 2:57 AM, Geoff <capsthorne@yahoo.co.uk> wrote:
On Thu, 16 Aug 2012 16:22:56 -0500 Myra Nelson <myra.nelson@hughes.net> wrote:
<snip>
I agree. I have read all the current threads and the few words which struck me with greatest force were in a post from Marti Raudsepp, where he said that an advantage of systemd is "... less fragmentation between Linux distribution". I have been full time on linux for nearly 13 years now, with the most recent five of those on Arch, and for me one of the principal attractions of the OS has always been fragmentation between distributions. The recent changes to Arch (and I dare say other distros which I do not monitor), all seem to me to point in the direction of drab ecumenism - eventually "One distro to rule them all ...." Sooner or later Arch will be distinguished only by its excellent rolling release model and the wonderful pacman. Perhaps all this was inevitable. I do not intend anything I say as a criticism of the devs - it is their distro and they are entitled to do what they choose with it. But it does make me sad.
the boot process isn't really that interesting (once you know/understand it anyway ... if not i encourage you to explor ;-) -- every distro pretty much does it the same way, but pointlessly independent, thus resulting in annoying differences that are completely irrelevant to begin with. no flexibility is lost by moving to systemd, and really, much more gained: wider userbase, wider testbase, simple units to write, simple units to read, loosely coupled ordering, implicit dependencies, Grand Unified logging capabilities, and of course, much better speed/reliability/robustness. take the (unanimous?) sentiments exhibiting by our developers -- and *many* developers elsewhere, in a great variety of capacities/niches -- as a sign of the good things to come. i fully expect 99%+ will have little trouble adjusting, and 98% will at that time agree it was clearly the right choice. initiatives like this are not removing choice -- they are consolidating the common bits so developers can get back to writing the interesting next-gen stuff instead of spinning wheels or putting out fires. like most things in life, balance is key to good health. -- C Anthony
On Fri, Aug 17, 2012 at 04:08:32AM -0500, C Anthony Risinger wrote:
no flexibility is lost by moving to systemd, and really, much more gained: wider userbase, wider testbase, simple units to write, simple units to read, loosely coupled ordering, implicit dependencies, Grand Unified logging capabilities, and of course, much better speed/reliability/robustness.
That is probably all true. But there is one observation in Myra's post which I think is very much to the point: the fact that 'upstream' (in this case mainly Redhat), is driving Linux to become 'enterprise-friendly'. This is also very visible if you read Lennart's blog. There's in principle nothing wrong with that, unless the way this is done means that it becomes more difficult for a user to configure his system differently. Note that the aim in most enterprises is to take control away from the end user, even if he's sitting right besides the system. It is inevitable that anything that enables this goes against the interest of the individual user. I'm pretty sure that much of the resistance to systemd (and some other subsystems) exists because it is seen (and IMHO not entirely in error) as part of a strategy in that direction. And it certainly matters to Arch users who by definition are their own admins, and who want the flexibility without having to disable, bypass or fight things they don't need and that get in the way. Having to do that with other distros was what drove me to Arch. All this also means that it is futile to attack L.P. personally (as seems to happen) - he is just a clever and ambitious young man used as a pawn in a game that is much bigger than he is. Ciao, -- FA A world of exhaustive, reliable metadata would be an utopia. It's also a pipe-dream, founded on self-delusion, nerd hubris and hysterically inflated market opportunities. (Cory Doctorow)
On Fri, 17 Aug 2012 09:57:51 +0000 Fons Adriaensen <fons@linuxaudio.org> wrote: <snip> +1 to every word. I ran LFS for three years, partly because I wanted to learn and partly to avoid the issues you mention. I left only because at that point in my life it was too time-consuming and Arch offered an ideal alternative. Geoff
On Fri, 17 Aug 2012 04:08:32 -0500 C Anthony Risinger <anthony@xtfx.me> wrote: <snip>
the boot process isn't really that interesting (once you know/understand it anyway ... if not i encourage you to explor ;-) -- every distro pretty much does it the same way, but pointlessly independent, thus resulting in annoying differences that are completely irrelevant to begin with.
Thank you for a measured reply Anthony. I take your points. I have also watched LP's FOSDEM systemd presentation on Youtube (understanding about 80% of it), and read most of the links provided by other posters (especially the internal debate between Red Hat devs). I understand that there are advantages, but I am left with the lingering impression that systemd is part of a larger project, - as discussed by Fons Adriaensen in this thread. It bothers me. Geoff
On Fri, Aug 17, 2012 at 12:18 PM, Geoff <capsthorne@yahoo.co.uk> wrote:
On Fri, 17 Aug 2012 04:08:32 -0500 C Anthony Risinger <anthony@xtfx.me> wrote:
<snip>
the boot process isn't really that interesting (once you know/understand it anyway ... if not i encourage you to explor ;-) -- every distro pretty much does it the same way, but pointlessly independent, thus resulting in annoying differences that are completely irrelevant to begin with.
Thank you for a measured reply Anthony. I take your points. I have also watched LP's FOSDEM systemd presentation on Youtube (understanding about 80% of it), and read most of the links provided by other posters (especially the internal debate between Red Hat devs). I understand that there are advantages, but I am left with the lingering impression that systemd is part of a larger project, - as discussed by Fons Adriaensen in this thread. It bothers me.
"Part of a larger project". Yes, I have the same feeling, but it doesn't have to be necessarily a bad thing. That would depend, in part, on what the larger project is. For example, upstart is part of a larger project (Ubuntu), so is git (Linux). Hey, even GCC is part of a bigger project (GNU). Some people fear that if you use it you will be giving something to that unknown project behind systemd. But if it takes you where you don't want to go, it can be forked. It has happened before with bigger projects. That's the great thing of opensource, you don't have put up with the powers behind: fork - improve - share. But for the time being they didn't give me any reason to believe that they have a hidden agenda or that they are evil, or anything... -- Rodrigo
On Fri, 17 Aug 2012 14:03:17 +0200 Rodrigo Rivas <rodrigorivascosta@gmail.com> wrote: <snip>
Some people fear that if you use it you will be giving something to that unknown project behind systemd. But if it takes you where you don't want to go, it can be forked. It has happened before with bigger projects.
<snip> Yes, but I have the feeling (just my feeling, I can be wrong), that the epoch when the best and brightest people did fork projects of this kind may be past, or at least passing. I am not blaming anyone, - the constraints of time / career are perhaps more difficult to contend with than they were 20 years ago. Further, the success of linux in fields far removed from my irrelevant little desktop brings opportunities and problems which may interest those people more. Times change, but one is allowed to regret some of the consequences. Geoff
But if it takes you where you don't want to go, it can be forked. It has happened before with bigger projects.
That's true but no one can do that on a whim and apparently (Redhat Dev) the code is rediculously hard to follow and review. I believe the ones who would do that will likely just start from scratch or use an existing shell based init and are more likely to fork upstart as a basis with systemd as a reference. -- _______________________________________________________________________ 'Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface' (Doug McIlroy) _______________________________________________________________________
On Fri, Aug 17, 2012 at 04:08:32AM -0500, C Anthony Risinger wrote:
initiatives like this are not removing choice
... Kinda. This initiative doesn't remove choice. It is a natural consequence of the greater linux ecosystem choosing to abandon some choices. Am convinced that moving to systemd is probably the right thing for Arch at this point. But let's not get overzealous in the proselyting.
On Fri, Aug 17, 2012 at 4:08 AM, C Anthony Risinger <anthony@xtfx.me> wrote:
On Thu, 16 Aug 2012 16:22:56 -0500 Myra Nelson <myra.nelson@hughes.net> wrote:
<snip>
I agree. I have read all the current threads and the few words which struck me with greatest force were in a post from Marti Raudsepp, where he said
advantage of systemd is "... less fragmentation between Linux distribution". I have been full time on linux for nearly 13 years now, with the most recent five of those on Arch, and for me one of the principal attractions of the OS has always been fragmentation between distributions. The recent changes to Arch (and I dare say other distros which I do not monitor), all seem to me to
On Fri, Aug 17, 2012 at 2:57 AM, Geoff <capsthorne@yahoo.co.uk> wrote: that an point
in the direction of drab ecumenism - eventually "One distro to rule them all ...." Sooner or later Arch will be distinguished only by its excellent rolling release model and the wonderful pacman. Perhaps all this was inevitable. I do not intend anything I say as a criticism of the devs - it is their distro and they are entitled to do what they choose with it. But it does make me sad.
the boot process isn't really that interesting (once you know/understand it anyway ... if not i encourage you to explor ;-) -- every distro pretty much does it the same way, but pointlessly independent, thus resulting in annoying differences that are completely irrelevant to begin with.
no flexibility is lost by moving to systemd, and really, much more gained: wider userbase, wider testbase, simple units to write, simple units to read, loosely coupled ordering, implicit dependencies, Grand Unified logging capabilities, and of course, much better speed/reliability/robustness.
take the (unanimous?) sentiments exhibiting by our developers -- and *many* developers elsewhere, in a great variety of capacities/niches -- as a sign of the good things to come. i fully expect 99%+ will have little trouble adjusting, and 98% will at that time agree it was clearly the right choice.
initiatives like this are not removing choice -- they are consolidating the common bits so developers can get back to writing the interesting next-gen stuff instead of spinning wheels or putting out fires.
like most things in life, balance is key to good health.
--
C Anthony
C. Anthony: First let me apologize for you winding up with my post twice. One thing that struck me from one of Tom's replies was "as a computer scientist". Now my degree is in Geology and I didn't get to finish my MS in Geophysics, not bragging just trying to set the stage for my discussion. My programming skills started in the age of punch cards and fortran and I skipped assembly. I'm begining to see the disparity in this conversation. On one side we have users and on the other side, so it seems, the devs are "computer scientists" trying to bring the next generation to the world. A very worthy and laudable effort. Please forgive the skeptic in me for saying, for some of us this isn't our first rodeo and for some of us ( reads: I've been this way for 60 years and it ain't gonna change any time soon) arguements put forth about how simple things will become and how much better things will be have been heard so many times with so little results, we have deaf ears. The proof is always in the pudding and when that time comes, maybe, I'll believe it. The reason for differentiating between users and scientists was this. Too many people in the world have come to distrust scientists. Just look at the FUD that's come to this discussion. It's starting to remind me of an old fashioned lynch mob. Now both sides have dug their feet in and refuse to listen to each other. That was the point of my original post, to change the discussion. To attempt to make the discussion meaningful. I would like to take you to task on one point.
if not i encourage you to explor ;-) -- every distro pretty much does it the same way, but pointlessly independent, thus resulting in annoying differences that are completely irrelevant to begin with.
This may be accurate, it may be precise, it may make sense, but somewhere someone thought it was the right way to do things. That does not, nor will it ever, make it irrelevant. It's the beauty of using Linux. It's flexible, one can make it work. I know first hand what happens when a scientist attempts to make someone believe something is irrelevant and it ain't pretty. It follows my version of Einstein's theory or relativity, "What's relative to you may or may not be relative to me, or relative to me in the same way". I know all those involved are busy with their lives, school, work, etc, and Arch users are supposed to be savvy enough to figure all this out on their own. But consider this: For example, you might feel in your gut that a particular design or algorithm is the right way to go and that other suggestions aren’t as effective. Great. Now prove it. It could be your expert intuition at work, or maybe it’s just a cognitive bias or other bug. You need to get some feedback: create a prototype, run some unit tests, and chart some benchmarks. Do what you need to do to prove that your idea is a good one, because your intuition may have been wrong. [94] Feedback is the key to agile software development for precisely this reason: software development depends on people. And as we’ve seen here, people have bugs, too. In short, we’re all nuts—one way or another. Despite our best intentions, we need to double-check ourselves and each other. You need unit tests for yourself, too. Testing Yourself When you are dead solid convinced of something, ask yourself why. You’re sure the boss is out to get you. How do you know? Everybody is using Java for this kind of application. Says who? You’re a great/awful developer. Compared to whom? How do you know? To help get a bigger picture perspective and test your understanding and mental model, ask yourself something like the following questions:[95] - How do you know? - Says who? - How specifically? - How does what I’m doing cause you to...? - Compared to what or whom? - Does it always happen? Can you think of an exception? - What would happen if you did (or didn’t)? - What stops you from...? Is there anything you can actually measure? Get hard numbers on? Any statistics?[96] What happens when you talk this over with a colleague? How about a colleague who has a very different viewpoint from your own? Do they passively agree? Is that a danger sign? Do they violently oppose the idea? Does that give it credibility? Or not?
From "Pragmatic Thinking and Learning" Refactor Your “Wetware”Andy HuntWe all have inate hardware bugs and preceptions, and we all need to debug ourselves.
Myra -- Life's fun when your sick and psychotic!
On Fri, Aug 17, 2012 at 11:08 AM, C Anthony Risinger <anthony@xtfx.me> wrote:
no flexibility is lost by moving to systemd, and really, much more gained: wider userbase, wider testbase, simple units to write, simple units to read, loosely coupled ordering, implicit dependencies, Grand Unified logging capabilities, and of course, much better speed/reliability/robustness.
These are all unwarranted assumptions. I would like to see the evidence for each one of these claims, and if you don't have hard evidence at best these are *opinions*. I do have contrary evidence for some of these, but I'm not claiming anything, you are, so you have the burden of proof.
take the (unanimous?) sentiments exhibiting by our developers -- and *many* developers elsewhere, in a great variety of capacities/niches -- as a sign of the good things to come. i fully expect 99%+ will have little trouble adjusting, and 98% will at that time agree it was clearly the right choice.
Maybe, maybe not, but is it the right choice *now*? That's the question.
initiatives like this are not removing choice
Yes they are. I don't want to use systemd, what will be my choice? -- Felipe Contreras
2012/8/22 Felipe Contreras <felipe.contreras@gmail.com>:
On Fri, Aug 17, 2012 at 11:08 AM, C Anthony Risinger <anthony@xtfx.me> wrote:
no flexibility is lost by moving to systemd, and really, much more gained: wider userbase, wider testbase, simple units to write, simple units to read, loosely coupled ordering, implicit dependencies, Grand Unified logging capabilities, and of course, much better speed/reliability/robustness.
These are all unwarranted assumptions. I would like to see the evidence for each one of these claims, and if you don't have hard evidence at best these are *opinions*. I do have contrary evidence for some of these, but I'm not claiming anything, you are, so you have the burden of proof.
take the (unanimous?) sentiments exhibiting by our developers -- and *many* developers elsewhere, in a great variety of capacities/niches -- as a sign of the good things to come. i fully expect 99%+ will have little trouble adjusting, and 98% will at that time agree it was clearly the right choice.
Maybe, maybe not, but is it the right choice *now*? That's the question.
Some upstream package are start to require systemd support. Udev, Polkit is just an example. This is not Arch decision. It is the decision made by upstream. Arch just follow the trend. Add as the poll shows: More Arch users(80%) agree with upstream for this change. There are indeed some corner cases that systemd not support. This is exact the reason Arch should encourage users to try systemd out. If there is indeed problem, they can just remove init= kernel parameter and report it, wait for it been fixed. If this step is not take, most essential package require systemd, Arch users have to switch in short time. There will be little time left to find and fix issue. This situation is the worst and should be avoided. Leon
initiatives like this are not removing choice
Yes they are. I don't want to use systemd, what will be my choice?
-- Felipe Contreras
On Wed, Aug 22, 2012 at 6:22 AM, Leon Feng <rainofchaos@gmail.com> wrote:
2012/8/22 Felipe Contreras <felipe.contreras@gmail.com>:
Maybe, maybe not, but is it the right choice *now*? That's the question.
Some upstream package are start to require systemd support. Udev, Polkit is just an example.
And I say this is extremely bad news. Make GTK+ depend on GNOME, and guess what will happen: people will stop using GTK+ (or fork it). Make PolicyKit depend on systemd and people will stop using it. I for one look forward to alternatives to udev, systemd and Polkit (and all the packages that depend on systemd). And let's remember that not every Arch Linux user uses Polkit (right?).
This is not Arch decision. It is the decision made by upstream. Arch just follow the trend. Add as the poll shows: More Arch users(80%) agree with upstream for this change.
Yes, they agree with the change, but the poll doesn't ask *when* this change should happen.
There are indeed some corner cases that systemd not support. This is exact the reason Arch should encourage users to try systemd out. If there is indeed problem, they can just remove init= kernel parameter and report it, wait for it been fixed.
Yes, people should be trying systemd *now*, but what happens if in the small percentage of users that are doing this you can already see problems? This should hint that the move to make it the default should be delayed for *later*. Cheers. -- Felipe Contreras
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, \begin{quote{} Add as the poll shows: More Arch users(80%) agree with upstream for this change. \end{quote} Source?...And which poll? I don't remember that some has been opened. Cheers, Jakob -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJQNPDLAAoJEOl7hkDId7YmrCsQAIgQSfSRaLQTQpfUfVuE+My3 u2/ugvXds87/GfV00beNJHW+yPX+ey2kZ6h9vhZ4km8l6fiyIc6hW8iCxNR+c0PF mI3N48flX0VcbIc10z2p5+euK9wDZWm7SP7L8nUH0cgc8QEB2llX2pi4YliFRl71 9nVtQ+EZDJ3p/gYM3MykbdwtzXiIaBJNxaoZzM7bRLt6r/D/NbrTT9FMFA9mJg06 br+yN+0tDmxv5uv2K+qTRTFWY8GWs9W6jrhePvxvxpyr4jMXQiReq81NL9z8XeOZ 3MaOnVMN5wYvCSZ7zm6oo4HIxuUi5WwGyZreZQ7lA56H+MpoF/yiVIDNeESZYn2L Kqi6Vq76XFbHOjI+w36q4dm6wS/xKifsnv7chMPvoUJVnZyT8Od2N2t1KsC0RhxG xcuW46pFPYHsyxqPZEB41W3zNQWAUr3R0ROLm3e2jfV4bIQ3wWFpSzsa6nq/MdyT FAUEveOwzF57Ao6EI3ZzGMuow/ACIrA+0rNIhseSjr2klnLNH+W2jPrO/KNAb5rs MD5a7WVwptoby388FmCE7nOeiGVhDaHkMJHcVQ40t1iaJySODQWjGzrNWXK81DBO /794cX+fEqR7mGBGCQFwkVNPuKQz4SR3bgSAGCBFozwe7gfe7UU2DpCPDhfdWDyr jx5VhmnOwxYv2i4dUnuy =SIyI -----END PGP SIGNATURE-----
On 08/22/2012 10:46 AM, Jakob Herrmann wrote:
Hi,
\begin{quote{} Add as the poll shows: More Arch users(80%) agree with upstream for this change. \end{quote} Source?...And which poll? I don't remember that some has been opened.
Cheers, Jakob
It was a poll started by a member in another thread on this list (titled "SystemD poll") Here is the link: http://www.easypolls.net/poll.html?p=502d2113e4b02c3adb09a939 -- Andre Goree andre@drenet.info
2012/8/17 Geoff <capsthorne@yahoo.co.uk>:
On Thu, 16 Aug 2012 16:22:56 -0500 Myra Nelson <myra.nelson@hughes.net> wrote:
<snip>
I agree. I have read all the current threads and the few words which struck me with greatest force were in a post from Marti Raudsepp, where he said that an advantage of systemd is "... less fragmentation between Linux distribution". I have been full time on linux for nearly 13 years now, with the most recent five of those on Arch, and for me one of the principal attractions of the OS has always been fragmentation between distributions. The recent changes to Arch (and I dare say other distros which I do not monitor), all seem to me to point in the direction of drab ecumenism - eventually "One distro to rule them all ...." Sooner or later Arch will be distinguished only by its excellent rolling release model and the wonderful pacman. Perhaps all this was inevitable. I do not intend anything I say as a criticism of the devs - it is their distro and they are entitled to do what they choose with it. But it does make me sad.
Before Ubuntu start upstart, there is simply no choice but sysvinit. No one complain it will end up to "One distro to rule them all ....". Leon
Geoff
On Thu, Aug 16, 2012 at 10:22 PM, Myra Nelson <myra.nelson@hughes.net> wrote:
of lib and lib64 to /usr/lib, I'm basically ambivalent. I still don't like not being able to put /usr on a separate partition, I know there's a mkinitcpio hook to cover that, but I can see the logic in cleaning up the
Thank you for a reasoned posting - one comment here about the issue of /usr on a separate partition - if you put /usr on a separate partition and then made a bind mount to / would that not work? I have not tried it though! I have been doing this for /home which is a directory /opt/home and /opt is a separate partition - I then bind mount it to /home as a directory in the root partition. It has never given a problem so I wondered if the analogous technique might work for /usr too? This is a side comment and I am not trying to subvert the main thread discussion here. -- mike c
I used to have seperate /usr partition, previous year, I didn't remember details but there was a bug that force me to reinstall my sytem without a sperate /usr partition. On Fri, Aug 17, 2012 at 10:14:58AM +0100, mike cloaked wrote:
On Thu, Aug 16, 2012 at 10:22 PM, Myra Nelson <myra.nelson@hughes.net> wrote:
of lib and lib64 to /usr/lib, I'm basically ambivalent. I still don't like not being able to put /usr on a separate partition, I know there's a mkinitcpio hook to cover that, but I can see the logic in cleaning up the
Thank you for a reasoned posting - one comment here about the issue of /usr on a separate partition - if you put /usr on a separate partition and then made a bind mount to / would that not work? I have not tried it though!
I have been doing this for /home which is a directory /opt/home and /opt is a separate partition - I then bind mount it to /home as a directory in the root partition. It has never given a problem so I wondered if the analogous technique might work for /usr too?
This is a side comment and I am not trying to subvert the main thread discussion here.
-- mike c
On Fri, Aug 17, 2012 at 10:14 AM, mike cloaked <mike.cloaked@gmail.com> wrote:
On Thu, Aug 16, 2012 at 10:22 PM, Myra Nelson <myra.nelson@hughes.net> wrote:
of lib and lib64 to /usr/lib, I'm basically ambivalent. I still don't like not being able to put /usr on a separate partition, I know there's a mkinitcpio hook to cover that, but I can see the logic in cleaning up the
Thank you for a reasoned posting - one comment here about the issue of /usr on a separate partition - if you put /usr on a separate partition and then made a bind mount to / would that not work? I have not tried it though!
I have been doing this for /home which is a directory /opt/home and /opt is a separate partition - I then bind mount it to /home as a directory in the root partition. It has never given a problem so I wondered if the analogous technique might work for /usr too?
Actually the answer to the /usr partition question seems to already be in the arch wiki at https://wiki.archlinux.org/index.php/Systemd#Arch_integration "Warning: /usr must be mounted and available at bootup (this is not particular to systemd). If your /usr is on a separate partition, you will need to make accommodations to mount it from the initramfs and unmount it from a pivoted root on shutdown. See the mkinitcpio wiki page and freedesktop.org#separate-usr-is-broken" https://wiki.archlinux.org/index.php/Mkinitcpio#.2Fusr_as_a_separate_partiti... http://www.freedesktop.org/wiki/Software/systemd/separate-usr-is-broken I should have read up on this before my previous post! -- mike c
https://wiki.archlinux.org/index.php/Systemd#Arch_integration
"Warning: /usr must be mounted and available at bootup (this is not particular to systemd). If your /usr is on a separate partition, you will need to make accommodations to mount it from the initramfs and unmount it from a pivoted root on shutdown. See the mkinitcpio wiki page and freedesktop.org#separate-usr-is-broken"
https://wiki.archlinux.org/index.php/Mkinitcpio#.2Fusr_as_a_separate_partiti... http://www.freedesktop.org/wiki/Software/systemd/separate-usr-is-broken
The link actually says this has nothing to do with systemd but I think that's lies and the arch post is correct in that it's not just systemd.
I should have read up on this before my previous post!
Aside from most of the pro points being incorrect like actually widening the difference between unixes (solaris being a minority), there are things they have overlooked too. _________________________________________________________________________ "we now just expect /usr to be pre-mounted from inside the initramfs, to be available before 'init' starts" _________________________________________________________________________ Well you used to execute /sbin/init and rc scripts after mounting /. so what's the real reason that hasn't been bothered to be mentioned with lennart pointing back to the thread that doesn't mention it. Also Lennart says _________________________________________________________________________ "Now you only have to pull out your rescue CD, if /boot is corrupted and not if / is corrupted." _________________________________________________________________________ Not true, you could always fix some errors but lots of things can not be fixed this way else the kernel/initramfs would be or as large as the filesystem which equates to more ignorance of busybox and embedded. On OpenBSD the critical files are on / and so is the kernel. /usr holds the well audited and so files that almost never need updating. /usr/local holds packages so you can update them whilst reducing the risk of trojaning login or damaging critical filesystems for example. You can easily update and backup the root filesystem too. /usr on Linux is far far more likely to have problems mounting as it is large and heavily used so actually you have made Linux less reliable not more reliable (as lennart argues) just like systemd does to. If it has all these functional bugs that seem to still be appearing and is so difficult to review the code then the only people that are likely to find the security bugs are the criminals and those getting paid many more times than Google pay for bugs in chrome not to mention that those who can find those bugs will not be running and so auditing systemd in any case. The simplicity of controlling the init scripts was a major factor in my choice of arch. The fast updates and simple and secure default stance led me to believe Arch held security highly and which I no longer believe. So as soon as my free time permits (which unfortunately may be a while). I shall have to join Baho in his quest for another OS. The decision to move to systemd actually has very little to do directly with my decision but the manner of the decision process and unbalanced summing up in arch is far more worrying and much more one sided than the summary made by RedHat devs. There may be more developer contention and balance than was dared to be made public, but it is unclear to me. A couple of devs murmured dislike of systemd, a couple made rediculous comments (not you Tom, you got hot headed and a little offensive at times but I understood why) but most devs reacted to lets move to systemd now for an easy life and an easy life has nothing to do with what I strive to achieve. Suggestion for distros without systemd and which hold security or code correctness and little enabled by default are welcome. Tom: Seccomp is only really there for a very particular usage by Google in Chrome. It is far too large grained to add security to daemons. Kc -- _______________________________________________________________________ 'Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface' (Doug McIlroy) _______________________________________________________________________
On Thu, Aug 16, 2012 at 10:22 PM, Myra Nelson <myra.nelson@hughes.net> wrote:
There has been much ado on the arch-general mailing list about the move to systemd. I participated in part of it, but like others finally tired of "seeing a dead horse kicked" over and over and over. So much so that the last dev who really paid attention to the list said goodbye. Yet the free for all continues. I think a comment on Allan's blog post might illustrate
Here are some stats that are quite useful in terms of the number of users of systemd: At http://smolt.fedoraproject.org/static/stats/stats.html Using the "kernel" tab we see that the approximate number of systems that have their system details logged using Fedora 16 is over 100,000 if you total the entries for x86_64 and the i686 and i686 PAE kernels most of which are systems using systemd. Given that so many machines are currently running systemd it can't be all that bad! This is of course only for Fedora but machines are also running systemd in other distributions as well. Speaks volumes really - and again supports the decision that the devs have made - with a much larger user base than the straw poll made available by another poster on this mailing list. -- mike c
On 17 August 2012 11:31, mike cloaked <mike.cloaked@gmail.com> wrote:
On Thu, Aug 16, 2012 at 10:22 PM, Myra Nelson <myra.nelson@hughes.net> wrote:
There has been much ado on the arch-general mailing list about the move to systemd. I participated in part of it, but like others finally tired of "seeing a dead horse kicked" over and over and over. So much so that the last dev who really paid attention to the list said goodbye. Yet the free for all continues. I think a comment on Allan's blog post might illustrate
Here are some stats that are quite useful in terms of the number of users of systemd:
At http://smolt.fedoraproject.org/static/stats/stats.html
Using the "kernel" tab we see that the approximate number of systems that have their system details logged using Fedora 16 is over 100,000 if you total the entries for x86_64 and the i686 and i686 PAE kernels most of which are systems using systemd. Given that so many machines are currently running systemd it can't be all that bad! This is of course only for Fedora but machines are also running systemd in other distributions as well.
Speaks volumes really - and again supports the decision that the devs have made - with a much larger user base than the straw poll made available by another poster on this mailing list.
-- mike c
Thank you for starting a thread that (crosses fingers) will stay rant free & intelligent. After reading all the who-har in the other's I decided to install systemd on my lappy & TBH was very pleased with the result. That being that the install itself was hassle free & the configuration was bizarrely intuitive & easy, I had a small issue that lightdm-unity-greeter was not starting, so I made a note of the error given & checked the .service, .device, .target files & was astounded to see seriously plain text to the point where I followed through the process systemd took & worked out the problem reboot & bingo I fixed it without even looking on the web! I still have sysVinit installed & will begin cloning the system prior to removing sysVinit, one point is that my Arch-laptop has one partition for the whole OS but when i come to try this on my desktop I will be facing lots of different drives & partitions which I feel may also be relatively easy to resolve & get working. Either way I think I have the same feeling on this as other Archers, that being that we came to arch to live on the OS edge & take advantage of what is new in the linux world whilst trying to stick with the KISS principle. I think systemd is a step forward but the truth will be in the pudding. Again thanks for a sane thread :) -- Regards Thomas Rand
On 17/08/2012 5:47 AM, Thomas Rand wrote:
Thank you for starting a thread that (crosses fingers) will stay rant free & intelligent.
After reading all the who-har in the other's I decided to install systemd on my lappy & TBH was very pleased with the result. That being that the install itself was hassle free & the configuration was bizarrely intuitive & easy, I had a small issue that lightdm-unity-greeter was not starting, so I made a note of the error given & checked the .service, .device, .target files & was astounded to see seriously plain text to the point where I followed through the process systemd took & worked out the problem reboot & bingo I fixed it without even looking on the web!
I also decided I should install systemd on my laptop last night. (At a time when I didn't actually have much time to work on it, because that's the kind of guy I am ;) ). I agree that the install itself was very easy, and with the recent rc.conf changes there was very little else to configure except to setup the starting services. I did hit a couple issues: Arch doesn't ship with units for all the daemons I use. I was able to copy the mysqld instructions out of the wiki, but my attempt at getting timidity working on my own failed. (Again, I suspect I will be able to get it working, but I was doing things quickly.) The other issue I hit was that it didn't like one of my fstab entries, for a loop back file system in my home partition that I use to fake a small drive for one of my old wine games. This error caused it to boot to a root console where I could see the file system in error. I haven't yet tried to debug the line, but once I commented it out I was able to boot my system. Stephen E. Baker [snip]
Again thanks for a sane thread :)
+1
On 17/08/2012 8:34 AM, Stephen E. Baker wrote:
The other issue I hit was that it didn't like one of my fstab entries, for a loop back file system in my home partition that I use to fake a small drive for one of my old wine games. This error caused it to boot to a root console where I could see the file system in error. I haven't yet tried to debug the line, but once I commented it out I was able to boot my system.
Some people have been replying off list with suggestions. With some help on #systemd I added x-systemd.automount to the options on the fstab and now that file system is working fine. I've now removed initscripts and sysvinit and everything is working nicely. I'm not convinced for me that there was much real advantage to the move, but there doesn't seem to be any disadvantage either. Stephen E. Baker
On Fri, Aug 17, 2012 at 10:31 AM, mike cloaked <mike.cloaked@gmail.com> wrote:
most of which are systems using systemd. Given that so many machines are currently running systemd it can't be all that bad! This is of
How many machines are currently running Windows*? Jorge Almeida
2012/8/17 mike cloaked <mike.cloaked@gmail.com>:
On Thu, Aug 16, 2012 at 10:22 PM, Myra Nelson <myra.nelson@hughes.net> wrote:
There has been much ado on the arch-general mailing list about the move to systemd. I participated in part of it, but like others finally tired of "seeing a dead horse kicked" over and over and over. So much so that the last dev who really paid attention to the list said goodbye. Yet the free for all continues. I think a comment on Allan's blog post might illustrate
Here are some stats that are quite useful in terms of the number of users of systemd:
At http://smolt.fedoraproject.org/static/stats/stats.html
Using the "kernel" tab we see that the approximate number of systems that have their system details logged using Fedora 16 is over 100,000 if you total the entries for x86_64 and the i686 and i686 PAE kernels most of which are systems using systemd. Given that so many machines are currently running systemd it can't be all that bad! This is of course only for Fedora but machines are also running systemd in other distributions as well.
Speaks volumes really - and again supports the decision that the devs have made - with a much larger user base than the straw poll made available by another poster on this mailing list.
Maybe there are some misunderstanding to be clear: Even if Arch support systemd as default, it does not means all Arch users are force to use systemd. Users prefer current initscripts can still use it. It is just like the choice between Grub/Grub2/syslinux. Leon.
-- mike c
I made the move to systemd on my flash drive install 2 days ago, and I have to say I am impressed. The only extra thing I needed to do was to write a unit file for espeakup, since there isn't yet a unit in the package or in systemd-arch-units. Writing the new .service file was extremely quick and painless, and worked the very first time I rebooted after enabling it. I didn't think it would be possible to make a very old computer with USB 1.1 boot or shutdown any faster, but systemd certainly made it happen with a minimum amount of effort, and everything works as well or better than it did before the migration. I also like the ease of use and configuration of systemd units and the intuitive layout of the files and directories. I also found the systemctl and journalctl commands to be very intuitive and easy to use. I only have to remember to include the .service suffix when enabling or disabling a service, as this process requires the complete unit name rather than just the name of the service, unlike starting, stopping, etc. Although there is always room for improvement in any software, systemd has come quite a long way in a relatively short amount of time, and continues to improve quickly. I would like to thank the systemd developers for their hard work, and the Arch developers for seeing systemd as a viable alternative to sysvinit and other aging and/or fragmented parts of a Linux system. Add me to the list of happy systemd users. ~Kyle
2012/8/18 Kyle <kyle@gmx.ca>:
I made the move to systemd on my flash drive install 2 days ago, and I have to say I am impressed. The only extra thing I needed to do was to write a unit file for espeakup, since there isn't yet a unit in the package or in systemd-arch-units. Writing the new .service file was extremely quick and painless, and worked the very first time I rebooted after enabling it. I didn't think it would be possible to make a very old computer with USB 1.1 boot or shutdown any faster, but systemd certainly made it happen with a minimum amount of effort, and everything works as well or better than it did before the migration. I also like the ease of use and configuration of systemd units and the intuitive layout of the files and directories. I also found the systemctl and journalctl commands to be very intuitive and easy to use. I only have to remember to include the .service suffix when enabling or disabling a service, as this process requires the complete unit name rather than just the name of the service, unlike starting, stopping, etc. Although there is always room for improvement in any software, systemd has come quite a long way in a relatively short amount of time, and continues to improve quickly. I would like to thank the systemd developers for their hard work, and the Arch developers for seeing systemd as a viable alternative to sysvinit and other aging and/or fragmented parts of a Linux system. Add me to the list of happy systemd users.
Systemd support shortform service name now. See the wiki page: https://wiki.archlinux.org/index.php/Systemd#Using_Units
~Kyle
+According to Leon Feng:
Systemd support shortform service name now. See the wiki page: https://wiki.archlinux.org/index.php/Systemd#Using_Units
For now, this only seems to work for starting, stopping and reloading services. Unfortunately it doesn't yet seem to work for enabling or disabling them. If I try for example sudo systemctl enable netcfg@Kyle or sudo systemctl disable netcfg@Kyle I receive the following error: Failed to issue method call: Invalid argument If I use the .service suffix, it works as expected. sudo systemctl start netcfg@Kyle and systemctl stop netcfg@Kyle also work as expected. Maybe it's a bug, but for now, I'll just remember the .service suffix unless I find out this behaviour is indeed abnormal. Thanks for the link. The wiki page is well written and helped prevent some potentially major headaches. ~Kyle
On Thu, Aug 16, 2012 at 11:22 PM, Myra Nelson <myra.nelson@hughes.net> wrote:
Even with udev moving into systemd, an individual on the systemd mailing list has already stated his desire to finally be rid of udev altogether. He considers it an abomination.
Who is this member? It seems I joined late to the party. I also dislike udev, and I think I can replace it with something much, *much* simpler. Similarly with systemd. Just like pacman is something non-standard maintained by Arch Linux developers, perhaps we can replace the udev-systemd abomination with something else, giving people a *choice*. -- Felipe Contreras
On 22.08.2012 01:56, Felipe Contreras wrote:
On Thu, Aug 16, 2012 at 11:22 PM, Myra Nelson <myra.nelson@hughes.net> wrote:
Even with udev moving into systemd, an individual on the systemd mailing list has already stated his desire to finally be rid of udev altogether. He considers it an abomination. Who is this member? It seems I joined late to the party. I also dislike udev, and I think I can replace it with something much, *much* simpler. Similarly with systemd.
Just like pacman is something non-standard maintained by Arch Linux developers, perhaps we can replace the udev-systemd abomination with something else, giving people a *choice*.
Well, then why don't you go ahead and come back with some software that is better and simpler?
On Wed, Aug 22, 2012 at 7:56 AM, Felipe Contreras <felipe.contreras@gmail.com> wrote:
On Thu, Aug 16, 2012 at 11:22 PM, Myra Nelson <myra.nelson@hughes.net> wrote:
Even with udev moving into systemd, an individual on the systemd mailing list has already stated his desire to finally be rid of udev altogether. He considers it an abomination.
Who is this member? It seems I joined late to the party. I also dislike udev, and I think I can replace it with something much, *much* simpler. Similarly with systemd.
Just like pacman is something non-standard maintained by Arch Linux developers, perhaps we can replace the udev-systemd abomination with something else, giving people a *choice*.
Not sure why you use 'we' here, considering you've repeatedly disparaged the Arch devs and Arch community, saying "you are breaking things" and all that rot. Code talks. Get coding.
On Wed, Aug 22, 2012 at 2:30 AM, Oon-Ee Ng <ngoonee.talk@gmail.com> wrote:
On Wed, Aug 22, 2012 at 7:56 AM, Felipe Contreras <felipe.contreras@gmail.com> wrote:
On Thu, Aug 16, 2012 at 11:22 PM, Myra Nelson <myra.nelson@hughes.net> wrote:
Even with udev moving into systemd, an individual on the systemd mailing list has already stated his desire to finally be rid of udev altogether. He considers it an abomination.
Who is this member? It seems I joined late to the party. I also dislike udev, and I think I can replace it with something much, *much* simpler. Similarly with systemd.
Just like pacman is something non-standard maintained by Arch Linux developers, perhaps we can replace the udev-systemd abomination with something else, giving people a *choice*.
Not sure why you use 'we' here, considering you've repeatedly disparaged the Arch devs and Arch community, saying "you are breaking things" and all that rot.
"We", is me and the people that don't like the systemd+udev beast, and they are a lot. And what's the point of being belligerent towards me? What could possibly be the purpose of your comment if not attack me personally. And no, I didn't disparage anyone. And no, I didn't say anything like "you are breaking things" at all. It seems you are simply unable to understand what I am saying. Cheers. -- Felipe Contreras
On Wed, Aug 22, 2012 at 2:54 AM, Felipe Contreras <felipe.contreras@gmail.com> wrote:
"We", is me and the people that don't like the systemd+udev beast, and they are a lot.
Huh? I've never seen any complaints about udev before you. Mind you, udev is around since 2003. It was merged into systemd's source, but it's not a problem to use it without running systemd. Otherwise your system won't run, don't you think? Udev provides /dev after all... Wikipedia says you can use something else, but libudev itself is in use. -- Kwpolska <http://kwpolska.tk> stop html mail | always bottom-post www.asciiribbon.org | www.netmeister.org/news/learn2quote.html GPG KEY: 5EAAEA16
"We", is me and the people that don't like the systemd+udev beast, and they are a lot.
Huh? I've never seen any complaints about udev before you. Mind you, udev is around since 2003.
Actually it's completely different to back in 2003 because of huge amounts of complaints. Check lwn.net
It was merged into systemd's source, but it's not a problem to use it without running systemd. Otherwise your system won't run, don't you think? Udev provides /dev after all... Wikipedia says you can use something else, but libudev itself is in use.
Where's the link, does it mean for dynamic /dev otherwise that's completely wrong and libudev != udev/systemd. -- _______________________________________________________________________ 'Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface' (Doug McIlroy) _______________________________________________________________________
Op 22 aug. 2012 10:59 schreef "Kevin Chadwick" <ma1l1ists@yahoo.co.uk> het volgende:
"We", is me and the people that don't like the systemd+udev beast, and they are a lot.
Huh? I've never seen any complaints about udev before you. Mind you, udev is around since 2003.
Actually it's completely different to back in 2003 because of huge amounts of complaints. Check lwn.net
It was merged into systemd's source, but it's not a problem to use it without running systemd. Otherwise your system won't run, don't you think? Udev provides /dev after all... Wikipedia says you can use something else, but libudev itself is in use.
Where's the link, does it mean for dynamic /dev otherwise that's completely wrong and libudev != udev/systemd.
Kevin, you seem to be fairly advanced user. How about creating a vm with Arch and getting an alternative to udev running? Should be an interesting experiment. Same goes for (for example) openrc. When it's working reliable for you, it should be easy enough to create some packages. In the case of init scripts, a very nice add-on would be to parse systemd's ini files (either 'live' or once). That way it would be a very easy transition for users already running systemd. For the record: this is meant as an encouragement. I would be very interested in things like this and be willing to help out. Perhaps more people on this list feel the same way. mvg, Guus
Kevin, you seem to be fairly advanced user. How about creating a vm with Arch and getting an alternative to udev running?
Seems is probably the right word. We are all fools fiddling in the dark to some degree with different ground covered. Some of us have more powerful torches and some keep to the lit roads more ;-) You might find this hard to believe and maybe arch wasn't the best choice (but not too bad so far) but a large reason of coming to Arch was to reduce my time spent on admin and not increase it and I can't afford any time at the moment. I don't really have an issue with udev, it breaks little and is perfectly replaceable. Build time will increase now but more options will become more prominent or it will fork if it isn't suitably maintained. The kernel is unlikely to break anything :-) on purpose or for a long time atleast. -- _______________________________________________________________________ 'Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface' (Doug McIlroy) _______________________________________________________________________
On Wed, Aug 22, 2012 at 12:16 PM, Guus Snijders <gsnijders@gmail.com> wrote:
Op 22 aug. 2012 10:59 schreef "Kevin Chadwick" <ma1l1ists@yahoo.co.uk> het volgende:
Kevin, you seem to be fairly advanced user. How about creating a vm with Arch and getting an alternative to udev running?
I do this all the time with buildroot; udev is a choice, and I often have trouble compiling it because it depends on so many things, like specific kernel configurations, and certain toolchain options. The fact of the matter is that udev doesn't do much for me, CONFIG_DEVTMPFS=y and CONFIG_DEVTMPFS_MOUNT=y does most of the job, the rest is loading the right modules at boot time, which can be done with a simple script. There's also mdev from busybox, but it's too simple, I don't really understand what is the point of it. But there's certainly people that don't use udev at all: http://wiki.gentoo.org/wiki/Mdev Cheers. -- Felipe Contreras
Op 22 aug. 2012 14:07 schreef "Felipe Contreras" <felipe.contreras@gmail.com> het volgende:
On Wed, Aug 22, 2012 at 12:16 PM, Guus Snijders <gsnijders@gmail.com>
wrote:
Op 22 aug. 2012 10:59 schreef "Kevin Chadwick" <ma1l1ists@yahoo.co.uk> het volgende:
How about creating a vm with Arch and getting an alternative to udev running?
I do this all the time with buildroot; udev is a choice, and I often have trouble compiling it because it depends on so many things, like specific kernel configurations, and certain toolchain options. The fact of the matter is that udev doesn't do much for me, CONFIG_DEVTMPFS=y and CONFIG_DEVTMPFS_MOUNT=y does most of the job, the rest is loading the right modules at boot time, which can be done with a simple script. There's also mdev from busybox, but it's too simple, I don't really understand what is the point of it.
Looks like i need to do some catching up ;-). Udev has worked fine for me, so my interest is mostly academic. Just in case, it's always good to learn about alternatives. Thanks. mvg, Guus
I do this all the time with buildroot; udev is a choice, and I often have trouble compiling it because it depends on so many things, like specific kernel configurations, and certain toolchain options. The fact of the matter is that udev doesn't do much for me, CONFIG_DEVTMPFS=y and CONFIG_DEVTMPFS_MOUNT=y does most of the job, the rest is loading the right modules at boot time, which can be done with a simple script. There's also mdev from busybox, but it's too simple, I don't really understand what is the point of it.
Looks like i need to do some catching up ;-).
Udev used to do a lot more but a lot of it's functionality was taken into the kernel for a more sane design and after much constructive flaming ;-). It's on lwn.net. -- _______________________________________________________________________ 'Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface' (Doug McIlroy) _______________________________________________________________________
I think these discussions will not change the result for Arch. Sooner or later Arch will have to seperate its way from its KISS philosophy. While the main approach of Arch is to use vanilla software, as possible; Arch devs have to follow upstream decisions and at some point Arch and other distros fall into software those hide things from end users. I think most of the main upstream software (take systemd, KDE, GNOME and others) trying to be corporate software. Not all upstream decisions are good but we have to follow them. My two cents...
trying to be corporate software.
I've been wondering what the best term for 'corporate' or 'enterprise' software like exchange is where they change your nappies for you but also offer you razor wire to hang yourself with by giving you IE to browse the web on the mail server itself and encouraging compulsory remote wipe for clients! "http://www.h-online.com/security/news/item/iCloud-attack-began-with-Amazon-h..." Especially when these features are so ineffective that they do nothing but cost you money. http://www.wired.com/gadgetlab/2012/08/mat-honan-data-recovery/all/ -- _______________________________________________________________________ 'Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface' (Doug McIlroy) _______________________________________________________________________
On Thu, Aug 23, 2012 at 12:12:05PM +0100, Kevin Chadwick wrote:
I've been wondering what the best term for 'corporate' or 'enterprise' software like exchange is where they change your nappies for you but also offer you razor wire to hang yourself with by giving you IE to browse the web on the mail server itself and encouraging compulsory remote wipe for clients!
I've always just called it "commoditized software" when I'm not surging with invective and use the term "infantile computing BS"
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 \begin{quote} While the main approach of Arch is to use vanilla software, as possible; Arch devs have to follow upstream decisions and at some point Arch and other distros fall into software those hide things from end users. I think most of the main upstream software (take systemd, KDE, GNOME and others) trying to be corporate software. Not all upstream decisions are good but we have to follow them. My two cents... \end{quote} So which components (obviously used by the majority of Arch users) do currently have or will soon have hardcoded! dependencies to systemd? As far as i can say, Gnome doesn't and if it will, there is still the possibility for everyone to either patch it, to install it along with systemd or just to use an alternative. Folks always confront me with the argument of more and more hardcoded dependencies, but I can't find them and am still happy without systemd (besides the udev thing which in fact isn't such a thing). Cheers, Jakob -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJQNkIOAAoJEOl7hkDId7Ym33cQAIQpXVwSkSlUbDdI1lxW+A0n aajlGn1c95JeupBdAqaDq9VXB7y8TVd1suyq9KxEwflYPpPCZTlhV746OIEXApJs 8JXkm3gv2jWJEOsMzM1CcJ18bQ2ir9ouDMJ2IuGOpKLx0hmftlrRwgmota7rEPiC rLwEDLva/enA/9Vuz9+IbklNNiLabiskn+fdX8fbS4sSg0Zz8BORMFWVXnmU5ScZ 8cLJJyoWHOKjO7XGrB2UbTFYpFuUlJXriKth3Z1wP9e8BtvZXxtehYIj4r95XHga zcGri2RAoIAH0gRWjaJVam6iydPWb+fWzDyu6kY6gOzM+/4mBpSxsMlNA9nRyVx5 5QPxR6dzTJMOFUcycLJ0HIBYLNvkoTUrpWOyr5JeFFAixwln6kD3UDnwve7cnXh9 LeLDayI0oeq4DJ7Zkyu9HjaQmn+j5S3FO0i1ETYKUEgaPl3OBgLxxKBtZbnwR5wF ffEKpDGzz+qV8N/QHDMDlnvz5vjt7IGOqTG+UadmMSKr1xUo058SwgaYN1GtKKXf 2SFayrplUAYKxS7wLPrAyt4+KLqZ8416W+yTsPcDwwdDkgnFR+AlztckdY9/6q6A Fh07xzhmsQFloNv7e/VO4fAXva+PzK65/rcf2IMEJuZ6c3TZVCFl8uGqGTQBPlIE 6Tt15f6c42z7bc02sJ+W =qJe9 -----END PGP SIGNATURE-----
On Thu, Aug 23, 2012 at 04:45:34PM +0200, Jakob Herrmann wrote:
So which components (obviously used by the majority of Arch users) do currently have or will soon have hardcoded! dependencies to systemd?
udev. Upstream, Gnome has considered it.
So which components (obviously used by the majority of Arch users) do currently have or will soon have hardcoded! dependencies to systemd?
udev.
Upstream, Gnome has considered it.
You know why, because according to heise some of their longterm devs have left leaving more than half the devs being RedHat employees. p.s. I have nothing against RedHat, I value they're work, mostly the work which goes unnoticed. Unfortunately the most prominent of they're work gets a bad rep or is it more prominent because of the rep? I think both because it often has a bad user experience and interaction factor. -- _______________________________________________________________________ 'Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface' (Doug McIlroy) _______________________________________________________________________
On Tuesday 28 Aug 2012 11:16:38 Kevin Chadwick wrote:
You know why, because according to heise some of their longterm devs have left leaving more than half the devs being RedHat employees.
p.s. I have nothing against RedHat, I value they're work, mostly the work which goes unnoticed. Unfortunately the most prominent of they're work gets a bad rep or is it more prominent because of the rep? I think both because it often has a bad user experience and interaction factor.
In this context, I had shared a link where systemd devs had suggested gnome devs to consider adding systemd as a dependency due to some funcitonality which was present in systemd only. [1] What is going on I am not sure, but this shows that GNOME in future is going to have a hard dependency on systemd. -- Cheers and Regards Jayesh Badwaik stop html mail | always bottom-post www.asciiribbon.org | www.netmeister.org/news/learn2quote.html [1] https://mail.gnome.org/archives/desktop-devel-list/2011-May/msg00427.html
On Tue, 2012-08-28 at 16:43 +0530, Jayesh Badwaik wrote:
You know why, because according to heise some of their longterm devs have left leaving more than half the devs being RedHat employees.
p.s. I have nothing against RedHat, I value they're work, mostly the work which goes unnoticed. Unfortunately the most prominent of
On Tuesday 28 Aug 2012 11:16:38 Kevin Chadwick wrote: they're
work gets a bad rep or is it more prominent because of the rep? I think both because it often has a bad user experience and interaction factor.
In this context, I had shared a link where systemd devs had suggested gnome devs to consider adding systemd as a dependency due to some funcitonality which was present in systemd only. [1]
What is going on I am not sure, but this shows that GNOME in future is going to have a hard dependency on systemd.
[1] https://mail.gnome.org/archives/desktop-devel-list/2011-May/msg00427.html
If somebody doesn't want to use systemd, IMO it's easy to quit GNOME. I don't think that gcalctool and other small apps will have a dependency chain, as well as GTK. Or could it become that extreme? Sorry for the noob question, Ralf
On Wed, Aug 22, 2012 at 10:13:33AM +0200, Kwpolska wrote:
Huh? I've never seen any complaints about udev before you.
udev is kinda crufty. And it really doesn't belong inside the same monolithic program that manages startup and file- system mounting.
On Tue, Aug 21, 2012 at 6:56 PM, Felipe Contreras <felipe.contreras@gmail.com> wrote:
On Thu, Aug 16, 2012 at 11:22 PM, Myra Nelson <myra.nelson@hughes.net> wrote:
Even with udev moving into systemd, an individual on the systemd mailing list has already stated his desire to finally be rid of udev altogether. He considers it an abomination.
Who is this member? It seems I joined late to the party. I also dislike udev, and I think I can replace it with something much, *much* simpler. Similarly with systemd.
Just like pacman is something non-standard maintained by Arch Linux developers, perhaps we can replace the udev-systemd abomination with something else, giving people a *choice*.
-- Felipe Contreras
I've been in the conversation for a while. I just don't bother with the threads with all the BikeShed on them, that's why I'm the OP. The reason you have run across my posts is I don't post them to threads you are in. Way too much noise. As others have stated and I will reiterate, if you think Arch has so many non-standard packages find a distro to your liking, or come up with something better. I believe the proper terminology in my part of the world is "fish or cut bait". FYI, Lennart does not want to be rid of systemd completely, that was my error. He wants it completely absorbed into systemd. So please be polite and don't hijack another thread like you have so many others. Myra Nelson -- Life's fun when your sick and psychotic!
participants (26)
-
Andre Goree
-
Anthony ''Ishpeck'' Tedjamulia
-
atilla ontas
-
C Anthony Risinger
-
Diep Pham Van
-
Felipe Contreras
-
Fons Adriaensen
-
Geoff
-
Guus Snijders
-
Jakob Herrmann
-
Jayesh Badwaik
-
Jorge Almeida
-
Kevin Chadwick
-
Kwpolska
-
Kyle
-
Leon Feng
-
mike cloaked
-
Myra Nelson
-
Nicholas MIller
-
Oon-Ee Ng
-
Ralf Mardorf
-
Rodrigo Rivas
-
Rémy Oudompheng
-
Stephen E. Baker
-
Sven-Hendrik Haase
-
Thomas Rand