User talk:Dsimic/Archive 3

Hi, Dsimic: this is a notice that after a MfD and two RfCs, the Editor Review process has been officially retired. You should not expect further comments on your open Editor Review, which will be archived soon. In the coming weeks there may be information available on alternative processes that you can pursue if you so desire. —/Mendaliv/^2¢/_Δ's/ 21:05, 28 May 2014 (UTC)

Hello there! Thank you for letting me know, I've removed the {{Editor review}} template from my user page. — Dsimic (talk | contribs) 22:16, 28 May 2014 (UTC)

Why does lowercase make more sense to you? If you are going to revert somebody's edit, you should provide a more elaborate reason than what arbitrarily makes more sense to you. – voidxor ^{(talk | contrib)} 05:09, 3 June 2014 (UTC)

Hello there! Edit summaries don't allow for longer descriptions, that's why I wasn't elaborate enough. :)

In a few words, MOS:BULLETLIST allows both sentence case and lower case for list items, and the lower case style made more sense to me because those weren't real sentences, and they were quite short at the same time. However, with latest edits that section grew up a bit, so I've edited the article by extending the section further and turning the list items into true sentences. Hope you find that acceptable. — Dsimic (talk | contribs) 23:32, 3 June 2014 (UTC)

Hi there, Dsimic! Now that the move of "Android rooting" to "Rooting (Android OS)" has been completed, I know you'll be interested in this parallel proposal:

• Talk:iOS jailbreaking#Requested move: iOS jailbreaking → Jailbreaking (iOS)

I'll see you there, I'm sure! =) — Jaydiem (talk) 19:36, 16 June 2014 (UTC)

Hello there! Thank you for bringing it to my attention, I'll keep an eye on it. — Dsimic (talk | contribs) 22:09, 16 June 2014 (UTC)

I do not understand how the article can be full of e.g. "flash-based" with a hyphen, and that is fine, but as soon as it becomes "flash memory-based" the hyphen is supposed to change to an en-dash.

Why??? What is the justification here? What is the benefit? I think it just clutters up the wikitext, makes editing more difficult, and will require more redirects when these things get into article titles (since nobody will be typing in the keycodes for endashes in the search box). Jeh (talk) 06:50, 8 July 2014 (UTC)

And from what I can tell, WP:ENDASH does not support you. "Instead of a hyphen, when applying a prefix (but not a suffix) to a compound that includes a space".

• ex–prime minister Thatcher;   pre–World War II aircraft;   but not credit card–sized

"flash memory-based" is parallel to "credit card-sized", and therefore, per this point, should NOT get an endash. Jeh (talk) 06:56, 8 July 2014 (UTC)

Hello there! I totally understand your confusion (BTDT), so please allow me to explain – I'm sure you'll see where are the benefits from the whole thing.

As I've already pointed out in my revert on the Solid-state drive article, more details are provided in MOS:ENDASH and in a detailed discussion which addresses suffixed compound adjectives much further while slightly confronting with that MOS section; while you're there, it might be worth to also have a look at a related discussion. You're right that MOS:ENDASH currently doesn't state that en dashes should be used for suffixed compounds, but the above linked discussion(s) provide numerous arguments why the en dash rule should be extended to suffixes as well. That's something I simply don't agree with the MoS, and there are more editors sharing that disagreement – as you can see in these linked MoS discussions.

What are the benefits of en dashes at all? Well, that's a good question. From one side, I've also thought a lot of ditching every form of hyphenation except plain hyphens; on the other hand, that would simply reduce value of the English language what can't be good. Sure thing, it's much more simple to use plain hyphens everywhere, but then we'll slowly end up with a text messages–style language, which is simply disgusting and in a long run makes people less smart without any true reasons of real-life benefits.

Speaking of "flash-based" vs. "flash memory–based", it's all about "flash memory" being a compound. Having a hyphen in place indicates the relation between only two words ("flash" and "based", and "memory" and "based"), while having an en dash idicates that "based" relates to "flash memory" as a whole. Sure thing, human brain is advanced enough to figure out these examples even with no hyphenation, but if we'd extend that a bit further we could easily go even without capitalizing first words in sentences, right? :)

Another examples of the en dashes usage (for a different purpose, of course) are Diode–transistor logic, Eye–hand coordination, Request–response, etc. These are all article titles, and they would have a completely different meaning if en dashes were replaced with plain hyphens; in those cases, using en dashes implies that the "linked" words remain independent what's important for the resulting meaning.

Regarding cluttering of the Wiki code, en dash character (–) could be used in the source code instead of the – HTML entity. This should make Wiki code more clear; however, I find typing in HTML entites much faster than going into "Special characters" picker, scrolling a bit and clicking onto the en dash character provided there. Could've used the toolbar available under the source code edit box instead, but I'm somehow used to the "Special characters" picker for that purpose. :)

Hope it all makes sense. Thoughts? — Dsimic (talk | contribs) 07:37, 8 July 2014 (UTC)

I think you are vastly overestimating the percentage of readers who will even notice whether a "short horizontal line" is an en dash as opposed to a hyphen... let alone ascribe to that distinction the meaning you think they well. It's not as if we're talking about em dashes, which are obviously different. I am something of a "type person" and the only way I can tell if something on WP is an en dash vs a hyphen with perfect reliability (provided there are no examples of both next to each other) is to use character search on the page to highlight the latter. And your invocation of "slippery slope" is a logical fallacy.

Anyway, as it stands, your edit and your reversion are contradicted by the MOS page. The discussions are interesting, but if there was consensus to agree to that change then the actual MOS page should have been changed. It is unreasonable to post MOS and then say "oh, well, you can't rely on that! See, this discussion says otherwise." Since when? Jeh (talk) 08:35, 8 July 2014 (UTC)

Well, I can always tell the difference in legth between a hyphen and an en dash just by looking at them while reading. You're right that most people don't even know (or care about) the difference between hyphens and en dashes, what's somewhat sad. A flawed "slippery slope" or not, the very fact people don't know about that, or about the distinction in meaning, indicates something... Right?

Linked MoS discussions could've resulted in actual changes to MOS:ENDASH, but there were a few editors completely reluctant to accept anything outside of their "by the Chicago Manual of Style" bubbles, so the proponents of changes lost their energy and interest.

In a few words, please feel free to revert my changes, I won't stand in your way. — Dsimic (talk | contribs) 08:52, 8 July 2014 (UTC)

Thanks. I may return to this. Jeh (talk) 09:56, 8 July 2014 (UTC)

You're welcome. — Dsimic (talk | contribs) 10:15, 8 July 2014 (UTC)

Please do not use that style of citation syntax on articles. The |publisher field is designed to list the publishing company of the work, not the domain name it came from. The title of the website must be in either a |work or |website field. Also please do not use Android Police as a source; it is a blog, and blogs are typically not considered reliable sources. ViperSnake151  Talk  16:36, 8 July 2014 (UTC)

Hello there! Thank you for pointing this out, moving forward I'll use the |website= parameter. However, to me web sites are publishers and specifying their domains instead is more usable in many cases, but of course that's debatable. For example, if a LWN.net article is used as a reference, I'd say that 99% of people wouldn't recognize "Eklektix" when it's specified as a publisher, while "LWN.net" is pretty much widely recognizable. Should we end up using something like "|website=LWN.net |publisher=Eklektix" for this example?

Oh, and by the way, please consider including edit summaries in your edits, they're quite usable. :) — Dsimic (talk | contribs) 21:58, 8 July 2014 (UTC)

Thanks for letting me know that I had missed items for my ZFS edit. I've updated it, and it should meet the requirements, year & references. Let me know if additional information is required. A'kwell (talk) 20:30, 6 July 2014 (UTC)

Hello there! You're welcome, and thank you for providing references and years, it looks good now! Went ahead and improved it further by touching it up, and by filling in a few references so they're now protected from link rot – please check it out. — Dsimic (talk | contribs) 22:26, 6 July 2014 (UTC)

Great. Thanks for the extras. I'm still learning Wikipedia editing, so some of my updates will be a bit primitive. But, I have the technical details, (with proof), to contribute. A'kwell (talk) 02:32, 9 July 2014 (UTC)

You're welcome. Just take your time, we've all gone through the learning phase here just as everywhere else. As a small suggestion‍—‌and I'm sure you're already well aware of it‍—‌there's the Wikipedia's Manual of Style as a great resource, which is also very usable outside of its primary role to be a general guide to editing Wikipedia. — Dsimic (talk | contribs) 04:46, 9 July 2014 (UTC)

Thank you for your recent improvements to kmscon article. Posting here only because I didn't want to spam your echo notification log with multiple "thanks" (for each edit). Good work! — Dmitrij D. Czarkoff (talk•track) 08:19, 9 July 2014 (UTC)

Hello there, and thank you very much! I'm glad you like those improvements I've made to the article. Oh, and of course thank you for your contributions to the kmscon article – that started everything. :) — Dsimic (talk | contribs) 00:59, 10 July 2014 (UTC)

Hi Dsimic,

I was just commenting on a feature SSH has. Yes, it allows to "punch" through a firewall, but I don't how that affects the text. Should I revert and append a reference to the manpage of openssh where that feature is described?

http://www.openbsd.org/cgi-bin/man.cgi?query=ssh&sektion=1 option "ssh -R [bind_address:]port:host:hostport"

Cruzzer (talk) 10:04, 14 July 2014 (UTC)

Hello there! In your addition to the OpenSSH article, you've described that it "can also be done in reverse direction where the server receives access to the environment of the client." However, that's a bit confusing, as in that case it is still about tunneling connections (or port forwarding requests) that are initiated from the client, what's also clearly described in the man page you've linked above:

-R [bind_address:]port:host:hostport

Specifies that the given port on the remote (server) host is to be forwarded to the given host and port on the local side. This works by allocating a socket to listen to port on the remote side, and whenever a connection is made to this port, the connection is forwarded over the secure channel, and a connection is made to host port hostport from the local machine.

[...]

In other words, -R [bind_address:]port:host:hostport can be used to connect arbitrary TCP ports both on the server side and and on the client side through an SSH tunnel, but that's still the same thing no matter from which side we're looking at it. Thus, it might be a bit misleading to describe it as being "done in reverse direction", if you agree.

Hope it makes sense. Went ahead and edited the article to include this info in a form that allows no misinterpretation by the readers. Please, check it out – hopefully you'll find this edit good enough. — Dsimic (talk | contribs) 11:54, 14 July 2014 (UTC)

