On Sunday 20 November 2011, Cristian Rodríguez wrote:

On 20/11/11 07:17, Rüdiger Meier wrote:

...

There is a "Filesystem Hierarchy Standard"

here we go with this bunch of papers and nice theory...

...

where admins, users and developers can read about where to find or where to put files. Old standards may not be entirely perfect forever but they are required keep things transparent specially for people who _have_ learned it already. Reading Poettering's email "Hey there, today we have /run" is absolutely the opposite of a doing things straightforward and transparent.

There is no conflict with the FHS, it doesn't forbid distributions to create their own top level directories, it asks for notification of the changes to a (dead) bugtracker/list

...

How/where exactly opensuse has _made_ that decision? I've missed it.

People who write code and deals with bugs and the consequences have to take decisions,

The user/admin has do deal even more with the consequences. Mounting tmpfs over long time existing dirs is a major change. It could lead to big problems for particular users. How you kown what else the admin is doing in /var/run. Is there enough swap space? What about scripts which don't cross filesystem boundaries now in /var/run? Backup ignore lists might be imperfect now. I'm not criticizing here tmpfs usage or /run itself. But as a major change it should have published on Release Notes at least.

in this case it was agreed among all major distributions.

My question was how such agreement happens in practice. I couldn't find anything about it. cu, RUdi -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Le 21/11/2011 13:46, Carlos E. R. a écrit :

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

On Monday, 2011-11-21 at 13:00 +0100, Ruediger Meier wrote:

...

I'm not criticizing here tmpfs usage or /run itself. But as a major change it should have published on Release Notes at least.

Absolutely!

there have been lot of posts asking for infos for release notes. Many things can't be written by members of the marketting team (lack of knowledge) so people making the change have to document it beforehand jdd -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Monday 21 November 2011, Joachim Schrod wrote:

Ruediger Meier wrote:

...

On Sunday 20 November 2011, Cristian Rodríguez wrote:

...

in this case it was agreed among all major distributions.

My question was how such agreement happens in practice. I couldn't find anything about it.

It was announced upstream, see http://lwn.net/Articles/436012/

This is Fedora and/or systemd specific only. I'm not using the one nor the other and don't consider it being upstream source of openSUSE's file system layout. Quotation of your link above: "With this upload Fedora and Suse have already adopted /run now." So Lennart Poettering just _decided_ _finally_ at Wed, 30 Mar 2011 that openSUSE gets /run? Can't believe it.

I'm no openSUSE developer, but AFAIU, the openSUSE maintainer of that package can then decide if the upstream decision is kept or not. Typically, it is.

Such major changes are far beyond the scope of package maintenance. BTW typically openSUSE packages differ very much with upstream's idea of how to install. cu, Rudi -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Monday, November 21, 2011 3:38 PM, "Andreas Jaeger" <aj@suse.com> wrote:

The change to make /var/run as tmpfs was discussed on the packaging mailing list: http://lists.opensuse.org/opensuse-packaging/2010-05/msg00018.html

I don't remember that /run was mentioned separately in a similiar way but this was part of the introduction of systemd that was discussed several times.

Please keep in mind that systemd is also an effort to bring the distributions together in some more areas to make packaging easier,

Exactly, where's the problem with this? There are some very good reasons why this /run is better than what it replaces (http://lwn.net/Articles/436012/). Opensuse would be a much worse distribution if it just kept doing things the way they've been done for years just because not everyone can agree on every change. Maybe that statement of purpose (or whatever it was) for Opensuse should be updated with something like: "Things change, even low-level system components. We'll try to make these changes as smooth as possible and only do them when they're beneficial overall, but if you want a Linux distribution that looks like one from 1999 you'd be better off using Slackware" :) Tim -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Monday, 2011-11-21 at 16:26 +0100, Bruno Friedmann wrote:

For thoses I saw telling that they don't use systemd, prepare yourself to cry. We offer sysvinit as a fallback this time (12.1) nothing prove that will be the case in future releases.

