I agree with your sentiments about local Fosters; it's shite. VB is likewise shite, however; most of the people I know drink either Boags or Cascade, as it is plentiful and relatively cheap (3 bucks odd for a pot, about 5 for a stubbie, bar prices.)
Apparently export fosters is quite good. I'll have to go to america one day just to try it.
I've barbequeued prawns before, the result is not worth the expense. I have no idea how prawns are meant to be cooked, but barbequeueing em just made black, crispy, carcinogenous prawns that tasted like arse.
007 Agent Under Fire contains an exploit in the save-game loading routine which can lead to a local-root compromise on your X-box with a specially corrupted save game file.
This can be used, for example, to boot Linux, or flash the BIOS.
The reason that this didn't win Mike Robertson's 100 large is because you still need to rip the lid off the box and solder a pair of jumpers (or use conductive pen) in order to enable 'write' on the flash rom.
it's a base64-encoded binary file. Base64 is a way of encoding 8 bit data into 7-bit clean text so that it can be passed through systems which aren't 8-bit clean, such as some older mailers.
Obviously, base64 increases filesize by at least 1/7.
it can be argued that every idea exists in every conceivable form irrespective of a person implementing it independently. The basic form of this argument contends that since an idea can be conceived independently by multiple entities, that the idea itself exists irrespective of whether it has been conceived.
There are basic laws of physics and chemistry which govern, to an extreme degree, any invention which can be conceived. In the intellectual domain, there are less strictures, but the subset of all possible ideas is significantly less than infinite.
Telstra do the same thing in Oz. There's a Telstra ATM network with DSLAMs on one end of it and ISPs (including Bigpond) on the other.
Telstra did a stupid thing, however, in that the PPPoE/A connections from the CPEs are routed to an L2TP LAC in their main exchange in each city and then sent to an LNS at each ISP. This means that every single PPP/L2TP call has to run through this LAC, causing mucho problemo for all concerned, including (ironically) bigpond.
The even stupider thing is that Telstra DSL's main competitor, Request DSL, appears to do the same thing.
The way I would have done it is to have the DSLAMs expose themselves as ATM switches, connect all the ISPs to ATM switches at the other end (this bit is how it is at the moment anyhow) and get the CPE to initiate an ATM SVC to the ISP based on its NSAP address (really long string of hex digits, kind of like an ATM phone number.) Of course, since most ADSL CPE gear doesn't support SVCs (the cisco 800 series is one exception that I know about, there may be others,) statically configured PVCs on each DSLAM would have worked just as well, and allowed ISPs to run whatever higher layer protocols they wanted, instead of forcing them to use PPP.
Mostly due to incumbents abuse of copper monopoly, ADSL has sucked more or less everywhere.
I gotta say, that C: How to program book was the most useful collection of dead trees i've encountered in this life or any other... I picked the thing up at the end of '98 as I was shopping for Uni books, and went from practically no C programming knowledge (although I had done a lot of asm programming on 8 bit platforms many years earlier) to being able to code reasonably competently in the space of maybe five days.
I credit this book with giving me the ability to show up half an hour before the end of a 3 hour prac class, drunk, and get 100%. Those were the days (reminisces.....)
You speak of 'ACL' as if it was some kind of 'thing' which mysteriously makes 'other things' better. You also seem to have absolutely no idea how any of the products you're recommending over the generic crappy 200 buck NAT devices (which, by the way, actually do suck. but not for the reasons you're suggesting.)
A Cisco 2610 is not only on the virge of planned obsolecence (at the very least, Cisco is advising that you buy the 2620 instead, as it has a 100 megabit ethernet port, as opposed to the 10 megabit port on the 2610), but will not do stateful filtering. ACLs on Cisco (or most other) pure l3 routers will not keep state in the same way that OpenBSD's PF, IPF from FreeBSD, etc will. They're simply designed to drop certain traffic based on policy. If you want things to work properly under TCP, you have to allow EVERY packet that has ACK & !SYN set back in the other direction.
I suggest next time, before you go off your banana at someone for not having as much of a 'clue' as you do about 'ACL', or anything else for that matter, that you attempt to thoroughly familiarize yourself with the subject matter at hand first, otherwise you look like a half-cocked moron.
I'm not sure about the SEC in America, but over here (Oz,) ASIC would spend significant time and resources tracking Pump'n'dump spammers because they're an over-funded government body with not a hell of a lot else to do apart from sue and arrest people (www.asic.gov.au).
Now, as far as sending out untracable emails; sure, there's no motive to indisputably link a real world entity with the spammer, as you quite correctly said that it could have been any of the shareholders (or contractors thereto) who sent the message.
You'll always be able to trace a spam back to an IP address, though, more or less. A few scenarios:
o Open relay is used, with forged headers. Forged headers are almost invariably insubtle and easy to determine. For instance:
Received: from open.relay.net (spambag.relay.net [192.168.0.1]) by smtp.victim.com for uid 1001 (date) Received: from dialup.spambag.net dialup.spambag.net [192.168.10.10]) by open.relay.net (8.11.2/8.11.4) id f00 (date) (fake received headers follow)
It's usually fairly easy to trace the spam back to an originator, and from there to a real person (based on the co-operation of the ISP; most ISPs in Australia would co-operate with ASIC, especially post One-Tel/One-Net)
o Formmail.pl or equivalent is used: the victim's mail server or the webserver's smarthost will show a connection from the webserver's IP. Subpoena the web logs. If needed, subpoena the spammer's proxy logs (if the HTTP connection came therefrom.)
o An open socks proxy is used (these usually don't leave a mark in the header, in fact, most of the time you're unlikely to know that spam has been forwarded from such.) Fortunately, most spammers aren't this subtle, and open proxies have a habit of disappearing overnight when people realise what they've done. A visit from the securities cops will usually bring this to people's attention:)
Maybe he should pay a few mil to a dentist in danger money to get his teeth removed and have a new set fitted.:P
I don't begrudge him his shrine, but I can't see how it's like some big lifetime dream... There are plenty of things that are more rad which would perpetuate SF is all i'm saying.
Isn't it weird all the stuff rich guys do with their money?
I mean, If i'd made billions of bucks from starting a software concern in the early eighties, I PROBABLY wouldn't be starting a shrine to science fiction.
Don't get me wrong, I love SF as much as the next geek (and constantly have to upgrade my bookshelves,) but.... a shrine? That's a little macabre.
The guy should do something worthwhile with his bucks, like sponsor literary awards for young SF authors to help ensure the genre doesn't stagnate. Or donate a few hundred mil to Seti.
First one I picked up was DOA, turned it on, the SYS OK light flashed for a couple seconds, then quit.
Sent the PSU back to the bloke in Sydney I bought it off and he sent me a revision 5 (OEM revision 4) PSU, rated at 550 (i think) watts. Worked fine (the 32550Ws are a gen-1 7200RPM drive and draw a stack of power.) When I upgraded to the 9G drives (a motley crue found on ebay for about AU40 apiece) they actually didn't get as hot or draw anything like as much power.
The second SSA had this PS to begin with (well, when I got it, anyway.)
The weird thing is that the molded plastic on the PSs is a darker grey than the rest of the SSA assembly. Heavy fucks, too...
Not bad, half a terabyte of fibre storage for around 2500 AUs all up:)
I have two SSA1010s upgraded to 9 gig disks, with 30 in each chassis, for around 522 gig of storage in two raid 5 arrays. Most of this is 256k MP3s and SHN recordings.
The majority of this wasn't downloaded, but encoded using parallel bladeenc (www.mpi.nd.edu/~jsquyres/bladeenc/) from various sources, my own CD collection for the most part.
Sad thing is, when I upgraded the SSAs from the 32550WC drives they came with (2.1G disks) to the hodge-podge of 9G drives that I spent a couple ebay-weeks collecting, I figured my storage woes were over.
I was recently assigned a/29 from my DSL ISP at home. Since the whole thing runs on NAT, this gives me 8 IPs not 6, since NAT ranges have no concept of 'broadcast' or 'network' addresses (which only have link-local significance, and there's no link.)
Unfortunately, the/29 fell at the top of the/24 in question (202.59.108.248/29.) This means that 202.59.108.255 is one of the IPs which are being routed to my network. Cool, right?
Wrong. Having configured static NAT between that IP address and a machine on the inside of the network (172.18.16.24, case in point,) the machine was reachable from Unix and Linux machines, but not from Windows boxes.
Further testing reveals that Windows still uses classful logic to determine whether an IP is 'valid' or not. On attempting to ping 202.59.108.255 from a slew of windows 2000 boxes, tcpdump showed nothing on the other end. An identical test from a unix box showed that it worked just fine.
Surely you mean 32 class Cs? (where 24-19=5, and 2^5=32.)
There are large parts of 203 (203/10 if memory serves,) all of 192 except for the RFC 1918 bits, and several other blocks which most backbone networks will accept up as up to a/24.
I have NFI about Arin, being Australian, but APnic (the same thing for these parts) has several provisions for getting large blocks of IPs without too much justification ('new service' applications etc.)
I believe that most registries also allocate the bottom/20 of a/19 and allow you to advertise it as a/19, provided you can justify up to a/20.
I realise this is probably flamebait, but I'll bite.
Calling Windows the 'standard' for Operating Systems is similar to calling McDonalds the 'standard' for food.
Sure, it's the 'standard' for fast food, whatever that may be, in much the same way that windows is the standard for desktop systems, but Windows has far less server market share than everything else out there put together.
I'm not saying it doesn't have the single largest percentage of installed machines, merely that it's not the 'standard' and doesn't even have a clear majority on the back end.
You're most likely getting less latency on your ISDN than people do on their various *DSLs because of the crap way that almost every ILEC implements the CMUX->3rd party ISP transition.
ISDN's theoretical minimum SRTT is ~30ms (15ms end to end.) This will vary based on your distance from the switch, and the router you're calling's distance from its switch, and the number of switches in the middle. Remember, ISDN is circuit switched, so once you've established a Q.931 call you 'own' that 64 kilobits of bandwidth until you hang it up. There's no contention (unless the router at the other end is being hammered by something and its CPU is peaking, but that's not a physical constraint.)
DSL is usually sold by LECs to ISPs in the form of an ATM circuit that plugs into an L2TP LNS (concentrator.) A PPPoE/PPPoA connection is then established between the subscriber and the LEC's DSLAM, which then, acting as an LAC (l2tp client) forwards the circuit through the ATM network into the ISP's LNS.
The issue here is analogous, but not identical, to the 'engaged signal' problem which dial ISPs had (and still have.) You only purchase so much capacity from your LEC. When the subscriber:capacity ration exceeds 1:1, you will inevitably get contention. In the circuit-switched world of dial, this results in busy signals. In the cell-switched DSL/ATM world, this results in contention for backhaul bandwidth, which causes an increase in ping times. In theory (assuming zero contention,) any DSL will be much faster than ISDN.
I'll give you some (real world) examples. On my home, majorly oversubscribed, ADSL line (which is currently unladen,) a traceroute yields this:
traceroute to 203.24.47.212 (203.24.47.212), 30 hops max, 38 byte packets
1 172.18.0.254 0.548 ms 0.231 ms 0.225 ms
2 202.59.108.248 1.092 ms 0.754 ms 6.590 ms
3 202.59.104.1 51.111 ms 41.659 ms 89.890 ms
The first 2 hops are the internal and external firewalls, respectively (yes, I am sad.) The third hop is the LNS at my ISP who shall remain nameless but is easily identifiable with a whois @whois.apnic.net.
The 2 megabit SDSL connection I've got at work, into our own equipment (I work at a small company who owns its own SDSL infrastructure, essentially a LEC in their own right,) the traceroute yields this.
traceroute to 203.24.47.212 (203.24.47.212), 30 hops max, 40 byte packets
1 203.x.y.1 0.805 ms 0.856 ms 0.705 ms
2 203.x.z.1 1.577 ms 1.298 ms 1.184 ms
3 10.144.0.13 2.583 ms 2.682 ms 2.084 ms
4 203.x.a.97 3.097 ms 1.989 ms 2.064 ms
Where, again, 203.x.y.1 (I don't plan to identify where I work in this post, because that path is fraught with danger) is the switch which separates the engineering subnet from management, wireless, and phone (which is almost invariably at 85% utilisation due to the broadcast nature of 3com NBXes). 203.x.z.1 is the SDSL router (a flowpoint 2200 if you're interested), and 10.144.0.13 is the DSLAM. There is no backhaul ATM network in this scenario because we don't have resellers.
Finally, off a friend's ISDN connection:
traceroute to 203.89.25.72 (203.89.25.72), 30 hops max, 40 byte packets
1 203.13.113.105 0.996 ms 0.855 ms 0.870 ms
2 203.13.114.255 30.416 ms 31.422 ms 30.518 ms
This network is less complex. 203.13.114.255 is the ISDN router at the ISP end. The link is unused at the moment as he's in the process of transitioning everything to an ADSL connection (oh, the irony.)
The reason your pings go to shit in a game is because you're trying to stuff too much data down your 64k line, and the buffer in your modem/router is filling up. As this happens, it takes extra time for each packet to get from the end of the queue to the start thereof. Your pings go to crap and you get kicked off the server.
Bandwidth and latency have an interesting relationship.
IDSL is an interesting case. IDSL is broadband. ISDN isn't.
How is this so? The various DSLs work by what is essentially an RF process, in the same way that cable modems, television channels, etc. do.
The opposite of broadband, baseband, is represented by things like 10BaseT (note the word 'base') and refers to a non-modulated signal.
As an aside, there was an early cable modem standard known as 10Broad36, from memory, which was 10 megabits with (I think) a 36 or 3.6GHz carrier signal. That's what the 'base' in 10BaseX, 100BaseX and 1000Base-XX means.
So, it's technically possible to have a really slow (IDSL) broadband connection, yet have a really fast (1000Base-ZX, good for up to 70KM over 1510nm single mode fibre) baseband connection.
Although, with the introduction of (D)WDM-style multiplexing, where several fibres can be modulated over one piece of fibre, the WDM part of the backhaul would still technically be broadband, as the various wavelengths are multiplexed onto one really clean piece of single-mode fibre at many slightly (I think they vary by about 100MHz in either direction, and the standard units are good for about 1.6GHz variance) different wavelengths.
Broadband is a meaningless term, although these days it appears to have been redefined to mean 'anything faster than 64k or so', in much the same way that hacker now means 'evil computer guy in a black hat and an Anthrax t-shirt.'
Disclaimer: i'm a network engineer, not an EE, so I've been deliberately vague about exactly how RF modulation and such actually work.
I'm not for the life of me saying that an 802.11-like protocol won't do the job. I'm merely contending that 802.11 in its current state won't.
You wouldn't plug your brand new 120GB WD Special Edition into a second-generation ISA IDE card, either (well, not and expect it to move more than about 2MB/sec.)
Handoff between base-stations would require one of two things in order to work:
a. the 802.11 infrastructure was all bridged, possibly with some interesting VLAN setups (although this would largely be useless, as you don't win anything by VLAN'ing on a shared network)
b. device advertises its address as a 32-bit prefix to each base station it encounters, which then redistributes this into the network's IGP. This would not scale very well either.
An ATM-based wireless protocol would sort out these issues as your IP connection would be an SVC (most likely) which could be handed between switches via PNNI. If convergence comes, it will be from this direction.
Wireless ATM would be a really rad usage of ATM, too. Phone calls and data calls would all be configured as SVCs to very interesting NSAP addresses, and the base stations would have to have full ATM switching logic (possibly with MPLS built in) in order to cope.
802.11 as next-generation cell? Unlikely. The contention arbitration mechanisms aren't there, and the protocol was never designed to be used over a distance of greater than about 500 metres.
People like Karlnet (with TurboCell) have tried to push this envelope, largely unsuccessfully. A company I was involved with (who shall remain nameless, as I still own some of their stock) tried to push these technologies as 'long distance wireless multipoint technology' and it plain sucked at it. Square peg, round hole.
Comparing 802.11(a,b,g, or even TurboCell) with 2.5G/WCDMA/GSM/whatever is like comparing shared 10 megabit ethernet with a DS1. The latter has fixed timeslots to avoid two, three, or 30 devices contending for the available bandwidth. Each device is allocated a section of spectrum (bandwidth in the case of a DS1.) 802.3 has CSMA/CD which guarantees that all devices can continue speaking in the presence of collisions. 802.11 uses an even more perverse scheme referred to as CSMA/CA (collision AVOIDANCE,) which avoids collisions in the unlikely event that all nodes can see each other.
Incidentally (I will get to the point eventually, I promise,) cell works by dividing the available spectrum into timeslots, much as a DS1 does. The three most common division mechanisms are FDMA (frequency multiplexing, in which case every device gets its own unique, but very small, section of spectrum), TDMA (timeslot multiplexing, in which all devices contend for the same spectrum, but the timing guarantees each device uses a given slot,) and CDMA (code-based multiplexing, i'm honestly not sure how this works. Qualcomm own a patent on much of it, paid for by the American taxpayer.)
Since each device is guaranteed, deterministically, not to step on the toes of any other device, the devices don't have to be able to see each other in order to avoid major contention issues.
Now, back to 802.11 and CSMA/CA. The CSMA/CA algorithm guarantees that a given device won't hog the spectrum when it can hear other devices contending for it. If you move some of these devices such that they can't hear each other, the theory has it (which is why you have a wireless net running in infrastructure mode with a base station) that the base station will repeat communications from one node to the others. However, node A won't have any way of knowing that node B is after some spectrum, and vice versa. End result, the node which is closer (think physics and speed of light) will get the lion's share of the bandwidth.
Based on these assumptions, as well as the fact that 802.11 operates in spectrum used by microwave ovens, obscure military devices (the UNI/I 5.8 gig band,) and some satellite stuff (sideband interference 100MHz up the scale), 802.11 will never replace a properly thought out deterministic voice-grade protocol.
Exploits like this, which appears to be a relatively trivial buffer overflow, manage to exist for 8 YEARS in a piece of incredibly popular open source software?
What ever happened to many eyes auditing the code? Not to say that the Samba team is doing a bad job, I run several Samba servers at home for various reasons, and they're damn rad. But I can't understand why this bug wasn't caught by somebody auditing the code.
I can only speak for myself, but I'd much prefer the Samba team to pore over the code looking for more bugs like this, than adding catch-up-with-the-gateses features like NT Domain Controller support which are largely irrelevant. The Unix philosophy is to do one thing, and do it well, and Samba already does this. If we want central authentication, we have a host of packages we can already choose from.
Not to deny the Samba team's work at all. I'll have to remember to send in my Pizza vouchers;)
I can think of a lot of places which offer exactly the set of advantages you comment on here. America is not the only country with good roads. Nor is it the only country with clean running water, gas, and electricity.
As you admitted yourself, there are many places with better health care.
Now, America DOES have the largest standing military in the world, more or less, and the largest defence industry. I'm not exactly sure that's something to be proud of, considering the problems that this has caused recently (viz., "Operation Iraqi Freedom," and the many indirect links to Israelis in Palestine and the West Bank.)
You name me one advantage which life in America has over life in, say, Australia, Canada, Japan, New Zealand, England or even friggin France.
The only advantage of America's which used to be bandied about was 'Freedom' (note the capital F and the 's.) This is increasingly under fire from fascist groups such as the RIAA. This, I think, is what the original poster was saying.
I'll admit to obvious bias, in this instance, because I live in Australia. The Victorian state and federal highway system is better than pretty much anywhere else in the world (save maybe Germany,) and the water here is soft and not overly chlorinated. Admittedly, I do pay about.18c/KWh for electricity, but that's a fair trade as far as I'm concerned.
I don't hate America, but there are places that are as good, if not better.
Slashdot Mirror
Yeah, note heavy sarcasm :) - I'm from Melbourne.
I agree with your sentiments about local Fosters; it's shite. VB is likewise shite, however; most of the people I know drink either Boags or Cascade, as it is plentiful and relatively cheap (3 bucks odd for a pot, about 5 for a stubbie, bar prices.)
Apparently export fosters is quite good. I'll have to go to america one day just to try it.
I've barbequeued prawns before, the result is not worth the expense. I have no idea how prawns are meant to be cooked, but barbequeueing em just made black, crispy, carcinogenous prawns that tasted like arse.
English, not American, is the first language of Australians ;)
These guys seem european, however, as there's no references to shrimps on barbies, or Fosters.
007 Agent Under Fire contains an exploit in the save-game loading routine which can lead to a local-root compromise on your X-box with a specially corrupted save game file.
This can be used, for example, to boot Linux, or flash the BIOS.
The reason that this didn't win Mike Robertson's 100 large is because you still need to rip the lid off the box and solder a pair of jumpers (or use conductive pen) in order to enable 'write' on the flash rom.
it's a base64-encoded binary file. Base64 is a way of encoding 8 bit data into 7-bit clean text so that it can be passed through systems which aren't 8-bit clean, such as some older mailers.
Obviously, base64 increases filesize by at least 1/7.
(disclaimer: not the original poster.)
it can be argued that every idea exists in every conceivable form irrespective of a person implementing it independently. The basic form of this argument contends that since an idea can be conceived independently by multiple entities, that the idea itself exists irrespective of whether it has been conceived.
There are basic laws of physics and chemistry which govern, to an extreme degree, any invention which can be conceived. In the intellectual domain, there are less strictures, but the subset of all possible ideas is significantly less than infinite.
Telstra do the same thing in Oz. There's a Telstra ATM network with DSLAMs on one end of it and ISPs (including Bigpond) on the other.
Telstra did a stupid thing, however, in that the PPPoE/A connections from the CPEs are routed to an L2TP LAC in their main exchange in each city and then sent to an LNS at each ISP. This means that every single PPP/L2TP call has to run through this LAC, causing mucho problemo for all concerned, including (ironically) bigpond.
The even stupider thing is that Telstra DSL's main competitor, Request DSL, appears to do the same thing.
The way I would have done it is to have the DSLAMs expose themselves as ATM switches, connect all the ISPs to ATM switches at the other end (this bit is how it is at the moment anyhow) and get the CPE to initiate an ATM SVC to the ISP based on its NSAP address (really long string of hex digits, kind of like an ATM phone number.) Of course, since most ADSL CPE gear doesn't support SVCs (the cisco 800 series is one exception that I know about, there may be others,) statically configured PVCs on each DSLAM would have worked just as well, and allowed ISPs to run whatever higher layer protocols they wanted, instead of forcing them to use PPP.
Mostly due to incumbents abuse of copper monopoly, ADSL has sucked more or less everywhere.
I gotta say, that C: How to program book was the most useful collection of dead trees i've encountered in this life or any other... I picked the thing up at the end of '98 as I was shopping for Uni books, and went from practically no C programming knowledge (although I had done a lot of asm programming on 8 bit platforms many years earlier) to being able to code reasonably competently in the space of maybe five days.
I credit this book with giving me the ability to show up half an hour before the end of a 3 hour prac class, drunk, and get 100%. Those were the days (reminisces.....)
To be really pedantic, the PERCENTAGE of prime numbers which are even is 100/infinity.
Hence the 'cent' in the word percentage.
I'm sad.
You're a moron.
You speak of 'ACL' as if it was some kind of 'thing' which mysteriously makes 'other things' better. You also seem to have absolutely no idea how any of the products you're recommending over the generic crappy 200 buck NAT devices (which, by the way, actually do suck. but not for the reasons you're suggesting.)
A Cisco 2610 is not only on the virge of planned obsolecence (at the very least, Cisco is advising that you buy the 2620 instead, as it has a 100 megabit ethernet port, as opposed to the 10 megabit port on the 2610), but will not do stateful filtering. ACLs on Cisco (or most other) pure l3 routers will not keep state in the same way that OpenBSD's PF, IPF from FreeBSD, etc will. They're simply designed to drop certain traffic based on policy. If you want things to work properly under TCP, you have to allow EVERY packet that has ACK & !SYN set back in the other direction.
I suggest next time, before you go off your banana at someone for not having as much of a 'clue' as you do about 'ACL', or anything else for that matter, that you attempt to thoroughly familiarize yourself with the subject matter at hand first, otherwise you look like a half-cocked moron.
Mike.
I'm not sure about the SEC in America, but over here (Oz,) ASIC would spend significant time and resources tracking Pump'n'dump spammers because they're an over-funded government body with not a hell of a lot else to do apart from sue and arrest people (www.asic.gov.au).
:)
Now, as far as sending out untracable emails; sure, there's no motive to indisputably link a real world entity with the spammer, as you quite correctly said that it could have been any of the shareholders (or contractors thereto) who sent the message.
You'll always be able to trace a spam back to an IP address, though, more or less. A few scenarios:
o Open relay is used, with forged headers. Forged headers are almost invariably insubtle and easy to determine. For instance:
Received: from open.relay.net (spambag.relay.net [192.168.0.1]) by smtp.victim.com for uid 1001 (date)
Received: from dialup.spambag.net dialup.spambag.net [192.168.10.10]) by open.relay.net (8.11.2/8.11.4) id f00 (date)
(fake received headers follow)
It's usually fairly easy to trace the spam back to an originator, and from there to a real person (based on the co-operation of the ISP; most ISPs in Australia would co-operate with ASIC, especially post One-Tel/One-Net)
o Formmail.pl or equivalent is used: the victim's mail server or the webserver's smarthost will show a connection from the webserver's IP. Subpoena the web logs. If needed, subpoena the spammer's proxy logs (if the HTTP connection came therefrom.)
o An open socks proxy is used (these usually don't leave a mark in the header, in fact, most of the time you're unlikely to know that spam has been forwarded from such.) Fortunately, most spammers aren't this subtle, and open proxies have a habit of disappearing overnight when people realise what they've done. A visit from the securities cops will usually bring this to people's attention
Maybe he should pay a few mil to a dentist in danger money to get his teeth removed and have a new set fitted. :P
I don't begrudge him his shrine, but I can't see how it's like some big lifetime dream... There are plenty of things that are more rad which would perpetuate SF is all i'm saying.
Isn't it weird all the stuff rich guys do with their money?
I mean, If i'd made billions of bucks from starting a software concern in the early eighties, I PROBABLY wouldn't be starting a shrine to science fiction.
Don't get me wrong, I love SF as much as the next geek (and constantly have to upgrade my bookshelves,) but.... a shrine? That's a little macabre.
The guy should do something worthwhile with his bucks, like sponsor literary awards for young SF authors to help ensure the genre doesn't stagnate. Or donate a few hundred mil to Seti.
Shrine? Bah.
First one I picked up was DOA, turned it on, the SYS OK light flashed for a couple seconds, then quit.
:)
Sent the PSU back to the bloke in Sydney I bought it off and he sent me a revision 5 (OEM revision 4) PSU, rated at 550 (i think) watts. Worked fine (the 32550Ws are a gen-1 7200RPM drive and draw a stack of power.) When I upgraded to the 9G drives (a motley crue found on ebay for about AU40 apiece) they actually didn't get as hot or draw anything like as much power.
The second SSA had this PS to begin with (well, when I got it, anyway.)
The weird thing is that the molded plastic on the PSs is a darker grey than the rest of the SSA assembly. Heavy fucks, too...
Not bad, half a terabyte of fibre storage for around 2500 AUs all up
I have two SSA1010s upgraded to 9 gig disks, with 30 in each chassis, for around 522 gig of storage in two raid 5 arrays. Most of this is 256k MP3s and SHN recordings.
The majority of this wasn't downloaded, but encoded using parallel bladeenc (www.mpi.nd.edu/~jsquyres/bladeenc/) from various sources, my own CD collection for the most part.
Sad thing is, when I upgraded the SSAs from the 32550WC drives they came with (2.1G disks) to the hodge-podge of 9G drives that I spent a couple ebay-weeks collecting, I figured my storage woes were over.
Alas, it's not so.
It ain't just broken routers.
/29 from my DSL ISP at home. Since the whole thing runs on NAT, this gives me 8 IPs not 6, since NAT ranges have no concept of 'broadcast' or 'network' addresses (which only have link-local significance, and there's no link.)
/29 fell at the top of the /24 in question (202.59.108.248/29.) This means that 202.59.108.255 is one of the IPs which are being routed to my network. Cool, right?
I was recently assigned a
Unfortunately, the
Wrong. Having configured static NAT between that IP address and a machine on the inside of the network (172.18.16.24, case in point,) the machine was reachable from Unix and Linux machines, but not from Windows boxes.
Further testing reveals that Windows still uses classful logic to determine whether an IP is 'valid' or not. On attempting to ping 202.59.108.255 from a slew of windows 2000 boxes, tcpdump showed nothing on the other end. An identical test from a unix box showed that it worked just fine.
Surely you mean 32 class Cs? (where 24-19=5, and 2^5=32.)
/24.
/20 of a /19 and allow you to advertise it as a /19, provided you can justify up to a /20.
There are large parts of 203 (203/10 if memory serves,) all of 192 except for the RFC 1918 bits, and several other blocks which most backbone networks will accept up as up to a
I have NFI about Arin, being Australian, but APnic (the same thing for these parts) has several provisions for getting large blocks of IPs without too much justification ('new service' applications etc.)
I believe that most registries also allocate the bottom
I realise this is probably flamebait, but I'll bite.
Calling Windows the 'standard' for Operating Systems is similar to calling McDonalds the 'standard' for food.
Sure, it's the 'standard' for fast food, whatever that may be, in much the same way that windows is the standard for desktop systems, but Windows has far less server market share than everything else out there put together.
I'm not saying it doesn't have the single largest percentage of installed machines, merely that it's not the 'standard' and doesn't even have a clear majority on the back end.
Latency.
An interesting term.
You're most likely getting less latency on your ISDN than people do on their various *DSLs because of the crap way that almost every ILEC implements the CMUX->3rd party ISP transition.
ISDN's theoretical minimum SRTT is ~30ms (15ms end to end.) This will vary based on your distance from the switch, and the router you're calling's distance from its switch, and the number of switches in the middle. Remember, ISDN is circuit switched, so once you've established a Q.931 call you 'own' that 64 kilobits of bandwidth until you hang it up. There's no contention (unless the router at the other end is being hammered by something and its CPU is peaking, but that's not a physical constraint.)
DSL is usually sold by LECs to ISPs in the form of an ATM circuit that plugs into an L2TP LNS (concentrator.) A PPPoE/PPPoA connection is then established between the subscriber and the LEC's DSLAM, which then, acting as an LAC (l2tp client) forwards the circuit through the ATM network into the ISP's LNS.
The issue here is analogous, but not identical, to the 'engaged signal' problem which dial ISPs had (and still have.) You only purchase so much capacity from your LEC. When the subscriber:capacity ration exceeds 1:1, you will inevitably get contention. In the circuit-switched world of dial, this results in busy signals. In the cell-switched DSL/ATM world, this results in contention for backhaul bandwidth, which causes an increase in ping times. In theory (assuming zero contention,) any DSL will be much faster than ISDN.
I'll give you some (real world) examples. On my home, majorly oversubscribed, ADSL line (which is currently unladen,) a traceroute yields this:
traceroute to 203.24.47.212 (203.24.47.212), 30 hops max, 38 byte packets
1 172.18.0.254 0.548 ms 0.231 ms 0.225 ms
2 202.59.108.248 1.092 ms 0.754 ms 6.590 ms
3 202.59.104.1 51.111 ms 41.659 ms 89.890 ms
The first 2 hops are the internal and external firewalls, respectively (yes, I am sad.) The third hop is the LNS at my ISP who shall remain nameless but is easily identifiable with a whois @whois.apnic.net.
The 2 megabit SDSL connection I've got at work, into our own equipment (I work at a small company who owns its own SDSL infrastructure, essentially a LEC in their own right,) the traceroute yields this.
traceroute to 203.24.47.212 (203.24.47.212), 30 hops max, 40 byte packets
1 203.x.y.1 0.805 ms 0.856 ms 0.705 ms
2 203.x.z.1 1.577 ms 1.298 ms 1.184 ms
3 10.144.0.13 2.583 ms 2.682 ms 2.084 ms
4 203.x.a.97 3.097 ms 1.989 ms 2.064 ms
Where, again, 203.x.y.1 (I don't plan to identify where I work in this post, because that path is fraught with danger) is the switch which separates the engineering subnet from management, wireless, and phone (which is almost invariably at 85% utilisation due to the broadcast nature of 3com NBXes). 203.x.z.1 is the SDSL router (a flowpoint 2200 if you're interested), and 10.144.0.13 is the DSLAM. There is no backhaul ATM network in this scenario because we don't have resellers.
Finally, off a friend's ISDN connection:
traceroute to 203.89.25.72 (203.89.25.72), 30 hops max, 40 byte packets
1 203.13.113.105 0.996 ms 0.855 ms 0.870 ms
2 203.13.114.255 30.416 ms 31.422 ms 30.518 ms
This network is less complex. 203.13.114.255 is the ISDN router at the ISP end. The link is unused at the moment as he's in the process of transitioning everything to an ADSL connection (oh, the irony.)
The reason your pings go to shit in a game is because you're trying to stuff too much data down your 64k line, and the buffer in your modem/router is filling up. As this happens, it takes extra time for each packet to get from the end of the queue to the start thereof. Your pings go to crap and you get kicked off the server.
Bandwidth and latency have an interesting relationship.
IDSL is an interesting case. IDSL is broadband. ISDN isn't.
How is this so? The various DSLs work by what is essentially an RF process, in the same way that cable modems, television channels, etc. do.
The opposite of broadband, baseband, is represented by things like 10BaseT (note the word 'base') and refers to a non-modulated signal.
As an aside, there was an early cable modem standard known as 10Broad36, from memory, which was 10 megabits with (I think) a 36 or 3.6GHz carrier signal. That's what the 'base' in 10BaseX, 100BaseX and 1000Base-XX means.
So, it's technically possible to have a really slow (IDSL) broadband connection, yet have a really fast (1000Base-ZX, good for up to 70KM over 1510nm single mode fibre) baseband connection.
Although, with the introduction of (D)WDM-style multiplexing, where several fibres can be modulated over one piece of fibre, the WDM part of the backhaul would still technically be broadband, as the various wavelengths are multiplexed onto one really clean piece of single-mode fibre at many slightly (I think they vary by about 100MHz in either direction, and the standard units are good for about 1.6GHz variance) different wavelengths.
Broadband is a meaningless term, although these days it appears to have been redefined to mean 'anything faster than 64k or so', in much the same way that hacker now means 'evil computer guy in a black hat and an Anthrax t-shirt.'
Disclaimer: i'm a network engineer, not an EE, so I've been deliberately vague about exactly how RF modulation and such actually work.
I'm not for the life of me saying that an 802.11-like protocol won't do the job. I'm merely contending that 802.11 in its current state won't.
You wouldn't plug your brand new 120GB WD Special Edition into a second-generation ISA IDE card, either (well, not and expect it to move more than about 2MB/sec.)
Handoff between base-stations would require one of two things in order to work:
a. the 802.11 infrastructure was all bridged, possibly with some interesting VLAN setups (although this would largely be useless, as you don't win anything by VLAN'ing on a shared network)
b. device advertises its address as a 32-bit prefix to each base station it encounters, which then redistributes this into the network's IGP. This would not scale very well either.
An ATM-based wireless protocol would sort out these issues as your IP connection would be an SVC (most likely) which could be handed between switches via PNNI. If convergence comes, it will be from this direction.
Wireless ATM would be a really rad usage of ATM, too. Phone calls and data calls would all be configured as SVCs to very interesting NSAP addresses, and the base stations would have to have full ATM switching logic (possibly with MPLS built in) in order to cope.
802.11 as next-generation cell? Unlikely. The contention arbitration mechanisms aren't there, and the protocol was never designed to be used over a distance of greater than about 500 metres.
People like Karlnet (with TurboCell) have tried to push this envelope, largely unsuccessfully. A company I was involved with (who shall remain nameless, as I still own some of their stock) tried to push these technologies as 'long distance wireless multipoint technology' and it plain sucked at it. Square peg, round hole.
Comparing 802.11(a,b,g, or even TurboCell) with 2.5G/WCDMA/GSM/whatever is like comparing shared 10 megabit ethernet with a DS1. The latter has fixed timeslots to avoid two, three, or 30 devices contending for the available bandwidth. Each device is allocated a section of spectrum (bandwidth in the case of a DS1.) 802.3 has CSMA/CD which guarantees that all devices can continue speaking in the presence of collisions. 802.11 uses an even more perverse scheme referred to as CSMA/CA (collision AVOIDANCE,) which avoids collisions in the unlikely event that all nodes can see each other.
Incidentally (I will get to the point eventually, I promise,) cell works by dividing the available spectrum into timeslots, much as a DS1 does. The three most common division mechanisms are FDMA (frequency multiplexing, in which case every device gets its own unique, but very small, section of spectrum), TDMA (timeslot multiplexing, in which all devices contend for the same spectrum, but the timing guarantees each device uses a given slot,) and CDMA (code-based multiplexing, i'm honestly not sure how this works. Qualcomm own a patent on much of it, paid for by the American taxpayer.)
Since each device is guaranteed, deterministically, not to step on the toes of any other device, the devices don't have to be able to see each other in order to avoid major contention issues.
Now, back to 802.11 and CSMA/CA. The CSMA/CA algorithm guarantees that a given device won't hog the spectrum when it can hear other devices contending for it. If you move some of these devices such that they can't hear each other, the theory has it (which is why you have a wireless net running in infrastructure mode with a base station) that the base station will repeat communications from one node to the others. However, node A won't have any way of knowing that node B is after some spectrum, and vice versa. End result, the node which is closer (think physics and speed of light) will get the lion's share of the bandwidth.
Based on these assumptions, as well as the fact that 802.11 operates in spectrum used by microwave ovens, obscure military devices (the UNI/I 5.8 gig band,) and some satellite stuff (sideband interference 100MHz up the scale), 802.11 will never replace a properly thought out deterministic voice-grade protocol.
Now, *MDS on the other hand....
Exploits like this, which appears to be a relatively trivial buffer overflow, manage to exist for 8 YEARS in a piece of incredibly popular open source software?
;)
What ever happened to many eyes auditing the code? Not to say that the Samba team is doing a bad job, I run several Samba servers at home for various reasons, and they're damn rad. But I can't understand why this bug wasn't caught by somebody auditing the code.
I can only speak for myself, but I'd much prefer the Samba team to pore over the code looking for more bugs like this, than adding catch-up-with-the-gateses features like NT Domain Controller support which are largely irrelevant. The Unix philosophy is to do one thing, and do it well, and Samba already does this. If we want central authentication, we have a host of packages we can already choose from.
Not to deny the Samba team's work at all. I'll have to remember to send in my Pizza vouchers
This will cost me Karma, but here goes.
.18c/KWh for electricity, but that's a fair trade as far as I'm concerned.
I can think of a lot of places which offer exactly the set of advantages you comment on here. America is not the only country with good roads. Nor is it the only country with clean running water, gas, and electricity.
As you admitted yourself, there are many places with better health care.
Now, America DOES have the largest standing military in the world, more or less, and the largest defence industry. I'm not exactly sure that's something to be proud of, considering the problems that this has caused recently (viz., "Operation Iraqi Freedom," and the many indirect links to Israelis in Palestine and the West Bank.)
You name me one advantage which life in America has over life in, say, Australia, Canada, Japan, New Zealand, England or even friggin France.
The only advantage of America's which used to be bandied about was 'Freedom' (note the capital F and the 's.) This is increasingly under fire from fascist groups such as the RIAA. This, I think, is what the original poster was saying.
I'll admit to obvious bias, in this instance, because I live in Australia. The Victorian state and federal highway system is better than pretty much anywhere else in the world (save maybe Germany,) and the water here is soft and not overly chlorinated. Admittedly, I do pay about
I don't hate America, but there are places that are as good, if not better.
Does this mean that next time I read the source to GCC, Bill Gates^W^W RMS owns my firstborn?