[opensuse] RE: Stability of systemd
Is systemd more reliable and stable in 12.3, than in 12.1 and 12.2 ? Or is keeping with sysvinit the better way to stay ? -- Duaine Hechler Piano, Player Piano, Pump Organ - Tuning, Servicing & Rebuilding (314) 838-5587 / dahechler@att.net / www.hechlerpianoandorgan.com Home & Business user of Linux - 13 years -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 06/15/2013 11:28 PM, Duaine Hechler wrote:
Is systemd more reliable and stable in 12.3, than in 12.1 and 12.2 ?
Or is keeping with sysvinit the better way to stay ?
What are you looking for specifically ? can't answer vague questions.. "stability" means different things depending on the context. Of course systemd has bugs like any other software, however most problems in older version are derived from issues in the openSUSE implementation and packages totally unrelated with it. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 06/15/2013 10:39 PM, Cristian Rodríguez wrote:
On 06/15/2013 11:28 PM, Duaine Hechler wrote:
Is systemd more reliable and stable in 12.3, than in 12.1 and 12.2 ?
Or is keeping with sysvinit the better way to stay ?
What are you looking for specifically ? can't answer vague questions.. "stability" means different things depending on the context.
Of course systemd has bugs like any other software, however most problems in older version are derived from issues in the openSUSE implementation and packages totally unrelated with it
Since I can't point to anything specific at the point, I'm thinking more in general. I remember with the older 2 versions, it was - highly - recommended to disable systemd and use sysvinit. So, is there a recommendation (then) ? -- Duaine Hechler Piano, Player Piano, Pump Organ - Tuning, Servicing & Rebuilding (314) 838-5587 / dahechler@att.net / www.hechlerpianoandorgan.com Home & Business user of Linux - 13 years -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 6/15/2013 8:45 PM, Duaine Hechler wrote:
On 06/15/2013 10:39 PM, Cristian Rodr�guez wrote:
On 06/15/2013 11:28 PM, Duaine Hechler wrote:
Is systemd more reliable and stable in 12.3, than in 12.1 and 12.2 ?
Or is keeping with sysvinit the better way to stay ?
What are you looking for specifically ? can't answer vague questions.. "stability" means different things depending on the context.
Of course systemd has bugs like any other software, however most problems in older version are derived from issues in the openSUSE implementation and packages totally unrelated with it
Since I can't point to anything specific at the point, I'm thinking more in general. I remember with the older 2 versions, it was - highly - recommended to disable systemd and use sysvinit. So, is there a recommendation (then) ?
Well it seems that Systemd works for me, but I find my self at a loss trying to maintain things I use to know how to deal with. There is a learning curve that I have not yet climbed. For Joe user its probably useable if not still has some of maddening bugs, but that is the purpose of opensuse, (finding bugs). For corporate use, or complex use cases, I might still prefer Sysvinit. Sysvinit may not scale well to really huge machines, but that's a problem I will never have to worry about. (I skipped all of 12.x until 12.3 came out). So on my machine I started with SystemD from the novice prospective. So far no major problems. -- _____________________________________ ---This space for rent--- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 06/15/2013 11:07 PM, John Andersen wrote:
On 6/15/2013 8:45 PM, Duaine Hechler wrote:
On 06/15/2013 10:39 PM, Cristian Rodr�guez wrote:
On 06/15/2013 11:28 PM, Duaine Hechler wrote:
Is systemd more reliable and stable in 12.3, than in 12.1 and 12.2 ?
Or is keeping with sysvinit the better way to stay ? What are you looking for specifically ? can't answer vague questions.. "stability" means different things depending on the context.
Of course systemd has bugs like any other software, however most problems in older version are derived from issues in the openSUSE implementation and packages totally unrelated with it Since I can't point to anything specific at the point, I'm thinking more in general. I remember with the older 2 versions, it was - highly - recommended to disable systemd and use sysvinit. So, is there a recommendation (then) ?
Well it seems that Systemd works for me, but I find my self at a loss trying to maintain things I use to know how to deal with. There is a learning curve that I have not yet climbed. For Joe user its probably useable if not still has some of maddening bugs, but that is the purpose of opensuse, (finding bugs). For corporate use, or complex use cases, I might still prefer Sysvinit. Sysvinit may not scale well to really huge machines, but that's a problem I will never have to worry about.
(I skipped all of 12.x until 12.3 came out). So on my machine I started with SystemD from the novice prospective. So far no major problems.
Thank you for your answer. At least for now, I'll stick with Sysvinit. Duaine -- Duaine Hechler Piano, Player Piano, Pump Organ - Tuning, Servicing & Rebuilding (314) 838-5587 / dahechler@att.net / www.hechlerpianoandorgan.com Home & Business user of Linux - 13 years -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
John Andersen said the following on 06/16/2013 12:07 AM:
On 6/15/2013 8:45 PM, Duaine Hechler wrote:
On 06/15/2013 10:39 PM, Cristian Rodr�guez wrote:
On 06/15/2013 11:28 PM, Duaine Hechler wrote:
Is systemd more reliable and stable in 12.3, than in 12.1 and 12.2 ?
Or is keeping with sysvinit the better way to stay ?
What are you looking for specifically ? can't answer vague questions.. "stability" means different things depending on the context.
Of course systemd has bugs like any other software, however most problems in older version are derived from issues in the openSUSE implementation and packages totally unrelated with it
Since I can't point to anything specific at the point, I'm thinking more in general. I remember with the older 2 versions, it was - highly - recommended to disable systemd and use sysvinit. So, is there a recommendation (then) ?
Well it seems that Systemd works for me, but I find my self at a loss trying to maintain things I use to know how to deal with. There is a learning curve that I have not yet climbed.
I'm further along that curve and I'm quite happy with systemd. I can't imagine going back to sysvinit now! It appears clunky and ad-hoc (in CMM terms). I realise that, in post years, I've built things like systemd (table driven task manager) to deal with otherwise obdurate ad-hoc applications that were implemented with a collection of scripts that were all written independently and had little in common, even though there was a very strong underlying commonality. My feeling now is 'why wasn't this done a _long_ time ago?'
For Joe user its probably useable if not still has some of maddening bugs, but that is the purpose of opensuse, (finding bugs).
Indeed. As Cristian has pointed out many of those bugs are not bugs per-se but things that have arisen from design decisions with openSuse. They are reversible since they are usually configuration issues. The problems I had with systemd were an emergent property of the way I had my prior system configured. The big hurdle was DNS, since I had this huge ad-blocker implemented in DNS (see http://pgl.yoyo.org/) and had to adjust the time-out. I also use fetchmail and that had to be made dependent on postfix and spamd. So I had to learn about .service files.
For corporate use, or complex use cases, I might still prefer Sysvinit.
One might argue that leading edge stuff is not for corporate (but if that's so why update office packages and databases and webservers and perl/php/python?) but systemd will accommodate complex configurations much more cleanly - that is visibly and more easily to modify, simply because of the highly constrained what it controls interactions.
Sysvinit may not scale well to really huge machines, but that's a problem I will never have to worry about.
Indeed, since the really massive machines are going to be running AIX or HP/UX or - drum roll, please - VM/CMS.
(I skipped all of 12.x until 12.3 came out). So on my machine I started with SystemD from the novice prospective. So far no major problems.
I'm running 12.2 with brtrfs and 12.3 and also have systemd running on a server with Mageia-v2 and a another workstation with Fedora-18. The Mageia is very conservative and the Fedora more aggressive. If there are 'bugs-that-are-bugs' as opposed to configuration matters such as those Cristian raises they aren't getting in my way. The problems-that-were-not-bugs were of my own making, usually resulting from my lack of understanding. Reading the documentation - Lennard does good stuff - and suggestions from Cristian *always* cleared that up, even if it did leave me feeling stupid for not seeing it right away. Thank you Cristian for your patience. -- We are all agreed that your theory is crazy. The question which divides us is whether it is crazy enough to have a chance of being correct. My own feeling is that it is not crazy enough. -- Niels Bohr -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Anton Aylward wrote:
Sysvinit may not scale well to really huge machines, but that's a problem I will never have to worry about.
Indeed, since the really massive machines are going to be running AIX or HP/UX or - drum roll, please - VM/CMS.
It probably depends on one's understanding of "really massive machines", but 94% of the TOP500 runs Linux. http://www.linux.com/news/enterprise/high-performance/147-high-performance/6... -- Per Jessen, Zürich (23.7°C) http://www.dns24.ch/ - free DNS hosting, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Per Jessen said the following on 06/16/2013 08:37 AM:
Anton Aylward wrote:
Sysvinit may not scale well to really huge machines, but that's a problem I will never have to worry about.
Indeed, since the really massive machines are going to be running AIX or HP/UX or - drum roll, please - VM/CMS.
It probably depends on one's understanding of "really massive machines", but 94% of the TOP500 runs Linux.
http://www.linux.com/news/enterprise/high-performance/147-high-performance/6...
I meant massive individual machines, not massive clusters of commodity PCs. I also meant massive machine that people like us are likely to use in our day jobs, the AIX, HP/UX and 'mainframes' that either run a proprietary OS or a version of UNIX specific to that architecture. I look forward to the day when IBM moves to Linux would love to admin one of IBM's mini-mainframes, those things about the size of a bar fridge or small stove which run many thousand virtual instances of Linux :-) One client ran a room full of HP 9000s, another ran a dozen T500s-HP/UX to replace a couple of large Amdahl boxes. These latter were using PA-RISC 7000 chips. Reminiscent of the big SUN servers. Oh, and the big RISC based AIX boxes. I used them too, with a a room full of RAID doing what is now called "big data" analysis. Yes, I know, commodity today is blade servers and lots of vmware VDI Windows instances. *sigh* -- "I observe that there is a good deal of German music on the programme, which is rather more to my taste than Italian or French. It is introspective, and I want to introspect." -- Sherlock Holmes, in "The Red Headed League" -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Anton Aylward wrote:
Per Jessen said the following on 06/16/2013 08:37 AM:
Anton Aylward wrote:
Sysvinit may not scale well to really huge machines, but that's a problem I will never have to worry about.
Indeed, since the really massive machines are going to be running AIX or HP/UX or - drum roll, please - VM/CMS.
It probably depends on one's understanding of "really massive machines", but 94% of the TOP500 runs Linux.
http://www.linux.com/news/enterprise/high-performance/147-high-performance/6...
I meant massive individual machines, not massive clusters of commodity PCs.
I also meant massive machine that people like us are likely to use in our day jobs, the AIX, HP/UX and 'mainframes' that either run a proprietary OS or a version of UNIX specific to that architecture.
Personally speaking, the most massive single box I'm likely to see is probably an HP box with 48 cores and a terabyte of RAM.
I look forward to the day when IBM moves to Linux would love to admin one of IBM's mini-mainframes, those things about the size of a bar fridge or small stove which run many thousand virtual instances of Linux :-)
Where have you been for the last 10 years? :-) 10+ years ago I ran a program for a <large US software firm>, promoting Linux on 390. I wrote sufficient floating-point support in Hercules to run Java on Linux/390 on Hercules. I honestly don't know the state of things today, I've been away from that field for too long, but IBM made that move to Linux long ago. -- Per Jessen, Zürich (21.4°C) http://www.dns24.ch/ - free DNS hosting, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Per Jessen said the following on 06/17/2013 02:50 AM:
Where have you been for the last 10 years?:-) 10+ years ago I ran a program for a <large US software firm>, promoting Linux on 390. I wrote sufficient floating-point support in Hercules to run Java on Linux/390 on Hercules. I honestly don't know the state of things today, I've been away from that field for too long, but IBM made that move to Linux long ago.
About 10 years ago was when I stopped replacing those big boxes in raised floor settings with Linux boxes and moved on to other things. It got rather tedious and repetitive. Yes I'm aware of the Linux-on-a-mainframe, I just haven't worked with it. That 48 core HP box you mentioned - that's blades rather than one single multi-core cpu, I presume? The boxes I was talking of (and sometimes replacing) were things like the HP-3000 series and the SA-RISK based T500 series. Non-intel architecture. -- How long did the whining go on when KDE2 went on KDE3? The only universal constant is change. If a species can not adapt it goes extinct. That's the law of the universe, adapt or die. -- Billie Walsh, May 18 2013 -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Anton Aylward wrote:
Per Jessen said the following on 06/17/2013 02:50 AM:
Where have you been for the last 10 years?:-) 10+ years ago I ran a program for a <large US software firm>, promoting Linux on 390. I wrote sufficient floating-point support in Hercules to run Java on Linux/390 on Hercules. I honestly don't know the state of things today, I've been away from that field for too long, but IBM made that move to Linux long ago.
About 10 years ago was when I stopped replacing those big boxes in raised floor settings with Linux boxes and moved on to other things. It got rather tedious and repetitive.
Yes I'm aware of the Linux-on-a-mainframe, I just haven't worked with it.
That 48 core HP box you mentioned - that's blades rather than one single multi-core cpu, I presume?
No, not blades - for instance an HP DL585 with quad opterons, each with 16 cores. -- Per Jessen, Zürich (29.8°C) http://www.dns24.ch/ - free DNS hosting, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Per Jessen said the following on 06/17/2013 08:24 AM:
No, not blades - for instance an HP DL585 with quad opterons, each with 16 cores.
Ah. Intel architecture. I think I saw something like that at a show-and-tell last year. Someone bragging that what they were running supported so many hundred "VDI" via VMWare instances. The remote terminals were older PCs using "re-purposed PCs" using RDP or something. Personally I felt the TCO quoted was a sham; the remote terminals were well equipped XP boxes but they still had to pay for the VMWare licences and the W/7 licences in the server. Now they had to have a VMware specialist who was 'tuning' and 'balancing' the server and deciding who was to have 'golden' accounts. Contrariwise ... One slow day over the winter I pulled a (yet another) junker out of the Closet of Anxieties and loaded it up with 1G of memory and a 40G disk and put, I think it was 12.2 (might have been mageiaV2 - definitely a systemd based thing) on it and set up some VNC and got 4 otherwise idle end users to try it out. I set up the server/vnc with xfce. Of _course_ there were complaints: -- why can't I have KDE? -- why can't I have firefox? this midori isn't as good as firefox -- can I have six desktops instead of four? stuff like that. But they ran Thunderbird, libreoffice and acroread OK. None of the heavy stuff like gimp. The one consistent performance complaint was -- when I move my mouse backwards and forwards fast the pointer can't keep up Lets see. This is Linux. So we have shared code. One person is running libreoffice so the code is 'in memory' and as a result the next person who starts up gets it FAST! All manner of libraries are shared. No matter how many people, there is only one copy of the code ever in core. Now this was a pretty underpowered machine. If everybody did something demanding at exactly the same time the single core, slow CPU just wasn't up to it. So long as it was simply browsing and reading mail with lots of 'pauses' everything was fine. But four users was the limit. Maybe if I was using sphinux - Sphinx Linux - http://sourceforge.net/p/sphinux/wiki/Home/ things would have been better ... :-) But my point here is that a multi-seat multi-user desktop Linux is much more resource efficient than the citrix- replacement vmware VDI. More to the point, it can run on other architectures. We know that ARM can be more efficient than Intel architecture. I wonder how many vnc sessions a Raspberry Pi can support? And then there are the RISC architectures from various vendors, not to mention ageing equipment like old Vaxen. I'm not saying there isn't a role for virtualization; I'm just giving this example of how the *NIX architecture can be more efficient and how non-Intel equipment can be used. I look forward to learning more about Wayland and about how systemd will support multi-seat using it, since that should be massively more efficient than vnc! Of course this is only Linux. being efficient, being flexible, being low cost, has never cut it against the massively funded marketing behind the Wintel machine. -- How long did the whining go on when KDE2 went on KDE3? The only universal constant is change. If a species can not adapt it goes extinct. That's the law of the universe, adapt or die. -- Billie Walsh, May 18 2013 -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Anton Aylward wrote:
Per Jessen said the following on 06/17/2013 08:24 AM:
No, not blades - for instance an HP DL585 with quad opterons, each with 16 cores.
Ah. Intel architecture.
Ignoring the PowerPC (which also powers z/OS) and maybe Itanium, what else is there (for large machines) today? HP-PA is long dead. I guess Sparc is still about, but does Sun/Oracle even build E10Ks or E25Ks any more? Unisys presumably still build the ES7000-line, but that's also Intel architecture. -- Per Jessen, Zürich (33.2°C) http://www.dns24.ch/ - free DNS hosting, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Per Jessen said the following on 06/17/2013 10:45 AM:
Anton Aylward wrote:
Per Jessen said the following on 06/17/2013 08:24 AM:
No, not blades - for instance an HP DL585 with quad opterons, each with 16 cores.
Ah. Intel architecture.
Ignoring the PowerPC (which also powers z/OS) and maybe Itanium, what else is there (for large machines) today? HP-PA is long dead. I guess Sparc is still about, but does Sun/Oracle even build E10Ks or E25Ks any more? Unisys presumably still build the ES7000-line, but that's also Intel architecture.
"Monoculture". Perhaps we need a single chip 48-core Raspberry Pi with 1T of memory :-) The fabled "Hot fuzzy golfball" -- How long did the whining go on when KDE2 went on KDE3? The only universal constant is change. If a species can not adapt it goes extinct. That's the law of the universe, adapt or die. -- Billie Walsh, May 18 2013 -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 06/17/2013 07:53 AM, Anton Aylward wrote:
Per Jessen said the following on 06/17/2013 10:45 AM:
Anton Aylward wrote:
Per Jessen said the following on 06/17/2013 08:24 AM:
No, not blades - for instance an HP DL585 with quad opterons, each with 16 cores.
Ah. Intel architecture.
Ignoring the PowerPC (which also powers z/OS) and maybe Itanium, what else is there (for large machines) today? HP-PA is long dead. I guess Sparc is still about, but does Sun/Oracle even build E10Ks or E25Ks any more? Unisys presumably still build the ES7000-line, but that's also Intel architecture.
"Monoculture".
Perhaps we need a single chip 48-core Raspberry Pi with 1T of memory :-) The fabled "Hot fuzzy golfball"
Does this fill the bill? http://www.kickstarter.com/projects/adapteva/parallella-a-supercomputer-for-... -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Bruce Ferrell said the following on 06/17/2013 11:56 AM:
On 06/17/2013 07:53 AM, Anton Aylward wrote:
Per Jessen said the following on 06/17/2013 10:45 AM:
Anton Aylward wrote:
Per Jessen said the following on 06/17/2013 08:24 AM:
No, not blades - for instance an HP DL585 with quad opterons, each with 16 cores.
Ah. Intel architecture.
Ignoring the PowerPC (which also powers z/OS) and maybe Itanium, what else is there (for large machines) today? HP-PA is long dead. I guess Sparc is still about, but does Sun/Oracle even build E10Ks or E25Ks any more? Unisys presumably still build the ES7000-line, but that's also Intel architecture.
"Monoculture".
Perhaps we need a single chip 48-core Raspberry Pi with 1T of memory :-) The fabled "Hot fuzzy golfball"
Does this fill the bill?
http://www.kickstarter.com/projects/adapteva/parallella-a-supercomputer-for-...
A very strange machine http://www.adapteva.com/introduction/ http://en.wikipedia.org/wiki/Adapteva <quote> The Epiphany architecture consists of up to 4,096 RISC microprocessors, all sharing a single flat memory space. </quote> That kind of MIMD requires a very different and very disciplined style of programming. Its not like the Linux SMNP multi-programming model where the scheduler can just assign any CPU. This is really a massively parallel coprocessor, the kind of thing that's needed for huge computational problems like modelling the solar system, a nuclear explosion, or a super-condensate. We used to call that approach 'array processors'. But at $99 or even $199 the boards are so attractive for experimenters. Not just the heavy projects, VR, calculating where Google's balloons should go http://www.zdnet.com/googles-project-loon-uses-big-networked-air-balloons-to... but also coming up with a plugin for gimp to do photo editing... Or perhaps a Wayland based VDI multi-seat for 1,000 Linux users. All for $199. EAT THAT VMWARE! Or perhaps not. It depends if this really sees scaled up production. This http://www.parallella.org/2013/05/11/the-parallella-board-now-runs-ubuntu/ is recent, but I wonder ... Maybe we'll see DES cracking in 30 seconds or less. The on to AES. -- How long did the whining go on when KDE2 went on KDE3? The only universal constant is change. If a species can not adapt it goes extinct. That's the law of the universe, adapt or die. -- Billie Walsh, May 18 2013 -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Duaine Hechler wrote:
On 06/15/2013 10:39 PM, Cristian Rodríguez wrote:
On 06/15/2013 11:28 PM, Duaine Hechler wrote:
Is systemd more reliable and stable in 12.3, than in 12.1 and 12.2 ?
Or is keeping with sysvinit the better way to stay ?
What are you looking for specifically ? can't answer vague questions.. "stability" means different things depending on the context.
Of course systemd has bugs like any other software, however most problems in older version are derived from issues in the openSUSE implementation and packages totally unrelated with it
Since I can't point to anything specific at the point, I'm thinking more in general. I remember with the older 2 versions, it was - highly - recommended to disable systemd and use sysvinit. So, is there a recommendation (then) ?
At this point, I would say stick with systemd. It _does_ still have minor teething problems, but they are really mostly corner-cases. Occasionally migration incompatibilities appear where systemd no longer supports what one was used to in sysvinit (see for instance Carlos' spamd issue re inline comments). -- Per Jessen, Zürich (19.7°C) http://www.dns24.ch/ - free DNS hosting, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Per Jessen wrote:
Duaine Hechler wrote:
On 06/15/2013 10:39 PM, Cristian Rodríguez wrote:
On 06/15/2013 11:28 PM, Duaine Hechler wrote:
Is systemd more reliable and stable in 12.3, than in 12.1 and 12.2 ?
Or is keeping with sysvinit the better way to stay ?
What are you looking for specifically ? can't answer vague questions.. "stability" means different things depending on the context.
Of course systemd has bugs like any other software, however most problems in older version are derived from issues in the openSUSE implementation and packages totally unrelated with it
Since I can't point to anything specific at the point, I'm thinking more in general. I remember with the older 2 versions, it was - highly - recommended to disable systemd and use sysvinit. So, is there a recommendation (then) ?
At this point, I would say stick with systemd. It _does_ still have minor teething problems, but they are really mostly corner-cases. Occasionally migration incompatibilities appear where systemd no longer supports what one was used to in sysvinit (see for instance Carlos' spamd issue re inline comments).
And if you depend on yast management of runlevels and services, I think that is a bit lacking too (I don't use it myself). -- Per Jessen, Zürich (20.4°C) http://www.dns24.ch/ - free DNS hosting, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Per Jessen said the following on 06/16/2013 04:55 AM:
At this point, I would say stick with systemd. It_does_ still have minor teething problems, but they are really mostly corner-cases. Occasionally migration incompatibilities appear where systemd no longer supports what one was used to in sysvinit (see for instance Carlos' spamd issue re inline comments).
That's not a show-stopper. "The Rest Of Us" who don't put in-line comments in the config files never saw that. And putting comments on separate lines is what appears in most files. This is certainly not an excuse for failing to use systemd. As Crisitan pointed out, it arises, like my own problems that he gently corrected me on, from not paying enough attention to the documentation. -- "Realizing the importance of the case, my men are rounding up twice the number of usual suspects" -- Cpt Renault to Major Strasser, Cassablanaca -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Anton Aylward wrote:
Per Jessen said the following on 06/16/2013 04:55 AM:
At this point, I would say stick with systemd. It_does_ still have minor teething problems, but they are really mostly corner-cases. Occasionally migration incompatibilities appear where systemd no longer supports what one was used to in sysvinit (see for instance Carlos' spamd issue re inline comments).
That's not a show-stopper. "The Rest Of Us" who don't put in-line comments in the config files never saw that. And putting comments on separate lines is what appears in most files.
So probabilistically, systemd will work. :-)
As Crisitan pointed out, it arises, like my own problems that he gently corrected me on, from not paying enough attention to the documentation.
And insufficient testing, both by developers and testers. -- Per Jessen, Zürich (23.7°C) http://www.dns24.ch/ - free DNS hosting, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Per Jessen said the following on 06/16/2013 08:30 AM:
Anton Aylward wrote:
That's not a show-stopper. "The Rest Of Us" who don't put in-line comments in the config files never saw that. And putting comments on separate lines is what appears in most files.
So probabilistically, systemd will work. :-)
Probability has nothing to do with it! Either it works unmodified, works with changes to config to suite the context, or its a fringe case where it doesn't work. The latter case might revert to the second with Cristian's kind attention.
As Crisitan pointed out, it arises, like my own problems that he gently corrected me on, from not paying enough attention to the documentation.
And insufficient testing, both by developers and testers.
Since the RTFM cases cannot be called 'insufficient testing' and since, as a subscriber to [systemd-devel] I see a lot of hammering at obscure problems and fringe cases -- things that we don't see reported here -- and responses which clarify mattes, I think that is a most unjustified comment. I absolute terms all software would benefit from more testing, fringe cases, off configuration settings , but systemd has fewer dependencies than many other applications and has been deliberately designed to 'fail soft'. I just with its like were available for some of the Big Machines I encounter! -- All day the wind had screamed and the rain had beaten against the windows, so that even here in the heart of great, hand-made London we were forced to raise our minds for the instant from the routine of life and to recognize the presence of those great elemental forces which shriek at mankind through the bars of his civilization, like untamed beasts in a cage. -- From "The Five Orange Pips" -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Sunday, 2013-06-16 at 07:56 -0400, Anton Aylward wrote:
Per Jessen said the following on 06/16/2013 04:55 AM:
At this point, I would say stick with systemd. It_does_ still have minor teething problems, but they are really mostly corner-cases. Occasionally migration incompatibilities appear where systemd no longer supports what one was used to in sysvinit (see for instance Carlos' spamd issue re inline comments).
That's not a show-stopper. "The Rest Of Us" who don't put in-line comments in the config files never saw that. And putting comments on separate lines is what appears in most files.
This is certainly not an excuse for failing to use systemd.
Who is giving excuses? Not me, I'm using it. - -- Cheers, Carlos E. R. (from 12.3 x86_64 "Dartmouth" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) iEYEARECAAYFAlG95vMACgkQtTMYHG2NR9VVSwCgkHZM4z0cf3G2+wiXTsIrf/fB 0bIAnR8xVDxUZeyFTChjvvxBFp8698L+ =+pOO -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 6/16/2013 4:56 AM, Anton Aylward wrote:
That's not a show-stopper. "The Rest Of Us" who don't put in-line comments in the config files never saw that. And putting comments on separate lines is what appears in most files.
Wait, What? A coding practice that has been around since the Pleistocene is missed by the developers of SystemD and its no cause for concern? You know, even people who set out to reinvent the wheel don't dispense with "round". -- _____________________________________ ---This space for rent--- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
El 16/06/13 15:32, John Andersen escribió:
On 6/16/2013 4:56 AM, Anton Aylward wrote:
That's not a show-stopper. "The Rest Of Us" who don't put in-line comments in the config files never saw that. And putting comments on separate lines is what appears in most files.
Wait, What? A coding practice that has been around since the Pleistocene is missed by the developers of SystemD and its no cause for conce?
We are talking about inline comments in sysconfig files. there is no formal specification of sysconfig and what is written says that comments are lines BEGINNING with #. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 06/16/2013 01:55 AM, Per Jessen wrote:
Duaine Hechler wrote:
On 06/15/2013 10:39 PM, Cristian Rodríguez wrote:
On 06/15/2013 11:28 PM, Duaine Hechler wrote:
Is systemd more reliable and stable in 12.3, than in 12.1 and 12.2 ?
Or is keeping with sysvinit the better way to stay ?
What are you looking for specifically ? can't answer vague questions.. "stability" means different things depending on the context.
Of course systemd has bugs like any other software, however most problems in older version are derived from issues in the openSUSE implementation and packages totally unrelated with it
Since I can't point to anything specific at the point, I'm thinking more in general. I remember with the older 2 versions, it was - highly - recommended to disable systemd and use sysvinit. So, is there a recommendation (then) ?
At this point, I would say stick with systemd. It _does_ still have minor teething problems, but they are really mostly corner-cases. Occasionally migration incompatibilities appear where systemd no longer supports what one was used to in sysvinit (see for instance Carlos' spamd issue re inline comments).
When a system that worked perfectly WITHOUT systemd has to be booted 3 time to get it to come up WITH systemd and no means of determining why, I wouldn't call it a "corner case". In my opinion (and I've been using Linux since '93), I'd say it's unstable, unreliable and nowhere near ready for release. While the concepts may be laudable, the implementation needs more careful thought... And THAT seems to be missing. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Bruce Ferrell said the following on 06/16/2013 09:51 AM:
When a system that worked perfectly WITHOUT systemd has to be booted 3 time to get it to come up WITH systemd and no means of determining why, I wouldn't call it a "corner case". In my opinion (and I've been using Linux since '93), I'd say it's unstable, unreliable and nowhere near ready for release.
Only 93? About 20 years after I started with UNIX ... So you started long after USG introduced the model we now call sysvinit in the early 1980s and didn't see the unholy mess they made of it, nor their re-working of things that Denis, Rob and many others had working just fine since the V7 days and and were rock solid in UNIX 8, which was internal to Bell Labs. You didn't see the arguments that people like Bill Joy had with them and why BSD and eventually SUN went in a different direction - and became a 'reference standard' for many developers and why the BSD model is still considered more secure (meaning stable, has integrity, flaw-free, not just 'hacker proof'). I've had USG UNIX not work in more cases than I care to think about. Originally DG/UX was fully compliant, but if you tried booting it with a small change to your hardware then it did strange things. Once I had the boot lock up and CPU overheat. Then I found that the device drivers weren't detecting end of media - not just the tape and floppy but the hard drive as well. If you did a 'dd' to a partition it would keep writing past the end of the partition. It took a lot to convince DG support that they had a bug. I'd been a kernel developer once and knew disk drivers well and when I described in detail what was wrong they accused me of - somehow - pirating their code. The USG distribution was a real mess and not everyone had the smarts to or the time to or the money to fix all its idiocies. So why am I using Linux rather then BSD? Because of systemd!
While the concepts may be laudable, the implementation needs more careful thought... And THAT seems to be missing.
How come it works so easily for me? Because I'm willing to adapt and learn and find out they WHY when things don' go the way I expect. All to often the 'don't go the way I expect' say more about my expectations than any flaw in the code. The thing is, I suspect, that I'm wiling to accept that Lennart and Cristian are smarter than me, a lot smarter, and I'm willing to accept their way and learn from them rather than insist that my way is the right way. I've seen to many changes in *NIX over the years and its been a proving ground for many great ideas, which is one reason it has come to dominate despite the lack of Big Advertising behind it. I subscribe to [systemd-devl] and I do see that a lot of careful thought and testing is going into development. I base what I say on evidence not prejudice. -- Leadership is understanding people and involving them to help you do a job. That takes all of the good characteristics, like integrity, dedication of purpose, selflessness, knowledge, skill, implacability, as well as determination not to accept failure. -- Admiral Arleigh A. Burke -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 06/16/2013 07:23 AM, Anton Aylward wrote:
Bruce Ferrell said the following on 06/16/2013 09:51 AM:
When a system that worked perfectly WITHOUT systemd has to be booted 3 time to get it to come up WITH systemd and no means of determining why, I wouldn't call it a "corner case". In my opinion (and I've been using Linux since '93), I'd say it's unstable, unreliable and nowhere near ready for release.
Only 93? About 20 years after I started with UNIX ...
So you started long after USG introduced the model we now call sysvinit in the early 1980s and didn't see the unholy mess they made of it, nor their re-working of things that Denis, Rob and many others had working just fine since the V7 days and and were rock solid in UNIX 8, which was internal to Bell Labs. You didn't see the arguments that people like Bill Joy had with them and why BSD and eventually SUN went in a different direction - and became a 'reference standard' for many developers and why the BSD model is still considered more secure (meaning stable, has integrity, flaw-free, not just 'hacker proof').
I said Linux since '93. I've worked with *IX since about '80. Back then mostly DecUnix and SunOS and I dID see the switch over from the BSD model to sysV. It did take some getting used to but sysV was based on transparency... And the shift was CLEARLY and FULLY documented... No, "well, ya gotta know" garbage.
snippage of kernel level stuff<
So why am I using Linux rather then BSD? Because of systemd!
While the concepts may be laudable, the implementation needs more careful thought... And THAT seems to be missing.
How come it works so easily for me? Because I'm willing to adapt and learn and find out they WHY when things don' go the way I expect. All to often the 'don't go the way I expect' say more about my expectations than any flaw in the code.
How come it doesn't work for me on a clean install?
The thing is, I suspect, that I'm wiling to accept that Lennart and Cristian are smarter than me, a lot smarter, and I'm willing to accept their way and learn from them rather than insist that my way is the right way. I've seen to many changes in *NIX over the years and its been a proving ground for many great ideas, which is one reason it has come to dominate despite the lack of Big Advertising behind it.
Lennert and Christain may be smarter than me... Not necessarily proven, and irrelevant BUT there seem to be a LOT of people who are having problems with Lennerts "inventions/concepts". *IX came to dominate for one, and only one reason. Linux, free, open Linux. Before that it was a huge expense and a bit of a vampire due to the corporate nature (want a driver for your ethernet card? $$$, how about your SCSI card? $$$... Networking, that's extra.) of *IX before Linux. And Linux happened because the folks from BSD386 wanted a good ol' boys garden and wouldn't let Linux play in it. And Yes, I was one of those dutiful compilers of code from Dr Dobbs... Right up until Linux came on the scene.
I subscribe to [systemd-devl] and I do see that a lot of careful thought and testing is going into development.
I base what I say on evidence not prejudice.
As do I. The evidence is in my system that worked just fine before systemd. systemd should have remained and OPTION/CHOICE not a mandate in openSUSE until it was better debugged in openSUSE. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 6/16/2013 10:53 AM, Bruce Ferrell wrote:
I said Linux since '93. I've worked with *IX since about '80. Back then mostly DecUnix and SunOS and I dID see the switch over from the BSD model to sysV. It did take some getting used to but sysV was based on transparency... And the shift was CLEARLY and FULLY documented... No, "well, ya gotta know" garbage.
For may part, simply, bsd init scripts and sysv init scripts, are both still scripts! Neither one tries to tell me from 20 years ago what I do not have any possible valid reason to do today. No matter how great some of the concepts are, and I agree they are, it's wrong simply because it tries to predict the unpredictable and it replaces a system that is both transparent and malleable with one that is neither. -- bkw -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Bruce Ferrell wrote:
On 06/16/2013 07:23 AM, Anton Aylward wrote: [big snip]
How come it works so easily for me? Because I'm willing to adapt and learn and find out they WHY when things don' go the way I expect. All to often the 'don't go the way I expect' say more about my expectations than any flaw in the code.
How come it doesn't work for me on a clean install?
Bruce, if that is the case, please open a bug report. A clean install is obviously _not_ a corner case, it simply has to work. -- Per Jessen, Zürich (21.4°C) http://www.dns24.ch/ - free DNS hosting, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 06/16/2013 11:36 PM, Per Jessen wrote:
Bruce Ferrell wrote:
On 06/16/2013 07:23 AM, Anton Aylward wrote: [big snip]
How come it works so easily for me? Because I'm willing to adapt and learn and find out they WHY when things don' go the way I expect. All to often the 'don't go the way I expect' say more about my expectations than any flaw in the code.
How come it doesn't work for me on a clean install?
Bruce, if that is the case, please open a bug report. A clean install is obviously _not_ a corner case, it simply has to work.
And what exactly do I put in the bug report? Problem: System boot/shutdown is erratic How to reproduce: Beats hell out of me... The system does what it wants to. No debugging possible due to systemd. No messages displayed or known to be logged. We all know that isn't a good bug report and in my day job I'd reject it out of hand. Actually, I'm not allowed to do that. I'd have to spend copious amounts of time finding out what the problem is... Not the mindset here. Right now, opensuse with systemd is so windows like that I may as well be using windows... Including non-existent support. As Anton has pointed out, this may be a packaging issue. I don't care, as far as I'm concerned it's systemd. If I wanted to be going back to upstream for fixes/support, I'd install LFS. As to removing systemd and putting in the sysvinit that seems to have re-appeared, the last time I did that, under advice from Ken Schneider here on the list, I got to do yet another re-install due to bricking the system... Followed by snark. Uncool at bets systemd, as packaged in opensuse, is NOT ready for deployment and should not be the single option. And in it's current state shows a deplorable state of craftsmanship and pride of work coupled with a "take it or leave it, it's free" attitude (BTW, when there was a boxed edition, I bought those to assist in supporting the distro). opensuse is just not worth it... Even free. I'm spending my time figuring out a way out of opensuse and still maintaining the functionality I need/want. opensuse used to be stable, rich and advanced. Now it's a mess and I really think Suse, if this really IS a testbed for them, needs to get it's act together and if Suse can't do that, then Attachmate needs to fold opensuse back into Suse and Suse back into Attachmate and go back to boxed sets. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Bruce Ferrell said the following on 06/17/2013 07:47 AM:
No debugging possible due to systemd. No messages displayed or known to be logged.
This is not so. Cristian has described a number of times how to enable debugging with systemd. I'm sure he will again :-) Of course you can ignore his explanation, continue to insist that because it doesn't work for you there is no point analysing what is going on by using the advanced logging Cristian will tell you about, not post a bug report (nor add to one already there such as Yast being unable to do things with systemd), not contribute. After all this is opensuse, not SLED. Its less bleeding edge than 'Factory', but if you want stability go with SLED. There are other distributions; you could go with BSD; you could even buy a cheap s/h SUN Sparc workstation - they are pretty good - and they don't run systemd. -- One can never consent to creep when one feels an impulse to soar. - Helen Keller -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Bruce Ferrell wrote:
On 06/16/2013 11:36 PM, Per Jessen wrote:
Bruce Ferrell wrote:
On 06/16/2013 07:23 AM, Anton Aylward wrote: [big snip]
How come it works so easily for me? Because I'm willing to adapt and learn and find out they WHY when things don' go the way I expect. All to often the 'don't go the way I expect' say more about my expectations than any flaw in the code.
How come it doesn't work for me on a clean install?
Bruce, if that is the case, please open a bug report. A clean install is obviously _not_ a corner case, it simply has to work.
And what exactly do I put in the bug report?
Problem: System boot/shutdown is erratic
How to reproduce: Beats hell out of me... The system does what it wants to. No debugging possible due to systemd. No messages displayed or known to be logged.
We all know that isn't a good bug report and in my day job I'd reject it out of hand. Actually, I'm not allowed to do that. I'd have to spend copious amounts of time finding out what the problem is... Not the mindset here.
Umm, that's a bit strong - Frederic Crozat and others have spent a lot of time debugging or helping with systemd reports. Getting more diagnostics from systemd: https://en.opensuse.org/SDB:Systemd#Getting_debug_from_systemd For instance: add "systemd.log_target=kmsg systemd.log_level=debug" to your boot parameters. For the bugreport, start by explaining how it is erratic. Just pick one example. -- Per Jessen, Zürich (28.8°C) http://www.dns24.ch/ - free DNS hosting, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 06/17/2013 05:13 AM, Per Jessen wrote:
Bruce Ferrell wrote:
On 06/16/2013 11:36 PM, Per Jessen wrote:
Bruce Ferrell wrote:
Umm, that's a bit strong - Frederic Crozat and others have spent a lot of time debugging or helping with systemd reports.
Getting more diagnostics from systemd:
https://en.opensuse.org/SDB:Systemd#Getting_debug_from_systemd
For instance: add "systemd.log_target=kmsg systemd.log_level=debug" to your boot parameters.
For the bugreport, start by explaining how it is erratic. Just pick one example.
Per, Thank you. That is useful information and I'll attempt your suggestion, althought I didn't notice that on a quick scan of the article you referenced. Consider this if you think my statement strong, for those thinking of trying the sysvinit... It's broken. It needs things that are missing, like /etc/inittab, /etc/init.d/boot (if you use the one that appearsed on my system as an rpmnew file) and /etc/rc. Again demonstrating a lack of pride in work on the part of whomever packaged sysvinit. Although the missing components show as belonging to aaa_base. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Bruce Ferrell wrote:
On 06/17/2013 05:13 AM, Per Jessen wrote:
Bruce Ferrell wrote:
On 06/16/2013 11:36 PM, Per Jessen wrote:
Bruce Ferrell wrote:
Umm, that's a bit strong - Frederic Crozat and others have spent a lot of time debugging or helping with systemd reports.
Getting more diagnostics from systemd:
https://en.opensuse.org/SDB:Systemd#Getting_debug_from_systemd
For instance: add "systemd.log_target=kmsg systemd.log_level=debug" to your boot parameters.
For the bugreport, start by explaining how it is erratic. Just pick one example.
Per,
Thank you. That is useful information and I'll attempt your suggestion, althought I didn't notice that on a quick scan of the article you referenced.
I forgot to mention - also remove 'quiet' from the boot options. Adding those systemd debugging options is typically what you would be asked for anyway.
Consider this if you think my statement strong, for those thinking of trying the sysvinit... It's broken. It needs things that are missing, like /etc/inittab, /etc/init.d/boot (if you use the one that appearsed on my system as an rpmnew file) and /etc/rc. Again demonstrating a lack of pride in work on the part of whomever packaged sysvinit. Although the missing components show as belonging to aaa_base.
sysvinit was (at least somewhat) intentionally broken, I'm afraid. I'm not sure, but I think 12.2 was the last release where sysvinit and systemd were "plug-compatible". -- Per Jessen, Zürich (33.1°C) http://www.dns24.ch/ - free DNS hosting, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 6/16/2013 7:23 AM, Anton Aylward wrote:
Bruce Ferrell said the following on 06/16/2013 09:51 AM:
When a system that worked perfectly WITHOUT systemd has to be booted 3 time to get it to come up WITH systemd and no means of determining why, I wouldn't call it a "corner case". In my opinion (and I've been using Linux since '93), I'd say it's unstable, unreliable and nowhere near ready for release.
Only 93? About 20 years after I started with UNIX ...
So you started long after USG introduced the model we now call sysvinit in the early 1980s and didn't see the unholy mess they made of it, nor their re-working of things that Denis, Rob and many others had working just fine since the V7 days and and were rock solid in UNIX 8, which was internal to Bell Labs. You didn't see the arguments that people like Bill Joy had with them and why BSD and eventually SUN went in a different direction - and became a 'reference standard' for many developers and why the BSD model is still considered more secure (meaning stable, has integrity, flaw-free, not just 'hacker proof').
I've had USG UNIX not work in more cases than I care to think about.
Originally DG/UX was fully compliant, but if you tried booting it with a small change to your hardware then it did strange things. Once I had the boot lock up and CPU overheat. Then I found that the device drivers weren't detecting end of media - not just the tape and floppy but the hard drive as well. If you did a 'dd' to a partition it would keep writing past the end of the partition. It took a lot to convince DG support that they had a bug. I'd been a kernel developer once and knew disk drivers well and when I described in detail what was wrong they accused me of - somehow - pirating their code. The USG distribution was a real mess and not everyone had the smarts to or the time to or the money to fix all its idiocies.
So why am I using Linux rather then BSD? Because of systemd!
While the concepts may be laudable, the implementation needs more careful thought... And THAT seems to be missing.
How come it works so easily for me? Because I'm willing to adapt and learn and find out they WHY when things don' go the way I expect. All to often the 'don't go the way I expect' say more about my expectations than any flaw in the code.
The thing is, I suspect, that I'm wiling to accept that Lennart and Cristian are smarter than me, a lot smarter, and I'm willing to accept their way and learn from them rather than insist that my way is the right way. I've seen to many changes in *NIX over the years and its been a proving ground for many great ideas, which is one reason it has come to dominate despite the lack of Big Advertising behind it.
I subscribe to [systemd-devl] and I do see that a lot of careful thought and testing is going into development.
I base what I say on evidence not prejudice.
Seriously Anton, an offhand phrase in a post does not require burdening the list with your chest thumping personal history. Where you've been, and what you've done (regardless of how God-Like) does not help the rest of us. -- _____________________________________ ---This space for rent--- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
John Andersen said the following on 06/16/2013 03:38 PM:
Where you've been, and what you've done (regardless of how God-Like) does not help the rest of us.
Maybe so, but its not about being god-like, its having seen enough ways of doing things to recognise an improvement when it comes along and to recall the can of worms that the version of UNIX tat USG foisted on us, and USG are the ones responsible for what we now call sysvinit. They were also responsible for a lot of broken stuff and some abysmal code and abysmal egregious re-writes of things that were fine in V6, V7 and V8. We all spent a long time cleaning out that mess. Having learnt flexibility and patience and learning from others how to make things work certainly helps me. My patience and willingness to learn might not help you, yes you are right about that, but I hope it sets an example to others who are not antagonistic to change. -- How long did the whining go on when KDE2 went on KDE3? The only universal constant is change. If a species can not adapt it goes extinct. That's the law of the universe, adapt or die. -- Billie Walsh, May 18 2013 -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 6/16/2013 1:00 PM, Anton Aylward wrote:
Having learnt flexibility and patience and learning from others how to make things work certainly helps me. My patience and willingness to learn might not help you, yes you are right about that, but I hope it sets an example to others who are not antagonistic to change.
There you go again.... The "god-like" was a subtle hint, but apparently neither subtly nor sarcasm is something you've mastered. -- _____________________________________ ---This space for rent--- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Sunday, 2013-06-16 at 10:55 +0200, Per Jessen wrote:
Duaine Hechler wrote:
Since I can't point to anything specific at the point, I'm thinking more in general. I remember with the older 2 versions, it was - highly - recommended to disable systemd and use sysvinit. So, is there a recommendation (then) ?
At this point, I would say stick with systemd. It _does_ still have minor teething problems, but they are really mostly corner-cases. Occasionally migration incompatibilities appear where systemd no longer supports what one was used to in sysvinit (see for instance Carlos' spamd issue re inline comments).
I concur. There are hurdles with migration, but as systemd is here to stay, better get it done with. At least with 12.3, I skipped 12.2 on purpose, so I'm learning it now. It's a complicated migration, 12.1 to 12.3... - -- Cheers, Carlos E. R. (from 12.3 x86_64 "Dartmouth" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) iEYEARECAAYFAlG9454ACgkQtTMYHG2NR9Xg+wCfap2g/hlHUnbsBpPpWWaYweo2 JDwAn1VSox6gFD+UrVtbD5vdXGKkI4eL =CKs6 -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Carlos E. R. wrote:
On Sunday, 2013-06-16 at 10:55 +0200, Per Jessen wrote:
Duaine Hechler wrote:
Since I can't point to anything specific at the point, I'm thinking more in general. I remember with the older 2 versions, it was - highly - recommended to disable systemd and use sysvinit. So, is there a recommendation (then) ?
At this point, I would say stick with systemd. It _does_ still have minor teething problems, but they are really mostly corner-cases. Occasionally migration incompatibilities appear where systemd no longer supports what one was used to in sysvinit (see for instance Carlos' spamd issue re inline comments).
I concur.
There are hurdles with migration, but as systemd is here to stay, better get it done with. At least with 12.3, I skipped 12.2 on purpose, so I'm learning it now.
It's a complicated migration, 12.1 to 12.3...
I migrated my laptop from 11.4 to 12.3 with only one critical issue: https://bugzilla.novell.com/show_bug.cgi?id=814510 -- Per Jessen, Zürich (21.2°C) http://www.dns24.ch/ - free DNS hosting, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Monday, 2013-06-17 at 08:29 +0200, Per Jessen wrote:
Carlos E. R. wrote:
At this point, I would say stick with systemd. It _does_ still have minor teething problems, but they are really mostly corner-cases. Occasionally migration incompatibilities appear where systemd no longer supports what one was used to in sysvinit (see for instance Carlos' spamd issue re inline comments).
I concur.
There are hurdles with migration, but as systemd is here to stay, better get it done with. At least with 12.3, I skipped 12.2 on purpose, so I'm learning it now.
It's a complicated migration, 12.1 to 12.3...
I migrated my laptop from 11.4 to 12.3 with only one critical issue:
Ah, but that one is not related to systemd, is it? :-) - -- Cheers, Carlos E. R. (from 12.3 x86_64 "Dartmouth" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) iEYEARECAAYFAlG+03MACgkQtTMYHG2NR9U1IQCfWQ6BUVk7Gj/1WzT0RRPFkm/w FBYAn2lRXv9VYc1TcZozasC45t5q5E8t =XfqU -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Per Jessen wrote:
At this point, I would say stick with systemd. It _does_ still have minor teething problems, but they are really mostly corner-cases. Occasionally migration incompatibilities appear where systemd no longer supports what one was used to in sysvinit (see for instance Carlos' spamd issue re inline comments).
If you have really primitive startup scripts ... then systemd seems useful, but for scripts that actually took advantage of scripting to build in flexibility it seems a rather large step backwards. Systemd would choke on my transmission startup script. Someone on the transmission forum wanted to know how to create such a script on a distro that had gone to systemd and had lost such flexibility. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Linda Walsh wrote:
Per Jessen wrote:
At this point, I would say stick with systemd. It _does_ still have minor teething problems, but they are really mostly corner-cases. Occasionally migration incompatibilities appear where systemd no longer supports what one was used to in sysvinit (see for instance Carlos' spamd issue re inline comments).
How would you do something like the attached in systemd? Or another for 'rcscript status' gave a stop-like display... #!/bin/bash # # /etc/rc.d/transmission.rc script by Astara at tlinx.org (c) 2010 # use, modify and derive from, as thou wilt. If you find this useful # that's great! If you want to mention me in credits, that a bonus! Enjoy! # Developed and tested on suse 11.2 - 12.2 # transmission[{XX}] [verb] [{XX}] -- where {XX} is an *optional* # integer and is appended to the # start script name - to allow running # more than one instance -- I run 2 # a main one 'transmission, and a child # transmission1 # running multiple daemons allows finer # grain control of priorities ## note: "tmd" below, is my short-hand notation for "transmission-daemon" # When {XX} is noted, for XX>0, home dir directs to 'child{XX}' under # the real home directory # ### BEGIN INIT INFO # Provides: transmission # Required-Start: $network, $local_fs, # Should-Start: upnp $remote_fs named # Required-Stop: # Should-Stop: # Default-Start: 3 5 # Default-Stop: 0 1 2 6 # Short-Description: transmission-daemon: a file transfer daemon # Description: transmission-daemon is a file transfer daemon utilizing # the 'bit-torrent' protocol. This allow for transferring # large amounts of data by sharing the network bandwith # among downloaders. Note -- to make effective use of # this client, it is necessary to allow incoming and # outgoing traffic through a firewall. # Only 1 port needs to be open and this can be defined # statically -- so you can manually add rules to your # firewall. The daemon will use upnp to talk to a # compliant firewall to ask it to open a port for it, # allowing for port randomization on startup, if that # is desired. Software upnp programs, like 'linux-igd' # are freely available by searching on the web, will # function as a upnp gateway and will manage connections # through a linux or other firewall. ### END INIT INFO # ## support code & functions Id="$(type -p id)" Sed="$(type -p sed)" Sudo="$(type -p sudo)" use_group_access=1 if ((use_group_access)); then unset Groups typeset -Ax Groups function _idparse { # parse output of id: # uid=##(name) gid=##(name) groups=##(name)[,##(name)]... # Note, names may be 'absent' (in which case there are no parens). # grouplist is *comma* separated! -- but only on output of 'id'; # I don't "idnames" can start with a number... (we'll assume not) # if group has no name, put it's number in as it's name # else you wouldn't see you are in those groups while read id ; do [[ $id =~ .?id= ]] && continue; #skip over uid/gid entries id="${id/\(/ }" id="${id/\)/}" gid="${id%% *}" name="${id#$gid}" name=${name##\ } [[ -z $name ]] && name="$gid" Groups[$name]="$gid" done < <($Id|$Sed -r ' s/\) gid/\)\ngid/ ; s/\) groups/\)\ngroups/ ; s/\\/\\\\/g ; s/\),([0-9])/)\n\1/g ; s/\b([0-9]+),/\1\n/g ; s/groups=//') } _idparse ## populate Groups Hash fi # I set my user defaults here as I try to use the group for access # (doesn't actually work taht well because transmission-daemon # has a design flaw and set's it's umask to it's own arbitrary value # vs. allowing user to set it tmd_user=torrent # generic 'torrent' user to run torrents tmd_home="$(eval echo ~$tmd_user)" #they better have a home tmd_base_home="$tmd_home" tmd_group="$(groups torrent 2>/dev/null |cut -d\ -f3)" #and a real group tmd_child="" # note sudo is annoying to configure properly these days.. # best to sudo first then run this script: # (ex. "sudo /etc/rc.d/transmission start" if (($EUID != 0)) ; then if [[ -n ${Groups[$tmd_group]:-} ]]; then if [[ -z ${TRIED_ROOT:-} ]]; then export TRIED_ROOT="yes" exec sudo -E -g "$tmd_group" $0 "$@" fi fi echo "Need Root privs to successully run this script..." exit -1 fi unset TRIED_ROOT >&/dev/null || ((0)) #no longer needed #presumably user is root-priv'ed now. #parse command instance prog="$(basename "$0")" core="$(echo $prog |sed -r 's/^.*transmission/trm/ ; s/^.*trm[0]*([1-9][0-9]+)/trm$1/')" [[ ${core:0:3} == trm && ${#core} -gt 3 ]] && tmd_child="${core:3}" [[ $# -gt 1 && $2 =~ ^[0-9]+$ ]] && tmd_child="$2" tmd_child="${tmd_child##0}" [[ $tmd_child ]] && tmd_home="$tmd_home/child$tmd_child" tmd_umask=002 etc_loglevel=info #default logging level #unset tmd_use_proxy # default # don't use these by default if [[ ! ${use_proxy:-} =~ ^y ]]; then unset -v http_proxy unset -v ftp_proxy unset -v https_proxy fi if [[ -r ${tmd_log_level_file:-""} ]]; then nlvl=$(<"$tmd_log_level_file") if [[ $nlvl == info || $nlvl == debug || $nlvl == error || $nlvl == none ]] ; then etc_loglevel=$nlvl fi fi # use prefix 'tmd' = instead of full program/service name; its just too long tmd_bin="/usr/bin/transmission-daemon" tmd_piddir="/var/run/transmission/" #make sure we can write in piddir if [[ ! -d $tmd_piddir ]]; then mkdir -m 6775 "$tmd_piddir" && chown $tmd_user.$tmd_group $tmd_piddir fi tmd_pidfile="$tmd_piddir/transmission-daemon$tmd_child.pid" tmd_logdir="/var/log/transmission" tmd_log="$tmd_logdir/daemon$tmd_child.log" tmd_output_log="$tmd_logdir/output$tmd_child.log" tmd_nice=5 # could use just "-c3" for lowest(idle) disk priority tmd_ionicep="-c2 -n7" # best effort; lowest in class tmd_existing_config=$tmd_home/settings.json # read the daemon's current config to get values...for defaults function read_json_config { local cfg="${1:-}" local fl="${2:-}" typeset -A $cfg perl -wE ' use 5.12.0; $|=1; my $cfg = shift @ARGV; open (my $cfgh, "<", $ARGV[0]) or die "error opening config file: $!\n"; my $bash_hash = "declare -A $cfg=("; while (<$cfgh>) { chomp; m{^\s+ \" ([^"]+) \":\s+ \"? ([^"]+) \"? ,\s*$}x and do { my ($name, $val) = ($1, $2); $bash_hash .= qq{[$name]=\"$value\" }; }; } print "$bash_hash )\n"; ' "$cfg" "$fl" } if [[ $# -ge 2 ]]; then eval $(read_json_config "$1" "$2") fi eval $(read_json_config Config "$tmd_home/settings.json") ################################################################ # 'default' tmd_a_rgs: # [[ ${Config[blocklist-enabled]} =~ true ]] && blocklist="--blocklist" [[ ${Config[download-dir]:-} ]] && ddd="--download-dir ${Config[download-dir]}" [[ ${config[incomplete-dir]:-} ]] && icd="--incomplete-dir ${config[incomplete-dir]}" ### check for main data dirs being mounted [[ $ddd ]] dir1="${Config[download-dir]}" [[ $icd ]] dir2="${Config[download-dir]}" if [[ $dir1 && ! -d $dir1 || $dir2 && ! -d $dir2 ]]; then echo "Fatal error: Torrent data directories are not found" echo "this may mean a disk is not mounted: will not proceed" rc_fail 1 rc_status v exit 1 fi ## note -- if you don't want to configure one of these; just comment # it out - many of these will be set if it was able to # read the json file from transmission's home dir. tmda_config_dir="--config-dir $tmd_home" tmda_dht="--dht" tmda_encryption="--encryption-tolerated" tmda_foreground="-f" tmda_incomplete_dir="--incomplete-dir $tmd_home/data/Downloading/transmission$tmd_child" tmda_local_peer_discovery="--lpd" tmda_logfile="--logfile $tmd_log" tmda_loglevel="--log-error" if [[ -z "$etc_loglevel" || $etc_loglevel == none ]] ; then tmda_logfile="--logfile /dev/null" else tmda_loglevel="--log-$etc_loglevel" fi tmda_pidfile="--pid-file $tmd_pidfile" tmda_portmap="--no-portmap" tmda_peer_port="${tmda_peer_port_number:+"--peerport $tmda_peer_port_number"}" tmda_port="${tmda_port_number:+"--port $tmda_port_number"}" tmda_rpc_allowed_access="--allowed 192.168.4.*,192.168.3.*,127.0.0.1" tmda_seedratio_glob="--no-global-seedratio" tmda_watchdir="--no-watch-dir" tmd_args=" ${tmda_blocklist:-} ${tmda_complete_dir:-} ${tmda_config_dir:-} ${tmda_dht:-} ${tmda_encryption:-} ${tmda_foreground:-} ${tmda_incomplete_dir:-} ${tmda_local_peer_discovery:-} ${tmda_logfile:-} ${tmda_loglevel:-} ${tmda_peerlimit_glob:-} ${tmda_peerlimit_per_torrent:-} ${tmda_peerport:-} ${tmda_port:-} ${tmda_pidfile:-} ${tmda_portmap:-} ${tmda_rpc_allowed_access:-} ${tmda_rpc_user:-} ${tmda_rpc_userpw:-} ${tmda_rpc_auth:-} ${tmda_seedratio_glob:-} ${tmda_watchdir:-} " #open file limit for our machine ulimit -Hn16384 ulimit -Sn16384 ulimit -n 16384 ionice_bin=$(type -P ionice) # Check for existence of config files; # read system first # possibility of a system config... (I don't have one) test -r "${tmd_sys_config:-""}" && . "$tmd_sys_config" tmd_sys_config="/etc/sysconfig/transmission$tmd_child" # then read home-dir-config if present # I put my config in the 'tmd' daemon's home dir. # in an "etc" directory, in "rc-config" tmd_home_config="$tmd_home/etc/rc-config" test -r "$tmd_home_config" && . "$tmd_home_config" tmd_etc="${tmd_etc:-"$tmd_home/etc"}" tmd_log_level_file="${tmd_log_level_file:-"$tmd_etc/log_level"}" #not sure how we could get this far w/o tmd_user not being set. if [[ -z ${tmd_user:-} ]]; then echo "tmd_user not set!" exit -1 fi if [[ -z ${tmd_group:-} ]]; then echo "User \"$tmd_user\" has no group -- (no /etc/passwd?)" exit -1 fi if [[ -z ${tmd_home:-} ]]; then echo "Configuration error: user \"$tmd_user\" has no home dir " exit -1 fi # Now read possible config options out of tmd user dir (I don't # use this as all my config vals are the defaults in this script! ;-) # but I DID use it to turn on options (debug and such) at times # in the past. # will look for a "environ" dir to read in "environment vars" # that you want to set for transmission (if any; if you # are doing development on it -- some debug options can be set in ENV # read env options... tmd_env="${tmd_env:-"$tmd_home/environ"}" if [[ -d $tmd_env ]]; then if [[ ! -r $tmd_env || ! -x $tmd_env ]]; then echo "Environment directory $tmd_env exists, but isn't readable" echo "Environment variables will be ignored" else cd $tmd_env; readarray vars <<<$(find . -type f -name '[^.]*' -print|tr ) if ((${#vars[*]}>0)); then for var in "${vars[@]}" ; do echo "var=$var" export $var=$(<"$var") done cd - >/dev/null fi fi fi # so note -- the tmd_secrets file can be anywhere -- it may # have been set in the tmd_environ's to anything, but it defaults # to a .secrets DIRECTORY in tmd_home # may be set by tmd_env # since this start script runs as root, these files probably don't # have to be readable by anyone # note -- I don't use a passwd on mine since it's interface is only # open on an internal network tmd_secrets="${tmd_secrets:-"$tmd_home/.secrets"}" tmd_usr_file="$tmd_secrets/.tmd_user" tmd_upw_file="$tmd_secrets/.tmd_userpw" if [[ -r $tmd_usr_file ]]; then tmda_rpc_user="$(<$tmd_usr_file)" fi tmda_rpc_user="${tmda_rpc_user:+"--username $tmda_rpc_user"}" if [[ -r $tmd_upw_file ]]; then tmda_rpc_userpw="$(<$tmd_upw_file)" fi tmda_rpc_userpw="${tmda_rpc_userpw:+"--password $tmda_rpc_userpw"}" if [[ -n ${tmda_rpc_user:-""} && -n ${tmda_rpc_userpw:-""} ]]; then tmda_rpc_auth="--auth" fi # some util that lets you start scripts as a user/var and such... # non configurable vars go after here... #startproc stprc="/sbin/startproc" [[ ! -e $stprc ]] && stprc=$(which startproc) [[ ! -e $stprc ]] && { echo "Fatal: startproc not found" >&2; exit 1 ; } #startproc's arg list.... startproc_args=" -l $tmd_output_log -p $tmd_pidfile -u $tmd_user -g $tmd_group -n $tmd_nice" test -x $tmd_bin || { echo "$tmd_bin not installed"; if [ "$1" = "stop" ]; then exit 0; else exit 5; fi; } sp_args="$startproc_args" # Shell functions sourced from /etc/rc.status: # rc_check check and set local and overall rc status # rc_status check and set local and overall rc status # rc_status -v be verbose in local rc status and clear it afterwards # rc_status -v -r ditto and clear both the local and overall rc status # rc_status -s display "skipped" and exit with status 3 # rc_status -u display "unused" and exit with status 3 # rc_failed set local and overall rc status to failed # rc_failed <num> set local and overall rc status to <num> # rc_reset clear both the local and overall rc status # rc_exit exit appropriate to overall rc status # rc_active checks whether a service is activated by symlinks set +e +u # rc.status has buggy code . /etc/rc.status # SuSE's common run script env (only necessary for # defining "rc_xxxx" commands below that set status or exit #set # Reset status of this service rc_reset # set's startup value to 'ok' cd $tmd_home || { /bin/false rc_status -v # set bad status verbosely and leave rc_exit } running=0 if [[ $1 != status ]]; then /sbin/checkproc -p $tmd_pidfile $tmd_bin running=$? if [[ $running == 0 ]]; then running=1 else running=0 fi fi case "$1" in start) if (($running)) ; then echo -n "Transmission already running... " else echo -n "Starting transmissiond " ## Start daemon with startproc(8). If thikks fails ## the return value is set appropriately by startproc. if [[ -n "$tr_umask" ]]; then umask $tr_umask fi all_args="$startproc_args $tmd_bin $tmd_args" if [[ -x $ionice_bin && -n "${tmd_ionicep:-}" ]]; then $ionice_bin $tmd_ionicep $stprc $all_args else $stprc $all_args fi fi # Remember status and be verbose rc_status -v ;; stop) if ((!$running)) ; then echo -n "Transmission is already stopped... " else echo -n "Shutting down transmissiond " ## Stop daemon with killproc(8) and if this fails ## killproc sets the return value according to LSB. /sbin/killproc -t 10 -p $tmd_pidfile -TERM $tmd_bin || { echo -n "Sending Kill..." /sbin/killproc -p $tmd_pidfile -t 1 -KILL $tmd_bin } fi # Remember status and be verbose rc_status -v ;; try-restart|condrestart) ## Do a restart only if the service was active before. ## Note: try-restart is now part of LSB (as of 1.9). ## RH has a similar command named condrestart. if test "$1" = "condrestart"; then echo -n "${attn} Use try-restart ${done}(LSB)${attn} " echo "rather than condrestart ${warn}(RH)${norm}" fi $0 status if test $? = 0; then $0 restart else rc_reset # Not running is not a failure. fi # Remember status and be quiet rc_status ;; restart) ## Stop the service and regardless of whether it was ## running or not, start it again. $0 stop $0 start # Remember status and be quiet rc_status ;; status) echo -n "Checking for service transmission-daemon${tmd_child} " ## Check status with checkproc(8), if<F5><F5> process is running ## checkproc will return with exit status 0. # Return value is slightly different for the status command: # 0 - service up and running # 1 - service dead, but /var/run/ pid file exists # 2 - service dead, but /var/lock/ lock file exists # 3 - service not running (unused) # 4 - service status unknown :-( # 5--199 reserved (5--99 LSB, 100--149 distro, 150--199 appl.) # NOTE: checkproc returns LSB compliant status values. /sbin/checkproc -p $tmd_pidfile $tmd_bin # NOTE: rc_status knows that we called this init script with # "status" option and adapts its messages accordingly. rc_status -v ;; probe) ## Optional: Probe for the necessity of a reload, print out the ## argument to this init script which is required for a reload. ## Note: probe is not (yet) part of LSB (as of 1.9) if [[ $tmd_sys_config -nt $tmd_pidfile || $tmd_home_config -nt $tmd_pidfile ]]; then echo reload fi ;; *) echo "Usage: $0 {start|stop|status|try-restart|restart|probe}" exit 1 ;; esac rc_exit # vim: ts=2 sw=2 syntax=sh
Linda Walsh wrote:
Linda Walsh wrote:
Per Jessen wrote:
At this point, I would say stick with systemd. It _does_ still have minor teething problems, but they are really mostly corner-cases. Occasionally migration incompatibilities appear where systemd no longer supports what one was used to in sysvinit (see for instance Carlos' spamd issue re inline comments).
How would you do something like the attached in systemd?
I probably wouldn't, but that's not a reason for not going with systemd. Why not just leave it as an LSB script? -- Per Jessen, Zürich (21.2°C) http://www.dns24.ch/ - free DNS hosting, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Monday, 2013-06-17 at 08:26 +0200, Per Jessen wrote:
Linda Walsh wrote:
How would you do something like the attached in systemd?
I probably wouldn't, but that's not a reason for not going with systemd. Why not just leave it as an LSB script?
I see lots of "starting LSB: whatever" entries in my boot sequence, there are many that were not fully migrated, so one more does not matter. The one that I have to look at is hylafax, it had an entry in inittab. Not that I send many faxes nowdays, it is on the decline, but here at least it is required for some paperwork to be legally admitted. I know of people with no email but a fax machine... - -- Cheers, Carlos E. R. (from 12.3 x86_64 "Dartmouth" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) iEYEARECAAYFAlG+1DUACgkQtTMYHG2NR9V3qQCbBwDycOXp2k8tT9qhLrFibDMa zIgAmwQxlsa5IHm0g8jhFVJWstHlo9eY =5to2 -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Carlos E. R. wrote:
On Monday, 2013-06-17 at 08:26 +0200, Per Jessen wrote:
Linda Walsh wrote:
How would you do something like the attached in systemd?
I probably wouldn't, but that's not a reason for not going with systemd. Why not just leave it as an LSB script?
I see lots of "starting LSB: whatever" entries in my boot sequence, there are many that were not fully migrated, so one more does not matter.
The one that I have to look at is hylafax, it had an entry in inittab.
Yes, it is a respawn of "faxgetty". I also have an entry for iaxmodem. Neither should be too difficult to write service units for, but my telephone server (asterisk) is still running 10.2. Upgrading it will be a significant effort, I think asterisk moved quite a bit since 1.4, my current version. /Per -- Per Jessen, Zürich (26.4°C) http://www.dns24.ch/ - free DNS hosting, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Linda Walsh wrote:
Per Jessen wrote:
At this point, I would say stick with systemd. It _does_ still have minor teething problems, but they are really mostly corner-cases. Occasionally migration incompatibilities appear where systemd no longer supports what one was used to in sysvinit (see for instance Carlos' spamd issue re inline comments).
If you have really primitive startup scripts ... then systemd seems useful, but for scripts that actually took advantage of scripting to build in flexibility it seems a rather large step backwards.
Systemd would choke on my transmission startup script.
A corner case? Most init scripts are in fact really primitive. I have a number of my own initscripts, but all they do is start a daemon. Anyway, I wasn't arguing systemd's usefulness, I was only responding to the OP's question of whether to go with systemd or try to stick to sysvinit. -- Per Jessen, Zürich (20.9°C) http://www.dns24.ch/ - free DNS hosting, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Monday, 2013-06-17 at 08:23 +0200, Per Jessen wrote:
Systemd would choke on my transmission startup script.
A corner case? Most init scripts are in fact really primitive. I have a number of my own initscripts, but all they do is start a daemon. Anyway, I wasn't arguing systemd's usefulness, I was only responding to the OP's question of whether to go with systemd or try to stick to sysvinit.
Oh, there is no doubt that we have to migrate or be left behind... like it or not. You can delay, but the end doesn't change. Resistance is futile - you will be assimilated ;-) - -- Cheers, Carlos E. R. (from 12.3 x86_64 "Dartmouth" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) iEYEARECAAYFAlG+1XYACgkQtTMYHG2NR9V2JQCeNoFimM6aLT5PIxoDzYbtRDSi 7IYAn3qB8dtXi7p9tvn0t/iZx1yuG8Gj =kKJW -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 6/16/2013 1:55 AM, Per Jessen wrote:
At this point, I would say stick with systemd. It _does_ still have minor teething problems, but they are really mostly corner-cases.
Every day there are reports on this list of more "corner cases". Just today Carlos reported a couple. After a certain number of "corners" one must concede being trapped in a labyrinth. Are these to be handled one by one, or are there fixes being pushed out in normal updates? Or is there a special repository we need to enable to collect these? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
El 16/06/13 15:28, John Andersen escribió:
Every day there are reports on this list of more "corner cases". Just today Carlos reported a couple. After a certain number of "corners" one must concede being trapped in a labyrinth.
Yes, he did , however what he reported has nothing to do with systemd but with applications misusing it. So far, only part of one of his reports could be construed as a limitation of systemd (it did what it was supposed to do, but what it does could be better) all the other problems have nothing to do with it. The other things he said are due to the lack of a high dose of RTFM :-D -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Sunday, 2013-06-16 at 15:33 -0400, Cristian Rodríguez wrote:
The other things he said are due to the lack of a high dose of RTFM :-D
Not all of us can read and understand those big manuals, and even less remember the salt of them :-) - -- Cheers, Carlos E. R. (from 12.3 x86_64 "Dartmouth" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) iEYEARECAAYFAlG+PYIACgkQtTMYHG2NR9VBYQCfUUb5qDwDZ9A4jjbjsN/fVBvW 1P0An18yHVCad3WMPpeAsG6xyN/fc4QW =PDA3 -----END PGP SIGNATURE-----
On 06/16/2013 06:34 PM, Carlos E. R. pecked at the keyboard and wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Sunday, 2013-06-16 at 15:33 -0400, Cristian Rodríguez wrote:
The other things he said are due to the lack of a high dose of RTFM :-D
Not all of us can read and understand those big manuals, and even less remember the salt of them :-)
+1 My short term memory is good for about 30 minutes, sometimes less which is why I cannot contribute through programming. You should see the number of sticky notes I have around here. :-) -- Ken Schneider SuSe since Version 5.2, June 1998 -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Carlos E. R. said the following on 06/16/2013 06:34 PM:
On Sunday, 2013-06-16 at 15:33 -0400, Cristian Rodríguez wrote:
The other things he said are due to the lack of a high dose of RTFM :-D
Not all of us can read and understand those big manuals, and even less remember the salt of them :-)
Indeed. That's why I keep re-reading them. "Reinforcement". Its not quite like swatting for exams by reading and re-reading your notes and prompt cards and crib sheets, but ... -- How long did the whining go on when KDE2 went on KDE3? The only universal constant is change. If a species can not adapt it goes extinct. That's the law of the universe, adapt or die. -- Billie Walsh, May 18 2013 -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 06/15/2013 08:28 PM, Duaine Hechler wrote:
Is systemd more reliable and stable in 12.3, than in 12.1 and 12.2 ?
Or is keeping with sysvinit the better way to stay ?
On my systems, it's wholly unstable and there seems no way to install sysV init. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Am 16.06.2013 05:28, schrieb Duaine Hechler:
Is systemd more reliable and stable in 12.3, than in 12.1 and 12.2 ?
Or is keeping with sysvinit the better way to stay ?
I'm no expert but I installed an openSUSE 12.3 lately. Initially there was no sysvinit available on the DVD. It appeared later after the first reboot probaply from online update. I then tried to switch on sysvinit-init and as expected YAST said it will remove systemd. As dependencies it altered a couple of other packages, e.g. thunderbird. YAST removed some fonts aswell. The next reboot stopped in an error message from grub2. At my level of knowledge the system was bricked. :( -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Andreas said the following on 06/17/2013 06:49 AM:
As dependencies it altered a couple of other packages, e.g. thunderbird. YAST removed some fonts aswell.
The next reboot stopped in an error message from grub2.
At my level of knowledge the system was bricked. :(
I've had that happen when grub(2) requires a font which it can't find. So what was your error message from grub2? It sounds like this isn't a systemd problem but a packaging/dependency problem -- of which we've seen many in our time :-( -- How long did the whining go on when KDE2 went on KDE3? The only universal constant is change. If a species can not adapt it goes extinct. That's the law of the universe, adapt or die. -- Billie Walsh, May 18 2013 -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 6/17/2013 7:19 AM, Anton Aylward wrote:
Andreas said the following on 06/17/2013 06:49 AM:
As dependencies it altered a couple of other packages, e.g. thunderbird. YAST removed some fonts aswell.
The next reboot stopped in an error message from grub2.
At my level of knowledge the system was bricked. :(
I've had that happen when grub(2) requires a font which it can't find.
So what was your error message from grub2?
It sounds like this isn't a systemd problem but a packaging/dependency problem -- of which we've seen many in our time :-(
Raising yet another idiocy that was shoved in because...I really have no idea... why the FFFF does a bootloader require a font???? Oh I know how it's used, I didn't ask what it's used for, I mean why is it *required*? I also know that it's *not* technically required by grub2 but just by the config that someone wrote for it. grub2 doesn't require any font. But if you write a config that says to load a font, then you need that font, and it needs to be exactly where the config said to look for it. Since grub2 does not proceed from such an unnecessary error when it could, I call that a misfeature that you just shouldn't use. The problem isn't that packaging or grub-update scripts somewhere failed to provide a font, it's that something like a bootloader even requires something so unnecessary in the first place. Actually, in a sense, grub2 did "proceed" from whatever his problem was, in that it fell back to a grub prompt that worked fine without that font (proving that no font is needed really), and probably could have been used to boot the system. But it wasn't exactly useful, where a plain text menu would have been. Essentially, opensuse developers have deliberately chosen to "brick" x% of systems unnecessarily so that the other 99% can have a prettier boot. We don't know that a font was his problem in this case, it could have been anything. But it is a problem that exists as you say. I have hit it myself trying to get a config working again after moving grub & boot files to a different physical drive. Ubuntu in that case, and fixing grub2 config to get it working again was 35x harder than the equivalent grub config. It was not "no worse, just different, you just can't handle change". -- bkw -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
В Mon, 17 Jun 2013 13:38:06 -0400
"Brian K. White"
Actually, in a sense, grub2 did "proceed" from whatever his problem was, in that it fell back to a grub prompt that worked fine without that font (proving that no font is needed really), and probably could have been used to boot the system. But it wasn't exactly useful, where a plain text menu would have been.
grub2 falls back to plain text console if font could not be loaded. More precisely, it switches to graphical output only if font was loaded successfully. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
participants (13)
-
Andreas -
Andrey Borzenkov -
Anton Aylward -
Brian K. White -
Bruce Ferrell -
Carlos E. R. -
Carlos E. R. -
Cristian Rodríguez -
Duaine Hechler -
John Andersen -
Ken Schneider - openSUSE -
Linda Walsh -
Per Jessen