(Arch) Linux Myths

fijam · 2010-11-13 15:15:47

I have recently noticed that online forums and Linux user communities in particular are prone to developing what I'd like to call "technology myths".

Most of the problems and solutions given on forums are anecdotal in nature. Problems are rarely sourced to the actual code and suggestions are often casual or incomplete which is of course natural for this kind of communication. However, as certain solutions are being repeated without clear feedback, some notions take deeper roots in the collective consciousness thus becoming myths. Let me illustrate with an example.

How often have you seen people posting glxgears results? How often have you seen people replying "glxgears is not a benchmark"? Could you actually explain why it's not suitable to be one? The explanation is out there.

Another example could be the myth that exporting INTEL_BATCH=1 increases performance on Intel integrated GPUs. I have seen this in circulation for a long time, despite the fact that the actual code that could be triggered by this environment variable has been removed a long time ago.

As Arch Linux is rolling-release and a lot of code is being replaced rather rapidly, old and tried solutions are likely to become obsolete fast. I'd like to ask the Community to share their examples of other widely circulated myths and help keep an updated and sourced list of them (https://wiki.archlinux.org/index.php/Myths) so others will not waste their time trying solutions which are sure to fail.

theapodan · 2010-11-14 05:03:25

It may be helpful to revise inaccurate wiki articles, rather than expecting someone to read the myths page.

For example, some of these wiki articles have a reference to INTEL_BATCH, which possibly should be removed:
INTEL_BATCH

jocheem67 · 2010-11-14 05:28:10

I follow the wiki's, they never let me down. I'm no expert, just a happy user with moderate skills reg. linux.
I do realise that some of the tips provided are at your own risk and may not help at all. One who already got to using Arch/Linux will probably know that.

fijam · 2010-11-14 07:47:56

I intended to link this page whenever someone repeats bogus solutions on the forums. This way other people could see the mistake in context, and remember to avoid repeating it.

Screening the wiki is an entirely separate issue, but to do this it would be necessary to identify those common misconceptions first (so pause for a moment and contribute please ). And I do believe that keeping a list is crucial as even if I remove the mentions of INTEL_BATCH from the wiki I won't be able to stop other users from adding it again.

.:B:. · 2010-11-14 08:23:30

I think it's still a good idea (context is never bad). But, as theapodan says, it is equally useful to clean out the related wiki pages that keep recycling this error (the forums aren't well suited for this) *and* refer to your myths page for the context on those very same pages that need cleaning (or have been cleaned).

655321 · 2010-11-14 09:09:23

Cleaning those pages can take a long, long time and effort, while putting up a myths page can be a LOT faster. In short, the myths page can be a good starting point for doing this.

ngoonee · 2010-11-14 11:22:17

Nobody is going to check a myths page until AFTER they encounter and are bitten by a myth.

Awebb · 2010-11-14 13:21:28

Myth:
acpi_osi=Linux solves all problems on Laptops.
acpi_osi="!Windows\ 2006" solves all problems on Laptops

Try asking google what acpi_osi is. You'll get a million links to ubuntu forums and blogs and alike but no actual information about the kernel parameter acpi_osi.

In fact, using such parameters solved some problems and created new ones.

I found an explanation here: http://www.mjmwired.net/kernel/Document … meters.txt

226        acpi_osi=    [HW,ACPI] Modify list of supported OS interface strings
227                acpi_osi="string1"    # add string1 -- only one string
228                acpi_osi="!string2"    # remove built-in string2
229                acpi_osi=        # disable all strings

I can't find any actual information when wich line should be used.

I consider this a myth, because it seems to be the holy grail of fixing problems on laptops and netbooks. It just moves the problems to other fields.

rwd · 2010-11-15 18:33:50

Placebo tweaks make your computer *feel* faster.

ChoK · 2010-11-15 22:51:57

Recompiling kernel with -funroll-loops

dptkby · 2010-11-15 23:08:55

Well, for me the truth is that without said kernel parameter adjusting the brightness of my screen doesn't work and with, it does. I gather it tells *some* part of your system to expect dealing with Linux (BIOS?), can't say I know exactly what it accomplishes.

Awebb wrote:

