Damian Ivanov wrote: Since when are large monolithic programs either good or maintainable? It's NOT modular design -- that is generally considered *BAD**...

It can't be broken apart (says its creator) -- again, these are all things that speak of bad design.

>He claims that his logind, udevd, dbusd all are dead and combined into systemd.

jdebert wrote: That's both interesting and quite revealing. -- To unsubscribe, e-mail: opensuse+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse+owner(a)opensuse.org

Damian Ivanov wrote: https://plus.google.com/+LennartPoetteringTheOneAndOnly/posts/8RmiAQsW9qf#+… (don't blame me for such a long URL -- it's from google!) -- To unsubscribe, e-mail: opensuse+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse+owner(a)opensuse.org

We Are the Borg. You Will be Assimilated. Resistance is Futile.

Multiseat? Explain why a distro aimed primarily at users needs multiseat? Seems very few people use opensuse as a server (well, 'cept me -- but I know I don't need multiseat). So why does anyone on this list need multiseat?

Carlos E. R. wrote: And multiseat worked perfectly under the old init system. I know, because I worked on machines with both BSD init and SysV init, with anywhere from a dozen to hundreds of simultaneous logins. Multiseat was NEVER a problem. Hell, I implemented multiseat on a lowly 8-bit Motorola 6809 microcomputer with 64k of memory, and that included interprocess communication (i.e. pipes and sockets). OH, and I did it in 4 weeks. So, really, it doesn't matter. 1970's era init is capable of multiseat, regardless of whether Linda sees a need for multiseat in opensuse or not, and regardless of Damiean's naive understanding of multiseat, there is absolutely ZERO connection between mutiseat and any suposed need for systemd. We've had multiseat for decades. Damian is just so inexperienced that he doesn't understand that one of the primary goals of Unix was to allow a multi-user computer to be used by those multiple users, simultaneously, as if each one of them was working on the computer alone, or interacting with other users (according to their wishes). -- To unsubscribe, e-mail: opensuse+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse+owner(a)opensuse.org

On 06/05/2014 01:27 AM, Damian Ivanov wrote: Indeed. Aaron is doing what he often does and talking about something using a shift in terminology. Multi-user is not the same as multi-seat. In this case he starts referring to 'multi-user' versions of UNIX. Yes, I was administering PDP-11s back in the late 70s/early80s running V6 and V7 UNIX ('from the 'love, Dennis' tapes) and BSD2.8 and kernel hacking V6 and V7 and we had up to 40 users on some of the larger config 11/45s before we switched to VAXen. But what Aaron fails to mention was that these users were running VT100 clones in text only mode on 9600 baud RS-232 links, not the high resolution graphics with keyboard and mouse such as I am currently working at. It is possible to plug in more graphics cards to my PC, and another (USB) keyboard and another (USB) mouse. Depending on the mobo and the graphics card I might get another two or three potential graphic stations. But as Damian says, the classic hack with X to make that work was unstable and not good. This is what MULTI-SEAT is about. <quote src="http://fedoraproject.org/wiki/Features/Multiseat"> Linux is inherently multiuser, but PC hardware is usually designed with a single local user in mind. However, it's relatively straightforward to add additional video cards, monitors, and mice to provide access for multiple simultaneous users. </quote> There are a number of how-to articles out there. The other shifteroo Aaron indulges in is ascribing to systemd things that it does not do, things that it uses other services to or other programs to do. Systemd is NOT monolithic any more than the BASH shell is monolithic. The original shell of the V7 era was minimalist and the kind of arguments Aaron is throwing against systemd could equally well be thrown at the BASH shell, if he was the UNIX purist he claims. The BASH shell has many things built into it that were done by external programs back in the V7 days and BASH has an amazing number of user interactive features that cause a great deal of "bloat". I mention this because systemd is not and is not going to subsume X. <quote src="http://www.freedesktop.org/wiki/Software/systemd/multiseat/"… systemd, versions 30 and newer, includes support for keeping track of user sessions and seats. </quote> Systemd is not implementing multi-seat, it is keeping track of resources are assigned to a seat. Right now, the X server doesn't handle multi-seat displays properly, so there is a shim in the systemd package to use until the Xorg team complete their work. This is sort of like the old TCPWrappers shim, which eventually went away and was properly integrated. Nearly a year ago we have http://code.lexarcana.com/posts/simple-multiseat-setup-on-fedora-17.html which starts out <quote> Hardware requirements Two video cards Two mice Two keyboards On the test system, we will use an ASRock motherboard with two ATI/AMD RadeonHD video cards: HD6850 and HD2400XT. The 6850 is on the PCIe x16 slot and the 2400 is on the PCIe x4 slot. </quote> So, is this all reliable? Is it all stable? No, like so much of Linux it is being offered for users to experiment with and give feedback. That has always been the Linux tradition. And THAT is where Aaron comes unstuck. Linux is not Microsoft, despite all his assertions. Systemd is not a finished product any more than a whole host of other things under Linux are, things he isn't complaining about. He rants about systemd and about KDE4 because they represent dramatic changes, more dramatic than the incremental changes that are going on other areas. For example, those of us doing photography can see that Darktable has updates every couple of days, the rate of change probably exceeds that of systemd! But Aaron isn't ranting about that. He may claim that systemd is more fundamental than darktable, but that is nonsense. Those of us doing a lot of photographic work and using darktable are face to face with darktable. For some of us its even part of our revenue stream. Its a lot more apparent than systemd! If what Aaron is so keen to denigrate and use bad language over is not unique to Linux. Darwin proposed evolutionary change and the debate between evolution and saltation http://en.wikipedia.org/wiki/Saltation_%28biology%29 persists to this day. But we can see the furore that non-evolutionary (aka patches) change in for example MS-Windows and MS-Office has wraught. The shifts from W/XP to W/Vista to W/7 and now W/8 have all been accompanied by outcries. http://technet.microsoft.com/en-us/library/cc178954%28v=office.15%29.aspx But they were nothing compared to the shift from the menu to the "ribbon" and that too garnered a negative reaction http://en.wikipedia.org/wiki/Ribbon_%28computing%29#Reaction What differentiates Aaron though is his personal attacks and his use of language. -- /"\ \ / ASCII Ribbon Campaign X Against HTML Mail / \ -- To unsubscribe, e-mail: opensuse+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse+owner(a)opensuse.org

This is what MULTI-SEAT is about.

programs to do. Systemd is NOT monolithic any more than the BASH shell is monolithic. The original shell of the V7 era was minimalist and the

Systemd is not implementing multi-seat, it is keeping track of resources are assigned to a seat. Right now, the X server doesn't handle multi-seat displays properly, so there is a shim in the systemd package to use until the Xorg team complete their work. This is sort of like the old TCPWrappers shim, which eventually went away and was properly integrated.

On 06/05/2014 11:32 AM, Carlos E. R. wrote: Perhaps you should consider a few other things that are shown there.

The second thing of note is because systemd is really a dispatcher, and one that does most of its work at the start of things (boot being one of those 'things') it is not consuming much cpu.

Compared to the resident parts of firefox and thunderbird items such as systemd and BASH are insignificant.

If you want to make improvements or fret about consumption then there are areas where effort will have more effect than getting a later over systemd.

Once I had the old init consuming... I don't remember, maybe 90% CPU. It was outrageous and absurd. Well, the cause was that my modem had got into an unknown state, an internal loop or something, maybe sending repeated irq signals via serial port (I did not find out what), but "init" was attending to the modem signals full time with all the cpu power available. A power cycle of the modem solved the issue - but before finding the culprit, I did reboot Linux, to no use. It kept me mad for hours.

SuSE introduced dummy packages in place of real ones for various sysV related functions so they could forward the actual management to systemd. Never saw such deception with bash emulating ksh or csh.

Bzzt. wrong. You can use it already if you have two seperate GPU's (thus if you have a recent Intel processor or AMD APU in combination with another nVidia/amd card) you only need a 2nd keyboard/mouse and monitor. Work is going on so even on a single gpu with more than one connector this will work.

It already works even on a single monitor since always... Its running fine without systemd.

On Thursday 05 June 2014, Damian Ivanov wrote: It already works even on a single monitor since always... Its running fine without systemd.

On 06/06/2014 07:49 AM, Carlos E. R. wrote:

Perhaps this article makes it more clear. One box with the mobo's GPU and then 3 more GPU cards. Plug in 3 more mice and 3 more keybaords via USB. One box, four seats. $600. http://cedarandthistle.wordpress.com/2013/12/02/setting-up-a-multiseat-syst…

We now need (affordable) multiport graphical cards. Meaning, a single card that can handle several fully independent displays. Useful not only for multiseat, but for panoramic multi displays and such.

Ah, then there are possibilities, yes. Good :-) Not that I need this at the moment, but it is certainly something to consider. If it is easy to setup in openSUSE, and gets some publicity, normal people may consider using it. Families, for instance. What about sound? For some uses it is important, like in a family

