Difference between revisions of "User talk:Pointone"

From ArchWiki
Jump to: navigation, search
(PolicyKit article: new section)
(PolicyKit article: wikified link)
Line 256: Line 256:
 
== PolicyKit article  ==
 
== PolicyKit article  ==
  
I have put in some work on the PolicyKit article which you flagged as needing expansion back in april 2011. I am not sure if I should go ahead and remove the flagging (or if it can reasonably be said to no longer need it?) or ask you to do it? Thanks. [[User:Madchine|Madchine]] ([[User talk:Madchine|talk]]) 16:38, 20 July 2012 (UTC)
+
I have put in some work on the [[PolicyKit]] article which you flagged as needing expansion back in april 2011. I am not sure if I should go ahead and remove the flagging (or if it can reasonably be said to no longer need it?) or ask you to do it? Thanks. [[User:Madchine|Madchine]] ([[User talk:Madchine|talk]]) 16:38, 20 July 2012 (UTC)

Revision as of 16:38, 20 July 2012

You reverted my changes to Beginners'_Guide/Extra#Message_bus, saying "rc.d script is preferred method of interacting with daemons)". Please correct me if I'm wrong, but I believe the correct call for the rc.d script is '/etc/rc.d/dbus start', not the current '/etc/rc.d start dbus'.

Wake 21:09, 3 February 2012 (EST)

Since May 2011, Arch Linux includes the /usr/sbin/rc.d script that can be used to interface with so-called "rc.d" scripts in /etc/rc.d. Running /etc/rc.d/dbus start is functionally equivalent to running /usr/sbin/rc.d start dbus. See also: initcripts-update-1, initscripts-update-2, rc.d @ initscripts.git.
In the name of consistency, all daemon operations on the wiki should use the rc.d executable.
-- pointone 12:29, 4 February 2012 (EST)
Thanks for the explanation. I added the full path (/usr/sbin/rc.d) so it won't trip other Arch newbies up.
Wake 08:35, 9 February 2012 (EST)

Thank you for pointing that out, I can't believe I missed the Romanian ArchWiki. I just went straight to the English version.

Sorry for my late reply , I had some problems with my Internet supplier and couldn't check my e-mails.


--Thras0 02:02, 14 November 2011 (EST)


Thanks for your remind about blank page deletion.

warren 13:00,18 May 2011 (TW, Asia)


Thanks for your work on the netcfg documentation!

Iphitus 20:18, 6 March 2010 (EST)


Hi and thanks for the good work wrt templates. I wanted first to get the green/red light for my idea and then proceed w/ adding the templates to the articles that beg for them. Many wiki pages are just a wall of grey text.

Karol 17:05, 31 May 2009 (EDT)


Thanks for fixing Compact TOC! I don't know much about templates/markup. manolo 18:49, 10 November 2009 (EST)


Kudos for cleaning up package-building articles! --Bhobbit 00:57, 26 November 2009 (EST)


Really good cleanup and update on Fake RAID article. Thanks. --Loosec 12:28, 4 December 2009 (CET)


I noticed your user page the list of potential protected pages, and was wondering if Irc has been considered? --Gen2ly 10:12, 11 December 2009 (EST)

For clarification; my list of consists of protected pages I've wished to edit -- not a complete list of protected pages (Special:ProtectedPages). IRC Channel is tagged with an ominous warning against editing! ;)
-- pointone 18:01, 11 December 2009 (EST)

Got dayum, pointione. Good work ;) pwd 23:01, 15 December 2009 (EST)

2 reports

-- Kynikos 10:01, 11 March 2011 (EST)
I've had a number of users contact me regarding the i18n links on the Official Arch Linux Install Guide. It is maintained in AIF git; I will not edit the wiki page directly. However, I've just finally gotten around to submitting a patch to the arch-releng mailing list.
Thanks for the gentle prodding. ;) -- pointone 17:54, 11 March 2011 (EST)

Section-specific request templates

"e.g. Template:ExpandSection, Template:MoveSection? Would such templates be useful?"

Splitting templates like that adds to more work when keeping up with the wiki's status on what needs to be done. Simply alter the existing expand/move article templates so that they refer to article/section instead of just article. pwd 22:43, 17 December 2009 (EST)

Padding

By padding I mean the space to right that renders on every single article on this wiki, and this is still there. This has less to do with suggestions to the Main Page but it seems like the central place for suggestions that affect everything, the same with the link captions. Dres 17:54, 14 January 2010 (EST)

To wiki or not to wiki?

Please unlock AUR User Guidelines. I hope that "high traffic/semi official" isn't the only reason that you locked it. The AUR is not even officially supported. Was there a history of vandalism or anything? It seems that pages are getting locked more often. It's difficult to get community participation if they are locked out. Thanks for reading. - louipc 22:31, 4 February 2010 (EST)

