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!
Re: Xfce4 default for Jessie? systemd + GNOME + delicious dr
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.
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
Re: Xfce4 default for Jessie? systemd + GNOME + delicious dr
Excuse me if I will say an impossibility but I do programming as a past time although I have tertiary mathematics and science education.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)
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().
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.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.
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.
The worst infection of all, is a false sense of security!
It is hard to get away from CLI tools.
Re: Xfce4 default for Jessie? systemd + GNOME + delicious dr
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?)
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
Re: Xfce4 default for Jessie? systemd + GNOME + delicious dr
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!
Some examples are:
These are the source files for systemd:
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);
....
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.
The worst infection of all, is a false sense of security!
It is hard to get away from CLI tools.
Re: Xfce4 default for Jessie? systemd + GNOME + delicious dr
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.
The worst infection of all, is a false sense of security!
It is hard to get away from CLI tools.
Re: Xfce4 default for Jessie? systemd + GNOME + delicious dr
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.
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
Re: Xfce4 default for Jessie? systemd + GNOME + delicious dr
I think, systemd can be improved by replacing all occurrences of assert by something similar to:
The process doing the system initialization, at every initialization step checks for the value of assert_failed:
Failing processes should also release any allocated memory.
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;
}
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;
}
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.
The worst infection of all, is a false sense of security!
It is hard to get away from CLI tools.
Re: Xfce4 default for Jessie? systemd + GNOME + delicious dr
I was wrong, systemd is using assert() but it is overridden (v210): src/shared/macro.h.164:
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:
and log_assert_failed() is:
src/shared/log.c.722:
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()
Code: Select all
#undef assert
#ifdef NDEBUG
#define assert(expr) do {} while(false)
#else
#define assert(expr) assert_se(expr)
#endif
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)
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();
}
---------------------------
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
Re: Xfce4 default for Jessie? systemd + GNOME + delicious dr
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.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.
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.
The worst infection of all, is a false sense of security!
It is hard to get away from CLI tools.
Re: Xfce4 default for Jessie? systemd + GNOME + delicious dr
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.
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
Re: Xfce4 default for Jessie? systemd + GNOME + delicious dr
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)
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)
Re: Xfce4 default for Jessie? systemd + GNOME + delicious dr
Pelly wrote: (If I posted this to the wrong place, please move it to the desktop debate thread)
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.
- airborne.rodent
- Posts: 8
- Joined: 2013-06-04 12:51
Re: Xfce4 default for Jessie? systemd + GNOME + delicious dr
I guess something of a drama has already started, testing got systemd and instantly stopped to properly suspend/hibernate on my laptop. whoa.
Re: Xfce4 default for Jessie? systemd + GNOME + delicious dr
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
Re: Xfce4 default for Jessie? systemd + GNOME + delicious dr
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.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.
Re: Xfce4 default for Jessie? systemd + GNOME + delicious dr
You are not alone to experience that feeling. The adage "keep it simple, stupid", apparently doesn't apply anymore. That is why Debianizing systemd should aim at preserving the simplicity and stability Debian is acknowledged with.vbrummond wrote:All of this complicated crap is making me really want to leave Linux.
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.
The worst infection of all, is a false sense of security!
It is hard to get away from CLI tools.
Re: Xfce4 default for Jessie? systemd + GNOME + delicious dr
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?
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.)edbarx wrote:You are not alone to experience that feeling. The adage "keep it simple, stupid", apparently doesn't apply anymore. That is why Debianizing systemd should aim at preserving the simplicity and stability Debian is acknowledged with.vbrummond wrote:All of this complicated crap is making me really want to leave Linux.
Re: Xfce4 default for Jessie? systemd + GNOME + delicious dr
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:edbarx wrote:vbrummond wrote:The adage "keep it simple, stupid", apparently doesn't apply anymore. That is why Debianizing systemd should aim at preserving the simplicity and stability Debian is acknowledged with.
- 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.
Re: Xfce4 default for Jessie? systemd + GNOME + delicious dr
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.
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
Re: Xfce4 default for Jessie? systemd + GNOME + delicious dr
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