Gentoo Forums
Gentoo Forums
Gentoo Forums
Quick Search: in
When (and if) Gentoo will switch to systemd?
View unanswered posts
View posts from last 24 hours

Goto page Previous  1, 2, 3 ... 11, 12, 13 ... 16, 17, 18  Next  
Reply to topic    Gentoo Forums Forum Index Other Things Gentoo
View previous topic :: View next topic  
Author Message
depontius
Advocate
Advocate


Joined: 05 May 2004
Posts: 3509

PostPosted: Wed Mar 05, 2014 4:28 pm    Post subject: Reply with quote

ssuominen wrote:
Anon-E-moose wrote:
Thanks for the links, I await the even larger train wreck, LoL

Next up iptables integration into systemd (and you thought I was full of um...fertilizer when I mentioned it earlier. :lol:


http://linux.slashdot.org/story/13/10/19/2118247/nftables-to-replace-iptables-in-the-linux-kernel in case you weren't aware yet.


Last I heard, nftables was a specific point effort - not tied to other projects. To me it sounds like evolutions - ipfwadm -> ipchains -> iptables -> nftables.
_________________
.sigs waste space and bandwidth
Back to top
View user's profile Send private message
Shamus397
Apprentice
Apprentice


Joined: 03 Apr 2005
Posts: 218
Location: Ur-th

PostPosted: Wed Mar 05, 2014 4:59 pm    Post subject: Reply with quote

I found this post in that thread to be quite interesting. Seems the best documented software wins the day, not necessarily the best quality. :P
Back to top
View user's profile Send private message
NeddySeagoon
Administrator
Administrator


Joined: 05 Jul 2003
Posts: 54096
Location: 56N 3W

PostPosted: Wed Mar 05, 2014 5:58 pm    Post subject: Reply with quote

Shamus397,

Heh, no surprises there. Betamax was a superior technical solution to VHS.
VHS was better marketed.
_________________
Regards,

NeddySeagoon

Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.
Back to top
View user's profile Send private message
steveL
Watchman
Watchman


Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery

PostPosted: Wed Mar 05, 2014 6:34 pm    Post subject: Reply with quote

NeddySeagoon wrote:
Heh, no surprises there. Betamax was a superior technical solution to VHS.
VHS was better marketed.

Yeah but betamax was still in use in broadcasting houses in 1994, when I was doing audio stuff, and ISTR it was used for quite a while after.

Gentoo: the high-quality distro. ;-)
Back to top
View user's profile Send private message
Suicidal
l33t
l33t


Joined: 30 Jul 2003
Posts: 959
Location: /dev/null

PostPosted: Wed Mar 05, 2014 11:31 pm    Post subject: Reply with quote

Shum wrote:
I'm not interested in GNOME. I'm interested in kdbus, faster boot times,

My laptop boots to kdm in 8 seconds, not that it gets rebooted very often anyway. How fast does boot need to be?

Shum wrote:
easier system configuration and management

Please do explain how systemd will solve all of our woes, I can write an openrc init script in the amount of time it takes to make a pot of coffee.

Shum wrote:
and just generally being "up-to-date" with the way linux is going.

Did you just install Gentoo yesterday? We had a dependency based init system a decade before systemd was even thought of.
If you want a distro that follows other distros off a cliff like a bunch of lemmings, you are in the wrong place.

mayak wrote:
One package manager = bigger community, more testing, more features, better code(?)


Doesn't seem to be the end all be all for apt-get, there are many things I like about mint, but some of the packages are so buggy I wrote the distribution off.
Back to top
View user's profile Send private message
Yamakuzure
Advocate
Advocate


Joined: 21 Jun 2006
Posts: 2280
Location: Adendorf, Germany

PostPosted: Thu Mar 06, 2014 10:09 am    Post subject: Reply with quote

