Also try Zelda: 4 Swords Adventure and Final Fantasy: Crystal Chronicles for the cube. Both have multiplayer built in. The downside is you need a GBA for each player. The only reason I got a GBA was to play those with my girlfriend.
I have to keep the PS2 around though. She loves DDR with the dance pad controllers.
Yeah, cause those of us that are over 30 don't know how to play these new-fangled video game thingies. Buy yourself a clue and get back to us with a theory that isn't based on the idea that 30 equals really old.
Even my parents aren't intimidated by the controllers. My mom tends to be intimidated by games like SSX where she has to press 5 buttons at the same time while simultaneously using both the D-pad and the analog stick, but that's something else entirely. Give her a nice platformer and she's fine. Did I mention she's getting close to 60? Granted, she may not be the average mom when it comes to video games, but you need to give older people a little more credit.
Every couple years, the military announces some new project to modernize the infantry. Millions are spent on R&D and then the project gets shelved because it will cost too much to issue it to every grunt.
I remember back in the early '90s they promised us kevlars with built-in GPS, 12 channel comms, and a heads-up display with topographical overlay and targeting reticle.
It's been twelve years and the only changes to my issue equipment are the new pads in the parachutist helmet and the addition of a Camelback.
My field gear has changed quite a bit, but most of it isn't issue. Blackhawk tactical vest, Blackhawk thigh rig, Magellan GPS, Motorola GMRS handheld two-way radio, etc, etc.
The only time we'll ever see this stuff actually used in the field is when it's cheap enough that individual soldiers can purchase it themselves.
What electronic equipment? The typical US soldier is carrying a Garmin or Magellan GPS and a Motorola handheld radio, both purchased at his/her own expense. SINCGARS are generally limited to vehicles and platoon RTOs. A squad may have an Iridium phone. The only issue electronics that might qualify as typical are NVGs, and that depends on the unit.
1)Provide a consistant interface to applications regardless of changes to the underlying database structure. 2)Enforce row level security. 3)Enforce data integrity.
Trees in relational tables without recursion is a problem that has been solved for years. http://www.sqlteam.com/item.asp?ItemID=8866 It is trivial to implement nested sets with a few lines of SQL and after the tree is constructed, a simple SELECT will give you children, descendants, or ancestors.
I think you've missed the point of stored procedures. The point of stored procedures is to provide an abstraction layer between the underlying database and applications. Additionally, they are the best place to enforce data integrity and they are extremely useful in implementing row level security.
Control over performance? I have just as much control over the performance and optimization of stored procedures as I do of functions written in any other language. And I don't have to do anything special to instrument the code. All I have to do is review the trace logs and execution plans to find bottlenecks.
Sure, you probably don't want a stored procedure to go out and pull a credit bureau report or something equally asinine but any application logic that doesn't have to access anything outside the database is fair game.
And when management wants to run business information reports on typical day-to-day stuff stored in an OODBMS, what then? Are you suggesting that the information found in your objects be duplicated in a relational database so that useful queries can be run? Or are you going to crush your server by having it walk every object?
If the impedance mismatch is so huge, maybe OO isn't always the answer? Have you considered that creating a well defined procedural interface may be more suitable for many applications? OO can result in easier to read front-end code but can also add a lot of complexity under the hood.
If you can afford a multi-tier architecture, you can afford a good RDBMS person. The Java programmer writes the Java code and the database developer writes the stored procedures. The database developer is used to set operations and understands how the RDBMS handles things under the hood.
The database applications I develop run on dedicated servers. There is no reason to ever change the RDBMS once the application is put into production. If it ain't broke, don't fix it.
Not using stored procedures doesn't buy you much in portability anyway. Take an application written for Oracle and try to run it against SQL Server and see how far you get. If you use any conversion functions, you're screwed, and if you use dates, you're going to be using conversion functions.
Government needs to own or heavily regulate base infrastructure. This includes roads, power, water, and telecom.
This can be a double edged sword, but I agree on the whole. Government is more likely to improve infrastructure for the benefit of the people than a corporation is to cannibalize their existing monopoly.
If by historically you mean 3.1 and by nowadays you mean 98 or NT4, you are correct. XP does not have a lot of these problems.
I just installed Visual Studio 2005 Express last night. I had to reboot after installing the.NET framework. Given what the framework does, I suspect that would be roughly equivalent to recompiling the kernel in Linux.
Installed IIS. No reboot. Installed C++. No reboot. Installed C#. No reboot. Installed SQL Server. No reboot. Hmm. I'm starting to see a pattern here.
On the other hand, a game I installed last week required a reboot so it could finish installing its Starforce copy protection drivers. Started having crashes, so I uninstalled the game. Starforce wasn't uninstalled with the game. The Starforce developers indicated that was by design.
When you refer to the Windows security system, I assume you mean Access Control Lists. ACLs aren't unique to Windows. Linux started including them as an option a year or two ago.
The standard *NIX owner, group, world set of permissions is not sufficient in many environments. A finer degree of control is often needed. ACLs provide that degree of control.
A SID is basically a globally unique user/group id. Some of the POSIX ACL implementations are already using SIDs.
If you want to bash on Windows security, the access control model isn't the place to do it. There are issues in other areas but even the most recent POSIX efforts fall short of what NT4 provides in access control.
It's a matter of scale. It takes longer to write. It takes longer to debug. It takes longer to maintain. You also have to account for other actions the user might take while you're waiting for the first one to come back. And when you're writing zero footprint applications, theres a big difference between 7k lines of code and 25k lines of code.
Sorry, I thought the traversal was apparent from the structure of the tree. The reports_to_employee_id is i_parent from my example. The tree table is more expensive to initially build than a simple parent child table but much faster to retrieve from.
Web developers only test IE because trying to make sure the site looks and acts the same with other browsers can substantially increase the cost.
It's one thing if the web site is strictly about presenting content. That's easy and doesn't take very much extra time. If you're writing web applications, it's a whole different story. Everything absolutely positively must look and act the same on all supported platforms. Period. You can't write documentation or train end users if the interface is different on their browser.
Look the same isn't the problem. Act the same can be. You want web developers to take more of an interest in FireFox? Support showModalDialog. Seriously. showModalDialog is huge. Opening a dependent window and screwing around with the onblur event doesn't even come close to what showModalDialog can do for you.
The big advantage to showModalDialog is that the calling code blocks and waits for showModalDialog to return before continuing. This is great in applications because the alternative is often shipping requests across an iframe and setting an interval timer to keep checking if the iframe has finished loading.
showModalDialog
function doSomething(id) {
var x = window.showModalDialog('../actions/doSomething.asp ?id=' + id);
if(x[0] == -1) {
error(x[1]);
return;
} /* do stuff */ }
I *have* written an arbitrary depth tree traversal in SQL. The use of temporary tables is limited to caching results from row level security logic that determines which nodes a given user can access. It's not as difficult you make it out to be.
/* Sample Script */ CREATE TABLE t_object(
i_object INT IDENTITY(1,1) NOT NULL,
i_left INT NOT NULL,
i_right INT NOT NULL,
i_parent INT NOT NULL,
vc_name VARCHAR(50) NOT NULL ) GO INSERT INTO t_object (i_object, i_left, i_right, i_parent, vc_name) VALUES( 1, 2, 0, 'ROOT') GO CREATE PROCEDURE add_child @Parent INT, @Name VARCHAR(50) AS
DECLARE @Right INT
SET @RIGHT = i_right FROM t_object WHERE i_object = @Parent UPDATE t_object SET i_right = i_right + 2 WHERE i_right >= @Right UPDATE t_object SET i_left = i_left + 2 WHERE i_left > @Right INSERT INTO t_object ( i_left, i_right, i_parent, vc_name ) VALUES( @Right, @Right + 1, @Parent, @Name ) GO /* End Sample Script */
The above example is a basic implementation of a tree. I left out indexes, transactions, error handling, and so forth for the sake of brevity. The important thing to note is that a descendant of a node will always have left and right values between those of its parent. Move, Copy, and Delete are left as exercises for the reader.
The real problem with SQL NULLs is SQL programmers that don't understand SQL NULLs. An ANSI standard SQL NULL has an unknown value. Since the value is unknown, any logical operation involving a SQL NULL will always return FALSE. NULL = NULL returns FALSE. NULL != NULL also returns FALSE. It can be inconvenient in WHERE clauses, but that is the standard.
The patent office gets funded based on how many patents they approve. Not how many they examine. I'd say they live in exactly the same world as the rest of us.
The 5 year vesting often only applies to the lower ranks. Top level executives often receive options with either no or shorter vesting periods.
But lets put that aside for a bit. The real problem is that not expensing options is far too easy to abuse. Company grants options for 50 million shares. When options are exercised, company issues 50 million more shares. This doesn't impact the company bottom line at all. There is still no expense incurred. The only measurable effect is that earnings per share goes down. Then after several years of this, the company takes a one time charge to repurchase the stock they issued to cover the options.
That's not even taking into consideration the dilution of ownership caused by excessive option granting.
I would rather they didn't. It leads to short term business practices that damage the company in the long term. The executives responsible have already cashed out and moved to another company before the negative consequences start to show in the bottom line.
As an example, the corporation for which I work use to own a number of large facilities around the country. The land and buildings were owned outright so there were no loan payments to consider. A few years ago, all of the facilities were sold with the new owners granting a 20 year lease. This made the bottom line look really good that year. A few years later the rental expense is a significant impact that could have been avoided.
The executives who made that decision don't care. They made millions from it. Many of them took offers from other companies.
So, what's the solution? I don't know. I do know that executive stock programs have only made things worse.
As an anonymous coward stated above, Apache is irrelevant in the grand scheme of things. It's middleware. If you're connecting to Active Directory, SQL Server, COM/DCOM components, or any number of other things, Microsoft could care less whether you use Apache or IIS as middleware. You're using their backend and that's where they make their money.
You're leaving out the cost of additional internal support. You're forgetting that customization of your environment leads to additional hassles applying patches and upgrades. Finally, you're forgetting that switching hardware costs money.
Ask yourself this: On how many thousands of computers would I have to save $100 per license to pay for a small team of programmers with secret or better security clearances for three years? If you figure a small team is 5-6 programmers, it works out to around 20,000 computers.
On how many more thousands of computers would I have to save $100 per license to pay the additional sysadmins, QA, and help desk personnel? What about the project managers that coordinate all these efforts? What about the additional oversight and compliance officers that ensure all of these activities meet regulations and standards?
As you can see, it quickly gets to a point where using a free as in beer product and supporting yourself is more expensive than buying from a vendor and getting a support contract.
A small to medium size business may save some money, but once you grow past that, it just makes more sense to pay for support.
It helps that the gamecube has been retailing for $99 for a while. At that price point it starts to look like a possiblity once 8-10 must have games are in the bargain bin for $25. With accessories (2nd controller, memory cards), you're looking at about a $15 premium per game. So you end up spending about $10 less than original retail for each of the must have games.
Once the X-Box drops below $100 I might consider it. It's going to be a tough sell though. Right now there are only 5 or 6 X-Box exclusives that I'd be interested in. With the X-Box 2 lacking backward compatibility, I'll probably pass over the current X-Box and wait to see if the X-Box 2 hits an attractive price point and has a bunch of killer exclusives.
In contrast, I bought a PS2 launch day. I already had 50-60 PS1 games. It played DVDs out of the box, so I didn't have to buy another DVD player for the second TV. DVD players at the time were still running around $200. I looked at it as getting a console for less than $100 after trading in my PS1. The launch titles were mostly crap, but it didn't matter. I had some PS1 games I hadn't finished yet and some high profile developers had already committed to releasing some high profile games on the PS2. The PS2 was out for quite a while in Japan before it was launched here. We already knew some cool stuff was coming our way once it got localized. Microsoft doesn't have that advantage.
You mean end user type applications? Well, that depends on the application. If the application accepts command line arguments, you can use those from a command line or batch script. If the application provides a COM interface, you can automate through that using WSH or some other scripting environment.
I can't say whether it is the norm for applications to do this. I develop financial systems and processes for a large institution. I can say that the only task I haven't been able to automate in our environment is using Rumba to screen scrape a mainframe report into a data file. It could be that the version of Rumba we use is out of date and a newer version would solve the problem. The newer versions haven't been approved yet.
Just about any Microsoft application can be installed from the command line. For other applications that do not natively offer unattended installation, a package can be created and pushed out using Microsoft SMS or a similar service.
The area where Microsoft continues to have issues is remote management of server software. Their standalone software is generally pretty good. I can't think of anything in SQL Server 2K that I can't administer remotely. The software integrated into the operating system is another matter. IIS is my biggest headache in this category. Most of it can be managed remotely but there a few things that require trips to the server room.
As for TCO, lets talk about the desktop first. Large corporations are going to pay for vendor support. If a bug occurs in a critical component, and the vendor does not resolve it in a timely manner, the vendor may be contractually obligated to make restitution. When you're dealing with lots of money, "We didn't think about that. We'll put that into our next milestone." doesn't cut it. The purchase and maintenance cost of Red Hat Enterprise Linux and Windows is pretty comparable. It's probably reasonable to assume that the long term administration costs will be similar as well. Short term costs of switching will be higher since all of the administration procedures will have to be rewritten.
Somebody mentioned training costs earlier. This is where Linux gets kicked in the teeth. Linux is sufficiently different that 99% of our employees will either have to take training classes or spend a lot of time figuring it out instead of doing productive work. When you have 125K employees just in North America, that really adds up.
Then any in-house application software using Win32 has to be rewritten. In our case, this isn't going to happen, because we just spent several years and lots of money moving it from X to Windows.
For a small company, the training costs and lost productivity may not be as much of a factor. For a large company with a significant software support and services division in-house, like IBM, vendor support may not be necessary. For nearly everyone else, Linux TCO is going to be comparable or higher than Windows.
On the server, a good case can be made for Linux. Personally, I might lean towards *BSD on a smaller server, but last I checked, the *BSDs weren't ready for big boxes. It depends on what the server is going to be used for though. In a big company, where most of the servers are used for fileshares, it _may_ make more sense to use Windows when most of your workstations are running Windows.
You must work for an ISP that charges extra for additional IPs. For the rest of us, NAT is what allows us to have all our computers on a LAN without having to pay our ISP extra $$$ per month per IP address.
In the real world, you generally don't write an application targetted to a specific CPU. You trust that your compiler is generally going to produce efficient machine code for your algorithm. Sometimes it won't, but if there isn't a performance problem with that particular section of code it usually isn't worth the effort to do anything about it.
The point of using a profiler to optimize your application is that usually you're going to identify a couple key areas where you need to do some tuning because your algorithm is not efficient regardless of the architecture on which its running.
Further, within the x86 family, different CPUs have different performance characteristics. The most efficient machine code on one may be the slowest on another. So to write the most efficient programs for x86, according to this guy's definition, I would end up having to implement run time CPU checking with different code paths depending on the result.
Guess what? It isn't worth the additional development time unless the result is substantial. How do we know which improvements would be substanial? We profile the code.
This guy needs to take a leave of absence from teaching and work as a programmer for a while before he shoots off his mouth on topics where he clearly has no clue.
Slashdot Mirror
Also try Zelda: 4 Swords Adventure and Final Fantasy: Crystal Chronicles for the cube. Both have multiplayer built in. The downside is you need a GBA for each player. The only reason I got a GBA was to play those with my girlfriend.
I have to keep the PS2 around though. She loves DDR with the dance pad controllers.
Yeah, cause those of us that are over 30 don't know how to play these new-fangled video game thingies. Buy yourself a clue and get back to us with a theory that isn't based on the idea that 30 equals really old.
Even my parents aren't intimidated by the controllers. My mom tends to be intimidated by games like SSX where she has to press 5 buttons at the same time while simultaneously using both the D-pad and the analog stick, but that's something else entirely. Give her a nice platformer and she's fine. Did I mention she's getting close to 60? Granted, she may not be the average mom when it comes to video games, but you need to give older people a little more credit.
Every couple years, the military announces some new project to modernize the infantry. Millions are spent on R&D and then the project gets shelved because it will cost too much to issue it to every grunt.
I remember back in the early '90s they promised us kevlars with built-in GPS, 12 channel comms, and a heads-up display with topographical overlay and targeting reticle.
It's been twelve years and the only changes to my issue equipment are the new pads in the parachutist helmet and the addition of a Camelback.
My field gear has changed quite a bit, but most of it isn't issue. Blackhawk tactical vest, Blackhawk thigh rig, Magellan GPS, Motorola GMRS handheld two-way radio, etc, etc.
The only time we'll ever see this stuff actually used in the field is when it's cheap enough that individual soldiers can purchase it themselves.
What electronic equipment? The typical US soldier is carrying a Garmin or Magellan GPS and a Motorola handheld radio, both purchased at his/her own expense. SINCGARS are generally limited to vehicles and platoon RTOs. A squad may have an Iridium phone. The only issue electronics that might qualify as typical are NVGs, and that depends on the unit.
It's just you. I use stored procedures to:
1)Provide a consistant interface to applications regardless of changes to the underlying database structure.
2)Enforce row level security.
3)Enforce data integrity.
Trees in relational tables without recursion is a problem that has been solved for years. http://www.sqlteam.com/item.asp?ItemID=8866 It is trivial to implement nested sets with a few lines of SQL and after the tree is constructed, a simple SELECT will give you children, descendants, or ancestors.
I think you've missed the point of stored procedures. The point of stored procedures is to provide an abstraction layer between the underlying database and applications. Additionally, they are the best place to enforce data integrity and they are extremely useful in implementing row level security.
Control over performance? I have just as much control over the performance and optimization of stored procedures as I do of functions written in any other language. And I don't have to do anything special to instrument the code. All I have to do is review the trace logs and execution plans to find bottlenecks.
Sure, you probably don't want a stored procedure to go out and pull a credit bureau report or something equally asinine but any application logic that doesn't have to access anything outside the database is fair game.
And when management wants to run business information reports on typical day-to-day stuff stored in an OODBMS, what then? Are you suggesting that the information found in your objects be duplicated in a relational database so that useful queries can be run? Or are you going to crush your server by having it walk every object?
If the impedance mismatch is so huge, maybe OO isn't always the answer? Have you considered that creating a well defined procedural interface may be more suitable for many applications? OO can result in easier to read front-end code but can also add a lot of complexity under the hood.
If you can afford a multi-tier architecture, you can afford a good RDBMS person. The Java programmer writes the Java code and the database developer writes the stored procedures. The database developer is used to set operations and understands how the RDBMS handles things under the hood.
The database applications I develop run on dedicated servers. There is no reason to ever change the RDBMS once the application is put into production. If it ain't broke, don't fix it.
Not using stored procedures doesn't buy you much in portability anyway. Take an application written for Oracle and try to run it against SQL Server and see how far you get. If you use any conversion functions, you're screwed, and if you use dates, you're going to be using conversion functions.
Government needs to own or heavily regulate base infrastructure. This includes roads, power, water, and telecom.
This can be a double edged sword, but I agree on the whole. Government is more likely to improve infrastructure for the benefit of the people than a corporation is to cannibalize their existing monopoly.
If by historically you mean 3.1 and by nowadays you mean 98 or NT4, you are correct. XP does not have a lot of these problems.
.NET framework. Given what the framework does, I suspect that would be roughly equivalent to recompiling the kernel in Linux.
I just installed Visual Studio 2005 Express last night. I had to reboot after installing the
Installed IIS. No reboot. Installed C++. No reboot. Installed C#. No reboot. Installed SQL Server. No reboot. Hmm. I'm starting to see a pattern here.
On the other hand, a game I installed last week required a reboot so it could finish installing its Starforce copy protection drivers. Started having crashes, so I uninstalled the game. Starforce wasn't uninstalled with the game. The Starforce developers indicated that was by design.
When you refer to the Windows security system, I assume you mean Access Control Lists. ACLs aren't unique to Windows. Linux started including them as an option a year or two ago.
The standard *NIX owner, group, world set of permissions is not sufficient in many environments. A finer degree of control is often needed. ACLs provide that degree of control.
A SID is basically a globally unique user/group id. Some of the POSIX ACL implementations are already using SIDs.
If you want to bash on Windows security, the access control model isn't the place to do it. There are issues in other areas but even the most recent POSIX efforts fall short of what NT4 provides in access control.
It's a matter of scale. It takes longer to write. It takes longer to debug. It takes longer to maintain. You also have to account for other actions the user might take while you're waiting for the first one to come back. And when you're writing zero footprint applications, theres a big difference between 7k lines of code and 25k lines of code.
add_child 1, 'Bob'
add_child 2, 'Carol'
add_child 2, 'Ted'
add_child 3, 'Alice'
add_child 4, 'Bill'
Carol and Ted report to Bob. Alice reports to Carol. Bill reports to Ted.
Your table looks like:Here's the retrieve.Simple, no?
As a side note, I generally use a clustered index on i_left, i_right with a unique index on
i_id.
It's one thing if the web site is strictly about presenting content. That's easy and doesn't take very much extra time. If you're writing web applications, it's a whole different story. Everything absolutely positively must look and act the same on all supported platforms. Period. You can't write documentation or train end users if the interface is different on their browser.
Look the same isn't the problem. Act the same can be. You want web developers to take more of an interest in FireFox? Support showModalDialog. Seriously. showModalDialog is huge. Opening a dependent window and screwing around with the onblur event doesn't even come close to what showModalDialog can do for you.
The big advantage to showModalDialog is that the calling code blocks and waits for showModalDialog to return before continuing. This is great in applications because the alternative is often shipping requests across an iframe and setting an interval timer to keep checking if the iframe has finished loading.
showModalDialogiframeIf I don't have to send the request to the server asynch for some reason, I'd much rather use showModalDialog.
The real problem with SQL NULLs is SQL programmers that don't understand SQL NULLs. An ANSI standard SQL NULL has an unknown value. Since the value is unknown, any logical operation involving a SQL NULL will always return FALSE. NULL = NULL returns FALSE. NULL != NULL also returns FALSE. It can be inconvenient in WHERE clauses, but that is the standard.
Chaz
The patent office gets funded based on how many patents they approve. Not how many they examine. I'd say they live in exactly the same world as the rest of us.
The 5 year vesting often only applies to the lower ranks. Top level executives often receive options with either no or shorter vesting periods.
But lets put that aside for a bit. The real problem is that not expensing options is far too easy to abuse. Company grants options for 50 million shares. When options are exercised, company issues 50 million more shares. This doesn't impact the company bottom line at all. There is still no expense incurred. The only measurable effect is that earnings per share goes down. Then after several years of this, the company takes a one time charge to repurchase the stock they issued to cover the options.
That's not even taking into consideration the dilution of ownership caused by excessive option granting.
I would rather they didn't. It leads to short term business practices that damage the company in the long term. The executives responsible have already cashed out and moved to another company before the negative consequences start to show in the bottom line.
As an example, the corporation for which I work use to own a number of large facilities around the country. The land and buildings were owned outright so there were no loan payments to consider. A few years ago, all of the facilities were sold with the new owners granting a 20 year lease. This made the bottom line look really good that year. A few years later the rental expense is a significant impact that could have been avoided.
The executives who made that decision don't care. They made millions from it. Many of them took offers from other companies.
So, what's the solution? I don't know. I do know that executive stock programs have only made things worse.
As an anonymous coward stated above, Apache is irrelevant in the grand scheme of things. It's middleware. If you're connecting to Active Directory, SQL Server, COM/DCOM components, or any number of other things, Microsoft could care less whether you use Apache or IIS as middleware. You're using their backend and that's where they make their money.
You're leaving out the cost of additional internal support. You're forgetting that customization of your environment leads to additional hassles applying patches and upgrades. Finally, you're forgetting that switching hardware costs money.
Ask yourself this: On how many thousands of computers would I have to save $100 per license to pay for a small team of programmers with secret or better security clearances for three years? If you figure a small team is 5-6 programmers, it works out to around 20,000 computers.
On how many more thousands of computers would I have to save $100 per license to pay the additional sysadmins, QA, and help desk personnel? What about the project managers that coordinate all these efforts? What about the additional oversight and compliance officers that ensure all of these activities meet regulations and standards?
As you can see, it quickly gets to a point where using a free as in beer product and supporting yourself is more expensive than buying from a vendor and getting a support contract.
A small to medium size business may save some money, but once you grow past that, it just makes more sense to pay for support.
It helps that the gamecube has been retailing for $99 for a while. At that price point it starts to look like a possiblity once 8-10 must have games are in the bargain bin for $25. With accessories (2nd controller, memory cards), you're looking at about a $15 premium per game. So you end up spending about $10 less than original retail for each of the must have games.
Once the X-Box drops below $100 I might consider it. It's going to be a tough sell though. Right now there are only 5 or 6 X-Box exclusives that I'd be interested in. With the X-Box 2 lacking backward compatibility, I'll probably pass over the current X-Box and wait to see if the X-Box 2 hits an attractive price point and has a bunch of killer exclusives.
In contrast, I bought a PS2 launch day. I already had 50-60 PS1 games. It played DVDs out of the box, so I didn't have to buy another DVD player for the second TV. DVD players at the time were still running around $200. I looked at it as getting a console for less than $100 after trading in my PS1. The launch titles were mostly crap, but it didn't matter. I had some PS1 games I hadn't finished yet and some high profile developers had already committed to releasing some high profile games on the PS2. The PS2 was out for quite a while in Japan before it was launched here. We already knew some cool stuff was coming our way once it got localized. Microsoft doesn't have that advantage.
You mean end user type applications? Well, that depends on the application. If the application accepts command line arguments, you can use those from a command line or batch script. If the application provides a COM interface, you can automate through that using WSH or some other scripting environment.
I can't say whether it is the norm for applications to do this. I develop financial systems and processes for a large institution. I can say that the only task I haven't been able to automate in our environment is using Rumba to screen scrape a mainframe report into a data file. It could be that the version of Rumba we use is out of date and a newer version would solve the problem. The newer versions haven't been approved yet.
Just about any Microsoft application can be installed from the command line. For other applications that do not natively offer unattended installation, a package can be created and pushed out using Microsoft SMS or a similar service.
The area where Microsoft continues to have issues is remote management of server software. Their standalone software is generally pretty good. I can't think of anything in SQL Server 2K that I can't administer remotely. The software integrated into the operating system is another matter. IIS is my biggest headache in this category. Most of it can be managed remotely but there a few things that require trips to the server room.
As for TCO, lets talk about the desktop first. Large corporations are going to pay for vendor support. If a bug occurs in a critical component, and the vendor does not resolve it in a timely manner, the vendor may be contractually obligated to make restitution. When you're dealing with lots of money, "We didn't think about that. We'll put that into our next milestone." doesn't cut it. The purchase and maintenance cost of Red Hat Enterprise Linux and Windows is pretty comparable. It's probably reasonable to assume that the long term administration costs will be similar as well. Short term costs of switching will be higher since all of the administration procedures will have to be rewritten.
Somebody mentioned training costs earlier. This is where Linux gets kicked in the teeth. Linux is sufficiently different that 99% of our employees will either have to take training classes or spend a lot of time figuring it out instead of doing productive work. When you have 125K employees just in North America, that really adds up.
Then any in-house application software using Win32 has to be rewritten. In our case, this isn't going to happen, because we just spent several years and lots of money moving it from X to Windows.
For a small company, the training costs and lost productivity may not be as much of a factor. For a large company with a significant software support and services division in-house, like IBM, vendor support may not be necessary. For nearly everyone else, Linux TCO is going to be comparable or higher than Windows.
On the server, a good case can be made for Linux. Personally, I might lean towards *BSD on a smaller server, but last I checked, the *BSDs weren't ready for big boxes. It depends on what the server is going to be used for though. In a big company, where most of the servers are used for fileshares, it _may_ make more sense to use Windows when most of your workstations are running Windows.
You must work for an ISP that charges extra for additional IPs. For the rest of us, NAT is what allows us to have all our computers on a LAN without having to pay our ISP extra $$$ per month per IP address.
In the real world, you generally don't write an application targetted to a specific CPU. You trust that your compiler is generally going to produce efficient machine code for your algorithm. Sometimes it won't, but if there isn't a performance problem with that particular section of code it usually isn't worth the effort to do anything about it.
The point of using a profiler to optimize your application is that usually you're going to identify a couple key areas where you need to do some tuning because your algorithm is not efficient regardless of the architecture on which its running.
Further, within the x86 family, different CPUs have different performance characteristics. The most efficient machine code on one may be the slowest on another. So to write the most efficient programs for x86, according to this guy's definition, I would end up having to implement run time CPU checking with different code paths depending on the result.
Guess what? It isn't worth the additional development time unless the result is substantial. How do we know which improvements would be substanial? We profile the code.
This guy needs to take a leave of absence from teaching and work as a programmer for a while before he shoots off his mouth on topics where he clearly has no clue.