It is very useful for schools, callcenters etc. Handhelds are a hype. Desktop and Laptop can be considered Desktop. Also everyone owns some PC. For any other misinformation in your answer it was just too long for me so I didn't read it anymore.

systemd the solution for 99.9% of users.

Carlos E. R. wrote:

Parents might want stable and reliable (which sorta disallows systemd right now, anyway, no?)

divided up, *today*, w/o systemd, that using multi-seat as a reason for driving this changes is ludicrous.

Carlos E. R. wrote: All booting in the systemd recommended way for performance of booting direct from the hard disk and not using a ramdisk(initrd)?

Everytime someone tells me they boot w/sep user or such, they really aren't. They are booting from initd, which mounts /usr, and THEN, the system does the real booting, -- without /usr being unmounted or separately mounted. (i.e. the initrd hides the separation so systemd doesn't have a cow.

Carlos E. R. wrote: So wait, opensuse wants to use systemd, but doesn't want to follow their recommendations and instructions?? Seems like that puts OS in a worse position in some ways than if they followed the baseline plan. But out of the box is NOT optimized by a long shot. It's bare-ass basic to work on lowest common denominator systems "out of the box". It' up to the user to optimize for performance if they want it. That used to be not so big a deal, but now, they are taking away optimization options even suggested by the systemd folks they are worshiping & following. I find such hypocrisy to be taking the worst of both worlds. You may not care about performance -- and you may have a family that does timesharing. Little kids might do that.. But when they get into rebellious teens... that won't cut it in MOST families. But some families live without TV and internet access, so whatever the scenario one comes up with -- it's almost a certainty that someone will be found to meet the scenario. But more to the point, say you get multi-seat... you going to fit mom and 2 kids on a tablet? -- each in their own session ... Right....doing what? playing solitaire? That's a pretty specious example. -- To unsubscribe, e-mail: opensuse+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse+owner(a)opensuse.org

Just as when I asked -- why move things to /usr/bin, when you could have put things in /bin and had the same effect (all in one place) but no risk of having /usr not mounted?

/usr has alot more stuff in it that isn't in root: X11R6, adm db games include libexec local share (man+docs) and more...

Anton Aylward wrote: ---- Sorry, that is not true. The boot process has things like keyboard screen fonts, etc in /usr/share. It must also be loaded at boot time. At first I was told it was not needed. When I pointed out the transgressions, I was told 'share' is part of usr, so of course it needs to be mounted too.

On 2014-06-08 23:21, Anton Aylward wrote: The problem is that she also refuses to use initrd. Thus, she has to implement tons of hacks, fighting against the methods used by the distribution, and more on every release.

Soon as you show me how to upgrade root w/o rebooting, let me know. I have updated /usr w/o a full reboot and certainly /usr/share is fairly trivial.