Shouldn't the topic be changed? The OP question was whether (and if when) gentoo will switch to systemd. The answer came shortly: never. So basically the OPs question is answered and the discussion went somewhere completely different, didn't it?
_________________
Important German:
  1. "Aha" - German reaction to pretend that you are really interested while giving no f*ck.
  2. "Tja" - German reaction to the apocalypse, nuclear war, an alien invasion or no bread in the house.
Back to top
View user's profile Send private message
Anon-E-moose
Watchman
Watchman


Joined: 23 May 2008
Posts: 6095
Location: Dallas area

PostPosted: Thu Mar 06, 2014 10:32 am    Post subject: Reply with quote

I'm not sure whether it's better to change the title (which the OP set) or
simply to split out some of the posts (would take some doing).

I would like to see the discussions regarding openrc/monit be moved into it's own thread though.
Simply so it won't get buried beneath side issues.
As it is a valid way forward to enhance openrc with some of the restart capabilities of the init part of systemd.
_________________
PRIME x570-pro, 3700x, 6.1 zen kernel
gcc 13, profile 17.0 (custom bare multilib), openrc, wayland
Back to top
View user's profile Send private message
depontius
Advocate
Advocate


Joined: 05 May 2004
Posts: 3509

PostPosted: Thu Mar 06, 2014 1:37 pm    Post subject: Reply with quote

Anon-E-moose wrote:

I would like to see the discussions regarding openrc/monit be moved into it's own thread though.
Simply so it won't get buried beneath side issues.
As it is a valid way forward to enhance openrc with some of the restart capabilities of the init part of systemd.


I suggest starting a new thread, something to the tune of "OpenRC enhancements". Using "monit" is only one part of the story.

1 - What's really being suggested with "monit" is better daemon monitoring, and monit is one way. I get the impression that there are multiple options, and I believe somewhere in the monit thread someone raised real and basic objections to something about the design.

2 - When thinking of "socket activation", xinetd comes to mind, and I'd like to understand its shortcomings.

3 - There are other init systems that have been discussed here. Really OpenRC isn't exactly/necessarily the init system, it's what some core init kicks off. It appears to me that other "basements" could be installed underneath OpenRC.

4 - The kicker. What about "OpenRC-logind"? Is it possible to become a functionally (if not politically) viable alternative?
_________________
.sigs waste space and bandwidth
Back to top
View user's profile Send private message
Anon-E-moose
Watchman
Watchman


Joined: 23 May 2008
Posts: 6095
Location: Dallas area

PostPosted: Thu Mar 06, 2014 2:06 pm    Post subject: Reply with quote

Good suggestions depontius.

1. I think that the design of adding monit is modular, ie others could be used instead.

2. I don't know

3. Yes, openrc sits on top of sysvinit but really does all the heavy lifting re: daemons.
It should be possible to have other init systems sit under openrc,
though some of them are a combination of sysvinit/openrc services so not sure about overlap.

4. Not sure about that. Ubuntu had, once upon a time, pulled logind out of systemd and had it running.
IIRC, LP stated that wouldn't work for long, whether because systemd is a moving target or
he was going to make sure that it would be hard to disentangle the pieces, I don't know.
It's possible that the code that Ubuntu had working standalone could be co-opted or used as a starting point.

Thanks for the suggestions.
_________________
PRIME x570-pro, 3700x, 6.1 zen kernel
gcc 13, profile 17.0 (custom bare multilib), openrc, wayland
Back to top
View user's profile Send private message
1clue
Advocate
Advocate


Joined: 05 Feb 2006
Posts: 2569

PostPosted: Thu Mar 06, 2014 5:25 pm    Post subject: Reply with quote

If anything I would suggest VERY CAREFULLY changing the name of this thread, because this is probably the most tolerable systemd thread going right now. Less yelling, so to speak. Let's not break something that seems to be somewhat constructive.

Better yet, just leave it.
Back to top
View user's profile Send private message
Fitzcarraldo
Advocate
Advocate


