Talk:Main Page

From LQWiki
Jump to: navigation, search

Some older posts have been moved here: Talk:Main Page (archive) for purposes of readablity.

SPAM

  • We've had a sudden rash of spam and I've installed some additional anti-spam measures as a result. If anyone notices any kind of collateral damage, please let me know ASAP. Jeremy 18:34, March 12, 2011 (UTC)

Upgrade

  • Just upgraded to the latest version of MediaWiki (1.15.1). If you run into any issues, let us know. Jeremy 18:15, February 27, 2010 (UTC)

Facebook Connect

Testing fbconnect 693221900-fb 00:12, March 1, 2010 (UTC)

Edit Note

  • Edits were disabled for about 12 hours while we addressed some spam issues we were having. We've made a couple minor changes and haven't gotten any additional spam in the 4 hours since we enabled edits. We'll keep an eye on things from here - thanks for the patience.
Just made some additional changes to try and slow down the current spam attack. If needed we will temporarily disable edits again. Jeremy 15:32, October 10, 2007 (EDT)
We've added some additional spam filtering - thanks for the patience. Jeremy 18:19, October 30, 2007 (EDT)
Seems to have worked, current spam comes from "contributors" who have registered months ago. --ThorstenStaerk 00:44, November 5, 2007 (EST)
I noticed this also, it's an odd pattern. We have two pending code updates that should help alleviate some of this. Jeremy 10:12, November 9, 2007 (EST)
Have you noted we have 18491 users according to http://wiki.linuxquestions.org/index.php?title=Special:Listusers&limit=500&offset=18000
I've been addressing some of the ones that are clearly spam. Thanks. Jeremy 15:23, November 9, 2007 (EST)

Suggestions for links

  • Other Linux wikis, most notably (according to Alexa traffic rankings): linux.wikia.com, wiki.ubuntu.com, wiki.debian.org, gentoo-wiki.com and last but not least (because LQ is home to the official Slackware forum) slackwiki.org. -- Marsm 05:27, May 28, 2007 (EDT)
  • HOWTO section
  • Performance
    Can someone please add Performance to the main page, it seems like here would be a better place for it rather then at the end of the "gaming" page. SciYro
    I agree Performance could be added, but please make sure the size of the main page is reduced for readability. I would remove distributions, People and Programming --ThorstenStaerk 04:35, February 17, 2007 (EST)
    I just added a link to performance in Linux_installation, that seems like a good place for it. You could also integrate a link to it from the Common_Tasks page imo. There is much room for improvement of course in the organisation/cleanness/readability of the installation or Common tasks pages right now, but i think one could easily find its way to the performance page from those places, or maybe even from the hardware page.
    I don't know if the link will be put on the main page but for now that should be a good start. my two cents. Questynux 06:00, February 17, 2007 (EST)
  • Where's the best place for cronic hardware/kernel problems? There is a largish problem revolving around APIC (not ACPI) timing issues under various linux kernels that cause the machine to freeze up hard. I'd like to add information about that, and I'm sure there are other cronic issues that deserve to have some space in the WIKI as well. -Scott Miller (5mi11er)
troubleshooting and apic. --ThorstenStaerk 13:18, November 12, 2009 (UTC)

Spam links

Just deleted what appeared to be spam links to german horoscope sites. If those were legit, someone let me know. Crazyeddie 03:19, Jul 3, 2004 (EDT)

That's ok - In order to assess the appropriateness of material, all content must currently be in English, and any external sites which are linked to must also be English language based - General policies
-- Skyline 06:23, Jul 3, 2004 (EDT)

Advocacy article

Should there be an Advocacy section linked from the Main Page? --Bunyip 08:52, Jul 23, 2004 (EDT)

Importing Advocacy article from Linux Documentation Project

Crazyeddie 11:54, Jul 23, 2004 (EDT):Perhaps, but an Advocacy article doesn't exist yet. There's an advocacy article over at the Linux Documentation Project, but we would have to get permission from the author of the article, because it looks like their license is not compatible with Creative Commons. Here's the copyright info:

TLDP Advocacy HOWTO's copyright information

This mini-HOWTO is Copyright © 1996-2000 by Paul L. Rogers. All rights reserved.

