I think both companies are well aware of the potential problems. The article talks about a timeframe of several years, so don't expect anything to be released within a few months.
Again, this would slow everything down, [...] on the client side because when the player suddenly encounters the enemy horde, his computer will be forced to load hundreds of character models all at once.
That's an easy to solve problem, the server could simply send out an "advisory message" to the client indicating which character models the player should load because they might soon become visible. The positions of the actual characters would however only be submitted when they actually are in sight.
Obviously this would still allow a mild form of cheating as the player might display those messages, thus receiving information such as "you are close to [some kind of enemy]". However, the player would not know how many enemies there are (there might be several enemies with the same character model) and where exactly they are.
Unfortunately I don't have a solution for the other problem (the server having to calculate the line of sight for every player all the time).
Apache's org.apache.jakarta.commons.lang package contains an abstract base class for typesafe enumerations (Enum), which contains a toString method and a readResolve method (to allow safe serialization of enumeration constants). The only disadvantage is that it also implements the Comparable interface, which sucks if you have an enumeration that doesn't really have a natural order.
I don't use ints for my enumerations anymore after reading Josh Bloch's Effective Java. The type-safe enum pattern he recommends is fantastic.
I second that. For those interested, the pattern is described in chapter 5 of the book, "Replacing C Constructs," which is available as a free sample chapter.
The book is great, I highly recommend that you read it (the whole book, not just the sample chapters).
Create a new email protocol that will be effective in eliminating spam (just how to do that is still to be determined) and make it require IPv6 to work.
I agree that a well-designed new protocol for email would be a good idea, however making it require IPv6 would break the seperation of network layers, so such a protocol would not qualify as "well-designed." A new email protocol should be built on top of TCP, which technically doesn't even have to be transported on top of IP.
Of course an email protocol needs some other technologies as well, e.g. it will probably refer to DNS for finding the mail server that is responsible for a domain. Technically the protocol could of course require the existance of a new DNS record type (e.g. "MX6") that only assigns IPv6 addresses to host names, however it would be quite trivial to extend it to use the standard MX record as a fallback, and most real world implementations would probably do just that. If you don't want the real world applications to all do that in a slightly different way, you'll have to make it part of the standard.
Besides, any new email protocol that wants to have an actual chance of replacing SMTP will need to somehow interface with SMTP anyway, otherwise it simply won't be adopted.
I just wish some browser maker would do better caching. I'm so tired on clicking "Back" and the browsers sits and spins for a long time. It's in the freaking cache, you dimwit pile of crap!
Actually that is the web site's fault in most cases, not a browser problem. Lots of web sites will send the page with HTTP headers that disallow caching the pages. That's because they display ads and want to boost page views, or because they have a stupid content management system that cannot figure out the difference between a document with static content (even if the HTML is generated from a database, the content is often static) and a document with truly dynamic content (i.e. content calculated from previous user input).
With such web sits, browsers have to either ignore the HTTP standard or not cache the page.
If you are a Mozilla or Phoenix user, you might be interested in the LiveHTTPHeaders plugin that displays will display the HTTP headers that were sent with a page. This is great for developing web sites, but for example will also show you that Slashdot sends a "Pragma: no-cache" and a "Cache-control: no-cache" header with each response, so don't expect caching to work here. At least Slashdot allows caching of images (except ads, of course), and they even include an "Expires" header (request date + 7 days) so your browser won't have to verify if its cached version is up to date. (If a browser has something in its cache that doesn't have an expiration date, it will usually send a conditional request with an "If-Modified-Since" header field.)
Most Windows installers maximize their window, whereas all common Mac installers just use a regular window.
I don't know about Macs, but the newer installers for Windows applications that are based on the Microsoft Installer technology usually run within a regular (dialog) window.
This is a common economic confusion of production with distribution. The production of an intellectual work is not the same thing as its reproduction, but economic theories evolved in the past have no conception of this.
I don't mean to flame you, but I think you are maybe confused by how ecnonomists (ab)use common terms? When Greenspan talks about "production", I'm pretty sure what he is referring to is the amount of output, not the creation of an intellectual work. I'm assuming this because "marginal cost" is the cost of producing one more unit. (I.e. if you had a function f(x) that calculates the total costs for producing x units, the marginal cost of production would be its derivative. Google found me this definition.)
To take Greenspan's example, creation of an on-line encyclopedia, the fact that "the cost of reproduction and distribution is near zero" does not enter into the cost of actual production, i.e., the foregoing creation.
Well, yes, obviously. That's probably why Greenspan says right in the paragraph after the one that you've quoted: "For example, though the set up cost of creating an on-line encyclopedia may be enormous, the cost of reproduction and distribution may be near zero if the means of distribution is the Internet."
What economists like Greenspan are attempting to do is justify ex post facto a regime that compensates those who reproduce and distribute works, when what is really needed is an economic model that compensates the producers of intellectual works.
I believe that Greenspan realizes this. I also don't see how you can claim that Greenspan justifies the current "regime" when in fact one of the question he asks is: "How appropriate is our current system--developed for a world in which physical assets predominated--for an economy in which value increasingly is embodied in ideas rather than tangible capital?"
Just how do you submit a complex transactional XML document using REST?
You can use HTTP POST with REST, so you simply POST the XML document to the appropriate URL (probably an URL that identifies some sort of handler).
Surely, submitting a SOAP document that wraps the XML document is better in this case.
But why do you want to wrap it?
The thing that is "wrong" about SOAP is that everything is wrapped into a POST request, even if you aren't posting anything but simply requesting some information.
For example, take the web service interface of some online store. I don't know Amazon's interface, but I suppose they would offer you a function to get the delivery status of your orders, and a way of sending them orders. With SOAP, if you want to send them an order, you'll have to wrap the order into a SOAP message call. With REST, you'd simply POST the order to an appropriate ressource, like http://webservice.example.com/newOrder. What an order looks like isn't defined by either SOAP or REST, so for the order itself, you'll have to build your own XML DTD (or schema or whatever) anyway. You'll also have to define a return type, obviously. In the SOAP case, that would be a SOAP message containing e.g. the order number. With REST, you could send back an application/xml response containing exactly the same data, but without the SOAP envelope.
What about getting the status of an order? With SOAP, you would POST the appropriate method call to some ressource. With REST, you could simply send a GET request without any parameters to an appropriate URL, e.g. http://webservice.example.com/order/1234567/status. Obviously the server would need to check if the order number is valid and if the client has the permission to request the status of that order. But the HTTP protocol already defines how to handle this, there are appropriate error codes. What do you need SOAP for?
There really isn't anything you can do with SOAP that you couldn't do with REST as well.
Personally, I think that REST is not only simpler, but the interface also feels much more "natural", i.e. it is more consistent with how URLs and HTTP are supposed to work. I guess the main thing I dislike about SOAP is that it doesn't really utilize the full potential of the HTTP standard, HTTP is only used as a wrapper. Obviously there are situations where you want this, after all it also adds some extra flexibility. But I believe in most cases where you want a "web service" you really want a web service, i.e. you want to use HTTP anyway.
Just looking at computers today, I'm not sure I agree. How much is a cutting edge Pentium 4 going to cost me today? How much is that same computer going to cost me next year?
You're mixing up "price" and "value," but even if we assume that the value will be measured by looking at the price, you're still wrong: why does the price of CPUs drop? The main reasons are the devlopment of new, improved CPU designs, and advances in production technology. Those however are not physical goods but "ideas."
In other words, the value (price) of physical goods degrades not because they're physical (that might be the case for with high wear and tear, but that's a predictable process, not a "radical change in value"). It degrades because of the invention of new products -- in other words, because of ideas.
Also note that while physical goods lose value, the value of most ideas will increase. How valueable, for example, is the "idea" of electricity? Or the transistor? These are also both good examples of how the value of ideas can change in a very radical way, as claimed by the original poster: the invention of the transistor radically changed the value of electricity. Likewise, the invention of technologies for global-scale computer networks radically changed the value of computers.
This did actually happen in Germany: some idiot drove his car into a river because the navigation system displayed a bridge, but actually there was only a ferry.
The last paragraph of the text says: "Please note: A GPS system cannot be a substitute for the driver's attention! In december 1998, a driver trusted his navigation system which suggested to continue driving straight ahead. A few seconds later, his car got wet because his road database didn't know anything about the ferry across the Havel (a river near Berlin). This is not a joke! The TV channel RTL had a report."
Surely the answer then is to develop a new business model adapted to the new market?
Yes, obviously. The problem he mentioned was however not the simple fact that you need a business model that works for online games, but that many publishers aren't familiar with such business models, so as a game developer you have the problem of finding one that is.
Dropping a game after this long is a stupid business move, [...]
No, it's not. If they expect that they won't be able to operate the game at a profit, then already having spent lots of money is no reason to lose even more.
But on the other hand, a big point of the internet is that it's supposed to be international, how are for instance americans supposed to type unique swedish characters to find the web site?
How are for instance Russians supposed to type latin characters to find an American web site?
(I suppose that they have keyboards that allow the user to type ASCII characters as well as cyrillic ones, but is that because they want to or because they have to?)
Firewalls are not just for your needs. They are also for the protection of others, too. It's the all-ports-open-on-outgoing stuff that allows worms like this to spread and wreak so much havoc.
Umm, no. It's idiots not patching their severs. If everyone had patched their servers, the worm would never have gotten in anywhere. The best way to protect others is to not get infected yourself.
It's dial-up Internet providers leaving port 25 open on outgoing that allow spammers to use throwaway accounts for spamming.
So how would you like me to send my mails then? I am not sending it using my ISP's mail server but are using the mail server of the company that hosts my domain. Please explain to me why I should be prevented from connecting to that server.
Oops. I'll have to admit that I didn't read the story since I already knew about the release and was only interested in other readers' comments. Sorry.
I really dislike that version numbering system. I know it makes development version numbering much easier, etc, but damn. I don't know. To me, a 2.5.35 release should be *better* than a 2.4.20 release
I assume you're talking about the Linux numbering system where an odd/even minor version indicates developer/stable releases? Apache doesn't even use that system. The previous stable version is 1.3.x.
IE compatibility isn't important. You may not realize this, but the W3C defines web compatibility. As long as Apple implements for the W3C, it doesn't matter who uses their browser.
Sure, but that doesn't mean that your web page will look the same everywhere because there are many options even when a browser is standards compliant.
For example, when you don't want your page to be displayed with a page margin, you can write "body {margin: 0px;}" into your CSS code, which will work fine in Internet Explorer and Mozilla, however for (I think) Opera you need to write "body {padding: 0px;}" because Opera uses "padding" for the default margin (which actually makes more sense). Of course, your page technically is "standards compliant" even when it displays with padding in Opera, but that might not be what you wanted.
As long as there isn't a "standard stylesheet" that all W3C compliant browsers have to use for the default rendering, you'll have to test your web site with most major browsers because the style sheet that you'll be writing for your site usually only defines where you don't want to look things the default way, but "the default way" isn't really defined anywhere.
But, what about a server? That rack mounted server is really hard to get out (and so big that someone would probably notice it,) but that hot swap drive is easy.
Good point. However, you probably wouldn't use a server for identifying the person using an online service (like an online banking account) because servers usually aren't associated with individual persons.
Make doesn't cache precompiled headers, which is what we want to do. So what if the precompiled headers are recompiled using make's dependency rules. That is ideal, if you ask me.
Yes, that's what I meant. If you write an appropriate makefile rule, make will cause the headers to be recompiled only when they have been modified. Effectively, this means that make will be "caching" your precompiled headers.
Why, why, why, why? Why can't the header file simply be compiled at the first inclusion and cached somewhere?
But that's just what make will do. Why rebuild the same functionality within a different tool? Basically, the reason is (probably, I'm not a GCC developer) the UNIX philosophy of having small tools doing their job. GCC is a compiler and nothing else, make is a tool that decides what needs to be compiled.
If you want automation, you can always use an IDE (or some other tool) that includes a make equivalent or that creates appropriate makefiles for you.
Which is more readable: newCar = oldCar + dealerCar; or newCar = oldCar.cloneWithOptions(dealerCar);
Well, duh. You're not supposed to misuse operator overloading simply to safe yourself from some typing. You can also get unreadable code by using stupid method names, e.g. when you want to clone a Car object and your language of choice doesn't permit overloading the "+" operator, you could just as well use a method called "add" instead of using the "+" operator, but that won't make your code any more or less understandable. When you aren't adding things, you shouldn't use something that makes your code look as if you did.
newCar = oldCar.add(dealerCar);
doesn't use operator overloading, but when what you're really doing is cloning things, it's still less readable than newCar = oldCar.cloneWithOptions(dealerCar);
However, operator overloading can be useful when used correctly, i.e. use the "+" operator for adding only, use the "*" operator for multiplying only, etc. For example I think that matrixC = matrixA + matrixB;
is more readable than matricC = matrixA.add(matrixB);
Oh, by the way, Java does have operator overloading, but only in predefined ways. E.g.the "+" operator is used both for adding numbers and for concatenating strings.
As with the game example above, other uses are financial transactions (for example, you could set it so that only your computer has access to your bank account records, so that even if someone stole your hard drive, and your username and password, they still wouldn't be able to get at your data,)
Huh? If someone can steal my hard drive, I assume he could just as well simply steal my whole computer.
Re:The PROOF that google is evil
on
Google vs. Evil
·
· Score: 2
> read as octal, gives 1889
Definitely not.
I think you misunderstood the parent of your post. It didn't say "converting 3541 into an octal number," it said "reading 3541 as octal" (i.e., as if it were an octal number), which in fact gives 1889.
Your idealism is heartwarming, but in order to "tell" anyone anything, you'd better bring some actual business reasons that aren't comprised of a whiteboard presentation of HTML standards and a pocket-full of hope.
In the long term, coding a web site according to standards will make that web site much easier to maintain.
When you have any type of automation in creating the pages (and that's true for almost every serious web site, even if it might be something as simple as adding a header and a footer to every document), you'll need some standard anyway, because whatever software you use to generate the pages will have certain expectations regarding its input. So, why not use the standard? It will make sure that you are not locked into one vendor's software, or, if you have an in-house solution, that you can replace large parts of it with standards tools (e.g. replace your own template processing code with an XSLT processor), so you'll save on maintenance cost. Another problem if you don't code to standards is that the non-standard way is probably less well documented. Again, this will increase the costs of maintaining your pages, page templates, and software.
Of course, if what you have right now is non-standard, then rewriting your code to make it standards compliant can be quite a lot of work and will cost money, but I'd look at it as an investment. Flexibility is important in today's markets. E.g. what if AOL drops Internet Explorer and bundles Netscape/Mozilla instead? How fast can your business react to that situation? Ideally, you don't have to react at all, because you already cared about standards before. Lean back and enjoy the customers coming to you from those of your competitors that couldn't adopt to the new situation within exactly zero seconds.
Slashdot Mirror
I think both companies are well aware of the potential problems. The article talks about a timeframe of several years, so don't expect anything to be released within a few months.
That's an easy to solve problem, the server could simply send out an "advisory message" to the client indicating which character models the player should load because they might soon become visible. The positions of the actual characters would however only be submitted when they actually are in sight.
Obviously this would still allow a mild form of cheating as the player might display those messages, thus receiving information such as "you are close to [some kind of enemy]". However, the player would not know how many enemies there are (there might be several enemies with the same character model) and where exactly they are.
Unfortunately I don't have a solution for the other problem (the server having to calculate the line of sight for every player all the time).
Apache's org.apache.jakarta.commons.lang package contains an abstract base class for typesafe enumerations (Enum), which contains a toString method and a readResolve method (to allow safe serialization of enumeration constants). The only disadvantage is that it also implements the Comparable interface, which sucks if you have an enumeration that doesn't really have a natural order.
I second that. For those interested, the pattern is described in chapter 5 of the book, "Replacing C Constructs," which is available as a free sample chapter.
The book is great, I highly recommend that you read it (the whole book, not just the sample chapters).
I agree that a well-designed new protocol for email would be a good idea, however making it require IPv6 would break the seperation of network layers, so such a protocol would not qualify as "well-designed." A new email protocol should be built on top of TCP, which technically doesn't even have to be transported on top of IP.
Of course an email protocol needs some other technologies as well, e.g. it will probably refer to DNS for finding the mail server that is responsible for a domain. Technically the protocol could of course require the existance of a new DNS record type (e.g. "MX6") that only assigns IPv6 addresses to host names, however it would be quite trivial to extend it to use the standard MX record as a fallback, and most real world implementations would probably do just that. If you don't want the real world applications to all do that in a slightly different way, you'll have to make it part of the standard.
Besides, any new email protocol that wants to have an actual chance of replacing SMTP will need to somehow interface with SMTP anyway, otherwise it simply won't be adopted.
Actually that is the web site's fault in most cases, not a browser problem. Lots of web sites will send the page with HTTP headers that disallow caching the pages. That's because they display ads and want to boost page views, or because they have a stupid content management system that cannot figure out the difference between a document with static content (even if the HTML is generated from a database, the content is often static) and a document with truly dynamic content (i.e. content calculated from previous user input).
With such web sits, browsers have to either ignore the HTTP standard or not cache the page.
If you are a Mozilla or Phoenix user, you might be interested in the LiveHTTPHeaders plugin that displays will display the HTTP headers that were sent with a page. This is great for developing web sites, but for example will also show you that Slashdot sends a "Pragma: no-cache" and a "Cache-control: no-cache" header with each response, so don't expect caching to work here. At least Slashdot allows caching of images (except ads, of course), and they even include an "Expires" header (request date + 7 days) so your browser won't have to verify if its cached version is up to date. (If a browser has something in its cache that doesn't have an expiration date, it will usually send a conditional request with an "If-Modified-Since" header field.)
I don't know about Macs, but the newer installers for Windows applications that are based on the Microsoft Installer technology usually run within a regular (dialog) window.
I don't mean to flame you, but I think you are maybe confused by how ecnonomists (ab)use common terms? When Greenspan talks about "production", I'm pretty sure what he is referring to is the amount of output, not the creation of an intellectual work. I'm assuming this because "marginal cost" is the cost of producing one more unit. (I.e. if you had a function f(x) that calculates the total costs for producing x units, the marginal cost of production would be its derivative. Google found me this definition.)
Well, yes, obviously. That's probably why Greenspan says right in the paragraph after the one that you've quoted: "For example, though the set up cost of creating an on-line encyclopedia may be enormous, the cost of reproduction and distribution may be near zero if the means of distribution is the Internet."
I believe that Greenspan realizes this. I also don't see how you can claim that Greenspan justifies the current "regime" when in fact one of the question he asks is: "How appropriate is our current system--developed for a world in which physical assets predominated--for an economy in which value increasingly is embodied in ideas rather than tangible capital?"
You can use HTTP POST with REST, so you simply POST the XML document to the appropriate URL (probably an URL that identifies some sort of handler).
But why do you want to wrap it?
The thing that is "wrong" about SOAP is that everything is wrapped into a POST request, even if you aren't posting anything but simply requesting some information.
For example, take the web service interface of some online store. I don't know Amazon's interface, but I suppose they would offer you a function to get the delivery status of your orders, and a way of sending them orders. With SOAP, if you want to send them an order, you'll have to wrap the order into a SOAP message call. With REST, you'd simply POST the order to an appropriate ressource, like http://webservice.example.com/newOrder. What an order looks like isn't defined by either SOAP or REST, so for the order itself, you'll have to build your own XML DTD (or schema or whatever) anyway. You'll also have to define a return type, obviously. In the SOAP case, that would be a SOAP message containing e.g. the order number. With REST, you could send back an application/xml response containing exactly the same data, but without the SOAP envelope.
What about getting the status of an order? With SOAP, you would POST the appropriate method call to some ressource. With REST, you could simply send a GET request without any parameters to an appropriate URL, e.g. http://webservice.example.com/order/1234567/status . Obviously the server would need to check if the order number is valid and if the client has the permission to request the status of that order. But the HTTP protocol already defines how to handle this, there are appropriate error codes. What do you need SOAP for?
There really isn't anything you can do with SOAP that you couldn't do with REST as well.
Personally, I think that REST is not only simpler, but the interface also feels much more "natural", i.e. it is more consistent with how URLs and HTTP are supposed to work. I guess the main thing I dislike about SOAP is that it doesn't really utilize the full potential of the HTTP standard, HTTP is only used as a wrapper. Obviously there are situations where you want this, after all it also adds some extra flexibility. But I believe in most cases where you want a "web service" you really want a web service, i.e. you want to use HTTP anyway.
You're mixing up "price" and "value," but even if we assume that the value will be measured by looking at the price, you're still wrong: why does the price of CPUs drop? The main reasons are the devlopment of new, improved CPU designs, and advances in production technology. Those however are not physical goods but "ideas."
In other words, the value (price) of physical goods degrades not because they're physical (that might be the case for with high wear and tear, but that's a predictable process, not a "radical change in value"). It degrades because of the invention of new products -- in other words, because of ideas.
Also note that while physical goods lose value, the value of most ideas will increase. How valueable, for example, is the "idea" of electricity? Or the transistor? These are also both good examples of how the value of ideas can change in a very radical way, as claimed by the original poster: the invention of the transistor radically changed the value of electricity. Likewise, the invention of technologies for global-scale computer networks radically changed the value of computers.
This did actually happen in Germany: some idiot drove his car into a river because the navigation system displayed a bridge, but actually there was only a ferry.
See pictures of his car here (scroll down).
The last paragraph of the text says: "Please note: A GPS system cannot be a substitute for the driver's attention! In december 1998, a driver trusted his navigation system which suggested to continue driving straight ahead. A few seconds later, his car got wet because his road database didn't know anything about the ferry across the Havel (a river near Berlin). This is not a joke! The TV channel RTL had a report."
Yes, obviously. The problem he mentioned was however not the simple fact that you need a business model that works for online games, but that many publishers aren't familiar with such business models, so as a game developer you have the problem of finding one that is.
No, it's not. If they expect that they won't be able to operate the game at a profit, then already having spent lots of money is no reason to lose even more.
How are for instance Russians supposed to type latin characters to find an American web site?
(I suppose that they have keyboards that allow the user to type ASCII characters as well as cyrillic ones, but is that because they want to or because they have to?)
Umm, no. It's idiots not patching their severs. If everyone had patched their servers, the worm would never have gotten in anywhere. The best way to protect others is to not get infected yourself.
So how would you like me to send my mails then? I am not sending it using my ISP's mail server but are using the mail server of the company that hosts my domain. Please explain to me why I should be prevented from connecting to that server.
Oops. I'll have to admit that I didn't read the story since I already knew about the release and was only interested in other readers' comments. Sorry.
I assume you're talking about the Linux numbering system where an odd/even minor version indicates developer/stable releases? Apache doesn't even use that system. The previous stable version is 1.3.x.
Sure, but that doesn't mean that your web page will look the same everywhere because there are many options even when a browser is standards compliant.
For example, when you don't want your page to be displayed with a page margin, you can write "body {margin: 0px;}" into your CSS code, which will work fine in Internet Explorer and Mozilla, however for (I think) Opera you need to write "body {padding: 0px;}" because Opera uses "padding" for the default margin (which actually makes more sense). Of course, your page technically is "standards compliant" even when it displays with padding in Opera, but that might not be what you wanted.
As long as there isn't a "standard stylesheet" that all W3C compliant browsers have to use for the default rendering, you'll have to test your web site with most major browsers because the style sheet that you'll be writing for your site usually only defines where you don't want to look things the default way, but "the default way" isn't really defined anywhere.
Good point. However, you probably wouldn't use a server for identifying the person using an online service (like an online banking account) because servers usually aren't associated with individual persons.
Yes, that's what I meant. If you write an appropriate makefile rule, make will cause the headers to be recompiled only when they have been modified. Effectively, this means that make will be "caching" your precompiled headers.
But that's just what make will do. Why rebuild the same functionality within a different tool? Basically, the reason is (probably, I'm not a GCC developer) the UNIX philosophy of having small tools doing their job. GCC is a compiler and nothing else, make is a tool that decides what needs to be compiled.
If you want automation, you can always use an IDE (or some other tool) that includes a make equivalent or that creates appropriate makefiles for you.
Well, duh. You're not supposed to misuse operator overloading simply to safe yourself from some typing. You can also get unreadable code by using stupid method names, e.g. when you want to clone a Car object and your language of choice doesn't permit overloading the "+" operator, you could just as well use a method called "add" instead of using the "+" operator, but that won't make your code any more or less understandable. When you aren't adding things, you shouldn't use something that makes your code look as if you did.
newCar = oldCar.add(dealerCar);
doesn't use operator overloading, but when what you're really doing is cloning things, it's still less readable than
newCar = oldCar.cloneWithOptions(dealerCar);
However, operator overloading can be useful when used correctly, i.e. use the "+" operator for adding only, use the "*" operator for multiplying only, etc. For example I think that
matrixC = matrixA + matrixB;
is more readable than
matricC = matrixA.add(matrixB);
Oh, by the way, Java does have operator overloading, but only in predefined ways. E.g.the "+" operator is used both for adding numbers and for concatenating strings.
Huh? If someone can steal my hard drive, I assume he could just as well simply steal my whole computer.
I think you misunderstood the parent of your post. It didn't say "converting 3541 into an octal number," it said "reading 3541 as octal" (i.e., as if it were an octal number), which in fact gives 1889.
More simply: 3541 octal == 1889 decimal.
In the long term, coding a web site according to standards will make that web site much easier to maintain.
When you have any type of automation in creating the pages (and that's true for almost every serious web site, even if it might be something as simple as adding a header and a footer to every document), you'll need some standard anyway, because whatever software you use to generate the pages will have certain expectations regarding its input. So, why not use the standard? It will make sure that you are not locked into one vendor's software, or, if you have an in-house solution, that you can replace large parts of it with standards tools (e.g. replace your own template processing code with an XSLT processor), so you'll save on maintenance cost. Another problem if you don't code to standards is that the non-standard way is probably less well documented. Again, this will increase the costs of maintaining your pages, page templates, and software.
Of course, if what you have right now is non-standard, then rewriting your code to make it standards compliant can be quite a lot of work and will cost money, but I'd look at it as an investment. Flexibility is important in today's markets. E.g. what if AOL drops Internet Explorer and bundles Netscape/Mozilla instead? How fast can your business react to that situation? Ideally, you don't have to react at all, because you already cared about standards before. Lean back and enjoy the customers coming to you from those of your competitors that couldn't adopt to the new situation within exactly zero seconds.