Sorry; I re-protected the page upon restoration after being overwritten by AUR - uživatelský průvodce (Česky) (it was protected prior to this incident). I agree that the page should be unlocked, though; this was an oversight.
-- pointone 23:41, 4 February 2010 (EST)
Well, I don't blame you for maintaining the status quo. Thanks for the quick response unlocking it. I appreciate it. - louipc 18:43, 5 February 2010 (EST)

Category:Laptops

This was already done with a pywikipedia bot, check the history in most of the laptop articles. heh, Dres 22:42, 4 February 2010 (EST)

Please unlock

I noticed you were the last to edit. AUR Trusted User Guidelines Are you able to unlock, or perhaps grant me privileges to edit it? Thanks. - louipc 15:00, 12 March 2010 (EST)

Please restore "Maven" page

Your reason for deleting was no content; (pacman -S maven). That's not entirely true, though. I wanted to have the "jre" package and suns java packages, not openjdk, in which case I needed to install maven by hand, which is what the wiki page you deleted explained how to do.

Page content was:
Maven is a software project build automation tool.

== Installing ==

=== With openjdk ===

 pacman -S maven

=== With Sun's jdk ===

See this guide: http://usingmaven.bachew.net/manually-install-maven-on-linux
  1. Users should not be recommended to manually install software; let pacman track it for you.
  2. The page needs more content. Perhaps a more detailed description of what Maven can do.
  3. The maven package from [community] works fine for me with the jre package (Sun) from [community] -- are you sure manual installation is necessary?
  4. Please categorize new pages.
Feel free to recreate the page with these notes in mind.
-- pointone 08:09, 22 April 2010 (EDT)

pointone, is there some mechanism for reporting abuse? Jheena789 added link spam to a page. Perhaps the account should be deleted? I have already undid the change, but wanted to be proactive. Thanks! -- Ryooichi 06:30, 23 July 2010 (EDT)

You can report vandalism using the Spammers page, or by contacting one of the admins directly. Thanks for reporting this incident.
-- pointone 09:33, 23 July 2010 (EDT)

Thanks for the pointer

Thanks for making me aware of my biased edits. I've fixed them so they are neutral and simply inform users of different possibilities so that they can make the best decision based on what they like. Trusktr 02:18, 31 August 2010 (EDT)

Thanks for the tips

Thanks for the pointers, I was feeling a little lost regarding the headings and syntax and so forth.

Regarding the slim options, I didn't cut and paste them, I downloaded the latest source code, looked at it a bit, and ran this command to get the options:

 sed -n 's/^.*option("\([^"]*\)","\([^"]*\)".*$/\1\t\2/p' slim-1.3.2/cfg.cpp

And I don't think slim is updated very often, it's just a port of login.app to begin with, and it's very simple code-wise. The syslog-ng page I copied much of from the gentoo wiki, but I helped write the article on the gentoo wiki. Anyway, appreciate you taking the time!

Also, not sure if I am supposed to reply to your note here or on my talk page..

AskApache 01:39, 2 November 2010 (EDT)


Any editing suggestions

Hey if you want to you could go through my wiki contributions real quick and help me to fix my bad wiki habits.. Or any other suggestions about what I should do differently would be a great help to me.. just if you notice anything, thanks. AskApache 17:49, 16 November 2010 (EST)

Do we accept usernames like this one?

Karol 09:18, 8 April 2011 (EDT)

No. Thanks for reporting it. -- pointone 18:11, 8 April 2011 (EDT)

Templates: love them or hate them?

+1 for Template:Cli hate -- Karol 09:24, 8 April 2011 (EDT)

