It's not unreasonable to have guidelines and even strong recommendations; for example, a company could discourage csh scripts in favor of bash because of the known problems with csh.
The funny thing is that there was a long period of time that all portable shell scripts had to be done in CSH. There were a few nasty incompatibilities between the once ubiquitous bourne shell and BASH found on all of the linux systems.
I was there in '02 or '03 and they had a small library that was open for a few hours every other Saturday. I spent more time sitting on the floor flipping through random WW2 declassified documents than I spent looking at the exhibits. One book was just old photocopies of reports about the german spies during WW2. They were dropped off on the easy coast by u-boat. And since germany couldn't pay them they were given a large quantity of cocaine that they were supposed to sell to fund their activities.
Write it first for BSD under whatever license you so choose. Then port it to the Linux kernel (but it must be a port and not a re-implementation). The software is then a derivative work of your BSD driver and not of the Linux header files. It's not exactly ethical but it's one of those funny loopholes in how the GPL has bastardized copyright law into contract law. If your code is not a derivative work of their copyright then their contract does not apply.
For the record. If you're selling hardware that you manufacture you're better off releasing under a BSD-ish license. It will increase the likelihood of both hobbyists buying it to tinker and other small companies buying it to resell it with their own special sauce.
Just because their social conscience differs from your own does not mean that they are wrong. When you persecute a company or an individual out of an outright intolerance for their beliefs then just how much of a dialogue do you expect?
We don't see things as they are, we see things as we are.
-- Anais Nin
For instance if the propogation of a large scale worm depended on the a server at www.example.com. There are two effective ways to stop the worm in it's tracks. One is to shut down the server at www.example.com. And the other is to pull the domain record. In such a situation most of us would advocate yanking both. I can't say that a registrar should never take action like this without a court order. But I don't believe this instance was jusitified.
Third party off-to-the-side resets are actually hard to do against a modern OS. Remember that big TCP reset against Cisco routers that could tear down BGP sessions... The fix was to be more restrictive on accepting reset packets. To do a third-party reset you have to be able to send the reset in real-time or each endpoint will have advanced their sequence window (actually the ack window is what matters). The reset will be properly ignored as invalid because each endpoint has moved on which would be impossible if one had actually sent the reset.
A third party spoofer can play games with the TCP Timestamps to effectively shut down a connection and he only has to be near-realtime. Send the right value and all of the legitimate packets get dropped by the OSes PAWS checks. I'll leave that one as an exercise to the reader.
GC does not free one big chunk in a single go. They free many small chunks in a single go. You're confusing GC with objstacks which can do a single huge free but they're not suitable for many cases and just don't work at all if you're using tons of memory and your address space gets fragmented. If you use a slab allocator (read the Bonwick papers) you'll probably see a negligble free() cost and very low allocation costs once you have complex objects.
My personal biggest gripe with GC is that it blows out the whole dcache in one go.
Security audits (or hell, any type of code audit) becomes a nightmare the more overloading and polymorphism a programmer uses. I HATE having to audit c++ code from even a moderately creative programmer. Honestly, the more of an OO language a programmer uses, the less verifiably secure it will be and it will be trusted less accordingly.
HTTP servers send a Date: modifier in their response. It doesn't get you millisecond resolution but it's better than nothing the way some machines' clocks drift.
$ telnet ntp.isc.org 80 Trying 204.152.184.138... Connected to ntp.isc.org. Escape character is '^]'. HEAD / HTTP/1.0
HTTP/1.1 302 Found Date: Sun, 31 Jul 2005 17:10:58 GMT Server: Apache Location: http://ntp.isc.org/bin/view/Main/WebHome Connection: close Content-Type: text/html; charset=iso-8859-1
Hey "salesguy bob" can you send me the updated manual for XYZ... How is he going to do that if it's html? What about all of the diagrams and figures? Tarball? Windows users can't read it. Zip file? Some unix users can't read it. What about formatting differences between html renderers?
PDF stands for portable document format. Think about it.
Sometimes I want dead tree manuals so I can get away from my computer for awhile and peruse it by the pool or the beach. Ever try using an LCD display in the sun? And for this I don't want HTML. I want PDF so I have page numbers and a usuable index.
the problem with desinging a new protocol is that the internet community is just too big and everyone will want their piece of the pie. the academics protocol people have no clue about the implementation side and the implementation people have no clue about the academic side.
the academics will want something extremely extensible so they write lots of useless research papers, the implementation people will want something that just fixes the flaws in TCP, and the embedded/router people will want something extremely simple so they can do it in a short time budget. now all the bazillion vendors come in wanting to put their own fingerprint smudges on it... if it ever happens, it'll be a monstrosity far worse than TCP.
on second thought, put 'em all in the same room. maybe they'll bludgeon each other to death.
the only way we'll get a good TCP replacement is if an 800lb gorilla has a few good protocol people that understand both the theoritical side and the implementation side. then they force it down everyones' throats. sadly to say, the only 800lb gorilla that could force the issue today would be Microsoft and I'm not convinced they would do it in a way that excludes all uses not benificial to MS.
i live in maryland. during world war 2, there was a threat of the germans landing troops presumably to conduct guerilla warfare around our nation's capitol. the governor of maryland called for all members of hunting lodges, trap and skeet clubs, shooting clubs and all citizens possessing their own firearms to defend the state in case of a foreign invasion.
ergo, I help constitute a "militia". checkmate my fair weather friend.
No other book will ever be the same. GRRM is such a master of weaving complex plot lines, spawning sub plots that turn into major plots before you notice, then deftly merging multiple plot lines back into one. It's one great tapestry of characters. GRRM honestly took the joy out of reading for me. It's like growing up drinking bud, discovering guiness, and finding out there are only three glasses of guiness on the planet with only three more to come. I check GRRM's web page every day hoping he'll announce when I can get my next hit.
the scrubber has had the ability to force a ttl from the beginning. 'scrub out all min-ttl 255' will evade this check. but it isn't enough to evade a good passive os fingerprinting algorithm. that is _really_ hard to do. an intermediate device can't easily play with the initial window size or the MSS without destroying the connection. DF, window scaling and tcp option order/nop are safe to play with though.
an aunt optometrist who does lasik, an uncle optometrist who works in the hospital, and another uncle who is a hotshot prof. of optometry. relatives w/ lasik.... zero
besides. crappy vision is a great excuse for xray specs at the beach;-)
bugs exist. deal with it. expecting anything less is naive.
to rewriting these in 'safe' languages. thank you very much but no. pushing the responsibity for security off the software author and onto the compiler/virtual machine is not a solution. it just deflects blame. not to mention the performance implications of doing crypto in a virtual machine. blech
waaah waaah. quit whining and write your own. a basic malloc/free implementation with hooks to mprotect takes a few hours max to write. POSIX even defines how the faulting address is returned to a signal handler so you can correlate the fault back to the source of the allocation or free. Last I tried, linux's return wasn't POSIX compliant but it was easy to work around with an ifdef.
then extend free to scan the outstanding objects for stale pointers into the object you're freeing and produce run-time warnings.
if you have a memory intensive application, you may need to limit the debugging to selective malloc sizes or only apply the debugging to specific object pools (if you use a pool allocator)
if you're a compentent programmer, it will take you a day to get all the kinks out. if you're not, go use java with all the other retards.
i believe major investment houses and large banks have little black boxes to place on both ends of a T1. they do the crypto, but they also constantly stream random bits if there is no real traffic.
do you care about someone pumping a few amps down the wire and trying to burn out the IO pins on your super-duper computer? in that case it would be prudent to pick up your soldering iron and build a serial relay with electro-optical interconnects.
your best bet may be to just go wireless, run IPSEC and keep lots of random traffic in the background. at least it would take more smarts to create an EM pulse strong enough to attack the electronics.
It's not unreasonable to have guidelines and even strong recommendations; for example, a company could discourage csh scripts in favor of bash because of the known problems with csh.
The funny thing is that there was a long period of time that all portable shell scripts had to be done in CSH. There were a few nasty incompatibilities between the once ubiquitous bourne shell and BASH found on all of the linux systems.
I was there in '02 or '03 and they had a small library that was open for a few hours every other Saturday. I spent more time sitting on the floor flipping through random WW2 declassified documents than I spent looking at the exhibits. One book was just old photocopies of reports about the german spies during WW2. They were dropped off on the easy coast by u-boat. And since germany couldn't pay them they were given a large quantity of cocaine that they were supposed to sell to fund their activities.
Write it first for BSD under whatever license you so choose. Then port it to the Linux kernel (but it must be a port and not a re-implementation). The software is then a derivative work of your BSD driver and not of the Linux header files. It's not exactly ethical but it's one of those funny loopholes in how the GPL has bastardized copyright law into contract law. If your code is not a derivative work of their copyright then their contract does not apply.
For the record. If you're selling hardware that you manufacture you're better off releasing under a BSD-ish license. It will increase the likelihood of both hobbyists buying it to tinker and other small companies buying it to resell it with their own special sauce.
Just because their social conscience differs from your own does not mean that they are wrong. When you persecute a company or an individual out of an outright intolerance for their beliefs then just how much of a dialogue do you expect?
We don't see things as they are, we see things as we are.
-- Anais Nin
For instance if the propogation of a large scale worm depended on the a server at www.example.com. There are two effective ways to stop the worm in it's tracks. One is to shut down the server at www.example.com. And the other is to pull the domain record. In such a situation most of us would advocate yanking both. I can't say that a registrar should never take action like this without a court order. But I don't believe this instance was jusitified.
Third party off-to-the-side resets are actually hard to do against a modern OS. Remember that big TCP reset against Cisco routers that could tear down BGP sessions... The fix was to be more restrictive on accepting reset packets. To do a third-party reset you have to be able to send the reset in real-time or each endpoint will have advanced their sequence window (actually the ack window is what matters). The reset will be properly ignored as invalid because each endpoint has moved on which would be impossible if one had actually sent the reset.
A third party spoofer can play games with the TCP Timestamps to effectively shut down a connection and he only has to be near-realtime. Send the right value and all of the legitimate packets get dropped by the OSes PAWS checks. I'll leave that one as an exercise to the reader.
GC does not free one big chunk in a single go. They free many small chunks in a single go.
You're confusing GC with objstacks which can do a single huge free but they're not suitable for many cases and just don't work at all if you're using tons of memory and your address space gets fragmented.
If you use a slab allocator (read the Bonwick papers) you'll probably see a negligble free() cost and very low allocation costs once you have complex objects.
My personal biggest gripe with GC is that it blows out the whole dcache in one go.
Security audits (or hell, any type of code audit) becomes a nightmare the more overloading and polymorphism a programmer uses. I HATE having to audit c++ code from even a moderately creative programmer. Honestly, the more of an OO language a programmer uses, the less verifiably secure it will be and it will be trusted less accordingly.
HTTP servers send a Date: modifier in their response. It doesn't get you millisecond resolution but it's better than nothing the way some machines' clocks drift.
$ telnet ntp.isc.org 80
Trying 204.152.184.138...
Connected to ntp.isc.org.
Escape character is '^]'.
HEAD / HTTP/1.0
HTTP/1.1 302 Found
Date: Sun, 31 Jul 2005 17:10:58 GMT
Server: Apache
Location: http://ntp.isc.org/bin/view/Main/WebHome
Connection: close
Content-Type: text/html; charset=iso-8859-1
Connection closed by foreign host.
Hey "salesguy bob" can you send me the updated manual for XYZ... How is he going to do that if it's html? What about all of the diagrams and figures? Tarball? Windows users can't read it. Zip file? Some unix users can't read it. What about formatting differences between html renderers?
PDF stands for portable document format. Think about it.
Sometimes I want dead tree manuals so I can get away from my computer for awhile and peruse it by the pool or the beach. Ever try using an LCD display in the sun? And for this I don't want HTML. I want PDF so I have page numbers and a usuable index.
the problem with desinging a new protocol is that the internet community is just too big and everyone will want their piece of the pie. the academics protocol people have no clue about the implementation side and the implementation people have no clue about the academic side.
the academics will want something extremely extensible so they write lots of useless research papers, the implementation people will want something that just fixes the flaws in TCP, and the embedded/router people will want something extremely simple so they can do it in a short time budget. now all the bazillion vendors come in wanting to put their own fingerprint smudges on it... if it ever happens, it'll be a monstrosity far worse than TCP.
on second thought, put 'em all in the same room. maybe they'll bludgeon each other to death.
the only way we'll get a good TCP replacement is if an 800lb gorilla has a few good protocol people that understand both the theoritical side and the implementation side. then they force it down everyones' throats. sadly to say, the only 800lb gorilla that could force the issue today would be Microsoft and I'm not convinced they would do it in a way that excludes all uses not benificial to MS.
i live in maryland. during world war 2, there was a threat of the germans landing troops presumably to conduct guerilla warfare around our nation's capitol. the governor of maryland called for all members of hunting lodges, trap and skeet clubs, shooting clubs and all citizens possessing their own firearms to defend the state in case of a foreign invasion.
ergo, I help constitute a "militia". checkmate my fair weather friend.
No other book will ever be the same. GRRM is such a master of weaving complex plot lines, spawning sub plots that turn into major plots before you notice, then deftly merging multiple plot lines back into one. It's one great tapestry of characters. GRRM honestly took the joy out of reading for me. It's like growing up drinking bud, discovering guiness, and finding out there are only three glasses of guiness on the planet with only three more to come. I check GRRM's web page every day hoping he'll announce when I can get my next hit.
you can you tcpdump and ethereal to browse and help analyze the firewall logs generated by OpenBSD's PF.
the scrubber has had the ability to force a ttl from the beginning. 'scrub out all min-ttl 255' will evade this check. but it isn't enough to evade a good passive os fingerprinting algorithm. that is _really_ hard to do. an intermediate device can't easily play with the initial window size or the MSS without destroying the connection. DF, window scaling and tcp option order/nop are safe to play with though.
ummm.. OpenBSD doesn't support MP.
are you really saying that you've run out of space in the code segment? or that the call depth is exceeding the size of the stack?
an aunt optometrist who does lasik, an uncle optometrist who works in the hospital, and another uncle who is a hotshot prof. of optometry. relatives w/ lasik.... zero
;-)
besides. crappy vision is a great excuse for xray specs at the beach
when the four horsemen come riding into your kitchen and the apocalypse is upon us, what one utensil/tool/object will you try to escape with?
;-)
and you can't bribe the horsemen with any good eats. they're not hungry
bugs exist. deal with it. expecting anything less is naive.
to rewriting these in 'safe' languages. thank you very much but no. pushing the responsibity for security off the software author and onto the compiler/virtual machine is not a solution. it just deflects blame. not to mention the performance implications of doing crypto in a virtual machine. blech
CAM tables if you're gluing together your own hardware. kinda like a hash table in hardware that never gets collisions until it is full.
the insertion/deletion maintance isn't free so you gotta be careful with your search/modify ratio.
waaah waaah. quit whining and write your own. a basic malloc/free implementation with hooks to mprotect takes a few hours max to write. POSIX even defines how the faulting address is returned to a signal handler so you can correlate the fault back to the source of the allocation or free. Last I tried, linux's return wasn't POSIX compliant but it was easy to work around with an ifdef.
then extend free to scan the outstanding objects for stale pointers into the object you're freeing and produce run-time warnings.
if you have a memory intensive application, you may need to limit the debugging to selective malloc sizes or only apply the debugging to specific object pools (if you use a pool allocator)
if you're a compentent programmer, it will take you a day to get all the kinks out. if you're not, go use java with all the other retards.
yaya. i fucked up and bought two cases of dew and two cases of coke. then the canadians told me about the caffeine thingy.
but there is a starbucks in the first floor of the hotel
but does it interfere with my microwave? faster net versus no programming food. thats a hard one.
i believe major investment houses and large banks have little black boxes to place on both ends of a T1. they do the crypto, but they also constantly stream random bits if there is no real traffic.
do you care about someone pumping a few amps down the wire and trying to burn out the IO pins on your super-duper computer? in that case it would be prudent to pick up your soldering iron and build a serial relay with electro-optical interconnects.
your best bet may be to just go wireless, run IPSEC and keep lots of random traffic in the background. at least it would take more smarts to create an EM pulse strong enough to attack the electronics.