Joined: 30 Aug 2008
Posts: 2034
Location: United Kingdom

PostPosted: Thu Mar 06, 2014 7:08 pm    Post subject: Reply with quote

depontius wrote:
I suggest starting a new thread, something to the tune of "OpenRC enhancements".

Good idea.
_________________
Clevo W230SS: amd64, VIDEO_CARDS="intel modesetting nvidia".
Compal NBLB2: ~amd64, xf86-video-ati. Dual boot Win 7 Pro 64-bit.
OpenRC udev elogind & KDE on both.

Fitzcarraldo's blog
Back to top
View user's profile Send private message
Anon-E-moose
Watchman
Watchman


Joined: 23 May 2008
Posts: 6095
Location: Dallas area

PostPosted: Fri Mar 07, 2014 9:15 pm    Post subject: Reply with quote

Anon-E-moose wrote:
4. Not sure about that. Ubuntu had, once upon a time, pulled logind out of systemd and had it running.
IIRC, LP stated that wouldn't work for long, whether because systemd is a moving target or
he was going to make sure that it would be hard to disentangle the pieces, I don't know.
It's possible that the code that Ubuntu had working standalone could be co-opted or used as a starting point.


Was doing some reading and it looks like ubuntu had based their logind on systemd up to 205.
I was looking at a thread where LP stated that it would be hard after that point to separate out
logind as they were going to make sure that it was so intertwined with cgroup code and
the rest of the systemd code that it would be almost impossible to make it separate.
(paraphrasing what was said, but it was pretty plain, at least to me)

I still think it's possible to use ubuntu's logind as a basis for creating a viable standalone logind.
I'm not so sure that it should be intertwined with cgroup handling. That should be separate.
Not everyone uses cgroups.

Just some further thoughts from reading here and there.

Edit to add: It would have been easy to modularize systemd from the start.
You create libraries of code, one for init, one for logind, one for cgrougs, one for logging, etc
Then in main you simply hook into the library that you need.
I've done that plenty of times where I've worked in the past.
Clean interfaces between elements that can be easily swapped out as needed.
_________________
PRIME x570-pro, 3700x, 6.1 zen kernel
gcc 13, profile 17.0 (custom bare multilib), openrc, wayland
Back to top
View user's profile Send private message
steveL
Watchman
Watchman


Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery

PostPosted: Sat Mar 08, 2014 4:33 am    Post subject: Reply with quote

Anon-E-moose wrote:
It would have been easy to modularize systemd from the start.
You create libraries of code, one for init, one for logind, one for cgrougs, one for logging, etc
Then in main you simply hook into the library that you need.
I've done that plenty of times where I've worked in the past.
Clean interfaces between elements that can be easily swapped out as needed.

Don't be so sensible ;)

Reading the discussion, I have to say again that I do believe there is scope for a "process daemon", it just doesn't need to be pid 1, nor should it be. The reason I say that is because you really want the same thing that's monitoring them to be the one notified when they die, which means it starts them too. And that's where integrating with openrc is a bit more work than simply allowing monit to start separately. ATM once openrc has started a daemon, it exits. That means a pid file is required, and we cannot use prctl(PR_SET_CHILD_SUBREAPER).

So I believe there's scope for a C daemon, as simple as we can make it, and preferably not much more than a few patches to an existing monitor. The principle new functionality would be running openrc (so rc-update is being called at a remove, or in-process) and catching SIGCHILD, then relating it to what we're monitoring, the code for which should already be in-place. And ofc cgroup handling and notification.

Socket activation can also be done by the same process, since it is the ancestral "init" (via the prctl), starting all the other daemons. Though personally I think that should be kept to the same functionality as xinetd, so we don't lose determinism.

Sure it sounds a lot like systemd: but it's not. It's very different: it doesn't have implications for taking down the kernel, it's deterministic as openrc is, with convenient dependency specification, and it uses runscript, so the admin has full control via standard sh, should that be required. Most of the time it won't be, and the declarative approach will suffice.
Back to top
View user's profile Send private message
1clue
Advocate
Advocate


