The problem with having incredibly fast last mile is that you need incredibly, incredibly fast upstream connectivity. For a stub system (i.e. a system which won't allow transit across itself,) the usual figures quoted are 16:1 contention; that is, sum(CPE bandwidth)/16.
For a transit system (a system which provides connectivity between other systems/networks,) peering bandwidth should not exceed intra-system bandwidth, but also needs to be great enough that systems who use you as a transit network actually do wind up getting the fastest path, as BGP has no concept of 'speed' as a metric.
Given that this idea is proposing to deploy fibre at (i would assume) at least 10Mb to the home, the upstream bandwidth will almost certainly need to be in the gigabits for this to be useful. Transit infrastructure will likely also need to be upgraded if too many smaller ISPs start rolling this out.
I don't think the networking infrastructure we have necessarily has the capacity right now. Perhaps when DWDM becomes more commonplace, with each run of Single mode carrying 100s of gigabits, but for now I think it's really only a pipe dream.
Another idea worth considering is the 'script kiddie terrorist' argument. If you give uncapped 10Mb access to every script kiddie on your block, you'll need to make sure that everything else scales proportionally, or script kiddie targets will suffer an exponentially worse fate.
The whole reason that provider-based IP space is advocated over each multi-homing customer obtaining their own space off the RIR is because of the mess of really long prefixes that the latter causes in BGP.
Advertising part of a larger allocation is frowned upon, as it causes the same problem. Additionally, the majority of tier 1 providers in the US (and, I presume, elsewhere) will not pass on the advertisement of anything longer than about a/19, with exceptions in their filters for the majority of/24s and/23s allocated by the old registries in the days before the 4 RIRs (192...., parts of 203, etc.)
Additionally, if you advertise part of an ISP's TLA to another provider, and the ISP who owns the block hasn't put a hole in their aggregation filter, ALL your traffic will flow through the second ISP (the one who doesn't own the block.) This is due to longest-match routing, where the most specific match wins. Routers will have entries for, say, 203.94.128.0/19 (aggregate from the ISP,) and 203.94.156.0/23 ('your' network which is being advertised through the OTHER ISP.) the/23 will always win because it's more specific.
For those wondering what the hell 6to4 is when it's at home, here's a brief explanation.
the/16 prefix 0x2002:: is reserved for 6to4 tunnelling (so it's not something that IANA is going to reclaim any time soon, any more than they're going to reclaim 172.16/12...). A 6to4 TLA is 48 bits in length, and comprises 2002:(your gateway IPv4 address in hex.) For instance, the 6to4 prefix at work, when I was playing with it, was 2002:CB53:9C82: (as the IP I was using was 203.94.156.130.)
For those unfamiliar with how IPv6 addressing works, under a/48, you have a network space the size of a/16, each of which is its own/64. ie, under 2002:CB53:9C82::, the subnets would be 2002:CB53:9C82::/64 through 2002:CB53:9C82:FFFF/64.
Each subnet can host up to a/48 of machines, the other half of the address is the Layer 2 address of the endpoint machine passed through an algorithm to convert it to 64 bits in length (forget the RFC which specifies this.)
The advantage of this setup is that ingress traffic doesn't need to pass through a series of tunnelled networks, as the endpoint address is encoded in the prefix.
Outbound traffic still passes through a gateway of some nature, which will then figure out how to dispatch the traffic (eg it could be connected to the 6bone, some native 6nets, or the destination address could be another 6to4 address.)
FreeBSD has a good 6to4 implementation called stf(4). I recommend checking it out if you're curious:)
Damn! Does that mean I'll need to pay royalties to the Mexican government every time I sit on my porch wearing one of those stupid hats, drinking Tequila and strumming the ukulele?
It's possible, under any system, to get used to 'the one true way.' Windows makes it easier by obfuscating what's going on under the hood. Unix (at least any half-decent Unix implementation) doesn't do this.
On most systems (with Windows being the notable exception, pre-X Mac was also a culprit), you get a reasonable idea of what's going on, and are able to think about the problem, as opposed to merely the solution.
I remember the first time I was exposed to it, the client told me that they had a 'unix box' which I was expected to get our JSP servlets running on (the brain-dead java people had configured the application so it would only talk to the database if it was running on the same machine as the jvm.)
Turns out the 'unix box' was an HP3000 running MPE and the associated POSIX subsystem. Everything was cool except that MPE's POSIX subsystem didn't support native threads, which for some godforsaken reason was a prerequisite of the java code (don't know how code running in a VM could tell between 'native' and 'green' threads, but it broke on green threads for some reason.)
I'll agree with the submitter that mainframes are mind-numbing and evil, but not due to their repetitive nature as others have stated. They're just plain unintuitive and dumb. This goes for MPE, AS/400 (and larger systems) running VM (which is an incredibly competent piece of work, just don't try and use it from a pure unix background without at least a week's worth of dedicated study,) and other systems.
Don't even get me started on SNA. All the evils of TCP, running over a layer 2 protocol (LLC2) with all the evils of TCP.
Reading the commentary literally, I have no issues with their contention whatsoever.
Reading between the lines, doesn't it sound like more subtle versions of what Microsoft has been saying about the GPL the whole time?
Why even mention software development models unless they're trying to cast aspersions on the Open Source model?
Why even mention the poor abused software developers who 'choose to license their intellectual property on commercial terms'?
Someone has a beef, and it's neither the procurement departments nor the open source people. Last time I checked, the open source guys were so disorganized they couldn't organize a piss up in a brewery, let alone lobby procuring departments.
Face it. This is subtle MS FUD. Very subtle MS FUD.
Something tells me to doubt that the no-direct-slams bit is more them being afraid of the negative spin than actually not doing it because they're nice, rad people.
The other thing that bothers me is that by being subtly evil, they're potentially doing more damage than they would do by being blatantly evil.
The Initiative for Software Choice seems like a whitewash organization backed by Microsoft.
It seems to me that every time it becomes politic to get somewhat more relaxed towards Microsoft, lest you draw mocking cries of 'Linux zealot! Stallman Fanboy!' that Microsoft turn around and prove to everyone just how justified the ire against them is.
Here are a few choice quotes:
"Policymakers should not make rigid intellectual property licensing choices a precondition for eligibility for procurement, nor should they discriminate between developers that choose to license their intellectual property on commercial terms, and developers that choose not to charge licensing fees...."
"Lately, concerns have emerged that policy makers, through government procurement policies, research funding or standards policies, may seek to favor one software development model over another."
I won't bother with any more.
The scary thing about this organization is that their party line appears to be quite subtle. Where they fail is that they appear to be up in arms about purchasing regimes which haven't happened yet.
They also use their contentions to subtly dig at the GPL... 'rigid intellectual property licensing' indeed. I wonder if anybody at the Initiative for Software Choice has ever tried to install Windows 2000 in Application Server mode. THAT is 'rigid licensing' at its best.
Ah. The reductio argument. You're making the logical fallacy of assuming that because premises A, A' and A'' are linked, they are necessarily either all true or all false.
It's obviously not such a great idea to let your daughter sleep with the overweight, balding, sweaty 46 year old bloke down the road, ugly questions of sexual power and maniuplation get raised as he is, by definition, likely around 30 years more mature than she.
However, you sound as though you would restrict your daughter's right to have sex with the 16 year old bloke she took to the prom. Where's the harm in that? Or does she suddenly become mature enough to make these decisions herself when she turns 21? Like a light switch?
How could these users be conned by Cable Con? Everyone knows that Cable Con just makes the cables... 'Iron' Jimmy and 'Brother' Nunzio do all the hard work like conning people, and breaking their kneecaps... Jeez, people.
Surprised if Cable Con doesn't sue slashdot for slander.
How much does your 2Mbps line cost per month? If you're buying a leased data circuit off Joe Telco, you could probably save a packet by getting a couple of 2-wire SDSL devices and running them back to back. I've had great results doing this over a 'private line' from Telstra (in Australia.)
Only problem I've run into is that the line drivers in the devices (Siemens, formerly Efficient, formerly Cabletron, formerly Flowpoint LLC Flowpoint 2200s) are designed to be used in CPE equipment, and although they can be used as a CO device, they produce a lot more heat in this configuration for some reason (probably a combination of crap power supply and extra RMS load on the DC rails.)
The combination costs me about $A30/end/month for about a four-and-a-half kilometre circuit as the cable runs (about 3 real kilometres.)
In my state (Victoria,) a 'freeway' is a dual carriageway with at least 2 lanes in each direction, designated on/offramps, no tolls, and certain other mod cons. A tollway is the same thing with the tolls.
'highway' can meet one of 4 classifications, 'M' class (basically a freeway, but there's allowed to be a certain number of traffic lights, roundabouts, and intersecting roads,) 'A' class (minimum of 1 lane each way, overtaking lanes every X kilometres,) 'B' class ('A' class without the overtaking lane restriction,) and 'C' class (a shit road from point A to point B.)
Sounds logical so far.
Go to Sydney (capital of another Australian state.) There are 'Freeways','Motorways' (both of which are essentially the same thing,) and 'Tollways.' As far as I can tell, a motorway may be either a freeway or a tollway, but each route only ever gets one of the 3 designations.
Brisbane (capital of Queensland) has yet another weird system, using the terms 'motorway' and 'expressway' (nfi about the difference.) There also used to be a 'freeway' between (I think, been a while since I've been there) Wacol Prison and near Indooropilly (big shopping precinct.)
Yeah, as is the symbol relocation information, specifications about the way system calls work, the dynamic linker, etc etc.
Binary format itself is, for the most part, the most interesting part of the ABI. If I can convince my kernel to parse binary format X, I can load it into a context, and perform syscall translation on it (a-la Linux on FreeBSD.) Often wondered why this isn't the approach used by Wine -- the Wine guys perform some kind of weirdo user-space LDT mangling to acheive the same results, when in reality this sort of stuff belongs in the kernel.
I don't think that the magic of the service is in the 'nuts and bolts,' what goes on under the hood, but the perception and mindshare that successful marketing of a simple concept creates.
If i'm prepared to pay, or have ads shoved down my throat, in order to gain access to a large userbase (all of whom have been sucked in by the same concept,) then it's gonzo marketing at its best.
Ultimately, though, there does have to be some infrastructure present for this sort of application to work. The model is more 'napster' than 'gnutella.'
I find it ironic, though, that Steve Case and his minions are getting rich off 'hello, a/s/l sweetheart' messages and other such shit.
An ABI is literally the format used by binaries on a given platform.
This includes things like dynamic linker functionality, symbol naming conventions, calling conventions, etc.
ABI consistency, in theory, guarantees binary compatability. When GLIBC 2.1 came out, it was backwards compatible with apps linked with GLIBC 2.0 by using a symbol naming hack to guarantee ABI consistency.
for instance, the C++ ABI is constantly changing between releases of GCC (up to 3, at least.) This has to do with symbol naming (how member function names get translated into symbol names, among other thing) and this almost inevitably breaks binary compatibility between a lib compiled with one GCC and an app compiled with another.
That's probably the best example I can give you....
An idea i've toyed with seriously on my semi-production personal network (2 sites with 1.5/256 DSL and a 2.3 megabit SHDSL over a PAPL between them) was to set up some kind of transaction-journalled network aware filesystem between the two sites, run over the PAPL.
Essentially, you have a poor man's Snapshot-style setup running over a link which is more than capable of handling it (assuming your AVERAGE transfer rate to whatever servers your doing this with is 2.320 Mb/sec), and if one site burns down... voila. All your data is rad.
Best thing about this idea is you don't need to screw around storing tapes or disks offsite, because they're already there, online and accessible. You'd still backup to tape as a secondary measure, probably once a fortnight or so.
This would also make it rad doing cool things like equal priority MX across the 2 sites. Haven't found the right software for the job yet... Anyone here know of anything? I looked at OpenGFS but that was more for a SAN type environment.
This is correct in the case of small networks multi-homing with larger networks. Specifically, the 'upstream' peers (in the 'you pay them' sense) are ordinarily locked down to the point where you have to advise them BEFORE you add any additional prefixes to your BGP session with them, or they'll be silently dropped and you'll wonder why.
In the case of larger networks peering with a route server at a peering facility, this could be an issue. Considering the dynamic nature of the TLAs being advertised, the tier 1 (and to an extent tier 2) providers have to trust each other more or less implicitly. However, in the case of eBGP sessions at an IX, most everyone is only peering with one peer, the 'route server', and this box is likely to be about as locked down as they come.
CIDR provides a further saving grace - in order to cause mass chaos, one would have to advertise a prefix shorter than one already being advertised. Since most large providers in the states and elsewhere filter out almost everything shorter than a full TLA (/19) (there are exceptions to this, mostly concerning pre-1998 assigned class C nets), the best you could do is blackhole a random subset of traffic to a given block.
That said, considering the fact that 99.99% of the world's tier 1/2 BGP servers are run by competent admins who stand to lose their jobs and become gardeners or trash-os if their BGP routers get compromised and wreak the sort of havoc alluded to in this article, one can reasonably assume that they're secure. Additionally, (I know APnic does this, not sure about other RIRs,) the netblocks assigned for IXs are usually/24 or longer, and aren't allowed to be advertised to the internet at large, so generally the really INTERESTING routers aren't reachable anyways.
I had a rad diagram here except the 'lameness' filter whacked it.
In an IX scenario, anyhow, all the routers speaking eBGP (as well as the route server) will be on unreachable IP addresses. The closest 'accessible' routers will likely be route reflectors peering via iBGP with both the eBGP 'peering' routers (unreachable) and the eBGP 'customer-side' routers (reachable, untrusted.)
So, to cut a short story long, this article is hype:)
writable media does NOT have any flags which are accessible via standard read calls (ie on anything other than a burner) which indicates whether it's a burned copy or not. The PMA/ATIP area on a CD-R does have information regarding the kind of dye used on the disc, etc, but this is only accessible via CD-R(w) specific commands which you can't rely (as a copy protection manufacturer) on drives supporting.
Admittedly, DVD[+-]R(w) media DOES have no provision for burning to the keyspace, but I would doubt that that's accessible from userland either.
The way that PS(2) copy protection worked was to fudge the data in one of the subchannels which burners (to this day) can't burn to for some obscure reason. The problem with this scheme is that subchannel data is designed for things such as non-block-accurate positioning (think red book audio, accurate to within 75 sectors,) CD+text, etc, and was never designed to be reliably readable. The data in subchannels isn't reliably addressable or error corrected, which lead to a lot of borked PS discs which would (funnily enough) still play with a modchip....
ns1.isonews.com and ns2.isonews.com resolve to 140.101.1.3 and.1.6 respectively.
whois 140.101.1.3@whois.arin.net returns NetName: USDOJ amongst other things.
I suspect that whichever DNS server you're looking at hasn't expired www.isonews.com from its cache yet (presumably it had a fairly long TTL set on it.)
Additionally, does the DOJ realise how stupid it is to have two DNS servers on the same physical subnet? It's possible that they're both on their own discrete/30 subnets, but they're still behind the same border router (at the very least) due to TLA length rules enforced across the internet backbone.
If I was the DOJ, i'd seriously consider hiring some semi-intelligent contractors to overhaul their network. And maybe hire some web designers with a clue - that 'ownz0red' page was written in netscape 4.79.
prior to windows 2000 (or NT4 if you can handle PPPoE), there's no easy way to set up tunnels. Win2k and XP can do IPSec tunnel mode, and L2TP/IPSec; either of these are fairly rad and play nicely with free software at the other end.
There's a whole bunch of links floating around the shop with details, most of them are linked from freeswan.org.
easy. assuming that you're sharing root keys between two boxes (not smart, and there's more elegant ways to do it, but this should give you the general idea.)
Slashdot Mirror
The problem with having incredibly fast last mile is that you need incredibly, incredibly fast upstream connectivity. For a stub system (i.e. a system which won't allow transit across itself,) the usual figures quoted are 16:1 contention; that is, sum(CPE bandwidth)/16.
For a transit system (a system which provides connectivity between other systems/networks,) peering bandwidth should not exceed intra-system bandwidth, but also needs to be great enough that systems who use you as a transit network actually do wind up getting the fastest path, as BGP has no concept of 'speed' as a metric.
Given that this idea is proposing to deploy fibre at (i would assume) at least 10Mb to the home, the upstream bandwidth will almost certainly need to be in the gigabits for this to be useful. Transit infrastructure will likely also need to be upgraded if too many smaller ISPs start rolling this out.
I don't think the networking infrastructure we have necessarily has the capacity right now. Perhaps when DWDM becomes more commonplace, with each run of Single mode carrying 100s of gigabits, but for now I think it's really only a pipe dream.
Another idea worth considering is the 'script kiddie terrorist' argument. If you give uncapped 10Mb access to every script kiddie on your block, you'll need to make sure that everything else scales proportionally, or script kiddie targets will suffer an exponentially worse fate.
What you are suggesting here is a very bad idea.
/19, with exceptions in their filters for the majority of /24s and /23s allocated by the old registries in the days before the 4 RIRs (192...., parts of 203, etc.)
/23 will always win because it's more specific.
The whole reason that provider-based IP space is advocated over each multi-homing customer obtaining their own space off the RIR is because of the mess of really long prefixes that the latter causes in BGP.
Advertising part of a larger allocation is frowned upon, as it causes the same problem. Additionally, the majority of tier 1 providers in the US (and, I presume, elsewhere) will not pass on the advertisement of anything longer than about a
Additionally, if you advertise part of an ISP's TLA to another provider, and the ISP who owns the block hasn't put a hole in their aggregation filter, ALL your traffic will flow through the second ISP (the one who doesn't own the block.) This is due to longest-match routing, where the most specific match wins. Routers will have entries for, say, 203.94.128.0/19 (aggregate from the ISP,) and 203.94.156.0/23 ('your' network which is being advertised through the OTHER ISP.) the
For those wondering what the hell 6to4 is when it's at home, here's a brief explanation.
/16 prefix 0x2002:: is reserved for 6to4 tunnelling (so it's not something that IANA is going to reclaim any time soon, any more than they're going to reclaim 172.16/12...). A 6to4 TLA is 48 bits in length, and comprises 2002:(your gateway IPv4 address in hex.) For instance, the 6to4 prefix at work, when I was playing with it, was 2002:CB53:9C82: (as the IP I was using was 203.94.156.130.)
/48, you have a network space the size of a /16, each of which is its own /64. ie, under 2002:CB53:9C82::, the subnets would be 2002:CB53:9C82::/64 through 2002:CB53:9C82:FFFF/64.
/48 of machines, the other half of the address is the Layer 2 address of the endpoint machine passed through an algorithm to convert it to 64 bits in length (forget the RFC which specifies this.)
:)
the
For those unfamiliar with how IPv6 addressing works, under a
Each subnet can host up to a
The advantage of this setup is that ingress traffic doesn't need to pass through a series of tunnelled networks, as the endpoint address is encoded in the prefix.
Outbound traffic still passes through a gateway of some nature, which will then figure out how to dispatch the traffic (eg it could be connected to the 6bone, some native 6nets, or the destination address could be another 6to4 address.)
FreeBSD has a good 6to4 implementation called stf(4). I recommend checking it out if you're curious
Damn! Does that mean I'll need to pay royalties to the Mexican government every time I sit on my porch wearing one of those stupid hats, drinking Tequila and strumming the ukulele?
What a shame.
Starring Bobcat Goldthwaite, a movie about a talking horse called Don who is good at playing the stock market.
http://us.imdb.com/Title?0095326
I'll take issue with that statement...
It's possible, under any system, to get used to 'the one true way.' Windows makes it easier by obfuscating what's going on under the hood. Unix (at least any half-decent Unix implementation) doesn't do this.
On most systems (with Windows being the notable exception, pre-X Mac was also a culprit), you get a reasonable idea of what's going on, and are able to think about the problem, as opposed to merely the solution.
MPE is an interesting operating system.
I remember the first time I was exposed to it, the client told me that they had a 'unix box' which I was expected to get our JSP servlets running on (the brain-dead java people had configured the application so it would only talk to the database if it was running on the same machine as the jvm.)
Turns out the 'unix box' was an HP3000 running MPE and the associated POSIX subsystem. Everything was cool except that MPE's POSIX subsystem didn't support native threads, which for some godforsaken reason was a prerequisite of the java code (don't know how code running in a VM could tell between 'native' and 'green' threads, but it broke on green threads for some reason.)
I'll agree with the submitter that mainframes are mind-numbing and evil, but not due to their repetitive nature as others have stated. They're just plain unintuitive and dumb. This goes for MPE, AS/400 (and larger systems) running VM (which is an incredibly competent piece of work, just don't try and use it from a pure unix background without at least a week's worth of dedicated study,) and other systems.
Don't even get me started on SNA. All the evils of TCP, running over a layer 2 protocol (LLC2) with all the evils of TCP.
Yuck.
Reading the commentary literally, I have no issues with their contention whatsoever.
Reading between the lines, doesn't it sound like more subtle versions of what Microsoft has been saying about the GPL the whole time?
Why even mention software development models unless they're trying to cast aspersions on the Open Source model?
Why even mention the poor abused software developers who 'choose to license their intellectual property on commercial terms'?
Someone has a beef, and it's neither the procurement departments nor the open source people. Last time I checked, the open source guys were so disorganized they couldn't organize a piss up in a brewery, let alone lobby procuring departments.
Face it. This is subtle MS FUD. Very subtle MS FUD.
Something tells me to doubt that the no-direct-slams bit is more them being afraid of the negative spin than actually not doing it because they're nice, rad people.
The other thing that bothers me is that by being subtly evil, they're potentially doing more damage than they would do by being blatantly evil.
The Initiative for Software Choice seems like a whitewash organization backed by Microsoft.
It seems to me that every time it becomes politic to get somewhat more relaxed towards Microsoft, lest you draw mocking cries of 'Linux zealot! Stallman Fanboy!' that Microsoft turn around and prove to everyone just how justified the ire against them is.
Here are a few choice quotes:
"Policymakers should not make rigid intellectual property licensing choices a precondition for eligibility for procurement, nor should they discriminate between developers that choose to license their intellectual property on commercial terms, and developers that choose not to charge licensing fees...."
"Lately, concerns have emerged that policy makers, through government procurement policies, research funding or standards policies, may seek to favor one software development model over another."
I won't bother with any more.
The scary thing about this organization is that their party line appears to be quite subtle. Where they fail is that they appear to be up in arms about purchasing regimes which haven't happened yet.
They also use their contentions to subtly dig at the GPL... 'rigid intellectual property licensing' indeed. I wonder if anybody at the Initiative for Software Choice has ever tried to install Windows 2000 in Application Server mode. THAT is 'rigid licensing' at its best.
MH
Ah. The reductio argument. You're making the logical fallacy of assuming that because premises A, A' and A'' are linked, they are necessarily either all true or all false.
It's obviously not such a great idea to let your daughter sleep with the overweight, balding, sweaty 46 year old bloke down the road, ugly questions of sexual power and maniuplation get raised as he is, by definition, likely around 30 years more mature than she.
However, you sound as though you would restrict your daughter's right to have sex with the 16 year old bloke she took to the prom. Where's the harm in that? Or does she suddenly become mature enough to make these decisions herself when she turns 21? Like a light switch?
How could these users be conned by Cable Con? Everyone knows that Cable Con just makes the cables... 'Iron' Jimmy and 'Brother' Nunzio do all the hard work like conning people, and breaking their kneecaps... Jeez, people.
Surprised if Cable Con doesn't sue slashdot for slander.
Yes, but you then lose the opportunity to use RFC1149 encapsulated datagrams as a backup service for during the migration season.
How much does your 2Mbps line cost per month? If you're buying a leased data circuit off Joe Telco, you could probably save a packet by getting a couple of 2-wire SDSL devices and running them back to back. I've had great results doing this over a 'private line' from Telstra (in Australia.)
Only problem I've run into is that the line drivers in the devices (Siemens, formerly Efficient, formerly Cabletron, formerly Flowpoint LLC Flowpoint 2200s) are designed to be used in CPE equipment, and although they can be used as a CO device, they produce a lot more heat in this configuration for some reason (probably a combination of crap power supply and extra RMS load on the DC rails.)
The combination costs me about $A30/end/month for about a four-and-a-half kilometre circuit as the cable runs (about 3 real kilometres.)
Offtopic somewhat, but...
It's even stranger in Australia.
In my state (Victoria,) a 'freeway' is a dual carriageway with at least 2 lanes in each direction, designated on/offramps, no tolls, and certain other mod cons. A tollway is the same thing with the tolls.
'highway' can meet one of 4 classifications, 'M' class (basically a freeway, but there's allowed to be a certain number of traffic lights, roundabouts, and intersecting roads,) 'A' class (minimum of 1 lane each way, overtaking lanes every X kilometres,) 'B' class ('A' class without the overtaking lane restriction,) and 'C' class (a shit road from point A to point B.)
Sounds logical so far.
Go to Sydney (capital of another Australian state.) There are 'Freeways','Motorways' (both of which are essentially the same thing,) and 'Tollways.' As far as I can tell, a motorway may be either a freeway or a tollway, but each route only ever gets one of the 3 designations.
Brisbane (capital of Queensland) has yet another weird system, using the terms 'motorway' and 'expressway' (nfi about the difference.) There also used to be a 'freeway' between (I think, been a while since I've been there) Wacol Prison and near Indooropilly (big shopping precinct.)
Yeah, as is the symbol relocation information, specifications about the way system calls work, the dynamic linker, etc etc.
Binary format itself is, for the most part, the most interesting part of the ABI. If I can convince my kernel to parse binary format X, I can load it into a context, and perform syscall translation on it (a-la Linux on FreeBSD.) Often wondered why this isn't the approach used by Wine -- the Wine guys perform some kind of weirdo user-space LDT mangling to acheive the same results, when in reality this sort of stuff belongs in the kernel.
I don't think that the magic of the service is in the 'nuts and bolts,' what goes on under the hood, but the perception and mindshare that successful marketing of a simple concept creates.
If i'm prepared to pay, or have ads shoved down my throat, in order to gain access to a large userbase (all of whom have been sucked in by the same concept,) then it's gonzo marketing at its best.
Ultimately, though, there does have to be some infrastructure present for this sort of application to work. The model is more 'napster' than 'gnutella.'
I find it ironic, though, that Steve Case and his minions are getting rich off 'hello, a/s/l sweetheart' messages and other such shit.
An ABI is literally the format used by binaries on a given platform.
This includes things like dynamic linker functionality, symbol naming conventions, calling conventions, etc.
ABI consistency, in theory, guarantees binary compatability. When GLIBC 2.1 came out, it was backwards compatible with apps linked with GLIBC 2.0 by using a symbol naming hack to guarantee ABI consistency.
for instance, the C++ ABI is constantly changing between releases of GCC (up to 3, at least.) This has to do with symbol naming (how member function names get translated into symbol names, among other thing) and this almost inevitably breaks binary compatibility between a lib compiled with one GCC and an app compiled with another.
That's probably the best example I can give you....
Peace,
MH
An idea i've toyed with seriously on my semi-production personal network (2 sites with 1.5/256 DSL and a 2.3 megabit SHDSL over a PAPL between them) was to set up some kind of transaction-journalled network aware filesystem between the two sites, run over the PAPL.
Essentially, you have a poor man's Snapshot-style setup running over a link which is more than capable of handling it (assuming your AVERAGE transfer rate to whatever servers your doing this with is 2.320 Mb/sec), and if one site burns down... voila. All your data is rad.
Best thing about this idea is you don't need to screw around storing tapes or disks offsite, because they're already there, online and accessible. You'd still backup to tape as a secondary measure, probably once a fortnight or so.
This would also make it rad doing cool things like equal priority MX across the 2 sites. Haven't found the right software for the job yet... Anyone here know of anything? I looked at OpenGFS but that was more for a SAN type environment.
oops. yes. :P
sorry
i meant 'longer'
Aye.
/24 or longer, and aren't allowed to be advertised to the internet at large, so generally the really INTERESTING routers aren't reachable anyways.
:)
This is correct in the case of small networks multi-homing with larger networks. Specifically, the 'upstream' peers (in the 'you pay them' sense) are ordinarily locked down to the point where you have to advise them BEFORE you add any additional prefixes to your BGP session with them, or they'll be silently dropped and you'll wonder why.
In the case of larger networks peering with a route server at a peering facility, this could be an issue. Considering the dynamic nature of the TLAs being advertised, the tier 1 (and to an extent tier 2) providers have to trust each other more or less implicitly. However, in the case of eBGP sessions at an IX, most everyone is only peering with one peer, the 'route server', and this box is likely to be about as locked down as they come.
CIDR provides a further saving grace - in order to cause mass chaos, one would have to advertise a prefix shorter than one already being advertised. Since most large providers in the states and elsewhere filter out almost everything shorter than a full TLA (/19) (there are exceptions to this, mostly concerning pre-1998 assigned class C nets), the best you could do is blackhole a random subset of traffic to a given block.
That said, considering the fact that 99.99% of the world's tier 1/2 BGP servers are run by competent admins who stand to lose their jobs and become gardeners or trash-os if their BGP routers get compromised and wreak the sort of havoc alluded to in this article, one can reasonably assume that they're secure. Additionally, (I know APnic does this, not sure about other RIRs,) the netblocks assigned for IXs are usually
I had a rad diagram here except the 'lameness' filter whacked it.
In an IX scenario, anyhow, all the routers speaking eBGP (as well as the route server) will be on unreachable IP addresses. The closest 'accessible' routers will likely be route reflectors peering via iBGP with both the eBGP 'peering' routers (unreachable) and the eBGP 'customer-side' routers (reachable, untrusted.)
So, to cut a short story long, this article is hype
Cheers,
MH
Sorry, but this is plain wrong.
writable media does NOT have any flags which are accessible via standard read calls (ie on anything other than a burner) which indicates whether it's a burned copy or not. The PMA/ATIP area on a CD-R does have information regarding the kind of dye used on the disc, etc, but this is only accessible via CD-R(w) specific commands which you can't rely (as a copy protection manufacturer) on drives supporting.
Admittedly, DVD[+-]R(w) media DOES have no provision for burning to the keyspace, but I would doubt that that's accessible from userland either.
The way that PS(2) copy protection worked was to fudge the data in one of the subchannels which burners (to this day) can't burn to for some obscure reason. The problem with this scheme is that subchannel data is designed for things such as non-block-accurate positioning (think red book audio, accurate to within 75 sectors,) CD+text, etc, and was never designed to be reliably readable. The data in subchannels isn't reliably addressable or error corrected, which lead to a lot of borked PS discs which would (funnily enough) still play with a modchip....
Peace,
MH
ns1.isonews.com and ns2.isonews.com resolve to 140.101.1.3 and .1.6 respectively.
/30 subnets, but they're still behind the same border router (at the very least) due to TLA length rules enforced across the internet backbone.
whois 140.101.1.3@whois.arin.net returns
NetName: USDOJ
amongst other things.
I suspect that whichever DNS server you're looking at hasn't expired www.isonews.com from its cache yet (presumably it had a fairly long TTL set on it.)
Additionally, does the DOJ realise how stupid it is to have two DNS servers on the same physical subnet? It's possible that they're both on their own discrete
If I was the DOJ, i'd seriously consider hiring some semi-intelligent contractors to overhaul their network. And maybe hire some web designers with a clue - that 'ownz0red' page was written in netscape 4.79.
MH.
whoops... i misread that as well.... erk.
prior to windows 2000 (or NT4 if you can handle PPPoE), there's no easy way to set up tunnels. Win2k and XP can do IPSec tunnel mode, and L2TP/IPSec; either of these are fairly rad and play nicely with free software at the other end.
There's a whole bunch of links floating around the shop with details, most of them are linked from freeswan.org.
easy. assuming that you're sharing root keys between two boxes (not smart, and there's more elegant ways to do it, but this should give you the general idea.)
on one box (the trusted box:)
pppd pty 'ssh -t trusting.host.net pppd noipdefault noauth' trusted.box.ip:trusting.box.ip
the -t is important, or pppd on the remote end will choke.