В Wed, 10 Apr 2013 23:39:38 +0200 Per Jessen пишет:

YCP isn't particularly difficult, anyone who can program will be able to pick it up.

Is there any documentation? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On Thu, Apr 11, 2013 at 10:10 AM, Per Jessen wrote:

Andrey Borzenkov wrote:

...

В Wed, 10 Apr 2013 23:39:38 +0200 Per Jessen пишет:

...

YCP isn't particularly difficult, anyone who can program will be able to pick it up.

Is there any documentation?

During the last 6-8 months, I've spent quite a bit of time looking at the yast-iscsi module(s), which is all YCP. Yes, there is documentation out there, but it can be difficult to find, google will help. There is also stuff like debugging info for YaST etc.

As you apparently already collected this information may be you consider making life easier to possible contributors by publishing these links? What about creating wiki page on opensuse.org? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

El 10/04/13 18:39, Per Jessen escribió:

YCP isn't particularly difficult, anyone who can program will be able to pick it up. It's more about a lack of developer-/community-interest in YaST.

Well, that's a moot point now, SUSE is currently working on --> https://github.com/yast/ycp-killer to get rid of YCP. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

В Thu, 11 Apr 2013 16:01:06 -0400 Anton Aylward пишет:

Oh dear!

For the first time in over a week I rebooted my workstation and had a bit of a problem.

There was a long, long delay. As in I made some coffee, came back and there was the plymouth screen still there. I rebooted in recovery mode and watched carefully, later went in to the journal.

Apr 11 10:47:09 MainBox systemd[1]: Job dev-sda1.swap/start failed with result 'dependency'. Apr 11 10:47:09 MainBox systemd[1]: Job dev-sda1.device/start failed with result 'timeout'.

I'm not sure how significant this is.

Could you run "journalctl --since=... --until=..." for a period including your full reboot which had these problems and upload e.g. to susepaste? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Cristian Rodríguez said the following on 04/10/2013 05:04 PM:

yast modules will probably be revamped/improved when converted to Ruby from YCP, that might take a while.

As there are only a handful of souls that speak the YCP language and some of them even no longer work for SUSE..yast needs such conversion in order to survive.

If anything, THAT is the bug - that the one thing which distinguished openSuse from other distributions, namely YAST, is unmaintainable! -- "That's right; the upper-case shift works fine on the screen, but they're not coming out on the damn printer... Hold? Sure, I'll hold." -- e.e. cummings last service call -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

El 10/04/13 20:23, John Andersen escribió:

On 4/10/2013 2:51 PM, Anton Aylward wrote:

This! Yast is a standout product, and when I hate to see it replaced by a bunch of CLI utilities who's name you can never remember is a shame.

Yast is not getting replaced by command line tools, how to do a particular task in the command line while Yast problems get sorted out is what is suggested here. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

El 10/04/13 18:54, Carlos E. R. escribió:

...

to start service on boot

systemctl enable yourservice

it is that simple, and works.

Aparently, some people report that it doesn't, or not for all services; I think those that do not have systemd native files fail.

Instead, they have to use:

chkconfig yourservice on

Yes, there are services where "enable" is not an option, as well ones where "disable" is also not an option.. the right instruction is "mask" in such cases. Do you know which services exactly cannot be enabled with systemctl ? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Thursday, 2013-04-11 at 00:54 +0200, Carlos E. R. wrote:

...

Do you know which services exactly cannot be enabled with systemctl ?

No, I have not bothered to remember them. I mean, I have not considered making a list, yet. The reports come often in the forums, and there is no clear conclusion.

For example this one: http://forums.opensuse.org/showthread.php?t=485284, the OP complains about "nfs or xinetd or ddclient".

A new one: http://forums.opensuse.org/showthread.php?t=485734 - -- Cheers, Carlos E. R. (from 12.1 x86_64 "Asparagus" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (GNU/Linux) iEYEARECAAYFAlFl/0oACgkQtTMYHG2NR9Um4wCfWiVJPdeCzkAlYqeLaFZJY59i iF8An3EFg9K4ti34tb0N37rNT0UDVS/Z =qSDS -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

El 10/04/13 21:06, Marc Chamberlin escribió:

I look forward to the day when a new GUI presents itself in the openSuSE world.

We are not talking about a new GUI yet ;-) just converting the existing code to language that more programmers understand or are willing to learn. THEN something new might come up, who knows.. In the meantime, don't be surprised if/when I ask "dumb"

questions on how to do something that YaST was once able to do for me. Getting openSuSE12.3 up an running has become a frustrating experience for us.

I understand, unfortunately Yast is showing up its age and keeping it current with the underlying system changes is a task that is in need of manpower at the moment. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

El 10/04/13 21:42, Carlos E. R. escribió:

Maybe manpower should be shifted from doing new features to keeping up yast instead.

Generally,people work in what they want or what they know how to do, it is not a matter of waving the magic wand and suddenly developers go in droves to learn YCP and fix YAST. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On Wednesday, April 10, 2013 06:32:18 PM Cristian Rodríguez wrote:

El 10/04/13 21:06, Marc Chamberlin escribió:

...

questions on how to do something that YaST was once able to do for me. Getting openSuSE12.3 up an running has become a frustrating experience for us.

I understand, unfortunately Yast is showing up its age and keeping it current with the underlying system changes is a task that is in need of manpower at the moment.

Showing it's age? I still remember using Yast1 and all the complaining and moaning that came about when the switch was made to Yast2. It was an interesting time. Mike -- Powered by SuSE 12.3 Kernel 3.7.10 KDE 4.10 18:42pm up 4:07, 2 users, load average: 9.00, 8.50, 8.30 -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Marc Chamberlin said the following on 04/10/2013 08:06 PM:

...

...

it is that simple, and works.

The learning curve is sometimes very steep and there are lots of "magic" commands that not everyone is familiar with.

I'd say the opposite. The big step is letting go of the old way of doing things. There's only really the one command - we've covered that. The trick is to think in terms of the dependency tree. And I mentioned the command for visualising that.

That is why having good GUI's, that act as guides to help us poor uneducated users solve such problems, is so important. IMHO! Then we wouldn't have to bother the experts with our dumb questions.

HA! All the evidence is to the contrary!

Having a sea of command line commands with a universe of options is wonderful for all the advance Linux gurus in the world, but for those of us who are learning the ropes, it is not always easy to find these golden nuggets on our own or discover/grok a new command such as systemctl....

What's this about the see? There aren't many commands; compared to tracing though wall the intricacies of shell scripts, includes, defined functions, external commands, then the systemd way of working is the joyous simplicity. If this had been thought of first we'd never have dreamt of something as awkward as sysvinit. Please disabuse yourself of this 'sea of commands' notion and please disabuse yourself of the idea that systemctl was difficult to find. Well perhaps it was since it is just the one think. Oh, right, there's a GUI version as well. Two things. And the log viewer. Three. As for finding things in the 'sea' that is /usr/bin - DON'T! I keep telling you guys out there in the suse world - use the 'apropos' command. A few times. "apropos systemd" will refer you to 30 man pages which will let you learn about the innards and operation of systemd. Does that seem a lot? Well think how many you need to read to learn about file systems - access control, the various standards, how udev works and more. In true UNIX tradition it has been broken down on the 'each thing does one thing' principle. And really, of those 30 how many are commands? systemctl (1) - Control the systemd system and service manager This is the one you need to know systemd (1) - systemd System and Service Manager You never invoke that, the init process starts it systemd-ask-password (1) - Query the user for a system password Again, you never run that; the system uses it when it needs your input systemd-cat (1) - Connect a pipeline or programs output with the journal That's the equivalent of "logger(1) for when you're writing control scripts, if ever systemd-cgls (1) - Recursively show control group contents A debugging & reporting tool Only relevant if you are using the control group mechanism (which pre-dated systemd) to divide up machine resources, for example to virtual machines or tasks. systemd-cgtop (1) - Show top control groups by their resource usage See note above. like the top(1) command but for the groups systemd-journalctl (1) - Query the systemd journal This you probably do need. The 'journal' is a 'replacement' for syslog that uses a binary format rather than plain text. This is the viewer. systemd-loginctl (1) - Control the systemd login manager Does something we should have had long ago - manage logins Try this command: systemctl help systemd-logind.service then systemctl status systemd-logind.service systemd-machine-id-setup (1) - Initialize the machine ID in /etc/machine-id systemd-notify (1) - Notify init system about start-up completion and other daemon status changes These are 'internal' to the operation systemd-nspawn (1) - Spawn a namespace container for debugging, testing and building This is a mechanism for doing the init of chroot'd subsystems Either you need to know how to use it 'cos you're setting those up, or you don't. I suspect you don't. I don't. So what about the others? The are man-5 or man-8, that is definition of file types and purposes. About as relevant as the on-disk structures involved with LVM or the various file system types and superblock layouts. Essential to the operation but ... What's more important is understanding the why and wherefore of systemd. The best way to do that, IMHO, is to read Lennart's Blog. There's a lot of it and it warrants reading over and over as your understanding grows. Don't expect to understand it all, and certainly not part XII, immediately. Heck, I'm still learning from what in systemctl(1)! Some of what parts of this thread have touched n Lennart covers in http://0pointer.de/blog/projects/three-levels-of-off.html Please note the date. Please not that its also the only useful mention of symlinking there. Its sort of 'kill with extreme prejudice' for the job. (Perhaps the systemctl command needs 'mask' option.) I'd particularly bring to your attention http://0pointer.de/blog/projects/the-biggest-myths.html <quote> Myth: systemd is difficult. This also is entire non-sense. A systemd platform is actually much simpler than traditional Linuxes because it unifies system objects and their dependencies as systemd units. The configuration file language is very simple, and redundant configuration files we got rid of. We provide uniform tools for much of the configuration of the system. The system is much less conglomerate than traditional Linuxes are. We also have pretty comprehensive documentation (all linked from the homepage) about pretty much every detail of systemd, and this not only covers admin/user-facing interfaces, but also developer APIs. systemd certainly comes with a learning curve. Everything does. However, we like to believe that it is actually simpler to understand systemd than a Shell-based boot for most people. Surprised we say that? Well, as it turns out, Shell is not a pretty language to learn, it's syntax is arcane and complex. systemd unit files are substantially easier to understand, they do not expose a programming language, but are simple and declarative by nature. That all said, if you are experienced in shell, then yes, adopting systemd will take a bit of learning. To make learning easy we tried hard to provide the maximum compatibility to previous solutions. But not only that, on many distributions you'll find that some of the traditional tools will now even tell you -- while executing what you are asking for -- how you could do it with the newer tools instead, in a possibly nicer way. Anyway, the take-away is probably that systemd is probably as simple as such a system can be, and that we try hard to make it easy to learn. But yes, if you know sysvinit then adopting systemd will require a bit learning, but quite frankly if you mastered sysvinit, then systemd should be easy for you. </quote> Personally I was glad to get rid of the mess that sysvinit had become. -- inoculatte (v): To take coffee intravenously when you are running late. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Cristian Rodríguez said the following on 04/10/2013 10:27 PM:

the date is mostly irrelevant as the systemctl *commands* are part of the "stability promise" so that instructions still hold valid,

That's true, but its not why I mentioned the date of the posting. I mentioned it because I wanted to emphasise that this information has been available for public consumption for a long time. I don't want to be though of as an unhelpful bigot who keeps yelling 'RTFM" and "Go Google". heck, I missed that reference to 'mask' when paging though the systemctl man page, so yes, despite all rumours to the contrary I'm as fallible as the rest of the people here. Perhaps I've been RTFM too long and trying to jam in some more is causing back-pressure resistance ... that, sclerosis of the eyeballs or .. what was that word beginning with "A that you mentioned, Patric? But I'm battling on, so I'm only guilty of "oh, I missed that". Its not as if that series - 'systemd for sysadmins' - is hard to find. Or maybe its that I've got a Fedora system bumming around here somewhere and systemd "just worked" there. Well they don't have Yast so I never tried using yast and went straight to systemctl so when I came to openSUSE and systemd I didn't use Yast for systemd things either. Despite that, I feel more "at home" with openSUSE than with Fedora. Lets face it, Lennart has done a good job. Over my career I've seen some ace coders, but few, very few of them, document what they do. I don't mean just the in-line comments and the basic command line options, but document their design decisions point, produce the documentation about application, produce all the support that Lennart has done. Not only is systemd more coherent than the collection of scripts that made up sysvinit (and its BSD and Solaris counterparts), its more thoroughly documented and those documents are easier to find. One reason I quoted the "Myths" part of the series was that it seems some mis-information ("myths") it seems will not die. -- Lead and inspire people. Don't try to manage and manipulate people. Inventories can be managed but people must be led. ~ Ross Perot -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Linda Walsh said the following on 04/11/2013 05:58 PM:

I would point out that the suse implementors believe it impossible to create backwards compatible systemd files to *allow* the *option* of booting from disk and have separate root and /usr file systems.

Lennart points out a number of things. First, he mentions that it's not systemd that introduced the issue of /usr being needed early on in the boot-init sequence, but that its something which has come about over the years. Second, he points out that there is an option with systemd to allow for separate / and /usr BUT ONLY IF YOU TAKE MEASURES TO GET OVER THOSE OTHER PROBLEMS THAT EXIST ANYWAY. One way he suggests is to have separate / and /usr and them modify the initrd to load both. Not something that is difficult, just something that you need to actually do.

That is trivial in sysVinit scripts. If the learning curve in systemd is not so steep, why wasn't anyone in SuSE able to figure this out before rolling 12.3?

I'd say the results speak for themselves about how easy it is to get things right in systemd.

Ah, sorry, I believe that its better to, as the proverb goes, "light a candle than curse the darkness". As far as I can see the people who have problems with systemd are the ... well "unbelievers", the people who don't want to listen, to research. The people who are again it from the get-go. They perpetuate various myths and repeat misinformation. That being said, Linda, you do have a point that the openSUSE packagers have not done a good job. I've pointed out that I had experience with systemd on Fedora before dealing with it openSuse. Because of that I never tried to use Yast to do systemd stuff. And yes, I had a system set up with / and /usr separate. I also ran openSuse 12.2 under systemd with / and /usr separate. I can't recall what I did so it was obviously not a big deal. The only reason I'm not running this 12.3 with them separate is that I'm experimenting with an all-in-one-BtrFS. The problems I'm having might be more to do with that since they seem to be disk/fs related.

NOTE: that doesn't mean the end product might not be better than what you have in sysVinit -- but things that handle alot more situations and are more comprehensive are almost always more difficult to configure in the first place.

The complexity of systemd is a lot less than that of sysvinit. Please don't confuse complexity with volume. The number of "config" files in systemd, files that specify targets and services, is quite large. This is because systemd is following the old adage that Tom Duff stated: "Each thing does one thing, only one thing and does it well". Each "config" file under /etc/systemd specifies just one activity in the dependency tree. The whole point is that the old sysvinit did not make a lot of things like dependencies explicit and could get itself into paradoxical situations. If you find systemd difficult to configure then I can see that you may be falling into a couple of traps. The first is that you're not looking at it from the POV of the dependency tree. This is understandable if you still have sysvinit convictions since sysvinit doesn't make its dependencies clear - that's because the only dependency is sequential. The only cure for this is to to let go of the sysvinit approach, flush it from your mind. The second is that you think that you need to configure everything. I've seen a few posts that imply that. This is no more true for systemd that it was for sysvinit. Its comes configured for the baseline case. You may need to customise some things. I did on one server. What you might have to do is so radically different from what you might have to do with sysvinit that there is little congruence and the tools and vision are quite different. Let me illustrate that. I converted a server from sysvinit to systemd and DNS stopped working. The server was the local server and used one of the tables at http://pgl.yoyo.org/ locally to stop adverts being visible in web pages and email. It took a long time to load. Under sysvinit the relevant script runs to completion. Under systemd the dispatcher times out; it thinks the job has hung and kills it, so the named never starts. It took me a while to figure out what was going on. Thankfully this was on a Mageia system, and they don't have a system manager anywhere as capable as Yast, so I wasn't tempted to waste time trying to solve this with Yast :-) As Lennart says: <quote src="http://www.freedesktop.org/wiki/Software/systemd/Incompatibilities"> Timeouts apply to all init script operations in systemd. While on SysV systems a hanging init script could freeze the system on systemd all init script operations are subject to a timeout of 5min. </quote> As I said, the problems people seem to have with systemd seem to come from expecting it to behave like sysvinit. It won't, it doesn't, and there for Yast as it stands cannot be used to to manage it. As I said, since I learnt systemd on systems without Yast, I don't have a problem with systemd since I don't expect to use Yast to manage it. But openSuse has always been my preferred distribution, so I'm disappointed that Yast isn't keeping up and I'd disheartened that so many people are blaming systemd for things that have nothing to do with systemd, like the /usr issue. quote src="http://freedesktop.org/wiki/Software/systemd/separate-usr-is-broken"> Most of the failures you will experience with /usr split off and not pre-mounted in the initramfs are graceful failures: they won't become directly visible, however certain features become unavailable due to these failures. Quite a number of programs these days hook themselves into the early boot process at various stages. A popular way to do this is for example via udev rules. The binaries called from these rules are sometimes located on /usr/bin, or link against libraries in /usr/lib, or use data files from /usr/share. If these rules fail udev will proceed with the next one, however later on applications will then not properly detect these udev devices or features of these devices. Here's a short, very in-comprehensive list of software we are aware of that currently are not able to provide the full set of functionality when /usr is split off and not pre-mounted at boot: udev-pci-db/udev-usb-db and all rules depending on this (using the PCI/USB database in /usr/share), PulseAudio, NetworkManager, ModemManager, udisks, libatasmart, usb_modeswitch, gnome-color-manager, usbmuxd, ALSA, D-Bus, CUPS, Plymouth, LVM, hplip, multipath, Argyll, VMWare, the locale logic of most programs and a lot of other stuff. </quote> Perhaps you recognise some of those from ussies that have come up on this list? -- Rock journalism is people who can't write interviewing people who can't talk for people who can't read. Frank Zappa, quoted in Linda Botts, "Loose Talk" (1980) -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Greg Freemyer said the following on 04/11/2013 09:00 PM:

On Thu, Apr 11, 2013 at 8:13 PM, Anton Aylward wrote:

...

I also ran openSuse 12.2 under systemd with / and /usr separate. I can't recall what I did so it was obviously not a big deal.

Anton,

That's because you didn't have to do anything. opensuse packagers update the initrd package to mount /usr prior to turning control over to the following boot sequence. Once that was in place, the packagers have assumed that /usr will be mounted prior to any systemd stuff running, so they have been moving binaries during boot off of / and to /usr.

A, you mean this http://lizards.opensuse.org/2011/08/03/mounting-usr-in-the-initrd/

Linda on the other hand apparently has her servers setup not to use initrd at all.

I recall one of Lennart's articles discusses using systemd without initrd.

Thus a configuration she has used for years is no longer supported. I don't know if systemd was involved in the decision for opensuse with split / and /usr to require initrd.

Apparently not. It may have been the 'last straw....' but the motivation was there and as has been pointed out elsewhere, many other non-Linux systems had already been though both that and the bin-merge. -- If you can read this, my cloaking device is on the blink. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Cristian Rodríguez said the following on 04/11/2013 10:16 PM:

El 11/04/13 22:38, Anton Aylward escribió:

...

I recall one of Lennart's articles discusses using systemd without initrd.

An initrd has always been required, it happends that now (and certainly in the future) systems without initrds will fail to boot.

Several critical parts of the startup sequence will be driven by systemd from the initrd in future openSUSE incarnations.

Please see item #2 at http://freedesktop.org/wiki/Software/systemd/Optimizations <quote> Consider bypassing the initrd, if you use one. On Fedora, make sure to install the OS on a plain disk without encryption, and without LVM/RAID/... (encrypted /home is fine) when doing this. Then, simply edit grub.conf and remove the initrd from your configuration, and change the root= kernel command line parameter so that it uses kernel device names instead of UUIDs, i.e. "root=sda5" or what is appropriate for your system. Also specify the root FS type with "rootfstype=ext4" (or as appropriate). Note that using kernel devices names is not really that nice if you have multiple hard disks, but if you are doing this for a laptop (i.e. with a single hdd), this should be fine. Note that you shouldn't need to rebuild your kernel in order to bypass the initrd. Distribution kernels (at least Fedora's) work fine with and without initrd, and systemd supports both ways to be started. </quote> He's using Fedora, but I can't see why this should not work with openSuse. Perhaps I'll try it. -- Ideology, politics and journalism, which luxuriate in failure, are impotent in the face of hope and joy. -- P. J. O'Rourke -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Cristian Rodríguez wrote:

El 11/04/13 22:38, Anton Aylward escribió:

