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
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
Re: Xfce4 default for Jessie? systemd + GNOME + delicious dr
Anyone wanting to see reason, wouldn't resort to saying it depends how you define simple. Usually, politicians do that, but in that case, such a reaction can be understood, because more often than not, they have vested interests.TobiSGD wrote:I would guess it depends how you define simple.edbarx 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.
Last edited by edbarx on 2014-07-01 08:25, edited 1 time in total.
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
Simple = complex "under the hood" code to make it "simple" to the end user / RHEL sysadmin.TobiSGD wrote:I would guess it depends how you define simple.
Simple = programs which do one thing and do it well, simple configuration files in plain text, shell scripts which can be examined, modified as necessary
I believe the end goal of systemd is to provide GUI admin tools (a la windows) and getting rid of rc scripts is one of the primary objectives to achieving this end.
Re: Xfce4 default for Jessie? systemd + GNOME + delicious dr
I find the /etc/rc.conf of freebsd simple enough. With a glance I know the default state of my system, including networking. It boots as fast as Linux or even faster, and I am sure I could optimize it further. I have had it fail because of improper syntax on my part. It just automatically boots to single user mode, I remount my root partition read-write fix the error and boot normally.
Always on Debian Testing
Re: Xfce4 default for Jessie? systemd + GNOME + delicious dr
You might want to have a look at Slackware, Crux or the BSDs.
Re: Xfce4 default for Jessie? systemd + GNOME + delicious dr
I have already looked at Slackware, Crux, and the BSDs. I have been around the block and back again, I am far beyond needing anyone's advice. If I am complaining about something it means I there is probably no good solution. I probably will have to hack one up myself.
Always on Debian Testing