Re: systemd: che ne pensate?
ho letto un po' di ulteriore documentazione e riporto qui i risultati...
in lista si parla di cose completamente non vere (purtroppo anch'io ho
partecipato a tutto questo).
Si prega d'ora in poi di citare una fonte certa che dimostra quanto si
afferma, altrimenti tutti diciamo cose completamente fuori dalla realtà.
Se non facciamo così ognuno dice che gliel'ha detto suo cuggino... e
quindi dobbiamo credergli per forza
On 02/12/2014 13:19, Pol Hallen wrote:
- systemd ha i suoi log (binari) - rispetto a quelli testuali di syslog
17 Myth: systemd uses binary configuration files.
No idea who came up with this crazy myth, but it's absolutely not true.
systemd is configured pretty much exclusively via simple text files. A
few settings you can also alter with the kernel command line and via
environment variables. There's nothing binary in its configuration (not
even XML). Just plain, simple, easy-to-read text files. [1]
20 Myth: systemd makes it impossible to run syslog.
Not true, we carefully made sure when we introduced the journal that all
data is also passed on to any syslog daemon running. In fact, if
something changed, then only that syslog gets more complete data now
than it got before, since we now cover early boot stuff as well as
STDOUT/STDERR of any system service.[1]
Se ritieni che non sia vera l'affermazione sul sito di systemd, allora
dove sono questi log binari?
- tutti i servizi della macchina dipendono da systemd (e di conseguenza
se crasha occorre riavviare)
1 Myth: systemd is monolithic.
If you build systemd with all configuration options enabled you will
build 69 individual binaries. These binaries all serve different tasks,
and are neatly separated for a number of reasons. For example, we
designed systemd with security in mind, hence most daemons run at
minimal privileges (using kernel capabilities, for example) and are
responsible for very specific tasks only, to minimize their security
surface and impact. Also, systemd parallelizes the boot more than any
prior solution. This parallization happens by running more processes in
parallel. Thus it is essential that systemd is nicely split up into many
binaries and thus processes. In fact, many of these binaries[1] are
separated out so nicely, that they are very useful outside of systemd, too.
A package involving 69 individual binaries can hardly be called
monolithic. What is different from prior solutions however, is that we
ship more components in a single tarball, and maintain them upstream in
a single repository with a unified release cycle.[1]
6 Myth: systemd is not modular.
Not true at all. At compile time you have a number of configure switches
to select what you want to build, and what not. And we document how you
can select in even more detail what you need, going beyond our configure
switches.
This modularity is not totally unlike the one of the Linux kernel, where
you can select many features individually at compile time. If the kernel
is modular enough for you then systemd should be pretty close, too.[1]
la logica di SysV era (è) appunto di separare ogni singola attività
(servizi) per renderli indipendenti e di facile debugging...
6 Myth: riportato qui sopra
10 Myth: systemd is not UNIX.
There's certainly some truth in that. systemd's sources do not contain a
single line of code originating from original UNIX. However, we derive
inspiration from UNIX, and thus there's a ton of UNIX in systemd. For
example, the UNIX idea of "everything is a file" finds reflection in
that in systemd all services are exposed at runtime in a kernel file
system, the cgroupfs. Then, one of the original features of UNIX was
multi-seat support, based on built-in terminal support. Text terminals
are hardly the state of the art how you interface with your computer
these days however. With systemd we brought native multi-seat support
back, but this time with full support for today's hardware, covering
graphics, mice, audio, webcams and more, and all that fully automatic,
hotplug-capable and without configuration. In fact the design of systemd
as a suite of integrated tools that each have their individual purposes
but when used together are more than just the sum of the parts, that's
pretty much at the core of UNIX philosophy. Then, the way our project is
handled (i.e. maintaining much of the core OS in a single git
repository) is much closer to the BSD model (which is a true UNIX,
unlike Linux) of doing things (where most of the core OS is kept in a
single CVS/SVN repository) than things on Linux ever were.
Ultimately, UNIX is something different for everybody. For us systemd
maintainers it is something we derive inspiration from. For others it is
a religion, and much like the other world religions there are different
readings and understandings of it. Some define UNIX based on specific
pieces of code heritage, others see it just as a set of ideas, others as
a set of commands or APIs, and even others as a definition of
behaviours. Of course, it is impossible to ever make all these people happy.
Ultimately the question whether something is UNIX or not matters very
little. Being technically excellent is hardly exclusive to UNIX. For us,
UNIX is a major influence (heck, the biggest one), but we also have
other influences. Hence in some areas systemd will be very UNIXy, and in
others a little bit less.[1]
leggere anche:
11 Myth: systemd is complex.[1]
12 Myth: systemd is bloated.[1]
[...]in a traditional Linux setup, sysvinit, start-stop-daemon, inetd,
cron, dbus, all implemented a scheme to execute processes with various
configuration options in a certain, hopefully clean environment[...]
Se è questo che si intende per "separare ogni singola attività (servizi)
per renderli indipendenti e di facile debugging" [quindi riproporla più
volte in diverse parti, con implementazioni diverse?]
18 Myth: systemd is a feature creep.
Well, systemd certainly covers more ground that it used to. It's not
just an init system anymore, but the basic userspace building block to
build an OS from, but we carefully make sure to keep most of the
features optional. You can turn a lot off at compile time, and even more
at runtime. Thus you can choose freely how much feature creeping you
want.[1]
24 Myth: systemd is unstable and buggy.
Certainly not according to our data. We have been monitoring the Fedora
bug tracker (and some others) closely for a long long time. The number
of bugs is very low for such a central component of the OS, especially
if you discount the numerous RFE bugs we track for the project. We are
pretty good in keeping systemd out of the list of blocker bugs of the
distribution. We have a relatively fast development cycle with mostly
incremental changes to keep quality and stability high.
25 Myth: systemd is not debuggable.
False. Some people try to imply that the shell was a good debugger.
Well, it isn't really. In systemd we provide you with actual debugging
features instead. For example: interactive debugging, verbose tracing,
the ability to mask any component during boot, and more. Also, we
provide documentation for it.
It's certainly well debuggable, we needed that for our own development
work, after all. But we'll grant you one thing: it uses different
debugging tools, we believe more appropriate ones for the purpose, though.
(ad esempio) un grave bug di apache/systemd può creare un crash totale
della macchina...
fornisci un link che spiega questa cosa?
Che spiega anche che con SysV questo problema non c'è...
grazie :-)
Quello che invece systemd offre è la possibilità di evitare che un
processo fuoriesca dal cgroup a cui è assegnato e possa acquisire
permessi. Quindi maggiore sicurezza.
a tal proposito nasce il fork di debian: devuan (una debian senza systemd)
senza systemd? Ma a me sembra che dicano una cosa ben diversa:
Subject: [Dng] I want systemd
[...]
For me Devuan is about freedom. Specifically users' freedom. And with
init freedom as a starting point.
What does that mean? Since we care about init freedom, we will start by
creating a systemd-free sysvinit distro base.
Does that mean we will reject systemd? Of course NO. We care about
users' (and sysadmins') freedom. And if a user wants systemd for his
computer running Devuan we should NOT say no. We should provide it as
one more of a variety of interchangeable init systems.
If we reject systemd we are being hypocrits.
[...]
Regards
Noel
er Envite[2]
e notare che questo Noel er Envite è quello che pubblica le Devuan
weekly news[3]
Però non ho trovato una pagina in cui spiegano perché ritengano Systemd
non valido..., visto che tu dici "a tal proposito nasce..." potresti
fornirci il link per indicare qual'è questo proposito e quali sono i
reali punti di demerito trovati in systemd da queste persone?
quanto ai tempi di avvio lasciamo stare che tanto (i server non si
riavviano mai, i client vanno in sleep ;-)
3 Myth: systemd's fast boot-up is irrelevant for servers.
That is just completely not true. Many administrators actually are keen
on reduced downtimes during maintenance windows. In High Availability
setups it's kinda nice if the failed machine comes back up really fast.
In cloud setups with a large number of VMs or containers the price of
slow boots multiplies with the number of instances. Spending minutes of
CPU and IO on really slow boots of hundreds of VMs or containers reduces
your system's density drastically, heck, it even costs you more energy.
Slow boots can be quite financially expensive. Then, fast booting of
containers allows you to implement a logic such as socket activated
containers, allowing you to drastically increase the density of your
cloud system.
Of course, in many server setups boot-up is indeed irrelevant, but
systemd is supposed to cover the whole range. And yes, I am aware that
often it is the server firmware that costs the most time at boot-up, and
the OS anyways fast compared to that, but well, systemd is still
supposed to cover the whole range (see above...), and no, not all
servers have such bad firmware, and certainly not VMs and containers,
which are servers of a kind, too.[1]
qualcuno con esperienze dirette? o anche indirette perchè no :-)
ma quindi tutte queste tue affermazioni da dove le hai prese?
Ciao
Davide
[1]
http://0pointer.de/blog/projects/the-biggest-myths.html
[2]
https://lists.dyne.org/lurker/message/20141130.125423.9da1f8c2.en.html
[3]
https://lists.dyne.org/lurker/message/20141202.001444.6f817ea0.en.html
--
Dizionari: http://linguistico.sourceforge.net/wiki
Petizione contro i brevetti software in Europa:
http://petition.stopsoftwarepatents.eu/
Non autorizzo la memorizzazione del mio indirizzo su outlook
Reply to: