Mr. Anonymous Coward forgets that the Earth didn't come from the factory with an oxygen atmosphere. Plankton make oxygen from carbon dioxide; carbon dioxide, of course, is produced by the Earth itself in geological processes.
If it were true that oxygen leaves the Earth's atmosphere-- it's not, in any significant sense-- then the plankton in our oceans would simply replace it, maintaining the equilibrium we've enjoyed for the last billion years or so.
Mr. Anonymous Coward is evidently an Anonymous Idiot.
Compare an American chicken to an Italian (or, more generally, western European) chicken and say that again. European chickens are generally scrawny, tough, gamey birds. American chickens are fatter, and more succulent. This is partly because of different farming methods, but also due to the genetics of the different populations.
There are other benefits to selective farm breeding. Farm-raised pigs have sweeter, more pleasant flesh than wild pigs, and are virtually free of Trichinella nematodes. Farm-raised veal results in a meat that is simply unavailable in free-range animals. And, of course, farm-raised seafood is almost universally superior to wild seafood.
Mandating that people reimplement all IE APIs reinforces dependence. It implies ownership of the web by Microsoft.
Pfft. Re-implementing IE's API's gives users convenient options. Forcing users to change their code to support a browser that nobody uses anyway is a recipe for permanent marginality.
As a user, if Mozilla doesn't serve your purposes, you can use IE. No one is stopping you. As a page author, there is little excuse.
Huh? The only mandate on developers is to use what works. If document.all works 95+% of the time, then it's very, very hard to argue that they were wrong to use it.
You misunderstand. I think that implementing document.all in its entirety is non-trivial.
I understood exactly what you're saying. Why would implementing document.all be non-trivial? The code to perform that function is already there; all one would have to do is add a new entry point for it.
A clean API that is used by everyone -- including Microsoft -- makes perfect sense.
No, it doesn't. This is a popular misconception. A "clean API" is of no value whatsoever. What makes perfect sense is software that does what users need, want, and expect it to do. Breaking compatibility with the de facto standard in favor of a de jure standard that is at best irrelevant makes no sense at all, from any perspective.
The Mozilla project's stated goal is standards compliance -- not IE compatibility. If it doesn't serve your needs, don't use it.
Don't worry. I don't. Neither does virtually anybody else. Given this attitude on the part of the developers, it's easy to see why.
You lost me at "centralized." You've got 70 branch offices and you want to create a centralized file server for all of them? Have you considered how much this is going to cost per month is telecom charges alone?
If you're remotely accessing a file server, a point-to-point T-1 per branch office is the absolute bare minimum you'll need for connectivity. Don't even think about using a VPN over the Internet; the latencies will be so high that nobody at the branch offices will be able to tolerate using the central file server, so they'll store their files locally, which defeats the whole purpose.
A much better idea would be to put small NAS devices at each branch office, and a big server at the central office. Have the central server back up each NAS server every hour, either using a commercial backup product like Legato (bad idea) or using the NAS vendor's remote mirror feature (good idea). Snap's remote mirror feature, for example, is called Server-to-Server Synchronization. You can do remote-to-central syncs over a VPN over DSL or something equivalent.
There will probably be occasions when a branch needs to access files from another branch. When that happens, you can either have the person who needs the file mount the appropriate filesystem from the central office and copy his file, or you could get a little fancier. You could easily whip up a simple system for scheduling asynchronous file requests. Person X goes to a web page (hosted at the central site) and finds the file that he wants, then clicks a button to submit a transfer request. He goes about his business while the file is transferred via FTP (probably) from the central server to the branch server, then he gets an email, IM, or SMS informing him that the transfer is complete. You could just let all the transfers happen at once, or you could get a little fancier by priority-queueing the requests and executing them in order. This would have the advantages of being easier for your users-- they wouldn't have to know where the file was stored; they could just search for it-- and of keeping all the files on the various NAS servers for easy administration and backup.
$3000 is with 256M. OSX needs 370M to not hit the pagefile...
That's completely bogus. I used an iBook with 256 MB every day for over a year with zero problems at all. My new Power Mac was only recently upgraded from 256 MB to 512 MB, and the only time I noticed swapping before the upgrade was when I was running Virtual PC. 256 MB would be just fine for an XServe, particularly if you're not running a web server or any additional stuff like that. Any extra RAM would be used for filesystem caching, which would be a good thing, but not a make-or-break thing.
I know that the X11 primary selection is somehow bridged to the system clipboard, so you can select in an X11 application and paste in an OS X application and vice versa, but does this interface handle styled text or graphics? I use the clipboard for moving styled text, Unicode text, and images around all the time, and not being able to do that to and from my word processor would kill me.
It's a simple matter of the rule of least effort. One method works for IE4 to 6, no Mozilla/Netscape. The other method works for IE5+/Mozilla/Netscape6+.
But the first method is already used in hundreds of thousands of lines of JavaScript code. (In my late, lamented company's vault alone.) Seems to me that "less effort" would be implementing the fucking thing in the browser.
This is just one example of the Mozillans' choices to stick to principles or standards rather than go the extra step for IE compatibility. It's obvious from their attitude that they generally couldn't care less whether anybody uses IE or not... so virtually everybody, even all this time after the release of "1.0," still uses IE.
Re:I wonder if the framers of the constitution...
on
Dow vs. Parody
·
· Score: 2
In other words I don't give a flying fuck whether 'everybody' accepts it or not.
That's fine, too. If nobody respects your alleged right to a free lunch, or whatever, then you can yell and scream about it all day but you're still not going to get your free lunch.
People in this category include your garden variety libertarians, who appear (from their party platform) to believe they have a right to a whole bunch of stuff that they simply aren't going to get.
I think the words you're groping for here are "compatibility" and "convenience."
As for needing document.all, you can add it yourself to point to the resources you need.
Since it's trivial to implement it with JavaScript, and it's a feature of 95% (maybe more) of the browsers out there, why not implement it in the engine itself? Arguing that it's an easy thing to add yourself doesn't make a very compelling argument against implementing it in the browser, in my opinion.
There's plenty of perversion in web browsers. Why pick on Mozilla's ommision of document.all?
Because Mozilla is the tall poppy. The Mozillans hop on pop about their rigid and total standards compatibility, while for no good reason breaking compatibility with the vast, vast, majority of browsers and of JavaScript out there. Makes no sense.
But it does kind of prove the point. They could have added support for document.all, just like they did for innerHTML, but they didn't, for reasons that I can only describe (as I did before) as perverse.
hmm by the choice of non-stories slashdot posts about Apple, it would be nice to have a Mac person working for slashdot. I'll volunteer:) -- Yes, I did graduate from a top 25 university and no I can't spell or use grammar properly, guess it doesn't matter:)
Nice sig. You're definitely qualified to be an editor.;-)
It's easy. Go to http://www.mac.com. Log in. Look at the giant thing that says, ".Mac address book with contact synchronization available Jan. 7." Submit story to Slashdot. Profit!
Lost them? Dude, iPhoto doesn't hide your photos someplace sneaky. They're right there in your Pictures folder. They're organized a little funny, but they're in there.
Two things. First, there's nothing wrong with proprietary extensions to an API. Gasp! Yeah, you heard me. There's nothing wrong with proprietary extensions to an API. If it works, implement it.
Second, it's been quite a while since I did any web programming-- that company ceased to exist about 6 months ago-- but I do not believe IE 5 or 6 supports getElementById. My memory could be flawed on that point, but I seem to recall that a good deal of code had to be stuck inside conditionals with document.all for IE and document.getElementById for Mozilla.
The browser market share is something like 99.9999% Internet Explorer Mozilla/Netscape 7 supports everything
That's not true. Mozilla (perversely, in my opinion) does not support document.all. It's possible to use a different method to perform the same function, but it's unnecessarily verbose.
Again, nuts. If you have to explain what you mean by "free" at this level of detail, then "free" is obviously not the correct word to use to describe it.
These are just mistakes on the part of the staff. They happen. We have posted over ten thousand stories in our history. The occasional duplicate is inevitable.
What they neglect to mention is that of the 10,000 stories posted on Slashdot, 4,000 of them were duplicates and another 1,000 of them were rumors, incorrect, or just plain trolls.
Re:I wonder if the framers of the constitution...
on
Dow vs. Parody
·
· Score: 2
I can assure you that I (and you) require certain rights whether you or the mob choose to recognize them or not. The fact that one can be imprisoned or killed, in some countries, for exercising those rights in no way means I (and you) don't require them.
In other words, you want everybody to accept that you have these rights. No problem. That's a "type 3" usage of the word "right." Just like I've been saying.
Slashdot Mirror
Mr. Anonymous Coward forgets that the Earth didn't come from the factory with an oxygen atmosphere. Plankton make oxygen from carbon dioxide; carbon dioxide, of course, is produced by the Earth itself in geological processes.
If it were true that oxygen leaves the Earth's atmosphere-- it's not, in any significant sense-- then the plankton in our oceans would simply replace it, maintaining the equilibrium we've enjoyed for the last billion years or so.
Mr. Anonymous Coward is evidently an Anonymous Idiot.
Compare an American chicken to an Italian (or, more generally, western European) chicken and say that again. European chickens are generally scrawny, tough, gamey birds. American chickens are fatter, and more succulent. This is partly because of different farming methods, but also due to the genetics of the different populations.
There are other benefits to selective farm breeding. Farm-raised pigs have sweeter, more pleasant flesh than wild pigs, and are virtually free of Trichinella nematodes. Farm-raised veal results in a meat that is simply unavailable in free-range animals. And, of course, farm-raised seafood is almost universally superior to wild seafood.
document.all is not a good API.
Why?
Mandating that people reimplement all IE APIs reinforces dependence. It implies ownership of the web by Microsoft.
Pfft. Re-implementing IE's API's gives users convenient options. Forcing users to change their code to support a browser that nobody uses anyway is a recipe for permanent marginality.
As a user, if Mozilla doesn't serve your purposes, you can use IE. No one is stopping you. As a page author, there is little excuse.
Huh? The only mandate on developers is to use what works. If document.all works 95+% of the time, then it's very, very hard to argue that they were wrong to use it.
You misunderstand. I think that implementing document.all in its entirety is non-trivial.
I understood exactly what you're saying. Why would implementing document.all be non-trivial? The code to perform that function is already there; all one would have to do is add a new entry point for it.
A clean API that is used by everyone -- including Microsoft -- makes perfect sense.
No, it doesn't. This is a popular misconception. A "clean API" is of no value whatsoever. What makes perfect sense is software that does what users need, want, and expect it to do. Breaking compatibility with the de facto standard in favor of a de jure standard that is at best irrelevant makes no sense at all, from any perspective.
The Mozilla project's stated goal is standards compliance -- not IE compatibility. If it doesn't serve your needs, don't use it.
Don't worry. I don't. Neither does virtually anybody else. Given this attitude on the part of the developers, it's easy to see why.
Because it's not in the standard, period.
That one sentence sums up why nobody gives a damn about Mozilla.
You, like so many other Slashdotters, seem to have forgotten that the purpose of the computer is to work for the user. Not the other way around.
You lost me at "centralized." You've got 70 branch offices and you want to create a centralized file server for all of them? Have you considered how much this is going to cost per month is telecom charges alone?
;-)
If you're remotely accessing a file server, a point-to-point T-1 per branch office is the absolute bare minimum you'll need for connectivity. Don't even think about using a VPN over the Internet; the latencies will be so high that nobody at the branch offices will be able to tolerate using the central file server, so they'll store their files locally, which defeats the whole purpose.
A much better idea would be to put small NAS devices at each branch office, and a big server at the central office. Have the central server back up each NAS server every hour, either using a commercial backup product like Legato (bad idea) or using the NAS vendor's remote mirror feature (good idea). Snap's remote mirror feature, for example, is called Server-to-Server Synchronization. You can do remote-to-central syncs over a VPN over DSL or something equivalent.
There will probably be occasions when a branch needs to access files from another branch. When that happens, you can either have the person who needs the file mount the appropriate filesystem from the central office and copy his file, or you could get a little fancier. You could easily whip up a simple system for scheduling asynchronous file requests. Person X goes to a web page (hosted at the central site) and finds the file that he wants, then clicks a button to submit a transfer request. He goes about his business while the file is transferred via FTP (probably) from the central server to the branch server, then he gets an email, IM, or SMS informing him that the transfer is complete. You could just let all the transfers happen at once, or you could get a little fancier by priority-queueing the requests and executing them in order. This would have the advantages of being easier for your users-- they wouldn't have to know where the file was stored; they could just search for it-- and of keeping all the files on the various NAS servers for easy administration and backup.
Email me for more details.
$3000 is with 256M. OSX needs 370M to not hit the pagefile...
That's completely bogus. I used an iBook with 256 MB every day for over a year with zero problems at all. My new Power Mac was only recently upgraded from 256 MB to 512 MB, and the only time I noticed swapping before the upgrade was when I was running Virtual PC. 256 MB would be just fine for an XServe, particularly if you're not running a web server or any additional stuff like that. Any extra RAM would be used for filesystem caching, which would be a good thing, but not a make-or-break thing.
I know that the X11 primary selection is somehow bridged to the system clipboard, so you can select in an X11 application and paste in an OS X application and vice versa, but does this interface handle styled text or graphics? I use the clipboard for moving styled text, Unicode text, and images around all the time, and not being able to do that to and from my word processor would kill me.
Anybody know what the deal is here?
It's a simple matter of the rule of least effort. One method works for IE4 to 6, no Mozilla/Netscape. The other method works for IE5+/Mozilla/Netscape6+.
But the first method is already used in hundreds of thousands of lines of JavaScript code. (In my late, lamented company's vault alone.) Seems to me that "less effort" would be implementing the fucking thing in the browser.
This is just one example of the Mozillans' choices to stick to principles or standards rather than go the extra step for IE compatibility. It's obvious from their attitude that they generally couldn't care less whether anybody uses IE or not... so virtually everybody, even all this time after the release of "1.0," still uses IE.
In other words I don't give a flying fuck whether 'everybody' accepts it or not.
That's fine, too. If nobody respects your alleged right to a free lunch, or whatever, then you can yell and scream about it all day but you're still not going to get your free lunch.
People in this category include your garden variety libertarians, who appear (from their party platform) to believe they have a right to a whole bunch of stuff that they simply aren't going to get.
document.all adds nothing except IE dependance.
I think the words you're groping for here are "compatibility" and "convenience."
As for needing document.all, you can add it yourself to point to the resources you need.
Since it's trivial to implement it with JavaScript, and it's a feature of 95% (maybe more) of the browsers out there, why not implement it in the engine itself? Arguing that it's an easy thing to add yourself doesn't make a very compelling argument against implementing it in the browser, in my opinion.
There's plenty of perversion in web browsers. Why pick on Mozilla's ommision of document.all?
Because Mozilla is the tall poppy. The Mozillans hop on pop about their rigid and total standards compatibility, while for no good reason breaking compatibility with the vast, vast, majority of browsers and of JavaScript out there. Makes no sense.
But it does kind of prove the point. They could have added support for document.all, just like they did for innerHTML, but they didn't, for reasons that I can only describe (as I did before) as perverse.
;-)
Oh, well. You get what you pay for, I guess.
hmm by the choice of non-stories slashdot posts about Apple, it would be nice to have a Mac person working for slashdot. I'll volunteer :) :)
;-)
--
Yes, I did graduate from a top 25 university and no I can't spell or use grammar properly, guess it doesn't matter
Nice sig. You're definitely qualified to be an editor.
As another poster pointed out, IE 5+ does implement the correct (DOM) way to do this.
Okay, I stand corrected.
Then, that extension should be dropped.
Why? Is the whole world going the way of Java, where every dot release deprecates whole swaths of the API? If both methods work, implement them both!
It's easy. Go to http://www.mac.com. Log in. Look at the giant thing that says, ".Mac address book with contact synchronization available Jan. 7." Submit story to Slashdot. Profit!
iPhoto recently lost all 501 of my photos
Lost them? Dude, iPhoto doesn't hide your photos someplace sneaky. They're right there in your Pictures folder. They're organized a little funny, but they're in there.
The prevailing rumor is that the asking price will be around $50 for iDVD, iMovie, and iPhoto together.
In other news, Apple is rumored to make an announcement about 802.11g.
Two things. First, there's nothing wrong with proprietary extensions to an API. Gasp! Yeah, you heard me. There's nothing wrong with proprietary extensions to an API. If it works, implement it.
Second, it's been quite a while since I did any web programming-- that company ceased to exist about 6 months ago-- but I do not believe IE 5 or 6 supports getElementById. My memory could be flawed on that point, but I seem to recall that a good deal of code had to be stuck inside conditionals with document.all for IE and document.getElementById for Mozilla.
The browser market share is something like 99.9999% Internet Explorer
Mozilla/Netscape 7 supports everything
That's not true. Mozilla (perversely, in my opinion) does not support document.all. It's possible to use a different method to perform the same function, but it's unnecessarily verbose.
Again, nuts. If you have to explain what you mean by "free" at this level of detail, then "free" is obviously not the correct word to use to describe it.
I know what #1 will be...
$#@#$fdscv
Yeah, but if you use English; you can just say $SHOE_SIZE instead.
From the FAQ:
These are just mistakes on the part of the staff. They happen. We have posted over ten thousand stories in our history. The occasional duplicate is inevitable.
What they neglect to mention is that of the 10,000 stories posted on Slashdot, 4,000 of them were duplicates and another 1,000 of them were rumors, incorrect, or just plain trolls.
I can assure you that I (and you) require certain rights whether you or the mob choose to recognize them or not. The fact that one can be imprisoned or killed, in some countries, for exercising those rights in no way means I (and you) don't require them.
In other words, you want everybody to accept that you have these rights. No problem. That's a "type 3" usage of the word "right." Just like I've been saying.
Members of the historic Pepys family said today they pronounce the name "Throat-wobbler Mangrove."
In other news, hillbillies today said that they would prefer to be called "sons of the soil."