agreed also if you say wan't a web based admin interface to a daemon app then things like cgi aren't really the kind of interface you want, you are going to have to write the cgis as seperate apps then connect them to your main daemon somehow.
whereas if you code the web server yourself you can just build it into your daemon and access the daemons transiant data through direct procedure/method calls or even direct reading of global variables or fields.
and provided you don't care about things like chunked encoding or keep alive http/1.1 is pretty simple to make a basic implmentation of too (though the spec is horrible)
ICANN was resposible for letting network soloutions (who were bought by verisign) have control in the first place and either not writing the contacts well enough or being to wussy and therefore not kicking verisign out of of managing.com and.net immediately for pulling that shit.
to block an individual.fr domain they would need control of the authoritive servers for fr which are almost certainly in france.
they could point the whole of.fr at new nameservers and have those nameservers make requests to the real.fr nameservers and filter them but that would be easilly noticed and would take a day or so to take full effect.
so yes they could but doing so would be basically suicidal. the european isps would almost certainly move to alternate roots extremely quickly if the us decided to pull something like this. They could go even further and set up servers at the network borders so even dns servers still set to use the old roots would get the new ones.
What about that study that said it was more benificial to society to give spammers the death penalty than murderers! Doesn't that reasoning apply here too.
2: or give up on dynamic ips so you have fixed addresses on every machine then go to every machine, configure the software to work with a different port then go an create a huge heap of mappings?
3: deploy an application level gateway or a nat that partially understands the application level protocol (e.g. most nats understand active mode ftp) but unless the protocol in question is very well known its likely to need a full pc as the edge box and may not be availible for the protocol you are interested in.
iirc over here in the uk BT can't remove the last payphone from a location without some form of govenment (not sure if its local authority or central goverment) permission.
payphones here aren't that bad for long calls sometimes better even than some landline tarrifs but they sting you with a 30p minimum charge
the problem is as long as sun java remains the standard others will always be behind.
if most java developers are on the sun jdk then they will produce apps that avoid falling foul of the bugs in the sun jre but don't nessacerally avoid the bugs in other jres. The apps may even end up relying on bugs in the sun jre.
its basically the same as windows apps on wine, the app developers avoid falling foul of the bugs in windows. but unless they test on wine they are likely to fall foul of its bugs.
to get decent performance it is often required for a client machine to know more than its user should know. Worse it may even be able to cause a hit if local hitscan passes to prevent lag from ruining hits (usually within some limits such as the shot adjusted by the server to hit still being feasible).
hence the only security left is through difficulty of reverse engineering the client to produce a cheat versions. It isn't good security but its a comprimise made because fast responsive games are more important than stopping the hardcore cheaters.
but one important thing to watch out for: if any of the devices connect to each other you might wan't to do some testing with a multimeter before blindly plugging them into the same PSU (or two seperate earth referenced psus) then you don't wan't to short out a large psu via devices ground lines.
i also seem to remember the gcj team saying you couldn't do much optimisation at the compile to bytecode stage because doing so would make the bytecode fail the verifier.
out of interest how much do such services cost compared to freephone numbers (0800 in the uk 1800 in the US +800 internationally etc) and normal outgoing calls.
generally the problem is abi compatibility tends to be one-way, you can run apps built on an older system on a newer one without too many problems. the other way though you are most likely going to fail.
debians soloution to this is basically a combination of forced upgrades (when a package is built afaict it is automaticially made to depend on the versions of libs that were on the build system) and building stuff seperately on every version of the distro.
cardbus is pci based afaict and you've been able to hotswap that since the win95 days and possiblly before. so hotswapping isn't really a new thing its just not generally seen in desktops (with the exception for the newish usb and firewire for external devices) because noone thinks there is any point.
the figure of 16 billion billion i gave was based on the the assumptions that each customer would get at least a/64 (you can get a/48 without too much trouble) if they use MAC based autoconfig then the probability of a hit is slightly higher but still pretty damn low (the number of possible addresses on one subnet with MAC based autoconfiguration would be many orders of magniture less than the total number of IPv4 addresses un existance).
true thats a far cry from every update though like seems to be the case on windows and from the description in the summary it doesn't seem like ms will be eliminating every reboot either.
also it IS possible to patch a running linux kernel. if the functionality is as a module then its easy just unload the old and reload the new, if the functionality is not as a module then it may still be possible to write a module that patches it (i belive someone did this for the brk exploit that happened a while back).
but to be honest if a few minuites downtime every time there is a kernel patch (and only for kernel patches and nothing else) is a problem for you then you probablly should have redundant systems anyway.
They have, to date, largely ignored them simply due to the cost to users of old client software who would then have to upgrade iirc there was a time when aim was finding a way to break trillian daily and trillian were fixing it just as fast.
msn went through some periods of fighting with the third party clients for a while too and there was at least one point where yahoo was unavailible in trillian for an extended period.
and then some time (i think it was a year or so but my memory is a bit fuzzy) ago they all seemed to give up.
Slashdot Mirror
agreed also if you say wan't a web based admin interface to a daemon app then things like cgi aren't really the kind of interface you want, you are going to have to write the cgis as seperate apps then connect them to your main daemon somehow.
whereas if you code the web server yourself you can just build it into your daemon and access the daemons transiant data through direct procedure/method calls or even direct reading of global variables or fields.
and provided you don't care about things like chunked encoding or keep alive http/1.1 is pretty simple to make a basic implmentation of too (though the spec is horrible)
select and poll are fine for moderate load its only when you get into thousands of simultainous connections that they start to become an issue.
verisign was responsible for doing it.
.com and .net immediately for pulling that shit.
ICANN was resposible for letting network soloutions (who were bought by verisign) have control in the first place and either not writing the contacts well enough or being to wussy and therefore not kicking verisign out of of managing
to block an individual .fr domain they would need control of the authoritive servers for fr which are almost certainly in france.
.fr at new nameservers and have those nameservers make requests to the real .fr nameservers and filter them but that would be easilly noticed and would take a day or so to take full effect.
they could point the whole of
so yes they could but doing so would be basically suicidal. the european isps would almost certainly move to alternate roots extremely quickly if the us decided to pull something like this. They could go even further and set up servers at the network borders so even dns servers still set to use the old roots would get the new ones.
iirc only the larger LPG bottles are generally refillable the smaller ones (used by single burner gas stoves etc) are generally disposable.
What about that study that said it was more benificial to society to give spammers the death penalty than murderers! Doesn't that reasoning apply here too.
which is easier?
1: unlock port x incoming to all machines?
2: or give up on dynamic ips so you have fixed addresses on every machine then go to every machine, configure the software to work with a different port then go an create a huge heap of mappings?
3: deploy an application level gateway or a nat that partially understands the application level protocol (e.g. most nats understand active mode ftp) but unless the protocol in question is very well known its likely to need a full pc as the edge box and may not be availible for the protocol you are interested in.
iirc over here in the uk BT can't remove the last payphone from a location without some form of govenment (not sure if its local authority or central goverment) permission.
payphones here aren't that bad for long calls sometimes better even than some landline tarrifs but they sting you with a 30p minimum charge
http://en.wikipedia.org/wiki/Autogyro
the problem is as long as sun java remains the standard others will always be behind.
if most java developers are on the sun jdk then they will produce apps that avoid falling foul of the bugs in the sun jre but don't nessacerally avoid the bugs in other jres. The apps may even end up relying on bugs in the sun jre.
its basically the same as windows apps on wine, the app developers avoid falling foul of the bugs in windows. but unless they test on wine they are likely to fall foul of its bugs.
yeah it can be trivially decompiled though iirc.
to get decent performance it is often required for a client machine to know more than its user should know. Worse it may even be able to cause a hit if local hitscan passes to prevent lag from ruining hits (usually within some limits such as the shot adjusted by the server to hit still being feasible).
hence the only security left is through difficulty of reverse engineering the client to produce a cheat versions. It isn't good security but its a comprimise made because fast responsive games are more important than stopping the hardcore cheaters.
oh and watch the current ratings on the negative rails
the +5 and the +12 rails would give you 7V the +5 and -5 10V the +5 and -12 or +12 and -5 17V and the +12 and -12 24V
but when doing theese tricks you have to be even more carefull if you wan't to connect any devices togeher
and 3.3V if its an ATX unit
but one important thing to watch out for: if any of the devices connect to each other you might wan't to do some testing with a multimeter before blindly plugging them into the same PSU (or two seperate earth referenced psus) then you don't wan't to short out a large psu via devices ground lines.
i also seem to remember the gcj team saying you couldn't do much optimisation at the compile to bytecode stage because doing so would make the bytecode fail the verifier.
out of interest how much do such services cost compared to freephone numbers (0800 in the uk 1800 in the US +800 internationally etc) and normal outgoing calls.
generally the problem is abi compatibility tends to be one-way, you can run apps built on an older system on a newer one without too many problems. the other way though you are most likely going to fail.
debians soloution to this is basically a combination of forced upgrades (when a package is built afaict it is automaticially made to depend on the versions of libs that were on the build system) and building stuff seperately on every version of the distro.
cardbus is pci based afaict and you've been able to hotswap that since the win95 days and possiblly before. so hotswapping isn't really a new thing its just not generally seen in desktops (with the exception for the newish usb and firewire for external devices) because noone thinks there is any point.
then the struct shared by b and c should be considered part of a cross binary interface.
thats a bloody good reason to keep security updates as minimal as possible!
if a security upgrade changes a cross binary interface then your release management sucks.
afaict claria/gator is distributed by agents for commission. i wouldn't be at all surprised if some of those agents resort to using browser bugs.
the figure of 16 billion billion i gave was based on the the assumptions that each customer would get at least a /64 (you can get a /48 without too much trouble) if they use MAC based autoconfig then the probability of a hit is slightly higher but still pretty damn low (the number of possible addresses on one subnet with MAC based autoconfiguration would be many orders of magniture less than the total number of IPv4 addresses un existance).
true thats a far cry from every update though like seems to be the case on windows and from the description in the summary it doesn't seem like ms will be eliminating every reboot either.
also it IS possible to patch a running linux kernel. if the functionality is as a module then its easy just unload the old and reload the new, if the functionality is not as a module then it may still be possible to write a module that patches it (i belive someone did this for the brk exploit that happened a while back).
but to be honest if a few minuites downtime every time there is a kernel patch (and only for kernel patches and nothing else) is a problem for you then you probablly should have redundant systems anyway.
They have, to date, largely ignored them simply due to the cost to users of old client software who would then have to upgrade
iirc there was a time when aim was finding a way to break trillian daily and trillian were fixing it just as fast.
msn went through some periods of fighting with the third party clients for a while too and there was at least one point where yahoo was unavailible in trillian for an extended period.
and then some time (i think it was a year or so but my memory is a bit fuzzy) ago they all seemed to give up.