...

I recall one of Lennart's articles discusses using systemd without initrd.

An initrd has always been required, it happends that now (and certainly in the future) systems without initrds will fail to boot.

Several critical parts of the startup sequence will be driven by systemd from the initrd in future openSUSE incarnations.

So systemd will be on initrd? What critical parts? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Linda Walsh said the following on 04/11/2013 09:59 PM:

Greg Freemyer wrote:

...

Linda on the other hand apparently has her servers setup not to use initrd at all. Thus a configuration she has used for years is no longer supported.

---

The reason it is no longer supported is that they didn't know how to do it with systemd.

Not so. Linda, I've just replied to Cristian on this pointing out item #2 http://freedesktop.org/wiki/Software/systemd/Optimizations -- Agnosticism simply means that a man shall not say he knows or believes that for which he has no grounds for professing to believe. Thomas H. Huxley -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Linda Walsh said the following on 04/11/2013 09:59 PM:

why? PATH not working?

Well, on the one hand: <quote src="man page for execcv"> Special semantics for execlp() and execvp() The execlp(), execvp(), and execvpe() functions duplicate the actions of the shell in searching for an executable file if the specified filename does not contain a slash (/) character. The file is sought in the colon-separated list of directory pathnames specified in the PATH environment variable. </quote> and on the other there is the execve(2) system call that does not have the wrapper that the above form and needs an absolute path name. The question is "how minimalist do you want to be?" Where do you think the "p" variants live - what library? In fact what dynamic library? You're a person that has stripped things down on your system. What do you think the the smallest "init" or init-replacement could be with the least other stuff running, that is without having to start up the shell and all the stuff that drags in? -- If you need to be told what your values are the implication is that you don't hold them right now. If you hold your values strongly enough, you don't need to print them out and stick them on a wall. If everyone shares them, they don't need to read them off a wall, either. -- Marcus J. Ranum -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Linda Walsh said the following on 04/11/2013 09:59 PM:

Putting all of usr on /rootfs nearly does the same thing, as the reason for a small root was to have less on it needing updating.

You are so missing the point. -- Five exclamation marks, the sure sign of an insane mind. -- Terry Pratchett _Reaper Man_ -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Linda Walsh said the following on 04/12/2013 09:54 PM:

Anton Aylward wrote:

...

Linda Walsh said the following on 04/11/2013 09:59 PM:

...

Putting all of usr on /rootfs nearly does the same thing, as the reason for a small root was to have less on it needing updating.

You are so missing the point.

---

Yes, I am. Could you tell me the point?

Because you can still have separate / and /usr without the problems you raise. I'm really baffled as to why you and others don't drill down and read the back-story and admin notes and guides that surround the systemd project.

To me it creates a more unstable system, more prone to failure and more difficult to restore to running condition.

How so? You say that but don't say how that is so.

This means more downtime and lower reliability overall. That's my point. So why do we want that?

The only way I can see that you'd zap a / and not /usr of they were separate is - BTDT - finger trouble. Else your whole disk dies. Recovery modes reflect failure modes. Right now, I'm running 12.3 on a old (so old the surface ought to be flaking off the platters) 20G drive. Actually a couple of them in old 800 MHz machines out of the Closet of Anxieties. On one I have, as I said, the whole system that isn't from NFS, which means that the basic / and /usr are there. Crappy SiS video. With the latest kernel its still acceptably fast. On the other everything except /boot is LVM and there is separate / and /usr. My point is that I've seen and am using both ways. The difference between thee and mee is that I'm running pretty much "out of the box". My problems, which I've described here in the past, are (a) from the hardware, which is old and crappy, and (b) from idiosyncrasies of the setup - that is they are my doing and not the shortcomings of the system, but problems because I went ahead and did stuff without thinking how it would impact the system. But look: I can put the whole system except for /home and all the custom stuff that might be under /srv for the web services on a 20G drive. Lets see, just a mo while I copy back /usr/share ... and do a bit with the basic /home $ df -h Filesystem Size Used Avail Use% Mounted on rootfs 18G 8.6G 7.8G 53% / devtmpfs 1.2G 36K 1.2G 1% /dev tmpfs 1.3G 12K 1.3G 1% /dev/shm tmpfs 1.3G 440K 1.3G 1% /run tmpfs 1.3G 0 1.3G 0% /sys/fs/cgroup tmpfs 1.3G 440K 1.3G 1% /var/lock tmpfs 1.3G 440K 1.3G 1% /var/run tmpfs 1.3G 0 1.3G 0% /media Of course YMMV, but that's a workstation with gimp, libreoffice and all the other stuff you'd expect on a workstation. Lots of writing tools, lots of Java based tools like UML modellers and XMIND and Freeplane in /usr/local. And its still less than 10G. That's with the unified / and /usr That's about twice the size of the UNIX V7 I ran on a PDP-11/45 back in 1982 and that didn't have networking, X11 or Java. Of course the physical disk is a fraction the size of those old "flying saucer" RK05 packs. So you're running big disks and RAID, but its still beside the point. Your argument is that you want a / that is small; I resume you mean easy to back up and restore. Who whoopee Dee! Mine fits on a USB stick That's not just my / but my / and /usr. And not even a stick I had to pay money for but one of the free give-aways I got at a trade show that the vendor puts the product docco on. What? Wait a mo. Here's the SD card from my camera, 32G, or the tiny one from my phone. Here's the USB card reader. No, to be honest, at one point that 20G disk was nearly full, even without /usr/share on it, because I was running 'snapshot' to take images from whenever I ran zypper or altered the config. Snapshot is a great proof against finger trouble (see above) but not a lot of use against your drive dying (see above). Its actually pretty smart about only appearing to eat disk space :-) So, I think you *ARE* missing the point. I don't see any more instability with my 12.3 systems and systemd, the one running separate / and /usr or the unified one, that an do with my 11.4 laptop. When I "zypper up" it updates what it updates and which FS or mounted FS doesn't bother it. The system core and 'essential' applications & libraries are pretty small so backup isn't an issue if you're worried about a disk failure. The Snapshot system is recommended if you fear finger trouble. But what it comes down to, Linda, is that if you've hacked your system about as much as you keep telling us, directly or by implication, then what you say is wrong with the 'out of the box' openSuse (or Fedora or Mageia) that the rest of us are running is pretty much irrelevant because its so far removed from what you're experiencing with your system, and the problems you go on about, which I'm not saying aren't factual for you, arise from the difference between your much modified system and the more vanilla system the rest of us live with. That's the point I think you're missing. All this stuff that your saying is so dreadful seems to work fine for me, even on my crappy hardware from the Closet of Anxieties. Have I had problems? Well yes, but I find that they have, as I said been due to either crappy hardware[1] or my own lack of understanding. Reading and research and thought will cure the former; repeated visits to the Closet of Anxieties or expenditure of hard earned lucre (or bumming someone else's equipment) can address the former. But that's me. The problems some other people face can't be fixed, not even by going back to older distributions. They aren't technical problems. [1] Here's this DVD drive that will read and write just fine but you can't use if for booting. I _think_ its a cable problem. -- "Excellence is not a destination; it is a continuous journey that never ends." -- Brian Tracy -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Carlos E. R. said the following on 04/14/2013 08:56 PM:

On Friday, 2013-04-12 at 22:58 -0400, Anton Aylward wrote:

...

...

And its still less than 10G.

...

That's with the unified / and /usr

My /usr alone has 18 GB. And it is small at the time.

You obviously have more installed. /usr/lib and /usr/share fill up PDQ as you add packages. One of the developers has a /usr around that size 'cos of all the libraries, development tools, debug tools etc. The share code lives there, the CVS/GIT database lives there. My personal setup is just writing - as in text, as in documentation & reports and test suites/specifications and proposals. -- "How well we communicate is determined not by how well we say things but by how well we are understood." -- Andrew S. Grove. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Linda Walsh said the following on 04/11/2013 09:59 PM:

Also, it's not just about / and /usr, but also /usr/share --- at least a few current booting progs make use of it,

Would you care to be more specific - tell us exactly what those are and where they occur in the boot sequence, please.

and the same arguments used for /usr can be used for /usr/share (where do you load your fonts from?)

I happily have my /usr/share as a NFS supplied by a 'headless server'. Of course your mileage may vary; you may have your fonts supplied by the font server - xfs. The point being that this is not needed until the X server starts up. You may term that part of the boot sequence, but its not part of what the initrd does for the rest of us. It, like the DNS server; like Postfix; like the cron, ssh, and cups daemons, are all user space and all come later. If you mean the fonts for grub and what scrolls before init runs the rc files or systemd runs, then of course that won't be on /usr/share! Perhaps you need to qualify what fonts you are talking about and when they are being accessed.

My /usr/share is a 3rd partition that is located on a 4th, /home, which requires lvm & udev...

On my (headless) server everything except /boot is on lvm. On this workstation everything, including /boot, is on the single, all encompasing - well everty8tg except the stuff under /home and /usr/share and those ramfs - BtrFS. -- When languishing for solutions, don't ask "Have I got the correct answer?" The correct question is "Have I got the correct question?" -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Linda Walsh said the following on 04/12/2013 10:19 PM:

Anton Aylward wrote:

...

Linda Walsh said the following on 04/11/2013 09:59 PM:

...

Also, it's not just about / and /usr, but also /usr/share --- at least a few current booting progs make use of it,

Would you care to be more specific - tell us exactly what those are and where they occur in the boot sequence, please.

---

They are in areas that were used as reasons to move files from '/' to '/usr/... what I would mostly call 'services'...

Again that's a bit vague. Can you be specific. I can't see any services that move files that way. Services like DNS, Apache aren't part of the boot. Are you talking about what are symlinks between /bin and /usr/bin? I suppose that gets back to your question about PATH. Personally I think you're asking the question the wrong way round. I think you need to ask "what binaries are needed by the shell to get the system booted". Of course that means different things to different people. Some people think 'booted' means "all the way to the graphical login prompt". I don't. I think it means "to a state where it can begin to execute and run programs in user space". If we look at it like that, then being able to run the shell, being able to run all those goodies in /usr/bin, isn't part of booting. The whole point of the initrd is that it should contain all that is needed to boot, all the binaries and libraries, before they become available in the file system hierarchy. And that's where we differ; I boot from initrd. If you don't then this whole thread of discussion is pointless since the implicit assumptions are so fundamentally different. Perhaps it dates me, but I recall the fuss when what we now call the sysvinit approach was introduced; when /home was introduced and when /usr was used for things other than users home directories. Why did we do that separation in the first lace? Basically, / was getting overloaded. In the old V7 days directories go searched linearly and there was no name caching. Big directories were a problem. Splitting /bin and /lib and offloading some stuff to /usr/bin and /usr/lib meant for smaller directories and hence faster operation. What was it with linear searches? O(N)? Now we have binary indexing it doesn't matter. One thing many of us don't face is a Read Only Root. We have living systems, adding and removing users and the like, altering configuration. But in an embedded system we want the 'system' to be fixed, probably on flash memory. Having a unified / and /usr makes that a lot easier.

