Re: implicit linkage (was: Re: Effectively criticizing decisions you disagree with in Debian)
On Sun, Oct 12, 2014 at 03:30:49PM +0300, Andrei POPESCU wrote: This is the same reason we are using shared libraries and the Debian Security Team is doing it's best to track code copies. Consider /etc/init.d/skeleton a library then. It's sources to any /etc/init.d script anyway. No, it doesn't. Again, simple 'no' is beautiful, but hardly contributes to the discussion. $ grep skeleton /etc/init.d/* /etc/init.d/dictd:# based on /etc/init.d/skeleton v1.7 05-May-1997 by miqu...@cistron.nl /etc/init.d/README:# Provides: skeleton /etc/init.d/skeleton:# Provides: skeleton It seems like you misunderstood the purpose of /etc/init.d/skeleton. It's not a library, but something to use as a base to write your own script. As of Jessie most of 'skeleton' has been turned into 'init-d-script' though. It was my mistake indeed. Thanks for the correction. Somehow I mistook /lib/lsb/init-functions for /etc/init.d/skeleton. True, but sysv-rc still can't deal with them correctly. It does not have to deal with the hardware, as it not its' job. It has to mount filesystems. No, it does not have to. In Debian, there's /etc/init.d/mountall.sh to do this job, in case initrd didn't care for it already. init(8) does not mount anything. $ dpkg -S /etc/init.d/mountall.sh initscripts: /etc/init.d/mountall.sh I never said init(8) would mount anything, but sysv-rc. By sysv-rc I mean /etc/init.d/rc and all other scripts required to boot your system. Apparently most of these are split out in the initscripts package. Ok, correction taken. And, to spice things up, [1]. Beautiful link telling everyone that it's not the init job to mount /usr as there's initrd for that. But sysv-rc still has to take care your / and /usr is remounted according to your fstab and also for mounting everything else defined in /etc/fstab and how this interacts with the rest of the boot / daemons. No objections here. Please enlighten me what exactly is systemd-specific here. Basically they tell yadda-yadda-yadda, fix your applications, and if you don't - we have this 90-second hack for you. Systemd makes it possible for me to adjust mpd's .service file to *require* a specific mount. This is not possible with sysv-rc's own mechanisms, I'd have to script it myself. But that's filesystem dependency, not a network one. Reco -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141013132742.ga30...@d1696.int.rdtex.ru
Re: implicit linkage (was: Re: Effectively criticizing decisions you disagree with in Debian)
Hmm. Let's comment that for people newer to scripting than I am. On Sun, Oct 12, 2014 at 6:28 AM, Steve Litt sl...@troubleshooters.com wrote: [...] Daemontools runscripts are incredibly simple shellscripts, that I'm sure you could write no sweat except in very wierd edge cases. Here's my run script for my home-grown cron substitute: == #!/bin/sh ### DON'T START littcrond UNTIL THE NETWORK'S UP ### pingaddr=8.8.8.8 pingaddr=192.168.something Binding a value to pingaddr twice? echo littcrond checking network 12 echo is kind of like a basic print statement, except you sort of don't need quotes. littcrond , checking , and network are passed as three separate tokens to echo, which sees each one as a string literal (because it doesn't recognize any of them as something defined) and echoed separately literally. The clot 12 , (man bash, / search for redirect) redirects stderr to stdout for the echo. while ! ping -q -c1 $pingaddr /dev/null; do between the while and the semicolon is the condition. Between the do and the done are the commands to execute in the loop. The loop condition is tested at the start of the loop. Exclamation mark inverts the test. ping returns a success value. In shell, success is zero, failure non-zero. That allows failure to be an error code, but it also surprises you if you forget that it's the reverse of C and many other languages. This doesn't really matter here, because ! expects the shell version of a boolean flag, so it does what it should. man ping tells us -q is quiet and -c1 says stop after 1 packet. $pingaddr refers through the name pingaddr, which was last bound to a LAN local address above, essentially as if pingaddr were a variable. sleep 1 echo littcrond REchecking network 12 done So the meat of the loop is in the test, and the body we just sleep and so we are waiting/checking. ### RUN THE DAEMON ### exec envuidgid slitt envdir ./env setuidgid slitt \ /d/at/python/littcron/littcron.py \ /d/at/python/littcron/crontab man exec for clues to that, understand that littcron.py is Steve's special cron (right, Steve?), and that he is setting up a special environment for things and there's other stuff there that I can only guess at, not having the code to littcron, I think. So I'll punt here. == -- Joel Rees Be careful where you see conspiracy. Look first in your own heart, and ask yourself if you are not your own worst enemy. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CAAr43iPyBSL+CHt-wcz2YN1HC5jKWWbbtcmVniwMCkFbp_8=x...@mail.gmail.com
Re: implicit linkage (was: Re: Effectively criticizing decisions you disagree with in Debian)
On Du, 12 oct 14, 01:41:34, Reco wrote: Hi. On Sat, 11 Oct 2014 23:02:01 +0300 Andrei POPESCU andreimpope...@gmail.com wrote: On Sb, 11 oct 14, 23:20:34, Reco wrote: On Sat, 11 Oct 2014 20:47:36 +0300 Andrei POPESCU andreimpope...@gmail.com wrote: At least with systemd if you fix a bug it will benefit all daemons using it. No, quite the contrary. By fixing such jack-of-all-trades libsystemd library you're risking to *break* some other daemons. But, pretending your point is valid, fixing /etc/init.d/skeleton grants the same benefits. Nope. The reason being? Code quality of systemd is not top-grade (to say lightly), and the project hardly reached its' maturity. It'll only get worse from here. And, I have to ask. Are you denying both of my statements, or the last one only? The last one only. I have no opinion on the code quality of systemd as I know nothing of C. This is the same reason we are using shared libraries and the Debian Security Team is doing it's best to track code copies. Consider /etc/init.d/skeleton a library then. It's sources to any /etc/init.d script anyway. No, it doesn't. Again, simple 'no' is beautiful, but hardly contributes to the discussion. $ grep skeleton /etc/init.d/* /etc/init.d/dictd:# based on /etc/init.d/skeleton v1.7 05-May-1997 by miqu...@cistron.nl /etc/init.d/README:# Provides: skeleton /etc/init.d/skeleton:# Provides: skeleton It seems like you misunderstood the purpose of /etc/init.d/skeleton. It's not a library, but something to use as a base to write your own script. As of Jessie most of 'skeleton' has been turned into 'init-d-script' though. True, but sysv-rc still can't deal with them correctly. It does not have to deal with the hardware, as it not its' job. It has to mount filesystems. No, it does not have to. In Debian, there's /etc/init.d/mountall.sh to do this job, in case initrd didn't care for it already. init(8) does not mount anything. $ dpkg -S /etc/init.d/mountall.sh initscripts: /etc/init.d/mountall.sh I never said init(8) would mount anything, but sysv-rc. By sysv-rc I mean /etc/init.d/rc and all other scripts required to boot your system. Apparently most of these are split out in the initscripts package. And, to spice things up, [1]. Beautiful link telling everyone that it's not the init job to mount /usr as there's initrd for that. But sysv-rc still has to take care your / and /usr is remounted according to your fstab and also for mounting everything else defined in /etc/fstab and how this interacts with the rest of the boot / daemons. Please enlighten me what exactly is systemd-specific here. Basically they tell yadda-yadda-yadda, fix your applications, and if you don't - we have this 90-second hack for you. Systemd makes it possible for me to adjust mpd's .service file to *require* a specific mount. This is not possible with sysv-rc's own mechanisms, I'd have to script it myself. Brilliant question. Certainly you've meant systemd, right? Just joking. Joke aside - because it's convenient to mount a filesystem once you really need it, and (which is much more important) - unmount it once it's not needed anymore. You mean a systemd automount? Thanks for the hint ;) Kind regards, Andrei -- http://wiki.debian.org/FAQsFromDebianUser Offtopic discussions among Debian users and developers: http://lists.alioth.debian.org/mailman/listinfo/d-community-offtopic http://nuvreauspam.ro/gpg-transition.txt signature.asc Description: Digital signature
Re: implicit linkage (was: Re: Effectively criticizing decisions you disagree with in Debian)
On Sun, 12 Oct 2014 19:06:11 +0900 Joel Rees joel.r...@gmail.com wrote: Hmm. Let's comment that for people newer to scripting than I am. On Sun, Oct 12, 2014 at 6:28 AM, Steve Litt sl...@troubleshooters.com wrote: ### RUN THE DAEMON ### exec envuidgid slitt envdir ./env setuidgid slitt \ /d/at/python/littcron/littcron.py \ /d/at/python/littcron/crontab man exec for clues to that, understand that littcron.py is Steve's special cron (right, Steve?), and that he is setting up a special environment for things and there's other stuff there that I can only guess at, not having the code to littcron, I think. So I'll punt here. Exec takes the current process, which in this case is the daemontools run script, and swaps exec's argument for the current process. So, if the current process is a shellscript PID 4321, after exec gnumeric, PID 4321 is now Gnumeric, not a shellscript. envdir, envuidgid and setuidgid are executables provided by daemontools. Let's talk about envdir. Although in daemontools you can export environment variables to sub programs, just like in any other shellscript, idiomatic daemontools usage specifies that instead of exporting within a shellscript, you have an environment directory in which each desired environment variable is associated with a file of the same name as the environment variable name, and the contents of the file is the value of the environment variable. So: envdir ./env The preceding means look in ./env, and all filenames are environment variable names, and the contents of each is the value of the respective filename. setuidgid and envuidgid are daemontools provided executables to accommodate running as an arbitrary user instead of root. Consider the command: setuidgid slitt The preceding runs the entire command defined by its arguments as user slitt instead of user root. In other words: setuidgid gnumuser gnumeric test.gnumeric The preceding runs gnumeric as user gnumuser. One gotcha: It runs it as user slitt with user slitt's major group, but it doesn't run it with auxilliary groups, for slitt, defined in /etc/group. So if the command depends on membership in those auxilliary groups, you have to do some fancy footwork. Here's another challenge: Now that you're running as a non-privileged user, you can't read the ./env directory. This is where envuidgid comes in: envuidgid slitt The preceding tells daemontools that user slitt can read the environment directory. And the way envuidgid command works, after making this notation it simply passes control to the command defined in its arguments, which include envdir (which finally defines the environment directory) and setuidgid, and last but not least, the actual program you're daemonizing. And speaking of the devil, /d/at/python/littcron/littcron.py /d/at/python/littcron/crontab The preceding is the cron substitute I wrote, whose one argument is the crontab file you're using. If I wanted, I could manually run it in the foreground and it would function just fine. But I wanted it automatic, and managed as a daemon. So daemontools runs it as user slitt, and puts its environment variables in the /service/littcrond/env directory. Environment vars are important here, because my cron program is called upon by its constituants to run GUI programs, so its $DISPLAY and $XAUTHORITY vars must be set right. SteveT Steve Litt* http://www.troubleshooters.com/ Troubleshooting Training * Human Performance -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141012141133.03803...@mydesq2.domain.cxm
Re: implicit linkage (was: Re: Effectively criticizing decisions you disagree with in Debian)
On Vi, 10 oct 14, 08:36:23, Joel Rees wrote: Some complexities you can encapsulate or hide, or expose in an organized manner so that that are easier to deal with. Others, no. [big snip] The complexity argument can be used both ways: - the Unix way (do one thing and do it well) leads to many small tools that can be combined in different ways, where each tool has its own quirks, bugs, release schedules, etc. that only increase complexity - sysvinit (/bin/init) is indeed quite simple, but in practice it's own mechanisms (/etc/inittab) are only used to start sysv-rc (/etc/init.d/rc), which starts all other initscripts, poorly written (/etc/init.d/skeleton itself is known to have bugs) in a (poor) programming language (shell script) with many different implementations (bash, dash, etc.). The scrips are not even enough, they have to rely on additional tools like start-stop-daemon(8) with their own quirks and bugs. - each service/daemon is implemented in its own unique way, with different methods of running (quite often multiple ways, depending on start-up switches, like foreground, forking, etc.), reloading, logging, etc. - computers have gotten quite complex themselves with removable devices, complex network connectivity, etc. - multiple users on the same system (GNU/Linux is supposed to be a multiuser system, isn't it) with different backgrounds, level of technical understanding, expectations, etc. It feels to me like systemd (the project) is rather *trying* to reduce complexity, by providing: - a clear and simple way (unit files) to declare what a service needs and how it should be run and a clear and simple method for the daemon to notify when it is ready to provide its service if its authors choose to implement it - mechanisms to deal with badly behaved daemons as well as provide proper isolation (e.g. cgroups, tmp files handling, etc.) - mechanisms to deal with the complex interactions between daemons, devices, networks, etc. - a logging mechanism that can capture *all* output of a daemon (stdout, stderr, logging) - a unified way to manage users (as in humans) and their complex ways of interacting with the computer (different privileges, local, remote, etc.) - etc. Is systemd (the project) trying to do too much? Possibly. Would it be better if this was done in a modular design *done right*? Probably. Yet, none of the solutions so far has *really* caught on. daemontools, runit, s6, init-ng, etc. and even upstart were either never adopted on a large scale or eventually abandoned in favor of systemd. As far as I understand Linus Torvalds himself admits that a modular kernel design is better, yet he choose to make Linux monolithic. On the other hand Hurd is still not even in a releasable state. Could it be that a modular design for such complex tasks becomes too difficult to *do it right*? Is systemd going to change the GNU/Linux ecosystem? Definitely. Will this change be good or bad? Only time will tell, but I'm quite sure that even if the change will turn out to be bad it will *not* destroy GNU/Linux, but help it evolve in better ways. Kind regards, Andrei -- http://wiki.debian.org/FAQsFromDebianUser Offtopic discussions among Debian users and developers: http://lists.alioth.debian.org/mailman/listinfo/d-community-offtopic http://nuvreauspam.ro/gpg-transition.txt signature.asc Description: Digital signature
Re: implicit linkage (was: Re: Effectively criticizing decisions you disagree with in Debian)
Hi. On Sat, 11 Oct 2014 15:18:58 +0300 Andrei POPESCU andreimpope...@gmail.com wrote: On Vi, 10 oct 14, 08:36:23, Joel Rees wrote: Some complexities you can encapsulate or hide, or expose in an organized manner so that that are easier to deal with. Others, no. [big snip] The complexity argument can be used both ways: Indeed. In fact: - the Unix way (do one thing and do it well) leads to many small tools that can be combined in different ways, where each tool has its own quirks, bugs, release schedules, etc. that only increase complexity On the other hand, full blown systemd comes with 69 binaries on board, and such number of binaries reduce complexity somehow :) - sysvinit (/bin/init) is indeed quite simple, but in practice it's own mechanisms (/etc/inittab) are only used to start sysv-rc (/etc/init.d/rc) You're wrong. At least gettys are started via /etc/inittab, and Ctrl-Alt-Del handling goes there too. , which starts all other initscripts, poorly written (/etc/init.d/skeleton itself is known to have bugs) Every software more complex than 'Hello World' has bugs. Heck, *systemd* has bugs. in a (poor) programming language (shell script) As latest development of OpenSSL show us, C isn't that great programming language either, and more complex than shell. with many different implementations (bash, dash, etc.). As long as shell in question conforms with POSIX specification, it does not matter. And nobody forbids one to put a binary into /etc/init.d, it'll work. Or a Perl script. It's just a convention that everyone put shell scripts there. The scrips are not even enough, they have to rely on additional tools like start-stop-daemon(8) with their own quirks and bugs. That's the intended usage of shell scripts - to be a glue between utilities. Does it surprise you? - each service/daemon is implemented in its own unique way, with different methods of running (quite often multiple ways, depending on start-up switches, like foreground, forking, etc.), reloading, logging, etc. Given that said 'services' are written by different people - that's nothing unusual. In fact, ever-growing DSL of systemd's units clearly shows that 'one size fits all' approach constantly fail to account for various corner cases. - computers have gotten quite complex themselves with removable devices, complex network connectivity, etc. 'Removable devices' could been news in 1980s. 'Complex network connectivity' usually requires one to configure a network interface or two, and start a bunch of helper daemons. It would be fair argument if systemd suite contained implementations of all VPN clients known to the man - but it does not. - multiple users on the same system (GNU/Linux is supposed to be a multiuser system, isn't it) with different backgrounds, level of technical understanding, expectations, etc. Wait, wait, wait. You mean there was no multiuser systems based on GNU/Linux before systemd invention? Or said multiuser systems were unusable? It feels to me like systemd (the project) is rather *trying* to reduce complexity, by providing: - a clear and simple way (unit files) to declare what a service needs and how it should be run and a clear and simple method for the daemon to notify when it is ready to provide its service if its authors choose to implement it By inventing its' own DSL [1] to write such unit files, therefore moving complexity from writing a shell script to learning constantly changing DSL. - mechanisms to deal with badly behaved daemons as well as provide proper isolation (e.g. cgroups, tmp files handling, etc.) You've probably meant 'using existing kernel mechanisms to deal with…'. - mechanisms to deal with the complex interactions between daemons, devices, networks, etc. Please provide an example of such interaction. And, while we're at it, a definition of a 'network' you're using here. - a logging mechanism that can capture *all* output of a daemon (stdout, stderr, logging) Which any daemon shouldn't have at all to start with. The very definition of daemon implies it detached own stdout, stderr and stdin. Systemd has couple of interesting tricks for starting daemons (ptrace, clearing environment, to name a few), but logging mechanism (aka journald) is an optional part of systemd. - a unified way to manage users (as in humans) and their complex ways of interacting with the computer (different privileges, local, remote, etc.) Said unified way is unable to distinguish a user at the console from a user who's connecting to a computer by means of x11vnc :) Does not assign a 'seat' to the ssh-connected user. And is only good for a typical desktop. Clearly there's much work to be done here. [1] https://en.wikipedia.org/wiki/Domain-specific_language Reco -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of
Re: implicit linkage (was: Re: Effectively criticizing decisions you disagree with in Debian)
On Sat, 11 Oct 2014 15:18:58 +0300 Andrei POPESCU andreimpope...@gmail.com wrote: On Vi, 10 oct 14, 08:36:23, Joel Rees wrote: Some complexities you can encapsulate or hide, or expose in an organized manner so that that are easier to deal with. Others, no. [big snip] The complexity argument can be used both ways: - the Unix way (do one thing and do it well) leads to many small tools that can be combined in different ways, where each tool has its own quirks, bugs, release schedules, etc. that only increase complexity At first, yes. But over time these do-one-thing-and-do-it-well pieces become battle-hardened and fully tested, and they change very slowly. And, they're not subject to feature creep. - sysvinit (/bin/init) is indeed quite simple, but in practice it's own mechanisms (/etc/inittab) are only used to start sysv-rc (/etc/init.d/rc), which starts all other initscripts, poorly written (/etc/init.d/skeleton itself is known to have bugs) in a (poor) programming language (shell script) with many different implementations (bash, dash, etc.). The scrips are not even enough, they have to rely on additional tools like start-stop-daemon(8) with their own quirks and bugs. :-) sysvinit is an idea whose time has gone. sysvinit is a poor way to showcase the Unix Way. First of all, the whole idea of runlevels is bizarre, and adds a lot of complexity to init scripts. If you compare a daemontools /service/myserviced/run to an init script, you'll see an order of magnetude simplification, without sacrificing the flexibility of a shellscript. - each service/daemon is implemented in its own unique way, with different methods of running (quite often multiple ways, depending on start-up switches, like foreground, forking, etc.), reloading, logging, etc. Daemontools, and I'd assume all the PID1 softwares based on daemontools, handles the backgroundization itself. So you just use a flag to run your daemon in the foreground, and it's taken care of. For those developers who insist on making their lives difficult by backgrounding it themselves, with no foreground switch, daemontools includes a program which *sometimes* can foregroundize the backgroundized service, although obviously the real way to do it is to have the original programmer provide a way to run his program in the foreground. - computers have gotten quite complex themselves with removable devices, complex network connectivity, etc. - multiple users on the same system (GNU/Linux is supposed to be a multiuser system, isn't it) with different backgrounds, level of technical understanding, expectations, etc. It feels to me like systemd (the project) is rather *trying* to reduce complexity, by providing: - a clear and simple way (unit files) to declare what a service needs and how it should be run and a clear and simple method for the daemon to notify when it is ready to provide its service if its authors choose to implement it - mechanisms to deal with badly behaved daemons as well as provide proper isolation (e.g. cgroups, tmp files handling, etc.) - mechanisms to deal with the complex interactions between daemons, devices, networks, etc. - a logging mechanism that can capture *all* output of a daemon (stdout, stderr, logging) - a unified way to manage users (as in humans) and their complex ways of interacting with the computer (different privileges, local, remote, etc.) I *might* characterize the preceding as trying to reduce complexity for the dufus who can't even write a shellscript. However, the cost of this reduced complexity for the dufus is huge complexity within the program: complexity even smart people can't work around without some truly ridiculous kludges. Also, and this is just my opinion, reducing complexity is not what I think Red Hat is trying to do. I think they're trying to make an operating system so complex that their help is necessary for anything but the most plain vanilla installations, and they're trying to create a Linux ecosystem where all distributions must march to the Red Hat drummer, with the ultimate goal of monopolism and divergence from standards (POSIX for one). Like I said, this is my opinion. You might say Hanlon's razor, and I'd reply follow the money. - etc. Is systemd (the project) trying to do too much? Possibly. :-) Nice understatement. Would it be better if this was done in a modular design *done right*? Probably. I'd say modular design done right would be for systemd to be PID1 and nothing else. It should be able to accept all PAM implementations currently accepted. It shouldn't need to subsume all sorts of other OS functions. And if that were the case, it would be done already, with not a bit of resistance from users. Yet, none of the solutions so far has *really* caught on. daemontools, runit, s6, init-ng, etc. and even upstart were either never adopted on a large scale or eventually
Re: implicit linkage (was: Re: Effectively criticizing decisions you disagree with in Debian)
On Sb, 11 oct 14, 19:57:42, Reco wrote: On Sat, 11 Oct 2014 15:18:58 +0300 Andrei POPESCU andreimpope...@gmail.com wrote: On Vi, 10 oct 14, 08:36:23, Joel Rees wrote: Some complexities you can encapsulate or hide, or expose in an organized manner so that that are easier to deal with. Others, no. [big snip] The complexity argument can be used both ways: Indeed. In fact: - the Unix way (do one thing and do it well) leads to many small tools that can be combined in different ways, where each tool has its own quirks, bugs, release schedules, etc. that only increase complexity On the other hand, full blown systemd comes with 69 binaries on board, and such number of binaries reduce complexity somehow :) coreutils alone has 107 binaries. - sysvinit (/bin/init) is indeed quite simple, but in practice it's own mechanisms (/etc/inittab) are only used to start sysv-rc (/etc/init.d/rc) You're wrong. At least gettys are started via /etc/inittab, and Ctrl-Alt-Del handling goes there too. Oh yes, forgot about that. But my point still stands: why is (almost) nobody using /etc/inittab to manage their services? , which starts all other initscripts, poorly written (/etc/init.d/skeleton itself is known to have bugs) Every software more complex than 'Hello World' has bugs. Heck, *systemd* has bugs. Yes, but with initscripts you can get slightly different version of the same bug (e.g. depending on which version of 'skeleton' they are based on, the script-fu of the respective maintainer, the phase of the moon, etc), but much more difficult to fix, because you have to inspect each package. At least with systemd if you fix a bug it will benefit all daemons using it. This is the same reason we are using shared libraries and the Debian Security Team is doing it's best to track code copies. The recent method of using a common script goes in the right direction though. in a (poor) programming language (shell script) As latest development of OpenSSL show us, C isn't that great programming language either, and more complex than shell. Sure, but at least a lot of eyeballs are looking at it. How many eyes do you think look at the average initscript? with many different implementations (bash, dash, etc.). As long as shell in question conforms with POSIX specification, it does not matter. And nobody forbids one to put a binary into /etc/init.d, it'll work. Or a Perl script. It's just a convention that everyone put shell scripts there. You're right, I just went through Policy 9.3 and can't find it explicitly stated that scripts in /etc/init.d/ should be shell scripts, but it seems to be an implicit assumption (ha!). The scrips are not even enough, they have to rely on additional tools like start-stop-daemon(8) with their own quirks and bugs. That's the intended usage of shell scripts - to be a glue between utilities. Does it surprise you? Nope, it just proves my point that sysv-rc is *very* complex. - each service/daemon is implemented in its own unique way, with different methods of running (quite often multiple ways, depending on start-up switches, like foreground, forking, etc.), reloading, logging, etc. Given that said 'services' are written by different people - that's nothing unusual. In fact, ever-growing DSL of systemd's units clearly shows that 'one size fits all' approach constantly fail to account for various corner cases. Such as? - computers have gotten quite complex themselves with removable devices, complex network connectivity, etc. 'Removable devices' could been news in 1980s. True, but sysv-rc still can't deal with them correctly. 'Complex network connectivity' usually requires one to configure a network interface or two, and start a bunch of helper daemons. It would be fair argument if systemd suite contained implementations of all VPN clients known to the man - but it does not. I'll just give my laptop as example: I have wired wireless at home, other wired/wireless network if I take my laptop around plus a dongle for mobile. And then there's IPv6 (coming... is... coming... whatever). - multiple users on the same system (GNU/Linux is supposed to be a multiuser system, isn't it) with different backgrounds, level of technical understanding, expectations, etc. Wait, wait, wait. You mean there was no multiuser systems based on GNU/Linux before systemd invention? Or said multiuser systems were unusable? No, that was just for the I'm sole user of this system, why would I need this logind stuff? crowd. It feels to me like systemd (the project) is rather *trying* to reduce complexity, by providing: - a clear and simple way (unit files) to declare what a service needs and how it should be run and a clear and simple method for the daemon to notify when it is ready to provide its service if its
Re: implicit linkage (was: Re: Effectively criticizing decisions you disagree with in Debian)
On Sb, 11 oct 14, 13:40:08, Steve Litt wrote: sysvinit is an idea whose time has gone. sysvinit is a poor way to showcase the Unix Way. First of all, the whole idea of runlevels is bizarre, and adds a lot of complexity to init scripts. If you compare a daemontools /service/myserviced/run to an init script, you'll see an order of magnetude simplification, without sacrificing the flexibility of a shellscript. Why should I write a script? I'm not a programmer. [snip] I *might* characterize the preceding as trying to reduce complexity for the dufus who can't even write a shellscript. However, the cost of this reduced complexity for the dufus is huge complexity within the program: complexity even smart people can't work around without some truly ridiculous kludges. I can write a (simple) shellscript, but I wouldn't dare write an initscript or even a daemontools runscript. I have a theory on that. runit, s6, init-ng, etc never caught on because sysvinit was considered good enough, and it was easier for the average person to work around its rough edges rather than learn a new init system. I recently needed something to run imapfilter and restart it in case it might exit, so I had a look at daemontools. I gave up quickly after I realised the amount of scaffolding required just to get daemontools itself running (additional top-level directories, are you kidding?). With systemd (v215) I had to write this unit file: ,[ .config/systemd/user/imapfilter.service ] | [Unit] | Description=Unit to run imapfilter | | [Service] | Type=simple | ExecStart=/usr/bin/imapfilter | Restart=always | | [Install] | WantedBy=default.target ` $ systemctl --user start imapfilter # to start it right away $ systemctl --user enable imapfilter # to have it start automatically on login (optional) # systemctl enable-linger my user # to enable my 'systemd --user' instance to run even if I'm not logged in. Kind regards, Andrei -- http://wiki.debian.org/FAQsFromDebianUser Offtopic discussions among Debian users and developers: http://lists.alioth.debian.org/mailman/listinfo/d-community-offtopic http://nuvreauspam.ro/gpg-transition.txt signature.asc Description: Digital signature
Re: implicit linkage (was: Re: Effectively criticizing decisions you disagree with in Debian)
Hi. On Sat, 11 Oct 2014 20:47:36 +0300 Andrei POPESCU andreimpope...@gmail.com wrote: On Sb, 11 oct 14, 19:57:42, Reco wrote: On Sat, 11 Oct 2014 15:18:58 +0300 Andrei POPESCU andreimpope...@gmail.com wrote: On Vi, 10 oct 14, 08:36:23, Joel Rees wrote: Some complexities you can encapsulate or hide, or expose in an organized manner so that that are easier to deal with. Others, no. [big snip] The complexity argument can be used both ways: Indeed. In fact: - the Unix way (do one thing and do it well) leads to many small tools that can be combined in different ways, where each tool has its own quirks, bugs, release schedules, etc. that only increase complexity On the other hand, full blown systemd comes with 69 binaries on board, and such number of binaries reduce complexity somehow :) coreutils alone has 107 binaries. Yup. Please calculate how many of them are actually used in /etc/init.d. You'll lower your number by the point of magnutude. Besides, coreutils is an essential package in Debian, systemd is not. - sysvinit (/bin/init) is indeed quite simple, but in practice it's own mechanisms (/etc/inittab) are only used to start sysv-rc (/etc/init.d/rc) You're wrong. At least gettys are started via /etc/inittab, and Ctrl-Alt-Del handling goes there too. Oh yes, forgot about that. But my point still stands: why is (almost) nobody using /etc/inittab to manage their services? Because one does not start services only, one sometimes needs to stop them. That's something that dbus people didn't learn in all these years, it seems. , which starts all other initscripts, poorly written (/etc/init.d/skeleton itself is known to have bugs) Every software more complex than 'Hello World' has bugs. Heck, *systemd* has bugs. Yes, but with initscripts you can get slightly different version of the same bug (e.g. depending on which version of 'skeleton' they are based on, the script-fu of the respective maintainer, the phase of the moon, etc), but much more difficult to fix, because you have to inspect each package. And with systemd you can have the same based on the same criteria. I mean, do you really expect a sane behavior from the project with a code quality like this - [1]? At least with systemd if you fix a bug it will benefit all daemons using it. No, quite the contrary. By fixing such jack-of-all-trades libsystemd library you're risking to *break* some other daemons. But, pretending your point is valid, fixing /etc/init.d/skeleton grants the same benefits. This is the same reason we are using shared libraries and the Debian Security Team is doing it's best to track code copies. Consider /etc/init.d/skeleton a library then. It's sources to any /etc/init.d script anyway. The recent method of using a common script goes in the right direction though. in a (poor) programming language (shell script) As latest development of OpenSSL show us, C isn't that great programming language either, and more complex than shell. Sure, but at least a lot of eyeballs are looking at it. How many eyes do you think look at the average initscript? As recent 'shellshock' vulnerability shows, many eyeballs are good, but hardly enough (hint - shellshock was introduced in 1989). And it also shows, that there're curious minds that are finding bugs everywhere, including shell scripts. Especially now, after shellshock 'fired'. The scrips are not even enough, they have to rely on additional tools like start-stop-daemon(8) with their own quirks and bugs. That's the intended usage of shell scripts - to be a glue between utilities. Does it surprise you? Nope, it just proves my point that sysv-rc is *very* complex. Hardly. It proves that starting daemons is complex. Sysv-rc is simple by itself, and that's about the only good thing that can be said about sysv-rc IMO. - each service/daemon is implemented in its own unique way, with different methods of running (quite often multiple ways, depending on start-up switches, like foreground, forking, etc.), reloading, logging, etc. Given that said 'services' are written by different people - that's nothing unusual. In fact, ever-growing DSL of systemd's units clearly shows that 'one size fits all' approach constantly fail to account for various corner cases. Such as? Please see an arbitrary systemd's changelog. Observe phrases such as we've added phrase FooBar to the unit files. Such phrases are the sign of DSL change, and it only happen for two reasons: a) Sudden irresistible urge (or voices in someone's head) to add a phrase. b) There's some daemon that genuinely need it. I prefer explanation b), what about you? - computers have gotten quite complex themselves with removable devices, complex network connectivity, etc. 'Removable devices' could
Re: implicit linkage (was: Re: Effectively criticizing decisions you disagree with in Debian)
On Sb, 11 oct 14, 23:20:34, Reco wrote: On Sat, 11 Oct 2014 20:47:36 +0300 Andrei POPESCU andreimpope...@gmail.com wrote: At least with systemd if you fix a bug it will benefit all daemons using it. No, quite the contrary. By fixing such jack-of-all-trades libsystemd library you're risking to *break* some other daemons. But, pretending your point is valid, fixing /etc/init.d/skeleton grants the same benefits. Nope. This is the same reason we are using shared libraries and the Debian Security Team is doing it's best to track code copies. Consider /etc/init.d/skeleton a library then. It's sources to any /etc/init.d script anyway. No, it doesn't. True, but sysv-rc still can't deal with them correctly. It does not have to deal with the hardware, as it not its' job. It has to mount filesystems. Ok. You have wired, that's one stanza in /etc/network/interfaces. Or one obscure systemd's unit, if you prefer *that*. You have wireless, and while it's possible to use /etc/network/interfaces for that too (I do, for example), Joe the Average User would probably use NetworkDestroyer (sorry, Manager), or wicd. Anyway, wireless requires usage of wpa_supplicant, which is not a part of systemd. Presumably one can use a systemd's unit for that too, but I've never tried it. A dongle for a mobile is probably a good old g_ether network interface aka usb0. It's complicated somewhat as one may need to use usb-modeswitch (not a part of systemd, btw), but it's nothing more complex than yet another stanza in /etc/network/interfaces. As for the IPv6 - unless you're turning your own PC into a router, configuring IPv6 is something that kernel does for you already without any intervention from the userspace (it's called a Router Advertisment). My point was that userspace has to react to changes in networking. The following might also provide for an interested read: http://www.freedesktop.org/wiki/Software/systemd/NetworkTarget/ You don't have to, in this specific case. NFS should be mounted long before any daemon starts, mpd included. Things can break, as your example show. A better example would be 'how I can ensure that mpd will stop if I unmount a NFS share?'. Still, I agree that's a valid point, *if* you disregard an existence of automount(5). Because, mounting NFS from an fstab is *so* AIX. Why should I need to install yet another daemon, with yet another configuration file/syntax? [3] tells us systemd 30 and newer include systemd-logind. This is a tiny daemon that manages user logins and seats in various ways. I had an impression that an ssh login is an actual login. And, since you can easily start an X session over ssh - there's need to consider it a ssh login a seat too. Are you talking about X forwarding? Isn't the X session on the ssh client side (a.k.a. the X server side)? As for the x11vnc - I doubt that it could be fixed. x11vnc attaches to an existing X server, and is translating said server I/O over VNC to anyone. It does not spawn its' own session, so there's nothing that can be tracked. According to the package description it has UNIX account and password support. If that is done via pam (how else?) it should be possible for it to use libpam-logind. Kind regards, Andrei -- http://wiki.debian.org/FAQsFromDebianUser Offtopic discussions among Debian users and developers: http://lists.alioth.debian.org/mailman/listinfo/d-community-offtopic http://nuvreauspam.ro/gpg-transition.txt signature.asc Description: Digital signature
Re: implicit linkage (was: Re: Effectively criticizing decisions you disagree with in Debian)
On Sat, 11 Oct 2014 21:21:14 +0300 Andrei POPESCU andreimpope...@gmail.com wrote: On Sb, 11 oct 14, 13:40:08, Steve Litt wrote: sysvinit is an idea whose time has gone. sysvinit is a poor way to showcase the Unix Way. First of all, the whole idea of runlevels is bizarre, and adds a lot of complexity to init scripts. If you compare a daemontools /service/myserviced/run to an init script, you'll see an order of magnetude simplification, without sacrificing the flexibility of a shellscript. Why should I write a script? I'm not a programmer. Why should I configure and maintain a firewall? I'm not an admin. One's being a programmer is such an arbitrary division. OK, you're not the first guy I'd call if I wanted a device driver coded, but I'd have complete confidence in you to write a short shellscript. And, being able to write a short shellscript (which I'm sure you can do), would make you a much more able Linux administrator and user. [snip] I *might* characterize the preceding as trying to reduce complexity for the dufus who can't even write a shellscript. However, the cost of this reduced complexity for the dufus is huge complexity within the program: complexity even smart people can't work around without some truly ridiculous kludges. I can write a (simple) shellscript, but I wouldn't dare write an initscript or even a daemontools runscript. Daemontools runscripts are incredibly simple shellscripts, that I'm sure you could write no sweat except in very wierd edge cases. Here's my run script for my home-grown cron substitute: == #!/bin/sh ### DON'T START littcrond UNTIL THE NETWORK'S UP ### pingaddr=8.8.8.8 pingaddr=192.168.100.96 echo littcrond checking network 12 while ! ping -q -c1 $pingaddr /dev/null; do sleep 1 echo littcrond REchecking network 12 done ### RUN THE DAEMON ### exec envuidgid slitt envdir ./env setuidgid slitt \ /d/at/python/littcron/littcron.py \ /d/at/python/littcron/crontab == The last three lines are really one line that wordwraps in email. If I hadn't checked for the network being up, this would have been a two line shellscript. I've known you (online) for several months, and although we sometimes disagree, I know you're pretty smart, so I'm positive you could have written this shellscript without breaking a sweat. I have a theory on that. runit, s6, init-ng, etc never caught on because sysvinit was considered good enough, and it was easier for the average person to work around its rough edges rather than learn a new init system. I recently needed something to run imapfilter and restart it in case it might exit, so I had a look at daemontools. I gave up quickly after I realised the amount of scaffolding required just to get daemontools itself running (additional top-level directories, are you kidding?). With systemd (v215) I had to write this unit file: [clip Andre's easy description of daemonizing imapfilter with systemd] Yes, there's significant scaffolding, mostly revolving around installing daemontools. Also, Andre didn't bring this up, but it's implicit in his objection: Most daemontools documentation is terse and assumes a whole lot of Unix-smarts on the part of the reader, with few examples. That's why I wrote this document: http://www.troubleshooters.com/linux/djbdns/daemontools_intro.htm Armed with the preceding document, a person can learn daemontools in a day, and use it for the rest of his life. If you can run imapfilter in the foreground, it's trivial to have daemontools daemonize it for you. And you'll know *exactly* how it's going to work. The other benefit of daemontools is it works, every single time. It never misfires, it never behaves in ways that are unspecified or against specification, it keeps working for years, and a simple (as root) backup walks it from distro to distro. SteveT Steve Litt* http://www.troubleshooters.com/ Troubleshooting Training * Human Performance -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141011172828.4a603...@mydesq2.domain.cxm
Re: implicit linkage (was: Re: Effectively criticizing decisions you disagree with in Debian)
On Sat, 11 Oct 2014 23:20:34 +0400 Reco recovery...@gmail.com wrote: Hi. On Sat, 11 Oct 2014 20:47:36 +0300 Andrei POPESCU andreimpope...@gmail.com wrote: [huge snip] No, that was just for the I'm sole user of this system, why would I need this logind stuff? crowd. Thanks, I'm perfectly aware why I don't need logind - it does not solve any of the problems I need to solve. Same for it's predecessor, ConsoleKit. If I ever need a computer with the multiple X servers running simultaneously - I'll consider using logind. Am I missing something. If I needed multiple X servers, wouldn't I just CLI log into different users on Ctrl+Alt+F2 and Ctrl+Alt+F3, and run startx from each? SteveT Steve Litt* http://www.troubleshooters.com/ Troubleshooting Training * Human Performance -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141011173500.03936...@mydesq2.domain.cxm
Re: implicit linkage (was: Re: Effectively criticizing decisions you disagree with in Debian)
Hi. On Sat, 11 Oct 2014 23:02:01 +0300 Andrei POPESCU andreimpope...@gmail.com wrote: On Sb, 11 oct 14, 23:20:34, Reco wrote: On Sat, 11 Oct 2014 20:47:36 +0300 Andrei POPESCU andreimpope...@gmail.com wrote: At least with systemd if you fix a bug it will benefit all daemons using it. No, quite the contrary. By fixing such jack-of-all-trades libsystemd library you're risking to *break* some other daemons. But, pretending your point is valid, fixing /etc/init.d/skeleton grants the same benefits. Nope. The reason being? Code quality of systemd is not top-grade (to say lightly), and the project hardly reached its' maturity. It'll only get worse from here. And, I have to ask. Are you denying both of my statements, or the last one only? This is the same reason we are using shared libraries and the Debian Security Team is doing it's best to track code copies. Consider /etc/init.d/skeleton a library then. It's sources to any /etc/init.d script anyway. No, it doesn't. Again, simple 'no' is beautiful, but hardly contributes to the discussion. True, but sysv-rc still can't deal with them correctly. It does not have to deal with the hardware, as it not its' job. It has to mount filesystems. No, it does not have to. In Debian, there's /etc/init.d/mountall.sh to do this job, in case initrd didn't care for it already. init(8) does not mount anything. And, to spice things up, [1]. Beautiful link telling everyone that it's not the init job to mount /usr as there's initrd for that. Ok. You have wired, that's one stanza in /etc/network/interfaces. Or one obscure systemd's unit, if you prefer *that*. You have wireless, and while it's possible to use /etc/network/interfaces for that too (I do, for example), Joe the Average User would probably use NetworkDestroyer (sorry, Manager), or wicd. Anyway, wireless requires usage of wpa_supplicant, which is not a part of systemd. Presumably one can use a systemd's unit for that too, but I've never tried it. A dongle for a mobile is probably a good old g_ether network interface aka usb0. It's complicated somewhat as one may need to use usb-modeswitch (not a part of systemd, btw), but it's nothing more complex than yet another stanza in /etc/network/interfaces. As for the IPv6 - unless you're turning your own PC into a router, configuring IPv6 is something that kernel does for you already without any intervention from the userspace (it's called a Router Advertisment). My point was that userspace has to react to changes in networking. The following might also provide for an interested read: http://www.freedesktop.org/wiki/Software/systemd/NetworkTarget/ Oh, you've meant *that* by complex. Ok, I misunderstood you. Along all presumably good things that page tells, there's these gems: This will ensure that all configured network devices are up and have an IP address assigned before boot continues. This service will time out after 90s. Enabling this service might considerably delay your boot even if the timeout is not reached. Both services are disabled by default. … If you are a developer, instead of wondering what to do about network.target, please just fix your program to be friendly to dynamically changing network configuration. That way you will make your users happy because things just start to work, and you will get fewer bug reports as your stuff is just rock solid. Please enlighten me what exactly is systemd-specific here. Basically they tell yadda-yadda-yadda, fix your applications, and if you don't - we have this 90-second hack for you. You don't have to, in this specific case. NFS should be mounted long before any daemon starts, mpd included. Things can break, as your example show. A better example would be 'how I can ensure that mpd will stop if I unmount a NFS share?'. Still, I agree that's a valid point, *if* you disregard an existence of automount(5). Because, mounting NFS from an fstab is *so* AIX. Why should I need to install yet another daemon, with yet another configuration file/syntax? Brilliant question. Certainly you've meant systemd, right? Just joking. Joke aside - because it's convenient to mount a filesystem once you really need it, and (which is much more important) - unmount it once it's not needed anymore. [3] tells us systemd 30 and newer include systemd-logind. This is a tiny daemon that manages user logins and seats in various ways. I had an impression that an ssh login is an actual login. And, since you can easily start an X session over ssh - there's need to consider it a ssh login a seat too. Are you talking about X forwarding? Isn't the X session on the ssh client side (a.k.a. the X server side)? X server on host A. ssh connection from host A to host B. X clients wrapped in X session on host B. Saves the trouble of using XDMCP. Call it the way you like it. As for the x11vnc - I doubt that it could be
Re: implicit linkage (was: Re: Effectively criticizing decisions you disagree with in Debian)
Hi. On Sat, 11 Oct 2014 17:35:00 -0400 Steve Litt sl...@troubleshooters.com wrote: On Sat, 11 Oct 2014 23:20:34 +0400 Reco recovery...@gmail.com wrote: Hi. On Sat, 11 Oct 2014 20:47:36 +0300 Andrei POPESCU andreimpope...@gmail.com wrote: [huge snip] No, that was just for the I'm sole user of this system, why would I need this logind stuff? crowd. Thanks, I'm perfectly aware why I don't need logind - it does not solve any of the problems I need to solve. Same for it's predecessor, ConsoleKit. If I ever need a computer with the multiple X servers running simultaneously - I'll consider using logind. Am I missing something. If I needed multiple X servers, wouldn't I just CLI log into different users on Ctrl+Alt+F2 and Ctrl+Alt+F3, and run startx from each? That's one way of doing it, sure. An old way, and a convenient one, but it's somewhat cruel to expect from the average user these days. An alternative would be some kind of a Display Manager (even venerable xdm will suffice). But that's not the point. The point is the following scenario: 1) A single shared PC with 2 users just to keep it simple. 2) User Alice logs in and starts browsing the Internet and listening some music. 3) User Alice goes away, but keeps her session in place, locking the screen. 4) User Bob logs in another X session. 5) User Bob does not share Alices' music tastes, yet he's unable to shut off Alices' music as he's the different user. So, unless Bob has root password - he's doomed (pun intended) to listen the music he does not like. Presumably that scenario is something that logind has to overcome. Reco -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141012014940.0e2fe89eba55854a664d1...@gmail.com
Re: implicit linkage (was: Re: Effectively criticizing decisions you disagree with in Debian)
2014/10/09 10:58 lee l...@yagibdah.de: Joel Rees joel.r...@gmail.com writes: 2014/09/25 9:15 lee l...@yun.yagibdah.de: Joel Rees joel.r...@gmail.com writes: Hmm. So linkage is a result of complexity, What is complexity? Complexity is not a simple topic. :-\ Indeed. And one of the problems with computers is that people want to believe that computers can make complexities go away. Some complexities you can encapsulate or hide, or expose in an organized manner so that that are easier to deal with. Others, no. and implicity is a result of undeclaredness (or unawareness of declaredness). Sort of, but not quite. I would rather say, Implicitness is the lack of explicit declaration at the point where the linkage is expressed (or occurs). but I'm not sure that would be universally well understood, either. So implicitness isn't a result of something but a lack of explicitness. Generally, the things which are implicit are the things which are not said, but assumed to be understood: unspoken assumptions. Logical implication is a different thing, the process of deriving something from assumptions which have to be explicit. The base word imply can cause yet another kind of confusion. Too much explicitness isn't good, either, because it'll get into your way. Yeah, if you take the time to explicitly specify every parameter, you're going to have a hard time getting started coding. And specifying too many parameters can really slow an implementation down. You could as well argue that linkage is basically a bad thing and therefore should only be accepted for instances where it has significant advantages which outweigh the disadvantages. At least we have a tautology here. Oh! The problem of evil rears its head in mathematics. ;-/ (sorry.) But the hidden assumption that linkages can be completely done away with is where the logic goes wrong. Remove all externally accessible parameters and you can't even write the algorithm, much less implement it. Generally, reducing complexity and reducing linkage are related, but not necessarily. The degree to which linkage is implicit, or to which entanglement is hidden, is not necessarily dependent on the degree of either complexity or linkage. These can be independent variables, depending on the case in question. In some cases, you can even make them indpendent variables, when they didn't start out that way in your analysis. Hm, true ... Less linkage is easier to hide than more linkage. It makes me think of a simple perl script. Such a script probably has an unbelievable amount of implicit linkage. For example: perl -e 'print scalar localtime, \n;' Well, that indeed illustrates a lot about complexity, and about hiding it, along with the hidden parameters that can turn into implicit linkage. (I'd like to say more about perl, but I don't have time.) Since you cannot make things less complex, I'm not sure what you're trying to say. If you know you can make things more complex, you know that there must be things that can be made less complex. The less complicated things tend to be deprecated and to become obsolete. Well, the sales crew definitely wants you to believe it. 25 years ago, computers didn't have sound cards. You could possibly add one, making your computer more complicated both in terms of total complexity of hardware and software. Nowadays, a replacement for a sound card is built in. Making things less complicated would mean to omit or to remove the sound cards and their replacements. Who wants to do that? On the one hand, sometimes you do remove most of the sound software, leaving just enough of the drivers to keep the sound card in a safely powered-down state. On the other hand, with sound-on-the-motherboard, many old sound card modes are unsupported. The overall number of externally accessible parameters, and the complexity of interaction of what remains is decidedly less that what all but the cheapest sound cards used to supply. Also, with all the stuff that is on the motherboard, you can often get rid of much of the circuitry that would otherwise drive the external busses, and simplify much of the driver software. You really can't say that progress is linear in the direction of increasing complexity. There are several kinds of complexity. One is purely subjective -- perceived complexity: It's different, so it's complicated. or I don't understand it, so it's complicated. We can talk about the parsing of a problem by the human brain, but it wouldn't help yet. We should set perceptions of complexity aside here. If you have a device with 100 inputs and 100 outputs, that's going to look complicated, right? But if all the inputs just feed directly to the outputs, it's not really all that complicated after all. This is one kind of complexity. Analysis is straightforward. If some of the inputs are inverted or amplified, that's a
Re: implicit linkage (was: Re: Effectively criticizing decisions you disagree with in Debian)
On Fri, 10 Oct 2014 08:36:23 +0900 Joel Rees joel.r...@gmail.com wrote: Indeed. And one of the problems with computers is that people want to believe that computers can make complexities go away. Some complexities you can encapsulate or hide, or expose in an organized manner so that that are easier to deal with. Others, no. And many times, the complexities you create trying to hide other complexities are worse than the originals. Every single car I've owned that had 60K miles *and* had electronic doors and windows had at least one malfunctioning lock or window. I think another example is Windows. In the name of User Friendly or Intuitive, they've made computer use a guessing game. I can't switch to an OpenBSD desktop because OpenBSD's virtual machines are badly broken, but in every other respect, if you want to see something that's predictable in its minimalism, look at OpenBSD. Every bit of configuration is easily done from an editor, and there's little complexity beyond the complexity of the original problem domain. SteveT Steve Litt* http://www.troubleshooters.com/ Troubleshooting Training * Human Performance -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141009195315.703d7...@mydesq2.domain.cxm
