User talk:Gabx

From ArchWiki
Jump to: navigation, search

Static IP network

Please see systemd-networkd discussion page here:

Systemd/cron functionality

Hi, can you please explain your recent edits to Systemd/cron functionality? I suppose you're trying to address the Accuracy tag that was at the top of the section, but other users are interested in following the changes to the page, and diffs like this are impossible to understand, as you can see; also you should make use of the Edit Summary for every edit, like everybody else is doing. Thank you. -- Kynikos (talk) 02:27, 7 July 2014 (UTC)

Hi. After a recent work on my box while croning services with systemd, I realized this article was totally inaccurate. You are right, these are huge diffs, but wiki reflects now how this functionality can be used.I had no idea about how to deal with this massive change and integrate the old version into the new. As for the edit, you are right. I usually do it (and you can see it) but totally forgot it yesterday. Please apologize for this lack of edit.-- Gabx (talk) 06:40, 7 July 2014 (UTC)
I must question question the improvement over the previous version (which was "inaccurate" anyway):
  • The last section relies on instructions you removed, and this will not help at all.
  • Removing inaccurate section without explanation is wrong, no matter what is provided instead.
  • Systemd/cron_functionality#Timer_unit_options only duplicates systemd.timer(5), it can be (and was) just linked to.
  • The basic example is wrong, it would work only on a server that has 24/7 uptime. If you reboot frequently, for example daily, the timer will activate daily (15 minutes after each boot). This is what the Persistent and OnCalendar options are for, and one more reason the previous version was "better".
Sorry, but I don't see any improvement at all.
-- Lahwaacz (talk) 09:01, 7 July 2014 (UTC)
As mentioned, the writing of this article is not yet finished. So you are right, the last section needs to be modified. The original document mentionned the creation of lots of unuseful timer target folders; the way the timer + the service were activated was inacurate; the wanted targets were inacurates; I do think overall lots of stuff were wrong and aged. Yes, in the cited example, service will activate on every boot. So maybe a better example can be given, but let me remind you two things : even if Arch can be used as a server, I do think its primary goal is more desktop oriented, then it is quite unsual to reboot a server daily. Now feel free to reverse to old version if you think my writing is misleading readers.Gabx (talk) 09:34, 7 July 2014 (UTC)
What does it mean "not finished"? Wiki articles are hardly ever finished; do you have any specific plans?
The previous approach based on {daily,weekly,monthly} targets was just marked as "counter-productive", meaning there is supposed to be a better approach. Unfortunately a bug regarding the AccuracySec option apparently comes with its implementation (read the talk page and the linked thread on arch-general ML), so updating the wiki is not as straightforward as one might think. There are obviously many different examples to be described, but please do more research before rewriting wiki articles this extensively.
-- Lahwaacz (talk) 09:57, 7 July 2014 (UTC)
Edit: (written before reading the next reply) I have reverted to the old revision and then re-added your 'Timer units' and 'Basic example' sections, this has been quicker than re-adding the removed information. I have omitted the 'Timer unit options' section as it was only duplicating the man page, reference to it has been added instead. -- Lahwaacz (talk) 10:33, 7 July 2014 (UTC)
wiki are hardly finished, I agree. My plan was to thereafter detail the updatedb, man-db, logrotate and shadow service timers. When reading your ML thread, I could remark this : "The timer configuration _should be_ one-to-one equivalent to a crontab, except for a different syntax..." (Carl Schaefer). That is exactly what was not correctly pointed in the previous wiki version. The mentioned bug report doesn't seem to raise any interest.
Now as a more general approach regarding systemd functionalities, they are moving and improving at a very fast pace. So shall we choose to write nothing (or a few) on WIKI because the functionallity is new and can be subjected to changes? Shall we wait for a large upstream use before we write any WIKI? These are usually quickly modified by users in case of inacurate informations. As a good example, please have a look at systemd-networkd wiki. I wrote most part of it even if this functionality is quite new. Looking at the history, you will see thereafter some changes, and now it seems to me Arch has a nice systemd-netword WIKI, whereas these kind of documentation are very spare across the web.
Last, everything I already wrote on any WIKI has been first tested and used successfuly on my machine. The machine is 100% Arch Vanilla, with no fancy hacks, updated and all setings are upstream ones. I am on the systemd-dev list and read alot. So please, do not underestimate my knowledges and be sure I document myself before writing anything. Again, feel free to reverse my changes.Gabx (talk) 10:28, 7 July 2014 (UTC)
Note that the logrotate, man-db and shadow timers/services have been removed after being included in core packages [1].
I have re-added the "inaccurate" section wich "counter-productive" suggestions because, IMHO, your changes did not address the real issue. (Of course feel free to correct me.)
I'm not questioning your past/future work on the wiki, just please use the edit summary properly.
-- Lahwaacz (talk) 10:47, 7 July 2014 (UTC)
@Lahwaacz Very well done, thank you!
@Gabx I'm just replying to some points of your answer to my initial post:
> "I had no idea about how to deal with this massive change and integrate the old version into the new."
We invite users to discuss massive changes in talk pages first, so that's what I suggest you to do next time (in this case you would have also noticed Talk:Systemd/cron_functionality#Counterproductive_Suggestions).
> "As for the edit, you are right. I usually do it (and you can see it) but totally forgot it yesterday."
By looking at Special:Contributions/Gabx it seems you forget very often. I suggest you to go to your Preferences > Editing and enable Prompt me when entering a blank edit summary: you will get the habit of entering a summary very soon ;)
-- Kynikos (talk) 12:23, 7 July 2014 (UTC)
> discuss massive changes in talk pages first
I will
> I suggest you to go to your Preferences Editing and enable Prompt me when entering a blank edit summary
done Gabx (talk) 12:29, 7 July 2014 (UTC)

BTRFS page changes

Your changes are causing a lot of problems. People are coming into the forums looking for help when things things aren't working right. Specifically creating /etc as a totally separate subvol is a really bad idea. Scimmia (talk) 16:13, 14 April 2015 (UTC)

snapshoting /etc is not a bad idea. One feature of btrfs is to easily take snapshot of vital directories, and /etc is one. Here we are talking of subvolumes, NOT partitions. Gabx (talk)
I didn't say that snapshotting /etc was a bad idea, I said that making it a totally separate subvol is a bad idea. To make it work right, you'll also need to mount it in the initramfs. I don't know what you have against child subvols.
Scimmia (talk) 16:53, 14 April 2015 (UTC)
Also see
Scimmia (talk) 17:19, 14 April 2015 (UTC)
not sure what you call btrfs child, but in case you talk about nested subvolume, there is a long thread in Btrfs mailing list about how it is NOT recommended to nest subvolumes.Gabx (talk)
Their wiki suggests otherwise. This is one of the advantages of subvols over partitions or of btrfs over lvm. Either way, your layout causes problems.
Scimmia (talk) 17:28, 14 April 2015 (UTC)

Ensure your contributions work on Arch Linux

Please check any advice you give on an Arch Linux machine before posting here. I'm specifically discussing this edit where you recommend iptables-apply. Unfortunately, that executable is not provided on Arch Linux machines, so your edit has been removed. See here for details on this rule. -- Rdeckard (talk) 16:19, 29 January 2018 (UTC)