Joel Rees writes:
> If pid 1 gets stalled, lots of things all over the system get to wait
> for something important that can't happen until pid 1 gets un-stalled,
> and that's true even with quad core. It may not freeze every process,
> but it can cause dropped packets and such things. Potentially
On Tue, 14 Oct 2014 07:37:17 +0900
Joel Rees wrote:
> The only way to fix that in systemd is for systemd to delegate the
> complicated stuff like managing dbus to child processes, so the
> processes that will occasionally stall won't impact the whole system
> as much.
>
> When/if that happens, w
On Mon, Oct 13, 2014 at 10:47 PM, Miles Fidelman
wrote:
> Chris Bannister wrote:
>>
>> On Mon, Oct 13, 2014 at 07:14:29PM +0900, Joel Rees wrote:
>>>
>>> On Mon, Oct 13, 2014 at 4:18 PM, Jonathan Dowland
>>> wrote:
On Sun, Oct 12, 2014 at 02:48:55PM -0400, Steve Litt wrote:
>
>
On Mon, 13 Oct 2014 08:18:57 +0100
Jonathan Dowland wrote:
> On Sun, Oct 12, 2014 at 02:48:55PM -0400, Steve Litt wrote:
> > On Sun, 12 Oct 2014 19:02:08 +0100 Martin Read
> > wrote:
> > > On 12/10/14 18:13, John Hasler wrote:
> > > > You have no problem with an 1800 line function?
> ...
> > > I
On Mon, Oct 13, 2014 at 10:44 PM, Chris Bannister
wrote:
> On Mon, Oct 13, 2014 at 07:14:29PM +0900, Joel Rees wrote:
>> On Mon, Oct 13, 2014 at 4:18 PM, Jonathan Dowland wrote:
>> > On Sun, Oct 12, 2014 at 02:48:55PM -0400, Steve Litt wrote:
>> >> On Sun, 12 Oct 2014 19:02:08 +0100 Martin Read
On Mon, Oct 13, 2014 at 10:53 PM, Chris Bannister
wrote:
> On Mon, Oct 13, 2014 at 02:10:11PM +0900, Joel Rees wrote:
>> >>
>> >> Which is another way of saying that you want others to have already made
>> >> the mistakes for you.
>> >
>> > No it isn't! Ponder why most people take their car to a
On Mon, Oct 13, 2014 at 02:10:11PM +0900, Joel Rees wrote:
> >>
> >> Which is another way of saying that you want others to have already made
> >> the mistakes for you.
> >
> > No it isn't! Ponder why most people take their car to a mechanic for
> > servicing.
>
> And you snipped:
>
> >> As long
Chris Bannister wrote:
On Mon, Oct 13, 2014 at 07:14:29PM +0900, Joel Rees wrote:
On Mon, Oct 13, 2014 at 4:18 PM, Jonathan Dowland wrote:
On Sun, Oct 12, 2014 at 02:48:55PM -0400, Steve Litt wrote:
On Sun, 12 Oct 2014 19:02:08 +0100 Martin Read wrote:
On 12/10/14 18:13, John Hasler wrote:
On Mon, Oct 13, 2014 at 07:14:29PM +0900, Joel Rees wrote:
> On Mon, Oct 13, 2014 at 4:18 PM, Jonathan Dowland wrote:
> > On Sun, Oct 12, 2014 at 02:48:55PM -0400, Steve Litt wrote:
> >> On Sun, 12 Oct 2014 19:02:08 +0100 Martin Read wrote:
> >> > On 12/10/14 18:13, John Hasler wrote:
> >> > > Yo
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
On Mon, Oct 13, 2014 at 7:34 PM, Ansgar Burchardt wrote:
> Hi,
>
> On 10/13/2014 12:14, Joel Rees wrote:
>> Get pid 1 down to 100 lines of C, no loops, no functions called, then
>> I'll be impressed.
> [...]
>> Setting aside initialization code, pid 1 should target less than 1000
>> lines of C in
Hi,
On 10/13/2014 12:14, Joel Rees wrote:
> Get pid 1 down to 100 lines of C, no loops, no functions called, then
> I'll be impressed.
[...]
> Setting aside initialization code, pid 1 should target less than 1000
> lines of C in the main loop. (If we were to use dash or other
> streamlined shells,
On Mon, Oct 13, 2014 at 4:18 PM, Jonathan Dowland wrote:
> On Sun, Oct 12, 2014 at 02:48:55PM -0400, Steve Litt wrote:
>> On Sun, 12 Oct 2014 19:02:08 +0100 Martin Read wrote:
>> > On 12/10/14 18:13, John Hasler wrote:
>> > > You have no problem with an 1800 line function?
> ...
>> > I have a pro
On Sun, Oct 12, 2014 at 02:48:55PM -0400, Steve Litt wrote:
> On Sun, 12 Oct 2014 19:02:08 +0100 Martin Read wrote:
> > On 12/10/14 18:13, John Hasler wrote:
> > > You have no problem with an 1800 line function?
...
> > I have a problem with 1800 line functions in general;
...
> I have no problem
Hi.
On Sun, 12 Oct 2014 02:53:37 +0200
lee wrote:
> Reco writes:
>
> > 3) User Alice goes away, but keeps her session in place, locking the
> > screen.
> >
> > 4) User Bob logs in another X session.
>
> How does Bob log in while the screen is locked?
Either by selecting 'Switch session' in
On Mon, Oct 13, 2014 at 1:38 PM, Chris Bannister
wrote:
> On Mon, Oct 13, 2014 at 07:53:03AM +0900, Joel Rees wrote:
>> 2014/10/13 2:14 "Andrei POPESCU" :
>> >
>> > On Du, 12 oct 14, 10:30:52, The Wanderer wrote:
>> > > On 10/12/2014 at 10:07 AM, Andrei POPESCU wrote:
>> > >
>> > > > Any program t
On Mon, Oct 13, 2014 at 07:53:03AM +0900, Joel Rees wrote:
> 2014/10/13 2:14 "Andrei POPESCU" :
> >
> > On Du, 12 oct 14, 10:30:52, The Wanderer wrote:
> > > On 10/12/2014 at 10:07 AM, Andrei POPESCU wrote:
> > >
> > > > Any program that requires additional scripting just to get it running
> > > >
On Mon, Oct 13, 2014 at 1:39 AM, Martin Read wrote:
> On 12/10/14 01:43, lee wrote:
>>
>> Reco writes:
>>
>>>
>>> http://cgit.freedesktop.org/systemd/systemd/tree/src/core/dbus-manager.c?id=3731acf1acfb4a6eb68374a5b137f3b368f63381#n638
>>
>>
>> Ah, this is a wonderful example :) My assumptions a
2014/10/13 2:45 "Steve Litt" :
>
> On Sun, 12 Oct 2014 09:33:43 +0100
> Martin Read wrote:
>
> > On 12/10/14 04:12, Peter Zoeller wrote:
> > > But the nice
> > > thing is shell scripting is simplistic easy to learn and understand.
> >
> > I refer the audience to David A. Wheeler's essay[1] on how
2014/10/13 2:14 "Andrei POPESCU" :
>
> On Du, 12 oct 14, 10:30:52, The Wanderer wrote:
> > On 10/12/2014 at 10:07 AM, Andrei POPESCU wrote:
> >
> > > Any program that requires additional scripting just to get it running
> > > is insufficiently advanced.
> > >
> > > (you can quote me on that)
> >
>
2014/10/12 23:07 "Andrei POPESCU" :
>
> On Sb, 11 oct 14, 21:40:49, Steve Litt wrote:
> >
> > From my viewpoint, shellscripts were never intended to be big, huge
> > programs. To me, they just glue together commands, and have a few
> > rudimentary branching and looping constructs.
>
> Isn't that li
On Du, 12 oct 14, 14:24:32, Steve Litt wrote:
>
> Because it can run in the foreground, it's a prime candidate for
> daemontools (or one of the daemontools-inspired programs like nosh,
> etc).
$ apt-cache show nosh
E: No packages found
> So if you don't like brand new top level directories, igno
On 10/11/2014 12:49 PM, Andrei POPESCU wrote:
On Sb, 11 oct 14, 12:19:29, Marty wrote:
>Could it be that a modular design for such complex tasks becomes too
>difficult to *do it right*?
I don't know, but I think given its history, the burden of proof is on
monolithic, not modular design. A bet
On 10/11/2014 12:49 PM, Andrei POPESCU wrote:
On Sb, 11 oct 14, 12:19:29, Marty wrote:
>Could it be that a modular design for such complex tasks becomes too
>difficult to *do it right*?
I don't know, but I think given its history, the burden of proof is on
monolithic, not modular design. A bet
On Sun, 12 Oct 2014 11:16:54 -0700
Don Armstrong wrote:
> On Sun, 12 Oct 2014, Steve Litt wrote:
> > This essay practically screams out for somebody to write a C program
> > that takes an argument of an arbitrary string, finds all files in a
> > directory, and returns a long string with those fil
On Sun, 12 Oct 2014 19:02:08 +0100
Martin Read wrote:
> On 12/10/14 18:13, John Hasler wrote:
> > Martin Read writes:
> >> I'm not seeing a serious problem with that function.
> >
> > You have no problem with an 1800 line function?
>
> The thing that you are asking me if it is the case is not th
Don Armstrong writes:
> On Sun, 12 Oct 2014, Steve Litt wrote:
>> This essay practically screams out for somebody to write a C program
>> that takes an argument of an arbitrary string, finds all files in a
>> directory, and returns a long string with those files separated by the
>> arbitrary strin
On Sun, 12 Oct 2014 17:07:01 +0300
Andrei POPESCU wrote:
> On Sb, 11 oct 14, 21:40:49, Steve Litt wrote:
> >
> > From my viewpoint, shellscripts were never intended to be big, huge
> > programs. To me, they just glue together commands, and have a few
> > rudimentary branching and looping constru
On Sun, 12 Oct 2014 15:33:48 +0300
Andrei POPESCU wrote:
> On Sb, 11 oct 14, 17:41:28, Steve Litt wrote:
> > On Sat, 11 Oct 2014 22:28:31 +0300
> > Andrei POPESCU wrote:
> >
> >
> > > Really? How do you write an initscript that restarts your daemon
> > > automatically in case it fails for som
Andrei POPESCU wrote:
On Sb, 11 oct 14, 21:40:49, Steve Litt wrote:
From my viewpoint, shellscripts were never intended to be big, huge
programs. To me, they just glue together commands, and have a few
rudimentary branching and looping constructs.
Isn't that like buying IKEA furniture, but whe
On Sun, 12 Oct 2014, Steve Litt wrote:
> This essay practically screams out for somebody to write a C program
> that takes an argument of an arbitrary string, finds all files in a
> directory, and returns a long string with those files separated by the
> arbitrary string.
You seem to be looking fo
On Sun, 12 Oct 2014 19:06:11 +0900
Joel Rees 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
> wrote:
> > ### RUN THE DAEMON ###
> > exec envuidgid slitt envdir ./env setuidgid slitt \
> > /d/at/python/littcron/l
On 12/10/14 18:13, John Hasler wrote:
Martin Read writes:
I'm not seeing a serious problem with that function.
You have no problem with an 1800 line function?
The thing that you are asking me if it is the case is not the thing I said.
I have a problem with 1800 line functions in general; th
On 10/12/2014 at 01:42 PM, Steve Litt wrote:
> On Sun, 12 Oct 2014 09:33:43 +0100 Martin Read
> wrote:
>
>> On 12/10/14 04:12, Peter Zoeller wrote:
>>
>>> But the nice thing is shell scripting is simplistic easy to learn
>>> and understand.
>>
>> I refer the audience to David A. Wheeler's essa
On Sun, 12 Oct 2014 09:33:43 +0100
Martin Read wrote:
> On 12/10/14 04:12, Peter Zoeller wrote:
> > But the nice
> > thing is shell scripting is simplistic easy to learn and understand.
>
> I refer the audience to David A. Wheeler's essay[1] on how to handle
> filenames correctly in shell scrip
Martin Read writes:
> I'm not seeing a serious problem with that function.
You have no problem with an 1800 line function?
--
John Hasler
jhas...@newsguy.com
Elmwood, WI USA
--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact li
On Du, 12 oct 14, 10:30:52, The Wanderer wrote:
> On 10/12/2014 at 10:07 AM, Andrei POPESCU wrote:
>
> > Any program that requires additional scripting just to get it running
> > is insufficiently advanced.
> >
> > (you can quote me on that)
>
> Part of the tradeoff for power is responsibility -
On Sun, 12 Oct 2014 03:05:59 +0200
lee wrote:
> Steve Litt writes:
>
> > pingaddr=8.8.8.8
> > pingaddr=192.168.100.96
>
> Why is this is defined multiple times?
Mistake!
The 8.8.8.8 isn't needed. That's a test of Internet connectivity, when
what I wanted was to test LAN connectivity, which
On 12/10/14 01:43, lee wrote:
Reco writes:
http://cgit.freedesktop.org/systemd/systemd/tree/src/core/dbus-manager.c?id=3731acf1acfb4a6eb68374a5b137f3b368f63381#n638
Ah, this is a wonderful example :) My assumptions about the code were right.
Does all/most of systemd look like that?
I'm n
Steve Litt writes:
> pingaddr=8.8.8.8
> pingaddr=192.168.100.96
Why is this is defined multiple times?
--
Hallowed are the Debians!
--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https
Reco writes:
> 3) User Alice goes away, but keeps her session in place, locking the
> screen.
>
> 4) User Bob logs in another X session.
How does Bob log in while the screen is locked?
--
Hallowed are the Debians!
--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
with a sub
Reco writes:
> http://cgit.freedesktop.org/systemd/systemd/tree/src/core/dbus-manager.c?id=3731acf1acfb4a6eb68374a5b137f3b368f63381#n638
Ah, this is a wonderful example :) My assumptions about the code were right.
Does all/most of systemd look like that?
--
Hallowed are the Debians!
--
T
On 10/12/2014 at 10:07 AM, Andrei POPESCU wrote:
> On Sb, 11 oct 14, 21:40:49, Steve Litt wrote:
>
>> From my viewpoint, shellscripts were never intended to be big,
>> huge programs. To me, they just glue together commands, and have a
>> few rudimentary branching and looping constructs.
>
> Isn'
On Sb, 11 oct 14, 21:40:49, Steve Litt wrote:
>
> From my viewpoint, shellscripts were never intended to be big, huge
> programs. To me, they just glue together commands, and have a few
> rudimentary branching and looping constructs.
Isn't that like buying IKEA furniture, but when you get home yo
On Sb, 11 oct 14, 17:41:28, Steve Litt wrote:
> On Sat, 11 Oct 2014 22:28:31 +0300
> Andrei POPESCU wrote:
>
>
> > Really? How do you write an initscript that restarts your daemon
> > automatically in case it fails for some reason?
> >
> > Also, imapfilter doesn't write a pidfile at all, so I'
On Du, 12 oct 14, 01:41:34, Reco wrote:
> Hi.
>
> On Sat, 11 Oct 2014 23:02:01 +0300
> Andrei POPESCU wrote:
>
> > On Sb, 11 oct 14, 23:20:34, Reco wrote:
> > > On Sat, 11 Oct 2014 20:47:36 +0300
> > > Andrei POPESCU wrote:
> > >
> > > > At least with systemd if you fix a bug it will benefit
Steve Litt:
### RUN THE DAEMON ###
exec envuidgid slitt envdir ./env setuidgid slitt \
/d/at/python/littcron/littcron.py \
/d/at/python/littcron/crontab
Joel Rees:
man exec for clues to that, understand that littcron.py is Steve's
special cron (right, Steve?), and that he is setting u
Andrei Popescu:
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 [...]
And here's how one can do it with the nosh package
(http://homepage.ntlworld.com./jonathan.deboynepollard/Softwares/nosh.html).
I took a
Andrei Popescu:
Why should I write a script? I'm not a programmer.
I can write a (simple) shellscript, but I wouldn't dare write an
initscript or even a daemontools runscript.
You have an incorrect mental model of the relative difficulty of the
tasks. A run program for a daemontools-family se
Hmm. Let's comment that for people newer to scripting than I am.
On Sun, Oct 12, 2014 at 6:28 AM, Steve Litt 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-gro
On 12/10/14 04:12, Peter Zoeller wrote:
But the nice
thing is shell scripting is simplistic easy to learn and understand.
I refer the audience to David A. Wheeler's essay[1] on how to handle
filenames correctly in shell scripts, and to the bug report that he
filed against POSIX.1-2008[2] on t
Hi Steve:
I agree that shell scripts are simplistic and not meant for fancy
programs although it could be done, just not productive. But the nice
thing is shell scripting is simplistic easy to learn and understand.
Sure beats the days when I wrote code in Assembler, Cobol, Fortran, PL1,
RPG,
On Sat, Oct 11, 2014 at 09:40:49PM -0400, Steve Litt wrote:
>
> Now that I've said that, you can accomplish some pretty incredible
> things by gluing a few commands together. I wrote the better half of a
> http log evaluation program using a shellscript gluing together grep,
> cut, and awk, and pi
On Sat, 11 Oct 2014 19:05:19 -0400
Doug wrote:
> On 10/11/2014 05:28 PM, Steve Litt wrote:
> > On Sat, 11 Oct 2014 21:21:14 +0300
> > 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 fo
On 10/11/2014 05:28 PM, Steve Litt wrote:
> On Sat, 11 Oct 2014 21:21:14 +0300
> Andrei POPESCU 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
Hi.
On Sat, 11 Oct 2014 17:35:00 -0400
Steve Litt wrote:
> On Sat, 11 Oct 2014 23:20:34 +0400
> Reco wrote:
>
> > Hi.
> >
> > On Sat, 11 Oct 2014 20:47:36 +0300
> > Andrei POPESCU wrote:
>
> [huge snip]
>
> > > No, that was just for the "I'm sole user of this system, why would
> > > I n
On Sat, 11 Oct 2014 22:28:31 +0300
Andrei POPESCU wrote:
> Really? How do you write an initscript that restarts your daemon
> automatically in case it fails for some reason?
>
> Also, imapfilter doesn't write a pidfile at all, so I'd need to make
> at least some modifications to the script.
D
Hi.
On Sat, 11 Oct 2014 23:02:01 +0300
Andrei POPESCU wrote:
> On Sb, 11 oct 14, 23:20:34, Reco wrote:
> > On Sat, 11 Oct 2014 20:47:36 +0300
> > Andrei POPESCU wrote:
> >
> > > At least with systemd if you fix a bug it will benefit all daemons using
> > > it.
> >
> > No, quite the contrar
On Sat, 11 Oct 2014 23:20:34 +0400
Reco wrote:
> Hi.
>
> On Sat, 11 Oct 2014 20:47:36 +0300
> Andrei POPESCU 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 logi
On Sat, 11 Oct 2014 21:21:14 +0300
Andrei POPESCU 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
On Sb, 11 oct 14, 23:20:34, Reco wrote:
> On Sat, 11 Oct 2014 20:47:36 +0300
> Andrei POPESCU 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 *brea
On Sb, 11 oct 14, 14:12:20, John Hasler wrote:
> Andrei POPESCU writes:
> > With systemd (v215) I had to write this unit file:
>
> Which is about as complex as filling out the skeleteon script to create
> an initscript to do the same thing.
Really? How do you write an initscript that restarts you
Hi.
On Sat, 11 Oct 2014 20:47:36 +0300
Andrei POPESCU wrote:
> On Sb, 11 oct 14, 19:57:42, Reco wrote:
> > On Sat, 11 Oct 2014 15:18:58 +0300
> > Andrei POPESCU wrote:
> >
> > > On Vi, 10 oct 14, 08:36:23, Joel Rees wrote:
> > > >
> > > > Some complexities you can encapsulate or hide, or ex
Andrei POPESCU writes:
> With systemd (v215) I had to write this unit file:
Which is about as complex as filling out the skeleteon script to create
an initscript to do the same thing.
--
John Hasler
jhas...@newsguy.com
Elmwood, WI USA
--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debi
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
On Sb, 11 oct 14, 19:57:42, Reco wrote:
> On Sat, 11 Oct 2014 15:18:58 +0300
> Andrei POPESCU 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,
On Sat, 11 Oct 2014 15:18:58 +0300
Andrei POPESCU 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 b
On Sb, 11 oct 14, 12:19:29, Marty wrote:
>
> >Could it be that a modular design for such complex tasks becomes too
> >difficult to *do it right*?
>
> I don't know, but I think given its history, the burden of proof is on
> monolithic, not modular design. A better question may be whether a
> distr
On 10/11/2014 08:18 AM, Andrei POPESCU wrote:
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
Hi.
On Sat, 11 Oct 2014 15:18:58 +0300
Andrei POPESCU 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
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 ma
On Fri, 10 Oct 2014 08:36:23 +0900
Joel Rees 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 de
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 varia
It won't be able to do the same things as the device with 10 inputs and
10 outputs because you have removed the interconnections. Each device
is on its own, with the same kind of complexity. Only each device is
less complex, and the whole thing is less complex because you removed
all the l
74 matches
Mail list logo
