[arch-general] Think twice before moving to systemd
Hi, I just became aware that Arch Linux plans to switch to systemd, and this worries me for several reasons. I tried systemd a while ago in a brand new machine with Arch Linux and the boot was *much slower*. After some exchanges with Lennart Poettering and other people in Google+[1], it became clear I was on my own. Eventually I found the culprit: Fedora uses CONFIG_HZ_1000, and Arch Linux uses CONFIG_HZ_300. It became clear to me that systemd was not ready for prime time, it wasn't thoroughly tested in a lot of machines, and if you have problems Lennart Poettering will blame you (PulseAudio sounds familiar?). systemd was the reason I stopped using Fedora in the first place; when they moved to it my machine stopped booting reliably. My configuration was non-standard (a single encrypted partition), so I guess they never tested that. Similarly, I expect many Arch Linux users to bite these corner-cases. Finally, it's much harder to debug. If you have a problem you will not be able to open a script and figure out what is happening, and perhaps modify it, and debug it. You would be greeted with an unmodified binary, and the source code would be along these lines: http://cgit.freedesktop.org/systemd/systemd/tree/src/remount-fs/remount-fs.c I'm sure in due time systemd will be ready, and will have nice advantages, but I doubt that's the case right now. Has anybody looked into the CONFIG_HZ issue? I doubt that. I was expecting more from the Arch Linux community, something along the lines of Google's analysis to pick to mercurial[2], but so far I have only seen a couple of people saying +1 in the development mailing list, with barely any explanation at all. Such an important move (one that might make users' machines stop booting) should warrant at least an analysis of some sort, with clear advantages. Would it not? At the moment I am unconvinced; does systemd has any *real* advantage? I don't think so; the potential of breakage outweighs the "supposed" advantages, and I think a proper analysis would show that. Cheers. [1] https://plus.google.com/108736516888538655285/posts/BTG39o6YoGS [2] http://code.google.com/p/support/wiki/DVCSAnalysis -- Felipe Contreras
On Tue, Aug 14, 2012 at 9:35 PM, Felipe Contreras < felipe.contreras@gmail.com> wrote:
Hi,
I just became aware that Arch Linux plans to switch to systemd, and this worries me for several reasons.
I tried systemd a while ago in a brand new machine with Arch Linux and the boot was *much slower*. After some exchanges with Lennart Poettering and other people in Google+[1], it became clear I was on my own. Eventually I found the culprit: Fedora uses CONFIG_HZ_1000, and Arch Linux uses CONFIG_HZ_300. It became clear to me that systemd was not ready for prime time, it wasn't thoroughly tested in a lot of machines, and if you have problems Lennart Poettering will blame you (PulseAudio sounds familiar?).
systemd was the reason I stopped using Fedora in the first place; when they moved to it my machine stopped booting reliably. My configuration was non-standard (a single encrypted partition), so I guess they never tested that. Similarly, I expect many Arch Linux users to bite these corner-cases.
Finally, it's much harder to debug. If you have a problem you will not be able to open a script and figure out what is happening, and perhaps modify it, and debug it. You would be greeted with an unmodified binary, and the source code would be along these lines:
http://cgit.freedesktop.org/systemd/systemd/tree/src/remount-fs/remount-fs.c
I'm sure in due time systemd will be ready, and will have nice advantages, but I doubt that's the case right now. Has anybody looked into the CONFIG_HZ issue? I doubt that.
I was expecting more from the Arch Linux community, something along the lines of Google's analysis to pick to mercurial[2], but so far I have only seen a couple of people saying +1 in the development mailing list, with barely any explanation at all. Such an important move (one that might make users' machines stop booting) should warrant at least an analysis of some sort, with clear advantages. Would it not?
At the moment I am unconvinced; does systemd has any *real* advantage? I don't think so; the potential of breakage outweighs the "supposed" advantages, and I think a proper analysis would show that.
Cheers.
[1] https://plus.google.com/108736516888538655285/posts/BTG39o6YoGS [2] http://code.google.com/p/support/wiki/DVCSAnalysis
-- Felipe Contreras
I haven't had this issue at all, and so far the systemd developers have been very accommodating to the arch developers
On 15/08/12 at 03:35am, Felipe Contreras wrote:
Hi,
I just became aware that Arch Linux plans to switch to systemd, and this worries me for several reasons.
snip
I am running it on both my home machines and my work laptop. I have full encryption on all three devices and LVM and Raid1 on two of them. Boot time is not considerably faster, but shutdown is. I have not had any problems migrating or running the three machines in the intervening fortnight. I think your concerns are largely unfounded and your alarmist tone does no credit to the Arch developers who have given this some consideration and have implemented it in a typically thorough and professional manner. /J -- http://jasonwryan.com/ [GnuPG Key: B1BD4E40]
On Wed, Aug 15, 2012 at 3:51 AM, Jason Ryan <jasonwryan@gmail.com> wrote:
On 15/08/12 at 03:35am, Felipe Contreras wrote:
I just became aware that Arch Linux plans to switch to systemd, and this worries me for several reasons.
snip
I am running it on both my home machines and my work laptop. I have full encryption on all three devices and LVM and Raid1 on two of them. Boot time is not considerably faster, but shutdown is.
I have not had any problems migrating or running the three machines in the intervening fortnight.
So you have 3 data-points. There's plenty of different machines and configurations out there, and the way you present your arguments seems to suggest that because you didn't have any problems, that proves that nobody out there can *possibly* have issues with systemd. I believe the opposite; even if you have tested in one thousand machines, the *possibility* still remains.
I think your concerns are largely unfounded and your alarmist tone does no credit to the Arch developers who have given this some consideration and have implemented it in a typically thorough and professional manner.
I tend to not believe things without evidence, and not believe because of some "authority" says it's true. I will believe there was some careful analysis, when I see the result of the analysis in a summarized form as the Google DVCS analysis. If the benefits are well known, and the disadvantages minded, it shouldn't be difficult to write such a summary. Would it? Cheers. -- Felipe Contreras
On 15/08/12 at 04:01am, Felipe Contreras wrote:
On Wed, Aug 15, 2012 at 3:51 AM, Jason Ryan <jasonwryan@gmail.com> wrote:
On 15/08/12 at 03:35am, Felipe Contreras wrote:
I just became aware that Arch Linux plans to switch to systemd, and this worries me for several reasons.
snip
I am running it on both my home machines and my work laptop. I have full encryption on all three devices and LVM and Raid1 on two of them. Boot time is not considerably faster, but shutdown is.
I have not had any problems migrating or running the three machines in the intervening fortnight.
So you have 3 data-points. There's plenty of different machines and configurations out there, and the way you present your arguments seems to suggest that because you didn't have any problems, that proves that nobody out there can *possibly* have issues with systemd.
No - I made no such overarching claims; I just countered your experience with my own.
I believe the opposite; even if you have tested in one thousand machines, the *possibility* still remains.
Yes, the possibility exists; that is hardly a reason to spread FUD on the list though, is it?
I think your concerns are largely unfounded and your alarmist tone does no credit to the Arch developers who have given this some consideration and have implemented it in a typically thorough and professional manner.
I tend to not believe things without evidence, and not believe because of some "authority" says it's true. I will believe there was some careful analysis, when I see the result of the analysis in a summarized form as the Google DVCS analysis. If the benefits are well known, and the disadvantages minded, it shouldn't be difficult to write such a summary. Would it?
I look forward to your analysis (which by your own criteria will need to include
1000 machines, presumably); or are you expecting someone else will do this to satisfy your demands for scientific rigour?
/J -- http://jasonwryan.com/ [GnuPG Key: B1BD4E40]
On Wed, Aug 15, 2012 at 4:40 AM, Jason Ryan <jasonwryan@gmail.com> wrote:
On 15/08/12 at 04:01am, Felipe Contreras wrote:
On Wed, Aug 15, 2012 at 3:51 AM, Jason Ryan <jasonwryan@gmail.com> wrote:
On 15/08/12 at 03:35am, Felipe Contreras wrote:
I just became aware that Arch Linux plans to switch to systemd, and this worries me for several reasons.
snip
I am running it on both my home machines and my work laptop. I have full encryption on all three devices and LVM and Raid1 on two of them. Boot time is not considerably faster, but shutdown is.
I have not had any problems migrating or running the three machines in the intervening fortnight.
So you have 3 data-points. There's plenty of different machines and configurations out there, and the way you present your arguments seems to suggest that because you didn't have any problems, that proves that nobody out there can *possibly* have issues with systemd.
No - I made no such overarching claims; I just countered your experience with my own.
I see, but that is irrelevant. Yo only need one data-point to prove a positive, and it's impossible to prove a negative.
I believe the opposite; even if you have tested in one thousand machines, the *possibility* still remains.
Yes, the possibility exists; that is hardly a reason to spread FUD on the list though, is it?
So I think Arch Linux will probably hit issues, and you think it's FUD to say "hey Arch Linux, I think you might hit issues"?
I think your concerns are largely unfounded and your alarmist tone does no credit to the Arch developers who have given this some consideration and have implemented it in a typically thorough and professional manner.
I tend to not believe things without evidence, and not believe because of some "authority" says it's true. I will believe there was some careful analysis, when I see the result of the analysis in a summarized form as the Google DVCS analysis. If the benefits are well known, and the disadvantages minded, it shouldn't be difficult to write such a summary. Would it?
I look forward to your analysis (which by your own criteria will need to include
1000 machines, presumably); or are you expecting someone else will do this to satisfy your demands for scientific rigour?
Why should I do the analysis? Are you saying that Arch Linux developers didn't do any analysis? Surely they did, it's just not summarized and publicized. And no, you don't need to test 1000 machines to make an analysis. Cheers. -- Felipe Contreras
On 15/08/12 at 08:38am, Felipe Contreras wrote:
On Wed, Aug 15, 2012 at 4:40 AM, Jason Ryan <jasonwryan@gmail.com> wrote:
On 15/08/12 at 04:01am, Felipe Contreras wrote:
On Wed, Aug 15, 2012 at 3:51 AM, Jason Ryan <jasonwryan@gmail.com> wrote:
On 15/08/12 at 03:35am, Felipe Contreras wrote:
I just became aware that Arch Linux plans to switch to systemd, and this worries me for several reasons.
snip
I am running it on both my home machines and my work laptop. I have full encryption on all three devices and LVM and Raid1 on two of them. Boot time is not considerably faster, but shutdown is.
I have not had any problems migrating or running the three machines in the intervening fortnight.
So you have 3 data-points. There's plenty of different machines and configurations out there, and the way you present your arguments seems to suggest that because you didn't have any problems, that proves that nobody out there can *possibly* have issues with systemd.
No - I made no such overarching claims; I just countered your experience with my own.
I see, but that is irrelevant. Yo only need one data-point to prove a positive, and it's impossible to prove a negative.
I believe the opposite; even if you have tested in one thousand machines, the *possibility* still remains.
Yes, the possibility exists; that is hardly a reason to spread FUD on the list though, is it?
So I think Arch Linux will probably hit issues, and you think it's FUD to say "hey Arch Linux, I think you might hit issues"?
You have “issues”. Your thread title, your baseless extrapolation of your own experience to all of Arch are classic FUD.[0]
I think your concerns are largely unfounded and your alarmist tone does no credit to the Arch developers who have given this some consideration and have implemented it in a typically thorough and professional manner.
I tend to not believe things without evidence, and not believe because of some "authority" says it's true. I will believe there was some careful analysis, when I see the result of the analysis in a summarized form as the Google DVCS analysis. If the benefits are well known, and the disadvantages minded, it shouldn't be difficult to write such a summary. Would it?
I look forward to your analysis (which by your own criteria will need to include
1000 machines, presumably); or are you expecting someone else will do this to satisfy your demands for scientific rigour?
Why should I do the analysis? Are you saying that Arch Linux developers didn't do any analysis? Surely they did, it's just not summarized and publicized.
Please don't attempt to put words into my mouth; it is (more) classic trolling.[1] 0. http://yourlogicalfallacyis.com/burden-of-proof 1. http://yourlogicalfallacyis.com/strawman -- http://jasonwryan.com/ [GnuPG Key: B1BD4E40]
So I think Arch Linux will probably hit issues, and you think it's FUD to say "hey Arch Linux, I think you might hit issues"?
You have “issues”. Your thread title, your baseless extrapolation of your own experience to all of Arch are classic FUD.[0]
If you look in a dictionary often a term will have many definitions. One for FUD would likely be "a term often used by some to dismiss valid concerns offhand". You haven't added anything, such as many of the pro systemd posts. -- _______________________________________________________________________ 'Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface' (Doug McIlroy) _______________________________________________________________________
On Tue, Aug 14, 2012 at 10:35 PM, Felipe Contreras <felipe.contreras@gmail.com> wrote:
Hi,
I'm sure in due time systemd will be ready, and will have nice advantages, but I doubt that's the case right now. Has anybody looked into the CONFIG_HZ issue? I doubt that.
Arch's stock kernel: $ zgrep CONFIG_HZ /proc/config.gz # CONFIG_HZ_100 is not set # CONFIG_HZ_250 is not set CONFIG_HZ_300=y # CONFIG_HZ_1000 is not set CONFIG_HZ=300 Systemd is working fine enough. A counter example shoud invalidate your argument that CONFIG_HZ is the culprit. -- A: Because it obfuscates the reading. Q: Why is top posting so bad? For more information, please read: http://idallen.com/topposting.html ------------------------------------------- Denis A. Altoe Falqueto Linux user #524555 -------------------------------------------
On Wed, Aug 15, 2012 at 12:17 AM, Denis A. Altoé Falqueto <denisfalqueto@gmail.com> wrote:
On Tue, Aug 14, 2012 at 10:35 PM, Felipe Contreras <felipe.contreras@gmail.com> wrote:
Hi,
I'm sure in due time systemd will be ready, and will have nice advantages, but I doubt that's the case right now. Has anybody looked into the CONFIG_HZ issue? I doubt that.
Arch's stock kernel:
$ zgrep CONFIG_HZ /proc/config.gz # CONFIG_HZ_100 is not set # CONFIG_HZ_250 is not set CONFIG_HZ_300=y # CONFIG_HZ_1000 is not set CONFIG_HZ=300
Systemd is working fine enough. A counter example shoud invalidate your argument that CONFIG_HZ is the culprit.
This can also really help you debug your problem: http://0pointer.de/blog/projects/self-documented-boot.html -- A: Because it obfuscates the reading. Q: Why is top posting so bad? For more information, please read: http://idallen.com/topposting.html ------------------------------------------- Denis A. Altoe Falqueto Linux user #524555 -------------------------------------------
On Wed, Aug 15, 2012 at 5:17 AM, Denis A. Altoé Falqueto <denisfalqueto@gmail.com> wrote:
On Tue, Aug 14, 2012 at 10:35 PM, Felipe Contreras <felipe.contreras@gmail.com> wrote:
Hi,
I'm sure in due time systemd will be ready, and will have nice advantages, but I doubt that's the case right now. Has anybody looked into the CONFIG_HZ issue? I doubt that.
Arch's stock kernel:
$ zgrep CONFIG_HZ /proc/config.gz # CONFIG_HZ_100 is not set # CONFIG_HZ_250 is not set CONFIG_HZ_300=y # CONFIG_HZ_1000 is not set CONFIG_HZ=300
Systemd is working fine enough. A counter example shoud invalidate your argument that CONFIG_HZ is the culprit.
That doesn't prove anything, your machine is not my machine. -- Felipe Contreras
On Wed, Aug 15, 2012 at 3:39 AM, Felipe Contreras <felipe.contreras@gmail.com> wrote:
On Wed, Aug 15, 2012 at 5:17 AM, Denis A. Altoé Falqueto <denisfalqueto@gmail.com> wrote:
On Tue, Aug 14, 2012 at 10:35 PM, Felipe Contreras <felipe.contreras@gmail.com> wrote:
Hi,
I'm sure in due time systemd will be ready, and will have nice advantages, but I doubt that's the case right now. Has anybody looked into the CONFIG_HZ issue? I doubt that.
Arch's stock kernel:
$ zgrep CONFIG_HZ /proc/config.gz # CONFIG_HZ_100 is not set # CONFIG_HZ_250 is not set CONFIG_HZ_300=y # CONFIG_HZ_1000 is not set CONFIG_HZ=300
Systemd is working fine enough. A counter example shoud invalidate your argument that CONFIG_HZ is the culprit.
That doesn't prove anything, your machine is not my machine.
And you dare to call for scientific process? Your arguments are general and your test universe is your machine? Oh, please. -- A: Because it obfuscates the reading. Q: Why is top posting so bad? For more information, please read: http://idallen.com/topposting.html ------------------------------------------- Denis A. Altoe Falqueto Linux user #524555 -------------------------------------------
On Wed, Aug 15, 2012 at 6:53 PM, Denis A. Altoé Falqueto <denisfalqueto@gmail.com> wrote:
On Wed, Aug 15, 2012 at 3:39 AM, Felipe Contreras <felipe.contreras@gmail.com> wrote:
On Wed, Aug 15, 2012 at 5:17 AM, Denis A. Altoé Falqueto <denisfalqueto@gmail.com> wrote:
On Tue, Aug 14, 2012 at 10:35 PM, Felipe Contreras <felipe.contreras@gmail.com> wrote:
Hi,
I'm sure in due time systemd will be ready, and will have nice advantages, but I doubt that's the case right now. Has anybody looked into the CONFIG_HZ issue? I doubt that.
Arch's stock kernel:
$ zgrep CONFIG_HZ /proc/config.gz # CONFIG_HZ_100 is not set # CONFIG_HZ_250 is not set CONFIG_HZ_300=y # CONFIG_HZ_1000 is not set CONFIG_HZ=300
Systemd is working fine enough. A counter example shoud invalidate your argument that CONFIG_HZ is the culprit.
That doesn't prove anything, your machine is not my machine.
And you dare to call for scientific process? Your arguments are general and your test universe is your machine? Oh, please.
When you make a claim such as "this change won't introduce any regressions" the evidence of "it works in my machine" isn't *proof* of any kind. If you have worked in any serious project you would know that (as many changes work on particular machines, and break in others). And if you know anything of the scientific process you would also know that "it works in my machine" isn't *proof* of any kind; my machine detects neutrinos travel faster than light, is that proof of anything? No. And this goes back to basics of rationality: you can't prove a negative, so it doesn't matter how many data-points of something not happening you have, and all you need is a positive data-point to show that something does indeed exist (or at least it's as likely as the possibility of that data-point being in fact true). I'm not going to explain this again. Either you get it or you don't. Cheers. -- Felipe Contreras
On Wed, Aug 15, 2012 at 2:51 PM, Felipe Contreras <felipe.contreras@gmail.com> wrote:
On Wed, Aug 15, 2012 at 6:53 PM, Denis A. Altoé Falqueto <denisfalqueto@gmail.com> wrote:
On Wed, Aug 15, 2012 at 3:39 AM, Felipe Contreras <felipe.contreras@gmail.com> wrote:
On Wed, Aug 15, 2012 at 5:17 AM, Denis A. Altoé Falqueto <denisfalqueto@gmail.com> wrote:
On Tue, Aug 14, 2012 at 10:35 PM, Felipe Contreras <felipe.contreras@gmail.com> wrote:
Hi,
I'm sure in due time systemd will be ready, and will have nice advantages, but I doubt that's the case right now. Has anybody looked into the CONFIG_HZ issue? I doubt that.
Arch's stock kernel:
$ zgrep CONFIG_HZ /proc/config.gz # CONFIG_HZ_100 is not set # CONFIG_HZ_250 is not set CONFIG_HZ_300=y # CONFIG_HZ_1000 is not set CONFIG_HZ=300
Systemd is working fine enough. A counter example shoud invalidate your argument that CONFIG_HZ is the culprit.
That doesn't prove anything, your machine is not my machine.
And you dare to call for scientific process? Your arguments are general and your test universe is your machine? Oh, please.
When you make a claim such as "this change won't introduce any regressions" the evidence of "it works in my machine" isn't *proof* of any kind. If you have worked in any serious project you would know that (as many changes work on particular machines, and break in others). And if you know anything of the scientific process you would also know that "it works in my machine" isn't *proof* of any kind; my machine detects neutrinos travel faster than light, is that proof of anything? No. And this goes back to basics of rationality: you can't prove a negative, so it doesn't matter how many data-points of something not happening you have, and all you need is a positive data-point to show that something does indeed exist (or at least it's as likely as the possibility of that data-point being in fact true).
I'm not going to explain this again. Either you get it or you don't.
This is so stupid that it's not even funny. You said that the problem was having CONFIG_HZ=300 and systemd. I said it is not, because I also have that situation and it works. So, your point is moot. I didn't say you don't have a problem, but just that it may be not related to CONFIG_HZ. I even sent you an article with ways on how to inspect the behaviour of systemd, which was completely ignored. Really, arch-general is not the same as before, and _that_ is the real problem. -- A: Because it obfuscates the reading. Q: Why is top posting so bad? For more information, please read: http://idallen.com/topposting.html ------------------------------------------- Denis A. Altoe Falqueto Linux user #524555 -------------------------------------------
On Wed, Aug 15, 2012 at 7:58 PM, Denis A. Altoé Falqueto <denisfalqueto@gmail.com> wrote:
On Wed, Aug 15, 2012 at 2:51 PM, Felipe Contreras <felipe.contreras@gmail.com> wrote:
On Wed, Aug 15, 2012 at 6:53 PM, Denis A. Altoé Falqueto <denisfalqueto@gmail.com> wrote:
On Wed, Aug 15, 2012 at 3:39 AM, Felipe Contreras <felipe.contreras@gmail.com> wrote:
On Wed, Aug 15, 2012 at 5:17 AM, Denis A. Altoé Falqueto <denisfalqueto@gmail.com> wrote:
On Tue, Aug 14, 2012 at 10:35 PM, Felipe Contreras <felipe.contreras@gmail.com> wrote:
Hi,
I'm sure in due time systemd will be ready, and will have nice advantages, but I doubt that's the case right now. Has anybody looked into the CONFIG_HZ issue? I doubt that.
Arch's stock kernel:
$ zgrep CONFIG_HZ /proc/config.gz # CONFIG_HZ_100 is not set # CONFIG_HZ_250 is not set CONFIG_HZ_300=y # CONFIG_HZ_1000 is not set CONFIG_HZ=300
Systemd is working fine enough. A counter example shoud invalidate your argument that CONFIG_HZ is the culprit.
That doesn't prove anything, your machine is not my machine.
And you dare to call for scientific process? Your arguments are general and your test universe is your machine? Oh, please.
When you make a claim such as "this change won't introduce any regressions" the evidence of "it works in my machine" isn't *proof* of any kind. If you have worked in any serious project you would know that (as many changes work on particular machines, and break in others). And if you know anything of the scientific process you would also know that "it works in my machine" isn't *proof* of any kind; my machine detects neutrinos travel faster than light, is that proof of anything? No. And this goes back to basics of rationality: you can't prove a negative, so it doesn't matter how many data-points of something not happening you have, and all you need is a positive data-point to show that something does indeed exist (or at least it's as likely as the possibility of that data-point being in fact true).
I'm not going to explain this again. Either you get it or you don't.
This is so stupid that it's not even funny. You said that the problem was having CONFIG_HZ=300 and systemd. I said it is not, because I also have that situation and it works. So, your point is moot. I didn't say you don't have a problem, but just that it may be not related to CONFIG_HZ. I even sent you an article with ways on how to inspect the behaviour of systemd, which was completely ignored.
Really, arch-general is not the same as before, and _that_ is the real problem.
No. You clearly don't understand how epistemology works, and I'm not going to explain it to you. My problem with CONFIG_HZ exists independently of whether you experience the problem yourself or not. Cheers. -- Felipe Contreras
On 16 August 2012 15:16, Felipe Contreras <felipe.contreras@gmail.com> wrote:
My problem with CONFIG_HZ exists independently of whether you experience the problem yourself or not.
I guess you've reported it to kernel devs, right...?
On Thu, Aug 16, 2012 at 3:19 PM, Alexandre Ferrando <alferpal@gmail.com> wrote:
On 16 August 2012 15:16, Felipe Contreras <felipe.contreras@gmail.com> wrote:
My problem with CONFIG_HZ exists independently of whether you experience the problem yourself or not.
I guess you've reported it to kernel devs, right...?
Why would I? It's a bug in systemd. -- Felipe Contreras
On 16 August 2012 15:27, Felipe Contreras <felipe.contreras@gmail.com> wrote:
On Thu, Aug 16, 2012 at 3:19 PM, Alexandre Ferrando <alferpal@gmail.com> wrote:
On 16 August 2012 15:16, Felipe Contreras <felipe.contreras@gmail.com> wrote:
My problem with CONFIG_HZ exists independently of whether you experience the problem yourself or not.
I guess you've reported it to kernel devs, right...?
Why would I? It's a bug in systemd.
Well, then change "kernel devs" by "systemd devs" or "whatever software devs" in that question. And why report it? Because of getting that issue solved, maybe? Just saying. But go on and continue with all the trolling and whining and not reporting issues
On Thu, 16 Aug 2012 15:16:31 +0200 Felipe Contreras <felipe.contreras@gmail.com> wrote:
On Wed, Aug 15, 2012 at 7:58 PM, Denis A. Altoé Falqueto <denisfalqueto@gmail.com> wrote:
This is so stupid that it's not even funny. You said that the problem was having CONFIG_HZ=300 and systemd. I said it is not, because I also have that situation and it works. So, your point is moot. I didn't say you don't have a problem, but just that it may be not related to CONFIG_HZ. I even sent you an article with ways on how to inspect the behaviour of systemd, which was completely ignored.
My problem with CONFIG_HZ exists independently of whether you experience the problem yourself or not.
But it suggests that the problem is not *just* systemd and CONFIG_HZ=300. I am, and many others are, running systemd with CONFIG_HZ=300 fine. If you encountered a problem, there must be some other underlying cause. A constructive response would work towards finding and addressing the other underlying cause.
No. You clearly don't understand how epistemology works, and I'm not going to explain it to you.
irony of ironies... -- John K Pate http://jkpate.net/ The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336.
On Thu, Aug 16, 2012 at 4:08 PM, John K Pate <j.k.pate@sms.ed.ac.uk> wrote:
On Thu, 16 Aug 2012 15:16:31 +0200 Felipe Contreras <felipe.contreras@gmail.com> wrote:
On Wed, Aug 15, 2012 at 7:58 PM, Denis A. Altoé Falqueto <denisfalqueto@gmail.com> wrote:
This is so stupid that it's not even funny. You said that the problem was having CONFIG_HZ=300 and systemd. I said it is not, because I also have that situation and it works. So, your point is moot. I didn't say you don't have a problem, but just that it may be not related to CONFIG_HZ. I even sent you an article with ways on how to inspect the behaviour of systemd, which was completely ignored.
My problem with CONFIG_HZ exists independently of whether you experience the problem yourself or not.
But it suggests that the problem is not *just* systemd and CONFIG_HZ=300. I am, and many others are, running systemd with CONFIG_HZ=300 fine.
Show me two bootcharts, one with CONFIG_HZ_300=y, and another with CONFIG_HZ_1000=y. Then I will believe that you are running systemd fine. The other possibility is that you are just not noticing the problem.
If you encountered a problem, there must be some other underlying cause. A constructive response would work towards finding and addressing the other underlying cause.
A logical reason would be that systemd is too sensitive on signals arriving fast, and if that's the case it's quite likely that there is no easy solution (if any). But anyway, my objective is not to improve systemd (I might have tried that if Lennart wasn't such an asshole), my objective is to show that systemd has problems, and CONFIG_HZ_300=y is just an example... there are other issues popping in arch-general that render the system unbootable. Perhaps in the future I will have time to investigate the issue, and make a proper bug report, and systemd would work properly for me, and most Arch Linux users, but I believe that's not the case *currently*. So I believe the logical course of action is to delay the migration until systemd is more robust. All I want is to minimize the issues that Arch Linux users hit, but unfortunately so far it seems Arch Linux developers don't care about how many problems could this move cause. Cheers. -- Felipe Contreras
On Thu, Aug 16, 2012 at 4:54 PM, Felipe Contreras < felipe.contreras@gmail.com> wrote:
On Thu, Aug 16, 2012 at 4:08 PM, John K Pate <j.k.pate@sms.ed.ac.uk> wrote:
On Thu, 16 Aug 2012 15:16:31 +0200 Felipe Contreras <felipe.contreras@gmail.com> wrote:
On Wed, Aug 15, 2012 at 7:58 PM, Denis A. Altoé Falqueto <denisfalqueto@gmail.com> wrote:
This is so stupid that it's not even funny. You said that the problem was having CONFIG_HZ=300 and systemd. I said it is not, because I also have that situation and it works. So, your point is moot. I didn't say you don't have a problem, but just that it may be not related to CONFIG_HZ. I even sent you an article with ways on how to inspect the behaviour of systemd, which was completely ignored.
My problem with CONFIG_HZ exists independently of whether you experience the problem yourself or not.
But it suggests that the problem is not *just* systemd and CONFIG_HZ=300. I am, and many others are, running systemd with CONFIG_HZ=300 fine.
Show me two bootcharts, one with CONFIG_HZ_300=y, and another with CONFIG_HZ_1000=y. Then I will believe that you are running systemd fine. The other possibility is that you are just not noticing the problem.
If you encountered a problem, there must be some other underlying cause. A constructive response would work towards finding and addressing the other underlying cause.
A logical reason would be that systemd is too sensitive on signals arriving fast, and if that's the case it's quite likely that there is no easy solution (if any).
But anyway, my objective is not to improve systemd (I might have tried that if Lennart wasn't such an asshole), my objective is to show that systemd has problems, and CONFIG_HZ_300=y is just an example... there are other issues popping in arch-general that render the system unbootable.
Perhaps in the future I will have time to investigate the issue, and make a proper bug report, and systemd would work properly for me, and most Arch Linux users, but I believe that's not the case *currently*.
So I believe the logical course of action is to delay the migration until systemd is more robust.
All I want is to minimize the issues that Arch Linux users hit, but unfortunately so far it seems Arch Linux developers don't care about how many problems could this move cause.
Cheers.
-- Felipe Contreras
So far it seems you are the only one with this "issue" and you haven't reported any bugs, so I don't see what you hope to accomplish
A better solution would be for you to reinstall with a clean pure install, then install systemd, and see if you run into the same solution which I bet you won't, I'm calling pebkac and ID-107 until you've used systemd on a pure install. if 9.999999/10 users have no issue with a default systemd install then the problem exists between the keyboard and the computer. On Thu, Aug 16, 2012 at 4:54 PM, Felipe Contreras < felipe.contreras@gmail.com> wrote:
On Thu, Aug 16, 2012 at 4:08 PM, John K Pate <j.k.pate@sms.ed.ac.uk> wrote:
On Thu, 16 Aug 2012 15:16:31 +0200 Felipe Contreras <felipe.contreras@gmail.com> wrote:
On Wed, Aug 15, 2012 at 7:58 PM, Denis A. Altoé Falqueto <denisfalqueto@gmail.com> wrote:
This is so stupid that it's not even funny. You said that the problem was having CONFIG_HZ=300 and systemd. I said it is not, because I also have that situation and it works. So, your point is moot. I didn't say you don't have a problem, but just that it may be not related to CONFIG_HZ. I even sent you an article with ways on how to inspect the behaviour of systemd, which was completely ignored.
My problem with CONFIG_HZ exists independently of whether you experience the problem yourself or not.
But it suggests that the problem is not *just* systemd and CONFIG_HZ=300. I am, and many others are, running systemd with CONFIG_HZ=300 fine.
Show me two bootcharts, one with CONFIG_HZ_300=y, and another with CONFIG_HZ_1000=y. Then I will believe that you are running systemd fine. The other possibility is that you are just not noticing the problem.
If you encountered a problem, there must be some other underlying cause. A constructive response would work towards finding and addressing the other underlying cause.
A logical reason would be that systemd is too sensitive on signals arriving fast, and if that's the case it's quite likely that there is no easy solution (if any).
But anyway, my objective is not to improve systemd (I might have tried that if Lennart wasn't such an asshole), my objective is to show that systemd has problems, and CONFIG_HZ_300=y is just an example... there are other issues popping in arch-general that render the system unbootable.
Perhaps in the future I will have time to investigate the issue, and make a proper bug report, and systemd would work properly for me, and most Arch Linux users, but I believe that's not the case *currently*.
So I believe the logical course of action is to delay the migration until systemd is more robust.
All I want is to minimize the issues that Arch Linux users hit, but unfortunately so far it seems Arch Linux developers don't care about how many problems could this move cause.
Cheers.
-- Felipe Contreras
On Aug 16, 2012 10:04 PM, "Justin Strickland" <azriel.kiten@gmail.com> wrote:
A better solution would be for you to reinstall with a clean pure
install,
then install systemd, and see if you run into the same solution which I bet you won't, I'm calling pebkac and ID-107 until you've used systemd on a pure install. if 9.999999/10 users have no issue with a default systemd install then the problem exists between the keyboard and the computer.
On Thu, Aug 16, 2012 at 4:54 PM, Felipe Contreras < felipe.contreras@gmail.com> wrote:
On Thu, Aug 16, 2012 at 4:08 PM, John K Pate <j.k.pate@sms.ed.ac.uk> wrote:
On Thu, 16 Aug 2012 15:16:31 +0200 Felipe Contreras <felipe.contreras@gmail.com> wrote:
On Wed, Aug 15, 2012 at 7:58 PM, Denis A. Altoé Falqueto <denisfalqueto@gmail.com> wrote:
This is so stupid that it's not even funny. You said that the problem was having CONFIG_HZ=300 and systemd. I said it is not, because I also have that situation and it works. So, your point is moot. I didn't say you don't have a problem, but just that it may be not related to CONFIG_HZ. I even sent you an article with ways on how to inspect the behaviour of systemd, which was completely ignored.
My problem with CONFIG_HZ exists independently of whether you experience the problem yourself or not.
But it suggests that the problem is not *just* systemd and CONFIG_HZ=300. I am, and many others are, running systemd with CONFIG_HZ=300 fine.
Show me two bootcharts, one with CONFIG_HZ_300=y, and another with CONFIG_HZ_1000=y. Then I will believe that you are running systemd fine. The other possibility is that you are just not noticing the problem.
If you encountered a problem, there must be some other underlying cause. A constructive response would work towards finding and addressing the other underlying cause.
A logical reason would be that systemd is too sensitive on signals arriving fast, and if that's the case it's quite likely that there is no easy solution (if any).
But anyway, my objective is not to improve systemd (I might have tried that if Lennart wasn't such an asshole), my objective is to show that systemd has problems, and CONFIG_HZ_300=y is just an example... there are other issues popping in arch-general that render the system unbootable.
Perhaps in the future I will have time to investigate the issue, and make a proper bug report, and systemd would work properly for me, and most Arch Linux users, but I believe that's not the case *currently*.
So I believe the logical course of action is to delay the migration until systemd is more robust.
All I want is to minimize the issues that Arch Linux users hit, but unfortunately so far it seems Arch Linux developers don't care about how many problems could this move cause.
Cheers.
-- Felipe Contreras
2 things top posting and no matter how much of an ass someone may or may not be no need for personal attacks
wasn't attacking him personally, I simply meant to state there is most likely an issue with his configuration and thus he should check a pure systemd install be for spamming the ML with his inexperience, granted the dev may or may not be a douche but thats still no execuse for not exhausting all possibilities On Thu, Aug 16, 2012 at 11:21 PM, Nicholas MIller <nick.kyky@gmail.com>wrote:
On Aug 16, 2012 10:04 PM, "Justin Strickland" <azriel.kiten@gmail.com> wrote:
A better solution would be for you to reinstall with a clean pure
install,
then install systemd, and see if you run into the same solution which I bet you won't, I'm calling pebkac and ID-107 until you've used systemd on a pure install. if 9.999999/10 users have no issue with a default systemd install then the problem exists between the keyboard and the computer.
On Thu, Aug 16, 2012 at 4:54 PM, Felipe Contreras < felipe.contreras@gmail.com> wrote:
On Thu, Aug 16, 2012 at 4:08 PM, John K Pate <j.k.pate@sms.ed.ac.uk> wrote:
On Thu, 16 Aug 2012 15:16:31 +0200 Felipe Contreras <felipe.contreras@gmail.com> wrote:
On Wed, Aug 15, 2012 at 7:58 PM, Denis A. Altoé Falqueto <denisfalqueto@gmail.com> wrote:
This is so stupid that it's not even funny. You said that the problem was having CONFIG_HZ=300 and systemd. I said it is not, because I also have that situation and it works. So, your point is moot. I didn't say you don't have a problem, but just that it may be not related to CONFIG_HZ. I even sent you an article with ways on how to inspect the behaviour of systemd, which was completely ignored.
My problem with CONFIG_HZ exists independently of whether you experience the problem yourself or not.
But it suggests that the problem is not *just* systemd and CONFIG_HZ=300. I am, and many others are, running systemd with CONFIG_HZ=300 fine.
Show me two bootcharts, one with CONFIG_HZ_300=y, and another with CONFIG_HZ_1000=y. Then I will believe that you are running systemd fine. The other possibility is that you are just not noticing the problem.
If you encountered a problem, there must be some other underlying cause. A constructive response would work towards finding and addressing the other underlying cause.
A logical reason would be that systemd is too sensitive on signals arriving fast, and if that's the case it's quite likely that there is no easy solution (if any).
But anyway, my objective is not to improve systemd (I might have tried that if Lennart wasn't such an asshole), my objective is to show that systemd has problems, and CONFIG_HZ_300=y is just an example... there are other issues popping in arch-general that render the system unbootable.
Perhaps in the future I will have time to investigate the issue, and make a proper bug report, and systemd would work properly for me, and most Arch Linux users, but I believe that's not the case *currently*.
So I believe the logical course of action is to delay the migration until systemd is more robust.
All I want is to minimize the issues that Arch Linux users hit, but unfortunately so far it seems Arch Linux developers don't care about how many problems could this move cause.
Cheers.
-- Felipe Contreras
2 things top posting and no matter how much of an ass someone may or may not be no need for personal attacks
also I may or may not have hit reply to on you nicholas if so I wasn't directing that earlier comment towards you On Thu, Aug 16, 2012 at 11:21 PM, Nicholas MIller <nick.kyky@gmail.com>wrote:
On Aug 16, 2012 10:04 PM, "Justin Strickland" <azriel.kiten@gmail.com> wrote:
A better solution would be for you to reinstall with a clean pure
install,
then install systemd, and see if you run into the same solution which I bet you won't, I'm calling pebkac and ID-107 until you've used systemd on a pure install. if 9.999999/10 users have no issue with a default systemd install then the problem exists between the keyboard and the computer.
On Thu, Aug 16, 2012 at 4:54 PM, Felipe Contreras < felipe.contreras@gmail.com> wrote:
On Thu, Aug 16, 2012 at 4:08 PM, John K Pate <j.k.pate@sms.ed.ac.uk> wrote:
On Thu, 16 Aug 2012 15:16:31 +0200 Felipe Contreras <felipe.contreras@gmail.com> wrote:
On Wed, Aug 15, 2012 at 7:58 PM, Denis A. Altoé Falqueto <denisfalqueto@gmail.com> wrote:
This is so stupid that it's not even funny. You said that the problem was having CONFIG_HZ=300 and systemd. I said it is not, because I also have that situation and it works. So, your point is moot. I didn't say you don't have a problem, but just that it may be not related to CONFIG_HZ. I even sent you an article with ways on how to inspect the behaviour of systemd, which was completely ignored.
My problem with CONFIG_HZ exists independently of whether you experience the problem yourself or not.
But it suggests that the problem is not *just* systemd and CONFIG_HZ=300. I am, and many others are, running systemd with CONFIG_HZ=300 fine.
Show me two bootcharts, one with CONFIG_HZ_300=y, and another with CONFIG_HZ_1000=y. Then I will believe that you are running systemd fine. The other possibility is that you are just not noticing the problem.
If you encountered a problem, there must be some other underlying cause. A constructive response would work towards finding and addressing the other underlying cause.
A logical reason would be that systemd is too sensitive on signals arriving fast, and if that's the case it's quite likely that there is no easy solution (if any).
But anyway, my objective is not to improve systemd (I might have tried that if Lennart wasn't such an asshole), my objective is to show that systemd has problems, and CONFIG_HZ_300=y is just an example... there are other issues popping in arch-general that render the system unbootable.
Perhaps in the future I will have time to investigate the issue, and make a proper bug report, and systemd would work properly for me, and most Arch Linux users, but I believe that's not the case *currently*.
So I believe the logical course of action is to delay the migration until systemd is more robust.
All I want is to minimize the issues that Arch Linux users hit, but unfortunately so far it seems Arch Linux developers don't care about how many problems could this move cause.
Cheers.
-- Felipe Contreras
2 things top posting and no matter how much of an ass someone may or may not be no need for personal attacks
On Thu, Aug 16, 2012 at 5:54 PM, Felipe Contreras <felipe.contreras@gmail.com> wrote:
On Thu, Aug 16, 2012 at 4:08 PM, John K Pate <j.k.pate@sms.ed.ac.uk> wrote:
On Thu, 16 Aug 2012 15:16:31 +0200 Felipe Contreras <felipe.contreras@gmail.com> wrote:
On Wed, Aug 15, 2012 at 7:58 PM, Denis A. Altoé Falqueto <denisfalqueto@gmail.com> wrote:
This is so stupid that it's not even funny. You said that the problem was having CONFIG_HZ=300 and systemd. I said it is not, because I also have that situation and it works. So, your point is moot. I didn't say you don't have a problem, but just that it may be not related to CONFIG_HZ. I even sent you an article with ways on how to inspect the behaviour of systemd, which was completely ignored.
My problem with CONFIG_HZ exists independently of whether you experience the problem yourself or not.
But it suggests that the problem is not *just* systemd and CONFIG_HZ=300. I am, and many others are, running systemd with CONFIG_HZ=300 fine.
Show me two bootcharts, one with CONFIG_HZ_300=y, and another with CONFIG_HZ_1000=y. Then I will believe that you are running systemd fine. The other possibility is that you are just not noticing the problem.
Chalange accepted. http://dl.dropbox.com/u/9222479/bootchart-arch-hz300.png Bootchart of 20 seconds, with Arch stock kernel, CONFIG_HZ=300. You can see that kdm is started in around 7 seconds after boot starts. http://dl.dropbox.com/u/9222479/bootchart-ck-hz1000.png Same length chart, with CK patchset kernel, from AUR package (some problems compiling stock kernel with CONFIG_HZ=1000, not related to systemd at all0. You'll be amazed to see kdm starting at around the same time. Happy now? -- A: Because it obfuscates the reading. Q: Why is top posting so bad? For more information, please read: http://idallen.com/topposting.html ------------------------------------------- Denis A. Altoe Falqueto Linux user #524555 -------------------------------------------
On Fri, Aug 17, 2012 at 01:22:09AM -0300, Denis A. Altoé Falqueto wrote:
On Thu, Aug 16, 2012 at 5:54 PM, Felipe Contreras <felipe.contreras@gmail.com> wrote:
On Thu, Aug 16, 2012 at 4:08 PM, John K Pate <j.k.pate@sms.ed.ac.uk> wrote:
On Thu, 16 Aug 2012 15:16:31 +0200 Felipe Contreras <felipe.contreras@gmail.com> wrote:
On Wed, Aug 15, 2012 at 7:58 PM, Denis A. Altoé Falqueto <denisfalqueto@gmail.com> wrote:
This is so stupid that it's not even funny. You said that the problem was having CONFIG_HZ=300 and systemd. I said it is not, because I also have that situation and it works. So, your point is moot. I didn't say you don't have a problem, but just that it may be not related to CONFIG_HZ. I even sent you an article with ways on how to inspect the behaviour of systemd, which was completely ignored.
My problem with CONFIG_HZ exists independently of whether you experience the problem yourself or not.
But it suggests that the problem is not *just* systemd and CONFIG_HZ=300. I am, and many others are, running systemd with CONFIG_HZ=300 fine.
Show me two bootcharts, one with CONFIG_HZ_300=y, and another with CONFIG_HZ_1000=y. Then I will believe that you are running systemd fine. The other possibility is that you are just not noticing the problem.
Chalange accepted.
http://dl.dropbox.com/u/9222479/bootchart-arch-hz300.png
Bootchart of 20 seconds, with Arch stock kernel, CONFIG_HZ=300. You can see that kdm is started in around 7 seconds after boot starts.
http://dl.dropbox.com/u/9222479/bootchart-ck-hz1000.png
Same length chart, with CK patchset kernel, from AUR package (some problems compiling stock kernel with CONFIG_HZ=1000, not related to systemd at all0. You'll be amazed to see kdm starting at around the same time.
Happy now?
-- A: Because it obfuscates the reading. Q: Why is top posting so bad? For more information, please read: http://idallen.com/topposting.html
------------------------------------------- Denis A. Altoe Falqueto Linux user #524555 ------------------------------------------- +1
On Fri, Aug 17, 2012 at 6:22 AM, Denis A. Altoé Falqueto <denisfalqueto@gmail.com> wrote:
On Thu, Aug 16, 2012 at 5:54 PM, Felipe Contreras <felipe.contreras@gmail.com> wrote:
On Thu, Aug 16, 2012 at 4:08 PM, John K Pate <j.k.pate@sms.ed.ac.uk> wrote:
On Thu, 16 Aug 2012 15:16:31 +0200 Felipe Contreras <felipe.contreras@gmail.com> wrote:
On Wed, Aug 15, 2012 at 7:58 PM, Denis A. Altoé Falqueto <denisfalqueto@gmail.com> wrote:
This is so stupid that it's not even funny. You said that the problem was having CONFIG_HZ=300 and systemd. I said it is not, because I also have that situation and it works. So, your point is moot. I didn't say you don't have a problem, but just that it may be not related to CONFIG_HZ. I even sent you an article with ways on how to inspect the behaviour of systemd, which was completely ignored.
My problem with CONFIG_HZ exists independently of whether you experience the problem yourself or not.
But it suggests that the problem is not *just* systemd and CONFIG_HZ=300. I am, and many others are, running systemd with CONFIG_HZ=300 fine.
Show me two bootcharts, one with CONFIG_HZ_300=y, and another with CONFIG_HZ_1000=y. Then I will believe that you are running systemd fine. The other possibility is that you are just not noticing the problem.
Chalange accepted.
http://dl.dropbox.com/u/9222479/bootchart-arch-hz300.png
Bootchart of 20 seconds, with Arch stock kernel, CONFIG_HZ=300. You can see that kdm is started in around 7 seconds after boot starts.
http://dl.dropbox.com/u/9222479/bootchart-ck-hz1000.png
Same length chart, with CK patchset kernel, from AUR package (some problems compiling stock kernel with CONFIG_HZ=1000, not related to systemd at all0. You'll be amazed to see kdm starting at around the same time.
Funny that you say "around the same time", when it's clearly less than 6 seconds, so it's 15% slower, but that's the second instance of kdm. The first instance starts at 2s in 1000 hz, and 4s in 300 hz, so there's *clearly* a big difference. Perhaps the boot of KDE is so slow that in comparison the difference is small and you don't notice the issue, but I certainly notice a *huge* difference with SLiM and Xfce. And still, you should be using the same kernel for a fair comparison, not 3.4.8 vs 3.5.2 + patches. You can certainly use 3.5.2 + patches for both. Cheers. -- Felipe Contreras
* Felipe Contreras (felipe.contreras@gmail.com) [22.08.12 02:22]:
Funny that you say "around the same time", when it's clearly less than 6 seconds, so it's 15% slower, but that's the second instance of kdm. The first instance starts at 2s in 1000 hz, and 4s in 300 hz, so there's *clearly* a big difference.
So it's only needs twice the time with only on third of the ticks? Well that is awesome... Yeah to systemd! Anyway we are talking about 2 seconds... compared to time you wasted for a lot of people: It would have been better you had just saved all the delaying seconds for 100 boots and got a cup of coffee as normal users do when they boot their computer.... Sebastian P.S.: sorry for feeding the trolls, but I simply could not resist... -- " Religion ist das Opium des Volkes. " | _ ASCII ribbon campaign Karl Marx | ( ) against HTML e-mail SEB@STI@N GÜNTHER | X against M$ attachments mailto:arch@teageek.de | / \ www.asciiribbon.org
2012/8/22 Sebastian Günther <arch@teageek.de>:
* Felipe Contreras (felipe.contreras@gmail.com) [22.08.12 02:22]:
Funny that you say "around the same time", when it's clearly less than 6 seconds, so it's 15% slower, but that's the second instance of kdm. The first instance starts at 2s in 1000 hz, and 4s in 300 hz, so there's *clearly* a big difference.
So it's only needs twice the time with only on third of the ticks? Well that is awesome... Yeah to systemd!
Anyway we are talking about 2 seconds... compared to time you wasted for a lot of people: It would have been better you had just saved all the delaying seconds for 100 boots and got a cup of coffee as normal users do when they boot their computer....
Sebastian
P.S.: sorry for feeding the trolls, but I simply could not resist...
-- " Religion ist das Opium des Volkes. " | _ ASCII ribbon campaign Karl Marx | ( ) against HTML e-mail SEB@STI@N GÜNTHER | X against M$ attachments mailto:arch@teageek.de | / \ www.asciiribbon.org
Where is that time where computer could take up to thirty seconds to boot up ? -- Cordialement, Coues Ludovic 06 148 743 42 -- () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments
On Wed, Aug 22, 2012 at 6:22 PM, Sebastian Günther <arch@teageek.de> wrote:
* Felipe Contreras (felipe.contreras@gmail.com) [22.08.12 02:22]:
Funny that you say "around the same time", when it's clearly less than 6 seconds, so it's 15% slower, but that's the second instance of kdm. The first instance starts at 2s in 1000 hz, and 4s in 300 hz, so there's *clearly* a big difference.
So it's only needs twice the time with only on third of the ticks? Well that is awesome... Yeah to systemd!
Anyway we are talking about 2 seconds... compared to time you wasted for a lot of people: It would have been better you had just saved all the delaying seconds for 100 boots and got a cup of coffee as normal users do when they boot their computer....
In fact, the first kdm in the graphs is kdm.service unit that's being loaded by systemd. The real kdm is started after every other dependency is satisfied, around 6 or 7 seconds after boot. I don't have initscripts anymore to make a comparison, but the time to get to kdm was almost double the current time. -- A: Because it obfuscates the reading. Q: Why is top posting so bad? For more information, please read: http://idallen.com/topposting.html ------------------------------------------- Denis A. Altoe Falqueto Linux user #524555 -------------------------------------------
On Wed, Aug 22, 2012 at 11:22 PM, Sebastian Günther <arch@teageek.de> wrote:
* Felipe Contreras (felipe.contreras@gmail.com) [22.08.12 02:22]:
Funny that you say "around the same time", when it's clearly less than 6 seconds, so it's 15% slower, but that's the second instance of kdm. The first instance starts at 2s in 1000 hz, and 4s in 300 hz, so there's *clearly* a big difference.
So it's only needs twice the time with only on third of the ticks? Well that is awesome... Yeah to systemd!
systemd is much more complicated, and requires many more tricks.
Anyway we are talking about 2 seconds...
We are talking about a difference of 100%. -- Felipe Contreras
On Thu, Aug 23, 2012 at 3:23 PM, Felipe Contreras < felipe.contreras@gmail.com> wrote:
Anyway we are talking about 2 seconds...
We are talking about a difference of 100%.
-- Felipe Contreras
You are being pedantic. A 2 second difference is negligible, and certainly not the huge issue you are making it out to be.
On Thu, Aug 23, 2012 at 03:31:19PM -0400, Brandon Watkins wrote:
You are being pedantic. A 2 second difference is negligible, and certainly not the huge issue you are making it out to be.
It's not negligible in computing terms. It can matter but plan A is usually for your boot time to be immaterial (because rebooting is lame in the first place). It's not entirely clear where these two seconds are being lost, tho'. It's tough to lay the blame precisely where Filipe is placing it.
On Thu, Aug 23, 2012 at 09:23:33PM +0200, Felipe Contreras wrote:
So it's only needs twice the time with only on third of the ticks? Well that is awesome... Yeah to systemd!
systemd is much more complicated, and requires many more tricks.
Please remember: I hate systemd. I have seen systemd boot faster than rough equivalents. Yes, the software is a huge, bloated piece of crap. But it is also unmistakably capable of faster boot times when services are started properly in parallel. That's assuming a few things (like that your services are not hugely inter-dependent or that a couple [like, maybe DHCP, depending on your server] just take stupidly long to start up). For all its faults, being incapabel of giving you a boot time advantage is _not_ one of them.
On Sat, Aug 25, 2012 at 4:31 AM, Anthony ''Ishpeck'' Tedjamulia <archlinux@ishpeck.net> wrote:
On Thu, Aug 23, 2012 at 09:23:33PM +0200, Felipe Contreras wrote:
So it's only needs twice the time with only on third of the ticks? Well that is awesome... Yeah to systemd!
systemd is much more complicated, and requires many more tricks.
Please remember: I hate systemd.
I have seen systemd boot faster than rough equivalents.
Yes, the software is a huge, bloated piece of crap. But it is also unmistakably capable of faster boot times when services are started properly in parallel.
That's assuming a few things (like that your services are not hugely inter-dependent or that a couple [like, maybe DHCP, depending on your server] just take stupidly long to start up).
For all its faults, being incapabel of giving you a boot time advantage is _not_ one of them.
Yes, that's *in theory*, but in practice that's not what I see, and I already investigated the culprit: http://people.freedesktop.org/~felipec/systemd/bootchart_sysd.png http://people.freedesktop.org/~felipec/systemd/bootchart_sysv.png Software shouldn't rely on CONFIG_HZ, but apparently systemd is doing something that does. I don't find this surprising at all; systemd is a relatively new piece of software, and a very complex one, it's bound to have tricky issues like this one. -- Felipe Contreras
On Sun, Aug 26, 2012 at 12:19:00AM +0200, Felipe Contreras wrote:
For all its faults, being incapabel of giving you a boot time advantage is _not_ one of them.
Yes, that's *in theory*, but in practice that's not what I see, and I already investigated the culprit:
It's more like "if the stars align." I hold the potential for boot time speed to be axiomatic and the only question is if your starting services are the particular combination that would actually make it matter.
2012/8/15 Felipe Contreras <felipe.contreras@gmail.com>:
Hi,
Finally, it's much harder to debug. If you have a problem you will not be able to open a script and figure out what is happening, and perhaps modify it, and debug it. You would be greeted with an unmodified binary, and the source code would be along these lines:
http://cgit.freedesktop.org/systemd/systemd/tree/src/remount-fs/remount-fs.c
The fact is you do not need to debug these scripts anymore. One foo.service is tested ok in one distro, it will be push into upstream and all other distro can just use it. When blame the C file here, do not forget most of the program you use is using C. The problem with bash script is they can not be used/shared between different distro. So every distro has to maintain their own script. It is a waste of time and resources. Leon
Cheers.
[1] https://plus.google.com/108736516888538655285/posts/BTG39o6YoGS [2] http://code.google.com/p/support/wiki/DVCSAnalysis
-- Felipe Contreras
On Wed, Aug 15, 2012 at 6:33 AM, Leon Feng <rainofchaos@gmail.com> wrote:
2012/8/15 Felipe Contreras <felipe.contreras@gmail.com>:
Hi,
Finally, it's much harder to debug. If you have a problem you will not be able to open a script and figure out what is happening, and perhaps modify it, and debug it. You would be greeted with an unmodified binary, and the source code would be along these lines:
http://cgit.freedesktop.org/systemd/systemd/tree/src/remount-fs/remount-fs.c
The fact is you do not need to debug these scripts anymore. One foo.service is tested ok in one distro, it will be push into upstream and all other distro can just use it.
Yes, you need to debug them, because they are not self-contained, the interact with the rest of the system. So what the C file does in your system is not what it does on my system; it depends on countless other things, such as configuration.
When blame the C file here, do not forget most of the program you use is using C. The problem with bash script is they can not be used/shared between different distro. So every distro has to maintain their own script. It is a waste of time and resources.
Yes they can. Code is code, language doesn't make a piece of code more share-able between distros than others. Cheers. -- Felipe Contreras
On Wed, Aug 15, 2012 at 2:42 PM, Felipe Contreras <felipe.contreras@gmail.com> wrote:>
Yes they can. Code is code, language doesn't make a piece of code more share-able between distros than others.
Cheers.
-- Felipe Contreras
Do you even know what .service files look like and how they work? Your statement would make just as much sense if you'd said "env variables don't translate from distro to distro"....
Felipe, On Aug 15, 2012 3:35 AM, "Felipe Contreras" <felipe.contreras@gmail.com> wrote:
I tried systemd a while ago in a brand new machine with Arch Linux and the boot was *much slower*. After some exchanges with Lennart Poettering and other people in Google+[1], it became clear I was on my own. Eventually I found the culprit: Fedora uses CONFIG_HZ_1000, and Arch Linux uses CONFIG_HZ_300. It became clear to me that systemd was not ready for prime time, it wasn't thoroughly tested in a lot of machines, and if you have problems Lennart Poettering will blame you (PulseAudio sounds familiar?).
Do you have a link to a proper bug report for this issue? I tried reading the Google+ thread but I couldn't stomach how rude you were in each of your messages (including the first one) so stopped reading.
systemd was the reason I stopped using Fedora in the first place; when they moved to it my machine stopped booting reliably. My configuration was non-standard (a single encrypted partition), so I guess they never tested that. Similarly, I expect many Arch Linux users to bite these corner-cases.
Please note that we have waited much longer than Fedora did to make sure the corner cases have been taken care of. Is this problem still an issue, or is it just FUD? Link to (current) bug report?
Finally, it's much harder to debug. If you have a problem you will not be able to open a script and figure out what is happening, and perhaps modify it, and debug it. You would be greeted with an unmodified binary, and the source code would be along these lines:
http://cgit.freedesktop.org/systemd/systemd/tree/src/remount-fs/remount-fs.c As someone who has spent a lot of time debugging both, I much prefer systemd. I think you are being disingenuous here, surely you don't have a problem reading C?
I'm sure in due time systemd will be ready, and will have nice advantages, but I doubt that's the case right now. Has anybody looked into the CONFIG_HZ issue? I doubt that.
This is the first I hear of it. I'd be interested to follow up if there is a proper bug report without unnecessary hostility.
I was expecting more from the Arch Linux community, something along the lines of Google's analysis to pick to mercurial[2], but so far I have only seen a couple of people saying +1 in the development mailing list, with barely any explanation at all. Such an important move (one that might make users' machines stop booting) should warrant at least an analysis of some sort, with clear advantages. Would it not?
We provided systemd optionally for a long time, as you know. Its pros and cons have been discussed at the various making lists at great length. A significant portion of our userbase has switched to it, and no serious issues seem to remain, based on the feedback we have been getting. Each dev will have had the possibility of trying it, and researching it. They will have done their own analysis on which the +1s are based. I see no value in providing an official public analysis. That's not how we work, and it would not help in the decision making at this point. That's not to say that an analysis would not be an interesting read, and I'm sure people like Allan our Jason will provide some excellent blog posts about this at some point.
At the moment I am unconvinced; does systemd has any *real* advantage? I don't think so; the potential of breakage outweighs the "supposed" advantages, and I think a proper analysis would show that.
If you find any issues, please report bugs. Except for that, all I can say is that no one set out to convince you, and I'm sure Google will find you discussions/analysis/code if you are genuinely interested. Tom
On Aug 15, 2012 7:35 AM, "Tom Gundersen" <teg@jklm.no> wrote:
On Aug 15, 2012 3:35 AM, "Felipe Contreras" <felipe.contreras@gmail.com> wrote:
I tried systemd a while ago in a brand new machine with Arch Linux and the boot was *much slower*. After some exchanges with Lennart Poettering and other people in Google+[1], it became clear I was on my own. Eventually I found the culprit: Fedora uses CONFIG_HZ_1000, and Arch Linux uses CONFIG_HZ_300. It became clear to me that systemd was not ready for prime time, it wasn't thoroughly tested in a lot of machines, and if you have problems Lennart Poettering will blame you (PulseAudio sounds familiar?).
Do you have a link to a proper bug report for this issue? I tried reading the Google+ thread but I couldn't stomach how rude you were in each of your messages (including the first one) so stopped reading.
Ok I we've back and read to the end. The last message contained interesting info. There is likely more to it, as I have not been able to reproduce this, but still, something with looking into. As to out kernel options, if there are good reasons to change any of them, open feature requests (working around bugs us not necessarily a good reason). Tom
On Wed, Aug 15, 2012 at 7:35 AM, Tom Gundersen <teg@jklm.no> wrote:
Felipe,
On Aug 15, 2012 3:35 AM, "Felipe Contreras" <felipe.contreras@gmail.com> wrote:
I tried systemd a while ago in a brand new machine with Arch Linux and the boot was *much slower*. After some exchanges with Lennart Poettering and other people in Google+[1], it became clear I was on my own. Eventually I found the culprit: Fedora uses CONFIG_HZ_1000, and Arch Linux uses CONFIG_HZ_300. It became clear to me that systemd was not ready for prime time, it wasn't thoroughly tested in a lot of machines, and if you have problems Lennart Poettering will blame you (PulseAudio sounds familiar?).
Do you have a link to a proper bug report for this issue? I tried reading the Google+ thread but I couldn't stomach how rude you were in each of your messages (including the first one) so stopped reading.
No, I don't have such report.
systemd was the reason I stopped using Fedora in the first place; when they moved to it my machine stopped booting reliably. My configuration was non-standard (a single encrypted partition), so I guess they never tested that. Similarly, I expect many Arch Linux users to bite these corner-cases.
Please note that we have waited much longer than Fedora did to make sure the corner cases have been taken care of. Is this problem still an issue, or is it just FUD? Link to (current) bug report?
I don't have that machine available at the moment, but I don't see how such an issue could have been fixed given the lack of interest from Lennart in that G+ post. I'd say this issue most likely is not fixed, but it's only an example. Just like one this there might be more.
Finally, it's much harder to debug. If you have a problem you will not be able to open a script and figure out what is happening, and perhaps modify it, and debug it. You would be greeted with an unmodified binary, and the source code would be along these lines:
http://cgit.freedesktop.org/systemd/systemd/tree/src/remount-fs/remount-fs.c
As someone who has spent a lot of time debugging both, I much prefer systemd. I think you are being disingenuous here, surely you don't have a problem reading C?
And I prefer sh. Preferences don't count for much. I do read and write C everyday for probably for more than 10 years now, yet I do have trouble reading systemd's code, but that's not important, what is important is that in order to test my modifications (to add debugging for example), I would need to *recompile*.
I'm sure in due time systemd will be ready, and will have nice advantages, but I doubt that's the case right now. Has anybody looked into the CONFIG_HZ issue? I doubt that.
This is the first I hear of it. I'd be interested to follow up if there is a proper bug report without unnecessary hostility.
Not to my knowledge.
I was expecting more from the Arch Linux community, something along the lines of Google's analysis to pick to mercurial[2], but so far I have only seen a couple of people saying +1 in the development mailing list, with barely any explanation at all. Such an important move (one that might make users' machines stop booting) should warrant at least an analysis of some sort, with clear advantages. Would it not?
We provided systemd optionally for a long time, as you know. Its pros and cons have been discussed at the various making lists at great length. A significant portion of our userbase has switched to it, and no serious issues seem to remain, based on the feedback we have been getting. Each dev will have had the possibility of trying it, and researching it. They will have done their own analysis on which the +1s are based. I see no value in providing an official public analysis. That's not how we work, and it would not help in the decision making at this point.
Well, I see absolutely no evidence of such an analysis, so consider me a skeptic.
That's not to say that an analysis would not be an interesting read, and I'm sure people like Allan our Jason will provide some excellent blog posts about this at some point.
One can only hope. Cheers. -- Felipe Contreras
On Wed, Aug 15, 2012 at 8:50 AM, Felipe Contreras <felipe.contreras@gmail.com> wrote:
I don't have that machine available at the moment, but I don't see how such an issue could have been fixed given the lack of interest from Lennart in that G+ post.
Without the insults, this would have been picked up on and sorted out a long time ago. At least based on my experience.
I do read and write C everyday for probably for more than 10 years now, yet I do have trouble reading systemd's code, but that's not important, what is important is that in order to test my modifications (to add debugging for example), I would need to *recompile*.
I'm aware that you are a professional, that's why I find your claims about the difficulty of understanding/recompiling... odd. By contrast, my C skills/experience are virtually nonexistent, and yet I have had no problems understanding/debugging/recompiling/patching the systemd code.
Well, I see absolutely no evidence of such an analysis, so consider me a skeptic.
That's ok. We are not in the PR business, we are not selling anything. -t
On Wed, Aug 15, 2012 at 9:01 AM, Tom Gundersen <teg@jklm.no> wrote:
On Wed, Aug 15, 2012 at 8:50 AM, Felipe Contreras <felipe.contreras@gmail.com> wrote:
I don't have that machine available at the moment, but I don't see how such an issue could have been fixed given the lack of interest from Lennart in that G+ post.
Without the insults, this would have been picked up on and sorted out a long time ago. At least based on my experience.
That's a loss for systemd, not for me. And I didn't insult anybody, Lennart did, so it's not my fault.
I do read and write C everyday for probably for more than 10 years now, yet I do have trouble reading systemd's code, but that's not important, what is important is that in order to test my modifications (to add debugging for example), I would need to *recompile*.
I'm aware that you are a professional, that's why I find your claims about the difficulty of understanding/recompiling... odd. By contrast, my C skills/experience are virtually nonexistent, and yet I have had no problems understanding/debugging/recompiling/patching the systemd code.
It's not my claims, it's a fact; compiling is more complicated than not-compiling (one step less), and you need a compiler, and linker (and in some systems development packages), and sometimes deploying the binaries. With scripting you don't need any of that; after you are done editing the text (which you have to do regardless), you are done.
Well, I see absolutely no evidence of such an analysis, so consider me a skeptic.
That's ok. We are not in the PR business, we are not selling anything.
You are selling a distribution. When Arch Linux stops giving the users what they want, the users will go for a different distribution. That's how distributions die; when something better is on the market for most of their users. Cheers. -- Felipe Contreras
On Wed, Aug 15, 2012 at 9:24 AM, Felipe Contreras <felipe.contreras@gmail.com> wrote:
Well, I see absolutely no evidence of such an analysis, so consider me a skeptic.
That's ok. We are not in the PR business, we are not selling anything.
You are selling a distribution.
We are? Damn. Where is my cut. Allan!? -t
On Wed, Aug 15, 2012 at 2:39 AM, Tom Gundersen <teg@jklm.no> wrote:
On Wed, Aug 15, 2012 at 9:24 AM, Felipe Contreras <felipe.contreras@gmail.com> wrote:
Well, I see absolutely no evidence of such an analysis, so consider me a skeptic.
That's ok. We are not in the PR business, we are not selling anything.
You are selling a distribution.
We are? Damn. Where is my cut. Allan!?
:-) it's interesting to me how so many can believe that OSS/distros/etc/etc are really driven and decided by the whimsical desires of the complete, mob-like user base. open, collaborative development has only 5% to do with feel good all-for-one-and-one-for-all type shitz, and 95% to do with the needs of the investing/funding/contracting user-base, and/or the itches/scratches/interests of developers capable of architecting useful tools from mere ideas and/or hot air. example: in the last ~2 months i've contributed code to ~4 different projects: 3 were fulfilling a *business* need for the company that employs me, relating to AMQP and [gag] SOAP, which frankly i could care less about and would actually prefer if they faded away forever ... but no, i FURTHERED them, because that's what the requirements called for; another project is a popular Python application server, and was furthered for both business and personal/pleasure reasons (interesting); only 1 was purely for fun, relating to Python -> JS translation ... a real challenge ... alas, even the one for fun i did for *me* -- not to sound like an ass, but i don't much give two shitzs about everyone else's needs less they contribute competent code, or at the very least, competent thought and constructive ideas. a little respect goes a long way ... ... and on that same vein, i have next-to-nil patience for whining. the point of this ramble-esque message is to highlight the fact that 90% of what i output is business related, 30-40% of that is shit i wish would evaporate, and 10-20% is my personal interests/free-time-development (which i abandon and find other projects once it becomes boring and/or "un-fun") SO! truth is the commercial fedoras/redhats and ubuntus out there are all a vibrant part of this process, and they WILL supply/shoulder the bulk of development. buck up folks! just get used to it! Arch plays a part too (yay python2 symlink! ;-) in various capacities, but software research/development and long-term maintenance of decadent tools is NOT that part. why? because Arch is part of the 10-20% section of most developer's time -- ehm, you know, the part where they do what they !@#$%^& want -- so suck it up and make clear/concise contributions of code/thought/reason as best you can ... because this endless droning on RE:piddly-little-wah-wah-problems makes for really fscking boring reads. -- C Anthony
SO! truth is the commercial fedoras/redhats and ubuntus out there are all a vibrant part of this process,
True
and they WILL supply/shoulder the bulk of development.
Wrong, there have been more commits from independents in the Linux tree in the last decade atleast. -- _______________________________________________________________________ 'Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface' (Doug McIlroy) _______________________________________________________________________
On Wed, 15 Aug 2012 05:09:29 -0500 C Anthony Risinger <anthony@xtfx.me> wrote: <snip>
it's interesting to me how so many can believe that OSS/distros/etc/etc are really driven and decided by the whimsical desires of the complete, mob-like user base. <snip>
All points taken, and, for my own part, I do not complain about the free product of other people's efforts. On the other hand, I suppose that many devs take at least some pride in the number of users who gratefully take advantage of their work. If that is right. then they might not object to someone explaining (politely, briefly, once), why the direction they are taking might lead the person concerned reluctantly to use something else instead. How they respond to such opinions is, of course, entirely a matter for them. Geoff
On Wed, Aug 15, 2012 at 12:09 PM, C Anthony Risinger <anthony@xtfx.me> wrote:
On Wed, Aug 15, 2012 at 2:39 AM, Tom Gundersen <teg@jklm.no> wrote:
On Wed, Aug 15, 2012 at 9:24 AM, Felipe Contreras <felipe.contreras@gmail.com> wrote:
Well, I see absolutely no evidence of such an analysis, so consider me a skeptic.
That's ok. We are not in the PR business, we are not selling anything.
You are selling a distribution.
We are? Damn. Where is my cut. Allan!?
I wonder why you are purposely using the (clearly) unintended definition of the word 'sell'. Just to make things clear: a : to develop a belief in the truth, value, or desirability of : gain acceptance for <trying to sell a program to the Congress> b : to persuade or influence to a course of action or to the acceptance of something <sell children on reading> http://www.merriam-webster.com/dictionary/sell
it's interesting to me how so many can believe that OSS/distros/etc/etc are really driven and decided by the whimsical desires of the complete, mob-like user base.
I am not saying such a thing at all. I am fully aware that contributors do their contributors mostly to scratch their own itch. But while scratching your own itch you are often scratching other people's itches, perhaps inadvertently (the 'invisible hand' theory). However, that's as a *contributor* to the project. The project itself needs contributors to survive, and keep moving, without contributors there's no users, and without users there's no project (and no contributors as well, as contributors most of the time are users first). It's fine to say "we don't target the common type of Linux user", but you have to have at least some idea of what your users are, and what they want, otherwise the project will never be truly successful. If you both attract and repel your users (inadvertently), you might get periods when the projects seems alive and thriving (as I think it is right now), and then just experience a quick death (as the users that came to Arch Linux for X will quickly realize they were 'deceived' and go away). The advantages of having a healthy user-base are numerous, but if I have to explain them I feel there's no point in discussing. The biggest thing any program can do is not the technical details of the program itself; it’s how useful the program is to users. So any time any program (like the kernel or any other project), breaks the user experience, to me, that’s the absolute worst failure that a software project can make. -- Linus Torvalds Cheers. -- Felipe Contreras
[2012-08-15 13:56:22 +0200] Felipe Contreras:
The biggest thing any program can do is not the technical details of the program itself; it’s how useful the program is to users. So any time any program (like the kernel or any other project), breaks the user experience, to me, that’s the absolute worst failure that a software project can make. -- Linus Torvalds
Fuck you! -- Linus Torvalds -- Gaetan
On Wed, Aug 15, 2012 at 8:28 PM, Gaetan Bisson <bisson@archlinux.org> wrote:
[2012-08-15 13:56:22 +0200] Felipe Contreras:
The biggest thing any program can do is not the technical details of the program itself; it’s how useful the program is to users. So any time any program (like the kernel or any other project), breaks the user experience, to me, that’s the absolute worst failure that a software project can make. -- Linus Torvalds
Fuck you! -- Linus Torvalds
-- Gaetan
That's full of win, right there.
On Aug 15, 2012 1:56 PM, "Felipe Contreras" <felipe.contreras@gmail.com> wrote:
The biggest thing any program can do is not the technical details of the program itself; it’s how useful the program is to users. So any time any program (like the kernel or any other project), breaks the user experience, to me, that’s the absolute worst failure that a software project can make. -- Linus Torvalds
I'm sorry,I can't help myself: 'You're a fucking moron. [snip] I'm stupider for just reading your email. Go away.' - Linus Torvalds to Felipe Contreras
On Wed, Aug 15, 2012 at 9:16 AM, Tom Gundersen <teg@jklm.no> wrote:
On Aug 15, 2012 1:56 PM, "Felipe Contreras" <felipe.contreras@gmail.com> wrote:
The biggest thing any program can do is not the technical details of the program itself; it’s how useful the program is to users. So any time any program (like the kernel or any other project), breaks the user experience, to me, that’s the absolute worst failure that a software project can make. -- Linus Torvalds
I'm sorry,I can't help myself:
'You're a fucking moron.
[snip]
I'm stupider for just reading your email. Go away.'
- Linus Torvalds to Felipe Contreras
Stop the idiotic arguing already. - Linus Torvalds to Felipe Contreras
On Wed, Aug 15, 2012 at 4:16 PM, Tom Gundersen <teg@jklm.no> wrote:
On Aug 15, 2012 1:56 PM, "Felipe Contreras" <felipe.contreras@gmail.com> wrote:
The biggest thing any program can do is not the technical details of the program itself; it’s how useful the program is to users. So any time any program (like the kernel or any other project), breaks the user experience, to me, that’s the absolute worst failure that a software project can make. -- Linus Torvalds
I'm sorry,I can't help myself:
'You're a fucking moron.
[snip]
I'm stupider for just reading your email. Go away.'
- Linus Torvalds to Felipe Contreras
Do I have to point out that even if I am a moron, that doesn't mean my particular argument that I am pushing forward is bad in any way? Ad hominem fallacy. -- Felipe Contreras
On Wed, Aug 15, 2012 at 2:56 PM, Felipe Contreras <felipe.contreras@gmail.com> wrote:
Ad hominem fallacy.
I don't know if you're trying to show that you really know argumentation topics by heart or just trying to make peopple dislike you right away. That kind of snobish sance doesn't help you at all. -- A: Because it obfuscates the reading. Q: Why is top posting so bad? For more information, please read: http://idallen.com/topposting.html ------------------------------------------- Denis A. Altoe Falqueto Linux user #524555 -------------------------------------------
On Wed, 15 Aug 2012 05:09:29 -0500 C Anthony Risinger <anthony@xtfx.me> wrote:
On Wed, Aug 15, 2012 at 2:39 AM, Tom Gundersen <teg@jklm.no> wrote:
On Wed, Aug 15, 2012 at 9:24 AM, Felipe Contreras <felipe.contreras@gmail.com> wrote:
Well, I see absolutely no evidence of such an analysis, so consider me a skeptic.
That's ok. We are not in the PR business, we are not selling anything.
You are selling a distribution.
We are? Damn. Where is my cut. Allan!?
:-)
it's interesting to me how so many can believe that OSS/distros/etc/etc are really driven and decided by the whimsical desires of the complete, mob-like user base.
open, collaborative development has only 5% to do with feel good all-for-one-and-one-for-all type shitz, and 95% to do with the needs of the investing/funding/contracting user-base, and/or the itches/scratches/interests of developers capable of architecting useful tools from mere ideas and/or hot air.
example: in the last ~2 months i've contributed code to ~4 different projects: 3 were fulfilling a *business* need for the company that employs me, relating to AMQP and [gag] SOAP, which frankly i could care less about and would actually prefer if they faded away forever ... but no, i FURTHERED them, because that's what the requirements called for; another project is a popular Python application server, and was furthered for both business and personal/pleasure reasons (interesting); only 1 was purely for fun, relating to Python -> JS translation ... a real challenge ...
alas, even the one for fun i did for *me* -- not to sound like an ass, but i don't much give two shitzs about everyone else's needs less they contribute competent code, or at the very least, competent thought and constructive ideas. a little respect goes a long way ...
... and on that same vein, i have next-to-nil patience for whining. the point of this ramble-esque message is to highlight the fact that 90% of what i output is business related, 30-40% of that is shit i wish would evaporate, and 10-20% is my personal interests/free-time-development (which i abandon and find other projects once it becomes boring and/or "un-fun")
SO! truth is the commercial fedoras/redhats and ubuntus out there are all a vibrant part of this process, and they WILL supply/shoulder the bulk of development. buck up folks! just get used to it! Arch plays a part too (yay python2 symlink! ;-) in various capacities, but software research/development and long-term maintenance of decadent tools is NOT that part. why? because Arch is part of the 10-20% section of most developer's time -- ehm, you know, the part where they do what they !@#$%^& want -- so suck it up and make clear/concise contributions of code/thought/reason as best you can ... because this endless droning on RE:piddly-little-wah-wah-problems makes for really fscking boring reads.
Relevant link: http://www.h-online.com/open/features/Can-open-source-be-democratic-1663702....
On 08/15/2012 03:39 AM, Tom Gundersen wrote:
On Wed, Aug 15, 2012 at 9:24 AM, Felipe Contreras <felipe.contreras@gmail.com> wrote:
Well, I see absolutely no evidence of such an analysis, so consider me a skeptic. That's ok. We are not in the PR business, we are not selling anything. You are selling a distribution. We are? Damn. Where is my cut. Allan!?
-t
I saw your cut....... why it's just over there ----->
2012/8/15 Felipe Contreras <felipe.contreras@gmail.com>:
On Wed, Aug 15, 2012 at 9:01 AM, Tom Gundersen <teg@jklm.no> wrote:
On Wed, Aug 15, 2012 at 8:50 AM, Felipe Contreras <felipe.contreras@gmail.com> wrote:
I don't have that machine available at the moment, but I don't see how such an issue could have been fixed given the lack of interest from Lennart in that G+ post.
Without the insults, this would have been picked up on and sorted out a long time ago. At least based on my experience.
That's a loss for systemd, not for me. And I didn't insult anybody, Lennart did, so it's not my fault.
I do read and write C everyday for probably for more than 10 years now, yet I do have trouble reading systemd's code, but that's not important, what is important is that in order to test my modifications (to add debugging for example), I would need to *recompile*.
I'm aware that you are a professional, that's why I find your claims about the difficulty of understanding/recompiling... odd. By contrast, my C skills/experience are virtually nonexistent, and yet I have had no problems understanding/debugging/recompiling/patching the systemd code.
It's not my claims, it's a fact; compiling is more complicated than not-compiling (one step less), and you need a compiler, and linker (and in some systems development packages), and sometimes deploying the binaries. With scripting you don't need any of that; after you are done editing the text (which you have to do regardless), you are done.
Well, I see absolutely no evidence of such an analysis, so consider me a skeptic.
That's ok. We are not in the PR business, we are not selling anything.
You are selling a distribution. When Arch Linux stops giving the users what they want, the users will go for a different distribution. That's how distributions die; when something better is on the market for most of their users.
Arch is always give user's their options they want. You can use initscript, even if systemd is the default just like I can use systemd now when initscript is the default. Switch from one to another is very easy. So use systemd as default does not means you can not use initscript. But if one day, most of the developer find systemd is more easier to use maintain, they will stop maintain initscript. And it may rot, so can not be used. When this happened, if you still think initscript is easier to maintain, you can adopt it as a new maintainer and used them till the world ends. Leon
Cheers.
-- Felipe Contreras
On Wed, Aug 15, 2012 at 9:55 AM, Leon Feng <rainofchaos@gmail.com> wrote:
2012/8/15 Felipe Contreras <felipe.contreras@gmail.com>:
On Wed, Aug 15, 2012 at 9:01 AM, Tom Gundersen <teg@jklm.no> wrote:
On Wed, Aug 15, 2012 at 8:50 AM, Felipe Contreras <felipe.contreras@gmail.com> wrote:
I don't have that machine available at the moment, but I don't see how such an issue could have been fixed given the lack of interest from Lennart in that G+ post.
Without the insults, this would have been picked up on and sorted out a long time ago. At least based on my experience.
That's a loss for systemd, not for me. And I didn't insult anybody, Lennart did, so it's not my fault.
I do read and write C everyday for probably for more than 10 years now, yet I do have trouble reading systemd's code, but that's not important, what is important is that in order to test my modifications (to add debugging for example), I would need to *recompile*.
I'm aware that you are a professional, that's why I find your claims about the difficulty of understanding/recompiling... odd. By contrast, my C skills/experience are virtually nonexistent, and yet I have had no problems understanding/debugging/recompiling/patching the systemd code.
It's not my claims, it's a fact; compiling is more complicated than not-compiling (one step less), and you need a compiler, and linker (and in some systems development packages), and sometimes deploying the binaries. With scripting you don't need any of that; after you are done editing the text (which you have to do regardless), you are done.
Well, I see absolutely no evidence of such an analysis, so consider me a skeptic.
That's ok. We are not in the PR business, we are not selling anything.
You are selling a distribution. When Arch Linux stops giving the users what they want, the users will go for a different distribution. That's how distributions die; when something better is on the market for most of their users.
Arch is always give user's their options they want.
You can use initscript, even if systemd is the default just like I can use systemd now when initscript is the default. Switch from one to another is very easy. So use systemd as default does not means you can not use initscript.
This is not what I've been reading on the mailing list. People want to get rid of initscripts, as maintaining both would be a "burden", and certain projects behave differently with or without systemd (wedge strategy). -- Felipe Contreras
On 15/08/2012 8:05 AM, Felipe Contreras wrote:
On Wed, Aug 15, 2012 at 9:55 AM, Leon Feng <rainofchaos@gmail.com> wrote: [snip]
Arch is always give user's their options they want.
You can use initscript, even if systemd is the default just like I can use systemd now when initscript is the default. Switch from one to another is very easy. So use systemd as default does not means you can not use initscript. This is not what I've been reading on the mailing list. People want to get rid of initscripts, as maintaining both would be a "burden", and certain projects behave differently with or without systemd (wedge strategy).
True, the devs will eventually not want to be burdened with it, but that doesn't mean you couldn't support a version in your own repository or the AUR no matter what anyone else does. Yes, it is a lot of work. Stephen E. Baker
[2012-08-15 03:35:15 +0200] Felipe Contreras:
it became clear I was on my own
Isn't life tough? And seriously, who do you think gives a damn about platitudes like
If you have a problem you will not be able to open a script and figure out what is happening, and perhaps modify it, and debug it.
anymore? Even "discussions" here have gone past that argument. How about before writing to this list next time you read it for a while and see if you can learn a thing or two?
I was expecting more from the Arch Linux community
Believe me, we were expecting more from you too. -- Gaetan
I tried systemd a while ago in a brand new machine with Arch Linux and the boot was *much slower*
It can be slower on embedded too, the reason is suspected to be maxing out a cheap processor. We are talking about instant on here which is only an issue if systemd becomes a requirement which it will never be for Linux but maybe without forking Arch or switching. -- _______________________________________________________________________ 'Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface' (Doug McIlroy) _______________________________________________________________________
participants (22)
-
Alexandre Ferrando
-
Anthony ''Ishpeck'' Tedjamulia
-
Baho Utot
-
Brandon Watkins
-
C Anthony Risinger
-
Denis A. Altoé Falqueto
-
Felipe Contreras
-
Gaetan Bisson
-
Geoff
-
Jason Ryan
-
John K Pate
-
Justin Strickland
-
Kevin Chadwick
-
Leon Feng
-
ludovic coues
-
Nicholas MIller
-
Oon-Ee Ng
-
Sander Jansen
-
Sebastian Günther
-
Stephen E. Baker
-
Tom Gundersen
-
Øyvind Heggstad