Avoiding confusion is surely the way to go. My intention was more to highlight the feature, as it's pretty unexpected from a network stance. It's also a security issue, as the client can open connections back into his own network, sidestepping firewall rules disallowing access to the client network. But I guess the the red "flag" is set with the --and to circumvent firewalls-- part. Cruzzer (talk) 12:44, 14 July 2014 (UTC) 

Right, there's already a note that SSH port forwarding can be used "to circumvent firewalls". Thus, if a reader is unable to grasp that, I'd freely conclude that no additional explanations about possible security issues would be helpful. — Dsimic (talk | contribs) 13:01, 14 July 2014 (UTC)

Additionally, OpenSSH § Features section now contains a link to the SSH tunnel article, which describes potential security issues in detail. That should make it all covered, if you agree. — Dsimic (talk | contribs) 13:13, 14 July 2014 (UTC)

However, went ahead and clarified it additionally. Please, check it out. — Dsimic (talk | contribs) 13:20, 14 July 2014 (UTC)

Yes, I like that. Thanks for your help. Cruzzer (talk) 13:43, 14 July 2014 (UTC)

You're welcome, and thank you for your contribution to the article – it started the whole thing. :) — Dsimic (talk | contribs) 13:59, 14 July 2014 (UTC)

Re: Power supply unit (computer): the calculation is explained in the next sentence. Otherwise, the other result is not explained either. Glrx (talk) 17:42, 15 July 2014 (UTC)

Hello there! Sorry, my bad, everything is fine with your addition to the article. Totally a brainfart from my side. — Dsimic (talk | contribs) 18:15, 15 July 2014 (UTC)

Ironically your revert comment came at a point I was fixing the same issue. See reworked version which should be simpler and more direct, and better tone (you probably saw it just now).

See what you think, fix what you need to, but try to avoid wholesale "plain reverting" :)

I look forward to discussing anything you want to, on the t/p later. FT2 ^{(Talk | email)} 14:38, 17 July 2014 (UTC)

Hello there! Please don't get me wrong, as I've already noted on Talk:SATA Express § Stimulus for SATAe your latest additions to the article aren't bad per se, but they're simply way too wordy and make the article look a bit like a forum post.

The only reason why I went with the "revert everything" approach (which I really don't like) is because at the moment I don't have enough time to dedicate for going through everything in detail. In the meantime (until later today, or early tomorrow latest), to me it's better to leave the old version. Of course, that's only my humble opinion. :) — Dsimic (talk | contribs) 14:50, 17 July 2014 (UTC)

An editor has asked for a discussion to address the redirect Kpatch. Since you had some involvement with the kpatch redirect, you might want to participate in the redirect discussion if you have not already done so. -- intgr [talk] 10:52, 21 July 2014 (UTC)

Hello there! Thank you for bringing it to my attention, I'll provide some feedback in the above linked redirect discussion. — Dsimic (talk | contribs) 01:34, 22 July 2014 (UTC)

Didn't seem notable to me. Someone should look the promo contribs of Special:Contributions/Wikidevb (and other SPAs which wrote that FlexRAID piece) in other articles. Someone not using his real name (talk) 18:05, 20 December 2013 (UTC)

Thank you for a heads-up! — Dsimic (talk) 18:29, 20 December 2013 (UTC)

@Dsimic: That section isn't about FlexRAID. An article on FlexRAID is being prepared separately. The section was about RAID over File System as a general RAID approach. Refer to prior discussion on the entry here. — Preceding unsigned comment added by Spectwiki (talk • contribs) 17:41, July 30, 2014‎ (UTC)

Hello there! Well, Ok, it doesn't hurt to keep it if you insist. — Dsimic (talk | contribs) 05:19, 31 July 2014 (UTC)

HI, this is my first reponse on a talk page, please forgive me if I mangle this submission. I found your TSX page quite good. I was wondering if you have an affiliation with Intel or have a contact with someone responsible for TSX at Intel? Regards, AndrewX – 12.15.146.127 (talk) 13:07, 7 August 2014 (UTC)

Hello there! No worries, it's Ok and I've just cleaned up your post a bit. :) Actually, I haven't created the Transactional Synchronization Extensions article, I've just contributed some improvements to it. Unfortunately, I have no connections with Intel, at least not beside using their products. :) — Dsimic (talk | contribs) 07:58, 8 August 2014 (UTC)

There you go violating BRD again. Your reversion to your text (after your change was reverted) is considered edit warring. The next stage is supposed to be "Discuss". It is not BRRD. Jeh (talk) 07:26, 9 August 2014 (UTC)

And your analysis is incorrect. The clause that follows which/that is not necessary to the sentence's meaning; it merely adds description. Therefore, according to your reference, "which" is correct. Jeh (talk) 07:30, 9 August 2014 (UTC)

Hello! Please, let's not split hairs on the WP:BRD rule – as you probably know, I'm more than open for discussion and this is one of the places where we can exchange our views. Anyway, here's an excerpt from the style reference I've included in my edit summary:

Use “which” plus commas to set off nonrestrictive (unnecessary) clauses; use “that” to introduce a restrictive (necessary) clause.

... and here's the edited sentence from the article (emphasis added):

Price decreasing from about US$15,000 per megabyte to less than $0.05 per gigabyte by 2013, a greater than 300-million-to-1 decrease that corresponds to a 41% per-year increase in bytes per dollar (or a 29% per-year decrease in price per byte).

According to the referenced rule, "which" is to be used for unnecessary clauses, and you've also confirmed that what follows which/that in the edited sentence simply adds a better description. That's simply true, there's no doubt. When looked from that side, "which" is the way to go; let's see how the sentence looks when that unnecessary clause is trimmed away:

Price decreasing from about US$15,000 per megabyte to less than $0.05 per gigabyte by 2013, a greater than 300-million-to-1 decrease.

To me, that doesn't sound great and it should be edited like this, what also complies with the referenced rule as the sentence still contains another unnecessary clause:

Price decreasing from about US$15,000 per megabyte to less than $0.05 per gigabyte by 2013, which is a greater than 300-million-to-1 decrease.

Now the sentence sounds good, at least to me. But, in this case returning back the initial unnecessary clause simply by using "which" (as the style refrence suggests) would look even worse:

Price decreasing from about US$15,000 per megabyte to less than $0.05 per gigabyte by 2013, which is a greater than 300-million-to-1 decrease, which corresponds to a 41% per-year increase in bytes per dollar (or a 29% per-year decrease in price per byte).

Now, that would be a true mess. :) Based on all that, using "that" is a much better choice. However, it could be me splitting hairs here, but please let me know where am I wrong and I'll be totally fine with using "which" in the first place. :) Also, maybe this could be some kind of a compromise:

Price decreasing from about US$15,000 per megabyte to less than $0.05 per gigabyte by 2013, which is a greater than 300-million-to-1 decrease that corresponds to a 41% per-year increase in bytes per dollar (or a 29% per-year decrease in price per byte).

Thoughts? — Dsimic (talk | contribs) 08:04, 9 August 2014 (UTC)

I do not at all see how you arrived at "'that' is a much better choice". I cannot, in fact, imagine how you can at once accept the notion that "that" is used to introduce necessary clauses and then argue for its use on an unnecessary clause, just because it "sounds better". (A lot of correct things "sound wrong" to many because the correct grammar has been misused for so long.)

In your compromise, "that" is still introducing an unnecessary (descriptive) clause, so "that" is still incorrect.

The sentence was fine as it was, except that it needed the comma before "which"... and I was in the process of adding that when you re-reverted.

The "true mess" is simply avoided by not using the "which" you're trying to introduce before "a greater than..."; not every descriptive clause needs "which" in front of it.

As a side note, there are many other ways to handle multiple descriptive clauses: em dashes, parentheses, break the second one off into a second sentence ("This corresponds to..."). But I see no need to inject a compromise here when the dispute is not between two shades of right, but rather between right and wrong. You want to use "that" to introduce an unnecessary clause, and that's wrong. Please restore the previous wording. Jeh (talk) 08:45, 9 August 2014 (UTC)

Ok, to simplify the things I've edited the sentence as you've suggested, tweaking it a bit further so we don't have a mishmash of parentheses, which'es and other constructs. Looking good? — Dsimic (talk | contribs) 08:59, 9 August 2014 (UTC)

No. None of the other items get two sentences, this shouldn't. Jeh (talk) 12:18, 9 August 2014 (UTC)

Why would something like that be important? That's really a hairsplitting; please feel free to edit the sentence as it suits your taste, I won't stand in your way. — Dsimic (talk | contribs) 20:20, 9 August 2014 (UTC)

"I won't stand in your way." Well, that didn't last long, did it? I took you at your word and... Yet another revert notice in my inbox. I strongly feel that when you have a series of bullet items like this they should present information like this in as parallel a form as possible; one point should not have embellishments that the others lack. And no, the answer is not to add similar embellishments to the others. Jeh (talk) 17:48, 10 August 2014 (UTC)

Please pardon me, but this is slowly becoming an inconvenience to me, and I'll try to explain why. Firstly, I didn't revert your edit, I've just restored the deleted sentence by converting it into a note by using "undo" feature to quickly fetch the deleted content and convert it. Just to emphasize it, I didn't simply revert your edit. At the same time, I've changed the edit summary so it doesn't trigger the "your edit was reverted" notification, as I've read somewhere in Wikipedia's guidelines (or in MediaWiki documentation, can't remember) that those notifications are based solely on edit summaries. Though, as we see that isn't the case, and I apologize for not using a different way to fetch the deleted content.

Then, why is your opinion in this case so much more important than mine, and why is it so important to you that some additional information is deleted? Ok, I'm not a native English speaker, and I'm always more than open to receiving any criticism language-wise as that's the only way to improve myself, but this is no longer about the language and style. Sure thing, that sentence by far isn't the Holy Grail of HDD-related information, but why should we delete it, as it simply provides an additional perspective? Someone invested his/her precious free time to do the required calculation and provide some more content, which does no harm whatsoever; hitting "delete" on something like that makes little sense to me. Also, now as a note, it doesn't disturb the overall form of the surrounding bulleted list.

Please don't get me wrong, I'm not here to argue, but I'm sensing some kind of pressure directed toward me, and (what's quite reasonable) that makes me uncomfortable. — Dsimic (talk | contribs) 05:04, 11 August 2014 (UTC)

As discussed in Talk:Hard disk drive § Highlights In History Section, bulleted list from the Hard disk drive § History section is now converted and compacted into a table, please check it out. At the same time, the troublesome footnote has been deleted. Looking good? — Dsimic (talk | contribs) 08:48, 11 August 2014 (UTC)