...

...

and the same arguments used for /usr can be used for /usr/share (where do you load your fonts from?)

I happily have my /usr/share as a NFS supplied by a 'headless server'. Of course your mileage may vary; you may have your fonts supplied by the font server - xfs.

---

That's disabled in some recent X due to some security bug or another.

That was back in 2007.

It is assumed all fonts are local.

What? It assumed all the fonts were local to the machine XFS was running on, not local to the machine that X was running on. You only needed the one font server for your network.

I've been struggling to keep xfs-font server available. I've been told by suse that it's outdated and should be dropped.

Who told you that? Yes its a heavy process and it makes no sense for most people who are running Linux as a windows desktop replacement and have just that machine. Simple to have the X server access the files locally. But again you've missed my point. You were going on about fonts being needed for boot. I'm saying that's not so; that they can be supplied by a NFS mount or by a font server. the issue is CAN BE. The issue is that this is nt necessary for boot. It is only necessary for running X, and X is a graphical mode user space application. Its optional. You can boot without it.

...

The point being that this is not needed until the X server starts up.

---

But having "X" available @ boot, was used to support the argument that /usr files needed to be on "/", so that booting to a full desktop could be parallelized.

Where did you get from 'parallelised' to that being an argument for /usr files on / ?? That seems a non sequitor. We're back to you playing around with the definition of 'boot'. You seem to be saying that a machine isn't booted until the graphical login is presented on the screen. I think that's not so. If it were the headless server under my desk that does DNS, my local web server, some dhcp stuff and more "never boots".

...

You may term that part of the boot sequence, but its not part of what the initrd does for the rest of us.

---

That's the flip side of my point. The stuff in initrd is stuff that isn't able to be done in systemd and needs to be done before systemd launches. My question was why does the stuff that is done in initrd have to live in /usr? It was on root, why not leave it on root?

See above. Once upon a time all the stuff you thin of as being in /usr WAS in /. The reasons for moving it to /usr are no longer valid.

It was systemd that needed things on /usr,

That's a bit of an over simplification and over generalization. I can write a target that needs /srv in order to start up Apache with Tomcat and a web enabled application, but that doesn't mean systemd needs things on /srv. In fact you've got it backwards. Given that / and /usr are the same file system it doesn't matter where some stuff is so long as its where its expected to be. That is what the symlinks you're complaining about are for. Some stuff really really really lives in /usr/bin so the links from /bin to there are for the stuff that isn't smart, that just does an exec for whatever reason. Yes there are people who code 'exec' rather than than 'execlpv'. Yes there are people who want light-weight chunks of code so try not to use certain libraries or dynamic linking. They are trying to be "optimal" for various values of 'optimal'. Just as you are with the way you've modified your system ...

But now initrd needs things on /usr -- or rather the things that initrd does needs things on /usr -- but that isn't "systemd", right?

No, initrd doesn't need. Its all a matter of how initrd is configured whether it HAS or doesn't HAVE various things that it needs to do things that are asked of it. If it is asked to mount /usr since /usr is a separate FS before proceeding then it need to have that capability. Heck, of you wanted you could include any or all of /usr/bin and /usr/lib in initrd. Its easy to do. I know, I did it once by mistake!

It, like the DNS server; like

...

Postfix; like the cron, ssh, and cups daemons, are all user space and all come later.

---

Agreed... This was the traditional model.

What I want to know is why has 'S' and '1' equivalent functional run levels been crippled to need booting from a ram disk when in other distros (RH/Fedora, at least), this is not the case?

Why does my my GM car have 5 nuts/lugs to hold each wheel on whereas my father's old Ford (and it seems the Fords of today) have only 4? Was it just that old man Ford back in the opening years of the 20th century was a cheapskate? Are the Fords less safe or are the GMs over-engineered? Why do different car manufactures use screws and bolts of different threads? BS, Whitworth, metric? Design decisions, opinions of engineers, product differentiations ...

If you accept that services are separate from boot, that there is no compelling reason why the boot-related files cannot remain (be moved back) to /root and create a compatible boot case...(like booting from HD).

This is what I mean when I say you're missing the point. If / and /usr (please! /root is the home directory of the user that logs in under the id 'root'; its the only home directory no on /home) are the same FS then the boot realted files are on the same FS as /. They aren't on the same FS as /boot - that's interesting. You need to read the above and think hard why we had a separate /usr in the first place and why it was eventually put on a separate file system. Logically we can split things up further. On one machine thetI have control over I decreed that no file system could contain more that 5G so they could be backed up to DVD. That meant on one developer's machine we had to put /usr/lib/perl5 on a separate FS. We could, logically, put /bin and /lib on their own file systems, along with /usr/bin and /usr/lib. The we'd have the argument about moving them each back to where we have had them on one FS. Because that's the argument you're having. I repeat, once upon a time there was only /bin and /lib - no /usr/bin or /usr/lib. Splitting them was a performance modification. All we're doing is going back to where we had it. Well Ok, not quite absolutely. We still have /sbin, but that's another story, another piece of optimization that led to something different. -- Those who wish to seek out the cause of miracles, and to understand the things of nature as philosophers, and not to stare at them in astonishment like fools, are soon considered heretical and impious,and proclaimed as such by those whom the mob adores as the interpreters of nature and the gods. For these men know that once ignorance is put aside that wonderment would be taken away which is the only means by which their authority is preserved. --Spinoza -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Linda Walsh said the following on 04/13/2013 10:39 AM:

Anton Aylward wrote:

...

Linda Walsh said the following on 04/12/2013 10:19 PM:

Linda, please DO NOT reply to both me and the list. I do read the list :-) Thanks. -- The only freedom which deserves the name, is that of pursuing our own good in our own way, so long as we do not attempt to deprive others of theirs, or impede their efforts to obtain it. --John Stuart Mill (On Liberty, 1859) -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

* Linda Walsh [04-13-13 18:43]:

I don't add your name. Your email headers say that to respond to "all", it needs to send a copy to both you and the list. The email software doesn't know that you are on the list. You do (or the list does). At both places where this knowledge is available (i.e. in your email client) and in the list software), their is an option to sent the "Reply-To:" field in the email.

Linda, *you* are full of crap! How the hell would one participate on the list w/o getting the list mail, and/or why would they?

This list doesn't set any intelligent (and seemingly wanted) defaults for email to the list and puts the onus on the users. But that requires users change their email software to automatically put a Reply-To field in when responding to this specific list.

The *lack* of intelligence is not in the mail list software! Mail list software mudging headers, especially "Reply-To:", is considered *wrong*. *You* are expected to reply to the list unless specifically requested otherwise. *You* are free to add "Reply-To:" headers to the mail you generate.

Depending on your list software, this can be done in multiple ways.

And definitely should *not*!

You, like me, have a domain, and appear to setup "per-list" or "per-company" addresses to aid in sorting incoming email -- something I've done for 13 years. People used to think that was odd, but now is becoming common-place enough that I almost never get questioned about it.

Anyway -- with 2 different addresses in the from headers, it has been standard to use Reply to *only* go to the person, or Reply-All to go to the person and everyone in CC list -- this is because my email software doesn't know if you are on the list or not -- some people on this list have set the "Reply-To:" field to point only at the list. That automatically tells client-email software the *default* reply-to address.

that to respond to all, it needed to reply to both. You can set your email software to put SuSE Linux

The mail client you posted has the capability to post-to-list, but .... much verbosity about the sky falling deleted.....! -- (paka)Patrick Shanahan Plainfield, Indiana, USA HOG # US1244711 http://wahoo.no-ip.org Photo Album: http://wahoo.no-ip.org/gallery2 http://en.opensuse.org openSUSE Community Member 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

Different e-mail lists are set up differently. I am on one list where the default is reply to sender but the list requires reply to list. It is absolutely stupid but that's how it is. One list I'm on has a requirement to have your ham call sign in your signature [ all those dots and dashes down there are me complying with the requirement ]. The thing is, just do what is necessary to comply with however the majority of the list people want it done and get along. I do agree that everyone should use an up to date mail client. I've been using Thunderbird since the first public release. I'm now up to version 17. This is the best it's ever been. -- “Only two things are infinite, the universe and human stupidity, and I’m not sure about the former.” -Albert Einstein _ _... ..._ _ _._ ._ ..... ._.. ... .._ -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 2013-04-14 07:26 (GMT-0400) Anton Aylward composed:

...running under a systemd driven openSuse 12.2 on a BtrFS file system on a crappy little 800MHz machine out of the Closet of Anxieties that is running at a mere 800Mhz with a stinking little 1Meg of memory ..

Velly intellestink, considering current openSUSE kernels are about five times your RAM size. :-) My first machine owned, a 386DX-25, had 8Meg for running DesqView on DOS both before and after that M$ v3.0 abomination was released. Even my 733MHz i810 system running 12.3 has 384M, including that allocated to its pathetic video. It's amazing how the same people can repeatedly type so much about a subject involving occasional extra DEL strokes or clicks, or insist an RFC is correct and that munging headers would be unjustifiable heresy even though the mail comes to me from the listserv and not its subscribing authors. When you subscribe to a magazine, it doesn't come from its collective authors and advertisers individually. It comes from a publisher. With mailing lists the listserv is the publisher. We get opensuse list mail from an openSUSE publisher, which collects articles for distribution from its subscribers. Any normal person who knows or has heard nothing about any RFC expects _reply_ to go back to the sender/publisher that the email came to him from, the listserv, not individual article authors, who sent their compositions to the listserv and not each individual subscriber. So if you don't like that people send you an extra copy, and insist counter-intuitive RFC conformance be locked in place for eternity, don't be bitching about extra copies. They will not cease before RFC conformance insanity is discarded in favor of munging. Whether through antiquated email client, ignorance, laziness and/or intent, they will continue, so deal with it personally, not by contributing to these recurring, pointless OT threads. -- "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

Linda Walsh said the following on 04/13/2013 06:39 PM:

Anton Aylward wrote:

...

...

Linda Walsh said the following on 04/13/2013 10:39 AM:

...

...

Anton Aylward wrote:

...

> Linda Walsh said the following on 04/12/2013 10:19 PM:

Linda, please DO NOT reply to both me and the list. I do read the list :-)

Thanks.

---

I don't add your name. Your email headers say that to respond to "all", it needs to send a copy to both you and the list. The email software doesn't know that you are on the list. You do (or the list does). At both places where this knowledge is available (i.e. in your email client) and in the list software), their is an option to sent the "Reply-To:" field in the email.

That's a weak and ridiculous argument, Linda. If it were so then every last message of mine you're replied to, or that anyone else had relied to, would have had duplicates. That hasn't been happening. -- Last night I played a blank tape at full blast. The mime next door went nuts! -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 04/13/2013 06:39 PM, Linda Walsh pecked at the keyboard and wrote:

Anton Aylward wrote:

...

Linda Walsh said the following on 04/13/2013 10:39 AM:

...

Anton Aylward wrote:

...

Linda Walsh said the following on 04/12/2013 10:19 PM:

Linda, please DO NOT reply to both me and the list. I do read the list :-)

Thanks.

---

I don't add your name. Your email headers say that to respond to "all", it needs to send a copy to both you and the list. The email software doesn't know that you are on the list. You do (or the list does). At both places where this knowledge is available (i.e. in your email client) and in the list software), their is an option to sent the "Reply-To:" field in the email.

This list doesn't set any intelligent (and seemingly wanted) defaults for email to the list and puts the onus on the users. But that requires users change their email software to automatically put a Reply-To field in when responding to this specific list.

Depending on your list software, this can be done in multiple ways.

You, like me, have a domain, and appear to setup "per-list" or "per-company" addresses to aid in sorting incoming email -- something I've done for 13 years. People used to think that was odd, but now is becoming common-place enough that I almost never get questioned about it.

Anyway -- with 2 different addresses in the from headers, it has been standard to use Reply to *only* go to the person, or Reply-All to go to the person and everyone in CC list -- this is because my email software doesn't know if you are on the list or not -- some people on this list have set the "Reply-To:" field to point only at the list. That automatically tells client-email software the *default* reply-to address.

that to respond to all, it needed to reply to both. You can set your email software to put SuSE Linux

in the "Reply-To:" field -- it's another field just like To, Cc: and their newgroup counterparts Newsgroup: and Followup-To: that can be set on a per-list basis in most email software. See http://img545.imageshack.us/img545/1962/foldersettings1.jpg for an example of this in firefox.

The Reply-To field takes precedence over the 'From' field when looking for who to send responses to. So when I hit reply it goes to the list-only. If I hit reply-All, the email software sees still sees the 'reply-to' and 'cc' are the same address, and only sends 1 copy. To send a copy to you and the list, I would have to type in your email address manually, which I have to want to do *intentionally*.

Since you have control over where responses go, I ask that you use that control and stop asking others to NOT do as your emailer is telling them to.

If you change everyone else to not follow the standards then you break features for other people.

Example: If you send email to the list AND to the person, one email may go into their "list folder" (that, by itself, gives no hint that the email was sent "in response" to something they wrote). Vs. if it is a response to something they said, it would be polite if there was a way to let them know that someone replied, directly, to something they wrote.

That's why it allows for 2 copies -- the one copy goes to a list folder, but the one sent to them directly, goes directly to them and, filtered appropriately, goes into a "direct" or "personal" response folder.

That folder is *generally* read before list email, as it is obvious the person said something directly to the poster in response to one of their posts (vs. a general list email that isn't a direct response).

So please -- if you only want the 1 copy, set your email software to put in 'Reply-To:' <listemail> and any standards-following email client will automatically ONLY put in the list address when they 'hit' reply OR reply to all -- i.e. they will have to type your address in manually for you to get a 2nd, unwanted copy -- and how likely is that? :-)

BULL SHIT Linda. Use the fracken "Reply List" button that Thunderbird offers you. YOU have been on this list long enough to know the list preferences, use them. -- Ken Schneider SuSe since Version 5.2, June 1998 -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On Saturday, April 13, 2013 07:11:06 PM Linda Walsh wrote:

=== Bull poop yourself Ken!. I don't have such a button -- read the standards (the ones I quoted in my followup... ignore the Reply-To nonsense.. I was wrong). But the 2 copies -- is a reader-issue, not a sender issue -- sender is supposed to send 2 copies on reply 2 all or it can cause lost email.

http://woozle.org/~neale/papers/reply-to-still-harmful.html

Getting two copies of the same email ------------------------------------

* Some people complain that they'll get two copies of the same email. Since they're on the list, their first copy is the one sent to them by the list. When the responder hit "reply all", it also put their email address in the recipient list, so they get a second copy directly.

Fortunately, there's already a technical solution to this. Since all mail clients put a unique Message-ID header field on their email, a mail reader has only to compare the Message-ID of a message to previously-recieved messages. *** If it's the same, then the second message is a duplicate and can be safely ignored. **

* If your mail reader doesn't do this, that's too bad, but it's not an * excuse to violate Internet standards and surprise people with * inconsistent behavior, just to prevent you from having to delete * a few emails. Anyone who gets any spam at all knows how to delete * email.

I am so tired of your pissing and moaing. Go find a distro that works for you and quit bitching about this one. If you don't like it go elsewhere. Don't bother answering. You've hit the bitbucket. -- Powered by SuSE 12.3 Kernel 3.7.10 KDE 4.10 20:04pm up 5:33, 2 users, load average: 8.11, 8.19, 8.27 -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Ken Schneider - openSUSE wrote:

On 04/13/2013 09:11 PM, Linda Walsh pecked at the keyboard and wrote:

...

Ken Schneider - openSUSE wrote:

...

BULL SHIT Linda. Use the fracken "Reply List" button that Thunderbird offers you. YOU have been on this list long enough to know the list preferences, use them. === Bull poop yourself Ken!. I don't have such a button -- read the standards (the ones I quoted in my followup... ignore the Reply-To nonsense.. I was wrong). But the 2 copies -- is a reader-issue, not a sender issue -- sender is supposed to send 2 copies on reply 2 all or it can cause lost email.

http://woozle.org/~neale/papers/reply-to-still-harmful.html

Getting two copies of the same email ------------------------------------

Because you are to fucking lazy to delete one, period!

Exactly... That's what the standards say: Some people complain that they'll get two copies of the same email. Fortunately, there's already a technical solution to this. Since all mail clients put a unique Message-ID header field on their email, a mail reader has only to compare the Message-ID of a message to previously-recieved messages. If it's the same, then the second message is a duplicate and can be safely ignored. If your mail reader doesn't do this, that's too bad, but it's not an excuse to violate Internet standard and surprise people with inconsistent behavior, just to prevent you from having to delete a few emails.Anyone who gets any spam at all knows how to delete email. I'm not so lazy I can't deal with the rules -- I wrote programs to deal with duplicate copies based on whatever rules I want. It seems you are the lazy one who can't be bothered to write a filter to drop duplicate messages. If any given user DOESN'T want to recieve two copies, then they can put reply-to in the metainfo for that folder. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Billie Walsh said the following on 04/14/2013 07:24 AM:

On 04/14/2013 02:14 AM, Linda Walsh wrote:

...

I'm not so lazy I can't deal with the rules -- I wrote programs to deal with duplicate copies based on whatever rules I want. It seems you are the lazy one who can't be bothered to write a filter to drop duplicate messages.

If any given user DOESN'T want to recieve two copies, then they can put reply-to in the metainfo for that folder.

Oh come on! You may be some kind of a geek but do you REALLY expect everyone to be one. No offense meant to those that aren't but..........................

Lets face it, the average home computer user is barely able to turn it on, get their e-mail and surf the web. They don't even know what an e-mail header is let alone how to read one properly. They've never seen the complete header and don't know how to find it. AND, you expect them to make filters to delete a duplicate.................................

You are quire right, Billie, but that's beside the point. Linda is being deliberately antagonistic. And she is being deliberately inconsistent. As I pointed out, her previous replies to me were not duplicates. If we go back to Message-ID: <5168BAC8.2070107@tlinx.org> Date: Fri, 12 Apr 2013 18:54:16 -0700 From: Linda Walsh User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.8.1.24) Gecko/20100228 Lightning/0.9 Thunderbird/2.0.0.24 then Linda did it "properly". For all her bluster and justification, for all her saying she is right and we are wrong, the fact is that she DOES know and is CAPABLE of posting to the list correctly, without duplication, because she has done so in the past. There is no need for us to implement filters. Well, OK, some of us have, by now, implemented more aggressive filters, but that's another matter. -- Opportunities multiply as they are seized. --Sun Tzu -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Linda Walsh said the following on 04/14/2013 03:14 AM:

Ken Schneider - openSUSE wrote:

...

Because you are to fucking lazy to delete one, period!

---- Exactly... That's what the standards say:

Some people complain that they'll get two copies of the same email.

No, Linda, what we're complaining about is that you are being inconsistent and you are then trying to justify your inconsistency. As I've pointed out and as I've got evidence here and as everyone else on the list you're replied to has evidence, you are quite capable of reply to the list alone without duplicates. You have, up until yesterday done that. In fact your early relies yesterday weren't duplicated. This isn't about standards, Linda, its about your behaviour and your attitude. One might speculate that we've stymied you as far as your derision of systemd goes, so now you're trolling on other matters. -- Warning: Do not attempt to stop blade with hands. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 4/14/2013 5:26 PM, Linda Walsh wrote:

Anton Aylward wrote:

...

No, Linda, what we're complaining about is that you are being inconsistent and you are then trying to justify your inconsistency.

---

SuSE is very inconsistent in the 12.x series. And you complain about me sending an extra email or not.

I'm very consistent -- when I get tired of deleting things, *manually* that I've spent time adapting to the standards and writing scripts to automate, I leave them.

I have scripts to deal with the standards. I *usually* cater to the masses that can't deal with standards.

The fact of the mater is that the Reply-To field used to be set on lists JUST to prevent this type of discussion/debate, but IANA spoke and said everyone must adapt -- if the user is in the From line and if it goes to a list -- then the standard says, to send back 2 copies.

I know people whine about it here. That doesn't mean it's right or that they shouldn't be educated.

Dealing with all the complaints, my tolerance level drops at times and I have more trouble dealing with 'extras' like deleting extra email addresses that they person.

