A few people may register domains for defense reasons, philosophical reasons or because they are gullible. Everyone else including most ISPs will simply ignore them. So while there may be some money to be made this way it will be nowhere near what could be made by running a real TLD.
No ISP is going to be interested in a service that noone really uses (by really use i mean as critial to access there stuff not aliases) and noones going to wan't to really use the names while most ISPs don't support them.
I've not one time experienced a phone outage, not once! then your damn lucky.
the big issue with POTS (and any service that uses POTS wiring such as ISDN and DSL) is if a big multipair gets severed it can take them a LONG time to fix. With mains you have a maximum of 5 connections to make in a severed cable (L1, L2, L3, neutral and earth). With cable TV networks you have to do a coax join. With pots wiring you may have to join HUNDREDS of cores which may not even be color coded depending on the age of the wiring requring engineers to put a test signal on one pair at a time (both from the exchange and from remote distribution points) that can be detected with equipment carried by the repair team.
DSL certainly goes out more than POTS though and at least in the uk its pretty well impossible to do anything about it you just have to wait until it comes back up again. I've no experiance with cable so i can't say if its better or worse.
and in many cases both of these servers are connected to the same piece of ethernet cable so it's not a great stretch of the imagination to imagine them both becoming unreachable
but if the only hosts in that domain are on the same peice of ethernet cable does it really matter if the dns goes down at the same time as the machines it points to?
ultimately you are still relying on the root servers and then whatever servers like in the path to the authoritive server(s) for the name your interested in.
Cached info might buy you some time (which is an advantage to this method over running your own recursive resolver) but its not gauranteed to and your method carries a far higher risk of getting deliberately faked info than running your own dns recursive resolver.
is to strike terror into a population. By doing so they aim to cause far more indirect damage than the direct damage of thier attacks.
Muggers at least normally are mugging people because they wan't money (either directly through cash, through using stolen cards, or by selling other property). Any terror struck into the population is a side effect and in fact may have a negative effect on the muggers primary objective by reducing the number of potential victims.
i remember nokia had issues a while back with counterfiet (they actually said nokia on them apparently) batteries from the third world. However while they looked like nokia batteries they lacked a lot of the protection circuitry and some of them exploded.
mmm LSB isn't that the monumental fuckup where rather than actually fixing the problems (such as retarded dynamic linker behaviour) they force you to statically link anything that they don't standardise.
and iirc to make the deadline for ISO they standardised on some beta version of C++ and then made C++ support an optional part of the standard (that noone implements).
but yeah debian does support installation of rpms by using alien to convert them into debs (which apparently is acceptable to LSB) and has a LSB dummy package to get the system into a LSB compliant state through its dependencies and conflicts (not sure if its installed by default or not) so presumablly ubuntu has it too at least in universe. I don't know if debian has formally passed certification or not though.
yet Ubuntu's package repository != Debian's package repository. well if you count universe then not equal but bloody close (there is a bit of stuff missing because it fails to build on thier autobuilders, including compilers that compile themselves)
Yes ubuntu polish up the most user visible stuff and occasionaly move in a big upgrade before it hits debian unstable but its still very much a second tier distribution working off debian (unlike mandrake which split off completely from red hat).
Expensive component systems that only talk to their own kind hmm the sony tuneramp we bought a couple of years back has standard phono sockets on the back for connecting tape decks CD players etc
and all the sony walkmans i've seen have line out on a 3.5mm jack (which gives better quality than using the headphone socket generally)
and the (admittedly quite old) sony minidisk decks that friends of mine had also used standard line and toslink connections.
true sony does some fake seperates systems at the low end that use some form of ribbon cable to connect the parts but so do other brands.
yeah theres been some more tweaking but overall the same problems still persist. In mustang for example they are planning to "fix" the bytebuffer issue by adding special optimisations for bimorphic classes. but afaict it will still slow to a crawl if unrelated code decides to create its own bytebuffer descendents.
Once code is written i don't expect changing another part of the app to radically effect its performance like that.
And to take one of the articles examples why isn't the vector class marked as deprecated so people know its a performance killer?
Also the pointers issue is way overblown. An array will never point to anything other than the array so thats a non-issue from an optimisers point of view and a pointer can only (legitimately) modify a local variable if a pointer has been taken from that local variable (this is an issue with reference perameters but then java forces you to use objects for those which isn't the pinnicle of efficiancy either).
Java can perform as well as or even better than C provided: 1: The app is fairly long running and/or something else on the system has already brought the VM into disk cache. 2: The C app follows the same stupid design patterns (such as overuse of the allocator) that java forces you into (this is one big issue with comparative benchmarks, the C code seems to have been written by someone who either wasn't bothering about performance or was trying to make the code as close to the java version as possible). 3: The C app doesn't use inline assembler for critical sections or the inline assembler is done badly. 4: The Java app either avoids the standard libraries completely in anything remotely critical or uses only those bits that were written by someone with a clue about performance.
say you find a bug in java, you can fix it for yourself but you can't fix it for your clients.
you have to wait for it to propogate back through sun and if they ignore it you have no recourse.
Also do you remember xfree86? the maintainers became worse and worse pricks eventually cumulating in a license change that was generally found unacceptable (most notablly it would have created licensing issues with linking GPL apps with xlibs). It was forked from a point before the license change and development quickly got going again with little loss. The fresh leadership has also lead to a radial sanitisation of the source tree that wouldn't have been feasible before.
Now suppose the same thing happened with java, noone else can take over maintainership because of licensing issues, so we would stuck with either continuing to redistribute old binaries in which we can't fix or update anything (Which is ok in the medium term but very bad in the long term, i386 and even amd64 WILL NOT be dominent forever!) or doing a complete rewrite (which is happening anyway because of distro politics but is far easier said than done).
Forking is the long term lifeblood of true opensource software allowing the software to outlive its authors interest (whether personal or commercial) in it. It also allows experimental features to be developed on a fork (and later possiblly reintegrates).
Ever since Chris Rijk published his earth shattering [aceshardware.com] benchmarks. lets take a look at his results then.
in the non infinite life ones the best C result beats the best java result every time.
In the infinite life one C does a lot worse.
In the fibonachi numbers test java clearly wins.
In the fft test the results are all over the place.
So the answer is for tight number crunching work java and C are comparable. For retarded use of reccursion (the fibbonachi test) java clearly wins.
For memory allocation java is by default better than C (especially GCC) BUT a good coder has far more chance to optimise in C. I bet if "set = (int*)malloc(4*sizeof(int));" was replaced by a custom cache of fixed size blocks things would speed up big time. In java every object gets its own block on the heap and theres nothing you can do about it. It gets even worse if you wan't an array of structures (i didn't notice any of theese in his tests) as java forces you to put every element of the array in a seperate block on the heap.
He also didn't make much use of the standard libraries many of which suck, though they are admittedly getting better nowadays. There are also a lot of gotchas from the way the JVM optimises (for example the performance of direct bytebuffers will plummet if non direct bytebuffers are used in the same VM).
So to summerise: In terms of actual execution of code its a toss up, In terms of memory allocation it depends if the coder can be bothered to optimise. In terms of standard libraries its pretty damn poor and in terms of startup time its barely acceptable especially the first time you start a java app after boot. I'd say java loses in the overall performace stakes even though its certainly possible to make benchmarks that it wins.
but if they did fiber to the curb properly you'd have a very fast copper link to the breakout unit (from what i can gather its perfectly feasible to make 100mbit utp links that work over several hundred meters of cable)
and ofc its always possible to put a DSLAM at the breakout point.
I agree though the fact the companies never did this makes a joke out of the whole thing.
bandwidth itself is cheap A high bandwidth link from one side of a building to another is extremely cheap. A high bandwidth link from one side of a city to another is more expensive but not insanely so. A high bandwidth international or worse intercontinental link is not cheap.
data transfer is what costs no data transfer is what they charge low end customers for because for such bursty users its the most reasonable way to account for who should pay what share of the providers bandwidth costs. Higher end customers tend to pay by thier 95th percentile bandwidth.
I have a supposedly 100mbit ethernet connection (gets to 100mbit at times, but realistically is approx 50mbit) from a room very near the amsix, which is costing me the equivalent of $60, including 1u rackspace and 50gb transfer/month.
I also have a supposedly 100mbit ethernet connection from a building near there, which also gets the full 100 mbit, and costs around $120 including 4u rackspace and 20gb traffic (and 24/7 access and some other stuff)
And how much would those links have cost you without the traffic cap?
Sure you can get fast real links cheap if you only utilise them lightly and either pay by the gigabyte or hit some other kind of punishment (e.g disconnection, rate cap or traffic shaping) if you try to use them heavilly. This is the model that home ISPs will probablly have to shift to either openly or not so openly (through "fair use policies" etc).
The problem is that ISPs like to advertise unlimited on home connections but there is no way they can afford to support a significant ammount of thier users actually using it, especially if the customers are using it for intercontinental (in country they can just pass it over a local exchange point and in continent they only have to route it accross land/shallow sea to reach the destination) traffic and the ISP isn't in the US (iirc generally people outside the US pay to get thier data to/from the US not vice versa).
phone service: 64kbit unmetered to people within a relatively small area. broadband internet service: usually at least several times that and often more unmetered to anywhere in the word.
that passenger airliner doors were designed to be virtually impossible to open if the cabin is at a higher pressure than the outside air (as it is in flight).
Slashdot Mirror
A few people may register domains for defense reasons, philosophical reasons or because they are gullible. Everyone else including most ISPs will simply ignore them. So while there may be some money to be made this way it will be nowhere near what could be made by running a real TLD.
No ISP is going to be interested in a service that noone really uses (by really use i mean as critial to access there stuff not aliases) and noones going to wan't to really use the names while most ISPs don't support them.
I've not one time experienced a phone outage, not once!
then your damn lucky.
the big issue with POTS (and any service that uses POTS wiring such as ISDN and DSL) is if a big multipair gets severed it can take them a LONG time to fix. With mains you have a maximum of 5 connections to make in a severed cable (L1, L2, L3, neutral and earth). With cable TV networks you have to do a coax join. With pots wiring you may have to join HUNDREDS of cores which may not even be color coded depending on the age of the wiring requring engineers to put a test signal on one pair at a time (both from the exchange and from remote distribution points) that can be detected with equipment carried by the repair team.
DSL certainly goes out more than POTS though and at least in the uk its pretty well impossible to do anything about it you just have to wait until it comes back up again. I've no experiance with cable so i can't say if its better or worse.
and in many cases both of these servers are connected to the same piece of ethernet cable so it's not a great stretch of the imagination to imagine them both becoming unreachable
but if the only hosts in that domain are on the same peice of ethernet cable does it really matter if the dns goes down at the same time as the machines it points to?
ultimately you are still relying on the root servers and then whatever servers like in the path to the authoritive server(s) for the name your interested in.
Cached info might buy you some time (which is an advantage to this method over running your own recursive resolver) but its not gauranteed to and your method carries a far higher risk of getting deliberately faked info than running your own dns recursive resolver.
is to strike terror into a population. By doing so they aim to cause far more indirect damage than the direct damage of thier attacks.
Muggers at least normally are mugging people because they wan't money (either directly through cash, through using stolen cards, or by selling other property). Any terror struck into the population is a side effect and in fact may have a negative effect on the muggers primary objective by reducing the number of potential victims.
isn't 911 supposed to have dedicated rescources allocated to stop just that issue?
The result is that we pay a huge premium for the name brand or one of the few aftermarket versions, or go through hell refilling them.
anyone tried one of theese "continuous ink flow system" kits that feeds the printer directly from big bottles of ink?
i remember nokia had issues a while back with counterfiet (they actually said nokia on them apparently) batteries from the third world. However while they looked like nokia batteries they lacked a lot of the protection circuitry and some of them exploded.
mmm LSB isn't that the monumental fuckup where rather than actually fixing the problems (such as retarded dynamic linker behaviour) they force you to statically link anything that they don't standardise.
and iirc to make the deadline for ISO they standardised on some beta version of C++ and then made C++ support an optional part of the standard (that noone implements).
but yeah debian does support installation of rpms by using alien to convert them into debs (which apparently is acceptable to LSB) and has a LSB dummy package to get the system into a LSB compliant state through its dependencies and conflicts (not sure if its installed by default or not) so presumablly ubuntu has it too at least in universe. I don't know if debian has formally passed certification or not though.
iirc alcohol was made a special case in a constitutional ammendment to end prohibtion and make sure it never returned.
dunno about tobacco though.
well assuming that they make good on thier 5 years of support promise for dapper i'd say it'll have been a very good choice.
imo once a server is initially set up unless requirements change the most important thing is a long period of support with minimal changes.
Holy cow. Get some fucking perspective. Get outside, at least.
someone wrote a very convincing essay a while back on why its more benificial to society to give the death penalty to spammers than to murderers.
but for some reason many people think that taking up many man-lifetimes of other peoples lives is less serious than killing one person.
yet Ubuntu's package repository != Debian's package repository.
well if you count universe then not equal but bloody close (there is a bit of stuff missing because it fails to build on thier autobuilders, including compilers that compile themselves)
Yes ubuntu polish up the most user visible stuff and occasionaly move in a big upgrade before it hits debian unstable but its still very much a second tier distribution working off debian (unlike mandrake which split off completely from red hat).
that debian announce sun java is now in thier non-free repositry thanks to suns new license for OS distributors.
btw any idea if the Wii will support vga output like the gamecube did?
Expensive component systems that only talk to their own kind
hmm the sony tuneramp we bought a couple of years back has standard phono sockets on the back for connecting tape decks CD players etc
and all the sony walkmans i've seen have line out on a 3.5mm jack (which gives better quality than using the headphone socket generally)
and the (admittedly quite old) sony minidisk decks that friends of mine had also used standard line and toslink connections.
true sony does some fake seperates systems at the low end that use some form of ribbon cable to connect the parts but so do other brands.
yeah theres been some more tweaking but overall the same problems still persist. In mustang for example they are planning to "fix" the bytebuffer issue by adding special optimisations for bimorphic classes. but afaict it will still slow to a crawl if unrelated code decides to create its own bytebuffer descendents.
Once code is written i don't expect changing another part of the app to radically effect its performance like that.
And to take one of the articles examples why isn't the vector class marked as deprecated so people know its a performance killer?
Also the pointers issue is way overblown. An array will never point to anything other than the array so thats a non-issue from an optimisers point of view and a pointer can only (legitimately) modify a local variable if a pointer has been taken from that local variable (this is an issue with reference perameters but then java forces you to use objects for those which isn't the pinnicle of efficiancy either).
Java can perform as well as or even better than C provided:
1: The app is fairly long running and/or something else on the system has already brought the VM into disk cache.
2: The C app follows the same stupid design patterns (such as overuse of the allocator) that java forces you into (this is one big issue with comparative benchmarks, the C code seems to have been written by someone who either wasn't bothering about performance or was trying to make the code as close to the java version as possible).
3: The C app doesn't use inline assembler for critical sections or the inline assembler is done badly.
4: The Java app either avoids the standard libraries completely in anything remotely critical or uses only those bits that were written by someone with a clue about performance.
say you find a bug in java, you can fix it for yourself but you can't fix it for your clients.
you have to wait for it to propogate back through sun and if they ignore it you have no recourse.
Also do you remember xfree86? the maintainers became worse and worse pricks eventually cumulating in a license change that was generally found unacceptable (most notablly it would have created licensing issues with linking GPL apps with xlibs). It was forked from a point before the license change and development quickly got going again with little loss. The fresh leadership has also lead to a radial sanitisation of the source tree that wouldn't have been feasible before.
Now suppose the same thing happened with java, noone else can take over maintainership because of licensing issues, so we would stuck with either continuing to redistribute old binaries in which we can't fix or update anything (Which is ok in the medium term but very bad in the long term, i386 and even amd64 WILL NOT be dominent forever!) or doing a complete rewrite (which is happening anyway because of distro politics but is far easier said than done).
Forking is the long term lifeblood of true opensource software allowing the software to outlive its authors interest (whether personal or commercial) in it. It also allows experimental features to be developed on a fork (and later possiblly reintegrates).
Ever since Chris Rijk published his earth shattering [aceshardware.com] benchmarks.
lets take a look at his results then.
in the non infinite life ones the best C result beats the best java result every time.
In the infinite life one C does a lot worse.
In the fibonachi numbers test java clearly wins.
In the fft test the results are all over the place.
So the answer is for tight number crunching work java and C are comparable. For retarded use of reccursion (the fibbonachi test) java clearly wins.
For memory allocation java is by default better than C (especially GCC) BUT a good coder has far more chance to optimise in C. I bet if "set = (int*)malloc(4*sizeof(int));" was replaced by a custom cache of fixed size blocks things would speed up big time. In java every object gets its own block on the heap and theres nothing you can do about it. It gets even worse if you wan't an array of structures (i didn't notice any of theese in his tests) as java forces you to put every element of the array in a seperate block on the heap.
He also didn't make much use of the standard libraries many of which suck, though they are admittedly getting better nowadays. There are also a lot of gotchas from the way the JVM optimises (for example the performance of direct bytebuffers will plummet if non direct bytebuffers are used in the same VM).
So to summerise: In terms of actual execution of code its a toss up, In terms of memory allocation it depends if the coder can be bothered to optimise. In terms of standard libraries its pretty damn poor and in terms of startup time its barely acceptable especially the first time you start a java app after boot. I'd say java loses in the overall performace stakes even though its certainly possible to make benchmarks that it wins.
but if they did fiber to the curb properly you'd have a very fast copper link to the breakout unit (from what i can gather its perfectly feasible to make 100mbit utp links that work over several hundred meters of cable)
and ofc its always possible to put a DSLAM at the breakout point.
I agree though the fact the companies never did this makes a joke out of the whole thing.
Some major ISPs at least here in the uk do either use a proxy by default in thier client setup or use forced proxying.
As for linux distros they are mostly mirrored in the uk anyway so our ISPs can just push the data over a peering point which is cheap.
Are there many popular free and 100% legal (e.g. not fanfiction or pirate japaneese anime) TV shows yet?
bandwidth itself is cheap
A high bandwidth link from one side of a building to another is extremely cheap. A high bandwidth link from one side of a city to another is more expensive but not insanely so.
A high bandwidth international or worse intercontinental link is not cheap.
data transfer is what costs
no data transfer is what they charge low end customers for because for such bursty users its the most reasonable way to account for who should pay what share of the providers bandwidth costs. Higher end customers tend to pay by thier 95th percentile bandwidth.
I have a supposedly 100mbit ethernet connection (gets to 100mbit at times, but realistically is approx 50mbit) from a room very near the amsix, which is costing me the equivalent of $60, including 1u rackspace and 50gb transfer/month.
I also have a supposedly 100mbit ethernet connection from a building near there, which also gets the full 100 mbit, and costs around $120 including 4u rackspace and 20gb traffic (and 24/7 access and some other stuff)
And how much would those links have cost you without the traffic cap?
Sure you can get fast real links cheap if you only utilise them lightly and either pay by the gigabyte or hit some other kind of punishment (e.g disconnection, rate cap or traffic shaping) if you try to use them heavilly. This is the model that home ISPs will probablly have to shift to either openly or not so openly (through "fair use policies" etc).
The problem is that ISPs like to advertise unlimited on home connections but there is no way they can afford to support a significant ammount of thier users actually using it, especially if the customers are using it for intercontinental (in country they can just pass it over a local exchange point and in continent they only have to route it accross land/shallow sea to reach the destination) traffic and the ISP isn't in the US (iirc generally people outside the US pay to get thier data to/from the US not vice versa).
Doesn't that only apply to local phone service.
phone service: 64kbit unmetered to people within a relatively small area.
broadband internet service: usually at least several times that and often more unmetered to anywhere in the word.
that passenger airliner doors were designed to be virtually impossible to open if the cabin is at a higher pressure than the outside air (as it is in flight).