Scheduled Maintenance: We are aware of an issue with Google, AOL, and Yahoo services as email providers which are blocking new registrations. We are trying to fix the issue and we have several internal and external support tickets in process to resolve the issue. Please see: viewtopic.php?t=158230

 

 

 

Xfce4 default for Jessie? systemd + GNOME + delicious drama!

User discussion about Debian Development, Debian Project News and Announcements. Not for support questions.
Message
Author
tomazzi
Posts: 730
Joined: 2013-08-02 21:33

Re: Xfce4 default for Jessie? systemd + GNOME + delicious dr

#136 Post by tomazzi »

The crucial problem is that those "geniuses" are using assert() to prevent segfaults.
Assert() is an ancient macro which has only 2 destructive effects:
- in debug builds it just kills the process (what can be easily used to disable some services or just kill the system - fortunatelly, at least sometimes this can produce a log entry)
- in release builds assert() is ignored and causes segfaults on errors - this means a system crash (not booting or killing vital services)

There are at least few other ways to go, but those "geniuses" don't even know about it - and this is a real problem.

However, usage of assert would be only a little problem, because it only means a low quality and insecure code which can be compromised practically only by memory errors or deep infiltration of the system. Unfortunately, the fact is, that their code is not prepared to withstand even most trivial methods of attacks - like injecting invalid entries to config files - so the services or the system can be killed/crashed/violated using literally thousants of methods.
This is a critical problem and it will remain a problem unless someone will kick out systemd from Debian (or rewrite it from ground up).

Regards.
Odi profanum vulgus

User avatar
edbarx
Posts: 5401
Joined: 2007-07-18 06:19
Location: 35° 50 N, 14 º 35 E
Been thanked: 2 times

Re: Xfce4 default for Jessie? systemd + GNOME + delicious dr

#137 Post by edbarx »

tomazzi wrote:Assert() is an ancient macro which has only 2 destructive effects:
- in debug builds it just kills the process (what can be easily used to disable some services or just kill the system - fortunatelly, at least sometimes this can produce a log entry)
- in release builds assert() is ignored and causes segfaults on errors - this means a system crash (not booting or killing vital services)
Excuse me if I will say an impossibility but I do programming as a past time although I have tertiary mathematics and science education.

I think, assert() can be reimplemented with a different behaviour to rectify its questionable behaviour. This can be done easily by renaming assert() to some other name like safe_assert().
tomazzi wrote:their code is not prepared to withstand even most trivial methods of attacks - like injecting invalid entries to config files - so the services or the system can be killed/crashed/violated using literally thousants of methods.
As coders they should know about parsers and why they are used, especially where a system critical executable is involved. If as they claim, their config files are simpler, it should also be simpler to write a proper parser to validate the config files entries. Avoding this basic task doesn't augur very well.

Added Later:
The problem with reimplementing assert() is when an error occurs. It seems the "geniuses" code is incomplete as it doesn't handle error situations properly. Exiting and crashing on errors is not serious programming especially when one is dealing with a system dependable executable. It seems these progammers were conditioned by the overuse of exceptions as their use of assert() smells of that type of code.

Added Later 2:
This is becoming interesting... I love to write code that tries to forsee what can go wrong and respond accordingly. Do think someone like me can try to debianize those parts of systemd where it should be edited? If the work is not overwhelming, I am ready to give my little helping hand.
Debian == { > 30, 000 packages }; Debian != systemd
The worst infection of all, is a false sense of security!
It is hard to get away from CLI tools.

tomazzi
Posts: 730
Joined: 2013-08-02 21:33

Re: Xfce4 default for Jessie? systemd + GNOME + delicious dr

#138 Post by tomazzi »

Unfortunately reimplementing assert() with some kind of "safe_assert()" only sounds easy.
Decision on using proper event handling system should be taken before first line of code is written - because this allows to plan what areas of code are protected and how particular events should be propagated. Proper event propagation ensures that every event can be logged, but what's more important, it is possible for the program to take a conscious decision what to do next.
It is easier to rewrite the program reusing portions of original code than implementing event handling system into existing solution.