Only if you can prove that it works as well as its predecesor. - -- Cheers, Carlos E. R. (from 11.4 x86_64 "Celadon" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) iEYEARECAAYFAk7K0dUACgkQtTMYHG2NR9VhAQCeJvdKbUEhDHTekMrW3cXZYTH7 irIAnifiRM3UJiuOSV1DMUIRu+GvhjoY =bmoV -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On 11/22/2011 12:43 AM, Linda Walsh wrote:

Bruno Friedmann wrote:

...

For thoses I saw telling that they don't use systemd, prepare yourself to cry. We offer sysvinit as a fallback this time (12.1) nothing prove that will be the

...

case in future releases.

---

Not a problem as long as it doesn't require special partitioning needs that require I reformat my system.

Nope, it does not.

(currently these are separate partitions...that has proven helpful more often than hindrance: sysdirs: /, /var, /tmp, /usr /var/cache (sysdirs) (FWIW:/var/rtmp is 'rbound' to /tmp, so present @boot) + various user level dirs... (/home, /Share, /backups, etc...)

Shouldn't be a problem.

As long as systemd gives me the same control and ease of use/maintenance, that's great. I'd **assume**, it was designed to support, AT LEAST, the minimum features of the existing sytem boot process, and then was enhanced, like any well designed replacement/rewrite?

It's different, so you have to learn a bit more but then it contains more features and is easier to use. And your existing LSB init scripts will continue to work.

(If not, that would already bias me to wonder about the designer's design 'sense', though, I'm easily convinced in the presence of irrefutable logic... ;-)

Andreas -- Andreas Jaeger aj@{suse.com,opensuse.org} Twitter/Identica: jaegerandi SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn,Jennifer Guild,Felix Imendörffer,HRB16746 (AG Nürnberg) GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126 -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Am 22.11.2011 10:43, schrieb Michal Kubeček:

On 2011-11-21 16:26:52, Bruno Friedmann wrote:

...

For thoses I saw telling that they don't use systemd, prepare yourself to cry. We offer sysvinit as a fallback this time (12.1) nothing prove that will be the case in future releases.

Well, this is important. So where should one look to be able to vote against such decision so that it's not "we already decided and you have to live with it" again? Making systemd default in its current state was bad but removing sysvinit would be much worse.

This is not about voting. This is about people taking care sysvinit does not bitrot while systemd gets all the development and bug fixes for things people see. You can vote as much as you like, but in open source projects those that pull stronger on one end win most of the times. Unless of course enough people find themselves pulling at the other end. Greetings, Stephan -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Tue, Nov 22, 2011 at 02:21:37PM +0400, Ilya Chernykh wrote:

On Tuesday 22 November 2011 13:51:01 Stephan Kulow wrote:

...

This is not about voting. This is about people taking care sysvinit does not bitrot while systemd gets all the development and bug fixes for things people see.

You can vote as much as you like, but in open source projects those that pull stronger on one end win most of the times. Unless of course enough people find themselves pulling at the other end.

For example in this case just adding -ltinfo does not help:

gcc -L/usr/lib/qt3/lib -L/opt/kde3/lib -L/usr/lib -lkdecore -lkdeui -lkio -lqt-mt -lkparts -lDCOP -ldl -lstdc++ -ltinfo -lncurses -Wl,-Bsymbolic-functions -L/usr/local/lib -o vim objects/buffer.o objects/charset.o objects/diff.o objects/digraph.o objects/edit.o objects/eval.o objects/ex_cmds.o objects/ex_cmds2.o objects/ex_docmd.o objects/ex_eval.o objects/ex_getln.o objects/fileio.o objects/fold.o objects/getchar.o objects/if_cscope.o objects/if_xcmdsrv.o objects/main.o objects/mark.o objects/memfile.o objects/memline.o objects/menu.o objects/message.o objects/misc1.o objects/misc2.o objects/move.o objects/mbyte.o objects/normal.o objects/ops.o objects/option.o objects/os_unix.o objects/pathdef.o objects/quickfix.o objects/regexp.o objects/screen.o objects/search.o objects/syntax.o objects/tag.o objects/term.o objects/ui.o objects/undo.o objects/window.o objects/gui.o objects/pty.o objects/gui_kde.o objects/gui_kde_x11.o objects/gui_kde_widget.o objects/gui_kde_widget_moc.o objects/kvim_iface_skel.o objects/netbeans.o objects/version.o -lSM -lICE -lXpm -lXt -lX11 -lXdmcp -lSM -lICE -lnsl -lncurses -lacl -lattr -ldl objects/os_unix.o: In function `mch_set_shellsize': /home/abuild/rpmbuild/BUILD/kvim-6.3/src/os_unix.c:3178: undefined reference to `term_set_winsize' collect2: ld returned 1 exit status

It needs to be added after -lncurses Ciao, Marcus -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Tuesday 22 November 2011, Stephan Kulow wrote:

Am 22.11.2011 10:43, schrieb Michal Kubeček:

...

On 2011-11-21 16:26:52, Bruno Friedmann wrote:

...

For thoses I saw telling that they don't use systemd, prepare yourself to cry. We offer sysvinit as a fallback this time (12.1) nothing prove that will be the case in future releases.

Well, this is important. So where should one look to be able to vote against such decision so that it's not "we already decided and you have to live with it" again? Making systemd default in its current state was bad but removing sysvinit would be much worse.

This is not about voting. This is about people taking care sysvinit does not bitrot while systemd gets all the development and bug fixes for things people see.

Yup, that's the ideal way to go.

You can vote as much as you like, but in open source projects those that pull stronger on one end win most of the times. Unless of course enough people find themselves pulling at the other end.

The problem is pulling at the sysvinit end can't be much more than just crying, voting whatever. Sysvinit works. It's complete. There is almost nothing to be done to keep this state. I'm not against systemd generally. Seeing systemd packagers breaking sysvinit support or creating endless system wide dependencies that's my problem. How could I try to prevent this actively? Should I pull the systemd end too to get it into an (IMO) better direction just because I don't want use systemd? That's paradox. cu, Rudi -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Am 22.11.2011 13:37, schrieb Stephan Kulow:

Am 22.11.2011 13:19, schrieb Ruediger Meier:

...

The problem is pulling at the sysvinit end can't be much more than just crying, voting whatever. Sysvinit works. It's complete. There is almost nothing to be done to keep this state.

Sorry, this is nonsense. Sysvinit is little above a collection of bash scripts and each of this scripts can fail when something changes in the system.

And systemd support _is_ changing the system - you can stay on Evergreen for another decade if you don't want changes, but as long as changes exist, keeping sysvinit support alive is WORK.

As nobody can explain to me how a migration path from sysvinit to systemd looks like (see my posting on this list which is unanswered and only contains basic questions) I don't see sysvinit dying right now. Apparently even with systemd we heavily rely on having the old-style init scripts. That may change during 12.2 development phase and I don't care about sysvinit when systemd works in the end and if there are more than 1,5 people in this project who understand how systemd works. Wolfgang -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Dne Út 22. listopadu 2011 13:48:49, Stephan Kulow napsal(a):

And that's clearly the nice part about how things work: as long as there are more people able to fix sysvinit scripts than there are to write systemd service files, it won't happen :)

