[arch-general] Arch Linux and systemd
Myra Nelson
myra.nelson at hughes.net
Fri Aug 17 13:33:33 EDT 2012
On Fri, Aug 17, 2012 at 4:08 AM, C Anthony Risinger <anthony at xtfx.me> wrote:
> On Fri, Aug 17, 2012 at 2:57 AM, Geoff <capsthorne at yahoo.co.uk> wrote:
> > On Thu, 16 Aug 2012 16:22:56 -0500
> > Myra Nelson <myra.nelson at hughes.net> wrote:
> >
> > <snip>
> >
> > I agree. I have read all the current threads and the few words which
> struck me
> > with greatest force were in a post from Marti Raudsepp, where he said
> that an
> > advantage of systemd is "... less fragmentation between Linux
> distribution". I
> > have been full time on linux for nearly 13 years now, with the most
> recent five
> > of those on Arch, and for me one of the principal attractions of the OS
> has
> > always been fragmentation between distributions. The recent changes to
> Arch
> > (and I dare say other distros which I do not monitor), all seem to me to
> point
> > in the direction of drab ecumenism - eventually "One distro to rule them
> > all ...." Sooner or later Arch will be distinguished only by its
> excellent
> > rolling release model and the wonderful pacman. Perhaps all this was
> > inevitable. I do not intend anything I say as a criticism of the devs -
> it is
> > their distro and they are entitled to do what they choose with it. But
> it does
> > make me sad.
>
> the boot process isn't really that interesting (once you
> know/understand it anyway ... if not i encourage you to explor ;-) --
> every distro pretty much does it the same way, but pointlessly
> independent, thus resulting in annoying differences that are
> completely irrelevant to begin with.
>
> no flexibility is lost by moving to systemd, and really, much more
> gained: wider userbase, wider testbase, simple units to write, simple
> units to read, loosely coupled ordering, implicit dependencies, Grand
> Unified logging capabilities, and of course, much better
> speed/reliability/robustness.
>
> take the (unanimous?) sentiments exhibiting by our developers -- and
> *many* developers elsewhere, in a great variety of capacities/niches
> -- as a sign of the good things to come. i fully expect 99%+ will have
> little trouble adjusting, and 98% will at that time agree it was
> clearly the right choice.
>
> initiatives like this are not removing choice -- they are
> consolidating the common bits so developers can get back to writing
> the interesting next-gen stuff instead of spinning wheels or putting
> out fires.
>
> like most things in life, balance is key to good health.
>
> --
>
> C Anthony
>
C. Anthony:
First let me apologize for you winding up with my post twice.
One thing that struck me from one of Tom's replies was "as a computer
scientist". Now my degree is in Geology and I didn't get to finish my MS in
Geophysics, not bragging just trying to set the stage for my discussion. My
programming skills started in the age of punch cards and fortran and I
skipped assembly.
I'm begining to see the disparity in this conversation. On one side we have
users and on the other side, so it seems, the devs are "computer
scientists" trying to bring the next generation to the world. A very worthy
and laudable effort. Please forgive the skeptic in me for saying, for some
of us this isn't our first rodeo and for some of us ( reads: I've been this
way for 60 years and it ain't gonna change any time soon) arguements put
forth about how simple things will become and how much better things will
be have been heard so many times with so little results, we have deaf ears.
The proof is always in the pudding and when that time comes, maybe, I'll
believe it.
The reason for differentiating between users and scientists was this. Too
many people in the world have come to distrust scientists. Just look at the
FUD that's come to this discussion. It's starting to remind me of an old
fashioned lynch mob. Now both sides have dug their feet in and refuse to
listen to each other. That was the point of my original post, to change the
discussion. To attempt to make the discussion meaningful. I would like to
take you to task on one point.
> if not i encourage you to explor ;-) --
>every distro pretty much does it the same way, but pointlessly
>independent, thus resulting in annoying differences that are
>completely irrelevant to begin with.
This may be accurate, it may be precise, it may make sense, but somewhere
someone thought it was the right way to do things. That does not, nor will
it ever, make it irrelevant. It's the beauty of using Linux. It's flexible,
one can make it work. I know first hand what happens when a scientist
attempts to make someone believe something is irrelevant and it ain't
pretty. It follows my version of Einstein's theory or relativity, "What's
relative to you may or may not be relative to me, or relative to me in the
same way".
I know all those involved are busy with their lives, school, work, etc, and
Arch users are supposed to be savvy enough to figure all this out on their
own. But consider this:
For example, you might feel in your gut that a particular design or
algorithm is the right way to go and that other suggestions aren’t as
effective. Great.
Now prove it.
It could be your expert intuition at work, or maybe it’s just a cognitive
bias or other bug. You need to get some feedback: create a prototype, run
some unit tests, and chart some benchmarks. Do what you need to do to prove
that your idea is a good one, because your intuition may have been wrong.
[94]
Feedback is the key to agile software development for precisely this
reason: software development depends on people. And as we’ve seen here,
people have bugs, too. In short, we’re all nuts—one way or another. Despite
our best intentions, we need to double-check ourselves and each other.
You need unit tests for yourself, too.
Testing Yourself
When you are dead solid convinced of something, ask yourself why. You’re
sure the boss is out to get you. How do you know? Everybody is using Java
for this kind of application. Says who? You’re a great/awful developer.
Compared to whom?
How do you know?
To help get a bigger picture perspective and test your understanding and
mental model, ask yourself something like the following questions:[95]
-
How do you know?
-
Says who?
-
How specifically?
-
How does what I’m doing cause you to...?
-
Compared to what or whom?
-
Does it always happen? Can you think of an exception?
-
What would happen if you did (or didn’t)?
-
What stops you from...?
Is there anything you can actually measure? Get hard numbers on? Any
statistics?[96] What happens when you talk this over with a colleague? How
about a colleague who has a very different viewpoint from your own? Do they
passively agree? Is that a danger sign? Do they violently oppose the idea?
Does that give it credibility? Or not?
>From "Pragmatic Thinking and Learning" Refactor Your “Wetware”Andy HuntWe
all have inate hardware bugs and preceptions, and we all need to debug
ourselves.
Myra
--
Life's fun when your sick and psychotic!
More information about the arch-general
mailing list