There are 2 ways to create event handling system:
1. Each function can use special event structure to report what went wrong (which arguments are bad or which sub-function have failed) and return it to the higher level function (propagate) or call an arbitrary event handler, which can either try to fix the error, make a log entry or execute alternative "safe mode" function. This method needs more code to be written, but has one big advatnage: it is easy to trace and log full path of code execution in the debugger.
2. Implement exceptions - yes C code can handle exceptions, and most of existing implementations are far better than in C++
Example: http://www.on-time.com/ddj0011.htm
Properly handled exceptions are still far better solution than just killing the process with assert().

I could rewrite the systmd, but I simply don't have time to do this - I'm working on 2 important projects at the moment, not counting few other smaller ones, what takes almost all my free time. Perhaps in a few months or so I'll finish some of those projects and then we can try to fix systemd.
...or better fork it, cause I don't think that those "geniuses" will accept any patches.
...nsysd? (aka new systemd or not a systemd?) :)
Odi profanum vulgus

User avatar
edbarx
Posts: 5401
Joined: 2007-07-18 06:19
Location: 35° 50 N, 14 º 35 E
Been thanked: 2 times

Re: Xfce4 default for Jessie? systemd + GNOME + delicious dr

#139 Post by edbarx »

I downloaded systemd's source code, searched for the occurrence of assert and saved the results in a text file. There are around 2500 occurrences of assert and assert_cc! :shock:

Some examples are:

Code: Select all

