Parallel programming is being facilitated in every modern OS by providing multithreading and multiprocessing capabilities. The programming language has to do jack with parallelism. That's what all those multithreading APIs are for! Read your system API documentation, then grab your favorite programming language and hack away!
I too have seen Windows 2000 and XP just love to make heavy use of the paging file even though there is clearly enough physical memory available.
The reason is there are various design problems in Windows. One is that shared memory and committed virtual memory are always backed by a file. On Windows and OS/2, virtual memory disk allocation and deallocation is excruciatingly slow. I once wrote a software virtual memory system for OS/2 that was about 10 times faster than the built-in system (just using regular OS/2 I/O calls). Windows is extremely slow, not just because of its virtual memory system, but also because of its task scheduler, which can switch away from a process for over 50 msecs (which is an eternity for modern processors). The Linux multitasking throughput is at least 1000 times higher than that of Windows (XP vs. an early Linux 2.6.x). Modern Linux systems are probably 5000-10000 times faster than Windows when multitasking throughput is concerned. The Windows loader maps all DLLs into memory whether they're currently used or not (b/c of the DllMain() function which must be executed for many DLLs). One giant bug in Windows is still that it's impossible to kill a process without messing up the DLL states, because TerminateProcess() does not execute DLL cleanup code and does not update DLL reference counters. That's why Windows is a poorly written OS and often called a toy OS, because of its unprofessional implementation. (HAHA sorry that had to be said -- I've programmed on Windows for 16 years, and I know why it sucks!;-) )
Have a look at the descriptions of the VirtualAlloc(), MapViewOfFile() and CreateFileMapping() API calls, which are used for virtual memory and shared memory, resp.; Shared memory on Windows is always backed by a file. Virtual memory is automatically backed by the paging file if pages are committed (so that's programmer-dependent). This means Windows has to access the DISK to allocate committed virtual memory or shared memory pages. That's one of the prime reasons why Windows is so slow (another reason is the lazy task switcher which can switch away from a process for 50 msecs or more, which is an eternity to modern CPUs). So, the OP is correct: If Windows was written properly, it would not stuff in the virtual memory statistics when there's still enough physical RAM available, no matter if the virtual memory is currently allocated in RAM; It means there's also space allocated on disk!
That's very simple: The movie film tape. That cannot be made by most cinemas, and hence someone has to copy it to a physical medium. That could be sold or licensed by the organization that made the movie (of course, anyone else could do the same).
You simply target the appropriate markets: Video game makers and movie makers. You can sell solutions that make their work easier. If you want to make money from the end customer: Making money from a FOSS video game could be achieved by making network games and charging the players with low monthly fees. Making money from a FOSS movie is achieved by licensing it out to cinemas and publishing it on DVDs, just as with regular movies. Both of the latter solutions have been successful in the past.
Exactly, customers will hold back upgrades if they know the product is bug-ridden. On the other hand, if you have perfectly working software, and there's new just as good version with better features, you're more likely to upgrade.
If a customer is not satisfied with a product or solution, they will return it and want their money back and/or sue the company that sold it. Software companies often go out of business because they assume customers will continue to buy bug-ridden updates or upgrades. Delivering good custom solutions to customers is what successful software companies are doing. Customers that are happy can spread the word around and deliver new customers to a company.
Writing custom software solutions is what MOST of the software industry was doing for decades. That goes all the way down to selling custom computer models (until the 1980ies). Software solution companies sell the customer computers and/or any software they need, be it off the shelf or custom. And that's where FOSS can shine: It can help to reduce the price tag for the customer. Most businesses require custom software that is only relevant to them, and that's where profit can be made. FOSS operating systems like Linux or BSD have a value that is a thousand times higher than that of Windows, at roughly the same price (if you pay up with sponsorship, merchandise or license fees). The giant tool set does or will enable the development of giant development tools for business applications. Most software companies use their own internal development tools. If those were FOSS as well, more companies could use them, and markets would be opened: Business applications on FOSS operating systems. The profit is or will be made from the custom software solutions that every business needs. Being in the solution business has been the bread and butter job for most software developers for decades, and it's unlikely to change.
Here in Germany, such technology has been in use by media retailers for about 20 years now!! When you walk into a media shop, items usually have a thick, metallic, self-adhesive tag on them (with white plastic casing), that is made inactive at the cash register. At the entrance and exit, there are detectors that use a magnetic field to see if someone walks through with a shoplifted item. An alarm goes off if that happens. I'm not sure whether that is using RFID or a similar technology. But it seems to work really well. The downside for the customer is that it requires a pointed tool and some force to remove the self-adhesive tag at home, often leading to scratches to the item's surface.
Yup, it's possible to get a considerably well paid IT job without a degree. It all depends on which employers you find, so job hunting is the most complicated part of it. As an example, you can take myself: I started computer programming as a kid, quit school a year early, and have now over 25 years of programming experience in my book, despite being just 38. Finding an employer can be a tough one, though. I've been unemployed for about half a year now, and haven't found any new job yet. The current economical crisis might also factor into this. With a degree you might have more job options, but it all depends on the conservativism of a work environment; so, if someone hires only graduates, that might not be a company you'd want to work for anyway. In some companies you'd only get looked down upon, so choosing your employer carefully is a necessity, despite the urge to get a job.
Indeed, IIRC AIX 2.x had a different kernel underneath the UNIX layer. They shouldn't have dropped that either. Probably it was something good as well.
Yeah... those big companies shouldn't do that, it makes their customers unhappy. Because having such a box on or under your desk is a completely different thing than just using some space on a server. And people then might simply choose a different kind of workstation instead of using a server.
Because customers used them, and might have wanted to continue to do so... but IBM did more offensive things in the past. I've known a former IBM manager who was also a programmer, who was so angry at IBM that he became a Microsoft-only guy. He had bought a mini computer from IBM that was discontinued about the same day it came to market. Way to spend a lot of money, I guess. He still kept on using that machine, of course, because it was so good. Sometimes it's a really a sad sight how good things are washed down the drain for the sake of profit.
but I/O (and namely filesystem I/O) on AIX is for the birds. JFS and JFS2 are very robust filesystems, but for anything approaching real speed, they just don't get it done.
Strange... I was always very pleased with AIX I/O performance, but I guess it depends on the machine and other factors. AIX has asynchronous I/O that lets you do other tasks while the I/O takes place. If a program is written nicely, it'll make I/O seamless and run as much stuff as possible in parallel.
However, they are like 4MB PCI cards or something silly, and the amount of colors you can get is laughable.
Using SMIT, you can configure the video mode of the graphics card to true color. In CDE, you can also raise the number of colors. This gives you true color mode for X apps, and 256 colors for the CDE itself. I did just that on the RS/6000 I mentioned, and this was about 8 years ago. So I guess, that on modern systems, that is still possible.
If you don't believe me, check out features like directory monitoring, asynchronous I/O and multithread signalling in the history of Linux kernels. You might find a surprise there, or two.
LOL, good analogy. Things are not that simple however, especially when you look closely at the kernels. AIX has one hell of a well designed kernel, at least from the programmer's point of view. Especially when it comes to multithreading, signalling, stuff like that, Linux can't cope (yet). When writing massively multithreaded apps, I ran into all sorts of problems on Linux and Solaris (however, this was on earlier releases, haven't tried on more recent ones yet). AIX works like a clockwork there. With the BSDs, I haven't tried yet, but they're looking better than Linux in that aspect as well. Hence, in my mind, there's still the notion "AIX is UNIX as it should be", and it'll take a while until I'm fully accustomed to the pecularities of Linux.
Yup, actually I'm using Debian 4.0r5 right now to type this. I'm quite pleased with it. Yet, sometimes I still yearn for an AIX workstation. Linux and the BSDs are getting better all the time, and in 2008 alone I had virtually nothing to complain about in those areas anymore. I'm not quite satisfied with PC I/O performance, but I received a number of hints already, like SAS or additional SATA cards.:)
Thanks. I'll have to try FreeBSD 7.0, since I have that on my box also. Across Linux distros, the source code for the driver might be the same, because it is part of the Linux kernel. I'm using an older kernel, 2.6.18, from the stable branch, and this might be a reason for that problem. For now, it'll not be something I'll lose sleep over, however. But I will look into SATA RAID and SAS cards sometime (SAS more later than sooner, because of the price tag, I guess!;) ).
Thanks, but I'm running Debian Linux 4.0r5!;) I'm not sure whether there are any dedicated Linux I/O drivers for my chipset (945G) from Intel (I didn't find any). Actually, in contrast to what I said before, the problem that I had was not copying from one SATA drive to another, but copying from one SATA drive to an external FireWire drive (which would also involve FireWire into the equation; however, I never noticed performance problems with that). The SATA drive is a Blu-ray drive, and I was copying files from a backup to the external FireWire drive. Just for one folder, which had merely 60,000 files in it, the process took over 6 hours. The reason for that is, that the Blu-ray drive has to do lengthy seek operations to access individual files sometimes; this drags down the copying time even for small times to over 1 second. During the seek operation, it's not possible to access the machine's internal hard drives. So, it might either be a sloppily written Linux driver, or a general design problem with the chipset (namely, that commands cannot be run asynchronously). I noticed bad I/O performance with that board before, especially on Windows Vista (of course I blamed it on Vista!;) ). So, it might be a general issue with the chipset. Anyway, I'd be happy to learn about any chipset that would solve this problem!:)
Slashdot Mirror
Parallel programming is being facilitated in every modern OS by providing multithreading and multiprocessing capabilities. The programming language has to do jack with parallelism. That's what all those multithreading APIs are for! Read your system API documentation, then grab your favorite programming language and hack away!
I too have seen Windows 2000 and XP just love to make heavy use of the paging file even though there is clearly enough physical memory available.
The reason is there are various design problems in Windows. One is that shared memory and committed virtual memory are always backed by a file. On Windows and OS/2, virtual memory disk allocation and deallocation is excruciatingly slow. I once wrote a software virtual memory system for OS/2 that was about 10 times faster than the built-in system (just using regular OS/2 I/O calls). Windows is extremely slow, not just because of its virtual memory system, but also because of its task scheduler, which can switch away from a process for over 50 msecs (which is an eternity for modern processors). The Linux multitasking throughput is at least 1000 times higher than that of Windows (XP vs. an early Linux 2.6.x). Modern Linux systems are probably 5000-10000 times faster than Windows when multitasking throughput is concerned. The Windows loader maps all DLLs into memory whether they're currently used or not (b/c of the DllMain() function which must be executed for many DLLs). One giant bug in Windows is still that it's impossible to kill a process without messing up the DLL states, because TerminateProcess() does not execute DLL cleanup code and does not update DLL reference counters. That's why Windows is a poorly written OS and often called a toy OS, because of its unprofessional implementation. (HAHA sorry that had to be said -- I've programmed on Windows for 16 years, and I know why it sucks! ;-) )
Have a look at the descriptions of the VirtualAlloc(), MapViewOfFile() and CreateFileMapping() API calls, which are used for virtual memory and shared memory, resp.; Shared memory on Windows is always backed by a file. Virtual memory is automatically backed by the paging file if pages are committed (so that's programmer-dependent). This means Windows has to access the DISK to allocate committed virtual memory or shared memory pages. That's one of the prime reasons why Windows is so slow (another reason is the lazy task switcher which can switch away from a process for 50 msecs or more, which is an eternity to modern CPUs). So, the OP is correct: If Windows was written properly, it would not stuff in the virtual memory statistics when there's still enough physical RAM available, no matter if the virtual memory is currently allocated in RAM; It means there's also space allocated on disk!
That's very simple: The movie film tape. That cannot be made by most cinemas, and hence someone has to copy it to a physical medium. That could be sold or licensed by the organization that made the movie (of course, anyone else could do the same).
You simply target the appropriate markets: Video game makers and movie makers. You can sell solutions that make their work easier. If you want to make money from the end customer: Making money from a FOSS video game could be achieved by making network games and charging the players with low monthly fees. Making money from a FOSS movie is achieved by licensing it out to cinemas and publishing it on DVDs, just as with regular movies. Both of the latter solutions have been successful in the past.
Exactly, customers will hold back upgrades if they know the product is bug-ridden. On the other hand, if you have perfectly working software, and there's new just as good version with better features, you're more likely to upgrade.
If a customer is not satisfied with a product or solution, they will return it and want their money back and/or sue the company that sold it. Software companies often go out of business because they assume customers will continue to buy bug-ridden updates or upgrades. Delivering good custom solutions to customers is what successful software companies are doing. Customers that are happy can spread the word around and deliver new customers to a company.
Writing custom software solutions is what MOST of the software industry was doing for decades. That goes all the way down to selling custom computer models (until the 1980ies). Software solution companies sell the customer computers and/or any software they need, be it off the shelf or custom. And that's where FOSS can shine: It can help to reduce the price tag for the customer. Most businesses require custom software that is only relevant to them, and that's where profit can be made. FOSS operating systems like Linux or BSD have a value that is a thousand times higher than that of Windows, at roughly the same price (if you pay up with sponsorship, merchandise or license fees). The giant tool set does or will enable the development of giant development tools for business applications. Most software companies use their own internal development tools. If those were FOSS as well, more companies could use them, and markets would be opened: Business applications on FOSS operating systems. The profit is or will be made from the custom software solutions that every business needs. Being in the solution business has been the bread and butter job for most software developers for decades, and it's unlikely to change.
Here in Germany, such technology has been in use by media retailers for about 20 years now!! When you walk into a media shop, items usually have a thick, metallic, self-adhesive tag on them (with white plastic casing), that is made inactive at the cash register. At the entrance and exit, there are detectors that use a magnetic field to see if someone walks through with a shoplifted item. An alarm goes off if that happens. I'm not sure whether that is using RFID or a similar technology. But it seems to work really well. The downside for the customer is that it requires a pointed tool and some force to remove the self-adhesive tag at home, often leading to scratches to the item's surface.
Yup, it's possible to get a considerably well paid IT job without a degree. It all depends on which employers you find, so job hunting is the most complicated part of it. As an example, you can take myself: I started computer programming as a kid, quit school a year early, and have now over 25 years of programming experience in my book, despite being just 38. Finding an employer can be a tough one, though. I've been unemployed for about half a year now, and haven't found any new job yet. The current economical crisis might also factor into this. With a degree you might have more job options, but it all depends on the conservativism of a work environment; so, if someone hires only graduates, that might not be a company you'd want to work for anyway. In some companies you'd only get looked down upon, so choosing your employer carefully is a necessity, despite the urge to get a job.
Thank you. I will look into that. :)
Indeed, IIRC AIX 2.x had a different kernel underneath the UNIX layer. They shouldn't have dropped that either. Probably it was something good as well.
LOL thanks! :)
Nice! I still have boxes full of OS/2 diskettes (which I actually had to use to install it, that was before CD-ROM drives became widely available).
Hey, don't puke on that carpet! ;)
Yeah ... those big companies shouldn't do that, it makes their customers unhappy. Because having such a box on or under your desk is a completely different thing than just using some space on a server. And people then might simply choose a different kind of workstation instead of using a server.
Because customers used them, and might have wanted to continue to do so ... but IBM did more offensive things in the past. I've known a former IBM manager who was also a programmer, who was so angry at IBM that he became a Microsoft-only guy. He had bought a mini computer from IBM that was discontinued about the same day it came to market. Way to spend a lot of money, I guess. He still kept on using that machine, of course, because it was so good. Sometimes it's a really a sad sight how good things are washed down the drain for the sake of profit.
Not everyone uses Windows, you know! ;)
but I/O (and namely filesystem I/O) on AIX is for the birds. JFS and JFS2 are very robust filesystems, but for anything approaching real speed, they just don't get it done.
Strange ... I was always very pleased with AIX I/O performance, but I guess it depends on the machine and other factors. AIX has asynchronous I/O that lets you do other tasks while the I/O takes place. If a program is written nicely, it'll make I/O seamless and run as much stuff as possible in parallel.
However, they are like 4MB PCI cards or something silly, and the amount of colors you can get is laughable.
Using SMIT, you can configure the video mode of the graphics card to true color. In CDE, you can also raise the number of colors. This gives you true color mode for X apps, and 256 colors for the CDE itself. I did just that on the RS/6000 I mentioned, and this was about 8 years ago. So I guess, that on modern systems, that is still possible.
If you don't believe me, check out features like directory monitoring, asynchronous I/O and multithread signalling in the history of Linux kernels. You might find a surprise there, or two.
LOL, good analogy. Things are not that simple however, especially when you look closely at the kernels. AIX has one hell of a well designed kernel, at least from the programmer's point of view. Especially when it comes to multithreading, signalling, stuff like that, Linux can't cope (yet). When writing massively multithreaded apps, I ran into all sorts of problems on Linux and Solaris (however, this was on earlier releases, haven't tried on more recent ones yet). AIX works like a clockwork there. With the BSDs, I haven't tried yet, but they're looking better than Linux in that aspect as well. Hence, in my mind, there's still the notion "AIX is UNIX as it should be", and it'll take a while until I'm fully accustomed to the pecularities of Linux.
Sure, e-mail me, let's talk about it! :)
Yup, actually I'm using Debian 4.0r5 right now to type this. I'm quite pleased with it. Yet, sometimes I still yearn for an AIX workstation. Linux and the BSDs are getting better all the time, and in 2008 alone I had virtually nothing to complain about in those areas anymore. I'm not quite satisfied with PC I/O performance, but I received a number of hints already, like SAS or additional SATA cards. :)
Thanks. I'll have to try FreeBSD 7.0, since I have that on my box also. Across Linux distros, the source code for the driver might be the same, because it is part of the Linux kernel. I'm using an older kernel, 2.6.18, from the stable branch, and this might be a reason for that problem. For now, it'll not be something I'll lose sleep over, however. But I will look into SATA RAID and SAS cards sometime (SAS more later than sooner, because of the price tag, I guess! ;) ).
Thanks, but I'm running Debian Linux 4.0r5! ;) I'm not sure whether there are any dedicated Linux I/O drivers for my chipset (945G) from Intel (I didn't find any). Actually, in contrast to what I said before, the problem that I had was not copying from one SATA drive to another, but copying from one SATA drive to an external FireWire drive (which would also involve FireWire into the equation; however, I never noticed performance problems with that). The SATA drive is a Blu-ray drive, and I was copying files from a backup to the external FireWire drive. Just for one folder, which had merely 60,000 files in it, the process took over 6 hours. The reason for that is, that the Blu-ray drive has to do lengthy seek operations to access individual files sometimes; this drags down the copying time even for small times to over 1 second. During the seek operation, it's not possible to access the machine's internal hard drives. So, it might either be a sloppily written Linux driver, or a general design problem with the chipset (namely, that commands cannot be run asynchronously). I noticed bad I/O performance with that board before, especially on Windows Vista (of course I blamed it on Vista! ;) ). So, it might be a general issue with the chipset. Anyway, I'd be happy to learn about any chipset that would solve this problem! :)