I said from day one that combining root+usr made system maintenance and recovery far more difficult. Any piece of junk that requires a monolith of 27G in backing libs, configs and files is just that: junk. Just because systemd is broken into parts doesn't mean it can boot off of root -- it has huge disk space requirements for what needs to be mounted in order to boot. That's where it is monolithic and non-sub-dividable.

Anton Aylward wrote: ---- I mean your root partition -- how do you resize or reformat it on a live system? /usr, /usr/share... I can format and restore from backup running from root. I can't restore root except by running from a rescue disk, but it won't have my my lvm & fstsab info if it unmounts root.

----- There are 3 points we could talk about. 1 is only used for emergency and that is coming up prior to having run any 'boot.d' scripts.... so no proc, no /sys, no /dev/ no udev, no disks... etc... Second is having brought up base machine to point of being ready to start bringing up the machine -- i.e. usually after boot.d, but before rc3.d scripts. According to the systemd 'dogma', they want the ability to bring up the GUI in parallel with mounting disks -- that means /usr/share + /usr + /.

What I would have found fine is -- let me start it up to point with disks mounted > (including lvm, since my /usr/share/ is on lvm). Then it could have started systemd > and brought up 3 or 5 (or 1)... I would have been ok w/that... But having it have > to go from before 'B' (by being the init-shell), to full system allowed no common ground.

My system still comes up in all those states -- before 'B', /usr isn't mounted -- it is mounted in 'b', before anything else comes up. But when startup scripts or startup problems prevent my system from coming up, I could boot into the beginning of 'B', and run scripts 1-by-1 to see where the problem was. Let see the systemd follks do that... Does it provide an interactive shell at beginning of boot where you can load each item that is part of the boot manually or in a script like for i in S*;do $i start [&] done

--- systemd has no such abilities for low level debugging and fixing.

If it doesn't boot what are you going to do?... It is init!... That's why going with a simple 'init' that requires nothing, is a good thing--- it's not likely to break.

On 2014-06-10 03:36, Anton Aylward wrote: Automatically (and dynamically?), yes. Well, no, the last implementations of sysvinit as used by openSUSE also started things in parallel, but defined statically, when inserting an init script. There was a makefile type of file that stored the dependencies and decided what was started when, what could be started in parallel to what. And it could be disabled. And, by the way, this also meant that the openSUSE implementation *ignored* the symlinks in the rc?.d directories, and the numbers in their names! People were surprised and came for help because they had created a symlink to a startup script, and it was never started automatically. In openSUSE you had to call insserv or chkconfig. Which, I suppose, it is contrary to the original and documented unix way of things ;-) This sequence and parallelism was defined by comments in the scripts, if they followed certain syntax. When services were inserted, the makefile was created, and the links.

Anton Aylward wrote: ---- Its the fact that you boot from a ramdisk first, which then boots your hard disk. That's fine if that's your want. But I like the ability to *see* what I am booting... If I change a script in /etc/init.d/XXX.d and reboot, I immediately see the changes. I don't have to regenerate an opaque blob of an initrd. Do you know all the files that go into your initrd? I have a pretty good idea of the files that my system boots from because they are in front of my eyes all the time. But the files in an initrd are not -- they are in an enclosed blob that you need to go out of your way to peer into and become familiar with. I like being familiar with my system's boot procedure -- I tend to read the boot log nearly every time it comes up --- usually because it's a new kernel and I look for changes. If it boots up off an opaque blob, it is human nature not to look to crack open your initrd and read it on a weekly basis. I like to be able to make changes or tweaks in how things come up. If some step takes too long, I fix it. If it was buried in a ram disk, I wouldn't have as easy access. ---- Problems don't just come from choices 1 person makes, but in combination with choices others make that intersect their choices. The lake doesn't make a choice to get polluted, but it makes a choice to stay in place since it's only other choice is to evaporate and fall someplace else. But when someone comes along and starts dumping in your basin, sure, you can say it's the lake's fault for the choices it made to stay where it was at, or you can look at the ones who made a choice to dump antithetical-to-lake-being junk in the lake. You can look at it from either side. The indians who didn't want to move and lived with the land, or take the side of looking at them as obstacles to growth and new ways of doing things. Sure, you can blame it on the ones who don't want to be forced into new ways for reasons that are predominantly, not in their best interests (having ones computer locked down so one can't do what one will with it, isn't my idea of fun), but MANY people preferred their walled-gardens, as is well seen with apple's growing influence. The fact that those creating the walled gardens may destroy the rest of the ecosphere for those who don't want to live that way -- sure, you can call it "their choice" and "their fault" for not taking the easy road, but is it really? In the end it won't make much difference as the forces pushing for uniformity and control are much longer lived than any independent forces....and move people will take the easier route and become part of the collective. ---- Without the need is 1 thing, but since I do development on my system, things sometimes get hosed. If I can't get to a console, restoration is alot more painful. --- If I did that for everything, all the time, yes... but for smaller "bites", it's fine. ----- Systemd *didn't* do the choke points very well. If followed dependencies starting order, but didn't wait for them to finish. This was especially true of legacy scripts and another reason I steered away from systemd. Too many times it tried to mount the lvm volumes BEFORE lvm was finished running. (as one example -- there were others). ---- That's not where the problems come in -- but when libs don't load due to conflicts and you can't login because pam won't approve you. IT's not bugs in the shell scripts but in how the SW is or is not linked together. ----- There are many levels of debugging. But being able to have your debug environment be one that is familiar to you because you already know the utilities and shell they run under is a big bonus. If I had to break out a special purpose debugger like gdb or such to debug, I'd be lost -- because I don't do it that often. ---- If my system is down I can't google. That's perhaps another difference. The system that systemd affects is my only route to the internet. If it doesn't boot, there are no 'online resources' or references -- I have to go by memory or what I can pull from the system. That means something familiar and reliable is the best way to go. Not something foreign and complex with all it's documentation in the cloud. They are correct for my use case. If you can't access online, then there is no documentation. -- To unsubscribe, e-mail: opensuse+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse+owner(a)opensuse.org