acl-util.c:22:#include <assert.h>
acl-util.c:34:        assert(acl);
acl-util.c:35:        assert(entry);
ask-password-api.c:70:        assert(message);
ask-password-api.c:71:        assert(_passphrase);
ask-password-api.c:255:        assert(name);
ask-password-api.c:320:        assert(_passphrases);
ask-password-api.c:322:        assert_se(sigemptyset(&mask) == 0);
ask-password-api.c:324:        assert_se(sigprocmask(SIG_BLOCK, &mask, &oldmask) == 0);
ask-password-api.c:549:        assert_se(sigprocmask(SIG_SETMASK, &oldmask, NULL) == 0);
ask-password-api.c:555:        assert(message);
ask-password-api.c:556:        assert(_passphrases);
ask-password.c:25:#include <assert.h>
ask-password.c:89:        assert(argc >= 0);
ask-password.c:90:        assert(argv);
automount.c:54:        assert(u);
automount.c:55:        assert(u->load_state == UNIT_STUB);
automount.c:66:        assert(path);
automount.c:83:        assert(a);
automount.c:105:        assert(a);
automount.c:120:        assert(a);
automount.c:121:        assert(m);
automount.c:143:        assert(a);
automount.c:155:        assert(a);
automount.c:172:        assert(a);
automount.c:200:        assert(u);
automount.c:201:        assert(u->load_state == UNIT_STUB);
automount.c:239:        assert(a);
automount.c:261:        assert(a);
automount.c:262:        assert(a->state == AUTOMOUNT_DEAD);
automount.c:272:                        assert(a->pipe_fd >= 0);
automount.c:287:        assert(a);
automount.c:301:        assert(a);
automount.c:312:        assert(m);
automount.c:341:        assert(dev_autofs_fd >= 0);
automount.c:342:        assert(where);
automount.c:377:        assert(dev_autofs_fd >= 0);
automount.c:378:        assert(ioctl_fd >= 0);
automount.c:403:        assert(dev_autofs_fd >= 0);
automount.c:404:        assert(ioctl_fd >= 0);
automount.c:419:        assert(dev_autofs_fd >= 0);
automount.c:420:        assert(ioctl_fd >= 0);
automount.c:441:        assert(a);
automount.c:442:        assert(status <= 0);
automount.c:489:        assert(a);
automount.c:490:        assert(a->pipe_fd < 0);
automount.c:491:        assert(a->where);
automount.c:561:        assert_se(close_pipe(p) == 0);
automount.c:578:        assert(a);
automount.c:579:        assert(UNIT_DEREF(a->mount));
automount.c:617:        assert(a);
automount.c:619:        assert(a->state == AUTOMOUNT_DEAD || a->state == AUTOMOUNT_FAILED);
automount.c:637:        assert(a);
automount.c:639:        assert(a->state == AUTOMOUNT_WAITING || a->state == AUTOMOUNT_RUNNING);
automount.c:650:        assert(a);
automount.c:651:        assert(f);
automount.c:652:        assert(fds);
automount.c:677:        assert(a);
automount.c:678:        assert(fds);
automount.c:734:        assert(u);
automount.c:740:        assert(u);
automount.c:748:        assert(a);
automount.c:762:        assert(a);
automount.c:763:        assert(fd == a->pipe_fd);
automount.c:815:        assert(m);
automount.c:824:        assert(a);
bridge.c:46:        assert(l > 0);
bridge.c:87:                assert(len <= EXTRA_SIZE);
bridge.c:209:                assert(nfds >= 1);
bridge.c:290:                                        assert(in_buffer_full >= (size_t) k);
bridge.c:335:                                        assert(out_buffer_full >= (size_t) k);
cgls.c:62:        assert(argc >= 1);
cgls.c:63:        assert(argv);
cgroup-attr.c:31:        assert(a);
cgroup-attr.c:77:        assert(controller);
cgroup-attr.c:78:        assert(name);
cgroup-attr.c:89:        assert(a);
cgroup.c:23:#include <assert.h>
cgroup.c:37:        assert(b);
cgroup.c:38:        assert(b->path);
cgroup.c:39:        assert(b->controller);
cgroup.c:64:        assert(b);
cgroup.c:72:                        assert_se(f = hashmap_get(b->unit->manager->cgroup_bondings, b->path));
cgroup.c:98:        assert(b);
cgroup.c:114:        assert(b);
cgroup.c:115:        assert(pid >= 0);
cgroup.c:136:        assert(b);
cgroup.c:158:        assert(b);
cgroup.c:180:        assert(b);
cgroup.c:181:        assert(sig >= 0);
cgroup.c:227:        assert(b);
cgroup.c:265:        assert(m);
cgroup.c:344:        assert(m);
cgroup.c:362:        assert(m);
cgroup.c:363:        assert(cgroup);
cgroup.c:364:        assert(bonding);
cgroup.c:401:        assert(m);
cgroup.c:402:        assert(group);
cgroup.c:440:        assert(m);
cgroup.c:481:        assert(controller);
cgroup.c:493:        assert(b);
cgroup.c:505:        assert(b);
cgroup-show.c:101:                assert(n < n_allocated);
cgroup-show.c:250:        assert(controller);
cgroup-show.c:251:        assert(path);
cgroup-util.c:43:        assert(controller);
cgroup-util.c:44:        assert(path);
cgroup-util.c:45:        assert(_f);
cgroup-util.c:65:        assert(controller);
cgroup-util.c:66:        assert(path);
cgroup-util.c:67:        assert(_f);
cgroup-util.c:109:        assert(controller);
cgroup-util.c:110:        assert(path);
cgroup-util.c:111:        assert(_d);
cgroup-util.c:131:        assert(d);
cgroup-util.c:198:        assert(controller);
cgroup-util.c:199:        assert(path);
cgroup-util.c:200:        assert(sig >= 0);
cgroup-util.c:286:        assert(path);
cgroup-util.c:287:        assert(controller);
cgroup-util.c:288:        assert(sig >= 0);
cgroup-util.c:347:        assert(path);
cgroup-util.c:348:        assert(controller);
cgroup-util.c:382:        assert(controller);
cgroup-util.c:383:        assert(from);
cgroup-util.c:384:        assert(to);
cgroup-util.c:455:        assert(controller);
cgroup-util.c:456:        assert(from);
cgroup-util.c:457:        assert(to);
cgroup-util.c:510:        assert(controller);
cgroup-util.c:511:        assert(fs);
cgroup-util.c:588:        assert(controller);
cgroup-util.c:589:        assert(path);
cgroup-util.c:628:        assert(controller);
cgroup-util.c:629:        assert(path);
cgroup-util.c:644:        assert(controller);
cgroup-util.c:645:        assert(path);
cgroup-util.c:671:        assert(controller);
cgroup-util.c:672:        assert(path);
cgroup-util.c:673:        assert(pid >= 0);
cgroup-util.c:693:        assert(controller);
cgroup-util.c:694:        assert(path);
cgroup-util.c:695:        assert(pid >= 0);
cgroup-util.c:712:        assert(controller);
cgroup-util.c:713:        assert(path);
cgroup-util.c:732:        assert(controller);
cgroup-util.c:733:        assert(path);
cgroup-util.c:782:        assert(controller);
cgroup-util.c:783:        assert(path);
cgroup-util.c:784:        assert(pid >= 0);
cgroup-util.c:847:        assert(controller);
cgroup-util.c:848:        assert(agent);
cgroup-util.c:909:        assert(controller);
cgroup-util.c:910:        assert(path);
cgroup-util.c:937:        assert(controller);
cgroup-util.c:938:        assert(path);
cgroup-util.c:979:        assert(spec);
cgroup-util.c:980:        assert(controller || path);
cgroup-util.c:1040:        assert(controller);
cgroup-util.c:1041:        assert(path);
cgroup-util.c:1059:        assert(path);
cgroup-util.c:1060:        assert(result);
cgroup-util.c:1088:        assert(path);
cgtop.c:68:        assert(g);
cgtop.c:93:        assert(controller);
cgtop.c:94:        assert(path);
cgtop.c:95:        assert(a);
cgtop.c:117:                        assert_se(hashmap_move_one(a, b, path) == 0);
cgtop.c:162:                assert_se(clock_gettime(CLOCK_MONOTONIC, &ts) == 0);
cgtop.c:247:                assert_se(clock_gettime(CLOCK_MONOTONIC, &ts) == 0);
cgtop.c:286:        assert(controller);
cgtop.c:287:        assert(path);
cgtop.c:288:        assert(a);
cgtop.c:339:        assert(a);
cgtop.c:423:        assert(a);
cgtop.c:522:        assert(argc >= 1);
cgtop.c:523:        assert(argv);
condition.c:39:        assert(type < _CONDITION_TYPE_MAX);
condition.c:61:        assert(c);
condition.c:81:        assert(parameter);
condition.c:127:        assert(parameter);
condition.c:196:        assert(c);
condition.c:257:                assert_not_reached("Invalid condition type.");
condition.c:288:        assert(c);
condition.c:289:        assert(f);
....
These are the source files for systemd:

Code: Select all

systemd-44/src$ ls
99-systemd.rules.in            machine-id-main.c
acl-util.c                     machine-id-setup.c
acl-util.h                     machine-id-setup.h
ac-power.c                     macro.h
ask-password-api.c             main.c
ask-password-api.h             manager.c
ask-password.c                 manager.h
assert_sysd                    missing.h
automount.c                    modules-load.c
automount.h                    mount.c
binfmt                         mount.h
bridge.c                       mount-setup.c
build.h                        mount-setup.h
bus-errors.h                   namespace.c
cgls.c                         namespace.h
cgroup-attr.c                  notify.c
cgroup-attr.h                  nspawn.c
cgroup.c                       org.freedesktop.systemd1.conf
cgroup.h                       org.freedesktop.systemd1.policy.in.in
cgroups-agent.c                org.freedesktop.systemd1.service
cgroup-show.c                  pager.c
cgroup-show.h                  pager.h
cgroup-util.c                  path.c
cgroup-util.h                  path.h
cgtop.c                        path-lookup.c
condition.c                    path-lookup.h
condition.h                    polkit.c
conf-parser.c                  polkit.h
conf-parser.h                  quotacheck.c
cryptsetup                     random-seed.c
dbus-automount.c               ratelimit.c
dbus-automount.h               ratelimit.h
dbus.c                         rc-local-generator.c
dbus-common.c                  readahead
dbus-common.h                  remount-api-vfs.c
dbus-device.c                  reply-password.c
dbus-device.h                  sd-daemon.c
dbus-execute.c                 sd-id128.c
dbus-execute.h                 securebits.h
dbus.h                         selinux-setup.c
dbus-job.c                     selinux-setup.h
dbus-job.h                     service.c
dbus-loop.c                    service.h
dbus-loop.h                    set.c
dbus-manager.c                 set.h
dbus-manager.h                 shutdown.c
dbus-mount.c                   shutdownd.c
dbus-mount.h                   shutdownd.h
dbus-path.c                    snapshot.c
dbus-path.h                    snapshot.h
dbus-service.c                 socket.c
dbus-service.h                 socket.h
dbus-snapshot.c                socket-util.c
dbus-snapshot.h                socket-util.h
dbus-socket.c                  spawn-agent.c
dbus-socket.h                  spawn-agent.h
dbus-swap.c                    special.h
dbus-swap.h                    specifier.c
dbus-target.c                  specifier.h
dbus-target.h                  strv.c
dbus-timer.c                   strv.h
dbus-timer.h                   swap.c
dbus-unit.c                    swap.h
dbus-unit.h                    sysctl.c
def.h                          sysfs-show.h
detect-virt.c                  systemadm.c
device.c                       systemadm.vala
device.h                       system.conf
execute.c                      systemctl.c
execute.h                      systemd
exit-status.c                  systemd-analyze
exit-status.h                  systemd-bash-completion.sh
fdset.c                        systemd-interfaces.c
fdset.h                        systemd-interfaces.vala
fsck.c                         systemd.pc.in
getty-generator.c              target.c
gnome-ask-password-agent.c     target.h
gnome-ask-password-agent.vala  tcpwrap.c
hashmap.c                      tcpwrap.h
hashmap.h                      test-cgroup.c
hostname                       test-daemon.c
hostname-setup.c               test-engine.c
hostname-setup.h               test-env-replace.c
initctl.c                      test-hostname.c
initreq.h                      test-id128.c
install.c                      test-install.c
install.h                      test-job-type.c
ioprio.h                       test-loopback.c
job.c                          test-ns.c
job.h                          test-strv.c
journal                        timedate
kmod-setup.c                   timer.c
kmod-setup.h                   timer.h
label.c                        timestamp.c
label.h                        tmpfiles.c
libsystemd-daemon.pc.in        tty-ask-password-agent.c
libsystemd-daemon.sym          umount.c
libsystemd-id128.pc.in         umount.h
libsystemd-id128.sym           unit.c
linux                          unit.h
list.h                         unit-name.c
load-dropin.c                  unit-name.h
load-dropin.h                  update-utmp.c
load-fragment.c                user.conf
load-fragment-gperf.gperf.m4   utf8.c
load-fragment.h                utf8.h
locale                         util.c
locale-setup.c                 util.h
locale-setup.h                 utmp-wtmp.c
log.c                          utmp-wtmp.h
log.h                          vconsole
login                          virt.c
logs-show.c                    virt.h
logs-show.h                    wraplabel.c
loopback-setup.c               wraplabel.vala
loopback-setup.h
Debian == { > 30, 000 packages }; Debian != systemd
The worst infection of all, is a false sense of security!
It is hard to get away from CLI tools.