What do you propose? Removing the template altogether? What about Template:Command? -- Kynikos 13:40, 8 April 2011 (EDT)
Why do we have Template:Cli anyway? To get white letters on a dark background? You can add formatting and blinking cursor inside the code parts using the old way (prefixing the code line with a space):
[user@host ~]$ {{Cursor}}
Template:Cli is not rendered using <pre> tags so it won't behave as expected with user-defined rules like pre { font-size:1.3em !important; }.
Template:Command has some sense to it so it can stay. I view it as the commandline equivalent of Template:File.
If we decide that e.g. a template is OK, do we need to revert edits such as this one? It's not a personal wiki, so you can't remove things just because you don't like it. -- Karol 14:23, 8 April 2011 (EDT)
Well, with respect to that specific article, it seems he put that template in first, and he himself then removed it, so in my opinion it's completely forgivable. -- Kynikos 15:55, 8 April 2011 (EDT)
That's what happens when you don't e-mail the author of the discussed edit ... Consider that part of the case closed. -- Karol 16:16, 8 April 2011 (EDT)
About Cli, I happen to quite like it, and I would have many other positive or negative opinions on other templates, but I think that users could never come to a point of agreement over aesthetic matters: either a coherent style is imposed by the admins, or we will have to get definitively used to style variations among the articles (which is not necessarily a bad thing, to some extent). -- Kynikos 15:55, 8 April 2011 (EDT)
I am not personally a fan of Template:Cli but as you say, style is a tricky subject. In cases like this, I defer to the primary/most active maintainer of a page to determine its style. -- pointone 18:21, 8 April 2011 (EDT)
I'm not using the wiki a lot so it doesn't overly bother me and I can always use a firefox boomkarklet to zap the colors but the only benefit I can see of using it over the one-space-at-the-beginning-of-the-line-style is you can indent it easily:
{{Cli|foo}} -- Karol 16:16, 8 April 2011 (EDT)
See? There's always a good side to everything! ^^ In my opinion, the problem is not directly about templates, but about font/box style: for what I have seen, there are 2 main "things" that still need to be styled in a much more coherent way: cli code and file text. Cli code has <pre>, Cli, Command and Codeline (4 different styles) while file text has <pre>, File and I would also add Filename in this list. I think that these 2 groups should be immediately identifiable and distinguishable at first sight: for cli code my proposal would be a similar style to that at stackoverflow.com (both block and inline, this would require 2 templates, but with the same background and font style); for file text I would try a yellowish background for the file name (both inline and block) and very light grey for the content; if filename were to be omitted, only the grey part should be showed (this would be 2/3 templates: inline for filename, block for filename + content and possibly another block for content only). Man, all this would be easier to do than to explain XD Maybe I will reword it better tomorrow -- Kynikos 18:15, 8 April 2011 (EDT)

Sorry, I'm doing this very rapidly, anyway these examples should explain my idea better than 10^9 words:

This is an example of inline style for code and file text:

bla bla bla bla bla codeline args bla bla bla bla /path/to/filename bla bla bla bla bla.

This is a block element for cli code:

$ code code
dbe56v ne4g5fe4 eg45e
xdrtgd g5edeht gddgdr

This is a block element for file text with file name:

/path/to/filename

1 sf5se de4g5ed4
2 de56e e5gt
3 d45ge d45her5
...

...and this is file text without file name:

1 sf5se de4g5ed4
2 de56e e5gt
3 d45ge d45her5
...

Please, note that these are just examples, take them as bare brainstorming ideas, nothing even close to be definitive, ok? ;) -- Kynikos 06:24, 9 April 2011 (EDT)

Sorry, I forgot to mention that this idea follows my previous post, and would make sense only if a precise style were defined by the admins and had to be respected through all the articles -- Kynikos 06:30, 9 April 2011 (EDT)

I'm not sure I like the colors but as I know how to disable them, I don't mind (I know those are only examples). Just make sure it doesn't look too much like Box BLUE template:
foo: bar
-- Karol 08:08, 9 April 2011 (EDT)
I don't want to talk about colors, borders..., those would be the last things to choose: what do you think of the idea of having standard color association for code (in the example blueish) and file text (in the example yellowish), both for block and inline elements? I absolutely don't want to create other templates, that'd be completely nonsense: I am trying to propose the implementation of a standard official style for the articles. -- Kynikos 09:42, 9 April 2011 (EDT)
I think it's a great idea, as long as the colors differ from ones used in the other templates, like Note or Box. -- Karol 10:19, 9 April 2011 (EDT)
Well, now we can wait to see if Pointone or other admins release an official style guide, and in that case this formatting could be discussed further. -- Kynikos 12:34, 11 April 2011 (EDT)
Thinking in more detail about templates and formatting, I wonder: do we need to separate "code" and "file" formatting? Originally (that is, before I started updating and reorganizing the template namespace) there was codeline, filename, command, file, and kernel. These were all created at the beginning of 2008. I see the need for only three distinct forms of code formatting: inline code,
block elements,
and "combo" boxes like templates command, file, and kernel.
Would you be opposed to the consolidation of code formatting templates? -- pointone 12:07, 13 April 2011 (EDT)
Of course you have the last word, but yes, I would oppose unless "combo" boxes are "consolidated" too, otherwise that would look incoherent to me: this solution could lead to a very KISS approach, keeping only 3 templates, but only if, as I've said, combo boxes are involved too.
My approach was completely different, not differentiating formatting depending on *where* (inline/block) or *how* (simple/combo) a piece of code appears in the article, but basing all the (visual) differences mainly on *what* that code is: that's why I was asking for consolidating block code formattings with their respective inline counterparts. This solution would prioritize merging styles before templates.
Anyway, whether you choose officially one solution or the other, it will be a nice improvement to the current situation. -- Kynikos 13:11, 13 April 2011 (EDT)
Both solutions are valid, and, as Kynikos wrote, both would be a step forward from the current situation. I don't mind Pointone's version but I don't think we have to limit ourselves that much as some people might like visually differentiating editing a file from typing a command.
I would like to see some order and consistency in templates and general (visual?) style but I'm not against either of the proposed solutions. -- Karol 13:52, 13 April 2011 (EDT)
@Pointone: seeing your attempt in the Sandbox I try to report again the example of stackoverflow.com, which originally inspired me the idea of inline/block code style similarity; by the way, I don't know if this behaviour can be enabled in the wiki, but there inline code is automatically formatted by enclosing it in backticks (`inline code`). -- Kynikos 20:12, 13 April 2011 (EDT)
I've taken a look to your attempts, and tried something by myself too: User:Kynikos/Random formatting ideas. To be honest, I find your version of the "combo" box still incoherent, because it changes the default color for code, which should be that light blue/cyan. I've come up with some alternatives. -- Kynikos 13:31, 14 April 2011 (EDT)