And, here we go again – 71.128.35.13 went a step back and restored that footnote. Hm. — Dsimic (talk | contribs) 21:01, 11 August 2014 (UTC)

See my comments at the talk page there. Jeh (talk) 00:59, 12 August 2014 (UTC)

In a recent edit to the page Transactional Synchronization Extensions, you changed one or more words or styles from one national variety of English to another. Because Wikipedia has readers from all over the world, our policy is to respect national varieties of English in Wikipedia articles.

For a subject exclusively related to the United Kingdom (for example, a famous British person), use British English. For something related to the United States in the same way, use American English. For something related to another English-speaking country, such as Canada, Australia, or New Zealand, use the variety of English used there. For an international topic, use the form of English that the original author used.

In view of that, please don't change articles from one version of English to another, even if you don't normally use the version in which the article is written. Respect other people's versions of English. They, in turn, should respect yours. Other general guidelines on how Wikipedia articles are written can be found in the Manual of Style. If you have any questions about this, you can ask me on my talk page or visit the help desk. http://english.stackexchange.com/questions/1338/are-collective-nouns-always-plural-or-are-certain-ones-singular Little Professor (talk) 18:33, 13 August 2014 (UTC)

Hello! Additionally, per WP:ARTCON articles should be written in a consistent manner, following one of the English varieties throughout the article. Which one prevails in this article? — Dsimic (talk | contribs) 04:28, 14 August 2014 (UTC)

Actually, Little Professor, it is you who would have been templated - except that Dsimic is too polite to template a regular. Intel is an American company and therefore articles about them and their developments should be phrased in American English. Nor is this a question of respecting the existing usage in the article. It contains numerous examples of treating "Intel" as singular, so your use of the British treatment of a collective noun goes against prevailing usage. Furthermore, you took what had been a completely dialect-neutral phrase ("Intel announced... which resulted in disabling...") and changed it to English dialect ("Intel announced... which lead to them disabling..."). In short it is you who are going against MOS:ENGVAR here, and you should withdraw and apologize for your complaint against Dsimic forthwith.

Just by the way, we don't care much what stackexchange.com says about anything (even though, in this case, it supports the notion that American dialect treats companies as singular); it consists of user-contributed content and therefore is not what WP considers a reliable source. Jeh (talk) 05:25, 14 August 2014 (UTC)

Thanks, Jeh. Getting a templated notification did look a bit strange to me, but I'm always more than eager to receive criticism related to my usage of the English language, as that's the only way I can improve myself. Anyway, I always assume that all editors are here to make both Wikipedia and themselves better. — Dsimic (talk | contribs) 09:00, 14 August 2014 (UTC)

You're very welcome. Now I wonder what you think of my edits to your edits. One is basically a revert. :-)

As mentioned in the edit comment, other than forgetting the final "s" on "suspects", I really was quite fond of that description of the reason for PING packets "This avoids the need to send a large DATA packet if the host suspects the device will just respond with NAK." If that's actually unclear, I'm curious how you interpreted it. Anyway, I tried a different phrasing. (Good reference finding, BTW.)

One change I wanted to make, but haven't found the right words for, is to split up the two uses of "non-standard" in the cable plugs table. Mini-A to micro-B is weird, but perfectly reasonable. A to A may exist, but you can't talk USB over it.

Another thing I'm tempted to do is mark the mini plugs as deprecated, tinting the column & row headers, and switch the compatibility matrix entries to green. To me, that reflects reality a bit better. What do you think? – 71.41.210.146 (talk) 20:52, 16 August 2014 (UTC)

Hello there! Regarding "ID pin" vs. "ID line", on second thought using "ID pin" should be actually better as it's used where connector pinouts are described. In other words, your revert is just fine with me. :) Your other edits are also fine with me, FWIW, especially simplification of the note in USB § Host and Device interface receptacles section – while it was acceptable before, I wasn't too happy with it as the provided description of differences in pin assignments between connectors wasn't precise enough. Thanks for improving the note so it's down to the exact differences; I've just cleaned it up a bit for improved readability.

The description of PING packets was somewhat confusing, as it was unclear how can a host suspect that. That's much more clear with your additions, and (after thinking about it for some time) I've restored your initial wording, sligthly tweaked and now in addition to the already present additional description. Hope you're fine with that. In addition, I've just cleaned up and clarified that and another earlier section, together with adding two more references.

Speaking about changes to the tables, I wouldn't change the colors or wording – both for "non-standard" combinations of cable plugs, and for Mini connectors. Why? Well, there's WP:COLOR that disallows color to be used as a sole carrier of the meaning, as there are blind people who use screen readers to access articles. Beside that guideline, introducing additional shades of color would probably be simply confusing. Thus, for the uses of "non-standard" I'd suggest a few notes to be added into respective table cells using the {{Efn}} template. For the Mini plugs and receptacles, I'd suggest we add nothing as they are deprecated but still used; please see WP:COMPNOW for something that might be used as a preservation analogy. Hope you find that acceptable. — Dsimic (talk | contribs) 08:23, 17 August 2014 (UTC)

Good points, especially about color & accessibility. Sigh, that may mean I have to go back and fix my beautiful Conventional PCI § Connector pinout chart. Anyway, it appears we're basically on the same page and don't have any significant disagreements. Feel free to go nuts with a red pen on my edits, and I'll try to communicate in edit comments. I just like to start discussion when I get as close to an edit war as re-doing a change that you reverted. (TIL about Template:Diff.) 71.41.210.146 (talk) 09:27, 17 August 2014 (UTC)

I'm glad that you find our discussion productive. :) Sure thing, there are no significant disagreements, it's all about improving the article by providing as clear and correct descriptions as possible. By the way, having small disagreements along the way is actually a good thing, as that way things (usually :) become better. And, of course, please feel free to change the content brought in with my edits.

Regarding the chart you've mentioned above, redoing it might not be required as a color-coding legend is also provided. Though, I'm not sure about that; if there isn't anything similar described in WP:COLOR, it might be better to ask on Wikipedia talk:Manual of Style/Accessibility before changing anything. Oh, and {{Diff}} template is quite useful. :) — Dsimic (talk | contribs) 09:49, 17 August 2014 (UTC)

There is currently a discussion at Wikipedia:Administrators' noticeboard/Incidents regarding to discuss a disruptive IP-hopping editor that edits Nvidia-related articles. The thread is Disruptive edits by IP-hopper on Nvidia-related articles. Thank you. —Jesse Viviano (talk) 17:40, 14 August 2014 (UTC)

Hello there! Thank you for bringing it to my attention, I'll see to provide some comments in the above linked discussion. — Dsimic (talk | contribs) 05:02, 15 August 2014 (UTC)

@Jesse Viviano: Well, the WP:AN/I discussion got archived with zero responses from other editors. That makes me wonder why should you, Lonaowna or I care for those Nvidia-related articles? Who else cares? — Dsimic (talk | contribs) 20:47, 18 August 2014 (UTC)