A verbatim copy may be reproduced or distributed in any medium physical or electronic without permission of the author. Translations are similarly permitted without express permission if it includes a notice on who translated it.

Short quotes may be used without prior consent by the author. Derivative work and partial distributions of the Advocacy mini-HOWTO must be accompanied with either a verbatim copy of this file or a pointer to the verbatim copy.

Commercial redistribution is allowed and encouraged; however, the author would like to be notified of any such distributions.

In short, we wish to promote dissemination of this information through as many channels as possible. However, we do wish to retain copyright on the HOWTO documents, and would like to be notified of any plans to redistribute the HOWTOs.

We further want that all information provided in the HOWTOs is disseminated. If you have questions, please contact Tim Bynum, the Linux HOWTO coordinator, at linux-howto@sunsite.unc.edu.

Responses

The "Derivative work and partial distributions of the Advocacy mini-HOWTO must be accompanied with either a verbatim copy of this file or a pointer to the verbatim copy" bit would seem to indicate that we could add the HOWTO(s) to the wiki (it would become a "Derivative work" after the first edit), as long as we include a link to the original verbatim copy, which should not be a problem.
Jeremy 15:27, Jul 23, 2004 (EDT)
Yes, but could we in good faith release it under the Creative Commons and let others reuse it from us? I think you might be right, but I would feel better if we got explicit permission from the author. At least there is a single author, unlike most Wikipedia articles. I was planning on trying to incorporate TLDP HOWTOs, as soon as I got to a certain point in the Jargon File incorporation, so I've had some time to think about this. Do you have any contacts at TLDP, or should I just email the guy myself? Crazyeddie 18:34, Jul 23, 2004 (EDT)

TLDP manifesto

Looking at http://www.tldp.org/manifesto.html I see:

"5. LICENSE REQUIREMENTS

Anyone may copy and distribute (sell or give away) LDP documents (or other LDP works) in any media and/or format. No fees are required to be paid to the authors. It is not required that the documents be modifiable, but it is encouraged.

You can come up with your own license terms that satisfy these conditions, or you can use a previously prepared license. The LDP has a boilerplate license that you can use if you wish. Some people like to use the GPL, while others write their own. There is a project underway to create a special GPL license just for documents and this may turn out to be a good choice.

The copyright for each document should be in the name of the principal authors. "The Linux Documentation Project" isn't a formal entity and thus can't be used as a copyright owner. "

Responses

This seems to fit exactly in with what we want to do. I'll contact TLDP just to verify, however. I'll post the outcome here.
Jeremy 00:53, Jul 24, 2004 (EDT)
After discussing this with TLDP, I am going to revisit the ability to add GFDL items to the LQ Wiki. Stay tuned. Jeremy 12:17, Jul 25, 2004 (EDT)

How would that work? I thought that the Creative Commons/GFDL incompatibility was pretty well established. "East is East and West is West, and ne'er the twain shall meet." As the GFDL and the CC are presently written, material under one can't be released under the other without the permission of the copyright holder (the original author in most cases). There's rumors that the FSF and the Creative Commons people are working on that issue, but until then, we're pretty well stuck with just asking for permission. Not that I would mind an easier solution, but I just don't think it's possible.Crazyeddie 16:40, Jul 26, 2004 (EDT)

It would work something like this. When you enter in a doc, there would be a "this is GFDL" checkbox. That doc would then be under the GFDL and *not* the CC. There are a few problems with this, and it could get complicated quite quickly, so It's not a definite addition at this point, just somehting we are exploring. Jeremy 17:50, Jul 26, 2004 (EDT)

Hmmm. That would be possible if it was a new article, and that the changes made to it were also GFDLed. But it would lead to some articles being GFDL, some being CC. A hack, but we're kinda in a corner. I think we'd still be better off contacting the original authors and getting CC permission, since this would increase the number of options available to downstream users (they would be able to use our version under the CC and the original under the GFDL), but I'd be willing to go along if there is consensus for it. Crazyeddie 15:32, Jul 27, 2004 (EDT)

