Believe it or not, I've actually had the opposite problem, accidentally toggling *on* the main PSU while trying to do a quick hardware install.
I agree that it's far too easy to knock the power cable out. My current case has its PSU on the bottom also, and it's way too easy for my foot to knock it out of the PSU. I also agree that the power cable often will prevent you from hitting the rocker switch in most configurations.
Me personally? I don't have much of a problem with rocker switches. I can see why others might. I'm not moved enough to care.
The old IBM XTs had a big red toggle switch. It was a beefy mofo in a recessed housing. Check it out! You couldn't accidentally toggle that thing off.
Rocker switches, on the other hand, can much more easily get bumped between "on" and "off" while futzing around with cabling, especially under a cramped desk.
What happens when you send a malformed terminal escape sequence to a more traditional xterm? In the worst case, you can effectively 'hang' xterm... Try sending the "set titlebar" escape and forget the ^G.;-)
They also don't normally have antibiotics in their bloodstream. It's not the sugar that's killing the bacteria, it's the fact that the sugar tricks bacteria into letting the antibiotics in. Even if elevated blood sugar could help this process, you still need an antibiotic.
You didn't watch the video, or if you did, you didn't read all the subtitles. Both sides have a motor and sensors. The sensor system tries to keep both boxes in sync, so if one side tries to move in a particular direction and the other side resists, then the unit will resist. There *is* a feedback path.
Now the real "that ain't a kiss" problem is that it only lets you make a specific set circular motions with your tongue, and lets face it, tongues and mouths are a bit more complicated than that, and kisses involve a lot more than what this device measures.
Right, but I get feeling that China's "mass production" advantages tend to require a couple more digits in the number than even 400. And if it's all robot controlled for the production, you're not even that sensitive to the labor costs, just materials and energy. goodmanj pointed out below that they're very CNC focused, with minimal human labor.
Well, apparently he had open heart surgery a couple years ago and has had health issues since then. I'm reminded of the saying, "A sucking chest wound is life's way of telling you to slow down." Burt's not quite to that point yet. May as well quit while he's ahead.
The sorting stuff came in handy for me when doing incredibly small sorts, ironically enough. Median filters end up being small sorts. With a 5x5 or 7x7 median filter, you've got 25 or 49 pixels and need to find the median pixel value quickly. Interestingly enough, I ended up using a combination of sorting networks and insertion sort a partially sorted pixel buffers for 7x7. (Partially sorted because the 7x7 kernel for adjacent pixels overlaps and so you can take advantage of the partial sorting in the overlap region for both.)
I've had it come in handy for other similar things here and there over the years. For example, I reused the 7-point sorting network when helping a customer optimize their power supply filtering code on a microcontroller once, for example. (It too was a median filter, but one dimensional.) Not everyone needs to sort megabytes of data to make use of Knuth.:-)
(Ok, I guess I am still filtering megabytes of data in some sense. Just not all in one go. I'm doing many, many, many smaller sorts that don't cross-communicate.)
Sometimes it really is best to learn by trial and error, with past experience providing some amount of guidance so that the cost of "trial' isn't quite as high.
Yes, if you locked this kid in a informational vacuum with nothing but a pile of blank paper, some pens and Galileo's first telescope and said "derive astrophysics from first principles", it'd be a total waste of time.
Fact of the matter is that this child is building on existing knowledge. He's just not accepting it wholesale. Challenging new ideas when they're new to you (even if they're not new to everyone else) is completely natural and healthy. It means your B.S. detector is functioning and that you don't just take knowledge on authority.
It's amazing that something so invisible can be such a strong sticking point, but I'm with you 100% on this. Even Fortran and TCL are more forgiving on this count.
I work directly with a VLIW architecture myself (the TI C6000 family of DSPs). From that perspective, I'm a little sad to see Itanium go. I realize EPIC isn't exactly VLIW, but they had an awful lot in common. Much of HP's and Intel's compiler research helps us other VLIW folks too.
I think EPIC tried to live up to its name a little too much. The original Merced overreached, and so it ended up shipping far too late for its performance to be compelling. Everybody always zooms in on the lackluster x86 performance, but x86 wasn't at all interesting in the spaces Itanium wanted to play in originally. It wanted to go after the markets dominated by non-x86 architectures such as Alpha, PA-RISC, MIPS and SPARC. And had it come out about 3 years earlier, it may've had a chance there by thinning the field and consolidating the high-end server space behind EPIC.
Instead, it launched late as a room-heating yawner. And putting crappy x86 emulation on board only tempted comparisons to the native x86 line. That it made it all the way to Poulson is rather impressive, but smells more like contractual obligation than anything else.
I found the article maddeningly vague, while that 8% number they threw out there strangely precise. Do you have a link to anything that says more specifically what they're doing? Your description sounds roughly like I was expecting (ie. sizing adders and multipliers to the actual needs of the problem rather than throwing standard sizes at them unthinkingly), but the article sorta treated transistors and logic as "magic" and their technique as "advanced magic". *eyeroll*
From what I remember, during time changes or other corrections, they'd shift the minute hand's gear to match the second hand until the clocks displayed the right time. The shift-in and shift-out happened right at the 12 o'clock position.
As a result, the motor still ran at the same rate, and at no point did any hand move faster than 6 degrees/second. Nonetheless, the displayed time would advance at 60x normal rate.
It's the kind of thing that could be handled with a simple shifting mechanism that changed which gear drove the minute hand. Even simpler than VTEC.
I have 16GB RAM in my 64-bit machine at home. I actually look forward to THP, since any process that actually benefits from that much RAM would also benefit from THP if it isn't already using hugetlbfs. As far as I can tell, hugetlbfs almost never gets used, so that means just about any process that I'd run that needs that much RAM would benefit from THP.
The other day I edited a page-sized full color scan in The Gimp at 600 DPI without swapping. That was actually pretty cool. That's an app that'd benefit from THP.
My facepalm story of the day. When I ordered a laptop upgrade at work, I picked one from our internal catalog with a nice, hi-res display. 1680x1050 was the highest res display I could find without going to a 17" dreadnought. So, it arrives and the display is all blurry. The tech had set it to 1024x768. I asked him why he did that. He said most people who get this and similar laptops complain about "their icons and fonts are too small" if they set them to the native resolution, so it was standard practice to set them to a lower resolution.
Slashdot Mirror
Believe it or not, I've actually had the opposite problem, accidentally toggling *on* the main PSU while trying to do a quick hardware install.
I agree that it's far too easy to knock the power cable out. My current case has its PSU on the bottom also, and it's way too easy for my foot to knock it out of the PSU. I also agree that the power cable often will prevent you from hitting the rocker switch in most configurations.
Me personally? I don't have much of a problem with rocker switches. I can see why others might. I'm not moved enough to care.
The old IBM XTs had a big red toggle switch. It was a beefy mofo in a recessed housing. Check it out! You couldn't accidentally toggle that thing off.
Rocker switches, on the other hand, can much more easily get bumped between "on" and "off" while futzing around with cabling, especially under a cramped desk.
What happens when you send a malformed terminal escape sequence to a more traditional xterm? In the worst case, you can effectively 'hang' xterm... Try sending the "set titlebar" escape and forget the ^G. ;-)
Yeah, I couldn't tell if I was reading a Slashdot article or a YouTube comment. The article needs some serious editing to turn it into English.
They also don't normally have antibiotics in their bloodstream. It's not the sugar that's killing the bacteria, it's the fact that the sugar tricks bacteria into letting the antibiotics in. Even if elevated blood sugar could help this process, you still need an antibiotic.
I guess it's there to make the Atari Pac-Man look good.
In general, I have to say that some of these selections are quite head-scratch-inducing.
You didn't watch the video, or if you did, you didn't read all the subtitles. Both sides have a motor and sensors. The sensor system tries to keep both boxes in sync, so if one side tries to move in a particular direction and the other side resists, then the unit will resist. There *is* a feedback path.
Now the real "that ain't a kiss" problem is that it only lets you make a specific set circular motions with your tongue, and lets face it, tongues and mouths are a bit more complicated than that, and kisses involve a lot more than what this device measures.
Right, but I get feeling that China's "mass production" advantages tend to require a couple more digits in the number than even 400. And if it's all robot controlled for the production, you're not even that sensitive to the labor costs, just materials and energy. goodmanj pointed out below that they're very CNC focused, with minimal human labor.
Well, apparently he had open heart surgery a couple years ago and has had health issues since then. I'm reminded of the saying, "A sucking chest wound is life's way of telling you to slow down." Burt's not quite to that point yet. May as well quit while he's ahead.
The sorting stuff came in handy for me when doing incredibly small sorts, ironically enough. Median filters end up being small sorts. With a 5x5 or 7x7 median filter, you've got 25 or 49 pixels and need to find the median pixel value quickly. Interestingly enough, I ended up using a combination of sorting networks and insertion sort a partially sorted pixel buffers for 7x7. (Partially sorted because the 7x7 kernel for adjacent pixels overlaps and so you can take advantage of the partial sorting in the overlap region for both.)
I've had it come in handy for other similar things here and there over the years. For example, I reused the 7-point sorting network when helping a customer optimize their power supply filtering code on a microcontroller once, for example. (It too was a median filter, but one dimensional.) Not everyone needs to sort megabytes of data to make use of Knuth. :-)
(Ok, I guess I am still filtering megabytes of data in some sense. Just not all in one go. I'm doing many, many, many smaller sorts that don't cross-communicate.)
The " Thousands of TrueType Fonts" part is what always pushes me over the edge.
The one published by the YHBT, YHL and HAND Consulting Group? ;-)
Of course, Erdos fueled that spark with a ton of coffee and some amphetamines....
Uh, how you figure? E = mc^2. 'c' is a fixed, positive constant (approx 3*10^8 m/s/s). So if 'm' is negative, so is 'E'.
Sometimes it really is best to learn by trial and error, with past experience providing some amount of guidance so that the cost of "trial' isn't quite as high.
Yes, if you locked this kid in a informational vacuum with nothing but a pile of blank paper, some pens and Galileo's first telescope and said "derive astrophysics from first principles", it'd be a total waste of time.
Fact of the matter is that this child is building on existing knowledge. He's just not accepting it wholesale. Challenging new ideas when they're new to you (even if they're not new to everyone else) is completely natural and healthy. It means your B.S. detector is functioning and that you don't just take knowledge on authority.
It's amazing that something so invisible can be such a strong sticking point, but I'm with you 100% on this. Even Fortran and TCL are more forgiving on this count.
I work directly with a VLIW architecture myself (the TI C6000 family of DSPs). From that perspective, I'm a little sad to see Itanium go. I realize EPIC isn't exactly VLIW, but they had an awful lot in common. Much of HP's and Intel's compiler research helps us other VLIW folks too.
I think EPIC tried to live up to its name a little too much. The original Merced overreached, and so it ended up shipping far too late for its performance to be compelling. Everybody always zooms in on the lackluster x86 performance, but x86 wasn't at all interesting in the spaces Itanium wanted to play in originally. It wanted to go after the markets dominated by non-x86 architectures such as Alpha, PA-RISC, MIPS and SPARC. And had it come out about 3 years earlier, it may've had a chance there by thinning the field and consolidating the high-end server space behind EPIC.
Instead, it launched late as a room-heating yawner. And putting crappy x86 emulation on board only tempted comparisons to the native x86 line. That it made it all the way to Poulson is rather impressive, but smells more like contractual obligation than anything else.
Rest in peace, Itanium.
You mean these generous blobs of thermal paste?
I found the article maddeningly vague, while that 8% number they threw out there strangely precise. Do you have a link to anything that says more specifically what they're doing? Your description sounds roughly like I was expecting (ie. sizing adders and multipliers to the actual needs of the problem rather than throwing standard sizes at them unthinkingly), but the article sorta treated transistors and logic as "magic" and their technique as "advanced magic". *eyeroll*
From what I remember, during time changes or other corrections, they'd shift the minute hand's gear to match the second hand until the clocks displayed the right time. The shift-in and shift-out happened right at the 12 o'clock position.
As a result, the motor still ran at the same rate, and at no point did any hand move faster than 6 degrees/second. Nonetheless, the displayed time would advance at 60x normal rate.
It's the kind of thing that could be handled with a simple shifting mechanism that changed which gear drove the minute hand. Even simpler than VTEC.
It wasn't anything too special. I built a pretty basic Phenom II x4 box. Here's a cut/paste from my Newegg receipt, minus prices.
Now, I didn't buy a fancy video card. That total rig, though, cost me less than $1K and that was a few months ago.
I have 16GB RAM in my 64-bit machine at home. I actually look forward to THP, since any process that actually benefits from that much RAM would also benefit from THP if it isn't already using hugetlbfs. As far as I can tell, hugetlbfs almost never gets used, so that means just about any process that I'd run that needs that much RAM would benefit from THP.
The other day I edited a page-sized full color scan in The Gimp at 600 DPI without swapping. That was actually pretty cool. That's an app that'd benefit from THP.
And it wasn't even a functioning goatse. Kids these days.
Why delete when you can just get a bigger hard drive?
My facepalm story of the day. When I ordered a laptop upgrade at work, I picked one from our internal catalog with a nice, hi-res display. 1680x1050 was the highest res display I could find without going to a 17" dreadnought. So, it arrives and the display is all blurry. The tech had set it to 1024x768. I asked him why he did that. He said most people who get this and similar laptops complain about "their icons and fonts are too small" if they set them to the native resolution, so it was standard practice to set them to a lower resolution.
*facepalm*