On 2014-06-10 11:11 (GMT+0200) Damian Ivanov composed: Speaking of trolling, I wonder if Damian is a competitive distro or M$ plant here for no other purposes than to provoke regulars, and pollute the mail and archive system with yet another top posted one liner, this time quoting without modification all 172 lines from the post replied to. It appears his only posts to this list have all been made since the first of this year. I have a suspicion that many regulars here have had his posts going to the bit bucket for quite some time. https://en.opensuse.org/openSUSE:Mailing_list_netiquette Excerpts from above: "When you reply to a message, please quote only the relevant passages to which you are replying." "...quote relevant sentences from the previous message and give your answers *under* the quote." (emphasis supplied) "Time and practice brought the general consensus that this is a better way to communicate on the lists." "We don't mind occasional posts that don't lean to netiquette, specially if someone is in a hurry, new to our mail list, using a mobile device that lacks functions, but permanently breaking rules will not make you any friends." -- "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/

On Tue, Jun 10, 2014 at 4:06 PM, Damian Ivanov &lt;damianatorrpm(a)gmail.com&gt; wrote: Sure it does. I've been using GMail on this ML for years. You can bottom/inline post if you're not lazy and can click your mouse (or use keyboards). Look at that,,, a trimmed bottom posted email sent from GMail. C. -- openSUSE 13.1 x86_64, KDE 4.13

2014-06-10 16:10 GMT+02:00 C <>:

When someone is out of technical arguments, one tries to fill formal complaints, right?

So Calros you want me to do what is pro my email provider and (may) against suse ml rules, or did you get confused :)

depends on what you thing is supported: https://productforums.google.com/forum/#!topic/gmail/ckx2MZ8HcYU

Is openSUSE officially demanding to use unsupported features from your mail provider?

> Look at that,,, a trimmed bottom posted email sent from GMail.

...I'm wondering if Felix Miata's posts are biased by money and company interests.

My posts started a long time ago and as well I have been speaking at opensuse conference since years ago.

Gmail does not support bottom posting.

Henne any recommendations on that one please?

On 06/10/2014 10:06 AM, Damian Ivanov wrote: I don't care for the default email app, so I use K9-mail. It's much better.

Anton Aylward wrote: ---- Its the fact that you boot from a ramdisk first, which then boots your hard disk. That's fine if that's your want. But I like the ability to *see* what I am booting... If I change a script in /etc/init.d/XXX.d and reboot, I immediately see the changes. I don't have to regenerate an opaque blob of an initrd. Do you know all the files that go into your initrd? I have a pretty good idea of the files that my system boots from because they are in front of my eyes all the time. But the files in an initrd are not -- they are in an enclosed blob that you need to go out of your way to peer into and become familiar with. I like being familiar with my system's boot procedure -- I tend to read the boot log nearly every time it comes up --- usually because it's a new kernel and I look for changes. If it boots up off an opaque blob, it is human nature not to look to crack open your initrd and read it on a weekly basis.

Systemd *didn't* do the choke points very well. If followed dependencies starting order, but didn't wait for them to finish. This was especially true of legacy scripts and another reason I steered away from systemd. Too many times it tried to mount the lvm volumes BEFORE lvm was finished running. (as one example -- there were others).

On 06/10/2014 04:56 AM, Linda Walsh wrote: I don't understand what point you are trying to make here. I can change a unit and reboot and immediately see the changes. I don't have to regenerate initrd. I don't understand why people told me to regenerate initrd to change my X driver. You keep saying that systemd HAS to do this or CANNOT do that. The fact is that most of the assertions you make are not in fact so. Why? I don't "know" all the files that are /usr/bin or /usr/lib, or all the fonts that are available to me in ... Wherever they live. But I can run 'ls' to find out and I can RTFM and find they live in /usr/share/fonts and run 'ls' on the directories there to see. And in just the same way I can run 'lsinitrd' to see what files go into my initrd. Ah. ' Micromanaging'. When I boot, which as I say is very rarely, I don't micromanage. I get a mug of coffee. When I install a new release (and yes I can do that with my spell checker turned on, Felix) and something goes wrong, as it often does with new releases which are really just the iteration that comes after the beta test and which all to often was released to a deadline (and anyone who has ever been a programmer knows what *that* means) then I can make use of the pages in my book of cheat sheets. See my earlier posting in this thread about command line options for booting for details on that. But as I say, I boot so rarely and when I do it always seems to work 'just fine'. I don't need to micromanage. Heck, I'm sure I could get the system to tell me every library that was referenced with every program I start, but why bother? They work. I'm not a developer doing a trace to debug a new creation. Perhaps I'm being unfair in calling you a 'micro-manager', Linda. We've already agreed that you run a very non-standard version that has been much modified. Perhaps you NEED to watch things very carefully because they are so non-standard. I don't reboot often, as I said. Once upon a time I shut down my desktop and the server under my desk every evening. Perhaps this was a mis-guided thought about saving electricity. (Perhaps I need to tie my treadmill to a generator and storage battery and run my desktop of low voltage batteries...) But it was hell on the hard disk. Just how often do you boot? Just how often do you rebuild your kernel? I don't understand your complaint. I've referenced the pages with boot command options for debugging boot in general and ones for the huge number of options available for systemd debugging, which include confirmation at each step and breaking out into a shell. Please stop saying that systemd can't do things that it very clearly can do, things that are well documented, things that appear in a quick google and things that I've explicitly pointed out very recently. Andrey has already discussed this so I won't repeat his points here. I will point out that you are attributing to systemd a problem with - as you point out - *legacy* scripts. So you are blaming systemd for PAM and library problems? Linda, sometimes its hard to tell whether the problems you describe are intrinsic to the distribution, a result of specific configuration misalignments (PAM can be a terror at times, just like AppArmour!) or are a result of the heavy customization you have made to your system. What you are describing here sounds like the latter. Identification and Authentication problems involving PAM, library search problems due to incorrect or absent LIBPATH (Under normal circumstances, you only need LIBPATH if shared libraries are located in different directories at run time from those that they are in at compile time, and I think that applies to your case) all have nothing to do with systemd or initrd. You only have a single machine? I'm glad I have the Closet of Anxieties and can pull out on old banger. (Many people might keep old bangers in their basement.) I'm glad I have my father's old XP laptop. I'm glad I have my cellphone. I'm glad I have my tablet. Yes, but this thread isn't about how to survive when you have no access at all and the assertions you are making, the mis-information you are spreading, is being done when you have a usable machine and access to the net and manuals -- /"\ \ / ASCII Ribbon Campaign X Against HTML Mail / \ -- To unsubscribe, e-mail: opensuse+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse+owner(a)opensuse.org