Jeremy, if you're still seriously considering dual-licensing, you might want to look at this first: http://en.wikipedia.org/wiki/Wikipedia_talk:Creative_commons_migration Keep in mind that I did not seriously expect this to be accepted, I was more trying to raise awareness of the problem. I would not have even suggested it if I hadn't (which I still do!) believed that the Creative Commons by-sa license is superior to the GFDL. Crazyeddie 19:06, Aug 2, 2004 (EDT)


How about changing the notice at the bottom of each edit page to ... "WITHOUT PERMISSION from the authors to post under LQWiki's Creative Commons license." You should add that each page is owned by the authors listed in its history. TomFrayne 09:58, Jul 24, 2004 (EDT)

Crazyeddie's extended post

(added sectioning for readability) That would be an ugly hack. I think I'd rather roll our own HOWTOs than go through that. Anyway, I'm looking at this from the point of view of a general solution rather than just importing this one article. Some reasons I think we should contact the article authors and ask for explicit permission:

  1. The Manifesto is a suggestion or a guideline for the TLDP contributors to use when deciding what licensing scheme to use. It doesn't look like they're too big on enforcing it, or at least a few of the older articles didn't even bother appending a license. It is not a license in and of itself.
  2. Even if the contributors do follow the Manifesto's guidelines, they don't have to allow modifications.
  3. They may have released in under a copyleft modifiable license that isn't compatible with the Creative Commons such as the GFDL. I'm not sure, but I don't think the GPL is Creative Commons compatible either.
  4. Like the manifesto says, the LDP is not the copyright holder, so they can't unilaterally give permission.
  5. Even if we could use an article without permission, it would be good form to tell the author about it. For example, if the author can no longer maintain or host the original, he or she could tell their users where they could go to get an updated copy. It occurs to me that the LDP could see us as competition. It might be a good idea to stress that they can backport any changes under the Creative Commons. Anybody else have any ideas that might smooth the path?
  6. Letting an experienced technical writer know about this wiki is a Good Thing. This subproject gives us a good excuse.
If you would like to start contacting authors of articles you think should be added, please feel free to do so. If you need anything from our end, let me know. Jeremy 17:54, Jul 26, 2004 (EDT)
Okay. I'll use Talk:Linux Documentation Project as a sort of improvised "command center" in case somebody else wants to help out/take over. A good first step would be to send off a general email to their mailing list. (I'll make sure that I mention that I'm doing this as my own intiative, not as an 'offical' LQwiki project.) If you don't think it's confidental or something, could you send me a copy of the correspondence you had with them? After the general email, I'll try contacting the Advocacy HOWTO's author. If anybody has suggestions on what to incorporate next, head over to the LDP talk and let me know. Crazyeddie 15:23, Jul 27, 2004 (EDT)
I have a draft email up on Talk:Linux Documentation Project. Please go idiotproof it everybody! Crazyeddie 16:14, Jul 27, 2004 (EDT)
Seems completely idiotless. :) Digiot 17:17, Jul 27, 2004 (EDT)

I'm placing the email on hold until I can rewrite it, to reflect my promotion to moderator. (Since I'm now moderator, it pretty much has to be an offical LQwiki project.) Also, it occurs to me that Grokdoc might want in on this. Crazyeddie 19:10, Aug 2, 2004 (EDT)

Have a list of LDP howtos up over at Talk:Linux Documentation Project. Take a look over and let me know if there is a howto you want me to put on the to-do list. Crazyeddie 18:50, Jul 28, 2004 (EDT)
Seems like to me the best principle would just be to prioritize them into 'niche interest' and 'outdated for a reason' and then take the remaining generally important and relevant topics and do them in chronological order. A major problem is outdated data and attacking that first would probably be most useful and most suited to wikification. Also, those authors who have abandoned or rarely update their topics might be the most receptive to passing on the maintenance of them, including relicensing or whatever it takes. Digiot 22:31, Jul 28, 2004 (EDT)
But on the other hand, abandoned or rarely updated documents also will be the hardest to get permission for. But I get your drift. I'll go over the list myself tomorrow, but I would like to know if there is any particular ones people want. This is going to take long enough that there is no reason to stick to any particular method if there's one that somebody really wants. I'll rig up some sort of voting system I suppose. I've already taken off some "removed for review" entries and I'm going to go back and remove some internationilization howtos, since those are usually written in a different language. (I'll also replace the sectioning with bullet points - didn't realize how ugly it would look until I was halfway through.) Crazyeddie 01:31, Jul 29, 2004 (EDT)