Joined: 05 Feb 2006
Posts: 2569

PostPosted: Sat Mar 08, 2014 4:53 am    Post subject: Reply with quote

I seriously don't see why a separate process for each thing is a bad idea. A simple, discrete, interchangeable tool for each job. It's the UNIX philosophy.
Back to top
View user's profile Send private message
gotyaoi
Tux's lil' helper
Tux's lil' helper


Joined: 01 Apr 2013
Posts: 137

PostPosted: Sat Mar 08, 2014 5:09 am    Post subject: Reply with quote

I think it was in one of steveL's links, that basically pid files are inherently unreliable, and it's better if you own a process and can definitively know when it exits.

On the other hand, I think I'll try to make an s6 plugin for qnikst's system, just to see how it goes, if nothing else.
Back to top
View user's profile Send private message
SamuliSuominen
Retired Dev
Retired Dev


Joined: 30 Sep 2005
Posts: 2133
Location: Finland

PostPosted: Sat Mar 08, 2014 7:10 am    Post subject: Reply with quote

Anon-E-moose wrote:
Anon-E-moose wrote:
4. Not sure about that. Ubuntu had, once upon a time, pulled logind out of systemd and had it running.
IIRC, LP stated that wouldn't work for long, whether because systemd is a moving target or
he was going to make sure that it would be hard to disentangle the pieces, I don't know.
It's possible that the code that Ubuntu had working standalone could be co-opted or used as a starting point.


Was doing some reading and it looks like ubuntu had based their logind on systemd up to 205.
I was looking at a thread where LP stated that it would be hard after that point to separate out
logind as they were going to make sure that it was so intertwined with cgroup code and
the rest of the systemd code that it would be almost impossible to make it separate.
(paraphrasing what was said, but it was pretty plain, at least to me)


It's based on 204 and both Debian and Ubuntu use the same patch:

http://ftp.de.debian.org/debian/pool/main/s/systemd/systemd_204-7.debian.tar.xz
http://archive.ubuntu.com/ubuntu/pool/main/s/systemd/systemd_204-5ubuntu13.debian.tar.gz

Code:

--- systemd-204.orig/src/login/pam-module.c
+++ systemd-204/src/login/pam-module.c
@@ -336,10 +336,6 @@ _public_ PAM_EXTERN int pam_sm_open_sess
 
         /* pam_syslog(handle, LOG_INFO, "pam-systemd initializing"); */
 