On 06/09/2014 07:54 PM, Linda Walsh wrote: I'm confused by the way you've phrased all that. My root is a LVM partition. It been possible to use a LVM partition for some while now. So long as you choose a file system that can be expanded live such as my default choice, reiserFS, then its not a problem.

My opinion is that many people create problems for themselves by the choices they make. If they had made different choices they wouldn't have those problems. I say that about myself too; my problems arise from my choices. The real issue is that most people don't want to admit that, they want to blame other people.

NOT! That's mis-information. The difference between sysvinit and systemd is that the latter identifies things that can be done in parallel. The unit can be parsed to construct a dependency tree. '/usr/share' can be mounted at the same time as '/home' but both are dependent on '/' being mounted. And do on. That is the case with sysvinit as well, but sysvinit does EVERYTHING sequentially. It fails to exploit any inherent parallelism. I recall from my days of C programming, one of the tools was a a call graph generator. It could scan both source code files and object libraries to show what functions depended on what others. With languages such as ALGOL and PASCAL this is clear from the lexical layout, but with C everything is 'top level' lexically. But once libraries come into the operation things can get quite involved: http://domseichter.blogspot.ca/2008/02/visualize-dependencies-of-binaries-a… We also use dependency trees in Zypper/Yast. Again I'm not clear what you're saying. Are you saying that you could accept a systemd that was simply a replacement for /etc/init.d/rc*.d operations? That what you're objecting to is that it covers the whole deal because it is process 1. But the whole point of systemd was to be able to bring the system up without the need for a shell. And your example of backgrounding each script after starting them in sequential order also strikes me as risky. Some of what sysvinit did was sequential because it needed dependencies. Universal parallelism doesn't achieve that. Lennart discussed this in some of his early posting on this subject. If you are going to decry systemd than please do get your facts about it straight and accurate. There's been enough misinformation about systemd and historic UNIX promulgated in these threads already. I must admit I've never needed it. The declarative form of systemd avoid programming mistakes that might appear in shell scripts such as sysvinit uses. However your assertion is incorrect. It does. Having such must at the very least been a part of the development cycle: how else could the developers have seen what was going on? But more specifically: http://freedesktop.org/wiki/Software/systemd/Debugging/ I presume you've read http://en.opensuse.org/SDB:Systemd#Getting_debug_from_systemd and goggled for information on debugging systemd? The latter produced quite a bit of interesting stuff. For example, you can add any of this to the boot command line in grub/grub2 rootwait ignore_loglevel debug debug_locks_verbose=1 sched_debug initcall_debug mminit_loglevel=4 udev.log_priority=8 loglevel=8 earlyprintk=vga,keep log_buf_len=10M print_fatal_signals=1 apm.debug=Y i8042.debug=Y drm.debug=1 scsi_logging_level=1 usbserial.debug=Y option.debug=Y pl2303.debug=Y firewire_ohci.debug=1 hid.debug=1 pci_hotplug.debug=Y pci_hotplug.debug_acpi=Y shpchp.shpchp_debug=Y apic=debug show_lapic=all hpet=verbose lmb=debug pause_on_oops=5 panic=10 sysrq_always_enabled I would suggest tying break=y first. If it doesn't boot than I'll try the above. Also https://wiki.archlinux.org/index.php/systemd#Diagnosing_boot_problems Please stop making assertions about systemd that are incorrect, that could have been cleared up by a simple google or a RTFM. RTFM? Why yes, there is quite a lot of mention of debugging modes and facilities there. --test Determine startup sequence, dump it and exit. This is an option useful for debugging only. --confirm-spawn Ask for confirmation when spawning processes. --system, --user [...] These options are hence of little use except for debugging. And that's quite apart from things to do woth analysis of the tree, dumping and crash exits.

linux-vdso.so.1 (0x00007fffc7531000) / libmount.so.1 => /lib64/libmount.so.1 (0x00007f626560d000) / libc.so.6 => /lib64/libc.so.6 (0x00007f626525d000) / libblkid.so.1 => /lib64/libblkid.so.1 (0x00007f6265022000) / libselinux.so.1 => /lib64/libselinux.so.1 (0x00007f6264dfe000) / /lib64/ld-linux-x86-64.so.2 (0x0000003000000000) / libuuid.so.1 => /lib64/libuuid.so.1 (0x00007f6264bf8000) / libdl.so.2 => /lib64/libdl.so.2 (0x00007f62649f4000) / libpcre.so.1 => /lib64/libpcre.so.1 (0x00007f626478e000) / libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f626456f000) Notice they are all out of lib64 now (for the /usr/bin/mount binary!)

Anton Aylward wrote: ----- I don't have it backwards anymore than you do. I am just using the current paradigm. I 'agree' with you on this issue -- even MS didn't do this -- they kept /windows/system32 reserved for native programs and 32-bit get redirects in the file system and registry. Same holds for 'program files' (native). --- Now you really miss the point. It's not about binary compat -- but source level compat -- being able to do a 'configure/Make' and have it gen a new working "whatever". If you change the paths, you have to change the sources of all the programs.