Okay, voting is setup (kinda). Crazyeddie 19:10, Aug 2, 2004 (EDT)

Disclaimer

A bit off the main topic, but one thing I noticed over at the TLDP... It might be wise to have a "No Warranty, As Is" type notice at the bottom of the page, down in the copyright notices. Unlike the Wikipedia (who have a similar notice, but a bit more buried) we're handing out documentation which could cause serious damage if used improperly, or if it is incorrect. In addition to it being a just plain good idea, some of the TLDP articles have that as their sole condition for modification and redistribution. If we actually do have something like that already, well, my friends don't call me "Captain Oblivious" for nothing. Crazyeddie 13:24, Jul 24, 2004 (EDT)

Good idea - a disclaimer has been added. Thanks. Jeremy 12:41, Jul 25, 2004 (EDT)

I've edited it to include contributors under the "don't sue us!" umbrella. Crazyeddie 18:48, Aug 2, 2004 (EDT)

Forum Revisited

Several people have asked about a general LQwiki discussion forum. Does anybody have any objections to using this talk page as such a forum? Crazyeddie 14:02, Jul 24, 2004 (EDT)

wiki software link

Is there a link on the main page or somewhere at the bottom where people can see what wiki software is being used here. It might be nice to link to the software's homepage, assuming it is free. I looks mostly like the software used on wikipedia, with some very nice modifications. --Paraphelion 06:50, Feb 9, 2005 (EST)

We do infact use MediaWiki, which is mentioned in the FAQ. Jeremy 11:31, Feb 10, 2005 (EST)
Where is the FAQ linked? It might be nice to also mention this information in "About LQ Wiki", especially because the link is on each page. There's no reason not to have it in both. I'm surprised that the FAQ isn't linked on the about page. --Paraphelion 02:54, Feb 15, 2005 (EST)

Could we open up our modifications to the community? It seems like there is some interest in them, and it's possible that some downstream users will make modifications that we might find useful... 15:24, Feb 10, 2005 (EST)

At this time we realistically don't have the resources to support a release. More and more, the changes are mostly cosmetic and not functional anyway. What we will definitely do moving forward is push bug fixes (and features if there is interest) upstream so that everyone can benefit. Jeremy 22:57, Feb 10, 2005 (EST)

I'm not suggesting a full release. I'm suggesting making our patches available. For the spellchecker, for example. Last I heard, MediaWiki is reluctant to uptake spellchecking because Wikipedia servers can't handle the load. (Or at least that's what the rumors say.) If enough downstream users show an interest, I think they might change their minds. Crazyeddie 03:23, Feb 11, 2005 (EST)

I remember that our modifications aren't in patch form... Could we possibly give read-only access to our cvs? Are we using a cvs? Crazyeddie 03:41, Feb 11, 2005 (EST)

CVS is not used for the LQ Wiki. Jeremy 16:51, Feb 11, 2005 (EST)

How about just an archive of our current PHP code? Surely y'all make backups? Crazyeddie 17:26, Feb 11, 2005 (EST)

As I mentioned earlier, just releasing the code without being able to support it in any way is probably not in anyones best interest. Aside from that, I don't want it to be seen as a fork, which it isn't. Users will get 100% of the benefits by us pushing bugfixes upstream. If there is interest in the spell checker (or anything else we have here) upstream we'd be more than happy to push that too. Jeremy 10:07, Feb 13, 2005 (EST)

I'm not talking about a formal fork, with the support and code maintenance involved. I'm talking about an open documentation project, based on open source software, making its modifications to that software public.

Ideally, since we're only making modifications, not a full fork, we should make those modifications available in the form of patches. In addition to being helpful for third-party users of MediaWiki software, it would help us when it comes time for us to upgrade to the next MediaWiki release, and it would make it easier for MediaWiki to upload our modifications. I fully agree that getting MediaWiki to upload our mods is the best solution, since that would mean that we would no longer have to maintain the code ourselves.