User avatar
edbarx
Posts: 5401
Joined: 2007-07-18 06:19
Location: 35° 50 N, 14 º 35 E
Been thanked: 2 times

Re: Xfce4 default for Jessie? systemd + GNOME + delicious dr

#140 Post by edbarx »

These are the frequencies of assert in systemd's code. Not completed.

Code: Select all

acl-util.c			2
ask-password-api.c		12
automount.c			51
bridge.c				5
cgls.c				2
cgroup.c				29
cgroup-show.c			3
cgroup-util.c			58
cgtop.c				14
condition.c			8
conf-parser.c			79
conf-parser.h			4
dbus.c				67
dbus-common.c		66
dbus-common.h		2
dbus-execute.c		35
dbus-job.c			11
dbus-loop.c			14
dbus-manager.c		29
dbus-mount.c			9
dbus-path.c			6
dbus-swap.c			3
dbus-timer.c			7
dbus-unit.c			44
device.c				29
execute.c				63
fdset.c				10
fsck.c				1
getty-generator.c		3
hashmap.c			21
Debian == { > 30, 000 packages }; Debian != systemd
The worst infection of all, is a false sense of security!
It is hard to get away from CLI tools.

tomazzi
Posts: 730
Joined: 2013-08-02 21:33

Re: Xfce4 default for Jessie? systemd + GNOME + delicious dr