But I *like* lists that follow the standard. I prefer to get 2 copies to emails that are in response to something I post. Then I know about it. Otherwise, I have to go find posts where I've posted and see if there are responses -- and sometimes I don't see responses at all -- I forget I posted in some thread or I see it days later.

What I read here is "blablabla because I can't bring myself to agree with the way the list is, I will just get on my soapbox until everyone puts me in there bit bucket"

...

As I've pointed out and as I've got evidence here and as everyone else on the list you're replied to has evidence, you are quite capable of reply to the list alone without duplicates. You have, up until yesterday done that. In fact your early relies yesterday weren't duplicated.

---

Capable? As long as you put "sometimes", sure. But that's what my behavior is... sometimes I'm too tired to delete the extra address and/or get tired of typing in the list address if I just hit reply.

Ah, yes. Proving the inconsistency point.

So when I'm tired -- I'm more likely to revert to minimal effort -- follow the standard. Note --- if you reply to this, it won't go to me, it will go to the list. You won't have to delete my name, because I as the creator of this message I can set the Reply-To field and point it at the list. Why those who don't want two copies can't do the same thing rather than jumping on someone who is would prefer to follow the standard anyway, is beyond me. It's easier for them to jump on people and expect them to know that like their distro's, opensuse mail lists don't like standards either.

Yes. too tired (lazy). If you want to conform to your beloved standards, you can. This list has a set way. It is what it is. If you don't like, go to ubuntu and bother them.

...

This isn't about standards, Linda, its about your behaviour and your attitude.

---

My attitude is fine. If you look tat the history of my posts, I'm sure you'll find that over 90% have had the 2nd address deleted.

...

One might speculate that we've stymied you as far as your derision of systemd goes, so now you're trolling on other matters.

---

I didn't bring up the issue. Others did.

Actually, I asked questions multiple times for key information and was waiting for any answer -- but to expect that is likely ludicrous.

In case you forgot:

1) So if no one moved files from /{bin,sbin,lib,lib64} --> their /usr equivs, what was the issue besides libblkid was on /usr? Wouldn't it be simpler and more compatible to move libblkid to /lib64?

There was 1 lib that mount needed that was on /usr. Because of that all files on root had to be moved to /usr?

(remember, we are talking *boot-time* files that currently exist in /bin and /usr/bin that have been duplicated on initrd -- including the boot.d sysVinit scripts). What it looks like is systemd couldn't handle things from boot, so they hid the sysVinit type scripts in initrd, so they can claim they switched fully to systemd, while hiding the large amount of boot that systemd doesn't handle in initrd). There's no reason that can't be on disk that I can see... I've asked why multiple times and never gotten a straight answer that showed WHY things had to change and be moved.

Then we have your note, that you never answered: 2. -- Anton Aylward wrote:

...

...

Linda Walsh said the following on 04/11/2013 09:59 PM:

...

...

Putting all of usr on /rootfs nearly does the same thing, as the reason for a small root was to have less on it needing updating. You are so missing the point.

---

Yes, I am. Could you tell me the point?

To me it creates a more unstable system, more prone to failure and more difficult to restore to running condition. This means more downtime and lower reliability overall. That's my point. So why do we want that?

--- I need a ram disk to boot that contains duplicates of things I have on my system -- wny not boot from the system. Boot used to rely on files in /bin, lib[64], /sbin... Now relies on those + /usr/bin /usr/lib /usr/lib64... how is that not less reliable if /usr is corrupt or not mounted?

I could bring up the file-system restore utils from the root partition -- now? Not in the default config.

I had others, but those seems difficult enough for anyone to answer, and I'm tired of typing...

Then stop typing. Well, type one more email. The one that removes you from this list. You say you're tired. We're tired too. Of you. Crying. Go. Away. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 4/14/2013 9:12 PM, Linda Walsh wrote:

If you want to rag on me, fine, but if you can't do anything to answer the questions, then you are just noise.

There are technical issues that I've repeatedly asked that have not been answered.

Michael S. Dunsavage wrote:

...

...

Actually, I asked questions multiple times for key information and was waiting for any answer -- but to expect that is likely ludicrous.

In case you forgot:

1) So if no one moved files from /{bin,sbin,lib,lib64} --> their /usr equivs, what was the issue besides libblkid was on /usr? Wouldn't it be simpler and more compatible to move libblkid to /lib64?

There was 1 lib that mount needed that was on /usr. Because of that all files on root had to be moved to /usr?

(remember, we are talking *boot-time* files that currently exist in /bin and /usr/bin that have been duplicated on initrd -- including the boot.d sysVinit scripts). What it looks like is systemd couldn't handle things from boot, so they hid the sysVinit type scripts in initrd, so they can claim they switched fully to systemd, while hiding the large amount of boot that systemd doesn't handle in initrd). There's no reason that can't be on disk that I can see... I've asked why multiple times and never gotten a straight answer that showed WHY things had to change and be moved.

Then we have your note, that you never answered: 2. -- Anton Aylward wrote:

...

...

Linda Walsh said the following on 04/11/2013 09:59 PM:

...

> Putting all of usr on /rootfs nearly does the same thing, as the > reason for a small root was to have less on it needing updating. You are so missing the point.

---

Yes, I am. Could you tell me the point?

To me it creates a more unstable system, more prone to failure and more difficult to restore to running condition. This means more downtime and lower reliability overall. That's my point. So why do we want that?

--- I need a ram disk to boot that contains duplicates of things I have on my system -- wny not boot from the system. Boot used to rely on files in /bin, lib[64], /sbin... Now relies on those + /usr/bin /usr/lib /usr/lib64... how is that not less reliable if /usr is corrupt or not mounted?

I could bring up the file-system restore utils from the root partition -- now? Not in the default config.

I had others, but those seems difficult enough for anyone to answer, and I'm tired of typing...

Then stop typing. Well, type one more email. The one that removes you from this list. You say you're tired. We're tired too. Of you. Crying. Go. Away.

Again you double email. What is so hard that no one else double emails but you have to? Please go away. quickly. very quickly. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Andrey Borzenkov wrote:

In ten years closely working with Mandrake/Mandriva there were quite a few bugs resulting from someone mounting /usr as separate filesystem.

...

