Actually it went international long before IP was even in use. University College London joined the ARPAnet back in 1973. TCP and IP were only standardized in 1978.
Re:gcc 3.x compilers have serious C++ perfs issues
on
GCC 3.3 Released
·
· Score: 3, Informative
We're using g++ with heavy use of templates in a project that currently has ~400,000 lines of code.
gcc 3.2.1 takes about 50% longer than gcc 2.95.4.
But, gcc 3.2.1 found loads of bugs that gcc 2.95 didn't notice, even with all the error checking enabled. I'd much rather have the extra checking and have to upgrade my compilation machines 6 months earlier, rather than have stupid errors go unreported by the compiler. So far today it looks like gcc 3.3 finds still more bugs in our code than 3.2.1 did.
Actually, the ISPs can't figure out how to bill for unicast either. Which is why so many of them are going bankrupt. Billing isn't a showstopper.
The real issue is that deploying any new service does cost money, and until competition or greed forces you to do so, you're not
likely to be first. If your customers will go
elsewhere because you've not deployed it and your competitors have, you'll deploy it anyway without figuring how to bill additionally for it.
Newer routers (especially Junipers) can handle multicast just fine. But I agree that deploying any additional service isn't zero-risk and, until SSM, multicast was particularly vulnerable to denial-of-service. The hosts mostly don't support IGMPv3 yet which is needed for SSM, so the ISPs are mostly playing wait-and-see.
There's lots of multicast deployment on Intranets though, where things are in a more carefully controlled less hostile environment.
Damn. Extra flaw. The MTA has to compute the hash too.
SHA is pretty cheap. But it doesn't have to be SHA. There are a whole class of assymetric algorithms that are far harder to generate than to check.
A simple example: generate the SHA hash of the msg, to, from timestamp and payload as before.
Call this H1. Now the sender is required to find a 80-byte string whose SHA hash has the same first n bits as H2. This is arbitrarily hard for the sender (choose an appropriate value of n), and constant cost for the receiver.
Now if SHA is too hard (I don't think it is), you can can choose a cheaper hash, and still make it hard for the sender.
I agree. Not to mention that most software written for Linux can easily be ported to run on Solaris, and vice-versa. What this means is that if Sun finds a niche where they deliver something the customer wants and they can be profitable doing it, they won't die because of lack of available software.
Linux is Sun's friend; if all the low-end servers moved to Windows, Sun would have a much harder time finding such a stable profitable niche.
I agree with you that H.323 sucks. But pretty much any IP device that separates signaling from data is going to suffer from similar problems negotiating the media ports. You need to separate signaling from data because you need to use RTP over UDP to transport audio and video because you've got tight timing constraints, yet you want a reliable signaling protocol that does appropriate handshaking to get through the firewall in the first place.
I'm one of the authors of SIP (RFC 2543), which is the only viable alternative to H.323, and it has the same fundamental problem. One of SIP's many benefits over H.323 is that the encoding is ASCII, as opposed to H.323's ASN.1 which is a pain in the ass. This makes the firewall's job somewhat easier, but still not trivial. There just isn't an easy solution when it comes to signaling protocols.
I disagree. It's far too easy to have multiple pointers pointing to the same data, and lose track of who is supposed to free it.
In C++, the best way to avoid double-free problems is to pass references rather than pointers whereever possible. If you receive a reference as a parameter, it's totally obvious you're not expected to free it.
was Dr. Reed's willingness to wave away two hundred years of well-established physics. Waves of the same frequency crossing the same point in space do interfere. How do I know? Because the very definition of interference is the effect they have.
Sure, and you can get nice interference patterns with visible light too. With visible light, it doesn't tend to matter though for three reasons:
We have lenses that allow precise directionality.
With a few exceptions such as glass, we don't usually try to look through solid objects. We usually expect radio to go through objects like buildings, and indeed it does, but refraction and diffration distort the directionality of the signal.
The wavelength of light is much shorter than the size of everyday objects, so defraction doesn't dominate.
It's really hard to build small precise directional antennas for RF because of the last point.
So, the analogy with light just doesn't hold. What I don't know though is how far you can use spread spectrum and coding to work around these problems. I think you can get a whole lot better than the current state of the art, but I don't know what the limits are.
Yes! I've got a Casio fx-450 solar-powered scientific calculator (which also has boolean login functions), which I bought in high school 20 years ago. I still use it regularly.
It's hinged down the middle - the basic calculator buttons are on the left half, and the scietific functions are on the right half, with a rubberized ribbon-cable/hinge between the two. The irony is that when I bought it, I was very worried that the hinge would fail quickly. I guess I was slightly wrong. But the solar cell is slowly degrading - it needs much brighter light to work than it used to.
Speed of light is 186,000 miles / second. That means that, best theoretical case, round trip is 129 milliseconds....
In the immortal words of John Carmack, "The Speed of Light Sucks".
And it sucks worse in glass - about 2/3 of the speed of light in a vacuum.
For inbound traffic: don't charge them for TCP SYNs, but do charge then for any inbound TCP data packets.
In effect, the rationale is that the SYN is unsolicited, but if the customer accepts the connection it's their fault. Then it's up to the customer to decide whether to accept a connection or not.
For ICMP, charge them for inbound echo requests only if they generate matching outbound echo responses.
Charge them for inbound echo responses only if they generate matching outbound echo requests.
This gives the customer the ability to control bandwidth usage through filtering if they wish.
For inbound UDP, it's much harder. I don't see any really good way to do this, but perhaps someone else can.
Of course the tools to do this sort of billing might not exist yet, and there are a bunch of details that make this harder than I imply, but this would be the basis of a policy that's fair to the customer.
At higher speeds you spend a lot of energy pushing air out of the way - wind resistance is roughly proportional to the square of the speed. In the city, you don't spend much energy moving air, but in normal city driving, you're constantly accelerating, then turning all that kinetic energy into heat by braking. If you just drove at a constance 30 mph, you'd get pretty good mileage mileage in almost any car, but practically no-one ever does this for obvious reasons. A hybrid will turn most of that energy lost by braking into electricity through regenerative braking, so each time you speed up and slow down you don't use much additional fuel.
Drag the CDRom to the trashcan to eject? That's a great one.
Actually the moment you click on the CDRom, the trashcan icon changes to an eject logo, so Apple have listened to this particular criticism.
Many years ago, a friend of mime once accidentally dragged an NFS mounted Unix filesystem to the trashcan on her Mac instead of the floppy she was trying to eject. Can you say "rm -rf *"? Not a happy camper.
I agree completely - it's a wonderful machine. I've used Unix on my desktop for the past 18 years, and this is the first machine that's ever made me seriously consider switching my desktop platform.
Yes, it gets warm. But mine's been powered up continuously for the past four days, and it's still within reasonable bounds. It's warmer than I'd ideally like, but not warm enough to be a serious issue.
On Apple's latest release, the modifier key for right button is the Apple key. The Middle button modifier is the Alt/Option key. So needing to do ctrl-click isn't an issue. Alt-click might be, but I don't recall ever needing to do this in 15 years of using X:-)
I had minor teething problems working the other way round. I've been using a Lucent WavePoint II basestation containing an old Lucent bronze card (7Mb/s proprietary, falls back to 2Mb/s standards compliant) at home for the last four years. Yeah 2Mb/s isn't fast, but it's faster than my DSL line, so it's fast enough. It's worked with every 802.11B card I've ever tried.
Last week I got a new G4 12" Powerbook (very nice, BTW!), with built-in 802.11g. Of course it wouldn't talk to the basestation. To get it to work required re-flashing the basestation to bring it up to more recent spec. After that it worked fine. It's always annoying to have to upgrade firmware, but to be honest I'm really impressed it works at all - I was expecting to have to change the card in the basestation to something a little more recent.
The paper is also at the IMW web site, along with the slides from Steve's presentation, and all the other papers. Scroll down
to Friday morning for Steve's paper and slides.
The data is captured and logged on a continuous basis to allow after-the-fact analysis of events that you can't predict in advance, or just to provide a window into how the network functions under normal conditions.
Typically the logger is a very fast PC or workstation with one of more gigabit ethernet cards. Usually those gig-E cards receive their data from a ethernet-switch port that is configured to mirror another switch port (ie send a duplicate of all the packets on one port to the monitoring port), or alternatively the monitoring machine may be connected to a passive optical tap.
In either case, the monitoring machine usually cannot send packets on the port that's being monitored.
Also, if the tap is at a very busy location, the logger might not be able to log fast enough to keep up with the link, so it may only be logging a random sample of packets.
Thus these sort of logs are useful primarily for offline analysis.
To actually filter the traffic would require access to the routers. But the researchers running the monitors usually are not the network operators, but more likely to be research scientists. Thus even if they saw what was going on before the network operators did, they still wouldn't be able to do anything about it directly.
The article quoted by the parent is seriously cool, if a little hard to read. Neither a non-executable stack or a non-executable heap will defend against this return into libc attack, nor will.rodata. I think propolice will though. Anyone know what the performance overhead of propolice is?
I don't think so. The disassembled code I've seen indicates that the SQL worm only spreads fast - any problems were just due to the load it's spreading attempts generate. If it had been real cyberwarfare, I'm sure they'd have at least deleted the SQL database files on the machines they attacked.
Of course the modified version someone else now crafts that starts spreading sometime next week might actually aim to do some persistent damage, but this version didn't.
In fact, you might even regard this as a blessing in disguise. The worm spread on a Friday night/Saturday morning, when least business would be affected. As of this morning, most ISPs now have filters in place, so any follow up isn't likely to do much damage, and it will now be hard to launch a really destructive attack using this particular vulnerability in future.
I should have added that many people don't realize that you absolutely don't want a high refresh rate with an LCD. Many of the LCDs I work with as sysadmin will only give a good sharp picture at 60Hz. Set them to anything else when using a VGA source, and the image quality can be pretty lousy.
You're mixing up two things. On a CRT you need a high refresh rate because otherwise your peripheral vision detects the flicker. On an LCD, there is no flicker (point a video camera at an LCD, and you see no artifacts), so you don't need a high refresh rate - 60Hz is fine - no flicker whatsoever.
And you can't detect that a 60Hz refresh on an LCD isn't continuous motion - 60Hz is plenty fast enough to fool the brain, so long as there's no flicker.
But you're completely right about the persistence.
LCDs just can't change state fast enough, so with fast moving sources, you can get visible smearing.
But I don't personally find it to be an issue - I find MPEG artifacts on DVDs to be much more annoying.
A lot depends on what you use the display for - if you work with text a lot, CRTs don't come close to LCDs in quality. If you work with video or photos, definitely CRTs have the edge. And for games, who cares - if you're paying attention to the monitor then the game can't be very good.
- Fzz
Re:itanium is a solid chip from what I've seen...
on
Itanium Problems
·
· Score: 1
It's not the cost of electricity they're concerned about, it's heat output. Data centers are very densely packed locations, and they are designed with assumptions that each rack consumes so much power and dissipates so much heat. Violate those limits and you simply don't get to be in the data center.
Slashdot Mirror
Actually it went international long before IP was even in use. University College London joined the ARPAnet back in 1973. TCP and IP were only standardized in 1978.
Thank you gcc team!!!!
The real issue is that deploying any new service does cost money, and until competition or greed forces you to do so, you're not likely to be first. If your customers will go elsewhere because you've not deployed it and your competitors have, you'll deploy it anyway without figuring how to bill additionally for it.
Newer routers (especially Junipers) can handle multicast just fine. But I agree that deploying any additional service isn't zero-risk and, until SSM, multicast was particularly vulnerable to denial-of-service. The hosts mostly don't support IGMPv3 yet which is needed for SSM, so the ISPs are mostly playing wait-and-see.
There's lots of multicast deployment on Intranets though, where things are in a more carefully controlled less hostile environment.
SHA is pretty cheap. But it doesn't have to be SHA. There are a whole class of assymetric algorithms that are far harder to generate than to check.
A simple example: generate the SHA hash of the msg, to, from timestamp and payload as before. Call this H1. Now the sender is required to find a 80-byte string whose SHA hash has the same first n bits as H2. This is arbitrarily hard for the sender (choose an appropriate value of n), and constant cost for the receiver.
Now if SHA is too hard (I don't think it is), you can can choose a cheaper hash, and still make it hard for the sender.
Linux is Sun's friend; if all the low-end servers moved to Windows, Sun would have a much harder time finding such a stable profitable niche.
I'm one of the authors of SIP (RFC 2543), which is the only viable alternative to H.323, and it has the same fundamental problem. One of SIP's many benefits over H.323 is that the encoding is ASCII, as opposed to H.323's ASN.1 which is a pain in the ass. This makes the firewall's job somewhat easier, but still not trivial. There just isn't an easy solution when it comes to signaling protocols.
In C++, the best way to avoid double-free problems is to pass references rather than pointers whereever possible. If you receive a reference as a parameter, it's totally obvious you're not expected to free it.
-Fzz
Sure, and you can get nice interference patterns with visible light too. With visible light, it doesn't tend to matter though for three reasons:
- We have lenses that allow precise directionality.
- With a few exceptions such as glass, we don't usually try to look through solid objects. We usually expect radio to go through objects like buildings, and indeed it does, but refraction and diffration distort the directionality of the signal.
- The wavelength of light is much shorter than the size of everyday objects, so defraction doesn't dominate.
It's really hard to build small precise directional antennas for RF because of the last point.So, the analogy with light just doesn't hold. What I don't know though is how far you can use spread spectrum and coding to work around these problems. I think you can get a whole lot better than the current state of the art, but I don't know what the limits are.
-Fzz
It's hinged down the middle - the basic calculator buttons are on the left half, and the scietific functions are on the right half, with a rubberized ribbon-cable/hinge between the two. The irony is that when I bought it, I was very worried that the hinge would fail quickly. I guess I was slightly wrong. But the solar cell is slowly degrading - it needs much brighter light to work than it used to.
And it sucks worse in glass - about 2/3 of the speed of light in a vacuum.
-Fzz
Yeah, but the packet loss rate is a little high for my tastes.
-Fzz
For ICMP, charge them for inbound echo requests only if they generate matching outbound echo responses. Charge them for inbound echo responses only if they generate matching outbound echo requests. This gives the customer the ability to control bandwidth usage through filtering if they wish.
For inbound UDP, it's much harder. I don't see any really good way to do this, but perhaps someone else can.
Of course the tools to do this sort of billing might not exist yet, and there are a bunch of details that make this harder than I imply, but this would be the basis of a policy that's fair to the customer.
- Fzz
Well, perhaps more like 60+ lbs of ice accellerated by a Mach 2 airstream for the time it took to fall from the tank to the orbiter.
-Fzz
- Fzz
Actually the moment you click on the CDRom, the trashcan icon changes to an eject logo, so Apple have listened to this particular criticism.
Many years ago, a friend of mime once accidentally dragged an NFS mounted Unix filesystem to the trashcan on her Mac instead of the floppy she was trying to eject. Can you say "rm -rf *"? Not a happy camper.
- Fzz
Yes, it gets warm. But mine's been powered up continuously for the past four days, and it's still within reasonable bounds. It's warmer than I'd ideally like, but not warm enough to be a serious issue.
- Fzz
- Fzz
Last week I got a new G4 12" Powerbook (very nice, BTW!), with built-in 802.11g. Of course it wouldn't talk to the basestation. To get it to work required re-flashing the basestation to bring it up to more recent spec. After that it worked fine. It's always annoying to have to upgrade firmware, but to be honest I'm really impressed it works at all - I was expecting to have to change the card in the basestation to something a little more recent.
- Fzz
-Fzz
Typically the logger is a very fast PC or workstation with one of more gigabit ethernet cards. Usually those gig-E cards receive their data from a ethernet-switch port that is configured to mirror another switch port (ie send a duplicate of all the packets on one port to the monitoring port), or alternatively the monitoring machine may be connected to a passive optical tap. In either case, the monitoring machine usually cannot send packets on the port that's being monitored.
Also, if the tap is at a very busy location, the logger might not be able to log fast enough to keep up with the link, so it may only be logging a random sample of packets.
Thus these sort of logs are useful primarily for offline analysis.
To actually filter the traffic would require access to the routers. But the researchers running the monitors usually are not the network operators, but more likely to be research scientists. Thus even if they saw what was going on before the network operators did, they still wouldn't be able to do anything about it directly.
-Fzz
-Fzz
Of course the modified version someone else now crafts that starts spreading sometime next week might actually aim to do some persistent damage, but this version didn't.
In fact, you might even regard this as a blessing in disguise. The worm spread on a Friday night/Saturday morning, when least business would be affected. As of this morning, most ISPs now have filters in place, so any follow up isn't likely to do much damage, and it will now be hard to launch a really destructive attack using this particular vulnerability in future.
- Fzz
- Fzz
And you can't detect that a 60Hz refresh on an LCD isn't continuous motion - 60Hz is plenty fast enough to fool the brain, so long as there's no flicker.
But you're completely right about the persistence. LCDs just can't change state fast enough, so with fast moving sources, you can get visible smearing. But I don't personally find it to be an issue - I find MPEG artifacts on DVDs to be much more annoying.
A lot depends on what you use the display for - if you work with text a lot, CRTs don't come close to LCDs in quality. If you work with video or photos, definitely CRTs have the edge. And for games, who cares - if you're paying attention to the monitor then the game can't be very good.
- Fzz
-Fzz