I don't think all your examples are good and I believe there is some mis-attribution in there as well. Let's start with the ones that might support your argument. PulseAudio (Lennart Poettering), DeviceKit (David Zeuthen) and gnome-user-share (Alexander Larsson and Bastien Nocera) were all created by Red Hat employees. I would argue that neither Xorg/X, DeviceKit or PulseAudio are part of GNOME even though it runs on top of them. They are really Linux desktop infrastructure and someone's got to develop that...
Compiz was not developed inside GNOME but parachuted in from outside and sadly stalled. It is close to metacity but it wound up coming with its own set of quirks that exposed new problems in applications.
If you actually look back at the XGL/AIGLX history you will find that it wasn't just Red Hat devs (such as Adam Jackson) who didn't want to adopt it - NVIDIA believed it was the wrong direction as it prevented the hardware exposing certain features. Strangely enough, Ubuntu was probably the first major distro to ship XGL and compiz in a release, much to the chagrin of some in the SUSE community. It is worth noting that KDE didn't adopt compiz as their default window manager either.
The problem with the parent post is that it pointed to a couple of areas where GNOME has accepted "Red Hat outsiders" in, which weakens its argument. Could the situation be less extreme than it painted if such confusion can occur?
(I'm not an MSCE either but I have written program snippets). My vague hand wavy thinking is that it is a difficult problem with a time, money, skill and resources tradeoff. You could:
Reduce the attack surface area by making software small. Software that doesn't open any files, take any parameters or read from the network is more difficult to exploit. However software that doesn't take any input is a bit self defeating. If you feel your software HAS to have complicated input interactions (e.g. an embedded programming language) there may be no easy way of doing this.
Make software that has no bugs or flaws in it. If your software is perfect and its specifications are perfect then there aren't any exploits. This is really hard to do though - it's impossible to show that every single possible program you could write doesn't have any bugs in it. You can go the mathematical route and try to write programs from (proven!) mathematical equations. These should have far fewer bugs but you then have to be sure you got the specification correct in the first place... This is also requires high skill while being expensive and time consuming for even small programs and only becomes more expensive as the program has to grow in size. If your program never makes it market (because it took too long to write or cost too much to make) then you also get no return for your effort.
Try and mitigate damage that could occur. You can write the program so that pieces run in different sandboxes with different privileges/abilities. The hope is that (like compartments on a ship) a hole in one area won't lead to damage in another area. This is expensive in terms of time to write and often requires more resources but it does seem to be the direction that Internet (e.g. web browsers, servers) facing apps are going.
The above also assumes that you don't get done in by software you (the author of the program) didn't write (e.g. the operating system code for drawing a letter has a hole in it and this allows an attacker to then break your program).
Basically non exploitable software is a difficult problem and because writing perfect programs is so hard, damage mitigation with sandboxing is probably the way we will go for now (unless you are writing something life critical etc). The resources to do the sandboxing are higher than without but we are at the stage where it is worth the cost.
[...] an older guy got up and said he thought MacPaint was probably the best program ever written. Was it possible for him to see the source code? It turns out the person asking the question was Don Knuth [...]
Sounds like Bill Atkinson can cite you and Knuth as fans:)
I was at a European conference a week ago and there were quite a few attendees with laptops running some version of openSUSE. A previous UK computer science department I was in also used openSUSE as its distro.
Yes, PAE causes a performance hit (mostly when you have to do over 1Gbyte memory allocations) but another reason to have it on is to enable hardware NX support.
But really, if you have a system capable of 64 bit support it is far better to use that (unless you have extremely special circumstances).
...at least not in its non-XML form (check out the doctype for starters). If you've wanted to cope with your typical "in the wild" web page over at least the past 10 years, you've needed a special HTML parser anyway - SGML wasn't enough.
What HTML5 has tried to do is codify how to recover from errors so hopefully if you do choose to make non-validating HTML5 pages there is a greater chance that all browsers will recover the same way.
...we are going to see a heck of a lot fewer Universities and they are going to be far, far smaller in size. I would find it very hard to justify funding such a system beyond saying anyone who goes can pay for it themselves or the establishment can pay for them. This would make make University the sole preserve of the hyper intelligent and the rich.
It is absolutely true that in some UK departments it is actually the research grants that pull in the majority of the money but if you look far enough, sooner or later it's going to come from taxation. If I was a parent who couldn't afford to send my kids to Uni I may be sorely tempted to say I don't want to fund other people's children to go to Uni either.
It's not the quote you explicitly sought but I would argue it makes it seem like Valve have said something about a Linux port. Regardless, your overall point that the source of information should be scrutinized definitely holds...
My understanding is that the Windows BSD based network TCP/IP stacks (as in the parts routing packets in the kernel rather than userland utilities) were written back in the Windows 3.11 and NT 3.1 days and were 3rd party addons. The core network stack shipped in the box has apparently not been BSD derived (and MS has claimed to have rewritten the stack several times since) - only the userland utilities so there are substantial differences and behaviour (perhaps that's why they fingerprint differently to tools like NMAP?).
There are ALSA drivers that are "nicer"
on
Fedora 13 Is Out
·
· Score: 1
Pulseaudio typically talks to ALSA on Linux and as such what the ALSA driver exposes and how it behaves can influence what happens in Pulseaudio. For example, I remember hearing that there were bugs in the emu10k1 ALSA driver with regard to reading back the current hardware pointer. It is also worth noting that different drivers will be able to report back different levels of information - not all drivers return volume decibel information for example. I can see how different "hardware" could influence the Pulseaudio experience.
Having said that, I don't ever remember seeing a Pulseaudio "hardware compatibility list". Hopefully these days the most egregious issues having been fixed or worked around.
Perhaps you haven't come across it because its usage varies by geography/region/dialect? I'm sure in the UK people use "mooted" periodically - mooted turns up on the BBC site a bit.
I used to run Firefox 3.0 on Ubuntu 8.04 with an ext3 formatted partition on an EeePC 900 with a "1st gen" (read extremely slow writes) SSD. Start up time and general pauses were so agonising I had taken to making a script to copy the profile into RAM and run Firefox there. Chromium on that system was a dramatically faster.
Now having upgraded to Firefox 3.6.3 on Ubuntu 10.04 with an ext4 formatted partition Firefox is much faster. It's hard to tell if the difference is down to ext4 or Firefox but the situation is much improved.
Fair enough - I was only answering the original query which mentioned acroread. Perhaps the okular plugin problem is a different issue - have you tried filing a bug on the Chromium issue database?
It's more like saying saying if ship 1 sinks it won't also sink ship 2 when they are only communicating via radio and sailing parallel to each other with large amounts of water between them (or something). Hmm this analogy seems overstretched...
The plugin isn't running inside the browser any more - it is run in a separate process (like say Excel and Word). Killing Chrome should kill the plugin but the plugin really can be killed via process explorer (or chrome's mini processor explorer) and Chrome continues to run. You can try this for yourself...
That's not to say that there couldn't be flaws in your OS' process isolation or that communication method doesn't have a in it but it's dramatically better in much the same way having an OS with memory protection often prevents one non privileged app killing other apps when it crashes (contrast "normal" app crashes in 3.11 to XP).
Out of process plugins really are a Good Thing in this case.
Javascript used to always be interpreted whereas these days it tends there are various methods to JIT it into native binary instructions with various improvements being added as time progresses. So yes, early implementations were weak compared to what we have today. Just compare how IE8 performs on javascript compared to modern browsers (note IE9 improves things dramatically).
As you pointed out, a software comparison benchmark that changes hardware between comparisions is next to useless so thankfully that's not what's happening:)
Apparently acroread depends on the browser implementing Xt (a really old toolkit) support for its plugins which Chrome/Chromium doesn't do. Further, acroread is 32 bit only on Linux which also acts as a disincentive for devs to work on the issue. You can read the details in the Chromium bug report about why the acroread plugin does not work on Linux.
Hmm that's unfortunate - I can only hope you find a bug in launchpad that matches your problem so at least you will get notice if something promising eventually turns up.
Your only hope is that AMD/ATI track down where the problem lies as they are the ones with the most information to do so. As Ubuntu don't have the source fglrx they are going to wait on AMD/ATI...
Typeracer is an online typing game that can also report your WPM. It doesn't need anything more than a modernish web browser and you can compete against other people. It's no good for learning the fingerings but it's fine if you just need practice typing text.
Embarrassing because I suspect the University in question would rather its advert not appear alongside such a story, as the viewer is likely to view the ad negatively. The advert was not for my alma matters but should that matter?
In my RSS feed for this Slashdot article there was an advert saying "Online Master Degrees, learn more now". Strangely relevant and yet embarrassing at the same time...
To the best of my knowledge, most printer drivers are in CUPS (something similar happens for scanners with SANE) which is userland. There are plenty of USB widgets in the kernel but this seems to be mostly for devices that do no not conform to a standardised USB class (e.g. most usb pens will be handled with the existing mass storage driver).
The majority of Linux kernel changes are to drivers but these are for new hard disk controllers, video cards, wifi cards and so forth. In fact I've just done a quick check on where the changes between 2.6.32 and 2.6.33-rc4 were and it looked like this:
Percentages are cumulative (drivers includes drivers/staging etc) and directories with less than 3% of the changes have been left out. So in this case most of the changes were to wifi driver, the ARM architecture and graphics driver bits.
Slashdot Mirror
I don't think all your examples are good and I believe there is some mis-attribution in there as well. Let's start with the ones that might support your argument. PulseAudio (Lennart Poettering), DeviceKit (David Zeuthen) and gnome-user-share (Alexander Larsson and Bastien Nocera) were all created by Red Hat employees. I would argue that neither Xorg/X, DeviceKit or PulseAudio are part of GNOME even though it runs on top of them. They are really Linux desktop infrastructure and someone's got to develop that...
Compiz was not developed inside GNOME but parachuted in from outside and sadly stalled. It is close to metacity but it wound up coming with its own set of quirks that exposed new problems in applications.
If you actually look back at the XGL/AIGLX history you will find that it wasn't just Red Hat devs (such as Adam Jackson) who didn't want to adopt it - NVIDIA believed it was the wrong direction as it prevented the hardware exposing certain features. Strangely enough, Ubuntu was probably the first major distro to ship XGL and compiz in a release, much to the chagrin of some in the SUSE community. It is worth noting that KDE didn't adopt compiz as their default window manager either.
Clutter was created by employees of a company called Open Handed which was later bought by Intel. I assume you mentioned this as the GNOME 3 gnome-shell window manager will use this library for compositing purposes.
GNOME Cheese was developed by Daniel G. Siegel when he was a student as part of Google's Summer of Code 2007 project and his mentor was Raphaël Slinckx (who currently appears to work for a company called Whatever SA).
The problem with the parent post is that it pointed to a couple of areas where GNOME has accepted "Red Hat outsiders" in, which weakens its argument. Could the situation be less extreme than it painted if such confusion can occur?
(I'm not an MSCE either but I have written program snippets). My vague hand wavy thinking is that it is a difficult problem with a time, money, skill and resources tradeoff. You could:
The above also assumes that you don't get done in by software you (the author of the program) didn't write (e.g. the operating system code for drawing a letter has a hole in it and this allows an attacker to then break your program).
Basically non exploitable software is a difficult problem and because writing perfect programs is so hard, damage mitigation with sandboxing is probably the way we will go for now (unless you are writing something life critical etc). The resources to do the sandboxing are higher than without but we are at the stage where it is worth the cost.
I remember watching a NerdTV interview with Andy Hertzfeld which made mention of MacPaint. Now I've done a search, I've found the transcript of Andy's interview on the web. I'll quote the section I was thinking of:
[...] an older guy got up and said he thought MacPaint was probably the best program ever written. Was it possible for him to see the source code? It turns out the person asking the question was Don Knuth [...]
Sounds like Bill Atkinson can cite you and Knuth as fans :)
I was at a European conference a week ago and there were quite a few attendees with laptops running some version of openSUSE. A previous UK computer science department I was in also used openSUSE as its distro.
Yes, PAE causes a performance hit (mostly when you have to do over 1Gbyte memory allocations) but another reason to have it on is to enable hardware NX support.
But really, if you have a system capable of 64 bit support it is far better to use that (unless you have extremely special circumstances).
WOFF is in Chromium's webkit but seemingly not mainline webkit.
...at least not in its non-XML form (check out the doctype for starters). If you've wanted to cope with your typical "in the wild" web page over at least the past 10 years, you've needed a special HTML parser anyway - SGML wasn't enough.
What HTML5 has tried to do is codify how to recover from errors so hopefully if you do choose to make non-validating HTML5 pages there is a greater chance that all browsers will recover the same way.
...we are going to see a heck of a lot fewer Universities and they are going to be far, far smaller in size. I would find it very hard to justify funding such a system beyond saying anyone who goes can pay for it themselves or the establishment can pay for them. This would make make University the sole preserve of the hyper intelligent and the rich.
It is absolutely true that in some UK departments it is actually the research grants that pull in the majority of the money but if you look far enough, sooner or later it's going to come from taxation. If I was a parent who couldn't afford to send my kids to Uni I may be sorely tempted to say I don't want to fund other people's children to go to Uni either.
"Valve has also confirmed that it will make Steam available to Linux users in the coming months." - telegraph.co.uk (this is on the website of national UK newspaper).
It's not the quote you explicitly sought but I would argue it makes it seem like Valve have said something about a Linux port. Regardless, your overall point that the source of information should be scrutinized definitely holds...
My understanding is that the Windows BSD based network TCP/IP stacks (as in the parts routing packets in the kernel rather than userland utilities) were written back in the Windows 3.11 and NT 3.1 days and were 3rd party addons. The core network stack shipped in the box has apparently not been BSD derived (and MS has claimed to have rewritten the stack several times since) - only the userland utilities so there are substantial differences and behaviour (perhaps that's why they fingerprint differently to tools like NMAP?).
Pulseaudio typically talks to ALSA on Linux and as such what the ALSA driver exposes and how it behaves can influence what happens in Pulseaudio. For example, I remember hearing that there were bugs in the emu10k1 ALSA driver with regard to reading back the current hardware pointer. It is also worth noting that different drivers will be able to report back different levels of information - not all drivers return volume decibel information for example. I can see how different "hardware" could influence the Pulseaudio experience.
Having said that, I don't ever remember seeing a Pulseaudio "hardware compatibility list". Hopefully these days the most egregious issues having been fixed or worked around.
Perhaps you haven't come across it because its usage varies by geography/region/dialect? I'm sure in the UK people use "mooted" periodically - mooted turns up on the BBC site a bit.
I used to run Firefox 3.0 on Ubuntu 8.04 with an ext3 formatted partition on an EeePC 900 with a "1st gen" (read extremely slow writes) SSD. Start up time and general pauses were so agonising I had taken to making a script to copy the profile into RAM and run Firefox there. Chromium on that system was a dramatically faster.
Now having upgraded to Firefox 3.6.3 on Ubuntu 10.04 with an ext4 formatted partition Firefox is much faster. It's hard to tell if the difference is down to ext4 or Firefox but the situation is much improved.
Fair enough - I was only answering the original query which mentioned acroread. Perhaps the okular plugin problem is a different issue - have you tried filing a bug on the Chromium issue database?
It's more like saying saying if ship 1 sinks it won't also sink ship 2 when they are only communicating via radio and sailing parallel to each other with large amounts of water between them (or something). Hmm this analogy seems overstretched...
The plugin isn't running inside the browser any more - it is run in a separate process (like say Excel and Word). Killing Chrome should kill the plugin but the plugin really can be killed via process explorer (or chrome's mini processor explorer) and Chrome continues to run. You can try this for yourself...
That's not to say that there couldn't be flaws in your OS' process isolation or that communication method doesn't have a in it but it's dramatically better in much the same way having an OS with memory protection often prevents one non privileged app killing other apps when it crashes (contrast "normal" app crashes in 3.11 to XP).
Out of process plugins really are a Good Thing in this case.
Javascript used to always be interpreted whereas these days it tends there are various methods to JIT it into native binary instructions with various improvements being added as time progresses. So yes, early implementations were weak compared to what we have today. Just compare how IE8 performs on javascript compared to modern browsers (note IE9 improves things dramatically).
As you pointed out, a software comparison benchmark that changes hardware between comparisions is next to useless so thankfully that's not what's happening :)
Apparently acroread depends on the browser implementing Xt (a really old toolkit) support for its plugins which Chrome/Chromium doesn't do. Further, acroread is 32 bit only on Linux which also acts as a disincentive for devs to work on the issue. You can read the details in the Chromium bug report about why the acroread plugin does not work on Linux.
Hmm that's unfortunate - I can only hope you find a bug in launchpad that matches your problem so at least you will get notice if something promising eventually turns up.
Your only hope is that AMD/ATI track down where the problem lies as they are the ones with the most information to do so. As Ubuntu don't have the source fglrx they are going to wait on AMD/ATI...
https://launchpad.net/ubuntu/lucid/+source/fglrx-installer/+changelog (2:8.721-0ubuntu1) says a working package of flgrx for lucid was released on the 17th March. Also see https://bugs.launchpad.net/ubuntu/+source/fglrx-installer/+bug/494699 . Is this version not working for you?
Typeracer is an online typing game that can also report your WPM. It doesn't need anything more than a modernish web browser and you can compete against other people. It's no good for learning the fingerings but it's fine if you just need practice typing text.
There is an excellent thread talking about how recent (2.6.31+) linux kernels try to report the underlying hard drive architecture (found via the OSNews comments). Alas, it looks like some of these drives are not reporting this data correctly and thus automatic adjustment (at partitioning time) is not taking place. It looks like in the future rather than trying to do detection by reported capability fdisk (and hopefully gparted) will default to sectors of 1MiB if the topology can't be found by default (unless your media is small).
Additionally, I gather that recent Fedoras will try to adjust things like LVM to match larger sectors too. Hopefully whatever is laying out LVM will also be fixed too.
Coincidentally, it looks like Oracle have a very committed dev trying to make this stuff work by default...
Embarrassing because I suspect the University in question would rather its advert not appear alongside such a story, as the viewer is likely to view the ad negatively. The advert was not for my alma matters but should that matter?
In my RSS feed for this Slashdot article there was an advert saying "Online Master Degrees, learn more now". Strangely relevant and yet embarrassing at the same time...
To the best of my knowledge, most printer drivers are in CUPS (something similar happens for scanners with SANE) which is userland. There are plenty of USB widgets in the kernel but this seems to be mostly for devices that do no not conform to a standardised USB class (e.g. most usb pens will be handled with the existing mass storage driver).
The majority of Linux kernel changes are to drivers but these are for new hard disk controllers, video cards, wifi cards and so forth. In fact I've just done a quick check on where the changes between 2.6.32 and 2.6.33-rc4 were and it looked like this:
9.0% arch/arm/
16.7% arch/
3.2% drivers/gpu/drm/nouveau/
5.2% drivers/gpu/drm/
4.0% drivers/media/
4.5% drivers/net/wireless/
8.1% drivers/net/
3.6% drivers/staging/rt2860/common/
7.4% drivers/staging/rt2860/
4.3% drivers/staging/rt3090/common/
9.4% drivers/staging/rt3090/
4.5% drivers/staging/rtl8192u/
8.5% drivers/staging/wlags49_h2/
35.2% drivers/staging/
66.1% drivers/
6.1% firmware/
Percentages are cumulative (drivers includes drivers/staging etc) and directories with less than 3% of the changes have been left out. So in this case most of the changes were to wifi driver, the ARM architecture and graphics driver bits.
A Mozilla developer has pointed out several drawbacks of using Directshow for HTML5 video. Among them was that some Directshow codecs are of questionable quality, it can be source of security bugs and would mean a different backend for every supported platform.
The Opera folks have said Directshow is not well geared to streaming videos so Opera has gone with a minimal gstreamer port for HTML5 video.