As much as I love Sarrio's products (His "universal" products are closer to being universal than anyone else, at least in ham radio circles), those "universal" chargers are such bullshit.
So what if it supports your battery chemistry? If it doesn't support the physical interface of your battery, it doesn't matter.
I'm willing to bet that that Sarrio charger doesn't do Dell batteries - Sarrio's specialty is two-way radio (esp. amateur radio), his notebook solutions are lacking.
If you're a ham, Sarrio and Batteries America (Actually, Batteries America may be owned by Sarrio, I can't remember) are amazing.
Think of it similar to an asymmetric net connection (cable modem, DSL) - It's optimized to transfer data REALLY FAST in only one direction.
Despite the obscene bandwidth of AGP, a few months ago there was an article on/. pointing to some people who ran some tests on capture from the framebuffer - They managed 10 FPS even at 640x480. PCI can do 30 fps raw video at 640x480 without breaking a sweat. (Look at any Bt8x8-based TV tuner card)
AGP's primary goal is to accelerate texture uploads, but in modern video cards, as one other person pointed out, there's a lot of other data that needs to be uploaded too.
Also, I recall (long ago), John Carmack talking about various limitations in video subsystems, and at that time, simply sending geometry data was beginning to saturate PCI buses. As polygon counts increase, I think that factor will be more and more important.
They'll have the knowledge to change their MAC (or find it easily)
Cheat programs are inherently "underground" programs, wherease you can find MAC changing references everywhere.
And it won't be long before a hacked version of this client becomes available that doesn't even require you to change your local MAC, it'll just misreport it. So no issues with the cable modem provider.
My first instinct was a reply saying, "PLEASE don't misspell the OS name!" I've seen too many people raving about their Sybian phones - Or does such a thing exist?:)
One of the guys heavily involved in that project is no longer at Caltech, but is a professor at Cornell University now.
http://vlsi.cornell.edu/~rajit/
One of the best (albeit toughest) profs I've ever had. This guy knows his stuff, and is very good at passing the knowledge on.:)
Happens to be responsible for Cornell's only FreeBSD lab, which the CS students prefer to the CS department's own systems. Many of them continue using the CSL lab long after finishing ECE/CS 314. (Req'd for all ECE and CS majors.)
In CMOS logic, power consumption is not related too much to the static state of the chips, i.e. "transistor is on for 5 ps".
It's related to how often the state change occurs.
A good example of where async logic might be useful: ALU multiply operation takes 20 pS, LOTS of transistors ALU add/subtract op takes 5, FAR fewer transistors In current designs, this usually means that add/subtract ops have to run at a clock rate that is slow enough to accomodate that 20 pS clock In an async design, the add/subtract instructions can run 4 times as fast. But since the multiply/divide stage is not clocked, those transistors aren't doing anything so overall power usage is less. (The add/subtract stage uses 4x the power it did before, but the mult/div stage was probably using 10x or more the power the add/sub stage was using)
You'll notice that Cadence (one of the big EDA software companies) is cooperating with/heavily investing in one of the async hardware companies. It's not an untapped opportunity - They're tapping it as we post.:)
In most modern CPUs, all of those occur independently in different units in the pipeline.
But they still do their function once per global clock cycle. After that, they pass their results on to the next stage.
As a result, the clock rate is limited by the longest propagation time across a given pipeline stage. A solution that allows for higher clock speeds is to increase the number of pipeline stages. This means that each stage has to do less. (The P4 one-ups this by having stages that are the equivalent of a NOP just to propagate the signal across the chip. But they're still globally clocked and synchronous.)
P4 has (I believe) a 20-stage pipeline. (It's in that ballpark) - The Athlon is sub-10, as are almost all other CPUs. This is why the P4 can achieve such a high clockrate, but it's average performance often suffers. (Once you have a 20-stage pipeline, you have to make guesses when branching as to WHICH branch you're going to go on. Mispredict and you have to start over again, paying a clock cycle penalty.)
Shorter pipelines can get around the branch misprediction issue by simply dictating that certain instruction orders are invalid. (For example, the MIPS architecture states that the instruction in memory after a branch instruction will always be executed, removing the main pipeline dependency issue in MIPS CPUs.)
With asynch logic, each stage can operate independently. I see a MAJOR boon in ALU performance - Adds/subtracts/etc. take up FAR less propagation time than multiplies/divides - but in synch logic the ALU has to operate at the speed of the slowest instruction.
Most important is the issue of power consumption - CMOS logic consumes almost no power when static (i.e. not changing its state), power consumption is almost exactly a linear function of how often the state changes, i.e. how fast the clock is going. With async logic, if there's no need for a state change (i.e. a portion of the CPU is running idle), almost no power consumed. It is possible to get some advantages in power consumption simply by changing the clock speed. (e.g. Intel SpeedStep allows you to change between two clock multiplier values dynamically, Transmeta's LongRun gives you FAR more control points and saves even more power, many Motorola microcontrollers such as the DragonBall series can adjust their clock speed in small steps - One Moto uC can adjust from 32 kHz to 16 MHz with a software command.)
You obviously have no clue what you're talking about. The "alt-tab" bug is an APPLICATION problem, not an OS problem. (Well, maybe a generic Win32 problem)
Win2k doesn't help you in the situations the original poster is talking about. Neither does XP. I have firsthand experience with this issue with DAoC under 98SE, Win2k, and WinXP. (Currently running 2k)
I think John Carmack would disagree with you here.
In fact, a few years ago, after leaving MS, the guy in charge of marketing DirectX admitted that DX was inferior to OpenGL and had some SERIOUS flaws. (Mainly, a REALLY ugly and unclean API - GLQuake was done in a VERY short time, whereas Carmack said that after looking at the ugliness of the DX APIs he didn't even know where to start)
Let's not forget that a lot of features that are "bleeding edge" in DX are usually standardized long before in OpenGL. (This can be attributed to the fact that OGL has a heritage in high-end graphics, which usually leads consumer 3D by a year or two or more, or at least used to.)
Also, OpenGL is fully cross-platform, wherease DX is extremely closely tied down to Win32 - Another strike against DX.
He states that DAoC doesn't run under WineX, and that the people on Transgaming's site have actively been devoting any and all RPGs with a scant few exceptions. (I've seen this firsthand. I retaliate by negatively nuking every non-RPG I see.)
You then state that DAoC is the only thing keeping Windows on your machine...
p.s. What server/realm? 44 theurg (Ezra) Lancelot Albion
It IS possible (read the forums) to get beyond the patcher.
The patcher opens up a VERY large number of files, larger than the default max # of open files under most distros. There's info on the forums on how to increase this number.
Of course, you don't get very far beyond the patcher...:(
I thought this was a marketing gimmick until I forgot to enable DMA on my new 48x burner.
Needless to say, hundreds of buffer-empty conditions and the CD still wasn't a coaster.
I'm a former SCSI afficionado - I now have a pure IDE system. (I eventually will plug in my 6-disc SCSI changer that I got at a garage sale for $10, but other than that my system is now SCSI free.)
SCSI cabling is far more sensitive to problems/glitches than IDE, so often I would spend an hour trying to get my SCSI chain working after moving the system. Eventually something was going wrong in the SCSI bus that was randomly corrupting data that I couldn't track down. I bought an 80 gig Maxtor (Apparently they've shaped up a LOT in the past few years from all I've heard) and have only once looked back. (For some reason IDE drives suck for ripping CD audio.)
Except for the smallest of businesses, more than 1 AP is needed.
My building has at least 4. (Using Cisco LEAP - Our admins aren't stupid.) I believe one in each end (north/south) on each floor. I would classify ourselve as medium/small. (2-floor building, not that large. There are MANY office buildings in this area that are MUCH larger)
http://www.kismetwireless.net/ While it wouldn't be implemented on the AP itself, 3-4 cheapo PCs with WLAN cards could easily be set up as packet sniffers that would show signal strength of all clients in the area.
http://www.instant802.com/ (I think) - AP with open firmware.
I think this is a variation of the Leidenfrost effect that allows you to dip your fingers in LN2 for VERY short periods of time.
It is more than possible to touch dry ice without "burning" yourself. In fact, you can pick it up and toss it without any problems.
My senior year in college, the Society of Physics Students put on a school-sponsored party. (Basically, they got paid to host a non-alcoholic event...)
Among the attractions were - Liquid Nitrogen ice cream (Make IC in 5 minutes or less...) Misc. optics crap Model of the Mars Rover LOTS of dry ice for various demos. People were playing air hockey with a small chunk. (The sublimation gave you air hockey w/o the air table). It also makes this neat whining sound when you cut it with warm metal. A bunch of us also played "Hot Potato" (or more appropriately, Cold Potato) with it. No burns.
There's nothing special in the RF portions (except for the signal generator, but you could probably do just fine with a DDS synthesizer sold in many kits for amateur radio use)
Haven't checked on the "student use" amp, but the high-power amplifier, the Ameritron AH-811A, happens to be a very common (and one of the cheapest) amateur radio tube amplifiers. (Mainly due to the use of three small and cheap 811A type tubes rather than single monster Eimac/Svetlana high-power tubes) - I believe the 3-tube 811A model is around 500-750 watts.
Legal limit on the ham bands is 1500 watts, so finding HF amplifiers up to this power is easy as pie.
As to why I don't know too much about the 50W driver amp - Most amateur HF rigs in the HF bands have 50-100W output, so can drive most tube amps (even the legal-limit variety) directly.
To get accurate temperature info from thermal images, you need to paint everything you're imaging. (Usually black - Get it as close to an ideal black body as possible). Otherwise, some colors are better radiators than others and will appear warmer on the camera at the same temperature.
That said, even unpainted, a thermal camera can tell you, "Something is really heating up quickly... That isn't right..."
The last word means that convection and conduction are no longer options for getting rid of heat.
Vacuum happens to be an excellent insulator...
And when the station is in direct sunlight it heats up VERY quickly. You can expect temperature swings for something in orbit to go from freezing cold to burning hot - Often in the course of a few minutes.
I was involved at school in designing a small satellite (See cubesat.org for a general description of this class of satellite) - I was (fortunately) handling the radio board, and wasn't one of the thermal guys. I felt sorry for them...
During dark times, the satellite had to have small heaters to keep the batteries from freezing.
20-30 minutes later in the orbit, the satellite's problem would be overheating.
I think it would be safe to say that risky hdparm flags should be an option ENABLED by an expert install, not DISABLED only in an expert install (i.e. on by default).
Slashdot Mirror
As much as I love Sarrio's products (His "universal" products are closer to being universal than anyone else, at least in ham radio circles), those "universal" chargers are such bullshit.
So what if it supports your battery chemistry? If it doesn't support the physical interface of your battery, it doesn't matter.
I'm willing to bet that that Sarrio charger doesn't do Dell batteries - Sarrio's specialty is two-way radio (esp. amateur radio), his notebook solutions are lacking.
If you're a ham, Sarrio and Batteries America (Actually, Batteries America may be owned by Sarrio, I can't remember) are amazing.
Think of it similar to an asymmetric net connection (cable modem, DSL) - It's optimized to transfer data REALLY FAST in only one direction.
/. pointing to some people who ran some tests on capture from the framebuffer - They managed 10 FPS even at 640x480. PCI can do 30 fps raw video at 640x480 without breaking a sweat. (Look at any Bt8x8-based TV tuner card)
Despite the obscene bandwidth of AGP, a few months ago there was an article on
AGP's primary goal is to accelerate texture uploads, but in modern video cards, as one other person pointed out, there's a lot of other data that needs to be uploaded too.
Also, I recall (long ago), John Carmack talking about various limitations in video subsystems, and at that time, simply sending geometry data was beginning to saturate PCI buses. As polygon counts increase, I think that factor will be more and more important.
They'll have the knowledge to change their MAC (or find it easily)
Cheat programs are inherently "underground" programs, wherease you can find MAC changing references everywhere.
And it won't be long before a hacked version of this client becomes available that doesn't even require you to change your local MAC, it'll just misreport it. So no issues with the cable modem provider.
My first instinct was a reply saying, "PLEASE don't misspell the OS name!" I've seen too many people raving about their Sybian phones - Or does such a thing exist? :)
One of the guys heavily involved in that project is no longer at Caltech, but is a professor at Cornell University now.
:)
http://vlsi.cornell.edu/~rajit/
One of the best (albeit toughest) profs I've ever had. This guy knows his stuff, and is very good at passing the knowledge on.
Happens to be responsible for Cornell's only FreeBSD lab, which the CS students prefer to the CS department's own systems. Many of them continue using the CSL lab long after finishing ECE/CS 314. (Req'd for all ECE and CS majors.)
In CMOS logic, power consumption is not related too much to the static state of the chips, i.e. "transistor is on for 5 ps".
It's related to how often the state change occurs.
A good example of where async logic might be useful:
ALU multiply operation takes 20 pS, LOTS of transistors
ALU add/subtract op takes 5, FAR fewer transistors
In current designs, this usually means that add/subtract ops have to run at a clock rate that is slow enough to accomodate that 20 pS clock
In an async design, the add/subtract instructions can run 4 times as fast. But since the multiply/divide stage is not clocked, those transistors aren't doing anything so overall power usage is less. (The add/subtract stage uses 4x the power it did before, but the mult/div stage was probably using 10x or more the power the add/sub stage was using)
You'll notice that Cadence (one of the big EDA software companies) is cooperating with/heavily investing in one of the async hardware companies. It's not an untapped opportunity - They're tapping it as we post. :)
In most modern CPUs, all of those occur independently in different units in the pipeline.
But they still do their function once per global clock cycle. After that, they pass their results on to the next stage.
As a result, the clock rate is limited by the longest propagation time across a given pipeline stage. A solution that allows for higher clock speeds is to increase the number of pipeline stages. This means that each stage has to do less. (The P4 one-ups this by having stages that are the equivalent of a NOP just to propagate the signal across the chip. But they're still globally clocked and synchronous.)
P4 has (I believe) a 20-stage pipeline. (It's in that ballpark) - The Athlon is sub-10, as are almost all other CPUs. This is why the P4 can achieve such a high clockrate, but it's average performance often suffers. (Once you have a 20-stage pipeline, you have to make guesses when branching as to WHICH branch you're going to go on. Mispredict and you have to start over again, paying a clock cycle penalty.)
Shorter pipelines can get around the branch misprediction issue by simply dictating that certain instruction orders are invalid. (For example, the MIPS architecture states that the instruction in memory after a branch instruction will always be executed, removing the main pipeline dependency issue in MIPS CPUs.)
With asynch logic, each stage can operate independently. I see a MAJOR boon in ALU performance - Adds/subtracts/etc. take up FAR less propagation time than multiplies/divides - but in synch logic the ALU has to operate at the speed of the slowest instruction.
Most important is the issue of power consumption - CMOS logic consumes almost no power when static (i.e. not changing its state), power consumption is almost exactly a linear function of how often the state changes, i.e. how fast the clock is going. With async logic, if there's no need for a state change (i.e. a portion of the CPU is running idle), almost no power consumed. It is possible to get some advantages in power consumption simply by changing the clock speed. (e.g. Intel SpeedStep allows you to change between two clock multiplier values dynamically, Transmeta's LongRun gives you FAR more control points and saves even more power, many Motorola microcontrollers such as the DragonBall series can adjust their clock speed in small steps - One Moto uC can adjust from 32 kHz to 16 MHz with a software command.)
You obviously have no clue what you're talking about. The "alt-tab" bug is an APPLICATION problem, not an OS problem. (Well, maybe a generic Win32 problem)
Win2k doesn't help you in the situations the original poster is talking about. Neither does XP. I have firsthand experience with this issue with DAoC under 98SE, Win2k, and WinXP. (Currently running 2k)
I think John Carmack would disagree with you here.
In fact, a few years ago, after leaving MS, the guy in charge of marketing DirectX admitted that DX was inferior to OpenGL and had some SERIOUS flaws. (Mainly, a REALLY ugly and unclean API - GLQuake was done in a VERY short time, whereas Carmack said that after looking at the ugliness of the DX APIs he didn't even know where to start)
Let's not forget that a lot of features that are "bleeding edge" in DX are usually standardized long before in OpenGL. (This can be attributed to the fact that OGL has a heritage in high-end graphics, which usually leads consumer 3D by a year or two or more, or at least used to.)
Also, OpenGL is fully cross-platform, wherease DX is extremely closely tied down to Win32 - Another strike against DX.
What's your problem with his post?
He states that DAoC doesn't run under WineX, and that the people on Transgaming's site have actively been devoting any and all RPGs with a scant few exceptions. (I've seen this firsthand. I retaliate by negatively nuking every non-RPG I see.)
You then state that DAoC is the only thing keeping Windows on your machine...
p.s. What server/realm? 44 theurg (Ezra) Lancelot Albion
It IS possible (read the forums) to get beyond the patcher.
:(
The patcher opens up a VERY large number of files, larger than the default max # of open files under most distros. There's info on the forums on how to increase this number.
Of course, you don't get very far beyond the patcher...
The HP DVD recorders suffer from serious compatibility problems.
Who cares if it burns faster if you're burning what are essentially coasters?
I thought this was a marketing gimmick until I forgot to enable DMA on my new 48x burner.
Needless to say, hundreds of buffer-empty conditions and the CD still wasn't a coaster.
I'm a former SCSI afficionado - I now have a pure IDE system. (I eventually will plug in my 6-disc SCSI changer that I got at a garage sale for $10, but other than that my system is now SCSI free.)
SCSI cabling is far more sensitive to problems/glitches than IDE, so often I would spend an hour trying to get my SCSI chain working after moving the system. Eventually something was going wrong in the SCSI bus that was randomly corrupting data that I couldn't track down. I bought an 80 gig Maxtor (Apparently they've shaped up a LOT in the past few years from all I've heard) and have only once looked back. (For some reason IDE drives suck for ripping CD audio.)
Big problem with your system - The Pringles antenna
Using an antenna like this will make your position fix dependent on not only the client's position but on its orientation too.
I suggest trying an omnidirectional antenna of some sort. (http://www.aerialix.com/ has cheap kits based on the Guerrilla.net designes)
The Mattel Power Glove also worked this way
Well, I see you've already been modded down.
Good.
Except for the smallest of businesses, more than 1 AP is needed.
My building has at least 4. (Using Cisco LEAP - Our admins aren't stupid.) I believe one in each end (north/south) on each floor. I would classify ourselve as medium/small. (2-floor building, not that large. There are MANY office buildings in this area that are MUCH larger)
http://www.kismetwireless.net/
While it wouldn't be implemented on the AP itself, 3-4 cheapo PCs with WLAN cards could easily be set up as packet sniffers that would show signal strength of all clients in the area.
http://www.instant802.com/ (I think) - AP with open firmware.
While not a kernel error, and one that is a BITCH to reproduce. (I don't know how you'd get it without intentionally damaging your system...)
"You don't exist. Go away."
I believe it can be achieved something like this:
Log in as user
Delete user from all password files
I think this is a variation of the Leidenfrost effect that allows you to dip your fingers in LN2 for VERY short periods of time.
It is more than possible to touch dry ice without "burning" yourself. In fact, you can pick it up and toss it without any problems.
My senior year in college, the Society of Physics Students put on a school-sponsored party. (Basically, they got paid to host a non-alcoholic event...)
Among the attractions were - Liquid Nitrogen ice cream (Make IC in 5 minutes or less...)
Misc. optics crap
Model of the Mars Rover
LOTS of dry ice for various demos. People were playing air hockey with a small chunk. (The sublimation gave you air hockey w/o the air table). It also makes this neat whining sound when you cut it with warm metal.
A bunch of us also played "Hot Potato" (or more appropriately, Cold Potato) with it. No burns.
There's nothing special in the RF portions (except for the signal generator, but you could probably do just fine with a DDS synthesizer sold in many kits for amateur radio use)
Haven't checked on the "student use" amp, but the high-power amplifier, the Ameritron AH-811A, happens to be a very common (and one of the cheapest) amateur radio tube amplifiers. (Mainly due to the use of three small and cheap 811A type tubes rather than single monster Eimac/Svetlana high-power tubes) - I believe the 3-tube 811A model is around 500-750 watts.
Legal limit on the ham bands is 1500 watts, so finding HF amplifiers up to this power is easy as pie.
As to why I don't know too much about the 50W driver amp - Most amateur HF rigs in the HF bands have 50-100W output, so can drive most tube amps (even the legal-limit variety) directly.
To get accurate temperature info from thermal images, you need to paint everything you're imaging. (Usually black - Get it as close to an ideal black body as possible). Otherwise, some colors are better radiators than others and will appear warmer on the camera at the same temperature.
That said, even unpainted, a thermal camera can tell you, "Something is really heating up quickly... That isn't right..."
The last word means that convection and conduction are no longer options for getting rid of heat.
Vacuum happens to be an excellent insulator...
And when the station is in direct sunlight it heats up VERY quickly. You can expect temperature swings for something in orbit to go from freezing cold to burning hot - Often in the course of a few minutes.
I was involved at school in designing a small satellite (See cubesat.org for a general description of this class of satellite) - I was (fortunately) handling the radio board, and wasn't one of the thermal guys. I felt sorry for them...
During dark times, the satellite had to have small heaters to keep the batteries from freezing.
20-30 minutes later in the orbit, the satellite's problem would be overheating.
I think it would be safe to say that risky hdparm flags should be an option ENABLED by an expert install, not DISABLED only in an expert install (i.e. on by default).