(remember, we are talking *boot-time* files

In the 25 years working with unix and linux, I have alot more history with having /usr standard. BUT, I said ***why MOVE*** the files from bin->/usr? Only 1 file had deps on /usr -- the new lib for mount. So why through out the entire ability to have a separate user when it worked for those who wanted it.

I missed my BT adapter on boot because it needed program to be started by udev rule to inform software stack that this adapter was present.

---- And you were unable to move that into /lib?

Unfortunately this rule called program that needed libraries from /usr.

Like the rules I see fly by that load things from /usr/share for oracle's virtual machine. IF they were important, I'd move them to root.

This worked quite nicely for adapter you plug in after system is initialized. But I had built-in adapter which needs coldplpug. And device coldplug is executed quite early in *boot-time* sequence ...

Is that a reason to move files needed by any and everyone to /usr? If your system has a limitation, should it be limited for everyone or, would you -- if you wanted to boot from root, move the needed drivers onto root. I've never said that opensuse should get rid of initrd or systemd. What I have said is to not *create* problems in compatibility for those who spent the time to make their system work.

...

What it looks like is systemd couldn't handle things from boot,

All those problems existed long before systemd was even invented.

--- For

specific configuration that you control 100% you can fix them.

Most people have 100% control over their own machine.

But we are speaking about generic distribution where we sometimes do not even control which software user installs.

Driver files could easily be moved to root. However, if initrd works for you -- and you like it, I don't suggest changing. Why would you want to close of flexibility options that are suggested by systemd for optimizing boot speed? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Andrey Borzenkov wrote:

On Mon, Apr 15, 2013 at 10:29 AM, Linda Walsh wrote: ...

...

BUT, I said ***why MOVE*** the files from bin->/usr?

Only 1 file had deps on /usr -- the new lib for mount. So why through out the entire ability to have a separate user when it worked for those who wanted it.

This only one for your specific configuration. Care to count how many files there will be for someone having /usr on iSCSI LUN connected to port requiring 802.1x with smart card authentication?

iSCSI requires network. Initial boot to 'S' hasn't included networking as a rule. Even 'init-1' only adds in networking *after* the local file systems are mounted. That said -- if you are booting "diskless", then you have a whole different set of problems that are, also, "not the general case".

If distribution goes to support it, it has to work for everyone. Not only for Lina Walsh.

It would be nice if it worked for everyone -- vs. breaking it only for the standard case systemd suggests to optimize your boot -- the case that Linda Walsh was already using because she knew how to optimize a system -- booting with no separate ramdisk first. The ram disk duplicates your files from /root and /usr in order to boot the real system.. Any files used at boot and also used later have to be loaded twice. The Ramdisk already boots into SHELL -- not systemd, so it can run the SystemVinit scripts that were in /etc/boot.d (that are all now on the init-ramdisk. The init-ramdisk also copies parts of /usr, /usr/share, and nearly all of /etc/sysconfig onto the ramdisk. The technology is there to identify all the parts needed for boot. That same technology could easily be used as part of rpm-lint to make sure needed boot components are on /root.

This is never ending story.

--- It's called development. There will always be *new* drivers that won't be on a machine. Then they have to be placed on the machine. The package of the driver should be responsible enough to know if it is a driver that is needed at boot or not. When it gets added to the dist. The integrator can make the correct choice. It is already the case that distro-builders, often, do not put packages in their "upstream" locations. How is this any different? Suse didn't need to move all of these files from /bin to /usr/bin -- noted because existing programs still have hardcoded references to the prog in its original location, in /bin or /sbin or /lib64 -- and compatibility links are needed to make those work. The problem you are stating is for *new* drivers and libs added to the system: are they needed at boot? yes, put them in a boot-accessible location. For *existing* programs, like most of these -- there was no need to move them from their existing locations to /usr. So why? Instead of moving them, why weren't symlinks put in /usr/[s]bin to point to the binaries on root? Administratively, those would have been "safe links", since /usr is mounted on the link-destination (i.e. they would be links to a higher, already mounted device). Vs. these that go against good practice and do forward links from 1 device to another device that it is not dependent on. I.e. creating forward dependencies that didn't exist before, and that are subject to failure. unsafe link: /sbin/adjtimex => /usr/sbin/adjtimex unsafe link: /sbin/agetty => /usr/sbin/agetty unsafe link: /sbin/arping => /usr/sbin/arping unsafe link: /sbin/badblocks => /usr/sbin/badblocks unsafe link: /sbin/blkid => /usr/sbin/blkid unsafe link: /sbin/blockdev => /usr/sbin/blockdev unsafe link: /sbin/brctl => /usr/sbin/brctl unsafe link: /sbin/cfdisk => /usr/sbin/cfdisk unsafe link: /sbin/chcpu => /usr/sbin/chcpu unsafe link: /sbin/chkconfig => /usr/bin/chkconfig unsafe link: /sbin/clockdiff => /usr/sbin/clockdiff unsafe link: /sbin/crda => /usr/sbin/crda unsafe link: /sbin/ctrlaltdel => /usr/sbin/ctrlaltdel unsafe link: /sbin/debugfs => /usr/sbin/debugfs unsafe link: /sbin/dhcpcd => /usr/sbin/dhcpcd unsafe link: /sbin/dumpe2fs => /usr/sbin/dumpe2fs unsafe link: /sbin/e2fsck => /usr/sbin/e2fsck unsafe link: /sbin/e2image => /usr/sbin/e2image unsafe link: /sbin/e2label => /usr/sbin/e2label unsafe link: /sbin/e2undo => /usr/sbin/e2undo unsafe link: /sbin/ethtool => /usr/sbin/ethtool unsafe link: /sbin/fbset => /usr/sbin/fbset unsafe link: /sbin/fbtest => /usr/sbin/fbtest unsafe link: /sbin/fdisk => /usr/sbin/fdisk unsafe link: /sbin/findfs => /usr/sbin/findfs unsafe link: /sbin/fsck => /usr/sbin/fsck unsafe link: /sbin/fsck.cramfs => /usr/sbin/fsck.cramfs unsafe link: /sbin/fsck.ext2 => /usr/sbin/fsck.ext2 unsafe link: /sbin/fsck.ext3 => /usr/sbin/fsck.ext3 unsafe link: /sbin/fsck.ext4 => /usr/sbin/fsck.ext4 unsafe link: /sbin/fsck.minix => /usr/sbin/fsck.minix unsafe link: /sbin/fsfreeze => /usr/sbin/fsfreeze unsafe link: /sbin/fstrim => /usr/sbin/fstrim unsafe link: /sbin/hwclock => /usr/sbin/hwclock unsafe link: /sbin/ifenslave => /usr/sbin/ifenslave unsafe link: /sbin/in.rdisc => /usr/sbin/in.rdisc unsafe link: /sbin/ip => /usr/sbin/ip unsafe link: /sbin/logsave => /usr/sbin/logsave unsafe link: /sbin/losetup => /usr/sbin/losetup unsafe link: /sbin/mke2fs => /usr/sbin/mke2fs unsafe link: /sbin/mkfs => /usr/sbin/mkfs unsafe link: /sbin/mkfs.bfs => /usr/sbin/mkfs.bfs unsafe link: /sbin/mkfs.cramfs => /usr/sbin/mkfs.cramfs unsafe link: /sbin/mkfs.ext2 => /usr/sbin/mkfs.ext2 unsafe link: /sbin/mkfs.ext3 => /usr/sbin/mkfs.ext3 unsafe link: /sbin/mkfs.ext4 => /usr/sbin/mkfs.ext4 unsafe link: /sbin/mkfs.minix => /usr/sbin/mkfs.minix unsafe link: /sbin/mkfs.ntfs => /usr/sbin/mkntfs unsafe link: /sbin/mkswap => /usr/sbin/mkswap unsafe link: /sbin/modeline2fb => /usr/sbin/modeline2fb unsafe link: /sbin/mount.fuse => /usr/sbin/mount.fuse unsafe link: /sbin/mount.vmhgfs => /usr/sbin/mount.vmhgfs unsafe link: /sbin/nologin => /usr/sbin/nologin unsafe link: /sbin/pivot_root => /usr/sbin/pivot_root unsafe link: /sbin/raw => /usr/sbin/raw unsafe link: /sbin/rckbd => /usr/sbin/rckbd unsafe link: /sbin/refresh_initrd => /usr/sbin/refresh_initrd unsafe link: /sbin/regdbdump => /usr/sbin/regdbdump unsafe link: /sbin/resize2fs => /usr/sbin/resize2fs unsafe link: /sbin/service => /usr/sbin/service unsafe link: /sbin/sfdisk => /usr/sbin/sfdisk unsafe link: /sbin/smart_agetty => /usr/sbin/smart_agetty unsafe link: /sbin/swaplabel => /usr/sbin/swaplabel unsafe link: /sbin/swapoff => /usr/sbin/swapoff unsafe link: /sbin/swapon => /usr/sbin/swapon unsafe link: /sbin/switch_root => /usr/sbin/switch_root unsafe link: /sbin/syslogd => /usr/sbin/syslogd unsafe link: /sbin/tracepath => /usr/sbin/tracepath unsafe link: /sbin/tracepath6 => /usr/sbin/tracepath6 unsafe link: /sbin/tune2fs => /usr/sbin/tune2fs unsafe link: /sbin/udevadm => /usr/bin/udevadm unsafe link: /sbin/udhcpc => /usr/sbin/udhcpc unsafe link: /sbin/vconfig => /usr/sbin/vconfig unsafe link: /sbin/wipefs => /usr/sbin/wipefs unsafe link: /bin/arch => /usr/bin/arch unsafe link: /bin/basename => /usr/bin/basename unsafe link: /bin/cat => /usr/bin/cat unsafe link: /bin/chgrp => /usr/bin/chgrp unsafe link: /bin/chmod => /usr/bin/chmod unsafe link: /bin/chown => /usr/bin/chown unsafe link: /bin/chvt => /usr/bin/chvt unsafe link: /bin/clrunimap => /usr/bin/clrunimap unsafe link: /bin/cp => /usr/bin/cp unsafe link: /bin/cpio => /usr/bin/cpio unsafe link: /bin/date => /usr/bin/date unsafe link: /bin/dd => /usr/bin/dd unsafe link: /bin/dd_rescue => /usr/bin/dd_rescue unsafe link: /bin/dd_rhelp => /usr/bin/dd_rhelp unsafe link: /bin/deallocvt => /usr/bin/deallocvt unsafe link: /bin/df => /usr/bin/df unsafe link: /bin/dmesg => /usr/bin/dmesg unsafe link: /bin/dumpkeys => /usr/bin/dumpkeys unsafe link: /bin/echo => /usr/bin/echo unsafe link: /bin/egrep => /usr/bin/egrep unsafe link: /bin/eject => /usr/bin/eject unsafe link: /bin/false => /usr/bin/false unsafe link: /bin/fgconsole => /usr/bin/fgconsole unsafe link: /bin/fgrep => /usr/bin/fgrep unsafe link: /bin/fillup => /usr/bin/fillup unsafe link: /bin/find => /usr/bin/find unsafe link: /bin/findmnt => /usr/bin/findmnt unsafe link: /bin/gawk => /usr/bin/gawk unsafe link: /bin/getkeycodes => /usr/bin/getkeycodes unsafe link: /bin/getunimap => /usr/bin/getunimap unsafe link: /bin/grep => /usr/bin/grep unsafe link: /bin/guess_encoding => /usr/bin/guess_encoding unsafe link: /bin/gunzip => /usr/bin/gunzip unsafe link: /bin/gzip => /usr/bin/gzip unsafe link: /bin/ip => /usr/sbin/ip unsafe link: /bin/ipg => /usr/bin/ipg unsafe link: /bin/kbd_mode => /usr/bin/kbd_mode unsafe link: /bin/kbdinfo => /usr/bin/kbdinfo unsafe link: /bin/kbdrate => /usr/bin/kbdrate unsafe link: /bin/kill => /usr/bin/kill unsafe link: /bin/ln => /usr/bin/ln unsafe link: /bin/loadkeys => /usr/bin/loadkeys unsafe link: /bin/loadunimap => /usr/bin/loadunimap unsafe link: /bin/logger => /usr/bin/logger unsafe link: /bin/ls => /usr/bin/ls unsafe link: /bin/lsblk => /usr/bin/lsblk unsafe link: /bin/mapscrn => /usr/bin/mapscrn unsafe link: /bin/md5sum => /usr/bin/md5sum unsafe link: /bin/mkdir => /usr/bin/mkdir unsafe link: /bin/mknod => /usr/bin/mknod unsafe link: /bin/mktemp => /usr/bin/mktemp unsafe link: /bin/more => /usr/bin/more unsafe link: /bin/mount => /usr/bin/mount unsafe link: /bin/mv => /usr/bin/mv unsafe link: /bin/nisdomainname => /usr/bin/nisdomainname unsafe link: /bin/openvt => /usr/bin/openvt unsafe link: /bin/outpsfheader => /usr/bin/outpsfheader unsafe link: /bin/ping => /usr/bin/ping unsafe link: /bin/ping6 => /usr/bin/ping6 unsafe link: /bin/psfaddtable => /usr/bin/psfaddtable unsafe link: /bin/psfgettable => /usr/bin/psfgettable unsafe link: /bin/psfstriptable => /usr/bin/psfstriptable unsafe link: /bin/psfxtable => /usr/bin/psfxtable unsafe link: /bin/pwd => /usr/bin/pwd unsafe link: /bin/readlink => /usr/bin/readlink unsafe link: /bin/resizecons => /usr/bin/resizecons unsafe link: /bin/rm => /usr/bin/rm unsafe link: /bin/rmdir => /usr/bin/rmdir unsafe link: /bin/screendump => /usr/bin/screendump unsafe link: /bin/sed => /usr/bin/sed unsafe link: /bin/setfont => /usr/bin/setfont unsafe link: /bin/setkeycodes => /usr/bin/setkeycodes unsafe link: /bin/setleds => /usr/bin/setleds unsafe link: /bin/setlogcons => /usr/bin/setlogcons unsafe link: /bin/setmetamode => /usr/bin/setmetamode unsafe link: /bin/setpalette => /usr/bin/setpalette unsafe link: /bin/setvesablank => /usr/bin/setvesablank unsafe link: /bin/setvtrgb => /usr/bin/setvtrgb unsafe link: /bin/showconsolefont => /usr/bin/showconsolefont unsafe link: /bin/showkey => /usr/bin/showkey unsafe link: /bin/sleep => /usr/bin/sleep unsafe link: /bin/sort => /usr/bin/sort unsafe link: /bin/spawn_console => /usr/bin/spawn_console unsafe link: /bin/spawn_login => /usr/bin/spawn_login unsafe link: /bin/stat => /usr/bin/stat unsafe link: /bin/stty => /usr/bin/stty unsafe link: /bin/su => /usr/bin/su unsafe link: /bin/sync => /usr/bin/sync unsafe link: /bin/systemctl => /usr/bin/systemctl unsafe link: /bin/systemd => /usr/lib/systemd/systemd unsafe link: /bin/systemd-ask-password => /usr/bin/systemd-ask-password unsafe link: /bin/testutf8 => /usr/bin/testutf8 unsafe link: /bin/touch => /usr/bin/touch unsafe link: /bin/true => /usr/bin/true unsafe link: /bin/umount => /usr/bin/umount unsafe link: /bin/uname => /usr/bin/uname unsafe link: /bin/unicode_start => /usr/bin/unicode_start unsafe link: /bin/unicode_stop => /usr/bin/unicode_stop unsafe link: /bin/ypdomainname => /usr/bin/ypdomainname unsafe link: /bin/zcat => /usr/bin/zcat unsafe link: /lib64/libcom_err.so.2 => /usr/lib64/libcom_err.so.2 unsafe link: /lib64/libcom_err.so.2.1 => /usr/lib64/libcom_err.so.2.1 unsafe link: /lib64/libe2p.so.2 => /usr/lib64/libe2p.so.2 unsafe link: /lib64/libe2p.so.2.3 => /usr/lib64/libe2p.so.2.3 unsafe link: /lib64/libext2fs.so.2.4 => /usr/lib64/libext2fs.so.2.4 unsafe link: /lib64/libfuse.so.2 => /usr/lib64/libfuse.so.2 unsafe link: /lib64/libfuse.so.2.9.0 => /usr/lib64/libfuse.so.2.9.0 unsafe link: /lib64/libhandle.a => /usr/lib64/libhandle.a unsafe link: /lib64/libhandle.la => /usr/lib64/libhandle.la unsafe link: /lib64/libkmod.so.2 => /usr/lib64/libkmod.so.2 unsafe link: /lib64/libkmod.so.2.2.2 => /usr/lib64/libkmod.so.2.2.2 unsafe link: /lib64/libss.so.2 => /usr/lib64/libss.so.2 unsafe link: /lib64/libss.so.2.0 => /usr/lib64/libss.so.2.0 ------------------------- There will always be something else. So

the only way to avoid it is to ensure you have full system environment from the start. And if you go this route, having the whole OS under single directory provides more advantages than arbitrary split across multiple directories. Even only from maintenance point of view.

That reasoning also applies to the system environment on a ram/init disk as well. Are you going to put all of /usr and /usr/share on initrd?

You have heavily customized system.

, what prevents you from adding

static mount binary to mount your /usr early in boot process?

That's a possible solution, but all of the above have been moved as well. Also, until I reported the bug and it was fixed, you couldn't build libc statically. Now you can -- but suse never chose to pursue a statically linked libc for boot. Instead they just tell you that you can't have one if you use any id&auth calls (getentX). That would have been perfect for a run-time loaded extra set of files to run when the network is up -- but if your network isn't up, being able to bind in NIS, winbind, LDAP, etc... is of limited use. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Carlos E. R. said the following on 04/10/2013 05:48 PM:

On Wednesday, 2013-04-10 at 18:40 -0300, Cristian Rodríguez wrote:

...

In this case it means Yast is dying due to the lack of developers.

And in turn that will be the death of openSUSE.

Unless ... -- Nothing excites a magical particle like meeting itself coming the other way. -- _The Science of Discworld_ -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wednesday, 2013-04-10 at 19:00 -0300, Cristian Rodríguez wrote:

El 10/04/13 18:48, Carlos E. R. escribió:

...

...

In this case it means Yast is dying due to the lack of developers.

And in turn that will be the death of openSUSE.

Sorry but I do not see the connection between yast dying and openSUSE dying.. anyway, work is being done to migrate out from the YCP language and allow Yast development to continue using Ruby.

YaST is the single tool that marks the difference between openSUSE and the rest of the distros. If YaST dissapears and I have to hand configure things, then I could as well use any thing like Debian instead. IMNSHO :-) - -- Cheers, Carlos E. R. (from 12.1 x86_64 "Asparagus" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (GNU/Linux) iEYEARECAAYFAlFl75EACgkQtTMYHG2NR9XdKQCfR/45ScEQQ0X7XzV+H0cwNAZC D7UAnAgo4yZEkx7NRmOraYx4SBrYN8dR =Ak5W -----END PGP SIGNATURE-----

Anton Aylward wrote:

Carlos E. R. said the following on 04/10/2013 07:02 PM:

...

YaST is the single tool that marks the difference between openSUSE and the rest of the distros. If YaST dissapears and I have to hand configure things, then I could as well use any thing like Debian instead.

IMNSHO :-)

+1

Yeah, I have to agree with Carlos - if it wasn't for YaST, I would never have gotten off the ground with SuSE Linux back in the mid 90s. Today I use YaST a lot less, but it is still a major advantage of openSUSE over everybody else. Well, a lack of developers for YaST - there's a test for the community. -- Per Jessen, Zürich (8.2°C) http://www.dns24.ch/ - free DNS hosting, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 04/10/2013 05:48 PM, Carlos E. R. pecked at the keyboard and wrote:

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

On Wednesday, 2013-04-10 at 18:40 -0300, Cristian Rodríguez wrote:

...

In this case it means Yast is dying due to the lack of developers.

And in turn that will be the death of openSUSE.

Exactly. YaST is THE reason I stay with openSUSE, as the rest is going down the tubes with the rapid release cycle (let's push it out ready or not, and lately it has not been ready to be released). -- Ken Schneider SuSe since Version 5.2, June 1998 -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

* Ken Schneider - openSUSE [04-11-13 11:50]:

On 04/10/2013 05:48 PM, Anton Aylward pecked at the keyboard and wrote:

...

Marc Chamberlin said the following on 04/10/2013 04:57 PM: <snip>

If old, decrepit, superannuated alzheimer-candidates like Patric and myself can manage that, I'm sure that younger, more nimble minds can manage it as well.

I have you and Patrick beat with my extreme short term memory loss on top of what you have. :-)

See and raise you six Dos Equis and three rounds of chemo. Brain cell retention may be somewhat diminished in addition to that related to the aging process :^). ps: if Dos Equiss not available, Tecante, Modelo or Corona will do. -- (paka)Patrick Shanahan Plainfield, Indiana, USA HOG # US1244711 http://wahoo.no-ip.org Photo Album: http://wahoo.no-ip.org/gallery2 http://en.opensuse.org openSUSE Community Member 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 Thursday, April 11, 2013 11:33:45 AM Anton Aylward wrote:

Damon Register said the following on 04/11/2013 10:24 AM:

...

I didn't really notice anything different in the YaST runlevel setting. Do I understand correctly there is a significant departure or shift in use of runlevel or how it works? Is there anyone who can help me understand this discussion?

It depends on whether your system is running with systemd or sysvinit. You can use zypper (or rpm) to what/which is installed.

Systemd has a backward compatibility function so commands such as init 3 and init 5 still appear work. Many things that still appear to exist under /etc/init.d are actually 'aliased' to their systemd equivalents.

Even though the init commands still work I have been using [CODE] systemctl isolate runlevel3.target and systemctl isolate runlevel5.target [/CODE] A few more key strokes but they do work. A lot more I need to learn about this new stuff, especially how to tell a service to start at boot or level 3, 4 or 5, etc.

For the ordinary user, so long as there are no hardware problems, it should be the same old "turn it on, wait a bit and see the login screen".

Unless you're specifically interested, in which case there is a vast amount of documentation, there's little reason to look "under the hood".

-- HTTP is like being married: you have to be able to handle whatever you're given, while being very careful what you send back. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Russ -- openSUSE 12.3(Linux 3.7.10-1.1-desktop x86_64)|KDE 4.10.2 "release 553"|Intel core2duo 2.5 MHZ,|8GB DDR3|GeForce 8400GS(NVIDIA-Linux-x86_64-310.32) -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Cristian Rodríguez wrote:

El 11/04/13 15:53, Upscope escribió:

...

especially how to tell a service to start at boot or level 3, 4 or 5, etc.

You usually don't, runlevels no longer exist and services will come up according what target, service or device needs it.

---- Aren't runlevels aliases to a set of services that the user wants to be running at a given point? Are you saying that equivalent targets couldn't be created to provide the same functionality? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Thursday, 2013-04-11 at 11:33 -0400, Anton Aylward wrote:

For the ordinary user, so long as there are no hardware problems, it should be the same old "turn it on, wait a bit and see the login screen".

Unless you're specifically interested, in which case there is a vast amount of documentation, there's little reason to look "under the hood".

But when there are problems, it is very difficult. There is a chap in the forum whose system is starting into emergency mode everytime, and we can not figure out why. - -- Cheers, Carlos E. R. (from 12.1 x86_64 "Asparagus" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (GNU/Linux) iEYEARECAAYFAlFncFEACgkQtTMYHG2NR9U9ogCeOievREXtBumzmqcpEg9ARqcd sE0An1WqMZ/F99NjR2WQ32viOAfY43MO =5OQG -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Thursday, 2013-04-11 at 23:33 -0300, Cristian Rodríguez wrote:

El 11/04/13 23:24, Carlos E. R. escribió:

...

But when there are problems, it is very difficult.

If you dont understand it.. yes it is hard, like pretty much everything else.

When systemv dropped you into emergency mode, the reason was clearly printed in the screen, whithout having to dig into logs. Like a device not mounting of failing fsck. This did not happen in 12.2. I wrote a bugzilla about this issue, and was told that things would be much better in 12.3. It appears they are... but not enough. I want to experiment with this myself on a virtual machine. It is difficult to diagnose things remotely.

...

There is a chap in the forum whose system is starting into emergency mode everytime, and we can not figure out why.

Does http://freedesktop.org/wiki/Software/systemd/Debugging yields any clue ?

I just had a quick look at it, and so far nothing "jumps" out at me. I'll look again tomorrow, when I get time... tomorrow I'll be busy. I'm off to bed now. - -- Cheers, Carlos E. R. (from 12.1 x86_64 "Asparagus" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (GNU/Linux) iEYEARECAAYFAlFnf4IACgkQtTMYHG2NR9VFlACgjwTNsoxDX6Q5IWIasmpw8yCb q4UAn2dmfMnDypGFuRz6pWwajKubFQqG =h0k9 -----END PGP SIGNATURE-----