It is when programming DSP's (and related devices).
From my experience, yes and no. Fixed-point DSP tends to be done in assembly, mainly because FP techniques don't translate well to C. The compilers also tend to suck. A fair to large amount of floating-point DSP is done with C when the compiler support is good. I have done a lot of floating-point DSP, and we found that the write in C, refine in ASM workflow was best.
Don't forget that microcontrollers outnumber microprocessors by a large margin.
That is true. I usually refer to this as "high" embedded versus "low" embedded systems. Along with DSP, I have spent my career mainly working on large, embedded systems running on microprocessors (Mot 68k, PowerPC, and some MIPS) under control of an RTOS. In this application, assembly doesn't get used as much as you think even when you are dealing with hard realtime requirements.
Even in embedded systems, assembly isn't used as much as it used to. It still get used in bootloaders, and sometimes in device drivers. However, most devices are memory mapped, and most of the driver is written in C, and asm() calls are made when appropriate (eg, asm("eieio");), especially when you get to use gcc and asm() syntax for accessing variables.
It is interesting to see how and when various operating system concepts get implemented. Interrupt threads are a pretty common technique in realtime systems, and have been around since the early 90's or so; they were the first driver technique that I learned.
It is interesting to see how and when various operating system concepts get implemented. Interrupt threads are a pretty common technique in realtime systems, and have been around since the early 90's or so; they were the first driver technique that I learned.
These switches are generally big round buttons about 2" in diameter, and almost always made out of bright red plastic. On top of that, the button take some force to depress and many facilities place a hinged, clear plexiglass box over them to prevent accidental use. It is pretty hard to mistake one for a normal light switch.
Ah, the famous History Eraser Button rears its ugly head. I think that everyone who has worked in a large datacenter or lab environment with one of these has a story to tell...
6. Most TeX distros [like tetex] are FREE and open source.
And there lot of OSS tools that support TeX. My favorite is using PARI/GP to do some math, and then using the TeX output to copy-and-paste into a document (like a journal submission). I did this for my last paper, and it worked well. The paper had to be submitted in Word format, though, so I made my editor re-enter all of the equations.:)
This, along with the fact that a lot of botnets are IRC controlled, is one of the reasons I declared IRC verbotten on our LAN and am now using the bleeding-snort IRC rules. I know they won't catch all IRC traffic, but in my mind they are worth the extra cycles.
The only thing in common is the fact that they use coaxial cable, but even then they use different impedences (10base2 is 50 Ohm, DOCSIS is 75 Ohm).
10base2 is a baseband CSMA/CD system. IIRC, the baseband encoding is Manchester.
DOCSIS is a modulated FDM/TDMA system. Upstream is QPSK, downstream varies between 64QAM and 256QAM depending on the ranging results during the initial modem negotiaions. In the US, channels are on 6 MHz spacing, and the carrier frequency is set the provider to fit in with their digital cable channels.
Some guy has a law that says you need to sample at a rate twice as frequent as the signal your sampling. Makes sense if you think about it.
That would be Mr. Nyquist. In practice, you get about 80% of the ideal bandwidth due to a non-zero transition width in the anti-alias filter and extreme group-delay at passband edge.
To be precise, you have to sample at twice the bandwith of your signal. For a lowpass signal (audio would count), this is twice the highest frequency present. For a bandpass signal (eg, RF), you can sample at twice the bandwidth of the signal(*) even though the actual frequency is much higher. This technique is known as under-sampling.
(*) Assuming the input bandwith of the sample-and-hold circuit on A/D is sufficient.
If your livelyhood depends on it, then they will find a way. If you read the specs, study implementations, read up, and start to flowchart things, then ideas like this are likely to fall out. As much as it sucks in cases like this, it is an engineer's job to figure out ways to do things that "can't be done."
Human skin may be able to detect a DC potential at 15VDC, but I have attended several training seminars that have stated that humans don't feel static discharges less than 3500 volts (reference). Most seminconductors fall in the Class 1 category in the chart on that page, so they can be damaged by a discharge that you can't feel.
As for humidity, check out this. You will see that humidity helps, but it will not prevent damaging discharges.
If you ever visit a manufacturing facility, or a hardware lab you will see several ESD control measures in place. A hydrometer will almost always be present, but that is more of a warning to call the HVAC vendor than a safe/not safe indicator for discharge. The floor will be conductive, and the engineers and techs will wear conductive sneakers or heel straps. Everyone will be wearing an approved labcoat and wriststrap. All stations will have mats which are checked frequently. Rework stations will have all of the above, and generally also have an ionizer.
So the whole static thing is dependant on where you live to a large degree.
Not really. I forget the exact number, but IIRC as little as 20V is enough to zap a component or cause a soft failure. Visible discharge is around 1000V or so. If you spend enough time working with hardware (eg, board design) you will learn the dangers of static.
I would imagine two 6800 cores would draw too much power and create too much heat for a single PCB.
The power issue doesn't really have to do with the PCB. It mainly has to do with the connector and the number of power pins. If a card draws too much power, the pins or fingers on the connector act as fuses and melt. (I have seen this happen on VME and cPCI boards.)
The parent was modded as funny, but I have always wondered about a trojan that exploited sudo, possibly through a too-permissive NOPASSWD rule, or something that exploits the window where sudo doesn't prompt for a password.
Public domain software existed before RMS started his FSF and GCC/GDB projects.
But GCC is probably the biggest reason that free software runs on just about anything now. Before GCC became widespread, porting software used to be a major bitch. GCC changed that, mainly because it was one of the first ANSI C implementations that worked well.
There are really two classes of users that need ``office'' software.
At the low end, you have most home users and students. Most of this group just needs basic wordprocessing and spreadsheet functionality. The most advanced feature would really need to be spellcheck.
At the high end, you have the business users who use a lot of the advanced features like revision tracking, charting, scheduling, etc.
I'm not really sure one suite can cover both audiences.
I'm not even sure I'd classify the Apple II or Macintosh as "revolutionary".
The Apple II may not have been revolutionary in terms of technology, but they definetly started the revolution of the way technology is used in classrooms.
The Apple II was found in a very large number of schools, even if it was just a single machine in the library, and introduced millions of children to computers.
Slashdot Mirror
It is when programming DSP's (and related devices).
From my experience, yes and no. Fixed-point DSP tends to be done in assembly, mainly because FP techniques don't translate well to C. The compilers also tend to suck. A fair to large amount of floating-point DSP is done with C when the compiler support is good. I have done a lot of floating-point DSP, and we found that the write in C, refine in ASM workflow was best.
Don't forget that microcontrollers outnumber microprocessors by a large margin.
That is true. I usually refer to this as "high" embedded versus "low" embedded systems. Along with DSP, I have spent my career mainly working on large, embedded systems running on microprocessors (Mot 68k, PowerPC, and some MIPS) under control of an RTOS. In this application, assembly doesn't get used as much as you think even when you are dealing with hard realtime requirements.Even in embedded systems, assembly isn't used as much as it used to. It still get used in bootloaders, and sometimes in device drivers. However, most devices are memory mapped, and most of the driver is written in C, and asm() calls are made when appropriate (eg, asm("eieio");), especially when you get to use gcc and asm() syntax for accessing variables.
What if the initial release of 386bsd had been before the initial linux release?
Rack mounted equipment, such as servers and storage, can also be troublesome to keep within temperature spec.
It is interesting to see how and when various operating system concepts get implemented. Interrupt threads are a pretty common technique in realtime systems, and have been around since the early 90's or so; they were the first driver technique that I learned.
Oops... posted in the wrong tab... arg.
It is interesting to see how and when various operating system concepts get implemented. Interrupt threads are a pretty common technique in realtime systems, and have been around since the early 90's or so; they were the first driver technique that I learned.
Most of the time it is Stimpy's fault. The rest of the time it is Fry's fault. I think there may be a connection...
These switches are generally big round buttons about 2" in diameter, and almost always made out of bright red plastic. On top of that, the button take some force to depress and many facilities place a hinged, clear plexiglass box over them to prevent accidental use. It is pretty hard to mistake one for a normal light switch.
Ah, the famous History Eraser Button rears its ugly head. I think that everyone who has worked in a large datacenter or lab environment with one of these has a story to tell...
6. Most TeX distros [like tetex] are FREE and open source.
And there lot of OSS tools that support TeX. My favorite is using PARI/GP to do some math, and then using the TeX output to copy-and-paste into a document (like a journal submission). I did this for my last paper, and it worked well. The paper had to be submitted in Word format, though, so I made my editor re-enter all of the equations. :)
This, along with the fact that a lot of botnets are IRC controlled, is one of the reasons I declared IRC verbotten on our LAN and am now using the bleeding-snort IRC rules. I know they won't catch all IRC traffic, but in my mind they are worth the extra cycles.
My az/el spreadsheet is at home, but the slant range for an elevation of 0deg for an antenna on the equator is about 42000km.
42000km / 300000000m/sec = 140msec
So the time of flight for an antenna pointing at the horizon is 280msec.
The only thing in common is the fact that they use coaxial cable, but even then they use different impedences (10base2 is 50 Ohm, DOCSIS is 75 Ohm).
10base2 is a baseband CSMA/CD system. IIRC, the baseband encoding is Manchester.
DOCSIS is a modulated FDM/TDMA system. Upstream is QPSK, downstream varies between 64QAM and 256QAM depending on the ranging results during the initial modem negotiaions. In the US, channels are on 6 MHz spacing, and the carrier frequency is set the provider to fit in with their digital cable channels.
Some guy has a law that says you need to sample at a rate twice as frequent as the signal your sampling. Makes sense if you think about it.
That would be Mr. Nyquist. In practice, you get about 80% of the ideal bandwidth due to a non-zero transition width in the anti-alias filter and extreme group-delay at passband edge.
To be precise, you have to sample at twice the bandwith of your signal. For a lowpass signal (audio would count), this is twice the highest frequency present. For a bandpass signal (eg, RF), you can sample at twice the bandwidth of the signal(*) even though the actual frequency is much higher. This technique is known as under-sampling.
(*) Assuming the input bandwith of the sample-and-hold circuit on A/D is sufficient.
If your livelyhood depends on it, then they will find a way. If you read the specs, study implementations, read up, and start to flowchart things, then ideas like this are likely to fall out. As much as it sucks in cases like this, it is an engineer's job to figure out ways to do things that "can't be done."
Human skin may be able to detect a DC potential at 15VDC, but I have attended several training seminars that have stated that humans don't feel static discharges less than 3500 volts (reference). Most seminconductors fall in the Class 1 category in the chart on that page, so they can be damaged by a discharge that you can't feel.
As for humidity, check out this. You will see that humidity helps, but it will not prevent damaging discharges.
If you ever visit a manufacturing facility, or a hardware lab you will see several ESD control measures in place. A hydrometer will almost always be present, but that is more of a warning to call the HVAC vendor than a safe/not safe indicator for discharge. The floor will be conductive, and the engineers and techs will wear conductive sneakers or heel straps. Everyone will be wearing an approved labcoat and wriststrap. All stations will have mats which are checked frequently. Rework stations will have all of the above, and generally also have an ionizer.
So the whole static thing is dependant on where you live to a large degree.
Not really. I forget the exact number, but IIRC as little as 20V is enough to zap a component or cause a soft failure. Visible discharge is around 1000V or so. If you spend enough time working with hardware (eg, board design) you will learn the dangers of static.
I would imagine two 6800 cores would draw too much power and create too much heat for a single PCB.
The power issue doesn't really have to do with the PCB. It mainly has to do with the connector and the number of power pins. If a card draws too much power, the pins or fingers on the connector act as fuses and melt. (I have seen this happen on VME and cPCI boards.)
The parent was modded as funny, but I have always wondered about a trojan that exploited sudo, possibly through a too-permissive NOPASSWD rule, or something that exploits the window where sudo doesn't prompt for a password.
The difference has to do with the types of changes that can be committed. Basically, it is harder to get a change approved after the RC stage.
Check out the FreeBSD Release Engineering page for more info.
Public domain software existed before RMS started his FSF and GCC/GDB projects.
But GCC is probably the biggest reason that free software runs on just about anything now. Before GCC became widespread, porting software used to be a major bitch. GCC changed that, mainly because it was one of the first ANSI C implementations that worked well.
There are really two classes of users that need ``office'' software.
At the low end, you have most home users and students. Most of this group just needs basic wordprocessing and spreadsheet functionality. The most advanced feature would really need to be spellcheck.
At the high end, you have the business users who use a lot of the advanced features like revision tracking, charting, scheduling, etc.
I'm not really sure one suite can cover both audiences.
There are also some people who only get pain relief with Vioxx; ``equivalent'' drugs don't seem to work.
I'm not even sure I'd classify the Apple II or Macintosh as "revolutionary".
The Apple II may not have been revolutionary in terms of technology, but they definetly started the revolution of the way technology is used in classrooms.
The Apple II was found in a very large number of schools, even if it was just a single machine in the library, and introduced millions of children to computers.