The current method of handing out our modifications, which consists of: "email Jeremy, and he'll fish out the bit you need and email it to you" is not convenient for either party. I think I've seen about six requests for our code in wiki, and I doubt that many requests have made it to you.

As I said, I think the ideal solution is to make our modifications available in patch form. But I realize that such a move would probably involve a lot of work, and I'm trying to suggest a compromise solution. Instead of having to exchange emails, all you would have to do is grunt "Code's over there. Help yourself." We should make it clear that we don't support the code, we're just handing it out to anybody who wants it. If somebody finds a bug, they can tell us about it, but we'll probably only fix it if the bug directly affects us. Patches would be welcome.

Our main added feature is spellchecking. There has been some interest in a spellchecking feature over at the Wikipedia. However, spellchecking would put an additional strain on their servers, so they haven't rolled their own yet. I think MediaWiki would only put in spellchecking as an optional feature if there was strong interest downstream. Some downstream wikis using an experimental and unsupported spellchecker would be a strong argument in favor of formal inclusion of a spellchecker option.

Something similar could be said for any additional feature we might make in the future. If we're adding the feature ourselves, then there is probably some reason why it isn't in the MediaWiki code already, and it will only be added as an option if there is strong downstream interest. The existance of a patch would no doubt help.

Even if one of our modifications is cosmetic, and not worthy of being included in MediaWiki, we should still make it available. There is no telling what an administrator might find helpful.

The LQwiki's main need right now is additional contributors, ideally ones with experience in Linux and/or wikis. Having wiki patches available would give us greater visibility in the wiki community, especially with administrators.

We might even attract some additional administration staff, who might be willing to help with other LQ projects.

Lastly, I think that providing documentation for wiki administration falls under the subject matter of this wiki. I don't think it's a stretch to include wiki code cookbooks. Crazyeddie 15:46, Feb 13, 2005 (EST)

We would not be providing a sealed software package to a helpless user. We would be providing prewritten cookbook code to an administrator, who would hopefully have the coding skills needed to modify our code to their own situation. Crazyeddie 17:00, Feb 13, 2005 (EST)

Because MediaWiki is distributed under the GPL, you MUST make your modifications available to the public in some manner. A good reason to roll your changes back into the original is so that you don't have to re-patch your code whenever you want to upgrade to the new version. Xxxyyy 19:28, Mar 10, 2005 (EST)

Correction, we only have to provide the code if we redistribute the program. That's my understanding, at least. If we were handing out or selling binaries we would have to make the code available at no more cost than the cost of physically creating the media. Since we aren't handing out binaries, but only using the MediaWiki engine internally, we aren't required by the GPL to hand out code. Google, for example, uses Linux to power their proprietary search engine magic. They, or so I have heard, did make modifications to Fedora Linux in order to use it in their operations, but since they only use it internally, they don't have to hand out their top-secret secret sauce.

I just happen to think that handing out our modifications is a good idea. To a certain extent, Jeremy agrees with me. Where we differ is how to go about it.

Jeremy would love to roll back our changes to MediaWiki. Problem is, most of our changes are cosmetic, only of use to us - or so we think, no telling what another wiki-admin might do with it. MediaWiki hasn't shown much interest in adapting our changes that aren't cosmetic. The main example being the spellchecker. (Making our code more easily available might change that though.)

I'm supporting making our code available to anyone who passes by. Right now, you could get the code by emailing Jeremy (I think, don't quote me on that), but that's not exactly convenient for anybody concerened.

Jeremy is worried that if we make our code easily available, people will think we're doing our own offical fork, and expect us to maintain it and provide support. Our coding room, which consists of exactly two part-time coders, who also keep the entire LQ site up and running, simply doesn't have the resources to do that.

I'd like some compromise plan - make our modifications easily available, but also stave off any requests for support with a clear, upfront, STFU. Crazyeddie 03:43, Mar 11, 2005 (EST)

Article diffs hard to interpret

Is there some reason that the diffs in this wiki are so different in appearance from the default? The color highlighting seems to be completely missing, and looking at the diffs isn't nearly as useful as a result. --Yath 16:04, Jul 26, 2005 (EDT)

