One thing that disappoints me about current UEFI motherboards is that you still need to have certain files at certain locations on your primary hard disk. Specifically my new EFI based system required me to partition my hard drive so that there is an EFI System partition.
This EFI System partition is a variant of the FAT file system that contains the EFI bootloader. When i heard of EFI i assumed there'd be a bit of flash on the motherboard to store the EFI bootloader and applications. I hoped the BIOS itself would be able to contain the driver for whatever filesystem i was currently using in its flash. I was hoping that EFI would make it so i could avoid having bootloaders on a specific drive thus making it possible to add or remove drives as wanted without having to worry about which drive contained the bootloader. Unfortunately this isn't the case. Your harddrive will still require certain sectors to contain certain files. There is still such a thing as a system partition. In fact it now requires you to pollute your hard drive with a special FAT based partition.
Essentially EFI has the same hack that traditional BIOS has in that a bootloader needs to be stored at sector 0 of the first drive (but in this case an EFI system partition in your partition table). When i heard about UEFI i hoped that there would be a way to load a filesystem driver directly into the flash of the BIOS so that i could layout whatever filesystem i had in whatever way i wanted. There isn't. Things on your hard drive must be set up in a specific way. Hopefully in the future motherboard manufacturers will include some flash on the motherboard setup as the EFI system partition but in the meantime you'll have to format one of your hard drive partitions as the system partition. Just like you do with traditional BIOS.
There's a function that helps avoid exploitation of the vulnerabilities in the API. developer.android.com/reference/android/app/ActivityManager.html#isUserAMonkey%28%29
Just ensure that it's returning false and you should be safe.
I've seen that too and I've always wondered if that isn't the real reason we are getting near impossible captchas these days. Some admin probably sees lots of bots getting past the captcha filter and instead of realising it's humans doing the work decides to make the captcha more and more difficult.
Some of the captchas go so far beyond a turing test this seems like the most plausible explanation. The current captchas can surely be toned down a bit in difficulty and still be impossible for state of the art ai to interpret. The ability to get humans to do the dirty work is another issue which can probably be solved with some simple text on each captcha stating what the captcha is for.
Jet engines are typically quieter per unit of power than internal combustion engines. eg. They call the turbine powered M1A1 whispering death because it is so silent compared to other tanks.
I wish they'd start putting the "P" into these Big-O notations, where the "P" is the number of processors. Some algorithms don't scale well, some do. Putting the P in illustrates this.
eg. O( n/P ) illustrates an algorithm that scales perfectly with more cores added. O( n / log(P) ) not so much.
You're forgetting the worst thing Blizzard is currently doing. Region locking. Someone with a US copy of SC2 simply cannot play with a friend in Europe as each copy is region locked to one online server. It's destroying the international pro-gaming scene which is what Starcraft is meant to be all about.
The reason they do this region locking isn't to prevent piracy either. It's so they can charge a different price in different regions. Maximising short term profits at the expense of pro-players support.
Actually all proper tests of compression add the decompression executable+dictionaries to the measured size of the final compressed file. So you can't cheat this way and say it can be compressed to 1 bit. You have to include the executable and dictionaries to that size.
Using a perfect compressor would give a value of the raw information content of a system. I'd assume this is what he is getting at. The raw information content of the genetic bootloader that interacts with the environment to create a human. It's a rough estimate he is giving.
Note: A perfect compressor doesn't exist yet and in fact such a thing mathematically implies a perfect artificial intelligence anyway -see Marcus Hutters papers on this topic. So measuring the raw bytes it takes to build a brain after using a perfect compressor is rather pointless. A perfect compression algorithm itself is already a perfect intelligence (it can predict the future and take action to achieve a future desired outcome).
The thing is if they say they wipe it rather than just encrypt it, it still changes how people use it. If someone stores a document on these drives that must never be decrypted/recovered even in 50 years they might be in a shock if quantum computers come out and are able to decrypt the drive they thought was erased.
People currently using AES on the other hand generally know that one day AES might be cracked by quantum computing. They don't rely on it for data that must never be revealed even in 50 years. If people look at Toshibas claims on these drives they might assume it's ok to store such documents on it, believing it will actually be wiped rather than just stored in an encrypted way.
Yes, it is a way of thinking but that's a reason it should be taught. Even if they are a non-techie and never going to become a programmer there's still merit in teaching them a new way of thinking. Anyone can learn the basics and as most programming books illustrate it's really no different than creating a recipe. So it really is a good idea to teach people the basics of programming. Especially in this case where people are asking to be taught.
Google Chrome offered to translate the pages in question. After translation it looks cleaner. I stopped looking at the characters as a mess of intelligible symbols but instead as words that i understood.
There are so many reasons why that can happen though. One of the first things i think of is that your program works well with the cache line size of the G4 (32bytes, i think) whereas the Core 2 is loading up more than it needs when it loads each new cache line (256bytes, i think). You'll probably find if you make even the slightest changes to the data structure size or alignment in the program the benchmarks will switch around.
In the end CPUs have to be general and there is no doubt that in general the current x86s are faster. If you find the G4 is faster for you well then i say keep using it. It's an exceptional circumstance that you happen to have where your code closely matches the design of the G4.
When i hear the line "hardware trojans' long posited by some security experts are indeed a real threat" all i can think is no shit, it was already done years ago. http://en.wikipedia.org/wiki/CIH_(computer_virus)
CIH spread and infected the BIOS itself rather than just the filesystem. It was shipped out on a bunch of Yamaha CD drives and the IBM Aptivas had it.
I figure the opposite. It's offensive not defensive. Aircraft carrier fleets are an offensive weapon and tools to defend them are part of that offensive capability, even if the tool on its own is defensive. Having missile interception ensures the US has an option to attack Chinese/Iranian/Russian assets with its carrier force if it wants to.
Yes. All low level devices are wired to the CPU by the memory bus. Writing data to a PCI card is simply a matter of writing to a certain memory address. The PCI card will see a specific address on the memory address bus and know the data on the data bus is intended for it. It's not like x86 CPUs have one bus for devices and one for memory.
There were reports of stuck accelerators here in Australia for a while but it was the Fords not Toyotas. Basically some guy rang police up on the freeway and claimed his cruise control was stuck at 80. There was a police chase/escort and eventually he was stopped. Soon after the incident there was a ton of idiots all ringing up talkback radio for days on end claiming the same thing happened to them in their Fords and that's why they crashed or got a speeding fine.
In the end the real storey started circulating. The guy who initially made the claim seemed to have issues. During the chase the police asked him to brake and he said it didn't work. They then asked him to change gear to neutral and he claimed it had no effect. They asked him to turn the key on a car with an old fashion manual key and he claimed that didn't work. His car was inspected afterwards and no fault was found. In the end the reports of problems quickly disappeared. All the bandwagon jumpers suddenly shut the hell up. http://news.drive.com.au/drive/motor-news/no-sign-of-cruisecontrol-faults-20100107-lwrq.html
"it was certainly a matter of one window with unix source to read from, the other window with linux source to write" Hell no. That's a bullshit accusation.
Here we likely have a programmer who has never seen the SCO code (was it even released publicly back then?) but knows that applications can call functionY from libraryX from the interface documentation. If he creates a new libraryX containing a compatible functionY he isn't violating copyright. It is established that creating code with a compatible API interface isn't a copyright violation unless you actually do copy the code. Indeed it appears this is exactly what is happening in the linked elflib files. The filenames are the same because they have to be (note both the redhat_libelf.h and SCO_libelf.h are actually referred to by just libelf.h in code and elflib.h is what applications need to link to) and the functions are the same because they have to be or else applications will be calling functions that don't exist.
This also happens with the WINE project. People there are creating the same header filenames and inside those headers the exact same function names. They aren't working off a split screen setup and blatantly copying Microsofts closed source code. They are merely recreating the functions that applications can call in Windows.
A similar thing happened years ago with Compaqs IBM compatible BIOS. Compaq re-created the IBM BIOS to get around having to buy the IBM BIOS. Both BIOSes responded to the same application calls in the same way with the same return values and messages. Despite this Compaq didn't break copyright because they still re-wrote the code. In fact Compaq hired engineers specifically for the fact they had never seen IBM BIOS code. This way it could be easily established that they didn't copy the code but instead just wrote the same code that performed the same task.
It's not even that. It's plain old rewriting a library to remain compatible. Here's an example of some end-user programs that use those very enumerations. The ELF_Type enumeration is used on page 37 in an end user application and ELF_T_WORD value is assigned to it on page 45. http://elftoolchain.sourceforge.net/for-review/libelf-by-example-20100112.pdf
There's no coincidence involved. If you write applications that use the ELF_Type enumeration and you decided to write a new elf library to support that app you'd end up having the same enumeration names to maintain compatibility.
Copyright allows you to recreate something that's compatible as long as it isn't copied directly.
No, read the POSIX interface standard (or in this case specifically the ELF executable standard). You have to give your functions certain names to be compliant to the specification. The code shown is interface code, the implementation is somewhere else. Interface code simply names the functions, parameters and variables. As the functions must have certain names and parameters to fit the standard you will get the exact same line that declares a function. Any C programmer could recreate that same block of code with just a list of functions names and parameters that must be declared.
eg. If you have to have a global function called elf_version with return of unsigned int and parameter of the version you'll get the line extern unsigned in elf_version( unsigned int __version );
We see that same line of code in both files as they both implement the same specification. I'm sure there's a ton of other UNIXes out there that have the same line of code.
Which explains why the N900 and Nokia in general does so poorly in the US. I imagine US carriers would never support a phone that can be a WAP, can do tethering and has VOIP support. Tethering has always pissed off the carriers and VOIP avoids the call rates. Even the android is often locked down by carriers to (try) and prevent these things.
US carriers won't sell something they can't lock down. Europeans on the other hand more often than not buy their phones from retail chains contract free, so the carriers don't get a say in the features.
The problem is you can't sell a phone like the N900 via carriers. The N900 can act as a WAP and it fully supports tethering. It has the best wifi VOIP support ever, when you get into range of a known wifi access point the phone auto logs in and starts receiving SIP, Skype and MSN calls, messages and video calls as if they were standard phone calls. Email support for it works in a similar way.
You can't disable these features either. The Maemo OS is just raw Linux with a great phone application.
Personally i don't think the OVI store should even exist. It's a minor part of the phone and it just gives people an excuse to say "Hey look at this OVI store thing, it's crap, it's nowhere near as good as the iPhone app store". Well this isn't an iPhone. The store application isn't how we N900 users get applications for it. It's an open phone and it has this great thing called the App Manager which is a graphical repository browser. It's better than any store on any phone.
The in-built N900 App Manager application has thousands of great apps available, some commercial some free (the commericial ones upon installing will usually ask for payment after install in typical shareware tradition). It has a great interface, easy to navigate and handles installation and updating of the apps well (as you'd expect from an apt front-end).
Do the iPhone or Android stores have all the major emulators available (ScummVM, DosBox, SNES, MAME, etc.)? Do they have apps to run the phone as a WAP? Do they even have apps to provide simple tethering? Perhaps an app to allow sound output via the FM transmitter? Or are the iPhones and Androids stores so locked down by the providers that they can't do these things?
I agree the OVI store is junk. So don't use it. Use the inbuilt app manager. With the app manager you can install all of those things I've mentioned and more with a tap of the screen.
"things like double tap to fully justify a column of text in a webpage" That's a very specific thing to be complaining about. I'm not even sure what you are getting at. Double tapping on the n900s browser zooms out the page (to the equivalent of being a 1280 width screen i believe). Double tapping again zooms in on that region. It's very intuitive and quick. It's not what you're describing but it seems to achieve the same goal; Web pages are easily viewable on the n900. You can also install n900 versions of Firefox, Chromium or Opera if you don't like the default browser on the n900. So i don't see what you are getting at here.
As for the app store it's really just a repository, don't use the OVI store browser as that's redundant, use the App manager to browse for apps. You click app manager on the phone and you get a list of programs available from the repositories (including the commercial OVI store repository). Mame, SNES and Megadrive emulators, OpenSSH, ftpd, all the tux games, programs to turn you phone into a wireless access point, VOIP apps, all the major linux apps etc. are all downloadable from these official repositories. The n900's a full Linux system and the huge number of apps for the n900 reflects this. I don't understand how you think there aren't many apps available. All i can think is that the official developer and extras repositories weren't added to the app manager and you browsed nothing more than the OVI store. Nokia open their phones so that there isn't one source of apps for the device, make sure you add the other well known sources. Note that's also why you never here about how Nokia killed app X for their phone. They aren't Apple. They couldn't stop a competing source of apps for their phones even if they wanted to and the OVI store is a small part of the ecosystem.
Slashdot Mirror
One thing that disappoints me about current UEFI motherboards is that you still need to have certain files at certain locations on your primary hard disk. Specifically my new EFI based system required me to partition my hard drive so that there is an EFI System partition.
http://en.wikipedia.org/wiki/EFI_System_partition
This EFI System partition is a variant of the FAT file system that contains the EFI bootloader. When i heard of EFI i assumed there'd be a bit of flash on the motherboard to store the EFI bootloader and applications. I hoped the BIOS itself would be able to contain the driver for whatever filesystem i was currently using in its flash. I was hoping that EFI would make it so i could avoid having bootloaders on a specific drive thus making it possible to add or remove drives as wanted without having to worry about which drive contained the bootloader. Unfortunately this isn't the case. Your harddrive will still require certain sectors to contain certain files. There is still such a thing as a system partition. In fact it now requires you to pollute your hard drive with a special FAT based partition.
Essentially EFI has the same hack that traditional BIOS has in that a bootloader needs to be stored at sector 0 of the first drive (but in this case an EFI system partition in your partition table). When i heard about UEFI i hoped that there would be a way to load a filesystem driver directly into the flash of the BIOS so that i could layout whatever filesystem i had in whatever way i wanted. There isn't. Things on your hard drive must be set up in a specific way. Hopefully in the future motherboard manufacturers will include some flash on the motherboard setup as the EFI system partition but in the meantime you'll have to format one of your hard drive partitions as the system partition. Just like you do with traditional BIOS.
There's a function that helps avoid exploitation of the vulnerabilities in the API.
developer.android.com/reference/android/app/ActivityManager.html#isUserAMonkey%28%29
Just ensure that it's returning false and you should be safe.
I've seen that too and I've always wondered if that isn't the real reason we are getting near impossible captchas these days. Some admin probably sees lots of bots getting past the captcha filter and instead of realising it's humans doing the work decides to make the captcha more and more difficult.
Some of the captchas go so far beyond a turing test this seems like the most plausible explanation. The current captchas can surely be toned down a bit in difficulty and still be impossible for state of the art ai to interpret. The ability to get humans to do the dirty work is another issue which can probably be solved with some simple text on each captcha stating what the captcha is for.
Jet engines are typically quieter per unit of power than internal combustion engines. eg. They call the turbine powered M1A1 whispering death because it is so silent compared to other tanks.
I wish they'd start putting the "P" into these Big-O notations, where the "P" is the number of processors. Some algorithms don't scale well, some do. Putting the P in illustrates this.
eg. O( n/P ) illustrates an algorithm that scales perfectly with more cores added. O( n / log(P) ) not so much.
You're forgetting the worst thing Blizzard is currently doing. Region locking. Someone with a US copy of SC2 simply cannot play with a friend in Europe as each copy is region locked to one online server. It's destroying the international pro-gaming scene which is what Starcraft is meant to be all about.
The reason they do this region locking isn't to prevent piracy either. It's so they can charge a different price in different regions. Maximising short term profits at the expense of pro-players support.
Actually all proper tests of compression add the decompression executable+dictionaries to the measured size of the final compressed file. So you can't cheat this way and say it can be compressed to 1 bit. You have to include the executable and dictionaries to that size.
Using a perfect compressor would give a value of the raw information content of a system. I'd assume this is what he is getting at. The raw information content of the genetic bootloader that interacts with the environment to create a human. It's a rough estimate he is giving.
Note: A perfect compressor doesn't exist yet and in fact such a thing mathematically implies a perfect artificial intelligence anyway -see Marcus Hutters papers on this topic. So measuring the raw bytes it takes to build a brain after using a perfect compressor is rather pointless. A perfect compression algorithm itself is already a perfect intelligence (it can predict the future and take action to achieve a future desired outcome).
Just like I want great looks and and great sex from a girl.
I've always just wanted a living, human female.
But hey, 2 out of 3 aint bad right?
The thing is if they say they wipe it rather than just encrypt it, it still changes how people use it. If someone stores a document on these drives that must never be decrypted/recovered even in 50 years they might be in a shock if quantum computers come out and are able to decrypt the drive they thought was erased.
People currently using AES on the other hand generally know that one day AES might be cracked by quantum computing. They don't rely on it for data that must never be revealed even in 50 years. If people look at Toshibas claims on these drives they might assume it's ok to store such documents on it, believing it will actually be wiped rather than just stored in an encrypted way.
Yes, it is a way of thinking but that's a reason it should be taught. Even if they are a non-techie and never going to become a programmer there's still merit in teaching them a new way of thinking. Anyone can learn the basics and as most programming books illustrate it's really no different than creating a recipe. So it really is a good idea to teach people the basics of programming.
Especially in this case where people are asking to be taught.
Google Chrome offered to translate the pages in question.
After translation it looks cleaner. I stopped looking at the characters as a mess of intelligible symbols but instead as words that i understood.
Here's a great example of the effect in reverse.
http://slashdot.jp/
So they're the exact opposite of the fundamentalists?
They have my vote then.
There are so many reasons why that can happen though. One of the first things i think of is that your program works well with the cache line size of the G4 (32bytes, i think) whereas the Core 2 is loading up more than it needs when it loads each new cache line (256bytes, i think).
You'll probably find if you make even the slightest changes to the data structure size or alignment in the program the benchmarks will switch around.
In the end CPUs have to be general and there is no doubt that in general the current x86s are faster. If you find the G4 is faster for you well then i say keep using it. It's an exceptional circumstance that you happen to have where your code closely matches the design of the G4.
When i hear the line "hardware trojans' long posited by some security experts are indeed a real threat" all i can think is no shit, it was already done years ago.
http://en.wikipedia.org/wiki/CIH_(computer_virus)
CIH spread and infected the BIOS itself rather than just the filesystem. It was shipped out on a bunch of Yamaha CD drives and the IBM Aptivas had it.
I figure the opposite. It's offensive not defensive.
Aircraft carrier fleets are an offensive weapon and tools to defend them are part of that offensive capability, even if the tool on its own is defensive. Having missile interception ensures the US has an option to attack Chinese/Iranian/Russian assets with its carrier force if it wants to.
Yes. All low level devices are wired to the CPU by the memory bus. Writing data to a PCI card is simply a matter of writing to a certain memory address. The PCI card will see a specific address on the memory address bus and know the data on the data bus is intended for it.
It's not like x86 CPUs have one bus for devices and one for memory.
There were reports of stuck accelerators here in Australia for a while but it was the Fords not Toyotas.
Basically some guy rang police up on the freeway and claimed his cruise control was stuck at 80. There was a police chase/escort and eventually he was stopped. Soon after the incident there was a ton of idiots all ringing up talkback radio for days on end claiming the same thing happened to them in their Fords and that's why they crashed or got a speeding fine.
In the end the real storey started circulating. The guy who initially made the claim seemed to have issues. During the chase the police asked him to brake and he said it didn't work. They then asked him to change gear to neutral and he claimed it had no effect. They asked him to turn the key on a car with an old fashion manual key and he claimed that didn't work. His car was inspected afterwards and no fault was found.
In the end the reports of problems quickly disappeared. All the bandwagon jumpers suddenly shut the hell up.
http://news.drive.com.au/drive/motor-news/no-sign-of-cruisecontrol-faults-20100107-lwrq.html
"it was certainly a matter of one window with unix source to read from, the other window with linux source to write"
Hell no. That's a bullshit accusation.
Here we likely have a programmer who has never seen the SCO code (was it even released publicly back then?) but knows that applications can call functionY from libraryX from the interface documentation. If he creates a new libraryX containing a compatible functionY he isn't violating copyright. It is established that creating code with a compatible API interface isn't a copyright violation unless you actually do copy the code.
Indeed it appears this is exactly what is happening in the linked elflib files. The filenames are the same because they have to be (note both the redhat_libelf.h and SCO_libelf.h are actually referred to by just libelf.h in code and elflib.h is what applications need to link to) and the functions are the same because they have to be or else applications will be calling functions that don't exist.
This also happens with the WINE project. People there are creating the same header filenames and inside those headers the exact same function names. They aren't working off a split screen setup and blatantly copying Microsofts closed source code. They are merely recreating the functions that applications can call in Windows.
A similar thing happened years ago with Compaqs IBM compatible BIOS. Compaq re-created the IBM BIOS to get around having to buy the IBM BIOS. Both BIOSes responded to the same application calls in the same way with the same return values and messages. Despite this Compaq didn't break copyright because they still re-wrote the code. In fact Compaq hired engineers specifically for the fact they had never seen IBM BIOS code. This way it could be easily established that they didn't copy the code but instead just wrote the same code that performed the same task.
It's not even that. It's plain old rewriting a library to remain compatible.
Here's an example of some end-user programs that use those very enumerations. The ELF_Type enumeration is used on page 37 in an end user application and ELF_T_WORD value is assigned to it on page 45.
http://elftoolchain.sourceforge.net/for-review/libelf-by-example-20100112.pdf
There's no coincidence involved. If you write applications that use the ELF_Type enumeration and you decided to write a new elf library to support that app you'd end up having the same enumeration names to maintain compatibility.
Copyright allows you to recreate something that's compatible as long as it isn't copied directly.
No, read the POSIX interface standard (or in this case specifically the ELF executable standard).
You have to give your functions certain names to be compliant to the specification. The code shown is interface code, the implementation is somewhere else. Interface code simply names the functions, parameters and variables. As the functions must have certain names and parameters to fit the standard you will get the exact same line that declares a function. Any C programmer could recreate that same block of code with just a list of functions names and parameters that must be declared.
eg. If you have to have a global function called elf_version with return of unsigned int and parameter of the version you'll get the line
extern unsigned in elf_version( unsigned int __version );
We see that same line of code in both files as they both implement the same specification. I'm sure there's a ton of other UNIXes out there that have the same line of code.
Which explains why the N900 and Nokia in general does so poorly in the US. I imagine US carriers would never support a phone that can be a WAP, can do tethering and has VOIP support. Tethering has always pissed off the carriers and VOIP avoids the call rates. Even the android is often locked down by carriers to (try) and prevent these things.
US carriers won't sell something they can't lock down. Europeans on the other hand more often than not buy their phones from retail chains contract free, so the carriers don't get a say in the features.
Just to clarify the point i'm making here;
Carriers don't like phone companies that actively screw the carriers.
The problem is you can't sell a phone like the N900 via carriers. The N900 can act as a WAP and it fully supports tethering. It has the best wifi VOIP support ever, when you get into range of a known wifi access point the phone auto logs in and starts receiving SIP, Skype and MSN calls, messages and video calls as if they were standard phone calls. Email support for it works in a similar way.
You can't disable these features either. The Maemo OS is just raw Linux with a great phone application.
Personally i don't think the OVI store should even exist. It's a minor part of the phone and it just gives people an excuse to say "Hey look at this OVI store thing, it's crap, it's nowhere near as good as the iPhone app store". Well this isn't an iPhone. The store application isn't how we N900 users get applications for it. It's an open phone and it has this great thing called the App Manager which is a graphical repository browser. It's better than any store on any phone.
The in-built N900 App Manager application has thousands of great apps available, some commercial some free (the commericial ones upon installing will usually ask for payment after install in typical shareware tradition). It has a great interface, easy to navigate and handles installation and updating of the apps well (as you'd expect from an apt front-end).
Do the iPhone or Android stores have all the major emulators available (ScummVM, DosBox, SNES, MAME, etc.)? Do they have apps to run the phone as a WAP? Do they even have apps to provide simple tethering? Perhaps an app to allow sound output via the FM transmitter?
Or are the iPhones and Androids stores so locked down by the providers that they can't do these things?
I agree the OVI store is junk. So don't use it. Use the inbuilt app manager. With the app manager you can install all of those things I've mentioned and more with a tap of the screen.
"things like double tap to fully justify a column of text in a webpage"
That's a very specific thing to be complaining about. I'm not even sure what you are getting at. Double tapping on the n900s browser zooms out the page (to the equivalent of being a 1280 width screen i believe). Double tapping again zooms in on that region. It's very intuitive and quick.
It's not what you're describing but it seems to achieve the same goal; Web pages are easily viewable on the n900. You can also install n900 versions of Firefox, Chromium or Opera if you don't like the default browser on the n900. So i don't see what you are getting at here.
As for the app store it's really just a repository, don't use the OVI store browser as that's redundant, use the App manager to browse for apps. You click app manager on the phone and you get a list of programs available from the repositories (including the commercial OVI store repository). Mame, SNES and Megadrive emulators, OpenSSH, ftpd, all the tux games, programs to turn you phone into a wireless access point, VOIP apps, all the major linux apps etc. are all downloadable from these official repositories. The n900's a full Linux system and the huge number of apps for the n900 reflects this.
I don't understand how you think there aren't many apps available. All i can think is that the official developer and extras repositories weren't added to the app manager and you browsed nothing more than the OVI store. Nokia open their phones so that there isn't one source of apps for the device, make sure you add the other well known sources. Note that's also why you never here about how Nokia killed app X for their phone. They aren't Apple. They couldn't stop a competing source of apps for their phones even if they wanted to and the OVI store is a small part of the ecosystem.
Here's some extra sources for n900 apps. Click these on your phone to add them to the App manager. The first link, the extras, is especially important as it's official and has a huge list of great apps with seemingly all the major linux apps represented. The rest i've linked here are a bit more specific and some are for beta version applications. But even if you just add the extras repository you should be giving the Android a run for it's money in the amount and quality of the applications available.
http://repository.maemo.org/extras/
http://repository.maemo.org/extras-testing/
http://repository.maemo.org/extras-devel/
http://my-maemo.com/repository/
ftp://ftp.mozilla.org/pub/mozilla.org/mobile
http://www.amsn-project.net/maemo
http://b-man.xceleo.org/repo/maemo-nintendo-emulators/
http://qole.org/repository