There are a few spots of the kernel that do use hand crafted SSE assembly (a quick glance says RAID calculation is one area (also here) and a particular crypto routine is another) but it is quite rare. Up until SSE4, SSE was really targeted at multimedia applications that contained a lot of floating point arithmetic. Generally floating point is avoided within the kernel so the maintenance pain of crafting an SSE optimised routine along with generic C version would not be worth it. Seemingly when you go to write assembly these days you have to account for the following:
Are you smarter than your compiler?
Will you still be smarter than it in a year's time?
Is it worth the time (both the initial and the maintenance time) to write the routine twice (in assembly and in generic C)?
Will your assembly still be faster when new processors with different properties come out?
Also don't conclude that just because the kernel doesn't contain many handcrafted SSE routines that no SSE instructions will ever be emitted by the compiler (assuming you've told it that you have a CPU that can cope with them). I believe very new versions of GCC (4.3 and above) have the just gained the ability to emit SSE4 instructions.
It is unlikely that you will see the kernel adopting anything that makes the build process much more complicated. Operating system glue layers (e.g. abstractions in code for drivers that are supposed to run on other platforms) are already already frowned upon in drivers. Any new dependencies on tools like autoconf or cmake would most likely be rejected with a "what are we gaining?" complaint. My understanding is that patches that convert gccisms to their C99 equivalents are generally accepted but people are not willing to maintain glue for other compilers because it makes the default case painful. That's their choice - there are always other OSes like NetBSD that can be "compiler portable".
When it comes to reads you can't really postpone them - if someone wants to play that music file now and you don't have it already in cache (and Linux already uses unused memory as cache) then you have to hit the disk.
When it comes to writes you you can often delay them so long as no one is waiting on you telling them that you have written the data to the disk (in which case you have to no choice but to hit the disk). This is already tunable via/proc/sys/vm/dirty_writeback_centisecs . Further there are things like/proc/sys/vm/laptop_mode that will try and batch writes when other I/O was going to happen (e.g. when you play that music file all the writes can happen too). Of course, in the event of a crash you lose much more data (as it wasn't on the disk) and you create more disk contention. See the Lesswatts disk tips page for more details.
While the top quality stuff might last, my own personal experience with el cheapo SSDs is that they go bad quickly with moderate (in my case laptop) use due to shabby wear levelling. Others are also warning about (cheap) SSDs throwing away data too. Such SSDs are often the ones you are going to encounter so while the majority of SSDs out there show this behaviour I think it's a warning worth mentioning...
First up your point about the sheer proliferation of different ways of playing sound on Linux and lack of docs is a strong one but things have been slowly improving over the years. The author of Pulseaudio has written a good guide as to what to use. The list of APIs is still bigger than 3 but in most cases it becomes clearer on what to target.
ALSA comes in (yeah I can hear the groans) two forms. A small "virtualisable" subset referred to as safe ALSA and full ALSA.
OSS is usually considered legacy. There most certainly is OSS4 (which is not) but that does not have the traction on Linux and most people only have an OSS3 -> ALSA layer so its dangerous for new apps to target it.
NAS is not that popular. I only come across it in Linux audio conversations like this. I don't think anyone feels they have to target it.
ESD is obsolete but was VERY popular. New apps should not be targeting it now though.
Pulseaudio. Interesting but has suffered due to partial implementations in some popular distros that users felt caused more problems than they fixed. For regular users I do think it is key for Pulseaudio to work past its problems though - it offers a lot of promise and is probably Linux's best chance to date of offering certain features. New apps can target it directly (for best support) or just use safe ALSA.
SDL (for sound). Interesting if you are writing games but in most other cases you would use something else. Its presence has never been a problem as it quickly became clear it was for games.
JACK. This is for professional musicians. If you have to target this then you are going after a high-end sound market. Most sound playing apps are not in this case.
KDE 4's Phonon. If you are only targeting KDE4 then I guess you should be using this.
gstreamer. If you are interested in codecs (e.g. playing vorbis music files or theora video) rather than decoding/encoding files yourself you should probably be using this.
For games use SDL. If you are only targeting KDE4 use the KDE4 stuff. For codec support use gstreamer. OSS and ESD should no longer be targeted in first tier Linux audio support. Pulseaudio will probably become more popular (so you can consider targeting it directly) but safe ALSA will probably have the broadest user base for a while.
It's hard to say that UTF-8 always doesn't work well on Linux. I'm using a Latin alphabet and it's been years since I had UTF-8 problems. However that's not your case...
I don't like the direction this is heading in (i.e. guaranteed broken) - bah (this always happens)! You didn't say what type of printer you have though. I'm also worried that you are getting duff results from Windows too.
Some part of me is thinking that if the printer is a laser postscript thing then the font it has does not have an extended character set. On Windows you might be able to fudge this by saying something like "Send as Bitmaps" (this has drawbacks though). What should ideally be happening is that the font should be being uploaded to the printer so it knows how to print the letter "natively" as it were.
On Windows (yeah I know I keep mentioning but I've seen these things in passing) make sure you have the right fonts for the right country. I'm vaguely aware there are Asian languages packs for Acrobat that ships with different fonts. This might let you verify a PDF produced on one system is correct even if it is mangled when sent to the printer.
Does this happen for all non-latin alphabets you try and print or only ones that are using an UTF-8 encoding? Does printing Chinese UTF-8 websites also break? If you open the text files in a browser and print do you have the same issue?
vi and friends have heuristics for trying to guess the encoding of a file. UTF-8 patches went in a few years ago. Assuming your terminal font has the characters it should display most characters.
The information in UTF-8 and Unicode FAQ for Unix/Linux under the printing says CUPS should be able to correctly convert a UTF8 text file to postscript so I would be interested in seeing some sample files...
Could you put up some short example documents on the web and link to them so I can try them?
I don't quite understand the question (although from your message I fear the problem is real). I am sad that it is broken on Linux - it's probably fine on OSX but here in Linux land there are plenty of unfortunate issues to go around. Sometimes those issues get fixed in the end though.
I have a few questions of my own: Where is the text coming from? What format is the text in if it is coming from a file (plain, doc, tex etc)? What program are you trying to print it from? Are you using lpr on the command line or some other means? When you say print do you mean to a printer or do you mean to a PDF? If it's the first does printing it into a PDF and printing that produce a better result? If it is a printer, do you know what type of printer it is (e.g. is it a postscript printer)? Do you know how the text is being sent to the printer (I'm struggling to come up with better wording but is it really going as text or is something turning it into a postscript/preprocessed file first?) Can you post a link to a web URI that has some sample text that shows the problem?
Being able to reproduce this problem myself would allow me to understand your issue. This is all offtopic for this post unfortunately and I have no idea how you will be able to follow up on this... Whatever happens, good luck!
Some people really do have x86 servers that aren't Windows... Being able to build a DOS "disk" for flashing purposes on such "1%" machines (because it's not feasible to put Windows on) is extremely important in such scenarios and doesn't seem unreasonable.
There really is a not-insignificant chunk of other stuff out there.
The POST a typical non-server grade system does some very weak memory tests. In all the cases I've seen of bad RAM in the past few years the POST never said anything. Skipping the memory check would be no big loss.
If you suspect your memory really is bad, run a proper memory checker. They catch far more memory faults than the POST does,
Experience has taught me that many UK University and school firewalls will arbitrarily block all sorts of outgoing packets (I have recently witnessed ICMP echo packets being thrown away by such firewalls). I have experience of outgoing encapsulated ip being blocked up by such firewalls rendering tunnel brokers useless.
I suspect external ipv6 won't arrive at most UK academic institutions until the institution's network folks decide to do it directly (there are some places where this is already the case).
Experience says that Samba usually is the "easiest" way (especially if some smidgen of security beyond IP address is needed). Don't forget if Samba notices another Samba system at the other end it enables some extensions. The alternative is going down the NFS v4 massive configuration route.
If you don't care about speed and are in Linux (or OSX... kinda) only environment and you mean ad-hoc (rather than log in) shares, sshfs is pretty easy to get going with recent distros. However, the moment you also need to share to Windows it's better to do the Samba dance.
Your boot is going to have to be sequential until you have decompressed ALL the data though. At only 50Mbytes your CPU is probably going to be stalled longer doing the decompression than waiting for 100Mbytes off your storage medium in our mythical one second boot (unless single CPU speeds get incredibly fast). You also can't make use of execute in place.
Using compression in the fashion you are suggesting is only a win if you are avoiding the slowness of reading in the data (e.g. by avoiding disk seeks due to having less data). As it stands you are probably going to cycle the RAM caches with all that decompression too...
This post is TOTALLY offtopic. Really you need to split these up and file them as bug reports over on launchpad. I'll post a couple of comments answers but I'm not going to follow up on any of this (even if you answer any questions I ask).
- switching from dual display to presentation (clone) and back totally messes up x config, I have to uninstall and reinstall nvidea drivers
Talk to NVIDIA (Linux web forum) about this. It's their code you're running and they are probably the only ones who are willing to fix it.
- in dual screen mode, nautilus opens on the first display. I have to open terminal and run nautilus& to lunch it on the second display
You can't drag it? I don't quite understand...
- in dual screen mode, keyboard keeps focus in the previous screen. I have to minimize/maximize a windows on the "new" screen to move keyboard focus
Are you using desktop effects? (Do windows fade and slide etc?) If so this sounds like a bug in compiz...
- RDP client crashes X windows in some cases (it does not close the drop down list of used servers... and bang)
Hmm. I'm really curious now as to whether you are using compiz. Regardless your best bet with this one would be to be to see if you can capture a backtrace of the crash with debug symbols and to file a bug report against the RDP client (I'm guessing you're using tsclient) in launchpad.
- oh and NO it's not AN ERROR if I close the RDP window. If I want to reconnect, I will, don't hide under my active windows and bring RDP windows back in 30 seconds. That's just plain stupid.
I guess file an enhancement request on tsclient in launchpad.
- java and window decorations don't play well together (popups without buttons etc.)
- How about opening a connection to a new server in a new tab, not in a new nautilus window?
Hmm probably best to file an enhancement request over on the GNOME bugzilla.
- Flash stops working. I just see a gray square where flash is supposed to be.
64 bit Firefox using 32 bit Flash via nspluginwrapper I'm guessing. There is a 64bit Linux Flash plugin that is in very early beta that MAY work better for you (I've heard mixed things mind). Also make sure you're using Flash 10 whatever route you are taking.
- Windows would become gray and unresponsive when there's a lot of disk activity.
You're using compiz aren't you? The greying is compiz telling you that the window HAS become unresponsive! As to why this is happening on I/O it probably varies from program to program. Too little information to many possibilities to say more.
- I've seen ubuntu crash on my much more times than I've seen BSOD on the same HW.
Quite possible. I've seen Linux stable on some computers and fla
I bet that making the kernel more asynchronous than it already is (with the current async patches) won't save any more significant amounts of time on this particular setup though! : )
It's absolutely true that Linux has a terrible time suspending to RAM (or coming back from suspend) on certain hardware. It has DEFINITELY been improving over the past two years though (one of my systems was fixed around 9 months ago).
First up make sure you are using the latest kernel you can (new fixes for suspend issues seem to have gone into each of the past few kernel releases including the very latest one). If you have the time you might be able to use the OpenSUSE instructions on debugging suspend to RAM to isolate where the fault lies.
Assuming the problem is more than monitor being off (i.e. the system is completely hanging without any binary only drivers being loaded) if you know how to run the very latest kernels (a prerelease 2.6.29) could you file a bug report over on Kernel Bugzilla after you've checked out the Linux kernel suspend debugging howto?
I admit I haven't checked this recently but isn't DSL using squashfs which is a compressed filesystem? If so that 50Mbytes is going to have to be uncompressed and that's going to take up precious time in that one second boot...
You know how everyone wanted a Linux-based operating system that "just worked" on a wide variety of hardware with drivers for everything? And didn't throw a shit-fit if you moved the hard disk to a completely different machine and tried to boot it up?
Driver probing isn't really why it's slow. Even without Arjan van de Van's fastboot kernel work probing for hardware* and loading drivers is not usually not what takes the most time during boot.
Typically boot time is dominated by the time it takes to actually read data from the disk (so disk seek time is a factor - especially if you aren't using readahead). Secondary to that is the time to start services. Assuming you are booting something graphical desktop environments (GNOME/KDE) take a bit of time to start too followed by X itself (this might be fixed now if you have kernel mode setting).
The above is excluding the BIOS boot time by the way - those can vary dramatically too. I've seen some servers that take many times longer to boot from cold past the BIOS than a typical desktop system takes to finish booting from poweroff all the way to a started Firefox.
* So long as we aren't talking about servers which may have large numbers of spun down disks or a big SCSI bus that takes time to enumerate etc.
Bootbooster caches various bits of the BIOS probing to the disk and allows the Eee to finish the BIOS phase faster than normal (providing you are booting off the internal SSD). The link is slightly inaccurate in so much as it doesn't speed up grub but instead cuts the time it takes to get to grub.
And for those kind words I'm going to post a follow up to my original post of more relevant changes between the 2.4 and latest 2.6 kernels (I'll try and add a few more words after each point).
Kernel configuration was overhauled. Outside support for more GUI menus, it now means you no longer have to do make dep after changing something. Further building modules outside the kernel tree is now not so baroque. The time to build and partially rebuild kernels also dropped. Building a kernel in parallel (i.e. using more than one CPU during the build process) works better.
I mentioned that 2.6 scales better under load in my previous post. Here are some benchmark comparison graphs of 2.4 versus 2.6 kernels (the graphs also include comparisons against the BSDs but you can see that Linux 2.4 had some serious problems that Linux 2.6 addressed).
The kernel is now (on systems where there is reliable device discovery) able to automatically load the modules it needs to drive hardware. No more having to adjust static lists of which modules need to be loaded.
udev was introduced. This change meant that the entries in/dev were no longer static. In 2.4 all possible device entries (even for devices you didn't have) were shown in/dev and their major/minor numbers were fixed (which was causing problems as new devices were turning up - what major/minor number do you give them?). Additionally the other dynamic/dev system (devfs) was whittled away and killed off.
FUSE support (LWN article about FUSE). Allows filesystem drivers to be written in userspace. Currently the best Linux NTFS driver is written using FUSE and it allows fun things like sshfs. Might be handy if you need users to be able to configure where data is stored remotely, you are writing your own filesystem or you need to support writing to NTFS formatted USB disks...
There is better CFS (Samba/SMB/Windows File Sharing) support. NFS version 4 support was also added.
cpufreq support. The kernel can clock down the CPU speed (usually by changing voltages via some hardware interface) to save large amounts of power. This can be done in response to work load so you run at full speed as often as possible and then when things are quiet you scale down to the lowest setting (you often save the most power when doing absolutely nothing so it pays to finish things as quickly as possible).
Any switch from 2.4 to 2.6 will of course require userspace changes (updated modutils, udev, later gcc, later glibc).
Many many other things have changed too (e.g. ALSA support for sound has been added) but I have tried to keep the ones mentioned at least tangentially related to the original scenario:)
I'm a bit younger than you (think decades) and I see other folks approaching your age picking up their (older) kids as though they are as light as a feather. When said kids ask ME to pick them up it just doesn't happen - I don't have that kind of weightlifting ability.
My current guess is that parents develop limbs of steel and muscles with infinite torque. It is only a matter of time before you too develop this miraculous ability to be able to lift cars and children with a single arm...
Poor videogame choice strikes again. If the kid had been given appropriate games where the key focus is driving (Burnout, Gran Turismo) or that freeware Japanese delivery game Rider he would have realised the tedium and complexity inherent in driving...
Slashdot Mirror
There are a few spots of the kernel that do use hand crafted SSE assembly (a quick glance says RAID calculation is one area (also here) and a particular crypto routine is another) but it is quite rare. Up until SSE4, SSE was really targeted at multimedia applications that contained a lot of floating point arithmetic. Generally floating point is avoided within the kernel so the maintenance pain of crafting an SSE optimised routine along with generic C version would not be worth it. Seemingly when you go to write assembly these days you have to account for the following:
Also don't conclude that just because the kernel doesn't contain many handcrafted SSE routines that no SSE instructions will ever be emitted by the compiler (assuming you've told it that you have a CPU that can cope with them). I believe very new versions of GCC (4.3 and above) have the just gained the ability to emit SSE4 instructions.
Last year Rob Landley was working on getting the Tiny C Compiler to build the kernel unmodified (again by adding gccisms to tcc) - here's an OLS video of the Landley talking about changing tcc to compile the kernel. Alas, from what I gather this effort has stalled for now.
It is unlikely that you will see the kernel adopting anything that makes the build process much more complicated. Operating system glue layers (e.g. abstractions in code for drivers that are supposed to run on other platforms) are already already frowned upon in drivers. Any new dependencies on tools like autoconf or cmake would most likely be rejected with a "what are we gaining?" complaint. My understanding is that patches that convert gccisms to their C99 equivalents are generally accepted but people are not willing to maintain glue for other compilers because it makes the default case painful. That's their choice - there are always other OSes like NetBSD that can be "compiler portable".
When it comes to reads you can't really postpone them - if someone wants to play that music file now and you don't have it already in cache (and Linux already uses unused memory as cache) then you have to hit the disk.
When it comes to writes you you can often delay them so long as no one is waiting on you telling them that you have written the data to the disk (in which case you have to no choice but to hit the disk). This is already tunable via /proc/sys/vm/dirty_writeback_centisecs . Further there are things like /proc/sys/vm/laptop_mode that will try and batch writes when other I/O was going to happen (e.g. when you play that music file all the writes can happen too). Of course, in the event of a crash you lose much more data (as it wasn't on the disk) and you create more disk contention. See the Lesswatts disk tips page for more details.
While the top quality stuff might last, my own personal experience with el cheapo SSDs is that they go bad quickly with moderate (in my case laptop) use due to shabby wear levelling. Others are also warning about (cheap) SSDs throwing away data too. Such SSDs are often the ones you are going to encounter so while the majority of SSDs out there show this behaviour I think it's a warning worth mentioning...
As mentioned on the nedmalloc page, glibc uses ptmalloc which (on average) isn't that slow.
glibc 2.3's malloc certainly isn't optimal for every possible workload but it doesn't tend to be incredibly poor for any workload either. For Firefox on Linux switching to jemalloc didn't cause as big an improvement as it did on Windows.
First up your point about the sheer proliferation of different ways of playing sound on Linux and lack of docs is a strong one but things have been slowly improving over the years. The author of Pulseaudio has written a good guide as to what to use. The list of APIs is still bigger than 3 but in most cases it becomes clearer on what to target.
ALSA comes in (yeah I can hear the groans) two forms. A small "virtualisable" subset referred to as safe ALSA and full ALSA.
OSS is usually considered legacy. There most certainly is OSS4 (which is not) but that does not have the traction on Linux and most people only have an OSS3 -> ALSA layer so its dangerous for new apps to target it.
NAS is not that popular. I only come across it in Linux audio conversations like this. I don't think anyone feels they have to target it.
ESD is obsolete but was VERY popular. New apps should not be targeting it now though.
Pulseaudio. Interesting but has suffered due to partial implementations in some popular distros that users felt caused more problems than they fixed. For regular users I do think it is key for Pulseaudio to work past its problems though - it offers a lot of promise and is probably Linux's best chance to date of offering certain features. New apps can target it directly (for best support) or just use safe ALSA.
SDL (for sound). Interesting if you are writing games but in most other cases you would use something else. Its presence has never been a problem as it quickly became clear it was for games.
JACK. This is for professional musicians. If you have to target this then you are going after a high-end sound market. Most sound playing apps are not in this case.
KDE 4's Phonon. If you are only targeting KDE4 then I guess you should be using this.
gstreamer. If you are interested in codecs (e.g. playing vorbis music files or theora video) rather than decoding/encoding files yourself you should probably be using this.
For games use SDL. If you are only targeting KDE4 use the KDE4 stuff. For codec support use gstreamer. OSS and ESD should no longer be targeted in first tier Linux audio support. Pulseaudio will probably become more popular (so you can consider targeting it directly) but safe ALSA will probably have the broadest user base for a while.
Does this EA announcement count?
It's hard to say that UTF-8 always doesn't work well on Linux. I'm using a Latin alphabet and it's been years since I had UTF-8 problems. However that's not your case...
I don't like the direction this is heading in (i.e. guaranteed broken) - bah (this always happens)! You didn't say what type of printer you have though. I'm also worried that you are getting duff results from Windows too.
Some part of me is thinking that if the printer is a laser postscript thing then the font it has does not have an extended character set. On Windows you might be able to fudge this by saying something like "Send as Bitmaps" (this has drawbacks though). What should ideally be happening is that the font should be being uploaded to the printer so it knows how to print the letter "natively" as it were.
On Windows (yeah I know I keep mentioning but I've seen these things in passing) make sure you have the right fonts for the right country. I'm vaguely aware there are Asian languages packs for Acrobat that ships with different fonts. This might let you verify a PDF produced on one system is correct even if it is mangled when sent to the printer.
Does this happen for all non-latin alphabets you try and print or only ones that are using an UTF-8 encoding? Does printing Chinese UTF-8 websites also break? If you open the text files in a browser and print do you have the same issue?
vi and friends have heuristics for trying to guess the encoding of a file. UTF-8 patches went in a few years ago. Assuming your terminal font has the characters it should display most characters.
The information in UTF-8 and Unicode FAQ for Unix/Linux under the printing says CUPS should be able to correctly convert a UTF8 text file to postscript so I would be interested in seeing some sample files...
Could you put up some short example documents on the web and link to them so I can try them?
Late breaking news! It's looking bad for unicode PDFs
I don't quite understand the question (although from your message I fear the problem is real). I am sad that it is broken on Linux - it's probably fine on OSX but here in Linux land there are plenty of unfortunate issues to go around. Sometimes those issues get fixed in the end though.
I have a few questions of my own:
Where is the text coming from?
What format is the text in if it is coming from a file (plain, doc, tex etc)?
What program are you trying to print it from? Are you using lpr on the command line or some other means?
When you say print do you mean to a printer or do you mean to a PDF? If it's the first does printing it into a PDF and printing that produce a better result?
If it is a printer, do you know what type of printer it is (e.g. is it a postscript printer)?
Do you know how the text is being sent to the printer (I'm struggling to come up with better wording but is it really going as text or is something turning it into a postscript/preprocessed file first?)
Can you post a link to a web URI that has some sample text that shows the problem?
Being able to reproduce this problem myself would allow me to understand your issue. This is all offtopic for this post unfortunately and I have no idea how you will be able to follow up on this... Whatever happens, good luck!
Some people really do have x86 servers that aren't Windows... Being able to build a DOS "disk" for flashing purposes on such "1%" machines (because it's not feasible to put Windows on) is extremely important in such scenarios and doesn't seem unreasonable.
There really is a not-insignificant chunk of other stuff out there.
The POST a typical non-server grade system does some very weak memory tests. In all the cases I've seen of bad RAM in the past few years the POST never said anything. Skipping the memory check would be no big loss.
If you suspect your memory really is bad, run a proper memory checker. They catch far more memory faults than the POST does,
Experience has taught me that many UK University and school firewalls will arbitrarily block all sorts of outgoing packets (I have recently witnessed ICMP echo packets being thrown away by such firewalls). I have experience of outgoing encapsulated ip being blocked up by such firewalls rendering tunnel brokers useless.
I suspect external ipv6 won't arrive at most UK academic institutions until the institution's network folks decide to do it directly (there are some places where this is already the case).
Experience says that Samba usually is the "easiest" way (especially if some smidgen of security beyond IP address is needed). Don't forget if Samba notices another Samba system at the other end it enables some extensions. The alternative is going down the NFS v4 massive configuration route.
If you don't care about speed and are in Linux (or OSX... kinda) only environment and you mean ad-hoc (rather than log in) shares, sshfs is pretty easy to get going with recent distros. However, the moment you also need to share to Windows it's better to do the Samba dance.
Your boot is going to have to be sequential until you have decompressed ALL the data though. At only 50Mbytes your CPU is probably going to be stalled longer doing the decompression than waiting for 100Mbytes off your storage medium in our mythical one second boot (unless single CPU speeds get incredibly fast). You also can't make use of execute in place.
Using compression in the fashion you are suggesting is only a win if you are avoiding the slowness of reading in the data (e.g. by avoiding disk seeks due to having less data). As it stands you are probably going to cycle the RAM caches with all that decompression too...
This post is TOTALLY offtopic. Really you need to split these up and file them as bug reports over on launchpad. I'll post a couple of comments answers but I'm not going to follow up on any of this (even if you answer any questions I ask).
- switching from dual display to presentation (clone) and back totally messes up x config, I have to uninstall and reinstall nvidea drivers
Talk to NVIDIA (Linux web forum) about this. It's their code you're running and they are probably the only ones who are willing to fix it.
- in dual screen mode, nautilus opens on the first display. I have to open terminal and run nautilus& to lunch it on the second display
You can't drag it? I don't quite understand...
- in dual screen mode, keyboard keeps focus in the previous screen. I have to minimize/maximize a windows on the "new" screen to move keyboard focus
Are you using desktop effects? (Do windows fade and slide etc?) If so this sounds like a bug in compiz...
- RDP client crashes X windows in some cases (it does not close the drop down list of used servers... and bang)
Hmm. I'm really curious now as to whether you are using compiz. Regardless your best bet with this one would be to be to see if you can capture a backtrace of the crash with debug symbols and to file a bug report against the RDP client (I'm guessing you're using tsclient) in launchpad.
- oh and NO it's not AN ERROR if I close the RDP window. If I want to reconnect, I will, don't hide under my active windows and bring RDP windows back in 30 seconds. That's just plain stupid.
I guess file an enhancement request on tsclient in launchpad.
- java and window decorations don't play well together (popups without buttons etc.)
I really would like to know whether you are using compiz. If you are I have a feeling this was a known "bug" in the Java bug database for a long time but the fix is not yet in Ubuntu.
- How about opening a connection to a new server in a new tab, not in a new nautilus window?
Hmm probably best to file an enhancement request over on the GNOME bugzilla.
- Flash stops working. I just see a gray square where flash is supposed to be.
64 bit Firefox using 32 bit Flash via nspluginwrapper I'm guessing. There is a 64bit Linux Flash plugin that is in very early beta that MAY work better for you (I've heard mixed things mind). Also make sure you're using Flash 10 whatever route you are taking.
- Firefox is not very stable.
Might be because of extensions or plugins or you may have found a problem page or your memory might be faulty or Firefox might be buggy or... You are going to have to sit down and capture the issue in Firefox this then file a bug report in launchpad.
- Windows would become gray and unresponsive when there's a lot of disk activity.
You're using compiz aren't you? The greying is compiz telling you that the window HAS become unresponsive! As to why this is happening on I/O it probably varies from program to program. Too little information to many possibilities to say more.
- I've seen ubuntu crash on my much more times than I've seen BSOD on the same HW.
Quite possible. I've seen Linux stable on some computers and fla
A while back you mentioned about the USB probing could be made faster (and asked why I was using pciehp). Well you were right USB probing DID get faster (boot tracing SVG of EeePC 900) and I no longer need pciehp on my EeePC 900.
I bet that making the kernel more asynchronous than it already is (with the current async patches) won't save any more significant amounts of time on this particular setup though! : )
It's absolutely true that Linux has a terrible time suspending to RAM (or coming back from suspend) on certain hardware. It has DEFINITELY been improving over the past two years though (one of my systems was fixed around 9 months ago).
First up make sure you are using the latest kernel you can (new fixes for suspend issues seem to have gone into each of the past few kernel releases including the very latest one). If you have the time you might be able to use the OpenSUSE instructions on debugging suspend to RAM to isolate where the fault lies.
Assuming the problem is more than monitor being off (i.e. the system is completely hanging without any binary only drivers being loaded) if you know how to run the very latest kernels (a prerelease 2.6.29) could you file a bug report over on Kernel Bugzilla after you've checked out the Linux kernel suspend debugging howto?
I admit I haven't checked this recently but isn't DSL using squashfs which is a compressed filesystem? If so that 50Mbytes is going to have to be uncompressed and that's going to take up precious time in that one second boot...
Driver probing isn't really why it's slow. Even without Arjan van de Van's fastboot kernel work probing for hardware* and loading drivers is not usually not what takes the most time during boot.
Typically boot time is dominated by the time it takes to actually read data from the disk (so disk seek time is a factor - especially if you aren't using readahead). Secondary to that is the time to start services. Assuming you are booting something graphical desktop environments (GNOME/KDE) take a bit of time to start too followed by X itself (this might be fixed now if you have kernel mode setting).
The above is excluding the BIOS boot time by the way - those can vary dramatically too. I've seen some servers that take many times longer to boot from cold past the BIOS than a typical desktop system takes to finish booting from poweroff all the way to a started Firefox.
* So long as we aren't talking about servers which may have large numbers of spun down disks or a big SCSI bus that takes time to enumerate etc.
Bootbooster caches various bits of the BIOS probing to the disk and allows the Eee to finish the BIOS phase faster than normal (providing you are booting off the internal SSD). The link is slightly inaccurate in so much as it doesn't speed up grub but instead cuts the time it takes to get to grub.
(After reading this and another comment I posted another follow up)
And for those kind words I'm going to post a follow up to my original post of more relevant changes between the 2.4 and latest 2.6 kernels (I'll try and add a few more words after each point).
Kernel configuration was overhauled. Outside support for more GUI menus, it now means you no longer have to do make dep after changing something. Further building modules outside the kernel tree is now not so baroque. The time to build and partially rebuild kernels also dropped. Building a kernel in parallel (i.e. using more than one CPU during the build process) works better.
Better support for configuring out unneeded parts of the core kernel on embedded systems. You can see the seeds of this going mainline in a git commit on 2.5.70. There is an outside project called Linux Tiny that produces patches aimed at being able to configure out features not needed for embedded systems. Over the course of 2.6 many of these patches have trickled into the mainstream kernel.
I mentioned that 2.6 scales better under load in my previous post. Here are some benchmark comparison graphs of 2.4 versus 2.6 kernels (the graphs also include comparisons against the BSDs but you can see that Linux 2.4 had some serious problems that Linux 2.6 addressed).
The kernel is now (on systems where there is reliable device discovery) able to automatically load the modules it needs to drive hardware. No more having to adjust static lists of which modules need to be loaded.
udev was introduced. This change meant that the entries in /dev were no longer static. In 2.4 all possible device entries (even for devices you didn't have) were shown in /dev and their major/minor numbers were fixed (which was causing problems as new devices were turning up - what major/minor number do you give them?). Additionally the other dynamic /dev system (devfs) was whittled away and killed off.
FUSE support (LWN article about FUSE). Allows filesystem drivers to be written in userspace. Currently the best Linux NTFS driver is written using FUSE and it allows fun things like sshfs. Might be handy if you need users to be able to configure where data is stored remotely, you are writing your own filesystem or you need to support writing to NTFS formatted USB disks...
There is better CFS (Samba/SMB/Windows File Sharing) support. NFS version 4 support was also added.
cpufreq support. The kernel can clock down the CPU speed (usually by changing voltages via some hardware interface) to save large amounts of power. This can be done in response to work load so you run at full speed as often as possible and then when things are quiet you scale down to the lowest setting (you often save the most power when doing absolutely nothing so it pays to finish things as quickly as possible).
Any switch from 2.4 to 2.6 will of course require userspace changes (updated modutils, udev, later gcc, later glibc).
There is also davej's post Halloween document discussing changes from 2.4 to 2.5. This is very detailed and is another excellent reference.
Many many other things have changed too (e.g. ALSA support for sound has been added) but I have tried to keep the ones mentioned at least tangentially related to the original scenario :)
Believe it or not it's surprisingly hard to have a player/OS combination that will play ALL the types of video out there. I think the most complete combination is some version of Windows with Quicktime, RealPlayer and VLC installed (and that probably won't play everything) with Flash installed for typical web video.
It's another case of "if someone hasn't done it for you then it's a pain".
I'm a bit younger than you (think decades) and I see other folks approaching your age picking up their (older) kids as though they are as light as a feather. When said kids ask ME to pick them up it just doesn't happen - I don't have that kind of weightlifting ability.
My current guess is that parents develop limbs of steel and muscles with infinite torque. It is only a matter of time before you too develop this miraculous ability to be able to lift cars and children with a single arm...
Poor videogame choice strikes again. If the kid had been given appropriate games where the key focus is driving (Burnout, Gran Turismo) or that freeware Japanese delivery game Rider he would have realised the tedium and complexity inherent in driving...
Remember - give your kids APPROPRIATE games.