Thanks for the feedback Yath. I'll look into this. Jeremy 09:18, Jul 27, 2005 (EDT)
This has been fixed - Thanks again. Jeremy 11:34, Jul 27, 2005 (EDT)
Thanks that's much better. --Yath 12:23, Jul 28, 2005 (EDT)

Your RSS feed now included in Planet Wiki

Hi, I included your RSS feed in Planet Wiki, a service of the Wikinerds Community which offers an online news aggregator that collects various RSS feeds from many wikis around the WikiWikiWeb. In this way more people may find your wiki and become contributors. If you have any maximum-hits policy please contact me through email. Good luck with your wikisite! Www.wikinerds.org 07:18, Jul 29, 2005 (EDT)

Thanks! Jeremy 11:17, Jul 29, 2005 (EDT)

link to linux-net

Is there someplace to put a link to the linux networking development wiki? http://linux-net.osdl.org

merging other Linux wiki -- Main Page locked

On http://en.wikibooks.org/wiki/Talk:Linux_For_Newbies , someone suggested merging that wiki with this Linux Questions wiki. The *only* reason given for not merging these wiki is that the main page of Linux Questions (unlike every other page of both wiki) is not editable.

  • Should the Main Page be locked?
  • Should these wiki be merged?

--DavidCary 17:16, Jan 13, 2006 (EST)

I'm not sure what is meant by "merged", but it doesn't look like the discussion about this topic is too active at the link you mentioned as there are only two comments with the most recent one being four months old. That being said, we'd surely encourage participation here at the LQ Wiki and I'd agree that often times content is far too spread out. We'd be happy to provide the resources needed on this one. While the main page is locked, the talk page can be used to discuss entirely new sections. It should also be noted that content here can be either CC or GFDL (although of course the two can't be mixed). If there is anything else I can help with, let me know. Jeremy 21:06, Jan 14, 2006 (EST)

Dos problemitas que tengo - 2 problems that i have

moved to User talk:Weimarcastro

Wiki Design problems

I'm not sure if you're aware that the top navigation of the wiki is not clear on Firefox 2 besides a white background for articles would be more readable --walidaly 12:35, Apr 02, 2006 (GMT)

Firefox 3 only shows the top half of the tabs...
#column-content {lq.css?195 (regel 46)
  margin-top:0;
  padding-top:37px;
}
seems an incompatible .css statement to me... (has been there for years I guess) - Bemoeial 10:32, May 1, 2009 (UTC)
The tabs seem to render OK for me in FF 3.x, but we'll take a closer look. Jeremy 16:21, May 1, 2009 (UTC)

Main Page strategy

I would rewrite the Main Page to be shorter and thus easier to read. I would like to go the "what do you want" approach, 4 links come to my mind:

http://wiki.linuxquestions.org/wiki/Special:Popularpages this is by far the most-read article (besides Main Page)

  • Guides/Tutorials/HowTos: you know what you want to accomplish, but do not know how. You need a tutorial
  • Tips: you do not have a concrete question, but the tips here will pay for reading them
  • Introduction: you need an introduction to Linux

Source Code Markup Support

Any ideas of when support can be added for the "<source>" tag? It makes source code very readable. Thanks. --Rdrdrd 16:30, October 14, 2008 (UTC)

This is a mediawiki extension, see http://www.mediawiki.org/wiki/Extension:ASHighlight --ThorstenStaerk 08:53, October 15, 2008 (UTC)
It looks like there are a couple MW extensions for this, each with its own set of issues/problems. Is the consensus that something like this is needed here? Jeremy 20:09, October 15, 2008 (UTC)


Confusing structure

The structure of the main page is a bit confusing since several links are to the same page. Instead of having

I think it should be

Unfortunately I can't edit that. Mikedlr 10:56, November 12, 2009 (UTC)


Incomplete License Notice

The bottom of each page reads, "Content is available under unless otherwise noted." It seems like there should be a specific license included, there, such as, "Content is available under The Most Awesome License Ever, unless otherwise noted." (License title subject to change.)  ;-) DaneM (talk) 02:16, August 15, 2014 (EDT)

We'll roll out a fix for this, thanks. LQWiki:Copyrights has more information about LQ Wiki licensing. Jeremy (talk) 11:53, August 15, 2014 (EDT)