Gnome guys; don't consider extending or improving XUL. That javascript+gtk widgets model hasn't managed to produce anything worthwhile, now has it? Obviously, you can do it better! Probably 3-4 times over the next 15 years. Good luck!
Satellites, obviously. We (meaning wealthy Westerners) have been disrupting the magnetic field by accelerating masses of metal into orbit for about half a century now. Being thoughtless pigs, we've placed most of our satellites in equatorial orbits and biased the natural, wholesome fields creating the holes we now observe. We prefer these orbits because they best serve the equatorial regions we have monopolized.
Clearly we must redistribute our presence on the surface such that polar orbits satisfy our excessive need for communication. Naturally this will liberate prime equatorial regions for those who prefer simpler lifestyles, simultaneously balancing the field bias and correcting our unfair land use.
What you're expecting is really beyond the capability of common SOHO NAS equipment. These devices lack the RAM and CPU to approach the capacity of GB Ethernet.
Unless you're willing to roll your own, you should consider a better class of gear and spend your time arguing for the funds to pay for it (a NetApp S550, perhaps.) If you are willing to roll your own, you can get there for $1-2k using all new hardware.
Beware reusing older hardware; many GB NICs can't approach GBE saturation, either due to PCI bus contention or low end, low cost implementation. Yes, in some cases older hardware can get there, but this will require careful configuration and tuning.
You want a PCI-E bus, a decent 'server' class NIC, recent SATA disks, a modern CPU (practically any C2D is sufficient) and enough RAM (2-4 GB). Personally I stick to Intel based MB chipsets and limit myself to the SATA ports provided by Intel (as opposed to the third party provided by jaton, silcon image, et al.) Linux, md raid 10. Will saturate a GBE port all day long, provided your switch can handle it...
You're serving desktops so jumbo frames are probably impractical (because some legacy hardware on that LAN will not tolerate it.) If your managed (?) switch can provide VLANs you can multihome your critical workstations and use jumbo frames. This will get you more performance with less CPU load for 'free'.
Is that actually the case? Honest question here as I am not an SSD engineer. Lacking seek or rotational latency any given block of SSD storage should take equal time to read/write. But does that assure that non-contiguous sequential IO (the thing defragging is intended to eliminate) is exactly as efficient as the contiguous case? (Please forgive my elevation of "shouldn't need that" to the "exactly as efficient" standard.)
It would seem that non-contiguous operations would still involve more IO commands between the host and the controller, and perhaps also more bus operations internally (between the controller and the physical storage.)
If you're going to transfer files over UDP then you need to build some TCP-like protocol on top of it.
No. TCP guarantees sequence, among other things, a property responsible of much of its complexity and overhead. BT should (and does) function well in the absence of transport layer enforced sequencing, automatic packet loss recovery, inadequate (16 bit) checksums, etc.
We really don't need is an arms race of new, greedier protocols
No, we don't, but we're getting one anyhow. BT is doing what it must in this arms race to remain relevant; if it did any less the greedy would abandon it for whatever weapon delivered more bandwidth. BT isn't actually at fault here. Try to remember that as you're knocking back the MSM kool-aid on the evils of BT.
An alternate protocol could conceivably improve on this by applying flow control to the aggregate throughput for the whole "bundle" of connections, rather than each connection individually.
Although it is possible to bake congestion control into an application layer above UDP, is not possible for BT to utilize such a design. Again, if it tried the downloaders would go elsewhere to avoid the congestion control.
This isn't about some technical inadequacy and there is no silver bullet solution. This is about fuckwits that will not stop until The Powers that Be step on them and their nonsense. Naturally we're all going under the boot lest there be some 'unfairness.'
An outfit called Sally Mae is the largest student loan financier in the US. It began as another GSE in the 70's and was later privatized.
If you're involved in collections you know that people that can't afford their own debt prioritize who they're going to stiff. First the education dept, then the credit cards, cars loans and finally the mortgage.
Look around and note the number of layoffs. How much time does Sally Mae have left before some overwhelming fraction of their loans become 'toxic'? Boom.
Pay in full at time of service with cash and get 30% off.
Until 'they' outlaw this. Those that can afford to pay cash for their service will be able to escape the collectivized rationing the government provides after it nationalizes the $2.2E12 health care industry. Great Leader and friends will convince 'us' that this is unfair.
When it installs it must piggyback off the main firefox profile
That's exactly what happens. When the brilliant zootropole says:
Minefield's install won't affect your Firefox, so there's no risk trying it
...he's means only that unpacking the nightly build archive won't replace your existing Firefox binaries. Running it, however, will immediately step all over your default Firefox profile. I guess zootropole doesn't give a damn when he misleads people.
The safe procedure:
1. Shut down FF. (yeah I know it can be done without shutting down, stfukthx) 2. Run your existing FF from the command line like so
firefox -profilemanager
3. Create a new profile (MyFF31profile, whatever) in the profile manager. 4. Run FF31 like so
Automatic MDI/MDI-X Configuration is intended to eliminate the need for crossover cables between similar devices. Implementation of an automatic MDI/MDI-X configuration is optional for 1000BASE-T devices. If an automatic configuration method is used, it shall comply with the following specifications...
I'm not an IEEE expert but the above appears fairly unambiguous. What I do know is that if it isn't required then you can be certain someone, somewhere omitted it. Heck, it would be found missing even if it were required. Crappy hardware abounds.
Actually, players are divided among servers. Specifically, all players in a single solar system (just "system" in EVE lingo) are isolated to a single thread within a single stackless python process.
This design does not permit real multicore concurrency for a single system. Every player action in space is handled by a single thread. Stackless python provides "microthreads" which gives the illusion of concurrency, but it's really just cooperative multitasking. Lacking real concurrency, EVE can not scale beyond what can be processed in a single thread in a reasonable amount of time. Presently that amounts to about 1000 ships/players.
Microthreads provide none of the concurrency mechanisms (locks, CAS, etc.) that permit threads to safely share data. Thus, the stackless design of EVE can not be scaled using SMP. In my opinion this is a major design flaw of EVE.
The stackless microthread design was chosen for ease of development. Today, that choice plagues the game; it can't be fixed (to permit real concurrency) without a major refactoring of the server side game engine. If EVE will ever scale to what the players actually expect (by virtue of the fact that they don't hesitate to try 1000+ ship battles) then CCP needs to begin thinking about this refactoring; systems should be capable of leveraging multiple cores on demand. That means abandoning microthreads, which is the right decision, because the design imperative behind the choice of stackless (ease of development) is obsolete; half a decade later the new imperative is scalability.
The StacklessIO thing is an improvement to asynchronous IO that CCP deployed earlier this week. It's nice in that it enabled about 1000 players/ships to fight in a system with less "lag" then had been the case with only 500 or so ships. The 32 bit nodes will still crash when they run out of RAM, buy hey, it's an improvement.
I must agree. Conservatives and frightened Democrats prevented a massive take-over by the political class.
Folks, it's a credit bubble. It's not the first and it won't be the last. There are no innocents; individuals have been racking up debt with large, adjustable, flex-pay, no money down liar loan mortgages, second mortgages, equity credit lines and third mortgages. They've been voting for members of both parties to make it happen; the left does it to buy 'low income' votes and the right does it for their Lehman buddies.
Credit bubbles pop. At some point the accumulated crap must be flushed. That doesn't mean we must turn our Government into the investor of last resort. That's exactly how Fannie and Freddy got us here.
Some fraction of all debt is presently considered 'toxic.' 30 seconds after that $700 billion gets legislated into existence the fraction of 'toxic' debt will multiply; the banks will be happy to invent as much 'toxic' debt as your Government thinks it can get away with buying.
Screw that. I'm not under and mountain of debt and I'm not afraid of those of you who put yourselves under one. Life is too short to live in fear of morons.
See clone(2). Every significant resource related to a process is selectable when spawning a new thread of execution. pthread_create() and fork() are both implemented in terms of clone(). You may invent you're own mix of shared or copied bits according to your specific needs.
Naturally the Windows case is far less general. First, clone() is too short. MinimumWindowsAPISymbolLengthIs(12). There is no fork(). This makes porting fun; see perl, cygwin, et al.
The design intent of Google's Chrome is, simply put, scalability. That's why they focus on Javascript performance; the faster that goes the larger the domain of possible applications. Separate processes mean fault tolerance and privilege isolation, important for long lived native operations doing privileged stuff. Ultimately you figure out the browser is sufficient for the entire GUI. When that happens using concurrent processes instead of threads becomes a requirement.
Paralell (sic) code is almost always superior......but the number of threads is impressive
Nothing impressive about it. Just because you detect a gaggle of threads doesn't prove the program is a collection of brilliant concurrent algorithms. Spawning an excessive number of threads is a common symptom of poorly written code. In practice I more often see threaded code being used to produce half-baked asynchronous IO systems often on platforms that already provide excellent IO multiplexing APIs.
You can't evaluate use of threads in IE8 from the limited empirical evidence provided here. You may compare it to the behavior of existing successful designs. With IE8 you end up asking "why so many freaking threads?" The answer is probably naive reimplementations of fork() to achieve asynchronous IO or privilege isolation.
She added that, if elected, she would not push the state Board of Education to add such creation-based alternatives to the state's required curriculum.
At one time Clinton was "pro-life". He conveniently modified that position for the Federal stage and Palin will do likewise. Hysteria about her creationism will fail.
How does this translate into normal transfer speed units like MB/s? Otherwise I have no point of reference to tell if I am impressed or indifferent.
I'll try to help.
MB/s is a measure of IO throughput. Often this isn't the most relevant figure for 'enterprise' storage. Certain applications do a lot of random access IO so IOPS becomes more important than throughput.
Today a typical desktop disk is capable of about 100-150 IOPS. That's a rule of thumb range that varies based on operation size, cache, etc. It works pretty well usually. You can aggregate disks and get almost linear scaling; 12 disks, for instance in a device like this, will give you a maximum of 1200 IOPs, roughly. A common USB Flash device can break 1000 IOPS with certain access patterns.
The second graph on this page illustrates the extreme IOPS advantage of Flash for certain applications. Disks are limited by head actuation and rotation latency. This is why enterprise storage vendors have been pursuing Flash aggressively. That's what this story is all about.
The dream is to host the same IOPS in with an order of magnitude less physical space, power, heat, etc. If you don't need thousands of IOPS (and most PC users don't) then it isn't very interesting. If you happen to run an OLTP system with thousands of reads/write per second it means a great deal.
The "just" part there is considered a problem. The argument goes that SSL would be ubiquitous if there were no cost, hassle, discloser requirements, etc. Imagine, for instance, that common web servers automatically generated self-signed certs as needed and that these certs were used to encrypt everything by default. This is how SSH servers (OpenSSL) typically work today.
As it is this isn't really possible because browsers erupt warnings, confirmation dialogs and other spasms when a self-signed cert is encountered. This is unacceptable for the bulk of users.
I have always thought that requiring encryption to be coupled with identity is a mistake. Identity needs encryption while encryption doesn't necessarily need identity; encryption is useful independently, regardless of what the security zealots claim.
$15 and a phone call to get a signed cert really is too much to ask. Some people have a difficult time understanding that.
How to fix it? I dunno.
Many around/. advocate eliminating the browser machinations over self-signed certs. This will never happen; compromising what limited integrity contemporary SSL provides will not be supported by the powers that be. IETF will not sign on to it. Verisign won't. Forget it. Any browser vendor foolish enough to fail to comply will be lambasted as insecure and shunned by major institutions.
Call the existing system "legacy" and invent something new? Microsoft won't buy it. Scratch 80% of all web traffic.
IPv6 with it's mandatory IPsec support? See you in 2030 I guess.
P.S. this recent hubbub about Firefox and it's warnings about self-signed certs; this isn't new. Firefox, IE and other browsers have been doing this for years. FF 3.x behavior is not some new phenomena for slashdot to hyperventilate over.
The new connector provides contacts for new wires. This is necessary because the existing wires can not operate at the frequency necessary for 5GB and remain compatible with legacy devices.
You can't appeal to reason; these folks hear 'for the children' and go sideways instantly. You must learn to find ways to appeal to malcontents by leveraging their contrarianism and hatreds. Observe:
Removing the doping bans would throw open the doors to big Pharma influence over Sports. Atheletes will end up wearing sponsorship banners on their uniforms advertising the steriods and "sport enhancements" they are obligated to consume to participate in their sport. This will constitute and endorsement the masses will accept as they become the unwitting victims of greedy drug corporations. As this acceptance permiates Society these obligations will also begin appearing outside of the domain of Sports, eventually appearing in non-Sports related occupations.
See? Implicit corporate evil and fear of/for the ignorant masses has been used to trump the lesser evil of sports authorities. Vastly more effective, around here.
Slashdot Mirror
CA wants a ban on energy guzzling Plasma as well ...and no, LCD isn't immune.
I'm reading a number of /. posts from folks who feel this matter should be 'left to the market.'
LOL
From six months ago, so some links may be dead...
http://slashdot.org/comments.pl?sid=609029&cid=24137949
Atmospheric Thermal Depletion, baby.
Does he know how to hunt? That's what I wanna know!
Apparently not. As he explicitly points out under the "Sportsman" section:
President Obama did not grow up hunting and fishing, but...
Well, at least he won't blast any colleagues in the face with bird-shot...
Gnome guys; don't consider extending or improving XUL. That javascript+gtk widgets model hasn't managed to produce anything worthwhile, now has it? Obviously, you can do it better! Probably 3-4 times over the next 15 years. Good luck!
Satellites, obviously. We (meaning wealthy Westerners) have been disrupting the magnetic field by accelerating masses of metal into orbit for about half a century now. Being thoughtless pigs, we've placed most of our satellites in equatorial orbits and biased the natural, wholesome fields creating the holes we now observe. We prefer these orbits because they best serve the equatorial regions we have monopolized.
Clearly we must redistribute our presence on the surface such that polar orbits satisfy our excessive need for communication. Naturally this will liberate prime equatorial regions for those who prefer simpler lifestyles, simultaneously balancing the field bias and correcting our unfair land use.
What you're expecting is really beyond the capability of common SOHO NAS equipment. These devices lack the RAM and CPU to approach the capacity of GB Ethernet.
Unless you're willing to roll your own, you should consider a better class of gear and spend your time arguing for the funds to pay for it (a NetApp S550, perhaps.) If you are willing to roll your own, you can get there for $1-2k using all new hardware.
Beware reusing older hardware; many GB NICs can't approach GBE saturation, either due to PCI bus contention or low end, low cost implementation. Yes, in some cases older hardware can get there, but this will require careful configuration and tuning.
You want a PCI-E bus, a decent 'server' class NIC, recent SATA disks, a modern CPU (practically any C2D is sufficient) and enough RAM (2-4 GB). Personally I stick to Intel based MB chipsets and limit myself to the SATA ports provided by Intel (as opposed to the third party provided by jaton, silcon image, et al.) Linux, md raid 10. Will saturate a GBE port all day long, provided your switch can handle it...
You're serving desktops so jumbo frames are probably impractical (because some legacy hardware on that LAN will not tolerate it.) If your managed (?) switch can provide VLANs you can multihome your critical workstations and use jumbo frames. This will get you more performance with less CPU load for 'free'.
they have a weighted average of factors
Indeed they do.
Weight% of CO2e emissions: 22
Weight% of Energy supply disruption: 3
Heh. CA's already had a taste of this sort of 'science.' Enjoy the dark.
Defragging a SSD? Shouldn't need that.
Is that actually the case? Honest question here as I am not an SSD engineer. Lacking seek or rotational latency any given block of SSD storage should take equal time to read/write. But does that assure that non-contiguous sequential IO (the thing defragging is intended to eliminate) is exactly as efficient as the contiguous case? (Please forgive my elevation of "shouldn't need that" to the "exactly as efficient" standard.)
It would seem that non-contiguous operations would still involve more IO commands between the host and the controller, and perhaps also more bus operations internally (between the controller and the physical storage.)
If you're going to transfer files over UDP then you need to build some TCP-like protocol on top of it.
No. TCP guarantees sequence, among other things, a property responsible of much of its complexity and overhead. BT should (and does) function well in the absence of transport layer enforced sequencing, automatic packet loss recovery, inadequate (16 bit) checksums, etc.
We really don't need is an arms race of new, greedier protocols
No, we don't, but we're getting one anyhow. BT is doing what it must in this arms race to remain relevant; if it did any less the greedy would abandon it for whatever weapon delivered more bandwidth. BT isn't actually at fault here. Try to remember that as you're knocking back the MSM kool-aid on the evils of BT.
An alternate protocol could conceivably improve on this by applying flow control to the aggregate throughput for the whole "bundle" of connections, rather than each connection individually.
Although it is possible to bake congestion control into an application layer above UDP, is not possible for BT to utilize such a design. Again, if it tried the downloaders would go elsewhere to avoid the congestion control.
This isn't about some technical inadequacy and there is no silver bullet solution. This is about fuckwits that will not stop until The Powers that Be step on them and their nonsense. Naturally we're all going under the boot lest there be some 'unfairness.'
An outfit called Sally Mae is the largest student loan financier in the US. It began as another GSE in the 70's and was later privatized.
If you're involved in collections you know that people that can't afford their own debt prioritize who they're going to stiff. First the education dept, then the credit cards, cars loans and finally the mortgage.
Look around and note the number of layoffs. How much time does Sally Mae have left before some overwhelming fraction of their loans become 'toxic'? Boom.
Short sell opportunity there...
Pay in full at time of service with cash and get 30% off.
Until 'they' outlaw this. Those that can afford to pay cash for their service will be able to escape the collectivized rationing the government provides after it nationalizes the $2.2E12 health care industry. Great Leader and friends will convince 'us' that this is unfair.
Enjoy!
When it installs it must piggyback off the main firefox profile
That's exactly what happens. When the brilliant zootropole says:
Minefield's install won't affect your Firefox, so there's no risk trying it
...he's means only that unpacking the nightly build archive won't replace your existing Firefox binaries. Running it, however, will immediately step all over your default Firefox profile. I guess zootropole doesn't give a damn when he misleads people.
The safe procedure:
1. Shut down FF. (yeah I know it can be done without shutting down, stfukthx)
2. Run your existing FF from the command line like so
firefox -profilemanager
3. Create a new profile (MyFF31profile, whatever) in the profile manager.
4. Run FF31 like so
The above will isolate FF31 to a distinct profile, on *nix. Windows? My sympathies, no help here.
IEEE Std 802.3-2005 clause 40.4.4 Automatic MDI/MDI-X Configuration
Automatic MDI/MDI-X Configuration is intended to eliminate the need for crossover cables between similar devices. Implementation of an automatic MDI/MDI-X configuration is optional for 1000BASE-T devices. If an automatic configuration method is used, it shall comply with the following specifications...
I'm not an IEEE expert but the above appears fairly unambiguous. What I do know is that if it isn't required then you can be certain someone, somewhere omitted it. Heck, it would be found missing even if it were required. Crappy hardware abounds.
Actually, players are divided among servers. Specifically, all players in a single solar system (just "system" in EVE lingo) are isolated to a single thread within a single stackless python process.
This design does not permit real multicore concurrency for a single system. Every player action in space is handled by a single thread. Stackless python provides "microthreads" which gives the illusion of concurrency, but it's really just cooperative multitasking. Lacking real concurrency, EVE can not scale beyond what can be processed in a single thread in a reasonable amount of time. Presently that amounts to about 1000 ships/players.
Microthreads provide none of the concurrency mechanisms (locks, CAS, etc.) that permit threads to safely share data. Thus, the stackless design of EVE can not be scaled using SMP. In my opinion this is a major design flaw of EVE.
The stackless microthread design was chosen for ease of development. Today, that choice plagues the game; it can't be fixed (to permit real concurrency) without a major refactoring of the server side game engine. If EVE will ever scale to what the players actually expect (by virtue of the fact that they don't hesitate to try 1000+ ship battles) then CCP needs to begin thinking about this refactoring; systems should be capable of leveraging multiple cores on demand. That means abandoning microthreads, which is the right decision, because the design imperative behind the choice of stackless (ease of development) is obsolete; half a decade later the new imperative is scalability.
The StacklessIO thing is an improvement to asynchronous IO that CCP deployed earlier this week. It's nice in that it enabled about 1000 players/ships to fight in a system with less "lag" then had been the case with only 500 or so ships. The 32 bit nodes will still crash when they run out of RAM, buy hey, it's an improvement.
I must agree. Conservatives and frightened Democrats prevented a massive take-over by the political class.
Folks, it's a credit bubble. It's not the first and it won't be the last. There are no innocents; individuals have been racking up debt with large, adjustable, flex-pay, no money down liar loan mortgages, second mortgages, equity credit lines and third mortgages. They've been voting for members of both parties to make it happen; the left does it to buy 'low income' votes and the right does it for their Lehman buddies.
Credit bubbles pop. At some point the accumulated crap must be flushed. That doesn't mean we must turn our Government into the investor of last resort. That's exactly how Fannie and Freddy got us here.
Some fraction of all debt is presently considered 'toxic.' 30 seconds after that $700 billion gets legislated into existence the fraction of 'toxic' debt will multiply; the banks will be happy to invent as much 'toxic' debt as your Government thinks it can get away with buying.
Screw that. I'm not under and mountain of debt and I'm not afraid of those of you who put yourselves under one. Life is too short to live in fear of morons.
This is no longer the "first" directly observed extrasolar planet? What value of "first" is are we using now?
aren't as fine-grained as they could be
See clone(2). Every significant resource related to a process is selectable when spawning a new thread of execution. pthread_create() and fork() are both implemented in terms of clone(). You may invent you're own mix of shared or copied bits according to your specific needs.
Naturally the Windows case is far less general. First, clone() is too short. MinimumWindowsAPISymbolLengthIs(12). There is no fork(). This makes porting fun; see perl, cygwin, et al.
The design intent of Google's Chrome is, simply put, scalability. That's why they focus on Javascript performance; the faster that goes the larger the domain of possible applications. Separate processes mean fault tolerance and privilege isolation, important for long lived native operations doing privileged stuff. Ultimately you figure out the browser is sufficient for the entire GUI. When that happens using concurrent processes instead of threads becomes a requirement.
Paralell (sic) code is almost always superior... ...but the number of threads is impressive
Nothing impressive about it. Just because you detect a gaggle of threads doesn't prove the program is a collection of brilliant concurrent algorithms. Spawning an excessive number of threads is a common symptom of poorly written code. In practice I more often see threaded code being used to produce half-baked asynchronous IO systems often on platforms that already provide excellent IO multiplexing APIs.
You can't evaluate use of threads in IE8 from the limited empirical evidence provided here. You may compare it to the behavior of existing successful designs. With IE8 you end up asking "why so many freaking threads?" The answer is probably naive reimplementations of fork() to achieve asynchronous IO or privilege isolation.
Your Wired story provides an Anchorage Daily News link with the following:
She added that, if elected, she would not push the state Board of Education to add such creation-based alternatives to the state's required curriculum.
At one time Clinton was "pro-life". He conveniently modified that position for the Federal stage and Palin will do likewise. Hysteria about her creationism will fail.
How does this translate into normal transfer speed units like MB/s? Otherwise I have no point of reference to tell if I am impressed or indifferent.
I'll try to help.
MB/s is a measure of IO throughput. Often this isn't the most relevant figure for 'enterprise' storage. Certain applications do a lot of random access IO so IOPS becomes more important than throughput.
Today a typical desktop disk is capable of about 100-150 IOPS. That's a rule of thumb range that varies based on operation size, cache, etc. It works pretty well usually. You can aggregate disks and get almost linear scaling; 12 disks, for instance in a device like this, will give you a maximum of 1200 IOPs, roughly. A common USB Flash device can break 1000 IOPS with certain access patterns.
The second graph on this page illustrates the extreme IOPS advantage of Flash for certain applications. Disks are limited by head actuation and rotation latency. This is why enterprise storage vendors have been pursuing Flash aggressively. That's what this story is all about.
The dream is to host the same IOPS in with an order of magnitude less physical space, power, heat, etc. If you don't need thousands of IOPS (and most PC users don't) then it isn't very interesting. If you happen to run an OLTP system with thousands of reads/write per second it means a great deal.
250GB/month =
0.77Mb/s (megabits) * 24/7
(a bit less than half a T1 running an full capacity)
3.31 days At 7.0Mb/s and you're out.
Not bad for cheap McInternet service, I guess...
Or are they just shooting for a free alternative?
The "just" part there is considered a problem. The argument goes that SSL would be ubiquitous if there were no cost, hassle, discloser requirements, etc. Imagine, for instance, that common web servers automatically generated self-signed certs as needed and that these certs were used to encrypt everything by default. This is how SSH servers (OpenSSL) typically work today.
As it is this isn't really possible because browsers erupt warnings, confirmation dialogs and other spasms when a self-signed cert is encountered. This is unacceptable for the bulk of users.
I have always thought that requiring encryption to be coupled with identity is a mistake. Identity needs encryption while encryption doesn't necessarily need identity; encryption is useful independently, regardless of what the security zealots claim.
$15 and a phone call to get a signed cert really is too much to ask. Some people have a difficult time understanding that.
How to fix it? I dunno.
Many around /. advocate eliminating the browser machinations over self-signed certs. This will never happen; compromising what limited integrity contemporary SSL provides will not be supported by the powers that be. IETF will not sign on to it. Verisign won't. Forget it. Any browser vendor foolish enough to fail to comply will be lambasted as insecure and shunned by major institutions.
Call the existing system "legacy" and invent something new? Microsoft won't buy it. Scratch 80% of all web traffic.
IPv6 with it's mandatory IPsec support? See you in 2030 I guess.
P.S. this recent hubbub about Firefox and it's warnings about self-signed certs; this isn't new. Firefox, IE and other browsers have been doing this for years. FF 3.x behavior is not some new phenomena for slashdot to hyperventilate over.
I'm glad you putted that one right.
Probably Mr. Shannon.
The new connector provides contacts for new wires. This is necessary because the existing wires can not operate at the frequency necessary for 5GB and remain compatible with legacy devices.
Physics, information theory, etc.
You're doing it wrong.
You can't appeal to reason; these folks hear 'for the children' and go sideways instantly. You must learn to find ways to appeal to malcontents by leveraging their contrarianism and hatreds. Observe:
Removing the doping bans would throw open the doors to big Pharma influence over Sports. Atheletes will end up wearing sponsorship banners on their uniforms advertising the steriods and "sport enhancements" they are obligated to consume to participate in their sport. This will constitute and endorsement the masses will accept as they become the unwitting victims of greedy drug corporations. As this acceptance permiates Society these obligations will also begin appearing outside of the domain of Sports, eventually appearing in non-Sports related occupations.
See? Implicit corporate evil and fear of/for the ignorant masses has been used to trump the lesser evil of sports authorities. Vastly more effective, around here.