Araluen wrote:
On Sun, 2014-06-01 at 16:13 -0400, Dirk Gently wrote:
Linda Walsh wrote:
Felix Miata wrote:
WRT openSUSE: The fence is down. The barn is empty. For all practical purposes the herd has been lost. If you don't want a system dependent on systemd...
Well, that's until it goes a bit too far.
Remember, it's just something to help help your system boot faster by doing parallel boot. And now? Seems like it fell a bit short of that initial goal, as well. If you already booted direct from HD and used parallel boot in the run scripts, there seems to be a slowdown. What I don't understand is why people keep converting more to systemd, when it didn't make good on its initial promises.
More importantly, shaving a couple of seconds off of boot time is really sooooper-dooooper important, why, exactly?
Systemd is doing the equivalent of fouling up the reliability of all the critical control systems of an automobile, all for the stated goal of gettin the engine to start in 3 seconds rather than 4.
The rsultant calamities would wind up in court as criminal malfeasance.
Nobody has yet explained WHY saving a couple of seconds at boot time is ooh soooo important (And I remember the days when unix systems with only 1 MB of memory took 15 minutes to boot up) that it justifies fucking up the entire concept of run-levels, and using well-debugged shell-scripts rather than some pulled-out-of-the-ass custom scripting language which is NOT anywhere close to fully debugged, and config files full of XML crud.
I think we both agree that the net effect of the trade-offs is not beneficial to users or system administrators, but it sure does stroke the ego of Lennert Poettering and Kay Sievert. There's going to be a special place in hell for those two.
Well then, if we are compromising system stability for such a negotiable benefit, how do we turn the situation around? Or is it full speed ahead and damn the torpedoes.
Unlike Farrugut's order at the Battle of Mobile Bay, going full-speed ahead is not going to achieve any useful objectives, yet the dangers of systemd are still there.
For one, systemd is making APPLICATIONS now dependant on the systemd API, which means when even the biggest fanboys here, at Redhat, and other distributions finally are forced to admit that systemd is a crock of shit.... we won't be able to remove it.... in other words, unlike Farragut, the probability of eventually being blown out of the water by a systemd torpedo is 100%.
SysV init has problems, but without a doubt, it does NOT present itself as being a massive security hole, nor present the risk of making a system unbootable.
Cheers, Mark
I don't know what Anton said, I did.
If we won't be able to remove systemd without major troubles - great, finally a good API around for long time. No matter how much you whine about systemd it's there. And it will be. Good :-)
2014-06-02 8:26 GMT+02:00 Dirk Gently dirk.gently00@gmail.com:
Araluen wrote:
On Sun, 2014-06-01 at 16:13 -0400, Dirk Gently wrote:
Linda Walsh wrote:
Felix Miata wrote:
WRT openSUSE: The fence is down. The barn is empty. For all practical purposes the herd has been lost. If you don't want a system dependent on systemd...
Well, that's until it goes a bit too far.
Remember, it's just something to help help your system boot faster by doing parallel boot. And now? Seems like it fell a bit short of that initial goal, as well. If you already booted direct from HD and used parallel boot in the run scripts, there seems to be a slowdown. What I don't understand is why people keep converting more to systemd, when it didn't make good on its initial promises.
More importantly, shaving a couple of seconds off of boot time is really sooooper-dooooper important, why, exactly?
Systemd is doing the equivalent of fouling up the reliability of all the critical control systems of an automobile, all for the stated goal of gettin the engine to start in 3 seconds rather than 4.
The rsultant calamities would wind up in court as criminal malfeasance.
Nobody has yet explained WHY saving a couple of seconds at boot time is ooh soooo important (And I remember the days when unix systems with only 1 MB of memory took 15 minutes to boot up) that it justifies fucking up the entire concept of run-levels, and using well-debugged shell-scripts rather than some pulled-out-of-the-ass custom scripting language which is NOT anywhere close to fully debugged, and config files full of XML crud.
I think we both agree that the net effect of the trade-offs is not beneficial to users or system administrators, but it sure does stroke the ego of Lennert Poettering and Kay Sievert. There's going to be a special place in hell for those two.
Well then, if we are compromising system stability for such a negotiable benefit, how do we turn the situation around? Or is it full speed ahead and damn the torpedoes.
Unlike Farrugut's order at the Battle of Mobile Bay, going full-speed ahead is not going to achieve any useful objectives, yet the dangers of systemd are still there.
For one, systemd is making APPLICATIONS now dependant on the systemd API, which means when even the biggest fanboys here, at Redhat, and other distributions finally are forced to admit that systemd is a crock of shit.... we won't be able to remove it.... in other words, unlike Farragut, the probability of eventually being blown out of the water by a systemd torpedo is 100%.
SysV init has problems, but without a doubt, it does NOT present itself as being a massive security hole, nor present the risk of making a system unbootable.
Cheers, Mark
-- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Damian Ivanov wrote:
I don't know what Anton said, I did.
If we won't be able to remove systemd without major troubles - great, finally a good API around for long time.
NO, Damian, that is the exact OPPOSITE of good.
NO application should be dependant upon the init system. NONE EVER. Applications shouldn't even have awareness of the init system.
Same of deamons.
Yet Systemd is being written so that deamons and some apps MUST call systemd
This REMOVES the concept of modularity.
And systgemd violates the VERY well time-tested Unix principle of do one thing, and do it well.
The init system should start up the system -- by running the appropriate processes to do system configuration, and deamon-starting.
Instead, what systemd does is try to configure EVERY FUCKING THING, and then completely takes over dozens of disparate functions (mount, login, system logging, network configuration and traffic, cron...etc, etc.), and rather than rely upon shell scripts (which used the well-tested shells as interpreters), they have gone and invented some new language (with who knows how many bugs)... all written in some incomprehensible xml bullshit.....for no reason that is good for Linux at all.
Let me say that again... for no reason that is good for LINUX.
Sievert and Poettering may be able to write a lot of code, but, there's a reason Linus cut off Sievert's commit privileges for the kernel -- becauswe rather than fix the fucking bugs in systemd, he was rewriting the kernel to adapt to ignore systemd's bugs.
I don't trust ANY coder who insists that other code be adapted to his buggy pile of shit, rather than just debug his own buggy pile of shit. And neither should you if you have even 10% of a brain.
No matter how much you whine about systemd it's there. And it will be. Good :-)
Bull fucking shit.
Kay Sievert and Lennert Poettering have no specific plan. They're literally making it up as they go along, gobbling up one daemon after another, which will continue until Linux looks like the retarded pile of crap called Windows.
That's not good... it's downright stupid. Asinine, in fact.
2014-06-02 8:26 GMT+02:00 Dirk Gently dirk.gently00@gmail.com:
Araluen wrote:
On Sun, 2014-06-01 at 16:13 -0400, Dirk Gently wrote:
Linda Walsh wrote:
Felix Miata wrote:
WRT openSUSE: The fence is down. The barn is empty. For all practical purposes the herd has been lost. If you don't want a system dependent on systemd...
Well, that's until it goes a bit too far.
Remember, it's just something to help help your system boot faster by doing parallel boot. And now? Seems like it fell a bit short of that initial goal, as well. If you already booted direct from HD and used parallel boot in the run scripts, there seems to be a slowdown. What I don't understand is why people keep converting more to systemd, when it didn't make good on its initial promises.
More importantly, shaving a couple of seconds off of boot time is really sooooper-dooooper important, why, exactly?
Systemd is doing the equivalent of fouling up the reliability of all the critical control systems of an automobile, all for the stated goal of gettin the engine to start in 3 seconds rather than 4.
The rsultant calamities would wind up in court as criminal malfeasance.
Nobody has yet explained WHY saving a couple of seconds at boot time is ooh soooo important (And I remember the days when unix systems with only 1 MB of memory took 15 minutes to boot up) that it justifies fucking up the entire concept of run-levels, and using well-debugged shell-scripts rather than some pulled-out-of-the-ass custom scripting language which is NOT anywhere close to fully debugged, and config files full of XML crud.
I think we both agree that the net effect of the trade-offs is not beneficial to users or system administrators, but it sure does stroke the ego of Lennert Poettering and Kay Sievert. There's going to be a special place in hell for those two.
Well then, if we are compromising system stability for such a negotiable benefit, how do we turn the situation around? Or is it full speed ahead and damn the torpedoes.
Unlike Farrugut's order at the Battle of Mobile Bay, going full-speed ahead is not going to achieve any useful objectives, yet the dangers of systemd are still there.
For one, systemd is making APPLICATIONS now dependant on the systemd API, which means when even the biggest fanboys here, at Redhat, and other distributions finally are forced to admit that systemd is a crock of shit.... we won't be able to remove it.... in other words, unlike Farragut, the probability of eventually being blown out of the water by a systemd torpedo is 100%.
SysV init has problems, but without a doubt, it does NOT present itself as being a massive security hole, nor present the risk of making a system unbootable.
Cheers, Mark
-- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Dirk,
The wonderful part about Linux in general is that it is open source. Someone somewhere didn't like the way things were being done so they made a version they did like. That's why we have so many versions of Linux to choose from instead of a monolithic structure like Mac OS or Windows. With Linux if you don't like the way one version does something you are free to go to a version that does things the way you want or create your own. Life is good that way.
You sitting here whining like a two year old on a tantrum isn't going to change anything except make you look like an ass. If you don't like the way OpenSuse is going move to another version or create your own. It's as simple as it gets.
To everyone else,
Dirk is a jackass that just likes to stir up trouble. Best solution is just delete anything from him and not reply to his messages and hopefully he will soon crawl back in his hole. If you don't he will stretch this tantrum out for as long as possible.
Damian Ivanov wrote:
I don't know what Anton said, I did.
If we won't be able to remove systemd without major troubles - great, finally a good API around for long time. No matter how much you whine about systemd it's there. And it will be. Good :-)
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.
Nearly every measure of software quality would label this a bad project -- from design, from non-general API's, monolithic design (all running as 'root', gee, and no one sees a problem with that?).
Unix/Linux has had power and growth because parts are replaceable.
Systemd is designing "out" all replaceable parts. It's designing out the strengths of linux.
Linus refused to go with 1 security model and instead demanded the LSM base to allow multiple models to live together. Now someone comes along and does just the opposite and this is considered good?
What crazed out world is this? This is a maintenance and security nightmare. This is NOT open software -- this is antithetical to almost every principle of open software. It's also (not that anyone seems to care) NOT going to be POSIX compatible, as POSIX compatible specifies unix-like systems -- not ones that have removed most of the unix features.
He claims that his logind, udevd, dbusd all are dead and combined into systemd. I want to use cgroups to implement my own process and daemon control, yet systemd is supposedly going to disallow such changes. It's taking over linux in a very bad way.
Um... no one is thinking megalomaniac? This is NOT good for open software and is exemplary of bad software design -- with most of the linux community being sucked up to deal with adapting to this crazy scheme.
Software monocultures are unhealthy. When will people learn??
On Tue, 03 Jun 2014 20:09:35 -0700 Linda Walsh suse@tlinx.org wrote:
Damian Ivanov wrote:
I don't know what Anton said, I did.
If we won't be able to remove systemd without major troubles - great, finally a good API around for long time. No matter how much you whine about systemd it's there. And it will be. Good :-)
Since when are large monolithic programs either good or maintainable?
It's NOT modular design -- that is generally considered *BAD**...
Monoliths are monopolies.
It can't be broken apart (says its creator) -- again, these are all things that speak of bad design.
Windoze terminology is used in the documentation, i.e., runlevel 1 is no longer "single user" but is now "rescue mode". And systemd.conf looks an awful lot like a windoze config file.
Wouldn't be something if this turned out to be done under external pressure and eventually became Not Secure Anymore?
jd
jdebert wrote:
On Tue, 03 Jun 2014 20:09:35 -0700 Linda Walsh suse@tlinx.org wrote:
Damian Ivanov wrote:
I don't know what Anton said, I did.
If we won't be able to remove systemd without major troubles - great, finally a good API around for long time. No matter how much you whine about systemd it's there. And it will be. Good :-)
Since when are large monolithic programs either good or maintainable?
It's NOT modular design -- that is generally considered *BAD**...
Monoliths are monopolies.
It can't be broken apart (says its creator) -- again, these are all things that speak of bad design.
Windoze terminology is used in the documentation, i.e., runlevel 1 is no longer "single user" but is now "rescue mode". And systemd.conf looks an awful lot like a windoze config file.
That's both interesting and quite revealing.
Wouldn't be something if this turned out to be done under external pressure and eventually became Not Secure Anymore?
jd
As always what to expect from systemd haters just some bullshit.
He claims that his logind, udevd, dbusd all are dead and combined into systemd.
Source?
2014-06-04 7:18 GMT+02:00 Dirk Gently dirk.gently00@gmail.com:
jdebert wrote:
On Tue, 03 Jun 2014 20:09:35 -0700 Linda Walsh suse@tlinx.org wrote:
Damian Ivanov wrote:
I don't know what Anton said, I did.
If we won't be able to remove systemd without major troubles - great, finally a good API around for long time. No matter how much you whine about systemd it's there. And it will be. Good :-)
Since when are large monolithic programs either good or maintainable?
It's NOT modular design -- that is generally considered *BAD**...
Monoliths are monopolies.
It can't be broken apart (says its creator) -- again, these are all things that speak of bad design.
Windoze terminology is used in the documentation, i.e., runlevel 1 is no longer "single user" but is now "rescue mode". And systemd.conf looks an awful lot like a windoze config file.
That's both interesting and quite revealing.
Wouldn't be something if this turned out to be done under external pressure and eventually became Not Secure Anymore?
jd
-- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Damian Ivanov wrote:
As always what to expect from systemd haters just some bullshit.
He claims that his logind, udevd, dbusd all are dead and combined into systemd.
Source?
https://plus.google.com/+LennartPoetteringTheOneAndOnly/posts/8RmiAQsW9qf#+L...
(don't blame me for such a long URL -- it's from google!)
Even if the URL is 1000 character long I wouldn't blame you.
udevd is not mentioned in the post. udev - They are in one and the same tarball, that's it. An init should perfectly know about you hardware and handle it logind - what's wrong with that being part of PID 1 kdbus - kernel dbus isn't even officially there so this is not a regression, it's technically different from user-space dbus. e.g multiseat - how did work before systemd (logind) and how now with it? logind made it work properly, before that there was no proper multiseat.
2014-06-04 12:42 GMT+02:00 Linda Walsh suse@tlinx.org:
Damian Ivanov wrote:
As always what to expect from systemd haters just some bullshit.
He claims that his logind, udevd, dbusd all are dead and combined into systemd.
Source?
https://plus.google.com/+LennartPoetteringTheOneAndOnly/posts/8RmiAQsW9qf#+L...
(don't blame me for such a long URL -- it's from google!)
-- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Wednesday 04 June 2014, Damian Ivanov wrote:
Even if the URL is 1000 character long I wouldn't blame you.
udevd is not mentioned in the post. udev - They are in one and the same tarball, that's it.
That's it? I don't think so if you read Poetterings first comment.
Poettering: "[...] I mean, it's a question of honesty: do I personally care whether people can easily run Upstart or whatever with the tools we ship in systemd? Only to a very small degree. [...]"
What kind of a moron is he? First merging udev, lying about his good intentions, then plan to break everything which is using it.
Udev was only merged to be completely free to break it. So it surely matters which tarball it belongs too. Good that at least the kernel itself is still on the right track. Banning Poetterings's abettor Sievers was good signal.
cu, Rudi
-- We Are the Borg. You Will be Assimilated. Resistance is Futile.
On 06/04/2014 08:04 AM, Ruediger Meier wrote:
We Are the Borg. You Will be Assimilated. Resistance is Futile.
If less than 100Ω. ;-)
Damian Ivanov wrote:
Even if the URL is 1000 character long I wouldn't blame you.
udevd is not mentioned in the post. udev - They are in one and the same tarball, that's it. An init should perfectly know about you hardware and handle it
---- Since when? And how do I upgrade or add new drivers without rebooting?
logind - what's wrong with that being part of PID 1
---- Everything is part of PID 1 now. Its indivisible ...
e.g multiseat - how did work before systemd (logind) and how now with it? logind made it work properly, before that there was no proper multiseat.
--- 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?
On 2014-06-05 01:21, Linda Walsh wrote:
Multiseat? Explain why a distro aimed primarily atusers 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?
We do. openSUSE is not only for the desktop.
Carlos E. R. wrote:
On 2014-06-05 01:21, Linda Walsh wrote:
Multiseat? Explain why a distro aimed primarily atusers 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?
We do. openSUSE is not only for the desktop.
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).
You are full of bullshit. Multiseat was a hack. Any clue of how the XServer did it? You do not (read the old setup guides - multiseat was broken and just made to work by a hack). I own multiseat devices. You should not enforce an old principle @the cost of system stability, API stability, performance etc. You should try to adhere to these *guidelines* (which I do) but not at any cost. To speak in your language: Cut off your legs and be happy you choose the right philosophy. I do *not* care even if a unix philosophy is not adhered to @places where it makes sense to do so. Why are you not complaining that the Linux kernel doesn't adhere to it, the only kernel that would adhere to unix philosophies would be a mach/micro kernel.
2014-06-05 3:26 GMT+02:00 Dirk Gently dirk.gently00@gmail.com:
Carlos E. R. wrote:
On 2014-06-05 01:21, Linda Walsh wrote:
Multiseat? Explain why a distro aimed primarily atusers 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?
We do. openSUSE is not only for the desktop.
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@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 06/05/2014 01:27 AM, Damian Ivanov wrote:
You are full of bullshit. Multiseat was a hack.
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.
Thank you Anton for being objective and incredibly competent. The world needs more people like you.
2014-06-05 15:19 GMT+02:00 Anton Aylward opensuse@antonaylward.com:
On 06/05/2014 01:27 AM, Damian Ivanov wrote:
You are full of bullshit. Multiseat was a hack.
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 keyboardsOn 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@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2014-06-05 15:31 (GMT+0200) Damian Ivanov composed:
... The world needs more people like you.
And less people who lazily pollute mail and archive servers with me too style full quote top posts like you.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2014-06-05 15:19, Anton Aylward wrote:
...
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
And systemd is not a single big binary, it is divided in several modules. I don't know how many.
|> USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND |> root 1 0.0 0.0 197828 5020 ? Ss May24 0:22 /sbin/init |> |> |> Telcontar:~ # l /sbin/init |> lrwxrwxrwx 1 root root 26 Mar 4 01:49 /sbin/init -> ../usr/lib/systemd/systemd* |> Telcontar:~ # l /usr/lib/systemd/systemd |> -rwxr-xr-x 1 root root 1072512 Feb 24 12:05 /usr/lib/systemd/systemd* |> Telcontar:~ #
That's just 1 MB big blob. Huge. :-)
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.
Thanks for all that explaining. I needed it. :-)
- -- Cheers / Saludos,
Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
On 06/05/2014 11:32 AM, Carlos E. R. wrote:
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
And systemd is not a single big binary, it is divided in several modules. I don't know how many.
|> USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND |> root 1 0.0 0.0 197828 5020 ? Ss May24 0:22 /sbin/init
Perhaps you should consider a few other things that are shown there.
There is a lot of 'special case' code in systemd, such as the backward compatibility that lets it deal with 'init' style commands. This being a virtual memory system that code isn't loaded unless its needed :-)
That is reflected by the very low value in RSS.
There are many programs like that. Perhaps they have many modules that are not often used. Darktable is one example of that. Perhaps they have complex initialization odes - "use once and throw away".
In such cases the virtual memory size doesn't matter.
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.
In many ways systemd is like the original Bourne shell. By that I mean the shell that had no input from the C-shell, none of the user-interaction and command line editing, history and other features in BASH. It is a parser and dispatcher. It relies on external programs to do its work, just like in the sysvinit script the shell scripts relied on external programs to slice and dice and carry out many functions. The sysvinit script could _almost_ have be run with the old V7 shell since they don't need the user interaction extensions. Of course BASH, like the Korn shell, has functional extensions such as pattern matching (so it doesn't always need to run 'grep') and arithmetic (so it doesn't need to run 'eval') and 'echo is also built in.
The main difference is that that systemd doesn't have all it uses built in, and that the control 'scripts' it interprets are declarative rather than procedural -- they are termed units. But both are interpreters and dispatchers.
By comaprison
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 31253 anton 20 0 1585384 367284 39524 S 12.57 9.206 37:54.22 thunderbird-bin 31255 anton 20 0 1719832 701064 52840 S 6.946 17.57 74:22.50 firefoxWrote31050 anton 20 0 359388 23156 17544 S 0.000 0.580 0:00.21 kdeinit4Wrote31072 anton 20 0 531424 22188 13132 S 0.000 0.556 0:02.05 ksmserverWrote31115 anton 20 0 682716 27644 17204 S 0.000 0.693 0:00.70 kmix 31126 anton 20 0 363112 35808 16160 S 0.000 0.898 0:01.03 basket 31135 anton 20 0 14612 3028 1584 S 0.000 0.076 0:00.04 bash
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.
On 2014-06-05 20:20, Anton Aylward wrote:
On 06/05/2014 11:32 AM, Carlos E. R. wrote:
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
And systemd is not a single big binary, it is divided in several modules. I don't know how many.
|> USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND |> root 1 0.0 0.0 197828 5020 ? Ss May24 0:22 /sbin/init
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.
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.
The old inittab file had lines for attending to the modem, triggered from PID 1. Either for console and remote access, or for fax. But I don't think I was using that feature that instant.
...
Compared to the resident parts of firefox and thunderbird items such as systemd and BASH are insignificant.
Indeed :-) Yesterday, my firefox was using 2 gigs RES. (!).
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.
Perhaps you didn't notice I was being ironic? ;-)
On 06/06/2014 07:47 AM, Carlos E. R. wrote:
Perhaps you didn't notice I was being ironic? ;-)
That is indeed the case. However ...
http://www.fastcompany.com/3031492/fast-feed/the-secret-service-is-seeking-s...
No doubt they will, eventually, do a better job than I am currently.
On 06/06/2014 07:47 AM, Carlos E. R. wrote:
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.
Yes, that's one of the problems with the old init and sysvinit, its sequential. The model is 'for each S*...'. So if one gets hung up in a forever loop it can't proceed to the next.
Now I only have to worry about things like the file system doing a sync/rebalance and eating all the CPU. That happened along the development path or BtrFS at one time :-) All the way up to load average 23, and back down a few minutes later!
Aaron is wrong: Linux is not UNIX. Linux offers much more opportunity for experimentation and development than UNIX ever did.
Anton Aylward wrote:
On 06/05/2014 01:27 AM, Damian Ivanov wrote: 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".
---- Bzzzt. wrong. Bash as built by openSuse maybe, but those features are configurable when you build the product.. Most importantly -- using bash doesn't preclude being able to use the other utils that it has built-in. Let's see you use SysV init and and a separate resource controller w/systemd. It precludes replacement modules being able to take part. Bash never required moving binaries from /bin to /usr/bin and never dictated how I should boot.
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>
---- Which is nice in a corporate setting, but you will need special hardware
Systemd is not implementing multi-seat, it is keeping track of resources are assigned to a seat.
And if I want to use 'csh' or 'ksh', then I won't be told I'm not supported?
I.e. if I want to stay with SysV boot & init, no problem you are saying, right?
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.
---- And then it can be merged into systemd?
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.
---- Not really. You have your new and old that can live along side each other. You can choose to run experimental kernel modules or NOT. It isn't forced down your throat.
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.
The shifts from W/XP to W/Vista to W/7 and now W/8 have all been accompanied by outcries.
---- Right because of changes that were not needed or wanted in the consumer and user community, where actions were taken to get rid of the desktop. Very often MS has been found to be operating under the table with duplicity -- sorta like things have been going w/systemd in the past year or two.
What differentiates Aaron though is his personal attacks and his use of language.
Maybe, but more people seem to be responding to him than when I brought up similar issues.
I didn't have the time to post stuff on here and create replacements for stuff axed by suse and shut-out systemd. I'm still booting with separate root+user off a hard disk -- and no systemd. Not sure how long I'll be able to do that -- will depend on how fast systemd kills off the competition. Bash doesn't do that.
Comparing bash w/systemd is just outright disingenuous.
On 2014-06-05 18:01, Linda Walsh wrote:
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.
Well, postfix keeps a "deceptive" sendmail binary, to fool programs that try to use sendmail into keep working, even though it is postfix which does the work.
Which is nice in a corporate setting, but you will need special hardware
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.
2014-06-05 18:20 GMT+02:00 Carlos E. R. robin.listas@telefonica.net:
On 2014-06-05 18:01, Linda Walsh wrote:
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.
Well, postfix keeps a "deceptive" sendmail binary, to fool programs that try to use sendmail into keep working, even though it is postfix which does the work.
-- Cheers / Saludos,
Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
On Thursday 05 June 2014, Damian Ivanov wrote:
Which is nice in a corporate setting, but you will need special hardware
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.
The only problem is that more and more programs are using stupid dbus, logind or whatever magic so that they don't even run properly with "su" or "ssh -X" anymore. Tunderbird/Firefox are worst examples.
I guess here comes systemd and soon wayland to introduce even more crap to let it work again and btw to disable network transparency completely ...
cu, Rudi
Le 06/06/2014 11:49, Ruediger Meier a écrit :
The only problem is that more and more programs are using stupid dbus, logind or whatever magic so that they don't even run properly with "su" or "ssh -X" anymore. Tunderbird/Firefox are worst examples.
never tried thunderbird, but firefox works (with option --no-remote)
jdd
On 06/06/2014 05:49 AM, Ruediger Meier wrote:
It already works even on a single monitor since always... Its running fine without systemd.
So you're not talking about multi-seat any more then?
Other than a rant against modernity, its unclear what you are talking about.
On Friday 06 June 2014, Anton Aylward wrote:
On 06/06/2014 05:49 AM, Ruediger Meier wrote:
It already works even on a single monitor since always... Its running fine without systemd.
So you're not talking about multi-seat any more then?
What is multi-seat in your definition. Does It also needs 2 DVD drives or is it allowed to share one or none? Does a blind person also needs his own monitor?
Other than a rant against modernity, its unclear what you are talking about.
You are right. This is not a new feature which comes with systemd but of course you are much more modern if you do it with systemd ...
cu, Rudi
On 2014-06-06 11:49, Ruediger Meier wrote:
On Thursday 05 June 2014, Damian Ivanov wrote:
Which is nice in a corporate setting, but you will need special hardware
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.
Single monitor is ONE seat. Not multiseat.
On 06/06/2014 07:49 AM, Carlos E. R. wrote:
On 2014-06-06 11:49, Ruediger Meier wrote:
On Thursday 05 June 2014, Damian Ivanov wrote:
Which is nice in a corporate setting, but you will need special hardware
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.
Single monitor is ONE seat. Not multiseat.
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-syste...
On 2014-06-06 13:53, Anton Aylward wrote:
On 06/06/2014 07:49 AM, Carlos E. R. wrote:
Single monitor is ONE seat. Not multiseat.
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-syste...
Wow. That's a far cry from previous documents I had read, pages and pages and pages long, with tons hacks... Unless there is some complex cruft hidden somewhere, it looks very easy.
The keyboard and mice are now way easier than they were, via USB, you can connect as many as you wish. Curious about which one works at boot, or bios, though :-)
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.
That's even a hard variant. I have a plugable UD165-M device, where in udev rules dir per default systemd knows that this is a multiseat device (I can drop that rule, or change it in /etc and It is a desktop extender).
Per default I connect monitor, mouse and kb to the device, connect the device to the PC. A new gdm appears at the new seat.
2014-06-06 14:47 GMT+02:00 Carlos E. R. robin.listas@telefonica.net:
On 2014-06-06 13:53, Anton Aylward wrote:
On 06/06/2014 07:49 AM, Carlos E. R. wrote:
Single monitor is ONE seat. Not multiseat.
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-syste...
Wow. That's a far cry from previous documents I had read, pages and pages and pages long, with tons hacks... Unless there is some complex cruft hidden somewhere, it looks very easy.
The keyboard and mice are now way easier than they were, via USB, you can connect as many as you wish. Curious about which one works at boot, or bios, though :-)
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.
-- Cheers / Saludos,
Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
On 06/06/2014 08:47 AM, Carlos E. R. wrote:
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, "affordable". You mean a 4-pot card that costs less than 4 single cards, or possibly a the overhead of a mobo that has 4 high speed slots for graphics cards.
http://www.nvidia.ca/object/nvs-310-graphics-card.html For under $100 that seems a good option. If I ever go for a multi-display desktop myself I might consider that.
Here's a 4-port http://www.visiontek.com/vhdci/hd-5570-4-port-vga.html It strikes me that it is short on memory. It also only produced analog output.
This http://www.visiontek.com/quad/hd-4670x2.html is a bit better. Price seems to be just over $100. TigerDirect are out of stock
On 2014-06-06 15:23, Anton Aylward wrote:
On 06/06/2014 08:47 AM, Carlos E. R. wrote:
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, "affordable". You mean a 4-pot card that costs less than 4 single cards, or possibly a the overhead of a mobo that has 4 high speed slots for graphics cards.
Yep. Exactly that :-)
And possibly less electricity.
It may cost a bit more than the four cards, but there are not many mobos with 4 slots, which you may also need for other things.
http://www.nvidia.ca/object/nvs-310-graphics-card.html For under $100 that seems a good option. If I ever go for a multi-display desktop myself I might consider that.
Here's a 4-port http://www.visiontek.com/vhdci/hd-5570-4-port-vga.html It strikes me that it is short on memory. It also only produced analog output.
This http://www.visiontek.com/quad/hd-4670x2.html is a bit better. Price seems to be just over $100. TigerDirect are out of stock
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.
Carlos E. R. wrote:
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
----- I'm sorry, but I really don't see multiseat being very useful with stock hardware.
The desktop market is shrinking and people are going to handhelds with data stored in the cloud.
needing a separate and full blown monitor off a PC -- I don't see the demand; they'd rather hook such up to their handheld.
The idea that families would 'trust' each other enough to be able to use 1 computer (at the same time no less) -- without junior p0wning the system, or junior feeling cramped by not being able to install the lastest kernel, or anything... different needs.
Parents might want stable and reliable (which sorta disallows systemd right now, anyway, no?) and kids might want fast graphics... (I'd love to see a system that would support multiple.. say 690 or 590 GeForce cards at the same time.
EVen a top end Dell workstation (Precision 7500) couldn't support 1-590 card without resetting under any load.
you are creating a strawman that has *nearly* no market demand.
Being able to support 2 or 4 users / box in a corporate setting isn't worth the hassle over a 128 Core processor running 64 VM's and them attaching via the cloud and network transparency. They not only won't be able to find a box to support 64 video cards, but it won't come close to competing with a virtualization solution. There is so much spare capacity on some of the large 100+ cpu machines that can be effectively divided up, *today*, w/o systemd, that using multi-seat as a reason for driving this changes is ludicrous.
This is not something useful for home OR corporate users (for different reasons). and certainly is no reason to turn a well functioning system on its head with all the attendent problems I've seen posted about systemd.
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.
2014-06-06 19:17 GMT+02:00 Linda Walsh suse@tlinx.org:
Carlos E. R. wrote:
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
I'm sorry, but I really don't see multiseat being very useful with stock hardware.
The desktop market is shrinking and people are going to handhelds with data stored in the cloud.
needing a separate and full blown monitor off a PC -- I don't see the demand; they'd rather hook such up to their handheld.
The idea that families would 'trust' each other enough to be able to use 1 computer (at the same time no less) -- without junior p0wning the system, or junior feeling cramped by not being able to install the lastest kernel, or anything... different needs.
Parents might want stable and reliable (which sorta disallows systemd right now, anyway, no?) and kids might want fast graphics... (I'd love to see a system that would support multiple.. say 690 or 590 GeForce cards at the same time.
EVen a top end Dell workstation (Precision 7500) couldn't support 1-590 card without resetting under any load.
you are creating a strawman that has *nearly* no market demand.
Being able to support 2 or 4 users / box in a corporate setting isn't worth the hassle over a 128 Core processor running 64 VM's and them attaching via the cloud and network transparency. They not only won't be able to find a box to support 64 video cards, but it won't come close to competing with a virtualization solution. There is so much spare capacity on some of the large 100+ cpu machines that can be effectively divided up, *today*, w/o systemd, that using multi-seat as a reason for driving this changes is ludicrous.
This is not something useful for home OR corporate users (for different reasons). and certainly is no reason to turn a well functioning system on its head with all the attendent problems I've seen posted about systemd.
-- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Damian Ivanov wrote:
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.
--- Given that reading is hard for you, you might have missed these:
IDC Press Release PC Shipments Post the Steepest Decline Ever in a Single Quarter, According to IDC 10 Apr 2013 Worldwide PC shipments totaled 76.3 million units in the first quarter of 2013 (1Q13), down -13.9% compared to the same quarter in 2012 and worse than the forecast decline of -7.7%, according to the International Data Corporation (IDC) Worldwide Quarterly PC Tracker. The extent of the year-on-year contraction marked the worst quarter since IDC began tracking the PC market quarterly in 1994. The results also marked the fourth consecutive quarter of year-on-year shipment declines. http://www.idc.com/getdoc.jsp?containerId=prUS24065413 ----------------------- Microsoft quietly kills off the desktop PC Extremetech-http://www.extremetech.com/computing/115003-microsoft-quietly-kills-off-the-... ------ Flight of the Desktops Soon there will be no reason to have a big, boxy computer on your desk. (Slate-http://www.slate.com/articles/technology/technology/2010/06/flight_of_the_de...) -Forecast: Share of US Consumer PC Sales By Form Factor, 2008 to 2015. (graph attached if it comes through, else see article).
The portable laptops and tablets of tomorrow won't have the power to do multiseat-- they'll be lucky to support 1seat. All heavier computing is expected to move into the clouds where it can be sold to us as a service.
One of the main roots of the problem: Intel can't continue earnings growth by selling desktop cpu's -- they can't make them "faster" (GHz), but they can make them "broader" (more cpu's)... but to recoup investment on a 100Core machine, they need to sell it at a premium price tag that will be good for businesses to provide "rental services" to end users.
systemd the solution for 99.9% of users.
---- Just like MS is used on 90+% of the computers doesn't mean it is *good*. systemd's concepts and configs come right out of MS's designs -- even down to the config files used to config systemd.
As for the rest that you didn't read, it's about *realities* in families about sharing computers. They can't even share phones, and you think they are going to share a computer? Get real.
The market/problem space this is trying to solve is a small and SHRINKING part of the market.
It *MAY* be it will be able to put to use in data centers to manage a 100core machine with 100 virtual graphics devices /seats that will map to a user's tablet, but that's a far cry from needing to support multiple GPU's, sound cards etc.
The documentation for systemd is HUGE. If you can't read something this short, then systemd is not for you.
L.
On 2014-06-06 22:29, Linda Walsh wrote:
As for the rest that you didn't read, it's about *realities* in families about sharing computers. They can't even share phones, and you think they are going to share a computer? Get real.
I have. I know a family with two kids and Mom's tablet. The kids take turns at it, 10 minutes each.
On 2014-06-06 19:17, Linda Walsh wrote:
Carlos E. R. wrote:
Parents might want stable and reliable (which sorta disallows systemd right now, anyway, no?)
No :-)
divided up, *today*, w/o systemd, that using multi-seat as a reason for driving this changes is ludicrous.
It is one reason of many. It may not be a reason for you, but it is for some people.
I have several systems, all with systemd, some with separate usr partition, working out of the box without modification, and reliably. I don't see that much of an issue. Some issues, yes.
Carlos E. R. wrote:
I have several systems, all with systemd, some with separate usr partition, working out of the box without modification, and reliably. I don't see that much of an issue. Some issues, yes.
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.
How many systems do you have that boot directly from HD w/no initrd -- something systemd recommends for "speed of boot".
On 2014-06-06 22:36, Linda Walsh wrote:
Carlos E. R. wrote:
I have several systems, all with systemd, some with separate usr partition, working out of the box without modification, and reliably. I don't see that much of an issue. Some issues, yes.
All booting in the systemd recommended way for performance of booting direct from the hard disk and not using a ramdisk(initrd)?
As I said, installed out of the box by openSUSE installer, as it wants things to be done.
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.
I don't care :-)
Carlos E. R. wrote:
On 2014-06-06 22:36, Linda Walsh wrote:
Carlos E. R. wrote:
I have several systems, all with systemd, some with separate usr partition, working out of the box without modification, and reliably. I don't see that much of an issue. Some issues, yes.
Also booting in the systemd recommended way for performance of booting direct from the hard disk and not using a ramdisk(initrd)?
As I said, installed out of the box by openSUSE installer, as it wants things to be done.
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.
wow, you kinda get stuck on whatever you can. multi-seat is an example. no real arguments againts systemd, let's hate what it does well, everything.
2014-06-06 23:36 GMT+02:00 Linda Walsh suse@tlinx.org:
Carlos E. R. wrote:
On 2014-06-06 22:36, Linda Walsh wrote:
Carlos E. R. wrote:
I have several systems, all with systemd, some with separate usr partition, working out of the box without modification, and reliably. I don't see that much of an issue. Some issues, yes.
Also booting in the systemd recommended way for performance
of booting direct from the hard disk and not using a ramdisk(initrd)?
As I said, installed out of the box by openSUSE installer, as it wants things to be done.
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@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Damian Ivanov wrote:
wow, you kinda get stuck on whatever you can. multi-seat is an example. no real arguments againts systemd, let's hate what it does well, everything.
Not at all -- I am just taking the things touted as features and "must haves" and and examining them 1-by-1 as I have done before.
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?
That one wasn't easy to make a case for. Since if you want to hold it's state separate, you either subject it to snapshots that can be rolled back or make it read-only during normal use.
If you wanted to share it, mount it on /usr/share/bin, then use rbind to mount it on /usr/share/bin and export that.
There was no reason to cause the breakage that occurred, it was *unthinking* and bad design -- yet such moving of binaries and libs is ongoing (many packages need to go against the normal defaults of a package to put things in /usr with links in /bin). I.e. the decision could be made to roll it back.
Same with providing for boot-from-disk. Vendors did it for years allowing customers to run a script generating a kernel for their system -- took no technical knowledge -- but did allow boot optimizing.
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 2014-06-07 01:54, Linda Walsh wrote:
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?
Because then /usr would be empty. :-P
Choose: a full root, or a full usr.
Things were moved out of /bin because they will not work, anyway, unless you have available, before mounting /usr, all the shared libraries that are stored below /usr. For a "/bin" to properly work, either you have everything statically linked, or provide all those libraries in /lib instead of /usr/lib.
That's the reason that things have been moved to usr.
And libraries are shared by policy, lets say.
Carlos E. R. wrote:
On 2014-06-07 01:54, Linda Walsh wrote:
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?
Because then /usr would be empty. :-P
---- hardly
Choose: a full root, or a full usr.
---- Neither.
/usr has alot more stuff in it that isn't in root: X11R6, adm db games include libexec local share (man+docs) and more...
The stuff you need in /bin are the basic things you need to do initial boot, before any mounts are done, the first mounts, disk repair and backup-restore .
Then usr has all the programs users normally run on top of that. (GUI/compilers... most servers can live there... etc.).
Things were moved out of /bin because they will not work, anyway, unless you have available, before mounting /usr, all the shared libraries that are stored below /usr. For a "/bin" to properly work, either you have everything statically linked, or provide all those libraries in /lib instead of /usr/lib.
Who told you that...cuz not true: look: Here's mount on /usr/bin : 5 libs in root(/lib64) and 4 in /usr/lib64
rpm -qf /usr/bin/mount
util-linux-2.23.2-3.1.x86_64
ldd /usr/bin/mount
linux-vdso.so.1 (0x00007fffc41fe000) /usr libmount.so.1 => /usr/lib64/libmount.so.1 (0x00007f14d02d4000) / libc.so.6 => /lib64/libc.so.6 (0x00007f14cff25000) /usr libblkid.so.1 => /usr/lib64/libblkid.so.1 (0x00007f14cfce9000) / libselinux.so.1 => /lib64/libselinux.so.1 (0x00007f14cfac5000) / /lib64/ld-linux-x86-64.so.2 (0x0000003000000000) /usr libuuid.so.1 => /usr/lib64/libuuid.so.1 (0x00007f14cf8c0000) / libdl.so.2 => /lib64/libdl.so.2 (0x00007f14cf6bb000) /usr libpcre.so.1 => /usr/lib64/libpcre.so.1 (0x00007f14cf455000) / libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f14cf237000)
Now for one in /bin (grep): linux-vdso.so.1 (0x00007fffa1bfe000) /usr libpcre.so.1 => /usr/lib64/libpcre.so.1 (0x0000003000400000) / libc.so.6 => /lib64/libc.so.6 (0x0000003002000000) / libpthread.so.0 => /lib64/libpthread.so.0 (0x0000003002400000) / /lib64/ld-linux-x86-64.so.2 (0x0000003000000000)
---- It doesn't matter if the binary is in /usr/bin or /bin, the loader loads from both directories.
Now if you want something to *work* before you mount /usr, that is a different story.
Here's mount again, but with my libs cleaned up:
ldd /usr/bin/mount
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!)
On 06/07/2014 09:49 PM, Linda Walsh wrote:
/usr has alot more stuff in it that isn't in root: X11R6, adm db games include libexec local share (man+docs) and more...
And there's nothing to top you creating yet another file system -- easy to do if you use LVM -- and put all of /usr/share in that. It doesn't need to be mounted at boot time.
You could go further, have a FS 'user-other' that has all of non essential stuff from /usr and have symlinks in /usr to there. User-other' won't need to be mounted at boot time either. So the stripped down /usr can be part of the root file system.
If you're still bothered about symlinks from /bin to /usr/bin then you can replace them with hard links now.
Anton Aylward wrote:
On 06/07/2014 09:49 PM, Linda Walsh wrote:
/usr has alot more stuff in it that isn't in root: X11R6, adm db games include libexec local share (man+docs) and more...
And there's nothing to top you creating yet another file system -- easy to do if you use LVM -- and put all of /usr/share in that. It doesn't need to be mounted at boot time.
---- 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.
You could go further, have a FS 'user-other' that has all of non essential stuff from /usr and have symlinks in /usr to there. User-other' won't need to be mounted at boot time either. So the stripped down /usr can be part of the root file system.
---- Oh, so lets see, ignoring things under 1M, I see: 1.8M samba 6.7M swat 183M sbin 264M local 350M include 379M opt 465M bin1 1.3G bin 2.1G lib 3.7G lib64 17G share ---- ----- 25.7G TOTAL
df /{,usr{,/share}}
Filesystem Size Used Avail Use% Mounted on /dev/root 12G 6.9G 5.2G 58% / /dev/sdc6 15G 8.7G 6.3G 58% /usr /dev/mapper/HnS-UsrShare 50G 17G 34G 33% /usr/share
I was told, and have verified it as true, that anything under /usr is fair game for being needed at boot.
If you're still bothered about symlinks from /bin to /usr/bin then you can replace them with hard links now.
---- So if I have lib,lib64,bin,sbin & share on root.... won't fit. But that's not entirely the point. Daily backups for root are about 2-3M (uncompressed). That's less than 0.03% -- 3-one-hundredths of a percent. Rather low (nearly all of /usr is that low as well), but /usr keeps growing. Upgrading /usr is much easier than creating a new root.
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.
If it was sub-dividable, I really doubt I would have had nearly the bad reaction to it that I do. But to require me to change / reformat my entire disk setup just because systemd has huge monolithic requirements, is bad design compared to init that could bring me to a console prompt with far less demands.
You want to know why the boot process takes so long? It's a difference of needing 25G v. ~1 (root is big now, because I have multiple copies of some system dirs as backups, so if some piece of software "helps me" by replacing binaries in /bin or /sbin with symlinks to an unmounted partition (which is normally not mountable w/o /usr/lib64), I can more easily recover.
Given the stability and 'help' given to disable root-booting, being able to easily recover is more of a necessity now, than it was when I first setup my system.
On 06/08/2014 05:02 PM, Linda Walsh wrote:
Anton Aylward wrote:
On 06/07/2014 09:49 PM, Linda Walsh wrote:
/usr has alot more stuff in it that isn't in root: X11R6, adm db games include libexec local share (man+docs) and more...
And there's nothing to stop you creating yet another file system -- easy to do if you use LVM -- and put all of /usr/share in that. It doesn't need to be mounted at boot time.
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.
Regardless of what you've been _told_, I've been running with /usr/share as a separate FS that is not loaded at boot time since 11.2 when I adopted LVM.
No errors in boot. Running grub2 might have something to do with it :-)
On 2014-06-08 23:21, Anton Aylward wrote:
On 06/08/2014 05:02 PM, Linda Walsh wrote:
Anton Aylward wrote:
Regardless of what you've been _told_, I've been running with /usr/share as a separate FS that is not loaded at boot time since 11.2 when I adopted LVM.
No errors in boot. Running grub2 might have something to do with it :-)
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.
On 06/09/2014 08:26 PM, Carlos E. R. wrote:
On 2014-06-08 23:21, Anton Aylward wrote:
On 06/08/2014 05:02 PM, Linda Walsh wrote:
Anton Aylward wrote:
Regardless of what you've been _told_, I've been running with /usr/share as a separate FS that is not loaded at boot time since 11.2 when I adopted LVM.
No errors in boot. Running grub2 might have something to do with it :-)
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.
It does make me wonder.
I realise that systemd does the 'faster boot though parallelism' thing but I really don't care. I leave even my desktop running day after day. I log out when there are changes to KDE and reboot for hardware changes, longer power-outs, kernel mods and such, but in the normal course of events that might be less often than once a month. Using initrd rather than some raw boot or a boot that even took as long as it takes to put another mug of coffee and add milk wouldn't bother me.
I really don't understand why she gets in a later about it.
My big 'hiccup' come with the major upgrades,
On 06/08/2014 05:02 PM, Linda Walsh wrote:
I was told, and have verified it as true, that anything under /usr is fair game for being needed at boot.
You've pointed out
X11R6, adm db games include libexec local
as being under /usr. I don't see them as being essential to boot. Perhaps X11 and games are essential, yes, but not to the boot process.
On 06/08/2014 05:02 PM, Linda Walsh wrote:
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.
Depending on your definition, yes I do all the time.
If you mean kernel updates, that's another matter. But anything in user space I can restart. That may require logging in again, but that's a matter to do with KDE or Gnome.
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.
Again it depends on your definition. If you mean 'get to the 'graphical login' the lets compare apples to apples. Sysvinit required the shell, grep, some awk and more, as well as utilities such as mount and more to get to that point.
If we drawn the line at where the old sysvinit started running the scripts in /etc/rc5.d or /etc/rc3.d as having completed boot and now starting user services then I think we can have a meaningful discussion, but I don't think that's where YOU are drawing the line.
But if you do mean 'get to the 'graphical login' when you say 'boot' then your assertions about what's required by systemd needs to be compared to what is required - all the functions & libraries and resources used - by sysvinit to get to the same point. When we factor out the common parts I don't think its anywhere near that dramatic.
One of the purposes of systemd was to be able to get many services up and running without needing to make use of shell or shell tools.
Anton Aylward wrote:
On 06/08/2014 05:02 PM, Linda Walsh wrote:
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.
Depending on your definition, yes I do all the time.
---- 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.
If you mean kernel updates, that's another matter.
---- Not really meaning that, but the next closest thing are the kexec features--- which I usually turn off, because my console never gets re-setup correctly after executing one of those.
Again it depends on your definition. If you mean 'get to the 'graphical login' the lets compare apples to apples. Sysvinit required the shell, grep, some awk and more, as well as utilities such as mount and more to get to that point.
I don't use a GUI on my linux system. It comes up in run level 3.
If we drawn the line at where the old sysvinit started running the scripts in /etc/rc5.d or /etc/rc3.d as having completed boot and now starting user services then I think we can have a meaningful discussion, but I don't think that's where YOU are drawing the line.
----- 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.
But if you do mean 'get to the 'graphical login' when you say 'boot' then your assertions about what's required by systemd needs to be compared to what is required - all the functions & libraries and resources used - by sysvinit to get to the same point. When we factor out the common parts I don't think its anywhere near that dramatic.
One of the purposes of systemd was to be able to get many services up and running without needing to make use of shell or shell tools.
On 06/09/2014 07:54 PM, Linda Walsh wrote:
Anton Aylward wrote:
On 06/08/2014 05:02 PM, Linda Walsh wrote:
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.
Depending on your definition, yes I do all the time.
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.
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.
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 + /.
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-an...
We also use dependency trees in Zypper/Yast.
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.
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.
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
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.
systemd has no such abilities for low level debugging and fixing.
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 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.
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.
On 2014-06-10 03:36, Anton Aylward wrote:
According to the systemd 'dogma', they want the ability to bring up the GUI in parallel with mounting disks -- that means /usr/share + /usr + /.
NOT!
That's mis-information.
The difference between sysvinit and systemd is that the latter identifies things that can be done in parallel.
Automatically (and dynamically?), yes.
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.
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.
Carlos E. R. wrote:
On 2014-06-10 03:36, Anton Aylward wrote:
According to the systemd 'dogma', they want the ability to bring up the GUI in parallel with mounting disks -- that means /usr/share + /usr + /.
NOT!
That's mis-information.
The difference between sysvinit and systemd is that the latter identifies things that can be done in parallel.
Automatically (and dynamically?), yes.
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.
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.
So in other words, more vandalism among the self-appointed gods in the openSuSE community, capriciously breaking things without putting out any notice of changes.
Considering how important the init system is, and how people UTTERLY rely on it to get things running automatically, it could have (AND SHOULD HAVE) been posted to this and other lists when the change was made in -factory, rather than people only finding out after they went through problems because init was not working they way it had always workde, and there was absolutely NO REASON to suspect, that, without notice, there would be changes to how sysv init had always worked.
Has ANYBODY in SuSE heard the concept of CHANGE MANAGEMENT? It seems not, bcause there has been a verty strong trend for the last couple of years for them to recklessly and capriciously go around breaking thingss...and to laugh at anybody who complains.
This sort of bullshit is why I stopped using or recommending Redhat 12 years ago, and now it's making Slackware look very attractive.
Anton Aylward 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.
---- 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.
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.
---- 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.
But the whole point of systemd was to be able to bring the system up without the need for a shell.
---- 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.
And your example of backgrounding each script after starting them in sequential order also strikes me as risky.
--- If I did that for everything, all the time, yes... but for smaller "bites", it's fine.
Some of what sysvinit did was sequential because it needed dependencies. Universal parallelism doesn't achieve that.
----- 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).
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.
systemd has no such abilities for low level debugging and fixing.
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.
----
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.
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/
----- 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.
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.
---- 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.
Please stop making assertions about systemd that are incorrect, that could have been cleared up by a simple google or a RTFM.
They are correct for my use case. If you can't access online, then there is no documentation.
And again a nice trolling try from Linda.
2014-06-10 10:56 GMT+02:00 Linda Walsh suse@tlinx.org:
Anton Aylward 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.
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.
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.
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.
But the whole point of systemd was to be able to bring the system up without the need for a shell.
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.
And your example of backgrounding each script after starting them in sequential order also strikes me as risky.
If I did that for everything, all the time, yes... but for smaller "bites", it's fine.
Some of what sysvinit did was sequential because it needed dependencies. Universal parallelism doesn't achieve that.
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).
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.
systemd has no such abilities for low level debugging and fixing.
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.
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.
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/
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.
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.
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.
Please stop making assertions about systemd that are incorrect, that could have been cleared up by a simple google or a RTFM.
They are correct for my use case. If you can't access online, then there is no documentation.
-- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2014-06-10 11:11 (GMT+0200) Damian Ivanov composed:
And again a nice trolling try from Linda.
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."
Hmm if that's not against the netiquette, than I guess I'm free to say: I'm wondering if Felix'es all his posts are paid by someone and he is trying to demolish free thinking and openSUSE. 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? PS: As for mobile devices btw. standard android mail does not support even plain text emails.
2014-06-10 15:50 GMT+02:00 Felix Miata mrmazda@earthlink.net:
On 2014-06-10 11:11 (GMT+0200) Damian Ivanov composed:
And again a nice trolling try from Linda.
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 damianatorrpm@gmail.com wrote:
Gmail does not support bottom posting. Henne any recommendations on that one please?
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.
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?
2014-06-10 16:10 GMT+02:00 C smaug42@opensuse.org:
On Tue, Jun 10, 2014 at 4:06 PM, Damian Ivanov damianatorrpm@gmail.com wrote:
Gmail does not support bottom posting. Henne any recommendations on that one please?
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 smaug42@opensuse.org:
Gmail does not support bottom posting. Henne any recommendations on that one please?
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.
When someone is out of technical arguments, one tries to fill formal complaints, right?
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2014-06-10 16:19, Damian Ivanov wrote:
2014-06-10 16:10 GMT+02:00 C <>:
Look at that,,, a trimmed bottom posted email sent from GMail.
When someone is out of technical arguments, one tries to fill formal complaints, right?
No.
I also object to you using full top posting with no trimming.
- -- Cheers / Saludos,
Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
So Calros you want me to do what is pro my email provider and (may) against suse ml rules, or did you get confused :)
2014-06-10 16:48 GMT+02:00 Carlos E. R. carlos.e.r@opensuse.org:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2014-06-10 16:19, Damian Ivanov wrote:
2014-06-10 16:10 GMT+02:00 C <>:
Look at that,,, a trimmed bottom posted email sent from GMail.
When someone is out of technical arguments, one tries to fill formal complaints, right?
No.
I also object to you using full top posting with no trimming.
Cheers / Saludos,
Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)-----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iEYEARECAAYFAlOXGq8ACgkQtTMYHG2NR9W/7QCgmJ2qgSoxC5yNZpUilbgoqNuP CKEAn0F7MRFnDNNdq7ElsKk7D2BKfxy4 =MEv0
-----END PGP SIGNATURE-----
To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
* Damian Ivanov damianatorrpm@gmail.com [06-10-14 11:02]:
So Calros you want me to do what is pro my email provider and (may) against suse ml rules, or did you get confused :)
No, Carlos (not Calros) and most of the rest of us would *really* appreciate a little respect and an attempt at *this* list's etiquette.
Your inability to use gmail properly is a personal problem related to interest, not an inability of gmail.
Then there is your personal affronts and social language skills, ....
But the world will go on and filters are not difficult.
On Tue, Jun 10, 2014 at 4:13 PM, Damian Ivanov damianatorrpm@gmail.com wrote:
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?
Come on... is it that hard to click twice to clean up the posting? You've been asked to stop top posting... you keep doing it. You also reply direct to me... it's also VERY easy to remove my email address from the to and set it back to send only top the ML.
Gmail isn't perfect and doesn't always play "nice" with MLs, but you can have a smidgen of respect and courtesy by respecting the norms of these MLs. It takes next to zero effort to do this.
If you're too lazy to do this.. stop using GMail.
Ah well... I should have known better than to reply to the endless trolling thread. Nevermind... keep being lazy and blaming GMail. I don't care. You will only get bucketlisted by everyone - not because you use GMail, but because of your attitude.
Shrug.. no skin off my nose/back/whatever.
C.
On 2014-06-10 10:13 (GMT-0400) Damian Ivanov composed:
depends on what you thing is supported: https://productforums.google.com/forum/#!topic/gmail/ckx2MZ8HcYU
That's all nonsense. That any email app dumps the cursor at the top is not a demand that typing begin there. It's actually a convenience feature for those who trim, to start trimming at the top and work down, a sensible Q & A concept. I just tried what C did. It works fine, whether by mousing the scroll bar or keyboard navigation keys. You can type anywhere you please in the textarea where the quote appears.
Is openSUSE officially demanding to use unsupported features from your mail provider?
No.
Hey,
On 10.06.2014 16:13, Damian Ivanov wrote:
Is openSUSE officially demanding to use unsupported features from your mail provider?
Yes, we ask you that you you bottom-post.
http://en.opensuse.org/openSUSE:Mailing_list_netiquette#Quoting
If that is a problem for your MUA, figure it out.
Henne
On Tue, Jun 10, 2014 at 10:13 AM, Damian Ivanov damianatorrpm@gmail.com wrote:
Look at that,,, a trimmed bottom posted email sent from GMail.
This post is from gmail's web interface.
I highlighted the above phrase I wanted to keep in the email, then clicked reply.
gmail automatically trimmed the rest of the email and dropped my cursor below the above to let me start typing.
I have the gmail labs add-on "Quote selected text" enabled. It's a great add-on if you do much email work on lists like this. It makes it really easy to respond to just a paragraph and do all the trimming in one easy step.
I see it does get the original author wrong. I hadn't noticed that before.
Greg -- Greg Freemyer
On Tue, Jun 10, 2014 at 4:06 PM, Damian Ivanov <> wrote:
Gmail does not support bottom posting. Henne any recommendations on that one please?
It does. Here goes this one, written directly from gmail web page.
On 2014-06-10 10:06 (GMT-0400) Damian Ivanov composed:
...I'm wondering if Felix Miata's posts are biased by money and company interests.
You must be ignoring my posts in threads involving helping people solve their problems.
I'm past 60 living on fixed income that permits affording a 30 year old car, new clothes every 2-3 years, no pay TV service, steak once a year, generics from the grocery, etc. Google tried to offer me a job 3 years ago, but couldn't accept my inability to relocate or travel farther than required to get groceries or medical treatment. It's seriously sucky to have two college degrees but only to have been able to work for 11 years. Maybe my posts are biased - by lack of money.
My posts started a long time ago and as well I have been speaking at opensuse conference since years ago.
I saw you on mostly bugzilla, factory, buildservice and openFATE on mistaken initial generic opensuse.org search results, but I then searched this list's archive exclusively and found exactly 145 posts among 15 hit pages containing string "Damian Ivanov". I sampled pages 1, 15, 10, 11, and saw every one contained thereon was created in 2014. I had to go back to the generic search to find another opensuse list post from you, back in August, about using Packman repo in 12.3.
Gmail does not support bottom posting.
Nonsense.
Henne any recommendations on that one please?
Use your keyboard or mouse to place the cursor where you wish to type. It's not that hard, unless you have crippled hands.
On 06/10/2014 10:06 AM, Damian Ivanov wrote:
As for mobile devices btw. standard android mail does not support even plain text emails.
I don't care for the default email app, so I use K9-mail. It's much better.
On Tue, Jun 10, 2014 at 11:40 AM, James Knott james.knott@rogers.com wrote:
On 06/10/2014 10:06 AM, Damian Ivanov wrote:
As for mobile devices btw. standard android mail does not support even plain text emails.
I don't care for the default email app, so I use K9-mail. It's much better.
Agreed - K-9 is my Android email app preference and I have it set to plain text emails only.
My only complaint is it can get slow every couple months. I just reset the email database to scratch when it happens. I don't recall doing that in the last month or two, so maybe they finally found the bug and fixed it. (I don't have my tablet with me to check anything at the moment.)
On 06/10/2014 10:06 AM, Damian Ivanov wrote:
Gmail does not support bottom posting. Henne any recommendations on that one please?
Manually delete the trailing `72 lines ... ?
On Tue, Jun 10, 2014 at 12:56 PM, Linda Walsh suse@tlinx.org wrote:
Anton Aylward 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.
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.
Here I tend to agree. Since Solaris switched to using boot archive, "boot archive out of sync" was common source of problems. Fortunately, Solaris also provided simple and documented procedure to fix it. Unfortunately it could not cover all the cases, making it sometimes necessary to still boot from installation media to fix.
[...]
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).
Sigh ... it has nothing to do with systemd. The same problem existed always, also using sysvinit. But large amount of shell code added significant delays to hide this problem in common cases.
I went through debugging such issues and I know how painful it is.
Systemd offers an interface where daemon can inform init that it has finished initialization and is now ready, so init can proceed with starting any service that depends on this daemon. It is now up to daemon author to use it - but do not blame systemd if daemon author prefers to not implement it. How can you do the same with sysvinit? How can /sbin/rc know when daemon is ready?
On 06/10/2014 04:56 AM, Linda Walsh wrote:
Anton Aylward 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.
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.
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.
Do you know all the files that go into your initrd?
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.
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.
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.
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.
Just how often do you boot? Just how often do you rebuild your kernel?
But the whole point of systemd was to be able to bring the system up without the need for a shell.
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.
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.
And your example of backgrounding each script after starting them in sequential order also strikes me as risky.
If I did that for everything, all the time, yes... but for smaller "bites", it's fine.
Some of what sysvinit did was sequential because it needed dependencies. Universal parallelism doesn't achieve that.
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).
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.
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.
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.
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.
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.
Please stop making assertions about systemd that are incorrect, that could have been cleared up by a simple google or a RTFM.
They are correct for my use case. If you can't access online, then there is no documentation.
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
Linda is just in a mood for: "They see me trollin, they hatin".
2014-06-10 13:52 GMT+02:00 Anton Aylward opensuse@antonaylward.com:
On 06/10/2014 04:56 AM, Linda Walsh wrote:
Anton Aylward 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.
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.
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.
Do you know all the files that go into your initrd?
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.
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.
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.
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.
Just how often do you boot? Just how often do you rebuild your kernel?
But the whole point of systemd was to be able to bring the system up without the need for a shell.
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.
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.
And your example of backgrounding each script after starting them in sequential order also strikes me as risky.
If I did that for everything, all the time, yes... but for smaller "bites", it's fine.
Some of what sysvinit did was sequential because it needed dependencies. Universal parallelism doesn't achieve that.
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).
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.
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.
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.
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.
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.
Please stop making assertions about systemd that are incorrect, that could have been cleared up by a simple google or a RTFM.
They are correct for my use case. If you can't access online, then there is no documentation.
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@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Everyone,
On 10.06.2014 13:56, Damian Ivanov wrote:
Linda is just in a mood for: "They see me trollin, they hatin".
Sigh, I guess another reminder is due:
In the openSUSE lists we criticize content not people.
I don't want to see more posts like this. Be civil!
Henne
Anton Aylward wrote:
On 06/09/2014 07:54 PM, Linda Walsh wrote:
Anton Aylward wrote:
On 06/08/2014 05:02 PM, Linda Walsh wrote:
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.
Depending on your definition, yes I do all the time.
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.
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.
ALL LVMs are another potential point of failure.
Many people (such as myself) don't use them unless it is absolutely necessary because and LVM is ONE MORE THING THAT CAN GO WRONG)
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.
And what about people such as Sievert and Poettering making choices that cause problems for everyone else?
Strange how you refuse to address that issue.
There are 3 points we could talk about. 1 is only used for emergencyand 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 + /.
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-an...
We also use dependency trees in Zypper/Yast.
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.
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.
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
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.
systemd has no such abilities for low level debugging and fixing.
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 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.
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.
Linda Walsh wrote:
Anton Aylward wrote:
On 06/08/2014 05:02 PM, Linda Walsh wrote:
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.
Depending on your definition, yes I do all the time.
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.
If you mean kernel updates, that's another matter.
Not really meaning that, but the next closest thing are the kexec features--- which I usually turn off, because my console never gets re-setup correctly after executing one of those.
Again it depends on your definition. If you mean 'get to the 'graphical login' the lets compare apples to apples. Sysvinit required the shell, grep, some awk and more, as well as utilities such as mount and more to get to that point.
I don't use a GUI on my linux system. It comes up in run level 3.
If we drawn the line at where the old sysvinit started running the scripts in /etc/rc5.d or /etc/rc3.d as having completed boot and now starting user services then I think we can have a meaningful discussion, but I don't think that's where YOU are drawing the line.
There are 3 points we could talk about. 1 is only used for emergencyand 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.
These people are too clueless to understand the inherent usefulness of int being as simple as possible.
But if you do mean 'get to the 'graphical login' when you say 'boot' then your assertions about what's required by systemd needs to be compared to what is required - all the functions & libraries and resources used - by sysvinit to get to the same point. When we factor out the common parts I don't think its anywhere near that dramatic.
One of the purposes of systemd was to be able to get many services up and running without needing to make use of shell or shell tools.
On 06/07/2014 09:49 PM, Linda Walsh wrote:
ldd /usr/bin/mount
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!)
I commend and applaud you for that, but I think you and openSuse have it backwards.
On a 64-bit machine 'native' should be /bin, /usr/bin, /lib, /usr/lib. I don't think there should be a /lin64. I said NATIVE and I meant that.
Perhaps, if there is a need for backwards compatability, there might be a /lib32/ and /usr/lib32.
What? Oh, right, the old 32 bit programs _assume_ /lib and /usr/lib. But lets face it. Do the new one _assume_ /lib64 or is that just an artifice of the linker?
We pay one hell of a price for backward compatibility. Its bad enough that the x86 architecture has backward compatibility issues for earlier Windows and DOS.
http://ianmurdock.com/platforms/on-the-importance-of-backward-compatibility/
https://wiki.linuxfoundation.org/en/Application_Compatibility
http://night-ray.blogspot.ca/2014/02/linux-backwards-binary-compatibility.ht...
http://www.pixelbeat.org/programming/linux_binary_compatibility.html
http://www.linuxhelp.net/forums/lofiversion/index.php/t3861.html
Can you really run the old SCO binaries on modern Linux? http://www.linux.org/threads/types-of-executables.4792/
And http://www.es.freebsd.org/doc/handbook/binary-formats.html <quote> When Linux made its painful transition to ELF, it was due to their inflexible jump-table based shared library mechanism, which made the construction of shared libraries difficult for vendors and developers. Since ELF tools offered a solution to the shared library problem and were generally seen as “the way forward”, the migration cost was accepted as necessary and the transition made. </quote>
Where was Aaron when we made that transition? Why wasn't he complaining about it?
Anton Aylward wrote:
On 06/07/2014 09:49 PM, Linda Walsh wrote:
ldd /usr/bin/mount Notice they are all out of lib64 now (for the /usr/bin/mount binary!)
I commend and applaud you for that, but I think you and openSuse have it backwards.
----- 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).
Can you really run the old SCO binaries on modern Linux? http://www.linux.org/threads/types-of-executables.4792/
--- 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.
On 06/08/2014 05:07 PM, Linda Walsh wrote:
Anton Aylward wrote:
On 06/07/2014 09:49 PM, Linda Walsh wrote:
ldd /usr/bin/mount Notice they are all out of lib64 now (for the /usr/bin/mount binary!)
I commend and applaud you for that, but I think you and openSuse have it backwards.
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).
Can you really run the old SCO binaries on modern Linux? http://www.linux.org/threads/types-of-executables.4792/
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.
No I haven't missed the point. If you had followed the URLs I supplied you'd have read about not only Windows being backwards compatible with MS-DOS (and with errors: that one about SimCity memory allocation was a beaut!) but you'd also have read about the 4rd party applications developed for SCO that are only available as binaries - the developing firm no longer exists but the application is critical for some people.
So of course Linux has bloat to deal with all those various binary formats that were described in another of the URLs I referenced. And yes the kernel has to now how to load those and set up the memory map, code and data segments, for them.
Anton Aylward wrote:
So of course Linux has bloat to deal with all those various binary formats that were described in another of the URLs I referenced. And yes the kernel has to now how to load those and set up the memory map, code and data segments, for them.
Sounds like you are talking about the optional 'misc binary' option... I think I leave it in my kernel for java to work right, not that I use it that much.
But you can configure it out of your kernel -- it is your choice.
Not even going to argue with those who are content with the system someone else decides they should have.
They're changing the rules on the fly for some purpose known only to them. And for what? This screws up networked systems where /usr is on nfs. It flies in the face of accepted filesystem structure. IIRC there is still exists a standard adopted by Linux/Gnu folk that systemd does not abide by. DSSSL or something like.
/usr was and is never to be used for system stuff. It is for user stuff, low-privilege stuff, just as it's name says. This is the standard and the norm. Or it was until systemd decided to break things.
This is the biggest complaint windoze professionals have with Linux: That everyone makes up their own standards and policies, and that there's total chaos because of it. microsoft does the same thing but it does the same thing to everyone. Everyone is equally screwed and equally miserable with microsoft. This systemd thing seems to be a despotic attempt to force people away from standards and accepted norms. And unfortunately, it is succeeding because no one seems to care about standards any more.
Things break when the standards are not followed. And that screws everybody. This seems to be wilful and deliberate. A handful of people are dictating what all users do and destroying the standards the linux community constructed carefully in response the last huge round of criticism and PR win from the microsoft crowd over this kind of thing.
I did boot-from-disk for years until systemd. It worked better and was always easier nad faster to make changes and try them.
On Fri, 06 Jun 2014 16:54:01 -0700 Linda Walsh suse@tlinx.org wrote:
Yet suse and linux can't do that... too 'compricated'...
Or... ... ...lazy?
Rational arguments are ignored in the end. There is a breakdown in logic here somewhere (maybe I just didn't drink the koolaid?)
+5
I've used *nix's various flavours since 1984. This has never happened before. Rather, no one's gotten away with going so far as this before. This was done with total disregard of existing standards and contempt of the entire Linux community. It can only harm Linux/Gnu in the long run.("Hell, Linux can't even follow their own standards and rules! Use Microcosft instead.")
Walks like, talks like. Don't tell me it doesn't when it obviously does.
jd
On Sat, Jun 7, 2014 at 2:53 PM, jdebert jdebert@garlic.com wrote:
I've used *nix's various flavours since 1984. This has never happened before.
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.
http://www.oracle.com/technetwork/articles/servers-storage-admin/intro-smf-b...
-- Later, Darin
В Sat, 7 Jun 2014 16:21:26 -0400 Darin Perusich darin@darins.net пишет:
On Sat, Jun 7, 2014 at 2:53 PM, jdebert jdebert@garlic.com wrote:
I've used *nix's various flavours since 1984. This has never happened before.
Sun/hOracle started replacing the init system back in Solaris 10.
It was Sun, not Oracle.
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.
init with /etc/inittab still exists, but the only thing that it really does is starting svc.startd which is then responsible for everything else.
On 2014-06-07 20:53, jdebert wrote:
/usr was and is never to be used for system stuff. It is for user stuff, low-privilege stuff, just as it's name says. This is the standard and the norm. Or it was until systemd decided to break things.
LOL.
That has not been so for decades. System V changed that, not system D. Or even before that.
Pick up a SuSE 5, (year 1998) and you will see that /usr is where most of the system stuff is.
http://refspecs.linuxfoundation.org/FHS_2.3/fhs-2.3.html#PURPOSE18
++++························· Filesystem Hierarchy Standard Filesystem Hierarchy Standard Group
...
Purpose
/usr is the second major section of the filesystem. /usr is shareable, read-only data. That means that /usr should be shareable between various FHS-compliant hosts and must not be written to. Any information that is host-specific or varies with time is stored elsewhere.
Large software packages must not use a direct subdirectory under the /usr hierarchy. ·························++-
On 06/07/2014 05:02 PM, Carlos E. R. wrote:
On 2014-06-07 20:53, jdebert wrote:
/usr was and is never to be used for system stuff. It is for user stuff, low-privilege stuff, just as it's name says. This is the standard and the norm. Or it was until systemd decided to break things.
LOL.
That has not been so for decades. System V changed that, not system D. Or even before that.
Quite definitely by the time System III was released. But to be fair, even V7 saw a lot of the system move to /usr as /usr/bin and /usr/lib
On 06/07/2014 05:02 PM, Carlos E. R. wrote:
On 2014-06-07 20:53, jdebert wrote:
/usr was and is never to be used for system stuff. It is for user stuff, low-privilege stuff, just as it's name says. This is the standard and the norm. Or it was until systemd decided to break things.
LOL.
That has not been so for decades. System V changed that, not system D. Or even before that.
Pick up a SuSE 5, (year 1998) and you will see that /usr is where most of the system stuff is.
http://refspecs.linuxfoundation.org/FHS_2.3/fhs-2.3.html#PURPOSE18
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.
On 2014-06-08 00:00, Anton Aylward wrote:
On 06/07/2014 05:02 PM, Carlos E. R. wrote:
http://refspecs.linuxfoundation.org/FHS_2.3/fhs-2.3.html#PURPOSE18
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.
Yes, the FSH is becoming irrelevant by inaction.
On 06/07/2014 02:53 PM, jdebert wrote:
/usr was and is never to be used for system stuff. It is for user stuff, low-privilege stuff, just as it's name says.
Right.
That is why all the user account stuff was moved out of it into /home.
I keep copies of sent mail on some of my accounts so I see what my random signature generator produces. And yes I've locked it for this account.
But some of those are beauts!
Definitions are temporary verbalizations of concepts, and concepts -- particularly difficult concepts- are usually revised repeatedly as our knowledge and understanding grows. - Ernst Mayr
On 2014-06-07 17:42 (GMT-0400) Anton Aylward composed:
all the user account stuff was moved out of it into /home.
And it's long past due to quit scattering global customization among /usr, /var & /etc. Figuring out where any particular bit of global is or should go is no small PITA. e.g., custom DE menu items to be shared among all users on a system or on multiple systems somewhere in the menu tree other than its root.
On 06/07/2014 06:28 PM, Felix Miata wrote:
On 2014-06-07 17:42 (GMT-0400) Anton Aylward composed:
all the user account stuff was moved out of it into /home.
And it's long past due to quit scattering global customization among /usr, /var & /etc. Figuring out where any particular bit of global is or should go is no small PITA. e.g., custom DE menu items to be shared among all users on a system or on multiple systems somewhere in the menu tree other than its root.
There was an explosion of applications for UNIX under SCO and SUN. About that time Apple released the first and early versions of the MAC, and it had a UI definition. However the 'where everything goes' under SCO was pretty arbitrary.
Now at least we have pressure to put .fond files under /etc. I admit not everyone does it. My personal #1 bitch on this is KDM. But the pressure to put config under /etc is there and a lot of stuff does follow it.
Part of the problem is what to do with options that aren't being used or 'for example' config files.
Some of the latter are deemed part of the documentation and get put in /usr/share/doc/. The man pages don't always mention this. Some of the optional config files seem to end up under /usr/lib/somewhereorother and that too may not appear in the man pages.
What probably confuses newcomers is when the documentation talks of the base for libraries as ${BASE}/something.
Under V6 and V7 and to some degree even SVR4 if you didn't install many packages there wasn't enough to worry about. X caused an explosion and the various DM made it even worse.
To some degree we have libraries rationalized, but for the most part /usr/lib top level is HUGE. Thankfully the RPM database know what belongs to what.
The 'all config under /etc' movement did a good job but as I say it isn't perfect. What we really need to do is to put pressure on the few packages who put their config elsewhere or fail to document their config. Isn't that what bug reports are for? 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 opensuse@antonaylward.com wrote:
Sadly too many developers respond "WONTFIX" since they don't see this as a valid bug.
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. And it's not just FOSS. Look at Windows 8.x & the uproar over removing the start menu which worked for most for almost 20 years.
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?
I'm typing this on my "obsolete" Thinkpad T60p, Core2 Duo T7600g, 3GB RAM, FireGL 5200 with 256MB, 1TB HDD, 1600x1200 display. I mean it's an 8 year old laptop. Why would anyone waste their time using something so useless? Maybe because it works.
Le 08/06/2014 16:48, Larry Stotler a écrit :
I could list so many more.
Windows 8 new touch screen interface...
oh, sorry
jdd
On 06/08/2014 10:48 AM, Larry Stotler wrote:
On Sat, Jun 7, 2014 at 6:54 PM, Anton Aylward opensuse@antonaylward.com wrote:
Sadly too many developers respond "WONTFIX" since they don't see this as a valid bug.
This all comes back to how devs want to do things without considering the impact on the installed user base:
- 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)
NOT!
The change was to introduce an auto-configure that worked in ther 95% case. This was a great advance for those who previously hadn't been able to configure X because the configuration was too complex.
The config file are still there if you want then, only now instead of one monolithic file there are individual files for each section. You only need them if you are going to override some part of the configuration.
All the power is still there for the sophisticates and the format makes it easier for the newbies to become acquainted.
The inpact on the user base was +ve in that it allowed many people to simply get it working with common recommended OTS hardware, hence making Linux more available for the Windows-but-curious and other Joe Sixpack types.
- 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.
Some things can only strech so far. The complaints about KDE4 - I can't comment on Gnome, I never used it - boiled down to people expecting a finished product ala Microsoft, SUN or IBM and being unwilling to participate in the spirit of open source development. The reality is that the chznge to KDE4 was less than the change from W/3 to W/97 or W/XP, less than the change from W/XP to W/7 or W/8. Yes they caused outcries too but the commonality between KDE3 and KDE4 was much greater than that between W/XP and W/8.
And its not as if Linux is short of Window managers, whereas the poor Microsoft users don't get offered any alternatives.
Its not that people were told "get over it" so much as they were told that this was a new development path and that they should work with it. I'm very glad I did and I'm very pleased with the results.
- Firefox going to a new UI in v29, yet having ready to go
extensions to revert it to the "old way".
You obviously don't get "experimentation" and 'customer trials'.
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.
Sadly there are arrogant programmers like that, but not all are so. However if you spend your time badmouthing them and telling them their work is a pile of doggie-do-do then don't expect them to sympathise or cooperate with you. With a few exceptions I've found most are willing to work WITH you if you are polite and not strident and understand that they are trying their best to create and improve. Proper bug reporting and working through use cases is part of this.
These people are volunteers. They are not paid to put up with personal abuse.
Sure, the devs contribute their time & code, but they don't consider how the changes will affect the people who use their software.
Oh, they do. They have a vision. But if you castigate them and their vision all it succeeds in doing is causing entrenchment. If all they hear is criticism and abuse, especially when its focused on their vision rather than their code, and KDE4 was a good example of this because it required a lot of development and 'evolutionary' steps to get there, then they are going to stop listening to you. When you do have something useful to say, they aren't going to hear it.
And what is worse, many of the developers will learn not to listen to reasonable users who appreciate what they are doing ebcuase of people like you.
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?
It seems you didn't read that article. My quote was ironic. The old standard was flawed and limited and the use-cases had pushed it beyond its limits. The 'new' dealt with and supported the real world use-cases and regularized support for them.
On 2014-06-08 16:48, Larry Stotler wrote:
This all comes back to how devs want to do things without considering the impact on the installed user base:
- Xorg removing config files because it should "just work"
They were not removed. They are simply normally not needed, but if you do put the config files in place, they are used.
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
On 06/07/2014 06:29 PM, Anton Aylward wrote:
Out with the old, in with the new. Here's something else for Aaron and Linda to complain about:
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
Hah. Good one :)
2014-06-08 7:09 GMT+02:00 Bruce Ferrell bferrell@baywinds.org:
On 06/07/2014 06:29 PM, Anton Aylward wrote:
Out with the old, in with the new. Here's something else for Aaron and Linda to complain about:
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@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Bruce Ferrell wrote:
On 06/07/2014 06:29 PM, Anton Aylward wrote:
Out with the old, in with the new. Here's something else for Aaron and Linda to complain about:
--- Why would I care, Anton? Why do you project your failings on others?
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
---- 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-stud...
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.
Linda if you ever wonder why people mark you as unhelpful (the below seem to be a common thing for systemd-hate-trolls though): You're trying sneaky to get people on your side by talking about something (off-topic) good and relate it to your arguments. You try to downplay arguments from others with a subjective, misinformed rant and than start talking off-topic about microscopes, Fox news, freedom and how proud you're of your first perl module but you're sad because people don't like it and mark you somewhere as unhelpful.
2014-06-08 23:49 GMT+02:00 Linda Walsh suse@tlinx.org:
Bruce Ferrell wrote:
On 06/07/2014 06:29 PM, Anton Aylward wrote:
Out with the old, in with the new. Here's something else for Aaron and Linda to complain about:
Why would I care, Anton? Why do you project your failings on others?
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
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-stud...
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@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 06/09/2014 12:06 AM, Damian Ivanov wrote:
Linda if you ever wonder why people mark you as unhelpful (the below seem to be a common thing for systemd-hate-trolls though): You're trying sneaky to get people on your side by talking about something (off-topic) good and relate it to your arguments. You try to downplay arguments from others with a subjective, misinformed rant and than start talking off-topic about microscopes, Fox news, freedom and how proud you're of your first perl module but you're sad because people don't like it and mark you somewhere as unhelpful.
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
On 06/09/2014 09:56 AM, Lew Wolfgang wrote:
On 06/09/2014 12:06 AM, Damian Ivanov wrote:
Linda if you ever wonder why people mark you as unhelpful (the below seem to be a common thing for systemd-hate-trolls though): You're trying sneaky to get people on your side by talking about something (off-topic) good and relate it to your arguments. You try to downplay arguments from others with a subjective, misinformed rant and than start talking off-topic about microscopes, Fox news, freedom and how proud you're of your first perl module but you're sad because people don't like it and mark you somewhere as unhelpful.
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.
On 06/09/2014 05:47 PM, Billie Walsh wrote:
On 06/09/2014 09:56 AM, Lew Wolfgang 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".
snip
(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.
This discussion with more than 200 mails in various related threads has been extremely informative to me. I've been using linux for 15 years, but I'm far less knowledgeable than people on both sides of the argument. I've been tempted to write many times because I find the personal attacks disturbing. At various points in the discussion I have alternated sides - thinking the "haters" are correct, then I have thought the "supporters" are correct. And I'm still going back and forth. I am not saying everyone is correct, I don't have the technical knowledge to be more sure. But I do think that both sides have something valuable to contribute. I think that acknowledging that and "speaking" to each other that way in our discussions is a key to keeping this community and the open source community in general alive and thriving. I believe GOOD WILL (not only technical knowledge) is the key to progress. Gustav.
On 2014-06-09 17:47, Billie Walsh wrote:
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.
It means that what we knew now is no longer valid. We have to find new ways to do the same thing, that is, study. Means time and effort, instead of just getting the thing done, because previously we already knew the way to do it, maybe several ways. Now we have to spend time, study or ask.
;-)
There are things that are currently broken or unfinished, but hey, this is Linux, not Unix.
Hey, I don't like systemd, but the arguments I see here against it are mostly invalid, so much so that me, which would like systemd to go away, have got instead to point them out defend systemd! Yiks!
So, I can grumble and hate, or simply accept that systemd is here to stay, no matter what; and learn its ways and live happy with it, as much as I can. Instead of refusing and trying to revert all the changes myself, like things going out of bin to usr, accept them. Large initrd? Ok, fine. I leave the distribution to have its own way, mostly, and I only change what I absolutely must, with the minimal of change and effort.
Makes life easier, and I can watch movies instead ;-)
On 06/09/2014 12:33 PM, Carlos E. R. wrote:
So, I can grumble and hate, or simply accept that systemd is here to stay, no matter what; and learn its ways and live happy with it, as much as I can. Instead of refusing and trying to revert all the changes myself, like things going out of bin to usr, accept them. Large initrd? Ok, fine. I leave the distribution to have its own way, mostly, and I only change what I absolutely must, with the minimal of change and effort.
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.
Le 09/06/2014 20:08, Billie Walsh a écrit :
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.
:-)
I just have to say Linux is moving very fast. So fast, I have sometime problems moving with it.
but it's always possible to buy SLES with 7 years support :-)
jdd
On 2014-06-09 20:22, jdd wrote:
I just have to say Linux is moving very fast. So fast, I have sometime problems moving with it.
Oh, absolutely. I also have problems with that.
And it is not an organized change, but more likely coming from different antagonistic "forces", each group having different ideas of the road to take.
Billie Walsh wrote:
On 06/09/2014 12:33 PM, Carlos E. R. wrote:
So, I can grumble and hate, or simply accept that systemd is here to stay, no matter what; and learn its ways and live happy with it, as much as I can. Instead of refusing and trying to revert all the changes myself, like things going out of bin to usr, accept them. Large initrd? Ok, fine. I leave the distribution to have its own way, mostly, and I only change what I absolutely must, with the minimal of change and effort.
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.
There is absolutely NO EXCUSE for Poettering & Sievert gratuitiously moving crucial binaries from /bin to /usr/bin (if they needed things in /usr/bin so badly, they should have created symbolic links from /usr/bin/xxx to /bin/xxx rather than moving boot-essential- and maintenance-essential binaries in /usr/bin, and thus forcing /usr to be on / filesystem.
Breaking shit JUST FOR THE SAKE OF BREAKING SHIT is *NOT* fucking acceptable.
If you disagree, I will gladly demonstrate the concept using a 10 kg sledge on various parts of your house and autombiles, until you do understand the concept.
On 06/09/2014 01:33 PM, Carlos E. R. wrote:
So, I can grumble and hate, or simply accept that systemd is here to stay, no matter what; and learn its ways and live happy with it, as much as I can. Instead of refusing and trying to revert all the changes myself, like things going out of bin to usr, accept them. Large initrd? Ok, fine. I leave the distribution to have its own way, mostly, and I only change what I absolutely must, with the minimal of change and effort.
Sort of like the Serenity payer http://en.wikipedia.org/wiki/Serenity_Prayer which has been attributed to many sources.
On 2014-06-09 21:13, Anton Aylward wrote:
On 06/09/2014 01:33 PM, Carlos E. R. wrote:
So, I can grumble and hate, or simply accept that systemd is here to stay, no matter what; and learn its ways and live happy with it, as much as I can. Instead of refusing and trying to revert all the changes myself, like things going out of bin to usr, accept them. Large initrd? Ok, fine. I leave the distribution to have its own way, mostly, and I only change what I absolutely must, with the minimal of change and effort.
Sort of like the Serenity payer http://en.wikipedia.org/wiki/Serenity_Prayer which has been attributed to many sources.
Oh. It was not intentional at all. Not part of the "Spanish catholic tradition", you know ;-) So, just coincidence :-)
On 06/09/2014 03:34 PM, Carlos E. R. wrote:
On 2014-06-09 21:13, Anton Aylward wrote:
On 06/09/2014 01:33 PM, Carlos E. R. wrote:
So, I can grumble and hate, or simply accept that systemd is here to stay, no matter what; and learn its ways and live happy with it, as much as I can. Instead of refusing and trying to revert all the changes myself, like things going out of bin to usr, accept them. Large initrd? Ok, fine. I leave the distribution to have its own way, mostly, and I only change what I absolutely must, with the minimal of change and effort.
Sort of like the Serenity payer http://en.wikipedia.org/wiki/Serenity_Prayer which has been attributed to many sources.
Oh. It was not intentional at all. Not part of the "Spanish catholic tradition", you know ;-) So, just coincidence :-)
If nothing else the Serenity Prayer is just plain ol' good advice. Keep your blood pressure down and keep you from getting ulcers.
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.
Le 09/06/2014 22:41, Billie Walsh a écrit :
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.
well, KDE 2546 is much better than GNOME 321 :-)
jdd
On 2014-06-09 22:46, jdd wrote:
Le 09/06/2014 22:41, Billie Walsh a écrit :
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.
well, KDE 2546 is much better than GNOME 321 :-)
LOL.
I prefer XFCE 470.
On 06/09/2014 03:51 PM, Carlos E. R. wrote:
On 2014-06-09 22:46, jdd wrote:
Le 09/06/2014 22:41, Billie Walsh a écrit :
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.
well, KDE 2546 is much better than GNOME 321 :-)
LOL.
I prefer XFCE 470.
What difference will it make in a hundred years? *<]:oD
@Lew Wolfgang: I'm impressed by your theory but no :) Ideological preferences will pass through you whatever you do in life. If I were to vote in the US I would vote liberal-democratic (but not because of the economic or foreigner politics or healthcare)
But I'm in Europe and I vote mid-conservative (we have lots of parties here).
2014-06-09 21:13 GMT+02:00 Anton Aylward opensuse@antonaylward.com:
On 06/09/2014 01:33 PM, Carlos E. R. wrote:
So, I can grumble and hate, or simply accept that systemd is here to stay, no matter what; and learn its ways and live happy with it, as much as I can. Instead of refusing and trying to revert all the changes myself, like things going out of bin to usr, accept them. Large initrd? Ok, fine. I leave the distribution to have its own way, mostly, and I only change what I absolutely must, with the minimal of change and effort.
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@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Billie Walsh wrote:
On 06/09/2014 09:56 AM, Lew Wolfgang wrote:
On 06/09/2014 12:06 AM, Damian Ivanov wrote:
Linda if you ever wonder why people mark you as unhelpful (the below seem to be a common thing for systemd-hate-trolls though): You're trying sneaky to get people on your side by talking about something (off-topic) good and relate it to your arguments. You try to downplay arguments from others with a subjective, misinformed rant and than start talking off-topic about microscopes, Fox news, freedom and how proud you're of your first perl module but you're sad because people don't like it and mark you somewhere as unhelpful.
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.
Linda and I are both professional administrators. It's not that we "like to tweak things", it's our JOB to make things work... and when suse is putting out crap which directly conflicts with making things work optimally, then I have to put up with crap from my employer because things don't work they way they should work.
Linda, I gather, used to work at SGI. She's probably the most professional person on this list.
On 2014-06-09 07:56 (GMT-0700) Lew Wolfgang composed:
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?
Velly intellestink. If this correlation is generally true, it would seem Linda is a fish out of water being a conservative in Damian's left coast (California). Same for Dirk in liberal Michigan union territory. My sense is the French are generally liberal, applicable to Anton in Toronto. I consider myself a right leaning Independent, originally registered Independent, but now as a Republican so I can vote in primaries.
On 06/09/2014 01:04 PM, Felix Miata wrote:
My sense is the French are generally liberal, applicable to Anton in Toronto.
I'm not French.
Isn't France a Republic?
What's with this myth that republicans are conservative? Everywhere except the USA republicans are revolutionaries! They are the people that overthrew the 'Ancien Régime'.
http://en.wikipedia.org/wiki/French_Fifth_Republic http://www.politicalcompass.org/
Where, then you would place "Agile Programming" and the "Release Early//Release Often" approach to application & System development?
Le 09/06/2014 19:38, Anton Aylward a écrit :
Where, then you would place "Agile Programming" and the "Release Early//Release Often" approach to application & System development?
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
On 06/09/2014 10:49 AM, jdd wrote:
Le 09/06/2014 19:38, Anton Aylward a écrit :
Where, then you would place "Agile Programming" and the "Release Early//Release Often" approach to application & System development?
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" :-)
I respectfully disagree about UNIX "just working". It was expensive in that you had to run it on expensive hardware. Most folks didn't run UNIX on x86 home-based systems, for example.
Then came Linus, and the surly bonds to expensive/proprietary hardware was broken! I sill remember the joy and awe I felt when I first got Slackware running on a 80286-based system at home. "I can actually run UNIX without having a Sun Sparcstation on my desk!"
The Open Source community is definitely "liberal", which has clashed with my default condition of conservatism from time to time. But I credit it with helping to enlarge my "bubble" and to realize that the right answer is usually in the middle somewhere.
Regards, Lew
Le 09/06/2014 20:00, Lew Wolfgang a écrit :
I respectfully disagree about UNIX "just working".
you are right, of course, but any computer isn't said to be "just working"? I went to Linux because I was bored with DOS / Windows 3.1 "just wirking" with viruses, blue screens of death and under the hood black magic :-)
Linux do not always works (but modern computer are way more complicated than they used to be in the 70' :-), but you *always* can find what happen, at the cost of works...
jdd
On 06/09/2014 02:00 PM, Lew Wolfgang wrote:
I respectfully disagree about UNIX "just working". It was expensive in that you had to run it on expensive hardware. Most folks didn't run UNIX on x86 home-based systems, for example.
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.
Anton Aylward wrote:
On 06/09/2014 02:00 PM, Lew Wolfgang wrote:
I respectfully disagree about UNIX "just working". It was expensive in that you had to run it on expensive hardware. Most folks didn't run UNIX on x86 home-based systems, for example.
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.
If you wanted to spend $thousands to obtain it.
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.
Xenix was licensed from AT&T, then sold to SCO. Part of the sale included a clause which prohibited Microsoft from competing in the Unix sphere. This is what brought about the Microsoft campaign to discredit and attempt to destroy everything having to do with Unix (even though Microsoft was still using Unix for internal development -- the hypocrites) because their own products weren't ready for prime time.
All they did was recompile AT&T's v7 source, and rewrite the < 5% of the kernel which was processor specific.
Then, in typical MS fashion, they didn't sell to end users, they sold to vendors.
On 2014-06-09 20:00, Lew Wolfgang wrote:
I respectfully disagree about UNIX "just working". It was expensive in that you had to run it on expensive hardware. Most folks didn't run UNIX on x86 home-based systems, for example.
That was true.
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.
Then came Linus, and the surly bonds to expensive/proprietary hardware was broken! I sill remember the joy and awe I felt when I first got Slackware running on a 80286-based system at home. "I can actually run UNIX without having a Sun Sparcstation on my desk!"
Same here.
Actually, I installed Linux in order to learn Unix for use at the job, it was similar enough.
On 06/09/2014 05:10 PM, Carlos E. R. wrote:
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.
Back when I first got my IMSAI 8080, I bought 3 books from Scelbi, for monitor, editor and assembler, which were essentially source code and both octal & hex listings. I had to manually toggle in the octal for the monitor and then save to cassette, just to get things going. I later did the same with their "SCELBAL" BASIC interpreter, but since I had the monitory running then, I was able to type, rather than toggle in the octal listing. Later on, I had the editor and assembler working, so I could then type in the source code. I also built that computer from a box full of parts. Back then, you really knew your computer inside, out. :-)
https://en.wikipedia.org/wiki/IMSAI_8080 https://en.wikipedia.org/wiki/SCELBI
On 2014-06-09 23:25, James Knott wrote:
On 06/09/2014 05:10 PM, Carlos E. R. wrote:
Back when I first got my IMSAI 8080, I bought 3 books from Scelbi, for monitor, editor and assembler, which were essentially source code and both octal & hex listings. I had to manually toggle in the octal for the monitor and then save to cassette, just to get things going. I later did the same with their "SCELBAL" BASIC interpreter, but since I had the monitory running then, I was able to type, rather than toggle in the octal listing. Later on, I had the editor and assembler working, so I could then type in the source code. I also built that computer from a box full of parts. Back then, you really knew your computer inside, out. :-)
I heard of those things.
Once I built a 1 bit adder module (with carry in/out) with relays, just for fun. That's the deeper I got to the bones. Software with switches... No! :-)
jdd wrote:
Le 09/06/2014 19:38, Anton Aylward a �crit :
Where, then you would place "Agile Programming" and the "Release Early//Release Often" approach to application & System development?
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" :-)
Except it wasn't available on his 80386 computer for anything less than US $THOUSANDS.
And his original purpose wasn't to recreate Unix, it was to explore the memory managememnt capabilities of the 80386. Creating a unix-like kernel was merely an avenue for accomplishing that goal.
jdd
On 2014-06-09 13:38 (GMT-0400) Anton Aylward composed:
Felix Miata wrote:
My sense is the French are generally liberal, applicable to Anton in Toronto.
I'm not French.
French is sometimes used not only for those native to France, but for anyone from Canada, especially if from Quebec, whose native or primary language is French, by the Heinz57 south of 49N (notwithstanding enclaves).
I would think many might make the same mistake knowing your email was sent from the north side of Lake Ontario, combined with your frequent spelling mistakes and sometimes funky grammar, leading one to believe English is not your native language.
Isn't France a Republic?
So is the USA, though I think few living in it know so any more.
What's with this myth that republicans are conservative? Everywhere except the USA republicans are revolutionaries! They are the people that overthrew the 'Ancien Régime'.
You might want to investigate the history of the words Democrat and Republican as used as political party names in Nobamaland.
http://en.wikipedia.org/wiki/French_Fifth_Republic http://www.politicalcompass.org/
Where, then you would place "Agile Programming" and the "Release Early//Release Often" approach to application & System development?
Eager pragmatist programmers with inadequate supply of Guinea Pigs aka Moderates or Independents?
On 06/09/2014 01:33 PM, Felix Miata wrote:
You might want to investigate the history of the words Democrat and Republican as used as political party names in Nobamaland.
Let me make it simple.
Democrat = Far Left
Republican = Far Right
On 2014-06-09 13:40 (GMT-0500) Billie Walsh composed:
Felix Miata wrote:
You might want to investigate the history of the words Democrat and Republican as used as political party names in Nobamaland.
"History", meaning long time ago, more specifically, pre-20th century.
Let me make it simple.
Democrat = Far Left
Demand less from self, more from gummints.
Republican = Far Right
Can't really tell any more. Definitely at least for a time pro-big business, more states' rights, but probably now more anti-Democrat than anything else. Possibly more of them know that the USA according to its Constitution is a Republic, and what the word "Republic" means.
On 06/09/2014 02:40 PM, Billie Walsh wrote:
Democrat = Far Left
Republican = Far Right
Actually, at one time, the Democrats were more like the Republicans are now, or rather were, before the wackos, starting with Reagan, took over. Back around the time of Lincoln, it was the Democrats who were the more conservative and religious. Lincoln, who did so much that was considered radical at the time was a Republican.
On 06/09/2014 04:28 PM, James Knott wrote:
On 06/09/2014 02:40 PM, Billie Walsh wrote:
Democrat = Far Left
Republican = Far Right
Actually, at one time, the Democrats were more like the Republicans are now, or rather were, before the wackos, starting with Reagan, took over. Back around the time of Lincoln, it was the Democrats who were the more conservative and religious. Lincoln, who did so much that was considered radical at the time was a Republican.
Indeed. Read some of Lincoln's campaign speeches and look at his negotiation stance though his time in office. These days he'd be termed a Socialist.
Hello!
On 06/09/2014 03:40 PM, Billie Walsh wrote:
On 06/09/2014 01:33 PM, Felix Miata wrote:
You might want to investigate the history of the words Democrat and Republican as used as political party names in Nobamaland.
Let me make it simple.
Democrat = Far Left
Republican = Far Right
As seen from down here (58W32, 34S43), believe me, Democrats are not the far left. I always find it amusing when someone from the US thinks that Obama is a socialist/communist, or that his policies are really in the far left of the political spectrum. Also, even while not all republicans are on the far right, Tea Party and such are really near the scary end of right. But then again... having witnessed the effects of real far right government, I find them mostly childlish-ly unenlightened and somewhat ridiculous, and not really that extreme. But then again, I'm really far, far away ;-)
Felix Miata wrote:
On 2014-06-09 07:56 (GMT-0700) Lew Wolfgang composed:
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?
Velly intellestink. If this correlation is generally true, it would seem Linda is a fish out of water being a conservative in Damian's left coast (California). Same for Dirk in liberal Michigan union territory. My sense is the French are generally liberal, applicable to Anton in Toronto. I consider myself a right leaning Independent, originally registered Independent, but now as a Republican so I can vote in primaries.
Michigan has a Republican legislature and a Republican Governor. The unions are dead, and the Democrats killed them (primarily the UAw and the Teamsters) because the Democrats decided that anyone who is white, male, or working in the private sector is the enemy.
Lew Wolfgang wrote:
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?
---- I don't think so... I tend toward liberalism in many things, but tend to vote something independent rather than demo/repub since both parties have sold their souls to make deals that have corrupted their ideals. Conservatives got in bed with Christians to get more votes -- before that -- it was conservative government -- stay out of personal lives as much as possible. But with Christians getting into conservative party, normal definitions fell apart. Now... get this... in the past several presidential terms going back to reagan -- the Conservatives have increased the US debt via large spending the most!.. and the liberals have tried to salvage the hemorrhaging budget --- complete opposite of historical reputations. So, it's hard to label ones self when the labels have been turned topsy turvy.
I don't like too much of either extreme and generally want things to play nice somewhere in the middle. That means solutions that lockout the other ways of doing things are not likely to be liked by me. People who tell me one way or the highway... *gack*... totally antithetical to freedom and choice...
I don't play politics well and am abit too forward w/my feelings... those are bad traits in todays world, where the top-wage earners are correlated with the highest levels of sociopathology. Those who are willing to step on the most people go the highest. I think that sucks, because I don't like stepping on others. but I resist strongly being stepped on, as well. C'est la vie.
On Sat, 7 Jun 2014 21:29:56 Anton Aylward wrote:
Out with the old, in with the new. Here's something else for Aaron and Linda to complain about:
As long as they don't deprecate RFC2549 (which updated RFC1149) or RFC6214 (IPv6 adaptation of RFC2549) we'll all be OK. ;)
Anton Aylward wrote:
Out with the old, in with the new. Here's something else for Aaron and Linda to complain about:
Unlike SystemD. the architets of HTTP 5 actually made a plan, and sought out comments far and wide for SEVEN YEARS before offering their ideas to the world (In contrast to Sievert and Poettering IMPOSING their "new vision" on the world, breaking things that never needed to be broken, and generally, acting like saboteurs -- and when questioned about anything, replying in a manner more fitting of conceited, spoiled little brats rather than computing professionals).
So, regarding your example ... FAIL!
Linda Walsh wrote:
Damian Ivanov wrote:
wow, you kinda get stuck on whatever you can. multi-seat is an example. no real arguments againts systemd, let's hate what it does well, everything.
Not at all -- I am just taking the things touted as features and "must haves" and and examining them 1-by-1 as I have done before.
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?
That one wasn't easy to make a case for. Since if you want to hold it's state separate, you either subject it to snapshots that can be rolled back or make it read-only during normal use.
If you wanted to share it, mount it on /usr/share/bin, then use rbind to mount it on /usr/share/bin and export that.
There was no reason to cause the breakage that occurred, it was *unthinking* and bad design -- yet such moving of binaries and libs is ongoing (many packages need to go against the normal defaults of a package to put things in /usr with links in /bin). I.e. the decision could be made to roll it back.
Same with providing for boot-from-disk. Vendors did it for years allowing customers to run a script generating a kernel for their system -- took no technical knowledge -- but did allow boot optimizing.
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?)
Linda, I have come to the conclusion that the age of reason is over.
We have poeple who are addicted to chaos, and lies to justify the chaos.
I don't expect to change them, but I will take EVERY opportunity to rub their face in it every time I catch them doing it, just like when you catch the dog pooging in the middle of the living room rug (the only difference is, the dog learns to feel a sense of shame, and eventually stops pooping on the rug, whereas these crazy people will continue doing this until they die.)
On 2014-06-06 23:36, Linda Walsh wrote:
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
Ah, no, the elder kid got a tablet of his own fre days ago. No systemd there, of course, nor a usr partition, either. It has galaxy something label somewhere, dunno what that means.
:-P
Ah, yes, not a Linux tablet.
On Friday 06 June 2014, Carlos E. R. wrote:
On 2014-06-06 11:49, Ruediger Meier wrote:
On Thursday 05 June 2014, Damian Ivanov wrote:
Which is nice in a corporate setting, but you will need special hardware
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.
Single monitor is ONE seat. Not multiseat.
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.
cu, Rudi
On 2014-06-08 00:51, Ruediger Meier wrote:
On Friday 06 June 2014, Carlos E. R. wrote:
Single monitor is ONE seat. Not multiseat.
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.
Makes sense.
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.
2014-06-08 1:43 GMT+02:00 Carlos E. R. robin.listas@telefonica.net:
On 2014-06-08 00:51, Ruediger Meier wrote:
On Friday 06 June 2014, Carlos E. R. wrote:
Single monitor is ONE seat. Not multiseat.
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.
Makes sense.
-- Cheers / Saludos,
Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
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,xkbvariant=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
Sounds already like lots of "frickeln" your approach. systemd does it hotplug and clean.
2014-06-08 13:42 GMT+02:00 Ruediger Meier sweet_f_a@gmx.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,xkbvariant=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@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Sunday 08 June 2014, Damian Ivanov wrote:
Sounds already like lots of "frickeln" your approach. systemd does it hotplug and clean.
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?
2014-06-08 13:42 GMT+02:00 Ruediger Meier sweet_f_a@gmx.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@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 06/08/2014 09:20 AM, Ruediger Meier 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?
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, Anton Aylward wrote:
On 06/08/2014 09:20 AM, Ruediger Meier 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?
If you read the links that I gave earlier you would have the answer to that.
No need to issue a command,
For me issuing a command is much more easy than clicking random buttons ...
And how would you start the second seat while one user is already logged in using all Monitors? (Whithout logging the first user off!)
each seat is presented with the graphical login.
So even there is only one user logged in ... the other monitors stay idle with login screen? I have no need for such poor thing...
cu, Rudi
On 06/08/2014 11:22 AM, Ruediger Meier wrote:
On Sunday 08 June 2014, Anton Aylward wrote:
On 06/08/2014 09:20 AM, Ruediger Meier 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?
If you read the links that I gave earlier you would have the answer to that.
No need to issue a command,
For me issuing a command is much more easy than clicking random buttons ...
This isn't about random buttons. Login is part of an identification and authentication process, part of what differentiates *NIX from DOS/Windows :-)
What you have missed is that before you issuing that command (and having to write that shell script) you had to log in.
The approach Damian and I are talking about ... You just log in. No random buttons, not issuing a custom command.
Each seat is presented with the login prompt.
And how would you start the second seat while one user is already logged in using all Monitors? (Whithout logging the first user off!)
each seat is presented with the graphical login.
So even there is only one user logged in ... the other monitors stay idle with login screen? I have no need for such poor thing...
Then you have no need for a multi-user system to start with.
It's really alerting that you don't see what the "frickeln" part is. On a single monitor you can do it your "frickel" way. 1) it is not a clean solution and locked into Xephyr, what about Mir, wayland? - why don't you whine here about lock-in to X for your solution 2) no serious company will let the employees stare at one monitor for two seats, it is unhealthy and is not compatible with EU ergonomics and health requirement at workplaces and also for 99.999% of the companies a security break (one employee see what the other does) 3) no imagine ignoring a&b what about not 2 users but 16, will you split your monitor into 16 xephyr sessions? 4) wikipedia: multiseat is about *independent sessions* which is already violated by *1* monitor
system-logind in combination with udev offers an incredible amount of hotplug possibilities: 1) already marked by udev hardware: like plugable multiseat stations: plug keyboard,mouse, monitor into the station - a new seat appears. 2) mark hardware as seat e.g usb hub: connect usb hub, connect monitor, mouse, keyboard to usb hub: now either a) loginctl attach $id_of_usb_hub seat2 b) have a udev rule which contains the usb device id / vendor id (now if you wish any usb hub from that manufactor(that model) will be recognized as a multiseat device - but all this is configurable as you wish) c) add the devices via loginctl attach $monitor2 $monitor3 (if you wish) $kb2 $mouse2 (you can also add them permanently or until reboot)
2014-06-08 15:20 GMT+02:00 Ruediger Meier sweet_f_a@gmx.de:
On Sunday 08 June 2014, Damian Ivanov wrote:
Sounds already like lots of "frickeln" your approach. systemd does it hotplug and clean.
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?
2014-06-08 13:42 GMT+02:00 Ruediger Meier sweet_f_a@gmx.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@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 06/05/2014 12:01 PM, Linda Walsh wrote:
Bash never required moving binaries from /bin to /usr/bin and never dictated how I should boot.
Neither did the move from OpenOffice to LibreOffice.
So what?
Personally I think you're confusing simultaneity with causality.
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.
Why do you drag up irrelevancies like this?
Anton Aylward wrote:
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.
Not irrelevant, as the reason for doing it was systemd that needed to have /usr mounted at boot. It *would* affect my system, since /usr is a secondary mount ... if all the files to process boot state are not on root, my system won't boot.
Moving files off to /usr and leaving turds in /bin and /sbin where binaries used to be or forcing deps on /usr/lib[64], was unnecessary and poor design.
I still have to run remedial scripts after updating suse software to check if root has any deps on /usr.
The fact that systemd couldn't even handle a simple file config without creating incompatibilities, highlights its adaptability -- and why it's a problem.
Anton Aylward wrote:
On 06/05/2014 01:27 AM, Damian Ivanov wrote:
You are full of bullshit. Multiseat was a hack.
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.
As early as 1984 at Purdue, I remember entire rooms full of high resolution graphics terminal all directly wired into the same computer.
They were used by grad students and some upper classmen to designed circuit chips (MSI, LSI and eventually VLSI)
One set were graphics terminals with storage tubes, tied into an IBM-370 running VM/CMS, and the other were some Tektronix 4000 series (I forget the exact model number) terminals, which were all directly wired into eg.ecn.purdue.edu, which was a dual-CPU VAX-11/780 (The original dual-CPU VAX was built, and programmed by George Goble at Purdue, for his masters degree in EE, the programming for the dual-CPU was included in BSD kernels starting with 4.2 BSD. Goble continues to work at Purdue, where he is Chief Engineer of the Engineering Computer Network -- which he essentially built from scratch in the late 1970's and early 1980's, including a networking protocol called pnet -- which included remote job execution, and a "network shell" ns, before TCP/IP was ported to UNIX.
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.
LTSP has been doing that for 10 years. Long before Multi-seat.
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.
Linda Walsh wrote:
Damian Ivanov wrote:
Even if the URL is 1000 character long I wouldn't blame you.
udevd is not mentioned in the post. udev - They are in one and the same tarball, that's it. An init should perfectly know about you hardware and handle it
Since when? And how do I upgrade or add new drivers without rebooting?
logind - what's wrong with that being part of PID 1
Everything is part of PID 1 now. Its indivisible ...
e.g multiseat - how did work before systemd (logind) and how now with it? logind made it work properly, before that there was no proper multiseat.
Multiseat? Explain why a distro aimed primarily atusers 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?
It doesn't matter, Linda.
simple 1970's era init was doing multi-seat on sytems with anywhere from a dozen to 100's of terminals (literally) when I was a computer engineering student at Purdue.
Multiseat has to be about the absolute WORST justification for systemd -- not because multiseat is an extravagant luxury, but because Unix has been multiseat since the beginning, for literally 4 decades before Poettering & Sievert's abomination.
Certainly, systemd has a very corporate feel to it, but how
Not very corporate to me. I used to work for a few years for a financial company. If I proposed moving systemd into that environment, I would have had my had torn off and shoved up between my legs for even voicing an interest in something so precarious.
is that a good fit for OpenSuSE which seems to be more desktop and laptop users than anything else?
Damian Ivanov wrote:
Even if the URL is 1000 character long I wouldn't blame you.
udevd is not mentioned in the post. udev - They are in one and the same tarball, that's it. An init should perfectly know about you hardware and handle it logind - what's wrong with that being part of PID 1
EVERYTHING is wrong with logind being part of PID 1.
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.
You obviously have no clue about the Unix design principles that have made *nix operating systems THE CHOICE for the overwhelming majority of the internet, and over 99.9% of the supercomputers on the planet.
Conversely, Damian, why SHOULD logind be part of PID 1. "It will save 3 lines of code and an exec()" is not a good enough reason. VIOLATING the wisdom of the principle modularity demands a far better reason than that.
kdbus - kernel dbus isn't even officially there so this is not a regression, it's technically different from user-space dbus.
Again, why should this be in PID 1?
That's just one more bunch of code that can have a bug and crash the system.
e.g multiseat - how did work before systemd (logind) and how now with it?
Dude. You must be extremly young
I was working on computers with anywhere from 15 to 150 users logged in simultaneously. And these were on physical terminals, no less, not internet rlogin's or ssh logins. getty (which then exec's login) handled those environments perfectly.
logind made it work properly, before that there was no proper multiseat.
BULLLLLLLLLLLLLLLLLLLLLLLLLSHIT.
Unix and Linux have been multiseat since the beginning of each.
The fact that you don't know ANY of this indicates how truly naive you are about the whole subject.
You don't understand the history of Unix and Linux. You don't understand the design of Unix and Linux You don't understand the principles of systems programming on Unix and Linux. You really don't understand ANYTHING about the subject of this discussion other than that you've been told that systemd has a bunch of bells & whistles, and you're to young, naive, and inexperienced to understand that PID 1 should NEVER have bells & whistles... EVER!
2014-06-04 12:42 GMT+02:00 Linda Walsh suse@tlinx.org:
Damian Ivanov wrote:
As always what to expect from systemd haters just some bullshit.
He claims that his logind, udevd, dbusd all are dead and combined into systemd.
Source?
https://plus.google.com/+LennartPoetteringTheOneAndOnly/posts/8RmiAQsW9qf#+L...
(don't blame me for such a long URL -- it's from google!)
-- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 06/04/2014 08:50 PM, Dirk Gently wrote:
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
Indeed.
On my system that is the case. When I run 'ps' I find
root 866 1 0 May30 ? 00:00:05 /usr/lib/systemd/systemd-logind
That is: the login daemon is running as PID=866. You can see its a daemon from the "?" which means there is no controlling TTY. It was, as you wanted, stated by the PID=1 process.
Anton Aylward wrote:
On 06/04/2014 08:50 PM, Dirk Gently wrote:
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
Indeed. On my system that is the case. When I run 'ps' I find root 866 1 0 May30 ? 00:00:05 /usr/lib/systemd/systemd-logind
Why does systemd need to run as '1' again? It's a matter of boundaries more than anything. If init had deficiencies, will I Poettering's name on any bug reports or suggestions to fix it?
It seems he wants to be able to know when something w/o a parent dies.
There are many uses of such -- I have multiple regular or long running jobs that I've thought about how to get notice of unexpected failures without trying to verify that there was "no problem" -- I prefer to be notified when there is a problem, I don't want to be notified when there is not.
So if I put my own catch routine in PID 1, that won't be a problem w/modular systemd right?
Vs. if I was going to write my catcher, I'd probably offer a subscription API so other processes can be notified of abnormal process termination. I'd design it to be usable by other people -- not just for me, as i'd think not doing that on a system resource like PID1, would be inappropriately selfish and short-sighted. Yet no one things twice when systemd puts a systemd-only replacement in place.
Similarly, how easy does systemd make it to plug in 3rd party cgroup control scripts? As near as I can tell, systemd is intending to make it **more** difficult to use anything other than systemd, with Poetty's claim that is is the kernel devs who want it that way. Given that the kernel devs preferred a modular security model to the point of requiring they all exist in a loadable/configurable framework, it seems unlikely and some imaginary 'leap of faith' to see how such a rigid system would be wanted by anyone other than it's creators.
On 2014-06-06 19:23, Linda Walsh wrote:
Why does systemd need to run as '1' again? It's a matter of boundaries more than anything.
Init must run as 1, because it is the first program the kernel loads. There will always be a userspace "something" running as pid 1, and it is "init". Systemd is init now.
And the kernel expects that PID 1 process to do the rest of starting the system.
Carlos E. R. wrote:
On 2014-06-06 19:23, Linda Walsh wrote:
Why does systemd need to run as '1' again? It's a matter of boundaries more than anything.
Init must run as 1, because it is the first program the kernel loads. There will always be a userspace "something" running as pid 1, and it is "init". Systemd is init now.
And the kernel expects that PID 1 process to do the rest of starting the system.
So if "linda-init" starts systemd, it will bring up rest of system w/o needing to be '1', right? I.e. no problem?
On 2014-06-06 22:32, Linda Walsh wrote:
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?
If open source. You can design your own program to take the 'init' place. Whether you can then put systemd as PID 2, I don't see what for, because now it is your task, not systemd, to handle the system.
Il 04/06/2014 07:42, Linda Walsh ha scritto:
Damian Ivanov wrote:
As always what to expect from systemd haters just some bullshit.
He claims that his logind, udevd, dbusd all are dead and combined into systemd.
Source?
https://plus.google.com/+LennartPoetteringTheOneAndOnly/posts/8RmiAQsW9qf#+L...
(don't blame me for such a long URL -- it's from google!)
You could have used an URL trimmer before copy the long link.
Google has its own trimmer;-)
Cheers,
On 06/04/2014 03:42 AM, Linda Walsh wrote:
Damian Ivanov wrote:
As always what to expect from systemd haters just some bullshit.
He claims that his logind, udevd, dbusd all are dead and combined into systemd.
Source?
https://plus.google.com/+LennartPoetteringTheOneAndOnly/posts/8RmiAQsW9qf#+L...
Wow! This guy doesn't come off very well. How can someone like this gain enough power to threaten our livelihoods? He comes off like obama, ruling by fiat, ignoring the rule of law, and oh, by the way, "the cost of electricity will necessarily skyrocket." At least obama was elected, I don't remember voting for Poettering.
Regards, Lew
On Mon, 2014-06-02 at 02:26 -0400, Dirk Gently wrote:
Araluen wrote:
On Sun, 2014-06-01 at 16:13 -0400, Dirk Gently wrote:
Linda Walsh wrote:
Felix Miata wrote:
WRT openSUSE: The fence is down. The barn is empty. For all practical purposes the herd has been lost. If you don't want a system dependent on systemd...
Well, that's until it goes a bit too far.
Remember, it's just something to help help your system boot faster by doing parallel boot. And now? Seems like it fell a bit short of that initial goal, as well. If you already booted direct from HD and used parallel boot in the run scripts, there seems to be a slowdown. What I don't understand is why people keep converting more to systemd, when it didn't make good on its initial promises.
More importantly, shaving a couple of seconds off of boot time is really sooooper-dooooper important, why, exactly?
Systemd is doing the equivalent of fouling up the reliability of all the critical control systems of an automobile, all for the stated goal of gettin the engine to start in 3 seconds rather than 4.
The rsultant calamities would wind up in court as criminal malfeasance.
Nobody has yet explained WHY saving a couple of seconds at boot time is ooh soooo important (And I remember the days when unix systems with only 1 MB of memory took 15 minutes to boot up) that it justifies fucking up the entire concept of run-levels, and using well-debugged shell-scripts rather than some pulled-out-of-the-ass custom scripting language which is NOT anywhere close to fully debugged, and config files full of XML crud.
I think we both agree that the net effect of the trade-offs is not beneficial to users or system administrators, but it sure does stroke the ego of Lennert Poettering and Kay Sievert. There's going to be a special place in hell for those two.
Well then, if we are compromising system stability for such a negotiable benefit, how do we turn the situation around? Or is it full speed ahead and damn the torpedoes.
Unlike Farrugut's order at the Battle of Mobile Bay, going full-speed ahead is not going to achieve any useful objectives, yet the dangers of systemd are still there.
For one, systemd is making APPLICATIONS now dependant on the systemd API, which means when even the biggest fanboys here, at Redhat, and other distributions finally are forced to admit that systemd is a crock of shit.... we won't be able to remove it.... in other words, unlike Farragut, the probability of eventually being blown out of the water by a systemd torpedo is 100%.
SysV init has problems, but without a doubt, it does NOT present itself as being a massive security hole, nor present the risk of making a system unbootable.
Cheers, Mark
If one is critical of the status quo, one must be able to present alternatives and their implementation... It seems systemd is just waiting to @#$% me up the !^&* What can i do? i mused. cheers mark
Maybe on Kay Sievert, yes he is problematic (as personality in open source). systemd doesn't not do everything. Under the systemd umbrella are few additional daemons reimplenting a lot of services. If you build systemd with all configuration options enabled you will build 69 individual binaries. These binaries all serve different tasks, and are neatly separated for a number of reasons. At compile time you have a number of configure switches to select what you want to build, and what not.
That developers code stuff that requires systemd is not systemd's fault. You don't like GNOME? Use something else. You have a problem with systemd as init or with some of all the services under systemd's umbrella (logind etc.)? You could develop alternatives for these. You don't want to? You want other people to develop for YOUR personal preferences? This ain't gonna happen. And as upstart is dead from now on and openrc doesn't do the job, let's embrace systemd with all of our heart.
Damian Ivanov wrote:
Maybe on Kay Sievert, yes he is problematic (as personality in open source). systemd doesn't not do everything. Under the systemd umbrella are few additional daemons reimplenting a lot of services. If you build systemd with all configuration options enabled you will build 69 individual binaries. These binaries all serve different tasks, and are neatly separated for a number of reasons. At compile time you have a number of configure switches to select what you want to build, and what not.
That developers code stuff that requires systemd is not systemd's fault.
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.
You don't like GNOME? Use something else. You have a problem with systemd as init or with some of all the services under systemd's umbrella (logind etc.)? You could develop alternatives for these. You don't want to? You want other people to develop for YOUR personal preferences? This ain't gonna happen. And as upstart is dead from now on and openrc doesn't do the job, let's embrace systemd with all of our heart.
You can run a different logging daemon like syslog-ng no problem. Also journalctl which seems to be your problem can filer per application, time etc. everything and write to file. no problem.
2014-06-02 9:19 GMT+02:00 Dirk Gently dirk.gently00@gmail.com:
Damian Ivanov wrote:
Maybe on Kay Sievert, yes he is problematic (as personality in open source). systemd doesn't not do everything. Under the systemd umbrella are few additional daemons reimplenting a lot of services. If you build systemd with all configuration options enabled you will build 69 individual binaries. These binaries all serve different tasks, and are neatly separated for a number of reasons. At compile time you have a number of configure switches to select what you want to build, and what not.
That developers code stuff that requires systemd is not systemd's fault.
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.
You don't like GNOME? Use something else. You have a problem
with systemd as init or with some of all the services under systemd's umbrella (logind etc.)? You could develop alternatives for these. You don't want to? You want other people to develop for YOUR personal preferences? This ain't gonna happen. And as upstart is dead from now on and openrc doesn't do the job, let's embrace systemd with all of our heart.
-- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Damian Ivanov wrote:
You can run a different logging daemon like syslog-ng no problem. Also journalctl which seems to be your problem can filer per application, time etc. everything and write to file. no problem.
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.
2014-06-02 9:19 GMT+02:00 Dirk Gently dirk.gently00@gmail.com:
Damian Ivanov wrote:
Maybe on Kay Sievert, yes he is problematic (as personality in open source). systemd doesn't not do everything. Under the systemd umbrella are few additional daemons reimplenting a lot of services. If you build systemd with all configuration options enabled you will build 69 individual binaries. These binaries all serve different tasks, and are neatly separated for a number of reasons. At compile time you have a number of configure switches to select what you want to build, and what not.
That developers code stuff that requires systemd is not systemd's fault.
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.
You don't like GNOME? Use something else. You have a problem
with systemd as init or with some of all the services under systemd's umbrella (logind etc.)? You could develop alternatives for these. You don't want to? You want other people to develop for YOUR personal preferences? This ain't gonna happen. And as upstart is dead from now on and openrc doesn't do the job, let's embrace systemd with all of our heart.
-- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
You have no idea. Not the slightest clue. You can't keep it technical. Fuck you Dirk Gently.
2014-06-03 2:26 GMT+02:00 Dirk Gently dirk.gently00@gmail.com:
Damian Ivanov wrote:
You can run a different logging daemon like syslog-ng no problem. Also journalctl which seems to be your problem can filer per application, time etc. everything and write to file. no problem.
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.
2014-06-02 9:19 GMT+02:00 Dirk Gently dirk.gently00@gmail.com:
Damian Ivanov wrote:
Maybe on Kay Sievert, yes he is problematic (as personality in open source). systemd doesn't not do everything. Under the systemd umbrella are few additional daemons reimplenting a lot of services. If you build systemd with all configuration options enabled you will build 69 individual binaries. These binaries all serve different tasks, and are neatly separated for a number of reasons. At compile time you have a number of configure switches to select what you want to build, and what not.
That developers code stuff that requires systemd is not systemd's fault.
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.
You don't like GNOME? Use something else. You have a problem
with systemd as init or with some of all the services under systemd's umbrella (logind etc.)? You could develop alternatives for these. You don't want to? You want other people to develop for YOUR personal preferences? This ain't gonna happen. And as upstart is dead from now on and openrc doesn't do the job, let's embrace systemd with all of our heart.
-- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Damian Ivanov wrote:
You have no idea. Not the slightest clue. You can't keep it technical. Fuck you Dirk Gently.
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?
2014-06-03 2:26 GMT+02:00 Dirk Gently dirk.gently00@gmail.com:
Damian Ivanov wrote:
You can run a different logging daemon like syslog-ng no problem. Also journalctl which seems to be your problem can filer per application, time etc. everything and write to file. no problem.
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.
2014-06-02 9:19 GMT+02:00 Dirk Gently dirk.gently00@gmail.com:
Damian Ivanov wrote:
Maybe on Kay Sievert, yes he is problematic (as personality in open source). systemd doesn't not do everything. Under the systemd umbrella are few additional daemons reimplenting a lot of services. If you build systemd with all configuration options enabled you will build 69 individual binaries. These binaries all serve different tasks, and are neatly separated for a number of reasons. At compile time you have a number of configure switches to select what you want to build, and what not.
That developers code stuff that requires systemd is not systemd's fault.
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.
You don't like GNOME? Use something else. You have a problem
with systemd as init or with some of all the services under systemd's umbrella (logind etc.)? You could develop alternatives for these. You don't want to? You want other people to develop for YOUR personal preferences? This ain't gonna happen. And as upstart is dead from now on and openrc doesn't do the job, let's embrace systemd with all of our heart.
-- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
You have no clue. Use google.
2014-06-03 9:08 GMT+02:00 Dirk Gently dirk.gently00@gmail.com:
Damian Ivanov wrote:
You have no idea. Not the slightest clue. You can't keep it technical. Fuck you Dirk Gently.
- 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).
- 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
- 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?
2014-06-03 2:26 GMT+02:00 Dirk Gently dirk.gently00@gmail.com:
Damian Ivanov wrote:
You can run a different logging daemon like syslog-ng no problem. Also journalctl which seems to be your problem can filer per application, time etc. everything and write to file. no problem.
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.
2014-06-02 9:19 GMT+02:00 Dirk Gently dirk.gently00@gmail.com:
Damian Ivanov wrote:
Maybe on Kay Sievert, yes he is problematic (as personality in open source). systemd doesn't not do everything. Under the systemd umbrella are few additional daemons reimplenting a lot of services. If you build systemd with all configuration options enabled you will build 69 individual binaries. These binaries all serve different tasks, and are neatly separated for a number of reasons. At compile time you have a number of configure switches to select what you want to build, and what not.
That developers code stuff that requires systemd is not systemd's fault.
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.
You don't like GNOME? Use something else. You have a problem
with systemd as init or with some of all the services under systemd's umbrella (logind etc.)? You could develop alternatives for these. You don't want to? You want other people to develop for YOUR personal preferences? This ain't gonna happen. And as upstart is dead from now on and openrc doesn't do the job, let's embrace systemd with all of our heart.
-- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org