I'm going to keep a copy of this for future reference... :-) Michal Kubeček -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On 22/11/11 10:01, Stefan Seyfried wrote:

Well. Most systemd service files are much easier to write than a sysv init script.

Significantly easier cleaner and shorter :) I take the lack of shell scripting as a feature ..;) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On 22/11/11 11:22, Ruediger Meier wrote:

On Tuesday 22 November 2011, Cristian Rodríguez wrote:

...

On 22/11/11 10:01, Stefan Seyfried wrote:

...

Well. Most systemd service files are much easier to write than a sysv init script.

Significantly easier cleaner and shorter :) I take the lack of shell scripting as a feature ..;)

Almost all (if not all) config files in /etc/sysconfig are shell code.

Talking about other design errors .. we have those shell-style configuration files :-) you have no idea what people tries to do with them.. after working for now around 5 years on this, I now consider them a bad thing(tm) most of that stuff should be in the respective daemon/service upstream configuration file. Those btw.. are supported by systemd via the EnvironmentFile variable. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On 22/11/11 12:16, Ruediger Meier wrote:

Creative admins can do a lot nice things everywhere they meet shell interpreted files. A lot more than setting static env vars.

That's what Im talking about, abusing a particular tool that wasn't meant to do so.

Are these files interpreted by shell. If yes which one is used?