"pacman -Syu package"

This could be a result of not having an official package installation syntax after the introduction of "pacman -Syu package": pepole could start forgetting what "y" and "u" even mean, and always repeat them unnecessarily... Also, in the previous section, pacman -Syu is used separately from the package: is it ok? -- Kynikos 13:40, 8 April 2011 (EDT)

I suppose a basic style guide is in order. Along the same lines, I'd also like for wiki editors to stop assuming yaourt as the de facto AUR helper and perhaps something regarding template use/etiquette. (Continues musing...) Any thoughts? -- pointone 20:45, 8 April 2011 (EDT)
You already know my thoughts on "pacman -Syu": keep it separate from "pacman -S package", even at the cost of writing to "first update the system with pacman -Syu" at the beginning of each article.
About AUR packages, I would force the use of makepkg and pacman -U on all wiki articles (ok, I'm using yaourt too, but users should be aware that the U in AUR means unsupported).
About templates read the previous discussion. -- Kynikos 06:36, 9 April 2011 (EDT)

Deleted Cmd Template?

Hey I went to look at the cmd template we made and it was deleted, I would really like to be able to recover the source from that template, is there any way you can undelete it or send me the source code from it? Also, I still could really use a template like that and the cli and command templates don't cut it for reasons listed on the deleted Cmd templates talk page. I'd also like to get the source code from the examples I added to the talk. AskApache 09:55, 9 April 2011 (EDT)

Recovered. -- pointone 13:06, 10 April 2011 (EDT)
Since this is practically a duplicate template, couldn't you just <nowiki> the template code (thus making it a normal page and not polluting the templates namespace) and invite him to use the Template:Sandbox page? -- Kynikos 12:30, 11 April 2011 (EDT)

Start Help:Style? (the Style Guide saga)

(this is a continuation of the various discussions on a possible style guide) What if we started contributing to a Help:Style page? At the moment we could mark it as unofficial at the top, but we could find agreements there on article styles and once you think it can go official we can start applying it to the wiki. -- Kynikos 05:01, 2 May 2011 (EDT)

Please, do! I feel like this is something that could be combined with Help:Reading which deals primarily with style, as well. -- pointone 20:43, 2 May 2011 (EDT)
Done, maybe until the page itself has not reached a sufficient level of organization it shouldn't be publicized much, not to involve too many users and rushing things excessively. -- Kynikos 09:37, 3 May 2011 (EDT)

i18n category naming

Both English category names and localized category names are using in my language's(SimpChinese) wiki.

Is it better to use "English Title (Language)" as artical naming? --Cuihao 05:34, 2 May 2011 (EDT)

Short answer: Yes. I responded to your forum thread in more detail. -- pointone 20:44, 2 May 2011 (EDT)

GNOME 3 talk page?

What happened to GNOME 3 talk page, which now should be in Talk:GNOME? -- Kynikos 04:55, 11 May 2011 (EDT)

Looks like you've just solved it. -- Kynikos 09:05, 11 May 2011 (EDT)

Sorry

I have not read the page cited, now translated to facilitate it. Help:I18n (Português)

PolicyKit article

I have put in some work on the PolicyKit article which you flagged as needing expansion back in april 2011. I am not sure if I should go ahead and remove the flagging (or if it can reasonably be said to no longer need it?) or ask you to do it? Thanks. Madchine (talk) 16:38, 20 July 2012 (UTC)