It is, but I'm in New Zealand. So, the data charges are based on the international data peering charges that US companies charge. At least it's come down recently. It used to be even more expensive.:)
It is possible to get uncapped traffic connection, but they are limited to 64kbps.
Actually, an idle upstream does have value to me. It costs me US$7.50/gig of data coming across the pipe in either direction. So if I send a gig, it's 7.50, it I download a gig, it's 7.50.:)
So, yep, an idle pipe has value, it's the cost savings of 7.50/gig!:)
I've recently discovered that it's actually _cheaper_ to go buy the DVD than it is to download it...
I've found that the show leaves holes on purpose. It lets you come up with reasons for people's behaviours. They aren't as inconsistant as you would believe.
1) The original cylon test...
This was Baltar attempting to gain some power and direct attention away from himself. Think about it. The guy who controls the cylon detector becomes very powerfull "Witch! She's a witch!"
In the pilot, he never had a working detector, he just needed a patsy and went with the person that the cylon in his head pointed out. He needed a cylon, and it didn't matter who it was.:)
After that, he kept getting more and more pressure to actually come up with a more workable solution. He didn't have one, didn't know how to create one, so he stalled, eventually even asking for (expecting to be turned down) and getting a nuke! Remember, it was her idea to get the nuke. He didn't need it, she did.
2) Boomer's test. Baltar realised that if she tested positive, she would kill him. Since he is a completely craven coward, he ensured from that point forward, that two things would happen:
a) no one would test positive to being a cylon. b) each test would take as long as possible.
The first would keep him safe, and the second would keep him important, and give him a reason to not help anyone. It also meant that it wouldn't be likely for the testee to be alone with Baltar when the results came in - the Doctor calls you with the results when he's done.
No one second guesses Baltar on technology. He works alone, and unsupervised.
If you use a memory dump save (as it sounds to me) you will eventually notice several things:
1) The files aren't easily loaded between versions of the software. 2) The files aren't platform independent. 3) The files are very fragile, and very dependent on compiler options.
This is one of the complaints about Word document files - they can contain memory dumps.:)
However, for simple ease of implementation, nothing beats getting a pointer and writing a block of memory to disk.
It doesn't lock files for edit, and when you're committing you aren't transferring the entire suite, just the files that have changed.
And it usually does the merges for you!
I've used CVS across a 14.4 modem without any problems.:)
VC products have changed substantially from the CCCS/RCS days of edit locks. Subversion has even more nifty features, but I'm unsure of the network performance.
Most report code that I write is perfectly capable of generating reports across multiple database connections.:) But then, I'm hand-crafting these things.:)
It all depends on where you start from. Sure, you don't get it all in a single query, but you do have all of the information there. I've frequently done things like:
1) get all of the bugs I'm interested in out of bugzilla. 2) get all of the transactions associated with those bugs out of cvszilla.
It's more of a web-service kind of view. Loose coupling means that you're not locked in, you can change VC systems or bug tracking systems and not lose everything.:)
And if you _really_ want everything together, you are perfectly free (with say CVSZilla) to put the VC tables into the Bugzilla database instance.
You can't make that assumption... If I were going to game an election and I had access to the source of the election machine, I would:
1) determine what were swing states/swing counties. 2) alter a specific (random withing a range) percentage of the votes - only if the vote wasn't going my way. 3) only do it on the proper date. 4) have some state so it only happens once per system - re-running to test the machine would avoid the code. 5) have some flag so that it isn't triggered during test.
And I would hide the code so that it didn't appear in the source, such as the infamous Login hack that was in the early Unix source. In other words, I would hack the compiler.:)
A fee gives you access to the CVS repository for 1 year. The software is GPL'ed (not LGPL), and forkable under those rules. To produce a closed source application requires additional $$. Since their target market probably prefers other OSs than Linux, this is where they would get a bunch of $$ from.
Since they require $$ before letting people see the code, it does limit the number of developers on the project. However, they seem to be making money at it.:)
Dude, pure end to end won't happen. Does Skype talk to end to end NetMeeting? Nope. Does Napster talk Gnutella? Nope. Do all web sites look the same in Mozilla as they do in Explorer? Nope.:)
Interopability is hard, and if universality is desired, you either end up with a monopoly, or interconnection. Interconnection results in translation, which can even mean decryption.
Even when standardised (see SIP, ISUP, H.323, CORBA, OpenGL), businesses (and open source teams) can't stop themselves from "innovating", creating features that only work on their variant. This is seen as a differentiator, and a way to lock in the customer.
Competition implies innovation which means incompatibility (even if it's only incompatible bugs). Incompatibility results in interconnection, which means that unless everyone is going to have all clients installed on their system, there's going to have to be some interconnection.:)
However, 15 years is a long way away. Moore's law is supposed to break down sooner than that. In other words, your guess is as good as mine that far out.:)
Yes, I agree that point-to-point makes it a lot harder.:)
My point is that even if within a specific network it goes point to point, it will likely have to go into a protocol converter between carriers. Protocol conversion will likely mean that it will need to be decrypted, and therefore tappable.
Finally, I don't think a carrier will want to allow all calls to be point to point, because then they won't make enough (any?) $$.
That doesn't prevent a group from creating their own system! What it does do is say that once that group wants to talk to the outside world, they're going to have to play by everyone else's rules.:)
As for the terrorists, look at all of the information that they obtained off of a "computer expert's" system! Encryption is available today, and the criminals still don't use it properly.
Doesn't matter. If you want to be able to call the cops (hospital, dentist, pizza), you'll have to play by the gov's rules, and then they can force those rules onto the groups doing interopability.
If it's just you and your buddies, sure, go ahead, use whatever encryption you want, but as soon as you want to actually "reach out and touch someone" you have to start to play by a shared set of rules, even to the point of going through a third party for protocol conversion (SIP to H.323, different SIP variants, etc).
Even today, every country has their own set of telephony protocols, and even between carriers in the same country there can be large differences. At each point where they connect, they have large documents describing the messages that each person is allowed to send/receive and how the system will respond.
I wouldn't tell the guys writing the software for the controllers that they aren't working with "real computers".:) Please don't belittle our GPU deprived friends in embedded systems!:)
Heck, dashboards have 32bit CPUs now!
http://www.micronas.com/products/documentation/a ut omotive/cdc3231gc/downloads/cdc3231g_1pi.pdf
And that's just the dash.
Hmmm, imagine a beowulf cluster of car fuel injection controllers.... Hmmm maybe not.
A Friend's truck had a bug in the ABS controller. There was a possibility for a sensor to get dirty. If the sensor got dirty, the controller would assume that, at low speeds, the truck was in a skid (or stopped?), and turn on the ABS - disabling the brakes! Yep, you heard me, the breaks failed OFF!
Of course, this caused him to have a low speed accident with some minor hood damage. He wasn't amused.
How's that for a "computer accident"?
Jason Pollock
Re:keep it anonymous and private.
on
Privacy in the Woods?
·
· Score: 2, Informative
They rent these to hikers here in NZ, and THEY WORK!
A guy rented one at the last minute, took it in, got into trouble, turned it on and was picked up at first light. Compared to the number of dead hikers and climbers they end up with this year, everyone should have one.
They can be activated locally and remotely (in case you are late and they need to find you).
I agree that the paper doesn't argue that. It was however, a view being put forward by other posters, and one I felt needed to be argued against.:)
You are entirely correct that more analysis should have been done. Most of the problems could have been simulated. But then, that would have doubled the cost of the project to the end result anyways.:) It would have just been a bit more comfortable along the way.
I am a HUGE fan of throwing hardware at a problem. I never understand why companies are willing to spend 100 person days of effort (with a loaded labour cost of $1k/day) to fix a problem that could be solved by spending $50k on hardware. Just doesn't make sense to me...
As for the tweaking of code. Yep, that should be left until you run into a problem. But there are always exceptions.:)
On the same project, we had a library that would hide the fact that certain configuration information was stored in the database. This information was retrieved every time the function was called. Not really a problem, until you realise that the function was called several times/transaction. It was another forseeable problem that should have been optimised earlier. More time was spent tracking down the problem (even before the fix was applied) than would have been spent doing it correctly the first time.
People really do need to design and write software with the performance limiters of their platform in mind. On the platform that I've worked on, everything was always O(number of database operations) + O(number of network round trips), nothing else mattered.:)
The system was throwing an exception whenever a socket didn't have the requested number of bytes available. So, it would happen pretty frequently - every message. It was very pretty code though.:)
Even if the exception doesn't happen frequently, the systems that I work on have a definite preference for worst-case performance close to average performance. Determinism is _very_ important. So it is worth a performance loss to ensure that when things start to go bad they don't go _really_ bad.:)
That's what you get when there's a high likelihood of your company being on the national news if your software goes bad. Heh.:)
I am hearing a lot of people saying that you shouldn't optimise prior to the first release. However, it is very easy to select a design or architecture that limits your high end performance limit. Therefore, there is some optimisation that needs to be done early.
When you're architecting a system that is going to take tens of man years of effort to implement, you need to ensure that your system will scale.
For example, a project I recently worked on hit a performance wall. We had left optimisation for later, always believing that it shouldn't be done until last. However, while the architecture chosen was incredibly nice and clear, it limited the performance to 1/3th what was required. Back to the drawing board, we just doubled the project cost - ouch.
Even worse, there are performance differences on each platform! For example, did you know that throwing an exception is 10,000 times slower than a return statement in HP/UX 11? Solaris is only a little better at 2 orders of magnitude. Linux is (I understand) a dead heat.
So, while low-level optimisation of statements is silly early in the project, you do need to ensure that the architecture you choose is going to meet your performance requirements. Some optimisations are definitely necessary early in the project.
The article also talks about tool selection, suggesting that the extra CPU could be better used to support higher level languages like Erlang. If a system has CPU to spare, I agree, use what you can. The projects I work on always seem to lack in CPU cycles, disk write speed, and network speed. You name it, we're short of it. In fact, a large part of our marketing strategy is that we are able to deliver high performance on low end systems. What would happen to us if we dropped that edge? We're working with a company that has implemented a real-time billing system in Perl. Not a problem, until you try and send it 500 transactions/second. Their hardware budget? Millions to our 10s of thousands. Who do you think the customer likes more?
I've read that it depends on the orbit you are hoping to achieve. If you are looking to get into an equatorial, geosynchronous orbit, it's best done from the equator.
Polar orbits, however, get little to no benefit from the location of the launch site. That's why places like Churchill Manitoba can look good for rocket launches...
Slashdot Mirror
It is, but I'm in New Zealand. So, the data charges are based on the international data peering charges that US companies charge. At least it's come down recently. It used to be even more expensive. :)
It is possible to get uncapped traffic connection, but they are limited to 64kbps.
Jason
Actually, an idle upstream does have value to me. It costs me US$7.50/gig of data coming across the pipe in either direction. So if I send a gig, it's 7.50, it I download a gig, it's 7.50. :)
:)
So, yep, an idle pipe has value, it's the cost savings of 7.50/gig!
I've recently discovered that it's actually _cheaper_ to go buy the DVD than it is to download it...
Jason Pollock
I've found that the show leaves holes on purpose. It lets you come up with reasons for people's behaviours. They aren't as inconsistant as you would believe.
:)
:)
1) The original cylon test...
This was Baltar attempting to gain some power and direct attention away from himself. Think about it. The guy who controls the cylon detector becomes very powerfull "Witch! She's a witch!"
In the pilot, he never had a working detector, he just needed a patsy and went with the person that the cylon in his head pointed out. He needed a cylon, and it didn't matter who it was.
After that, he kept getting more and more pressure to actually come up with a more workable solution. He didn't have one, didn't know how to create one, so he stalled, eventually even asking for (expecting to be turned down) and getting a nuke!
Remember, it was her idea to get the nuke. He didn't need it, she did.
2) Boomer's test. Baltar realised that if she tested positive, she would kill him. Since he is a completely craven coward, he ensured from that point forward, that two things would happen:
a) no one would test positive to being a cylon.
b) each test would take as long as possible.
The first would keep him safe, and the second would keep him important, and give him a reason to not help anyone. It also meant that it wouldn't be likely for the testee to be alone with Baltar when the results came in - the Doctor calls you with the results when he's done.
No one second guesses Baltar on technology. He works alone, and unsupervised.
Anyways, just some things to think about.
Jason
If you use a memory dump save (as it sounds to me) you will eventually notice several things:
:)
1) The files aren't easily loaded between versions of the software.
2) The files aren't platform independent.
3) The files are very fragile, and very dependent on compiler options.
This is one of the complaints about Word document files - they can contain memory dumps.
However, for simple ease of implementation, nothing beats getting a pointer and writing a block of memory to disk.
Jason
I cannot recommend this course higher. It made it blatantly obvious to me what I was doing wrong when interacting with others at work.
Honestly, this course turned my career around, and removed a glass ceiling that I had previously hit.
Jason Pollock
Dang, my math is off. That'll learn me to not check first.
.352 c US/minute
The real costs are:
G711 -
G729 - 1.19 c US/minute.
I think, maybe, unless I've slipped a digit again...
Local calls are free if you are a residential user (business lines charge per minute), but traffic costs money. It costs ~US$10.50/GB of traffic.
.4cUS/minute.
:)
So, let's say we're using G.729 at 8kbps (GSM), this gives us ~23kbps (8kbps for the payload + overhead), with a resulting cost of:
195kbytes/minute (* 2 channels) =
If we use the less frugal G.711 codec(64kpbs), it costs us:
4788kbytes/minute (* 2 channels) = 10cUS/minute.
The G.711 cost doesn't sound like much until you start counting hours or days/month.
So, it ain't free, it's barely competitive with the existing calling cards!
Jason
That's why you use a non-locking VC like CVS. :)
:)
It doesn't lock files for edit, and when you're committing you aren't transferring the entire suite, just the files that have changed.
And it usually does the merges for you!
I've used CVS across a 14.4 modem without any problems.
VC products have changed substantially from the CCCS/RCS days of edit locks. Subversion has even more nifty features, but I'm unsure of the network performance.
Jason Pollock
What types of reports? Release Content?
:) But then, I'm hand-crafting these things. :)
:)
Most report code that I write is perfectly capable of generating reports across multiple database connections.
It all depends on where you start from. Sure, you don't get it all in a single query, but you do have all of the information there. I've frequently done things like:
1) get all of the bugs I'm interested in out of bugzilla.
2) get all of the transactions associated with those bugs out of cvszilla.
It's more of a web-service kind of view. Loose coupling means that you're not locked in, you can change VC systems or bug tracking systems and not lose everything.
And if you _really_ want everything together, you are perfectly free (with say CVSZilla) to put the VC tables into the Bugzilla database instance.
Jason
CVSZilla
ScumBug Both provide integration between Bugzilla and CVS. CVSZilla also integrates with Subversion. Jason Pollock
You can't make that assumption... If I were going to game an election and I had access to the source of the election machine, I would:
:)
1) determine what were swing states/swing counties.
2) alter a specific (random withing a range) percentage of the votes - only if the vote wasn't going my way.
3) only do it on the proper date.
4) have some state so it only happens once per system - re-running to test the machine would avoid the code.
5) have some flag so that it isn't triggered during test.
And I would hide the code so that it didn't appear in the source, such as the infamous Login hack that was in the early Unix source. In other words, I would hack the compiler.
Jason Pollock
A fee gives you access to the CVS repository for 1 year. The software is GPL'ed (not LGPL), and forkable under those rules. To produce a closed source application requires additional $$. Since their target market probably prefers other OSs than Linux, this is where they would get a bunch of $$ from.
:)
/
Since they require $$ before letting people see the code, it does limit the number of developers on the project. However, they seem to be making money at it.
http://www.openss7.com/
http://www.openss7.org
Jason Pollock
Dude, pure end to end won't happen. Does Skype talk to end to end NetMeeting? Nope. Does Napster talk Gnutella? Nope. Do all web sites look the same in Mozilla as they do in Explorer? Nope. :)
:)
:)
Interopability is hard, and if universality is desired, you either end up with a monopoly, or interconnection. Interconnection results in translation, which can even mean decryption.
Even when standardised (see SIP, ISUP, H.323, CORBA, OpenGL), businesses (and open source teams) can't stop themselves from "innovating", creating features that only work on their variant. This is seen as a differentiator, and a way to lock in the customer.
Competition implies innovation which means incompatibility (even if it's only incompatible bugs). Incompatibility results in interconnection, which means that unless everyone is going to have all clients installed on their system, there's going to have to be some interconnection.
However, 15 years is a long way away. Moore's law is supposed to break down sooner than that. In other words, your guess is as good as mine that far out.
Jason
Yes, I agree that point-to-point makes it a lot harder. :)
:)
My point is that even if within a specific network it goes point to point, it will likely have to go into a protocol converter between carriers. Protocol conversion will likely mean that it will need to be decrypted, and therefore tappable.
Finally, I don't think a carrier will want to allow all calls to be point to point, because then they won't make enough (any?) $$.
That doesn't prevent a group from creating their own system! What it does do is say that once that group wants to talk to the outside world, they're going to have to play by everyone else's rules.
As for the terrorists, look at all of the information that they obtained off of a "computer expert's" system! Encryption is available today, and the criminals still don't use it properly.
Jason
Doesn't matter. If you want to be able to call the cops (hospital, dentist, pizza), you'll have to play by the gov's rules, and then they can force those rules onto the groups doing interopability.
:)
If it's just you and your buddies, sure, go ahead, use whatever encryption you want, but as soon as you want to actually "reach out and touch someone" you have to start to play by a shared set of rules, even to the point of going through a third party for protocol conversion (SIP to H.323, different SIP variants, etc).
Even today, every country has their own set of telephony protocols, and even between carriers in the same country there can be large differences. At each point where they connect, they have large documents describing the messages that each person is allowed to send/receive and how the system will respond.
SIP is already fragmented like this.
Jason Pollock
I think I understand (sorta). :)
Thanks!
And yet, I'm told that WRF (the new weather model software) and MM5 both run happily on a beowulf clusters. :)
i sciplines /default.aspx/weather_modeling.aspx
http://www.wrf-model.org/
Google for WRF beowulf
http://www.aspsys.com/clusters/beowulf/d
Perhaps the communication is limited only to adjacent cells?
Jason Pollock
I wouldn't tell the guys writing the software for the controllers that they aren't working with "real computers". :) Please don't belittle our GPU deprived friends in embedded systems! :)
a ut omotive/cdc3231gc/downloads/cdc3231g_1pi.pdf
Heck, dashboards have 32bit CPUs now!
http://www.micronas.com/products/documentation/
And that's just the dash.
Hmmm, imagine a beowulf cluster of car fuel injection controllers.... Hmmm maybe not.
Jason Pollock
O.k. Here's one.
A Friend's truck had a bug in the ABS controller. There was a possibility for a sensor to get dirty. If the sensor got dirty, the controller would assume that, at low speeds, the truck was in a skid (or stopped?), and turn on the ABS - disabling the brakes! Yep, you heard me, the breaks failed OFF!
Of course, this caused him to have a low speed accident with some minor hood damage. He wasn't amused.
How's that for a "computer accident"?
Jason Pollock
They rent these to hikers here in NZ, and THEY WORK!
A guy rented one at the last minute, took it in, got into trouble, turned it on and was picked up at first light. Compared to the number of dead hikers and climbers they end up with this year, everyone should have one.
They can be activated locally and remotely (in case you are late and they need to find you).
Jason
I agree that the paper doesn't argue that. It was however, a view being put forward by other posters, and one I felt needed to be argued against. :)
:) It would have just been a bit more comfortable along the way.
:)
:)
You are entirely correct that more analysis should have been done. Most of the problems could have been simulated. But then, that would have doubled the cost of the project to the end result anyways.
I am a HUGE fan of throwing hardware at a problem. I never understand why companies are willing to spend 100 person days of effort (with a loaded labour cost of $1k/day) to fix a problem that could be solved by spending $50k on hardware. Just doesn't make sense to me...
As for the tweaking of code. Yep, that should be left until you run into a problem. But there are always exceptions.
On the same project, we had a library that would hide the fact that certain configuration information was stored in the database. This information was retrieved every time the function was called. Not really a problem, until you realise that the function was called several times/transaction. It was another forseeable problem that should have been optimised earlier. More time was spent tracking down the problem (even before the fix was applied) than would have been spent doing it correctly the first time.
People really do need to design and write software with the performance limiters of their platform in mind. On the platform that I've worked on, everything was always O(number of database operations) + O(number of network round trips), nothing else mattered.
Jason Pollock
The system was throwing an exception whenever a socket didn't have the requested number of bytes available. So, it would happen pretty frequently - every message. It was very pretty code though. :)
:)
:)
Even if the exception doesn't happen frequently, the systems that I work on have a definite preference for worst-case performance close to average performance. Determinism is _very_ important. So it is worth a performance loss to ensure that when things start to go bad they don't go _really_ bad.
That's what you get when there's a high likelihood of your company being on the national news if your software goes bad. Heh.
Jason Pollock
I am hearing a lot of people saying that you shouldn't optimise prior to the first release. However, it is very easy to select a design or architecture that limits your high end performance limit. Therefore, there is some optimisation that needs to be done early.
When you're architecting a system that is going to take tens of man years of effort to implement, you need to ensure that your system will scale.
For example, a project I recently worked on hit a performance wall. We had left optimisation for later, always believing that it shouldn't be done until last. However, while the architecture chosen was incredibly nice and clear, it limited the performance to 1/3th what was required. Back to the drawing board, we just doubled the project cost - ouch.Even worse, there are performance differences on each platform! For example, did you know that throwing an exception is 10,000 times slower than a return statement in HP/UX 11? Solaris is only a little better at 2 orders of magnitude. Linux is (I understand) a dead heat.
So, while low-level optimisation of statements is silly early in the project, you do need to ensure that the architecture you choose is going to meet your performance requirements. Some optimisations are definitely necessary early in the project.
The article also talks about tool selection, suggesting that the extra CPU could be better used to support higher level languages like Erlang. If a system has CPU to spare, I agree, use what you can. The projects I work on always seem to lack in CPU cycles, disk write speed, and network speed. You name it, we're short of it. In fact, a large part of our marketing strategy is that we are able to deliver high performance on low end systems. What would happen to us if we dropped that edge? We're working with a company that has implemented a real-time billing system in Perl. Not a problem, until you try and send it 500 transactions/second. Their hardware budget? Millions to our 10s of thousands. Who do you think the customer likes more?
Jason PollockI've read that it depends on the orbit you are hoping to achieve. If you are looking to get into an equatorial, geosynchronous orbit, it's best done from the equator.
Polar orbits, however, get little to no benefit from the location of the launch site. That's why places like Churchill Manitoba can look good for rocket launches...
Reference 1
Jason Pollock
Think of the nifty things you could do if when doing tabbed completion you got the manpage summary as well.....
Jason Pollock