Myth:
acpi_osi=Linux solves all problems on Laptops.
acpi_osi="!Windows\ 2006" solves all problems on Laptops
Try asking google what acpi_osi is. You'll get a million links to ubuntu forums and blogs and alike but no actual information about the kernel parameter acpi_osi.
In fact, using such parameters solved some problems and created new ones.
I found an explanation here: http://www.mjmwired.net/kernel/Document … meters.txt
226        acpi_osi=    [HW,ACPI] Modify list of supported OS interface strings
227                acpi_osi="string1"    # add string1 -- only one string
228                acpi_osi="!string2"    # remove built-in string2
229                acpi_osi=        # disable all strings
I can't find any actual information when wich line should be used.
I consider this a myth, because it seems to be the holy grail of fixing problems on laptops and netbooks. It just moves the problems to other fields.

Julius2 · 2010-11-16 14:41:24

In my experience, outdated wiki pages tend to propagate this stuff, along with blog entries. The trouble with blog entries is that they're often fire-and-forget, which means that solutions that might have been necessary a while ago are now unsuitable or unnecessary.

Wiki pages have no such excuse, being more fluid than blogs posts. This is particularly prevalent on the Arch Wiki, as Arch is a distribution with a small number but a large variety of (mostly) technically-experienced users who will often go to great lengths to increase performance or to accomodate for Rube Goldberg machine-like hardware or network setups. Thus, there are a lot of hacks on obscure pages (not, say, the Beginner's Guide or the major pages).

What we need is a major overhaul and review of many of the shorter and more obscure wiki pages, such as any of the ones under Request:Correction and Request:Expansion. I've "rescued" a few pages from this purgatory, but many pages have sat there for months or years and I do not have the experience or knowledge to improve them. I think that we could gain a great deal from more community awareness about improving the wiki and trying to encourage people to edit more. Rather than the same editors working on more mainstream pages and ignoring or barely touching the more arcane ones, it might be preferable to have people with little editing experience but more technical experience to take a look at some of the pages, capitalizing on the cumulative knowledge of our userbase a bit more.

Just a thought.

Awebb · 2010-11-16 15:44:21

dptkby wrote:

Well, for me the truth is that without said kernel parameter adjusting the brightness of my screen doesn't work and with, it does. I gather it tells *some* part of your system to expect dealing with Linux (BIOS?), can't say I know exactly what it accomplishes.

In my case:

Without the line in Grub, my Fn keys didn't work. With the line in Grub, the cpu governors were broken. I fixed it by now (I'll write a wiki article in my vacation... soon). It's not the elixir of life, it's just a possible option.

Cdh · 2010-11-16 15:51:54

Well, for some eeePCs like mine acpi just doesn't work without. The eeepc-laptop module cannot load, thus wireless doesn't really work and all the special keys don't work. I don't believe it "solves everything" but it is necessary for my eee to run normally.

RiceKills · 2010-11-16 20:37:31

The belief that you need x86-64 to use more than 4gb of ram is sort of a myth, you can compile the 32bit kernel to use more than 4gb of ram, but most people don't do that.

ChoK · 2010-11-17 02:14:25

sysctl vm.swappiness=1 improves responsiveness is a myth.
Well actually if an app is cached to disk it will be brought back slower, but the kernel can use the free RAM do do things more efficiently, like transfering data, caching inodes/files and if you run out of RAM the heavy swapping will most certainly bring the system to its knees. This of course is mitigated if the system as plenty memory (8GB+).

Limiting writes cycle on SSD because they will die too fast is a myth http://www.storagesearch.com/ssdmyths-endurance.html

theapodan · 2010-11-17 04:01:46

RiceKills wrote:

The belief that you need x86-64 to use more than 4gb of ram is sort of a myth, you can compile the 32bit kernel to use more than 4gb of ram, but most people don't do that.

It might be a myth that that is a good way of dealing with the 4 GB limitation.

Physical Address Extension (PAE), while allowing use of more than 4 GB, has inferior performance in some benchmarks. This article describes benchmarks done (with something less than scientific rigor) to investigate this. However, they did not test these scenarios on a machine with more than 4 GB installed:
http://www.phoronix.com/scan.php?page=a … _pae&num=1

anonymous_user · 2010-11-17 05:37:08

ChoK wrote:

Limiting writes cycle on SSD because they will die too fast is a myth http://www.storagesearch.com/ssdmyths-endurance.html

So I can enable search indexing, use a journaling filesystem, use a disk cache (for example a web browser), etc and it won't really affect the life of an SSD? Woohoo!

rwd · 2010-11-17 07:30:59

[citation needed]

arinlares · 2010-11-17 09:22:45

ChoK wrote:

sysctl vm.swappiness=1 improves responsiveness is a myth.
Well actually if an app is cached to disk it will be brought back slower, but the kernel can use the free RAM do do things more efficiently, like transfering data, caching inodes/files and if you run out of RAM the heavy swapping will most certainly bring the system to its knees. This of course is mitigated if the system as plenty memory (8GB+).

