Yes, I meant that you wouldn't start sending it out til you had the first few bytes of the layer 4 header.:-) That's more latency than a layer 3 switch, but less latency than a layer 4 router when there isn't enough traffic to queue more than 1 packet.
Of course, I don't know how much benefit there'd be to that really. Most of the time when you're close enough for the speed of light to not swamp the latency you can use a layer 3 switch since you don't generally need the added security and checking of the layer 4 forwarding and filtering rules.
I guess if apartment level ISPs started being commonplace, there'd be a use. Or maybe in hosting centers, though most traffic at such places isn't between machines at the hosting center.
That sounds kind of interesting. I'll have to look into it. I suspect though that the card might end up with 2 IP addresses unless they're doing some really ugly munging that I'd prefer they not do.
But, that's what I meant by layer 4 switch. It wouldn't start sending the packet out the door until it had gotten the first few bytes of the layer three payload so it could apply the layer 4 rules.
May I ask why? Is it for operational performance e.g. you believe you can increase the code's quality, operational comfort e.g. you can validate the code, or just a personal preference for open source architectures?
All three reasons to varying degrees.
I don't really think I can increase the code's quality significantly, but I would like to be able to stuff in some new algorithm because, say, SHA-1 or AES was broken. And I don't want to have to depend on the vendor to do this for me.
I don't necessarily trust the vendor's code. For CPU microcode (as an example), this is only a little important. There aren't a lot of ways for a CPU to purposely leak information to the outside world, though I would like to be able to disable any DRM technologies I found. But, for a network card, especially one I trust to do encryption for me, this is supremely important.
I also have a preference for Open Source technologies. I think Open Source is more efficient for the economy as a whole, even if it makes it slightly harder for some particular company to make money or keep themselves technologically ahead of their competitors.
If this card can do most of the work of IPSEC for me, it'd be a big win.
My main concern though is that with two ports, how can I be absolutely certain the packet has to go through my firewall rules before it can go anywhere?
Of course, the extra ports could be an advantage. If it could handle all the rules for you, then it might even be capable of functioning as a layer 4 switch and sending out a new IP packet before completely recieving said packet.
But, I'd want all the software on that card to be Open Source.
*shrug* I had one brief stint of being unemployed. It lasted for 9 months in 2003. I'm currently wearing shorts and a t-shirt, and I'm using Linux for my development environment.
I don't think this kind of environment is rare.
I think clothing and appearance standards are arbitrary. Witness how they've changed so drastically over the centuries, or how they were so very different in different parts of the world until european influences took over.
I do not believe that you should be able to do whatever you want, always. I think that if something isn't important for getting your job done, it shouldn't matter. Dress and appearance are among those things for the average programmer. The fact that you think my attitude equates to that tells me you have a huge attitude problem and aren't very professional. I would not want to work with you, and if I noticed it while interviewing you, I'd recommend against hiring because you'd wouldn't work well with people you thought were too different.
So, you think that rather than take a single life, we should've just rolled over and let the Japanese and Germans have their way rather than kill anybody? It's war, and the sad fact is, in war, you kill people. You start having to make moral decisions that you generally find horribly repugnant. That's how it is, and that's why war is ugly.
You know, at Amazon you're out of place if you're wearing a suit. If you wore anything resembling a suit to work there, people would assume you were interviewing elsewhere, or that you were just a martian.
OTOH, lots of people there have visible tattoos and piercings.
The standard is arbitrary, and stupid. And your narrow-minded little rant says more about you than anything else. I do not want to work in a place where people have your attitude. It's their loss.
To me, your attitude indicates your severe lack of professionalism. "Mommy, the man with the funny haircut scares me! I don't care if he's written software that's made things ten times faster and less error-prone. What's important is his scary haircut. Please make him go away!"
Actually, when I interview people, a suit tends to count as a very mild minus. I have to remind myself that some people seem to expect that you should wear a suit to an interview so I don't view the candidate in a more negative light than I ought to. I hate suits, and most people I've met (outside of an interview situation) who were wearing a suit were disingenuous and slimey.
Interesting. That must be why more games get ported to Linux than the Mac, because Linux has a bigger desktop share... Oh, wait...
This is a pititful excuse by game developers who don't want to change their attitudes or outlooks. All that make your game easily portable requires is dumping all the DirectBlah BS and using an API that doesn't make you Microsoft's whipping boy.
Heck, if the API is inadequate, you could even add a bit to it for whatever it is you needed and release the changes back. It might make it easier to make games, which would make a bigger market, which would probably make things better for everybody.
As it is, I tend to buy games from small independents (Garage Games, Guild Software, Introversion Software, the list goes on) instead of the big publishers because the game developers who work for them have minds of their own and tend to make Linux versions of stuff. As opposed to people like you who stick their fingers in their ears and chant 'Marketshare' over and over again.
He doesn't strike me as someone who'd do something like that. Perhaps you're right, but I've read his blog for awhile now, and it doesn't seem in his character.
I think he's honestly just very peeved and looking for a way to just not have to worry about all the little details and glitches that is desktop Linux today. He tends to be outspoken and curmudgeonly, but doesn't seem to be especially much of an attention hound.
Your vision of the development process is flawed because you expect the impossible of the client.
The client can't give you the exact specification, and they never will be able to. You have to design and build in very small steps and get them to look at what you have after every step. That way, you'll never spend a whole bunch of wasted time and effort going down the right path. Also, the client will have a lot more visibility into the project and will be consequently be happier with it because they won't think you made a bunch of arbitrary design choices for your own benefit that they disagree with.
You are insane. Why not just completely disconnect from the Internet? That's what you'll have to do eventually as the war between your insane egress filtering and the virus writers escalates.
Nope, never been fired over it yet. In smaller places, I end being de-facto in charge of security even though I'm mostly a developer. And I would generally not work in a place where the sysadmin was so incompetent that they felt the need to egress filter anyway.
Yeah, like you'll even notice. DNS tunneling, HTTP tunneling, SMTP tunneling, the choices are manifold. And you can even use all of them at once. Once you cover one loophole, another will be thought of. I wrote my own piece of tunneling software in a matter of a few hours once. Not one of you obnoxious control freaks is going to prevent me from ssh'ing home.
Egress filtering is evil and pointlessly stupid. Any sysadmin who engages in it is covering their own incompetence.
Umm... The BSD license doesn't have to be broken in order for some random person or company to close up their version. The software isn't licensed under the GPL, which would prevent this.
No, it wasn't. And if it were a GUI application, I would separate the application into presentation and engine layers. Then I would write completely different presentation layers for each platform while keeping the engine layer largely the same. This is the approach taken by Nethack, and I believe that it has been ported to more paltforms than practically anything else, with the possible exception of emacs and gcc.
The various different platforms all have distinct UI rules that are followed by convention in all the apps on that platform. It would be nearly impossible to make a single set of code that could present the GUI properly on all of them.
Alternatively, I would use a cross-platform GUI library like Qt, *shudder* Tk, wxWindows, or GNOME/GTK. Then I would be honest that my application would largely not share the multitude of little rules and conventions that other native applications on that platform had.
I would actually be distraught nearly to the point of apoplexy to discover some body of code that tried to use #ifdef's to manage a cross-platform GUI.
I have done this. And I did it by building a library of platform dependent code and using a different libraries on the two platform. The entry points to the library remained nearly identical.
The only place where platform dependence crept into the main code was where I had to have one set of code to deal with being an NT service and another to be a proper Unix daemon. Then, I believe (if I remember correctly) I made an attempt at factoring the code out into two different modules and had perhaps one or two #ifdef's in the main code.
The basic concepts of Win32 and Unix are actually very similar. The implementation details of those concepts are wildly divergent, and certain concepts (like fork) don't translate at all, but it wasn't enough to affect the main body of the program.
Firewalls that firewall outgoing traffic in that way deserved to have their input voltages increased by an order of magnitude until all their components have been turned into unrecognizable lumps of slag. In addition, the people who set them up that way should be forced to requisition a platypus and a pregnant mule from a position inside the middle tier of the British bureuacracy.
Really, egress filtering in that way is just plain stupid. The only egress filtering I implement is not allowing people who connect to my open wireless AP to connect to port 25 of any system in the outside world to avoid accidentally providing spammer hosting.
Most of the time, when I see #ifdef's being used for platform independence, I see a bunch of code that is written in a very platform dependent way that doesn't actually need to be. I also see platform dependencies being allowed to proliferate through code instead of being confined to a small area.
I admit that in some code, in some places, #ifdef is the way to manage platform independence. But, in most code, in most places, it's not, and you should refactor your code to either completely remove the platform dependencies, or confine them to as small a piece of code as possible.
I've maintained commerical code that was ported to at least 8 (probably more) different Unix platforms. There was a core of that code that did a lot to encapsulate platform dependencies in a small area, and a much larger body of code in which the tool of first-resort was a #ifdef. One body of code required a lot of babying and maintenance work. Another ported effortlessly. I'll let you guess which was which.
IMHO, #ifdef's are a poor way to handle portability, and the code needs some serious refactoring to either try to find a single method that works on all platforms properly, or move the platform dependent piece out to separate modules.
I've been advocating this point of view quietly for awhile. I think the justification for it is sound.
The third amendment reads:
No Soldier shall, in time of peace be quartered in any house, without the consent of the Owner, nor in time of war, but in a manner to be prescribed by law.
I take this to mean that people shall not be required to personally support agents of the state in their homes. The broadcast flag requires that a piece of hardware that tries to monitor and control your activity for the purpose of furthering the goals of the state be installed in devices that you buy and pay for the electricity to run and such. I think this constitutes being forced to personally support an agent of the state in ones home.
Slashdot Mirror
Yes, I meant that you wouldn't start sending it out til you had the first few bytes of the layer 4 header. :-) That's more latency than a layer 3 switch, but less latency than a layer 4 router when there isn't enough traffic to queue more than 1 packet.
Of course, I don't know how much benefit there'd be to that really. Most of the time when you're close enough for the speed of light to not swamp the latency you can use a layer 3 switch since you don't generally need the added security and checking of the layer 4 forwarding and filtering rules.
I guess if apartment level ISPs started being commonplace, there'd be a use. Or maybe in hosting centers, though most traffic at such places isn't between machines at the hosting center.
That sounds kind of interesting. I'll have to look into it. I suspect though that the card might end up with 2 IP addresses unless they're doing some really ugly munging that I'd prefer they not do.
It's certainly not my best post. But I don't think it's quite that bad.
If this card can do most of the work of IPSEC for me, it'd be a big win.
My main concern though is that with two ports, how can I be absolutely certain the packet has to go through my firewall rules before it can go anywhere?
Of course, the extra ports could be an advantage. If it could handle all the rules for you, then it might even be capable of functioning as a layer 4 switch and sending out a new IP packet before completely recieving said packet.
But, I'd want all the software on that card to be Open Source.
*shrug* I had one brief stint of being unemployed. It lasted for 9 months in 2003. I'm currently wearing shorts and a t-shirt, and I'm using Linux for my development environment.
I don't think this kind of environment is rare.
I think clothing and appearance standards are arbitrary. Witness how they've changed so drastically over the centuries, or how they were so very different in different parts of the world until european influences took over.
I do not believe that you should be able to do whatever you want, always. I think that if something isn't important for getting your job done, it shouldn't matter. Dress and appearance are among those things for the average programmer. The fact that you think my attitude equates to that tells me you have a huge attitude problem and aren't very professional. I would not want to work with you, and if I noticed it while interviewing you, I'd recommend against hiring because you'd wouldn't work well with people you thought were too different.
So, you think that rather than take a single life, we should've just rolled over and let the Japanese and Germans have their way rather than kill anybody? It's war, and the sad fact is, in war, you kill people. You start having to make moral decisions that you generally find horribly repugnant. That's how it is, and that's why war is ugly.
You know, at Amazon you're out of place if you're wearing a suit. If you wore anything resembling a suit to work there, people would assume you were interviewing elsewhere, or that you were just a martian.
OTOH, lots of people there have visible tattoos and piercings.
The standard is arbitrary, and stupid. And your narrow-minded little rant says more about you than anything else. I do not want to work in a place where people have your attitude. It's their loss.
To me, your attitude indicates your severe lack of professionalism. "Mommy, the man with the funny haircut scares me! I don't care if he's written software that's made things ten times faster and less error-prone. What's important is his scary haircut. Please make him go away!"
Actually, when I interview people, a suit tends to count as a very mild minus. I have to remind myself that some people seem to expect that you should wear a suit to an interview so I don't view the candidate in a more negative light than I ought to. I hate suits, and most people I've met (outside of an interview situation) who were wearing a suit were disingenuous and slimey.
I'm not sure if you got the sarcasm... Linux has a desktop marketshare that's roughly equivalent (and quite possibly greater) to the Mac's.
Interesting. That must be why more games get ported to Linux than the Mac, because Linux has a bigger desktop share... Oh, wait...
This is a pititful excuse by game developers who don't want to change their attitudes or outlooks. All that make your game easily portable requires is dumping all the DirectBlah BS and using an API that doesn't make you Microsoft's whipping boy.
Heck, if the API is inadequate, you could even add a bit to it for whatever it is you needed and release the changes back. It might make it easier to make games, which would make a bigger market, which would probably make things better for everybody.
As it is, I tend to buy games from small independents (Garage Games, Guild Software, Introversion Software, the list goes on) instead of the big publishers because the game developers who work for them have minds of their own and tend to make Linux versions of stuff. As opposed to people like you who stick their fingers in their ears and chant 'Marketshare' over and over again.
He doesn't strike me as someone who'd do something like that. Perhaps you're right, but I've read his blog for awhile now, and it doesn't seem in his character.
I think he's honestly just very peeved and looking for a way to just not have to worry about all the little details and glitches that is desktop Linux today. He tends to be outspoken and curmudgeonly, but doesn't seem to be especially much of an attention hound.
Your vision of the development process is flawed because you expect the impossible of the client.
The client can't give you the exact specification, and they never will be able to. You have to design and build in very small steps and get them to look at what you have after every step. That way, you'll never spend a whole bunch of wasted time and effort going down the right path. Also, the client will have a lot more visibility into the project and will be consequently be happier with it because they won't think you made a bunch of arbitrary design choices for your own benefit that they disagree with.
Now we know why your username is SiO2. You are utterly transparent to humor, it goes right through you without affecting you at all.
You are insane. Why not just completely disconnect from the Internet? That's what you'll have to do eventually as the war between your insane egress filtering and the virus writers escalates.
Nope, never been fired over it yet. In smaller places, I end being de-facto in charge of security even though I'm mostly a developer. And I would generally not work in a place where the sysadmin was so incompetent that they felt the need to egress filter anyway.
Yeah, like you'll even notice. DNS tunneling, HTTP tunneling, SMTP tunneling, the choices are manifold. And you can even use all of them at once. Once you cover one loophole, another will be thought of. I wrote my own piece of tunneling software in a matter of a few hours once. Not one of you obnoxious control freaks is going to prevent me from ssh'ing home.
Egress filtering is evil and pointlessly stupid. Any sysadmin who engages in it is covering their own incompetence.
Egress filtering is evil. The first thing I do upon encountering it is erect a tunnel.
Umm... The BSD license doesn't have to be broken in order for some random person or company to close up their version. The software isn't licensed under the GPL, which would prevent this.
No, it wasn't. And if it were a GUI application, I would separate the application into presentation and engine layers. Then I would write completely different presentation layers for each platform while keeping the engine layer largely the same. This is the approach taken by Nethack, and I believe that it has been ported to more paltforms than practically anything else, with the possible exception of emacs and gcc.
The various different platforms all have distinct UI rules that are followed by convention in all the apps on that platform. It would be nearly impossible to make a single set of code that could present the GUI properly on all of them.
Alternatively, I would use a cross-platform GUI library like Qt, *shudder* Tk, wxWindows, or GNOME/GTK. Then I would be honest that my application would largely not share the multitude of little rules and conventions that other native applications on that platform had.
I would actually be distraught nearly to the point of apoplexy to discover some body of code that tried to use #ifdef's to manage a cross-platform GUI.
I have done this. And I did it by building a library of platform dependent code and using a different libraries on the two platform. The entry points to the library remained nearly identical.
The only place where platform dependence crept into the main code was where I had to have one set of code to deal with being an NT service and another to be a proper Unix daemon. Then, I believe (if I remember correctly) I made an attempt at factoring the code out into two different modules and had perhaps one or two #ifdef's in the main code.
The basic concepts of Win32 and Unix are actually very similar. The implementation details of those concepts are wildly divergent, and certain concepts (like fork) don't translate at all, but it wasn't enough to affect the main body of the program.
Firewalls that firewall outgoing traffic in that way deserved to have their input voltages increased by an order of magnitude until all their components have been turned into unrecognizable lumps of slag. In addition, the people who set them up that way should be forced to requisition a platypus and a pregnant mule from a position inside the middle tier of the British bureuacracy.
Really, egress filtering in that way is just plain stupid. The only egress filtering I implement is not allowing people who connect to my open wireless AP to connect to port 25 of any system in the outside world to avoid accidentally providing spammer hosting.
Most of the time, when I see #ifdef's being used for platform independence, I see a bunch of code that is written in a very platform dependent way that doesn't actually need to be. I also see platform dependencies being allowed to proliferate through code instead of being confined to a small area.
I admit that in some code, in some places, #ifdef is the way to manage platform independence. But, in most code, in most places, it's not, and you should refactor your code to either completely remove the platform dependencies, or confine them to as small a piece of code as possible.
I've maintained commerical code that was ported to at least 8 (probably more) different Unix platforms. There was a core of that code that did a lot to encapsulate platform dependencies in a small area, and a much larger body of code in which the tool of first-resort was a #ifdef. One body of code required a lot of babying and maintenance work. Another ported effortlessly. I'll let you guess which was which.
IMHO, #ifdef's are a poor way to handle portability, and the code needs some serious refactoring to either try to find a single method that works on all platforms properly, or move the platform dependent piece out to separate modules.
I've been advocating this point of view quietly for awhile. I think the justification for it is sound.
The third amendment reads:
I take this to mean that people shall not be required to personally support agents of the state in their homes. The broadcast flag requires that a piece of hardware that tries to monitor and control your activity for the purpose of furthering the goals of the state be installed in devices that you buy and pay for the electricity to run and such. I think this constitutes being forced to personally support an agent of the state in ones home.