Aside from the fact that widescale DSLAM deployment is prohibitively expensive, Bell will only let you colocate in the CO. Customers in remote areas who are too far from the CO can't be serviced by them. Even some relatively dense suburban neighbourhoods (such as mine) are too far from the CO to get a decent sync speed.
Bell works around these issues by using remotes, but they won't allow third party ISPs to put their own DSLAMs in them. And even if building your own remotes wasn't such a ridiculous idea, Bell probably wouldn't let you plug it into their copper.
So installing your own DSLAMs is really only practical in dense urban neighbourhoods. For everyone else it'll just result in slower speeds, or possibly even no service at all.
Actually, it would be better to start looking at POSIX. It won't get you binary compatibility, but done "right" a recompile should get it running on any POSIX-based OS, including everyone's favourites, Linux and Mac OS X (Windows too, if you don't mind the performance hit of Cygwin/SFU).
If you need binary compatibility, Unix is still a good choice. Most Unix operating systems strive to maintain binary backwards compatibility. In fact, many of them exist only because they do.
Only problem comes in if you want a GUI. You could use a web interface for a truly cross platform UI, but that doesn't always work. There are X servers for most platforms, but I hear it's slow on at least OS X (I haven't pushed Cygwin/X enough to say, nor heard anything about it's performance, but I'm sure there are at least commercial solutions that would do well on Windows). You could target GTK+/Qt, but they depend on X on OS X as far as I know. (I hear a lot of complaints from OS X users about a GTK+ app I do "support" for just raping their system resources.) There's wxWindows too, but I've always found it to be horribly slow here on Linux/GTK+.
It's a shame, I think, that UIs are the only area where there really isn't an adequate cross-platform solution. If only it were easier/faster/"cleaner" there might be more people doing it. As it stands, it's almost not even worth bothering with. At least not as anything more than an afterthought.
To be fair, I would guess that NES on the SNES and NES/SNES on the N64 just wouldn't have been technically feasible. By the time the GC came around it may have been, but no one would've wanted a cartridge slot for each of the three former systems, and the internet just wasn't popular enough for downloadable content to be worthwhile. It's not really surprising that all three new consoles will be backwards compatible with their CD/DVD-based brethren, but hearing that the Revolution will emulate the old cart games as well is quite a shock.
It would be nice to play all those great games on a console again, but if I have to buy them again too and it doesn't support stuff like save states (as I'm sure will be the case), I'll just stick with PC emulation. Of course, I've never found N64 emulation to be all that great on the PC, so I may find a use for it after all.
For those of you not familiar with it, the heap is where applications dynamically allocate memory at runtime. The problem is it is just one chunk of memory that is grown, and can only be shrunk if the memory at the very top is deallocated.
For example, you might be viewing a lot of large images in Firefox consuming lots and lots of memory. Firefox might then go ahead and allocate some dynamic memory during this period that gets tossed on the top of the heap. When you eventually close all those tabs, the memory where the images are stored are in the middle of the heap, so it doesn't actually shrink, and thus memory usage doesn't decrease. On the plus side, this wasted memory will be reused for future allocations, and may end up being swapped out (still bad, but better than being locked in memory that can't be used by other applications).
There's an interesting wiki discussion about this and other memory consumption issues for anyone interested.
Anyway, try closing Firefox and opening those four tabs again, memory consumption should be much less. Mind you, if it works you could just as well say it's a memory leak, so it doesn't really prove anything.
Also be sure you're measuring RSS, as that's a measure of what is actually in memory. VSZ just measures the address space size, a lot of which isn't actual memory.
If anyone is curious, my Firefox is currently consuming 56M with 22 tabs open (mostly/. articles and other morning news).
This really isn't any surprise when you consider how varying Linux distros can be, and how similiar installations of Windows are. In practice however, a binary will work on any Linux distro of the same architecture provided the required libraries are available, which makes this a dependency issue. Windows avoids this by providing many commonly used functions as part of a base install, while Linux distros make these (and many more) optional. If Microsoft doesn't provide a needed function, the programmer either codes it themselves or includes a third party library as part of the installer. Of course, this has it's disadvantages:
A bloated base operating system with libraries you may not need (though in practice, many of the built in applications that your average joe uses depend on them), and
programmers waste time reimplementing functions that Microsoft does not provide, or
installers install DLLs globally and you have DLL Hell, or
installers waste disk space and memory by installing DLLs in their application directory.
The last group could be avoided by installing DLLs globally with versioned filenames, but I guess that would be too unixy.:P
The fact that Windows doesn't provide an installation system is also a big minus. For example, installing firefox with flash support on Gentoo:
emerge firefox netscape-flash
And on Windows:
Run MSIE
Google for firefox, because you don't have the URI memorized
Download installer
Run installer
Go through installation wizard (3 steps minimum, IIRC)
Run firefox
Google for macromedia flash
Download installer
Run installer
Go through installation process (which I can't remember)
Restart firefox
I don't know about you, but I think the Gentoo way is easier. Sure it'll pull in dependencies, and spend a good while building it all. But apt, and other binary packaging systems I'm not familiar with, can be just as good, and in most cases will be faster even when grabbing dependencies.
Slashdot Mirror
Aside from the fact that widescale DSLAM deployment is prohibitively expensive, Bell will only let you colocate in the CO. Customers in remote areas who are too far from the CO can't be serviced by them. Even some relatively dense suburban neighbourhoods (such as mine) are too far from the CO to get a decent sync speed.
Bell works around these issues by using remotes, but they won't allow third party ISPs to put their own DSLAMs in them. And even if building your own remotes wasn't such a ridiculous idea, Bell probably wouldn't let you plug it into their copper.
So installing your own DSLAMs is really only practical in dense urban neighbourhoods. For everyone else it'll just result in slower speeds, or possibly even no service at all.
Actually, it would be better to start looking at POSIX. It won't get you binary compatibility, but done "right" a recompile should get it running on any POSIX-based OS, including everyone's favourites, Linux and Mac OS X (Windows too, if you don't mind the performance hit of Cygwin/SFU).
If you need binary compatibility, Unix is still a good choice. Most Unix operating systems strive to maintain binary backwards compatibility. In fact, many of them exist only because they do.
Only problem comes in if you want a GUI. You could use a web interface for a truly cross platform UI, but that doesn't always work. There are X servers for most platforms, but I hear it's slow on at least OS X (I haven't pushed Cygwin/X enough to say, nor heard anything about it's performance, but I'm sure there are at least commercial solutions that would do well on Windows). You could target GTK+/Qt, but they depend on X on OS X as far as I know. (I hear a lot of complaints from OS X users about a GTK+ app I do "support" for just raping their system resources.) There's wxWindows too, but I've always found it to be horribly slow here on Linux/GTK+.
It's a shame, I think, that UIs are the only area where there really isn't an adequate cross-platform solution. If only it were easier/faster/"cleaner" there might be more people doing it. As it stands, it's almost not even worth bothering with. At least not as anything more than an afterthought.
I saw USE and just couldn't help but think "Gentoo."
To be fair, I would guess that NES on the SNES and NES/SNES on the N64 just wouldn't have been technically feasible. By the time the GC came around it may have been, but no one would've wanted a cartridge slot for each of the three former systems, and the internet just wasn't popular enough for downloadable content to be worthwhile. It's not really surprising that all three new consoles will be backwards compatible with their CD/DVD-based brethren, but hearing that the Revolution will emulate the old cart games as well is quite a shock.
It would be nice to play all those great games on a console again, but if I have to buy them again too and it doesn't support stuff like save states (as I'm sure will be the case), I'll just stick with PC emulation. Of course, I've never found N64 emulation to be all that great on the PC, so I may find a use for it after all.
So Q4 in Q4. Cool.
This is Slashdot, since when do we care about quality tech journalism?
For those of you not familiar with it, the heap is where applications dynamically allocate memory at runtime. The problem is it is just one chunk of memory that is grown, and can only be shrunk if the memory at the very top is deallocated.
For example, you might be viewing a lot of large images in Firefox consuming lots and lots of memory. Firefox might then go ahead and allocate some dynamic memory during this period that gets tossed on the top of the heap. When you eventually close all those tabs, the memory where the images are stored are in the middle of the heap, so it doesn't actually shrink, and thus memory usage doesn't decrease. On the plus side, this wasted memory will be reused for future allocations, and may end up being swapped out (still bad, but better than being locked in memory that can't be used by other applications).
There's an interesting wiki discussion about this and other memory consumption issues for anyone interested.
Anyway, try closing Firefox and opening those four tabs again, memory consumption should be much less. Mind you, if it works you could just as well say it's a memory leak, so it doesn't really prove anything.
Also be sure you're measuring RSS, as that's a measure of what is actually in memory. VSZ just measures the address space size, a lot of which isn't actual memory.
If anyone is curious, my Firefox is currently consuming 56M with 22 tabs open (mostly /. articles and other morning news).
This really isn't any surprise when you consider how varying Linux distros can be, and how similiar installations of Windows are. In practice however, a binary will work on any Linux distro of the same architecture provided the required libraries are available, which makes this a dependency issue. Windows avoids this by providing many commonly used functions as part of a base install, while Linux distros make these (and many more) optional. If Microsoft doesn't provide a needed function, the programmer either codes it themselves or includes a third party library as part of the installer. Of course, this has it's disadvantages:
The last group could be avoided by installing DLLs globally with versioned filenames, but I guess that would be too unixy. :P
The fact that Windows doesn't provide an installation system is also a big minus. For example, installing firefox with flash support on Gentoo:
And on Windows:
I don't know about you, but I think the Gentoo way is easier. Sure it'll pull in dependencies, and spend a good while building it all. But apt, and other binary packaging systems I'm not familiar with, can be just as good, and in most cases will be faster even when grabbing dependencies.