I just tried to resolve the situation. I used to automatically hate Nvidia products because a G86 GPU that was soldered to my laptop's motherboard failed due to the bad bumps issue and took the motherboard down with it. I had to spend a large amount of money to recover from that. Nvidia then hit another reliability low point with its GeForce 400 series which endured high RMA rates probably due to overheating. Later on, AMD's drivers for my Radeon HD 6970 started to crash on me when I am trying to read my email or use a web browser on my desktop machine I built after the failed laptop motherboard incident. AMD's driver quality apparently tanked after Carrell Killebrew, the then head of the AMD Graphics Product Group, was laid off from AMD. I had to replace my Radeon with an Nvidia card in my desktop build to solve the frequent crashes. Nvidia's poor sales figures and high RMA rates for its GeForce 400 series spanked some sense into Nvidia that we care about card heat and noise. Since the GeForce 500 series was not as hot, it was much more reliable. These incidents have left me with a bitter hatred for idiotic fanboyism for both sides. I still wish there was a way to force Nvidia to recall all of the G84 and G86 GPUs that were made with the defective stepping. (A later stepping fixed the bad bumps issue that destroyed my laptop's motherboard.) I also don't like someone spreading debunked statements on Wikipedia without explaining that they were debunked. Such half-truths and lies in Wikipedia without disclosing that they are debunked hurts Wikipedia. Jesse Viviano (talk) 22:52, 18 August 2014 (UTC)

I'm not a fanboy either. Back in 2002–2006, I had two desktop PCs with Nvidia GPUs, and they both worked just fine under Linux with open-source drivers, what made me quite happy about Nvidia. Then, in 2007, I got a newer desktop PC with a more modern Nvidia GPU, which simply refused to work properly with even the latest available open-source drivers of the time. Speaking about garbled screens in X sessions (for example, all buttons in Firefox turn into black rectangles, and almost on a regular basis), manual upgrading to latest X and its associated libraries, and other extremely time-consuming endeavours aimed toward fixing the issues, I was forced to use Nvidia's closed-source Linux drivers. Aaargh, a binary blob as a module in my kernel?! Never thought of having those before, but that became an unavoidable everyday reality; at least the GPU worked fine with that huge (4–5 MB, IIRC) binary blob.

Back in 2008 (or so) I got a laptop that came with a discrete Radeon GPU; I was already used to having binary blobs around. Linux support for Radeon GPUs can't be bad, right? If open-source drivers don't work, official binary blobs will do the trick. Not so fast! It turned out that open-source drivers existed only as a then-beta RadeonHD open-source project, while the official closed-source Linux drivers were a story of their own. For example, when a running X session is switched to virtual consoles (Ctrl+Alt+Fn), laptop's screen turns into something that extremely resembles a broken LCD, making it look as if moisture got into LCD from the bottom and destroyed it. You can imagine my feelings while looking at that for the first time. :) Luckily, those were only visual effects; of course, all that also locked up the laptop requiring hard reboots. After a few days of experimenting, I've ended up with hand-crafted RadeonHD open-source drivers, which worked but caused very reduced battery runtimes and made it impossible to use an external monitor. Sigh.

Thus, I've been tortured with products from both manufacturers, but at least was lucky enough not to experience physically damaged hardware – I can feel your pain when your laptop's motherboard failed. :( — Dsimic (talk | contribs) 02:28, 19 August 2014 (UTC)

Hi. I linked the entries as I did on the dab page IML because WP:DABPIPE encourages linking the article itself, rather than redirects. ENeville (talk) 22:53, 18 August 2014 (UTC)

Hello there! Thank you for pointing out this disambiguation linking guideline, I'll use it for my future edits related to disambiguation pages. — Dsimic (talk | contribs) 02:33, 19 August 2014 (UTC)

Hello - I notice you've undertaken a lot of work to build out the F5 page...nice work. Could you help me? I am wondering where the content for "history of software development" originates. I cannot find the sources and I am wondering if you are the brother of Bojan Simic and getting content from him. Any help you can provide is appreciated. – Jaim Harlow 17:39, 19 August 2014 (UTC)

Hello there! Thanks, I've contributed a little bit to the F5 Networks article. Regarding the F5 Networks § BIG-IP software development history section, back at the time I was interested in the design of Traffic Management Microkernel (TMM), and I've contributed a few related references to that section. Unfortunately, I have no brother named Bojan, and those references I've contributed were simply Googled out. I'm sorry I can't provide a better assistance, but that's how it is. — Dsimic (talk | contribs) 18:17, 19 August 2014 (UTC)

Just a heads up to let you know I responded to your request with a question. MjolnirPants Tell me all about it. 13:48, 21 August 2014 (UTC)

Hello there! Thank you very much, I'll respond there in a few minutes. — Dsimic (talk | contribs) 04:47, 22 August 2014 (UTC)

Hi. Thanks you for your comment in revert in Duff's device with link to WP:COMPNOW. I think we should somehow mention in introduction that this method was used in 1980-s and in early 1990-s, but can be harmful for modern optimizing compilers (it creates very complex CFG - control flow graph - which should be deoptimized back into simple unrolled loop before compiler can optimize it in correct way)... a5b (talk) 17:50, 21 August 2014 (UTC)

Hello there! You're welcome; by the way, WP:COMPNOW is a recently added guideline and I've seen it as a result of watching the page it belongs to. As we know, relation between the Duff's device and modern compilers is already covered in Duff's device § Performance section, here's a quotation for completeness:

This automatic handling of the remainder may not be the best solution on all systems and compilers – in some cases two loops may actually be faster (one loop, unrolled, to do the main copy, and a second loop to handle the remainder). The problem appears to come down to the ability of the compiler to correctly optimize the device; it may also interfere with pipelining and branch prediction on some architectures. When numerous instances of Duff's device were removed from the XFree86 Server in version 4.0, there was an improvement in performance. Therefore, when considering using this code, it may be worth running a few benchmarks to verify that it actually is the fastest code on the target architecture, at the target optimization level, with the target compiler.

You're right that the article's lead section should also sum this briefly – went ahead and slightly expanded the lead section, improving one reference at the same time. Please check it out, hopefully you'll find it good enough. :) — Dsimic (talk | contribs) 05:42, 22 August 2014 (UTC)

Thank you. PS: what do you think about Reliable Sources for Ribbon cable (flat IDE cable)? I added two at bottom after improving ru: article ru:Ленточный кабель. `a5b (talk) 00:48, 23 August 2014 (UTC)

You're welcome, I'm glad you like changes to the Duff's device article. Regarding those two references, I presume you refer to these two edits to the Ribbon cable article? They look good and WP:RELIABLE; however, they should be converted into WP:FOOTNOTES, as in current form they're more suitable to be moved into new "Further reading" section. — Dsimic (talk | contribs) 04:37, 23 August 2014 (UTC)

I think 'class="hintergrundfarbe6"' is a color code for the cells. I borrowed the tables from a German Wikipedia page haha, the class may not apply here. Thanks, again, for the help! — Preceding unsigned comment added by Jchap1590 (talk • contribs) 23:00, 24 August 2014‎ (UTC)

Hello there! You're right, 'class="hintergrundfarbe6"' changes the color of table headers, I've confirmed that by temporarily changing Wiki code on the German Wikipedia page linked above. And, yes, that CSS class doesn't apply on the English Wikipedia. :) You're welcome, and thank you for your contributions to the DIMM atricle, I've just touched them up while reviewing the changes. — Dsimic (talk | contribs) 05:21, 25 August 2014 (UTC)

Hey, I like the new table layout! It may be my browser version or some other factor, but it looks like there is a broken empty row from the DDR2 table on the second column of tables. I didn't see anything in particular that needed correcting, however. see here: http://i1304.photobucket.com/albums/s526/jason_chapman1/DIMMSpeeds_zps1d66ed8b.png Jchap1590 (talk) 22:09, 1 September 2014 (UTC)

Thanks, and that's a very good remark – you're right, there are some issues when {{Div col}} template is used for a compacted layout and columns contain tables; additionally, the template documentation states that it "handles wiki table code", but it's up to browsers to split the content into columns. I've just tried it in Internet Explorer 11, and I can only confirm that it doesn't render columns properly; though, I see it as an empty row inserted before the end of the DDR2 table in the first column, while its last row "overflows" into the second column – how much sense in the world does that make? :) Anyway, Firefox 31.0 renders it just fine.

Went ahead and changed the way layout compaction is performed; that's still not an ideal way to do it, but unfortunately I'm unaware of a better way. It renders fine in Internet Explorer, but the issues are now on narrow screens – please try resizing your browser window and you'll see what I'm talking about. I'd really love to know if there's a better way to do it? — Dsimic (talk | contribs) 04:34, 2 September 2014 (UTC)

Just tried another approach that uses {{Col-float}} template and it slightly simplifies the Wiki code. Though, it's still not ideal as column breaks must be specified manually instead of having a dynamically adjusted number of columns that's produced by the {{Div col}} template. — Dsimic (talk | contribs) 05:08, 2 September 2014 (UTC)

You are invited to join the discussion at Talk:Hard disk drive § An End To The RAMAC Price Duologue. Please help end the duologue on capacity and price of the IBM RAMAC Model 350 disk file. Thanks. Tom94022 (talk) 21:49, 4 September 2014 (UTC)

Sure thing, I'll have a look into that in the next few hours. — Dsimic (talk | contribs) 21:57, 4 September 2014 (UTC)

Done, added a comment. — Dsimic (talk | contribs) 05:06, 5 September 2014 (UTC)

{{anchor|2-clause}}

=== {{anchor|2-CLAUSE}} 2-clause license ("Simplified BSD License" or "FreeBSD License") ===
Content ... ...

Hello. I assumed that {{anchor|2-clause}} and {{anchor|2-CLAUSE}} are hidden anchors and "#2-clause license ("Simplified BSD License" or "FreeBSD License")" is an explicit anchor, which is the opposite to a "hidden anchor". Maybe I got wrong, maybe you meant "anchor with an all capitalized name" by saying "explicit anchor"? --Tomchen1989 (talk) 23:09, 4 September 2014 (UTC)

If so, I don't know why we should use an "anchor with an all capitalized name" instead of a normal anchor. Is there a guideline about this? Thx. --Tomchen1989 (talk) 23:12, 4 September 2014 (UTC)

Please allow me to explain. In a few words, no anchors (as HTML elements) are visible in resulting web pages; let's have a look at what the HTML code looks like for a section title:

<span id="Section title" class="mw-headline">Section title</span>

Creating a section also implicitly creates an anchor (the <span> HTML element above) with the same name as the section title, and that's what an implicit anchor is. On the other hand, placing {{Anchor}} templates explicitly creates additional anchors (hence the name of such anchors). The main benefit of explicit anchors is that they remain unaffected if a section becomes renamed later – that's why using explicit anchors is always a good idea when linking to sections.

Regarding the all-uppercase names for explicit anchors, there are no guidelines regarding that (AFAIK) but I've seen a few other editors doing that for explicit anchors so I've followed them. As of why, that way it's much easier to distinguish implicit and explicit anchors wherever they're referenced – if it's an all-uppercase anchor, that's an explicit one. Hope you agree. — Dsimic (talk | contribs) 23:53, 4 September 2014 (UTC)

Ah you mean {{anchor|2-clause}} and {{anchor|2-CLAUSE}} are explicit anchors, and "#2-clause license ("Simplified BSD License" or "FreeBSD License")" is an implicit anchor, just the opposite to what I thought LOL. Whatever.. Thank you for clarifying this. I'm aware of these concepts and techniques, I just didn't know what you meant by saying "explicit anchor". <a name="link_here"></a> (btw no whitespace is allowed in name or id attribute in the specification) was used, but now it is not supported by HTML5. Although the template's name is {{Anchor}}, it renders as a <span id="link_here"></span> rather than an anchor element <a></a> in HTML actually.

Well I still have a little doubt about that word "explicit" after doing a little lookup. It seems that WP:ANCHOR uses the word "explicit" to describe section title links.

Anyway, it is not the definition of "explicit" that matters here. Under your definition, I've replaced an explicit anchor "#2-CLAUSE" with another explicit anchor "#2-clause". You can see in the article BSD licenses we have {{anchor|2-clause}} {{anchor|3-clause}} {{anchor|4-clause}} with lowercased names, but we only have {{anchor|2-CLAUSE}} with a uppercased one. There should not be too much {{anchor}}. As a shortcut, one {{anchor}} for every section title is usually enough. It is reasonable to remove that "isolated" (no other anchor with uppercased name) {{anchor|2-CLAUSE}} I guess. I don't see using all-uppercase name for anchors is conventional at all. Unless if it's an unwritten but relatively conventional approach used or advocated by even a small majority of editors, I don't think it's good to use uppercase names.--Tomchen1989 (talk) 00:52, 5 September 2014 (UTC)

Sorry, this means that I was unnecessarily explaining concepts you're already familiar with. I apologize for doing that. Of course, thank you for further clarifications and corrections. By the way, I really don't know else how should the results of placing {{Anchor}} templates be called? You're right that WP:ANCHOR seems to be using word "explicit" for exactly the opposite anchor variant, but FWIW that makes little sense to me.

Regarding {{Anchor|2-clause}} in the BSD licenses article, I've contributed to the whole confusion by looking at the Wiki code by clicking on "edit" links right to the section titles; this explicit (or however it should be called :) anchor is placed in a separate line before the section title, what makes it invisible when a section is edited. I totally agree that {{Anchor|2-CLAUSE}} is then redundant, but according to documentation of the {{Anchor}} template additional anchors should be part of the lines that contain section titles (== {{Anchor|EXAMPLE}}Section title ==, for example).

All-uppercase explicit (additional or whatever) anchors or not? Of course, that's debatable as there are no guidelines that would either encourage or disallow such a scheme. To me, all-uppercase anchors are quite usable – again, FWIW. — Dsimic (talk | contribs) 01:25, 5 September 2014 (UTC)

Well, technically and very strictly, I guess it can be called "a subordinate resource that can be pointed to by URI with a hash mark ('#') fragment identifier".

But it can also be called:

1. fragment identifier (strictly speaking, it's the "#ABC" "?ABC" stuff in the URI, not the resource it points to)
2. link (but "link" usually refers to the <a href=""></a> anchor, or the URL "http://...", rather than the thing we are talking about)
3. link within a page / link within the same page (understandable)
4. internal link (very ambiguous. it has two meanings: 1. (primary) an anchor link to a page outside the same domain name; 2. the thing we are currently discussing here. The lead section of the article Internal link defines it using the first meaning, but the "Examples" section uses the second, this article definitely needs to be rewritten)
5. section link (for Wikipedia pages)
6. anchor / anchor name (as I mentioned before, "anchor" is an old school name and technically not that right since it's not necessarily an anchor element <a href=""></a>. However the word is largely used and may considered OK)

For the part where {{Anchor|2-clause}} is outside the section and invisible when the section is edited, I put all those anchor templates inside their related section titles. --Tomchen1989 (talk) 10:19, 7 September 2014 (UTC)

We should also take into account that it's the MediaWiki who diverts from the ordinary definition of HTML anchors, what was required for MediaWiki redirects and such stuff; a brief explanation is available here: Wikipedia:Village pump (technical)/Archive 121 § JavaScript and redirects issues?. As we know, including #ABC in a URI works only with <a href=""></a> if there is no additional JavaScript code that would handle the page positioning. With all that, MediaWiki's "anchor" is pretty much unrelated to true HTML anchor elements – it's more of an abstraction of that concept, if you agree.

And, of course, thanks for folding the {{Anchor|...}} templates into section titles! — Dsimic (talk | contribs) 20:56, 7 September 2014 (UTC)

Hey, I just wanted to offer my apology since my edit summary wasn't as polite as it could have. Sorry about that and glad that you took it so well. Cheers! --uKER (talk) 02:39, 11 September 2014 (UTC)

Hello there! No worries, just as I've stated in my consecutive edit summary that was a clear mistake from my side, and your disagreement was perfectly fine. The tone in which the disagreement was expressed might be debatable, but it was fine with me – I'm always more than open to having anyone point out my mistakes, as that's the best way for both personal and project improvements. In other words, I'd say that there was pretty much no need for the apology, however I'm happy that you've thought about it afterwards and I'm more than gladly accepting it. Thank you! :) — Dsimic (talk | contribs) 19:28, 13 September 2014 (UTC)

While we're here, it might be good if I describe further the reason why I've reverted your edit on the Dalvik (software) article a few minutes ago. I totally agree with you that we shouldn't limit ART to the previews of Android L, but that's all what we have currently available from Android L. In my opinion, your edit is just fine but we should probably wait with it until Android L becomes released and available in its production form. Hope you agree. — Dsimic (talk | contribs) 19:36, 13 September 2014 (UTC)

Well, I understand that theoretically there's the remote possibility that L could go back to Dalvik and to avoid going WP:CRYSTAL we should leave it, so well, while it's now what I'd do, I respect your concern. --uKER (talk) 20:34, 13 September 2014 (UTC)

Nice job on the Docker, it looks much better now! Best, --Nabak (talk) 16:16, 21 September 2014 (UTC)

Hello there! Thank you very much, I'm glad that you like those layout improvements. — Dsimic (talk | contribs) 20:38, 21 September 2014 (UTC)

What about the Sony Xperia Z3 and the Sony Xperia Z3 Compact? --Jobu0101 (talk) 20:14, 11 October 2014 (UTC)

Hello there! Regarding my edit on the Nexus 4 article, I probably wasn't clear enough in the provided edit summary. It was about "768×1280" being uncommon as the way to specify a screen resolution, not about how often screens with that resolution are found in cellphones. In other words, "1280×768" is the common way to specify this screen resolution; if you look around, it's almost always that the bigger number goes first. — Dsimic (talk | contribs) 20:41, 11 October 2014 (UTC)

However, UKER just reverted my edit; if that's the standard format for cellphone screens, I'm fine with it, although "1280×768" is more logical to me. — Dsimic (talk | contribs) 20:47, 11 October 2014 (UTC)

Screen resolutions have been historically expressed as Width*Height, and that's the way most technically correct sources mention it (see GSMArena, PhoneArena). Some sources use it the other way around (biggest length first) I guess for the sense of familiarity, as for example 1080x1920 doesn't ring the same bells in the public as 1920x1080. I, for one, am for keeping it as WxH, since it reflects the true orientation of the display, but feel free to put it up for discussion if you see fit. --uKER (talk) 23:13, 11 October 2014 (UTC)

It all makes sense, and I don't see the need for starting another discussion. However, maybe I'm a bit old-fashioned, but I'm somehow "classifying" the screen resolutions mentally by their first numbers; thus, seeing "768" as the first number brings me a much worse sense of direction than seeing "1280" first. Of course, that's just me. — Dsimic (talk | contribs) 01:07, 12 October 2014 (UTC)

Yes, I know HHVM is defined as HipHop Virtual Machine in that article; I meant exactly what I said, which was that no pronunciation is given. My point was that, as a native English speaker, I can see no way to pronounce "HHVM" other than as an initialism.

I admit all that was a bit unnecessary, so, sorry for such a wordy edit summary in the first place; but I digress. To get to the point:

• Does that capitalization convention also apply to {{Redr}} or only the single-rcat templates?
• Is this a serious enough issue that I should be editing redirects I previously categorized just to capitalize that "R"? My understanding is that such trivial edits are normally discouraged. Is there some previous discussion I should be looking at?

--SoledadKabocha (talk) 00:41, 12 October 2014 (UTC)

Hello there, and thank you for the clarification! I can't pronounce "HHVM" in any other way either, not even in my native language if that matters. :) No worries about your edit summary, maybe it was just a bit confusing but adding {{R from initialism}} was totally fine.

Regarding the capitalization of template names, that's debatable and I'm unaware of any associated official guidelines. However, I tend to capitalize them, and {{R from initialism}} also refers to itself with a capital R. At the same time, I'd usually leave such edits to Wiki code unchanged, but I've used that more to quickly comment back. Not a great way to do that, I know; hopefully you find that acceptable. — Dsimic (talk | contribs) 02:09, 12 October 2014 (UTC)

Thank you. I've been trying for a few years in the Turkish language. I know Wikipedia, but I do not have much English :( --Fsandlinux (talk) 19:28, 13 October 2014 (UTC)

You're welcome, and thank you for your contributions. Just keep working and learning – almost everything can be accomplished by investing some time, together with applying just the right amounts of elbow grease. :) — Dsimic (talk | contribs) 20:16, 13 October 2014 (UTC)

I think the guy you just reverted was referring to the fact that Google officially announced Lollipop for the N4 a couple of days ago. --uKER (talk) 12:54, 21 October 2014 (UTC)

Well, I've reverted Harshal.dhumal's edit that pretty much changed the Nexus 4 article so Lollipop is stated as an offical and over-the-air upgradable release. As we know, Lollipop is still only a developer preview, which requires a phone to be flashed using one of the official preview images. Thus, to me it's better to wait a bit longer until Lollipop becomes released as a regular Android update. Hope you agree. — Dsimic (talk | contribs) 19:46, 21 October 2014 (UTC)

Hello again, there, sir! I was wondering if you would be able to provide assistance with improving the RAID-Z section (which was) in the non-standard RAID levels article. the information was unsourced and has been deleted by another user. I feel this is an important topic on the subject of non-standard RAID and would like to ask for your help in recreating the section. Thanks, in advance, for any consideration. Jchap1590 (talk) 07:33, 26 October 2014 (UTC)

Hello! Thank you for bringing it to my attention; of course, I agree that RAID-Z deserves to be part of the Non-standard RAID levels article. Though, as everything else in Wikipedia, it needs to be backed by a few references – I'll have a look into finding better references, as the ones used for RAID-Z descriptions in the ZFS article are somewhat bordering with what's acceptable. To keep the discussion in one place, I'll post my findings and further opinions in Talk:Non-standard RAID levels § RAID-Z section you've already created. — Dsimic (talk | contribs) 08:54, 26 October 2014 (UTC)

Hello Dragan,

I found your Picture of a small Voltage and Current Meter for USB-Connections on Wikipedia: File:USB voltage and current meter.jpg.

As I am preparing an article about Charging of portable devices from different sources and especially the Problems the User should be aware, I am asking you two questions:

1. May I use this picture in the publication in the German Radio Amateur Magazin FUNKAMATEUR? Of course, I will mention it in a literature annex, where I've found it.
2. Could you please give an Idea, were I will have a chance to buy such a useful tool? This question is primarily because I expect users to ask me or the publisher after publication where they may buy it and/or looking for more detailed specs, such as voltage drop on the GND or the V_BUS line(s).

I am awaiting your kind reply. kind regards, or as Radio Amateurs around the world would say: vy 73.

Hartwig Harm, DH2MIC http://dh2mic.darc.de [in German :-( ] mailto: dh2mic@darc.de — Preceding unsigned comment added by 84.148.215.15 (talk) 16:05, 7 November 2014 (UTC)

Hello there!

Sure thing, please feel free to use this picture in the article you're preparing. The picture has been made available and licensed under CC-BY-SA-3.0, which allows pretty much all kinds of usage, though a brief attribution would be required.

I've bought this gadget on eBay; since that time, other variants became available as well – some of them provide simultaneous voltage and current readouts, others even provide power measurements and estimated battery capacity readouts (in mAh, of course). More fancy versions even have OLED displays, :) and just saw that some versions additionally allow calibration to be performed by end users. Simply search for "USB meter" on eBay, and you'll see a whole bunch of such devices, which are also quite cheap at the same time (under $10). Unfortunately, detailed specifications for these measurement devices, such as their temperature dependencies and incurred voltage drops, do not seem to be available. However, accuracy levels are usually available, and they're typically specified to be within 0.1 V and 0.01 A error margins.

As a side note, you might also find Wikipedia's USB article usable, sections USB § Power, USB § Charging ports, and USB § USB Power Delivery in particular. Those sections provide an overview of the power delivery over USB ports and involved negotiation between devices, as well as links to detailed documentation that describes it further and provides official specifications.

Is your article, once it's published, going to be available online? I'd like to read its published version, if possible. :) — Dsimic (talk | contribs) 21:05, 7 November 2014 (UTC)

The request about Wikipedia style and naming looks confusing. 84.127.115.190 (talk) 23:52, 9 November 2014 (UTC)

Hello! Thank you very much for bringing it to my attention, I'll make sure to make it less confusing; that's the result of a bot listing it on Wikipedia:Requests for comment/Wikipedia style and naming. — Dsimic (talk | contribs) 00:25, 10 November 2014 (UTC)

Done, it should be better now. Improved RfC description should be picked up soon by Legobot. — Dsimic (talk | contribs) 01:13, 10 November 2014 (UTC)

My friend Dragan! First of all, I see that you have been recognized by one of my few other Wikipedia buddies QWERTYVS [or is it QWERTYUS ?]; and so I draw your joint attention to the anomalous Wikipedia entry on the movie "Red Planet Mars", which movie (which I have just viewed on Youtube) was a quite heartfelt and anomalous comment on the possibility that compassion is a universal reality! But the Wikipedia entry itself is way, way out there! Synchronist (talk) 05:25, 10 November 2014 (UTC)

Hello! Unfortunately, I haven't watched Red Planet Mars yet, but I'll make sure to do that. Based on what's available in Red Planet Mars § Plot, I'd say that it describes what might be seen as "search for the higher goal". In other words, human society seems to be flooded with "you must have latest and greatest <something>, which is of course much more shiny, bigger and better", while things like alternative, less polluting energy sources are receiving much less (public?) attention. Knowing that we aren't alone in space might be a wake-up call for the search for the higher goal, bringing back more compassion into people's hearts at the same time. :) — Dsimic (talk | contribs) 06:36, 10 November 2014 (UTC)

Sorry for reverting your changes to Ethernet. I mistook 1BASE5 for 10BASE5. I don't think I would have made this error if you had linked to StarLAN instead of 1BASE5. I'm tempted to change that. Do you have any objection? ~KvnG 15:50, 11 November 2014 (UTC)

Hello there! No worries about reverting those changes, we're all here to work together. I totally agree that it's very easy to see "10BASE5" while looking at "1BASE5", as 10BASE5 was actually used and seen around in commercial networks. While 1BASE5 is actually a redirect to StarLAN, I went ahead and clarified it a bit further; please check it out. Looking good? — Dsimic (talk | contribs) 17:21, 11 November 2014 (UTC)

Hello, Dsimic. You have new messages at Talk:Bufferbloat.
Message added 18:21, 11 November 2014 (UTC). You can remove this notice at any time by removing the {{Talkback}} or {{Tb}} template.

Widefox; talk 18:21, 11 November 2014 (UTC)

Hello! Thank you for bringing it to my attention, I've just replied on the article's talk page. — Dsimic (talk | contribs) 18:46, 11 November 2014 (UTC)

Category Linux kernel on Commons is empty, actually in use category Linux-Kernel. --Victor•talk 18:50, 11 November 2014 (UTC).

Hello! That's a good point, thank you for pointing it out. However, having "Linux-Kernel" as a category name is simply awkward... I'll see how to get that cleaned up. Once again, thank you for the SVG drawing, it looks great! — Dsimic (talk | contribs) 18:57, 11 November 2014 (UTC)

 Done: After a lot of clicking around and editing, Linux kernel category replaced Linux-Kernel on Commons. — Dsimic (talk | contribs) 20:05, 11 November 2014 (UTC)

I saw your desire for a lowercase username on your user page. While not technically possible for the reasons you state, you can somewhat fake it by adding {{Lowercase title}} to your user page and user talk page, then changing the capitalization in your signature. This is just merely a tip from your friend who also prefers a lowercase username. – voidxor ^{(talk | contrib)} 20:57, 13 November 2014 (UTC)

Hello! Thank you for the tip, but that might create some kind of a discrepancy between different places where the same username is displayed, like in article histories, diffs, talk page posts, etc. Sure thing, changing the case of one letter doesn't introduce a huge discrepancy, :) but I've also seen some editors that use completely different names in their signatures, what makes quite difficult to track and correlate their edits in various places. With all that in mind, back at the time I've decided to ignore my desire and keep capitalized username all around. :) — Dsimic (talk | contribs) 22:05, 13 November 2014 (UTC)

Don't feel bad about making this error; even native English speakers make it all of the time (myself included). The problem is English spelling—not you! May I suggest the following userbox? – voidxor ^{(talk | contrib)} 21:09, 13 November 2014 (UTC)

Hehe, well, that mistake was a true brainfart from my side, and I wouldn't attribute it to English spelling. :) Speaking about the English-language spelling reform, that's a highly debatable topic... Inevitably, every language becomes changed slightly over time, but it also isn't good to lose the existing variety and fine language details. I always tend to compare such simplifications to the so-called Web 3.0 when it's displayed on large screens – it becomes a big question why large screens are actually needed. :) — Dsimic (talk | contribs) 22:43, 13 November 2014 (UTC)

Months ago, I wrote a review about Dsimic. I have defended this user when he made a good decision. Now, I would like Dsimic to reflect on his contributions; I am aware of what has happened in Linux distribution. 84.127.115.190 (talk) 06:02, 16 November 2014 (UTC)

Hello! I understand your concerns, so please allow me to explain.

It's all about bringing in opinions from more editors, as the whole thing in Wikipedia talk:WikiProject Software § Date format in release history sections of Linux articles pretty much turned into a not-so-well discussed imposing of additional rules to a WikiProject. Please don't get me wrong, I'm not trying to influence the outcome of the discussion; doing something like that would also be against WP:CANVASS. Instead, what I'm trying is to turn that into a much better discussion that would lead to a much broader consensus, which may be whatever we end up with.

In other words, a few editors simply can't create new guidelines – a much broader consensus is required for something like that (please see WP:CONLEVEL). Furthermore, that proposed new guideline even went into effect in a few places, what simply isn't the way to go. Thus, the whole thing spins out of control and doesn't have much sense if we don't bring in more editors, and that's what I've tried to do by posting invitations to talk pages of a few editors with substantial edits in the field; doing something like that complies with WP:CANVASS.

Hope you agree. — Dsimic (talk | contribs) 06:35, 16 November 2014 (UTC)

I'm not looking for support. I'm trying to warn people (and give accurate info) about the FACT that PAD, a game enjoyed by millions of people several times a day on Android, will not be playable for them once they allow the upgrade to 5.0. Since you're well-established here, perhaps you can add that info in the appropriate ways and places? To those who play the game (and those seeking facts about ART vs. D.) it is significant. Thanks! JT (talk) 02:13, 18 November 2014 (UTC)

Hello! Thanks for the clarification. As with any major software release, or major architectural change in a mature software product, there will always be bugs, unforeseen troubles, and eventually broken stuff. Your report on this Android game no longer working with ART is valid, but unfortunately Wikipedia shouldn't list individual problems with particular software products; that would turn Wikipedia into a bug tracker, what it isn't. On the other hand, adding such info would be doable in case such problems are widespread (affecting numerous Android applications, in this case), together with having them backed by reliable sources. Hope you agree. — Dsimic (talk | contribs) 02:33, 18 November 2014 (UTC)

The HDD article concerns HDDs, not SSDs. HDDs less than 100 MB aren't common, because they're largely obsolete. Cluttering the article with SSD-specific provisos and eventualities is not justified. It just adds clutter. SSD formatting should be addressed elsewhere, not here.71.128.35.13 (talk) 22:55, 20 November 2014 (UTC)

Hello! Thank you for bringing it to my attention, I'll reply in Talk:Hard disk drive § Partitions? File systems? RAID? section so we keep the discussion in one place and better visible to more editors. Just for later reference, it's about this revert on the Hard disk drive article. — Dsimic (talk | contribs) 23:19, 20 November 2014 (UTC)

Could you weight in on Wikipedia:Articles for deletion/DDR5 SDRAM, since it seems that nobody feels qualified to "vote"? Thanks! Thue (talk) 18:45, 23 November 2014 (UTC)

Hello! Thank you for bringing it to my attention, I'll have a look and possibly cast my vote. — Dsimic (talk | contribs) 22:41, 23 November 2014 (UTC)

Done, unfortunately the article should be deleted as highly misleading; it seems to be created by a confused editor that jumped the gun over some quick searches for "DDR5". — Dsimic (talk | contribs) 23:27, 23 November 2014 (UTC)

Hi, there is broken link in article in Ref. #3.  --Victor•talk 19:24, 23 November 2014 (UTC).

Hello! Nice catch, thank you! I've just fixed the reference by pointing it to another web page that also provides man page for the ksplice-create utility, which covers the content in article's lead section. While we're here, may I ask you to have a look at the Wikipedia:Graphics Lab/Illustration workshop § A high-level overview of Ceph's inner workings section, just in case you might be willing to take that request as well? :) — Dsimic (talk | contribs) 21:59, 23 November 2014 (UTC)

OK, I will.  --Victor•talk 23:45, 23 November 2014 (UTC).

Thanks! — Dsimic (talk | contribs) 23:46, 23 November 2014 (UTC)

Dragan, I have for the first time found it necessary to stick a fork in something -- see my recent edit to the "Semantic Search" article. The guys at IDMARCH are giving semantic search a bad name, and so I have tried to follow the BOLD directive -- but perhaps there was a better way? Synchronist (talk) 04:41, 29 November 2014 (UTC)

Hello! I had a look at your edit on the Semantic search article, and unfortunately there are a few issues. The biggest issue comes from the fact that, in general, editors should try to refrain from writing about something they're directly involved with; please see WP:COI for more details on possibly associated issues. Also, articles should never include links to Wikipedia user pages; even using self-written published articles as references requires additional attention, please see WP:SELFCITE for more details. — Dsimic (talk | contribs) 05:02, 29 November 2014 (UTC)

OK, it's been undone, and thanks for keeping me on the straight and narrow! But if you find out anything about those guys at IDMARCH -- their motto is "Designed and built with all the love in the world in Europe", although the site is basically anonymous -- I would love to be clued in. Synchronist (talk) 15:30, 29 November 2014 (UTC)

You're welcome, and I'm glad that you took it so well, so to speak. I know, it's quite difficult to go by all the guidelines, rules, essays and unwritten rules Wikipedia has in place – it's no surprise that nowadays not many editors contribute new content to Wikipedia articles. Speaking about that IDMARCH thing, right off the bat it looks a bit strange to me; with no description of who they actually are and why do they do that, it looks as just another AdWords revenue generator. — Dsimic (talk | contribs) 22:00, 29 November 2014 (UTC)

Dragan, there has been a happy ending -- or perhaps beginning! -- to the story. I used the "whois" facility to get the email address of IDMARCH's founder, and we had a pleasant correspondence today (available here: http://www.space-machines.com/Nov_29_correspondence_with_IDMARCH_founder.pdf ), with the salient feature that he has added a facility to the web site enabling one to determine the number of hits for a particular article. Unfortunately, I have had no hits except my own, and so my consternation with Dragomir -- for that is his name -- has now now turned to solicitude. He really has pulled off a neat trick in indexing 7 million PDF documents -- the only one of the many semantic search engines out there, for example, to have found my two articles, if Google Advanced Search can be trusted in my hands, and the semantic indexing is really not bad. Furthermore, he has asked for ideas, and so I will be thinking about ways to help him in both practical and strategic terms. And given that I have alluded in the correspondence to a Wikipedia buddy who is perhaps his near countryman -- and the guy, in fact, who got the critical edit reverted! -- it would be quite appropriate for you to jump into the fray. All for now, but there is much, much more I could say about all of this. Synchronist (talk) 02:28, 1 December 2014 (UTC)

Hey, that's great you've actually reached someone at the other end of the wire! I'd be extremely happy to see a semantic search website like that grow into something many people use to find better-matched content. I'll think about what could be added in terms of features, options, etc. For the beginning, it might be good for the website to include a description of what they do and why do they it, so it looks less like a puzzle. By the way, it's quite interesting to compare websites with US background and those having Eastern Europe or (in particular) Russian background – it might be only up to legal stuff, but the US ones tend to provide better descriptions of actual intentions that drive them. Oh, and based solely on Dragomir's last name, he and I could be considered countrymen only if we abstract out hundreds of miles and a few country borders. :) — Dsimic (talk | contribs) 05:52, 1 December 2014 (UTC)

Since you made the solid-state storage redirect, just notifying that because I have been informed there are some other kinds of non-drive storage (cards) I turned the SSS page into a disambig. Was wondering if you know any other types, or if I am wrong and other forms of solid-state storage like the SD Card might be considered drives in some way. --64.228.88.135 (talk) 01:29, 1 December 2014 (UTC)

Hello! That looks like a good move to me, thank you! I've just improved it a bit, so the major meanings are listed, and so it conforms to the basic guidelines for disambiguation pages. There's also the Flash-based storage page, and I've turned it into a redirect to Solid-state storage – that should fit better with the now available disambiguation page. Just as a note, article links in general shouldn't point to disambiguation pages (linked example might not be very good as it was more of a prose addition, which might have introduced potential confusion that early in the article's lead section); please see WP:DABNAME for more details. — Dsimic (talk | contribs) 07:05, 1 December 2014 (UTC)

Hello, both illustrations in this article are out of date: as if OpenBSD "quit" :) in mid-2013, as if Mac OS X is not OS X now and v.10.10, etc., etc... You may answer in Gr. Lab. --Victor•talk 08:54, 4 December 2014 (UTC).

Hey Victor! Yes, both File:Unix history-simple.svg and File:Unix timeline.en.svg could use some maintenance. :) I'll see to compile a list of required changes to these two drawings, thank you for pointing it out! — Dsimic (talk | contribs) 10:33, 4 December 2014 (UTC)

Hi. I saw that you deleted the addition about PDF pages on WP:Citing sources, on the grounds of avoiding browser-dependent stuff and/or needing more explanation of where it works. As far as I know it works in all popular browsers, including the built-in PDF viewers and Adobe plug-ins for Chrome, Firefox, IE, and Safari. And according to SourceOhWatch (SrotahaUvacha), who originally added it, if a browser doesn't support it, then it degrades gracefully with the browser displaying the first page.

I added a comment to Wikipedia talk:Citing sources#PDF page links, with a link to a PDF explaining these hash URIs. If you know of any browser-dependent issues, could you leave a comment there? Otherwise I'd like to put it back. Thanks. – Margin1522 (talk) 15:03, 6 December 2014 (UTC)

Hello! Well, the content I've deleted would require additional explanation; basically, it should be explained that it depends on built-in web browser functionality (or a browser plugin), and that it works only when a linked PDF file is viewed/opened inside a web browser. Despite the introduction of somewhat technical mumbo-jumbo, :) having that additional explanation would be beneficial. Hope you agree. — Dsimic (talk | contribs) 15:19, 6 December 2014 (UTC)

OK, I think that since the only way to view a Wikipedia link is in a browser (right?), we don't need to explain that. But I guess it wouldn't hurt to add a caveat that the browser has to support it. There are dozens of viewers and OS variants for smartphones, and some of them might not. Would the following be OK?

Note that this functionality depends on support from the browser's PDF viewer. In some cases, the browser may ignore the PDF page specification and display the first page instead.

I don't think we have to worry about downloaded files. Users will expect the browser to download the whole file, which is what happens, and then once you have the file, the link where you got it is irrelevant. – Margin1522 (talk) 17:05, 6 December 2014 (UTC)

Actually, links to PDF files do not always end up viewed inside web browsers – some people prefer to use "open with" or even to save PDFs before opening them using a separate application. Furthermore, if we go into corner cases, someone could even use wget or curl to bypass the browser entirely. :) Anyway, your additional explanation is just fine, I totally agree on including it. By the way, as another editor pointed out, I was wrong and WP:YOU doesn't apply to guidelines, which already address readers directly in numerous places. — Dsimic (talk | contribs) 06:55, 7 December 2014 (UTC)

That's a point. In the meantime, Mxn has restored it in the guideline with a better version of the caveat. He's also started a thread at Module talk:Citation/CS1/Archive 11#PDF page links, where Gadget850 pointed out that this has been discussed before and rejected for reliability reasons. – Margin1522 (talk) 07:47, 7 December 2014 (UTC)

Went ahead and improved the guideline addition (clarified and added the note you've proposed above), hope you find it good. Yeah, I saw the module talk discussion, and it surely isn't "dependent on the server", as web servers generally have nothing to do with the URLs they're requested to serve. Of course, if a PDF file isn't served statically that's another story, but the majority of PDF files are served that way. — Dsimic (talk | contribs) 07:58, 7 December 2014 (UTC)

Just saw your edit on restrict with the pithy description "Hm, doesn't look like an improvement". How is marking an example as flawed (is not actually an example due to other issues) even if one cannot (maybe just then) add a correct one, *not an improvement*? I reverted your edit. 94.220.161.15 (talk) 22:57, 13 December 2014 (UTC)

Hello! I apologize for my terse edit summary, please allow me to explain it here. First, the changes I've undone introduced additional spacing that's too Java-like and doesn't improve the code readability. Second, but not too important, since when "UB" is an abbreviation for "undefined behavior"? Sorry, but I've never heard of it. Third, what's the point of saying that those pointers might overlap? Surely they all might overlap or point to exactly the same location, as pretty much nothing of that is checked against by the C language, compiler or runtime; even with restrict in place, the pointers can still overlap or be the same as restrict is merely a hint to the C compiler. Additionally, could you please elaborate a bit on how and why the example in Restrict § Optimization section is broken?

Usually I wouldn't immediately revert an edit performed this way (with an ongoing discussion), as doing something like that pretty much isn't by the WP:BRD, but your edit is somewhat misleading; thus, I've dared to revert it. Hope you understand, and I'm more than open to discussing this further. — Dsimic (talk | contribs) 08:57, 14 December 2014 (UTC)

Hi, re this edit, mousing is a word, see wikt:mouse#Verb. --Redrose64 (talk) 19:15, 16 December 2014 (UTC)

Hello, and thank you for pointing that out! Got my associated neural paths updated. :) — Dsimic (talk | contribs) 20:16, 16 December 2014 (UTC)

Don't do this again. It is pointlessly antagonistic. There is nothing which makes an editor look less suitable for collaborative development than this sort of idiotic revert war. The rationale behind keeping the case is that if the link is somehow transformed such that the piping is no longer necessary (such as in "Interface" in your example, where the pipe trick means the piped text can be omitted entirely in the edit) it doesn't accidentally enter wrongly-cased text. If you've some control issues with your life that you need to work out, do it somewhere else. Argh, and this was going so well. Chris Cunningham (user:thumperward) (talk) 10:32, 11 December 2014 (UTC)

Hello! If I may notice, your commanding tone isn't that friendly, and it simply doesn't help in making Wikipedia a good and collaborative environment. If there's a disagreement, we're here to discuss it and find a solution whatever the subject is. Anyway, is there a guideline about that, or are those just your own preferences for piped links? As far as I can see, Wikipedia:Piped link says nothing about the case; by the way, the tone you used in an edit summary while adjusting that guideline today also doesn't seem to reflect a great amount of tolerance and openness to discussion.

At the same time, please stay away from involving any personal issues as you see them – no editor, myself included, simply doesn't deserve to be addressed that way. We're here to make articles better; as WP:TPYES says, "comment on content, not on the contributor". Also, as an administrator, you should be the one who promotes friendliness and tolerance, and helps in reaching compromises and solutions for various issues that are inevitable along the way. — Dsimic (talk | contribs) 11:40, 11 December 2014 (UTC)

The precise tone I use is dependent on context. You've demonstrated that you're a mature editor with a solid understanding both of the technical matters of what you edit and of the editing process itself. Accordingly, I'm not going to beat around the bush when confronted with passive-aggressive nonsense like this (not by any means the first summary revert I can remember). I've provided an actual rationale, whereas you simply pointed at an example without any elaboration on why you think that example said what it did. The onus is on you to explain your edit, not on me to find some stone tablet marked with instructions that back up the rationale I've provided. But I'd far rather you simply stopped doing it, and reconsidered whether using the undo button on good faith edits is improving the project. That article has a long way to go (though it's getting better incrementally) and it needs its editors to be cooperating rather than competing with one another. Chris Cunningham (user:thumperward) (talk) 12:58, 11 December 2014 (UTC)

No matter how something is or isn't to be approached softly, friendliness and non-commanding tone only demonstrate one's maturity and improve the overall desire toward collaboration and team work. Also, technically speaking, I didn't revert your edit, as that wasn't performed by clicking on the "undo" link. However, the way my edit was performed is less important, and here's why I find capitalized piped links to be suited better.

As we know, Wikipedia internally capitalizes article titles by default and nothing can be done to prevent that; using {{Lowercase title}} only displays lowercase titles while reading articles. Thus, following the Wikipedia's approach down to piped article links makes things more consistent; the text to right of the pipe is what's to be displayed, while the text on the left is pretty much Wikipedia's "key" for the linked article. In regular non-piped links, using a lowercase title (where appropriate, of course) actually determines what's displayed, with automatic conversion into article "keys" (capitalized titles) when a page is rendered and actual URLs are generated. In other words, using "keys" in piped links stays to Wikipedia's (externally visible) internal way of referencing articles.

Of course, a perfectly logical question for my train of thoughts is "why shouldn't then [[Article|article]] also be used?" Because only the first letters in article links become automatically capitalized, no matter what, and that can be relied upon to produce valid "keys". At the same time, repeating pretty much the same string twice would be overly redundant.

Considering your rationale toward keeping piped links case in accordance to their positions in sentences, so someone later isn't going to put a capitalized word in the middle of a sentence, I'd say that "foolproofing" it that way simply isn't worth it. Unfortunately, if an editor isn't careful enough to click on "show preview" and review his/her changes before hitting "save page", nothing helps, and we'll probably have much bigger errors to handle than needlessly capitalized words.

Hope it makes sense. — Dsimic (talk | contribs) 14:12, 11 December 2014 (UTC)

The English Wikipedia's use of initial uppercase in article titles is a hack for articlespace; it's not the preferred form for MediaWiki itself (nor the other namespaces on en-WP), and in any case the very last thing we should be optimising for is the backend codebase. It is far better to optimise for editors, who should see as few implementation details as we can get away with. As far as editors should be concerned, Example and example are exactly equivalent, and thus "optimisation" of pages by piping the latter to the former shouldn't even be considered. What that boils down to is that we should not be including capital letters in links unless except in the specific case that we want them in the output. Chris Cunningham (user:thumperward) (talk) 10:50, 12 December 2014 (UTC)

While understanding your reasoning, I still respectfully disagree. It's perfectly fine to have different opinions on things not covered by any explicit rules or guidelines, and probably the solution in this case is not to modify case of piped links once they're placed into an article's Wiki code. — Dsimic (talk | contribs) 13:25, 12 December 2014 (UTC)

Nope. Your version is demonstrably broken IMO, leading to unnecessary piping for pointless optimisation. I fixed this during routine copyediting and will continue to do so in future. I don't expect that such changes will be reverted in future. Chris Cunningham (user:thumperward) (talk) 13:59, 15 December 2014 (UTC)

How can that be clearly demonstrated, and how does that cause "unnecessary piping"? What I've questioned above about [[Article|article]] was not a suggestion for something like that to be used, but exactly the opposite; that was just a self-asked question for my reasoning.

Also, I expect you not to do such copyediting, as there are no related guidelines; moving forward, I won't do such changes either. Changes in case would be similar to switching articles between different styles, what's‍—‌as we know‍—‌explicitly forbidden in the lead section of WP:MOS and further explained in this ArbCom ruling. — Dsimic (talk | contribs) 14:22, 15 December 2014 (UTC)

It's not "switching articles between different styles"; it was only present in a couple of sentences. I don't really expect to find many articles where this idiosyncrasy has been prevalent since article creation, but if I do then you're free to invoke ArbCom rulings regarding style changes on said pages if you wish (though I dare say most people would consider invisible changes like this to be a different matter from the language and date formatting disputes that led to ENGVAR). Chris Cunningham (user:thumperward) (talk) 14:29, 17 December 2014 (UTC)

It does involve some kind of switching an article or its part between different styles, or better said, between different personal preferences. If something isn't explicitly regulated by a guideline, and if there are multiple ways to do it with the same or similar final results, then that is some kind of a style and the only good solution is to leave it as-is while copyediting articles. Thus, there's simply no ground for saying that you "will continue to do so in future" – in that case I also have the same right to implement my preferred style; though, as we probably agree, there's no point in doing something like that. Of course, there's also the article-level consistency argument that may justify such changes in style, but that clearly wasn't the case in BIOS article.

Would you feel comfortable if I ask for a WP:3O on this? We're clearly in a slight disagreement here, and a third opinion might help. — Dsimic (talk | contribs) 22:49, 17 December 2014 (UTC)

IMO it's far too much work to have to decide whether any particular area of syntax oddness is due simply to sloppy editing or some editor's particular writing idiosyncrasies across the entire encyclopedia, and therefore editors shouldn't be expected to do so, particularly in cases where the style in question is obviously not in common use. You can ask for a 3O if you like, though I'm sure you're aware that as a non-binding process it's unlikely to resolve an issue which is basically a difference in personal aesthetics. Chris Cunningham (user:thumperward) (talk) 13:18, 18 December 2014 (UTC)

That's exactly why I've said that the case of already existing piped links should simply be left unchanged while editing articles – that way no personal preferences would be involved into something that isn't regulated by Wikipedia's guidelines. Also, based on my experience, [[Article|something]] form is much more commonly used than [[article|something]]. Thus, capitalized form is far away from being "not in common use". — Dsimic (talk | contribs) 13:56, 18 December 2014 (UTC)

In early computer the CPU it was the only unit that handed all the system. The only "clever" unit. All passed through the CPU (memory accesses, interrupts, etc.). So that the name "central". To day the function of old CPUs is to execute only the "instructions" of a program and no other. It is equivalent to another processor, for instance Disk processor, Graphic processor etc., just only with a different task. The correct name would have to be "instruction processor" but it is called shortly only "processor". We have Intel processor, PowerPC processor etc. but no one recall the term CPU, why ?. Because it is obsolete. Please does not to confuse the term "central" with the "main" meaning, that is the most important processor just only because execute the instructions that are the main function of a computer. I am a super expert in the computer field, mainly in multiprocessor e NUMA system with several patents (more than twenty: find: Ferruccio Zulian patent). I have collaborated with Olivetti, IBM, General Electric, Honeywell, Bull, AT&T, NCR during more than 30 years as computer architect with more a tens design systems. In wiki there are many not correct information written by no not expert people. Ferry24.Milan (talk) 19:37, 18 December 2014 (UTC)

Hello! While your reasoning makes sense to a certain degree, changes you've introduced into the Central processing unit article would require at least one good reference. As you probably already know, Wikipedia doesn't allow original research, and content of the articles should be based on reliable sources. Please don't get me wrong, that isn't personal and means absolutely no disrespect – that's simply the way Wikipedia works.

At the same time, I do remember "CPU" as a term and use it regularly; the actual meaning, which might be somewhat historical, should be clear to a wide audience. Also, if we stretch your rationale far enough, even the PC XT's 8088 chip shouldn't be called a CPU as it, for example, relies on the 8259A PIC for interrupt handling; XT's selection of graphics cards just takes that further. As another example, with that reasoning even the Commodore 64's 6510 can't be called a CPU, as it offloads majority of graphics and sound processing to VIC-II and SID chips. All that wouldn't make much sense, if you agree. — Dsimic (talk | contribs) 11:00, 19 December 2014 (UTC)

Was this really necessary? To boost your edit count? I added the tag and reason; do we need to start nitpicking over a period? WP:OWN --82.136.210.153 (talk) 08:02, 28 December 2014 (UTC)

Sorry, that probably came across too harsh. Didn't mean it like that. --82.136.210.153 (talk) 08:10, 28 December 2014 (UTC)

Hello there! No worries, I'm not an overly thin-skinned person. :) Of course, removing that period wasn't absolutely necessary, but it should be better not to have it for two reasons: that isn't a complete sentence, and placing a period there effectively creates a "link" to a non-existing "GPL." section on the article's talk page. However, if you really prefer to have that period, please feel free to put it back. :) — Dsimic (talk | contribs) 08:32, 28 December 2014 (UTC)

Merry Christmas and Happy New Year! Password Saeba Ryo (talk) 12:59, 24 December 2014 (UTC)

Thank you very much, best wishes to you too! :) — Dsimic (talk | contribs) 15:23, 24 December 2014 (UTC)

Sorry, but I don't get it? Now you want to take back your good wishes? Changing your mood so quickly makes absolutely no sense, unless you've tried to use such stuff for campaigning related to the discussion taking place in Wikipedia:Articles for deletion/IA-32 (see also WP:CANVAS). — Dsimic (talk | contribs) 00:14, 25 December 2014 (UTC)

This is not personal, but Merry Christmas and Happy New Year! Password Saeba Ryo (talk) 11:49, 25 December 2014 (UTC)

Hehe, well, this is now really confusing and a bit weird. :)

Please keep in mind that everything I wrote regarding IA-32 vs. x86 vs. x86-64 isn't judging you as a person but your statements, and all that has only improvements to the articles as the final goal. While working together on improving an article, the editors should judge only each other's contributions to the article and statements expressed on the talk page, and nothing more; that's what "it isn't personal" means.

On the other hand, when we express good wishes related to holidays, there has to be at least some amount of personal involvement if the wishes are true. Such wishes show good will and positive feelings about an editor, while they aren't directly related to the articles we're working on or we have worked on.

Hope it makes sense. :) — Dsimic (talk | contribs) 12:31, 25 December 2014 (UTC)

Hi. User:Password Saeba Ryo has been blocked indefinitely as a sock puppet of User:Janagewen. --Claw of Slime (talk) 12:13, 27 December 2014 (UTC)

Hello! Thank you very much, Claw of Slime, for clarifying this somewhat awkward situation with Password Saeba Ryo. And, of course, Merry Christmas and best wishes for the around-the-corner 2015! :) — Dsimic (talk | contribs) 12:53, 27 December 2014 (UTC)

I invite you to this page to discuss that should the consistency of talk pages of IA-32, x86 and x86-64 should be kept! Because I've seen you as one of most active editors there. So thank you! Remover remover (talk) 15:14, 29 December 2014 (UTC)

Thank you for bringing it to my attention, I've cast my vote there. — Dsimic (talk | contribs) 15:29, 29 December 2014 (UTC)

We don't know its cache system until we see the actual product in fall 2015. Before that we'd stick with current info. Please do not edit this unless you're an employee that works for Intel. Thank you! — Preceding unsigned comment added by 71.57.33.215 (talk) 08:05, 6 December 2014 (UTC)

Hello! Well, if you insist, leaving the article's infobox as-is is fine with me; also, cache-related information is already tagged with {{Citation needed}}. However, it's quite unlikely that the L1 cache in Skylake is going to be bumped to 128 KB, but the time will tell whether that will be the case. — Dsimic (talk | contribs) 08:14, 6 December 2014 (UTC)

All the back-and-forth (also known as edit warring) over essentially unsourced L1/L2/L3 cache sizes information is pretty much pointless, so it is better not to have that as part of the article's infobox at all. At the same time, content marked with {{Citation needed}} may be removed if the sources haven't been provided for extended periods of time, and in this case no sources have been provided since October 2014. — Dsimic (talk | contribs) 18:31, 30 December 2014 (UTC)