 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 20/11/2011 04:58 PM, Darren New wrote:
> On 11/19/2011 12:35, Orchid XP v8 wrote:
>> It's not like you just write the code in
>> Erlang and it magically becomes reliable.
>
> No, of course not. You certainly have to write the code to be
> fault-tollerant. The difference is that in Erlang it's much easier, and
> you have bunches of libraries to help out.
Other than providing a library that says "if this thread dies, restart
it", I'm not sure what help the libraries actually provide. (Then again,
I'm not very familiar with Erlang.) Certainly the dynamic loading and
hot code swapping makes things easier.
>> Well, if there's a module named "Cookies", then it's a pretty good bet
>> what that does.
>
> Yeah, if only everything was named that well.
As I wrote a bit further down, it's sometimes how /possible/ to name
everything perfectly.
>> Yeah, that could work. I mean, it wouldn't work with my usual iterative
>> prototyping method, but hey...
>
> You would be surprised. You can still write a one or two sentence
> comment at the start of a function before you code it. It's no harder
> than deciding what to name the function and the arguments. And of course
> you go back and fix the comments as you code.
The usual problem is that I start writing all the code, and half way
through I suddenly discover that due to some interaction I hadn't
thought of, the program basically won't work the way it's currently
structured. (Or won't work very well, anyway.) I don't think writing
comments would prevent that. It might make a useful to-do list, however.
>> Unfortunately, every PC on Earth has a web browser installed.
>
> And, more importantly, every firewall has a hole for port 80. *That* was
> the real impetus.
To this day I have never yet seem a firewall which blocks *outbound*
traffic. So I don't see why this would even be an issue.
>> why Hotmail got started. (And as best as I can tell, that's where this
>> whole crazy idea originated.)
>
> Nah. There were lots of systems putting apps over http because it would
> go thru firewalls long before anyone tried to reimplement stuff that
> everyone already had software for like email.
Really?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 11/21/2011 1:31, Invisible wrote:
> Other than providing a library that says "if this thread dies, restart it",
> I'm not sure what help the libraries actually provide.
The whole distributed processing thing? "If this thread dies, restart it"
isn't especially robust if both threads are on the same machine.
The heartbeat monitor, that restarts the entire VM if it locks up?
The logging libraries that let you know there's a problem so you can fix it?
The debugging libraries that let you debug a process that's running on some
other machine somewhere?
> The usual problem is that I start writing all the code, and half way through
> I suddenly discover that due to some interaction I hadn't thought of, the
> program basically won't work the way it's currently structured. (Or won't
> work very well, anyway.) I don't think writing comments would prevent that.
No, of course not. If you're writing the wrong code, commenting what you're
writing before you write it won't prevent that. Of course, I find if I
comment it before I write it, the number of times I miss a corner case
plummets drastically, because I'm not totally focused on the minutia of the
current line of code, but rather on what I'm trying to accomplish.
"Some interaction I hadn't thought of" needs a higher-level design document,
like an actual requirements spec, to avoid. And of course you still can't
always avoid it, by definition of the phrase "hadn't thought of."
> It might make a useful to-do list, however.
And it's handy when you come back six months later and you have to read the
code to see if it's the code you want to look at.
> To this day I have never yet seem a firewall which blocks *outbound*
> traffic.
It's not uncommon in even a fairly small corporation.
>> Nah. There were lots of systems putting apps over http because it would
>> go thru firewalls long before anyone tried to reimplement stuff that
>> everyone already had software for like email.
>
> Really?
Yep
--
Darren New, San Diego CA, USA (PST)
People tell me I am the counter-example.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Le 2011-11-21 04:31, Invisible a écrit :
>
> To this day I have never yet seem a firewall which blocks *outbound*
> traffic. So I don't see why this would even be an issue.
>
That's because you haven't seen many firewalls!
At my current place of employment, there are three different layers of
firewalls between the user environment and the public Internet. not
only do each layer block unauthorized traffic in both directions, there
isn't even a default route out to the Internet. You need to talk to the
proxy server infrastructure, and it only accepts specific ports.
And looking in the other direction, there are also firewalls between the
labs, UAT environments, and regular network, as well as protecting the
mainframes from the unwashed masses.
For B2B extranets, it's even more prevalent. There, firewalls will
usually also be very strict in what they allow out, because the last
thing you want is a letter from the legal dept. of Boeing, NASA, or say,
the London Stock Exchange saying you are trying to infect their network
with bots.
>>> why Hotmail got started. (And as best as I can tell, that's where this
>>> whole crazy idea originated.)
>>
>> Nah. There were lots of systems putting apps over http because it would
>> go thru firewalls long before anyone tried to reimplement stuff that
>> everyone already had software for like email.
>
> Really?
RealPlayer and ICQ, both of which predate Hotmail, are the first I came
across that did that, I'm sure there were others.
--
/*Francois Labreque*/#local a=x+y;#local b=x+a;#local c=a+b;#macro P(F//
/* flabreque */L)polygon{5,F,F+z,L+z,L,F pigment{rgb 9}}#end union
/* @ */{P(0,a)P(a,b)P(b,c)P(2*a,2*b)P(2*b,b+c)P(b+c,<2,3>)
/* gmail.com */}camera{orthographic location<6,1.25,-6>look_at a }
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> To this day I have never yet seem a firewall which blocks *outbound*
>> traffic. So I don't see why this would even be an issue.
>>
>
> That's because you haven't seen many firewalls!
>
> At my current place of employment, there are three different layers of
> firewalls between the user environment and the public Internet. not only
> do each layer block unauthorized traffic in both directions, there isn't
> even a default route out to the Internet. You need to talk to the proxy
> server infrastructure, and it only accepts specific ports.
>
> And looking in the other direction, there are also firewalls between the
> labs, UAT environments, and regular network, as well as protecting the
> mainframes from the unwashed masses.
>
> For B2B extranets, it's even more prevalent. There, firewalls will
> usually also be very strict in what they allow out, because the last
> thing you want is a letter from the legal dept. of Boeing, NASA, or say,
> the London Stock Exchange saying you are trying to infect their network
> with bots.
And you're seriously saying that somebody would go to all that trouble,
and then allow arbitrary Internet traffic so long as it's on TCP port 80?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Le 2011-11-28 04:02, Invisible a écrit :
>>> To this day I have never yet seem a firewall which blocks *outbound*
>>> traffic. So I don't see why this would even be an issue.
>>>
>>
>> That's because you haven't seen many firewalls!
>>
>> At my current place of employment, there are three different layers of
>> firewalls between the user environment and the public Internet. not only
>> do each layer block unauthorized traffic in both directions, there isn't
>> even a default route out to the Internet. You need to talk to the proxy
>> server infrastructure, and it only accepts specific ports.
>>
>> And looking in the other direction, there are also firewalls between the
>> labs, UAT environments, and regular network, as well as protecting the
>> mainframes from the unwashed masses.
>>
>> For B2B extranets, it's even more prevalent. There, firewalls will
>> usually also be very strict in what they allow out, because the last
>> thing you want is a letter from the legal dept. of Boeing, NASA, or say,
>> the London Stock Exchange saying you are trying to infect their network
>> with bots.
>
> And you're seriously saying that somebody would go to all that trouble,
> and then allow arbitrary Internet traffic so long as it's on TCP port 80?
Where did I say that?
I did say that traffic has to go through a proxy before getting out,
didn't I? Since, as you point out, lots of thought went into designing
the various security zones and their respective security policies, one
can safely assume that a similar level of care went into designing the
proxy infrastructure. Of course URLs are filtered, pages scanned on the
fly, java applet signatures verified, etc...
If I'm really lucky, I'd be able to listen to some streaming radio site,
but my internet usage would probably be reported to my manager.
Thankfully, I work from home most of the time, so I don't have to worry
about losing my job because I spent a few minutes watching a Youtube video.
--
/*Francois Labreque*/#local a=x+y;#local b=x+a;#local c=a+b;#macro P(F//
/* flabreque */L)polygon{5,F,F+z,L+z,L,F pigment{rgb 9}}#end union
/* @ */{P(0,a)P(a,b)P(b,c)P(2*a,2*b)P(2*b,b+c)P(b+c,<2,3>)
/* gmail.com */}camera{orthographic location<6,1.25,-6>look_at a }
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> And you're seriously saying that somebody would go to all that trouble,
>> and then allow arbitrary Internet traffic so long as it's on TCP port 80?
>
> Where did I say that?
Well, you didn't. But this whole "everybody uses HTTP because it goes
through the firewall" seems absurd to me, because... well... people
filter HTTP traffic too, no?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 11/28/2011 1:02, Invisible wrote:
> And you're seriously saying that somebody would go to all that trouble, and
> then allow arbitrary Internet traffic so long as it's on TCP port 80?
Not any more. Now people invented "application-layer proxies" to prevent you
from doing that sort of crap.
Look up "push web" online. That's what they used to call this stuff before
it became just a normal part of doing business.
--
Darren New, San Diego CA, USA (PST)
People tell me I am the counter-example.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Mon, 28 Nov 2011 09:02:07 +0000, Invisible wrote:
> And you're seriously saying that somebody would go to all that trouble,
> and then allow arbitrary Internet traffic so long as it's on TCP port
> 80?
Yep, lots of businesses do that.
When I was traveling to teach, I would often (after getting approval from
the client) tunnel through HTTP to get ssh and (primarily) e-mail
connections to my corporate servers.
Jim
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> And you're seriously saying that somebody would go to all that trouble,
>> and then allow arbitrary Internet traffic so long as it's on TCP port
>> 80?
>
> Yep, lots of businesses do that.
That's kind of bizarre, don't you think?
> When I was traveling to teach, I would often (after getting approval from
> the client) tunnel through HTTP to get ssh and (primarily) e-mail
> connections to my corporate servers.
I can see how it would be pretty trivial to just run SSH over TCP port
80. But I don't see how you can tunnel SSH over HTTP...
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Tue, 29 Nov 2011 09:02:46 +0000, Invisible wrote:
>>> And you're seriously saying that somebody would go to all that
>>> trouble,
>>> and then allow arbitrary Internet traffic so long as it's on TCP port
>>> 80?
>>
>> Yep, lots of businesses do that.
>
> That's kind of bizarre, don't you think?
Not really, identifying what the traffic actually is requires a fair bit
of work.
>> When I was traveling to teach, I would often (after getting approval
>> from the client) tunnel through HTTP to get ssh and (primarily) e-mail
>> connections to my corporate servers.
>
> I can see how it would be pretty trivial to just run SSH over TCP port
> 80. But I don't see how you can tunnel SSH over HTTP...
Go have a look at the program 'httptunnel'. You do need a listener on
the outside.
Jim
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
