I mean... do you have exactly 1024 gigabyte-sized objects you need to exactly fit on your hard drive? Of course not.
The abuse-of-SI prefix business shouldn't surprise anyone, IMHO. Every box has that little "*" next to the size and the units below. And some manufacturers are realizing that at GB sizes and up, that discrepancy is getting large enough to be complain-aboutable, and they are now advertising the "real" size (or showing both on the box with equal billing). And if you needed that extra power-of-two scale factor wiggle room at the 1TB, buy four 300GB drives instead, and get the benefit of fewer-platters-per-drive, and more spindles.
Oh, don't forget to account for room for FS formatting and extent allocation slack.
No. Just please, leave. What the fuck is wrong with people? You just learn the metric system? Got a stick up your ass?
Is there are problem with 4KB being an even multiple of a HD sector (512 bytes)? Is that A FUCKING PROBLEM FOR YOU?
Oh wait, those of us who actually deal with these under-the-hood type issues actually HAVE PRETTY FUCKING GOOD REASONS for kilobyte to be different than kilobaud. You can go back to playing with photoshop and jerking off onto your blog, where you'll complain about god knows what else, you fucking technocrati.
KILO IS AN ORDER OF MAGNITUDE MEASURE FROM LATIN! GET OVER YOURSELF
Gigabyte doesn't mean anything else beyond 1024^3 because you never need to measure storage in units other than powers of two, because of the memory addressing limitation.
I mean, the 2TB limit of SCSI LUNs is 2*1024^4, not 2 * 1000^4. So that 1024GB = 1TB is very, very important in that respect.
There is NO REASON for a gigabyte = 1000^3 bytes to exist at all. So why introduce a prefix that is only ever used for bytes, especially when the base-10 prefix is NEVER used for the same purpose?
Why do we have to change our order-of-magnitude prefix based on context, and choke out poorly-stressed pseudo-latin prefixes that make us sound even more like properllerheads?
It's just not right. No amount of wishing the word means something other than what we already agree it to mean is going to change anything.
And the only time when the unit causes confusion is when you try to use those size quantities in mixed representations with SI units, like time.
And the rule there is to either go with the proposed SI units IN THAT CIRCUMSTANCE, to avoid confusion, or even better:
Use scientific notation and base units drop the SI prefix OR Use a telco-specific term... multiply the base-10 value by 8 and call it "baud" OR Use base-10 SI prefixes and change "bytes" to "octects"
Octects are bytes represented "outside" of the computer without underlying assumptions to medium, and so base-2 addressing requirements are not necessary, and so normal SI prefixes make sense.
Furthermore octects are encoding independant... a conversion from apparent MiB/s at a software interface into megaoctects per second over the wire could take into account 10-bit octects and other strangeness that would cause greater disparity than just 1024^2 vs one million
FLOPs are Hz. Hz is a time unit, and has nothing to do with the reasoning why data structures in computers are measured in 2^20 increments.
The logic is:
* If you're counting something in IT which has a physical SI basis (time) then you're using SI prefixes when you say kilo and mega. I.E. Mbps.
* If you're counting something in IT which is purely a software construct, and specifically you are talking about a size requirement, then you're using the "computer" prefixes when you say kilo and mega.
So, long story short: kilobytes = 1024. Megabytes = 1024^2. And so forth. DATA SIZING ONLY. NO MIXING WITH SI-UNITS UNLESS YOU CLARIFY. That means if you want to represent the speed of transfer between hard drives in 2^20-sized units per second, you write MiB/s to avoid confusion. And LO, that is standard practice.
But a 4KB sector size means 4096, and NOTHING ELSE. 4KiB or what the fuck ever makes no sense. The point of using shorthand like that is to reduce the required precision to jot down something precisely. And in the computer software domain, values like 1kb, 4kb, 1MB are actually important that they mean what we "know" them to mean. Addressing block offsets in a database, making sure your table extent sizes add up to the size of the files containing them... just use the one unit that is going to not require extra precision in the preferred multiples of the units and such! Imagine trying to deal with that if it was 4.1kb and 1.05MB and do they add up to my file size usage of 262MB or do I have round-off error?
EVERYTHING ELSE (kilo*, mega*) involving computers is 10^3, 10^6, etc. Megahertz, kilo-baud, they are all base 10 without question.
NForce3, Via, Broadcomm chipsets... or the very, very newest in interconnect tech for which the drivers have not been stabilized (in my case: PCIe SAS controllers, I'm looking at you)
But then, if you run say RHEL 4 (2.6.9) or Slackware 10 on a nice piece of kit then you get AIX-like stability. It's when you use fancier, newer features (i.e. experimental filesystems) or more esoteric hardware that you can get yourself into trouble. And even so, if they're clustering it then you'd expect they'd build in node failover and monitoring, so a hard freeze should trigger a watchdog and someone goes and kicks it in the head (if that isn't automated). And you log it, just in case a node is actually developing hardware failures.
We would assume they would test, test, test to identify the stable configurations before hand. It would be irresponsible to do otherwise.
It is trivial to overcome color variation issues: you use a perceptual transformation of the image data. For example, discard the hue, normalize the saturation and use it to weight the value. Or calculate the difference-from-background color metric. Or use a luminence-based edge detection algorithm (basically a convolution kernel). yadda yadda yadda.
Yeah, that stuff's childs play. The real hard stuff is finding letter shapes that are difficult for OCR algorithms to handle, yet are "legible enough" for humans without disgusting them like some illegible CAPTCHAs out there.
One technique I like is to use a 3d extruded wireframe version of each letter, but projected isometrically. Then you take the endpoints of your lines and arcs and jitter them, allowing line edges to cross or to become disconnected.
The human eye is really good at picking out the letter outlines in 3d (especially since you have reinforcement of the front-face pattern with back faces) That extra information helps overcome the jitter.
But OCRs of this generation focus on line corners and points of interest (features that are mostly scale/rotate and font-invariant) so lines that cross or end prematurely are particularly problematic for these algorithms.
I'm saying that if the brain/ear interface actually had non-linear aspects that mattered, then it wouldn't be possible to resolve directionality without a head-transform for cues -- X o'clock relative to your ear centerline in an anechoic chamber if you will -- by just phase alone. And you can pick any combination of harmonics and it still sounds okay.
So for the interesting primary frequencies that the ear is designed to pick up, it seems the brain assumes linear properties for sound, even if physically that is an approximation of reality.
So an audiophile can believe what he wants about the non-linear properties of high-frequency sound. But if it ain't in the range that my A/D filter is set at, you can't hear it anyway and what you can hear is linear enough to be captured appropriately by the system.
And you do realize I was being somewhat facetious in my previous post, right?
Also, I hate audiophiles. In case you couldn't guess.
That's why I emphasized "relative to cost". You can mechanically afford a standard-sized cabin with effective torque and range provided you use the right amount of batteries. But the cost of these batteries is high relative to a mass-produced drivetrain.
By making the vehicle lighter you can get away with less required stored energy and the batteries don't push the price too far above a luxury compact.
I mean --- I'm not saying we'll never get there. But right now hybrids are cost-effective because you don't need nearly as many batteries, and you can throw in a cheap, light engine that is not intended to direct drive, but is geared only for electricity production.
Also: it's not like you don't pay for the KWh to juice your car. It's about 8 times cheaper* than gas but at the same time, if your vehicle has the same range and power of the car you're trying to replace, then you're paying that upfront cost that you have to wait 5 years or more before it breaks even.
*8 times cheaper than gas: ICE hybrid drivetrains are about 20% efficiency, while full electric cars have about 80% efficiency. Cost per kWh is 5 cents for residential wall power. Gasoline has 33 kWh/gal, and at $3.20/gal that's 10 cents a kWh. (.10 /.5) * (.8 /.2) = 8
It's just pure data mining. But if you're google, you are going to turn everything into an attribute, and you have the luxury of running your classifiers over gigantico training sets to pick out minute details and correlations. And you can settle for low support values; all that matters is that some profitable subset of people targeted by a campaign respond to it. So if that target is to "reach" 1% of the market, and 10% of the people in the training set have a correlated action and responded to a survey a certain way; and if of those 10% you have 10% support of a correlation --- well that's good enough for google-scale ads to be considered potentially successful!
but there's no reason to distribute it that way... that just wastes bandwidth.
You should really be using a modern perceptual codec. I hear AAC and Vorbis are nice. And they support 48Khz recordings with arbitrary bit depths / dynamic ranges.
But if you compress at 6:1 - 8:1 using modern codecs, you WILL NOT notice in an A/B test. What you're 'hearing' is the knowledge that you used a lossy codec in the first place -- like people seeing Jesus in pieces of toast and tree bark.
Of course, there are some really shitty (read: old) codecs out there. Don't use them. But an ogg -q6 is quite literally indistinguishable from FLAC (again, only when barring the apriori knowledge of the format... otherwise most audiophiles can suddenly 'hear' the difference again)
I think it's disingenious to talk about air as a non-linear system. It doesn't start acting non-linear until you're talking about distances (and/or/which imply) amplitudes that would shatter your eardrums or kill you.
I mean, let's talk about the non-linearity of speakers! They're damped oscillators!
And you can prove to an audiophile (hearing is believing) that sound is sufficiently linear to make such arguments irrelevant.
Take two frequencies (say... 14000 and 14300). If you play them, you get a 300Hz beat. Put that on one channel. Now take a 300Hz sine on the other channel, and then adjust the phase slowly. You should "hear" the 300Hz tone moving around the sound stage.
This experiment only works because sound reproduction (and your ears/brain) are a sufficiently linear system that trying to call it anything else when making qualitative arguments is just silly.
Batteries are expensive, heavy, and (potentially) environmentally damaging to produce/destroy. HP is low (although torque is constant across RPMS -- a different kind of advantage which doesn't drive sales). You need to reduce weight to account for batteries so cabin sizes suffer and become more bubble-like.
Batteries don't yet have the energy density (relative to costs) to make full-electrics feasible unless they did things like electrolyze water on charging and use said hydrogen in fuel-cells during driving (hydrogen has a high energy density by weight).
the stock stereos have bigger amplifiers, drivers and heatsinks that's accounting for the drop in milage.
Airbags are LIGHT. Traction control is a COMPUTER that by-wires the BRAKES. These kind of changes are minute compared to the ones that actually matter:
* CAD vs. human designed complex structures -- body panels, door hinge designs, dash/firewalls * Unibody construction vs. body on frame * Polycarbonate windshields * Alloy wheels and vented 4-wheel disk brakes * Crumple zones
etc... these are things that affect the composition, size and shape of the heavy/large components of the vehicle. And how they were designed and the material usage has changed a lot.
I mean, there were performance cars in the 80s that used a lot of the higher-tech techniques to reduce weight that are common in all cars now by the changing industry.
I am quite familiar with the NISPOM... but everyone hates COEs (which is what you really need if you're going to try to set up any moderately complicated system)
IMHO, DISA doesn't really seem to care if you are that anal about configuration management (I've never seen an inspector look at a mouse or monitor with any seriousness). They are more concerned with functional safeguards (does the system actually behave correctly and log appropriately) and appropriate reactions to questions from key personnel (i.e. "Show me your backup password list". Correct response: "No.")
You apparently don't remember when we used to get ASCII-art trolls constantly; pictures of goatse made up of pictograms (thanks 2ch for the inspiration...) They started stripping everything non-USASCII and looking for things that look like blocks of text and filtering them out.
I mean, it's nice to do it all in one command, but all it's doing is: gunzip -9 infile | tar xf - When you add that z flag to "tar xzf infile"
Syntactic sugar. I don't know, tar and cpio are really shitty archive formats anyway unless you need to do stuff in a stream. We need an archive format with per-file (or per-directory) compression and an index so you can actually use the goddamn SEEK system call to speed up access... (and infozip, while it has some nice Unix features, is limited by compatibility with other implementations).
A build system would not be ideal. I should be able to point my boxes at a mirror (or enterprise-central) server, search or ask it to install a package by name, it download only what I need, install it and the prerequisites (updating anything that would need to be updated in the process), put example config files in the right place, all without using Make or CC.
Only the LSASS can grant authorization tokens to processes. Things like Winlogon (what you see when you login and also lock the screen) and the Run As... service run as Local System at startup. Only Local System stuff has the privledge to ask LSASS to create tokens that allow sub-processes to run with other identities; i.e. "Administrator" or whatever user you use when you login. It is also needed to do things like verify passwords. Normal programs can't actually ask takeyour Windows password, hash it, and verify it themselves... only LSASS can actually do that.
So you have LSASS which is started by the kernel at boot time, and it handles all of that stuff. In addition, any process which parents processes which run at a low authority also gets started by the kernel with Local System permissions as well (i.e. csrss, winlogon, the service host) No suexec or anything like that is available... NT doesn't use "execute through" methods for assigning security tokens to processes.
This is in contrast to Unix; while processes can certainly drop down in privledge as in NT, and many services are modeled that way, it is also essential in Unix to "privledge up". That is, to be able to start processes running as an unprivledged user and call into a executable image running as a different user (presumably with internally coded policy that enforces security from the respect of the original running user, take the "passwd" command for example). But this leaves room for a lot of security issues, and so the push now is to severly restrict what files are chmodded "+s" and to audit them closely.
A number of software packages have changed how they operate (especially those that interact with hardware). Many of them at some point were suexec-root based, to talk to audio, video, or serial devices and such. Now such software is usually broken into parts, one half runs at boot time in a privledged mode as a service- providng the other half (UI) an API which can run as an unprivledged user. Other software packages changed their installation instructions, informing the installer that they would need to change permissions on certain devices to let end users manipulate them with software running in an unprivledged mode. Still others don't check at all, but assume the login scripts for the system change the permissions on commonly used devices to the current logged-in user (through the use of facilities such as PAM). This only works for the user sitting at the device, but it's a good assumption, since it's the usage scenario that most end-users care about when using software that interfaces with local hardware.
If you read the comments posted in response to both articles, interested readers who have opinions on the issue do not, in general, actually believe that we should abolish copyright and leave a vacuum. Because we all know (with the exception of a few utopia-ists) that many businesses would fall apart and in general it wouldn't be very good, especially for anyone in IT.
And would such a poorly thought-out change in law even come about short of armed uprising?
In any case, I think the point is that the original article's author was addressing a viewpoint that few actually have, save the most vocal mouthbreathers and me-tooers on various forums and blogs. When I read it when it first came up, I skipped the slashdot discussion because I thought it was "obvious" flamebaiting since it assumes that no one has considered the duality before (current ironic situation vs. where you ACTUALLY want to be with respect to IP law) I don't know, I've seen that discussion done to death on Slashdot a million times before, so apparently we've thought about it a little.
And this guy just wanted to poke a beehive to get the Google AdSense traffic... and this other guy is calling him out on his arguments (they're not incorrect, they just miss the point... it's like, why are we even talking about this?)
Blargh. I hate the blogosphere, for just this reason.
You really didn't read the article, did you. You read it up until the point where you confirmed the position you thought it was taking, and then assumed the rest to be bollocks or whatever.
THE POINT was that the GPL would need to be changed if copyright laws were changed. The spirit of the GPL (Cohesion and Continuity, per the article) would be enforced by other clauses that would be created in light of whatever law takes the place of copyright, again per the article, "... be enforced using laws so drastically different from our laws today as to be unrecognizeable".
His position is that we can't just get rid of copyright, but we would have to replace it with something more modern. Something 21st century. Something that can be used to prove right of authorship and prevent plagaristic forms of derivative works, without limiting scope of distribution by the public, by default.
And the GPL would have to evolve to fit in that environment.
Slashdot Mirror
I mean... do you have exactly 1024 gigabyte-sized objects you need to exactly fit on your hard drive?
Of course not.
The abuse-of-SI prefix business shouldn't surprise anyone, IMHO. Every box has that little "*" next to the size and the units below.
And some manufacturers are realizing that at GB sizes and up, that discrepancy is getting large enough to be complain-aboutable, and they are now advertising the "real" size (or showing both on the box with equal billing).
And if you needed that extra power-of-two scale factor wiggle room at the 1TB, buy four 300GB drives instead, and get the benefit of fewer-platters-per-drive, and more spindles.
Oh, don't forget to account for room for FS formatting and extent allocation slack.
And your swap file.
And room to defragment or move files around.
No. Just please, leave.
What the fuck is wrong with people? You just learn the metric system? Got a stick up your ass?
Is there are problem with 4KB being an even multiple of a HD sector (512 bytes)? Is that A FUCKING PROBLEM FOR YOU?
Oh wait, those of us who actually deal with these under-the-hood type issues actually HAVE PRETTY FUCKING GOOD REASONS for kilobyte to be different than kilobaud. You can go back to playing with photoshop and jerking off onto your blog, where you'll complain about god knows what else, you fucking technocrati.
KILO IS AN ORDER OF MAGNITUDE MEASURE FROM LATIN!
GET OVER YOURSELF
And when we deal with memory system, base-10 doesn't make sense anymore. And we don't say "octets", we say "bytes".
So one giga-octect = 1000^3 octects
And one gigabyte = 1024^3 bytes
That's it. End of story.
Gigabyte doesn't mean anything else beyond 1024^3 because you never need to measure storage in units other than powers of two, because of the memory addressing limitation.
I mean, the 2TB limit of SCSI LUNs is 2*1024^4, not 2 * 1000^4. So that 1024GB = 1TB is very, very important in that respect.
There is NO REASON for a gigabyte = 1000^3 bytes to exist at all. So why introduce a prefix that is only ever used for bytes, especially when the base-10 prefix is NEVER used for the same purpose?
Why do we have to change our order-of-magnitude prefix based on context, and choke out poorly-stressed pseudo-latin prefixes that make us sound even more like properllerheads?
It's just not right. No amount of wishing the word means something other than what we already agree it to mean is going to change anything.
And the only time when the unit causes confusion is when you try to use those size quantities in mixed representations with SI units, like time.
And the rule there is to either go with the proposed SI units IN THAT CIRCUMSTANCE, to avoid confusion, or even better:
Use scientific notation and base units drop the SI prefix OR
Use a telco-specific term... multiply the base-10 value by 8 and call it "baud" OR
Use base-10 SI prefixes and change "bytes" to "octects"
Octects are bytes represented "outside" of the computer without underlying assumptions to medium, and so base-2 addressing requirements are not necessary, and so normal SI prefixes make sense.
Furthermore octects are encoding independant... a conversion from apparent MiB/s at a software interface into megaoctects per second over the wire could take into account 10-bit octects and other strangeness that would cause greater disparity than just 1024^2 vs one million
So it's partly an aspect of UNITS.
FLOPs are Hz. Hz is a time unit, and has nothing to do with the reasoning why data structures in computers are measured in 2^20 increments.
The logic is:
* If you're counting something in IT which has a physical SI basis (time) then you're using SI prefixes when you say kilo and mega. I.E. Mbps.
* If you're counting something in IT which is purely a software construct, and specifically you are talking about a size requirement, then you're using the "computer" prefixes when you say kilo and mega.
So, long story short:
kilobytes = 1024. Megabytes = 1024^2. And so forth.
DATA SIZING ONLY. NO MIXING WITH SI-UNITS UNLESS YOU CLARIFY. That means if you want to represent the speed of transfer between hard drives in 2^20-sized units per second, you write MiB/s to avoid confusion. And LO, that is standard practice.
But a 4KB sector size means 4096, and NOTHING ELSE. 4KiB or what the fuck ever makes no sense. The point of using shorthand like that is to reduce the required precision to jot down something precisely. And in the computer software domain, values like 1kb, 4kb, 1MB are actually important that they mean what we "know" them to mean. Addressing block offsets in a database, making sure your table extent sizes add up to the size of the files containing them... just use the one unit that is going to not require extra precision in the preferred multiples of the units and such! Imagine trying to deal with that if it was 4.1kb and 1.05MB and do they add up to my file size usage of 262MB or do I have round-off error?
EVERYTHING ELSE (kilo*, mega*) involving computers is 10^3, 10^6, etc. Megahertz, kilo-baud, they are all base 10 without question.
NForce3, Via, Broadcomm chipsets... or the very, very newest in interconnect tech for which the drivers have not been stabilized (in my case: PCIe SAS controllers, I'm looking at you)
But then, if you run say RHEL 4 (2.6.9) or Slackware 10 on a nice piece of kit then you get AIX-like stability. It's when you use fancier, newer features (i.e. experimental filesystems) or more esoteric hardware that you can get yourself into trouble.
And even so, if they're clustering it then you'd expect they'd build in node failover and monitoring, so a hard freeze should trigger a watchdog and someone goes and kicks it in the head (if that isn't automated). And you log it, just in case a node is actually developing hardware failures.
We would assume they would test, test, test to identify the stable configurations before hand. It would be irresponsible to do otherwise.
It is trivial to overcome color variation issues: you use a perceptual transformation of the image data. For example, discard the hue, normalize the saturation and use it to weight the value. Or calculate the difference-from-background color metric. Or use a luminence-based edge detection algorithm (basically a convolution kernel). yadda yadda yadda.
Yeah, that stuff's childs play. The real hard stuff is finding letter shapes that are difficult for OCR algorithms to handle, yet are "legible enough" for humans without disgusting them like some illegible CAPTCHAs out there.
One technique I like is to use a 3d extruded wireframe version of each letter, but projected isometrically. Then you take the endpoints of your lines and arcs and jitter them, allowing line edges to cross or to become disconnected.
The human eye is really good at picking out the letter outlines in 3d (especially since you have reinforcement of the front-face pattern with back faces) That extra information helps overcome the jitter.
But OCRs of this generation focus on line corners and points of interest (features that are mostly scale/rotate and font-invariant) so lines that cross or end prematurely are particularly problematic for these algorithms.
I'm saying that if the brain/ear interface actually had non-linear aspects that mattered, then it wouldn't be possible to resolve directionality without a head-transform for cues -- X o'clock relative to your ear centerline in an anechoic chamber if you will -- by just phase alone. And you can pick any combination of harmonics and it still sounds okay.
So for the interesting primary frequencies that the ear is designed to pick up, it seems the brain assumes linear properties for sound, even if physically that is an approximation of reality.
So an audiophile can believe what he wants about the non-linear properties of high-frequency sound.
But if it ain't in the range that my A/D filter is set at, you can't hear it anyway and what you can hear is linear enough to be captured appropriately by the system.
And you do realize I was being somewhat facetious in my previous post, right?
Also, I hate audiophiles. In case you couldn't guess.
That's why I emphasized "relative to cost". You can mechanically afford a standard-sized cabin with effective torque and range provided you use the right amount of batteries. But the cost of these batteries is high relative to a mass-produced drivetrain.
.5) * (.8 / .2) = 8
By making the vehicle lighter you can get away with less required stored energy and the batteries don't push the price too far above a luxury compact.
I mean --- I'm not saying we'll never get there. But right now hybrids are cost-effective because you don't need nearly as many batteries, and you can throw in a cheap, light engine that is not intended to direct drive, but is geared only for electricity production.
Also: it's not like you don't pay for the KWh to juice your car. It's about 8 times cheaper* than gas but at the same time, if your vehicle has the same range and power of the car you're trying to replace, then you're paying that upfront cost that you have to wait 5 years or more before it breaks even.
*8 times cheaper than gas: ICE hybrid drivetrains are about 20% efficiency, while full electric cars have about 80% efficiency. Cost per kWh is 5 cents for residential wall power. Gasoline has 33 kWh/gal, and at $3.20/gal that's 10 cents a kWh. (.10 /
It's just pure data mining.
But if you're google, you are going to turn everything into an attribute, and you have the luxury of running your classifiers over gigantico training sets to pick out minute details and correlations. And you can settle for low support values; all that matters is that some profitable subset of people targeted by a campaign respond to it. So if that target is to "reach" 1% of the market, and 10% of the people in the training set have a correlated action and responded to a survey a certain way; and if of those 10% you have 10% support of a correlation --- well that's good enough for google-scale ads to be considered potentially successful!
but there's no reason to distribute it that way... that just wastes bandwidth.
You should really be using a modern perceptual codec. I hear AAC and Vorbis are nice. And they support 48Khz recordings with arbitrary bit depths / dynamic ranges.
But if you compress at 6:1 - 8:1 using modern codecs, you WILL NOT notice in an A/B test. What you're 'hearing' is the knowledge that you used a lossy codec in the first place -- like people seeing Jesus in pieces of toast and tree bark.
Of course, there are some really shitty (read: old) codecs out there. Don't use them. But an ogg -q6 is quite literally indistinguishable from FLAC (again, only when barring the apriori knowledge of the format... otherwise most audiophiles can suddenly 'hear' the difference again)
I think it's disingenious to talk about air as a non-linear system. It doesn't start acting non-linear until you're talking about distances (and/or/which imply) amplitudes that would shatter your eardrums or kill you.
I mean, let's talk about the non-linearity of speakers! They're damped oscillators!
And you can prove to an audiophile (hearing is believing) that sound is sufficiently linear to make such arguments irrelevant.
Take two frequencies (say... 14000 and 14300). If you play them, you get a 300Hz beat. Put that on one channel. Now take a 300Hz sine on the other channel, and then adjust the phase slowly. You should "hear" the 300Hz tone moving around the sound stage.
This experiment only works because sound reproduction (and your ears/brain) are a sufficiently linear system that trying to call it anything else when making qualitative arguments is just silly.
Batteries are expensive, heavy, and (potentially) environmentally damaging to produce/destroy.
HP is low (although torque is constant across RPMS -- a different kind of advantage which doesn't drive sales).
You need to reduce weight to account for batteries so cabin sizes suffer and become more bubble-like.
Batteries don't yet have the energy density (relative to costs) to make full-electrics feasible unless they did things like electrolyze water on charging and use said hydrogen in fuel-cells during driving (hydrogen has a high energy density by weight).
the stock stereos have bigger amplifiers, drivers and heatsinks that's accounting for the drop in milage.
Airbags are LIGHT. Traction control is a COMPUTER that by-wires the BRAKES. These kind of changes are minute compared to the ones that actually matter:
* CAD vs. human designed complex structures -- body panels, door hinge designs, dash/firewalls
* Unibody construction vs. body on frame
* Polycarbonate windshields
* Alloy wheels and vented 4-wheel disk brakes
* Crumple zones
etc... these are things that affect the composition, size and shape of the heavy/large components of the vehicle. And how they were designed and the material usage has changed a lot.
I mean, there were performance cars in the 80s that used a lot of the higher-tech techniques to reduce weight that are common in all cars now by the changing industry.
I don't see how you could mistake "all intents and purposes" for "all intensive purposes"
They mean TWO DIFFERENT FUCKING THINGS
The first means: "all -- including the things you haven't considered yet"
The second means: "all the intensive things"
I MEAN WHAT THE FUCK. ARE YOU PEOPLE FUCKING DEAF AND DUMB?
I am quite familiar with the NISPOM... but everyone hates COEs (which is what you really need if you're going to try to set up any moderately complicated system)
IMHO, DISA doesn't really seem to care if you are that anal about configuration management (I've never seen an inspector look at a mouse or monitor with any seriousness). They are more concerned with functional safeguards (does the system actually behave correctly and log appropriately) and appropriate reactions to questions from key personnel (i.e. "Show me your backup password list". Correct response: "No.")
You apparently don't remember when we used to get ASCII-art trolls constantly; pictures of goatse made up of pictograms (thanks 2ch for the inspiration...)
They started stripping everything non-USASCII and looking for things that look like blocks of text and filtering them out.
I mean, it's nice to do it all in one command, but all it's doing is:
gunzip -9 infile | tar xf -
When you add that z flag to "tar xzf infile"
Syntactic sugar. I don't know, tar and cpio are really shitty archive formats anyway unless you need to do stuff in a stream. We need an archive format with per-file (or per-directory) compression and an index so you can actually use the goddamn SEEK system call to speed up access... (and infozip, while it has some nice Unix features, is limited by compatibility with other implementations).
A build system would not be ideal.
I should be able to point my boxes at a mirror (or enterprise-central) server, search or ask it to install a package by name, it download only what I need, install it and the prerequisites (updating anything that would need to be updated in the process), put example config files in the right place, all without using Make or CC.
nt
Only the LSASS can grant authorization tokens to processes. Things like Winlogon (what you see when you login and also lock the screen) and the Run As... service run as Local System at startup. Only Local System stuff has the privledge to ask LSASS to create tokens that allow sub-processes to run with other identities; i.e. "Administrator" or whatever user you use when you login. It is also needed to do things like verify passwords. Normal programs can't actually ask takeyour Windows password, hash it, and verify it themselves... only LSASS can actually do that.
So you have LSASS which is started by the kernel at boot time, and it handles all of that stuff. In addition, any process which parents processes which run at a low authority also gets started by the kernel with Local System permissions as well (i.e. csrss, winlogon, the service host)
No suexec or anything like that is available... NT doesn't use "execute through" methods for assigning security tokens to processes.
This is in contrast to Unix; while processes can certainly drop down in privledge as in NT, and many services are modeled that way, it is also essential in Unix to "privledge up". That is, to be able to start processes running as an unprivledged user and call into a executable image running as a different user (presumably with internally coded policy that enforces security from the respect of the original running user, take the "passwd" command for example). But this leaves room for a lot of security issues, and so the push now is to severly restrict what files are chmodded "+s" and to audit them closely.
A number of software packages have changed how they operate (especially those that interact with hardware). Many of them at some point were suexec-root based, to talk to audio, video, or serial devices and such. Now such software is usually broken into parts, one half runs at boot time in a privledged mode as a service- providng the other half (UI) an API which can run as an unprivledged user.
Other software packages changed their installation instructions, informing the installer that they would need to change permissions on certain devices to let end users manipulate them with software running in an unprivledged mode.
Still others don't check at all, but assume the login scripts for the system change the permissions on commonly used devices to the current logged-in user (through the use of facilities such as PAM). This only works for the user sitting at the device, but it's a good assumption, since it's the usage scenario that most end-users care about when using software that interfaces with local hardware.
Wow... I really went on a tear there.
If you read the comments posted in response to both articles, interested readers who have opinions on the issue do not, in general, actually believe that we should abolish copyright and leave a vacuum. Because we all know (with the exception of a few utopia-ists) that many businesses would fall apart and in general it wouldn't be very good, especially for anyone in IT.
And would such a poorly thought-out change in law even come about short of armed uprising?
In any case, I think the point is that the original article's author was addressing a viewpoint that few actually have, save the most vocal mouthbreathers and me-tooers on various forums and blogs. When I read it when it first came up, I skipped the slashdot discussion because I thought it was "obvious" flamebaiting since it assumes that no one has considered the duality before (current ironic situation vs. where you ACTUALLY want to be with respect to IP law)
I don't know, I've seen that discussion done to death on Slashdot a million times before, so apparently we've thought about it a little.
And this guy just wanted to poke a beehive to get the Google AdSense traffic... and this other guy is calling him out on his arguments (they're not incorrect, they just miss the point... it's like, why are we even talking about this?)
Blargh. I hate the blogosphere, for just this reason.
You really didn't read the article, did you. You read it up until the point where you confirmed the position you thought it was taking, and then assumed the rest to be bollocks or whatever.
THE POINT was that the GPL would need to be changed if copyright laws were changed. The spirit of the GPL (Cohesion and Continuity, per the article) would be enforced by other clauses that would be created in light of whatever law takes the place of copyright, again per the article, "... be enforced using laws so drastically different from our laws today as to be unrecognizeable".
His position is that we can't just get rid of copyright, but we would have to replace it with something more modern. Something 21st century. Something that can be used to prove right of authorship and prevent plagaristic forms of derivative works, without limiting scope of distribution by the public, by default.
And the GPL would have to evolve to fit in that environment.
nt