[arch-general] How to disable systemd-tmpfiles-clean.timer
Since a recent update (I have first noticed a couple of weeks ago this new systemd enhancement), systemd started to automatically clean /tmp directory daily. This is not something that I like as I prefer to decide when to clean up and to manually perform the clean up. I have tried systemctl stop systemd-tmpfiles-clean.timer systemctl disable systemd-tmpfiles-clean.timer The disabling apparently did not survived a reboot and the undesired systemd service came back. I guess that I could mess with tmpfiles-clean config file but I am just not interested in the service at all. What is the sure way method to disable it for good? thank you,
On Thu, May 8, 2014 at 3:43 PM, Olivier Langlois < olivier@olivierlanglois.net> wrote:
Since a recent update (I have first noticed a couple of weeks ago this new systemd enhancement), systemd started to automatically clean /tmp directory daily. This is not something that I like as I prefer to decide when to clean up and to manually perform the clean up.
I have tried
systemctl stop systemd-tmpfiles-clean.timer systemctl disable systemd-tmpfiles-clean.timer
The disabling apparently did not survived a reboot and the undesired systemd service came back.
I guess that I could mess with tmpfiles-clean config file but I am just not interested in the service at all. What is the sure way method to disable it for good?
thank you,
Try: systemctl mask systemd-tmpfiles-clean.timer Should definitely work. -- Savyasachee Jha *"Aerodynamics is for people whodon't know how to build engines."*
On 8 May 2014 09:43, Olivier Langlois <olivier@olivierlanglois.net> wrote:
Since a recent update (I have first noticed a couple of weeks ago this new systemd enhancement), systemd started to automatically clean /tmp directory daily. This is not something that I like as I prefer to decide when to clean up and to manually perform the clean up.
I'm sorry I don't have a solution to your problem (which is also mine as I tend to keep a lot of files in /tmp...) but the invasiveness of systemd is just outrageous and, allow me to say, not KISS at all, i.e. do one thing and do it well [0]. First it was udev, next dbus, then journal logs, then timers, now automatic /tmp cleaning. What's next, mandatory reboot on each update? This is not a rant against Arch or its devs and community, but against systemd; the sad facts speak for themselves. [0] http://boycottsystemd.org/ -- X https://aur.archlinux.org/packages/?SeB=m&K=nous http://tiny.cc/linux-pf
On Thu, May 8, 2014 at 9:46 AM, Christos Nouskas <nous@archlinux.us> wrote:
On 8 May 2014 09:43, Olivier Langlois <olivier@olivierlanglois.net> wrote:
Since a recent update (I have first noticed a couple of weeks ago this new systemd enhancement), systemd started to automatically clean /tmp directory daily. This is not something that I like as I prefer to decide when to clean up and to manually perform the clean up.
I'm sorry I don't have a solution to your problem (which is also mine as I tend to keep a lot of files in /tmp...) but the invasiveness of systemd is just outrageous and, allow me to say, not KISS at all, i.e. do one thing and do it well [0]. First it was udev, next dbus, then journal logs, then timers, now automatic /tmp cleaning. What's next, mandatory reboot on each update?
This is not a rant against Arch or its devs and community, but against systemd; the sad facts speak for themselves.
[0] http://boycottsystemd.org/
-- X https://aur.archlinux.org/packages/?SeB=m&K=nous http://tiny.cc/linux-pf
Please don't start another systemd flamewar. And BTW, automatic /tmp cleaning was there since the beginning.
On Thursday 08 May 2014 09:53:41 Lukas Jirkovsky wrote:
On Thu, May 8, 2014 at 9:46 AM, Christos Nouskas <nous@archlinux.us> wrote:
On 8 May 2014 09:43, Olivier Langlois <olivier@olivierlanglois.net> wrote:
Since a recent update (I have first noticed a couple of weeks ago this new systemd enhancement), systemd started to automatically clean /tmp directory daily. This is not something that I like as I prefer to decide when to clean up and to manually perform the clean up.
The /tmp directory is intended for temporary files, after all. If you need them to stick around, I'd recommend using /var/tmp. But yeah, masking the unit file should solve this for you, I think.
I'm sorry I don't have a solution to your problem (which is also mine as I tend to keep a lot of files in /tmp...) but the invasiveness of systemd is just outrageous and, allow me to say, not KISS at all, i.e. do one thing and do it well [0]. First it was udev, next dbus, then journal logs, then timers, now automatic /tmp cleaning. What's next, mandatory reboot on each update?
For those of us that run systems that are up for months at a time between reboots, relying on a reboot to clean out the cruft that accumulates in /tmp is not too elegant. Bear in mind that systemd itself is a set of separate tools, each performing one job and performing it well, in the UNIX tradition. It just so happens that the task that the systemd init daemon does is to manage and run many unit files (each doing one thing and doing it well), resulting in a well-managed system, in the UNIX tradition. Paul
-----Original Message----- From: arch-general [mailto:arch-general-bounces@archlinux.org] On Behalf Of Lukas Jirkovsky Sent: Thursday, May 08, 2014 3:54 AM
Please don't start another systemd flamewar. And BTW, automatic /tmp cleaning was there since the beginning.
I agree to not start a flamewar but hopefully systemd devs do not consider their SW as perfect and are looking to improve it by taking into consideration the userbase complains about it. Maybe automatic /tmp cleaning was there since the beginning but it appears that it never worked on my systems until very recently after using ArchLinux for over 2 years.
-----Original Message----- From: arch-general [mailto:arch-general-bounces@archlinux.org] On Behalf Of Paul Gideon Dann Sent: Thursday, May 08, 2014 5:26 AM
On Thursday 08 May 2014 09:53:41 Lukas Jirkovsky wrote:
On Thu, May 8, 2014 at 9:46 AM, Christos Nouskas <nous@archlinux.us> wrote:
On 8 May 2014 09:43, Olivier Langlois <olivier@olivierlanglois.net> wrote:
Since a recent update (I have first noticed a couple of weeks ago this new systemd enhancement), systemd started to automatically clean /tmp directory daily. This is not something that I like as I prefer to decide when to clean up and to manually perform the clean up.
The /tmp directory is intended for temporary files, after all. If you need them to stick around, I'd recommend using /var/tmp. But yeah, masking the unit file should solve this for you, I think.
I was forecasting that this comment would come when I wrote the original request. While I agree with what you say, I think that it is reasonable to let the user have the control over when it is cleaned. Without denaturing the /tmp folder, I'm using it to experiment patches on some packages or launch computation and store results into /tmp to return back at them the next morning. I have been a bit shocked to find out one morning that my files have been deleted by my system. IMHO, this goes against the rule of least surprise which is a pillar of the unix philosophy. I understand that for some sysadmins it might be convenient to have an automatic cleanup but IMHO they should explicitly set it up. I am not too sure that this is a good default behavior. That being said, I'll try to mask the service. Thank you very much for your replies. Greetings, Olivier Please ignore the confidentiality notice below. It is automatically added without my consent. ________________________________ CONFIDENTIALITY : This e-mail and any attachments are confidential and may be privileged. If you are not a named recipient, please notify the sender immediately and do not disclose the contents to another person, use it for any purpose or store or copy the information in any medium.
On 08/05/14 11:44 AM, LANGLOIS Olivier PIS -EXT wrote:
-----Original Message----- From: arch-general [mailto:arch-general-bounces@archlinux.org] On Behalf Of Lukas Jirkovsky Sent: Thursday, May 08, 2014 3:54 AM
Please don't start another systemd flamewar. And BTW, automatic /tmp cleaning was there since the beginning.
I agree to not start a flamewar but hopefully systemd devs do not consider their SW as perfect and are looking to improve it by taking into consideration the userbase complains about it.
Maybe automatic /tmp cleaning was there since the beginning but it appears that it never worked on my systems until very recently after using ArchLinux for over 2 years.
Several of the Arch developers are systemd developers, so it's not like you're talking about a group of outsiders here. The /tmp cleaning doesn't delete recently touched files (10 days), so perhaps you've never noticed it before.
-----Original Message----- From: arch-general [mailto:arch-general-bounces@archlinux.org] On Behalf Of Paul Gideon Dann Sent: Thursday, May 08, 2014 5:26 AM
On Thursday 08 May 2014 09:53:41 Lukas Jirkovsky wrote:
On Thu, May 8, 2014 at 9:46 AM, Christos Nouskas <nous@archlinux.us> wrote:
On 8 May 2014 09:43, Olivier Langlois <olivier@olivierlanglois.net> wrote:
Since a recent update (I have first noticed a couple of weeks ago this new systemd enhancement), systemd started to automatically clean /tmp directory daily. This is not something that I like as I prefer to decide when to clean up and to manually perform the clean up.
The /tmp directory is intended for temporary files, after all. If you need them to stick around, I'd recommend using /var/tmp. But yeah, masking the unit file should solve this for you, I think.
I was forecasting that this comment would come when I wrote the original request. While I agree with what you say, I think that it is reasonable to let the user have the control over when it is cleaned. Without denaturing the /tmp folder, I'm using it to experiment patches on some packages or launch computation and store results into /tmp to return back at them the next morning. I have been a bit shocked to find out one morning that my files have been deleted by my system. IMHO, this goes against the rule of least surprise which is a pillar of the unix philosophy.
Use your home directory. /tmp is a dangerous place since it's a shared, world-writable ephemeral directory. The only things that are stored there are temporary files used by currently open applications. In most cases, $XDG_RUNTIME_DIR is a better choice (sockets, fifos, etc.).
I understand that for some sysadmins it might be convenient to have an automatic cleanup but IMHO they should explicitly set it up. I am not too sure that this is a good default behavior.
It's good default behaviour, as long as you aren't abusing /tmp for stuff it's not meant for.
That being said, I'll try to mask the service. Thank you very much for your replies.
You can override the /usr/lib/tmpfiles.d/tmp.conf file in /etc/tmpfiles.d and get rid of the cleaning.
On Thu, May 08, 2014 at 03:44:51PM +0000, LANGLOIS Olivier PIS -EXT wrote:
I was forecasting that this comment would come when I wrote the original request. While I agree with what you say, I think that it is reasonable to let the user have the control over when it is cleaned. Without denaturing the /tmp folder, I'm using it to experiment patches on some packages or launch computation and store results into /tmp to return back at them the next morning. I have been a bit shocked to find out one morning that my files have been deleted by my system. IMHO, this goes against the rule of least surprise which is a pillar of the unix philosophy.
You should create a temporary directory under /tmp for your experiment. Put a file in /etc/tmpfiles.d/mydir.conf with this content: d /tmp/mydirectory mode uid gid and work under that directory; systemd won't clean it. For more information: $ man 5 tmpfiles.d
On 08/05/14 03:46 AM, Christos Nouskas wrote:
On 8 May 2014 09:43, Olivier Langlois <olivier@olivierlanglois.net> wrote:
Since a recent update (I have first noticed a couple of weeks ago this new systemd enhancement), systemd started to automatically clean /tmp directory daily. This is not something that I like as I prefer to decide when to clean up and to manually perform the clean up.
I'm sorry I don't have a solution to your problem (which is also mine as I tend to keep a lot of files in /tmp...) but the invasiveness of systemd is just outrageous and, allow me to say, not KISS at all, i.e. do one thing and do it well [0]. First it was udev, next dbus, then journal logs, then timers, now automatic /tmp cleaning. What's next, mandatory reboot on each update?
The Arch developers decided to use it for timer units and logs, not anyone else. It's still the same udev it always was, and dbus is moving into the kernel, not systemd (systemd interacts with it as a client and provides a compatibility layer for yet to be updated processes). I guess you'll be upset that Tom (one of the Arch developers) wrote systemd-networkd. You'll probably also be upset that there's going to be a simple systemd-console from the kmscon developer (who is an Arch user) and a systemd-timesyncd for basic NTP clients not needing a full blown server with complicated RTC handling. Everyone else will continue on with their lives, because they realize that there's nothing wrong with maintaining more than one binary/library under one version control repository.
This is not a rant against Arch or its devs and community, but against systemd; the sad facts speak for themselves.
This is a rant against the Arch devs and the Arch community. Several of the developers and several people involved with the community are systemd developers, and there is certainly consensus among the Arch developers and trusted users to use systemd.
There are no facts there. I already responded to this FUD on reddit: http://www.reddit.com/r/archlinux/comments/24zj10/what_are_the_benefits_of_p...
This is not a rant against Arch or its devs and community, but against systemd; the sad facts speak for themselves.
This is a rant against the Arch devs and the Arch community. Several of the developers and several people involved with the community are systemd developers, and there is certainly consensus among the Arch developers and trusted users to use systemd.
This sounds really bad. Ranting against systemd should never be taken as ranting against Arch in general or some specific Arch developers. After all, Arch Linux is a Linux distribution, not a systemd distribution. ;) Systemd was chosen for some important reasons, I support this decision, but it shouldn't be considered a holy grail. The holy grail is pacman, and anyone who rants against pacman rants against Arch devs and community! ;-) -- Kind regards, Damian Nowak StratusHost www.AtlasHost.eu
On 08/05/14 05:01 PM, Nowaker wrote:
This is not a rant against Arch or its devs and community, but against systemd; the sad facts speak for themselves.
This is a rant against the Arch devs and the Arch community. Several of the developers and several people involved with the community are systemd developers, and there is certainly consensus among the Arch developers and trusted users to use systemd.
This sounds really bad. Ranting against systemd should never be taken as ranting against Arch in general or some specific Arch developers. After all, Arch Linux is a Linux distribution, not a systemd distribution. ;) Systemd was chosen for some important reasons, I support this decision, but it shouldn't be considered a holy grail. The holy grail is pacman, and anyone who rants against pacman rants against Arch devs and community! ;-)
Some of the Arch developers are pacman developers, and others are systemd developers. Both projects are part of the base install and are a significant part of the distributions flavour. The msys2 project uses pacman on Windows, so it's not really any more specific to Arch than systemd. Bashing an open-source project and spreading FUD about it is always an attack on the open-source community, whether it's GNOME, systemd, KDE, PHP, or something else. It's one thing to take a rational look at a project and criticize it, and quite another to promote content accusing the developers of having bad faith without *any* evidence.
I guess you'll be upset that Tom (one of the Arch developers) wrote systemd-networkd.
You guess wrong.
You'll probably also be upset that there's going to be a simple systemd-console from the kmscon developer (who is an Arch user) and a systemd-timesyncd for basic NTP clients not needing a full blown server with complicated RTC handling.
Again wrong. Unless they're enabled by default.
Everyone else will continue on with their lives, because they realize that there's nothing wrong with maintaining more than one binary/library under one version control repository.
Don't escalate and don't make it personal. You're just guessing wrong; I don't mind running systemd, unless it decides what's best for me without asking me. Clearing /tmp is one of those annoying things. I've also been annoyed by the fact that I have a PC that won't boot with systemd>198-2, because systemd can't mount /usr/local (which is empty). On the other hand I do love the _netdev & x-systemd.automount directives in /etc/fstab.
This is a rant against the Arch devs and the Arch community.
Wrong yet again. It isn't. I didn't say "The Arch and systemd devs are this and that", I just pointed out some facts about *systemd* that I find annoying and this has nothing to do with the developers themselves, for crying out loud! Are you suggesting people should just shut up and never voice an unfavourable opinion? Or you'd rather prefer a court of flatterers praising how perfect this world is?
Several of the developers and several people involved with the community are systemd developers, and there is certainly consensus among the Arch developers and trusted users to use systemd.
Which makes systemd perfect how exactly? Anyway, if I've offended anyone I offer them my apologies. -- X https://aur.archlinux.org/packages/?SeB=m&K=nous http://tiny.cc/linux-pf
On 08/05/14 05:10 PM, Christos Nouskas wrote:
I guess you'll be upset that Tom (one of the Arch developers) wrote systemd-networkd.
You guess wrong.
So you're okay with it providing networking, but not timer units? Timer units were a very simple addition on top of the existing event loop, while networkd is a significant project.
You'll probably also be upset that there's going to be a simple systemd-console from the kmscon developer (who is an Arch user) and a systemd-timesyncd for basic NTP clients not needing a full blown server with complicated RTC handling.
Again wrong. Unless they're enabled by default.
The systemd console would replace the virtual terminals provided by the kernel. The NTP client might make sense as something enabled by default, although I don't know if it's planned to be.
Everyone else will continue on with their lives, because they realize that there's nothing wrong with maintaining more than one binary/library under one version control repository.
Don't escalate and don't make it personal. You're just guessing wrong; I don't mind running systemd, unless it decides what's best for me without asking me. Clearing /tmp is one of those annoying things.
I'm don't see how I'm making it personal with a bit of sarcasm. You already made it quite personal by promoting FUD with gems like this:
systemd's team is noticeably chauvinistic
Do you think Tom and Dave are chauvanistic? Or did you not really read what you linked to?
I've also been annoyed by the fact that I have a PC that won't boot with systemd>198-2, because systemd can't mount /usr/local (which is empty).
I'm not sure what you mean by this.
On the other hand I do love the _netdev & x-systemd.automount directives in /etc/fstab.
This is a rant against the Arch devs and the Arch community.
Wrong yet again. It isn't. I didn't say "The Arch and systemd devs are this and that", I just pointed out some facts about *systemd* that I find annoying and this has nothing to do with the developers themselves, for crying out loud! Are you suggesting people should just shut up and never voice an unfavourable opinion? Or you'd rather prefer a court of flatterers praising how perfect this world is?
No, I'm asking you to stop spreading misinformation and attacks on the developers behind the project (who also develop Arch Linux). If you interrupt a constructive thread with FUD, you can expect to be called out.
Several of the developers and several people involved with the community are systemd developers, and there is certainly consensus among the Arch developers and trusted users to use systemd.
Which makes systemd perfect how exactly?
No one said it's perfect.
Anyway, if I've offended anyone I offer them my apologies.
Do accept the fact that not everyone is content with everything systemd and just leave it at that. Thank you and bye. -- X https://aur.archlinux.org/packages/?SeB=m&K=nous http://tiny.cc/linux-pf
On 08/05/14 05:37 PM, Christos Nouskas wrote:
Do accept the fact that not everyone is content with everything systemd and just leave it at that. Thank you and bye.
That can be expressed without calling the developers chauvanistic and spreading misinformation. It's yet a free software project available to people who want it, and you can choose to use an alternative like runit instead.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 05/08/2014 05:22 PM, Daniel Micay wrote:
On 08/05/14 05:10 PM, Christos Nouskas wrote:
I guess you'll be upset that Tom (one of the Arch developers) wrote systemd-networkd.
You guess wrong.
So you're okay with it providing networking, but not timer units? Timer units were a very simple addition on top of the existing event loop, while networkd is a significant project.
You'll probably also be upset that there's going to be a simple systemd-console from the kmscon developer (who is an Arch user) and a systemd-timesyncd for basic NTP clients not needing a full blown server with complicated RTC handling.
Again wrong. Unless they're enabled by default.
The systemd console would replace the virtual terminals provided by the kernel. The NTP client might make sense as something enabled by default, although I don't know if it's planned to be.
Everyone else will continue on with their lives, because they realize that there's nothing wrong with maintaining more than one binary/library under one version control repository.
Don't escalate and don't make it personal. You're just guessing wrong; I don't mind running systemd, unless it decides what's best for me without asking me. Clearing /tmp is one of those annoying things.
I'm don't see how I'm making it personal with a bit of sarcasm.
You already made it quite personal by promoting FUD with gems like this:
systemd's team is noticeably chauvinistic
Do you think Tom and Dave are chauvanistic? Or did you not really read what you linked to?
I've also been annoyed by the fact that I have a PC that won't boot with systemd>198-2, because systemd can't mount /usr/local (which is empty).
I'm not sure what you mean by this.
On the other hand I do love the _netdev & x-systemd.automount directives in /etc/fstab.
This is a rant against the Arch devs and the Arch community.
Wrong yet again. It isn't. I didn't say "The Arch and systemd devs are this and that", I just pointed out some facts about *systemd* that I find annoying and this has nothing to do with the developers themselves, for crying out loud! Are you suggesting people should just shut up and never voice an unfavourable opinion? Or you'd rather prefer a court of flatterers praising how perfect this world is?
No, I'm asking you to stop spreading misinformation and attacks on the developers behind the project (who also develop Arch Linux). If you interrupt a constructive thread with FUD, you can expect to be called out.
Several of the developers and several people involved with the community are systemd developers, and there is certainly consensus among the Arch developers and trusted users to use systemd.
Which makes systemd perfect how exactly?
No one said it's perfect.
Anyway, if I've offended anyone I offer them my apologies.
To all, Don't make any of this personal. In addition, I hope the inclusion of systemd in Arch Linux has more justification than just some Arch developers are also Systemd developers. Arch may not be a democracy, but it's not supposed to be infested with cronyism either (I don't think it is). Let's all be calm and collected here and sort things out. Regards, Mark -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iF4EAREIAAYFAlNsYRUACgkQZ/Z80n6+J/Y52QEAhReqsw4fdGtGAPunRLmD3v8t +Yafv6/f0J4C/ytR8xYA/3QsLD6Pd/kyGGaIGyxeM1Z9Ay91cSuHzlhg11lW4/RB =IDYd -----END PGP SIGNATURE-----
On 09/05/14 01:01 AM, Mark Lee wrote:
To all,
Don't make any of this personal. In addition, I hope the inclusion of systemd in Arch Linux has more justification than just some Arch developers are also Systemd developers. Arch may not be a democracy, but it's not supposed to be infested with cronyism either (I don't think it is). Let's all be calm and collected here and sort things out.
Regards, Mark
I never stated that it was a reason for it being included in Arch Linux. You're misrepresenting what I said. The context of the thread is someone promoting content including a lot of inaccurate claims and ad hominem attacks like this: "systemd's team is noticeably chauvinistic and anti-Unix" and yet making this claim:
This is not a rant against Arch or its devs and community, but against systemd; the sad facts speak for themselves.
I was countering the claim by pointing out that the group of people they are disparaging includes several Arch developers and other prominent people in the community.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 05/09/2014 01:22 AM, Daniel Micay wrote:
On 09/05/14 01:01 AM, Mark Lee wrote:
To all,
Don't make any of this personal. In addition, I hope the inclusion of systemd in Arch Linux has more justification than just some Arch developers are also Systemd developers. Arch may not be a democracy, but it's not supposed to be infested with cronyism either (I don't think it is). Let's all be calm and collected here and sort things out.
Regards, Mark
I never stated that it was a reason for it being included in Arch Linux.
You're misrepresenting what I said.
The context of the thread is someone promoting content including a lot of inaccurate claims and ad hominem attacks like this: "systemd's team is noticeably chauvinistic and anti-Unix" and yet making this claim:
This is not a rant against Arch or its devs and community, but against systemd; the sad facts speak for themselves.
I was countering the claim by pointing out that the group of people they are disparaging includes several Arch developers and other prominent people in the community.
To Daniel, I'm pointing out that respect for people shouldn't affect technical skepticism. People can rant against whomever they want as long as it has technical criticism (at least on this mailing list). Hence, don't make anything personal. Regards, Mark -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iF4EAREIAAYFAlNsZ60ACgkQZ/Z80n6+J/a4MAD/f80apvVb66cYD/cwAC4u7mjZ g4lKktVoRiMwer4wqv4A/2+5+pf3RIGuQItDZNFaUP8wVAbTnW50iH1uvPwMt53T =kt7h -----END PGP SIGNATURE-----
On 09/05/14 01:29 AM, Mark Lee wrote:
To Daniel,
I'm pointing out that respect for people shouldn't affect technical skepticism. People can rant against whomever they want as long as it has technical criticism (at least on this mailing list).
Accusing the developers of bad faith and spreading misinformation about the project is not technical skepticism. I'll quote one of my earlier statements:
Bashing an open-source project and spreading FUD about it is always an attack on the open-source community, whether it's GNOME, systemd, KDE, PHP, or something else. It's one thing to take a rational look at a project and criticize it, and quite another to promote content accusing the developers of having bad faith without *any* evidence.
Hence, don't make anything personal.
Regards, Mark
You're implying that I've made it personal, but I don't think I've done any such thing. What have I said that you think is venturing into the land of a personal attack?
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 05/09/2014 01:41 AM, Daniel Micay wrote:
On 09/05/14 01:29 AM, Mark Lee wrote:
To Daniel,
I'm pointing out that respect for people shouldn't affect technical skepticism. People can rant against whomever they want as long as it has technical criticism (at least on this mailing list).
Accusing the developers of bad faith and spreading misinformation about the project is not technical skepticism. I'll quote one of my earlier statements:
Bashing an open-source project and spreading FUD about it is always an attack on the open-source community, whether it's GNOME, systemd, KDE, PHP, or something else. It's one thing to take a rational look at a project and criticize it, and quite another to promote content accusing the developers of having bad faith without *any* evidence.
Hence, don't make anything personal.
Regards, Mark
You're implying that I've made it personal, but I don't think I've done any such thing. What have I said that you think is venturing into the land of a personal attack?
To Daniel, Regarding, your "personal attack". I inferred a personal attack when you claimed that the Arch developers were also SystemD developers and were well respected. It seemed to me like you were peer pressuring the fellow into withdrawing the issue by belittling his credentials in comparison to a community and powerful developers. This looked like a David vs. Goliath situation to me; we shouldn't ever be forcing Archers with questions in this situation. The opinion of a user should be just as valuable as the opinion of a developer. There are right ways to handle things and wrong ways. The Archer had a technical issue and an opinion. Solving the technical issue is more important. We can usually just ignore the opinion. This may seem hypocritical that I'm typing this (since this doesn't solve the issue for the Archer), so it'll be the last response I make regarding a person's opinionated response (at least on this thread). With that in mind, I hope the issue's solved for the Archer. Regards, Mark -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iF4EAREIAAYFAlNsb14ACgkQZ/Z80n6+J/ZN3AD9FjVt91gtQMR/Jrf3UKb9Ac9B 3uRz27Jx2f6U/PmTqGoA/2r/9EEG6RgPvzWN0b24fpLz4fVH4C7kjWi5U9L0oynM =OSef -----END PGP SIGNATURE-----
On 09/05/14 02:02 AM, Mark Lee wrote:
On 05/09/2014 01:41 AM, Daniel Micay wrote:
On 09/05/14 01:29 AM, Mark Lee wrote:
To Daniel,
I'm pointing out that respect for people shouldn't affect technical skepticism. People can rant against whomever they want as long as it has technical criticism (at least on this mailing list).
Accusing the developers of bad faith and spreading misinformation about the project is not technical skepticism. I'll quote one of my earlier statements:
Bashing an open-source project and spreading FUD about it is always an attack on the open-source community, whether it's GNOME, systemd, KDE, PHP, or something else. It's one thing to take a rational look at a project and criticize it, and quite another to promote content accusing the developers of having bad faith without *any* evidence.
Hence, don't make anything personal.
Regards, Mark
You're implying that I've made it personal, but I don't think I've done any such thing. What have I said that you think is venturing into the land of a personal attack?
To Daniel,
Regarding, your "personal attack". I inferred a personal attack when you claimed that the Arch developers were also SystemD developers and were well respected. It seemed to me like you were peer pressuring the fellow into withdrawing the issue by belittling his credentials in comparison to a community and powerful developers. This looked like a David vs. Goliath situation to me; we shouldn't ever be forcing Archers with questions in this situation. The opinion of a user should be just as valuable as the opinion of a developer.
Calling the systemd developers "chauvanistic" and claiming they have bad faith is a personal attack. There was no issue raised by the person I'm replying to, only flaming and a link to more flamebait containing actual personal attacks and outright lies. They claimed attacking systemd was not attacking the Arch community, and I clearly quoted that part of their message and responded to it by stating that since prominent members of the community (including developers) are systemd developers, attacking the systemd developers *is* attacking the Arch developers. I get the impression that you only skimmed over the conversation or read the last few messages, because you seem to be missing the context.
There are right ways to handle things and wrong ways. The Archer had a technical issue and an opinion. Solving the technical issue is more important. We can usually just ignore the opinion. This may seem hypocritical that I'm typing this (since this doesn't solve the issue for the Archer), so it'll be the last response I make regarding a person's opinionated response (at least on this thread).
With that in mind, I hope the issue's solved for the Archer.
Regards, Mark
The person I responded to is not the one asking a technical question. Here is the first message they sent to the list: https://mailman.archlinux.org/pipermail/arch-general/2014-May/036206.html It's not the original post with the technical issue. It's someone taking the time to link to FUD (ad hominem attacks on the systemd developers, hollow rhetoric and misinformation) because there was a post about systemd. Have you read the content of the link?
On 9 May 2014 00:22, Daniel Micay <danielmicay@gmail.com> wrote:
You already made it quite personal by promoting FUD with gems like this:
systemd's team is noticeably chauvinistic
Good grace, you pasted a quote I didn't make and made it appear as mine or as if I approved it, whilst I was very careful about which facts I *actually* agree with and quoted from the aforementioned site. Furthermore, you kept implying I made or endorsed that quote in all your subsequent posts, making it your chief argument. What kind of people do that? [0]
Do you think Tom and Dave are chauvanistic?
I've been an Archer since 2004 and I've never attacked anyone in our lists or the boards. It's not polite and it's not constructive. I also made it very very clear in my first post that I wasn't ranting against people. But sucking up to authority was always a fast way to the top, eh? To answer my own question [0]: those who end up in my "Trolls-Slanderers-Bigots-Fanatics" gmail trash filters. You match on all of them. Welcome and goodnight. -- X https://aur.archlinux.org/packages/?SeB=m&K=nous http://tiny.cc/linux-pf
On 08/05/14 03:40 PM, Daniel Micay wrote:
There are no facts there. I already responded to this FUD on reddit: http://www.reddit.com/r/archlinux/comments/24zj10/what_are_the_benefits_of_p...
Whoops, wrong link: http://www.reddit.com/r/programming/comments/23tyez/this_group_wants_to_revi...
Op 8 mei 2014 21:41 schreef "Daniel Micay" <danielmicay@gmail.com> het volgende:
[...]
and a systemd-timesyncd for basic NTP clients not needing a full blown server with complicated RTC handling.
Just for the record: that is what is called sntp (Simple ntp). Ntp is about clock sync, sntp just sets the clock. As long as it's used as any daemon, i'd ok with that being enabled by default; those can be simply disabled (remove symlink or systemctl disable), as i prefer a real ntp on my systems. mvg, Guus
Hi, On Thu, 08 May 2014 02:43:57 -0400 Olivier Langlois <olivier@olivierlanglois.net> wrote:
Since a recent update (I have first noticed a couple of weeks ago this new systemd enhancement), systemd started to automatically clean /tmp directory daily. This is not something that I like as I prefer to decide when to clean up and to manually perform the clean up.
I have tried
systemctl stop systemd-tmpfiles-clean.timer systemctl disable systemd-tmpfiles-clean.timer
The disabling apparently did not survived a reboot and the undesired systemd service came back.
I guess that I could mess with tmpfiles-clean config file but I am just not interested in the service at all. What is the sure way method to disable it for good?
systemd-tmpfiles-clean does more that just removing stuff from /tmp. So changing the config is the only way to go. Just copy /usr/lib/tmpfiles.d/tmp.conf to /etc/tmpfiles.d/ and modify it as you like... Cheers, -- Leonid Isaev GPG fingerprints: DA92 034D B4A8 EC51 7EA6 20DF 9291 EE8A 043C B8C4 C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D
participants (12)
-
Alessandro Doro
-
Christos Nouskas
-
Daniel Micay
-
Guus Snijders
-
LANGLOIS Olivier PIS -EXT
-
Leonid Isaev
-
Lukas Jirkovsky
-
Mark Lee
-
Nowaker
-
Olivier Langlois
-
Paul Gideon Dann
-
Savyasachee Jha