Dunno... there are probably millions of lines of code in the math libraries and the like vs. maybe 100,000 lines of code for the emulator? I dunno the actual numbers, but I imagine there are more lines of code that run on the things than required by the emulator.
Seriously, though, I don't get it from the players perspective. You pay $30-$50 a shot to BUY the game and the first month. Then you pay $10 a month to play. You, then, PAY (?!?!?) for major updates to the system (cleverly named 'expansions')???
Actually, I played EverQuest for 5 years (from Day 1 until recently). Before EQ, I played many games, typically buying at least one $50 per month only to get tired of it and never play it again. With EQ, I payed a few times the $50 for expansions and took the longer subscription times for something like $13/month but I almost never bought any other games. While I played EQ, I actually spent less money on computer games than I did before I started playing EQ. So, in a sad way, I saved money by playing EQ rather than my pre-EQ buying patterns.
Fortunately, I've been EQ sober for almost 8 months now, having cancelled my subscriptions about 5 months ago.
What MMOG really need is a 'death' time. You 'age' in the game, and once you hit like 60 you die.
This only works for the game makers if the cost to getting "super massive skills" is very cheap (a few days at most) and there is lots of content that is worth playing multiple/many times. Otherwise, there is no replayability and when folks die the first time, they cancel their subscriptions.
Horizons was something that I watched for a few years. The original premise and descriptions were really cool but sometimes about a year ago, maybe, they started releasing real information and it wasn't going to be anywhere near their ideals. I never tried it.
A lot of the money/food that already is earmarked to feed and clothe the poorest in the world never finds its way to them. In many cases, warlords in places such as Africa take the food/supplies for their own needs before it can be distributed to the needy.
There was a student from somewhere else (not naming names) going to a school in Tennessee (Eastern side of it). One day, he decided he wanted to take a "weekend trip" to Seattle. Heh, folks pulled out a map and said... remember when we went to Memphis? That's right here. Then showed the distance on the map from the city where they were to Memphis between their thumb and forefinger (about three inches or so). Remember how long that took? Well... here is Seattle on this map....
Some game consoles work like this even now. That way, you never worry about someone upgrading the OS out from under your game and now your game needs patching. The solution is to have the CD basically being a bootable CD complete with loader, OS, and autorun the game that is on it. Not a bad idea actually...
I still can't, for the life of me, see how MS can say with a straight face that something that costs money is cheaper than something that doesn't cost anything?
You answered your own question. IT support staff for Unix/Linux is typically more expensive (salaries are higher) than for Windows.
IT wouldn't be spending yearly cash on service contracts and the like with open source, wouldn't they instead just HIRE their support? Hire IT pros that KNOW how to program and configure and support and fix the open source servers/databases? You pay for the IT people anyway, why pay in addition to that for service contracts?
Because support contracts are more than just that. You pay for support contracts on hardware, not just software. Unless your IT staff can run out to the junkyard and fabricate new CPUs, memory, and HDD, support contracts are going to cost money.
After they build it, you keep them as your IT department to maintain everything. No service contracts...not even to Redhat or SUSE or anyone. Now, how is that more expensive than the MS solution?
That's fine. Make it so that no OSS folks can make money at all. See how long they stay around. You pay support to these folks so they can stay around and continue to do stuff (like come out with newer distributions). Without actually hiring folks to make it their business to advance OSS, the rate of fixes and packaging would slow to a crawl because no one would be able to do it except in their spare time, after they came home from a hard day at work doing whatever else they have to do to put food on the table and a roof over their head and keep electricity flowing to the computer.
If OSS is to be successful, it most certainly will not be "free" (as in beer).
In my post above, I show how it lets us port fairly easily and we don't have vendor lockin. I can easily see where you can write code and stored procedures in such a way as to be tied too tightly to one particular RDBMS, but I'd argue that these types of problems are a result of not analyzing your problem enough to abstract it enough to prevent such tight codependency of your software and the RDBMS in question.
Maybe it also helps them keep an accurate passenger record in case something bad happens. They know who was on the plane and can contact the appropriate parties afterwards.
In addition, the last time I checked, all the airlines were private businesses. If they want to require you to submit to a cavity search before boarding their planes, I don't see why they couldn't. Their customers (or lack thereof) will indicate whether anything like this is tollerable or not.
In one place, we needed exclusive selection of some number of records from a table for processing. Our code calls a stored procedure that gives back a result set of the records to process. The SP for Oracle vs. MSSQL vs. whatever is different but the results are the same. The upper level code doesn't change, only the stored procedure has to.
In another case, we have a bit of processing to do. This processing involves the creation of a number of temporary tables and data processing that must be protected by a number of transactions. In addition, it requires quite a bit of referential integrity (and many JOIN statements). The order of processing that we target with this code is an upper bound of 10,000,000 records and more typically around 100,000 to 1,000,000 records at a time. The inputs are the same, regardless of RDBMS (basically, a number of parameters to say what we are interested in extracting) and the output is basically the same (a result set of up to 10M records).
Writing SQL isn't that much different from writing in other languages. You define the inputs and the outputs and then write the stuff. For us, we knew that the operations would all be carried out within a single database. If we had to span RDBMS to merge all that data (for example, some data was on MSSQL and the other was on Oracle), then it is a lot more complicated and you need to draw the logic up a level. However, if you are on a single RDBMS and in a single database, if you can write the SQL statements to do some task and use embedded SQL statements in your code to do it, I'd argue that you can do the same thing in stored procedures.
In the example above with the up to 10M record result set, the Oracle SQL was almost, but not completely, unlike the MSSQL SQL that I had to write. There were lots of instances of syntax/operations specific to the RDBMS targeted, lots of optimization differences (when to create an index, what to index, etc.) In this case, we abstracted the operation into a class that basically had a "DoIt" function which, as output, returned the resultant table name which contained the processed records that were required (or returned an error if there were problems encountered during execution - which included ROLLBACKs as necessary). That "DoIt" determined which RDBMS was being used and issued the appropriate SQL statements to get the job done. However, I could have easily turned that into a stored procedure and eliminated the code fork underneath the "DoIt" function that determined which RDBMS was in use and issued the appropriate SQL statements.
I'm not sure why folks are so against stored procedures. I look at them like just functions in my program, just written in a different language. I figure out what I need to have done and do it... more like black boxing it. I guess I might not have had as extensive problems as some folks may have, but I haven't had a situation yet where I couldn't use stored procedures if we chose to do so. Using embedded SQL seems to do the same thing, just moves all the SQL into your codebase as opposed to having it in a stored procedure. I don't see much difference between embedded SQL and SPs I guess. Anything you can do with embedded SQL, I'd argue you can do with a SP. It's not even a different language. You have to write the embedded SQL to get stuff done, then do glue and tie logic in your other language. You could just do the glue/tie logic in the SP. Maybe folks are having problems abstracting their work to that level. I dunno. I haven't had any problems in the past embedding SQL or using SP in a reasonably clean way.
Again, when you are processing between different RDBMS, things get a lot more complicated. Maybe this is where folks are complaining about SPs... but that is a bit more difficult problem anyway.
Heh... I'd be surprised if your system works "perfectly".
If you have to rewrite 250,000 lines of code just to change to a real RDBMS, your code must particularly aweful. We typically isolate all database specific code in appropriate classes and stored procedures (after all, that's one of the things stored procedures are for... to help abstract the database specific code from the rest of your code) and it isn't bad at all to port to a new RDBMS, as long as it has the features we need (referential integrity, transactions, etc.)
In fact, in most cases, we can port to a new RDBMS without recompiling our source, just by providing the appropriate stored procedures on the new system.
Correctly, however, an "intranet" means a "non-public network running application protocols popular on The Internet".
Yes, you are correct.
If the basement LAN uses HTTP and SMTP, then it's an intranet. But if it uses things like SMB/CIFS, nfs/sun-rpc, or X11 (protocols which you would not sanely run on the Internet), then it's not.
http://www.m-w.com defines these:
Main Entry: intranet Pronunciation: 'in-tr&-"net Function: noun : a network operating like the World Wide Web but having access restricted to a limited group of authorized users (as employees of a company)
(note the capitalization here)
Main Entry: Internet Pronunciation: 'in-t&r-"net Function: noun : an electronic communications network that connects computer networks and organizational computer facilities around the world
As the uberparent says, this is from wiki (http://en.wikipedia.org/wiki/Internet)
The word "Internet" is a capitonym. In the general sense, an internet (with a lowercase "i", a shortened form of the original inter-network) is a computer network that connects several networks. As a proper noun, the Internet is the publicly available internationally interconnected system of computers (plus the information and services they provide to their users) that uses the TCP/IP suite of packet switching communications protocols. Thus, the largest internet is called simply "the" Internet. The art of connecting networks in this way is called internetworking.
In popular parlance, Internet often refers to the World Wide Web, electronic mail and online chat services operating on the Internet.
and...
An intranet is an access restricted network used internally in an organization. Typically the term refers to the internal web site. The same concepts and technologies of the world wide web such as web browsers and servers running on the internet protocol suite are used to build an intranet. Other internet protocols are commonly used as well, especially ftp and email. There is often an attempt to use internet technologies to provide new interfaces with corporate 'legacy' data and information systems.
These are the definitions I know these things by and will continue to use. In both cases, there is a distinction between an internet and The Internet.
No, because you don't have an internet connecting your basement intranet (you do own that intranet, and can call it The Intranet if you want, I guess) to The Internet.
However, if you did connect your intranet with those addresses to The Internet, you would definitely hear someone complain because you'd be messing up DNS servers and causing problems with redirecting traffic from existing sites, and other stuff, potentially. At that point, you'd probably get some nastygrams at least, and possibly get to talk with some lawyers.
I have a network inside my home. It is an intranet as it connects things inside my network. I also have a network that connects me to my ISP. I suggest you stop trying to teach yourself anything computer related and find some formal training on the subjects.
The internet is a continuously evolving complex system. Routes change, nodes come on and off line, it never sits still. Referring to it as a proper entity makes about as much sense as referring to the people in Times Square as "The Crowd."
"The people in Times Square" isn't specific enough to be called "The Crowd". If you are talking specifically about the people in Times Square at the dropping of the ball on New Years, then you could arguably call it "The Crowd".
Yes, the Internet is constantly evolving. Your body is constantly changing. The majority of the cells in your body right now are almost certainly not the ones you started out with when you were named, neither are your thought processes. Why do we call you by a series of capitalized words?
The Internet is specifically the one that consists of the public domain space of IP addresses. An internet is simply any network that connects two other networks.
Why do we capitalize names then? The odds are that you do not have a unique name. Why put capital letters at the front of them? Maybe it is because we are talking about a specific instance of the name by which you are addressed? This is the same reason The Internet should be capitalized.
At one time, there was only one internet and it was called the Internet.
"internet" is just a network that connects two other networks (intranets, for example), much like an interstate hiway is a hiway that goes between (at least) two states here in the USA. I have an internet connecting my home network with my ISP.
The Internet is a specific entity, namely, the one you are using to read this post, most likely. There is only one of it.
There is no controlling entity, no plan for future development, no widespread coordination, or anything else that would make it deserving of a proper name.
You mean the only time you were owned and knew it. With linux, software behaves consistently enough, that it's much more obvious when you've been nailed.
Not if the person who hacked your box knows what they are doing. You could have been rooted for a year and not know. Again, this is because Linux, the thing is consistent enough to where another user (even one that has rooted your machine) can do plenty of other stuff on your machine without your being impacted by it at all.
If the Windows API were an free, complete openly-published standard that competing companies could implement, then this wouldn't be a problem.
Nope. This has nothing to do with it. If you try setting up an old RedHat distribution on that machine, for example, and do not keep the patches up to date, it'd be rooted in no time as well. This doesn't have as much to do with what OS you are running as it does with keeping whatever OS you are running up to date. In this case, being up to date means not using Windows 98 and using Windows XP instead. Just as you would be running an unpatched RH7.2 machine, you'd at least install patches or you'd upgrade to the latest distribution.
Are you sure this isn't a time for a colorful metaphor?
Dunno... there are probably millions of lines of code in the math libraries and the like vs. maybe 100,000 lines of code for the emulator? I dunno the actual numbers, but I imagine there are more lines of code that run on the things than required by the emulator.
haven't had caffeine for months
:( Caffeine makes the world go 'round.
You poor man
Seriously, though, I don't get it from the players perspective. You pay $30-$50 a shot to BUY the game and the first month. Then you pay $10 a month to play. You, then, PAY (?!?!?) for major updates to the system (cleverly named 'expansions')???
Actually, I played EverQuest for 5 years (from Day 1 until recently). Before EQ, I played many games, typically buying at least one $50 per month only to get tired of it and never play it again. With EQ, I payed a few times the $50 for expansions and took the longer subscription times for something like $13/month but I almost never bought any other games. While I played EQ, I actually spent less money on computer games than I did before I started playing EQ. So, in a sad way, I saved money by playing EQ rather than my pre-EQ buying patterns.
Fortunately, I've been EQ sober for almost 8 months now, having cancelled my subscriptions about 5 months ago.
What MMOG really need is a 'death' time. You 'age' in the game, and once you hit like 60 you die.
This only works for the game makers if the cost to getting "super massive skills" is very cheap (a few days at most) and there is lots of content that is worth playing multiple/many times. Otherwise, there is no replayability and when folks die the first time, they cancel their subscriptions.
Horizons was something that I watched for a few years. The original premise and descriptions were really cool but sometimes about a year ago, maybe, they started releasing real information and it wasn't going to be anywhere near their ideals. I never tried it.
A lot of the money/food that already is earmarked to feed and clothe the poorest in the world never finds its way to them. In many cases, warlords in places such as Africa take the food/supplies for their own needs before it can be distributed to the needy.
Heh... reminds me of a story from college.
There was a student from somewhere else (not naming names) going to a school in Tennessee (Eastern side of it). One day, he decided he wanted to take a "weekend trip" to Seattle. Heh, folks pulled out a map and said... remember when we went to Memphis? That's right here. Then showed the distance on the map from the city where they were to Memphis between their thumb and forefinger (about three inches or so). Remember how long that took? Well... here is Seattle on this map....
Some game consoles work like this even now. That way, you never worry about someone upgrading the OS out from under your game and now your game needs patching. The solution is to have the CD basically being a bootable CD complete with loader, OS, and autorun the game that is on it. Not a bad idea actually...
AMD has their own line of RISC type microcontroller processors (AMD29000 IIRC is one of them) in addition to their Intel x86 ISA processors.
I still can't, for the life of me, see how MS can say with a straight face that something that costs money is cheaper than something that doesn't cost anything?
You answered your own question. IT support staff for Unix/Linux is typically more expensive (salaries are higher) than for Windows.
IT wouldn't be spending yearly cash on service contracts and the like with open source, wouldn't they instead just HIRE their support? Hire IT pros that KNOW how to program and configure and support and fix the open source servers/databases? You pay for the IT people anyway, why pay in addition to that for service contracts?
Because support contracts are more than just that. You pay for support contracts on hardware, not just software. Unless your IT staff can run out to the junkyard and fabricate new CPUs, memory, and HDD, support contracts are going to cost money.
After they build it, you keep them as your IT department to maintain everything. No service contracts...not even to Redhat or SUSE or anyone. Now, how is that more expensive than the MS solution?
That's fine. Make it so that no OSS folks can make money at all. See how long they stay around. You pay support to these folks so they can stay around and continue to do stuff (like come out with newer distributions). Without actually hiring folks to make it their business to advance OSS, the rate of fixes and packaging would slow to a crawl because no one would be able to do it except in their spare time, after they came home from a hard day at work doing whatever else they have to do to put food on the table and a roof over their head and keep electricity flowing to the computer.
If OSS is to be successful, it most certainly will not be "free" (as in beer).
In my post above, I show how it lets us port fairly easily and we don't have vendor lockin. I can easily see where you can write code and stored procedures in such a way as to be tied too tightly to one particular RDBMS, but I'd argue that these types of problems are a result of not analyzing your problem enough to abstract it enough to prevent such tight codependency of your software and the RDBMS in question.
Maybe it also helps them keep an accurate passenger record in case something bad happens. They know who was on the plane and can contact the appropriate parties afterwards.
In addition, the last time I checked, all the airlines were private businesses. If they want to require you to submit to a cavity search before boarding their planes, I don't see why they couldn't. Their customers (or lack thereof) will indicate whether anything like this is tollerable or not.
Well... some simple examples of what we did:
In one place, we needed exclusive selection of some number of records from a table for processing. Our code calls a stored procedure that gives back a result set of the records to process. The SP for Oracle vs. MSSQL vs. whatever is different but the results are the same. The upper level code doesn't change, only the stored procedure has to.
In another case, we have a bit of processing to do. This processing involves the creation of a number of temporary tables and data processing that must be protected by a number of transactions. In addition, it requires quite a bit of referential integrity (and many JOIN statements). The order of processing that we target with this code is an upper bound of 10,000,000 records and more typically around 100,000 to 1,000,000 records at a time. The inputs are the same, regardless of RDBMS (basically, a number of parameters to say what we are interested in extracting) and the output is basically the same (a result set of up to 10M records).
Writing SQL isn't that much different from writing in other languages. You define the inputs and the outputs and then write the stuff. For us, we knew that the operations would all be carried out within a single database. If we had to span RDBMS to merge all that data (for example, some data was on MSSQL and the other was on Oracle), then it is a lot more complicated and you need to draw the logic up a level. However, if you are on a single RDBMS and in a single database, if you can write the SQL statements to do some task and use embedded SQL statements in your code to do it, I'd argue that you can do the same thing in stored procedures.
In the example above with the up to 10M record result set, the Oracle SQL was almost, but not completely, unlike the MSSQL SQL that I had to write. There were lots of instances of syntax/operations specific to the RDBMS targeted, lots of optimization differences (when to create an index, what to index, etc.) In this case, we abstracted the operation into a class that basically had a "DoIt" function which, as output, returned the resultant table name which contained the processed records that were required (or returned an error if there were problems encountered during execution - which included ROLLBACKs as necessary). That "DoIt" determined which RDBMS was being used and issued the appropriate SQL statements to get the job done. However, I could have easily turned that into a stored procedure and eliminated the code fork underneath the "DoIt" function that determined which RDBMS was in use and issued the appropriate SQL statements.
I'm not sure why folks are so against stored procedures. I look at them like just functions in my program, just written in a different language. I figure out what I need to have done and do it... more like black boxing it. I guess I might not have had as extensive problems as some folks may have, but I haven't had a situation yet where I couldn't use stored procedures if we chose to do so. Using embedded SQL seems to do the same thing, just moves all the SQL into your codebase as opposed to having it in a stored procedure. I don't see much difference between embedded SQL and SPs I guess. Anything you can do with embedded SQL, I'd argue you can do with a SP. It's not even a different language. You have to write the embedded SQL to get stuff done, then do glue and tie logic in your other language. You could just do the glue/tie logic in the SP. Maybe folks are having problems abstracting their work to that level. I dunno. I haven't had any problems in the past embedding SQL or using SP in a reasonably clean way.
Again, when you are processing between different RDBMS, things get a lot more complicated. Maybe this is where folks are complaining about SPs... but that is a bit more difficult problem anyway.
Heh... I'd be surprised if your system works "perfectly".
If you have to rewrite 250,000 lines of code just to change to a real RDBMS, your code must particularly aweful. We typically isolate all database specific code in appropriate classes and stored procedures (after all, that's one of the things stored procedures are for... to help abstract the database specific code from the rest of your code) and it isn't bad at all to port to a new RDBMS, as long as it has the features we need (referential integrity, transactions, etc.)
In fact, in most cases, we can port to a new RDBMS without recompiling our source, just by providing the appropriate stored procedures on the new system.
Correctly, however, an "intranet" means a "non-public network running application protocols popular on The Internet".
Yes, you are correct.
If the basement LAN uses HTTP and SMTP, then it's an intranet. But if it uses things like SMB/CIFS, nfs/sun-rpc, or X11 (protocols which you would not sanely run on the Internet), then it's not.
http://www.m-w.com defines these:
Main Entry: intranet
Pronunciation: 'in-tr&-"net
Function: noun
: a network operating like the World Wide Web but having access restricted to a limited group of authorized users (as employees of a company)
(note the capitalization here)
Main Entry: Internet
Pronunciation: 'in-t&r-"net
Function: noun
: an electronic communications network that connects computer networks and organizational computer facilities around the world
As the uberparent says, this is from wiki (http://en.wikipedia.org/wiki/Internet)
The word "Internet" is a capitonym. In the general sense, an internet (with a lowercase "i", a shortened form of the original inter-network) is a computer network that connects several networks. As a proper noun, the Internet is the publicly available internationally interconnected system of computers (plus the information and services they provide to their users) that uses the TCP/IP suite of packet switching communications protocols. Thus, the largest internet is called simply "the" Internet. The art of connecting networks in this way is called internetworking.
In popular parlance, Internet often refers to the World Wide Web, electronic mail and online chat services operating on the Internet.
and...
An intranet is an access restricted network used internally in an organization. Typically the term refers to the internal web site. The same concepts and technologies of the world wide web such as web browsers and servers running on the internet protocol suite are used to build an intranet. Other internet protocols are commonly used as well, especially ftp and email. There is often an attempt to use internet technologies to provide new interfaces with corporate 'legacy' data and information systems.
These are the definitions I know these things by and will continue to use. In both cases, there is a distinction between an internet and The Internet.
No, because you don't have an internet connecting your basement intranet (you do own that intranet, and can call it The Intranet if you want, I guess) to The Internet.
However, if you did connect your intranet with those addresses to The Internet, you would definitely hear someone complain because you'd be messing up DNS servers and causing problems with redirecting traffic from existing sites, and other stuff, potentially. At that point, you'd probably get some nastygrams at least, and possibly get to talk with some lawyers.
I have a network inside my home. It is an intranet as it connects things inside my network. I also have a network that connects me to my ISP. I suggest you stop trying to teach yourself anything computer related and find some formal training on the subjects.
The internet is a continuously evolving complex system. Routes change, nodes come on and off line, it never sits still. Referring to it as a proper entity makes about as much sense as referring to the people in Times Square as "The Crowd."
"The people in Times Square" isn't specific enough to be called "The Crowd". If you are talking specifically about the people in Times Square at the dropping of the ball on New Years, then you could arguably call it "The Crowd".
Yes, the Internet is constantly evolving. Your body is constantly changing. The majority of the cells in your body right now are almost certainly not the ones you started out with when you were named, neither are your thought processes. Why do we call you by a series of capitalized words?
The Internet is specifically the one that consists of the public domain space of IP addresses. An internet is simply any network that connects two other networks.
Spoken like someone who (at most) taught themselves networking.
See other posts as to the difference between The Internet and an internet. Or... take a few networking classes.
Why do we capitalize names then? The odds are that you do not have a unique name. Why put capital letters at the front of them? Maybe it is because we are talking about a specific instance of the name by which you are addressed? This is the same reason The Internet should be capitalized.
At one time, there was only one internet and it was called the Internet.
"internet" is just a network that connects two other networks (intranets, for example), much like an interstate hiway is a hiway that goes between (at least) two states here in the USA. I have an internet connecting my home network with my ISP.
The Internet is a specific entity, namely, the one you are using to read this post, most likely. There is only one of it.
There is no controlling entity, no plan for future development, no widespread coordination, or anything else that would make it deserving of a proper name.
Yeah... and no IETF....
Geez... it takes 10 1/2 hours to install...
or reinstall Windows 98 or any OS...
You mean the only time you were owned and knew it. With linux, software behaves consistently enough, that it's much more obvious when you've been nailed.
Not if the person who hacked your box knows what they are doing. You could have been rooted for a year and not know. Again, this is because Linux, the thing is consistent enough to where another user (even one that has rooted your machine) can do plenty of other stuff on your machine without your being impacted by it at all.
If the Windows API were an free, complete openly-published standard that competing companies could implement, then this wouldn't be a problem.
Nope. This has nothing to do with it. If you try setting up an old RedHat distribution on that machine, for example, and do not keep the patches up to date, it'd be rooted in no time as well. This doesn't have as much to do with what OS you are running as it does with keeping whatever OS you are running up to date. In this case, being up to date means not using Windows 98 and using Windows XP instead. Just as you would be running an unpatched RH7.2 machine, you'd at least install patches or you'd upgrade to the latest distribution.