-        /* Make this a NOP on non-logind systems */
-        if (!logind_running())
-                return PAM_SUCCESS;
-
         if (parse_argv(handle,
                        argc, argv,
                        &controllers, &reset_controllers,
@@ -400,7 +396,8 @@ _public_ PAM_EXTERN int pam_sm_open_sess
 
         bus = dbus_bus_get_private(DBUS_BUS_SYSTEM, &error);
         if (!bus) {
-                pam_syslog(handle, LOG_ERR, "Failed to connect to system bus: %s", bus_error_message(&error));
+                if (debug)
+                        pam_syslog(handle, LOG_ERR, "Failed to connect to system bus: %s", bus_error_message(&error));
                 r = PAM_SESSION_ERR;
                 goto finish;
         }


Code:

--- systemd-204.orig/src/login/logind.c
+++ systemd-204/src/login/logind.c
@@ -978,6 +978,11 @@ int manager_spawn_autovt(Manager *m, int
             (unsigned) vtnr != m->reserve_vt)
                 return 0;
 
+        /* It only makes sense to send a StartUnit call to systemd if this
+         * machine is actually booted with systemd. */
+        if (!sd_booted())
+                return 0;
+
         if ((unsigned) vtnr != m->reserve_vt) {
                 /* If this is the reserved TTY, we'll start the getty
                  * on it in any case, but otherwise only if it is not
@@ -1371,9 +1376,17 @@ void manager_gc(Manager *m, bool drop_no
         Seat *seat;
         Session *session;
         User *user;
+        Iterator i;
 
         assert(m);
 
+        /* clean up empty sessions when not running under systemd */
+        if (!sd_booted()) {
+                HASHMAP_FOREACH(session, m->session_cgroups, i)
+                        if (session_get_state(session) == SESSION_CLOSING)
+                                session_add_to_gc_queue(session);
+        }
+
         while ((seat = m->seat_gc_queue)) {
                 LIST_REMOVE(Seat, gc_queue, m->seat_gc_queue, seat);
                 seat->in_gc_queue = false;


Code:

--- systemd-204.orig/src/login/logind-session.c
+++ systemd-204/src/login/logind-session.c
@@ -642,7 +642,7 @@ static int session_terminate_cgroup(Sess
 
                         r = manager_get_session_by_pid(s->manager, s->leader, &t);
                         if (r > 0 && t == s) {
-                                kill(s->leader, SIGTERM); /* for normal processes */
+                                /*kill(s->leader, SIGTERM); */ /* for normal processes */
                                 kill(s->leader, SIGHUP);  /* for shells */
                                 kill(s->leader, SIGCONT); /* in case they are stopped */
                         }


This no longer applies cleanly since 206, which is likely why both Debian and Ubuntu are stuck at 204 for now. It's also unlikely they will forward port it, since they have made the decision to switch into systemd.
Indeed, this could be used as a basis for the work, in addition to the required changes in C, there is the requirement of build system plus Gentoo bits like init script.

I had logind separately running w/ =sys-fs/udev-204 and OpenRC a while back, but I never got the job (ebuild, build system) finalized, and gave up when upstream diverged too much. But I wish good luck to anyone trying it.
Back to top
View user's profile Send private message
mv
Watchman
Watchman


Joined: 20 Apr 2005
Posts: 6747

PostPosted: Sat Mar 08, 2014 9:11 am    Post subject: Reply with quote

Shamus397 wrote:
Seems the best documented software wins the day, not necessarily the best quality.

s/best/reasonably/
nftables is really an example how it should not be done: When I checked last, the "documentation" was one blog with a few examples. If you want to find out the syntax, commands, semantics of the configuration language or just want to understand roughly what your configuration finally does, you have to analyze the source code. In other words: If you have not understood the full source code, you cannot even configure that thing for a safe system. Except for a few security specialists nobody will spend the time to do this.
Back to top
View user's profile Send private message
Anon-E-moose
Watchman
Watchman


Joined: 23 May 2008
Posts: 6095
Location: Dallas area

PostPosted: Sat Mar 08, 2014 10:50 am    Post subject: Reply with quote

steveL wrote:
Don't be so sensible ;)


It's in my nature. LoL

Quote:
Reading the discussion, I have to say again that I do believe there is scope for a "process daemon", it just doesn't need to be pid 1, nor should it be.


What I said about modularity shouldn't mean that I think it's a good idea to run everything as pid 1.
I remember all too well the BSOD and that's what happens with one intertwined process controlling everything ala MS windows.

But what I said is true, it should have been modularized, then things could have been called from one place (if someone desired)
or it could have been done as separate executables (with init starting first) or some combination of the two, with the added
ability to not use some parts if not desired. Don't want cgroups don't run it, don't want binary logging don't run it. Etc....

It might be well to look at the feasibility of taking the systemd code and modularizing it properly.
That way, init, logind, cgroups, daemon management, etc could be used without the sink clogging up.
_________________
PRIME x570-pro, 3700x, 6.1 zen kernel
gcc 13, profile 17.0 (custom bare multilib), openrc, wayland
Back to top
View user's profile Send private message
Anon-E-moose
Watchman
Watchman


Joined: 23 May 2008
Posts: 6095
Location: Dallas area

PostPosted: Wed Mar 12, 2014 8:39 pm    Post subject: Reply with quote

I pulled down the 208 systemd code and looked at it.

I think rather than trying to modularize it, it might be better
to go with my original thought of enhancing openrc.
Perhaps provide the abi interface that systemd provides
and just make things work the right way and make it modular.
Want daemon monitoring, use that module,
want logind then use that module, etc.

I think it's going to be hard enough to keep up with just
abi interface changes instead of trying to modularize
systemd every time a new version comes out. I do
expect that once they understand that their might
be competition, the changes will come hard and heavy
and let the users be damned.

But if a stable interface done right is presented then those
that have chosen to use systemd might change their mind.


On another note, anything new happening on the openrc/monit front?


And admins, it might be a good idea to split off the stuff from several pages back where openrc/monit
was being discussed and split into it's own thread, call it "systemd alternatives" or whatever.

Edit to add: this just goes to what I said about trying to keep up with systemd.
Quote:
systemd 211 Released with Major Fixes and Stability Improvements

Of course the stability is because of bugs they introduced in version 209 but that doesn't matter
it will be increasingly harder to keep up with not only bug fixes but enhancements.
_________________
PRIME x570-pro, 3700x, 6.1 zen kernel
gcc 13, profile 17.0 (custom bare multilib), openrc, wayland
Back to top
View user's profile Send private message
Dominique_71
Veteran
Veteran


Joined: 17 Aug 2005
Posts: 1869
Location: Switzerland (Romandie)

PostPosted: Thu Mar 13, 2014 7:57 am    Post subject: Reply with quote

NeddySeagoon wrote:
Shamus397,

Heh, no surprises there. Betamax was a superior technical solution to VHS.
VHS was better marketed.


Exactly like the Amiga was a far better technical solution than the PC, this both for their hardware than for their OS, but their marketing was as bad than their computers was good.
_________________
"Confirm You are a robot." - the singularity
Back to top
View user's profile Send private message
666threesixes666
Veteran
Veteran


Joined: 31 May 2011
Posts: 1248
Location: 42.68n 85.41w

PostPosted: Thu Mar 13, 2014 8:57 am    Post subject: Reply with quote

1clue wrote:
I seriously don't see why a separate process for each thing is a bad idea. A simple, discrete, interchangeable tool for each job. It's the UNIX philosophy.


im a big fan of not selling my self lies. rm has recursion functions and flags to make it do things besides just rm..... just as ping and others do..... if that really is the unix philosophy, it is extremely flawed, and NEVER adhered to. emerge has an avalanche of functions and it does them well. emerge certainly does not do 1 thing, it violates this philosophy. ill start throwing the bath water out with the baby too..... if we actually followed that flawed philosophy the package list for linux etc would be much larger. ex lspci... lspci -k becomes lspci and hwmods.
Back to top
View user's profile Send private message
Anon-E-moose
Watchman
Watchman


Joined: 23 May 2008
Posts: 6095
Location: Dallas area

PostPosted: Thu Mar 13, 2014 9:20 am    Post subject: Reply with quote

666threesixes666 wrote:
1clue wrote:
I seriously don't see why a separate process for each thing is a bad idea. A simple, discrete, interchangeable tool for each job. It's the UNIX philosophy.


im a big fan of not selling my self lies. rm has recursion functions and flags to make it do things besides just rm.....


rm does one thing, it removes files/directories/sockets.
The fact that it can recurse directories doesn't make it do more than one thing.
It doesn't walk your dog, it doesn't create files, it doesn't talk to remote devices.

lspci does one thing.
emerge does one thing.

That they may have subfunctions, doesn't make it do more than one thing.
One tool, one job, is the unix philosophy.

I don't know whether you really don't understand.
But in any case your description of your examples is flawed whatever your motives are.

Edit to add: And yes, sometimes the philosophy gets violated. But by and large it is followed by most programs and programmers.
An editor does editing, a mail program handles mail, a compiler compiles and creates programs.
_________________
PRIME x570-pro, 3700x, 6.1 zen kernel
gcc 13, profile 17.0 (custom bare multilib), openrc, wayland
Back to top
View user's profile Send private message
depontius
Advocate
Advocate


Joined: 05 May 2004
Posts: 3509

PostPosted: Thu Mar 13, 2014 10:10 am    Post subject: Reply with quote

Anon-E-moose wrote:

An editor does editing, a mail program handles mail, a compiler compiles and creates programs.


Perhaps a poor example - there's always emacs, oft cited as the ultimate case of creeping functionality.
_________________
.sigs waste space and bandwidth
Back to top
View user's profile Send private message
Anon-E-moose
Watchman
Watchman


Joined: 23 May 2008
Posts: 6095
Location: Dallas area

PostPosted: Thu Mar 13, 2014 10:12 am    Post subject: Reply with quote

depontius wrote:
Anon-E-moose wrote:

An editor does editing, a mail program handles mail, a compiler compiles and creates programs.


Perhaps a poor example - there's always emacs, oft cited as the ultimate case of creeping functionality.


LoL, true, but as I said in a footnote, there are a few that violate that philosophy.
I used emacs for quite a while, but went back to vi, I didn't need a kitchen sink as an editor. :lol:
Though if one likes it one might never have to leave the confines of it.
_________________
PRIME x570-pro, 3700x, 6.1 zen kernel
gcc 13, profile 17.0 (custom bare multilib), openrc, wayland
Back to top
View user's profile Send private message
khayyam
Watchman
Watchman


Joined: 07 Jun 2012
Posts: 6227
Location: Room 101

PostPosted: Thu Mar 13, 2014 10:40 am    Post subject: Reply with quote

666threesixes666 wrote:
... if that really is the unix philosophy, it is extremely flawed, and NEVER adhered to.

666threesixes666 ... for all your often convoluted advice, this is possibly the most transparent. No one expects that you understand what the "unix philosophy" is, but before you go ahead calling "extremely flawed" you really should have some idea of what it is your talking about ...

A flawed little human (Doug McIlroy) once wrote ...

Quote:
Make each program do one thing well. To do a new job, build afresh rather than complicate old programs by adding new features.

We can see this same idea echoed in the first of these rules ...
    the rule of modularity: write simple parts connected by clean interfaces.
    the rule of clarity: clarity is better than cleverness.
    the rule of composition: design programs to be connected to other programs.
    the rule of separation: separate policy from mechanism; separate interfaces from engines.
    the rule of simplicity: design for simplicity; add complexity only where you must.
    the rule of parsimony: write a big program only when it is clear by demonstration that nothing else will do.
    the rule of transparency: design for visibility to make inspection and debugging easier.
    the rule of robustness: robustness is the child of transparency and simplicity.
    the rule of representation: fold knowledge into data so program logic can be stupid and robust.
    the rule of least surprise: in interface design, always do the least surprising thing.
    the rule of silence: when a program has nothing surprising to say, it should say nothing.
    the rule of repair: when you must fail, fail noisily and as soon as possible.
    the rule of economy: programmer time is expensive; conserve it in preference to machine time.
    the rule of generation: avoid hand-hacking; write programs to write programs when you can.
    the rule of optimization: prototype before polishing ... get it working before you optimize it.
    the rule of diversity: distrust all claims for "one true way".
    the rule of extensibility: design for the future, because it will be here sooner than you think.
... feel free to expound on any of the above ... but be careful to undertand the idea behind them first.

best ... khay
Back to top
View user's profile Send private message
Display posts from previous:   
Reply to topic    Gentoo Forums Forum Index Other Things Gentoo All times are GMT
Goto page Previous  1, 2, 3 ... 11, 12, 13 ... 16, 17, 18  Next
Page 12 of 18

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum