Difference between revisions of "ArchWiki talk:Reports"

From ArchWiki
Jump to: navigation, search
(User:Idomeneo1: re)
(User:Idomeneo1: re)
Line 166: Line 166:
::::::::The question was what is the difference between daemon and one-shot that requires the default daemon to be structurally separated from its flagged one-shot version, under separate headings.
::::::::The question was what is the difference between daemon and one-shot that requires the default daemon to be structurally separated from its flagged one-shot version, under separate headings.
::::::::[[User:Idomeneo1|Idomeneo1]] ([[User talk:Idomeneo1|talk]]) 14:53, 19 February 2014 (UTC)
::::::::[[User:Idomeneo1|Idomeneo1]] ([[User talk:Idomeneo1|talk]]) 14:53, 19 February 2014 (UTC)
:::::::::None in particular, that's why I was asking you to start a discussion in [[Talk:Network_Time_Protocol_daemon]] to find a shared solution that makes everybody happy. However I've started it instead, [[Talk:Network_Time_Protocol_daemon#New_structure.3F]], as discussing like this is not very productive. -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 13:38, 20 February 2014 (UTC)
::::For your information, Arch's default configuration for ntpd is not vulnerable to CVE-2013-5211 because {{ic|noquery}} disables responses for the {{ic|monlist}} command. If a user removes {{ic|noquery}} from their configuration, and does not add {{ic|disable monlist}}, then that user is vulnerable.
::::For your information, Arch's default configuration for ntpd is not vulnerable to CVE-2013-5211 because {{ic|noquery}} disables responses for the {{ic|monlist}} command. If a user removes {{ic|noquery}} from their configuration, and does not add {{ic|disable monlist}}, then that user is vulnerable.

Revision as of 13:38, 20 February 2014

In this page you can list:

  • Edits that a contributor made to the wiki without a proper explanation (that is what the Summary field is for) and whose validity you lack the knowledge to judge by yourself. In this case, please add a link to the edit in question with a brief explanation why you think it should be investigated. Consider contacting the contributor to ask for an explanation, which is often an effective way to solve these issues. Please report the eventual answer (if any) below the initial report. You can also link to a discussion already started in the talk page of the edited article.
  • Links to discussions started in talk pages requesting to add, delete, or modify some content in the respective articles which you do not have sufficient knowledge to answer definitively by yourself.

Please sign your edits and feel free to comment on others' reports. Discussions will be deleted 3 days after closing.

See ArchWiki:Spam to report vandalism.

New templates

Just a heads-up, if you're OK with them [1] [2] , please close the report :-) -- Karol 07:42, 14 December 2011 (EST)

If we start applying them consistently in all the tables, probably adding a proper rule in Help:Style, then I'm ok with them, since coloring cells in tables is not very straightforward even with wiki syntax.
Note their Chinese counterparts have been created too: Template:是 and Template:否. Since those templates' code is very flexible, I suggest replacing them with only 2 templates, Template:Y and Template:N, which would produce "Yes" and "No" by default, but whose first optional argument would allow them to display any other string, including translations, without the need to have localized versions of each template.
Going even a bit further, since some tables use additional colors, we may base the templates' names on their color instead of their meaning, so that we would have Template:G, Template:R, Template:Y, Template:B, and if necessary also Template:P and Template:O (purple and orange, just to complete the secondary colors). These templates should require the first argument, but I think they would be easy to use anyway, for sure much easier than the current | style="color:...." | blabla.
Waiting for opinions. -- Kynikos 09:19, 15 December 2011 (EST)
This template group would also give us an excuse to delete The Status Table Series and related templates, since they have a too narrow field of application and practically just create nested tables in the end, thus giving almost no real advantage. -- Kynikos 13:13, 24 December 2011 (EST)
I support this idea. Similar to the Template:Box COLOUR templates, a series of table cell coloured templates would ensure consistency across articles. -- pointone 16:46, 19 January 2012 (EST)
So good :) However I don't consider this an urgent task, I'm linking this discussion from a new entry among my numerous template ideas in my todo list. Of course if you or someone else want to implement it, just go for it. Just reminding that the implementation should be accompanied by some related style rules.
Also note that among my template-related ideas there's one about the Box COLOR series that seems to go in the opposite direction than the cell color templates, but I think that the colors for the Note, Warning and Tip templates should be reserved for them, and not be usable in other ways.
-- Kynikos 06:47, 20 January 2012 (EST)

Jumbo frames' "Real World Examples" section

Jumbo_Frames#Real_World_Examples <-- This section doesn't seem fitting on our wiki. This section just seems to be an advertisement for jumbo frames, and I think it should be removed. And I should also note that the methodology is a bit unreliable, in my opinion. To truly test just the difference that jumbo frames makes, one should make a RAM disk so hard disk performance is completely removed from the equation. And if we really want to sell people on switching to jumbo frames, I would rather we simply provide a one-liner plus a link to a technical white paper, IEEE conference paper, etc. Does anyone else agree?
-- Jstjohn (talk) 21:59, 4 June 2012 (UTC)

Well, I don't know if we can really consider that section as an advertisement, however it's true that benchmarking sections are not really Arch-specific, and would probably better fit a blog or some other kind of website, which could be linked from the article. A similar article is SSD Benchmarking, for example.
On the other hand it looks like an original work and I would hesitate a bit before simply deleting it, maybe moving the "Using Jumbo Frames on Arch Linux" section more to the top could be a start. User:Graysky seems to have added that section in 2009, he may be interested in discussing also about the reliability of the methodology, but I would do that in Talk:Jumbo Frames (possibly adding e.g. Template:Accuracy to the article), since this talk page is more used for discussing recent changes reports :)
-- Kynikos (talk) 15:26, 5 June 2012 (UTC)
Another alternative would be moving it to a sub-page, and having a link to it somewhere in the article.
-- thestinger (talk) 15:14, 7 June 2012 (UTC)
I just found this discussion. I do not feel that the examples I posted represent an advertisement in any way. They do represent a concrete example of leveraging the topic of the page on which they are written. They are a bit dated however. I agree with the RAM disk suggestion. If I get dome time over the weekend, I might update on more modern hardware under more controlled conditions.
-- Graysky (talk) 01:39, 12 October 2012 (UTC)

Pacnew_and_Pacsave_Files report

Original quick report:

[3]: what was wrong with the old script that was replaced?

I think the edit in question added just some error-checking and dependency-checking. As pacnew and pacidff files are often edited as root or with sudo, the script does additional check for that. I don't think it's a questionable edit. -- Karol (talk) 18:08, 1 February 2014 (UTC)

Honestly the only parts of the new script that I like are the diffed variable that makes it easier to change it to the preferred merge tool, and the pacsave alert at the end. About the rest, I think that always checking for the availability of the required programs (~1/3 of the script) is complete overkill for such a little script: it's uselessly run every time while it could be much more Simply left to the user, who is supposed to know what applications (s)he has installed; I think mentioning the required packages in the section intro would be more appropriate. Then there's the problem of replacing gksudo with plain sudo, which IIRC at least until some time ago was a discouraged practice. -- Kynikos (talk) 05:08, 2 February 2014 (UTC)

wpa_supplicant article

User:Idomeneo1 is creating another "Beginners' Guide", this time for networking: [4]. Specifically, these two edits got me started: [5], [6]. Talking to him was not very productive, and this is not a proper correction.

Anyone got the time (and nerves) to fix the wpa_supplicant article? If not, I'll do this next week after my last exam.

-- Lahwaacz (talk) 21:30, 6 February 2014 (UTC)

Uhm, dhcpcd-6.2.1 (which was pushed into the core repo yesterday) actually looks at /etc/wpa_supplicant/wpa_supplicant.conf. I still had 6.1.0 until today (I actually checked for updates before looking at the code, but the mirrors were probably not synced yet). So I might have been trolling after all... -- Lahwaacz (talk) 18:29, 7 February 2014 (UTC)
Coincidental indeed that dhcpcd update which brought the change. I looked up the commit and read over the changes. Bests for your exam. --Indigo (talk) 21:46, 7 February 2014 (UTC)

"Issue" -> "problem" updates

I don't know what to think about User:Notasynonym, every contribution of this user (fortunately they are not that many) is just a replacement of "issue" with "problem" (and modifications for plural). Are those valid edits? I find it rather uncomfortable... -- Lahwaacz (talk) 22:40, 11 February 2014 (UTC)

I'm not a native English speaker, my only guess is that he's doing it because "problem" is a more specific word, while "issue" can have other meanings. Maybe we can ask him? -- Kynikos (talk) 05:27, 12 February 2014 (UTC)
The name of the account suggests that the propaganda is "issue" and "problem" are not synonyms, which I just can't accept - even Github has issue pages. I think that in IT it cannot be confused with the other meanings. -- Lahwaacz (talk) 08:14, 12 February 2014 (UTC)
I've invited him to join this discussion. However I'd appreciate if also a third-party native English speaker shared his/her feelings about this issue... problem... matter! -- Kynikos (talk) 07:58, 13 February 2014 (UTC)
I'm a native English speaker. "issue" and "problem" are only synonyms in certain contexts. As a general rule of thumb, every "problem" is an "issue", but not every "issue" is a "problem".
Using User:Lahwaacz's GitHub example, GitHub chose the proper word for their system because GitHub's issue tracker is for reporting bugs, requesting new features, logging pull requests, asking general questions, etc. Of those, only bug reports are both "problems" and "issues"; the rest are simply "issues".
I skimmed over a couple of User:Notasynonym edit's. Of those I checked, they seem okay because the instances where he changed "issue" to "problem" are in the context of bugs or troubleshooting problems. I would have a major problem (hehe) with anyone blindly doing a search-and-replace of "issue" to "problem", but it does not appear that he is doing this.
Hope this helps!
-- Jstjohn (talk) 02:27, 14 February 2014 (UTC)
Thanks Jstjohn, I too think that those edits are acceptable. When patrolling them, I didn't pay attention to User:Notasynonym's username, which is probably the main reason that has made Lahwaacz suspicious: using "propaganda" usernames is indeed common practice among trolls, and still I don't understand why this user is using a separate account for this kind of edits, as if he thought himself they could generate criticism. -- Kynikos (talk) 00:51, 15 February 2014 (UTC)


I've been accused of trolling once again: User talk:Lahwaacz#Stop (please tell me I'm not...)

The discussion is about a series of edits to the Network Time Protocol daemon: [7], ..., [8], ..., [9]

I'm reporting User:Idomeneo1 for the last one -- I'm beginning to take it personally, so someone else should probably step in...

-- Lahwaacz (talk) 23:16, 15 February 2014 (UTC)

Stepped in. -- Kynikos (talk) 04:25, 16 February 2014 (UTC)

[Moving here the original discussion from User talk:Lahwaacz#Stop in order to have users discuss in only one place. -- Kynikos (talk) 02:40, 17 February 2014 (UTC)]

Lahwaacz, you appear to be trolling my edits. Please stop doing that.

Idomeneo1 (talk) 20:51, 15 February 2014 (UTC)

  1. Commands like systemctl enable ntpd do not belong into ArchWiki - see Help:Style#Daemon operations. The original wording was absolutely fine and compliant to the style guidelines.
  2. There is a fundamental difference in how the individual network managers use NTP: NetworkManager runs the daemon which stays running, whereas netctl and wicd synchronize only once.
  3. Why the hell is "Synchronize once per boot" under "Running as daemon"?
Reverting once again, sorry... Please do not edit articles outside your competence.
-- Lahwaacz (talk) 21:09, 15 February 2014 (UTC)
That is the difference between "ntpd" and "ntpd -q". Either can be used with any network manager hook.
I will change "Running as daemon" to "Running under systemd". I will also spell out the difference between "ntpd" and "ntpd -q", even though that could be gotten from man ntpd.
Idomeneo1 (talk) 21:44, 15 February 2014 (UTC)
Is there any common case where "Running as daemon" != "Running under systemd" these days? The ntpd-q command is described in Network_Time_Protocol_daemon#Using_without_daemon, what exactly is missing there? I can only think of the link to the man page :P
See also Help:Style#Hypertext metaphor, even copying from man page might be considered as duplicating external resources.
What exactly is your point here, to leave your trace on every bloody article on ArchWiki?!
-- Lahwaacz (talk) 22:04, 15 February 2014 (UTC)
The problem is that you appear to be muddying the difference between daemon and one-shot, and yes, I did mention man ntpd to you.
My "point" is to edit some of the more unreadable wiki articles, and improve them. As any editor does. I expect to be able to do that in a civil environment, and without being trolled.
Idomeneo1 (talk) 22:22, 15 February 2014 (UTC)
I'm well aware of the one-shot service type, note that the != operator I used is not commutative. It was meant as "...where Running as daemon does not mean Running under systemd" and not the other way round... And you did not mention the man page!
Unreadable is subjective. I find the Beginners' Guide being unreadable to me, even though I admit it contains correct information (until some first-time ArchWiki editor steps in and...). The point is to make ArchWiki readable for most of the readers, which is why I do not involve myself (much) in editing the Beginners' Guide. It is obvious that some compromises are necessary, specifically, ArchWiki assumes that the reader is acquainted with Help:Reading — which you clearly did not read since my last "trolling" — and that the editor is at least willing to gradually improve his knowledge of the Help:Style guidelines. I will not read it for you, but some sections for the start:
The Network Time Protocol daemon page is was perfectly fine before, you did not do anything else than changing a Help:Style-complying article into a non-complying one. I'm afraid I'll have to revert it again...
-- Lahwaacz (talk) 22:50, 15 February 2014 (UTC)
Right: "I will also spell out the difference between "ntpd" and "ntpd -q", even though that could be gotten from man ntpd."
You have not read my comments any more than you've read the edits you're reverting. You won't be happy with any edits.
That is not how a Wiki works.
Idomeneo1 (talk) 23:05, 15 February 2014 (UTC)
That's about just enough, you're reported: ArchWiki_talk:Reports#User:Idomeneo1. We shall see what the others have to say. -- Lahwaacz (talk) 23:19, 15 February 2014 (UTC)
Guys, please, let's try to work together in peace, ok? Discussing in this tone is only a waste of time for yourselves, and now also for me.
@Idomeneo1: please understand that Lahwaacz is not trolling, he's an official Maintainer who does lots of edits everywhere, and in this case he's trying to keep the article compliant with our style guidelines. If an edit is modified, or even reverted, because of style issues, it's pointless to redo it exactly the same way as before, right? :) It will never end that way...
We need to end this quarrel now and move back on to constructive collaboration, so I will take Idomeneo1's last edit as the whole matter of dispute and explain in details why it doesn't improve the article:
  1. Changing the # prompt to $ sudo is the opposite of what is recommended in Help:Style#Command_line_text.
  2. Giving basic systemctl examples conflicts with Help:Style#Daemon_operations.
  3. The title "Running as a daemon" is better than "Starting ntpd at boot" because:
    • a daemon cannot only be started at boot
    • the second title duplicates "ntpd" which is already the subject of the article
  4. Idomeneo1's section structure loses the clear distinction between the two main uses of ntpd: daemon and oneshot. Leaving the distinction to be understood by the user only by the presence or absence of the -q option is clearly insufficient, and this is also proved by the need for a note in "Run at network connection" that duplicates - and links to - the introduction of "Using without daemon".
Please accept this explanation, I will do the needed updates to the article, then please use that revision as a starting point for new, different, edits, without restarting edit wars, otherwise I'll be forced to protect the page. Thank you ^^
-- Kynikos (talk) 04:24, 16 February 2014 (UTC)

[At this point the discussion was continued directly in this talk page. -- Kynikos (talk) 02:40, 17 February 2014 (UTC)]

With ntp, isn't it daemon by default (ntpd)? Running it non-daemon is by flag (-q). Shouldn't the approach to the article, and its structure reflect this - it seems the network hooks could be configured either way.
Idomeneo1 (talk) 16:17, 16 February 2014 (UTC)
Unfortunately, there is a serious bug in the release (4.2.6) you use as a daemon right now. Things like this are exactly the reason why using it non-daemon should be the preference for most (and not only desktop) users. My suggestion would be you raise your ideas for expanding Network_Time_Protocol_daemon#Running_as_a_daemon in ntpd talk. --Indigo (talk) 18:59, 16 February 2014 (UTC)
I had actually taken out the daemon/non-daemon headings, because that was a matter of a flag - the default being the daemon. It could be set up either way, with or without the flag, in most circumstances.
If users at this point need to be warned away from using it as a daemon, that information should definitely be in the article, and the one-shot flag given along side it.
Idomeneo1 (talk) 21:20, 16 February 2014 (UTC)
Well, using netctl or wicd to start ntpd as a daemon wouldn't make much sense, that's why they're mentioned only in the oneshot section.
@Idomeneo1: Indigo has said the right thing: at this point, if you have an idea for a new structure, please first propose it in Talk:Network_Time_Protocol_daemon with clear supporting arguments.
I've added a warning about the mentioned vulnerability at the top of Network_Time_Protocol_daemon#Running_as_a_daemon.
-- Kynikos (talk) 03:06, 17 February 2014 (UTC)
The problem with this is that it begs the question can't you just set it up either way, with or without the flag. Presumably the bug will be fixed soon enough.
Running a daemon from a network manager does make sense if you need to sign into a network, and don't have de facto access right away when the NM is done with its job.
Other than this bug, what is the significant difference between the daemon and the one-shot?
Idomeneo1 (talk) 01:14, 18 February 2014 (UTC)
If you have an effective idea to restructure the article to show the ways to autostart ntpd independently from the daemon or oneshot usage, please outline it in Talk:Network_Time_Protocol_daemon.
I'm afraid I haven't uderstood your last question.
-- Kynikos (talk) 06:41, 19 February 2014 (UTC)
The question was what is the difference between daemon and one-shot that requires the default daemon to be structurally separated from its flagged one-shot version, under separate headings.
Idomeneo1 (talk) 14:53, 19 February 2014 (UTC)
None in particular, that's why I was asking you to start a discussion in Talk:Network_Time_Protocol_daemon to find a shared solution that makes everybody happy. However I've started it instead, Talk:Network_Time_Protocol_daemon#New_structure.3F, as discussing like this is not very productive. -- Kynikos (talk) 13:38, 20 February 2014 (UTC)
For your information, Arch's default configuration for ntpd is not vulnerable to CVE-2013-5211 because noquery disables responses for the monlist command. If a user removes noquery from their configuration, and does not add disable monlist, then that user is vulnerable.
I feel that running ntpd as a daemon should be the preferred method for most use cases, including laptop and desktop users (especially for those that leave their systems on for extended periods of time), and that the wiki article should place strong emphasis on not removing noquery from their configuration.
-- Jstjohn (talk) 06:53, 18 February 2014 (UTC)
+1 for bug analysis and neutrality, I added the related ML link from the maintainer to the page yesterday and tweaked the bit where "noquery" appears first today. It is a work-around for a vulnerability of an otherwise valid server/daemon side option. Once the package gets another stable, the warning in the related edits can imo be quietly dropped and all is good to roll on. --Indigo (talk) 12:53, 18 February 2014 (UTC)
I just added some information about what makes a configuration vulnerable to the DDoS exploit [10] (mostly a copy+paste of my response above).
I think we should leave a warning in place for at least a month or so after Arch packages a new stable version because not all Arch users update their systems as often as recommended.
-- Jstjohn (talk) 22:20, 18 February 2014 (UTC)
Yes, got that, thanks. Sidenote: when I google "ntpd" the page comes up 2nd here. Maybe with an active Talk:Network_Time_Protocol_daemon ... --Indigo (talk) 19:13, 19 February 2014 (UTC)