Apparently it is parsed and executed through d-bus, hopefullyn without forking a shell ;) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On 22.11.2011 18:29, Ruediger Meier wrote:

On Tuesday 22 November 2011, Cristian Rodríguez wrote:

...

That's what Im talking about, abusing a particular tool that wasn't meant to do so.

Ah, still learning something new everyday. Writing shell code into shell scripts is abuse.

/etc/sysconfig/* are config files. That they have "shell-compatible" syntax and that they were parsed by a shell was a mere implementation detail. server:~ # grep '# *! */' /etc/sysconfig/* server:~ # => no shebang, no script. But you are probably also complaining if local root exploits in the kernel are fixed, because now you no longer can use that to become root easily... -- Stefan Seyfried "Dispatch war rocket Ajax to bring back his body!" -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On 22/11/11 15:18, Ruediger Meier wrote:

Ah you are right! I see bashrc and the whole stuff in profile.d/, bash_completion.d/ is misused too.

We are talking about sysconfig implementation and purpose, not about shell profiles ! come on ! -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On 11/22/2011 1:46 PM, Ruediger Meier wrote:

On Tuesday 22 November 2011, Cristian Rodríguez wrote:

...

On 22/11/11 15:18, Ruediger Meier wrote:

...

Ah you are right! I see bashrc and the whole stuff in profile.d/, bash_completion.d/ is misused too.

We are talking about sysconfig implementation and purpose, not about shell profiles ! come on !

It doesn't change the fact there it's nothing bad with using shell code within config files if you know they are interpreted by shell.

It is in fact an explicit feature. Not some abused accident. It is the very reason things are done that way when & where they are, barring plainly bad coding by the inexperienced. If you intend a file to contain only some key/value pairs, you write them in a file that doesn't even pretend or accidentally look like a shell (or other) script, and you do not read that file by sourcing it with any script interpreter. If you DO read a config file by sourcing it right into your current interpreter, then by definition you INTEND for that config file to contain ANYTHING that your script interpreter can do, including sourcing yet other files and running other programs. This allows function libraries, modular chunks of common shared configs, dynamic configs, gah it's endless. Good grief the wrongness of this argument is beyond laughable. This modularity and tool-combining functionality and "we don't know or care what use you might make of this, we're just providing an unlimited flexible blank slate with a bag of small tools you assemble any way you discover you need to, with merely some convention as a helpful starter and guide, instead of trying and failing to predict every possible legitimate need that ever might come up in the future by anyone anywhere ever" is part of the very dna of unix from day one.

"no shebang => no script" is simply wrong.

There are better examples than shell profiles of course. Some of them using python, others using lisp or whatever and sysconfig is currently using shell.

Anyway.

cu, Rudi

-- bkw -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Can we please stop bitching and poking each other? "Why, that's much more fun than a discussion about sysvinit or systemd!" But it doesn't drive openSUSE Factory forward further. And that's the main goal why people are on this list. systemd isn't at bronze level yet. sysvinit isn't platinium. As Coolo said all is open and all depend on how things are developing with the next releases. Making systemd the default - in particular in the update case - didn't made me happy too. But on the other hand it follow the keep it simple stupid (KISS) approch. If someone talks these days about openSUSE 12.1 there is no need to ask which init approach is driving the system. It's systemd by default in in case. Please let us focus on openSUSE Factory work again. Well, I don't like to behave like a list dictator but I strongly suggest EOT. Cheers Lars -- Lars Müller [ˈlaː(r)z ˈmʏlɐ] Samba Team SUSE Linux, Maxfeldstraße 5, 90409 Nürnberg, Germany

