Well, any form of credit payment (which is the norm for electronic commerce) is nothing more than a promise to pay at a later date.
Ccard companies factor a given amount of loss due to error, fraud, etc, into their business models. It is perfectly reasonable to suggest a model in which a subset of users paid. If that subset could be accurately predicted, even better.
In either case, you are forgetting the time-honored system that puts the bread on the table for everyone from waiters to strippers: it's called _Gratuity_.
Okay, is this just me or does it look like the napster bans were requested _soley_ to drive people to their site & force them into "registering"? Isn't there some way Napster can legally elect to flat-out ignore them, on the grounds that they are flagrantly abusing the provision?
With all due respect to the frighteningly-evolved world of compiler research, even the best compiler is unlikely to match hand-written assembly for lots of tasks.
For one thing, a higher-level language is simply too vague for conveying processor-specific instructions, and there are plenty of times when an astute programmer can apply her understanding of an algorithm to prefetch data intelligently, structure code to jive with a particular processor's branch prediction rules, exploit pairability of certain simple operations, and so forth.
Mind you, an intelligent compiler will try to employ these same strategies, but its ability to do so is dependant on the choice of higher-level instructions given by the programmer. For instance, a particular processor might have an instruction that can test for zero and jump in a single clock cycle. In this case, the difference between iterating up versus down to zero in a for loop might determine if the compiler can actually exploit this.
A programmer who is intimately familiar with the vagaries of a particular compiler will have better luck, but this generally ends up being more trouble than it's worth.
For some applications, the importance placed on performance justifies the time necessary to hand-optimize code in assembly. This is not exclusive to people writing, say, memory allocation routines for an os. If any piece of code is called often enough, a difference in execution time of a couple dozen clock cycles may make the difference between a usable application and one that sucks. (Of course, this all assumes that the overall algorithm/design is sensible in the first place. Assembly will not save you from shitty code.)
I could swear there was a tidbit on the news a couple weeks ago about the campus police deciding (after some deliberation) to cancel orders for several M-16 derivatives for their arsenal.
Imagine the bowl-cleansing horror of having a bunch of yokel campus cops armed with *assault rifles* storm your dorm room, having confused a video game enthusiast club with a murder conspiracy. What do we give the odds of an accidental shooting..?
So obviously 'net broadcasts dramatically increase the effective size of a station's market. Hence it makes perfect sense that the fee structure should consider this context, particulaly when this broader market may be considered when pricing advertising.
However, one factor that distinguishes this from radio broadcast is that the audience can be accurately tracked (as opposed to fuzzy methods used to generate ratings for traditional radio). For starters, stations should lobby for reasonable stepping of fees based on such statistics...
(So I'm not generally one to get all riled up about environmental issues, but DANG. I hope Mr. Ellison stays up nights realizing that Mother Earth wants to rape his ass...)
The one thing that struck me about these systems is the alarming lack of wireless technology. Maybe it sounds more impressive to put 30 miles of cabling through your walls, but it seems that a more elegant (cheaper, more flexible, less intrusive, generally much more effective) solution must exist. But then, these guys are CEO's, not scientists or engineers...
This dead horse may have been flogged already, but here goes again...
Although the line separating SAN's and NAS is starting to blur in some places, the difference is probably best shown by where (in the IO path) the network lies.
In a SAN, the network is placed between raw block-addressed storage devices and the host/filesystem. The networking medium here is generally something that has its genesis in internal host bus technology (fibre channel, infiniband, etc), and the storage devices (large RAID arrays, tape libraries, etc) tend to behave just like the HD or CD burner out on your home machine's SCSI bus (SCSI is actually the language most of these fibre channel storage devices speak). The filesystem is the business of attached servers, _NOT_ exposed within the SAN.
NAS devices, on the other hand, place the network in front of the filesystem. In other words, a NAS box like NetApp's Filer series will actually have a filesystem on it. The networking medium here is often Ethernet (Gbit or otherwise), and hosts connect to the storage devices directly via file-level protocols (NFS, SMB, CIFS, etc).
So the filesystem is a component of a NAS device, but is _NOT_ a concern for a traditional SAN implementation.
As for multiple hosts accessing the same data, as you have mentioned, this is certainly within the capability of the networked filesystem onboard your NAS device. In the case of a SAN, although it will generally be possible to make logical volumes accessible to multiple hosts this is not usually usefull (remember, the filesystem is a construct of the host, not the disk itself!).
FYI, this "Home Recording Rights Coalition" has related info on their website, including details on how to comment to the FCC.
(see http://hrrc.org/html/what_s_new_at_the_fcc.html)
Since it treats code in a more utilitarian manner, does this ruling give traction to the idea that software manufacturers can be held liable for damage caused by their software..?
When the author speaks of "script kiddies", he implies an attacker who does not fundamentally understand the technology they are exploiting. It seems like the issue he _should_ have been focusing on is the problem of a clever minority creating easy-to-use pre-packaged cracking tools, thus empowering masses of dumb angry kids who would otherwise be completely harmless.
Clearly one motivation for widely distributing a cracking tool that any idiot could use would be to force an unresponsive & incompetent software company to fix obvious dangerous problems that they might otherwise continue to ignore. This could be seen as legitimate activism.
While a penetration tool that is easy to use facilitates legitimate security auditing, it seems reasonable to question the judgement of lowering the threshold of competence required to wage an effective attack...
Yes, but for WHO? Career beuraucrats won't even dream of commenting on this issue. We need a concerted effort to ferret out those just beginning their careers as politicians who are willing to state concrete positions on this so we can support them like all hell...
Any communication with actual physical hardware is very timing-critical. Just as you need realtime guarantees in order to make your missile hit its target, a tape drive or CDR needs to be provided with data at a particular rate in order to dump those bits onto the media as it passes.
Of course, many really nasty timing-critical tasks like moving graphics data to your video card, or (link-layer) network traffic processing are handled by carefully crafted interrupt handlers, the firmware on your NIC, etc. But more complex tasks (burning a CD, for instance) simply cannot be done at that level. Applications that directly control mechanical processes (for manufacturing, teledildonics, whatever) generally require this kind of precision. This is a requirement for many embedded applications, and is thus necessary if Linux is to be usefull outside of the catch-all realm of desktop PCs.
Slashdot Mirror
Well, any form of credit payment (which is the norm for electronic commerce) is nothing more than a promise to pay at a later date.
Ccard companies factor a given amount of loss due to error, fraud, etc, into their business models. It is perfectly reasonable to suggest a model in which a subset of users paid. If that subset could be accurately predicted, even better.
In either case, you are forgetting the time-honored system that puts the bread on the table for everyone from waiters to strippers: it's called _Gratuity_.
Okay, is this just me or does it look like the napster bans were requested _soley_ to drive people to their site & force them into "registering"? Isn't there some way Napster can legally elect to flat-out ignore them, on the grounds that they are flagrantly abusing the provision?
With all due respect to the frighteningly-evolved world of compiler research, even the best compiler is unlikely to match hand-written assembly for lots of tasks.
For one thing, a higher-level language is simply too vague for conveying processor-specific instructions, and there are plenty of times when an astute programmer can apply her understanding of an algorithm to prefetch data intelligently, structure code to jive with a particular processor's branch prediction rules, exploit pairability of certain simple operations, and so forth.
Mind you, an intelligent compiler will try to employ these same strategies, but its ability to do so is dependant on the choice of higher-level instructions given by the programmer. For instance, a particular processor might have an instruction that can test for zero and jump in a single clock cycle. In this case, the difference between iterating up versus down to zero in a for loop might determine if the compiler can actually exploit this.
A programmer who is intimately familiar with the vagaries of a particular compiler will have better luck, but this generally ends up being more trouble than it's worth.
For some applications, the importance placed on performance justifies the time necessary to hand-optimize code in assembly. This is not exclusive to people writing, say, memory allocation routines for an os. If any piece of code is called often enough, a difference in execution time of a couple dozen clock cycles may make the difference between a usable application and one that sucks. (Of course, this all assumes that the overall algorithm/design is sensible in the first place. Assembly will not save you from shitty code.)
I could swear there was a tidbit on the news a couple weeks ago about the campus police deciding (after some deliberation) to cancel orders for several M-16 derivatives for their arsenal.
Imagine the bowl-cleansing horror of having a bunch of yokel campus cops armed with *assault rifles* storm your dorm room, having confused a video game enthusiast club with a murder conspiracy. What do we give the odds of an accidental shooting..?
Please read the press release on the site. It should be pretty clear that this is a hoax... (count the exclamation points, for one thing...)
So obviously 'net broadcasts dramatically increase the effective size of a station's market. Hence it makes perfect sense that the fee structure should consider this context, particulaly when this broader market may be considered when pricing advertising.
However, one factor that distinguishes this from radio broadcast is that the audience can be accurately tracked (as opposed to fuzzy methods used to generate ratings for traditional radio). For starters, stations should lobby for reasonable stepping of fees based on such statistics...
(So I'm not generally one to get all riled up about environmental issues, but DANG. I hope Mr. Ellison stays up nights realizing that Mother Earth wants to rape his ass...)
The one thing that struck me about these systems is the alarming lack of wireless technology. Maybe it sounds more impressive to put 30 miles of cabling through your walls, but it seems that a more elegant (cheaper, more flexible, less intrusive, generally much more effective) solution must exist. But then, these guys are CEO's, not scientists or engineers...
This dead horse may have been flogged already, but here goes again...
Although the line separating SAN's and NAS is starting to blur in some places, the difference is probably best shown by where (in the IO path) the network lies.
In a SAN, the network is placed between raw block-addressed storage devices and the host/filesystem. The networking medium here is generally something that has its genesis in internal host bus technology (fibre channel, infiniband, etc), and the storage devices (large RAID arrays, tape libraries, etc) tend to behave just like the HD or CD burner out on your home machine's SCSI bus (SCSI is actually the language most of these fibre channel storage devices speak). The filesystem is the business of attached servers, _NOT_ exposed within the SAN.
NAS devices, on the other hand, place the network in front of the filesystem. In other words, a NAS box like NetApp's Filer series will actually have a filesystem on it. The networking medium here is often Ethernet (Gbit or otherwise), and hosts connect to the storage devices directly via file-level protocols (NFS, SMB, CIFS, etc).
So the filesystem is a component of a NAS device, but is _NOT_ a concern for a traditional SAN implementation.
As for multiple hosts accessing the same data, as you have mentioned, this is certainly within the capability of the networked filesystem onboard your NAS device. In the case of a SAN, although it will generally be possible to make logical volumes accessible to multiple hosts this is not usually usefull (remember, the filesystem is a construct of the host, not the disk itself!).
FYI, this "Home Recording Rights Coalition" has related info on their website, including details on how to comment to the FCC. (see http://hrrc.org/html/what_s_new_at_the_fcc.html)
Since it treats code in a more utilitarian manner, does this ruling give traction to the idea that software manufacturers can be held liable for damage caused by their software..?
When the author speaks of "script kiddies", he implies an attacker who does not fundamentally understand the technology they are exploiting.
It seems like the issue he _should_ have been focusing on is the problem of a clever minority creating easy-to-use pre-packaged cracking tools, thus empowering masses of dumb angry kids who would otherwise be completely harmless.
Clearly one motivation for widely distributing a cracking tool that any idiot could use would be to force an unresponsive & incompetent software company to fix obvious dangerous problems that they might otherwise continue to ignore. This could be seen as legitimate activism.
While a penetration tool that is easy to use facilitates legitimate security auditing, it seems reasonable to question the judgement of lowering the threshold of competence required to wage an effective attack...
Yes, but for WHO? Career beuraucrats won't even dream of commenting on this issue. We need a concerted effort to ferret out those just beginning their careers as politicians who are willing to state concrete positions on this so we can support them like all hell...
Any communication with actual physical hardware is very timing-critical. Just as you need realtime guarantees in order to make your missile hit its target, a tape drive or CDR needs to be provided with data at a particular rate in order to dump those bits onto the media as it passes.
Of course, many really nasty timing-critical tasks like moving graphics data to your video card, or (link-layer) network traffic processing are handled by carefully crafted interrupt handlers, the firmware on your NIC, etc. But more complex tasks (burning a CD, for instance) simply cannot be done at that level.
Applications that directly control mechanical processes (for manufacturing, teledildonics, whatever) generally require this kind of precision. This is a requirement for many embedded applications, and is thus necessary if Linux is to be usefull outside of the catch-all realm of desktop PCs.