Home Messages Index
[Date Prev][Date Next][Thread Prev][Thread Next]
Author IndexDate IndexThread Index

Re: [News] Proprietary Drivers Leave Vista/Windows Behind (in 32-bit World), Less Secure

  • Subject: Re: [News] Proprietary Drivers Leave Vista/Windows Behind (in 32-bit World), Less Secure
  • From: "[H]omer" <spam@xxxxxxx>
  • Date: Sun, 05 Aug 2007 18:06:44 +0100
  • Bytes: 5941
  • In-reply-to: <1256860.7sF0geIfvX@xxxxxxxxxxxxxxx>
  • Newsgroups: comp.os.linux.advocacy
  • Openpgp: id=BF436EC9; url=http://slated.org/files/GPG-KEY-SLATED.asc
  • Organization: Slated.org
  • References: <1256860.7sF0geIfvX@xxxxxxxxxxxxxxx>
  • User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.8.1.5) Gecko/20070720 Remi/2.0.0.5-1.fc6.remi Thunderbird/2.0.0.5 Mnenhy/0.7.5.666
  • Xref: ellandroad.demon.co.uk comp.os.linux.advocacy:548466
Verily I say unto thee, that Roy Schestowitz spake thusly:

> 64-bit PCs: Drivers wanted

The woeful lack of 64-bit proprietary drivers (or even 32-bit drivers on
Vista, for that matter) is only the tip of the iceberg. With proprietary
software, 64-bit support is practically non-existent. This is shameful
for an architecture that's been around exactly seven years (this month).

It's uncanny that you should post this now, since I've just finished a
little experiment; Proprietary Vs Free software (64-bit support), on
Fedora 6. Here's what I found:

ATI (AMD) Graphics: The Free radeon module is available for whatever
architecture is supported by the kernel and X.org, in this case it
*does* support 64-bit. The proprietary driver (fglrx) package (Livna
RPM) is a mix of 64-bit and 32-bit components, since certain closed
source blobs have *not* been built multi-arch by ATI/AMD (i386 only),
including /usr/bin/amdcccle (Catalyst Control Center). This has the
effect of "pulling" a slew of otherwise totally unnecessary 32-bit
dependencies, on a system that was previously "64-bit clean". Pathetic.

I should also point out that the proprietary fglrx simply didn't work
*at all* with the latest X.org, and left e.g. Fedora 7 proprietary
driver fanbois waiting *two months* before a working fix came from
upstream at AMD.

Flash: Adobe (né Macromedia) Flash is *still* not 64-bit compatible,
even after all these years. Solution - use a 32-bit browser or switch to
the Free Gnash plugin. Guess which I chose. Apparently the Free software
community can achieve something that a huge mega-corporation like Adobe
finds too difficult. Again, using the 32-bit version of Firefox on a
64-bit system, pulls in a vast number of 32-bit deps. Totally
unnecessary bloat.

Java: It's is truly unbelievable that Sun Micro can somehow manage to
build the huge Java JRE/SDK codebase to x86_64, but spectacularly fail
to build a tiny 134Kb plugin (libjavaplugin_oji.so) to 64-bit. The
reason, apparently, is not even a technical one (naturally), but is
politically motivated. Specifically Sun stated that the reason they
omitted this single tiny file from the vast build, is that Mozilla do
not ship a 64-bit version of Firefox upstream. The fact that virtually
*all* GNU/Linux users obtain Firefox (and all their other packages)
*downstream* from their vendor's repos, is a fact that seems to have
completely escaped the rather ignorant Sun. Solution: use the Free GNU
libgcj, which *is* available in a 64-bit build. I was pleasantly
surprised to discover that not only is there a browser plugin available,
and that it works well, but in fact it worked on an applet that I never
could get to work with proprietary Java on GNU/Linux:

http://www.thinkbroadband.com/speedtest.html

With Sun's Java 1.5, it just sat there doing nothing. For the first time
I can actually use this applet.

Other examples: Google Desktop (i386 only), GoogleEarth (i386 only),
Acronis TrueImage (i686 only), Adobe Reader (né Acrobat) (i386 only),
Opera Browser (i386 only), etc., etc. The list goes on and on.

And the overall result of me "needing" these ridiculously "i386 only"
packages:

~]# ix86_pkgs=$(rpm -qa --qf "%{arch}\n" | grep "i.86" | wc -l);
all_pkgs=$(rpm -qa | wc -l); pc=$(echo "scale=2; ${ix86_pkgs} * 100 /
${all_pkgs}" | bc); echo; echo "Total packages  : ${all_pkgs}"; echo
"ix86 packages   :  ${ix86_pkgs}"; echo "ix86 percentage : ${pc}%"; echo

Total packages  : 1248
ix86 packages   :  134
ix86 percentage : 10.73%

More than 10% of my system, needlessly wasted.

However, with Windows, I'd fully expect these numbers to be reversed. In
fact I doubt if any Windows user could even achieve anywhere near 10%
64-bit support from their applications.

64-bit support for proprietary software is pitiful, and yet the Free
Software Community, with virtually no financial resources, somehow
manages near 100% multi-arch support.

Take a good look at the architectures supported by the Debian distro alone:

http://www.debian.org/ports/

And uClinux (for embedded systems):

http://www.uclinux.org/ports/

So, what good is proprietary software, when it won't work on your
hardware ... or will work, but only with great difficulty and by
unnecessarily bloating the system?

Food for thought, for the proprietary software fanbois.

-- 
K.
http://slated.org

.----
| "Proprietary licenses, the crack cocaine of software finance."
|  - Matt Asay, CNET
`----

Fedora release 7 (Moonshine) on sky, running kernel 2.6.21-1.3194.fc7
 18:04:58 up 6 days,  3:20,  2 users,  load average: 1.39, 1.50, 1.54

[Date Prev][Date Next][Thread Prev][Thread Next]
Author IndexDate IndexThread Index