I missed one character in a regex in a monitoring system that would cause it to think all the hard drives in a machine had failed when the machine was booted. Since it only happens on boot, it wasn't noticed until there was maintenance work that powered off an entire datacenter. When they turned the power back on, ~5000 machines all decided their hard drives had failed simultaneously. Took 2 days to clean up the mess.
The US has no official national language. By your logic, everyone in the US should learn and the government should only conduct business in the various Native American languages.
Having been part of the team that evaluated practically every processor being considered for Apple products from 2003-2009, Cell wasn't used because it sucks as a general purpose processor. The SPUs are interesting but you need to completely rewrite algorithms to use them effectively. While porting to Intel wasn't exactly easy (mostly due to the endian switch), it didn't involve rewriting every compute-heavy algorithm from scratch. Intel also had a roadmap while Cell was a point design.
It's interesting that the question implies that Linux is leading the charge in defining new APIs. Everything listed has a FreeBSD equivalent that predates the linux version:
Of course, the Linux developers decided to reinvent them all making compatibility impossible. I guess you could argue that the Linux versions offer some extra features over the FreeBSD versions, but from a user and developer perspective, the FreeBSD versions seem more complete and stable (see jails vs cgroups).
CDNs are designed to minimize latency which also happens to minimize distance (and generally cost as well) to the end user. BT _could_ do something similar by measuring latency of requests and preferring peers that have low latency. CDNs just do it all upfront and manually.
That really only scales up so far. It's actually quite difficult to saturate a 1gbps, let alone a 10gbps or 100gbps, link with a single stream. Multiple streams work around some of the problems and allow the full link to be used.
Intellectual property from other companies generally has to be stripped from the code base and those algorithms reimplemented in a different way. Yes, technically those other companies could open-source their code, but generally they don't. Sadly, that intellectual property is almost always used to get high performance.
Typically for graphics cards, the only data sent over PCIe is texture data, vertex lists, and commands. The bulk of the operations done by the card are running the commands over the vertex lists while bringing in texture data. The commands are almost always a multi-pass or pipeline so each vertex will be used in computations more than once. The result is the pushed to the monitor, not the PCIe. So, yes, in general, a graphics card will have more FLOPs than I/O bandwidth.
People who will try to cause fear and injury aren't new. There hasn't been any proof that all this legislation and fear mongering around curiosity has actually made us any safer. We live in an inherently dangerous world. It's time to realize that we can't baby-proof it. Then we can get back to doing research, having odd hobbies, and being generally curious without fear of being accosted.
Perhaps you should actually read up on the technology (link are already in other comments) and realize that the sleep proxy service handles some requests without waking the machine. For something like a ping, it doesn't wake the machine, but instead the proxy responds to the ping directly. Same for service advertisements. It only wakes the machine when the proxy can't handle the request on the machine's behalf.
So yeah, it does solve the problem. Now you've proven that not only are you unable to perform basic research, but that you ignore the facts presented and continue claim something entirely refuted by the facts.
If you've ever had a display calibrated, you'd know that even the existing RGB color space can't be completely recreated with existing RGB-based displays. The problem is in the inability of LEDs or LCD or plasma panels to produce light uniformly in the three color channels. If you can add a 4th channel that lets the RGB color space be more accurately produced by the display, then you will see an improvement. It won't make the source any better, but the output generated by the display for that input will be better.
You carefully document the costs to buy a mac, but assume that an Android developer would already have some computer. That's not a fair comparison. The cost of the machine should be prorated based on additional uses. Thus, the Mac will still cost more than the already owned machine, but it isn't free.
Funny, Comcast is actually starting IPv6 trials in my area and has asked for volunteers. They've taken a long time, but they are finally moving and it doesn't appear that they are suffering from an immediate lack of IPv4.
So in other words, it was OK for everyone to broadcast information that they don't really want to be public because they didn't expect anyone to actually make it public. Then, when someone does, it's the fault of the collector that everything was available? Huh? Perhaps it would be more prudent for individuals to consider what having something be made public means before deciding to do so. The options for not broadcasting SSIDs have been in APs since the beginning.
A probably poor analogy: When I'm visiting my parents, I tend to not bother locking my car doors since they live in the middle of nowhere. I don't expect anyone to steal my car because it is unlikely that someone would know that I leave it unlocked and would venture out that far to steal a car. Now, a company comes along and records locations and the number of cars that have unlocked doors. If it helps, consider that this can be determined for most cars without touching the car. If my car gets stolen, do I sue the company for making it known that my car was frequently unlocked in this area? No, I realize how dumb I was, file an insurance claim, and start shopping for a new car. I probably won't leave my car unlocked any more either.
So, why were you broadcasting said information in cleartext to anyone within range? If you didn't want it to be public, you shouldn't have been shouting it from the AP.
Slashdot Mirror
I missed one character in a regex in a monitoring system that would cause it to think all the hard drives in a machine had failed when the machine was booted. Since it only happens on boot, it wasn't noticed until there was maintenance work that powered off an entire datacenter. When they turned the power back on, ~5000 machines all decided their hard drives had failed simultaneously. Took 2 days to clean up the mess.
The US has no official national language. By your logic, everyone in the US should learn and the government should only conduct business in the various Native American languages.
Having been part of the team that evaluated practically every processor being considered for Apple products from 2003-2009, Cell wasn't used because it sucks as a general purpose processor. The SPUs are interesting but you need to completely rewrite algorithms to use them effectively. While porting to Intel wasn't exactly easy (mostly due to the endian switch), it didn't involve rewriting every compute-heavy algorithm from scratch. Intel also had a roadmap while Cell was a point design.
It's interesting that the question implies that Linux is leading the charge in defining new APIs. Everything listed has a FreeBSD equivalent that predates the linux version:
cgroups -> jails
udev -> devfs
fanotify, timerfd, signalfd -> kqueue
Of course, the Linux developers decided to reinvent them all making compatibility impossible. I guess you could argue that the Linux versions offer some extra features over the FreeBSD versions, but from a user and developer perspective, the FreeBSD versions seem more complete and stable (see jails vs cgroups).
The grandparent never said it did. They simply stated that it certainly is illegal in the USA and suggested it may be in Canada as well.
CDNs are designed to minimize latency which also happens to minimize distance (and generally cost as well) to the end user. BT _could_ do something similar by measuring latency of requests and preferring peers that have low latency. CDNs just do it all upfront and manually.
That really only scales up so far. It's actually quite difficult to saturate a 1gbps, let alone a 10gbps or 100gbps, link with a single stream. Multiple streams work around some of the problems and allow the full link to be used.
They are never present in the main search results. They are above or to the right of the results.
Direct message. It's short enough that it should just always be written out.
Except that a century ago, stealing blueprints actually deprived the owner of something tangible. It was actually theft.
Not if we are in the USA, the photos are taken from a public place (the street), and they are only for personal use.
Only if that patch includes new functionality or content and the company is publicly traded.
Actually, the USA has no official language.
Intellectual property from other companies generally has to be stripped from the code base and those algorithms reimplemented in a different way. Yes, technically those other companies could open-source their code, but generally they don't. Sadly, that intellectual property is almost always used to get high performance.
IMHO, Cicero's Pizza in San Jose has probably the best NY-style pizza outside of NY.
Typically for graphics cards, the only data sent over PCIe is texture data, vertex lists, and commands. The bulk of the operations done by the card are running the commands over the vertex lists while bringing in texture data. The commands are almost always a multi-pass or pipeline so each vertex will be used in computations more than once. The result is the pushed to the monitor, not the PCIe. So, yes, in general, a graphics card will have more FLOPs than I/O bandwidth.
Seems like we already have: top speed limiters, safety scissors, plastic butter knives....
People who will try to cause fear and injury aren't new. There hasn't been any proof that all this legislation and fear mongering around curiosity has actually made us any safer. We live in an inherently dangerous world. It's time to realize that we can't baby-proof it. Then we can get back to doing research, having odd hobbies, and being generally curious without fear of being accosted.
Perhaps you should actually read up on the technology (link are already in other comments) and realize that the sleep proxy service handles some requests without waking the machine. For something like a ping, it doesn't wake the machine, but instead the proxy responds to the ping directly. Same for service advertisements. It only wakes the machine when the proxy can't handle the request on the machine's behalf.
So yeah, it does solve the problem. Now you've proven that not only are you unable to perform basic research, but that you ignore the facts presented and continue claim something entirely refuted by the facts.
If you've ever had a display calibrated, you'd know that even the existing RGB color space can't be completely recreated with existing RGB-based displays. The problem is in the inability of LEDs or LCD or plasma panels to produce light uniformly in the three color channels. If you can add a 4th channel that lets the RGB color space be more accurately produced by the display, then you will see an improvement. It won't make the source any better, but the output generated by the display for that input will be better.
You carefully document the costs to buy a mac, but assume that an Android developer would already have some computer. That's not a fair comparison. The cost of the machine should be prorated based on additional uses. Thus, the Mac will still cost more than the already owned machine, but it isn't free.
No one said those microorganisms are still alive. If they are all dead, there isn't life.
Funny, Comcast is actually starting IPv6 trials in my area and has asked for volunteers. They've taken a long time, but they are finally moving and it doesn't appear that they are suffering from an immediate lack of IPv4.
So in other words, it was OK for everyone to broadcast information that they don't really want to be public because they didn't expect anyone to actually make it public. Then, when someone does, it's the fault of the collector that everything was available? Huh? Perhaps it would be more prudent for individuals to consider what having something be made public means before deciding to do so. The options for not broadcasting SSIDs have been in APs since the beginning.
A probably poor analogy: When I'm visiting my parents, I tend to not bother locking my car doors since they live in the middle of nowhere. I don't expect anyone to steal my car because it is unlikely that someone would know that I leave it unlocked and would venture out that far to steal a car. Now, a company comes along and records locations and the number of cars that have unlocked doors. If it helps, consider that this can be determined for most cars without touching the car. If my car gets stolen, do I sue the company for making it known that my car was frequently unlocked in this area? No, I realize how dumb I was, file an insurance claim, and start shopping for a new car. I probably won't leave my car unlocked any more either.
So, why were you broadcasting said information in cleartext to anyone within range? If you didn't want it to be public, you shouldn't have been shouting it from the AP.