Someone sent me this link about the new 64-bit Windows XP. There's some interesting text on that page I would like to quote here (assuming the link doesn't change...):
I can tell you with confidence that if you go from Solaris 9 on x86 to Solaris 10 with both x86 and x64, you will NOT have to erase your hard drive (assuming you've enough room for the new x64-native binaries, and you probably do already if you're in possession of an x64-capable box).
Wednesday, April 27, 2005
Monday, March 28, 2005
US Navy and Open Source - how last decade! :)
An old friend/colleague sent me this url:
http://linux.slashdot.org/article.pl?sid=05/03/26/028200&tid=103&tid=106
And in particular wanted me to read this response to the posting in question.
The response is pretty good, and right up front talks about two projects (see here and here respectively) that I had the pleasure to work on.
The work we did at NRL lives on today in many places either directly or indirectly. We have our war stories (no pun intended), including locking horns with GPL-bigots who did not like that we were going to put out our software with a BSD license, in spite of our funding sources' requirements that our work be directly transferable into commercial products.
So raise your glasses to the new, folks, but don't forget the old. And also don't forget that just because you remember history, it doesn't mean that you can't make the good parts repeat!
http://linux.slashdot.org/article.pl?sid=05/03/26/028200&tid=103&tid=106
And in particular wanted me to read this response to the posting in question.
The response is pretty good, and right up front talks about two projects (see here and here respectively) that I had the pleasure to work on.
The work we did at NRL lives on today in many places either directly or indirectly. We have our war stories (no pun intended), including locking horns with GPL-bigots who did not like that we were going to put out our software with a BSD license, in spite of our funding sources' requirements that our work be directly transferable into commercial products.
So raise your glasses to the new, folks, but don't forget the old. And also don't forget that just because you remember history, it doesn't mean that you can't make the good parts repeat!
Sunday, January 9, 2005
Grudge Match (TM) to Jump the Shark (TM)?
Now that I've got my "I like end-systems doing the heavy lifting" rant out there, it's time to lighten up for a bit.
One of my favorite humor sites is the World-Wide Web Fights - Grudge Match page. They take the 4th-grade (age 9 for our international readers) concept of "oooh, what if the Enterprise took on the Death Star?" to its maximum silliness and fun. I've been a regular reader (and occasional Bronze-Medal contributor as well) for most of its 10 years of existence.
So now, their current match has the interesting property of having cursed-actor Ted McGinty as one of the contestants... and their hint for their next match is "Jumping the Shark", which I'll let readers follow this link to see background information on the term.
I was concerned that one of my favorite sites would not make it to its 10-year anniversary. So I sent a mail, and got this enigmatic response (full poor-form top-posted reply included):
So I'm hoping it's just a stunt - and a funny one at that. If you're semi-knowledgible about American pop culture, you'll probably bust a gut at some of the matches on this site. Please click that link above and visit... before it's too late?!?
One of my favorite humor sites is the World-Wide Web Fights - Grudge Match page. They take the 4th-grade (age 9 for our international readers) concept of "oooh, what if the Enterprise took on the Death Star?" to its maximum silliness and fun. I've been a regular reader (and occasional Bronze-Medal contributor as well) for most of its 10 years of existence.
So now, their current match has the interesting property of having cursed-actor Ted McGinty as one of the contestants... and their hint for their next match is "Jumping the Shark", which I'll let readers follow this link to see background information on the term.
I was concerned that one of my favorite sites would not make it to its 10-year anniversary. So I sent a mail, and got this enigmatic response (full poor-form top-posted reply included):
To: danmcd@kebe.com
Subject: Re: You're not going off the air, are you?
I can neither confirm nor deny these rumors.
- Brian (tm)
Dan McDonald wrote:
>
> Please tell me it's a 10-year anniversary stunt... bringing Ted McGinley
> aboard, and then teasing us about Jumping the Shark... please, please, please
> don't go off the air!
>
> A fan since 1995 (and recipient of both a Final Word and a Bronze Grudgie),
> Dan McD.
--
- Brian Wright
WWWF Grudge Match
http://www.grudge-match.com/
"So consistently funny it ought to be developed into
a series for Comedy Central!"
- Entertainment Weekly
So I'm hoping it's just a stunt - and a funny one at that. If you're semi-knowledgible about American pop culture, you'll probably bust a gut at some of the matches on this site. Please click that link above and visit... before it's too late?!?
Monday, January 3, 2005
I hate middleboxes...
Ever since I worked on one of the early IPv6 implementations, I've had a sour taste in my mouth for any node in the middle of a network that did more than forward packets (or maybe one or two other things, which I'll talk about later).
Nodes that are in the middle of the network and do not merely forward packets I will call middleboxes in this entry. The granddaddy middlebox was the firewall. These were designed to prevent classes of packets (often very large classes of packets) from reaching a network that was connected to the Internet. Given the poor state of end-node implementations (anyone remember when sendmail was the biggest source of vulnerabilities?) at the time, firewalls were a sensible solution to the problem.
To cope with people demanding Internet services while still being behind their safe firewall, the proxy came into play. These boxes pretend to be servers for machines on the inside of a firewall, and clients to machines outside the firewall.
To cope with address space "shortages" (especially when the addresses in question might never be seen on the Internet, thanks to firewalling), the Network Address Translator (NAT) was invented. To the outside world, the NAT presents a small number of Internet addresses (often that number is one). Behind the NAT, there is a whole network (usually carved out of addresses that are reserved just for this
purpose) of nodes.
These nodes often cause as many problems as they solve. A server cannot depend on IP addresses (whether or not that's good design is a discussion for another time) any more (even if they're secured with IPsec). IPsec itself does not work without the NAT-Traversal hack (now available in Solaris 10). Anything using a proxy is prone to failure if the proxy is flaky - my outbound ssh sessions often disappear because the proxy times them out. With most middleboxes, state that should only be on the two the end-nodes is now distributed to a third, or more. And often, that third node is out of the user's control.
There are some good cases for having some set of middlebox functionality. Alec Muffet has convinced me with
defense-in-depth arguments that some set of firewall functionality is useful in various environments. I can understand (but still despise) NAT in places where stingy ISPs only allow one address per subscriber, or worse, do NAT for you. We are where we are today because a lot of this was a market-driven reaction to poor implementations of network service applications (and in some cases the OS as well). We in OS and network-service development can, of course, fix this if we try hard enough. I'd suggest looking at recent articles about what historical development practices have wrought.
I think we all finally understand what our responsibilities are as end-node engineers. The sooner we act on those responsibilities, the sooner we can remove any excuses for the new classes of bridge trolls to exist. (Did I mention anyone who likes this blog should visit David Reed's excellent site?) And if any folks out there are dissatisfied with their current choice, I hope that they realize that the market will provide other choices.
Nodes that are in the middle of the network and do not merely forward packets I will call middleboxes in this entry. The granddaddy middlebox was the firewall. These were designed to prevent classes of packets (often very large classes of packets) from reaching a network that was connected to the Internet. Given the poor state of end-node implementations (anyone remember when sendmail was the biggest source of vulnerabilities?) at the time, firewalls were a sensible solution to the problem.
To cope with people demanding Internet services while still being behind their safe firewall, the proxy came into play. These boxes pretend to be servers for machines on the inside of a firewall, and clients to machines outside the firewall.
To cope with address space "shortages" (especially when the addresses in question might never be seen on the Internet, thanks to firewalling), the Network Address Translator (NAT) was invented. To the outside world, the NAT presents a small number of Internet addresses (often that number is one). Behind the NAT, there is a whole network (usually carved out of addresses that are reserved just for this
purpose) of nodes.
These nodes often cause as many problems as they solve. A server cannot depend on IP addresses (whether or not that's good design is a discussion for another time) any more (even if they're secured with IPsec). IPsec itself does not work without the NAT-Traversal hack (now available in Solaris 10). Anything using a proxy is prone to failure if the proxy is flaky - my outbound ssh sessions often disappear because the proxy times them out. With most middleboxes, state that should only be on the two the end-nodes is now distributed to a third, or more. And often, that third node is out of the user's control.
There are some good cases for having some set of middlebox functionality. Alec Muffet has convinced me with
defense-in-depth arguments that some set of firewall functionality is useful in various environments. I can understand (but still despise) NAT in places where stingy ISPs only allow one address per subscriber, or worse, do NAT for you. We are where we are today because a lot of this was a market-driven reaction to poor implementations of network service applications (and in some cases the OS as well). We in OS and network-service development can, of course, fix this if we try hard enough. I'd suggest looking at recent articles about what historical development practices have wrought.
I think we all finally understand what our responsibilities are as end-node engineers. The sooner we act on those responsibilities, the sooner we can remove any excuses for the new classes of bridge trolls to exist. (Did I mention anyone who likes this blog should visit David Reed's excellent site?) And if any folks out there are dissatisfied with their current choice, I hope that they realize that the market will provide other choices.
Tuesday, November 30, 2004
Hello, world!
NOTE: Obviously this was from my old Sun blog.
Welcome to my Sun blog. I was encouraged by certain people (who appear on my list of other Sun blogs) to set up one of these, and so I have.
The title of this blog comes from one of the fundamental principles of the Internet architecture -- The End to End Argument. Anyone who claims to do networking for a living should at least know about this paper, if not be able to explain it to you. Basically, the end to end argument states that only the application(s) at the two endpoints of communication know exactly what's going on. The network should not get involved, unless it can provide a useful performance enhancement.
That's all for now. I will be back as time permits. Thanks!
Welcome to my Sun blog. I was encouraged by certain people (who appear on my list of other Sun blogs) to set up one of these, and so I have.
The title of this blog comes from one of the fundamental principles of the Internet architecture -- The End to End Argument. Anyone who claims to do networking for a living should at least know about this paper, if not be able to explain it to you. Basically, the end to end argument states that only the application(s) at the two endpoints of communication know exactly what's going on. The network should not get involved, unless it can provide a useful performance enhancement.
That's all for now. I will be back as time permits. Thanks!
Subscribe to:
Posts (Atom)