#141 Post by tomazzi »

So there is at least 2500 ways to damage Debian by using systemd...
Outrageous.

edbarx:
As You can see this not going to be an easy task - it will need a lot of time and effort.
Odi profanum vulgus

User avatar
edbarx
Posts: 5401
Joined: 2007-07-18 06:19
Location: 35° 50 N, 14 º 35 E
Been thanked: 2 times

Re: Xfce4 default for Jessie? systemd + GNOME + delicious dr

#142 Post by edbarx »

I think, systemd can be improved by replacing all occurrences of assert by something similar to:

Code: Select all

bool assert_failed = 0; // global variable accessible by the process loading function

if (!(logic test for replacing assert))
{
      assert_failed = 1;
      return;
}
The process doing the system initialization, at every initialization step checks for the value of assert_failed:

Code: Select all

if (assert_failed)
{
    gracefully terminate all loaded processes;
    display the process name causing the failure;
    display the relevant config file and line causing the failure;
    inform the user system is halted gracefully;
    enter a loop similar to the kernel's panic;
}
Failing processes should also release any allocated memory.
Debian == { > 30, 000 packages }; Debian != systemd
The worst infection of all, is a false sense of security!
It is hard to get away from CLI tools.

tomazzi
Posts: 730
Joined: 2013-08-02 21:33

Re: Xfce4 default for Jessie? systemd + GNOME + delicious dr

#143 Post by tomazzi »

I was wrong, systemd is using assert() but it is overridden (v210): src/shared/macro.h.164:

Code: Select all

#undef assert
#ifdef NDEBUG
#define assert(expr) do {} while(false)
#else
#define assert(expr) assert_se(expr)
#endif
In release builds assert() does nothing - it's just dummy code -> crash/undefined behaviour
In debug builds it is replaced with assert_se() which just logs message and calls abort() so it works almost identically to original assert()
src/shared/macro.h.157:

Code: Select all

#define assert_se(expr)                                                 \
        do {                                                            \
                if (_unlikely_(!(expr)))                                \
                        log_assert_failed(#expr, __FILE__, __LINE__, __PRETTY_FUNCTION__); \
        } while (false)
and log_assert_failed() is:
src/shared/log.c.722:

Code: Select all

noreturn void log_assert_failed(const char *text, const char *file, int line, const char *func) {
        log_assert(LOG_CRIT, text, file, line, func, "Assertion '%s' failed at %s:%u, function %s(). Aborting.");
        abort();
}
there are also direct calls to assert_se() - so in such cases even in release buids systemd will call abort()

---------------------------
I'm working with v210 because this is latest "stable" version and I see no point in fixing (or forking) the old one.

---------------------------
Systemd is a multi-threaded and multi process environment - You cant just set a single global flag to indicate that some assertion have failed somewhere - because it is possible that some errors are the effect of other errors in different process or the error can be recovered - it is not a solution to just kill everything what reports an error and quit.
In other words, in such complex situation error "dependancy tracking" is needed and this requires a structurized event system - assert() creates "flat" event structure - the policy is to just quit on any error.

Regards.

ps. in version 210 there is over 5800 calls to assert() and over 2100 direct calls to asser_se()
Odi profanum vulgus

User avatar
edbarx
Posts: 5401
Joined: 2007-07-18 06:19
Location: 35° 50 N, 14 º 35 E
Been thanked: 2 times

Re: Xfce4 default for Jessie? systemd + GNOME + delicious dr

#144 Post by edbarx »

tomazzi wrote:I'm working with v210 because this is latest "stable" version and I see no point in fixing (or forking) the old one.
It means you are already working on a systemd fork. I only offered my "limited" help because I have time to give a little help. If you find anything you think I can help, and my circumstances do not change, I offer my help, however that may not depend solely on you as you may already be working with other developers.
Debian == { > 30, 000 packages }; Debian != systemd
The worst infection of all, is a false sense of security!
It is hard to get away from CLI tools.

tomazzi
Posts: 730
Joined: 2013-08-02 21:33

Re: Xfce4 default for Jessie? systemd + GNOME + delicious dr

#145 Post by tomazzi »

I'm just reading the sources and i've made few experiments in the vm - but that's all for now (I don't have the time).
First thing to do is to decide which event handling system will do the job here and whether it can be implemented in systemd without rewritting it from scratch.