I've actually seen this one in action, except I use vm.swappiness=10 (1 prevents swappage more than 10, but I don't see much difference). I've run sysctl vm.swappiness=10 in the middle of a sizeable file transfer, and seen my system improve drastically on several occasions. I had to run Ubuntu at vm.swappiness=10 because I would swap with Firefox and Youtube at vm.swappiness=60. My netbook only has one gigabyte of RAM, though, so somebody with 8GB would be able to do a lot more than I could before they started using swap (my record w/ vm.swappiness=60 was ~300MB before swap/slowdown).

Last edited by arinlares (2010-11-17 09:23:36)

el mariachi · 2010-11-24 14:34:48

how do you benchmark the swappiness in order to objectively compare different options?
I just finished an hour long trial and error with different kernel options in menu.lst and adding fastboot took 3seconds out of boot time (more or less irrelevant). All other options in the wiki like disabling ipv6 and quiet made no difference whatsoever. Myth too?

arinlares · 2010-11-24 22:48:54

el mariachi wrote:

how do you benchmark the swappiness in order to objectively compare different options?

Sorry, maybe I should've done that, but would a claim of a jump from three seconds to near instant program launch in XFCE suffice?

eldragon · 2010-11-24 23:16:44

arinlares wrote:

el mariachi wrote:
how do you benchmark the swappiness in order to objectively compare different options?
Sorry, maybe I should've done that, but would a claim of a jump from three seconds to near instant program launch in XFCE suffice?

no, i dont trust your objectiveness. the human brain is not a good clock

el mariachi · 2010-11-24 23:53:29

@arinlares: I wasn't challenging your opinion mate I was merely asking how did you benchmark, in order for me to do the same with my system and test different tweaks. I'm using it and it feels faster, sometimes... guess that's good enough for now

655321 · 2010-12-09 06:07:51

ChoK wrote:

sysctl vm.swappiness=1 improves responsiveness is a myth.
Well actually if an app is cached to disk it will be brought back slower, but the kernel can use the free RAM do do things more efficiently, like transfering data, caching inodes/files and if you run out of RAM the heavy swapping will most certainly bring the system to its knees. This of course is mitigated if the system as plenty memory (8GB+).
Limiting writes cycle on SSD because they will die too fast is a myth http://www.storagesearch.com/ssdmyths-endurance.html

GREAT article, cleared out a lot of things about SSDs

Now the only limitation its the price haha

Arch Linux

#1 2010-11-13 15:15:47

(Arch) Linux Myths

#2 2010-11-14 05:03:25

Re: (Arch) Linux Myths

#3 2010-11-14 05:28:10

Re: (Arch) Linux Myths

#4 2010-11-14 07:47:56

Re: (Arch) Linux Myths

#5 2010-11-14 08:23:30

Re: (Arch) Linux Myths

#6 2010-11-14 09:09:23

Re: (Arch) Linux Myths

#7 2010-11-14 11:22:17

Re: (Arch) Linux Myths

#8 2010-11-14 13:21:28

Re: (Arch) Linux Myths

#9 2010-11-15 18:33:50

Re: (Arch) Linux Myths

#10 2010-11-15 22:51:57

Re: (Arch) Linux Myths

#11 2010-11-15 23:08:55

Re: (Arch) Linux Myths

#12 2010-11-16 14:41:24

Re: (Arch) Linux Myths

#13 2010-11-16 15:44:21

Re: (Arch) Linux Myths

#14 2010-11-16 15:51:54

Re: (Arch) Linux Myths

#15 2010-11-16 20:37:31

Re: (Arch) Linux Myths

#16 2010-11-17 02:14:25

Re: (Arch) Linux Myths

#17 2010-11-17 04:01:46

Re: (Arch) Linux Myths

#18 2010-11-17 05:37:08

Re: (Arch) Linux Myths

#19 2010-11-17 07:30:59

Re: (Arch) Linux Myths

#20 2010-11-17 09:22:45

Re: (Arch) Linux Myths

#21 2010-11-24 14:34:48

Re: (Arch) Linux Myths

#22 2010-11-24 22:48:54

Re: (Arch) Linux Myths

#23 2010-11-24 23:16:44

Re: (Arch) Linux Myths

#24 2010-11-24 23:53:29

Re: (Arch) Linux Myths

#25 2010-12-09 06:07:51

Re: (Arch) Linux Myths

Board footer