This is pedantic but I don't consider references to be pointers because they can be garbage collected. Someone summed it up to me like this: The difference between pointers and references is that you can do arithmetic on pointers.
It's a real shame what the burger flippers are doing that to you folks though...
Bonjour for services hasn't taken off in a big way on Linux (or Windows outside of Adobe Products/iTunes for that matter). However, most Linux distros now ship with Avahi which is fairly mature but there are comparatively few programs that can use it (its main use currently seems to be for autoip configuration). Some distros also firewall it off by default (but Kubuntu isn't in that list).
I've noticed music programs (Rhythmbox, Amarok) often support it but they are trying to interoperate with iTunes which is another issue again.
I'm also a little sad that OSX has dropped default support for printers annouced over CUPS broadcast but thems the breaks. If you know what you're doing it's possible to renable it (and set your Macs to broadcast too but that's another story).
I wish I could mod you up and still reply to your post because your basic point is sound (vendors frequently stop supporting old software). However I just quickly want to say that RHEL is currently supported 7 years so yes, I can name a vendor that will support you using a 7 year old version of their product - Red Hat. (You can argue that we're talking about formats rather than programs though)
Now as to that compatiblity pack for Office 2003... Earlier last year I had reason to ask someone to install the file format the addon. The problem was that the 2007 document in question was sent with a.doc extension which meant that Word 2003 still refused to open it after the addon was in place. Changing the extension on the file to.docx solved the problem but it was annoying because I didn't already know that was all that was needed especially given that Windows doesn't show extensions by default. Once the file was renamed it worked fine.
It's easy enough to copy a Linux ISO to a USB key and make it bootable but if it could boot an ISO just sitting on the key (without having prepared the key first) that would be even better (but sounds fiddly without software).
I can't come up with a long list but I can suggest a few. Didn't bittorrent start off open source? I still like rsync and it's method of transmission. I considered compiz and its wobbly windows to be innovative when I saw it. Doesn't the GRASS GIS software have features not found elsewhere?
When someone says innovative I often wonder what they mean. Is it innovative taking an old idea and making it popular? Is an idea still innovative if you put it out at the same time that several others? How different do you have to be from what went before to be considered innovative? If you independently reimplement something isn't that innovative? Is it relative to - does it simply have to be new to an individual?
I do wonder if innovation is overrated though. Being first doesn't always yield the most benefit in the long run (Wordstar isn't in common use). There are loads of innovative computer science related pieces of software out there but much of it is very niche based so as not to be usable by the vast majority. Additionally I'd argue some innovations have landed their companies with customers who were upset because people are inherently suspicious of change and it is rare to get things right first time.
I think the people who clamour for the most innovation are those who have seen the most products. If you see every last incremental improvement continuously sooner or later nothing will seem new.
Disclaimer: I happen to know Alan and he's a bright chap. You shouldn't blindly believe everything bright people tell you but that doesn't mean they're always talking rubbish either.
I'm going to just chime in and say RAID (as most people use the phrase) is not a backup. Again - RAID (as most people use the phrase) is NOT a backup. As you suggested RAID (I assuming you are discounting "RAID0" as I don't think it helps your argument) helps safety - but only a particular type of safety. If you delete a file on most RAID systems the file is "deleted" from all the disks. The RAID did what you told it - it only distributed the data you told it to keep but sometimes mistakes happen and we would like to recover from them with minimal cost. Many people are told about RAID and conclude that it solves all possible data issues but it isn't that simple.
Additionally I have first hand experience of seeing hardware RAID5 fail due to a failing disk. It really does happen but at the moment it doesn't happen often and I was able to go back to backups. All I can say is - it is important to understand the scope and limitations of whatever system you are putting in place. A lack understanding on a given topic can really come back and hurt you. My understanding must be complete if I always want the correct answer and in those cases where it is not, just because I believe something to be true it need not be true (or even possible).
Finally I've been told that many locks you get today can be picked by a good lockpicker with decent tools in a relatively low amount of time. Further if someone REALLY wants to break into your house maybe they won't try and break the lock on the door but they will instead just smash a window round the back. I think there's a phrase "Locks only keep honest people honest" - they are only there to stop people casually getting into your house, not keep out the determined.
The perils of RAM just seems to be one of those open secrets. Apparently even Microsoft has tried pushing for ECC RAM in all machines (including dekstops) as memory errors have risen to the top 10 causes of system crashes according to their crash analysis.
Earlier this decade I was living with strange, random crashes when booting Linux that would only seemingly only occur when booting from cold (but not every time!). It was only years later when running a memtest on someone else's sticks (which turned out to be fine in their machine) that I learned that the motherboard was unhappy with the timing settings even though the RAM was rated as being compatible with said settings.
A few years later on a different machine I was MD5summing a big file locally and the sum turned out to be different to what was expected. For whatever reason I tried doing a MD5sum of the same file over a network filesystem (as the server was running Samba) and was surprised to find that the sum came to the expected result. Upon reruning the MD5sum locally the sum was again incorrect...... in a manner that was different to the first try. Repeated runs on the same unchanging file were giving different MD5sums. Running a memtest went on to show the memory was dodgy.
I have also seen a not inexpensive system throw up SCSI errors and effectively make the disks disappear from the operating system while doing RAID 5 with a hardware SCSI RAID controller after a single disk failure. Apparently if a SCSI disk fails in a particularly rare manner it is possible for it to keep the bus busy and thus disable communication with any other drives on same bus. Thankfully the backups worked (the filesystem had been corrupted) but if your data is important you can never be too careful. As disk and memory sizes go up along with the rates that data are transferred the chances of rare circumstances like bit flips happening only increase. The question is - will you notice the problem before it's too late and are how much are you willing to pay (in terms of money and performance) to reduce the odds?
I'm no expert I'm afraid but I'll let I'll share with you what I know. The Linux I/O scheduler (which I believe turned up some time in the 2.6 era) is somewhat separate from the CPU scheduler (although there is a link in priority and timeslices). Thus it was always possible to drag a process doing I/O down by having something else perform enough disk I/O, especially if you are the root user. If you can make a system swap that will hurt things even more (and that's a form of I/O).
The thing to remember is that servicing certain types of I/O need not necessarily use up much CPU time. If a device is capable of doing DMA it will need comparatively little time from the CPU to be serviced (bigger transfers can happen while the CPU is off doing other things as opposed to have the device generating interrupts all the time that the CPU has to service before any more data is transferred because some temporary buffer is full and needs moving). Additionally, certain network drivers are able to do NAPI which can reduce CPU load during heavy transfers. The way that Linux handles interrupts (which have a top and bottom "half") allows the bottom half to happen in a process context (so the heavier part of the processing counts towards a process's timeslice). This is touched upon in on Robert Love's MMCSS entry. However, if you have an important process's I/O queued up behind something less important (and the low priority task is able to generate enough a big enough request for I/O on its timeslice) then the important processes may appear to go slower (effectively its latency will go up due to having to be passed over because its I/O isn't ready) despite having more CPU time assuming the hardware can't satisfy all the requests for I/O quickly enough (imagine big writes to a slow disk with deep queues and the task needing acknowledgement all the data made it to disk).
Depending on which I/O scheduler you picked and your hardware you may be able to alleviate this problem but that's not to say that things can't be improved (or that no one is complaining about the problem).
In short I would imagine the new CPU scheduler impact would be marginal improvement on I/O performance or latency under I/O load. If it was OK before it should still be OK (but bear in mind in memory virus scanning is a special case that I would imagine would make any OS go slower).
If so it could be down to rounding issues due to accumulated error (you do a calculation and due to the fractional part you end up rounding up, something changes ever so slightly and now the fractional part is smaller so you end up rounding down).
I have to admit I thought most of these had been squashed years ago (I used to see this many times a day back in 2000). If you have time on your hands you might want to trawl Mozilla's Bugzilla for the issue. If you have slightly less time or can't find an existing bug but have a reliable test case that always shows the problem, you are probably best off filing a new bug report.
The licence oversight was just that and needed fixing but if the modified exe business is true then someone made one small problem and another larger problem with this particular distribution.
You're probably one of those script-ruby-wiki-vandal-spam-botnet-evangelists aren't you? When I foolishly blurt out this new cool site you quietly infiltrate it accounts from your zombie bot army... Then one day you strike and destroy the inboxes and connectivity of 99% of the most important people in one strike. I wind up being disowned and the remaining 1% are forced to wander from IRC server to ICB server looking for a new home...
Besides, I'm no luminary so I am on the wrong side of the fence to know where everyone has gone (if they have indeed gone anywhere). Years from now we'll probably find that they're all on Facebook or something...
I remember hearing that Samba has some pretty elegant code. Apparently several projects like talloc have also fallen out of it. Later versions also have very extensive test suites...
Andy mentions this topic towards the end of an interview with Bob Cringely on Nerd TV. At the bottom of this archive of NerdTV episodes is a link to episode number 1 in a variety of formats. Here's the transcript of the Nerd TV interview where Andy says
So I was thinking of putting it on the site, Apple would send me a cease-and-desist, I'd take it down, but it would be out there then. But I was just a little too chicken. Finally Tim O'Reilly came up with the brilliant solution of donating it to the Computer History Museum as a historic artifact. Perhaps they could get permission from Apple. So that's what we did. It took a few months but [i]n August Apple approved the donation of the MacPaint source code to the Computer History Museum. This was their first major software artifact in their collection so they made a big deal of it, made a video of us, and eventually the MacPaint source code will be available from their web site to anyone in the world.
It's just occurred to me you are Tim O'Reilly. Wow, there are still some important folks that still post on/. ! Your company gave me some free books and a T-shirt when I was in my second year of University, thanks! Many of the well known people who used to post here have abandoned it in recent years so the feel of the place has changed. The only big name I still see around here is Jeremy Alison from Samba...
(However if you check the Wikipedia list of computer bus bandwidths is says that x16 PCIe 1.0 can only reach 40Gbit/s. I think this is because the encoding overhead has been taken into account).
The GP also forgot to mention the 3rd option (for the flash plugin): 3) nspluginwrapper. It's far from easy to get going on Ubuntu Feisty and needs a 32 development environment (in addition to a 64 bit environment) to be compiled but it _can_ be made work. A brief glance suggests it does it stuff by running the plugin in a 32 bit environment and communicating back to the 64 bit browser over sockets.
The open source ATI folks have a tool for the r300 chipsets called revenge and another tool imaginatively called radeondump which I gather do something similar. However tools like the mmiotrace are useful for both efforts so I think both projects are as "sophisticated" as each other.
Microsoft - Conspiracy theorists find a way to blame Microsoft for every problem in Linux. This time they point out when Microsoft decided to use a vendor's chip in the XBox consoles or chipset vendors puts DirectX 8.0 support you don't get specs any more.
??? - Patents and fear of competitors or patent scumsucking companies bringing infringement. Vendors claim releasing chipset docs to the public may make it easier for these things to be found; however, most X.org developers have no problem signing suitable NDAs .
Profit - Graphics card manufacturing is a very competitive industry, especially in the high-end gaming, 3-6 month development cycle, grind-out- as-many-different-cards-as-you-can. Quake 3 speeds are spotted in binary drivers any way and it doesn't explain fglrx which are some of the most unsuitable drivers for gaming on Linux.
Read the proceedings for detailed explanation of why no more kittens need to killed!
See ATI dri drivers. Support for the r300 and above came about through reverse engineering effort so in many ways the ATI reverse engineering effort is far further along (in so much as there are end user drivers that are even capable of the basic desktop effects)...
ATI Committed To Fixing Its OSS Problems was posted only a few days ago (that one came from Chris Blizzard's blog) and the cautious tone is backed up by other Red Hat summit reports. However, since we're here why don't we pick out the highlights (along with overlooked gems) from last time?
Elsewhere on the web folks are wondering whether this means that the a new GPGPU will be accessible but the actual graphics driver itself will remain closed. AMD/ATI has also announced open source drivers before which translated into more stable and more frequently released Linux binary x86 drivers...
Ever since Ubuntu Edgy much of the low hanging fruit in speeding up the Ubuntu boot has already been taken. Looking at the bootcharts for my system since then shows remarkably little time when the CPU is idle once the base kernel has finished loading. This means that running anything more in parallel simply won't net me anything (in fact scheduler overhead and disk thrashing may in theory make things slower).
For example, there is an improvement in the time it takes for the clock to appear from "Ubuntu Dapper Flight 3 Default kernel" to "Ubuntu Feisty Herd 5 generic kernel". The Ubuntu folks worked hard to try an eliminate sleeps from their initscripts and when a sleep was unavoidable they would run other parts of the startup process in parallel. They also made changes to Xorg to prevent it (re)reading so much stuff on launch. There was also the introduction of the readahead script which tries to arrange for as much of the boot time reading to be done in one big chunk. Throughput is higher when the disk is only reading and can utilise it's readahead. An attempt is also made to try and request files in the order in which they are laid out on disk (to minimise disk seeks which hurt performance). In Feisty a move was made to using dash instead of bash for scripts because it was smaller and executes scripts faster.
The only things that seem to win me any gain over the default Ubuntu Feisty install are turning off initscripts for services I absolutely won't use (e.g. ipv4 autoconfig via avahi) and reducing the number of restricted binary driver modules being probed (I have long noticed that the only benefit that recompiling the kernel gives to boot speed is that you can simply leave out features not on your computer making the initial kernel startup where it probes for things you might not have (like which software RAID is faster) a shade faster). It is also worth noting that Ubuntu starts X quite early and continues loading services afterwards which means the gain from disabling one of these "after X" services (like CUPS) isn't so noticeable (but might mean your desktop actually starts responding to clicks a bit sooner).
Profiling the boot to try and improve the readahead takes a long time to run - the profile run seems to take three times as long as a regular boot. It could be argued that you will never gain back the extra time you waited on the profile run...
And they most certainly accelerated. Two things can happen: 1. Their output is redirected to an offscreen buffer (either a framebuffer object or an older pbuffer) 2. There's an option to pass fullscreen unobstructed windows straight to the card.
Furthermore the reason why AIGLX doesn't work with the ATI binary drivers is because they don't yet implement GLX_EXT_texture_from_pixmap GL extension. The composite extension is handled by X itself - not the graphics driver - and thus is a non-issue.
You are right that XGL doesn't expose all the extensions/features of regular X though. The usual place where you see this is in video as XGL is forced to use a card's 3D support for everything and if you don't have pixel shaders not being able to use the accelerated Xv that the regular X provides tends to be slow.
Slashdot Mirror
http://miller.emu.id.au/pmiller/books/rmch/
This is pedantic but I don't consider references to be pointers because they can be garbage collected. Someone summed it up to me like this: The difference between pointers and references is that you can do arithmetic on pointers.
It's a real shame what the burger flippers are doing that to you folks though...
Bonjour for services hasn't taken off in a big way on Linux (or Windows outside of Adobe Products/iTunes for that matter). However, most Linux distros now ship with Avahi which is fairly mature but there are comparatively few programs that can use it (its main use currently seems to be for autoip configuration). Some distros also firewall it off by default (but Kubuntu isn't in that list).
I've noticed music programs (Rhythmbox, Amarok) often support it but they are trying to interoperate with iTunes which is another issue again.
By the way I think someone said they might work on a Kopete bonjour plugin a few weeks ago.
I'm also a little sad that OSX has dropped default support for printers annouced over CUPS broadcast but thems the breaks. If you know what you're doing it's possible to renable it (and set your Macs to broadcast too but that's another story).
I wish I could mod you up and still reply to your post because your basic point is sound (vendors frequently stop supporting old software). However I just quickly want to say that RHEL is currently supported 7 years so yes, I can name a vendor that will support you using a 7 year old version of their product - Red Hat. (You can argue that we're talking about formats rather than programs though)
.doc extension which meant that Word 2003 still refused to open it after the addon was in place. Changing the extension on the file to .docx solved the problem but it was annoying because I didn't already know that was all that was needed especially given that Windows doesn't show extensions by default. Once the file was renamed it worked fine.
Now as to that compatiblity pack for Office 2003... Earlier last year I had reason to ask someone to install the file format the addon. The problem was that the 2007 document in question was sent with a
It's easy enough to copy a Linux ISO to a USB key and make it bootable but if it could boot an ISO just sitting on the key (without having prepared the key first) that would be even better (but sounds fiddly without software).
I can't come up with a long list but I can suggest a few. Didn't bittorrent start off open source? I still like rsync and it's method of transmission. I considered compiz and its wobbly windows to be innovative when I saw it. Doesn't the GRASS GIS software have features not found elsewhere?
When someone says innovative I often wonder what they mean. Is it innovative taking an old idea and making it popular? Is an idea still innovative if you put it out at the same time that several others? How different do you have to be from what went before to be considered innovative? If you independently reimplement something isn't that innovative? Is it relative to - does it simply have to be new to an individual?
I do wonder if innovation is overrated though. Being first doesn't always yield the most benefit in the long run (Wordstar isn't in common use). There are loads of innovative computer science related pieces of software out there but much of it is very niche based so as not to be usable by the vast majority. Additionally I'd argue some innovations have landed their companies with customers who were upset because people are inherently suspicious of change and it is rare to get things right first time.
I think the people who clamour for the most innovation are those who have seen the most products. If you see every last incremental improvement continuously sooner or later nothing will seem new.
Disclaimer: I happen to know Alan and he's a bright chap. You shouldn't blindly believe everything bright people tell you but that doesn't mean they're always talking rubbish either.
I'm going to just chime in and say RAID (as most people use the phrase) is not a backup. Again - RAID (as most people use the phrase) is NOT a backup. As you suggested RAID (I assuming you are discounting "RAID0" as I don't think it helps your argument) helps safety - but only a particular type of safety. If you delete a file on most RAID systems the file is "deleted" from all the disks. The RAID did what you told it - it only distributed the data you told it to keep but sometimes mistakes happen and we would like to recover from them with minimal cost. Many people are told about RAID and conclude that it solves all possible data issues but it isn't that simple.
Additionally I have first hand experience of seeing hardware RAID5 fail due to a failing disk. It really does happen but at the moment it doesn't happen often and I was able to go back to backups. All I can say is - it is important to understand the scope and limitations of whatever system you are putting in place. A lack understanding on a given topic can really come back and hurt you. My understanding must be complete if I always want the correct answer and in those cases where it is not, just because I believe something to be true it need not be true (or even possible).
Finally I've been told that many locks you get today can be picked by a good lockpicker with decent tools in a relatively low amount of time. Further if someone REALLY wants to break into your house maybe they won't try and break the lock on the door but they will instead just smash a window round the back. I think there's a phrase "Locks only keep honest people honest" - they are only there to stop people casually getting into your house, not keep out the determined.
The perils of RAM just seems to be one of those open secrets. Apparently even Microsoft has tried pushing for ECC RAM in all machines (including dekstops) as memory errors have risen to the top 10 causes of system crashes according to their crash analysis.
... in a manner that was different to the first try. Repeated runs on the same unchanging file were giving different MD5sums. Running a memtest went on to show the memory was dodgy.
Earlier this decade I was living with strange, random crashes when booting Linux that would only seemingly only occur when booting from cold (but not every time!). It was only years later when running a memtest on someone else's sticks (which turned out to be fine in their machine) that I learned that the motherboard was unhappy with the timing settings even though the RAM was rated as being compatible with said settings.
A few years later on a different machine I was MD5summing a big file locally and the sum turned out to be different to what was expected. For whatever reason I tried doing a MD5sum of the same file over a network filesystem (as the server was running Samba) and was surprised to find that the sum came to the expected result. Upon reruning the MD5sum locally the sum was again incorrect...
I have also seen a not inexpensive system throw up SCSI errors and effectively make the disks disappear from the operating system while doing RAID 5 with a hardware SCSI RAID controller after a single disk failure. Apparently if a SCSI disk fails in a particularly rare manner it is possible for it to keep the bus busy and thus disable communication with any other drives on same bus. Thankfully the backups worked (the filesystem had been corrupted) but if your data is important you can never be too careful. As disk and memory sizes go up along with the rates that data are transferred the chances of rare circumstances like bit flips happening only increase. The question is - will you notice the problem before it's too late and are how much are you willing to pay (in terms of money and performance) to reduce the odds?
I'm no expert I'm afraid but I'll let I'll share with you what I know. The Linux I/O scheduler (which I believe turned up some time in the 2.6 era) is somewhat separate from the CPU scheduler (although there is a link in priority and timeslices). Thus it was always possible to drag a process doing I/O down by having something else perform enough disk I/O, especially if you are the root user. If you can make a system swap that will hurt things even more (and that's a form of I/O).
The thing to remember is that servicing certain types of I/O need not necessarily use up much CPU time. If a device is capable of doing DMA it will need comparatively little time from the CPU to be serviced (bigger transfers can happen while the CPU is off doing other things as opposed to have the device generating interrupts all the time that the CPU has to service before any more data is transferred because some temporary buffer is full and needs moving). Additionally, certain network drivers are able to do NAPI which can reduce CPU load during heavy transfers. The way that Linux handles interrupts (which have a top and bottom "half") allows the bottom half to happen in a process context (so the heavier part of the processing counts towards a process's timeslice). This is touched upon in on Robert Love's MMCSS entry. However, if you have an important process's I/O queued up behind something less important (and the low priority task is able to generate enough a big enough request for I/O on its timeslice) then the important processes may appear to go slower (effectively its latency will go up due to having to be passed over because its I/O isn't ready) despite having more CPU time assuming the hardware can't satisfy all the requests for I/O quickly enough (imagine big writes to a slow disk with deep queues and the task needing acknowledgement all the data made it to disk).
Depending on which I/O scheduler you picked and your hardware you may be able to alleviate this problem but that's not to say that things can't be improved (or that no one is complaining about the problem).
In short I would imagine the new CPU scheduler impact would be marginal improvement on I/O performance or latency under I/O load. If it was OK before it should still be OK (but bear in mind in memory virus scanning is a special case that I would imagine would make any OS go slower).
If so it could be down to rounding issues due to accumulated error (you do a calculation and due to the fractional part you end up rounding up, something changes ever so slightly and now the fractional part is smaller so you end up rounding down).
I have to admit I thought most of these had been squashed years ago (I used to see this many times a day back in 2000). If you have time on your hands you might want to trawl Mozilla's Bugzilla for the issue. If you have slightly less time or can't find an existing bug but have a reliable test case that always shows the problem, you are probably best off filing a new bug report.
I gather that a copyright notice has no been added to the Steam DosBox distribution but all the interest has now led people to carefully check how DosBox is being distributed. Currently it looks like someone went and modified DosBox.exe to make it check in with Steam (I can't verify this myself though). If this is true (it's not clear what has happened to this exe) a can of worms has been opened (and the half-chance "easy" way out might have been closed).
The licence oversight was just that and needed fixing but if the modified exe business is true then someone made one small problem and another larger problem with this particular distribution.
See AMD/ATI graphics drivers Slashdot greatest hits for some further details. I would love to see better (and ideally Free) Linux support from their drivers (yes there is some Linux support out there but I'm told if you have the very latest ATI/AMD HD X2xxx cards then you will have no 3D on Linux). This is not too surprising because for around 6 months after launch there was no X1xxx Linux support. The drivers have DEFINITELY improved over time (the number of crashes due to binary ATI drivers has fallen) but while AMD/ATI are still doing stuff like refusing to get back to developers or AMD/ATI are allegedly misappropriating developer code I feel very uneasy and currently I would be wary of buying a machine with a new AMD/ATI graphics card for use with Linux.
You're probably one of those script-ruby-wiki-vandal-spam-botnet-evangelists aren't you? When I foolishly blurt out this new cool site you quietly infiltrate it accounts from your zombie bot army... Then one day you strike and destroy the inboxes and connectivity of 99% of the most important people in one strike. I wind up being disowned and the remaining 1% are forced to wander from IRC server to ICB server looking for a new home...
Besides, I'm no luminary so I am on the wrong side of the fence to know where everyone has gone (if they have indeed gone anywhere). Years from now we'll probably find that they're all on Facebook or something...
I remember hearing that Samba has some pretty elegant code. Apparently several projects like talloc have also fallen out of it. Later versions also have very extensive test suites...
It's just occurred to me you are Tim O'Reilly. Wow, there are still some important folks that still post on
PCIe does *theoretical* maximum of 8GBytes/s according to Wikipedia. 8 bits in a byte so 8*8 = 64Gbits/s and 64Gbits > 40Gbits mentioned in the article. Watch out on those units - case matters!
(However if you check the Wikipedia list of computer bus bandwidths is says that x16 PCIe 1.0 can only reach 40Gbit/s. I think this is because the encoding overhead has been taken into account).
Perhaps it is a hardware bug but hardware bugs occur with less frequency than software ones. Parallels definitely has bugs though and I've personally run up against Enabling Parallels' NAT shared networking makes Mail.app slow when replying to mail with attachments. Frustratingly, it is very hard to find a list of issues from the folks making Parallels.
I guess the way to know for sure if it's Parallels or the hardware is to test whether your issue turns up when using VMWare...
You're right. The Penguin.SWF blog says the flash JIT VM needs to be converted and that's why there's no 64 bit version.
The GP also forgot to mention the 3rd option (for the flash plugin):
3) nspluginwrapper. It's far from easy to get going on Ubuntu Feisty and needs a 32 development environment (in addition to a 64 bit environment) to be compiled but it _can_ be made work. A brief glance suggests it does it stuff by running the plugin in a 32 bit environment and communicating back to the 64 bit browser over sockets.
The open source ATI folks have a tool for the r300 chipsets called revenge and another tool imaginatively called radeondump which I gather do something similar. However tools like the mmiotrace are useful for both efforts so I think both projects are as "sophisticated" as each other.
Over in my slashdot post roundup there are mutterings in a post of further announcements. The same mutterings reappeared elsewhere too...
as-many-different-cards-as-you-can. Quake 3 speeds are spotted in binary drivers any way and it doesn't explain fglrx which are some of the most unsuitable drivers for gaming on Linux.
Read the proceedings for detailed explanation of why no more kittens need to killed!
See ATI dri drivers. Support for the r300 and above came about through reverse engineering effort so in many ways the ATI reverse engineering effort is far further along (in so much as there are end user drivers that are even capable of the basic desktop effects)...
Elsewhere on the web folks are wondering whether this means that the a new GPGPU will be accessible but the actual graphics driver itself will remain closed. AMD/ATI has also announced open source drivers before which translated into more stable and more frequently released Linux binary x86 drivers...
Ever since Ubuntu Edgy much of the low hanging fruit in speeding up the Ubuntu boot has already been taken. Looking at the bootcharts for my system since then shows remarkably little time when the CPU is idle once the base kernel has finished loading. This means that running anything more in parallel simply won't net me anything (in fact scheduler overhead and disk thrashing may in theory make things slower).
For example, there is an improvement in the time it takes for the clock to appear from "Ubuntu Dapper Flight 3 Default kernel" to "Ubuntu Feisty Herd 5 generic kernel". The Ubuntu folks worked hard to try an eliminate sleeps from their initscripts and when a sleep was unavoidable they would run other parts of the startup process in parallel. They also made changes to Xorg to prevent it (re)reading so much stuff on launch. There was also the introduction of the readahead script which tries to arrange for as much of the boot time reading to be done in one big chunk. Throughput is higher when the disk is only reading and can utilise it's readahead. An attempt is also made to try and request files in the order in which they are laid out on disk (to minimise disk seeks which hurt performance). In Feisty a move was made to using dash instead of bash for scripts because it was smaller and executes scripts faster.
The only things that seem to win me any gain over the default Ubuntu Feisty install are turning off initscripts for services I absolutely won't use (e.g. ipv4 autoconfig via avahi) and reducing the number of restricted binary driver modules being probed (I have long noticed that the only benefit that recompiling the kernel gives to boot speed is that you can simply leave out features not on your computer making the initial kernel startup where it probes for things you might not have (like which software RAID is faster) a shade faster). It is also worth noting that Ubuntu starts X quite early and continues loading services afterwards which means the gain from disabling one of these "after X" services (like CUPS) isn't so noticeable (but might mean your desktop actually starts responding to clicks a bit sooner).
Profiling the boot to try and improve the readahead takes a long time to run - the profile run seems to take three times as long as a regular boot. It could be argued that you will never gain back the extra time you waited on the profile run...
I suspect reducing the boot further will start to need more complicated procedures, perhaps reordering modprobe.conf and reducing the amount of needless reading of files. Eventually you end up having to do the same tricks as Windows/OSX - e.g. working out where the fastest part of the disk is and copying every file needed to boot there, bringing up the network cardafter the desktop has started, periodically defraging bits of the disk, prelinking...
And they most certainly accelerated. Two things can happen:
1. Their output is redirected to an offscreen buffer (either a framebuffer object or an older pbuffer)
2. There's an option to pass fullscreen unobstructed windows straight to the card.
Furthermore the reason why AIGLX doesn't work with the ATI binary drivers is because they don't yet implement GLX_EXT_texture_from_pixmap GL extension. The composite extension is handled by X itself - not the graphics driver - and thus is a non-issue.
You are right that XGL doesn't expose all the extensions/features of regular X though. The usual place where you see this is in video as XGL is forced to use a card's 3D support for everything and if you don't have pixel shaders not being able to use the accelerated Xv that the regular X provides tends to be slow.
Finally what's this about about compiz not being GPL'd? Where did you get that from - please quote your source. Given Beryl is not (yet) a complete rewrite of compiz, that basically means compiz must have had a BSD/MIT or GPL style licence in the first place...