This guy says "I haven't been able to listen to the sounds in HalfLife II" - OK, but then did he really play the games, or is he just going on other people's statements about the engines?
Or did he in fact play HL2, but for some reason was not able to hear the sounds?
This alone makes me wonder about the validity of the review.
And I am sorry, but while the issue of portability may not matter to many, it is important to me - and in that regard Doom wins.
And one last thing - will this reviewer receive the flamage about saying HalfLife was based upon the Quake II engine that I did in when I said that in a previous/. post?
In fairness, I would generalize your statement to:
Don't connect ANY computer to the Internet, or any other hostile network, without a firewall.
Now, you can argue that, in the case of some operating systems, the firewall built into the OS, when properly configured, is enough.
You can also argue that a firewall should be a firewall, and a firewall ONLY, and that any other services should be provided by another machine BEHIND the firewall.
And depending upon the circumstances, either argument can win.
However, if you think in terms of "First the firewall, THEN the services", you will be miles ahead.
Connecting a Linux box, or a *BSD box, or a Mac, or an AS/400, or.* to a hostile network with any non-trivial set of services running and no firewall, and it is going to have problems.
The problem here is that the people who set up the MySQL servers on these boxes did not insure they were firewalled - this could have happened just as easily to a Linux box with a similarly bad setup.
Actually, having written several Ethernet drivers for standard chipsets for use within embedded systems, I can say you are incorrect - the MAC address is a set of registers on the card which are programmed by the card driver. Usually, the driver just reads the MAC from a EEPROM attached to the chip, but there is nothing preventing the driver from assigning whatever values to the card it wishes, ignoring the EEPROM.
So MAC is not guaranteed to be unique among computers - in fact many consumer broadband routers will allow you to set the MAC of the router's WAN port to be identical to the MAC of your PC, if your ISP does MAC filtering (and this simply points out the futility of MAC filtering).
The Media Access Controller address is becoming the computing equivalent of the US Social Security Number - (ab)used for things for which it was never intended and is inappropriate.
First of all, a MAC address does not uniquely identify a computer - it uniquely identifies a network interface. I have several computers which have more than one Ethernet controller in them, and so they have several MAC addresses associated with them.
Secondly, since almost ALL modern cards allow the MAC address to be changed by software, there is no guarantee that the MAC address is unique.
These two items alone should be sufficient to convince people that using the MAC address as anything other than the physical layer address of a specific Ethernet card is a BAD IDEA.
If you want to generate a unique identifier for a message, use something else - use/dev/random (or your OS's equivalent service) or some other method.
Everyone talking about Remote Desktop, Terminal Services, VNC - but these solutions require a port open on the server and firewall.
LogMeIn and GoToMyPC only need an outgoing connection.
Which they use to create the same result - a way an incoming connection can be established to your PC.
The only difference is that instead of opening a port on your firewall that you can pick (allowing you to use a non-standard port to raise the bar above the heads of the script kiddies), you use somebody else's computer to control your security.
Somebody you cannot audit.
Somebody who can screw up and comprimise your computer.
Somebody who is a high-profile high-value target for an attacker.
Were I a system administrator, I would null route all of these services at the firewall, and would log any attempt to access them from within my network and kill the connection of the PC that attempted them - then proceed to LART the user that did so in a fashion that would make the BOFH wince. Their main purpose is to allow stupid lusers to do an end-run around the "meeny stupid-head network admin who won't let me access MY computer" (because he is doing his job of maintaining network security).
Folks, any remote access solution involves cracking a hole in your firewall - bar none. You can either admit that to yourself and realise that you must take increased security precautions, or you can delude yourself and ride for a fall.
One way this might be accomplished would be via antisense DNA - you make a DNA strand that is the compliment to a critical gene of the bacterium. Inject into the patient.
The bacteria take up the DNA, which then binds to the gene when it is attempting to make the mRNA to synthisize its protein, thus blocking mRNA formation and killing the bacterium (or at least slowing it down enough for the patient's immune system to kill it.)
For normal file systems, the only APIs I need are the standard open/close/read/write supported on all *nix operating systems.
However, ZFS's big claim to fame is that it will allow extra capabilities - database-like searches and the like.
These will require APIs above and beyond the standard APIs - APIs that will be Solaris only.
Now, if you go back and re-read my post, you will see I said:
Let's see - will Sun be making the API for their new file system's extra-special features available so that other *nix OSs can support it with their own native file systems?
In other words, will Sun make the new APIs that will be specific to ZFS available to other operating systems, so that if their underlying file system can perform similar operations they can export the same API to userspace, so that, in time, the new APIs Sun is pushing will be as common, and COMPATIBLE, as open/close/read/write?
Now, I know it is hard for a troll to understand abstract concepts like this, so think really hard - push through the pain, enlightenment is on the other side.
You see, complaining that IBM is not being compatible, while at the same time trying to lock future programs into being Solaris only by providing non-standard APIs is an example of what is called "hypocrisy" - look it up.
And moderators - try reading ALL the comments in a thread before moderating. I realise that moderation on/. has been sliding down toward the event horizon for several years, but it is not yet too late to pull back.
Let's see - will Sun be making the API for their new file system's extra-special features available so that other *nix OSs can support it with their own native file systems?
No?
Well, will Sun make their new file system available for other *nix OSs?
No?
Well, will Sun have ANY compatibility between Solaris with their new, all-signing-all-dancing file system and any other OS?
No?
Then to Sun I say - "SHUT THE FBOMB UP ABOUT OTHER PEOPLE'S COMPATIBILITY UNTIL YOU ARE COMPATABLE YOURSELF!"
I don't think he had the fglrx drivers AND gatos running - he simply pulled the Xorg source from CVS and had the tuner working with the standard Xorg build - as I have for some time with my 7500.
However, I spent the day yesterday working with my 9600, and while I have the fglrx code running with the CVS pull of Xorg, the tuner section is not loading - as the fglrx drivers don't invoke the gatos modules.
So, it would seem the partial answer to my question is "No, the flgrx driver for Xorg does not work with the gatos drivers."
Actually, I was just wondering if Mr. Powell will be going to work for one of the BPL equipment providers as a "consultant"....
And as for "... coating BPL with teflon and ramming it through...." - It seems more like he coated it with Tabasco and rammed it into HF operator's... well, I leave the rest of the image to you.
For the nature of the 820.11 specs, I'd suggest googling for the standards documents (the place I'd go is not available to the average person).
The processor required wouldn't be much - a PIC level CPU (8 bits, a couple of MHz) would be enough.
The ASIC for a USB device has the micro already, and is not what we are discussing.
The ASICS on the cards for PCs is a different story - they currently don't have a micro on them, and I suggest putting one in. You do that by licensing a core and dropping it into the ASIC's design, just like all the other components you design in.
And as for selling a card with a built-in micro - I don't know of anybody who is doing that - hence why I say the need is for all of us consumers to demand one.
See my other comments in this thread about calibration, but:
Yes, you use a feedback loop to control signal levels. However, when dealing with discontinuous signals like WiFi, you cannot use a simple analog loop, since the signal is not there all the time. You have to gate the loop - run it only when there is a signal present. You also have what are known as "power envelopes" - you have to bring the power up and down on each burst according to a defined pattern. Lastly, a feedback loop is only as good as its reference input - and power detectors vary from component to component. You still have to calibrate them.
Frankly, as someone plays at doing software development almost every day, I'd just as soon not *have* to s/w control the gain.
As somebody who has had to write software to control the gain of an RF system, believe me, you have no idea how badly it sucks to have to do software control on a shared processor. If you have ANY jitter in how quickly the CPU can respond to the loop, your loop stabilty goes to shit (unless you use a long loop delay, but then your take forever to correct for disturbances).
Again, that is why, where I designing a WiFi card, I would want a dedicated microcontroller handling the RF - something who's sole job is to manager the RF, and who isn't going to be off dealing with swap space when it comes time to tweak the system. I *like* taking encapsulation to the hardware, and having the main processor say "105 MHz at 0 dBm please" and letting the micro do the work.
However, I design gear that costs between US$20,000 and up (waaaay up), so I can get away with that. It is a whole 'nother world when you are designing things that sell for US$20.
Isn't the gain control a set of bits in a "register", though? And if so, can't you limit the gain by limiting the number of bits?
Not quite. What you usually have is an digital to analog converter (DAC) that controls a variable gain amp (VGA). The voltage from the DAC controls how much the amplifier amplifies - think of it as the volume control on a stereo.
Now, the RF final amps (the speakers) have some variance in terms of how much gain they have (some speakers are louder than others at the same input). So you characterize the variance of the amps ( 99% of the speakers fall between X and Y loudness, and anything below X or above Y is rejected as bad.). Let us suppose that X is 1 and Y is 2 - you then need to have enough DAC (enough volume control) to make a 1 through a 2 the same loudness.
Now, for a specific device - e.g. YOUR WiFi card, as opposed to MY card of the same type - the RF amps may have a given level of gain (your speakers are a 1.5). So, during the final cal on the line, the production line system writes into your card's EEPROM that the maximum allowable volume is X. Now, my card's outputs may not be as hot (speakers are a 1.0) so my card gets written with a max that is 1.5 times higher than yours.
So, no, you cannot limit the values.
Are the ASICs that are going into the devices proprietary?
Yes, they are.
And finally, roughly how much design effort goes into design of the ASIC given some prefab design or part that is the actual radio?
It depends. A designer can license "cores" (think libraries for hardware) that implement given functions, and string them together in one ASIC. However, just like in software, you may be able to get 90% of your fucntionality in cores, but that remaining 10% can be a bitch. Also, where you differentiate your produce from everybody else can be in NOT using a standard core - you may have a better solution than the standard one.
I'd like to see that in the US, along with logic to determine if the car is tailgating and has been tailgating for more than a couple of seconds.
Along with the integration of a cattleprod in the driver's seat, of course.
However, since they auto industry doesn't employ BAEFHs (bastard automotive engineers from hell), a simple "Warning - tailgating" or a beeper would be acceptable.
It would depend upon the design - but the short answer is "No".
RF parts have tolerances - some transistors have more gain than other of the same model number due to process variation during their manufacture.
So, what you do when you design an RF device is you design the hardware to allow for enough gain variation to compensate for 99% of the parts you will see. You then measure what the limits are for the specific device you buit, and write them into an EEPROM or flash on the device. You then write your drivers to respect those limits.
For a device with its own CPU and resident firmware this is not a problem, as the user cannot modify the firmware nor can he modify the cal tables. But for a device which relies upon the host CPU to make the adjustments, where the host CPU code is available to the user, you can no longer guarantee the limits will be honored.
IAASDRD (I am a software defined radio designer), so let me answer a few of your questions:
are basically a single IC with with the registers wired to the USB bus.
Which is an application specific integrated circuit (ASIC) containing the RF circuits and a microcontroller.
...but would it really add cost to just hardwire those settings?
You don't WANT to "hardwire" the power settings - you want the WiFi device to be able to adjust its power settings based upon the amount of power needed to communicate to the other devices. What you DON'T want is the user taking the device out of the designed limits.
How much trouble can a private citizen get into by buying the (unpackaged) chip hooking it to a battery and some light switches?
If he causes interference on the band, and gets caught, and fails to shut the device down, he can get hit with a notice of forfiture for upwards of US$10,000. Furthurmore, the average user is not able to "(hook) it to a battery and some light switches" and do anything but let the smoke out.
Considering the small amount of comment spam vs. the large amount of trolls and crapfloods, removing all the comment spam would have a negligable effect upon the comments.
However, I do agree with you - adding this attribute to the links would be a good idea if only to slightly discourage the "Help me get a free $THING via this multi-level-marketing scam" sigs.
First of all - I have an Atheros chipset WiFi board down in my server that is currently doing little but sucking milliamps as the Linux drivers are unstable as sweaty nitro. I'd *LOVE* to see Atheros release proper programming specs for the chip - as an embedded software engineer I could then fix the damn drivers.
That said - folks, it ain't a-gonna happen. The FCC , DTI and other regulatory bodies around the world are very clear about this - for a product to be type certified, it must not be easily modifiable by the end user to operate out of the allocated frequency bands and power specifications.
Consider the recent Notice Of Forfeiture against the Pilot truck stops for selling amateur radio equipment that could be modified for use in the Citizen's Band frequencies by moving a jumper. Whether the jumper was set or not was unimportant - the fact that the radios could be trivially modified to operate outside their allocated frequencies was enough.
The arguement that "The card + the drivers as shipped cannot operate out of spec, so that combination can be type certified" only works when the user is not give the source for the driver! That is why the card manufacturers can ship Windows binary drivers - the user is not trivially able to change things. A driver which has source under/usr/src/linux/drivers/802.11 is a different issue - the user can trivially change the card's output power and operating frequencies.
And I am sorry folks, but that is a spectacularly bad idea. For an example of why, just listen to the Children's Band within a hundred miles of any major city - it is one big heterodyne squeal and spatterfest because of all the morons who think "If 90% modulation is good, then 190% modulation must be BETTER!"
ESPECIALLY with a complex modulation scheme like 802.11 uses, you CANNOT safely just rail the power levels - the amplifiers have to have a certain amount of headroom in order to faithfully reproduce the signals, and if you turn the gain up too far, you will start to run the amplifiers into compression, and distort the signal - and a distorted signal will have LESS range than a properly modulated signal. And you cannot tell the signal is properly modulated without a signal analyzer - and that is about US$20K or more (I know, as I design them!)
Or consider the recent Slashdot post about the guy who could not use his WAP in his apartment, because of all the other WAPs in the building. What was the first piece of advice he received? "Turn it up, D00D!" So then what happens? Nobody can use the band.
There is a GOOD REASON that there is regulation of the RF spectrum - it IS a shared resource that we all wish to benefit from. However, all it takes is one jackass to screw it up for everybody in the area. One child peeing in the pool once is not a big problem - but if you let one kid do it, the pool turns yellow pretty damn quickly.
Now, if the card manufacturers would stop trying to do things on the cheap, and would put a microcontroller on the card to control the RF section, and would either put flash on the card to drive the micro OR release the binary of the micro for free redistribution, THEN this wouldn't be a problem, as the user-modifiable driver would not be able to make the card go out-of-spec (and this would not be a violation of the GPL as the code for the micro would not be linked against anything - it would be data that is stuffed into the card at init, possibly by a userspace program in response to a hotplug event). However, the card manufacturers would rather "save" the money (even though the incremental per-unit cost of embedding a micro into the ASIC that implements the RF modem is essentially zero).
To recap - I am ALL FOR Free Software drivers for hardware: I've bitched at ATI for the poor support for their video cards, I've bemoaned the poor Atheros WiFi drivers, I've cussed at more crap drivers that I can count! But unless you repeal the FCC's (DTI, or whatever the TLA is in the reader'
A feature I'd like to see the Gnome and KDE guys look at would be to implement the "Program menu is at top of screen and changes based upon input focus" model that Apple and GEM (and IIRC Amiga) used.
This allows the use of Fitt's law that screen edges are "infinitely tall/wide" - you can move the mouse up with abandon, knowing that you will stop when you hit the edge (virtual desktops being discussed below). This makes it easier to select menus for the app.
There are difficulties with this approach:
You have to have a "Menu Manager" function to arbritrate what shows on the menu between all the programs, but since both Gnome and KDE already have the idea of "Panels" this would be an extension of that approach.
You have the inertia of old users (and Windows users) who 'like the "old" way' (which was actually introduced LATER in history) - so you make it a preference (Gnome guys: a preference WHICH HAS AN EASILY ACCESSIBLE SETTING IN THE UI - not some obscure RegEdit^W GConf setting).
You have the problem of legacy/non-Gnome/KDE apps which would still put their menus at top of window.
If the user is using a panning virtual desktop (e.g. Virtual "2048x2048" in X) the menu may be off the visible screen - however when using a panning virtual desktop that happens with other UI elements - so this obviously isn't as much of a problem for the people who choose to use virtual desktop resolutions.
Likewise, when dealing with multiple desktop where you can change the desktop by scrolling the mouse over the edge (like good old Sawmill under earlier Gnome *sniff* (/me wipes tear from my eye)) you have to prevent a desktop switch. However, you can use the approach Sawmill used - you don't change screens unless you are dragging a window.
Slashdot Mirror
Ok, let's take up a collection for Rob et. al. to get this book....
This guy says "I haven't been able to listen to the sounds in HalfLife II" - OK, but then did he really play the games, or is he just going on other people's statements about the engines?
/. post?
Or did he in fact play HL2, but for some reason was not able to hear the sounds?
This alone makes me wonder about the validity of the review.
And I am sorry, but while the issue of portability may not matter to many, it is important to me - and in that regard Doom wins.
And one last thing - will this reviewer receive the flamage about saying HalfLife was based upon the Quake II engine that I did in when I said that in a previous
And the last part of the crawl is.
You'll laugh!
You'll cry!
You'll kiss ten bucks goodbye!
GET IN LINE NOW!
"Irregardless" is not a valid word.
r dl ess
"Ir-" means negation.
"-less" means "without"
Irregardless would mean "not without regard".
It would either be "irrespective" (not respecting) or "regardless" (without regard).
http://dictionary.reference.com/search?q=irrega
In fairness, I would generalize your statement to:
.* to a hostile network with any non-trivial set of services running and no firewall, and it is going to have problems.
Don't connect ANY computer to the Internet, or any other hostile network, without a firewall.
Now, you can argue that, in the case of some operating systems, the firewall built into the OS, when properly configured, is enough.
You can also argue that a firewall should be a firewall, and a firewall ONLY, and that any other services should be provided by another machine BEHIND the firewall.
And depending upon the circumstances, either argument can win.
However, if you think in terms of "First the firewall, THEN the services", you will be miles ahead.
Connecting a Linux box, or a *BSD box, or a Mac, or an AS/400, or
The problem here is that the people who set up the MySQL servers on these boxes did not insure they were firewalled - this could have happened just as easily to a Linux box with a similarly bad setup.
Actually, having written several Ethernet drivers for standard chipsets for use within embedded systems, I can say you are incorrect - the MAC address is a set of registers on the card which are programmed by the card driver. Usually, the driver just reads the MAC from a EEPROM attached to the chip, but there is nothing preventing the driver from assigning whatever values to the card it wishes, ignoring the EEPROM.
So MAC is not guaranteed to be unique among computers - in fact many consumer broadband routers will allow you to set the MAC of the router's WAN port to be identical to the MAC of your PC, if your ISP does MAC filtering (and this simply points out the futility of MAC filtering).
The Media Access Controller address is becoming the computing equivalent of the US Social Security Number - (ab)used for things for which it was never intended and is inappropriate.
/dev/random (or your OS's equivalent service) or some other method.
First of all, a MAC address does not uniquely identify a computer - it uniquely identifies a network interface. I have several computers which have more than one Ethernet controller in them, and so they have several MAC addresses associated with them.
Secondly, since almost ALL modern cards allow the MAC address to be changed by software, there is no guarantee that the MAC address is unique.
These two items alone should be sufficient to convince people that using the MAC address as anything other than the physical layer address of a specific Ethernet card is a BAD IDEA.
If you want to generate a unique identifier for a message, use something else - use
Which they use to create the same result - a way an incoming connection can be established to your PC.
The only difference is that instead of opening a port on your firewall that you can pick (allowing you to use a non-standard port to raise the bar above the heads of the script kiddies), you use somebody else's computer to control your security.
Somebody you cannot audit.
Somebody who can screw up and comprimise your computer.
Somebody who is a high-profile high-value target for an attacker.
Were I a system administrator, I would null route all of these services at the firewall, and would log any attempt to access them from within my network and kill the connection of the PC that attempted them - then proceed to LART the user that did so in a fashion that would make the BOFH wince. Their main purpose is to allow stupid lusers to do an end-run around the "meeny stupid-head network admin who won't let me access MY computer" (because he is doing his job of maintaining network security).
Folks, any remote access solution involves cracking a hole in your firewall - bar none. You can either admit that to yourself and realise that you must take increased security precautions, or you can delude yourself and ride for a fall.
One way this might be accomplished would be via antisense DNA - you make a DNA strand that is the compliment to a critical gene of the bacterium. Inject into the patient.
The bacteria take up the DNA, which then binds to the gene when it is attempting to make the mRNA to synthisize its protein, thus blocking mRNA formation and killing the bacterium (or at least slowing it down enough for the patient's immune system to kill it.)
For normal file systems, the only APIs I need are the standard open/close/read/write supported on all *nix operating systems.
However, ZFS's big claim to fame is that it will allow extra capabilities - database-like searches and the like.
These will require APIs above and beyond the standard APIs - APIs that will be Solaris only.
Now, if you go back and re-read my post, you will see I said:
In other words, will Sun make the new APIs that will be specific to ZFS available to other operating systems, so that if their underlying file system can perform similar operations they can export the same API to userspace, so that, in time, the new APIs Sun is pushing will be as common, and COMPATIBLE, as open/close/read/write?
Now, I know it is hard for a troll to understand abstract concepts like this, so think really hard - push through the pain, enlightenment is on the other side.
You see, complaining that IBM is not being compatible, while at the same time trying to lock future programs into being Solaris only by providing non-standard APIs is an example of what is called "hypocrisy" - look it up.
And moderators - try reading ALL the comments in a thread before moderating. I realise that moderation on
No, sir, I do not.
The idea of the new Solaris ZFS is to export functions to programs - to allow programs to better search the file system.
That capability will only be available on Solaris - thus rendering any program that uses those features Solaris only.
A program that is Solaris only is not compatible.
Sun, by not making at least the API available to other OSs, is encouraging incompatibility.
Therefore, Sun is not following their own advice to IBM.
Therefore, they are hypocrites.
And since you are unable to follow such a chain of reasoning without having it explained to you, and yet you chastize me, you sir, are a moron.
Let's see - will Sun be making the API for their new file system's extra-special features available so that other *nix OSs can support it with their own native file systems?
No?
Well, will Sun make their new file system available for other *nix OSs?
No?
Well, will Sun have ANY compatibility between Solaris with their new, all-signing-all-dancing file system and any other OS?
No?
Then to Sun I say - "SHUT THE FBOMB UP ABOUT OTHER PEOPLE'S COMPATIBILITY UNTIL YOU ARE COMPATABLE YOURSELF!"
I don't think he had the fglrx drivers AND gatos running - he simply pulled the Xorg source from CVS and had the tuner working with the standard Xorg build - as I have for some time with my 7500.
However, I spent the day yesterday working with my 9600, and while I have the fglrx code running with the CVS pull of Xorg, the tuner section is not loading - as the fglrx drivers don't invoke the gatos modules.
So, it would seem the partial answer to my question is "No, the flgrx driver for Xorg does not work with the gatos drivers."
Leaving unaswered the question "Why not?"
Actually, I was just wondering if Mr. Powell will be going to work for one of the BPL equipment providers as a "consultant"....
... well, I leave the rest of the image to you.
And as for "... coating BPL with teflon and ramming it through...." - It seems more like he coated it with Tabasco and rammed it into HF operator's
For the nature of the 820.11 specs, I'd suggest googling for the standards documents (the place I'd go is not available to the average person).
The processor required wouldn't be much - a PIC level CPU (8 bits, a couple of MHz) would be enough.
The ASIC for a USB device has the micro already, and is not what we are discussing.
The ASICS on the cards for PCs is a different story - they currently don't have a micro on them, and I suggest putting one in. You do that by licensing a core and dropping it into the ASIC's design, just like all the other components you design in.
And as for selling a card with a built-in micro - I don't know of anybody who is doing that - hence why I say the need is for all of us consumers to demand one.
Yes, you use a feedback loop to control signal levels. However, when dealing with discontinuous signals like WiFi, you cannot use a simple analog loop, since the signal is not there all the time. You have to gate the loop - run it only when there is a signal present. You also have what are known as "power envelopes" - you have to bring the power up and down on each burst according to a defined pattern. Lastly, a feedback loop is only as good as its reference input - and power detectors vary from component to component. You still have to calibrate them.
As somebody who has had to write software to control the gain of an RF system, believe me, you have no idea how badly it sucks to have to do software control on a shared processor. If you have ANY jitter in how quickly the CPU can respond to the loop, your loop stabilty goes to shit (unless you use a long loop delay, but then your take forever to correct for disturbances).
Again, that is why, where I designing a WiFi card, I would want a dedicated microcontroller handling the RF - something who's sole job is to manager the RF, and who isn't going to be off dealing with swap space when it comes time to tweak the system. I *like* taking encapsulation to the hardware, and having the main processor say "105 MHz at 0 dBm please" and letting the micro do the work.
However, I design gear that costs between US$20,000 and up (waaaay up), so I can get away with that. It is a whole 'nother world when you are designing things that sell for US$20.
Not quite. What you usually have is an digital to analog converter (DAC) that controls a variable gain amp (VGA). The voltage from the DAC controls how much the amplifier amplifies - think of it as the volume control on a stereo.
Now, the RF final amps (the speakers) have some variance in terms of how much gain they have (some speakers are louder than others at the same input). So you characterize the variance of the amps ( 99% of the speakers fall between X and Y loudness, and anything below X or above Y is rejected as bad.). Let us suppose that X is 1 and Y is 2 - you then need to have enough DAC (enough volume control) to make a 1 through a 2 the same loudness.
Now, for a specific device - e.g. YOUR WiFi card, as opposed to MY card of the same type - the RF amps may have a given level of gain (your speakers are a 1.5). So, during the final cal on the line, the production line system writes into your card's EEPROM that the maximum allowable volume is X. Now, my card's outputs may not be as hot (speakers are a 1.0) so my card gets written with a max that is 1.5 times higher than yours.
So, no, you cannot limit the values.
Yes, they are.
It depends. A designer can license "cores" (think libraries for hardware) that implement given functions, and string them together in one ASIC. However, just like in software, you may be able to get 90% of your fucntionality in cores, but that remaining 10% can be a bitch. Also, where you differentiate your produce from everybody else can be in NOT using a standard core - you may have a better solution than the standard one.
I'd like to see that in the US, along with logic to determine if the car is tailgating and has been tailgating for more than a couple of seconds.
Along with the integration of a cattleprod in the driver's seat, of course.
However, since they auto industry doesn't employ BAEFHs (bastard automotive engineers from hell), a simple "Warning - tailgating" or a beeper would be acceptable.
It would depend upon the design - but the short answer is "No".
RF parts have tolerances - some transistors have more gain than other of the same model number due to process variation during their manufacture.
So, what you do when you design an RF device is you design the hardware to allow for enough gain variation to compensate for 99% of the parts you will see. You then measure what the limits are for the specific device you buit, and write them into an EEPROM or flash on the device. You then write your drivers to respect those limits.
For a device with its own CPU and resident firmware this is not a problem, as the user cannot modify the firmware nor can he modify the cal tables. But for a device which relies upon the host CPU to make the adjustments, where the host CPU code is available to the user, you can no longer guarantee the limits will be honored.
Which is an application specific integrated circuit (ASIC) containing the RF circuits and a microcontroller.
You don't WANT to "hardwire" the power settings - you want the WiFi device to be able to adjust its power settings based upon the amount of power needed to communicate to the other devices. What you DON'T want is the user taking the device out of the designed limits.
If he causes interference on the band, and gets caught, and fails to shut the device down, he can get hit with a notice of forfiture for upwards of US$10,000. Furthurmore, the average user is not able to "(hook) it to a battery and some light switches" and do anything but let the smoke out.
Uhh, considering I design Software defined radios for a living, I am all for them.
However, I don't see SDR transmitters becoming Free software, for exactly the reasons I stated.
So, I don't see your point - did you have one?
Considering the small amount of comment spam vs. the large amount of trolls and crapfloods, removing all the comment spam would have a negligable effect upon the comments.
However, I do agree with you - adding this attribute to the links would be a good idea if only to slightly discourage the "Help me get a free $THING via this multi-level-marketing scam" sigs.
First of all - I have an Atheros chipset WiFi board down in my server that is currently doing little but sucking milliamps as the Linux drivers are unstable as sweaty nitro. I'd *LOVE* to see Atheros release proper programming specs for the chip - as an embedded software engineer I could then fix the damn drivers.
/usr/src/linux/drivers/802.11 is a different issue - the user can trivially change the card's output power and operating frequencies.
That said - folks, it ain't a-gonna happen. The FCC , DTI and other regulatory bodies around the world are very clear about this - for a product to be type certified, it must not be easily modifiable by the end user to operate out of the allocated frequency bands and power specifications.
Consider the recent Notice Of Forfeiture against the Pilot truck stops for selling amateur radio equipment that could be modified for use in the Citizen's Band frequencies by moving a jumper. Whether the jumper was set or not was unimportant - the fact that the radios could be trivially modified to operate outside their allocated frequencies was enough.
The arguement that "The card + the drivers as shipped cannot operate out of spec, so that combination can be type certified" only works when the user is not give the source for the driver! That is why the card manufacturers can ship Windows binary drivers - the user is not trivially able to change things. A driver which has source under
And I am sorry folks, but that is a spectacularly bad idea. For an example of why, just listen to the Children's Band within a hundred miles of any major city - it is one big heterodyne squeal and spatterfest because of all the morons who think "If 90% modulation is good, then 190% modulation must be BETTER!"
ESPECIALLY with a complex modulation scheme like 802.11 uses, you CANNOT safely just rail the power levels - the amplifiers have to have a certain amount of headroom in order to faithfully reproduce the signals, and if you turn the gain up too far, you will start to run the amplifiers into compression, and distort the signal - and a distorted signal will have LESS range than a properly modulated signal. And you cannot tell the signal is properly modulated without a signal analyzer - and that is about US$20K or more (I know, as I design them!)
Or consider the recent Slashdot post about the guy who could not use his WAP in his apartment, because of all the other WAPs in the building. What was the first piece of advice he received? "Turn it up, D00D!" So then what happens? Nobody can use the band.
There is a GOOD REASON that there is regulation of the RF spectrum - it IS a shared resource that we all wish to benefit from. However, all it takes is one jackass to screw it up for everybody in the area. One child peeing in the pool once is not a big problem - but if you let one kid do it, the pool turns yellow pretty damn quickly.
Now, if the card manufacturers would stop trying to do things on the cheap, and would put a microcontroller on the card to control the RF section, and would either put flash on the card to drive the micro OR release the binary of the micro for free redistribution, THEN this wouldn't be a problem, as the user-modifiable driver would not be able to make the card go out-of-spec (and this would not be a violation of the GPL as the code for the micro would not be linked against anything - it would be data that is stuffed into the card at init, possibly by a userspace program in response to a hotplug event). However, the card manufacturers would rather "save" the money (even though the incremental per-unit cost of embedding a micro into the ASIC that implements the RF modem is essentially zero).
To recap - I am ALL FOR Free Software drivers for hardware: I've bitched at ATI for the poor support for their video cards, I've bemoaned the poor Atheros WiFi drivers, I've cussed at more crap drivers that I can count! But unless you repeal the FCC's (DTI, or whatever the TLA is in the reader'
This allows the use of Fitt's law that screen edges are "infinitely tall/wide" - you can move the mouse up with abandon, knowing that you will stop when you hit the edge (virtual desktops being discussed below). This makes it easier to select menus for the app.
There are difficulties with this approach:
Does anybody know if the Xorg version of the driver will work with the GATOS modules that are in the current CVS build of Xorg?
And, if not, then WHY ON EARTH NOT?