Re:Don't read too much into Googles response ...
on
Forget Moore's Law?
·
· Score: 1
That's what they invented hashes for. What do you thing the "q=cache:CjvO3xI_O_EC:" is for on the google URLs for cached pages?
I wasn't talking about google in this case, I was talking about ebay. Ebay doesn't keep a server# or hash in the url.
Definitely no mirrroring
Right, again that was my point, google doesn't need to mirror in the same way that ebay does. Ebay does realtime updating of data where the backend has to be synchronized for anyone accessing a single piece of data, for google it just doesn't matter how timely the information is. You don't mirror in the classic sense, you just make sure your data is redundant enough to have all the interesting bits located in several different places, which you will since you have your server farm anyway. Each machine just updates whenever it is convenient.
Software expenses are countered by using software that isn't licensed per seat (hint: Google runs on Linux).
In this case I was talking about database servers. You're not going to be able to run ebay on mysql, and those multiple Oracle licenses get darn spendy, even if your os license is free.
Ebay has a google-type application. Ebay could do exactly the same thing by splitting their database by auction or seller. A search query goes to each db server that has everything in RAM so that it can easily handle the request load.
No it's not, totally different. Having to update information realtime makes it a completely different application. Queries (well searches) are nothing, you just create your static pages (or cached dynamic pages) where convenient. However, everytime someone bids on an item, that item has to be reflected and it can't just be in ram, it can be cached, but it HAS to be written immediately to the backend store.
There are tops only a few dozen of people active per auction, so each server should easily be capable of more than one auction.
Optimizations are possible too: auction distribution could balance the load by making sure that not all auctions for a machine end at the same time.
Auctions end based on when they were posted and so are not arbitrarily distributed. On any given day they have 12million ongoing auctions. If we assume that the average auction duration is 5 days, that means that approx 2million auctions end every day, that comes out to roughly 23 auctions ending every second (1400/minute). If you have an average of three "snipers" bidding on an auction in the last minute thats 4200 bids a minute, and that's assuming an even distribution, which it isn't. And all this is just bidding, not searching or doing whatever other stuff people do. So when you're specing this system out and coming up with requirements, the part of your software that is responsible for REALTIME updating/displaying has to be able to handle this. This isn't just a few linux boxes, it would be a LOT of linux boxes which would HAVE to be mirrored (since like any other ecommerce site downtime means no money time).
Again, I'm not even counting the searches and other routine account maintenance. I'm talking about a site that has to do realtime updating with multiple people hitting the same data at a very high rate. google has it easy, their app is perfect for web access, stateless, can't ask for anything easier. They can throw whatever hardware their whim desires. They could leave old data for an entire day and very few people would notice. ebay has no such luxury.
Re:Don't read too much into Googles response ...
on
Forget Moore's Law?
·
· Score: 1
No. Ebay has one synchronization requirement per auction item.
I stated as much in my original post. The issue is that having _any_ synchronization requirement suddenly makes your back end much more complex. If you're fronting your system with a server farm, you suddenly have to have a mechanism that "knows" exactly which db server has the item you're interested in. When you're creating your listing pages, you have to query multiple db servers to complete your listings. If you're trying to spread the db load amongst different machines, then your software expenses increase proportionatly. Are you mirroring your db servers, then you have to mirror multiple boxes which once again is more expensive. All these things are either non issues are greatly dimished when you have the google type application. So even though "spread the db's around" sounds simple, the implications are huge. Oh, and you have to partition by auction, NOT by seller, since seller state is not an issue, your fronting server farm can deal with that.
Re:And how would IA64 chips solve that problem?
on
Forget Moore's Law?
·
· Score: 1
So why would eBay go to IA64? Where's the win?
I never said that ebay would/should go with IA64. I was just pointing out that the computing requirements for google differed form that of ebay. ebay has more of a need for bigger iron than google does because of differences in their applications. Last I heard ebay was using a few e10k's anyway (maybe they've upgraded to SunFire's by now?), at least for the database stuff, so they're already 64bit.
Re:Don't read too much into Googles response ...
on
Forget Moore's Law?
·
· Score: 1
That's not entirely right. EBay isn't really any more synchronised than Google
That's why I said in my post:
ALL their servers (well the non listing ones) HAVE to be going after a single or synchronized data source.
But to characterize this delayed listing as "isn't really any more synchronised than Google" is really missing the point. Google has NO synchronization requirements, ebay has one huge one. And this difference is all the difference in the world when you're architecting your back end. You end up with two vastly different requirements and correspondingly, two vastly different approaches.
Don't read too much into Googles response ...
on
Forget Moore's Law?
·
· Score: 3, Insightful
For their application having clusters of "smaller" machines make sense. Lets compare this to ebay.
The data google deals with is non real time. They churn on some data and produce indices. A request comes in over a server, that server could potentially have it's own copy of the indices and can access a farm of servers that hold the actual data. The fact that the data and indices live on farms is no big deal as there is no synchronization requirement between them. If server A serves up some info but is 15 minutes behind server Z, that's ok. This is a textbook application for distributed non-stateful server farms
Now ebay, ALL their servers (well the non listing ones) HAVE to be going after a single or synchronized data source. Everybody MUST have the same view of an auction and all requests coming in have to be matched up. The "easiest" way to do this is by going against a single data repository (well single in the sense that the data for any given auction must reside in one place, different auctions can live on different servers of course). All this information needs to be kept up on a real time basis. So ebay also has the issue of transactionally updating data in realtime. Thus their computing needs are significantly different than that of google.
They're shielded cables, of course they're going to be more expensive than an IDE ribbon.
That's not what we're comparing it to. Back in the mid 80's a 3ft scsi cable could easily cost >$100 depending on manufacturer. Now that's outrageous, shielded or not. Then again ethernet adaptors were over $1000, so I guess everything was expensive back then;)
"The RISC OS 5.00 kernel did not contain work taken from or derived from the ARM-Linux or Linux kernel
then they say:
has it's PCI allocation and bridge setup based in part on the following functions from the Linux kernel sources:
So they say "based in part on the following functions", so are they saying that they have literally taken no CODE but were BASING their code on some Linux kernel code? So are they then saying that perhaps they just took the api from the LK but the code itself is new? If this is the case, then I could see how there would be a lot of confusion and that they have done nothing wrong. If not, then I'm not sure what they're trying to say?
I can see not wanting configure applications on small network, but with all of these broadcast packets i would imagine it would saturate a low speed (read:wireless) network.
Oh yeah, I -REALLY- want my phone to drop out whenever someone tries to microwave their lunch.
I think you're thinking too much about the here and now and not about the future. Just as 20 years ago, tcp/ip might have seemed like overkill for those slow 2Mbps wires just to shuttle some files around, the current uses are many and varied. Rendezvous as a standardized protocol can open up a lot of possibilities that may not be appropriate for todays hardware, but could really be opened up by tomorrows. Even today if you were using an 802.11a network, you wouldn't have the interference concerns (well at least not as much) as well as having the additional bandwidth required become a smaller issue.
And speaking of bandwidth, I haven't read the spec, but assuming that "servers" only broadcast when re-configs take place and that clients only broadcast when discovery needs to occur, in a typical office environment, these items do not happen that often (employee comes in the office, turns computer on, starts working, turns off computer at 5), so I would doubt that the overall impact on network performance would be all that great (again, I don't know, just conjecturing). Now if you tried to run your 200 line phone system using voip over this thing, then yes, I could see how that might cause a few issues with your other traffic (and vice-versa).
Funny, I've hot plugged keyboards and mice on PC's for years without a problem. I think not being able to hot plug them is a myth that's been perpetrated ever since the original IBM PC had a flakey keyboard controller that could fry if you hot-plugged it. Modern hardware doesn't have this problem.
Well we were talking about times past, even before ps/2 came around. I've always had hit or miss experiences with keyboards. Pre-386 kb's tended to stop working after they were pulled. A couple of old Dell's would actually lock up the system if you tried to plug the kb back in after you unplugged it. Dell's from about 4-5 years ago had problems when unplugging ps/2 kb and mice. The kb repeat rate would get hosed (you could correct it by going back and tweaking the values) and the mouse tracking rate would also get messed up. Now I can't say with certainty if this was a kb/mouse problem, or just Windoze (NT) getting confused, but it was far from "plug and play".
I don't know all the reasons, but at least one is that the max length for an ide cable is like a foot and a half. Add to that the intervening connectors and I assume that the ide signal is not robust enough to survive such a rugged journey.
God forbid you pull a cable with the power on. Plus the SCSI cables were *expensive*.
Remember that hot pluggable peripherals is a realtively recent thing (at least affordable ones). Back then they were warning you not to unplug your parallel cables while computer/printer was on. And god forbid you unplugged your kb or mouse (this is all on a pc). Your right about the scsi cables, absolutely criminal the cost of those stupid things.
Does anyone else remember "analysts" making fun of Apple for going to USB and Firewire?
Remember, you can always spot the trailblazers, they're the ones with the arrows sticking out their backs;)
I guess that's progress for you, but we can't help but feel screwed over.
Why is that? This happens every day to people who've bought almost any kind of computer/electronic anything? I can understand feeling kinda bummed out over the timing, but that's a lot different than feeling "screwed over". Is Apple supposed to say, "Now watch out everybody, we're going to bump the hardware in about a month or so, so don't buy anything right now"? Or are you saying that Apple should always have new models be more expensive than old ones just to make recent purchasers of the older models not feel bad?
What I do not understand is why anybody is interested in having Apple servers. Afterall servers do not have to look good, they just have to be cheap and fast.
Well if previous Apple server sales (pre xserve) are any indication, nobody is;)
But seriously, these boxes are for Mac shops. It provides them with a "real" server platform, but one that uses an os that is common with their desktop machines, making maintenance muuuuch simpler. Plus if the servers are easier to maintain in general, then you have a potentially huge savings from that fact alone. After all, how many places need raw cpu power, some obviously do, but I would guess that the majority have other issues that are more critical to them. This is a no brainer for people who are simply using the things as file servers, as the specs are more than adequate for that. I don't think people are looking at these things (or Apple positioning them) as massive compute servers to run their TB Oracle database servers on.
Most importantly, it keeps shops in the Apple fold. One argument that people could make is that if they have to go with pc/linux servers, then they might as well go with the desktops too, again to simplify maintenance. This way, Apple ensures that people stay 100% Mac and keep the M$/Linux infiltration at bay.
Well if you're refering to the general switch from scsi to ide, then not really. Apple adopted scsi wwwwaaay back before ide even existed. Back then there was scsi or mfm/rll. And mfm/rll only offered internal hard drive storage, no scanners, no external drives. So the original adoption of scsi made complete sense back then. Apples continued use of scsi made sense for almost exactly the same reasons. Many people had things like scanners and external hd's (dtp, video, etc), so a move to ide wouldn't have made sense even if it would have resulted in a somewhat cheaper disk subsystem, since they'd most likely would have to have shipped scsi anyway.
Now fast forward, things like usb and firewire take care of things like scanners and other higher speed peripherals, the the internal disk bus can be just that. So all of a sudden ide makes sense. And then in terms of performance, ide has definitely caught up and it would be hard to make an argument for scsi from a strictly price/performance standpoint.
So, while a curiousity, it not all that ironic, just a sign of the times.
Welcome to the User Agreement for eBay Inc. The following describes the terms on which eBay offers you access to our services.
This agreement describes the terms and conditions applicable to your use of our services available under the domain and sub-domains of www.ebay.com (including half.ebay.com, ebaystores.com) and the general principles for the Web sites of our subsidiaries and international affiliates. If you do not agree to be bound by the terms and conditions of this agreement, please do not use or access our services.
Notice that it doesn't say anything about registering, it says "using their serice", which could be interpreted as also browsing, since that is a "feature" offered by their website. Registering simply brings into effect other parts of the eula that are applicable to those actions. If nothing else, the contents of the site are still copyrighted, so even if you didn't agree to their eula, you still couldn't do anything with the content.
One of the biggest sites that I've not seen anyone mention is eBay. Following is in their eula:
Our Web site contains robot exclusion headers and you agree that you will not use any robot, spider, other automatic device, or manual process to monitor or copy our Web pages or the content contained herein without our prior expressed written permission.
You agree that you will not use any device, software or routine to bypass our robot exclusion headers, or to interfere or attempt to interfere with the proper working of the eBay site or any activities conducted on our site.
You agree that you will not take any action that imposes an unreasonable or disproportionately large load on our infrastructure.
Much of the information on our site is updated on a real time basis and is proprietary or is licensed to eBay by our users or third parties. You agree that you will not copy, reproduce, alter, modify, create derivative works, or publicly display any content (except for Your Information) from our Web site without the prior expressed written permission of eBay or the appropriate third party.
Now why they do this is obvious, they have an absolute goldmine of information and they want to be able to take advantage of it when they're good and ready. I assume other sites could adopt this type of eula, which wouldn't make the software itself illegal, but would make using it so (or at least until someone challenges it).
It would have been nice to have more details on how the book was soooo heavily bent towards VC++. I would assume by the fact that he makes such a big deal out of it that these references are such that it wouldn't do any good for a non VC++ programmer? Are these things specific to the environment (visual studio, debugging, etc) or the OS (win32 api, m$ specific data types, etc).
Overall, I think his review needs a bit more beef (i.e. more examples) vs just saying "I thought it was blah..." and us having to just take his word for it. Even more so because of the topic and the level at which it is apparently targeted.
I'll have to show to article to the wife. That way the next time I get the hiccups, she'll understand why I start going for, uh well, if you read the article you'll know.
One approach they could take would be to tier it like cellular service. Pay a flat amount for a certain amount of bits, if you go over, then pay extra. Remember, they _could_ afford to lower prices for some if they can raise the prices for others to compensate. In the end, they want to make money, so they have plenty of data for them to try to come up with a pricing scheme that will allow them to continue doing so.
The vast masses are not chewing up the most bandwidth. And I would disagree, I think many would choose "internet". How are p2p users like the golden goose? They suck up bandwidth and the real valuable users are the ones that barely use the system, they help pay for those who really do use bandwidth. After all, it would be simple to adopt a cell phone type of strategy where the price is fixed for a certain amount of usage, and then is metered above that amount.
any attempts to change their pricing to this model will be met by massive consumer outcry.
But if ALL the high speed isp's start charging "by the bit", then why would they care if their p2p customers start bitching. They are under no legal obligation to provide unlimited bandwidth. And if the p2p people don't like it, they can switch back to dialup is what they'll say. I think that "by the bit" is inevitable. They don't do it now because they are all trying to stay afloat and expand their customer bases. But once they have a nice critical mass built up, then they'll start metering. Makes too much sense. It's "fair" in that those who use the most, pay the most. They wouldn't care how many machines are hiding behind your NAT, because in the end, they'll still get their money (depending on pricing scales of course).
Re:I have a question.
on
Columbia Coverage
·
· Score: 3, Interesting
Why is this tragic accident SO much more important than so many others?
Not to sound too crass, but it's the quality, not the quantity (up to a point) that counts here. You're right, 100 average joes/joettes die somewhere and nobody blinks an eye. Seven astronauts die and the nation is in mourning and the flags are half mast. Why, well it's because the astronauts are celebrities. Why do people make pilgrimages to view Elvis's grave, but wouldn't take to time to stop at the Vietnam war memorial? Why does an entire nation come out the mourn the death of a single "princess"? It's all about who you are. This is no different.
But is this really true? Unless M$ was using some non pin compatable part from Intel, they could have gone with with faster/cheaper parts right? They could always leave the clock the same to maintain compatability, but they could use cheaper revs of the chip. And if M$ sells enough of the things, then it's not as expensive for Intel to continue to fab the chips, unless they have a fab that they're really wanting to upgrade and can't because of all these slower chips they're being forced to produce. I don't see how M$ so tied to the cpu, since it's just another Intel CPU (as far as I know).
Right, but those commodity parts don't have to come from desktop manufacturers right. I mean the technology used for the most part is fairly old (cpu, memory, io). Laptops have gotten significantly more powerful and cheaper in the meantime. Now a laptop has an initial higher cost to manufacture, but once you have the design, you can start cranking them out and make the pieces smaller. Now I haven't seen the innards of a xbox, so I can't speak for how well it's integrated (and judging by the size, I'm assuming not very well), but technically, there should be absolutely no reason to take so long to scale the thing down. That modem that their using has gotten smaller and cheaper and integrated onto a southbridge with the ethernet and other io functions. One serious advantage they have is because it is just a slightly tweaked pc, they should have a tremendous amount of flexibility in speccing parts for the thing, the fact that it uses vendor A's modem in one rev and vendor B's in another, should have a very minimal impact on the system overall, unlike purely inhouse designs like the PS2/GC.
OK, M$ was NEVER going to profit from xbox sales without getting the cost of the box itself down to either lower their loss on each box, or maybe show a profit (don't know exactly which point they're at right now). What's curious is that even though their using "commodity" parts, it has taken them this long to get the thing shrunk. You would think that with all the resources of the various portable manufacturers, they'd be able to tap into a lot of talent when it comes to making smaller/more compact packages. Heck, it's not like the things bleeding edge hardware wise, cooling should not be an issue, and performance isn't (as far as needing to increase it), so why has it taken SOOOOOO long to come up with a smaller cheaper (for M$) xbox? This is a critical time for xbox, it has to wait the entire year before the next holiday rush. In the meantime Sony will be starting to get the PS3 marketing machine into gear, so this smaller xbox is going to have to pull it's own thru this tough period. If it makes it to xmas, M$ is either going to have to rev the hardware again (smaller and faster/better) or pray that next xmas's sales are spectacular, or xbox won't live too much beyond '04.
I thought Sega was doing well since they tossed their hardware? Last I heard they had a quarterly profit. The article said that they were "propping up" the Japanese manuf., it doesn't sound like Sega needs propping?
Slashdot Mirror
That's what they invented hashes for. What do you thing the "q=cache:CjvO3xI_O_EC:" is for on the google URLs for cached pages?
I wasn't talking about google in this case, I was talking about ebay. Ebay doesn't keep a server# or hash in the url.
Definitely no mirrroring
Right, again that was my point, google doesn't need to mirror in the same way that ebay does. Ebay does realtime updating of data where the backend has to be synchronized for anyone accessing a single piece of data, for google it just doesn't matter how timely the information is. You don't mirror in the classic sense, you just make sure your data is redundant enough to have all the interesting bits located in several different places, which you will since you have your server farm anyway. Each machine just updates whenever it is convenient.
Software expenses are countered by using software that isn't licensed per seat (hint: Google runs on Linux).
In this case I was talking about database servers. You're not going to be able to run ebay on mysql, and those multiple Oracle licenses get darn spendy, even if your os license is free.
Ebay has a google-type application. Ebay could do exactly the same thing by splitting their database by auction or seller. A search query goes to each db server that has everything in RAM so that it can easily handle the request load.
No it's not, totally different. Having to update information realtime makes it a completely different application. Queries (well searches) are nothing, you just create your static pages (or cached dynamic pages) where convenient. However, everytime someone bids on an item, that item has to be reflected and it can't just be in ram, it can be cached, but it HAS to be written immediately to the backend store.
There are tops only a few dozen of people active per auction, so each server should easily be capable of more than one auction. Optimizations are possible too: auction distribution could balance the load by making sure that not all auctions for a machine end at the same time.
Auctions end based on when they were posted and so are not arbitrarily distributed. On any given day they have 12million ongoing auctions. If we assume that the average auction duration is 5 days, that means that approx 2million auctions end every day, that comes out to roughly 23 auctions ending every second (1400/minute). If you have an average of three "snipers" bidding on an auction in the last minute thats 4200 bids a minute, and that's assuming an even distribution, which it isn't. And all this is just bidding, not searching or doing whatever other stuff people do. So when you're specing this system out and coming up with requirements, the part of your software that is responsible for REALTIME updating/displaying has to be able to handle this. This isn't just a few linux boxes, it would be a LOT of linux boxes which would HAVE to be mirrored (since like any other ecommerce site downtime means no money time).
Again, I'm not even counting the searches and other routine account maintenance. I'm talking about a site that has to do realtime updating with multiple people hitting the same data at a very high rate. google has it easy, their app is perfect for web access, stateless, can't ask for anything easier. They can throw whatever hardware their whim desires. They could leave old data for an entire day and very few people would notice. ebay has no such luxury.
No. Ebay has one synchronization requirement per auction item.
I stated as much in my original post. The issue is that having _any_ synchronization requirement suddenly makes your back end much more complex. If you're fronting your system with a server farm, you suddenly have to have a mechanism that "knows" exactly which db server has the item you're interested in. When you're creating your listing pages, you have to query multiple db servers to complete your listings. If you're trying to spread the db load amongst different machines, then your software expenses increase proportionatly. Are you mirroring your db servers, then you have to mirror multiple boxes which once again is more expensive. All these things are either non issues are greatly dimished when you have the google type application. So even though "spread the db's around" sounds simple, the implications are huge. Oh, and you have to partition by auction, NOT by seller, since seller state is not an issue, your fronting server farm can deal with that.
So why would eBay go to IA64? Where's the win?
I never said that ebay would/should go with IA64. I was just pointing out that the computing requirements for google differed form that of ebay. ebay has more of a need for bigger iron than google does because of differences in their applications. Last I heard ebay was using a few e10k's anyway (maybe they've upgraded to SunFire's by now?), at least for the database stuff, so they're already 64bit.
That's not entirely right. EBay isn't really any more synchronised than Google
That's why I said in my post:
ALL their servers (well the non listing ones) HAVE to be going after a single or synchronized data source.
But to characterize this delayed listing as "isn't really any more synchronised than Google" is really missing the point. Google has NO synchronization requirements, ebay has one huge one. And this difference is all the difference in the world when you're architecting your back end. You end up with two vastly different requirements and correspondingly, two vastly different approaches.
For their application having clusters of "smaller" machines make sense. Lets compare this to ebay.
The data google deals with is non real time. They churn on some data and produce indices. A request comes in over a server, that server could potentially have it's own copy of the indices and can access a farm of servers that hold the actual data. The fact that the data and indices live on farms is no big deal as there is no synchronization requirement between them. If server A serves up some info but is 15 minutes behind server Z, that's ok. This is a textbook application for distributed non-stateful server farms
Now ebay, ALL their servers (well the non listing ones) HAVE to be going after a single or synchronized data source. Everybody MUST have the same view of an auction and all requests coming in have to be matched up. The "easiest" way to do this is by going against a single data repository (well single in the sense that the data for any given auction must reside in one place, different auctions can live on different servers of course). All this information needs to be kept up on a real time basis. So ebay also has the issue of transactionally updating data in realtime. Thus their computing needs are significantly different than that of google.
They're shielded cables, of course they're going to be more expensive than an IDE ribbon.
;)
That's not what we're comparing it to. Back in the mid 80's a 3ft scsi cable could easily cost >$100 depending on manufacturer. Now that's outrageous, shielded or not. Then again ethernet adaptors were over $1000, so I guess everything was expensive back then
At one point they say:
"The RISC OS 5.00 kernel did not contain work taken from or derived from the ARM-Linux or Linux kernel
then they say:
has it's PCI allocation and bridge setup based in part on the following functions from the Linux kernel sources:
So they say "based in part on the following functions", so are they saying that they have literally taken no CODE but were BASING their code on some Linux kernel code? So are they then saying that perhaps they just took the api from the LK but the code itself is new? If this is the case, then I could see how there would be a lot of confusion and that they have done nothing wrong. If not, then I'm not sure what they're trying to say?
I can see not wanting configure applications on small network, but with all of these broadcast packets i would imagine it would saturate a low speed (read:wireless) network.
Oh yeah, I -REALLY- want my phone to drop out whenever someone tries to microwave their lunch.
I think you're thinking too much about the here and now and not about the future. Just as 20 years ago, tcp/ip might have seemed like overkill for those slow 2Mbps wires just to shuttle some files around, the current uses are many and varied. Rendezvous as a standardized protocol can open up a lot of possibilities that may not be appropriate for todays hardware, but could really be opened up by tomorrows. Even today if you were using an 802.11a network, you wouldn't have the interference concerns (well at least not as much) as well as having the additional bandwidth required become a smaller issue.
And speaking of bandwidth, I haven't read the spec, but assuming that "servers" only broadcast when re-configs take place and that clients only broadcast when discovery needs to occur, in a typical office environment, these items do not happen that often (employee comes in the office, turns computer on, starts working, turns off computer at 5), so I would doubt that the overall impact on network performance would be all that great (again, I don't know, just conjecturing). Now if you tried to run your 200 line phone system using voip over this thing, then yes, I could see how that might cause a few issues with your other traffic (and vice-versa).
Funny, I've hot plugged keyboards and mice on PC's for years without a problem. I think not being able to hot plug them is a myth that's been perpetrated ever since the original IBM PC had a flakey keyboard controller that could fry if you hot-plugged it. Modern hardware doesn't have this problem.
Well we were talking about times past, even before ps/2 came around. I've always had hit or miss experiences with keyboards. Pre-386 kb's tended to stop working after they were pulled. A couple of old Dell's would actually lock up the system if you tried to plug the kb back in after you unplugged it. Dell's from about 4-5 years ago had problems when unplugging ps/2 kb and mice. The kb repeat rate would get hosed (you could correct it by going back and tweaking the values) and the mouse tracking rate would also get messed up. Now I can't say with certainty if this was a kb/mouse problem, or just Windoze (NT) getting confused, but it was far from "plug and play".
Also, why does IDE not do external devices
;)
I don't know all the reasons, but at least one is that the max length for an ide cable is like a foot and a half. Add to that the intervening connectors and I assume that the ide signal is not robust enough to survive such a rugged journey.
God forbid you pull a cable with the power on. Plus the SCSI cables were *expensive*.
Remember that hot pluggable peripherals is a realtively recent thing (at least affordable ones). Back then they were warning you not to unplug your parallel cables while computer/printer was on. And god forbid you unplugged your kb or mouse (this is all on a pc). Your right about the scsi cables, absolutely criminal the cost of those stupid things.
Does anyone else remember "analysts" making fun of Apple for going to USB and Firewire?
Remember, you can always spot the trailblazers, they're the ones with the arrows sticking out their backs
I guess that's progress for you, but we can't help but feel screwed over.
Why is that? This happens every day to people who've bought almost any kind of computer/electronic anything? I can understand feeling kinda bummed out over the timing, but that's a lot different than feeling "screwed over". Is Apple supposed to say, "Now watch out everybody, we're going to bump the hardware in about a month or so, so don't buy anything right now"? Or are you saying that Apple should always have new models be more expensive than old ones just to make recent purchasers of the older models not feel bad?
What I do not understand is why anybody is interested in having Apple servers. Afterall servers do not have to look good, they just have to be cheap and fast.
;)
Well if previous Apple server sales (pre xserve) are any indication, nobody is
But seriously, these boxes are for Mac shops. It provides them with a "real" server platform, but one that uses an os that is common with their desktop machines, making maintenance muuuuch simpler. Plus if the servers are easier to maintain in general, then you have a potentially huge savings from that fact alone. After all, how many places need raw cpu power, some obviously do, but I would guess that the majority have other issues that are more critical to them. This is a no brainer for people who are simply using the things as file servers, as the specs are more than adequate for that. I don't think people are looking at these things (or Apple positioning them) as massive compute servers to run their TB Oracle database servers on.
Most importantly, it keeps shops in the Apple fold. One argument that people could make is that if they have to go with pc/linux servers, then they might as well go with the desktops too, again to simplify maintenance. This way, Apple ensures that people stay 100% Mac and keep the M$/Linux infiltration at bay.
Well if you're refering to the general switch from scsi to ide, then not really. Apple adopted scsi wwwwaaay back before ide even existed. Back then there was scsi or mfm/rll. And mfm/rll only offered internal hard drive storage, no scanners, no external drives. So the original adoption of scsi made complete sense back then. Apples continued use of scsi made sense for almost exactly the same reasons. Many people had things like scanners and external hd's (dtp, video, etc), so a move to ide wouldn't have made sense even if it would have resulted in a somewhat cheaper disk subsystem, since they'd most likely would have to have shipped scsi anyway.
Now fast forward, things like usb and firewire take care of things like scanners and other higher speed peripherals, the the internal disk bus can be just that. So all of a sudden ide makes sense. And then in terms of performance, ide has definitely caught up and it would be hard to make an argument for scsi from a strictly price/performance standpoint.
So, while a curiousity, it not all that ironic, just a sign of the times.
From ebay again:
Welcome to the User Agreement for eBay Inc. The following describes the terms on which eBay offers you access to our services.
This agreement describes the terms and conditions applicable to your use of our services available under the domain and sub-domains of www.ebay.com (including half.ebay.com, ebaystores.com) and the general principles for the Web sites of our subsidiaries and international affiliates. If you do not agree to be bound by the terms and conditions of this agreement, please do not use or access our services.
Notice that it doesn't say anything about registering, it says "using their serice", which could be interpreted as also browsing, since that is a "feature" offered by their website. Registering simply brings into effect other parts of the eula that are applicable to those actions. If nothing else, the contents of the site are still copyrighted, so even if you didn't agree to their eula, you still couldn't do anything with the content.
One of the biggest sites that I've not seen anyone mention is eBay. Following is in their eula:
Our Web site contains robot exclusion headers and you agree that you will not use any robot, spider, other automatic device, or manual process to monitor or copy our Web pages or the content contained herein without our prior expressed written permission.
You agree that you will not use any device, software or routine to bypass our robot exclusion headers, or to interfere or attempt to interfere with the proper working of the eBay site or any activities conducted on our site.
You agree that you will not take any action that imposes an unreasonable or disproportionately large load on our infrastructure.
Much of the information on our site is updated on a real time basis and is proprietary or is licensed to eBay by our users or third parties. You agree that you will not copy, reproduce, alter, modify, create derivative works, or publicly display any content (except for Your Information) from our Web site without the prior expressed written permission of eBay or the appropriate third party.
Now why they do this is obvious, they have an absolute goldmine of information and they want to be able to take advantage of it when they're good and ready. I assume other sites could adopt this type of eula, which wouldn't make the software itself illegal, but would make using it so (or at least until someone challenges it).
It would have been nice to have more details on how the book was soooo heavily bent towards VC++. I would assume by the fact that he makes such a big deal out of it that these references are such that it wouldn't do any good for a non VC++ programmer? Are these things specific to the environment (visual studio, debugging, etc) or the OS (win32 api, m$ specific data types, etc).
..." and us having to just take his word for it. Even more so because of the topic and the level at which it is apparently targeted.
Overall, I think his review needs a bit more beef (i.e. more examples) vs just saying "I thought it was blah
I'll have to show to article to the wife. That way the next time I get the hiccups, she'll understand why I start going for, uh well, if you read the article you'll know.
Fair!?!
One approach they could take would be to tier it like cellular service. Pay a flat amount for a certain amount of bits, if you go over, then pay extra. Remember, they _could_ afford to lower prices for some if they can raise the prices for others to compensate. In the end, they want to make money, so they have plenty of data for them to try to come up with a pricing scheme that will allow them to continue doing so.
The vast masses of home Internet users
The vast masses are not chewing up the most bandwidth. And I would disagree, I think many would choose "internet". How are p2p users like the golden goose? They suck up bandwidth and the real valuable users are the ones that barely use the system, they help pay for those who really do use bandwidth. After all, it would be simple to adopt a cell phone type of strategy where the price is fixed for a certain amount of usage, and then is metered above that amount.
any attempts to change their pricing to this model will be met by massive consumer outcry.
But if ALL the high speed isp's start charging "by the bit", then why would they care if their p2p customers start bitching. They are under no legal obligation to provide unlimited bandwidth. And if the p2p people don't like it, they can switch back to dialup is what they'll say. I think that "by the bit" is inevitable. They don't do it now because they are all trying to stay afloat and expand their customer bases. But once they have a nice critical mass built up, then they'll start metering. Makes too much sense. It's "fair" in that those who use the most, pay the most. They wouldn't care how many machines are hiding behind your NAT, because in the end, they'll still get their money (depending on pricing scales of course).
Why is this tragic accident SO much more important than so many others?
Not to sound too crass, but it's the quality, not the quantity (up to a point) that counts here. You're right, 100 average joes/joettes die somewhere and nobody blinks an eye. Seven astronauts die and the nation is in mourning and the flags are half mast. Why, well it's because the astronauts are celebrities. Why do people make pilgrimages to view Elvis's grave, but wouldn't take to time to stop at the Vietnam war memorial? Why does an entire nation come out the mourn the death of a single "princess"? It's all about who you are. This is no different.
But is this really true? Unless M$ was using some non pin compatable part from Intel, they could have gone with with faster/cheaper parts right? They could always leave the clock the same to maintain compatability, but they could use cheaper revs of the chip. And if M$ sells enough of the things, then it's not as expensive for Intel to continue to fab the chips, unless they have a fab that they're really wanting to upgrade and can't because of all these slower chips they're being forced to produce. I don't see how M$ so tied to the cpu, since it's just another Intel CPU (as far as I know).
Right, but those commodity parts don't have to come from desktop manufacturers right. I mean the technology used for the most part is fairly old (cpu, memory, io). Laptops have gotten significantly more powerful and cheaper in the meantime. Now a laptop has an initial higher cost to manufacture, but once you have the design, you can start cranking them out and make the pieces smaller. Now I haven't seen the innards of a xbox, so I can't speak for how well it's integrated (and judging by the size, I'm assuming not very well), but technically, there should be absolutely no reason to take so long to scale the thing down. That modem that their using has gotten smaller and cheaper and integrated onto a southbridge with the ethernet and other io functions. One serious advantage they have is because it is just a slightly tweaked pc, they should have a tremendous amount of flexibility in speccing parts for the thing, the fact that it uses vendor A's modem in one rev and vendor B's in another, should have a very minimal impact on the system overall, unlike purely inhouse designs like the PS2/GC.
OK, M$ was NEVER going to profit from xbox sales without getting the cost of the box itself down to either lower their loss on each box, or maybe show a profit (don't know exactly which point they're at right now). What's curious is that even though their using "commodity" parts, it has taken them this long to get the thing shrunk. You would think that with all the resources of the various portable manufacturers, they'd be able to tap into a lot of talent when it comes to making smaller/more compact packages. Heck, it's not like the things bleeding edge hardware wise, cooling should not be an issue, and performance isn't (as far as needing to increase it), so why has it taken SOOOOOO long to come up with a smaller cheaper (for M$) xbox? This is a critical time for xbox, it has to wait the entire year before the next holiday rush. In the meantime Sony will be starting to get the PS3 marketing machine into gear, so this smaller xbox is going to have to pull it's own thru this tough period. If it makes it to xmas, M$ is either going to have to rev the hardware again (smaller and faster/better) or pray that next xmas's sales are spectacular, or xbox won't live too much beyond '04.
I thought Sega was doing well since they tossed their hardware? Last I heard they had a quarterly profit. The article said that they were "propping up" the Japanese manuf., it doesn't sound like Sega needs propping?