What is Digg?Sponsored by Sony Pictures
Do you believe the 2012 Mayan Prophecy? view!
whowillsurvive2012.com - The Mayan Calendar predicts the end of time: 2012. See the trailer for 2012, opening November 13.
44 Comments
- AdonisEffect, on 10/12/2007, -0/+29I think 'hack' is used here in it's original geek context.
An innovative use of existing tech to create something more useful/fun/interesting - schestowitz, on 10/12/2007, -3/+26Follow the link even if you don't use Ubuntu Linux. There's almost nothing there -- if anything at all -- which is Ubuntu specific. GNOME, POSIX and GNU utilities...
- mjg59, on 10/12/2007, -0/+20This is bad. Really, astonishingly bad.
"Lowering the number of PIDs can improve performance on systems with slow CPUs or little RAM since it reduces the number of simultaneous tasks."
Unless you're having tasks fail to start because you're out of PIDs, this isn't going to make any appreciable difference. And the symptom of that is going to be programs refusing to start. Not really a great optimisation.
"A 32-bit PC architecture like the Intel Pentium i686 family can only access 4 GB of RAM. "
Except for the ones with PAE, though given the prevalence of 64-bit CPUs now this is still somewhat irrelevant.
"The kernel can only access 1 GB of RAM. Any remaining RAM is unused."
Wrong. The stock 32-bit Ubuntu kernel is built with support for 4GB.
"anacron—As mentioned earlier, this subsystem periodically runs processes. You may want to disable it and move any critical services to cron."
There's an important difference between cron and anacron - anacron will "catch up" on jobs that haven't been run because the machine has been switched off.
"atd and cron—By default, there are not at or cron jobs scheduled. If you do not need these services, then they can be disabled. Personally, I would always leave them enabled since they take relatively few resources."
The default install contains important cron jobs.
"apmd—This service handles power management and is intended for older systems that do not support the ACPI interface. It only monitors the battery. If you have a newer laptop (or are not using a laptop), then you probably do not need this service enabled."
Exits if you don't have apm available, so disabling it won't do much other than improve boot time by a really small amount.
"acpid—The acpid service monitors battery levels and special laptop buttons such as screen brightness, volume control, and wireless on/off. Although intended for laptops, it can also support some desktop computers that use special keys on the keyboard (for example, a www button to start the browser). If you are not using a laptop and do not have special buttons on your keyboard, then you probably do not need this service."
Except that by disabling it, you also won't have anything to load the various acpi support modules and so won't get temperature feedback via ACPI. Various systems depend on this being available in order to perform proper CPU throttling to deal with overheating. Only disable it if you know that you're not risking hardware damage by doing so.
"vbesave—rvices monitors the Video BIOS real-time configuration. This is an ACPI function and is usually used on laptops when switching between the laptop display and an external display. If your computer does not support APCI or does not switch between displays, then you do not need this service."
As far as I can tell, this has just been made up entirely. It certainly doesn't bear any resemblance to reality (hint: I wrote that code)
If this is actually representative of the content of the book, then stay well clear.
Matthew Garrett - Ubuntu kernel team - NnyDarko, on 10/12/2007, -2/+20Says a digg flamebaiter
- davidvasta, on 10/12/2007, -0/+15Hack as in Geek and in make better. Not the Hack that means bad and is used by the media.
- muszek, on 10/12/2007, -1/+15Very decent article, with one "but", though. It's not very fresh - was written around the Dapper era and a lot has changed since then Upstart replaced init in Edgy. So at least the "and speeding up boot time" part of TFA is outdated. Other than that, it's really good.
- sishgupta, on 10/12/2007, -1/+11The phenomenon is quite interesting.
I would assume mostly Ubuntu users on digg (of the linux users), and distro watch says it is the most popular by a lot. There are also a number of non-ubuntu users.
Normally it would be assumed that a Linux article applies to most Linux distros including ubuntu.
But, users digg articles with ubuntu in the title but not with Linux in the title.
An article with Linux in the title should grab the ubuntu users and the users of other distros...and an ubuntu article should only grab the ubuntu users.
But this isn't so, "ubuntu" articles get the most and "linux" articles get less.
Do "ubuntu" users not realize they are using Linux?
It doesn't seem likely.
IMO The most likely explanation is that most "linux" users already know the information in the article because they have been using linux for quite some time and don't see these rather basic articles as informative. Whereas I would guess that a large percentage of "Ubuntu" users on digg are new to linux and digg articles because they don't already know most of the information within them.
Then the problem would seem that new ubuntu users don't see themselves as linux users or capable of understanding a general linux tutorial, OR they think that ubuntu is so greatly different from the rest of the linux distros that a general linux tutorial wouldn't be of use. - sbrown123, on 10/12/2007, -0/+8Actually, its the reverse: Linux is all about tweaking. Linux users are much like those people who sit around tweaking a hot rod they built themselves from scratch. Windows people buy their cars from the car mart and the only modification they make is to hang something stupid from the mirror. Mac users also buy their car as is, but buy it for its exterior look and creature features.
- phr0ze, on 10/12/2007, -0/+6Did you even read the whole thing. See there is a little link in the lower right corner of the article. This brings up another page in the article. Try it out.
- clearzen, on 10/12/2007, -2/+8Nice article, I don't know why every article on digg about linux has to have ubuntu in the title though
- phr0ze, on 10/12/2007, -0/+5Every system needs to be tuned. Linux never claimed to not need tuning. But with linux you can tune it to an extreme which other systems will not let you do.
- jdawg19, on 10/12/2007, -0/+3it grabs attention whether good or bad.
- johlin, on 10/12/2007, -0/+3So...if most of the things aren't Ubuntu specific, why did you write Hacking Ubuntu and not Hacking Linux?
- KielKilla, on 10/12/2007, -0/+3Actually most people probably dual or even triple boot with windows.
- javascriptdude, on 10/12/2007, -0/+3heres the whole article, on only one page!
http://www.extremetech.com/print_article2/0,1217,a=205347,00.asp - dhonn, on 10/12/2007, -0/+2I seen lots of inaccuracies. It looks like the author needs to do more research. Plus the author refers back to pretty old documentation for references.
- ptFoe, on 10/12/2007, -1/+3Has digg ever publicised how many of its users use Linux or more precisely Ubuntu. I think there are many wannabe Linux users.
- Apreche, on 10/12/2007, -1/+3There is no reason to "hack" Ubuntu for performance. If there were some magic way to make Ubuntu faster without making a trade-off for stability, compatability, features, or something else, then the Ubuntu developers would do it. Trust me, the people developing Ubuntu aren't stupid. It's not like they accidentally set some configuration to make the OS slower for no reason. Everything is done for a reason. People are looking at all the code and all the packages all the time. If someone noticed a magic way to make something faster, they would change it, and you would get it via an update.
If you try to use these hacks you will most likely end up breaking your system in one way or another. From giving out help on forums and other places I can tell you that the #1 cause of problems among amateur Linux users is when they try to fool around with things they don't understand because some howto told them it was a good idea. If it isn't broken, don't fix it. You're only asking for trouble.
If you can't afford new hardware, and you need to run Linux and get better performance than Ubuntu offers, then use Gentoo. - KielKilla, on 10/12/2007, -1/+2You won't like me when I'm MAD!
but srsly bad idea... your about to be dugg so far down... - NealKrawetz, on 10/12/2007, -0/+1stevemax,
Just for clarity: this issue you are describing in your latest posting is with a sidebar on page 206, and not my actual description of cron/anacron. Sidebars appear in the book as a gray text box, and are used to relate the general content of the chapter to a specific, realistic scenario. This gives readers an idea for how to apply the content.
NOTE: You might look in /etc/cron* first, but other people might look in /etc/init.d/, /var/spool/cron/*, or at the other running processes (in case of a spawn).
In this sidebar, I mentioned not knowing what was starting the "updatedb" process and that I eventually tracked it down to anacron. This entire sidebar, titled "Time to Change", discusses some of the differences between Ubuntu and other distributions. The two examples that I give are "updatedb" and the automatic time configuration in /etc/network/if-up.d/. This sidebar sets the basis for the chapter: how do you tune the system, including determining where things are hiding.
If you are a hard-core Ubuntu guru, then this may seem like an unnecessary waste of time. Then again, if you are a hard-core Ubuntu guru, then you probably don't need any book on Ubuntu or even Linux. However, if you know Linux but not Ubuntu, or are an Ubuntu user but not a low-level system guru, then the situations in the sidebar should sound familiar, or you have likely had a similar experience with some other subsystems.
How "at", "cron", and "anacron" work is detailed later in the chapter, on pages 224-225. I cover all three because all three are installed by default and used by different applications. Why are they discussed so late in the chapter? I decided to order the chapter from top-down -- from the UI to the kernel. This means, first viewing running processes, then measuring performance, inspecting scripts, and finally low-level system tuning. You can see this organization in the table of contents.
Anacron and cron are also mentioned in other chapters, where I provide hacks for running different scripts. These appear in chapters 3, 6, 10, and 11. - mjg59, on 10/12/2007, -0/+1max_threads = mempages / (8 * THREAD_SIZE / PAGE_SIZE);
mempages = physical ram / PAGE_SIZE
Therefore:
max_threads = physical ram / (8 * THREAD_SIZE)
Therefore:
"Similarly, a system with a smaller page size (usually found with older/slower processors) will have a lower default value."
clearly, unambiguously, astonishingly and entirely wrong. PAGE_SIZE has nothing whatsoever to do with it. - Spr0k3t, on 10/12/2007, -0/+1Listen to Matt, he knows his *****
- GMorgan, on 10/12/2007, -0/+1The fact that Linux can be tweaked doesn't necessarily mean it needs to be either. It's just as standard it will compete well with the opposition and when tweaked it blows them away.
- dansus, on 10/12/2007, -0/+1Ive been looking at linux for a few years now, but every time get into it, many of the guides turn out to be full of rubbish and there doesnt seem to be a unfied, centralized way of doing things. eg: Ive seen at least 5 different guides to installing ATI drivers, all different and none of em work.
Nothings changed then.
Saying that, i think its time with fiesty. (and an Nvidia card) - jcmia1, on 02/07/2009, -0/+1Pretty generic methodology. Well written. Tuning operating systems, application servers, databases and your application code takes time and focus. Start by monitoring them under load. I found this article useful because it gives the actual commands and screen shots on how to do this:
http://www.performancewiki.com/app-performance-mon ... - mjg59, on 10/12/2007, -0/+1"If you are running a low-resource or slow system, then more running processes
will consume more RAM and more CPU time. This will result in a slower
system. One option is to lower the number of PIDs. This will reduce
the number of running processes."
There are two possible outcomes of lowering the maximum PID number.
1) You're running fewer processes than that already. Lowering the maximum PID number will result in nothing happening.
2) The application you've just tried to run would take the number of running processes over the new maximum. As a result, the application will not be started. Sure, you're saving resources, but your computer no longer does anything useful.
Basically, there's no point in ever doing this on a desktop system. Ever. The only way it can improve your performance is by making your computer less useful, and if you want to do that then, well, just run DOS - you'll have far more RAM available for other applications.
Pretty much everything else you've said is about equally wrong. I could forgive you for being misguided to begin with, but the fact that you're trying to argue your way out by producing even more ridiculously inaccurate ***** is absolutely insane. Please, stop. - mjg59, on 10/12/2007, -0/+1This should, obviously, have been a reply to Neal's reply to my original comment. It seems that understanding something about the kernel doesn't qualify me to use a website properly...
- NealKrawetz, on 10/12/2007, -0/+1stevemax,
You are mistaken: updatedb is started by anacron, not cron.
You can see that it is started by anacron in the file /etc/cron.daily/slocate.
By default, /etc/cron.daily/ is processed once a day, starting 5 minutes after the machine boots.
However, you can easily move it to cron without seriously impacting functionality.
muszek:
I decided to focus on Dapper rather than Edgy or Feisty for some simple reasons:
1. Edge was not released when I started writing the book. At the time, other books came out discussing the soon-to-be-released Edge and they turned out having some serious mistakes because things changed between the time they wrote the book and when it was released. I didn't even begin to discuss Feisty since the book was nearly complete before they even gave it a name.
2. Dapper is the LTS version. Dapper will still have support long after Edge is obsolete.
However, there are some parts of the book that mention differences between Dapper and Edgy. (Most notably: init has been replaced in Edgy, so the init hacks won't work in Edgy.)
schestowitz:
Remember: Ubuntu is not an operating system. Ubuntu is a distribution. Similarly, RedHat and Suse are not operating systems, they are alternate distributions. In each of the cases, the operating system is "Linux". The distribution determines what gets installed by default, how it is configured, the type of support, where you can get additional ready-to-go binary packages, and some custom scripts used by the operating system. The default Gnome that ships with RedHat has a different default configuration than the default Gnome under Ubuntu -- even though the binaries come from the same source.
This book starts with a basic Ubuntu installation -- and that includes Gnome -- and shows you how to tweak and tune the entire system for speed, security, usability, etc. - immrlizard, on 10/12/2007, -0/+1I never felt the need to hack it for performance. It runs faster then windows on the same machine, so I was happy. I like to avoid potential problems where I can.
@ dansus
I hear and feel your pain. I am a sufferer of the ATI syndrome myself. If you haven't bought your video card yet, do a little searching on the forums to see which Nvidia cards are the least trouble. Not all Nvidia cards work well with linux. According to some forums there are a number that won't run beryl well yet.
I did manage to get my ATI X850 XT working in feisty and it works well. Not everyone has had the same results on every card. Good luck and hit those forums. It will give you the best idea of which card to get - NealKrawetz, on 10/12/2007, -0/+1stevemax:
You are still incorrect.
Anacron is not the same as cron.
They are two different time scheduling systems.
Anacron's configuration (/etc/anacrontab) says to run everything in the /etc/cron.* scripts. Even though the directories are named "cron.daily", "cron.weekly", and "cron.monthly", they are not cron; they are anacron.
In contrast, cron stores its configuration files in /var/spool/cron/crontabs/.
In fact, from the Anacron man page:
DESCRIPTION
Anacron can be used to execute commands periodically, with a frequency
specified in days. Unlike cron(8), it does not assume that the machine
is running continuously. Hence, it can be used on machines that aren’t
running 24 hours a day, to control daily, weekly, and monthly jobs that
are usually controlled by cron.
I'm curious, if you think that "/usr/sbin/anacron" is the same as "/usr/sbin/cron", do you also think that "/usr/bin/at" is the same as cron since it too is a time scheduling system? - clievers, on 10/10/2007, -0/+1Wow, this above is an exciting read. When/where is the brawl taking place?
- SteveMax, on 10/12/2007, -2/+2This guy had to search around to discover that updatedb was a cron job (besides the clear errors pointed out by mjg59 below). I'd recommend people to stay well clear from this content, as the author obviously doesn't know what he's talking about.
- puneypunk, on 10/12/2007, -3/+3I thought he was extremely witty, thumbs up 34tnu5x199
- SteveMax, on 10/12/2007, -1/+1"/etc/cron.daily/slocate"
/etc/cron* is the standard location for cron jobs. Anacron is a (slightly modified) cron daemon. updatedb is always ran by whatever cron daemon your distro chose to install. Every *nix person would know that.
Sorry, but if you couldn't see this, than you're not in position to write a book on *nix. - SteveMax, on 10/12/2007, -1/+1anacron is "A" cron daemon, it runs the same scripts as any other cron daemon would if the distro had chosen to install them (dcron, fcron, vixie-cron, etc).
The point is: if updatedb is being ran, the first place you would look would be /etc/cron*. It's imprinted in the minds of anyone who has ever worked in a *nix system. The fact that you took some effort to find it there says a lot about your expertise, which leads to a sound conclusion about your ability to offer advice. - SteveMax, on 10/12/2007, -1/+1I don't use Ubuntu. I use Linux since 1998. In any event, cron jobs are defined by the crontab, which will point out where are the actual jobs being ran. init.d jobs will run at startup, and no distro would be stupid enough to run updatedb at every startup (the user would feel the performance loss); /var includes only runtime events, it shouldn't contain any configuration files.
I read the linked article, not your book. I won't read your book, and won't recommend anyone to, because of all the errors mentioned. Any Linux user with enough experience to give some advice on system startup and job scheduling would never spend more than one minute to find a call to updatedb. Below, you pointed to a kerneltrap article that says the exact opposite of your point, showing that you didn't even bother to read it. And of course, besides not being qualified enough to advise anyone, you are being an ass. - NealKrawetz, on 10/12/2007, -1/+0It appears that something I mentioned in Chapter 7 of Hacking Ubuntu has become controversial (I've received a few comments on it). In this chapter, I discuss many different steps for improving Ubuntu Linux's performance, including kernel tuning. One of my suggestions was to change the maximum number of running processes. This suggestion has generated some controversy since "nobody would ever want to do this", right? And some people have argued that changing the maximum number of concurrent threads won't improve performance.
Ubuntu's Dapper Drake (covered in the book) uses the Linux 2.6 kernel. You can download the source code from www.kernel.org. In linux-2.6.20/kernel/fork.c, the function fork_init() defines the default value for the maximum number of concurrent processes. It even includes a comment about performance:
/*
* The default maximum number of threads is set to a safe
* value: the thread structures can take up at most half
* of memory.
*/
max_threads = mempages / (8 * THREAD_SIZE / PAGE_SIZE);
The THREAD_SIZE and PAGE_SIZE are dependent on the architecture. The THREAD_SIZE is fairly constant -- most platforms use 8192 bytes. However, PAGE_SIZE varies dramatically among platforms, from as small as 256 bytes to over 8 KB. A general rule of thumb: the faster the processor, the larger the page size. (This correlation is due to faster architectures and not CPU speed.)
What does this means?
* The default value is dependent on the amount of memory your system has, and the hardware platform.
* By default, a computer with less memory will allow fewer concurrent processes. Similarly, a system with a smaller page size (usually found with older/slower processors) will have a lower default value.
* If you need to allocate more threads, uses sysctl to change the threads-max kernel parameter. (How to do this is covered in Chapter 7). For example, if you are running a program that spawns many subprocesses, but you only have a few available threads, then you can increase this value.
* If you have memory-intensive applications with few concurrent processes, then you might want to lower the maximum number of threads so the memory can be used by other processes.
* If you need to have two identical installations for testing before deploying code (e.g., mission critical environments), then be sure to make sure the maximum number of threads is set to the same value. If they are not (e.g., same software configuration, but on different hardware configurations), then consider setting it manually.
Granted, the average user probably won't want or need to tweak this option. However, the ExtremeTech series is not about average users. It's about power users; people who want to squeeze the most out of their systems. (This is the "Extreme" in ExtremeTech.)
Hopefully this addresses any concerns. - NealKrawetz, on 10/12/2007, -1/+0Matthew,
I think we will have to agree to disagree here.
If the kernel developers believed the way you believe, then they would make the maximum number of PIDs the same value for all platforms. Instead, they made the maximum number of PIDs vary based on the available resources. While I agree that changing this value may not lead to a noticeable performance difference on desktop systems, this option for tweaking the kernel can be beneficial on low-resource and mission critical servers. Remember: Ubuntu is not just for laptops.
I do find it curious that you left the Debian for Ubuntu after claims that there was too many trolls within the Debian forums. Yet, you seem to be doing that here. For someone who claims to hold the Ubuntu Code of Conduct in high standings (http://www.ubuntu.com/community/conduct), you seem to be completely ignoring "Be considerate", "Be respectful", and "When you disagree, consult others". I consulted many people when I wrote this book, including people who work directly on the Ubuntu distribution.
I sincerely tried to make this book as complete and accurate as possible. I made sure that the book was reviewed by people involved in Linux, Ubuntu, and open source. While there are a few errors that made it past quality control, I have never seen a technical book that had no errors. (Ok, books in their 4th edition are usually close to perfect.) For you to claim that this book is "really, astonishingly bad" over items where we disagree or one inaccurate statement in one chapter is like saying "Ubuntu is a horrible operating system because vbesave crashes on some configurations". Your vbesave does crash on some configurations, that does not mean people should ignore the entire distribution. Similarly, I believe that this book's first edition may have a few errors, but it is not "astonishingly bad". Your comments seem to be more like the trolls that you complained about. - NealKrawetz, on 10/12/2007, -3/+1Hi Matthew,
I'd like to address some of your concerns.
1. "Lowering the number of PIDs can improve performance on systems"
You said, "Unless you're having tasks fail to start because you're out of PIDs, this isn't going to make any appreciable difference."
The point that I was making is that running processes consume resources.
This is not the number of PIDs -- the PID table is relatively tiny.
This is the number of actual active processes.
If you are running a low-resource or slow system, then more running processes
will consume more RAM and more CPU time. This will result in a slower
system. One option is to lower the number of PIDs. This will reduce
the number of running processes. Fewer running processes reduces the
number CPU and RAM requirements. However, if done incorrectly then you
could end up unable to spawn critical processes.
2. "A 32-bit PC architecture like the Intel Pentium i686 family can only access 4 GB of RAM."
You wrote: "the prevalence of 64-bit CPUs now this is still somewhat irrelevant."
It really depends on your environment. While I agree with you in regards to
home systems, this is not necessarily the case in corporate environments.
I know many environments that are predominantly 64-bit architectures. (And
they run Ubuntu.) This book is not just for home users.
While the i686 in particular can access up to 16 GB in some situations,
it really depends on the chipset, and PCI adapters have trouble mapping
into larger memory areas. So far, I have not come across any pentium
computer (CPU+motherboard chipset) that can access more than 4 GB of RAM.
3. "The kernel can only access 1 GB of RAM. Any remaining RAM is unused."
You replied: "The stock 32-bit Ubuntu kernel is built with support for 4GB."
I mention that the kernel cannot access 4GB of RAM.
This is similar to the information specified in:
http://kerneltrap.org/node/2450
In particular, physical memory used by the 2.6 kernel is limited to 1 GB.
Virtual memory is limited to 4 GB. Virtual memory is not just RAM -- it
also includes swap space.
4. "anacron -- As mentioned earlier, this subsystem periodically runs processes. You may want to disable it and move any critical services to cron."
You wrote: "anacron will "catch up" on jobs that haven't been run because the machine has been switched off."
Yes and no. It will try to catch up in a limited situation.
If the scheduled job has a specific date for running, then it will be
started if the computer was off when the date happened.
However, if the computer has been turned off for 2 hours and a job is
supposed to run every 15 minutes, then it won't run the job 8 times.
In addition, all of the jobs found in the default anacron configuration
work just as well under cron. The "catch up" functionality is not
essential nor used in the default configuration.
5. "atd and cron - By default, there are not at or cron jobs scheduled. If you do not need these services, then they can be disabled. Personally, I would always leave them enabled since they take relatively few resources."
You wrote: "The default install contains important cron jobs."
I just checked the default Dapper install for Mac and i386.
I do not see any cron jobs scheduled.
Can you elaborate on which cron jobs are scheduled by default?
6. "apmd -- This service handles power management and is intended for older systems that do not support the ACPI interface. It only monitors the battery. If you have a newer laptop (or are not using a laptop), then you probably do not need this service enabled."
You wrote: "Exits if you don't have apm available, so disabling it won't do much."
I do not see the issue.
I am saying "if you don't need it, then disable it". You are saying
"if it is not needed, then it will exit". My contention: why even start
it if you don't need it?
Chapter 7 focuses on speed. Disabling it is faster than having it start
and exit.
7. "acpid -- The acpid service monitors battery levels and special laptop buttons such as screen brightness, volume control, and wireless on/off. Although intended for laptops, it can also support some desktop computers that use special keys on the keyboard (for example, a www button to start the browser). If you are not using a laptop and do not have special buttons on your keyboard, then you probably do not need this service."
You wrote: "Except that by disabling it, you also won't have anything to load the various acpi support modules and so won't get temperature feedback via ACPI. Various systems depend on this being available in order to perform proper CPU throttling to deal with overheating. Only disable it if you know that you're not risking hardware damage by doing so."
Again, I don't see where I am wrong. If you don't need it, then why even
have it running? With it running, system resources are consumed.
I don't mention monitoring the temperature on the CPU at all. I have
found very few computers that support temperature/speed control on the
CPU via the ACPI interface. In most cases that I have found, this is
controlled by the BIOS.
8. "vbesave -- This services monitors the Video BIOS real-time configuration. This is an ACPI function and is usually used on laptops when switching between the laptop display and an external display. If your computer does not support APCI or does not switch between displays, then you do not need this service."
You wrote: "As far as I can tell, this has just been made up entirely. It certainly doesn't bear any resemblance to reality (hint: I wrote that code)"
I initially got the description from your man page for vbetool. In the
man page, you wrote:
"vbetool - run real-mode video BIOS code to alter hardware state" and
it contains many functions for querying and changing video modes.
When I was researching how people use vbesave, nearly every posting
reported using it on a laptop. In particular, they reported problems with
it hanging during suspend or changing displays. Some examples:
https://translations.launchpad.net/ubuntu/+source/vbetool/+bugs
https://launchpad.net/ubuntu/+source/acpi-support/+bug/42368
https://bugs.launchpad.net/bugs/38500
http://ubuntuforums.org/archive/index.php/t-14096.html
In most of these examples, you responded you the issues. I really liked
your advice:
"run '/etc/init.d/vbesave start', and see if that hangs the machine."
However, you are correct in that it plays a large role in video suspend
and not changing internal/external displays.
If vbesave has a use on systems other than laptops, please let me know.
What I noticed: disabling it on a desktop system does not seem to have
any harmful effect. However, this could be due to the systems that I
was testing on. - inactive, on 10/12/2007, -7/+2i thought linux was all about not having to do something like this.
- inactive, on 10/12/2007, -11/+5Maked as lame, its just a link to some ***** that tries to sell you a book, i saw no helpful tips. try www.ubuntuforums.org
- EerFoolWVU, on 10/12/2007, -14/+4VT professor sacrifices his life to save students...let the digg nation know about his hero
http://digg.com/world_news/I_don_t_think_my_teacher_got_out_VT_prof_sacrfices_life_to_save_students - g4blows, on 10/12/2007, -32/+2I didn't know you could "hack" open source.
- inactive, on 10/12/2007, -60/+3Linux is for losers and virgins.
© Digg Inc. 2009
— Content created and posted by Digg users is