Also unlike Windows, 64-bit Leopard will happily run all 32-bit applications and device drivers, and it's all run native and not using translation.
Running 32-bit and 64-bit applications side by side on a 64-bit OS is easy, I do it frequently. I highly doubt that you will be able to use 32-bit device drivers natively with a 64-bit kernel though, do you have any evidence to back that claim up?
As a Linux user, I once considered getting an Apple laptop after Lenovo took over the Thinkpad line, in the case that Lenovo wasn't able to carry on the line satisfactorily. That consideration lasted until I found out that all Apple laptops have no useful pointing devices. While the single mouse button may not be a big deal for a desktop where you can simply replace the defective mouse with a real mouse, you can't fix the laptop without voiding your warranty.
So no, the kludge (which doesn't even cover a third button) you mention does not mean it's OK to design defective hardware.
Indeed, consumer hardware in general is held back by Windows and it's countless deficiencies. With memory for example, you basically can't use more than 2G of RAM with consumer level hardware because a) Windows still has miserable 64-bit support and b) Windows scales very poorly with more RAM anyways. So even those of us that aren't directly crippled by Windows, still have to put up with underdeveloped hardware.
Gzip is sufficiently fast that I suspect in most cases it's more limited by your hard drive speed than your CPU speed. There is however, parallel bzip2, which most certainly does benefit from parallelism.
IE is part of your Windows system, like it or not. You can say "don't browse the web with IE", but you CAN'T completely avoid it on a Windows system without real difficulties. IE 6 is completely integrated into your system. Hopefully IE 7 is better. In ANY case, a system level upgrade on a functioning Windows box is nothing to take lightly.
You assume that we have a Windows system in the first place.
You get the benefit of haveing all the os threading be done on the other core so even single threaded apps will see a benefit next to a single core system at the same speed.
While this is a popular belief, it's not really applicable. The OS is doing just about nothing while you're playing a game and the 0.1% speedup you might have gotten from this will likely evaporate due to the (minimal) SMP overhead.
Now, if you were running a dedicated game server and playing said game on the same machine at the same time, you'd obviously see a benefit there, but most people don't do that.
There is no way to fully test a package repository. Since every package modifies the base system, the only way to prove that a package will work is to test it against every possible package configuration available!
If you make the assumption that every package that is installed modifies the base system, then you can make the same argument for any system without a centralized package repository too. In fact, the reality is even grimmer without a centralized package repository as the number of packages is even larger (read: essentially limitless), and the amount of integration testing is even lower! (read: essentially nil)
I would argue that any system that doesn't have a centralized package repository is fundamentally broken. But that's a discussion for another day.
I never said it was a general replacement for Windows and neither did anyone else in this thread.
Most software needs can be filled by native applications for Linux, but for the odd thing that doesn't have a native application, Wine can usually be used to fill that hole. That's what I say, and that's what I see most other people say.
So because Wine is only known to work with many Windows applications and not *all* Windows applications, it's not suitable to use for any Windows applications? By that logic, Windows 2000/XP aren't suitable replacements for Windows 98 because they're not compatible with *every* application that Windows 98 is.
Of course, if the problem is that Wine is not finished, than it should be label as a work in progress rather than a finished product.
For a piece of software that was in alpha for over 10 years and only within the last year finally reached beta, I think it's sufficiently known as "not finished yet".
Wine is more incomplete than buggy. It can run all sorts of outrageously complicated Windows software rather well (Microsoft Office and Lotus Notes, for example), but some other applications will use things that simply aren't implemented yet and thus you really end up with a hit or a miss situation without much in between.
One of the features I love about portage is that you can mix and match packages in any way you want. Say you want to install PHP, MySQL and Apache, this is trivial with any package manager. But say your distro only has packages for PHP 5.0, MySQL 4.1 and Apache 2.2, and you need PHP 4.4 with MySQL 5.0 and Apache 2.0, now you're out of luck unless you create the packages yourself. With portage, you can mix and match versions easily. Right now I can install any arbitrary combination of PHP (4.4/5.0/5.1), MySQL (3.23/4.0/4.1/5.0/5.1), and Apache (1.3/2.0/2.2) without having to create my own packages or otherwise leave the confines of my package manager.
The other main feature I love about portage is that it's (IMO) the most complete and up-to-date package repository, especially since there are no Gentoo "releases" per se, just a constant rolling upgrade, so you're current as often as you want, instead of being current for a week once every 6 months.
Several people have mentioned strace, but I have yet to see anyone mention oprofile. I haven't used dtrace before, but oprofile allows you to see where an application is spending it's time transparently, with negligible performance hit, and without restarting the application.
oprofile has been around since late 2002 it seems, so it's not particularly new either. How does dtrace compare to oprofile?
Slashdot Mirror
At how unbelieveably awful it is?
It's far more likely that the memory that was assigned for that variable was zero already, not that gcc initialized it to zero for you.
Running 32-bit and 64-bit applications side by side on a 64-bit OS is easy, I do it frequently. I highly doubt that you will be able to use 32-bit device drivers natively with a 64-bit kernel though, do you have any evidence to back that claim up?
As a Linux user, I once considered getting an Apple laptop after Lenovo took over the Thinkpad line, in the case that Lenovo wasn't able to carry on the line satisfactorily. That consideration lasted until I found out that all Apple laptops have no useful pointing devices. While the single mouse button may not be a big deal for a desktop where you can simply replace the defective mouse with a real mouse, you can't fix the laptop without voiding your warranty.
So no, the kludge (which doesn't even cover a third button) you mention does not mean it's OK to design defective hardware.
Only if they're global variables.
Try running this:
(apparently ecode doesn't display tabs)
You'll get something like this:
Indeed, consumer hardware in general is held back by Windows and it's countless deficiencies. With memory for example, you basically can't use more than 2G of RAM with consumer level hardware because a) Windows still has miserable 64-bit support and b) Windows scales very poorly with more RAM anyways. So even those of us that aren't directly crippled by Windows, still have to put up with underdeveloped hardware.
You assume that we have a Windows system in the first place.
Hold down the middle mouse button and drag.
I've been running the 64-bit Nvidia drivers since I got my Athlon X2 system 7 months ago and have yet to see a crash.
While this is a popular belief, it's not really applicable. The OS is doing just about nothing while you're playing a game and the 0.1% speedup you might have gotten from this will likely evaporate due to the (minimal) SMP overhead.
Now, if you were running a dedicated game server and playing said game on the same machine at the same time, you'd obviously see a benefit there, but most people don't do that.
Just read my sig, I think it speaks for itself.
If you make the assumption that every package that is installed modifies the base system, then you can make the same argument for any system without a centralized package repository too. In fact, the reality is even grimmer without a centralized package repository as the number of packages is even larger (read: essentially limitless), and the amount of integration testing is even lower! (read: essentially nil)
I would argue that any system that doesn't have a centralized package repository is fundamentally broken. But that's a discussion for another day.
I never said it was a general replacement for Windows and neither did anyone else in this thread.
Most software needs can be filled by native applications for Linux, but for the odd thing that doesn't have a native application, Wine can usually be used to fill that hole. That's what I say, and that's what I see most other people say.
So because Wine is only known to work with many Windows applications and not *all* Windows applications, it's not suitable to use for any Windows applications? By that logic, Windows 2000/XP aren't suitable replacements for Windows 98 because they're not compatible with *every* application that Windows 98 is.
For a piece of software that was in alpha for over 10 years and only within the last year finally reached beta, I think it's sufficiently known as "not finished yet".
Wine is more incomplete than buggy. It can run all sorts of outrageously complicated Windows software rather well (Microsoft Office and Lotus Notes, for example), but some other applications will use things that simply aren't implemented yet and thus you really end up with a hit or a miss situation without much in between.
One of the features I love about portage is that you can mix and match packages in any way you want. Say you want to install PHP, MySQL and Apache, this is trivial with any package manager. But say your distro only has packages for PHP 5.0, MySQL 4.1 and Apache 2.2, and you need PHP 4.4 with MySQL 5.0 and Apache 2.0, now you're out of luck unless you create the packages yourself. With portage, you can mix and match versions easily. Right now I can install any arbitrary combination of PHP (4.4/5.0/5.1), MySQL (3.23/4.0/4.1/5.0/5.1), and Apache (1.3/2.0/2.2) without having to create my own packages or otherwise leave the confines of my package manager.
The other main feature I love about portage is that it's (IMO) the most complete and up-to-date package repository, especially since there are no Gentoo "releases" per se, just a constant rolling upgrade, so you're current as often as you want, instead of being current for a week once every 6 months.
Why wouldn't you just start kwin again?
Linux's 3dfx driver has supported x86, amd64, sparc, alpha, ia64, ppc, and more for quite awhile.
Several people have mentioned strace, but I have yet to see anyone mention oprofile. I haven't used dtrace before, but oprofile allows you to see where an application is spending it's time transparently, with negligible performance hit, and without restarting the application.
oprofile has been around since late 2002 it seems, so it's not particularly new either. How does dtrace compare to oprofile?
The first problem of which is obviously "What am I going to do with all this free time I have now?", but what's the second?
Hmm, but that would rely on the macro operating linewise, no? What happens if your macro operates on the next 7 lines and creates 2 of it's own?
You only start one copy of a program per boot, and never reopen it?