On 22/11/11 17:07, Will Stephenson wrote:

+1. sysvinit vs systemd is the new emacs vs vim.

heh, the difference is that systemd still doesnt implement a whole OS yet :-D Seriously, after reading this many threads about systemd and "its evils" I upgraded the configuration I have been using for years with the old tools and found no problems except between chair and computer. Even pulseaudio works smoothly and solves an annoying clicking noise at the start of track I was having using only alsa + samplerate. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Tuesday 22 Nov 2011 17:12:15 Cristian Rodríguez wrote:

On 22/11/11 17:07, Will Stephenson wrote:

...

+1. sysvinit vs systemd is the new emacs vs vim.

heh, the difference is that systemd still doesnt implement a whole OS yet :-D

Seriously, after reading this many threads about systemd and "its evils" I upgraded the configuration I have been using for years with the old tools and found no problems except between chair and computer.

Same here, I took the bareback sed -i -e 's,11.4,12.1,g' /etc/zypp/repos.d/* && zypper dup -l approach to upgrading my home workstation and guess what, it all just worked. Hats off to Frederic and the others working on systemd integration and all the people who tested and made bug reports. Will -- Will Stephenson, openSUSE Team SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 21284 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On 11/22/2011 10:16 AM, Ruediger Meier wrote:

On Tuesday 22 November 2011, Cristian Rodríguez wrote:

...

On 22/11/11 11:22, Ruediger Meier wrote:

...

On Tuesday 22 November 2011, Cristian Rodríguez wrote:

...

On 22/11/11 10:01, Stefan Seyfried wrote:

...

Well. Most systemd service files are much easier to write than a sysv init script.

Significantly easier cleaner and shorter :) I take the lack of shell scripting as a feature ..;)

Almost all (if not all) config files in /etc/sysconfig are shell code.

Talking about other design errors .. we have those shell-style configuration files :-) you have no idea what people tries to do with them..

Creative admins can do a lot nice things everywhere they meet shell interpreted files. A lot more than setting static env vars.

...

after working for now around 5 years on this, I now consider them a bad thing(tm) most of that stuff should be in the respective daemon/service upstream configuration file.

Those btw.. are supported by systemd via the EnvironmentFile variable.

Are these files interpreted by shell. If yes which one is used?

cu, Rudi

Indeed. I have many config files with dynamic shell logic in them that makes things "just work" without having to hand-edit the file on different systems or after every software update. It makes them not merely more convenient but more reliable, more likely to work even if neglected or managed by unknowing monkey-admins, more robust all around, scale times NNN machines... "all such logic should be in the actual service" haha ignorant, no need to worry abut their opinion in this topic any more. Does systemd necessarily prevent this? I would doubt it but other than sysv I've only used upstart not systemd yet, and upstart did not prevent this. Worst possible case you might just need another layer of wrapper script right? Not the end of the world, but I can't believe it's actually necessary anyways. -- bkw -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Tuesday 22 November 2011, Stefan Seyfried wrote:

Did you ever try to create a systemd service file and compare the amount of work with what you need to do to create a *properly working* init script?

Even if I would have a runnning systemd somewhere I would choose the init script interface to be more portable between my machines. Writing init scripts is usually not more than copying a skeleton and mixing it with some lines from my bash_history. Testing the script can be done as non-root and regardless what init system is installed or runnning. cu, Rudi -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Monday 21 November 2011, Andreas Jaeger wrote:

The change to make /var/run as tmpfs was discussed on the packaging mailing list: http://lists.opensuse.org/opensuse-packaging/2010-05/msg00018.html

Thanks, that's what I was looking for. Specially I wanted to review potential other discussions about (IMO bad) ideas like merging /tmp and /var/tmp or using tmpfs for /tmp too. As expected I've found something about this there and looks like it ended good.

Please keep in mind that systemd is also an effort to bring the distributions together in some more areas to make packaging easier,

Generally I support this but not at the price of having more and more dependencies from single packages and having simple things like mounting /run non-changeable hardcoded into systemd. IMO it's a design desaster. Why you can't deinstall systemd anymore even though you are not using it? I know why. It's a desaster. cu, Rudi -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Monday 21 November 2011, Andreas Jaeger wrote:

On 11/21/2011 04:25 PM, Ruediger Meier wrote:

...

Why you can't deinstall systemd anymore even though you are not using it? I know why. It's a desaster.

That's your point of view. ;)

It's a disaster to support long-term two separate init-systems the same way. As long as we need SysV init as fallback, I'm fine with having it but let's not overdo it and keep it for ever ;)

Hehe, I'm not worry about it. Don't expect systemd beeing stable next years. Poettering will start the next thing before finishing systemd (like ConsoleKit, pulseaudio ...).

It's far easier to use even on SysV init boot case some of the systemd tools then reimplementing them again to have two systems that behave in a similar way.

If systemd would ever behave similar to sysvinit then even I had no problem to use it. :) cu, Rudi -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Monday 21 November 2011, Cristian Rodríguez wrote:

On 21/11/11 12:50, Ruediger Meier wrote:

...

Hehe, I'm not worry about it. Don't expect systemd beeing stable next years. Poettering will start the next thing before finishing systemd (like ConsoleKit, pulseaudio ...).

There is no such thing as finished software, ever,

My definition of finsished is "no more features needed, no critical open bugs". Of course bugs will always appear and need to be fixed. There is a lot existing "finished" software for example sysvinit, coreutils, postfix, atd, xinitd ... (just some random examples) Complex things like systemd will never get finished that's true. At least the current state of systemd doesn't deserves PID 1. cu, Rudi -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Monday, 2011-11-21 at 15:16 -0300, Cristian Rodríguez wrote:

...

So Lennart Poettering just _decided_ _finally_ at Wed, 30 Mar 2011 that openSUSE gets /run? Can't believe it.

No, sensible proposals are reviewed and adopted when they make sense, plz let focus in the technical merits of ideas rather than individuals.

I have no problems with /run and all that - after it was explained. The problem is that there was no mention of it in the release notes. Surprises of this order are not very nice. - -- Cheers, Carlos E. R. (from 11.4 x86_64 "Celadon" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) iEYEARECAAYFAk7K0YEACgkQtTMYHG2NR9WW1ACfVEQ9KlE+AYIcZrePsds4/M78 J7kAn0Wj5pzHpjs8R3DS7ayaDEC0bd7Y =2QIe -----END PGP SIGNATURE-----

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Content-ID: <alpine.LNX.2.00.1111220151150.6471@Telcontar.valinor> On Monday, 2011-11-21 at 23:48 +0100, Lars Müller wrote:

On Mon, Nov 21, 2011 at 11:32:33PM +0100, Carlos E. R. wrote: [ 8< ]

...

I have no problems with /run and all that - after it was explained. The problem is that there was no mention of it in the release notes.

Surprises of this order are not very nice.

Now it's no longer a surprise. And you know all the details. File a bug report to the release notes component including pointers to this thread in the mail archive and Karl will add and polish your input and it gets included to the next release notes update, please.

Done!

And again this is no longer about openSUSE Factory. Please shift the discussion to the general openSUSE list. Move along, nothing to see here. ;)

There we would still be asking questions and nobody answering, because the people that have made 12.1 are here, not there. Unfortunately. And this time it wasn't me who started the two threads about this. - -- Cheers, Carlos E. R. (from 11.4 x86_64 "Celadon" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) iEYEARECAAYFAk7K8nMACgkQtTMYHG2NR9XMMQCfU7vGuErWtONooM1DZMrKS4l3 uHEAn0SLA+ssSHqD5puDyrkh/qTx1Ebq =MboH -----END PGP SIGNATURE-----

On Tuesday, November 22, 2011 12:36:39 AM Joachim Schrod wrote:

Ruediger Meier wrote:

...

On Monday 21 November 2011, Joachim Schrod wrote:

...

Ruediger Meier wrote:

...

On Sunday 20 November 2011, Cristian Rodríguez wrote:

...

in this case it was agreed among all major distributions.

My question was how such agreement happens in practice. I couldn't find anything about it.

It was announced upstream, see http://lwn.net/Articles/436012/

This is Fedora and/or systemd specific only. I'm not using the one nor the other and don't consider it being upstream source of openSUSE's file system layout.

1) The email in that article clearly tells that this is a coordinated move between several distributions, among them openSUSE. This is not specific for Fedora.

2) systemd *is* upstream, and it introduced /run. When it got selected for openSUSE, /run was selected, too.

Methinks that your real crusade is that you want to avoid systemd under any circumstances. Good luck with that; I don't think you'll succeed.

Joachim I may not be an admin per se, but systemd looks like a good thing. It is indeed a new thing though, and forces the user to read new documentation to know precisely how to do things. I feel like a lot of the more technical users have a knee jerk reaction against systemd since it is new and radically different from the old init system. I think, before we get fussy over it we should make sure we familiarize ourselves with how to work with it and how it provides potentially powerful new functionality before protesting. Knowledge is half the battle, and once a person truly understands it then they can raise more pertinent points in protest concerning it. -- Roger Luedecke openSUSE Ambassador Ind. Repairs and Consulting **Looking for a C++ etc. mentor*** -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Tuesday, November 22, 2011 02:01:28 AM Carlos E. R. wrote:

On Monday, 2011-11-21 at 15:53 -0800, Roger Luedecke wrote:

...

I may not be an admin per se, but systemd looks like a good thing. It is indeed a new thing though, and forces the user to read new documentation to know precisely how to do things.

The openSUSE reference book documents the clasical boot system and system V extensively: an entire chapter. Alas, no mention of systemd.

And man pages aren't a nice read to learn things, very hard to read. No comparison with the SUSE docs. And they will not write the new chapter for several months.

(yes, there is a bugzilla about that, before anybody asks). On that note, I have a blog that is aggregated by the planet. I wanted to write an article on systemd. However, I frankly do not much understand it. ANd beyond that I want to show it in a positive light... the threads here have mostly been about why people think its horrible, and that wouldn't do anybody much good. So far the only thing I really understand about it is the aggressive parellelization for starting services leading ot a faster boot time. The rest is rather greek to me. ANd I have looked at some documetnation etc. but its not especially intelligible to me and doesn't give me any practical points to write about. Ideas and assistance would be appreciated. This thread will probably need to be forked for that. -- Roger Luedecke openSUSE Ambassador Ind. Repairs and Consulting **Looking for a C++ etc. mentor*** -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Tuesday, November 22, 2011 03:09:36 AM Joachim Schrod wrote:

Roger Luedecke wrote:

...

On Tuesday, November 22, 2011 02:01:28 AM Carlos E. R. wrote:

...

On Monday, 2011-11-21 at 15:53 -0800, Roger Luedecke wrote:

...

I may not be an admin per se, but systemd looks like a good thing. It is indeed a new thing though, and forces the user to read new documentation to know precisely how to do things.

The openSUSE reference book documents the clasical boot system and system V extensively: an entire chapter. Alas, no mention of systemd.

And man pages aren't a nice read to learn things, very hard to read. No comparison with the SUSE docs. And they will not write the new chapter for several months.

(yes, there is a bugzilla about that, before anybody asks).

On that note, I have a blog that is aggregated by the planet. I wanted to write an article on systemd. However, I frankly do not much understand it. Lennart wrote an extensive list of blog posts about systemd, at http://0pointer.de/blog/. Among them are 11 posts about systemd from an administrator's perspective.

Do you know about them?

If not, http://0pointer.de/blog/projects/systemd.html is an initial post about what systemd is about; and http://0pointer.de/blog/projects/inetd.html has links to all other admin-related blog postings. I do not necessarily agree with all of his and Kais arguments (that satiric comparison sheet http://i.imgur.com/usftZ.png is there for a reason), but docs are there in abundance. I'd have loved to have the same level of documentation for ConsoleKit/PolicyKit, but that's another story... ;-)

Joachim I did not. And despite my name, I am not from Germany. -- Roger Luedecke openSUSE Ambassador Ind. Repairs and Consulting **Looking for a C++ etc. mentor*** -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Sunday, November 20, 2011 11:17:06 AM Rüdiger Meier wrote:

How/where exactly opensuse has made that decision? I've missed it. Open the partitioner and you should see we have the various tempfs that correspond to this scheme. -- Roger Luedecke openSUSE Ambassador Ind. Repairs and Consulting **Looking for a C++ etc. mentor*** -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On 21/11/11 09:47, Carlos E. R. wrote:

On Sunday, 2011-11-20 at 11:25 -0800, Roger Luedecke wrote:

...

On Sunday, November 20, 2011 11:17:06 AM Rüdiger Meier wrote:

...

How/where exactly opensuse has made that decision? I've missed it. Open the partitioner and you should see we have the various tempfs that correspond to this scheme.

which is very confusing.

It might be, yes, maybe opening a bug report to get this system reserved mount points hidden from the UI can be less confusing. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Monday, November 21, 2011 01:47:53 PM Carlos E. R. wrote:

On Sunday, 2011-11-20 at 11:25 -0800, Roger Luedecke wrote:

...

On Sunday, November 20, 2011 11:17:06 AM Rüdiger Meier wrote:

...

How/where exactly opensuse has made that decision? I've missed it.

Open the partitioner and you should see we have the various tempfs that correspond to this scheme.

which is very confusing. Yes, it threw me for a loop. Gave me a wee panic attack since there was no mention of this in any release notes. But, I fortunately was able to ask some questions and get answers. -- Roger Luedecke openSUSE Ambassador Ind. Repairs and Consulting **Looking for a C++ etc. mentor*** -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On 11/21/2011 08:02 PM, Sven Zallmann wrote:

Good evening folks,

While you are on the subject and this topic came up on IRC: Ubuntu 11.10 has also adopted using /run and thereby symlinked /var/run to /run and /var/tmp to /run/tmp. SUSE 12.1 seems to employ a different approach here - but which exactly?

Thanks for enlightenment.

Kind regards

Sven

devtmpfs on /dev type devtmpfs (rw,relatime,size=8201552k,nr_inodes=2050388,mode=755) tmpfs on /dev/shm type tmpfs (rw,relatime) those two are normal like before tmpfs on /sys/fs/cgroup type tmpfs (rw,nosuid,nodev,noexec,relatime,mode=755) cgroup and capabilities tmpfs on /run type tmpfs (rw,nosuid,nodev,relatime,mode=755) This one is new tmpfs on /var/lock type tmpfs (rw,nosuid,nodev,relatime,mode=755) tmpfs on /var/run type tmpfs (rw,nosuid,nodev,relatime,mode=755) those two are rebinded from /run and /run/lock tmpfs on /media type tmpfs (rw,nosuid,nodev,noexec,relatime,mode=755) this one is new two. For those who need something in it created at each boot have a look at man tmpfiles.d to learn how to do it like for example d /media/backup 0755 root root - recreate a backup directory owned by root with rwxr-xr-x rights nor /tmp or /var/tmp has been changed in the last 4 versions. hope this help -- Bruno Friedmann Ioda-Net Sàrl www.ioda-net.ch openSUSE Member & Ambassador GPG KEY : D5C9B751C4653227 irc: tigerfoot -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org