Don't mix shitty parallel computation libraries and actual performance. Multithreaded applications without MPI are, of course, faster than anything with MPI, however it says absolutely nothing about:
I assume you mean "don't use MPI on an SMP/NUMA machine if you want to get the highest performance out of this box". Anyone who knows anything about parallel computing knows the difference between message passing and SMP architectures and why this is the case, there isn't anything "insightful" about that.
Other than that, decent MPI communication library implemenations should do very well compared to native message passing on message passing architectures. I'd be willing to bet that an MPI app on a cluster of PCs is faster than pure multithreaded code on the same hardware.:)
Disclaimer: I have ported MPICH to a number of platforms as well as implemented a few MPI implementations from scratch.
(heh... took me 5 tries to post this message.... is/./.ing itself?)
Re:IRIX is better for computational graphics than
on
New SGI Altix 3000
·
· Score: 1
Ah... forgot about the graphics part... the other was about simple crunching. Yes, SGI has always had top of the line visualization capability. Nothing like playing Doom/Quake in a Cave.
Re:IRIX is better for computational graphics than
on
New SGI Altix 3000
·
· Score: 3, Interesting
Well... our experience with the O2K was a bit different (haven't touched an O3K though so I dunno much about it). With the Origins 2K and NUMA, if you ran large simulations, the distant memory would flat kill your performance so you had to make sure your working sets fit on a single node. Also, even though each processor board in the O2K had 2 CPUs, if you actually ran an even somewhat memory intensive process on each CPU, your app slogged because the memory bandwidth only supported about 1.4X the bandwidth of a single CPU. Another bad habit was that if someone snuck onto the machine when you were running your 64 process job and they fired up something like emacs, it would cause this nasty shifting around of memory that got you into the NUMA state mentioned above. Later, SGI came out with some tools that would minimize this effect though, which helped a lot.
So... in order to support the kind of stuff we did and run it on 64 nodes, we would have had to buy a 128 processor system because we would only run one process per node and all the nodes were two processors.
So, we also looked at the Sun10K. While the cpu to cpu comparison of raw crunch was lower, the memory bandwidth was uniform so the programs behaved predictably and were almost as fast in any case. It also had the benefit of running 1 process (as far as performance per process) wasn't noticably different from running 64 processes (on a 64 processor machine). At the time, the Sun10K met our needs much better.
Now, of course, all those have been shoved out the door and replaced by something even faster.
I think we all know what the GPL is supposed to mean, for people who cant see through the legalese it is clearly described in the FAQ on the GNU website...
And this is why we have lawyers... to see if what we all "think" it is supposed to mean, what it is described to us in "layman's terms" as, and what the legalese actually says are all the same thing.
"If the processor was "better", it would actually do more with each clock cycle, instead of less."
No... not at all. "better" is subjective and you can't simply "prove" this. If the P4 had an IPC of 1, but could reach 1THz, it would still be fast . It's about tradeoffs... the more you try to "do" in a clock cycle, the more circuitry you have to have actually "doing" something. You also have to have the added complexity of the reordering logic and dispatch logic to try to extract as much parallelism out of the instruction stream as you can. This, of course, makes chips more and more complex (read: harder to test, design, etc.).
Back in the day, there were two schools of design philosophy. The "Brainiacs" believed in doing more per clock. The "Speed Freaks" believed in designs optimized for increased (and increasing) clock speed.
One of the things I think the Brainiacs realized is that the more you try to do in a single clock, the bigger and more complex the cpu becomes, and it is a greater than linear increase in complexity. Complexity causes the clock speed to be hard to increase (longer pathways may result from the increased complexity = lower clock speeds). The Speed Freaks aren't without their problems either -- I/O (keeping the cpu fed), heat, clock signals, etc.
Design approaches like Intel's EPIC are a hybrid of the two approaches, to some degree. It is supposed to make the chip design more simple, eliminating a lot of the forwarding/ordering logic in the CPU, by offloading these responsibilities to the compliers (which have to become more complex). At the same time, it provides a 'wide' set of execution units. This idea is to make the CPU simpler, which helps increase clock speed, while not sacrificing compute power (because you have a bunch of execution units). The challenge of the compilers is to keep all the execution pathways in the EPIC cpu full. Of course, with this design philosophy, you are at the mercy of the quality of compiler writers. EPIC tries to tradeoff complexity/speed in this way. Of course, Intel is having its share of problems getting EPIC to fly (chicken and egg problem with software to some degree, cost, etc).
Which is right? It's a matter of preference I guess. Both designs enable fast parts. I guess the only real question in my mind is which design more future value (to the company that is making the cpus) -- how much of today's design can be reused when going forward? how hard is it to come out with version++ from where you are today? how hard is it to get more performance than what we have today?
I'd agree with this as long as you add 'maintainable'. If tight/fast was your only goal, you wouldn't use GUIs... which are typically much better for end-user interaction and efficiency, for example. If tight/fast was your main goal, you wouldn't use a multi-tasking OS... you'd only make single-purpose devices programmed to the bare silicon.
One of my theories that Un*x and Un*x-like programmers are typically stronger (although, there are plenty who are not very strong) is that they have to do so much more work to get things to 'go'. For instance, it isn't enough that I know C. I have to also know make... and probably either vi and/or emacs.... and dbg or some other debugger... and man... and possibly autoconf... and the list goes on.
On Windows, the environment is pretty easy to use, especially for less skilled people. It makes programming less '3l337'/shrug.
I agree somewhat though... a good hardware class and some assembly would do many programmers good though. If nothing else, it lets them know what goes on behind the languages they use. Once you write a bit in assembly, pretty much any other computer language isn't that big of a deal.
You buy something, you can tear it apart and learn about it at home all you want. You can't use that knowledge to make more of them though and you can't post the information you learned for others' consumption.
I've taken apart all sorts of stuff to find out how it works. Never has my house been raided. Of course, I never posted it or tried to make more of them either.
-. Make sure you provide the rest of the world, especially those far behind our country, with the tools, material, and examples needed to learn and further their own technological advancement beyond your own. Let our brightest minds teach the rest of the world so that they can compete better in technological fields.
"They are released ahead of any *windows* 64-bit drivers for Nvidia cards."
Could be because they are released ahead of any *windows 64-bit OS*. Windows-64 hasn't been released yet. Linux already supports 64-bit CPUs. Not hard to do the math.
Re:Open Source is NOT the issue - it's the IMAGE
on
Largo Loving Linux
·
· Score: 1
"I tried Linux but it was too hard for me to install, then that guy flamed me on the newsgroups"
Heh... reading the replies to this post made me think back to this line.
Yes... but the individual components in the mainframe isn't the issue... the whole system is counted as one machine... and some of those haven't been down in many years. Basically, even though individual components of the machine may have been taken down, removed, or upgraded, the job that the machine does hasn't stopped.
We had legal licenses and we didn't have to pay nearly this much. There are Enterprise class licenses that you can take advantage of (at least, we purchased Enterprise class licenses).
Also, you forgot to add training and such for Linux and the equivalent applications that they will be using. Since his users already probably know windows and those applications, give his 400 employees a week of training (will incur this expense anyway as people try to figure out what they are doing and general get-up-to-speed time accounting for productivity lost from the year for learning the new stuff). Assuming that the average salary for his employees is $26000/year (makes the math easier):
400 x $500 = $200000
Using your numbers, the Windows costs $344,600 per year for the first year. The first year for your Linux solution is $450,000.
Now, we can start talking about the non-recurring costs for the next few years.
Of course, you assume that all the software that his company will be using on Linux has no cost (free as in beer), which is STUPID, STUPID, STUPID for a company to do. You'll want to pay for support for your Linux distros. Even using RedHat you will have 400 seats at $40 at least, $149.95 for the "Professional Version". One seat you'll have to be a server - $2499 for RedHat Advanced Server with best support. $995 for RedHat's Stronghold Secure Web Server.
We were also a part of a larger group of folks, around 20 of us total I think, who admin'd about 2000 Suns, about 200 SGIs, a smattering of AIX boxes, a few NetBSD boxes, and about 8000 x86 PCs running everything from Windows98 to Windows NT to Novell.
Just because you don't know how doesn't mean that others don't either.
Anyway... there were two things that prevented Netscape from being successful. First, apathy of users to download/install anything else (particularly when what they had worked fine for them). Second, Netscape was garbage.
So, back to the question in my previous post... What about the GNU tools? What about a lot of other stuff that 'comes for free' in a Linux distro? To borrow your words...
Every 'customer' of Linux using GNU tools must 'buy', install, support, and regardless and in fact use the GNU tools. No other product has a chance in hell of being successful.
You can lie all you want about what GNU did or did not do...
yada yada yada, you get the point.
How much of a chance do I have of writing and selling (either licensed or as support) my own version of the GNU tools? What about LaTeX? or a text editor to compete with VI or emacs? Would I be a fool to even try? Sounds like the same thing to me... Mr. Pot, meet Mr. Kettle.
And yes, a company that I helped startup did (and still does) compete in the OSS world (for 7 years now - Linux support and sales is always the lowest numbers). Many people who contacted us about our product balked when they learned that we (gasp) actually charged any money at all for purchase or support for our products. They wanted it free and they wanted the source. Their alternative was to go with some stuff that was OSS and was substandard by any means (buggy, slow, inefficient, and basically junk) for the *only* reason that they thought it was free (as in beer). They were willing to use some software that they would freely admit was poor quality (poorer than ours, they would freely admit this themselves) simply because they could download it for free and not pay support costs. What's funny was that the 'free' stuff really wasn't free because they had to have someone work on it all the time to get it running and keep it running. (How do I know this? because I helped write the OSS stuff as a small part of a collaborative project and their design decisions made the code pretty nasty. We started a company so we could do better and offer support and such for it). Unfortunately, the OSS world is not very nice to try to do that sort of thing in.
So... yes... the company I worked for *and* helped start up competed in that environment. Luckily, we were able to diversify well and we offer a wide variety of products on a number of platforms. It's very hard to make a living in that environment unless you are just selling IT Support type contracts. Programmers have a hard time keeping themselves fed.
The whole part about OSS is generally written by hobbyists and such I believe. The ironic thing is that many of those people work as programmers or whatever for companies who pay their salary so they can do hobbyist things and write code to give away for free in their off-time. These practices makes it difficult for other programmers (who usually sell their time/skills in order to pay their bills) to compete in the marketplace because you can't develop applications and expect to sell them. In the same breath, these hobbyists usually say how bad proprietary things are.
Basically, OSS is a great boon and marketplace for IT (can you say job security?) but pretty lousy for programmers. Usually, a new application is written and paid for in advance of sales - either through private or venture funding or from monies made from the sale of other products/services. That is the up-front costs for application development. After the product is written, you then hope to make your money back and then some on product sales and/or support contracts.
Heh, since a large number of people who use Linux want their software free (and don't want to pay support either), where does the money come from to pay the programmers who developed the application? (Hint: it comes from the companies that the hobbiests work for who indirectly subsidize the code that the hobbyist writes.)
And people wonder why there aren't many games on Linux boxes...
The hurdle that must be overcome for software to compete with bundled software is apathy (aside from subversive techniques such as making a JVM that doesn't run 'standard' java codes). Other than this, there is no reason why Netscape couldn't be installed on a Windows box and used (I know many people who used Netscape on Windows platforms and I've seen Netscape installed on hundreds of Windows machines). Why did it fail? It was offered for free just like IE (I don't know of a single person who actually purchased it). Many would say that IE was a superior product. I know that even on Un*x boxes I couldn't load 5 sites in succession without SEGVing Netscrape and my experiences on Windows were about the same. If Netscape was better, why didn't it win? If it were better, it wouldn't have mattered that both were free or that one was bundled any more than almost all Linux distros come bundled with a browser.
By the same token, I would ask who out there uses alternately developed/packaged tools to the GNU tools provided on Linux? By your logic, the GNU tools impede the innovation of standard command line utilities (ls, tar, bzip2, vi, emacs, grep, find, man, cd, etc.) How many alternatives do I have for those tools? How many people do you know who use alternative C/C++ compilers to GCC (and why do so many people use GCC and why aren't there many alternatives to GCC)? How much success would I have to develop an alternative help system to replace 'man'? If you say I'm stupid for even thinking of wanting to replace 'man', I might consider the GNU tools to be a barrier to my innovation in those areas.
IF the man pages were converted to HTML (which is a pretty good thing actually imo, because you can hyperlink to related topics and such), all Linux distros would have to deliver a browser in order to read them. I've seen *many* people use Netscape out of apathy, they simply know that Netscape exists and don't try any other browser. For these people (who also qualify as a significant portion of non-technical users), whatever browser delivered or installed for them by the IT group would be what was used. I know that I rarely install any other browser on Linux boxes I set up... as long as what's there works reasonably well, there isn't a strong enough reason to mess around with it unless some user requires or requests something new. If one distro became vastly dominant (maybe RedHat or UL), your argument would begin to apply to the Linux world as well.
As far as markets that are 'strongly owned' by Microsoft, the only ones that I personally see regularly are IE (if you count this as a product, I don't because it is integral to the OS just like more/man is), a development environment (I haven't found any on Windows better), Office (I hate productivity suites anyway, regardless of which - I prefer LaTeX for papers and such), and SQLServer (which, IMO is much easier and cheaper to get good performance out of than Oracle). Of those mentioned, only one of those is bundled or even free.
For listening to MP3s, WinAMP is used by almost everyone I know, some use that Musicmatch thing. For archiving/compression, WinZip. DiVX codecs for movies. Burning CDs I use Nero. PDF files and Realplayers and Quicktime. If you really wanted to dodge Office you could use one of the alternatives.
As far as bad design, I can't tell you the number of things I've downloaded on my Linux box that required some version of some library later than what I had. The only difference is that I can usually download the library to make up for it (usually leading into a nightmare of dependency issues).
So far, the main issue I see with your posts is that you don't like the idea of the next Office suite requiring a later version of the OS to run. Except for subscription licensing (which I don't like either) and interoperability, there is nothing that prevents me from continuing to run Win98 and a version of Office that runs on that OS for the rest of my life without paying another penny. Just because the next thing is out doesn't mean that you have to upgrade if what you have serves your needs. I know of a group who runs Apple ][e machines and software to this day because it has software on it that completely suits the need. They don't plan to upgraded until they can no longer find spare parts.
There are very few things that you are 'locked' into using other than by your own ignorance or by your own choice. I just don't buy the argument that Microsoft 'makes' you buy anything after your initial investment (except for subscription licensing and Microsoft was by far not the first company to do that... ever run a VAX?)
"But, what it does point out is that bundling crap with the OS is always a bad idea."
So.... all the GNU tools should be removed from Linux distros?
"1. bundling increases the cost for everyone"
True.
"2. bundling suppresses advanced technology by eliminating fair and open markets"
This is a hard one... Let's use IE for a hypothetical example... Let's suppose that Microsoft wanted to standardize all of its Help files, online documentation, and every other 'printed' documentation in the system to HTML. Let's then suppose that it seems that a browser can be generalized (at least conceptually) to be able to view just about anything on the system... such as file systems, system parameters, configuration files, system resources, etc. What if it then seems a good idea to make the 'standard' human interface to the OS be a browser. Basically, one application that 'does it all'. This might sound like a good idea because then it is only one app that has to be written to do all these things (maybe through the extensive use of plug-ins or some custom interfaces), which can be seen as a 'good thing' for the programmers because there may be less duplication of effort across the board - why have a seperate help viewer and custom file format for help AND have a view that can view HTML - especially when the help file format really just wants to be HTML, and it can be seen as good for users because they only have to remember one thing that 'does it all'. This mega-app would then have to be bundled with the system so you could view help files, navigate directories, view the web, etc. Without bundling this piece of software, you wouldn't have very much fun on the system. So... you get integration of a 'browser' throughout the system... something that is familiar to a user to use no matter what they are doing. Mom and pop like familiarity and non-obscurity.
"The result is harm to the industry and consumers."
What you consider "harm", others may consider beneficial. See above.
"As for the change in "threads", I doubt that threads have anything to do with the new features in Office XP. More likely than not any additions to Office XP could be completely contained in the application itself."
I agree... I was using "threads" as an example of something that is a basic core design principle of an OS... whether it supports it or not. You can't simply shoe-horn threads into an OS or you get some abomination like cooperative pthreads.
I have no clue as to why OfficeXP has to only run on WindowsXP. I can make the assumption that it is purely for renewed licensing and to cause more upgrades to WindowsXP. However, I have no evidence either way and to write it off to the conspiracy theorist mindset without more knowledge is foolish. That being said, I wouldn't be at all suprised if this was the case but I cannot simply proclaim that it is without having evidence (no... past actions are not evidence... they only show a predisposition to do this).
"Gosh, if OpenOffice/StarOffice, Mozilla and others can run on Linux, Microsoft Windows, Unix, the Mac and others then the idea that the OS must be custom to permit the application to run is just silly."
Yes, it would be silly.
"Requiring the OS to be upgraded harms consumers directly by greatly increasing their costs to benefit from new applications. And, that additional cost should be avoided if at all possible."
As does support of legacy software... I supported a product that had originally been written on VAX machines but later had frozen on those machines and was ported to Un*x and WindowsNT. The policy of the company I worked for was that software was supported until the last customer migrated. We had to keep two VAX personel on the roster all the time, although no new development had been done on the VAX for 4 years - but we had customers who didn't want to migrate to the newer system. Those developers had to be paid some way. We could have simply upped the support costs to astronomic values for that one customer I guess, but we chose to subsidize the developers from the new software. In this case, it was more expensive to all because we had to support the old stuff instead of letting it fade away.
"Of course, Microsoft could care less about saving customers money and is only interested in forcing customers to upgrade so that the bundled applications are more pervasive. And, collecting more money from the fools, of course."
I guess it collects money from some fools. Some people seem to be able to work fine with those tools and have no particular religious ties to it other than it gets the job done. To them, it is worth it I would wager. Besides, companies like the idea of support so even the free (as in beer) software is all over the place, they will probably like to pay some support for the added piece of mind (any business that didn't have some method of support - no matter the OS/software choice - for critical software is run by idiots). There's no real difference other than simply what people want to charge for support. Microsoft licensing is support costs. You pay Microsoft some money every year and keep the latest stuff they put out. You pay someone like your company every year (or per-incident) to make sure that the free (as in speech) software keeps working. The only difference is that your company choses a price schedule that is lower than Microsofts so you can bolster your religion by often pointing how much cheaper your services are than Microsoft's./shrug doesn't seem too different to me except that I can potentially choose to fly by the seat of my pants and put my business in jeopardy or I can potentially find someone more religious/hungry than you (and therefore more willing to have lower prices) to pay my support. In all honesty, it really just sounds like a bunch of IT folks who are pissed off because they can't get a piece of the OS support pie from Microsoft.
...but what if that functionality is something core to the design of the OS like Threads... at that point, upgrading the old OS is *making it* the new OS (Windows 98 => Windows XP for example).
So... you could rewrite the entire other OS (generating WindowsXP) and upgrade the older OS (Windows98) to the new OS (Windows XP), then install the product on it...
"Some IT managers may be dumb enough..."
What works for you might not work for others, and vice versa. Maybe you should see what they need to do before you make such broad statements. I'm not dumb enough to think that OSS/Linux will solve every IT problem in the world. I'm especially not dumb enough to recommend something without seeing what it is someone may actually want/need.
"Extremely well written" is very subjective. While there is typically a sufficient (or more than sufficient) amount of ASCII in files about something I am looking up, I personally find man pages very obtuse and very inconsistent. Do a 'man' on 'grep' or 'find' sometime and try to make anything out of that in 1 minute. I usually skip to the ends in hopes that there is an example of what I want to do (which runs about 50/50 chance of there being any example vs. lots of good examples).
Remember... when I am doing something, I don't want a 2 hour diversion from the task at hand to do something that should be simple... reading the book that is provided for many things by 'man' is hardly useful. I don't want to know every commandline option for a command (usually there is something like a flag of every letter of the alphabet and then some for some combinations - with little/no help on which ones are used together and such without spending large amounts of time searching for it). I will remember how to do what I want this time and add it to my knowledge of the command. Hopefully, I can search through the man page and get some hits on what I want to do.
There are lots of other things about 'man' that I don't like but I know how to use it and can get by. I think it can be improved a whole lot, though. (One simple way to help a lot of people out is to not have engineers write the documents as if another engineer is the audience. I am an engineer and I can read the things, my mother, however, cannot.)
"Why design Office XP so that it requires Windows XP?"
Well... I'll bite with an example (may not be the real reason but it is a reason)... Maybe there is new functionality that is included only in WinXP that they want to use for the new product. Win98 doesn't support it. By your logic, we should all still be programming to only the Un*x APIs that were present in the 1960s. No XWindows for you... no threads... can't use PERL either...
As far as backwards compatibility, you have to continue to provide and maintain *all* the old APIs *maintaining their semantics* in addition to the new APIs you provide... which leads to bloat and increased complexity as you rewrite the older APIs in terms of newer APIs. You aren't allowed to deprecate anything in that scenario.
You are doing double-duty... teacher and Linux Admin because it sounds like you are not only a teacher but a computer hobbyist as well. If/When you leave, will they be able to hire another such double-duty teacher to keep up with security and such? If not, will they have to hire two people in your place?
Slashdot Mirror
Don't mix shitty parallel computation libraries and actual performance. Multithreaded applications without MPI are, of course, faster than anything with MPI, however it says absolutely nothing about:
:)
/. /.ing itself?)
I assume you mean "don't use MPI on an SMP/NUMA machine if you want to get the highest performance out of this box". Anyone who knows anything about parallel computing knows the difference between message passing and SMP architectures and why this is the case, there isn't anything "insightful" about that.
Other than that, decent MPI communication library implemenations should do very well compared to native message passing on message passing architectures. I'd be willing to bet that an MPI app on a cluster of PCs is faster than pure multithreaded code on the same hardware.
Disclaimer: I have ported MPICH to a number of platforms as well as implemented a few MPI implementations from scratch.
(heh... took me 5 tries to post this message.... is
Ah... forgot about the graphics part... the other was about simple crunching. Yes, SGI has always had top of the line visualization capability. Nothing like playing Doom/Quake in a Cave.
Well... our experience with the O2K was a bit different (haven't touched an O3K though so I dunno much about it). With the Origins 2K and NUMA, if you ran large simulations, the distant memory would flat kill your performance so you had to make sure your working sets fit on a single node. Also, even though each processor board in the O2K had 2 CPUs, if you actually ran an even somewhat memory intensive process on each CPU, your app slogged because the memory bandwidth only supported about 1.4X the bandwidth of a single CPU. Another bad habit was that if someone snuck onto the machine when you were running your 64 process job and they fired up something like emacs, it would cause this nasty shifting around of memory that got you into the NUMA state mentioned above. Later, SGI came out with some tools that would minimize this effect though, which helped a lot.
So... in order to support the kind of stuff we did and run it on 64 nodes, we would have had to buy a 128 processor system because we would only run one process per node and all the nodes were two processors.
So, we also looked at the Sun10K. While the cpu to cpu comparison of raw crunch was lower, the memory bandwidth was uniform so the programs behaved predictably and were almost as fast in any case. It also had the benefit of running 1 process (as far as performance per process) wasn't noticably different from running 64 processes (on a 64 processor machine). At the time, the Sun10K met our needs much better.
Now, of course, all those have been shoved out the door and replaced by something even faster.
I think we all know what the GPL is supposed to mean, for people who cant see through the legalese it is clearly described in the FAQ on the GNU website ...
And this is why we have lawyers... to see if what we all "think" it is supposed to mean, what it is described to us in "layman's terms" as, and what the legalese actually says are all the same thing.
"If the processor was "better", it would actually do more with each clock cycle, instead of less."
No... not at all. "better" is subjective and you can't simply "prove" this. If the P4 had an IPC of 1, but could reach 1THz, it would still be fast . It's about tradeoffs... the more you try to "do" in a clock cycle, the more circuitry you have to have actually "doing" something. You also have to have the added complexity of the reordering logic and dispatch logic to try to extract as much parallelism out of the instruction stream as you can. This, of course, makes chips more and more complex (read: harder to test, design, etc.).
Back in the day, there were two schools of design philosophy. The "Brainiacs" believed in doing more per clock. The "Speed Freaks" believed in designs optimized for increased (and increasing) clock speed.
One of the things I think the Brainiacs realized is that the more you try to do in a single clock, the bigger and more complex the cpu becomes, and it is a greater than linear increase in complexity. Complexity causes the clock speed to be hard to increase (longer pathways may result from the increased complexity = lower clock speeds). The Speed Freaks aren't without their problems either -- I/O (keeping the cpu fed), heat, clock signals, etc.
Design approaches like Intel's EPIC are a hybrid of the two approaches, to some degree. It is supposed to make the chip design more simple, eliminating a lot of the forwarding/ordering logic in the CPU, by offloading these responsibilities to the compliers (which have to become more complex). At the same time, it provides a 'wide' set of execution units. This idea is to make the CPU simpler, which helps increase clock speed, while not sacrificing compute power (because you have a bunch of execution units). The challenge of the compilers is to keep all the execution pathways in the EPIC cpu full. Of course, with this design philosophy, you are at the mercy of the quality of compiler writers. EPIC tries to tradeoff complexity/speed in this way. Of course, Intel is having its share of problems getting EPIC to fly (chicken and egg problem with software to some degree, cost, etc).
Which is right? It's a matter of preference I guess. Both designs enable fast parts. I guess the only real question in my mind is which design more future value (to the company that is making the cpus) -- how much of today's design can be reused when going forward? how hard is it to come out with version++ from where you are today? how hard is it to get more performance than what we have today?
a good programmer makes fast tight code
/shrug.
I'd agree with this as long as you add 'maintainable'. If tight/fast was your only goal, you wouldn't use GUIs... which are typically much better for end-user interaction and efficiency, for example. If tight/fast was your main goal, you wouldn't use a multi-tasking OS... you'd only make single-purpose devices programmed to the bare silicon.
One of my theories that Un*x and Un*x-like programmers are typically stronger (although, there are plenty who are not very strong) is that they have to do so much more work to get things to 'go'. For instance, it isn't enough that I know C. I have to also know make... and probably either vi and/or emacs.... and dbg or some other debugger... and man... and possibly autoconf... and the list goes on.
On Windows, the environment is pretty easy to use, especially for less skilled people. It makes programming less '3l337'
I agree somewhat though... a good hardware class and some assembly would do many programmers good though. If nothing else, it lets them know what goes on behind the languages they use. Once you write a bit in assembly, pretty much any other computer language isn't that big of a deal.
mmmm... no
IANAL but...
You buy something, you can tear it apart and learn about it at home all you want. You can't use that knowledge to make more of them though and you can't post the information you learned for others' consumption.
I've taken apart all sorts of stuff to find out how it works. Never has my house been raided. Of course, I never posted it or tried to make more of them either.
-. Make sure you provide the rest of the world, especially those far behind our country, with the tools, material, and examples needed to learn and further their own technological advancement beyond your own. Let our brightest minds teach the rest of the world so that they can compete better in technological fields.
"They are released ahead of any *windows* 64-bit drivers for Nvidia cards."
Could be because they are released ahead of any *windows 64-bit OS*. Windows-64 hasn't been released yet. Linux already supports 64-bit CPUs. Not hard to do the math.
"I tried Linux but it was too hard for me to install, then that guy flamed me on the newsgroups"
Heh... reading the replies to this post made me think back to this line.
Maybe folks would take his working for them as a sign that it might be done right... that his guiding hand might make it better...
Yes... but the individual components in the mainframe isn't the issue... the whole system is counted as one machine... and some of those haven't been down in many years. Basically, even though individual components of the machine may have been taken down, removed, or upgraded, the job that the machine does hasn't stopped.
We had legal licenses and we didn't have to pay nearly this much. There are Enterprise class licenses that you can take advantage of (at least, we purchased Enterprise class licenses).
Also, you forgot to add training and such for Linux and the equivalent applications that they will be using. Since his users already probably know windows and those applications, give his 400 employees a week of training (will incur this expense anyway as people try to figure out what they are doing and general get-up-to-speed time accounting for productivity lost from the year for learning the new stuff). Assuming that the average salary for his employees is $26000/year (makes the math easier):
400 x $500 = $200000
Using your numbers, the Windows costs $344,600 per year for the first year.
The first year for your Linux solution is $450,000.
Now, we can start talking about the non-recurring costs for the next few years.
Of course, you assume that all the software that his company will be using on Linux has no cost (free as in beer), which is STUPID, STUPID, STUPID for a company to do. You'll want to pay for support for your Linux distros. Even using RedHat you will have 400 seats at $40 at least, $149.95 for the "Professional Version". One seat you'll have to be a server - $2499 for RedHat Advanced Server with best support. $995 for RedHat's Stronghold Secure Web Server.
400 * 150 = $60,000
1 * 2500 = $2500
1 * 995 = $995
So... about 1/2 the software costs.
So... now the total, using your numbers and mine (without training, this is the years after the first),
Windows = $344,600
Linux = $310,000
We were also a part of a larger group of folks, around 20 of us total I think, who admin'd about 2000 Suns, about 200 SGIs, a smattering of AIX boxes, a few NetBSD boxes, and about 8000 x86 PCs running everything from Windows98 to Windows NT to Novell.
Just because you don't know how doesn't mean that others don't either.
At the same time, we also admin'd about 70 Sun machines, around 20 Linux boxes, and a couple NetBSD boxes.
Where I worked there were two of us maintaining approximately 100 Windows machines (I can't remember the exact number but it was around 96 or so).
...and did you actually earn an income during this time? and if so, who was paying it?
get a clue... Microsoft doesn't make the BIOS. You've been indoctrinated into the religion well it seems.
... I thought IE was given away free?
Anyway... there were two things that prevented Netscape from being successful. First, apathy of users to download/install anything else (particularly when what they had worked fine for them). Second, Netscape was garbage.
So, back to the question in my previous post... What about the GNU tools? What about a lot of other stuff that 'comes for free' in a Linux distro? To borrow your words...
Every 'customer' of Linux using GNU tools must 'buy', install, support, and regardless and in fact use the GNU tools. No other product has a chance in hell of being successful.
You can lie all you want about what GNU did or did not do...
yada yada yada, you get the point.
How much of a chance do I have of writing and selling (either licensed or as support) my own version of the GNU tools? What about LaTeX? or a text editor to compete with VI or emacs? Would I be a fool to even try? Sounds like the same thing to me... Mr. Pot, meet Mr. Kettle.
And yes, a company that I helped startup did (and still does) compete in the OSS world (for 7 years now - Linux support and sales is always the lowest numbers). Many people who contacted us about our product balked when they learned that we (gasp) actually charged any money at all for purchase or support for our products. They wanted it free and they wanted the source. Their alternative was to go with some stuff that was OSS and was substandard by any means (buggy, slow, inefficient, and basically junk) for the *only* reason that they thought it was free (as in beer). They were willing to use some software that they would freely admit was poor quality (poorer than ours, they would freely admit this themselves) simply because they could download it for free and not pay support costs. What's funny was that the 'free' stuff really wasn't free because they had to have someone work on it all the time to get it running and keep it running. (How do I know this? because I helped write the OSS stuff as a small part of a collaborative project and their design decisions made the code pretty nasty. We started a company so we could do better and offer support and such for it). Unfortunately, the OSS world is not very nice to try to do that sort of thing in.
So... yes... the company I worked for *and* helped start up competed in that environment. Luckily, we were able to diversify well and we offer a wide variety of products on a number of platforms. It's very hard to make a living in that environment unless you are just selling IT Support type contracts. Programmers have a hard time keeping themselves fed.
The whole part about OSS is generally written by hobbyists and such I believe. The ironic thing is that many of those people work as programmers or whatever for companies who pay their salary so they can do hobbyist things and write code to give away for free in their off-time. These practices makes it difficult for other programmers (who usually sell their time/skills in order to pay their bills) to compete in the marketplace because you can't develop applications and expect to sell them. In the same breath, these hobbyists usually say how bad proprietary things are.
Basically, OSS is a great boon and marketplace for IT (can you say job security?) but pretty lousy for programmers. Usually, a new application is written and paid for in advance of sales - either through private or venture funding or from monies made from the sale of other products/services. That is the up-front costs for application development. After the product is written, you then hope to make your money back and then some on product sales and/or support contracts.
Heh, since a large number of people who use Linux want their software free (and don't want to pay support either), where does the money come from to pay the programmers who developed the application? (Hint: it comes from the companies that the hobbiests work for who indirectly subsidize the code that the hobbyist writes.)
And people wonder why there aren't many games on Linux boxes...
The hurdle that must be overcome for software to compete with bundled software is apathy (aside from subversive techniques such as making a JVM that doesn't run 'standard' java codes). Other than this, there is no reason why Netscape couldn't be installed on a Windows box and used (I know many people who used Netscape on Windows platforms and I've seen Netscape installed on hundreds of Windows machines). Why did it fail? It was offered for free just like IE (I don't know of a single person who actually purchased it). Many would say that IE was a superior product. I know that even on Un*x boxes I couldn't load 5 sites in succession without SEGVing Netscrape and my experiences on Windows were about the same. If Netscape was better, why didn't it win? If it were better, it wouldn't have mattered that both were free or that one was bundled any more than almost all Linux distros come bundled with a browser.
By the same token, I would ask who out there uses alternately developed/packaged tools to the GNU tools provided on Linux? By your logic, the GNU tools impede the innovation of standard command line utilities (ls, tar, bzip2, vi, emacs, grep, find, man, cd, etc.) How many alternatives do I have for those tools? How many people do you know who use alternative C/C++ compilers to GCC (and why do so many people use GCC and why aren't there many alternatives to GCC)? How much success would I have to develop an alternative help system to replace 'man'? If you say I'm stupid for even thinking of wanting to replace 'man', I might consider the GNU tools to be a barrier to my innovation in those areas.
IF the man pages were converted to HTML (which is a pretty good thing actually imo, because you can hyperlink to related topics and such), all Linux distros would have to deliver a browser in order to read them. I've seen *many* people use Netscape out of apathy, they simply know that Netscape exists and don't try any other browser. For these people (who also qualify as a significant portion of non-technical users), whatever browser delivered or installed for them by the IT group would be what was used. I know that I rarely install any other browser on Linux boxes I set up... as long as what's there works reasonably well, there isn't a strong enough reason to mess around with it unless some user requires or requests something new. If one distro became vastly dominant (maybe RedHat or UL), your argument would begin to apply to the Linux world as well.
As far as markets that are 'strongly owned' by Microsoft, the only ones that I personally see regularly are IE (if you count this as a product, I don't because it is integral to the OS just like more/man is), a development environment (I haven't found any on Windows better), Office (I hate productivity suites anyway, regardless of which - I prefer LaTeX for papers and such), and SQLServer (which, IMO is much easier and cheaper to get good performance out of than Oracle). Of those mentioned, only one of those is bundled or even free.
For listening to MP3s, WinAMP is used by almost everyone I know, some use that Musicmatch thing. For archiving/compression, WinZip. DiVX codecs for movies. Burning CDs I use Nero. PDF files and Realplayers and Quicktime. If you really wanted to dodge Office you could use one of the alternatives.
As far as bad design, I can't tell you the number of things I've downloaded on my Linux box that required some version of some library later than what I had. The only difference is that I can usually download the library to make up for it (usually leading into a nightmare of dependency issues).
So far, the main issue I see with your posts is that you don't like the idea of the next Office suite requiring a later version of the OS to run. Except for subscription licensing (which I don't like either) and interoperability, there is nothing that prevents me from continuing to run Win98 and a version of Office that runs on that OS for the rest of my life without paying another penny. Just because the next thing is out doesn't mean that you have to upgrade if what you have serves your needs. I know of a group who runs Apple ][e machines and software to this day because it has software on it that completely suits the need. They don't plan to upgraded until they can no longer find spare parts.
There are very few things that you are 'locked' into using other than by your own ignorance or by your own choice. I just don't buy the argument that Microsoft 'makes' you buy anything after your initial investment (except for subscription licensing and Microsoft was by far not the first company to do that... ever run a VAX?)
"But, what it does point out is that bundling crap with the OS is always a bad idea."
/shrug doesn't seem too different to me except that I can potentially choose to fly by the seat of my pants and put my business in jeopardy or I can potentially find someone more religious/hungry than you (and therefore more willing to have lower prices) to pay my support. In all honesty, it really just sounds like a bunch of IT folks who are pissed off because they can't get a piece of the OS support pie from Microsoft.
So.... all the GNU tools should be removed from Linux distros?
"1. bundling increases the cost for everyone"
True.
"2. bundling suppresses advanced technology by eliminating fair and open markets"
This is a hard one... Let's use IE for a hypothetical example... Let's suppose that Microsoft wanted to standardize all of its Help files, online documentation, and every other 'printed' documentation in the system to HTML. Let's then suppose that it seems that a browser can be generalized (at least conceptually) to be able to view just about anything on the system... such as file systems, system parameters, configuration files, system resources, etc. What if it then seems a good idea to make the 'standard' human interface to the OS be a browser. Basically, one application that 'does it all'. This might sound like a good idea because then it is only one app that has to be written to do all these things (maybe through the extensive use of plug-ins or some custom interfaces), which can be seen as a 'good thing' for the programmers because there may be less duplication of effort across the board - why have a seperate help viewer and custom file format for help AND have a view that can view HTML - especially when the help file format really just wants to be HTML, and it can be seen as good for users because they only have to remember one thing that 'does it all'. This mega-app would then have to be bundled with the system so you could view help files, navigate directories, view the web, etc. Without bundling this piece of software, you wouldn't have very much fun on the system. So... you get integration of a 'browser' throughout the system... something that is familiar to a user to use no matter what they are doing. Mom and pop like familiarity and non-obscurity.
"The result is harm to the industry and consumers."
What you consider "harm", others may consider beneficial. See above.
"As for the change in "threads", I doubt that threads have anything to do with the new features in Office XP. More likely than not any additions to Office XP could be completely contained in the application itself."
I agree... I was using "threads" as an example of something that is a basic core design principle of an OS... whether it supports it or not. You can't simply shoe-horn threads into an OS or you get some abomination like cooperative pthreads.
I have no clue as to why OfficeXP has to only run on WindowsXP. I can make the assumption that it is purely for renewed licensing and to cause more upgrades to WindowsXP. However, I have no evidence either way and to write it off to the conspiracy theorist mindset without more knowledge is foolish. That being said, I wouldn't be at all suprised if this was the case but I cannot simply proclaim that it is without having evidence (no... past actions are not evidence... they only show a predisposition to do this).
"Gosh, if OpenOffice/StarOffice, Mozilla and others can run on Linux, Microsoft Windows, Unix, the Mac and others then the idea that the OS must be custom to permit the application to run is just silly."
Yes, it would be silly.
"Requiring the OS to be upgraded harms consumers directly by greatly increasing their costs to benefit from new applications. And, that additional cost should be avoided if at all possible."
As does support of legacy software... I supported a product that had originally been written on VAX machines but later had frozen on those machines and was ported to Un*x and WindowsNT. The policy of the company I worked for was that software was supported until the last customer migrated. We had to keep two VAX personel on the roster all the time, although no new development had been done on the VAX for 4 years - but we had customers who didn't want to migrate to the newer system. Those developers had to be paid some way. We could have simply upped the support costs to astronomic values for that one customer I guess, but we chose to subsidize the developers from the new software. In this case, it was more expensive to all because we had to support the old stuff instead of letting it fade away.
"Of course, Microsoft could care less about saving customers money and is only interested in forcing customers to upgrade so that the bundled applications are more pervasive. And, collecting more money from the fools, of course."
I guess it collects money from some fools. Some people seem to be able to work fine with those tools and have no particular religious ties to it other than it gets the job done. To them, it is worth it I would wager. Besides, companies like the idea of support so even the free (as in beer) software is all over the place, they will probably like to pay some support for the added piece of mind (any business that didn't have some method of support - no matter the OS/software choice - for critical software is run by idiots). There's no real difference other than simply what people want to charge for support. Microsoft licensing is support costs. You pay Microsoft some money every year and keep the latest stuff they put out. You pay someone like your company every year (or per-incident) to make sure that the free (as in speech) software keeps working. The only difference is that your company choses a price schedule that is lower than Microsofts so you can bolster your religion by often pointing how much cheaper your services are than Microsoft's.
...but what if that functionality is something core to the design of the OS like Threads... at that point, upgrading the old OS is *making it* the new OS (Windows 98 => Windows XP for example).
So... you could rewrite the entire other OS (generating WindowsXP) and upgrade the older OS (Windows98) to the new OS (Windows XP), then install the product on it...
"Some IT managers may be dumb enough..."
What works for you might not work for others, and vice versa. Maybe you should see what they need to do before you make such broad statements. I'm not dumb enough to think that OSS/Linux will solve every IT problem in the world. I'm especially not dumb enough to recommend something without seeing what it is someone may actually want/need.
"Extremely well written" is very subjective. While there is typically a sufficient (or more than sufficient) amount of ASCII in files about something I am looking up, I personally find man pages very obtuse and very inconsistent. Do a 'man' on 'grep' or 'find' sometime and try to make anything out of that in 1 minute. I usually skip to the ends in hopes that there is an example of what I want to do (which runs about 50/50 chance of there being any example vs. lots of good examples).
Remember... when I am doing something, I don't want a 2 hour diversion from the task at hand to do something that should be simple... reading the book that is provided for many things by 'man' is hardly useful. I don't want to know every commandline option for a command (usually there is something like a flag of every letter of the alphabet and then some for some combinations - with little/no help on which ones are used together and such without spending large amounts of time searching for it). I will remember how to do what I want this time and add it to my knowledge of the command. Hopefully, I can search through the man page and get some hits on what I want to do.
There are lots of other things about 'man' that I don't like but I know how to use it and can get by. I think it can be improved a whole lot, though. (One simple way to help a lot of people out is to not have engineers write the documents as if another engineer is the audience. I am an engineer and I can read the things, my mother, however, cannot.)
"Why design Office XP so that it requires Windows XP?"
Well... I'll bite with an example (may not be the real reason but it is a reason)... Maybe there is new functionality that is included only in WinXP that they want to use for the new product. Win98 doesn't support it. By your logic, we should all still be programming to only the Un*x APIs that were present in the 1960s. No XWindows for you... no threads... can't use PERL either...
As far as backwards compatibility, you have to continue to provide and maintain *all* the old APIs *maintaining their semantics* in addition to the new APIs you provide... which leads to bloat and increased complexity as you rewrite the older APIs in terms of newer APIs. You aren't allowed to deprecate anything in that scenario.
One issue with this...
You are doing double-duty... teacher and Linux Admin because it sounds like you are not only a teacher but a computer hobbyist as well. If/When you leave, will they be able to hire another such double-duty teacher to keep up with security and such? If not, will they have to hire two people in your place?