On 29 Dec 2012, at 20:17, Joe Ferraro wrote:
I don't think I've seen a developer "code" anything lower than Ruby or Python in years...
I consider PHP t be marginally lower than both, but no less of a bastardisation of the concept of coding. I do owe my career to it though ;)
--
Mark Benson
http://DECtec.info
Twitter: @DECtecInfo
HECnet: STAR69::MARK
Online Resource & Mailing List for DEC Enthusiasts.
On 29 Dec 2012, at 15:17, Joe Ferraro <jferraro at gmail.com> wrote:
Johnny... you are still too low in the stack... JAVA may as well be the new assembly (though I think its more like the COBOL of future IT, in that we'll spend the next 50 years trying to get rid of it). I don't think I've seen a developer "code" anything lower than Ruby or Python in years...
I don't think Sunacle will let Java die. ;)
I know someone that was trying to make an IRC bot in x86 ASM...
On Sat, Dec 29, 2012 at 3:15 PM, Johnny Billquist <bqt at softjar.se> wrote:
On 2012-12-29 20:55, Peter Lothberg wrote:
But it is fun to see people fail. :-)
It is definitely fun to watch people try to break in to VMS. ;)
On Sol.Stupi.Se (59.10) they think it understands X.86 binaries..
I'm sure tehey don't even understand the stackpointer moves UP not
down on a DEC20/PDP10.
You are giving them way too much credit, Peter. I'm sure most of them would not even know what a stack pointer is... The stack is a magic object that keeps information around in your Java virtual machine...
Johnny
--
Cory Smelosky
http://gewt.net/ Personal stuff!
http://gimme-sympathy.org/ My permanently-a-work-in-progress pet project.
Johnny... you are still too low in the stack... JAVA may as well be the new assembly (though I think its more like the COBOL of future IT, in that we'll spend the next 50 years trying to get rid of it). I don't think I've seen a developer "code" anything lower than Ruby or Python in years...
On Sat, Dec 29, 2012 at 3:15 PM, Johnny Billquist <bqt at softjar.se> wrote:
On 2012-12-29 20:55, Peter Lothberg wrote:
But it is fun to see people fail. :-)
It is definitely fun to watch people try to break in to VMS. ;)
On Sol.Stupi.Se (59.10) they think it understands X.86 binaries..
I'm sure tehey don't even understand the stackpointer moves UP not
down on a DEC20/PDP10.
You are giving them way too much credit, Peter. I'm sure most of them would not even know what a stack pointer is... The stack is a magic object that keeps information around in your Java virtual machine...
Johnny
On 29 Dec 2012, at 15:15, Johnny Billquist <bqt at softjar.se> wrote:
On 2012-12-29 20:55, Peter Lothberg wrote:
But it is fun to see people fail. :-)
It is definitely fun to watch people try to break in to VMS. ;)
On Sol.Stupi.Se (59.10) they think it understands X.86 binaries..
I'm sure tehey don't even understand the stackpointer moves UP not
down on a DEC20/PDP10.
You are giving them way too much credit, Peter. I'm sure most of them would not even know what a stack pointer is... The stack is a magic object that keeps information around in your Java virtual machine
What're you talking about? ;) Most skiddies would use VB.net. ;)
Johnny
--
Cory Smelosky
http://gewt.net/ Personal stuff!
http://gimme-sympathy.org/ My permanently-a-work-in-progress pet project.
Interesting... my "attacks" seem to come from botnets... I'm surprised that this is a deterrent, unless you mostly see single-host attacks...
Funny nonetheless...
On Sat, Dec 29, 2012 at 12:34 PM, <sampsa at mac.com> wrote:
> I usually just ignore that stuff. There is constant probing of my web server on MIM. It's kindof fun to see all kind of stuff they are trying. Also a good reference to see all kind of problems and exploits that exists on Unix and Windows web servers...
>
> (I *think* my RSX web server is actually pretty safe, but who knows...)
>
> Trying to retaliate would be an endless battle which I don't care about anyway...
>
But attacking them back is kinda funny, oh here's one more script in case there's no HTTP:
--- gohydra ---
#p1 = host, p2 = port, p3 = service
hydra -P ~/words -l fuckyou -s $2 $1 $3
--- end gohydra ---
On 2012-12-29 20:55, Peter Lothberg wrote:
But it is fun to see people fail. :-)
It is definitely fun to watch people try to break in to VMS. ;)
On Sol.Stupi.Se (59.10) they think it understands X.86 binaries..
I'm sure tehey don't even understand the stackpointer moves UP not
down on a DEC20/PDP10.
You are giving them way too much credit, Peter. I'm sure most of them would not even know what a stack pointer is... The stack is a magic object that keeps information around in your Java virtual machine...
Johnny
But it is fun to see people fail. :-)
It is definitely fun to watch people try to break in to VMS. ;)
On Sol.Stupi.Se (59.10) they think it understands X.86 binaries..
I'm sure tehey don't even understand the stackpointer moves UP not
down on a DEC20/PDP10.
-P
On Dec 29, 2012, at 2:34 PM, Johnny Billquist wrote:
On 2012-12-29 20:29, Paul_Koning at Dell.com wrote:
On Dec 28, 2012, at 4:44 PM, Johnny Billquist wrote:
...
Yes, VMS can route packets. Yes, all ethernet interfaces under DECnet phase IV will have the same MAC address. No, VMS have no idea of the concept of a bridge. And if you bridge two ethernet segments together, and VMS sits on both those segments, bad juju happens.
Actually, DEC nodes are quite aware of bridging -- DEC after all invented LAN bridging. The thing that you have to get right is that the multiple DECnet phase IV interfaces *must* be on distinct extended LANs. The changed MAC addresses are the reason why.
And I still claim that they are not bridging, but routing.
They do not ignorantly repeat any packets received on one interface out on other interfaces, which is what a bridge does.
I'd happily discuss this further, if you really disagree with me. :-)
I quite agree with you. "Routing" nodes are routing... I just disagreed with the comment that VMS nodes don't understand bridging. They don't DO it, but they understand it...
This changes with Phase V, since that doesn't change the MAC address (if it doesn't have to be Phase IV compatible, that is). Also, unlike Phase IV, Phase V supports end nodes with more than one interface.
Right. Phase V is a different story again. And I assume you mean endnodes with more than one active interface, as phase IV endnodes can also have more than one interface, but only one can be active.
Johnny
Yes, that's what I meant.
paul
On 2012-12-29 20:29, Paul_Koning at Dell.com wrote:
On Dec 28, 2012, at 4:44 PM, Johnny Billquist wrote:
...
Yes, VMS can route packets. Yes, all ethernet interfaces under DECnet phase IV will have the same MAC address. No, VMS have no idea of the concept of a bridge. And if you bridge two ethernet segments together, and VMS sits on both those segments, bad juju happens.
Actually, DEC nodes are quite aware of bridging -- DEC after all invented LAN bridging. The thing that you have to get right is that the multiple DECnet phase IV interfaces *must* be on distinct extended LANs. The changed MAC addresses are the reason why.
And I still claim that they are not bridging, but routing.
They do not ignorantly repeat any packets received on one interface out on other interfaces, which is what a bridge does.
I'd happily discuss this further, if you really disagree with me. :-)
This changes with Phase V, since that doesn't change the MAC address (if it doesn't have to be Phase IV compatible, that is). Also, unlike Phase IV, Phase V supports end nodes with more than one interface.
Right. Phase V is a different story again. And I assume you mean endnodes with more than one active interface, as phase IV endnodes can also have more than one interface, but only one can be active.
Johnny
On 29 Dec 2012, at 14:29, <Paul_Koning at Dell.com> wrote:
On Dec 28, 2012, at 4:44 PM, Johnny Billquist wrote:
...
Yes, VMS can route packets. Yes, all ethernet interfaces under DECnet phase IV will have the same MAC address. No, VMS have no idea of the concept of a bridge. And if you bridge two ethernet segments together, and VMS sits on both those segments, bad juju happens.
Actually, DEC nodes are quite aware of bridging -- DEC after all invented LAN bridging. The thing that you have to get right is that the multiple DECnet phase IV interfaces *must* be on distinct extended LANs. The changed MAC addresses are the reason why.
OpenVPN just became touchy and disallowed the MAC address change in my case.
This changes with Phase V, since that doesn't change the MAC address (if it doesn't have to be Phase IV compatible, that is). Also, unlike Phase IV, Phase V supports end nodes with more than one interface.
Can you have different addresses per interface in Phase V?
paul
--
Cory Smelosky
http://gewt.net/ Personal stuff!
http://gimme-sympathy.org/ My permanently-a-work-in-progress pet project.