Yet suse and linux can't do that... too 'compricated'...

Rational arguments are ignored in the end. There is a breakdown in logic here somewhere (maybe I just didn't drink the koolaid?)

On Sat, Jun 7, 2014 at 2:53 PM, jdebert &lt;jdebert(a)garlic.com&gt; wrote: Sun/hOracle started replacing the init system back in Solaris 10.

However at the time, it's been a few years since I've been on a Solaris system, init(1m) wasn't displaced but I don't know if that's still the case.

On 2014-06-07 20:53, jdebert wrote: LOL. That has not been so for decades. System V changed that, not system D. Or even before that.

On 06/07/2014 05:02 PM, Carlos E. R. wrote:

First written in 1994, last revised 2004, a decade ago. What kind of systems were we using back then? My desktop of 1994 ran Convergent SVR4. IIR I had a pair of 1G drives. My desktop of 2003 had a 120G drive. My desktop today has twin 1T drives. So, in 20 years that fits with a Moore's law for disk capacity.

all the user account stuff was moved out of it into /home.

Sadly too many developers respond "WONTFIX" since they don't see this as a valid bug.

On Sat, Jun 7, 2014 at 6:54 PM, Anton Aylward &lt;opensuse(a)antonaylward.com&gt; wrote: This all comes back to how devs want to do things without considering the impact on the installed user base: 1. Xorg removing config files because it should "just work" & those of use with different monitors having to manually run xrandr on login to make the screens work properly(yes, I could write a script, but I shouldn't have to since the old way just worked once configured)

2. KDE4/Gnome3 being a completely new system over KDE3/Gnome2 & people being told to get over it. Which is why we now have TDE & Cinnamin/MATE.

3. Firefox going to a new UI in v29, yet having ready to go extensions to revert it to the "old way".

I could list so many more. When you get right down to it, the majority of the FOSS community uses the software & are not programmers. We get told to learn how to program or get over it.

Sure, the devs contribute their time & code, but they don't consider how the changes will affect the people who use their software.

As you said "Out with the old, in with the new." That's what is important now adays. Why waste time just improving what we have when we can throw the baby out with the bathwater & have a new one?

On 06/07/2014 06:29 PM, Anton Aylward wrote: uh... yeah, widely known not to work and impossible to implement... kind of like what opensuse has become. Linda, might you be willing to share your scripts and techniques for eviscerating systemd? I suspect there would be wide interest in them. I know I'd love to have them to put my system(s) to rights and keep them that way -- To unsubscribe, e-mail: opensuse+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse+owner(a)opensuse.org

Bruce Ferrell wrote: --- Why would I care, Anton? Why do you project your failings on others? ---- I have no issue sharing what I have, BUT, since it was done under 'emergency' conditions I had to cut corners in places, which has made me reluctant to share anything until I could smooth off the edges, so to speak. I.e. people using the scripts 'now' would have to deal with little things like: ##inline data (should be in external file) # eth5 is in twice -- once for before bonding once for after; map hw2if=( [00:15:17:bf:be:b2]=eth0 [00:15:17:bf:be:b3]=eth1 [00:26:b9:48:71:e2]=eth2 [00:26:b9:48:71:e4]=eth3 [a0:36:9f:15:c9:c0]=eth4 [a0:36:9f:15:c9:c2]=eth5 ) map if2hw=( [eth0]=00:15:17:bf:be:b2 [eth1]=00:15:17:bf:be:b3 [eth2]=00:26:b9:48:71:e2 [eth3]=00:26:b9:48:71:e4 [eth4]=a0:36:9f:15:c9:c0 [eth5]=a0:36:9f:15:c9:c2 ) --- Also haven't figured out why it doesn't work reliably at boot (it works great when I run it by hand, which is unfortunate. But I made another change and am hoping it might work (I don't reboot my system that often, so usually wait for some other reason to reboot than just retesting this script. (above script written in bash, sets normal names on the interfaces by their hardware ethernet addrs). But it *should* read such things from a separate config... so "rough edges"... It was my intention to put them online when I got them to some ready state, but historically, I take way too long to do that, being one of those perfectionist types. I'm trying to keep most stuff in bash, but the script to test for bad symlinks and dependencies was more complex so went to perl. But too many *holes would have a field day examining anything I put out with a microscope -- have seen it before -- releasing images where @ 300-500% size, you could see some fine-detail problems --- it wasn't designed for over magnification...irrelevant. It was only my 3rd work... irrelevant.... etc etc etc... Or ... I released a pretty good module on CPAN -- and got http://ledgersmbdev.blogspot.co.uk/2013/11/on-cpan-community-and-p-case-stu… Never mind that it was my first CPAN module, never mind that I was asked to prove my concepts by writing such a module, never mind that he doesn't really critique the module, but the 'name', the CPAN porting difficulties (which were overcome after less than a month of being on CPAN), it's all "Fox News" quality commentary in their typical 'fair and balanced format'. He didn't even know what the module did before he wrote it! He didn't even bother to read the documentation, but it was good enough for his "case study". Or people's ignorance and malevolent intent of deliberately lying about the module and shutting out my answers to them by making sure that my response isn't shown (it's hidden as an "unhelpful review") -- on 'P', and 'mem'...(the later one of them copied part of its functionality because it was useful while saying they'd never use it in production code...idiots. Of course if you look at my modules (http://search.cpan.org/~lawalsh/) All of them except 1 with no tests show 100% passing (over 300 different testers) --- a stark contrast to the initial liar who wrote his case study. Maybe if enough people from here voted up those modules that they marked down and marked their trashy reviews as 'not helpful', it might reverse some people's feelings.. As it is, I don't even know where I'd release such "specialty" scripts. -- To unsubscribe, e-mail: opensuse+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse+owner(a)opensuse.org

On 06/09/2014 12:06 AM, Damian Ivanov wrote: This diatribe against Linda is interesting to me. It's obvious that we all live in our own "frames of reference", or "bubbles" if you will. People/things/ideas outside of our own personal bubbles cause suspicion and hostility. I'm sure that Damian, Dirk and Linda are fine, upstanding, and honest people, but they are perceived by those outside their bubbles as being "unhelpful". Could it be that like/dislike of systemd is correlated with the political bubbles in which we live? Could appreciation of systemd come from Liberals? Fear and loathing of systemd comes from Conservatives? Does political polarization extend into our technical world? Maybe the answer here is for us to expand our bubbles? Does the truth lie in that area in the middle where the bubbles overlap? For the record, I'm conservative (surprise!) and I am suspicious of systemd. Linda: are you conservative? Damian: are you liberal? Dirk: are you conservative? Can your opinion of systemd be correlated with how you vote on election day? (sorry for the off-topic rumination, my caffeine fix hasn't kicked in yet) Regards, Lew

We all use our computers differently. Me, I'm just an average home user. I surf the web. Do e-mail. The most strenuous things I do are create web pages and I use Winff with avconv to convert video once a week. I only know one command line string by heart. That one installs Synaptic on a clean install because the KDE package handlers suck big time. I have no idea what systemd is or does. I couldn't care less as long as my computer boots up and works. See, I'm the computer user that everyone says Linux isn't ready for.

I suspect the ones doing all the complaining are the power users that like to get into the systems guts and tweak all the settings. Change means that what they want to do no longer works. That upsets them. They want things to remain static forever. Someone much smarter than myself one remarked that the only constant is change. Personally, I believe the change is towards entropy, but that's another story.

If some people spent half as much effort learning how to work with changes as they did crying about it things might just move along smoother.

On 06/09/2014 12:33 PM, Carlos E. R. wrote: I think if more people had your attitude......................... If some people spent half as much effort learning how to work with changes as they did crying about it things might just move along smoother.

On 06/09/2014 01:33 PM, Carlos E. R. wrote: Sort of like the Serenity payer http://en.wikipedia.org/wiki/Serenity_Prayer which has been attributed to many sources.

Personally I like, "Ask yourself what difference it will make in a hundred years." Amazing how many things won't/don't matter all that much.

On 2014-06-09 22:46, jdd wrote: LOL. I prefer XFCE 470.

On 06/09/2014 01:33 PM, Carlos E. R. wrote: Sort of like the Serenity payer http://en.wikipedia.org/wiki/Serenity_Prayer which has been attributed to many sources. -- /"\ \ / ASCII Ribbon Campaign X Against HTML Mail / \ -- To unsubscribe, e-mail: opensuse+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse+owner(a)opensuse.org

This diatribe against Linda is interesting to me. It's obvious that we all live in our own "frames of reference", or "bubbles" if you will. People/things/ideas outside of our own personal bubbles cause suspicion and hostility. I'm sure that Damian, Dirk and Linda are fine, upstanding, and honest people, but they are perceived by those outside their bubbles as being "unhelpful".

Could it be that like/dislike of systemd is correlated with the political bubbles in which we live? Could appreciation of systemd come from Liberals? Fear and loathing of systemd comes from Conservatives? Does political polarization extend into our technical world?

Maybe the answer here is for us to expand our bubbles? Does the truth lie in that area in the middle where the bubbles overlap?

For the record, I'm conservative (surprise!) and I am suspicious of systemd. Linda: are you conservative? Damian: are you liberal? Dirk: are you conservative? Can your opinion of systemd be correlated with how you vote on election day?

Where, then you would place "Agile Programming" and the "Release Early//Release Often" approach to application & System development?

I respectfully disagree about UNIX "just working".

On 06/09/2014 02:00 PM, Lew Wolfgang wrote: NOT! Towards the end of the 1980s and early 1990s there were a large number of x86 systems. You might have heard of, for example, SCO.

But there was also a number small firms , such as Convergent, which grew big enough to swallow SCO. Oh, and there was also this port of UNIX to a variety of microprocessors including the 8086 and 80286 called XENIX. It was from Microsoft.

Long ago I got the first Spanish edition of the Tanenbaum "operating systems" book. The last part of the book had a printed copy of the Minix source code. I had no means of downloading it. I actually considered hand typing the two hundred pages or so. It was the closest thing I dreamt of trying some thing close to Unix.

Le 09/06/2014 19:38, Anton Aylward a �crit : things that "just works" are soon boring, and a bit later begin not to work so well. Then the fun is to make new things until they become to "just work". if this wasn't true, Linus would never have invented Linux :-), after all unix "just worked" :-)

jdd

You might want to investigate the history of the words Democrat and Republican as used as political party names in Nobamaland.

Democrat = Far Left Republican = Far Right

On 06/09/2014 01:33 PM, Felix Miata wrote: Let me make it simple. Democrat = Far Left Republican = Far Right

For the record, I'm conservative (surprise!) and I am suspicious of systemd. Linda: are you conservative? Damian: are you liberal? Dirk: are you conservative? Can your opinion of systemd be correlated with how you vote on election day?

Out with the old, in with the new. Here's something else for Aaron and Linda to complain about: https://www.mnot.net/blog/2014/06/07/rfc2616_is_dead

You may not care about performance -- and you may have a family that does timesharing. Little kids might do that.. But when they get into rebellious teens... that won't cut it in MOST families. But some families live without TV and internet

On Friday 06 June 2014, Carlos E. R. wrote:

Don't know the exact definition but I would call it multi-seat when 2 persons are working simultaneously with 2 keyboards on same machine. Doesn't matter if each of them has two, one or only a half monitor.

http://en.wikipedia.org/wiki/Multiseat_configuration sure it can be on one monitor if you manage to split the monitor so 2 X servers can run (and be active) at the same time and both users have their independent session.

Sounds already like lots of "frickeln" your approach. systemd does it hotplug and clean.

2014-06-08 13:42 GMT+02:00 Ruediger Meier &lt;sweet_f_a(a)gmx.de&gt;de>: > On Sunday 08 June 2014, Damian Ivanov wrote: >> http://en.wikipedia.org/wiki/Multiseat_configuration >> sure it can be on one monitor if you manage to split the monitor >> so 2 X servers can run (and be active) at the same time and both >> users have their independent session. > > That's very easy if you run each "seat X-server" within > (borderless) Xephyr windows. You can resize and place the windows > across half, one or x monitors dynamically as needed. if one user > is away for a coffee then the other one can resize his Xephyr to > the full available underlying real X-Server. > > This solution is completely independent of how many GPUs or > monitors you want to use. > > Simplified I start such second seat but this script: > ------------ > disp=":11" > > # as root > MOUSE="/dev/input/by-id/usb-Logitech_USB_Optical_Mouse-event-mouse" > KBD="/dev/input/by-id/usb-Dell_Dell_USB_Keyboard-event-kbd" > > export DISPLAY=:0 > Xephyr \ > "${disp}" \ > -ac \ > -screen 1280x1024 \ > -dpms \ > -keybd > "evdev,,device=${KBD},xkbrules=evdev,xkbmodel=evdev,xkblayout=de,xk >bvariant=nodeadkeys,xkboptions=compose:rwin" \ -mouse > "evdev,,device=${MOUSE}" \ > & > sleep 2 > > # as user > export DISPLAY="${disp}" > startkde # or whatever > ----------- > > Since systemd, logind, new udev, dbus deps or whatever I got > several kind of problems. As workaround now I run Xephyr as root > and "startkde" as the user which wants to use the new session. > > cu, > Rudi > -- > To unsubscribe, e-mail: opensuse+unsubscribe(a)opensuse.org > To contact the owner, e-mail: opensuse+owner(a)opensuse.org

On 06/08/2014 09:20 AM, Ruediger Meier wrote: If you read the links that I gave earlier you would have the answer to that. No need to issue a command,

each seat is presented with the graphical login.

On Sunday 08 June 2014, Damian Ivanov wrote: LOL, where exactly is the "frickeln" part? I start a second seat by typing just one command. How would you do this with systemd? What kind of hotplug could be used? Second user appears in front of the desk and is automatically logged in or what? How would it know which keyboard is placed in front of the left monitor? Or what if you still want to use one of three keyboards for both monitors? How would systemd automatically decide how many montors should be used for the one or the other user? Does it run on single monitor at all? -- To unsubscribe, e-mail: opensuse+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse+owner(a)opensuse.org

If I were to unlink and move back those binaries and put in a reverse link, say, do you imagine it would affect my system? I think not.

Damian Ivanov wrote: ---- Since when? And how do I upgrade or add new drivers without rebooting? ---- Everything is part of PID 1 now. Its indivisible ... --- Multiseat? Explain why a distro aimed primarily at users needs multiseat? Seems very few people use opensuse as a server (well, 'cept me -- but I know I don't need multiseat). So why does anyone on this list need multiseat?

Certainly, systemd has a very corporate feel to it, but how

is that a good fit for OpenSuSE which seems to be more desktop and laptop users than anything else?

PID 1 is special, and there's no need to have a LOGIN DEAMON as part of PID 1. PID 1 should be starting daemons, not taking on the role of the daemons themselves

Why does systemd need to run as '1' again? It's a matter of boundaries more than anything.

Carlos E. R. wrote:

So if "linda-init" starts systemd, it will bring up rest of system w/o needing to be '1', right? I.e. no problem?

Damian Ivanov wrote: https://plus.google.com/+LennartPoetteringTheOneAndOnly/posts/8RmiAQsW9qf#+…

Damian Ivanov wrote: You don't konw that the fuck you're talking about. If the syslog deamon has been removed, then I can't sent logging messages to a standard file handle which can (in the startup script) be sent to the syslog process. Instead, deamons NOW have to call a special logging function in systemd to have anything logged. Thus, now the applications have to be aware of systemd... which then makes systemd NON-REPLACEABLE. haven't the past 30 years of Microsoft's machinations taught you anything about the inherent evilness of "embrace and extend" programming. Systemd is being designed to be a one-way trapdoor, so that, if/when people realize that it's not all it's been sold as being (in fact, not even close) then it will be impossible to replace it without ALSO rewriting tons of other code in other projects. That reason alone makes it stupid for any distribution to adopt it. -- To unsubscribe, e-mail: opensuse+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse+owner(a)opensuse.org

Damian Ivanov wrote: So, we're supposed to run TO loggin deamons now.... And this is an improvement how, exactly, Damian? Do you understand how absolutely idiotic that "solution" is? It's not a solution, it's a pollution. -- To unsubscribe, e-mail: opensuse+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse+owner(a)opensuse.org

Damian Ivanov wrote: 1. systemd doesn't produce ASCII (or for that matter, UTF) log files, it produces binary blob log files. Which means you can't just browse through a log file using grep, awk, and/or more (or less). 2. systemd eliminates separate log files... so if you're looking for ntp messages, we no longer have ntp log files... now we have to wade through the whole combined (binary only) logfile 3. The old time tested method of keeping log files small and maneagble (daily rotation) is now also broken, YATFUBSD (Yet Another Thing Fucked Up By SystemD) Obviously, you're either ignorant or making up more lies. Which is it? Do you want to keep on playing this idiotic game where you make false assertions, and I point out how the truth differs from what you say it is? -- To unsubscribe, e-mail: opensuse+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse+owner(a)opensuse.org

Damian Ivanov wrote: I have. That's how I found out these things. But that's ok, keep living the lie. -- To unsubscribe, e-mail: opensuse+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse+owner(a)opensuse.org

1. systemd doesn't produce ASCII (or for that matter, UTF) log files, it produces binary blob log files.

Which means you can't just browse through a log file using grep, awk, and/or more (or less).

2. systemd eliminates separate log files... so if you're looking for ntp messages, we no longer have ntp log files... now we have to wade through the whole combined (binary only) logfile