Re: stop posting useless cruft and get to work (systemd and Linux are *fundamentally incompatible* -> and I can prove it)
On 28 Mar 2014 03:40, Olav Vitters wrote: [...] > > I can tell you right now, it is *vastly more difficult* to try to > > adapt programs modified to work with systemd in their current state, > > than it is to *revert* those programs to their pre-systemd state. > > You're so certain while so utterly wrong on so many levels it is pretty > amusing and embarrassing at the same time. You said you don't easily get > offended, but hopefully you do pickup some learnings here. Did you understand that... There are (at least) two paths to take here, and this is referring to the more difficult of the two. The easier choice is the reversion then selective upgrade path. I did go on to explain why the first path was more difficult. Did you consider what I said there? Please, put why I'm so utterly wrong into writing here and let's see what you understand. -Kev -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/cadkoaxhnleetyo6-fgjqujaryhnq8nv6kaxu8bazyudvzvr...@mail.gmail.com
Re: stop posting useless cruft and get to work (systemd and Linux are *fundamentally incompatible* -> and I can prove it)
On 26 Mar 2014 12:30, Matthias Urlichs wrote: [...] > > But here is the vastly oversimplified technical argument... > > > To the point of being neither technical nor valid. > (Which admittedly was never in doubt even before I started reading.) What do you consider technical? Vastly oversimplified doesn't mean automatically wrong in this context. It means there are a huge amount more of valid technical points I can raise here, but under the requirements expressed, I had to fit it down to a page, and so I left out quite a lot. These arguments are still valid, even if they are but only a small tip of the iceberg. > > I think you will confirm that neither you, nor I, nor the guy who came > > up with the original idea actually understands how it works > > If understanding how systemd works is so much of a problem for you that you > cannot even conceive of anybody, let alone its author, doing so then I'd > like to suggest that debian-devel is not the right place for you. One of the problems of giving truncated information is that some people aren't aware of the steps one has already taken to establish the validity of the argument. Lennart Poettering doesn't really understand what systemd is, and as a consequence, how it works. I tested this out myself. You can read up on how I determined this if you want, but it is a truth in its own right. > I'd suggest an alternate mailing list, but I'm afraid I'd offent both you > and the other participants of that list, should I do so. You do not have to fear that you will offend me. But, there are specific reasons why debian-devel is the primary target here. Again... information I left out in the condensed version. -Kev -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CADkoAxj+rFQXvGhv-BHF5pX0DZwMV=gyioaf_d8j8be-ywz...@mail.gmail.com
Re: stop posting useless cruft and get to work (systemd and Linux are *fundamentally incompatible* -> and I can prove it)
On 26 March 2014 13:42, Shachar Shemesh wrote: [...] > As far as the systemd vs. upstart discussion, I was leaning in upstart (more > precisely, against systemd). As such, your email was very interesting to me. > Unfortunately, it was unreadable. You said you'll start with background, but > instead of providing technical background, you provided meaningless and > irrelevant "he said, I said" arguments. Trying to skim ahead to find where > the meat starts did not easily detect such a point. > > At this point, I simply assumed the email had nothing more to say. If I'm > wrong, feel free to answer with the technical gist of your arguments. If you > want me to read it, please adhere to the following guidelines: > > No more than one page. > No *asterisks* and -> arrows. > No references to previous discussions, or other people's arguments > for/against systemd. First, here is a version with the asterisks removed. It might be visually easier to read. https://lists.debian.org/debian-devel/2014/03/msg00449.html Second, some concepts need a lot of information communicated to make sense to those who are not already familiar with the concept. We don't send people to college for a day and expect them to grasp 4 years of higher education. There are some limits on Human learning that you have to respect. But here is the vastly oversimplified technical argument... The test of comprehension is... if you cannot put an idea into writing, then you do not understand that idea well enough to be of any practical use. If that idea is a program... this means you do not actually have control of the program when implemented. Our ability to control things is directly dependent on our knowledge of how that thing operates. With knowledge, comes the ability to manipulate the thing to suite our purposes. Please, tell me what systemd is, fitting its entire functionality as expressed as one single concept. That does not mean it has to be one sentence, but it does mean you cannot group different concept together and simply give that as an answer. Grouping them together is saying what it does, not what it is. Big difference. I think you will confirm that neither you, nor I, nor the guy who came up with the original idea actually understands how it works, and we will not actually have control of it in situations where we need to control it. And so we need to pull it out of linux. -Kev -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CADkoAxgmfwpKw-cx4abjQZXK0d+-VgKzbu1Rugk=xtp3efk...@mail.gmail.com
Re: stop posting useless cruft and get to work (systemd and Linux are *fundamentally incompatible* -> and I can prove it)
On 26 March 2014 10:13, Cameron Norman wrote: [...] > That is pretty much impossible, according to the developers of the logind > API and its single implementation. Perhaps a subset of the logind API for > use by desktop environments / compositors would be more useful in this init > and OS portability predicament. I think Matthias Clasen, a GNOME developer, > actually recently expressed interest in this from a portable window manager > and compositor's perspective. I can tell you right now, it is *vastly more difficult* to try to adapt programs modified to work with systemd in their current state, than it is to *revert* those programs to their pre-systemd state. There is a huge amount of unknown design parameters that would need to be known to adapt those programs effectively, and since systemd clearly lacks any coherent design, you will not be able to identify coherent ways to fix this. That is your signal to abandon that path right there. Trust me on this, you don't want to try to patch the *current* versions. And what about all the non-systemd improvements made to those programs over the years they worked with systemd? For that, it is *orders of magnitude easier* to take the improvements and adapt them to the pre-systemd version of the program. This is why I specifically mentioned that Debian perform a pre-systemd reversion to escape this mess. Once you have reverted, you can then figure out how to apply the *useful* upgrades to the old programs. This is the easiest path you can take. -Kev -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CADkoAxh2_GyySKzTVOmdTvzSMy8w=pjkhu1u4vj76jtvw-y...@mail.gmail.com
Re: stop posting useless cruft and get to work (systemd and Linux are *fundamentally incompatible* -> and I can prove it)
On 26 March 2014 05:40, Thomas Goirand wrote: [...] > If you want thing to move on, stop posting useless messages, and start > working on alternatives. For example, helping adding more features to > OpenRC would certainly help a way more than this post. I am going to have to respectfully disagree with you on my post being useless. First off, let's realize that we have more than one problem here. The actual implementation work that you indicate should be done is a valid point. We are both in agreement there. However, there exists an even bigger problem to be tackled. You can come up with all the solutions you want, but until it is *widely understood* that your solutions are *needed*, people tend to ignore and dismiss you. You can clearly see that happening in the responses I got back in Nov 2012. You first have to help people *understand* the problem and given how all the other topics on systemd being a failure *still didn't stop* debian's progress with using it I decided a very different perspective needed to be introduced. And I had to wait a while for things to get bad enough for people to see some validity in what I am saying. And while *you* might understand systemd is a problem, it is *objectively evident* that most do not, given the recent momentum to further adopt systemd by the linux community at large. My post is an analysis of systemd from an engineer's point of view. And systemd *violates* every engineering principle I spent years in college to learn. The biggest problem is awareness and that is the primary purpose of my post. And having it discussed in closed or private circles does not help mass awareness. It needs to be out in the open where everyone can read it. But it will have the most traction here. Hence why debian-devel was the primary target all along. -Kev -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CADkoAxhLo5fmJHEukhct2WB1ATH6a4yf_k=kjtm9qvc2gnk...@mail.gmail.com
Re: systemd and Linux are *fundamentally incompatible* -> and I can prove it
On Tuesday, March 25, 2014 11:40:02 AM UTC-5, Jonathan Dowland wrote: > I was very proud of my fellow colleagues for not feeding the troll a > full 24 hours later. Thanks for breaking the record :( Jonathan we've been through this before. -> https://lists.debian.org/debian-devel/2012/11/msg00565.html -> https://lists.debian.org/debian-devel/2012/11/msg00604.html You think I'm retarded or a troll. Believe it or not, I can actually sympathize with why you think that. I too, would find myself to be a huge pain in the ass if I threw a wrench into something as big as systemd. I recognize the frustration, I really do. But I am not trolling you here. There is something that you fundamentally don't get -> if I present a question regarding the interaction of linux and systemd -> and you get pissed with me because it's too exhausting or difficult to formulate a response -> that means you don't really understand how the interaction between linux and systemd works Yes. That's the point (not to piss you off, but to test what you comprehend). That's why engineering has the phrase to begin with... -> if you can't put it in writing, then you don't understand it well enough Because it's pissing you off, it's telling me that we have a problem with the design of systemd. It's underthought. Dangerously underthought. This entire time, my concerns were never about the features of either program. It was always about the design. Features don't make good software.good design makes good software. systemd is its own project (operating system?). It does not have any design blueprint for how it works with linux. That's why you need to pull it out of linux, because it's trashing all the good designs for crap that we can't even explain very well in writing. Which means that we don't really know what this is doing. And when we don't really understand what something is doing, we are extremely vulnerable to a symphony of problems waiting to occur. I would say that trying to resolve the default init system hassle is one example of a problem that could have been easily avoided if we had a blueprint for how systemd is designed. Please try to look past my failings with using lists, and see that we really do have a nightmare situation on our hands. -Kev -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/cadkoaximadsjomvwd1xihlglp3v8utfyb4bqrpa+u0bypz3...@mail.gmail.com
Re: systemd and Linux are *fundamentally incompatible* -> and I can prove it
On 25 March 2014 11:25, William Unruh wrote: [...] > And if they are there, together with all the boldfacing, people tend to > think that you are a complete kook. So you makes your choices... Okay, my apologies. I am not very experienced with lists and the expectations that run within them. Here is a plaintext version stripped of asterisks. I do think the arrows help though. -Kev -- To all debian developers: -> systemd is fundamentally incompatible with linux Now, I realize that's a bold claim, but if you are up for some reading, I will prove it. First -> a little history just to put this into a context that's easier to follow Over a year ago (Nov 2012), I tried to warn you that systemd was a disaster in progress. It started out over a discussion about udev, and some of the reasons people were giving for using systemd seemed to be woefully naive. I tried to explain this simple point at first, but it became increasingly evident that -> none of the people who were advocating systemd -> because they claimed it would solve certain problems -> seemed to understand what systemd would do to linux So, I took some of the problems systemd was supposed to fix, and wrote a response that primarily did three things. 1 -> explain why linux had certain mechanisms, and what would happen if you removed them 2 -> show how those problems could be solved without stripping out very important pieces of the architecture (which systemd would do, knowingly or not) 3 -> the most important one -> probe how much the systemd people really understood about what they were doing to the rest of linux Now, I'm sure many people will jump on that last one right there and declare -> how can you possibly judge what they understand if you don't understand it yourself?!! And this is how... There is a well known saying that runs in every engineering discipline, including software engineering... -> if you can't put it in writing, then you don't understand it well enough Einstein had another version... -> if you can't explain it simply, you don't understand it well enough So, I presented a series of technical questions, that I asked to be answered without references for me to go read documentation. Those questions are not there because I'm clueless as to how systemd works. Those questions are there to see if anyone (including systemd people) had any clue how systemd would interoperate with -> the rest of linux. And I got my answer. -> nope I even said -> the point of this post was to see if these questions could be answered -> because if they couldn't -> that was a very strong signal that they didn't understand it And I got several responses, many of them saying I was... -> ignorant -> unhelpful -> wasting everyone's time because I didn't read the documentation -> weird (lol) -> and in some places elsewhere over the internet -> autistic I even went to Lennart Poettering's google+ page and -> tried to warn everyone there that systemd was headed for failure -> asked Poettering (in a different way) if he could answer what role systemd was to serve in linux I said -> I have a question for you. If you can answer it with one, and ONLY one, concept that describes fully what systemd is I will consider I might have misjudged this. He replied... -> systemd is a suite of basic building blocks to build an OS from Okay -> right there he gives two important pieces of information... 1 -> there is nothing about how it works with linux 2 -> his answer is so vague, it should tell you he hasn't really thought this out systemd will wreck linux, I am certain of it. Without some kind of design blueprint of some sort -> systemd ended up being built by programming blindly in the dark. There is no boundary where systemd stops and linux begins. They will keep on absorbing pieces of linux until systemd is the entire operating system -> and there is no coherent design to how it does / should work. I think everyone here knows how this is going to end. I tried to get this point across back in Nov 2012 -> however, I don't think systemd caused enough chaos back then to really register with people what was coming their way. Now that systemd has wrecked all kinds of previously working stuff, and many are beginning to realize the impossibility of getting systemd to work with linux -> I think this might have some effect this time around. -> Debian needs to cut all ties to systemd It is not possible to save it unless a design blueprint for how it works with linux can be expressed in writing -> and I seriously doubt anyone can (I sure as hell can't). -> revert every program systemd took over to its pre-systemd state -> cut your losses while you still can technically achieve a reversion While systemd might one day work flawlessly on its own -> it has absolutely no business being in linux. And you might ask -> why did I put this
Re: systemd and Linux are *fundamentally incompatible* -> and I can prove it
On 25 March 2014 08:54, Federico Di Gregorio wrote: [...] > Lots of asterisks won't make a point. The asterisks are there to specifically focus your attention on those words. Because -> I find that if I don't use them -> people tend to misread what I write (or more so at least) -Kev -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/cadkoaxjot59abrb-+ihutqf6g8e8mdto5n3vcbwf9zuxzh6...@mail.gmail.com
systemd and Linux are *fundamentally incompatible* -> and I can prove it
To all debian developers: -> systemd is *fundamentally incompatible* with linux Now, I realize that's a bold claim, but if you are up for some reading, I will prove it. First -> a little history just to put this into a context that's easier to follow Over a year ago (Nov 2012), I tried to *warn* you that systemd was a disaster in progress. It started out over a discussion about udev, and some of the reasons people were giving for using systemd seemed to be woefully naive. I tried to explain this simple point at first, but it became increasingly evident that -> none of the people who were advocating systemd -> because they claimed it would solve certain problems -> seemed to *understand* what systemd would do to *linux* So, I took some of the problems systemd was supposed to fix, and wrote a response that primarily did three things. 1 -> explain *why* linux had certain *mechanisms*, and what would happen if you removed them 2 -> show *how* those problems could be *solved* without stripping out very important pieces of the architecture (which systemd would do, knowingly or not) 3 -> the *most important* one -> probe how much the systemd people *really understood* about what they were doing to the rest of linux Now, I'm sure many people will jump on that last one right there and declare -> how can you possibly judge what they understand if you don't understand it yourself?!! And this is *how*... There is a well known saying that runs in every engineering discipline, including software engineering... -> if you can't put it in writing, then you don't understand it well enough Einstein had another version... -> if you can't explain it simply, you don't understand it well enough So, I presented a series of *technical questions*, that I asked to be answered *without* references for *me* to go *read documentation*. Those questions are *not* there because I'm clueless as to how systemd works. Those questions are there to see if *anyone* (including systemd people) had any clue how systemd would *interoperate* with -> the rest of linux. And I got my answer. -> nope I even said -> the *point* of this post was to see if these questions *could* be answered -> because if they couldn't -> that was a *very strong* signal that they *didn't understand it* And I got several responses, many of them saying I was... -> ignorant -> unhelpful -> wasting everyone's time because I didn't read the documentation -> weird (lol) -> and in some places elsewhere over the internet -> autistic I even went to Lennart Poettering's google+ page and -> tried to warn everyone there that systemd was headed for failure -> asked *Poettering* (in a different way) if he *could answer* what role systemd was to serve in linux I said -> I have a question for you. If you can answer it with one, and ONLY one, concept that describes fully what systemd is I will consider I might have misjudged this. He replied... -> systemd is a suite of basic building blocks to build an OS from Okay -> right there he gives two important pieces of information... 1 -> there is *nothing* about how it works with linux 2 -> his answer is so *vague*, it should tell you *he hasn't really thought this out* systemd will *wreck* linux, I am certain of it. *Without* some kind of *design blueprint* of some sort -> systemd ended up being built by *programming blindly in the dark*. There is no *boundary* where systemd stops and linux begins. They will keep on absorbing pieces of linux until systemd is the entire operating system -> and there is no coherent design to how it does / should work. I think everyone here knows how this is going to end. I tried to get this point across back in Nov 2012 -> however, I don't think systemd caused enough chaos back then to really register with people what was coming their way. Now that systemd has wrecked all kinds of previously working stuff, and many are beginning to realize the *impossibility* of getting systemd to work *with* linux -> I think this might have some effect this time around. -> Debian needs to *cut all ties* to systemd It is *not possible* to save it *unless* a design blueprint for how it works *with* linux can be *expressed in writing* -> and I seriously doubt anyone can (I sure as hell can't). -> revert every program systemd took over to its pre-systemd state -> cut your losses while you still can technically achieve a reversion While systemd *might* one day work flawlessly on its own -> it has *absolutely no business* being in linux. And you might ask -> why did I put this on the debian list? This clearly applies to *all* of linux... -> because out of any linux distro that stands a *reasonable chance* to undo the systemd nightmare -> debian is the *most visible* -> and other distros are more likely to *follow your lead* than any other distro that might change If you think I am wrong -> let's settle the debate, once and for all. If sy
Re: Systemd
Thu, 22 Nov 2012 12:56:09 +0800 from Chow Loong Jin > > -> What role is systemd designed to facilitate? > > An init daemon. But why don't you ask yourself -- what role(s) should an init > daemon play anyway? Thank you. Everyone raising a fuss and not many seeing the focus I am trying to direct you towards -> this *had* to be answered by someone other than myself. Let's (just to show what I mean), consider an init daemon facilitates the role of [daemon launch facility] or something like that. Singular concept. I phrased that question with role as a *singular* concept for specific reasons. I won't state them again because you've kindly just answered my question, but I want to focus your attention now towards this last rationale -> If there is more than one role, they should be *identified* and *distinctly* separated into individual ones, and if they interact with themselves or things external, the mechanisms for how they interact should be specified. Things that perform different roles should be considered different entities and separate from one another. -> If this cannot be done (as in it's not so easy to write it out), that is a *very strong* indication the design is not understood well enough for things to move forward with it. This is what I mean when I say the engineering wisdom of : if you can't put it in writing, then you don't understand it well enough. I am afraid the fundamental idea behind systemd has mobilized people into action without a really concrete idea of just *what* is systemd's *role* and what are the ways it interacts with things performing other roles in linux. It looks like systemd takes on a bunch of roles and that makes it very difficult to really understand what it is. I think if it's not so easy to detail out the separate roles that are involved here, it's not so easy to spot complex problems with it down the road. If you can trace out all of the different roles involved, and the follow along all the ways they interconnect, disastrous problems become (more) detectable. This is what I am trying to get you to consider. Everyone gets upset that I don't know what I'm talking about and all I'm trying to do is see if you can easily put it *into words* what's going on, and it's the *people are getting pissed* responses that make me think systemd needs a lot more thought to how it is designed. I will leave you alone now that you recognize the point of the questions. I appreciate your patience with me. I am sorry to get on your last nerves. I pray something good comes from the uproar I have caused. I hope this has some positive effect. -Kev -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CADkoAxhNHwFEkRvB27O3jy9pXAKxL=2htj+rxkgtmthxagn...@mail.gmail.com
systemd
> Sadly it is obvious from the rest of this message that you are not up > to speed on the topic here. If you want to usefully contribute to the > topic, at a very least you should familiarise yourself with the prior > threads about systemd to debian-devel. At a very, bare-minimum least. > It would then of course be polite to other thread participants to make > sure you are at least up to speed on what systemd is and how it works… > > > I think it is categorically important to *identify* and *convey to the > > community*... > > > > -> What role is systemd designed to facilitate? > > > -> Do we know why we want to prevent a process from forking? > > This is something that pretty much goes without saying, if you are > familiar with the technology which underpins what we're talking about. First off, I don't have a sysvinit agenda. I know you didn't say that, but I keep getting the feeling that is what these responses are concluding, and therefore dismissing what I am saying. I use gentoo with openrc. So I would like for you to consider my reasons are something different than -> I am just trying to shoot down anything that is not sysvinit. I read through some of the systemd man page and a little of the original design document. I think I have a rough idea of what systemd thinks it is. But I am not able to form a sound foundation from the ideas systemd describes. It is very dangerous to go ahead with systemd if that first question cannot be given an answer. It seems to me that you are confusing my asking as me being ignorant and stuck to archaic ideas (which I tried to show previously old idea != bad idea), when the real reason I am asking is to get you to think about how this is designed and how it should work. If you can't formulate them and write them down, we have an underthought design. In engineering, there is a *very wise* expression when considering how much thought to give to a design -> If you can't put it in writing, then you don't understand it well enough. Software engineering is no different. Read the second listing as to what caused the Air France 447 crash in 2009. https://en.wikipedia.org/wiki/Air_France_447#Final_report -> Inappropriate control inputs. (the sticks the pilot and copilot each have were not coordinated to act together) In flying (originally with mechanically linked controls), when the pilot and copilot are in the cockpit, their control over the airplane is synchronized. One pilot cannot pull up and the other pilot push down. This has the purpose of letting one pilot know if the other is making a mistake. People make mistakes, planes crash, we learned to have to pilot & copilot with constant connection to each other so that they could watch for errors. What went wrong with Air France 447 is the *software* that controlled the force feedback on the *digital stick* didn't give this any thought and the pilot's control stick was not coupled together with the copilot's control stick. Air France 447 crashed because a rookie pilot pulled the stick the wrong way during a sensor error -> while the experienced pilot held steady and the airplane's software *stupidly* averaged the two inputs together. If it had synchronized it like the mechanical sticks do, Air France 447 would not have crashed. If they had thought it out -> What design does the synchronized sticks fulfil and why is it like that? -> Should we perhaps consider it when coding the digital sticks? -> Why do we have 2 sets of sticks and only one is needed to fly the plane? Not knowing how to *answer the question* of how to make 2 sticks fly one plane, they just decided : we'll average them together. That makes sense. Ok, moving on. If you can't give me an answer to my questions it might be that systemd is so overly complicated and takes on so many separate roles that it might be a disaster to lump them all together. I say might, because unless you can show me how it won't, then it certainly needs some more thought to its design, and certainly needs to answer my questions with something besides *sigh, isn't it obvious you know nothing...read documentation* So I would appreciate it if you would consider that linux might be used in some important technology, like deployment of airbags in cars one day, and I would like you to be able to see that we might have a problem with what all systemd is trying to take control over and how that might require a bit more thought. People went to the moon on 1960s technology, others designed the unix model with 1960s technology. What they first had to master was *understanding what it was they were doing* - they had to *comprehend* it. They gave it thought. They *designed* it according to what *role* it was supposed to serve. There is real wisdom in that. So let's review the purpose of my previous post in this sobering light one more time. Has systemd considered that the *filesystem* in linux is the mechanism in which programs can interact with other progr
Re: Gentoo guys starting a fork of udev
> Me too, please read: > http://catb.org/jargon/html/T/top-post.html Oh crap, my apologies. I honestly forgot that the reply was still at the bottom of my email. I did not intentionally leave it there. It certainly wasn't some passive-aggressive kind of post-reply, I do apologize for it being there. -Kev
Re: Gentoo guys starting a fork of udev
unning them with deception. Since unix long ago learned that you should only use the admin account to do admin things, on unix, malware might print through all the paper you have, or delete all of your files, but with minimal permissions, the damage would (usually) stop there. It would suck, but it wasn't compromise your entire computer with just browsing the web suck. You had to be targeted by crackers, your system wasn't so naive as to just let any and everybody have their way - hence, where the unix model got its start. Microsoft tested what happens when you remove a police force from a population - anarchy and chaos and vigilantes ensue. Only it's system - malware, bluescreens, and antivirus. Would not call it a better way to go. People don't like history lessons because they feel lectured when history disagrees with their idea. History shows people who don't like history lessons tend to concretely re-establish why we teach history lessons in the first place. History is a ladder. Kick it aside and start climbing anyway and eventually you will climb up to where you started, minus a significant amount of time and energy, and possibly your life as well. If it is something new, go for it. If it is something previously done but abandoned, there are probably some lessons why, and that is what some of the people here are trying to get you to see. -Kev On 19 November 2012 04:23, John Paul Adrian Glaubitz wrote: > Hello Kevin, > > On Sun, Nov 18, 2012 at 09:51:22PM -0600, Kevin Toppins wrote: >> Just because something is very old, does not necessarily make it >> wrong, obsolete, or require that it be changed. > > Correct. But on the other hand, just because something is 40 years > old, doesn't mean we're not allowed to rethink the idea and start from > scratch. A fresh breeze is always needed from time to time. > >> The unix model stemmed from when computers were mainframes and single >> user systems had not been conceived. > > Thank you for your lesson, but I think I already know that. > >> Unix's design of minimal permissions was/is a good idea. Since not >> everything running reflects the mindset of just one person, it makes >> sense to isolate users from messing with one another. Or, to allow for >> some relative sanctuary while using the system with others logged in. > > And this has to do with replacing sysvinit with a modern alternative > how? We still have user separation. In fact, we have even more > possibilities by being able to control what ressources single users > can use (cgroups) which is very important if you have a big cluster > with dozens of concurrent users. > >> It worked well to keep the peace. > > Again, that doesn't mean we're not allowed to rethink the idea. CRT > television sets, analogue broadcasting, steam engines, mechanic > typewriters, analogue photography, audio and video cassettes also > worked well for decades. Still, people have upgraded to newer > technologies when they became available. > >> Computer viruses (really) emerged when microsoft threw that notion to >> the wind and made their os a single user system with unlimited power >> and no layers of permissions to protect the integrity of the system. > > Well, no. You can have a single user operating system and still be > perfectly free of virusses. On the other hand, you can even have > virusses on Linux machines. An important factor of a successful virus > infection is social engineering. Even Windows can be safe when taking > the proper precautions and even without a virus scanner. > >> It's like if the pentagon upgraded every united states government >> employee with the highest security clearance. Sure the spec ops guy >> has clearance. So does the janitor and the delivery guy as well. It's >> defcon 1 24/7. > > Again, how is this related to systemd vs sysvinit? As I mentioned > already, systemd has even more features to ensure resource control and > security (fine-grained permissions for journalctl, for example). > >> That is why viruses are so prevalent. That is the real reason. > > No, virusses are prevalent because people open every file without > extra precautions. Even advanced users and administrators sometimes > happen to do that. > >> So unix stayed with the idea of minimal permissions for 40 years. They >> still stay with it. So does linux. > > It's getting tiresome. I suggest you just read up on systemd a bit > before you start your discussion. systemd is actually a huge > improvement over sysvinit regarding reliability and security. It's > designed with these considerations in mind. > >> Just about every os I can think of that has some resistance to malware >> us