There is a lot of work to do - so any help will be appreciated.

Regards.
Odi profanum vulgus

User avatar
Pelly
Posts: 145
Joined: 2012-11-16 17:49

Re: Xfce4 default for Jessie? systemd + GNOME + delicious dr

#146 Post by Pelly »

Though I'm a KDE user, I use XFCE, too, and I have to say: Squeak!
XFCE should be the default DE in Debian as it's less resource-hungry and more appealing to Winblows refugees saying goodbye to Microshaft than GNOME 3. Especially ex-9x/pre-XP NT users.
(If I posted this to the wrong place, please move it to the desktop debate thread)

User avatar
llivv
Posts: 5340
Joined: 2007-02-14 18:10
Location: cold storage

Re: Xfce4 default for Jessie? systemd + GNOME + delicious dr

#147 Post by llivv »

Pelly wrote: (If I posted this to the wrong place, please move it to the desktop debate thread)
:lol:
looks like "Xfce4 default for Jessie? + GNOME + delicious drama" to me.
only thing missing is the systemd drama which you can fix if and whenever you like.
In memory of Ian Ashley Murdock (1973 - 2015) founder of the Debian project.

User avatar
airborne.rodent
Posts: 8
Joined: 2013-06-04 12:51

Re: Xfce4 default for Jessie? systemd + GNOME + delicious dr

#148 Post by airborne.rodent »

I guess something of a drama has already started, testing got systemd and instantly stopped to properly suspend/hibernate on my laptop. whoa.

vbrummond
Posts: 4432
Joined: 2010-03-02 01:42

Re: Xfce4 default for Jessie? systemd + GNOME + delicious dr

#149 Post by vbrummond »

I am getting sick of cgroups which systemd makes heavy use of. I can't even find good documentation on them. Not to mention the whole "per user", "per service", "per task session" blend of systemd/autogroups. There has to be a performance penalty with all the task insertions.. At least Debian is clever enough to disable autogroups by default. All of this complicated crap is making me really want to leave Linux.
Always on Debian Testing

Bulkley
Posts: 6383
Joined: 2006-02-11 18:35
Has thanked: 2 times
Been thanked: 39 times

Re: Xfce4 default for Jessie? systemd + GNOME + delicious dr

#150 Post by Bulkley »

vbrummond wrote:I am getting sick of cgroups which systemd makes heavy use of. I can't even find good documentation on them. Not to mention the whole "per user", "per service", "per task session" blend of systemd/autogroups. There has to be a performance penalty with all the task insertions.. At least Debian is clever enough to disable autogroups by default. All of this complicated crap is making me really want to leave Linux.
The best problems to have are ones that everyone else has. They get fixed. I remember working on a product that had a circuit board with a 95% failure rate due to overheating. The manufacturers fixed that tout suite. What we don't need is a rare intermittent failure; we will likely end up replacing the product without fixing it.

User avatar
edbarx
Posts: 5401
Joined: 2007-07-18 06:19
Location: 35° 50 N, 14 º 35 E
Been thanked: 2 times

Re: Xfce4 default for Jessie? systemd + GNOME + delicious dr

