2. The fact that RedHat will not produce a RedHat-branded free Linux distro was also known for a while.
I just don't remember them saying that they weren't going to provide it for sale at all... I have no problem with them charging for the download, or only selling on CD. I just don't want to have to change distributions!
Change scares me. It's a big scary world out there.:)
If Fedora provides a release in time, I guess I'll have to look at it. I would prefer to purchase a CD from RH. And no, I can't justify US$180/system.
Interestingly, the article doesn't mention that they were going to drop RHL altogether. End of Lifing a specific version is very different from EOL'ing the product line.
It all depends on how structured a development environment you have. If you have automated build systems, then you should be able to do it pretty easily (use the same tags as your last release). The hard bit (I found) was in gathering all of the required documentation. I had to find word documents, txt files, things on Zope, etc...
Of course, we had a policy of checking any non-standard tools into CVS with the code. That way, we versioned the build system with the code. The only things that weren't in CVS were gcc, gmake, bison/flex.
It all flows from how serious you consider the problem of a bad deposit. I went from the point of view of "What would I like to get if the company goes under?" I figured the customers will turn to the current employees if the business goes under. I wouldn't own the existing code, but I would have access to what is in escrow. It was in my individual best interest to see that it worked.:)
Our setup guaranteed that what was in escrow was what was delivered, and what was in escrow compiled - most of the time.:)
Escrow services I have worked for have provided this service. They would take the deposit, construct a build environment, create the installation packages and install/test them.
Of course, they did charge you for that, but it was needed, we had just reported a loss of several million dollars.:)
I remember back to first year CS at University of Waterloo (long time ago). We had been instructed to talk to others, to share information, but to leave the pencils down when you do it.
Anyways, it was the last assignment. I get back my assignment, -100%! It was a direct copy of so-and-so. Now, I'd never heard of the other guy, so I went to the TA, toting the text book I had scarfed the answer from.
When I got there, the TA said that the other student had already been in (with a different book/same author) and re-instated the grade.
I learned 2 lessons that day. Cheating gets you BUSTED, and how to attribute your sources. They hadn't told us about that, so I was LUCKY!
As research, you can check out what Waterloo has done to students that appealed the findings over the past 6 years or so.
You are all missing the point. The only reason that carriers are implementing this functionality is because it is _required_ for emergency services. E911 has specified this for years, and as with most things, carriers have been dragging their feet for years. Europe has the same requirements.
Essentially this is all there to allow 911 operators to know where you are calling from. I've been in a car accident and called 911 from a cell phone. Do you know how hard it is to tell where you are at night, on a highway without distance markers? Exactly.
So, the functionality is already there, for an extremely important safety function. This isn't there to allow the cops to follow you at all times.
It does however, result in really cool other functionality. How about:
A friends list that tells you whos in the neighborhood?
Location based for sale ads (real estate, garage sales)?
Location based allowed/barred incoming calls? (If I'm at home, I don't want calls from work)
All pretty cool, and that's just the tip of the iceberg.
It isn't that hard. I had to do this with my Dell. Most systems now come with "image restore" disks instead of installation disks for software piracry reasons.
Now, to dual-boot all you have to do is:
1) resize your windows partition using any available tool (I purchased partition magic). 2) Install linux in the newly created free space. 3) Put the bootloader (I'm partial to Grub now) into the MBR.
And you're off to the races!
Of course, this means that if your windows partition goes south you have to backup your linux partition and start from scratch, but that's the risk you take.
It doesn't stop you from installing linux, it doesn't stop you from dual-booting. It is simply a quick and easy way to install windows for a fixed hardware platform.
You can type "make" from the main directory, and everything builds correctly. You even get told which downstream changes are needed (side-effect detection! Cool!). You don't get that from "make foo". To top it off, it doesn't build anything that doesn't need to be built either.
As with any large scale software engineering, you will need to put some sort of structure in or you will fail. Not might, not possibly, but will.
You will need some things like code style guides, documentation guides, testing guides, etc. So, a little "artificial structure" makes it so that anyone, regardless of how long they've been with the company and team, is able to pick up the software, find the relevent piece of code and get it to build - the first time.
As for performance, there are many, many tools out there to help with that - try ccache and distcc. We got complete builds from scratch down from 3 hours to 20 minutes.:)
Recursive make works fine for us here. You only need a couple of rules:
1) Get rid of cyclical dependencies! 2) Separate global vs local interfaces. 3) Have a centralised make system that works 90% of the time by filling in a list of source files. 4) Differentiate between libraries and executables.
How do you do this? We use a simple build order.
1) Copy out the changed global header files. 2) Build your libraries. 3) Build your shared libraries. 4) Build your executables.
Easy enough to do. We have a subsystem/programs separation. Libraries go in subsystem, anything that needs a library goes into programs.
So, the order of library build doesn't matter, the only dependency is on the interfaces (header files). The build order of executables doesn't matter, they only depend on the libraries... No fancy directed graphs, simple to explain. We even have header and library dependencies!
Why does the piecewise it difficult? This isn't pilot scheduling!
I just set up the same thing here. 7 people, you have it from Thursday to Thursday (people can then take Mon/Fri off!). I did add one thing though... If it rings two nights in a row, it goes to the next person.
Indeed, anytime you bring a human into the mix you will have a process that is error-prone and subvertible.:)
Sucks to be human.:) A quote I remember... "The most dangerous weapon is the human mind". A quick google search turns up David C. Stolinsky for attribution.
I suppose we are actually in agreement after all, eh?:)
It's amazing the number of times that happens...
"I'm right" "NO, I'M RIGHT!" .... "Hey, wait, we're saying the same thing!" -blush
Pretty nifty to have a chat go on for a couple of days on slashdot.
Procedurally, a CRC is equivalent to digital signature. The only difference is that a CRC can be faked.
Even with a strong signature you still have to have a single (or group, an individual is stronger in terms of security) person validate the data and then sign it. In order to validate the data, they either have to go out and sit there with a GPS and ensure that it's the correct point (not feasible), or compare it with a known good copy.
Since the known good copy would have to have been produced in the same fashion as the new list, it has the same security problems.
The problem then devolves back to the human security problem I initially raised. I have never claimed that the list could not be distributed in a secure fashion, my claims have always been that the production of the list will be error-prone and subvertible.
CRCs, etc do not ensure the quality/validity of the data that is input into the system. They only ensure that it was unchanged in transit. You still need someone to input and verify the data prior to CRC. That is the single person you need access to. Even a minor change of 1/1000 of a degree in the input data will allow you to move the area by 70cm. If you have several thousand of these numbers, how are you going to validate each and every one for accuracy down to even the nearest second?
This would require CIA/FBI/NSA level of security checks in an organisation that I cannot see needing that level of security.
Since this has to be externally controlled, or else it will be out of date, and subject to change by the people in the plane. Therefore, you attack the groundstation and make the airports no fly zones...
They then disable the system (to fix it) and you crash the planes where you want.
Actually it could also indicate that the next state (post selection) is dependent on the current state + inputs (player keypress). So, in other words, it doesn't select a number until _after_ you press a key, and it uses the keypress as input to the RNG to generate the result. Therefore, you will always get the same result for a single keypress, but a different result if you choose the other selection.
Hence the indication that the seed is determined by the players keypresses (and not time)... You still need to decompile the ROM to tell what is really going on. I'm saying that it only appears that the outcome is pre-determined. It's funny like that with random number generators...
If the seed is by keypress, the low/high selection determines the next result using the pseudo random number generator. Therefore, pressing hi will always generate the same result (from the same original state). Is it random? No, computers aren't. Is it a bad choice of seed? Probably not, since players are essentially the random element, and as I said, there may be another source of randomness that they emulator is removing (clock? initial state?).
But they aren't the first. Have a search for Ian Goldberg and Netscape. Netscape was using date and PID as part of the random seed for their SSL keys...
Isn't this simply showing that the player's inputs are used as the seed to the random number generator? So, yes, the game isn't truly random. Is it stealing from you? That would require decomposition of the ROM, not simply producing situations where the input (the keypress) results in failure situations no matter what input.
It could also be that the emulator has a fault in it. While a real system might start up with random memory, the emulator might be zeroing everything out, resulting in less than expected randomness.
But, if someone would be so kind as to dis-assemble the ROM, then we'll know for sure!
I have to disagree here. The best way is to get started and then improve your ship as you go. You will need generic manufacturing capabilities anyways (replacement parts), so why not build better engines?
You have to have the ability to manufacture anything that Earth can simply to stay alive during the trip, so all you then need are the plans/templates, which is simple communication.
So you start, improve your ship and speed up. No time wasted, and you still get there first.
Unless of course someone invents FTL, in which case, you can't get the plans before they show up and say "hi".
It's the same with hard computer problems. Sure, it may get faster later, but you start now and improve the hardware as you go. Don't assume a closed system!
What type of database are you using that you can't have a local instance of the tables? Not an entire copy of the live data, but a small subset of test data? DB-2? Even then, you should be able to create a small test database instance and test against that. Sure, it does require management support to find people to set it up, but automated unit tests are a central component to XP. Without them, there's not much point in doing anything else.
Slashdot had a story of how one group managed it.
Here, we're setting up similar things against Oracle.
Cringley isn't an idiot. You may not agree with what he's saying, you may think that he doesn't understand what an OS is, you may even think that Microsoft would never follow that course, but he isn't an idiot.
He is talking about Microsoft doing _exactly_ the same thing that Apple has done with OSX (use someone else's OS), except with Linux instead of BSD. Five years ago, would anyone have thought that Apple would use someone else's OS to run their UI? Heresy!
Is it going to be as easy as simply porting a windowing system? No Way! Does he understand that? Most certainly.
What he is saying is that Microsoft has demonstrated that it doesn't _need_ to control the underlying OS in order to get everyone to think that they're running the show on the desktop.
He points out the benefits of moving to Linux or even BSD. Would replacing XP/NT/9X as the OS remove MFC.NET, C#, DirectX or any other API? Nope, it would just use the underlying OS differently. In fact, Wine has done a lot of this already...
Would Microsoft ever do it? Doubtful, but then I would have sworn that Apple would never use BSD...
I would be interested in seeing how they failed. Was it inside the networks? Or did the messages never leave the phone? What were the Telco excuses? WHY is SMS so unreliable?
SMS is never intended to be reliable. There are many places that the SMS can be lost. So, lets go through a description.:) Before we begin, let me prefix this by saying it's all GSM, and probably wrong (going from memory), but probably close enough.
Acronyms:
MS - handset
BS - base station
SMSC - short message service centre
HLR - home location registry (knows where destination is).
Your handset is connected to a base station. The base station talks to the SMSC and gives the SMS to it to deliver. The SMSC then attempts to forward it on to the destination SMSC, who will send it to the destination BS and finally to the destination phone.
Now, add in the fact that a destination phone may not always be available to receive the SMS. It may be outside of signal range, have a dead battery, or simply be turned off. So the destination SMSC has to store the SMS. The SMS is usually lost because the SMSC has to flush it, like a congested router.
The next place that it can be lost is in the originating SMSC. Consider, it takes a _lot_ of negotiation between carriers to get links set up, and add more. Cost/SMS, payments, etc have to be agreed. Now, imagine you've saturated that link and need to send another message. Yep, it queues up on the sending SMSC too, only he doesn't care as much because you're not his customer.:)
Let's look at some math:
SMS/subscriber/day: 10 (billed+others)
Number of subs/SMSC: 2m
Size of SMS: 256bytes
Percentage lost: 3%
Number of lost messages: 600k
Space needed to store all lost messages until delivery: 600,000 *.25kbytes = 150megs
So, assuming that all messages can be delivered in 24 hours, you would have to find 150megs of free space on the system to get it to work (good luck). Of course, the messages would be late and confusing, but who cares!
An SMS is an unreliable, time limited message. It doesn't carry long term value, and is usually used for "ping" type messages. Top it off with TV shows receiving votes by SMS which result in rates going from 100SMS/second to 500SMS/second, and you get an idea into how hard the problem can be.
If you didn't have anyone laying cable, then yes, I wouldn't bother. However, in many places they are already digging up the street.
Here in Wellington NZ, we have 4 companies digging up the roads, sequentially (Telecom, Saturn, Clear now merged with Saturn, CityLink). They are all running their own cables in the downtown core. Each one results in the same piece of road being torn up to lay more cable. The paint on the sidewalk detailing all the wiring is quite impressive.
Of course, they're going to have to do it all over again in 10 years...
As for the cost, I can only assume that the initial cost would be the similar to the cost of laying a single wire (they currently sink a pipe, just a smaller one) in the first place (let alone 4). So, you get one carrier to subsidize the cost for lower rent on the pipe later.
We have municipalities charging rent on phone booths, so why not?
Carriers win because they avoid the capex, ROI is faster and easier to see. They get to walk away from bad investments without having thrown money down a hole.
Cities win because they get income without having to do anything like pave a road. Better all around.
Of course, it will play merry hell with fault tolerance and single points of failure....:)
Sewer lines are dirty, nasty confined places, do we really need the roto-rooter guy taking out our broadband connection?
Everyone sees roads continually being torn up to lay cable. Why don't the municipalities lay a "data pipe" to go along with the gas and sewer lines.
That way, there's a maintained pipe for power and data to run down. The city rents space, and you don't have roads being torn up anymore. Instead of once per carrier per service, it's torn up once period! New services become a _lot_ cheaper because you don't have to pay to repave the roads!
Cities would love it because they get a steady income, companies love it because it doesn't involve insane amounts of capex... Win all around?
Slashdot Mirror
I just don't remember them saying that they weren't going to provide it for sale at all... I have no problem with them charging for the download, or only selling on CD. I just don't want to have to change distributions!
Change scares me. It's a big scary world out there. :)
If Fedora provides a release in time, I guess I'll have to look at it. I would prefer to purchase a CD from RH. And no, I can't justify US$180/system.
Jason PollockInterestingly, the article doesn't mention that they were going to drop RHL altogether. End of Lifing a specific version is very different from EOL'ing the product line.
Jason Pollock
It all depends on how structured a development environment you have. If you have automated build systems, then you should be able to do it pretty easily (use the same tags as your last release). The hard bit (I found) was in gathering all of the required documentation. I had to find word documents, txt files, things on Zope, etc...
:)
:)
Of course, we had a policy of checking any non-standard tools into CVS with the code. That way, we versioned the build system with the code. The only things that weren't in CVS were gcc, gmake, bison/flex.
It all flows from how serious you consider the problem of a bad deposit. I went from the point of view of "What would I like to get if the company goes under?" I figured the customers will turn to the current employees if the business goes under. I wouldn't own the existing code, but I would have access to what is in escrow. It was in my individual best interest to see that it worked.
Our setup guaranteed that what was in escrow was what was delivered, and what was in escrow compiled - most of the time.
Jason Pollock
Escrow services I have worked for have provided this service. They would take the deposit, construct a build environment, create the installation packages and install/test them.
:)
Of course, they did charge you for that, but it was needed, we had just reported a loss of several million dollars.
I remember back to first year CS at University of Waterloo (long time ago). We had been instructed to talk to others, to share information, but to leave the pencils down when you do it.
Anyways, it was the last assignment. I get back my assignment, -100%! It was a direct copy of so-and-so. Now, I'd never heard of the other guy, so I went to the TA, toting the text book I had scarfed the answer from.
When I got there, the TA said that the other student had already been in (with a different book/same author) and re-instated the grade.
I learned 2 lessons that day. Cheating gets you BUSTED, and how to attribute your sources. They hadn't told us about that, so I was LUCKY!
As research, you can check out what Waterloo has done to students that appealed the findings over the past 6 years or so.
UW Committee on Student Appeals
Jason PollockWow, good work.
Diagnosis, work-around and description of fault all inside of 2 hours. That sort of support for a GPL'ed piece of software is very cool to see.
I'm definitely going to look into this one closely. Might help us with our java screen problems.
Thanks,
Jason Pollock
Guys,
You are all missing the point. The only reason that carriers are implementing this functionality is because it is _required_ for emergency services. E911 has specified this for years, and as with most things, carriers have been dragging their feet for years. Europe has the same requirements.
Essentially this is all there to allow 911 operators to know where you are calling from. I've been in a car accident and called 911 from a cell phone. Do you know how hard it is to tell where you are at night, on a highway without distance markers? Exactly.
So, the functionality is already there, for an extremely important safety function. This isn't there to allow the cops to follow you at all times.
It does however, result in really cool other functionality. How about:
All pretty cool, and that's just the tip of the iceberg.
Jason PollockIt isn't that hard. I had to do this with my Dell. Most systems now come with "image restore" disks instead of installation disks for software piracry reasons.
Now, to dual-boot all you have to do is:
1) resize your windows partition using any available tool (I purchased partition magic).
2) Install linux in the newly created free space.
3) Put the bootloader (I'm partial to Grub now) into the MBR.
And you're off to the races!
Of course, this means that if your windows partition goes south you have to backup your linux partition and start from scratch, but that's the risk you take.
It doesn't stop you from installing linux, it doesn't stop you from dual-booting. It is simply a quick and easy way to install windows for a fixed hardware platform.
Jason Pollock
You can type "make" from the main directory, and everything builds correctly. You even get told which downstream changes are needed (side-effect detection! Cool!). You don't get that from "make foo". To top it off, it doesn't build anything that doesn't need to be built either.
:)
:)
As with any large scale software engineering, you will need to put some sort of structure in or you will fail. Not might, not possibly, but will.
You will need some things like code style guides, documentation guides, testing guides, etc. So, a little "artificial structure" makes it so that anyone, regardless of how long they've been with the company and team, is able to pick up the software, find the relevent piece of code and get it to build - the first time.
As for performance, there are many, many tools out there to help with that - try ccache and distcc. We got complete builds from scratch down from 3 hours to 20 minutes.
I do intend to read the paper though.
Jason Pollock
Recursive make works fine for us here. You only need a couple of rules:
:)
1) Get rid of cyclical dependencies!
2) Separate global vs local interfaces.
3) Have a centralised make system that works 90% of the time by filling in a list of source files.
4) Differentiate between libraries and executables.
How do you do this? We use a simple build order.
1) Copy out the changed global header files.
2) Build your libraries.
3) Build your shared libraries.
4) Build your executables.
Easy enough to do. We have a subsystem/programs separation. Libraries go in subsystem, anything that needs a library goes into programs.
So, the order of library build doesn't matter, the only dependency is on the interfaces (header files). The build order of executables doesn't matter, they only depend on the libraries... No fancy directed graphs, simple to explain. We even have header and library dependencies!
Too easy.
Jason Pollock
Here! Here!
Why does the piecewise it difficult? This isn't pilot scheduling!
I just set up the same thing here. 7 people, you have it from Thursday to Thursday (people can then take Mon/Fri off!). I did add one thing though... If it rings two nights in a row, it goes to the next person.
Jason Pollock
It's amazing the number of times that happens...
Pretty nifty to have a chat go on for a couple of days on slashdot.
Thanks, Jason PollockProcedurally, a CRC is equivalent to digital signature. The only difference is that a CRC can be faked.
Even with a strong signature you still have to have a single (or group, an individual is stronger in terms of security) person validate the data and then sign it. In order to validate the data, they either have to go out and sit there with a GPS and ensure that it's the correct point (not feasible), or compare it with a known good copy.
Since the known good copy would have to have been produced in the same fashion as the new list, it has the same security problems.
The problem then devolves back to the human security problem I initially raised. I have never claimed that the list could not be distributed in a secure fashion, my claims have always been that the production of the list will be error-prone and subvertible.
Thank you,
Jason Pollock
CRCs, etc do not ensure the quality/validity of the data that is input into the system. They only ensure that it was unchanged in transit. You still need someone to input and verify the data prior to CRC. That is the single person you need access to. Even a minor change of 1/1000 of a degree in the input data will allow you to move the area by 70cm. If you have several thousand of these numbers, how are you going to validate each and every one for accuracy down to even the nearest second?
This would require CIA/FBI/NSA level of security checks in an organisation that I cannot see needing that level of security.
Jason Pollock
Since this has to be externally controlled, or else it will be out of date, and subject to change by the people in the plane. Therefore, you attack the groundstation and make the airports no fly zones...
They then disable the system (to fix it) and you crash the planes where you want.
Jason
Think further back. All of this data will come from a single point (FAA?), and there will be no way to accurately verify it once it leaves that point.
So, you only need 1 person in a large group, far away from the airport to screw up the whole system.
Jason
Actually it could also indicate that the next state (post selection) is dependent on the current state + inputs (player keypress). So, in other words, it doesn't select a number until _after_ you press a key, and it uses the keypress as input to the RNG to generate the result. Therefore, you will always get the same result for a single keypress, but a different result if you choose the other selection.
:)
No thieving required.
Hence the indication that the seed is determined by the players keypresses (and not time)... You still need to decompile the ROM to tell what is really going on. I'm saying that it only appears that the outcome is pre-determined. It's funny like that with random number generators...
If the seed is by keypress, the low/high selection determines the next result using the pseudo random number generator. Therefore, pressing hi will always generate the same result (from the same original state). Is it random? No, computers aren't. Is it a bad choice of seed? Probably not, since players are essentially the random element, and as I said, there may be another source of randomness that they emulator is removing (clock? initial state?).
But they aren't the first. Have a search for Ian Goldberg and Netscape. Netscape was using date and PID as part of the random seed for their SSL keys...
Jason Pollock
Isn't this simply showing that the player's inputs are used as the seed to the random number generator? So, yes, the game isn't truly random. Is it stealing from you? That would require decomposition of the ROM, not simply producing situations where the input (the keypress) results in failure situations no matter what input.
It could also be that the emulator has a fault in it. While a real system might start up with random memory, the emulator might be zeroing everything out, resulting in less than expected randomness.
But, if someone would be so kind as to dis-assemble the ROM, then we'll know for sure!
Jason Pollock
I have to disagree here. The best way is to get started and then improve your ship as you go. You will need generic manufacturing capabilities anyways (replacement parts), so why not build better engines?
You have to have the ability to manufacture anything that Earth can simply to stay alive during the trip, so all you then need are the plans/templates, which is simple communication.
So you start, improve your ship and speed up. No time wasted, and you still get there first.
Unless of course someone invents FTL, in which case, you can't get the plans before they show up and say "hi".
It's the same with hard computer problems. Sure, it may get faster later, but you start now and improve the hardware as you go. Don't assume a closed system!
Jason Pollock
What type of database are you using that you can't have a local instance of the tables? Not an entire copy of the live data, but a small subset of test data? DB-2? Even then, you should be able to create a small test database instance and test against that. Sure, it does require management support to find people to set it up, but automated unit tests are a central component to XP. Without them, there's not much point in doing anything else.
Slashdot had a story of how one group managed it. Here, we're setting up similar things against Oracle.
Jason Pollock
Cringley isn't an idiot. You may not agree with what he's saying, you may think that he doesn't understand what an OS is, you may even think that Microsoft would never follow that course, but he isn't an idiot.
He is talking about Microsoft doing _exactly_ the same thing that Apple has done with OSX (use someone else's OS), except with Linux instead of BSD. Five years ago, would anyone have thought that Apple would use someone else's OS to run their UI? Heresy!
Is it going to be as easy as simply porting a windowing system? No Way! Does he understand that? Most certainly.
What he is saying is that Microsoft has demonstrated that it doesn't _need_ to control the underlying OS in order to get everyone to think that they're running the show on the desktop.
He points out the benefits of moving to Linux or even BSD. Would replacing XP/NT/9X as the OS remove MFC .NET, C#, DirectX or any other API? Nope, it would just use the underlying OS differently. In fact, Wine has done a lot of this already...
Would Microsoft ever do it? Doubtful, but then I would have sworn that Apple would never use BSD...
Jason Pollock
SMS is never intended to be reliable. There are many places that the SMS can be lost. So, lets go through a description. :) Before we begin, let me prefix this by saying it's all GSM, and probably wrong (going from memory), but probably close enough.
Acronyms:
Your handset is connected to a base station. The base station talks to the SMSC and gives the SMS to it to deliver. The SMSC then attempts to forward it on to the destination SMSC, who will send it to the destination BS and finally to the destination phone.
Now, add in the fact that a destination phone may not always be available to receive the SMS. It may be outside of signal range, have a dead battery, or simply be turned off. So the destination SMSC has to store the SMS. The SMS is usually lost because the SMSC has to flush it, like a congested router.
The next place that it can be lost is in the originating SMSC. Consider, it takes a _lot_ of negotiation between carriers to get links set up, and add more. Cost/SMS, payments, etc have to be agreed. Now, imagine you've saturated that link and need to send another message. Yep, it queues up on the sending SMSC too, only he doesn't care as much because you're not his customer. :)
Let's look at some math:
- SMS/subscriber/day: 10 (billed+others)
- Number of subs/SMSC: 2m
- Size of SMS: 256bytes
- Percentage lost: 3%
- Number of lost messages: 600k
- Space needed to store all lost messages until delivery: 600,000 *
.25kbytes = 150megs
So, assuming that all messages can be delivered in 24 hours, you would have to find 150megs of free space on the system to get it to work (good luck). Of course, the messages would be late and confusing, but who cares!An SMS is an unreliable, time limited message. It doesn't carry long term value, and is usually used for "ping" type messages. Top it off with TV shows receiving votes by SMS which result in rates going from 100SMS/second to 500SMS/second, and you get an idea into how hard the problem can be.
Jason Pollock
If you didn't have anyone laying cable, then yes, I wouldn't bother. However, in many places they are already digging up the street.
:)
Here in Wellington NZ, we have 4 companies digging up the roads, sequentially (Telecom, Saturn, Clear now merged with Saturn, CityLink). They are all running their own cables in the downtown core. Each one results in the same piece of road being torn up to lay more cable. The paint on the sidewalk detailing all the wiring is quite impressive.
Of course, they're going to have to do it all over again in 10 years...
As for the cost, I can only assume that the initial cost would be the similar to the cost of laying a single wire (they currently sink a pipe, just a smaller one) in the first place (let alone 4). So, you get one carrier to subsidize the cost for lower rent on the pipe later.
We have municipalities charging rent on phone booths, so why not?
Carriers win because they avoid the capex, ROI is faster and easier to see. They get to walk away from bad investments without having thrown money down a hole.
Cities win because they get income without having to do anything like pave a road. Better all around.
Of course, it will play merry hell with fault tolerance and single points of failure....
Jason
Sewer lines are dirty, nasty confined places, do we really need the roto-rooter guy taking out our broadband connection?
Everyone sees roads continually being torn up to lay cable. Why don't the municipalities lay a "data pipe" to go along with the gas and sewer lines.
That way, there's a maintained pipe for power and data to run down. The city rents space, and you don't have roads being torn up anymore. Instead of once per carrier per service, it's torn up once period! New services become a _lot_ cheaper because you don't have to pay to repave the roads!
Cities would love it because they get a steady income, companies love it because it doesn't involve insane amounts of capex... Win all around?
Jason Pollock