On Mon, Feb 17, 2014 at 12:28 PM, Yuri K. Shatroff <yks-...@yandex.ru> wrote: > Sorry for entering others' dialog... > > > On 17.02.2014 21:13, Canek Peláez Valdés wrote: >> >> On Mon, Feb 17, 2014 at 6:17 AM, Tanstaafl <tansta...@libertytrek.org> >> wrote: >> [snip] >>>>> >>>>> Can you surgically remove systemd in the future without reverse >>>>> >>>>> engineering >>>>> half of what the LSB would look at the time, or will its developers >>>>> ensure >>>>> that this is a one time choice only? >>> >>> >>> >>>> You guys talk about software like if it was a big bad black magical >>>> box with inexplicable powers. >>>> >>>> If someone is willing and able, *everything* can be "surgically >>>> remove[d]". We got rid of devfs, remember? We got rid of OSS (thank >>>> the FSM for ALSA). We got rid of HAL (yuck!). GNOME got rid of bonobo, >>>> and ESD. KDE got rid of aRts (and who knows what more). >>> >>> >>> >>> I think you are being a little disingenuous here. >> >> >> I am not. >> >>> The obvious unspoken meaning behind the 'can you surgically remove' was: >>> >>> Can you do it *easily*? I'm sure you would not suggest that getting rid >>> of >>> the above were 'easy'? >> >> >> I've never said it was easy. I said it could be done by someone >> willing and able. I repeated that like five times I think. I said it >> was done before; I never said it was easy. > > > The whole point of creating new software is making things easier. Easier to > use, easier to maintain, easier to remove.
Well, systemd is easier to use after a little time learning how it works. And it seems to be easier to maintain that thousands of lines of spaghetti shell code. And, I'm sorry, did you just said "easier to remove"? Seriously? You think the kernel is "easier to remove"? Or glibc? > >> But it can be done, and that's a indisputable fact. > > > A total ground-up rewrite of the whole Linux is also quite possible. Of course it is; that's the beauty of free (libre) software. > > >>> It simply doesn't matter if systemd boils down to one monolithic binary, >>> or >>> 600, if they are tied together in such a way that they can not >>> *individually* be replaced *easily and simply* (ie, without having to >>> rewrite the whole of systemd). >> >> >> You are setting a group of conditions that preemptively wants to stop >> adoption of anything that is tightly integrated. That is a losing >> strategy (different projects actually *want* tight integration), and >> besides the burden of work should not fall on the people wanting to >> use a tightly integrated stack. > > > How Integrated? The TCP/IP stack *is* integrated. But it is *protocol* > integration, *standards* integration not *software* integration. You do want > tight integration where it just can't work otherwise, but the design of Unix > provides (well, again repeating this), and almost any robust design should > provide, the ignorance of one abstraction level about another. Why HAL? Why > udev? Why drivers as modules? Why not just go and integrate all stuff into > the kernel, well (again!) like MS do, and don't please say I compare wrong > things just because MS is not OSS. You make a wrong comparison, because MS is not free (libre) software. With Linux, and systemd, and OpenRC, and HAL, and devfs, and sysv, we have been able to try new technologies (and see that some of them fail, like HAL [yuck!]), because we have the source. As you said, you can replace the whole of Linux if you so desire (and have the technical ability). You will never be able to do that with any MS software, and so the comparison makes no sense. > >> You want individual modules that are "easily and simply" replaced? >> Then WROTE THEM. Don't expect the systemd authors (or any other) to do >> it for you. > > > We really don't expect that systemd's authors do anything for us. Anything > they do is not for us, thanks. Sorry, but they do. Read the mailing list. Feature requests, bugs, they do it for their users. Every time a new distro chooses systemd as init, the developers try to help the maintainers to integrate systemd to it. >>> That said, it seems to me that, for now at least, it isn't that big a >>> deal >>> to switch back and forth between systemd and, for example, OpenRC. > > > "For now" it's not, but take a look into the future when not a single > product will be published without systemd's support, just because it's > everywhere -- and since it's everywhere, then why bother support anything > other? Time, money... If enough people, willing and able, want to do it, they will. Look at ReactOS. Or Syllable. Or Hurd. Or Debian/kFreeBSD. The thing (and that's also my point), apparently *most* of the people willing and able to create cool software have decided that systemd is the way to go. And, even if you want to attribute that to a simple monetary issue, most of them do it *happily* because many things are just easier to do with systemd. > So it's a matter of time -- you'll personally be happy > with this scenario -- at first -- but think further... I do. All the time, since 1996 when I started using Linux. > They'll be able to > stuff everything into it, making effectively a thing in itself which will > dictate you where to go and what to do, just because you're not technically > competent enough to deal with it -- hence more support calls and more $ etc > etc. Oh, but nobody will be able to do that to me. I know how to write code. I'm willing (and I believe able) to write and/or modify software if I don't like how it does things. I've done it before; I could do it again. The thing is, with Linux+systemd+GNOME I need to do it less and less with every new release. The developers of the whole stack are bringing Linux to where I have always wanted it to be. I don't believe in Red Hat's being a corporation of Good, nor any other > corporation being such, and please remember the notorious examples of almost > privatizing OSS by other 'corporations of Good'. (Android, MySQL, almost > OpenOffice...) I don't care about RedHat; I used that distribution a couple of years before moving to Mandrake, and then finally to Gentoo in 2002. I don't care about them; I care about Linux, and Gentoo. And *nothing* that RedHat does or stops doing it affect Gentoo nor Linux in the negative, from my point of view. > Well, there's some probability that by the time systemd occupies all linux > distros, some clever RH guy (or a green soxx guy) will emerge and emerge > systemd v2 which will be different ... But it's not something one should > count on. If someone is willing and able to write something better than system, THEY WILL. >> [...] >> >> If *someone*, *willing* AND *able* steps up to do ALL that work, MAYBE >> it would happen. >> >> But don't complain if no one does, and it doesn't. > > > That's your point -- and mine. We aren't complaining -- we want to prevent > this. Prevent what? People writing new software that offers cool features, and therefore distros are using them? > The forward-looking people must unite, it may sound ridiculous, > against systemd You cannot stop people for writing new cool stuff, nor distros for wanting to using them. You CAN write your own cool stuff, and convincing people that is better than the alternative. But you have to offer *at least* the same features than the competition. That's why *nobody* on Debian's TC choose OpenRC above Upstart and systemd. > -- not because of its design, technical details etc, but > because otherwise in short time you'll end up comparing systemd to itself. ? > You know what it is: everything's free but nothing to choose from. We had it > before, it's called communism. Maybe it is not that bad but we don't want it > anymore. (Really? A cold war reference?) The code is out there. You can choose to pick any point in time of the whole stack (ca. 2009, before systemd existed), and wrote from there if you have enough people willing and able to. No one is taking anything from any one. No one is forcing nothing. Free software is being written and offered, and knowledgeable people are choosing to use it in their distros. You are against that? Then wrote your own version with the same (or better) features. Regards. -- Canek Peláez Valdés Posgrado en Ciencia e Ingeniería de la Computación Universidad Nacional Autónoma de México