#151 Post by edbarx »

vbrummond wrote:All of this complicated crap is making me really want to leave Linux.
You are not alone to experience that feeling. The adage "keep it simple, stupid", apparently doesn't apply anymore. :roll: That is why Debianizing systemd should aim at preserving the simplicity and stability Debian is acknowledged with.
Debian == { > 30, 000 packages }; Debian != systemd
The worst infection of all, is a false sense of security!
It is hard to get away from CLI tools.

lucas7
Posts: 8
Joined: 2014-06-07 23:32

Re: Xfce4 default for Jessie? systemd + GNOME + delicious dr

#152 Post by lucas7 »

I'm using Testing. How do I know if systemd is running? It is installed since I guess something I Installed in the past depends on it but how do I know if it is running as my init system as of right now?
edbarx wrote:
vbrummond wrote:All of this complicated crap is making me really want to leave Linux.
You are not alone to experience that feeling. The adage "keep it simple, stupid", apparently doesn't apply anymore. :roll: That is why Debianizing systemd should aim at preserving the simplicity and stability Debian is acknowledged with.
I'll admit I came here from Arch so I don't really hate systemd since it always worked for me. The best thing to do if you're just a user and not directly involved in Debian's development is to not read threads like this... it's the best for your sanity. I don't have the energy to keep up with the fighting... I get physically tired by it. I just ignore these things and hope for the best. (not an easy thing to do if you're really involved in Debian or linux in general though I know.) :|

User avatar
TobiSGD
Posts: 859
Joined: 2010-05-08 22:27
Location: Hannover, Germany

Re: Xfce4 default for Jessie? systemd + GNOME + delicious dr

#153 Post by TobiSGD »

edbarx wrote:
vbrummond wrote:The adage "keep it simple, stupid", apparently doesn't apply anymore. :roll: That is why Debianizing systemd should aim at preserving the simplicity and stability Debian is acknowledged with.
I would guess it depends how you define simple. IMHO, consolidating commands so that you only have to use one command per administration task is making things simpler:
- journalctl for all things logging
- systemctl for all things related to daemons and runlevels
- timedatectl for all things related to time and timezones
- ...

Of course this involves learning new things, but it seems to me that this is indeed simpler than having to remember several commands per administration task.

But of course to each his own.

tomazzi
Posts: 730
Joined: 2013-08-02 21:33

Re: Xfce4 default for Jessie? systemd + GNOME + delicious dr

#154 Post by tomazzi »

TobiSDG: I fully agree with You. (this time)
Perhaps I should say it again: Yes, I know and I agree that Linux needs a service manager - the idea behind the systemd is good, but the implementation is faulty by design - and this is a problem.

If noone will take the effort to fix the code of systemd then it will become the SPOF (Single Point Of Failure) and the main target for attacks.
Two ways are possible: fix systemd or kick it out from Debian - convenience in administrating the system should not be the reason to sacrifice stability and security.

And finally (again): Debian testing is going to be the next stable release, and systemd is not ready for serious deployments - it can exist as an optional package but if it will become the default, it will blow up the stability and as a consequence - the reputation of Debian.

Regards.
Odi profanum vulgus

vbrummond
Posts: 4432
Joined: 2010-03-02 01:42

Re: Xfce4 default for Jessie? systemd + GNOME + delicious dr

#155 Post by vbrummond »

There seems to be some mistake that I am unfamiliar with systemd. Actually for the most part I have no issue being an "end user" of it and have a lot of experience with it. My problem is that parts of it change often, also it being so integrated in the system could be potentially dangerous in the event of a critical bug, and I don't like cgroups. There used to be config options I used to make more sense of my systems resource management but they are deprecated and gone. I am confused when using it how libcgroup, systemd, and autogroups all interact. Do they stack? Are some ignored? This pervasive inclusion of control groups also breaks common unix utilities like nice. I am not a systemd hater, just the direction of Linux in general. I would never go back to Windows or similar. I still recommend Linux.
Always on Debian Testing

Post Reply