I haven't had a problem with my two-year-old Hauppage WinTV (with FM tuner) card. I fire off a ffmpeg cron job every night that records the sound to the Lehrer Newshour, so I can listen to it from my cube at school. Works like a champ. Initially getting a decent version of the video4linux drivers was a problem, but I think that's fixed in the 2.4.x kernels.
As far as tuning goes, the TV signal is extremely bad through the antenna for me, but it acceptably fine with cable (well, as good as crummy AT&T wiring can be).
To add more fuel to myths/rumors/lies, the story I heard was that they had particularly poor yield in the coprocessor region of the 486 die. It doesn't seem hard to believe that certain aggressive component layouts would be more susceptible to manufacturing faults than others.
Intel would rather than have a part they can sell for less (a 486 minus the coprocessor) rather than a completely "broken" and unmarketable part.
Additional words of warning: the Sony MDR-NC20's also have a bit of a hiss which you can hear when they aren't playing anything.
Once I put on music, the hiss either disappears or my brain ignores it. In any case, these do a decent job at reducing fan/hard drive noise when I'm in computer labs and at home. They look a little flimsy (almost all plastic, looks like it'll break any minute now -- but is actually pretty tough). They've taken over two years of abuse from me and are still in good condition. The cheap ones from avshop definitely have an appealing price, though I'm not sure I'd want the dongle with 2 AAA batteries in it.
I guess the danger of browsing the dell support forums is that you see an overwhelmingly negative view of their products. Very few people go there if their hardware works, so there aren't many success reports (I don't remember seeing any for Linux).:)
I have an FP2000 running with the analog connection right now (my video card is a Matrox Millenium 2, hardly a match for the display). I'm curious about whether you had any problems getting the 2000FP to work with X11 in DVI mode at 1600x1200 or if you're using Windows...
Thanks!
(For those who don't know, the dell support forums are full of problem reports trying to get this think to work at 1600x1200 with DVI connections)
>That's the problem with a lot of Ask Slashdots - the person asking really cannot give a lot of information about his needs, so we cannot weed out suggestions that won't work.
Nor will s/he give information about which frequencies *are* good. If a clue isn't given, expect plenty of useless answers. In addition, there is no justification for why a wired connection isn't optimal (and how "optimal" is defined in this situation). It almost seems as if this person doesn't want an answer!
>pi=4/1-4/3+4/5-4/7+4/9-4/11+4/13-4/15+4/17-4/19+. .. When I was 12, I wrote a little gwbasic program on my IBM PC using this algorithm. Granted, my algorithmic skills were really bad then (and I didn't know much about floating point errors). After running for three weeks straight, it settled on 3.14288...
Google is unique in that it doesn't really matter whether the latest data is in its cache or not, or even if they lose it or not. It could take a hit, even lose all of the data that it crawled through yesterday, yet still have an operational site (I know I wouldn't be able to tell the difference, could you?)
You don't want your bank using the same unreliable hardware. Do you want to wait a week while the maintenance guy comes along to replace the failed node that held the records of your last deposit?
Mainframes are built for customers who simply can't take downtime or data loss. Some businesses can, many can't. If you build a bank off this idea, let me know. I'll be sure to stay away.
> Actually, I got stocking stuffers -- "safety hammers." These are the orange, weighted hammers for smashing auto glass, with a notch protecting a blade for slicing seatbelts etc.
If you have decent organizational skills, you should be able to do that with paper. If you don't, you'll take more than a minute whether or not you have an application helping you.
Serious VMs go back a bit further than that. Burroughs (now Unisys) built a line of machines in the 70's that could emulate any machine of the day up to the native machine width with the right microcode. The machines were actually quite fast for the time (they only sold crippled versions of the machine, since it could nip at the heels of the native large-scale systems).
If you're interested, search for the Burroughs B1700 and B1800 on google. There's also a little orange book by Organick that describes how the hardware, host, and guest code worked together to do things like emulate the IBM 360.
You're partly on crack. Intel's Xeon processors have used 36-bit addressing (through PAE, physical addressing extension) for several years now. That gives a 64GB address space which you could use for a gigantic in-core file cache.
You can't easily use this memory within a single process. DMBSs such as MS SQL Server and Oracle can take advantage of it, but they have to do their own memory management, anyway. A file cache could probably be implemented in a similar manner. Unfortunately for the people who try to build big iron machines out of Intel boxes, a 64GB address space is pretty small.
Self-modifying code is a horrible burden for the L1 caches. If you allow writes to code pages, the processor must treat the writes as data writes in the L1 D-cache. This means that there are now two different versions of the same cache line in the cache heirarchy, which means you need to keep them coherent. This means there has to be coherency between the L1 I-cache and L1 D-cache. Yuck.
It's going to take more than 1 cycle to keep those lines coherent, which is going to increase your average I-cache latency (and is exactly what you're trying to avoid). You really don't want to do this on modern processors. Besides, if your inner loop is big enough to thrash in your I-cache, you've got bigger problems (pun intended)... and if it's not big enough, you're not going through that slow memory bus, are you?
Bottom line: self-modifying code is a bad idea.
Second bottom line: Modern Java JITs end up doing this sort of thing, which gives computer architects a major headache!
The problem is at runtime, not compilation. Builds were done on one machine. Beyond the compilation step, header files do not matter, but the programs still crashed with gcc problems. When you start a program, it attempts to dynamically link with glibc shared objects. If the runtime linking doesn't work properly, you generally get a segfault.
It turned out that the way I debugged it was to get login permission on the remote machines and run builds on the machines by hand. I later learned about a number of other switches I could have added to my condor submission script that would have logged stdout and stderr.
This actually has nothing to do with the kernel or header files. It's purely a glibc mismatch.
I've had bad experiences with this in a Condor cluster of linux machines which had different versions of glibc. Seemingly randomly, my jobs would blow up into the netherworld without running and without an error message. Until the administrators matched all of the glibc's (but not the linux distributions, for some reason), I had to compile everything with -static on one machine and pray.
I wonder how much of a problem network bandwidth is in this system. With Condor, moving large datasets between machines is a problem. Object files can be pretty big and if you have a lot of them, you might risk pushing the compile bottleneck to the network. Even worse might be the link step, where all of the objects have to be visible to one machine (gcc doesn't have incremental linking yet, does it?).
Slashdot Mirror
Yes, but it's probably just college students returning to high-bandwidth dorm connections at school.
I haven't had a problem with my two-year-old Hauppage WinTV (with FM tuner) card. I fire off a ffmpeg cron job every night that records the sound to the Lehrer Newshour, so I can listen to it from my cube at school. Works like a champ. Initially getting a decent version of the video4linux drivers was a problem, but I think that's fixed in the 2.4.x kernels.
As far as tuning goes, the TV signal is extremely bad through the antenna for me, but it acceptably fine with cable (well, as good as crummy AT&T wiring can be).
To add more fuel to myths/rumors/lies, the story I heard was that they had particularly poor yield in the coprocessor region of the 486 die. It doesn't seem hard to believe that certain aggressive component layouts would be more susceptible to manufacturing faults than others.
Intel would rather than have a part they can sell for less (a 486 minus the coprocessor) rather than a completely "broken" and unmarketable part.
Additional words of warning: the Sony MDR-NC20's also have a bit of a hiss which you can hear when they aren't playing anything.
Once I put on music, the hiss either disappears or my brain ignores it. In any case, these do a decent job at reducing fan/hard drive noise when I'm in computer labs and at home. They look a little flimsy (almost all plastic, looks like it'll break any minute now -- but is actually pretty tough). They've taken over two years of abuse from me and are still in good condition. The cheap ones from avshop definitely have an appealing price, though I'm not sure I'd want the dongle with 2 AAA batteries in it.
Excellent!
:)
I guess the danger of browsing the dell support forums is that you see an overwhelmingly negative view of their products. Very few people go there if their hardware works, so there aren't many success reports (I don't remember seeing any for Linux).
Thanks a lot!
I have an FP2000 running with the analog connection right now (my video card is a Matrox Millenium 2, hardly a match for the display). I'm curious about whether you had any problems getting the 2000FP to work with X11 in DVI mode at 1600x1200 or if you're using Windows...
Thanks!
(For those who don't know, the dell support forums are full of problem reports trying to get this think to work at 1600x1200 with DVI connections)
>That's the problem with a lot of Ask Slashdots - the person asking really cannot give a lot of information about his needs, so we cannot weed out suggestions that won't work.
Nor will s/he give information about which frequencies *are* good. If a clue isn't given, expect plenty of useless answers. In addition, there is no justification for why a wired connection isn't optimal (and how "optimal" is defined in this situation). It almost seems as if this person doesn't want an answer!
>Now, if someone would make a half-decent IMAP *client* ... :)
My "pride and joy" ezimail
>pi=4/1-4/3+4/5-4/7+4/9-4/11+4/13-4/15+4/17-4/19+. . .
When I was 12, I wrote a little gwbasic program on my IBM PC using this algorithm. Granted, my algorithmic skills were really bad then (and I didn't know much about floating point errors). After running for three weeks straight, it settled on 3.14288...
I was horribly disappointed.
Google is unique in that it doesn't really matter whether the latest data is in its cache or not, or even if they lose it or not. It could take a hit, even lose all of the data that it crawled through yesterday, yet still have an operational site (I know I wouldn't be able to tell the difference, could you?)
You don't want your bank using the same unreliable hardware. Do you want to wait a week while the maintenance guy comes along to replace the failed node that held the records of your last deposit?
Mainframes are built for customers who simply can't take downtime or data loss. Some businesses can, many can't. If you build a bank off this idea, let me know. I'll be sure to stay away.
> Actually, I got stocking stuffers -- "safety hammers." These are the orange, weighted hammers for smashing auto glass, with a notch protecting a blade for slicing seatbelts etc.
Are these for breaking into cars or out of them?
If you have decent organizational skills, you should be able to do that with paper. If you don't, you'll take more than a minute whether or not you have an application helping you.
Serious VMs go back a bit further than that. Burroughs (now Unisys) built a line of machines in the 70's that could emulate any machine of the day up to the native machine width with the right microcode. The machines were actually quite fast for the time (they only sold crippled versions of the machine, since it could nip at the heels of the native large-scale systems).
If you're interested, search for the Burroughs B1700 and B1800 on google. There's also a little orange book by Organick that describes how the hardware, host, and guest code worked together to do things like emulate the IBM 360.
1 : to introduce as or as if new
2 archaic : to effect a change in
intransitive senses : to make changes : do something in a new way
You're partly on crack. Intel's Xeon processors have used 36-bit addressing (through PAE, physical addressing extension) for several years now. That gives a 64GB address space which you could use for a gigantic in-core file cache.
You can't easily use this memory within a single process. DMBSs such as MS SQL Server and Oracle can take advantage of it, but they have to do their own memory management, anyway. A file cache could probably be implemented in a similar manner. Unfortunately for the people who try to build big iron machines out of Intel boxes, a 64GB address space is pretty small.
Self-modifying code is a horrible burden for the L1 caches. If you allow writes to code pages, the processor must treat the writes as data writes in the L1 D-cache. This means that there are now two different versions of the same cache line in the cache heirarchy, which means you need to keep them coherent. This means there has to be coherency between the L1 I-cache and L1 D-cache. Yuck.
It's going to take more than 1 cycle to keep those lines coherent, which is going to increase your average I-cache latency (and is exactly what you're trying to avoid). You really don't want to do this on modern processors. Besides, if your inner loop is big enough to thrash in your I-cache, you've got bigger problems (pun intended)... and if it's not big enough, you're not going through that slow memory bus, are you?
Bottom line: self-modifying code is a bad idea.
Second bottom line: Modern Java JITs end up doing this sort of thing, which gives computer architects a major headache!
Yes, but this one is just full of innuendo:
ActiMates: How to play with Barney
The problem is at runtime, not compilation. Builds were done on one machine. Beyond the compilation step, header files do not matter, but the programs still crashed with gcc problems. When you start a program, it attempts to dynamically link with glibc shared objects. If the runtime linking doesn't work properly, you generally get a segfault.
It turned out that the way I debugged it was to get login permission on the remote machines and run builds on the machines by hand. I later learned about a number of other switches I could have added to my condor submission script that would have logged stdout and stderr.
This actually has nothing to do with the kernel or header files. It's purely a glibc mismatch.
I've had bad experiences with this in a Condor cluster of linux machines which had different versions of glibc. Seemingly randomly, my jobs would blow up into the netherworld without running and without an error message. Until the administrators matched all of the glibc's (but not the linux distributions, for some reason), I had to compile everything with -static on one machine and pray.
I wonder how much of a problem network bandwidth is in this system. With Condor, moving large datasets between machines is a problem. Object files can be pretty big and if you have a lot of them, you might risk pushing the compile bottleneck to the network. Even worse might be the link step, where all of the objects have to be visible to one machine (gcc doesn't have incremental linking yet, does it?).
They're up to 90 watts now? I was amazed that my i8100 had a 70W power brick.
Lemme guess, you work for the DMV.
That means the new expense system can hide the expense of writing the expense system for only the expense of the CIO/CTO. Fancy that!
Does the cost of supplies include the fax machine or computer that is receiving the fax? Or is it just the consumable supplies?
NT/2000 implemented some portions of the POSIX standard. It left out some fairly significant things like POSIX threads, signals, etc...
.net would not include the POSIX support layer anymore.
A little bird said that
Nice Try.