Re: [opensuse] interesting reading about systemd
> -----Ursprüngliche Nachricht-----
Von: Glenn Holmer Gesendet: So. 02.10.2016 15:29 An: opensuse@opensuse.org , Betreff: Re: [opensuse] interesting reading about systemd
On 10/02/2016 01:35 AM, stakanov@freenet.de wrote:
Found on Phoronix and thought to share.
" target="_blank">https://www.agwa.name/blog/post/how_to_crash_systemd_in_one_tweet
https://medium.com/@davidtstrauss/how-to-throw-a-tantrum-in-one-blog-post-c2...
Interesting reading thank you. By what is says it confirms partly the criticism and in part is able to make some points. What is puzzling me that the post of Ayer is perceived as a "anti-systemd-fanatic". When I was reading it, I did not see this as a call to "abandon" systemd, but to limit some tendencies. I see it as interesting contribution and I am puzzled about not few about the assertions Strauss makes in his post. And not the minor this: "As most, it would justify a call to fork systemd and reverse the umask default". WTF, are we now only able through forking to reconsider problems when pointed out? Maybe it is THIS attitude that calls for abandoning a software, not the points themselves. For what I see, the post makes me more worried then not having read it. It seems as much "religious" and biased as the first. I will hold in mind that there are justified critiques and points in the first post and that unfortunately there is a tendency to bash whatever criticism, as there is as well the tendency to bloat criticism of pitfalls on the other side. All this is not really a good "clima". YMMV. --- Die Bundesliga hat begonnen! Alle Tore, alle Ergebnisse, alle News: Pocket Liga jetzt im https://app.adjust.com/dpynzd oder https://app.adjust.com/dpynzd herunterladen - kostenlos! -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Sun, Oct 2, 2016 at 10:28 AM, <stakanov@freenet.de> wrote:
Interesting reading thank you. By what is says it confirms partly the criticism and in part is able to make some points. What is puzzling me that the post of Ayer is perceived as a "anti-systemd-fanatic". When I was reading it, I did not see this as a call to "abandon" systemd, but to limit some tendencies. I see it as interesting contribution and I am puzzled about not few about the assertions Strauss makes in his post. And not the minor this:
"As most, it would justify a call to fork systemd and reverse the umask default".
WTF, are we now only able through forking to reconsider problems when pointed out? Maybe it is THIS attitude that calls for abandoning a software, not the points themselves. For what I see, the post makes me more worried then not having read it. It seems as much "religious" and biased as the first. I will hold in mind that there are justified critiques and points in the first post and that unfortunately there is a tendency to bash whatever criticism, as there is as well the tendency to bloat criticism of pitfalls on the other side. All this is not really a good "clima". YMMV.
systemd to me personally has always seemed to be a solution in search of a problem. While sysVinit had it's flaws, it worked. The devs behind systemd seem to be trying to take over the linux ecosystem by proxy. IMNSHO, the biggest reason linux has never taken over the desktop is the fact that it is so fractured with hundreds of distros With WinDoZe & MacOS you basically have one codebase/one desktop environment for each. With the BSDs, you have maybe a dozen. With Linux we have so many that we duplicate so much work. Each distro has a customized version of a software package(say Firefox) and then there are different versions of the distros. I wonder how much diskspace the whole linux ecosystem takes up on mirrors compared to WinDoZe or macOS......... And so many packages that I could care less about: Avahi, pulseaudio, NetworkManager(so I'm doing a transfer in a virtual terminal and I log out of my X session - the network goes down.....), semantic desktop(still waiting to see what the point of that is), 3d desktop, desktop search(beagle, tracker, etc). There's more of course. However a lot of people want/use those packages so who am I to say no to them? All I ask for is an easy way to NOT have them installed if I chose. Open Source/GNU/Linux/FOSS is supposed to be about choice. When people tell others to get over it and this is the way it is, then choice is being reduced. systemd took over because of limited resources and everyone was using it. While I never cared for KDE4, I am able to choose to use TrinityDE(KDE3 continuation) instead. Fortunately, someone decided to take up the challenge to give them self and others a choice. That's what we should be encouraging instead of comments like this: "There's always Devuan for those anti-systemd fanatics." -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 10/02/2016 01:50 PM, Larry Stotler wrote:
Interesting reading thank you. By what is says it confirms partly the criticism and in part is able to make some points. What is puzzling me that the post of Ayer is perceived as a "anti-systemd-fanatic". When I was reading it, I did not see this as a call to "abandon" systemd, but to limit some tendencies. I see it as interesting contribution and I am puzzled about not few about the assertions Strauss makes in his post. And not the minor this:
"As most, it would justify a call to fork systemd and reverse the umask default".
WTF, are we now only able through forking to reconsider problems when pointed out? Maybe it is THIS attitude that calls for abandoning a software, not the points themselves. For what I see, the post makes me more worried then not having read it. It seems as much "religious" and biased as the first. I will hold in mind that there are justified critiques and points in the first post and that unfortunately there is a tendency to bash whatever criticism, as there is as well the tendency to bloat criticism of pitfalls on the other side. All this is not really a good "clima". YMMV. systemd to me personally has always seemed to be a solution in search of a problem. While sysVinit had it's flaws, it worked. The devs behind systemd seem to be trying to take over the linux ecosystem by
On Sun, Oct 2, 2016 at 10:28 AM, <stakanov@freenet.de> wrote: proxy.
IMNSHO, the biggest reason linux has never taken over the desktop is the fact that it is so fractured with hundreds of distros With WinDoZe & MacOS you basically have one codebase/one desktop environment for each. With the BSDs, you have maybe a dozen. With Linux we have so many that we duplicate so much work. Each distro has a customized version of a software package(say Firefox) and then there are different versions of the distros. I wonder how much diskspace the whole linux ecosystem takes up on mirrors compared to WinDoZe or macOS.........
And so many packages that I could care less about: Avahi, pulseaudio, NetworkManager(so I'm doing a transfer in a virtual terminal and I log out of my X session - the network goes down.....), semantic desktop(still waiting to see what the point of that is), 3d desktop, desktop search(beagle, tracker, etc). There's more of course.
However a lot of people want/use those packages so who am I to say no to them? All I ask for is an easy way to NOT have them installed if I chose.
Open Source/GNU/Linux/FOSS is supposed to be about choice. When people tell others to get over it and this is the way it is, then choice is being reduced. systemd took over because of limited resources and everyone was using it. While I never cared for KDE4, I am able to choose to use TrinityDE(KDE3 continuation) instead. Fortunately, someone decided to take up the challenge to give them self and others a choice. That's what we should be encouraging instead of comments like this:
"There's always Devuan for those anti-systemd fanatics."
Actually systemd wrapped up things into one nice package and got rid of age-old cruft. Finally Linux systems are a joy to administer. So on one hand you're saying Linux isn't successful because it's fractured. Okay, systemd came into solve a bunch of problems (and did so well), and did exactly what you are stating is the downfall of Linux. But, you still are complaining. And now this thread is going to start into another systemd war which I really don't care to read because the debate is over. systemd is here to stay, if you don't like it, go to devuan. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Sun, Oct 2, 2016 at 4:52 PM, sdm <fastcpu@openmailbox.org> wrote:
Actually systemd wrapped up things into one nice package and got rid of age-old cruft. Finally Linux systems are a joy to administer. So on one hand you're saying Linux isn't successful because it's fractured. Okay, systemd came into solve a bunch of problems (and did so well), and did exactly what you are stating is the downfall of Linux. But, you still are complaining. And now this thread is going to start into another systemd war which I really don't care to read because the debate is over. systemd is here to stay, if you don't like it, go to devuan.
You just made my argument for me. All I did was say "hey I dont care for it, but it is care for by others so just give me a way to not have to use it" and you go and try to tell me what to do. So basically, if I don't agree with you, I shouldn't be here on this list and shouldn't use openSUSE - even tho I have been using it and supporting it for 17 years. I admin Linux systems and I find using systemd more difficult than what I am used to. I don't find it better, so where is the advantage? Further, I see no advantage for using systemd on a server at all. But that's MY experience, which is obviously different from YOURS. However, I'm not telling you to go away just because we disagree. This echoes of the KDE4 changeover where people who had issues with it were told to get over it. That no one wanted to hear what we had to say and that KDE4 was the way forward. systemd is here to stay? sure, till the next great thing shows up and everyone runs to it instead. Glad to hear the "debate is over" So, are you now in charge? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 10/02/2016 05:02 PM, Larry Stotler wrote:
I admin Linux systems and I find using systemd more difficult than what I am used to.
I've admin'd (and more) something like 40 different versions of *NIX over the years. Once upon a time I treated SunOS as the 'baseline' or 'reference' and thought in terms of how the others deviated from that. The SUN changed its os! And I moved on the AIX as the reference since, in my opinion, the customizations HP did for HP/US were too deviant to use as a 'baseline', and then when most of the systems I worked on were PC based I thought of Redhat as the 'baseline'. Now I've been using openSuse for so long I consider that to be my reference. And so it goes. Times change, and I've changed with them :-) And lets not forget that many of the distributions had a development and a stable production version. Redhat was like that with their 'Enterprise' level (RHEL) and 'Fedora;, the FOSS/development side. Until recently we had OpenSuse and SLES/SLED. The OpenSuse/Fedora were recognized to be a community development edition and potentially unstable, certainly not for the likes of Wall Street or Government/Military!
I don't find it better, so where is the advantage?
There's a great deal of subjectivity here. Systemd can do many things that sysv-init can't, as I've mentioned elsewhere, which may or may not be relevant to specific individuals, such as multi-seat management, cgroup stuff that impacts things like Docker, SELinux integration and more. It may be that systemd has advantages to you that you haven't explored (yet, as is the case for me, Docker is my agenda but not yet ...).
Further, I see no advantage for using systemd on a server at all.
Perhaps you should read up some of Pottering's articles on that issue. Things like cgroup management, quota management and more are certainly relevant to some server use-cases. It may be that at some time in the future you may need or benefit from some of the things that systemd can do.
This echoes of the KDE4 changeover where people who had issues with it were told to get over it. That no one wanted to hear what we had to say and that KDE4 was the way forward.
That's not entirely fair for a couple of reasons. leaving aside, for the moment, the 'asshole-ness' aspects, of dumping KDE4 MASSIVELY unfinished (up until .12 in my opinion!), lets not forget that this is FOSS, and end users get to do not just the beta testing but the Alpha testing to!
From my PoV, "KDE5" did slightly better, working out as an alternative install from the 13.2 days before being the norm in Leap42. But from my PoV, and what I see reported on this forum, 42.1 was beta and still beta when 42.2 came out. Perhaps not as problematic as KDE4, but not 'Production Quality" as I expect.
My big complaint about the way systemd was initially presented was that some distributions (you know who I'm thinking of!) forced it on *all* users as the *only* version of their Linux, rather than in parallel with a sysv-init version. I think that there should have been an 'optional'/experimental' distribution available that people who wanted to try a potentially unstable, incompletely implanted version. We had a similar issue with BtrFS, but there you could install your RootFS with ext4FS. Any 'new' software is, almost by definition, incomplete. It takes time to do the conversion of old facilities and to write the new stuff. And yes it has to be tested by someone outside the development group. But when the distributors make the incomplete, experimental code their normal release and offer no alternative of course people are going to be unhappy! Of course systemd gained a bad reputation. That we still talk of the disaster that was the release of KDE4 is indicative of how the negatives stay with us even when the problems have been overcome. -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Sun, Oct 2, 2016 at 10:14 PM, Anton Aylward <opensuse@antonaylward.com> wrote:
It may be that at some time in the future you may need or benefit from some of the things that systemd can do.
I don't dispute that.
Of course systemd gained a bad reputation. That we still talk of the disaster that was the release of KDE4 is indicative of how the negatives stay with us even when the problems have been overcome.
I was one of the people who pushed to have KDE3 in 11.1 instead of dropping it since KDE4 was in such sad shape back then. I haven't been very active(life kinda gets in the way - kids, overtime, bills, etc) and don't really do much computer work professionally anymore. It's not that I'm against systemd(and I wasn't against KDE4 - I just didn't see any advantage in it and still don't for myself at any rate). I'm just not sure why the devs are so hell bent on swallowing up everything(as I noted in my reply to Richard) and taking away choice. Heck, I wish I could run firefox decently on my old laptop(P3/1.2Ghz/1GB RAM). I'm typing on a Core2 laptop now with 3GB RAM that's 10 years old. Still does everything I need it to do, even with current software. Why not upgrade? Well, I'm using the last 4x3 Thinkpad they made(T60p - 1600x1200). Shoot, I still use a slider/keyboard phone that's 4 years old but still LTE(and I have spares since they don't make them anymore). -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 10/03/2016 04:20 AM, Larry Stotler wrote:
Well, I'm using the last 4x3 Thinkpad they made(T60p - 1600x1200).
*sigh* I keep watching eBay ... I don't have a great deal of need for an Intel/laptop .. BUT There are a few public domain/community version of programs written in Java such as XMind and Freeplane that I'd love to use on my tablet. What this <excreta> about Android using Java and Java being 'write once, run anywhere' but those Java application won't run on Android's Java! If I have to get a laptop just to I can do Powerpoint presentations etc etc, and I'd rather XMind in presentation mode, then I don't want some PC that will take over my life, especially not these days here in Canada we seem to have -- perhaps Federally mandated - all laptops with the dorky bilingual keyboards with the incorrectly places and shaped keys. A T60p would be nice. Mind you, a pair of 20" displays @ 1600x1200 side by side (possibly in page-mode orientation) on my desk would be nice as well. Dream on, Anton, Dream on. -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Anton Aylward wrote:
There are a few public domain/community version of programs written in Java such as XMind and Freeplane that I'd love to use on my tablet.
What this <excreta> about Android using Java and Java being 'write once, run anywhere' but those Java application won't run on Android's Java!
Android apps are written in Java, but that's not the same as you being permitted to run any arbitrary bit of Java on your Android machine. -- Per Jessen, Zürich (14.8°C) http://www.dns24.ch/ - free dynamic DNS, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2 October 2016 at 23:02, Larry Stotler <larrystotler@gmail.com> wrote:
You just made my argument for me. All I did was say "hey I dont care for it, but it is care for by others so just give me a way to not have to use it" and you go and try to tell me what to do. So basically, if I don't agree with you, I shouldn't be here on this list and shouldn't use openSUSE - even tho I have been using it and supporting it for 17 years.
For the last 6 of those 17 years, openSUSE has been talking about using systemd For the last 5 of those 17 years, since 11.4 at the beginning of 2011, openSUSE has been shipping systemd. By the end of that year, in openSUSE 12.1 it was running by default. The best time to discuss or raise actionable objections to systemd in openSUSE were 6 years ago, in 2010, before the openSUSE community made a collective decision to go there. An acceptable time would have been any time during 2011 or even into 2012, there is of course the reality that these things sometimes take some time for peoples opinions to coalesce But in 2016, 5 years after implementation and 4 years after the official support end date of the last non-systemd openSUSE distribution? I'm sorry, that ship has sailed, crossed the ocean, docked, set out again, circumnavigated the globe, and is going around again
I admin Linux systems and I find using systemd more difficult than what I am used to. I don't find it better, so where is the advantage? Further, I see no advantage for using systemd on a server at all. But that's MY experience, which is obviously different from YOURS. However, I'm not telling you to go away just because we disagree.
I am asking you to do take the time to learn about systemd before considering your opinion on it as complete. systemd is downright amazing on servers. Want to make a service that automatically deletes files in a folder every time they appear? That's like 3 lines in a systemd unit file, done using systemd's more dynamic features, like having services start only when required, is a dreamy way of optimising your servers http://0pointer.de/blog/projects/socket-activated-containers.html unlike ancient, old, useless init systems that preceded it, systemd KNOWS the state of the boot and the services it required. Not guessing it and hoping for dozens of well written init scripts to be able to detect and report their status truthfully, but KNOW, to the point where a simple systemctl can show you the status of every single service and it's health. http://0pointer.de/blog/projects/systemd-for-admins-1.html systemd uses cgroups by default - Again, this ensures you as an admin CAN know every process a service owns - No more dighttp://0pointer.de/blog/projects/on-etc-sysinit.htmlging around ps and trying to figure out what bloody processes another service started. No more mystery processes that escaped the service by wonderful forking tricks (yes I'm looking at you apache), every service is running in a cgroup, so a simple systemctl status shows the processes in that group. http://0pointer.de/blog/projects/systemd-for-admins-2.html Want to limit or prioritise cpu, memory or IO resources to one service over another? Sure! http://0pointer.de/blog/projects/resources.html I could go on.. actually I will Want to figure out EXACTLY which services are taking a long time to boot and the role they play in the critical boot chain? systemd has tools that can answer that.. http://0pointer.de/blog/projects/blame-game.html As a sysadmin you want to be in complete control of your system You want to be able to override the settings and scripts that distributions have given you for the services they have packaged Can you do that with sysvinit? not on your life - as soon as you install the upgraded version of the package all those customisations will be thrown away With systemd, you have various ways of selectively, or entirely, replacing distribution systemd configuration with exactly what you need, in a way which does not interfere with distributions doing their responsible role of providing sane defaults for those services http://0pointer.de/blog/projects/on-etc-sysinit.html Got a service you want to run 10 times with just one parameter different, such as we do with openQA where we're running multiple worker services on the same host - systemd makes it easy - http://0pointer.de/blog/projects/instances.html aaaand now I'm getting tired of signing systemd's praises.. I COULD go on..and frankly the fact that I could after writing all of the above should probably give any systemd-sceptic, especially a sysadmin-systemd-sceptic, pause for thought and start them wondering whether systemd really is the nasty monster the rumours have made it out to be, or whether any sysadmin who isn't getting up to speed on what this can do is going to be left without the skills and expertise to actually manage the linux systems of today, never mind tomorrow. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Mon, Oct 3, 2016 at 3:41 AM, Richard Brown <RBrownCCB@opensuse.org> wrote:
For the last 6 of those 17 years, openSUSE has been talking about using systemd
From my experience, over the years the number 1 issue I've had with most linux distros is dependency hell. You try to remove something unneeded/unwanted and you almost get a broken system. I come from CP/M, DOS, & OS/2. While each had it's own issues, when you got them running right, they ran. With Linux, it seems I'm always having to update everything all the time. I like the LTS approach that uBuntu uses(just don't care for uBuntu). If we had something like that on openSUSE(kinda like SLE but more open) I'd probably use it. Heck, I
I have been busy with life and not that involved. I generally just lurk and comment very occasionally. I'm not saying systemd is all bad or that it doesn't make things better for a lot of people. My point is that it's trying to take over the whole ecosystem, which isn't what it was presented to folks as originally. First it was an init replacement, then they kept adding in all these other services and it's becoming a ogre in the corner. Why should a desktop (GNOME) require an init system as a dependency? Even though people were told that KDE4 was the way it was, we have a team at openSUSE keeping KDE3 alive and we have TDE(which is what I use) as well. So, we have choice. think my server is still running 12.3....... I looked through all your use cases, and they don't really apply to me. I have simple needs for my own systems as well as the few systems I babysit. Shoot, I still have an 11.0 system in production at one place - mainly because it has never had an issue and never given a problem other than a hardware failure(RAM) about a year ago). It just runs file/print services, and does daily backups of the client systems. It has net access, but it's behind a robust firewall. There's a spare drive that gets cloned bi-yearly for the root drive that sits in a firesafe). Nice and simple. Choice is really what a lot of people want. We have different distros, different DEs(KDE vs GNOME and the rest), different browsers(Firefox vs Chrome), different editors(emacs vs vi), and so on. Why is it that we can't have a choice in init? Now, I'm aware that keeping a distro going is a monumental task, and I don't expect miracles. I'm not asking the devs to fight the river of change now. I just don't see why we need to let systemd creep over and keep swallowing other non init services and functions. It's like they are stacking the deck for their own pet projects - If they create a dependency on something with systemd, then they take control of the project. When it is going to become GNU/systemd? Or just systemdOS?(and hey, if people want that then go for it. There's still the BSDs and Slackware). -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Mon, Oct 3, 2016 at 11:09 AM, Larry Stotler <larrystotler@gmail.com> wrote:
Why should a desktop (GNOME) require an init system as a dependency?
It does not require it. You are mistaken. ...
Choice is really what a lot of people want.
Which is exactly what you have been told from the very beginning - this distribution made its choice. So what exactly is wrong with it? You allow others to make their choice only if they agree with your choice? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 3 October 2016 at 10:09, Larry Stotler <larrystotler@gmail.com> wrote:
Choice is really what a lot of people want. We have different distros, different DEs(KDE vs GNOME and the rest), different browsers(Firefox vs Chrome), different editors(emacs vs vi), and so on. Why is it that we can't have a choice in init? Now, I'm aware that keeping a distro going is a monumental task, and I don't expect miracles. I'm not asking the devs to fight the river of change now. I just don't see why we need to let systemd creep over and keep swallowing other non init services and functions. It's like they are stacking the deck for their own pet projects - If they create a dependency on something with systemd, then they take control of the project. When it is going to become GNU/systemd? Or just systemdOS?(and hey, if people want that then go for it. There's still the BSDs and Slackware).
Hell hath frozen over - I'm going to quote a Red Hat developer to reply to you http://www.redhat.com/archives/fedora-devel-list/2008-January/msg00861.html "If I could only have one thing this year, it would be to eliminate that meme from the collective consciousness. It is a disease. It strangles the mind and ensures you can never change anything ever because someone somewhere has OCD'd their environment exactly how they like it and how dare you change it on them you're so mean and next time I have friends over for Buffy night you're not invited mom he's sitting on my side again. As a consumer, yes, you have lots of choices in which Linux you use. This does not mean Linux is in any sense _about_ choice, any more than because there are so many kinds of cars you can buy that cars are about choice." The only choices that matter in opeSUSE are the choices which the openSUSE community bothers to put together. If the openSUSE community worked together to support sysvinit as well as systemd, sure, I'd support that. But unlike GNOME + KDE, or vi + emacs, or Firefox + Chrome, supporting 2 init systems is a totally different situation With your other examples, those alternatives co-exist happily with no effort from either 'side', worst case you need the two sides to get together and work on shared solutions every once in a while Supporting two init systems requires a huge amount of work, ESPECIALLY when that other init system is sysvinit. EVERY SINGLE SERVICE will need to have a systemd unit file (normally easy) AND a sysvinit script (normally complicated as heck). EVERY SINGLE MAINTAINER of EVERY SINGLE SERVICE will need to do extra work to continue to support sysvinit, and that work is typically harder than the support required to continue to support systemd If someone managed to persuade all of our service contributors to do all of that work, wow, cool, great, but you only need to look at anti-systemd distributions like Devuan to see that creating a maintaining a non-systemd distribution in this day and age is a huge amount of work that will generally keep you far behind modern developments.. and Devuan have the benefit of not offering choice, only offering sysvinit, so they have less work to do that your proposed push for 'choice'. Linux isn't about choice. openSUSE isn't about choice. It's about doing things the right way for the modern use cases faced by our users, built the right way using the modern tools available to our contributors. Sometimes that means choices present themselves, sometimes not. Regards, Richard Brown openSUSE Chairman -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Richard Brown wrote:
The only choices that matter in opeSUSE are the choices which the openSUSE community bothers to put together.
First problem -- don't say it is the 'community' -- it's the "board" that makes the directions and allows those who wish to help that direction to work on creating the next distro. The community, OTOH, submitted compatibility patches for various things (before systemd) in the past that were rejected, since the board choice was to disable the choice that could have been supported w/the patch. That story has been played again and again.
If the openSUSE community worked together to support sysvinit as well as systemd, sure, I'd support that.
you might, but the board wouldn't.
But unlike GNOME + KDE, or vi + emacs, or Firefox + Chrome, supporting 2 init systems is a totally different situation
--- Not really -- unless they are not just limited to "init".
With your other examples, those alternatives co-exist happily with no effort from either 'side', worst case you need the two sides to get together and work on shared solutions every once in a while
Supporting two init systems requires a huge amount of work, ESPECIALLY when that other init system is sysvinit.
---- Not at all. The first reason it became "impossible" is that systemd refused to allow co-existence, and absorbed compatibility interfaces to disallow it working with other parts. Second major reason -- is systemd didn't develop an "init" system, then stop. It's has absorbed several - scores of other functions and is continuing to do so. So you can't have systemd handle "init" and then use something else to manage cgroups, power, your system log, login, system-console, mount, device management, cleaning-tmpfiles, etc, etc, etc. You can't just drop in systemd, and continue to use a BUNCH of things that are NOT sysVinit. Logging, mounting, udev -- they are all being rearchitected to merge w/systemd and won't function without it. That's the MAIN reason why choice was eliminated, as systemd provides all the choices -- it is one monolithic (yes, it is -- because the parts won't inter-connect with anything but systemd-parts) piece of SW that is designed to crowd out and extinguish any competing part that it has taken over.
EVERY SINGLE SERVICE will need to have a systemd unit file (normally easy) AND a sysvinit script (normally complicated as heck).
Laugh! LSI included a 39-line auto-converter to generate sysd-unit files on the fly, from existing scripts. It's automated in a 39-line shell script -- and you call that "complicated as heck"?
EVERY SINGLE MAINTAINER of EVERY SINGLE SERVICE will need to do extra work to continue to support sysvinit, and that work is typically harder than the support required to continue to support systemd
Turn that around -- They need do nothing to extra to support systemd (the sysVinit scripts were already written) -- just run the converter on the fly.
you only need to look at anti-systemd distributions to see that creating a maintaining a non-systemd distribution in this day and age is a huge amount of work
It's only because systemd has made it hard to do the opposite, because it's not just an init system. If developers only wrote startup-and shutdown scripts according to the LSB guidelines, then auto-generation of systemd unit files would be automatic and involve no work on their part.
Linux isn't about choice[sic].
It's not linux that isn't about choice, but systemd. linux was designed based on unix principles where parts interacted in well defined ways and parts were *interchangeable*. It's systemd that has broken that interchangeable parts paradigm and it's systemd that is working to change all of linux to be without choice, since choice threatens the large "status quo" corporations. MS would have required secure boot with Win10 to only allow MS-signed binaries to boot on all PC's, if it wasn't for the prevalence of alternatives. So what to do? Convert linux to another closed ecosystem that will only let corporate signed binaries run. Just like Anton complained about JavaScript programs written to run anywhere javascript runs, not running on google devices -- because it's not about js being "closed source", but the ecosystem being closed, with only google-allowed binaries to run. Similarly, systemd and linux will be used to create a closed "linux"[sic] ecosystem, and then the other close-OS providers will be able to compete and fully close their systems, as there will only be fringe distros/providers that provide open-OS's and they won't be able to run on the majority of HW platforms that will then be available. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 6 October 2016 at 23:37, Linda Walsh <suse@tlinx.org> wrote:
Richard Brown wrote:
The only choices that matter in opeSUSE are the choices which the openSUSE community bothers to put together.
--- First problem -- don't say it is the 'community' -- it's the "board" that makes the directions and allows those who wish to help that direction to work on creating the next distro.
The community, OTOH, submitted compatibility patches for various things (before systemd) in the past that were rejected, since the board choice was to disable the choice that could have been supported w/the patch. That story has been played again and again.
Linda, Your above statement is absolutely unadulterated unquestionable baseless nonsense The Board's role is to provide guidance and decision making assistance when necessary, not to declare or force contributors to do anything. The openSUSE Board is strict and strong believers in the principle of "Those Who Do, Decide", and it is a simple fact that in openSUSE something only gets done because someone (a contributor or a group of contributors) decides and then actually does the actual work. The only role the openSUSE Board plays in technical decision making processes is when a matter is escalated to us from those contributors This might be because the contributors in question want a second opinion, which we're happy to share More importantly, the Board is the escalation point when two members or groups of the community have both decided to 'do' something which conflicts with each other Resolving these "community deadlocks" is one of the most important roles of the Board and the most likely opportunities where the board can directly influence the technical direction of the Project. However, in keeping with our Guiding Principles, the Board's first priority is ALWAYS to get those conflicted developers to communicate to each other and the Board works very hard to encourage and foster a compromise that satisfies all involved parties. It is only as an absolute last resort that "The Board" would make a decision to effectively overrule the decisions of the "community" and in that case it would be to support a different decision also made by the "community" Therefore, you cannot argue that "The Board" makes those decisions. The openSUSE contributors decide the direction of this project. Full stop.
If the openSUSE community worked together to support sysvinit as well as systemd, sure, I'd support that.
--- you might, but the board wouldn't.
Ahem, I am 1/6 of the Board, but to clarify let me rephrase what I said "If the openSUSE community worked together to support sysvinit as well as systemd, sure, I would support that, and I can guarantee based on my experience from being a Board member for many years now, and an openSUSE contributor for many more, that the openSUSE Board would also support it, just as they support any contributors working on anything which 'scratches an itch' the openSUSE Project can help solve" That said, I might never actually USE sysvinit again, wouldn't recommend the fruits of their labour to others, and I'd think it would be a monumental waste of time for everyone involved, but if they are going to do all the work required to make it work, then who the heck am I to stop them? Richard Brown openSUSE Chairman -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 10/07/2016 02:10 AM, Richard Brown wrote:
That said, I might never actually USE sysvinit again, wouldn't recommend the fruits of their labour to others, and I'd think it would be a monumental waste of time for everyone involved, but if they are going to do all the work required to make it work, then who the heck am I to stop them?
What this all boils down to, Linda -- and tohers -- is that if yu are so fervently anti-systemd, so pre-sysv-init, then make teh effort to support the sysv0init code base, keep it maintained and functioning as an alternative. Put up or shut up. Richard and the board aren't going to stop you if you are willing to put the effort in to support this as an alternative. As he says, he'll encourage you, IF YOU ARE WILLING TO MAKE THE EFFORT. It happened, as many of you anti-systemd-ers are so keen to point out with KDE3. That's because there are people willing to make the effort to support it. If you are that vociferousness, then act. There's no-one stopping you, this is FOSS. The old code is out there. Put up or shut up. Richard is too polite to say it, but what he does say amounts to the same thing. This is FOSS. If you don't like how it is work on an alternative. Make it happen. No one is stopping you. You make it happen, show the commitment, deliver the stuff and the board will support you. Put up or shut up. -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Friday, 7 October 2016 07:54:26 BST Anton Aylward wrote:
On 10/07/2016 02:10 AM, Richard Brown wrote:
That said, I might never actually USE sysvinit again, wouldn't recommend the fruits of their labour to others, and I'd think it would be a monumental waste of time for everyone involved, but if they are going to do all the work required to make it work, then who the heck am I to stop them?
What this all boils down to, Linda -- and tohers -- is that if yu are so fervently anti-systemd, so pre-sysv-init, then make teh effort to support the sysv0init code base, keep it maintained and functioning as an alternative. Put up or shut up.
Richard and the board aren't going to stop you if you are willing to put the effort in to support this as an alternative. As he says, he'll encourage you, IF YOU ARE WILLING TO MAKE THE EFFORT.
It happened, as many of you anti-systemd-ers are so keen to point out with KDE3. That's because there are people willing to make the effort to support it.
If you are that vociferousness, then act. There's no-one stopping you, this is FOSS. The old code is out there. Put up or shut up.
Richard is too polite to say it, but what he does say amounts to the same thing.
This is FOSS. If you don't like how it is work on an alternative. Make it happen. No one is stopping you. You make it happen, show the commitment, deliver the stuff and the board will support you. Put up or shut up.
Nicely put, should be a standard reply to all detractors of any software.
> Q: Are you sure? > >> A: Because it reverses the logical flow of conversation. >> >>> Q: Why is top posting frowned upon?
-- opensuse:tumbleweed:20161003 Qt: 5.7.0 KDE Frameworks: 5.26.0 KDE Plasma: 5.7.4 kwin5-5.7.4-1.3.x86_64 kmail5-16.08.1-1.2.x86_64 Kernel: 4.7.5-1-default Nouveau: 1.0.13_1.1 -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Le 07/10/2016 à 19:09, ianseeks a écrit :
On Friday, 7 October 2016 07:54:26 BST Anton Aylward wrote:
This is FOSS. If you don't like how it is work on an alternative. Make it happen. No one is stopping you. You make it happen, show the commitment, deliver the stuff and the board will support you. Put up or shut up.
Nicely put, should be a standard reply to all detractors of any software.
not completely. I admit that such thread deserve such answer. But for the record, even FOSS authors should be aware than they need a user base and have on some extend to listen it. Some people can be very useful describing problems, translating, documenting and so on. simply reporting problems. But any criticism should be made positive. aimed to make things better, when this thread for a great part can only drive people out of FOSS... Well, guys, if you want trolls, I don't like this fuck of emacs and likes much more the genius of VI, what do you think? jdd (:-))) -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 10/07/2016 01:59 PM, jdd wrote:
Well, guys, if you want trolls, I don't like this fuck of emacs and likes much more the genius of VI, what do you think?
Right on, bro'! My fingers learnt classical VI on a PDP-11 long before this "VIM" and "gVIM", long before the VAX virtual memory system let the EMACS 'eight megabytes' be available for running on affordable memory while crippling the machine with its constant swapping. Modern users are spoilt with their gigabytes of RAM. And I bet my long white beard is longer that your long white beard. So there! -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Le 07/10/2016 à 22:14, Anton Aylward a écrit :
Right on, bro'!
:-)
My fingers learnt classical VI on a PDP-11 long before this "VIM" and "gVIM",
I once tried to find "the original VI", but couldn't really find one, the original ones being spread in source form https://en.wikipedia.org/wiki/Vi
long before the VAX virtual memory system let the EMACS 'eight megabytes' be available for running on affordable memory while crippling the machine with its constant swapping.
my first emacs was filling my computer so much I couldn't make any work. bet the time :-)
And I bet my long white beard is longer that your long white beard. So there!
not that sure, I didn't play with computer before having an HP-41C around 1980 (and an eprom burner :-)) jdd -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 10/07/2016 04:57 PM, jdd wrote:
I once tried to find "the original VI", but couldn't really find one, the original ones being spread in source form
To be fair, Bill Joy's original code was very unstructured, lots and lots of global variables, no built-in command interpreter, hard-coded version of an early iteration of what later became 'termcap', but was small (it could run cleanly on a PDP-11/40 with about 20 users doing development editing/compile cycles) and quite responsive. Personally I considered it unmaintainable :-) -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
* Anton Aylward (opensuse@antonaylward.com) [20161007 22:14]:
On 10/07/2016 01:59 PM, jdd wrote:
Well, guys, if you want trolls, I don't like this fuck of emacs and likes much more the genius of VI, what do you think?
Right on, bro'!
Isn't that the editor where you can place one command between two ESCs >:-> ? Philipp -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Richard Brown wrote:
On 6 October 2016 at 23:37, Linda Walsh <suse@tlinx.org> wrote:
Richard Brown wrote:
The only choices that matter in opeSUSE are the choices which the openSUSE community bothers to put together.
First problem -- don't say it is the 'community' -- it's the "board" that makes the directions and allows those who wish to help that direction to work on creating the next distro.
The community, OTOH, submitted compatibility patches for various things (before systemd) in the past that were rejected, since the board choice was to disable the choice that could have been supported w/the patch. That story has been played again and again.
Linda,
Your above statement is absolutely unadulterated unquestionable baseless nonsense.
Those are my perceptions based on 10+ years of experience w/ SuSE/OpenSuse. That you wouldn't see things the same way, being on the "inside", is not surprising.
The Board's role is to provide guidance and decision making assistance when necessary, not to declare or force contributors to do anything.
I never saw discussions about accepting systemd or not on the opensuse or opensuse-factory lists. By the time I saw anything, I was told it was decided. As for patches -- I submitted patches for various products, but in specific, for one good example, with vim/gvim, I submitted a build patch for the rpm to allow the executable(s) to *attempt* to dynamically load the script languages at runtime, and dynamically configure available script options based on what was able to be included (as it does on Windows). This was after being in repair mode, trying to run vim but being told it wouldn't run because it couldn't find libs for various languages (ruby, python, perl) so it couldn't "edit" any files. ??? I didn't need to run scripts -- I wanted to edit the files -- but the vim builder had hard-linked all the script engines in to require them present at runtime -- in ORDER to edit files. Similarly I tried to submit support for building perl without lots of version requirements so vim could try to load the current perl (if it failed, no perl support) -- as it used to be able to before someone got very nit-picky to not even allow different "patch-level" releases of perl to be loaded or used in place of an early perl of the same major-minor version. I even provided statements from the perl developers that the patch-level versions were designed to be compatible so people could update a bug in perl without having to recompile®enerate all the modules for a specific major-minor perl. But the suse builder refused, pretty much running around talking about how the the sky would be falling if that was allowed. Pleh! I'd done it for 4-5 years in suse before that with no problems, now due to version hell, I havn't had many components of yast running since 12.3. yast to run.
The openSUSE Board is strict and strong believers in the principle of "Those Who Do, Decide",
--- And there's the rub -- Who is allowed to "DO". It's a cute saying, but when who is allowed to "Do" is controlled, the whole thing becomes a different way of controlling what is done and what is decided. In a similar way, one of our worst presidents in history, George Bush II, fired all government employees who couldn't be verified to be loyal Republicans. Such had never been done in recent memory, and threw away scores of decades of experience by firing career employees who had been at their jobs through many presidents. By only allowing Republicans in government offices (including the federal courts), they could ensure only decisions favorable to the party's political views would be made. I couldn't even get a OBS account to work and was finally told I should create and register a new email to get a new account and try to set it up again, as the old one was broken (and no one knew how to fix it).
Therefore, you cannot argue that "The Board" makes those decisions. The openSUSE contributors decide the direction of this project. Full stop.
I can argue it, as the board approves who it lets volunteer and do the work. In a similar way Bush-II had control far beyond his direct-influence or power.
If the openSUSE community worked together to support sysvinit as well as systemd, sure, I'd support that.
you might, but the board wouldn't.
I saw previous, similar decisions with hoping to XFS for all disks, then not supporting it due to a hop to grub which had a bug on XFS (vs. staying with lilo which didn't show the bug). Or not supporting lilo -- even when the version from the developer still worked, or not supporting direct-boot from disk -- which is still working for me even with separate root+usr, which I was told wouldn't work and wouldn't be supported, even though it is recommended in systemd documentation for better performance. When I asked for reasons why it was required to create unstable forward-symlinks (forward to partitions that hadn't been mounted yet) in /bin to /usr/bin, vs. the *safer* alternative of putting the binaries in /bin and back-links in /usr/bin to it's parent fs where /usr is mounted. I was told it was already decided by the "doers" and couldn't be fixed and wouldn't be done. When I asked why /usr couldn't be mounted in early boot (S01boot.usr-mount) to make sure /usr was available for other boot & starting services that needed it, I was told it couldn't be done (yet that is how my system is running). I've had tons of such experiences to show me how open Suse really is, to say that it's simply "not true" is ignoring the many times Suse has been closed because the "ship has sailed around the world N times... etc".. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 8 October 2016 at 22:31, L. A. Walsh <suse@tlinx.org> wrote:
The Board's role is to provide guidance and decision making assistance when necessary, not to declare or force contributors to do anything.
--- I never saw discussions about accepting systemd or not on the opensuse or opensuse-factory lists. By the time I saw anything, I was told it was decided.
I remember them They were very long They also included debates at conferences like openSUSE Conference 2010 and 2011
As for patches -- I submitted patches for various products, but in specific, for one good example, with vim/gvim, I submitted a build patch for the rpm to allow the executable(s) to *attempt* to dynamically load the script languages at runtime, and dynamically configure available script options based on what was able to be included (as it does on Windows).
This was after being in repair mode, trying to run vim but being told it wouldn't run because it couldn't find libs for various languages (ruby, python, perl) so it couldn't "edit" any files. ??? I didn't need to run scripts -- I wanted to edit the files -- but the vim builder had hard-linked all the script engines in to require them present at runtime -- in ORDER to edit files. Similarly I tried to submit support for building perl without lots of version requirements so vim could try to load the current perl (if it failed, no perl support) -- as it used to be able to before someone got very nit-picky to not even allow different "patch-level" releases of perl to be loaded or used in place of an early perl of the same major-minor version.
I even provided statements from the perl developers that the patch-level versions were designed to be compatible so people could update a bug in perl without having to recompile®enerate all the modules for a specific major-minor perl. But the suse builder refused, pretty much running around talking about how the the sky would be falling if that was allowed. Pleh!
I'd done it for 4-5 years in suse before that with no problems, now due to version hell, I havn't had many components of yast running since 12.3. yast to run.
None of the above examples were anything to do with the Board All of the above examples sound like you were doing stuff with the primary maintainer wouldn't want to accept for very good reasons. If you disputed those reasons you should have discussed them with the maintainer at length at first, maybe discussed it in a broader context next and then perhaps escalated the topic TO the Board Blaming them for something they had nothing to do with just paints a picture of you as someone who has no idea how the openSUSE Project works despite your 10 years of activity with the project.
The openSUSE Board is strict and strong believers in the principle of "Those Who Do, Decide",
--- And there's the rub -- Who is allowed to "DO".
It's a cute saying, but when who is allowed to "Do" is controlled, the whole thing becomes a different way of controlling what is done and what is decided. In a similar way, one of our worst presidents in history, George Bush II, fired all government employees who couldn't be verified to be loyal Republicans. Such had never been done in recent memory, and threw away scores of decades of experience by firing career employees who had been at their jobs through many presidents. By only allowing Republicans in government offices (including the federal courts), they could ensure only decisions favorable to the party's political views would be made.
Politics have no place here. I consider your analogy as both baseless and offensive, and kindly request to stick to our guiding principles and avoid being so in the future.
I couldn't even get a OBS account to work and was finally told I should create and register a new email to get a new account and try to set it up again, as the old one was broken (and no one knew how to fix it).
The Board also had nothing to do with this Do you have the ticket number for your support call with our infra team (admin@opensuse.org) regarding your account issues?
Therefore, you cannot argue that "The Board" makes those decisions. The openSUSE contributors decide the direction of this project. Full stop.
--- I can argue it, as the board approves who it lets volunteer and do the work. In a similar way Bush-II had control far beyond his direct-influence or power.
Ok, you can argue. You are wrong. The Board does not appoint maintainers. The Board does not approve volunteers. The people doing the work, are the people doing the work, the ones who have stepped up and posted on opensuse-factory and said "I will take the responsibility for $foo" and then poured their efforts behind that commitment The Board has no say in such matters, it's a simple case of "if no one else is taking care of it, thanks, you're it!" and if someone else is taking care of it then the expectation is that the parties involve find a way to work together (and only if they can not, is there the possibility that the Board might end up involved to resolve that conflict between contributors).
If the openSUSE community worked together to support sysvinit as well as systemd, sure, I'd support that.
--- you might, but the board wouldn't.
--- I saw previous, similar decisions with hoping to XFS for all disks, then not supporting it due to a hop to grub which had a bug on XFS (vs. staying with lilo which didn't show the bug). Or not supporting lilo -- even when the version from the developer still worked, or not supporting direct-boot from disk -- which is still working for me even with separate root+usr, which I was told wouldn't work and wouldn't be supported, even though it is recommended in systemd documentation for better performance.
When I asked for reasons why it was required to create unstable forward-symlinks (forward to partitions that hadn't been mounted yet) in /bin to /usr/bin, vs. the *safer* alternative of putting the binaries in /bin and back-links in /usr/bin to it's parent fs where /usr is mounted. I was told it was already decided by the "doers" and couldn't be fixed and wouldn't be done.
Yes, people doing more work for you, who are actively maintaining more parts of the distribution, are going to have more influence on the technical decision of the project..that is the very essence of "Those who do, decide" "I did this one small thing so I get to decide despite the impact that has" is not a valid operational mantra of the openSUSE Project. The lesson I think you need to take away from this thread is that "doing" does not include mailinglist posts. I have long seen you on our lists and I know you have submitted things from time to time, but I have never seen you step up and take responsibility for any part of the openSUSE distribution, to effectively 'own' something as part of our community project, and to do all that such entails, such as taking the initiative, driving the effort, and working with others to make everything work together. sysvinit could have been that thing, it could have been it back in 2010, it could still be it now (admittedly with more work for you). But if you don't do the work, we're just going to be wasting our breaths and electrons on this mailinglist. If you only ever throw stones over the wall, either in the form of drive-by patches or grumpy mailinglist posts, you need to expect those stones to be thrown back. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
I'll keep on repeating these mantras: openSUSE is you, me, all of us. This means including the members of the board. Who are as much "community" as any other person involved in or using (parts of) the openSUSE project. Hence there is no "community vs. board" In other words: there can be no "team vs. it's members". (dot) Gertjan Lettink, a.k.a. Knurpht openSUSE Board Member openSUSE Forums Team Op donderdag 6 oktober 2016 14:37:22 CEST schreef Linda Walsh <suse@tlinx.org> :
Richard Brown wrote:
The only choices that matter in opeSUSE are the choices which the openSUSE community bothers to put together.
--- First problem -- don't say it is the 'community' -- it's the "board" that makes the directions and allows those who wish to help that direction to work on creating the next distro.
I won't accept this statement as an accurate representation of reality.
The community, OTOH, submitted compatibility patches for various things (before systemd) in the past that were rejected, since the board choice was to disable the choice that could have been supported w/the patch. That story has been played again and again.
If the openSUSE community worked together to support sysvinit as well as systemd, sure, I'd support that.
--- you might, but the board wouldn't.
Nor this statement.
But unlike GNOME + KDE, or vi + emacs, or Firefox + Chrome, supporting 2 init systems is a totally different situation
--- Not really -- unless they are not just limited to "init".
Start giving it a try,
With your other examples, those alternatives co-exist happily with no effort from either 'side', worst case you need the two sides to get together and work on shared solutions every once in a while
Supporting two init systems requires a huge amount of work, ESPECIALLY when that other init system is sysvinit.
---- Not at all. The first reason it became "impossible" is that systemd refused to allow co-existence, and absorbed compatibility interfaces to disallow it working with other parts. Second major reason -- is systemd didn't develop an "init" system, then stop.
It's has absorbed several - scores of other functions and is continuing to do so. So you can't have systemd handle "init" and then use something else to manage cgroups, power, your system log, login, system-console, mount, device management, cleaning-tmpfiles, etc, etc, etc.
You can't just drop in systemd, and continue to use a BUNCH of things that are NOT sysVinit. Logging, mounting, udev -- they are all being rearchitected to merge w/systemd and won't function without it.
That's the MAIN reason why choice was eliminated , as systemd provides all the choices -- it is one monolithic (yes, it is -- because the parts won't inter-connect with anything but systemd-parts) piece of SW that is designed to crowd out and extinguish any competing part that it has taken over.
That's an explicit and very serious accusation of the developpers of systemd. Please reread and think again.
EVERY SINGLE SERVICE will need to have a systemd unit file (normally easy) AND a sysvinit script (normally complicated as heck).
--- Laugh! LSI included a 39-line auto-converter to generate sysd-unit files on the fly, from existing scripts. It's automated in a 39-line shell script -- and you call that "complicated as heck"?
Reread what's been called "complicated as heck".
EVERY SINGLE MAINTAINER of EVERY SINGLE SERVICE will need to do extra work to continue to support sysvinit, and that work is typically harder than the support required to continue to support systemd
---- Turn that around -- They need do nothing to extra to support systemd (the sysVinit scripts were already written) -- just run the converter on the fly.
you only need to look at anti-systemd distributions to see that creating a maintaining a non-systemd distribution in this day and age is a huge amount of work
and simultaniously check which of the anti-systemd distros of the past now happily use it ....
---- It's only because systemd has made it hard to do the opposite, because it's not just an init system. If developers only wrote startup-and shutdown scripts according to the LSB guidelines, then auto-generation of systemd unit files would be automatic and involve no work on their part.
Linux isn't about choice[sic].
--- It's not linux that isn't about choice, but systemd. linux was designed based on unix principles where parts interacted in well defined ways and parts were *interchangeable*. It's systemd that has broken that interchangeable parts paradigm and it's systemd that is working to change all of linux to be without choice, since choice threatens the large "status quo" corporations. MS would have required secure boot with Win10 to only allow MS-signed binaries to boot on all PC's, if it wasn't for the prevalence of alternatives. So what to do? Convert linux to another closed ecosystem that will only let corporate signed binaries run.
Just like Anton complained about JavaScript programs written to run anywhere javascript runs, not running on google devices -- because it's not about js being "closed source", but the ecosystem being closed, with only google-allowed binaries to run.
Similarly, systemd and linux will be used to create a closed "linux"[sic] ecosystem, and then the other close-OS providers will be able to compete and fully close their systems, as there will only be fringe distros/providers that provide open-OS's and they won't be able to run on the majority of HW platforms that will then be available.
Well, you've made your point, you don't like systemd, and you're still frustrated about the fact that systemd became the de facto standard. And you're convinced sysVinit is a better future. Now what? What a project basically needs is people who step up and do the job. Like the ones that wanted KDE3 to stay and started the Trinity project.... -- Gertjan Lettink, a.k.a. Knurpht openSUSE Board Member openSUSE Forums Team -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Knurpht - Gertjan Lettink wrote:
But unlike GNOME + KDE, or vi + emacs, or Firefox + Chrome, supporting 2 init systems is a totally different situation
Not really -- unless they are not just limited to "init".
Start giving it a try,
--- It's a bit late to make it easy. If they started when sysV was still in place and added auto-port options for systemd, it would have been reasonably possible, but now, you'd have to reinvent the wheel -- also true is systemd is a monolithic piece of SW that has replace so much -- requiring any replacement of it to supply replacements for everything it has replaced.
That's the MAIN reason why choice was eliminated, as systemd provides all the choices -- it is one monolithic (yes, it is -- because the parts won't inter-connect with anything but systemd-parts) piece of SW that is designed to crowd out and extinguish any competing part that it has taken over.
That's an explicit and very serious accusation of the developpers of systemd. Please reread and think again.
I've read many times. I'm not the only one who has noticed systemd's lack of allowing alternatives. Show me how I could run my own "init(pid=1)" that implements a subscriber service for dying pid notifications... I believe you'll find it can't be done without modifying systemd -- and that such modifications won't be accepted upstream.
EVERY SINGLE SERVICE will need to have a systemd unit file (normally easy) AND a sysvinit script (normally complicated as heck).
Laugh! LSI included a 39-line auto-converter to generate sysd-unit files on the fly, from existing scripts. It's automated in a 39-line shell script -- and you call that "complicated as heck"?
Reread what's been called "complicated as heck".
--- You mean the scripts -- all of which were already written? It was a well understood technology that provided skeleton.templates for new services that were remarkably easy to generate services with.
Well, you've made your point, you don't like systemd, and you're still frustrated about the fact that systemd became the de facto standard.
You don't get my point. It's systemd's bad design I don't like. You can't replace parts and it doesn't allow use of standard interfaces if you tried. Maybe I want systemd to start my daemons, but not be PID 1. Will it allow that? Nope. Because it ties everything together, I can't use the parts I like -- give it everything, or nothing are the two options -- systemd was designed to not allow use of it's parts separately from init. A simple init could have provided info on processes dying with a subscription model, the same way the OS provides notices of file-alteration through something like famd -- allowing many programs to use the notification feature. The programs don't have to be installed in the kernel to monitor the files or monitor process death. But if one program replaces the standard interface and famd breaks? A bunch of other programs stop working. That systemd replaces pid-1 disallows any other "sharing" program that could notify all programs -- not just systemd or its tentacles. If anything goes wrong in systemd, you need to do the Microsoft-reboot dance, which is pathetic. I can't see businesses worried about uptime being happy about that. Init(pid1) could be a small separate program that was built for a specific purpose and provided a pid-death-notification service that could be used by "anyD" and wouldn't be hard to write -- but it won't work with sysD, which, I'm told, won't run unless it is started as pid-1. That's what I mean by sysD not being a team player that even *allows* any alternative -- it shuts down avenues of compatibility. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 3 October 2016 at 10:09, Larry Stotler <larrystotler@gmail.com> wrote:
I like the LTS approach that uBuntu uses(just don't care for uBuntu). If we had something like that on openSUSE(kinda like SLE but more open) I'd probably use it. Heck, I think my server is still running 12.3.......
It's called openSUSE Leap It's based on SUSE Linux Enterprise, but is more open It's been the only non-rolling distribution offered by the openSUSE Project since November 2015 https://speakerdeck.com/sysrich/open-enterprise-and-open-community-working-t... -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Richard Brown composed on 2016-10-03 10:56 (UTC+0200):
Larry Stotler wrote:
I like the LTS approach that uBuntu uses(just don't care for uBuntu). If we had something like that on openSUSE(kinda like SLE but more open) I'd probably use it. Heck, I think my server is still running 12.3.......
It's called openSUSE Leap
It's based on SUSE Linux Enterprise, but is more open
It's been the only non-rolling distribution offered by the openSUSE Project since November 2015
What exactly is the "it" of which you write? I read Larry's "it" as being a 5 year support LTS product, with 5 years being its key feature.
https://speakerdeck.com/sysrich/open-enterprise-and-open-community-working-t...
FWIW, as bringing this up anywhere else has produced zero traction, my primary OS is 42.1, but, for reasons not under control of the openSUSE team, its looking like upgrading it to 42.2 (or any other distro's upcoming release) is not going to be an option for the foreseeable future, if ever, without abandoning my (non-Gnome) environment of choice: https://bugs.kde.org/show_bug.cgi?id=367499 (includes upstream bug refs., mozilla and gtk that are the actual problem) -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2016-10-03 10:56, Richard Brown wrote:
On 3 October 2016 at 10:09, Larry Stotler <larrystotler@gmail.com> wrote:
I like the LTS approach that uBuntu uses(just don't care for uBuntu). If we had something like that on openSUSE(kinda like SLE but more open) I'd probably use it. Heck, I think my server is still running 12.3.......
It's called openSUSE Leap
No. It is Evergreen, not Leap. Leap is not an LTS. An Evergreen is ending soon, so we no longer will have an LTS. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
Op maandag 3 oktober 2016 14:30:21 CEST schreef Carlos E. R. <robin.listas@telefonica.net> :
On 2016-10-03 10:56, Richard Brown wrote:
On 3 October 2016 at 10:09, Larry Stotler <larrystotler@gmail.com> wrote:
I like the LTS approach that uBuntu
uses(just don't care for uBuntu). If we had something like that on openSUSE(kinda like SLE but more open) I'd probably use it. Heck, I think my server is still running 12.3.......
It's called openSUSE Leap
No. It is Evergreen, not Leap. Leap is not an LTS. An Evergreen is ending soon, so we no longer will have an LTS.
You missed something. Leap is LTS, since it will have support for as long as the "connected" SUSE+SP versions. -- Gertjan Lettink, a.k.a. Knurpht openSUSE Board Member openSUSE Forums Team -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Mon, Oct 3, 2016 at 3:41 PM, Knurpht - Gertjan Lettink <knurpht@opensuse.org> wrote:
No. It is Evergreen, not Leap. Leap is not an LTS. An Evergreen is ending soon, so we no longer will have an LTS.
You missed something. Leap is LTS, since it will have support for as long as the "connected" SUSE+SP versions.
Normal SLE SP is not LTS. Its lifetime is 6 months after next SP is released. Usually last SP of a version becomes LTS - but then you also need to pay extra to get access to it after regular support ends. I wonder what will happen with Leap 42.4 (or whatever SP will be the last) ... will it continue to receive fixes from SLE12 SP4 LTS? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2016-10-03 14:41, Knurpht - Gertjan Lettink wrote:
Op maandag 3 oktober 2016 14:30:21 CEST schreef Carlos E. R. <> :
On 2016-10-03 10:56, Richard Brown wrote:
On 3 October 2016 at 10:09, Larry Stotler <larrystotler@gmail.com> wrote:
I like the LTS approach that uBuntu
uses(just don't care for uBuntu). If we had something like that on openSUSE(kinda like SLE but more open) I'd probably use it. Heck, I think my server is still running 12.3.......
It's called openSUSE Leap
No. It is Evergreen, not Leap. Leap is not an LTS. An Evergreen is ending soon, so we no longer will have an LTS.
You missed something. Leap is LTS, since it will have support for as long as the "connected" SUSE+SP versions.
https://en.opensuse.org/Lifetime «Each Leap Major Release (eg. 42.x) is expected to be supported for at least 36 months, until the next major version of Leap is available (eg. 43.0) A Leap Minor Release (eg. 42.1, 42.2, etc) is expected to be released annually, and users are expected to upgrade to the latest minor release within 6 months of its availability, leading to a support life cycle of 18 months » So, Leap 42.1 will stay for 18 months, 42.2 another 18 months... If I have 42.1 I have to upgrade to 42.2 in a year and a bit. I can not stay with 42.1 for two or three years. I missed nothing, there is no LTS. So no, I don't buy that the major release, 42 stays longer. I still have to do system upgrades, 3 times in the period. We do not have service packs. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
On 3 October 2016 at 14:48, Carlos E. R. <robin.listas@telefonica.net> wrote:
On 2016-10-03 14:41, Knurpht - Gertjan Lettink wrote:
Op maandag 3 oktober 2016 14:30:21 CEST schreef Carlos E. R. <> :
On 2016-10-03 10:56, Richard Brown wrote:
On 3 October 2016 at 10:09, Larry Stotler <larrystotler@gmail.com> wrote:
I like the LTS approach that uBuntu
uses(just don't care for uBuntu). If we had something like that on openSUSE(kinda like SLE but more open) I'd probably use it. Heck, I think my server is still running 12.3.......
It's called openSUSE Leap
No. It is Evergreen, not Leap. Leap is not an LTS. An Evergreen is ending soon, so we no longer will have an LTS.
You missed something. Leap is LTS, since it will have support for as long as the "connected" SUSE+SP versions.
https://en.opensuse.org/Lifetime
«Each Leap Major Release (eg. 42.x) is expected to be supported for at least 36 months, until the next major version of Leap is available (eg. 43.
A Leap Minor Release (eg. 42.1, 42.2, etc) is expected to be released annually, and users are expected to upgrade to the latest minor release within 6 months of its availability, leading to a support life cycle of 18 months »
So, Leap 42.1 will stay for 18 months, 42.2 another 18 months... If I have 42.1 I have to upgrade to 42.2 in a year and a bit. I can not stay with 42.1 for two or three years.
I missed nothing, there is no LTS.
So no, I don't buy that the major release, 42 stays longer. I still have to do system upgrades, 3 times in the period. We do not have service packs.
SLE Service packs are released once per year, and can be installed using two mechanisms, an online update using tools like zypper and an offline mechanism booting to the Service Pack Installation media The commitment from SUSE is that a SLE Service Pack is easy to upgrade to with minimal changes to expected workflows. Besides that a SLE service pack can include significant changes to the operating system, such as kernel, GNOME and systemd upgrades. openSUSE Leap Minor releases are released once per year, and can be installed using two mechanisms, an online update using tools like zypper and an offline mechanism booting to the Minor Release Installation Media The commitment from openSUSE is that a Leap Minor Release is easy to upgrade to with minimal changes to expected workflows. Besides that an openSUSE Leap Minor Release can include significant changes to the operating system, such as Kernel, GNOME, and systemd upgrades. Have I made my point, or would you like to continue splitting hairs? openSUSE Leap is an LTS release. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Le 04/10/2016 à 16:14, Richard Brown a écrit :
Have I made my point, or would you like to continue splitting hairs?
what is sure is that installing 42.1, changing the repos to 42.2 and zypper dup works like a charm. of course, one have, on his distro life, to add extra repos and these are not sure to work, but this is always true other LTS are not different, only the core is LTS... jdd -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Richard Brown composed on 2016-10-04 16:14 (UTC+0200):
The commitment from openSUSE is that a Leap Minor Release is easy to upgrade to with minimal changes to expected workflows. Besides that an openSUSE Leap Minor Release can include significant changes to the operating system, such as Kernel, GNOME, and systemd upgrades.
# zypper se -i libgtk-3 i | libgtk-3-0 | package | 3.20.9-1.1 | x86_64 | openSUSE-42.2-0 That means upstream WONTFIX bug https://bugzilla.mozilla.org/show_bug.cgi?id=1269274 , and https://bugs.kde.org/show_bug.cgi?id=367499 apply, and also the upstream WONTFIX bug they depend on https://bugzilla.gnome.org/show_bug.cgi?id=757142 , creating a usability handicap with no solution in sight. To me and I'm sure others with lower than average vision, 42.2's new UI impediment won't be posing a minimal change to important workflows.
Have I made my point, or would you like to continue splitting hairs?
openSUSE Leap is an LTS release.
I don't see LTS explicit in Leap's official description. You have not convinced me that distro shoppers looking for an LTS would consider it to be so, which is probably where the term counts the most. -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2016-10-04 19:49, Felix Miata wrote:
Richard Brown composed on 2016-10-04 16:14 (UTC+0200):
The commitment from openSUSE is that a Leap Minor Release is easy to upgrade to with minimal changes to expected workflows. Besides that an openSUSE Leap Minor Release can include significant changes to the operating system, such as Kernel, GNOME, and systemd upgrades.
openSUSE Leap is an LTS release.
I don't see LTS explicit in Leap's official description. You have not convinced me that distro shoppers looking for an LTS would consider it to be so, which is probably where the term counts the most.
That is so. I only consider an LTS if there are updates, but not upgrades. Like currently Evergreen. I'm not convinced that the jumps are minor. 70% of the distro content doesn't come from SLE. What about desktops? As I recall, SLE doesn't include KDE, it is only gnome. Then many of us use extra repositories. The admin has to decide what to do with each repository, one by one. Upgrading is actually an ordeal, and is somewhat dangerous. Probably lesser than it was, I admit that, but it has yet to be proven. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
Le 04/10/2016 à 20:56, Carlos E. R. a écrit :
Then many of us use extra repositories. The admin has to decide what to do with each repository, one by one. Upgrading is actually an ordeal, and is somewhat dangerous. Probably lesser than it was, I admit that, but it has yet to be proven.
no such repos are LTS on ubuntu neither jdd -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2016-10-04 21:47, jdd wrote:
Le 04/10/2016 à 20:56, Carlos E. R. a écrit :
Then many of us use extra repositories. The admin has to decide what to do with each repository, one by one. Upgrading is actually an ordeal, and is somewhat dangerous. Probably lesser than it was, I admit that, but it has yet to be proven.
no such repos are LTS on ubuntu neither
In openSUSE many repos continue building for evergreen. Not all. The most important, packman, continues. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
Le 04/10/2016 à 22:25, Carlos E. R. a écrit :
In openSUSE many repos continue building for evergreen. Not all. The most important, packman, continues.
nobody knows what will happen when 42 will be 3 years old. One very important step will arise soon when 42.2 come, we will see if the update is really painless. jdd -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
jdd wrote:
Le 04/10/2016 à 22:25, Carlos E. R. a écrit :
In openSUSE many repos continue building for evergreen. Not all. The most important, packman, continues.
nobody knows what will happen when 42 will be 3 years old. One very important step will arise soon when 42.2 come, we will see if the update is really painless.
We should all be testing this now, Leap422 is out in Beta. -- Per Jessen, Zürich (10.1°C) http://www.hostsuisse.com/ - virtual servers, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 10/03/2016 04:09 AM, Larry Stotler wrote:
I'm not saying systemd is all bad or that it doesn't make things better for a lot of people. My point is that it's trying to take over the whole ecosystem, which isn't what it was presented to folks as originally. First it was an init replacement, then they kept adding in all these other services and it's becoming a ogre in the corner. Why should a desktop (GNOME) require an init system as a dependency?
I think, Larry, that you have failed to read Richard's post. Or perhaps not really understood what he was saying. Not, I hope CNS[1]. He was quite specific about why systemd monitors ALL process. The example he gave of Apache is a goo one. Saying "'X' requires an init system as a dependency" for whatever value of 'X' gets thing backwards. For 'X' to run there must be an environment for it to run in and that has to be set up and be stable. 'X' may require other things beside libraries such as IO channels, network services such as DNS, clocks and counters and more. More to the point, focusing on the 'X' misses the point. The computer, the processes on it, its position and environment and context are there to do things for humans. Richard hints at some of the possibilities there, ensuring restart, ensuring a context is set up that the human can use the programs safely and securely. One definition of security from the days before the term 'cyber' became fashionable was that the computer/program/process does what you expect, only what you expect without unexpected side effects or problems. Systemd, as Richard points out intrinsically facilitates that. And unlike sysv-init, it plays well with SELinux :-) [1] CNS - "Compulsive Narrative Syndrome", a cognitive, neurological condition that produces an inability to process pattern-anomalous data. Common in zealots, be they religious, political or even just supporters of a particular sports team or brand of technology. -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 10/03/2016 04:09 AM, Larry Stotler wrote:
Choice is really what a lot of people want.
Indeed. You live in a democracy don't you? People voted for an elected their representatives, their government. If it happens the representative and government isn't the one you wanted, the one you voted for, then, sorry, it *IS* what a 'lot' of people chose. If as you say was the case with yourself, Larry, you didn't involve yourself with the process, you didn't 'vote', then I think its unfair to complain. As you say, there are alternatives. Many people found that they didn't like the counties, the political system, the representatives and the policies of the countries they lived in (I know, I'm one) and emigrated. Maybe they then become more active in the decision making, 'voting', process. Maybe not. But if you don't then please don't complain about the consequences. -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2016-10-03 09:41, Richard Brown wrote:
But in 2016, 5 years after implementation and 4 years after the official support end date of the last non-systemd openSUSE distribution?
I'm sorry, that ship has sailed, crossed the ocean, docked, set out again, circumnavigated the globe, and is going around again
Yes, that is so. I don't have (big) problems with systemd. I think. In general, I'm happy. Well, perhaps that if there is a problem I can not edit an script and solve it. I have to wait for the devs to solve and distribute it. Ie, little problems are now more difficult to hack or solve for the administrator. ...
I am asking you to do take the time to learn about systemd before considering your opinion on it as complete.
Perhaps have an easy to find document, a FAQ, would help: I have this problem, what do I do? Not a long documentation to study and comprehend, but something practical and to the point, with actual examples to copy and use. Like: How do I start something before/during/after boot/after some other service. It is a question often asked: this week, I think. Maybe it exists, but I wouldn't know where. This one is good: https://doc.opensuse.org/documentation/leap/reference/html/book.opensuse.ref...
systemd is downright amazing on servers. Want to make a service that automatically deletes files in a folder every time they appear? That's like 3 lines in a systemd unit file, done
Is that in the fAQ? ;-)
using systemd's more dynamic features, like having services start only when required, is a dreamy way of optimising your servers
http://0pointer.de/blog/projects/socket-activated-containers.html
Doesn't xinetd do it? -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
Carlos E. R. wrote:
On 2016-10-03 09:41, Richard Brown wrote:
But in 2016, 5 years after implementation and 4 years after the official support end date of the last non-systemd openSUSE distribution?
I'm sorry, that ship has sailed, crossed the ocean, docked, set out again, circumnavigated the globe, and is going around again
Yes, that is so.
I don't have (big) problems with systemd. I think. In general, I'm happy. Well, perhaps that if there is a problem I can not edit an script and solve it. I have to wait for the devs to solve and distribute it. Ie, little problems are now more difficult to hack or solve for the administrator.
Can you come up with an example of that, Carlos? I think you're wrong. systemd has better options than editing the script - a service unit is easily overridden etc.
Perhaps have an easy to find document, a FAQ, would help: I have this problem, what do I do? Not a long documentation to study and comprehend, but something practical and to the point, with actual examples to copy and use.
Like: How do I start something before/during/after boot/after some other service. It is a question often asked: this week, I think.
Maybe it exists, but I wouldn't know where.
It's most likely in the man page(s), but I agree they can be a bit long and not always easy to grok. What you need to look at are the After, Requires, and Wants directives.
using systemd's more dynamic features, like having services start only when required, is a dreamy way of optimising your servers
http://0pointer.de/blog/projects/socket-activated-containers.html
Doesn't xinetd do it?
Yep, it does, based on network events. In one instance, I use it to run rsyncd, but otherwise my servers run everything all the time. -- Per Jessen, Zürich (14.5°C) http://www.hostsuisse.com/ - virtual servers, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2016-10-03 14:32, Per Jessen wrote:
Carlos E. R. wrote:
I don't have (big) problems with systemd. I think. In general, I'm happy. Well, perhaps that if there is a problem I can not edit an script and solve it. I have to wait for the devs to solve and distribute it. Ie, little problems are now more difficult to hack or solve for the administrator.
Can you come up with an example of that, Carlos? I think you're wrong. systemd has better options than editing the script - a service unit is easily overridden etc.
Yes, sure. I had problems with umounting some filesystem and systemd instantly remounting it on my back. Or the other way round. One that is hard to reproduce: during halt, network was disconnected, then the process decided to umount an nfs mount. Obviously, it could not, and got stuck. On the end, I had to hit the power button.
Perhaps have an easy to find document, a FAQ, would help: I have this problem, what do I do? Not a long documentation to study and comprehend, but something practical and to the point, with actual examples to copy and use.
Like: How do I start something before/during/after boot/after some other service. It is a question often asked: this week, I think.
Maybe it exists, but I wouldn't know where.
It's most likely in the man page(s), but I agree they can be a bit long and not always easy to grok.
What you need to look at are the After, Requires, and Wants directives.
Yes, I know, but I'm talking about a FAQ that I can read and point people to. I do not want to study a long documentation in order to figure out what to do. And that was just an example of possible things to do with systemd, there are many more. The suse.doc page gets close. Yes, I know that the info is there. But too long. Man pages typically do not have examples, and you have to know what page to open first. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
On Mon, Oct 3, 2016 at 3:41 PM, Carlos E. R. <robin.listas@telefonica.net> wrote:
Can you come up with an example of that, Carlos? I think you're wrong. systemd has better options than editing the script - a service unit is easily overridden etc.
Yes, sure.
I had problems with umounting some filesystem and systemd instantly remounting it on my back. Or the other way round.
This is expected to be mitigated (I hesitate to say "fixed") in current upstream systemd. But it also demonstrates one of bad design habits in systemd - doing something implicitly, without making "something" configurable or even documented.
One that is hard to reproduce: during halt, network was disconnected, then the process decided to umount an nfs mount. Obviously, it could not, and got stuck. On the end, I had to hit the power button.
Expressed this way it is hardly systemd related at all. All UNIX systems I have been working with would come to a hard stop in this case (depending on exact NFS mount options) including Solaris which is created by the same company that invented NFS in the first place ... -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2016-10-03 14:54, Andrei Borzenkov wrote:
On Mon, Oct 3, 2016 at 3:41 PM, Carlos E. R. <robin.listas@telefonica.net> wrote:
Can you come up with an example of that, Carlos? I think you're wrong. systemd has better options than editing the script - a service unit is easily overridden etc.
Yes, sure.
I had problems with umounting some filesystem and systemd instantly remounting it on my back. Or the other way round.
This is expected to be mitigated (I hesitate to say "fixed") in current upstream systemd. But it also demonstrates one of bad design habits in systemd - doing something implicitly, without making "something" configurable or even documented.
Yep. It is also a problem with not handling traditional fstab usage. It appears that one has to issue a systemctl command to umount things.
One that is hard to reproduce: during halt, network was disconnected, then the process decided to umount an nfs mount. Obviously, it could not, and got stuck. On the end, I had to hit the power button.
Expressed this way it is hardly systemd related at all. All UNIX systems I have been working with would come to a hard stop in this case (depending on exact NFS mount options) including Solaris which is created by the same company that invented NFS in the first place ...
I have only experienced it with systemd. Notice that I'm not talking about a "system" share, like would be "/usr", but a plain data partition that can be umounted early, as soon as user tasks have died. The obvious solution is don't kill network before network shares and other network services exit... -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
Carlos E. R. wrote:
One that is hard to reproduce: during halt, network was disconnected, then the process decided to umount an nfs mount. Obviously, it could not, and got stuck. On the end, I had to hit the power button.
Expressed this way it is hardly systemd related at all. All UNIX systems I have been working with would come to a hard stop in this case (depending on exact NFS mount options) including Solaris which is created by the same company that invented NFS in the first place ...
I have only experienced it with systemd. Notice that I'm not talking about a "system" share, like would be "/usr", but a plain data partition that can be umounted early, as soon as user tasks have died.
The obvious solution is don't kill network before network shares and other network services exit...
On my test Leap42 desktop(s) I have two NFS shares. Depending on what I'm working on, they're not rebooted that often, but I've not seen the problem your describe yet. I guess the nfs unmount happens at the right time, somehow. -- Per Jessen, Zürich (15.4°C) http://www.dns24.ch/ - your free DNS host, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2016-10-03 15:16, Per Jessen wrote:
Carlos E. R. wrote:
On my test Leap42 desktop(s) I have two NFS shares. Depending on what I'm working on, they're not rebooted that often, but I've not seen the problem your describe yet. I guess the nfs unmount happens at the right time, somehow.
To me it only happened once. I don't reboot often, either. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
On 10/03/2016 08:54 AM, Andrei Borzenkov wrote:
On Mon, Oct 3, 2016 at 3:41 PM, Carlos E. R. <robin.listas@telefonica.net> wrote:
Can you come up with an example of that, Carlos? I think you're wrong. systemd has better options than editing the script - a service unit is easily overridden etc.
Yes, sure.
I had problems with umounting some filesystem and systemd instantly remounting it on my back. Or the other way round.
This is expected to be mitigated (I hesitate to say "fixed") in current upstream systemd. But it also demonstrates one of bad design habits in systemd - doing something implicitly, without making "something" configurable or even documented.
Maybe it is documented. The trouble with a lot of documentation is that, whether long or not, "it says so much" that sometimes things get overlooked. In the man page 'systemd.mount' it describes how to make unit files for mounting disks. It also has section about FSTAB. To summarise, there is a program that parses /etc/fstab and converts the entries there into unit files. See the man page 'systemd-fstab-generator'. https://www.freedesktop.org/software/systemd/man/systemd-fstab-generator.htm... If you rely solely on /etc/fstab then that is your only source of control, and as carlos found, the default is to persist in maintaining the system as defined therein. If you don't like that, then remove the relevant entry from /etc/fstab and create your own unit file specific to that disk. Note also: RequiresMountsFor= Takes a space-separated list of absolute paths. Automatically adds dependencies of type Requires= and After= for all mount units required to access the specified path. Mount points marked with noauto are not mounted automatically and will be ignored for the purposes of this option. If such a mount should be a requirement for this unit, direct dependencies on the mount units may be added (Requires= and After= or some other combination). -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2016-10-03 15:22, Anton Aylward wrote:
On 10/03/2016 08:54 AM, Andrei Borzenkov wrote:
On Mon, Oct 3, 2016 at 3:41 PM, Carlos E. R. <> wrote:
If you don't like that, then remove the relevant entry from /etc/fstab and create your own unit file specific to that disk.
Absolutely not nice, and an argument against systemd. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
Carlos E. R. wrote:
On 2016-10-03 15:22, Anton Aylward wrote:
On 10/03/2016 08:54 AM, Andrei Borzenkov wrote:
On Mon, Oct 3, 2016 at 3:41 PM, Carlos E. R. <> wrote:
If you don't like that, then remove the relevant entry from /etc/fstab and create your own unit file specific to that disk.
Absolutely not nice, and an argument against systemd.
How can being able to override the system(d) default be seen as an argument _against_ systemd? However, you don't need to remove anything from fstab, you just create your own local mount in /etc/systemd/system - systemctl cat mount-point.mount >mount-point.mount edit mount-point.mount and amend the options systemctl daemon-reload systemctl cat mount-point.mount (to see your new options enabled). -- Per Jessen, Zürich (15.1°C) http://www.dns24.ch/ - your free DNS host, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2016-10-03 16:12, Per Jessen wrote:
Carlos E. R. wrote:
On 2016-10-03 15:22, Anton Aylward wrote:
On 10/03/2016 08:54 AM, Andrei Borzenkov wrote:
On Mon, Oct 3, 2016 at 3:41 PM, Carlos E. R. <> wrote:
If you don't like that, then remove the relevant entry from /etc/fstab and create your own unit file specific to that disk.
Absolutely not nice, and an argument against systemd.
How can being able to override the system(d) default be seen as an argument _against_ systemd?
Because systemd modifies the behaviour of mount and fstab that has been known for decades.
However, you don't need to remove anything from fstab, you just create your own local mount in /etc/systemd/system -
systemctl cat mount-point.mount >mount-point.mount
edit mount-point.mount and amend the options
I don't understand what that would do. I simply want to issue my mount commands, as user, not root, and what I do to stay without getting systemd altering the reults. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
Carlos E. R. wrote:
On 2016-10-03 16:12, Per Jessen wrote:
Carlos E. R. wrote:
On 2016-10-03 15:22, Anton Aylward wrote:
On 10/03/2016 08:54 AM, Andrei Borzenkov wrote:
On Mon, Oct 3, 2016 at 3:41 PM, Carlos E. R. <> wrote:
If you don't like that, then remove the relevant entry from /etc/fstab and create your own unit file specific to that disk.
Absolutely not nice, and an argument against systemd.
How can being able to override the system(d) default be seen as an argument _against_ systemd?
Because systemd modifies the behaviour of mount and fstab that has been known for decades.
Maybe it does and maybe for good reason - different discussion. Nonetheless, being able to override what systemd does is surely a Good Thing and cannot be counted against it.
However, you don't need to remove anything from fstab, you just create your own local mount in /etc/systemd/system -
systemctl cat mount-point.mount >mount-point.mount
edit mount-point.mount and amend the options
I don't understand what that would do. I simply want to issue my mount commands, as user, not root, and what I do to stay without getting systemd altering the reults.
Earlier you neglected to explain to us what it is you want to do. You know, the crystal ball is out for a service today :-) If you want to manually do your mounting and unmounting, you add "noauto" to the appropriate line in fstab. Or you leave it out altogether. -- Per Jessen, Zürich (11.2°C) http://www.hostsuisse.com/ - virtual servers, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2016-10-03 20:40, Per Jessen wrote:
Carlos E. R. wrote:
I don't understand what that would do. I simply want to issue my mount commands, as user, not root, and what I do to stay without getting systemd altering the reults.
Earlier you neglected to explain to us what it is you want to do. You know, the crystal ball is out for a service today :-) If you want to manually do your mounting and unmounting, you add "noauto" to the appropriate line in fstab. Or you leave it out altogether.
Andrei understood it very well. He knows that bug/design decision. As I said: I used "umount directory" to umount a device temporarily (perhaps /home), I think it was to run fsck on it, and the fsck command failed because it was mounted. I found that system was mounting it again on my back. THAT is the specific problem. That line can not be optioned "noauto". Andrei also said that the problem has been addressed in current systemd releases. I don't know how, though. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
Carlos E. R. wrote:
On 2016-10-03 20:40, Per Jessen wrote:
Carlos E. R. wrote:
I don't understand what that would do. I simply want to issue my mount commands, as user, not root, and what I do to stay without getting systemd altering the reults.
Earlier you neglected to explain to us what it is you want to do. You know, the crystal ball is out for a service today :-) If you want to manually do your mounting and unmounting, you add "noauto" to the appropriate line in fstab. Or you leave it out altogether.
Andrei understood it very well. He knows that bug/design decision.
I'll have to borrow his crystal ball, mine's not back till Friday. -- Per Jessen, Zürich (11.1°C) http://www.dns24.ch/ - your free DNS host, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 10/03/2016 02:32 PM, Carlos E. R. wrote:
Because systemd modifies the behaviour of mount and fstab that has been known for decades.
Ah. Right, so has IPv4 Pot, kettle ... What's this IPv6 nonsense? -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 10/03/2016 02:32 PM, Carlos E. R. wrote:
I don't understand what that would do. I simply want to issue my mount commands, as user, not root, and what I do to stay without getting systemd altering the reults.
Err, well then, systemd is the way to go. The SYSTEM units can control the system level files, / /usr/ /usr/share /srv /local and however you have your system side set up. Then in '$HOME/.config/systemd/user/' you have the units that are specific to you the user. Users as users should not fiddle with the system.But delegating stuff to them makes sense. You can then use the systemd-mount on your own mount units. Strictly speaking, you could have one that appears to over-ride one of the ones in /etc/systemd/system, but that might prove problematic. Hopefully you'll run into other access control issues. -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 10/03/2016 09:55 AM, Carlos E. R. wrote:
On 2016-10-03 15:22, Anton Aylward wrote:
On 10/03/2016 08:54 AM, Andrei Borzenkov wrote:
On Mon, Oct 3, 2016 at 3:41 PM, Carlos E. R. <> wrote:
If you don't like that, then remove the relevant entry from /etc/fstab and create your own unit file specific to that disk.
Absolutely not nice, and an argument against systemd.
Not so! The generator is a 'backwards compatibility' compromise. if you have up on that backwards comparability and worked exclusively with properly written mount unit files then you would have proper control and control over aspects that you currently don't have at the moment since the generator produces all mounts according to a simplistic standardized template as it parses the /etc/fstab. That systemd keeps monitoring the state of the system, including what is mounted, and tries to keep it stable, is, to my mind, a Good Thing. As far as systemd is concerned, you were trying to destabilise the system by taking away a mounted file system without telling it, without saying that it should now be released. The problem is the mount command. As I've said previously, the suite of what makes up systemd is only advancing as fast as matters can be coded and ratified. Right now, the 'umount' command *OUGHT* to check to see if the FS is managed by systemd and it it is send a D-Bus message to systemd telling it to unmount. Quite possibly the 'mount' command might dynamically generate a unit file and tell systemd to mount it accordingly. Richard, what do you think? -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Mon, Oct 3, 2016 at 5:15 PM, Anton Aylward <opensuse@antonaylward.com> wrote:
On 10/03/2016 09:55 AM, Carlos E. R. wrote:
On 2016-10-03 15:22, Anton Aylward wrote:
On 10/03/2016 08:54 AM, Andrei Borzenkov wrote:
On Mon, Oct 3, 2016 at 3:41 PM, Carlos E. R. <> wrote:
If you don't like that, then remove the relevant entry from /etc/fstab and create your own unit file specific to that disk.
Absolutely not nice, and an argument against systemd.
Not so! The generator is a 'backwards compatibility' compromise.
fstab semantic under systemd is *NOT* backward compatible. This is permanent source of complaints which are ignored. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 10/03/2016 10:19 AM, Andrei Borzenkov wrote:
On Mon, Oct 3, 2016 at 5:15 PM, Anton Aylward <opensuse@antonaylward.com> wrote:
On 10/03/2016 09:55 AM, Carlos E. R. wrote:
On 2016-10-03 15:22, Anton Aylward wrote:
On 10/03/2016 08:54 AM, Andrei Borzenkov wrote:
On Mon, Oct 3, 2016 at 3:41 PM, Carlos E. R. <> wrote:
If you don't like that, then remove the relevant entry from /etc/fstab and create your own unit file specific to that disk.
Absolutely not nice, and an argument against systemd.
Not so! The generator is a 'backwards compatibility' compromise.
fstab semantic under systemd is *NOT* backward compatible. This is permanent source of complaints which are ignored.
I did not say it was 'compatable', I said it was a comparability compromise. Like all compromises it not 'absolutely the same'. -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Mon, Oct 3, 2016 at 5:24 PM, Anton Aylward <opensuse@antonaylward.com> wrote:
On 10/03/2016 10:19 AM, Andrei Borzenkov wrote:
On Mon, Oct 3, 2016 at 5:15 PM, Anton Aylward <opensuse@antonaylward.com> wrote:
On 10/03/2016 09:55 AM, Carlos E. R. wrote:
On 2016-10-03 15:22, Anton Aylward wrote:
On 10/03/2016 08:54 AM, Andrei Borzenkov wrote:
On Mon, Oct 3, 2016 at 3:41 PM, Carlos E. R. <> wrote:
If you don't like that, then remove the relevant entry from /etc/fstab and create your own unit file specific to that disk.
Absolutely not nice, and an argument against systemd.
Not so! The generator is a 'backwards compatibility' compromise.
fstab semantic under systemd is *NOT* backward compatible. This is permanent source of complaints which are ignored.
I did not say it was 'compatable', I said it was a comparability compromise. Like all compromises it not 'absolutely the same'.
What exactly forced systemd to drop compatible behavior? Why it was not possible to keep compatible behavior UNLESS extra options enabled new - presumably, better - one? Until you can explain this, what you say remains just commonplace without any substance. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 10/03/2016 10:28 AM, Andrei Borzenkov wrote:
What exactly forced systemd to drop compatible behavior? Why it was not possible to keep compatible behavior UNLESS extra options enabled new - presumably, better - one? Until you can explain this, what you say remains just commonplace without any substance.
The way I look at it systemd did not 'drop compatible behaviour'. That's a very prejudicial way of phrasing it, like asking a question which presumes the answer is 'NO!" rather than asking it in an open manner. That's a trick I usually attribute to politicians and flaks. The way I look at it systemd strives to keep a stable system. This has been brought up before; Richard mentioned it and its mention in many postings. I see it as a benefit. Being able to arbitrary unmount a FS I see as a problem. I see systemd as having addressed that ... bug ... architectural deficiency. As far as systemd is concerned, the arbitrary use of the umount command is trying to destabilise the system by taking away a mounted file system without telling it, without saying that it should now be released. The problem is the umount command and its arbitrary use. As I said, relying on erroneous, buggy or poor operational practices is not a good thing.Fixing them, re-architecting for robustness and stability is only a 'problem' of you relied on those bugs and errors in the first place. -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Mon, Oct 3, 2016 at 5:38 PM, Anton Aylward <opensuse@antonaylward.com> wrote:
On 10/03/2016 10:28 AM, Andrei Borzenkov wrote:
What exactly forced systemd to drop compatible behavior? Why it was not possible to keep compatible behavior UNLESS extra options enabled new - presumably, better - one? Until you can explain this, what you say remains just commonplace without any substance.
The way I look at it systemd did not 'drop compatible behaviour'. That's a very prejudicial way of phrasing it, like asking a question which presumes the answer is 'NO!" rather than asking it in an open manner. That's a trick I usually attribute to politicians and flaks.
The way I look at it systemd strives to keep a stable system. This has been brought up before; Richard mentioned it and its mention in many postings. I see it as a benefit.
Being able to arbitrary unmount a FS I see as a problem. I see systemd as having addressed that ... bug ... architectural deficiency.
So the fact that "mount" command mounts something and "umount" command unmount something is now a bug?
As far as systemd is concerned, the arbitrary use of the umount command is trying to destabilise the system by taking away a mounted file system without telling it, without saying that it should now be released.
The problem is the umount command and its arbitrary use.
You seem to imply that systemd will remount file system that was manually unmounted using "umount" command. Of course it will not. Do you ever try something? Do you actually understand the problem Carlos mentioned?
As I said, relying on erroneous, buggy or poor operational practices is not a good thing.Fixing them, re-architecting for robustness and stability is only a 'problem' of you relied on those bugs and errors in the first place.
-- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon?
-- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 10/03/2016 10:48 AM, Andrei Borzenkov wrote:
You seem to imply that systemd will remount file system that was manually unmounted using "umount" command. Of course it will not. Do you ever try something? Do you actually understand the problem Carlos mentioned?
Yes, but you also haven't been paying attention. There have, as was mentioned, been upstream changes to address the issue. There was also a corresponding 'bug' where systemd kept mounting a manually mounted drive :) As Carlos also mentioned, this has been addressed upstream. I think that the newly released systemd version of the mount command, as I suggested earlier, dynamically creating a unit, indicates the changes systemd is making in this area. https://www.phoronix.com/scan.php?page=news_item&px=Systemd-Mount Which is amplified at https://www.reddit.com/r/linux/comments/4ypb2g/systemd_rolls_out_its_own_mou... As he says, swapping USB keys or other removable media without following the mount/umount protocols can lead to confusion. -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Carlos E. R. wrote:
On 2016-10-03 14:32, Per Jessen wrote:
Carlos E. R. wrote:
I don't have (big) problems with systemd. I think. In general, I'm happy. Well, perhaps that if there is a problem I can not edit an script and solve it. I have to wait for the devs to solve and distribute it. Ie, little problems are now more difficult to hack or solve for the administrator.
Can you come up with an example of that, Carlos? I think you're wrong. systemd has better options than editing the script - a service unit is easily overridden etc.
Yes, sure.
I had problems with umounting some filesystem and systemd instantly remounting it on my back. Or the other way round.
One that is hard to reproduce: during halt, network was disconnected, then the process decided to umount an nfs mount. Obviously, it could not, and got stuck. On the end, I had to hit the power button.
I'm sure that is/was a genuine problem, but allow me to count it as an exception to prove the rule. I think it is very far from your example to your general suggestion that "... that if there is a problem I can not edit an script and solve it. I have to wait for the devs to solve and distribute it".
It's most likely in the man page(s), but I agree they can be a bit long and not always easy to grok.
What you need to look at are the After, Requires, and Wants directives.
Yes, I know, but I'm talking about a FAQ that I can read and point people to. I do not want to study a long documentation in order to figure out what to do.
Yes, I suppose there's room for some of that. Speaking for myself, I find it is acceptable to work with the man-page, existing examples and google. -- Per Jessen, Zürich (15.8°C) http://www.dns24.ch/ - your free DNS host, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2016-10-03 14:58, Per Jessen wrote:
Carlos E. R. wrote:
I'm sure that is/was a genuine problem, but allow me to count it as an exception to prove the rule. I think it is very far from your example to your general suggestion that
"... that if there is a problem I can not edit an script and solve it. I have to wait for the devs to solve and distribute it".
It is an example, I have more. Like this message spamming my log: <3.4> 2016-09-21 13:59:38 Telcontar systemd 1 - - Cannot add dependency job for unit udev.service, ignoring: Unit udev.service failed to load: No such file or directory. Finally someone found a hack to clear it, but it took months to find. It appeared just after the last update was applied to 13.1, and of course, bug reports were ignored, even though they created the problem. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
Carlos E. R. wrote:
On 2016-10-03 14:58, Per Jessen wrote:
Carlos E. R. wrote:
I'm sure that is/was a genuine problem, but allow me to count it as an exception to prove the rule. I think it is very far from your example to your general suggestion that
"... that if there is a problem I can not edit an script and solve it. I have to wait for the devs to solve and distribute it".
It is an example, I have more. Like this message spamming my log:
<3.4> 2016-09-21 13:59:38 Telcontar systemd 1 - - Cannot add dependency job for unit udev.service, ignoring: Unit udev.service failed to load: No such file or directory.
Finally someone found a hack to clear it, but it took months to find.
It appeared just after the last update was applied to 13.1, and of course, bug reports were ignored, even though they created the problem.
Right - do you believe you could have fixed such issues in sysvinit by simply editing a script? I don't think they're very good examples of problems "that can be solved by editing a script", that's what I mean. Sure they _are_ problems, but moving to systemd has not made them any more difficult to solve. IMHO. -- Per Jessen, Zürich (15.5°C) http://www.hostsuisse.com/ - dedicated server rental in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2016-10-03 15:25, Per Jessen wrote:
Carlos E. R. wrote:
Right - do you believe you could have fixed such issues in sysvinit by simply editing a script? I don't think they're very good examples of problems "that can be solved by editing a script", that's what I mean.
Well, I can not even try. I did solve pesky problems like those in the past hacking at the service scripts. I don't know about the current problems. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
Le 03/10/2016 à 15:57, Carlos E. R. a écrit :
I did solve pesky problems like those in the past hacking at the service scripts. I don't know about the current problems.
so did I. Today it's probably necessary to hack systemd services, and it was very difficult to hack inits and not necessarily more difficult to hack systemd services (may be not the same things are difficults or easy) I find such discussion very unpleasant. systemd is here and devoted to stay, we have to accomodate it, not rant. such discussions are deadly for openSUSE, for any people not part of the handful accustomed of it jdd -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 10/03/2016 08:58 AM, Per Jessen wrote:
I'm sure that is/was a genuine problem, but allow me to count it as an exception to prove the rule. I think it is very far from your example to your general suggestion that
"... that if there is a problem I can not edit an script and solve it. I have to wait for the devs to solve and distribute it".
Indeed. As I say in another posting, if you are relying on /etc/fstab and the generator that parses it, you end up with the systemd semantics that maintain the system, automatically restarting when something 'dies' so as to maintain a constant picture. If you want different, take the entry out of fstab and write your own mount file that does what you want. This is not a problem with systemd. It is doing what it supposed to. You haven't told it otherwise. -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Anton Aylward wrote:
On 10/03/2016 08:58 AM, Per Jessen wrote:
I'm sure that is/was a genuine problem, but allow me to count it as an exception to prove the rule. I think it is very far from your example to your general suggestion that
"... that if there is a problem I can not edit an script and solve it. I have to wait for the devs to solve and distribute it".
Indeed. As I say in another posting, if you are relying on /etc/fstab and the generator that parses it, you end up with the systemd semantics that maintain the system, automatically restarting when something 'dies' so as to maintain a constant picture.
If you want different, take the entry out of fstab and write your own mount file that does what you want.
Or even just override the generated unit - In systemd/system, create "mount-point.mount.d/your.overrides" and add your specific config. At least I think that is possible, I haven't tested it. -- Per Jessen, Zürich (15.4°C) http://www.hostsuisse.com/ - virtual servers, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2016-10-03 15:26, Anton Aylward wrote:
On 10/03/2016 08:58 AM, Per Jessen wrote:
I'm sure that is/was a genuine problem, but allow me to count it as an exception to prove the rule. I think it is very far from your example to your general suggestion that
"... that if there is a problem I can not edit an script and solve it. I have to wait for the devs to solve and distribute it".
Indeed. As I say in another posting, if you are relying on /etc/fstab and the generator that parses it, you end up with the systemd semantics that maintain the system, automatically restarting when something 'dies' so as to maintain a constant picture.
If you want different, take the entry out of fstab and write your own mount file that does what you want.
That's not a solution. The right solution would be a syntax in fstab telling systemd to leave that line alone.
This is not a problem with systemd.
Yes, it is. It started with systemd. Thus per definition, it is a systemd generated problem. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
On 10/03/2016 10:00 AM, Carlos E. R. wrote:
On 2016-10-03 15:26, Anton Aylward wrote:
On 10/03/2016 08:58 AM, Per Jessen wrote:
I'm sure that is/was a genuine problem, but allow me to count it as an exception to prove the rule. I think it is very far from your example to your general suggestion that
"... that if there is a problem I can not edit an script and solve it. I have to wait for the devs to solve and distribute it".
Indeed. As I say in another posting, if you are relying on /etc/fstab and the generator that parses it, you end up with the systemd semantics that maintain the system, automatically restarting when something 'dies' so as to maintain a constant picture.
If you want different, take the entry out of fstab and write your own mount file that does what you want.
That's not a solution.
The right solution would be a syntax in fstab telling systemd to leave that line alone.
Something like 'noauto' ?
This is not a problem with systemd.
Yes, it is. It started with systemd. Thus per definition, it is a systemd generated problem.
No, systemd is trying to keep the system stable. Systemd also corrected many problems and deficiencies that previously existed. Relying on erroneous, buggy or poor operational practices is not a good thing. Fixing them, re-architecting for robustness and stability is only a 'problem' of you relied on those bugs and errors in the first place. -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2016-10-03 16:21, Anton Aylward wrote:
On 10/03/2016 10:00 AM, Carlos E. R. wrote:
If you want different, take the entry out of fstab and write your own mount file that does what you want.
That's not a solution.
The right solution would be a syntax in fstab telling systemd to leave that line alone.
Something like 'noauto' ?
No, because I want the line to be mounted at boot, and then left alone. As has been for decades. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
Carlos E. R. wrote:
On 2016-10-03 16:21, Anton Aylward wrote:
On 10/03/2016 10:00 AM, Carlos E. R. wrote:
If you want different, take the entry out of fstab and write your own mount file that does what you want.
That's not a solution.
The right solution would be a syntax in fstab telling systemd to leave that line alone.
Something like 'noauto' ?
No, because I want the line to be mounted at boot, and then left alone. As has been for decades.
Today, without having looked into it in any great detail, I would create a mount unit (as demonstrated in a different posting), and that would be it. (no fstab entry). I think what has happened is that systemd has applied a more strict interpretation of /etc/fstab than in the past and thereby "screwed up" some of the things (or bad habits) we have grown used to over the last 20 years. -- Per Jessen, Zürich (11.2°C) http://www.hostsuisse.com/ - dedicated server rental in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2016-10-03 20:46, Per Jessen wrote:
Carlos E. R. wrote:
No, because I want the line to be mounted at boot, and then left alone. As has been for decades.
Today, without having looked into it in any great detail, I would create a mount unit (as demonstrated in a different posting), and that would be it. (no fstab entry).
I think what has happened is that systemd has applied a more strict interpretation of /etc/fstab than in the past and thereby "screwed up" some of the things (or bad habits) we have grown used to over the last 20 years.
Yes, exactly. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
On 10/03/2016 02:37 PM, Carlos E. R. wrote:
No, because I want the line to be mounted at boot, and then left alone.
Yes that is the intent of a properly written systemd mount unit. Yes you want the system stuff left alone. Yes you (may) want some stuff the appear whenever you log in that need not be mounted boot. If you see it when you log in then what difference does it make? And as I've said a couple of times now, having a user specific unit lets the user control that as he wishes. But you don't want a user buqqering around with the system devices. (Especially not on a shared multi-seat or multi-login system). And don't forget, there are services like Apache, BIND and others that may depend on mounted file systems. Unless, that is, you are a BtrFS-obsessive and have a 'one disk/filesystem' with no actual mounts except for the RootFS. -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Carlos E. R. wrote:
On 2016-10-03 15:26, Anton Aylward wrote:
On 10/03/2016 08:58 AM, Per Jessen wrote:
I'm sure that is/was a genuine problem, but allow me to count it as an exception to prove the rule. I think it is very far from your example to your general suggestion that
"... that if there is a problem I can not edit an script and solve it. I have to wait for the devs to solve and distribute it".
Indeed. As I say in another posting, if you are relying on /etc/fstab and the generator that parses it, you end up with the systemd semantics that maintain the system, automatically restarting when something 'dies' so as to maintain a constant picture.
If you want different, take the entry out of fstab and write your own mount file that does what you want.
That's not a solution.
The right solution would be a syntax in fstab telling systemd to leave that line alone.
I think "noauto" will do that. -- Per Jessen, Zürich (16.1°C) http://www.dns24.ch/ - free dynamic DNS, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2016-10-03 17:09, Per Jessen wrote:
Carlos E. R. wrote:
If you want different, take the entry out of fstab and write your own mount file that does what you want.
That's not a solution.
The right solution would be a syntax in fstab telling systemd to leave that line alone.
I think "noauto" will do that.
Yes, but not quite. I do want the device to be mounted automatically at boot. Only at boot. I simply want to be sure that if I umount a partition, any partition (say, /home) to do an fsck on it, it is not remounted in seconds. I want my manual orders to be obeyed, that's all. If the command mount has to be recoded, so be it. But that is systemd fault. It has changed behaviours that have been the same for decades. And no, jdd, I'm not saying "remove systemd". That boat sailed away ages ago, as Richard says. I want it better and not break things. I want no zealots that say that all systemd does is good, either. I want faults to be recognized and repaired. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
Carlos E. R. wrote:
On 2016-10-03 17:09, Per Jessen wrote:
Carlos E. R. wrote:
If you want different, take the entry out of fstab and write your own mount file that does what you want.
That's not a solution.
The right solution would be a syntax in fstab telling systemd to leave that line alone.
I think "noauto" will do that.
Yes, but not quite. I do want the device to be mounted automatically at boot. Only at boot. I simply want to be sure that if I umount a partition, any partition (say, /home) to do an fsck on it, it is not remounted in seconds. I want my manual orders to be obeyed, that's all.
Now I understand. Yes, that is (afaict) a practice/situation systemd does not currently cater to.
If the command mount has to be recoded, so be it. But that is systemd fault. It has changed behaviours that have been the same for decades.
Well, since maybe the 70s, but yes, in that particular instance systemd has indeed changed the behaviour we have grown used to. It's like you started out saying, it's only a little problem, nothing major. -- Per Jessen, Zürich (11.1°C) http://www.dns24.ch/ - your free DNS host, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 10/03/2016 03:09 PM, Per Jessen wrote:
Carlos E. R. wrote:
On 2016-10-03 17:09, Per Jessen wrote:
Carlos E. R. wrote:
If you want different, take the entry out of fstab and write your own mount file that does what you want.
That's not a solution.
The right solution would be a syntax in fstab telling systemd to leave that line alone.
I think "noauto" will do that.
Yes, but not quite. I do want the device to be mounted automatically at boot. Only at boot. I simply want to be sure that if I umount a partition, any partition (say, /home) to do an fsck on it, it is not remounted in seconds. I want my manual orders to be obeyed, that's all.
Now I understand. Yes, that is (afaict) a practice/situation systemd does not currently cater to.
Yes systemd does cater to that You can create a unit "fsck-home.service' The Before: does the unmount. The Exec: does the fsck. The After: remounts. Its a unit under the control of systems so it can take care of the unmount. Alternatively, if you're CLI, then: systemctl stop home.mount fsck /dev/HOME systemctl start home.mount Which is essentially the guts of the above described unit.
If the command mount has to be recoded, so be it. But that is systemd fault. It has changed behaviours that have been the same for decades.
Well, since maybe the 70s, but yes, in that particular instance systemd has indeed changed the behaviour we have grown used to. It's like you started out saying, it's only a little problem, nothing major.
-- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2016-10-03 22:43, Anton Aylward wrote:
On 10/03/2016 03:09 PM, Per Jessen wrote:
Carlos E. R. wrote:
Yes, but not quite. I do want the device to be mounted automatically at boot. Only at boot. I simply want to be sure that if I umount a partition, any partition (say, /home) to do an fsck on it, it is not remounted in seconds. I want my manual orders to be obeyed, that's all.
Now I understand. Yes, that is (afaict) a practice/situation systemd does not currently cater to.
Yes systemd does cater to that
You can create a unit "fsck-home.service' The Before: does the unmount. The Exec: does the fsck. The After: remounts.
Its a unit under the control of systems so it can take care of the unmount.
Buff :-(
Alternatively, if you're CLI, then:
systemctl stop home.mount fsck /dev/HOME systemctl start home.mount
Which is essentially the guts of the above described unit.
Well, that would work, but it is something new to remember. It is modified behaviour to what existed for decades. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
On 10/03/2016 05:23 PM, Carlos E. R. wrote:
Well, that would work, but it is something new to remember. It is modified behaviour to what existed for decades.
As I said, IPV6 is 'modified behaviour to what existed for decades'. Systemd changes a lot of things; intrinsically is is also 'modified behaviour to what existed for decades'. So what else is new? If you're really smart you can use the shell's alias mechanism :-) And if you're really really smart you'll use the ability units have to parametrise the call. -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Anton Aylward wrote:
On 10/03/2016 03:09 PM, Per Jessen wrote:
Carlos E. R. wrote:
On 2016-10-03 17:09, Per Jessen wrote:
Carlos E. R. wrote:
If you want different, take the entry out of fstab and write your own mount file that does what you want.
That's not a solution.
The right solution would be a syntax in fstab telling systemd to leave that line alone.
I think "noauto" will do that.
Yes, but not quite. I do want the device to be mounted automatically at boot. Only at boot. I simply want to be sure that if I umount a partition, any partition (say, /home) to do an fsck on it, it is not remounted in seconds. I want my manual orders to be obeyed, that's all.
Now I understand. Yes, that is (afaict) a practice/situation systemd does not currently cater to.
Yes systemd does cater to that
You can create a unit "fsck-home.service' The Before: does the unmount. The Exec: does the fsck. The After: remounts.
Its a unit under the control of systems so it can take care of the unmount.
Alternatively, if you're CLI, then:
systemctl stop home.mount fsck /dev/HOME systemctl start home.mount
Which is essentially the guts of the above described unit.
Yes, good point. I think I'd prefer to retain the use of mount/unmount though - maybe they ought to be turned into small scripts and made sensitive to whether a mount-point is under systemd control? if under systemd control systemctl {stop|start} else mount|unmount fi -- Per Jessen, Zürich (9.4°C) http://www.hostsuisse.com/ - virtual servers, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2016-10-03 21:09, Per Jessen wrote:
Carlos E. R. wrote:
On 2016-10-03 17:09, Per Jessen wrote:
Carlos E. R. wrote:
If you want different, take the entry out of fstab and write your own mount file that does what you want.
That's not a solution.
The right solution would be a syntax in fstab telling systemd to leave that line alone.
I think "noauto" will do that.
Yes, but not quite. I do want the device to be mounted automatically at boot. Only at boot. I simply want to be sure that if I umount a partition, any partition (say, /home) to do an fsck on it, it is not remounted in seconds. I want my manual orders to be obeyed, that's all.
Now I understand. Yes, that is (afaict) a practice/situation systemd does not currently cater to.
Good! Understanding problem solved :-)
If the command mount has to be recoded, so be it. But that is systemd fault. It has changed behaviours that have been the same for decades.
Well, since maybe the 70s, but yes, in that particular instance systemd has indeed changed the behaviour we have grown used to. It's like you started out saying, it's only a little problem, nothing major.
Exactly. Well, it made me waste some time... I had to ask on the mail list. I don't remember how I solved it. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
On 10/03/2016 05:19 PM, Carlos E. R. wrote:
On 2016-10-03 21:09, Per Jessen wrote:
Carlos E. R. wrote:
On 2016-10-03 17:09, Per Jessen wrote:
Carlos E. R. wrote:
If you want different, take the entry out of fstab and write your own mount file that does what you want.
That's not a solution.
The right solution would be a syntax in fstab telling systemd to leave that line alone.
I think "noauto" will do that.
Yes, but not quite. I do want the device to be mounted automatically at boot. Only at boot. I simply want to be sure that if I umount a partition, any partition (say, /home) to do an fsck on it, it is not remounted in seconds. I want my manual orders to be obeyed, that's all.
Now I understand. Yes, that is (afaict) a practice/situation systemd does not currently cater to.
Good! Understanding problem solved :-)
You simply don't want to be convinced or learn, do you, Carlos? You simply want Linux to be the Linux of the previous century. -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Mon, Oct 3, 2016 at 4:26 PM, Anton Aylward <opensuse@antonaylward.com> wrote:
On 10/03/2016 08:58 AM, Per Jessen wrote:
I'm sure that is/was a genuine problem, but allow me to count it as an exception to prove the rule. I think it is very far from your example to your general suggestion that
"... that if there is a problem I can not edit an script and solve it. I have to wait for the devs to solve and distribute it".
Indeed. As I say in another posting, if you are relying on /etc/fstab and the generator that parses it, you end up with the systemd semantics that maintain the system, automatically restarting when something 'dies' so as to maintain a constant picture.
The problem with unexpected (un-)mounts has absolutely nothing to do with generator or fstab.
If you want different, take the entry out of fstab and write your own mount file that does what you want.
Which will have exactly the same problem. Do you ever test what you suggest?
This is not a problem with systemd. It is doing what it supposed to.
Without leaving user choice of changing it and without even telling user it will do it. So yes, it is not a bug - it is design decision. Both design decision and how it is implemented is questionable and contributes to attitude towards systemd. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 10/03/2016 10:38 AM, Andrei Borzenkov wrote:
The problem with unexpected (un-)mounts has absolutely nothing to do with generator or fstab.
Sorry, Andrei, it does. The naive template generated units (see them in /run/systemd/generator) are simplistic. You take what you're given. Because they are simplistic they don't give you the control you want.
If you want different, take the entry out of fstab and write your own mount file that does what you want.
Which will have exactly the same problem. Do you ever test what you suggest?
Yes. I can now manage it using systemctl to mount and unmount. Hmmm Well actually I've just run systemctl stop /run/systemd/generator/home-anton-MyDocuments.mount and that did the unmount. And systemctl status ...... let me see the 'status'. Actually you don't need the full path, I just show that so you can find where the uits are so you can read them an see how naive they are. Now in reality, we get into issues of access control. There are system and per user versions, and the system disks should be under control of the system and the user stuff under control of the user. THE SPECIFIC USER. Each user can have their own units in '$HOME/.config/systemd/user' and have control over their own file system. Easily mount when they login, unmount when they log out. With fstab you can only have 'user' in the options.
This is not a problem with systemd. It is doing what it supposed to.
Without leaving user choice of changing it and without even telling user it will do it. So yes, it is not a bug - it is design decision. Both design decision and how it is implemented is questionable and contributes to attitude towards systemd.
No, systemd is quite consistent. Its preventing arbitrary action. Its making sure the system is and stays as 'specified'. If you want things different, change the 'specification'. Richard, Per and myself have given more than enough to enable that. -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Actually you don't need the full path, I just show that so you can find where the uits are so you can read them an see how naive they are.
You can get a list of the mount units with systemctl -t mount --all -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2016-10-03 16:58, Anton Aylward wrote:
Hmmm Well actually I've just run
systemctl stop /run/systemd/generator/home-anton-MyDocuments.mount
Horrible! :-/ -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
On 10/03/2016 02:45 PM, Carlos E. R. wrote:
On 2016-10-03 16:58, Anton Aylward wrote:
Hmmm Well actually I've just run
systemctl stop /run/systemd/generator/home-anton-MyDocuments.mount
Horrible!
Yes but then so is doing things without a $PATH and having to type /usr/bin/<command> Yes, but then so is not having the CD command and doing things like /usr/bin/oowrite /home/anton/MyDocuments/Leters/Daddy/Christmas-card-2016.odt I did say
Actually you don't need the full path, I just show that so you can find where the units are so you can read them an see how naive they are.
-- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
(Resent to fix a rogue typo that made a paragraph illegible) On 2 October 2016 at 23:02, Larry Stotler <larrystotler@gmail.com> wrote:
You just made my argument for me. All I did was say "hey I dont care for it, but it is care for by others so just give me a way to not have to use it" and you go and try to tell me what to do. So basically, if I don't agree with you, I shouldn't be here on this list and shouldn't use openSUSE - even tho I have been using it and supporting it for 17 years.
For the last 6 of those 17 years, openSUSE has been talking about using systemd For the last 5 of those 17 years, since 11.4 at the beginning of 2011, openSUSE has been shipping systemd. By the end of that year, in openSUSE 12.1 it was running by default. The best time to discuss or raise actionable objections to systemd in openSUSE were 6 years ago, in 2010, before the openSUSE community made a collective decision to go there. An acceptable time would have been any time during 2011 or even into 2012, there is of course the reality that these things sometimes take some time for peoples opinions to coalesce But in 2016, 5 years after implementation and 4 years after the official support end date of the last non-systemd openSUSE distribution? I'm sorry, that ship has sailed, crossed the ocean, docked, set out again, circumnavigated the globe, and is going around again
I admin Linux systems and I find using systemd more difficult than what I am used to. I don't find it better, so where is the advantage? Further, I see no advantage for using systemd on a server at all. But that's MY experience, which is obviously different from YOURS. However, I'm not telling you to go away just because we disagree.
I am asking you to do take the time to learn about systemd before considering your opinion on it as complete. systemd is downright amazing on servers. Want to make a service that automatically deletes files in a folder every time they appear? That's like 3 lines in a systemd unit file, done using systemd's more dynamic features, like having services start only when required, is a dreamy way of optimising your servers http://0pointer.de/blog/projects/socket-activated-containers.html unlike ancient, old, useless init systems that preceded it, systemd KNOWS the state of the boot and the services it required. Not guessing it and hoping for dozens of well written init scripts to be able to detect and report their status truthfully, but KNOW, to the point where a simple systemctl can show you the status of every single service and it's health. http://0pointer.de/blog/projects/systemd-for-admins-1.html systemd uses cgroups by default - Again, this ensures you as an admin CAN know every process a service owns - No more digging around ps and trying to figure out what bloody processes another service started. No more mystery processes that escaped the service by wonderful forking tricks (yes I'm looking at you apache), every service is running in a cgroup, so a simple systemctl status shows the processes in that group. http://0pointer.de/blog/projects/systemd-for-admins-2.html Want to limit or prioritise cpu, memory or IO resources to one service over another? Sure! http://0pointer.de/blog/projects/resources.html I could go on.. actually I will Want to figure out EXACTLY which services are taking a long time to boot and the role they play in the critical boot chain? systemd has tools that can answer that.. http://0pointer.de/blog/projects/blame-game.html As a sysadmin you want to be in complete control of your system You want to be able to override the settings and scripts that distributions have given you for the services they have packaged Can you do that with sysvinit? not on your life - as soon as you install the upgraded version of the package all those customisations will be thrown away With systemd, you have various ways of selectively, or entirely, replacing distribution systemd configuration with exactly what you need, in a way which does not interfere with distributions doing their responsible role of providing sane defaults for those services http://0pointer.de/blog/projects/on-etc-sysinit.html Got a service you want to run 10 times with just one parameter different, such as we do with openQA where we're running multiple worker services on the same host - systemd makes it easy - http://0pointer.de/blog/projects/instances.html aaaand now I'm getting tired of signing systemd's praises.. I COULD go on..and frankly the fact that I could after writing all of the above should probably give any systemd-sceptic, especially a sysadmin-systemd-sceptic, pause for thought and start them wondering whether systemd really is the nasty monster the rumours have made it out to be, or whether any sysadmin who isn't getting up to speed on what this can do is going to be left without the skills and expertise to actually manage the linux systems of today, never mind tomorrow. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
* Larry Stotler (larrystotler@gmail.com) [20161002 22:50]:
systemd to me personally has always seemed to be a solution in search of a problem.
No, the problem was real. SysVinit doesn't know the current state of the system but rather what it believes the status should be. So a replacement that does track the state was needed.
The devs behind systemd seem to be trying to take over the linux ecosystem by proxy.
That's part of the problem. The main reason is that it's head developers believe their views are the only correct ones and can't be debated. This alienates people rather quickly. Philipp -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Friday, 7 October 2016 10:19:36 BST Philipp Thomas wrote:
* Larry Stotler (larrystotler@gmail.com) [20161002 22:50]:
systemd to me personally has always seemed to be a solution in search of a problem.
No, the problem was real. SysVinit doesn't know the current state of the system but rather what it believes the status should be. So a replacement that does track the state was needed.
The devs behind systemd seem to be trying to take over the linux ecosystem by proxy.
That's part of the problem. The main reason is that it's head developers believe their views are the only correct ones and can't be debated. This alienates people rather quickly. Its pretty much the same attitude with the kernel but everyone approves of
Thats one of those statements i see where a lot negative and incorrect ideas have run out, a bit like "its monolithic". that, its the systemd devs baby so they call the shots. More people should read their forums before making judgements. I think its more to do with people misunderstanding L Poettering and therefore disliking him, most of the time.
Philipp
People should spend more time looking into it rather than just trashing it for vague reasons, nothing is perfect or bug free. Ian -- opensuse:tumbleweed:20161003 Qt: 5.7.0 KDE Frameworks: 5.26.0 KDE Plasma: 5.7.4 kwin5-5.7.4-1.3.x86_64 kmail5-16.08.1-1.2.x86_64 Kernel: 4.7.5-1-default Nouveau: 1.0.13_1.1 -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 10/07/2016 04:48 AM, ianseeks wrote:
People should spend more time looking into it rather than just trashing it for vague reasons, nothing is perfect or bug free.
While the initial release of systemd was a lot more worked out, a lot more functional than the initial release of KDE4, the same principle holds. This is FOSS. This is not IBM or Microsoft[1] where they can pay many developers, testers or documenters and throw effort to get a completed, documented, tested product out to start with. We routinely accept that there are pre-bet, beta, pre-alpha and release candidate version of such things as the kernel level and other releases. We accepted the incomplete Linux before version 0.99. (Well, some of us did.) Its sad that KDE4 originally came out as what amounted to pre-pre-pre-pre-pre-beta, but none the less the same cycle of feedback from users testing to the developers applied. Oh, wait, not I come to think of it, Microsoft (and others) does in fact release early candidates to to users for test and feedback. The difference between Microsoft and the FOSS community, I think, is that the people to whom Microsoft releases those early evaluation/beta version to (a) have a more professional attitude and (b) are bound by signed agreements about what they can disclose and the responsibilities they commit to. This being FOSS there are not such signed agreements. A developer who releases software, no matter how tested & documented, leaves himself/herself open to to public. We've seen how that includes death threats and threats of rape and dismemberment in various such 'open' communities. See pint 'a' above. [1] Well perhaps not so. -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Friday, 7 October 2016 08:16:10 BST Anton Aylward wrote:
On 10/07/2016 04:48 AM, ianseeks wrote:
People should spend more time looking into it rather than just trashing it for vague reasons, nothing is perfect or bug free.
While the initial release of systemd was a lot more worked out, a lot more functional than the initial release of KDE4, the same principle holds.
This is FOSS. This is not IBM or Microsoft[1] where they can pay many developers, testers or documenters and throw effort to get a completed, documented, tested product out to start with.
We routinely accept that there are pre-bet, beta, pre-alpha and release candidate version of such things as the kernel level and other releases.
We accepted the incomplete Linux before version 0.99. (Well, some of us did.)
Its sad that KDE4 originally came out as what amounted to pre-pre-pre-pre-pre-beta, but none the less the same cycle of feedback from users testing to the developers applied.
Oh, wait, not I come to think of it, Microsoft (and others) does in fact release early candidates to to users for test and feedback. The difference between Microsoft and the FOSS community, I think, is that the people to whom Microsoft releases those early evaluation/beta version to (a) have a more professional attitude and (b) are bound by signed agreements about what they can disclose and the responsibilities they commit to.
This being FOSS there are not such signed agreements. A developer who releases software, no matter how tested & documented, leaves himself/herself open to to public. We've seen how that includes death threats and threats of rape and dismemberment in various such 'open' communities. See pint 'a' above.
Yep, that always gets forgotten
[1] Well perhaps not so.
> Q: Are you sure? > >> A: Because it reverses the logical flow of conversation. >> >>> Q: Why is top posting frowned upon?
-- opensuse:tumbleweed:20161003 Qt: 5.7.0 KDE Frameworks: 5.26.0 KDE Plasma: 5.7.4 kwin5-5.7.4-1.3.x86_64 kmail5-16.08.1-1.2.x86_64 Kernel: 4.7.5-1-default Nouveau: 1.0.13_1.1 -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2016-10-07 14:16, Anton Aylward wrote:
On 10/07/2016 04:48 AM, ianseeks wrote:
People should spend more time looking into it rather than just trashing it for vague reasons, nothing is perfect or bug free.
While the initial release of systemd was a lot more worked out, a lot more functional than the initial release of KDE4, the same principle holds.
This is FOSS. This is not IBM or Microsoft[1] where they can pay many developers, testers or documenters and throw effort to get a completed, documented, tested product out to start with.
We routinely accept that there are pre-bet, beta, pre-alpha and release candidate version of such things as the kernel level and other releases.
We accepted the incomplete Linux before version 0.99. (Well, some of us did.)
Its sad that KDE4 originally came out as what amounted to pre-pre-pre-pre-pre-beta, but none the less the same cycle of feedback from users testing to the developers applied.
Oh, wait, not I come to think of it, Microsoft (and others) does in fact release early candidates to to users for test and feedback. The difference between Microsoft and the FOSS community, I think, is that the people to whom Microsoft releases those early evaluation/beta version to (a) have a more professional attitude and (b) are bound by signed agreements about what they can disclose and the responsibilities they commit to.
The difference is that it is not normal that they release to the general public an unfinished or beta product, which is what has been done here several times, like with kde4. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
On 10/07/2016 11:15 AM, Carlos E. R. wrote:
The difference is that it is not normal that they release to the general public an unfinished or beta product, which is what has been done here several times, like with kde4.
While its certainly true that beta things like KDE4 and BTRFS have been released "experimentally" upon opensuse users, we here on this list have always known that OpenSuse was a development platform for SLES/SLED under prior ownership. Whether this persists with Leap remains to be seen. If I just bought a brand name, I would be interested in protecting that asset and making sure the kinds in the yard didn't trash the trash the house again. We knew we were getting beta. We kind of expected it. We knew we were a testbed. The innocent linux tourist on the street ended up the victim of this policy and soon wanders off elsewhere cursing both Opensuse and KDE4. This was always done by making these experiments the DEFAULT selection without so much as a word of warning, and then when that blew up in their face, insisting nobody forced that choice on the user. -- After all is said and done, more is said than done.
On 2016-10-07 21:34, John Andersen wrote:
On 10/07/2016 11:15 AM, Carlos E. R. wrote:
The difference is that it is not normal that they release to the general public an unfinished or beta product, which is what has been done here several times, like with kde4.
While its certainly true that beta things like KDE4 and BTRFS have been released "experimentally" upon opensuse users, we here on this list have always known that OpenSuse was a development platform for SLES/SLED under prior ownership.
Yes, that is my belief too, but it has always been denied from "up somewhere" :-p But my point was that on the proprietary camp they never do that, or at least I'm not aware of it. Instead they recruit Beta testers that have to sign up somewhere so that they are aware that they are testing and using a Beta product. After all, you would not pay to use a Beta, you pay for a "finished" product. And you typically have to pay for the next version that should have significant changes.
Whether this persists with Leap remains to be seen. If I just bought a brand name, I would be interested in protecting that asset and making sure the kinds in the yard didn't trash the trash the house again.
No, that role now is in Tumbleweed, which has a much bigger user base that the old Factory ever had.
We knew we were getting beta. We kind of expected it. We knew we were a testbed.
The innocent linux tourist on the street ended up the victim of this policy and soon wanders off elsewhere cursing both Opensuse and KDE4.
Yep.
This was always done by making these experiments the DEFAULT selection without so much as a word of warning, and then when that blew up in their face, insisting nobody forced that choice on the user.
Yep. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
Le 07/10/2016 à 22:40, Carlos E. R. a écrit :
But my point was that on the proprietary camp they never do that,
LOL. Did you ever use Windows?
pay for a "finished" product. And you typically have to pay for the next version that should have significant changes.
did you ever use one of the "drivers" burn on CD and sold with devices? oh... it was said to immediately update through the net... every software evolve so fast having something like a stable one is a dream, and this whatever software you have, pay or use. FOSS is no less stable as any paid software, on the contrary it's nearly the only ecosystem where one can directly speak to "the ones who knows". Do you simply know who is responsible of Windows Photo editor? Anybody can talk to the Digikam one at will. openSUSE was never a beta (when not said so). It was simply software. And kde4 was not openSUSE specific and certainly not worst than Windows 8 (for example) can one forget the Cathedral & the bazaar, Rlease early, release often? https://fr.wikipedia.org/wiki/Release_early,_release_often this is FOSS by essence and TW have much more users than Leap, so this is what users want jdd -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2016-10-07 23:06, jdd wrote:
Le 07/10/2016 à 22:40, Carlos E. R. a écrit :
But my point was that on the proprietary camp they never do that,
LOL. Did you ever use Windows?
Yes, sure. Do you know that in Spain almost every body has a pirated copy? Windows is free! :-P
pay for a "finished" product. And you typically have to pay for the next version that should have significant changes.
did you ever use one of the "drivers" burn on CD and sold with devices? oh... it was said to immediately update through the net...
Ah, yes. Those are typically an exception. And when Windows does an upgrade to another version, many of those drivers fail. You either buy a new printer or do not upgrade Windows. But drivers are not "software", strictly speaking in the sense I meant.
Do you simply know who is responsible of Windows Photo editor? Anybody can talk to the Digikam one at will.
Yes, true. Although there are exceptions.
openSUSE was never a beta (when not said so). It was simply software. And kde4 was not openSUSE specific and certainly not worst than Windows 8 (for example)
Oh, I don't know about that one.
can one forget the Cathedral & the bazaar, Rlease early, release often?
Yes, I read it.
this is FOSS by essence
and TW have much more users than Leap, so this is what users want
jdd
-- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
On 10/07/2016 04:40 PM, Carlos E. R. wrote:
After all, you would not pay to use a Beta, you pay for a "finished" product. And you typically have to pay for the next version that should have significant changes.
In theory but what about ... Oh wait a moment, I didn't pay for Linux![1] Come to that, I look at the people who *HAVE* paid for MS-Windows and see that they are going though even though they did not knowingly sign up as testers, and get a 'product' that is a lot more unstable and awkward and irritating than any version of Linux I've had since I switched of OpenSUSE at about 5.something. And unlike MS-Windos, each release has not been a massive new learning project; the basic 'pattern' principles of *NIX that I learnt in the 1970s have served me well, while everything about MS-Windows seems 'sui generis'. Heck, people seem to need retraining courses even with a new release of MS-Office; I recall that happening at one company I was working for that was sucking at the MS teat and saying that it was more cost effective than Linux or OSX because there was a greater pool of expertise. Ha, bloody ha ha. [1] Well, OK, I paid for DVDs and for the bandwidth to download the ISO to burn onto them, but I was buying those DVDs to do backups anyway and the network costs were a 'sunk cost' anyhow. -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Fri, Oct 7, 2016 at 6:04 PM, Anton Aylward <opensuse@antonaylward.com> wrote:
Oh wait a moment, I didn't pay for Linux![1]
I paid for S.u.S.E. versions for years because I didn't have a high speed internet connection. Probably at least 10 versions between v5.3 & v9.3 over 7 years. When I finally got high speed internet, the openSUSE project was just starting, so I did what I could to test it out and report good and bad. Then life became more important and I dropped off due to lack of time. I personally would not have a problem paying a small yearly fee($20-50) for a stable long term support version(5 years at least) of an OS that did what I needed and supported my (generally older) hardware. I used OS/2 before coming to linux, and DOS and CP/M before that. Even macOS is now free to upgrade to a new version. WinDoZe has a huge advantage over Linux - Inertia. You go to a website and download the program and it basically installs on whatever version you have on your machine. With Linux, you have a repo manager instead(and 100s of distros and several versions of each). It was a huge shift(that iOS and Android have adopted now with their "App stores" & M$ is trying to copy) compared to what people were used to. I did work for several companies locally that we tried to switch over to Linux on the desktop(generally at their request). Each project pretty much failed. With the cost of us installing and setting up the systems and trying(to great frustration all around) to train the users on the different programs, and incompatibilities with openOffice & MS Office products, it ended up not saving anyone any money. When we broke down the attempted changover vs the support costs of fixing and maintaining/upgrading/cleaning their current systems, it was a wash. I don't even offer to do a desktop Linux install anymore - business or personal. I am more than happy to setup a server though. I don't expect my experience to be a majority one. It's just what I have seen. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 10/07/2016 05:17 PM, Larry Stotler wrote:
I paid for S.u.S.E. versions for years because I didn't have a high speed internet connection. Probably at least 10 versions between v5.3 & v9.3 over 7 years.
Me too. I bought just about every boxed set they sold, and still have several on the shelf, the others I gave to employees. I didn't always use these, but they were like 50 bucks or so and I just did it to support them and get another set of manuals. And this was even after we DID have high speed internet. I stopped buying them when they stopped making them back in the Novell days. And we also had two paid SLES server subscriptions in house, and three others that we recommended for client sites. I also ordered rack-mounts that came with SLES installed. -- After all is said and done, more is said than done. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 8 October 2016 at 02:32, John Andersen <jsamyth@gmail.com> wrote:
And this was even after we DID have high speed internet. I stopped buying them when they stopped making them back in the Novell days.
We didn't stop doing them... Open Source Press have been doing the boxes with us for a while now https://shop.opensuse.org/ That said, Leap 42.1 might be the last one, Open Source Press are not sure they still want to make boxed sets still, we're chatting with them about 42.2 -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Le 08/10/2016 à 10:00, Richard Brown a écrit :
We didn't stop doing them... Open Source Press have been doing the boxes with us for a while now
alas german only :-( jdd -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2016-10-08 10:31, jdd wrote:
Le 08/10/2016 à 10:00, Richard Brown a écrit :
We didn't stop doing them... Open Source Press have been doing the boxes with us for a while now
alas german only :-(
Yep. No English book. The books might be sold separately, perhaps :-? -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
On 10/08/2016 01:00 AM, Richard Brown wrote:
On 8 October 2016 at 02:32, John Andersen <jsamyth@gmail.com> wrote:
And this was even after we DID have high speed internet. I stopped buying them when they stopped making them back in the Novell days. We didn't stop doing them... Open Source Press have been doing the boxes with us for a while now
That said, Leap 42.1 might be the last one, Open Source Press are not sure they still want to make boxed sets still, we're chatting with them about 42.2
For what it's worth, I used to purchase dozens of boxed sets for each SuSE release to distribute at work. My goal was to advance the Linux adoption rate, and it worked within my context. The seeds that I planted 20-years ago are still providing employment for me now. We also recently considered SLED and SLES, but the Gnome hurdle was insurmountable for my users. Regards, Lew -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Sat 08 Oct 2016 09:11:00 AM CDT, Lew Wolfgang wrote:
On 10/08/2016 01:00 AM, Richard Brown wrote:
On 8 October 2016 at 02:32, John Andersen <jsamyth@gmail.com> wrote:
And this was even after we DID have high speed internet. I stopped buying them when they stopped making them back in the Novell days. We didn't stop doing them... Open Source Press have been doing the boxes with us for a while now
That said, Leap 42.1 might be the last one, Open Source Press are not sure they still want to make boxed sets still, we're chatting with them about 42.2
For what it's worth, I used to purchase dozens of boxed sets for each SuSE release to distribute at work. My goal was to advance the Linux adoption rate, and it worked within my context. The seeds that I planted 20-years ago are still providing employment for me now.
We also recently considered SLED and SLES, but the Gnome hurdle was insurmountable for my users.
Regards, Lew
Hi KDE/Plasma5 is available via PackageHub; https://packagehub.suse.com/ -- Cheers Malcolm °¿° LFCS, SUSE Knowledge Partner (Linux Counter #276890) openSUSE Leap 42.1|GNOME 3.16.2|4.1.31-30-default up 1 day 0:58, 2 users, load average: 0.47, 0.24, 0.21 CPU AMD Athlon(tm) II X4 635 @ 2.90GHz | GPU Nvidia GeForce 8800 GT -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Le 08/10/2016 à 18:29, Malcolm a écrit :
KDE/Plasma5 is available via PackageHub; https://packagehub.suse.com/
I see: "While we are hard at work preparing the official release of SUSE Package Hub, you can test it out ahead of time! " is it usable right now? is it usable with the free 60 days account, for testing purpose comparing with Leap, are these package (in term of version number) olders, equal,, newers? thanks jdd -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
* jdd <jdd@dodin.org> [01-01-70 12:34]:
Le 08/10/2016 à 18:29, Malcolm a écrit :
KDE/Plasma5 is available via PackageHub; https://packagehub.suse.com/
I see:
"While we are hard at work preparing the official release of SUSE Package Hub, you can test it out ahead of time! "
is it usable right now? is it usable with the free 60 days account, for testing purpose
comparing with Leap, are these package (in term of version number) olders, equal,, newers?
looking at plasma5 packages on the website, appears 5.5.5 perhaps you can look and compare package versions. -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri http://wahoo.no-ip.org Photo Album: http://wahoo.no-ip.org/gallery2 Registered Linux User #207535 @ http://linuxcounter.net -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Sat 08 Oct 2016 06:42:55 PM CDT, jdd wrote:
Le 08/10/2016 à 18:29, Malcolm a écrit :
KDE/Plasma5 is available via PackageHub; https://packagehub.suse.com/
I see:
"While we are hard at work preparing the official release of SUSE Package Hub, you can test it out ahead of time! "
is it usable right now? is it usable with the free 60 days account, for testing purpose
comparing with Leap, are these package (in term of version number) olders, equal,, newers?
thanks jdd
Since it's hosted on download.opensuse.org you can browse to see what is there... http://download.opensuse.org/repositories/openSUSE:/Backports:/SLE-12-SP1/st... I'm no lawyer, but.."There is no extra cost to use SUSE Package Hub packages with valid SUSE Linux Enterprise subscriptions." but it won't disappear after 60 days if you add it. -- Cheers Malcolm °¿° LFCS, SUSE Knowledge Partner (Linux Counter #276890) openSUSE Leap 42.1|GNOME 3.16.2|4.1.31-30-default up 1 day 1:34, 2 users, load average: 0.04, 0.08, 0.09 CPU AMD Athlon(tm) II X4 635 @ 2.90GHz | GPU Nvidia GeForce 8800 GT -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Le 08/10/2016 à 19:09, Malcolm a écrit :
I'm no lawyer, but.."There is no extra cost to use SUSE Package Hub packages with valid SUSE Linux Enterprise subscriptions." but it won't disappear after 60 days if you add it.
it's just now for testing purpose, for example what about Packman, is it simply necessary or are the special license software included. But may be it's not the place to discuss SLES? age coming I feel not as free to experiment new things than I was and seriously plan to move to SLES :-( jdd -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Sat 08 Oct 2016 08:04:18 PM CDT, jdd wrote:
Le 08/10/2016 à 19:09, Malcolm a écrit :
I'm no lawyer, but.."There is no extra cost to use SUSE Package Hub packages with valid SUSE Linux Enterprise subscriptions." but it won't disappear after 60 days if you add it.
it's just now for testing purpose, for example what about Packman, is it simply necessary or are the special license software included. But may be it's not the place to discuss SLES?
age coming I feel not as free to experiment new things than I was and seriously plan to move to SLES :-(
jdd
Hi I don't use packman, but they have SLE repos that should work fine. -- Cheers Malcolm °¿° LFCS, SUSE Knowledge Partner (Linux Counter #276890) openSUSE Leap 42.1|GNOME 3.16.2|4.1.31-30-default up 1 day 2:43, 2 users, load average: 1.53, 1.53, 1.12 CPU AMD Athlon(tm) II X4 635 @ 2.90GHz | GPU Nvidia GeForce 8800 GT -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 8 October 2016 at 02:17, Larry Stotler <larrystotler@gmail.com> wrote:
I personally would not have a problem paying a small yearly fee($20-50) for a stable long term support version(5 years at least) of an OS that did what I needed and supported my (generally older) hardware. I used OS/2 before coming to linux, and DOS and CP/M before that. Even macOS is now free to upgrade to a new version.
Hello! Have you heard of an operating system called SUSE Linux Enterprise Desktop? It's a stable long term supported distribution with over 5 years of support, and as an 'Enterprise' product supports a very wide range of hardware, including generally older hardware. It's available under an annual subscription model, costing $50 a year https://www.suse.com/shop/desktop#subnav -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On October 8, 2016 1:00:39 AM PDT, Richard Brown <RBrownCCB@opensuse.org> wrote:
On 8 October 2016 at 02:17, Larry Stotler <larrystotler@gmail.com> wrote:
I personally would not have a problem paying a small yearly fee($20-50) for a stable long term support version(5 years at least) of an OS that did what I needed and supported my (generally older) hardware. I used OS/2 before coming to linux, and DOS and CP/M before that. Even macOS is now free to upgrade to a new version.
Hello!
Have you heard of an operating system called SUSE Linux Enterprise Desktop?
It's a stable long term supported distribution with over 5 years of support, and as an 'Enterprise' product supports a very wide range of hardware, including generally older hardware.
It's available under an annual subscription model, costing $50 a year
Yup, bought that too, but was all Gnome and didn't even keep up with the timely releases of office suites we bought it to run. There might have been a reason it was all Gnome, since that was back in the KDE4 wars era. Could be suse was smart enough not to eat it's own dogfood. It was generally regarded as a rip off by those customers who ended up using it. -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Le 08/10/2016 à 10:00, Richard Brown a écrit :
It's available under an annual subscription model, costing $50 a year
yes, and it's nice, but gnome only :-( It was said often than money is not a problem for openSUSE (reasonably), so making an annual payment for openSUSE is neither a solution. What could be done is marketing material. For example, I spend some money printing french flyers. Not expensive enough to be worth a reimbursing application, but also not good enough IMHO. It could certainly be made better with some local organization, but I never had time to manage one. openSUSE lacks what Ubuntu have: local systems. But we are probably too far from the initial subject of the thread and I don't have time right now to start a new one :-( by the way helping as much as you can (yes, you, the reader :-)) is the best path to take. Think at how large is the commercial power of the competitors... jdd -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 10/07/2016 02:15 PM, Carlos E. R. wrote:
The difference is that it is not normal that they release to the general public an unfinished or beta product, which is what has been done here several times, like with kde4.
Oh, you think so, do you? "Several time", eh? Over the years almost everything went though that. It's what FOSS is about. You weren't around for the pre- 0.99 days, then? You weren't around when the ext FS was 'experimental'? You weren't around when the whole IP networking stack was 'experimental' and only a subset worked. You weren't around when SAMBA was incomplete and experimental and only a subset worked and was unstable at that. Cue Mary Hopkins singing "Those were the days". At the time, yes, it was frustrating and "we thought they'd never end", the bugs, the patches, the arguments. But they did. -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2016-10-07 22:21, Anton Aylward wrote:
On 10/07/2016 02:15 PM, Carlos E. R. wrote:
The difference is that it is not normal that they release to the general public an unfinished or beta product, which is what has been done here several times, like with kde4.
Oh, you think so, do you? "Several time", eh?
Over the years almost everything went though that. It's what FOSS is about.
You weren't around for the pre- 0.99 days, then? You weren't around when the ext FS was 'experimental'? You weren't around when the whole IP networking stack was 'experimental' and only a subset worked. You weren't around when SAMBA was incomplete and experimental and only a subset worked and was unstable at that.
No. Insstead I paid for using a distribution that was stable and not experimental. Called SuSE 5.3. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
On 10/07/2016 04:21 PM, Anton Aylward wrote:
On 10/07/2016 02:15 PM, Carlos E. R. wrote:
The difference is that it is not normal that they release to the general public an unfinished or beta product, which is what has been done here several times, like with kde4.
Oh, you think so, do you? "Several time", eh?
Over the years almost everything went though that. It's what FOSS is about.
You weren't around for the pre- 0.99 days, then? You weren't around when the ext FS was 'experimental'? You weren't around when the whole IP networking stack was 'experimental' and only a subset worked. You weren't around when SAMBA was incomplete and experimental and only a subset worked and was unstable at that.
Cue Mary Hopkins singing "Those were the days". At the time, yes, it was frustrating and "we thought they'd never end", the bugs, the patches, the arguments. But they did.
Ah yes, those were the days indeed. Installing from floppies (lots of floppies). Having to edit file after file to setup networking. Having to run a program (I forget the name) to configure "X", and heaven forbid if you answered on the the 20 some choices wrong and had to start over. My first linux version was from Slackware, I believe on something like 15 3.5" floppies. -- Ken linux since 1994 S.u.S.E./openSUSE since 1996 -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
ianseeks wrote:
On Friday, 7 October 2016 10:19:36 BST Philipp Thomas wrote:
* Larry Stotler (larrystotler@gmail.com) [20161002 22:50]:
systemd to me personally has always seemed to be a solution in search of a problem.
Thats one of those statements i see where a lot negative and incorrect ideas have run out, a bit like "its monolithic".
Caught this in looking for something. You apparently didn't see where I explained why it was monolithic, and I wanted to explain why it was -- as well as using "proprietary" interfaces (ones owned by systemd vs. non-proprietary interfaces that might be considered "open" or "public". It is monolithic because its parts are not designed to be "drop-in-replaceable" by any other non-sysD part. You can't replace any of the parts of systemd that have replaced the earlier parts. Good example: syslog. Syslog was easily interchangeable with ng-syslog and rsyslog. But none of those logs are able to replace systemd's journal. You can add them on as an afterthough -- but not as a drop-in replacement for journal. SysD's parts are interdependent so the they can't be replaced -- I might want to use the redhat cgroup manager instead of Sysd -- can I replace Sysd's ownership of the cgroups or "Init"? Say I develop an init and want to use it in place of SysD -- but just for capturing dead procs and such (creating a subscription mechanism usable by other "parties", including SysD). Could I simply drop it in and have it work? Of course not! That's why SysD is monolithic -- it can't be used for its separate parts which are mostly indivisible as they use each other in ways that are _proprietary_ to SysD (i.e. there is no *open*, widely supported interface to interact with them. Proprietary mean "owned by someone" -- in this case sysd -- which has appropriated the previous "open" interfaces and replaced them with interfaces that only other SysD 'units' use. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Sun, Oct 23, 2016 at 7:06 PM, Linda Walsh <suse@tlinx.org> wrote:
ianseeks wrote:
On Friday, 7 October 2016 10:19:36 BST Philipp Thomas wrote:
* Larry Stotler (larrystotler@gmail.com) [20161002 22:50]:
systemd to me personally has always seemed to be a solution in search of a problem.
Thats one of those statements i see where a lot negative and incorrect ideas have run out, a bit like "its monolithic".
--- Caught this in looking for something.
You apparently didn't see where I explained why it was monolithic, and I wanted to explain why it was -- as well as using "proprietary" interfaces (ones owned by systemd vs. non-proprietary interfaces that might be considered "open" or "public".
It is monolithic because its parts are not designed to be "drop-in-replaceable" by any other non-sysD part.
Of course they are. It is just that no one has bothered to make such replacements in most cases.
You can't replace any of the parts of systemd that have replaced the earlier parts. Good example: syslog. Syslog was easily interchangeable with ng-syslog and rsyslog. But none of those logs are able to replace systemd's journal. You can add them on as an afterthough -- but not as a drop-in replacement for journal.
There is an enormous difference between saying program A can't be replaced with program B and saying program A can't be replaced at all. You only provide examples of the first case, but then claim the second. Yes, systemd's tools work in different ways than previous tools. That is why people wrote new tools to begin with, to satisfy needs and use-cases the older tools didn't fill. So it is no surprise that older tools don't act as drop-in replacements. But there is nothing stopping someone else from writing a tool that could act as a replacement.
Say I develop an init and want to use it in place of SysD -- but just for capturing dead procs and such (creating a subscription mechanism usable by other "parties", including SysD). Could I simply drop it in and have it work?
Of course you could, as long as it provided the features needed by the programs you want it to work with. systemd's components all use standard linux tools to talk to each other and all talk using open, documented interfaces. There is absolutely nothing whatsoever preventing anyone from replacing any one of them with their own, completely independent program. This hasn't happened much because opponents of systemd aren't willing to put in the effort, there is nothing whatsoever preventing it.
Of course not! That's why SysD is monolithic -- it can't be used for its separate parts which are mostly indivisible as they use each other in ways that are _proprietary_ to SysD (i.e. there is no *open*, widely supported interface to interact with them.
The interfaces aren't "widely supported" solely because no one who opposed systemd has made any effort to support them. There is nothing stopping anyone else from supporting them other than the fact that systemd opponents aren't willing to put in the effort. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Sunday, 23 October 2016 21:52:47 BST Todd Rme wrote:
On Sun, Oct 23, 2016 at 7:06 PM, Linda Walsh <suse@tlinx.org> wrote:
ianseeks wrote:
On Friday, 7 October 2016 10:19:36 BST Philipp Thomas wrote:
* Larry Stotler (larrystotler@gmail.com) [20161002 22:50]:
systemd to me personally has always seemed to be a solution in search of a problem.
Thats one of those statements i see where a lot negative and incorrect ideas have run out, a bit like "its monolithic".
--- Caught this in looking for something.
You apparently didn't see where I explained why it was monolithic, and I wanted to explain why it was -- as well as using "proprietary" interfaces (ones owned by systemd vs. non-proprietary interfaces that might be considered "open" or "public".
It is monolithic because its parts are not designed to be "drop-in-replaceable" by any other non-sysD part.
Of course they are. It is just that no one has bothered to make such replacements in most cases.
You can't replace any of the parts of systemd that have replaced the earlier parts. Good example: syslog. Syslog was easily interchangeable with ng-syslog and rsyslog. But none of those logs are able to replace systemd's journal. You can add them on as an afterthough -- but not as a drop-in replacement for journal.
There is an enormous difference between saying program A can't be replaced with program B and saying program A can't be replaced at all. You only provide examples of the first case, but then claim the second. Yes, systemd's tools work in different ways than previous tools. That is why people wrote new tools to begin with, to satisfy needs and use-cases the older tools didn't fill. So it is no surprise that older tools don't act as drop-in replacements. But there is nothing stopping someone else from writing a tool that could act as a replacement.
Say I develop an init and want to use it in place of SysD -- but just for capturing dead procs and such (creating a subscription mechanism usable by other "parties", including SysD). Could I simply drop it in and have it work?
Of course you could, as long as it provided the features needed by the programs you want it to work with. systemd's components all use standard linux tools to talk to each other and all talk using open, documented interfaces. There is absolutely nothing whatsoever preventing anyone from replacing any one of them with their own, completely independent program. This hasn't happened much because opponents of systemd aren't willing to put in the effort, there is nothing whatsoever preventing it.
Of course not! That's why SysD is monolithic -- it can't be used for its separate parts which are mostly indivisible as they use each other in ways that are _proprietary_ to SysD (i.e. there is no *open*, widely supported interface to interact with them.
The interfaces aren't "widely supported" solely because no one who opposed systemd has made any effort to support them. There is nothing stopping anyone else from supporting them other than the fact that systemd opponents aren't willing to put in the effort.
Unfortunately people seem to forgot that its open source and if they want to do something different from the norm then they'll have to step up and do the work - they just want it "done their way". -- opensuse:tumbleweed:20161022 Qt: 5.7.0 KDE Frameworks: 5.27.0 KDE Plasma: 5.8.2 kwin5-5.8.2-159.1.x86_64 kmail5-16.08.2-1.1.x86_64 Kernel: 4.8.3-1-default Nouveau: 1.0.13_1.1 -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 10/07/2016 01:19 AM, Philipp Thomas wrote:
* Larry Stotler (larrystotler@gmail.com) [20161002 22:50]:
systemd to me personally has always seemed to be a solution in search of a problem. No, the problem was real. SysVinit doesn't know the current state of the system but rather what it believes the status should be. So a replacement that does track the state was needed.
The devs behind systemd seem to be trying to take over the linux ecosystem by proxy. That's part of the problem. The main reason is that it's head developers believe their views are the only correct ones and can't be debated. This alienates people rather quickly.
Philipp
That's actually not correct, if you had read this long thread, you would see all the arguments in favor of systemd. The people that do the work get the credit, and the "head developers" are the ones who did the work. Most all the popular distros picked systemd up for a reason. It can be debated contrary to what you say, but it mostly just falls on deaf ears because every argument against systemd can be rebutted. "Talk is cheap." If you don't like systemd, then don't just spam a mailing list of a distro where the overwhelming majority of users are in support of systemd. Do something about it. Doing something about it isn't spamming a user support list for openSUSE about your fanatical views regarding how systemd is embedding its tentacles into every facet of Linux. If that is your idea of doing something about "it", then that is really horrible time management, not to mention just creates spam on this list which is not for debating philisophical ideas and questions when it comes to Linux. The openSUSE mailing list is for end-to-end user support. Not for political compains against systemd. I thought this discussion had already been had on every single IRC, Mailing list, Forum, and yet it's still going on and just this thead alone is near 100 responses. Completely ridiculous. It's like anti-vaxxers, the same type of people. The ones with the loud voices are a small minority yet make a lot of noise, and they get a small group to rally against something that essentially goes nowhere. The overwhelmingly large majority is in favour of systemd, and systemd will not be going anywhere for a very long time. The fringe fanatics can go find a distro like Devuan that doesn't have systemd. I don't see what the problem is either. You can have a distro that doesn't have systemd. What is there to debate? We can have systemd, and you can have upstart or whatever they are using in place of systemd. Now, can we please go back to user support and not having a philosophical debate (which was over a long time ago, yes the debate is OVER) that is just egging on trolls because that's exactly what they are trying to accomplish over systemd? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 10/07/2016 01:19 AM, Philipp Thomas wrote:
* Larry Stotler (larrystotler@gmail.com) [20161002 22:50]:
systemd to me personally has always seemed to be a solution in search of a problem. No, the problem was real. SysVinit doesn't know the current state of the system but rather what it believes the status should be. So a replacement that does track the state was needed.
The devs behind systemd seem to be trying to take over the linux ecosystem by proxy. That's part of the problem. The main reason is that it's head developers believe their views are the only correct ones and can't be debated. This alienates people rather quickly.
Philipp
That's actually not correct, if you had read this long thread, you would see all the arguments in favor of systemd. The people that do the work get the credit, and the "head developers" are the ones who did the work. Most all the popular distros picked systemd up for a reason. It can be debated contrary to what you say, but it mostly just falls on deaf ears because every argument against systemd can be rebutted. "Talk is cheap." If you don't like systemd, then don't just spam a mailing list of a distro where the overwhelming majority of users are in support of systemd. Do something about it. Doing something about it isn't spamming a user support list for openSUSE about your fanatical views regarding how systemd is embedding its tentacles into every facet of Linux. If that is your idea of doing something about "it", then that is really horrible time management, not to mention just creates spam on this list which is not for debating philisophical ideas and questions when it comes to Linux. The openSUSE mailing list is for end-to-end user support. Not for political compains against systemd. I thought this discussion had already been had on every single IRC, Mailing list, Forum, and yet it's still going on and just this thead alone is near 100 responses. Completely ridiculous. It's like anti-vaxxers, the same type of people. The ones with the loud voices are a small minority yet make a lot of noise, and they get a small group to rally against something that essentially goes nowhere. The overwhelmingly large majority is in favour of systemd, and systemd will not be going anywhere for a very long time. The fringe fanatics can go find a distro like Devuan that doesn't have systemd. I don't see what the problem is either. You can have a distro that doesn't have systemd. What is there to debate? We can have systemd, and you can have upstart or whatever they are using in place of systemd. Now, can we please go back to user support and not having a philosophical debate (which was over a long time ago, yes the debate is OVER) that is just egging on trolls because that's exactly what they are trying to accomplish over systemd? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 10/07/2016 04:53 AM, sdm wrote:
[...] If you don't like systemd, then don't just spam a mailing list of a distro where the overwhelming majority of users are in support of systemd. Do something about it.
aka "Put up or shut up!"
Doing something about it isn't spamming a user support list for openSUSE about your fanatical views regarding how systemd is embedding its tentacles into every facet of Linux. If that is your idea of doing something about "it", then that is really horrible time management, not to mention just creates spam on this list which is not for debating philisophical ideas and questions when it comes to Linux.
Good point. Perhaps the list management will recognise the vociferous anti-systemd type as the spammers they are and filter their postings, filtering out such time-wasting nonsense. -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 02/10/2016 16:28, stakanov@freenet.de wrote:
> -----Ursprüngliche Nachricht-----
Von: Glenn Holmer Gesendet: So. 02.10.2016 15:29 An: opensuse@opensuse.org , Betreff: Re: [opensuse] interesting reading about systemd
On 10/02/2016 01:35 AM, stakanov@freenet.de wrote:
Found on Phoronix and thought to share.
" target="_blank">https://www.agwa.name/blog/post/how_to_crash_systemd_in_one_tweet https://medium.com/@davidtstrauss/how-to-throw-a-tantrum-in-one-blog-post-c2... Interesting reading thank you. By what is says it confirms partly the criticism and in part is able to make some points. What is puzzling me that the post of Ayer is perceived as a "anti-systemd-fanatic". When I was reading it, I did not see this as a call to "abandon" systemd, but to limit some tendencies. I see it as interesting contribution and I am puzzled about not few about the assertions Strauss makes in his post. And not the minor this:
"As most, it would justify a call to fork systemd and reverse the umask default".
WTF, are we now only able through forking to reconsider problems when pointed out? Maybe it is THIS attitude that calls for abandoning a software, not the points themselves. For what I see, the post makes me more worried then not having read it. It seems as much "religious" and biased as the first. I will hold in mind that there are justified critiques and points in the first post and that unfortunately there is a tendency to bash whatever criticism, as there is as well the tendency to bloat criticism of pitfalls on the other side. All this is not really a good "clima". YMMV.
--- Die Bundesliga hat begonnen! Alle Tore, alle Ergebnisse, alle News: Pocket Liga jetzt im https://app.adjust.com/dpynzd oder https://app.adjust.com/dpynzd herunterladen - kostenlos!
My vote on systemd - I jumped from using a 12.1 system where I had a major dbus bug that was fixed when I switched the system to systemd, it didn't change the systems boot and shutdown times and I was never quite sure if dbus was working properly. I jumped straight into Leap:42.1 and was impressed by the boot time reduction and especially by the shut down time. I was irritated by the inability to write into run-level scripts but actually didn't have to, there's still /etc/bash.bashrc.local. What's the alternative? Dave P -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 10/04/2016 01:57 PM, Dave Plater wrote:
What's the alternative?
Do some searching on the web and you will find some examples that allow you to write your own systemd services and tie them to targets. I had to do this to get VirtualBox to start my VMs at boot time and shut them down at shutdown time. Took me an afternoon on my first attempt cribbing from examples found on line. Its not any harder than an init script. -- After all is said and done, more is said than done. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 10/04/2016 09:02 PM, John Andersen wrote:
On 10/04/2016 01:57 PM, Dave Plater wrote:
What's the alternative?
Do some searching on the web and you will find some examples that allow you to write your own systemd services and tie them to targets.
I had to do this to get VirtualBox to start my VMs at boot time and shut them down at shutdown time.
Took me an afternoon on my first attempt cribbing from examples found on line. Its not any harder than an init script.
Indeed. Way back when in the early days I did the same to get a unit working for starting Postfix. I've made a couple more since. its not difficult and they are easier to work with than sysv-init scripts since the effect and side effects and dependencies are so clear. -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
participants (22)
-
Andrei Borzenkov -
Anton Aylward -
Carlos E. R. -
Dave Plater -
Felix Miata -
ianseeks -
jdd -
John Andersen -
Ken Schneider -
Knurpht - Gertjan Lettink -
L. A. Walsh -
Larry Stotler -
Lew Wolfgang -
Linda Walsh
-
Malcolm -
Patrick Shanahan -
Per Jessen -
Philipp Thomas -
Richard Brown -
sdm -
stakanov＠freenet.de -
Todd Rme