FTA: "if you write your data _first_, you're never going to see corruption at all"
Agreed, but I think this still misses the point - Computers go down unexpectedly. Period.
Once upon a time, we all seemed to understand that, and considered writeback behavior (when rarely available)
always a dangerous option only for use in non-production systems and with a good UPS connected.
And now? We have writeback FS caching enabled by silent default, sometimes without even a way to disable it!
Yes, it gives a huge performance boost... But performance without reliability means absolutely nothing. Eventually
every computer will go down without enough warning to flush the write buffers.
REGARDLESS of the fact that they may lose. Voting for either Republican or Democrat
because "no one else will win" is not only morally bankrupt it is foolish.
I would consider throwing away your vote foolish as well, and voting for who you want
rather than who can potentially win, naive at best.
We don't need people to throw away their votes on Nader or Paul, we need our entire election
system overhauled to allow at least something like more fair like IRV (yes, I realize
that has its flaws, but it works a hell of a lot better than winner-take-all when it
comes to exactly my disagreement with your quoted text).
Of course, we also need a drastically weaker federal government - Or as another poster pointed out, a more
"distributed" government to make it resilient to DoS attacks by any particular interest group.
"We pledge allegiance to the flag of these United States".
A machine's firewall configuration doesn't have anything to do with how it hangs off of the network.
Technically true, but then, neither does IPv6 vs IPv4. You can stick a naked machine on the internet with a real live IPv4 address; and at least historically, NAT didn't address a shortage of addresses but rather the fact that ISPs have always charged extra for them.
Anyway, the reason I mentioned firewalls - Yes, you allow or disallow whatever you want, and each machine can appear
on both sides of the wall however you like. In practice, however, no one uses them like that... Typically you would have a
DMZ containing the handful of servers you want publicly visible, and everything else totally unreachable from the outside
world. Further, you'd almost never give your DMZ machines "real" external addresses, you just redirect ports on the firewall
to the appropriate DMZ machine. And unless you need to have a dozen externally visible web servers or the like, none of that
requires more than one externally visible IPv4 address.
So to reiterate - You can say what you want about address scarcity and "end-to-end" reachability, but it all amounts to trying to
sell shiny glass beads once you consider actual real-world LAN configurations.
It's that end-to-end is getting less and less available as the internet grows
I don't think that has so much to do with NAT, as with the simple fact that firewalling your
home PC (on a LAN or not) no longer counts as "optional". Whether or not my firewall happens to
use fictional (from the perspective of the "real" internet) IP addresses for my LAN-side machines
really makes no difference to most people.
Why does someone always have to point that out in every single thread about DIY projects?
Yes, we all know that "DIY" means spending time on the project. And yes, we all know that our time
has value (I would even argue we each have a far more limited supply of time than (potentially)
of money).
But in the real world, with a realistic exchange of time for money (I don't work for AIG,
dontchaknow), I can afford to spend 30 hours turning $2,000 worth of supplies into a
$20k finished product. I can't, however, afford the $20k directly to buy the
pre-finished project.
So yes, time has value, but until the day the worms have my eyes for lunch, I have little doubt
I'll have far more of the former than the latter.
All you have to do to get a copy of the blacklist is check every URL on the entire internet twice.
Given the choice between dealing with government bureaucracy or using a technical end-run around the same, I'll
take the technical approach every time. At least it will deterministically give the desired results.
And as I mentioned, you don't need to get the whole page, just check the headers. This task would also parallelize
perfectly... A few dozen people splitting the task between them could probably do it in under an hour. You could further
optimize it by only checking the list of possible positives in the noncensoring-country phase.
But by all means, feel free to complain to the politicians, and see which of us gets an answer first... And which of us
trusts the answer we get (if any).
Personally, I think this would make an interesting exercise for a potential link aggregation site... Run the same experiment
daily from various known-censoring countries, and post them to the FP so everyone can instantly see the day's new "Big Brother
disapproves of this" content. Sort of an automated Streisand effect.
Step 1) Run a simple web spider that checks availability but never actually pulls content, from within Australia.
Step 2) Run the same spider in any non-censoring country.
Step 3) Compare the two lists.
Simple as that. Nothing more than a few hundred megs of shotgun-requests, and you can map the portions of the
web that look dark but shouldn't.
Besides, to put it bluntly, I sincerely doubt you are more than 160 times more productive than an average developer.
For the most part, we agree. But there, you missed the point.
You can't measure the true genius coder (which I don't claim myself as, but I've known one) in terms of "x times more
productive". They don't (just) churn out code faster, they solve problems in ways no one else would ever even
consider.
Einstein didn't do math "faster" than Maxwell, he made a massive jump in reasoning that made the idea of the "aether"
or even a rest frame completely irrelevant.
Team skills are empirically known to be the most important predictor
of developer productivity, not technical skills.
"Predictor" != "Descriptive". You don't use a predictor when you have a known quantity, you use the known quantity itself.
The number of people who can do what no one else does is extremely small.
Taking that as hyperbole, lets call him "merely" one in a million... So the planet has a mere 6000+ people as good as him at
his niche. And you want to hire an entire team to replace him? Talk about taking the importance of "teamwork" way
too far! I agree that we shouldn't always favor gurus over reproducibility, but gurus do have their place - just not
on a team, and if you try to squeeze them into one, don't blame the tools when the nail bends under repeated blows from the
only monkeywrench you have handy.
a better team player with somewhat weaker technical skills is generally a better hire than a
guru who can't play nicely with others
That depends greatly on what your company needs. If you need long-term solutions to a relatively stable
problem set, I would agree. If you need to beat the competition to the punch or you'll find yourself on the dole
next month, you want a guru.
creating far more value downstream
Put bluntly, that requires a "downstream" to exist.
Overall, I have to agree with the GP. If you told me "fire the PITA on my 'team' who saved us millions",
I'd fire you instead.
I'm not convinced that there's a higher penetration of this in IT than any other profession.
CEOs, for example.
I can't help but notice that most of the qualities that various highly-modded posters have called "intolerable" in
programmers, count as goddamned prerequisites for upper management.
The "Josh" in question could probably pass, in attitude if nothing else, for a Richard Branson.
If we could have gotten him to work with others, maybe he could have cured aging.
A great line of PC BS, but in practice, rarely true.
History contains almost nothing but one-man miracles. The "team" sweeps the floor and packages the
the semiconductor laser as a cool new type of record player, but without the genius, they'd just
sweep the floor.
You may have missed the point where it was believed that it was possible that
the millions of dollars saved was due to the millions of dollars worth of screw-up
in his code, or even actual sabotage
Why yes, the author of TFA does come across as extremely paranoid.
He has no evidence of that accusation, nor even and reason to believe it, other than his
inability to accept Josh as "just that good".
If you can't be replaced, you can't be promoted. Hope you like your current job.
This topic deals with "really good" coders. Who, for the most part, hold management in
utter disdain and don't want to climb the corporate ladder.
The mediocre programmers, who struggle through getting the job done and want nothing more than
to climb above the pit, can have their sad middle-management positions. They just need to
know their place, and stay out of the way of the actual talent.
I don't say that to defend the prima-donnas, BTW... We all need to understand our limits, and
even superstar coders have them (just not when it comes to coding, for the most part). Me, I consider
myself among the ranks of "really good" coders, though certainly not a superstar, and I have one
really big humbling weakness - I suck at the business world and at marketing myself. If not for that,
I'd have no use for "the company", but accepting reality, I do my part to get along with everybody that
needs to work with me.
So perhaps anyone dealing with a "Josh" needs to figure out what Josh needs from the company;
if "nothing", he wouldn't waste his time there.
Sometimes you need a solution NOW, and you will have time to clean it up (or re-implement it more carefully) later.
At most companies, you always need a solution "NOW", and time to do anything but deal with the next
now" never comes. Thus, "Josh" will benefit most companies more than he harms them.
In part, though, that forms a self-perpetuating cycle - You'll never escape damage-control mode as long as you
work in damage-control mode. On the flip side of that, however, I would encourage most people to ask themselves,
honestly, what tediously documenting every step really buys you.
First of all, most "solutions" become irrelevant long before they break. We've all heard about the woes of 40-year old payroll
systems that no one can upgrade, or even the Y2K fears dealing with legacy code... But those situations fall into an extreme
minority. We work in a world where most software counts as "venerably ancient" if it sees five years.
Second, "cleaning up later" only matters if Josh leaves... Which he eventually will, but good luck selling that
as a problem to Josh. I don't mean that as necessarily a lack of care on his part, BTW, so much as a simple
statement of the fact that true superstars honestly don't think in terms of "the team" - Except as baggage they have
to drag along for the ride.
Finally, even with good documentation, even on a codebase still retaining some relevance, would a semi-clean
reimplementation better suit present needs (and possibly take less time thanks to newer dev tools) than trying to
keep patching holes in a well-known but crumbling dike?
In particular, on that last point, I certainly don't count as a superstar, but I've made that exact argument myself.
I can personally reimplement quite a lot from scratch faster than I can understand even a well-documented
preexisting project. That might not always exist as an option, but more often than not, your "2000 human-years
invested" legacy project only really contains perhaps six months worth of chewy goodness for a single decent
programmer, with countless years worth of "Patching holes in a wall-known but crumbling dike".
Re:But without copyright protections...
on
So Amazing, So Illegal
·
· Score: 5, Interesting
Future generations will look back on this time in history and wonder
why the recording industry was so hot to protect top 40 crap-pop.
Probably not. I suspect future generations will look back and ask, wide-eyed, "Wow,
they could just steal arbitrary two-note sequences from other artists dead
less than the full millennium required by Disney? Didn't they worry about getting
the death penalty?"
long term, Sun will locate SSDs closer to the server CPUs to cut the bottleneck that occurs
when powerful, multicore CPUs have to wait for data to be delivered from hard drives
So close, and yet...
SSDs allow us to stop thinking about attached "storage" devices, and instead think
of them as their originally-intended purpose - Slow memory. For decades, they've run
so much slower than the CPU that we can't treat them as a form of memory without
paying a huge performance hit (try running XP with 64MB of RAM and a 2GB pagefile on the
fastest HDD out there, and experience the suck); but finally, with SSDs, we may
soon have the ability to treat them as a system's primary memory, with what we
currently consider RAM acting as an L3/L4 cache. Not to say SSDs have come anywhere
*near* DRAM for speed, but the no-seek-time-penalty starts putting them in the right
ballpark.
I also don't know that I'd consider building them right on the motherboard a good idea...
Much like the same path DRAM took, in the end the limitations (no easy upgradeability)
far outweighed the convenience ("just there" as a given).
But one small step at a time, I guess, so kudos to Sun for taking even a baby-step in
the right direction.
Whether the audio was originally analog or not is
unrelated to hard it will be to compress.
Yes and no...
if the "original" used the same type of compression (or at least a form of compression
that throws away nearly identical information) to your final format, then
reencoding(1) it will lose less information than compression of (for example) a high
quality analog recording of the same piece done live and on actual instruments.
If the original used purely synthetic sounds without closely-spaced frequencies and
little to no noise, it will compress (via a time-to-frequency domain transformation
such as the DCT used in MP3s) better than even the simplest of "real" sounds.
If, however, we compare compressing a 96KHz@48bit digital source with
a similar quality analog source, then no, the results will not differ enough
to call them meaningfully distinct.
1) Note that transcoding in general gives drastically worse quality
results compared to the original than either alone; but in the case under
consideration, the original will more closely (and cleanly) resemble those
features of the sound favored by the encoder.
the cost of shipping is not worth it for whoever does it.
The Africans making a living taking care of our electronics "waste" would probably
disagree with you.
Just because we don't consider it worth our health to use nasty chemicals to reclaim
metals from scrap boards, doesn't mean no one should want to do it.
Maybe if they return to making real software, instead of spending all this
time creating just another update cycle for a revenue stream, they will not change.
What do you mean, "return"?
Everything decent they ever produced came from Peter Norton. Once he left the scene to
do the Playboy Philanthropist thing, Symantec may as well have closed up shop.
Thousands or tens of thousands is more typical for MLC flash parts.
Tens of thousands - Per cell.
Wear leveling means that unless you have a filesystem 99% statically full with a small number of blocks
constantly changing, those 10,000 writes will take tens to hundreds of trillions of actual writes
to use up.
For some hard numbers, at 120GB, with 8GB of reserved cells, 4k cells, a cell lifetime of a mere 10k writes, and
50% static usage, you have 83 billion writes before you damage even a single cell. As the spec'd write lifetime
represents a few SD south in a normal distribution, you can expect literally hundreds of trillions of writes before
the wear levelling will realistically fail to keep the drive functional.
For comparison to the original question, I currently do most of my development on a rather inefficient.NET project with roughly 25MB spread over a few thousand small files (not my choice, beyond the fact that
I like my job in general), almost a worst-case scenario for impacting write lifetimes. Getting the full
source from our repository and compiling (which effectively makes two temp files and one output file per
source file) uses roughly 25k cell-writes.
If I did a full get-and-compile once per minute (ignoring the fact that a full get takes around 5 minutes
and a compile takes almost 15 minutes), it would take me 19 years just to reach the above-mentioned 83 billion
cell-writes. To actually "wear out the device" in terms of writes, I could not possibly live long enough.
It just depends on how easy the publisher wants to make it to resell.
Bingo - You've just described pretty much the entire problem.
Piracy? No, publishers all understand (even if they can never admit it) that some people
pay, some people pirate, and increased distribution from either means results in
more people in the first category overall. But resale? That eats into
the "paying" category, and publishers have a strong motivation to erect as many barriers
to that as possible.
Slashdot Mirror
FTA: "if you write your data _first_, you're never going to see corruption at all"
Agreed, but I think this still misses the point - Computers go down unexpectedly. Period.
Once upon a time, we all seemed to understand that, and considered writeback behavior (when rarely available) always a dangerous option only for use in non-production systems and with a good UPS connected. And now? We have writeback FS caching enabled by silent default, sometimes without even a way to disable it!
Yes, it gives a huge performance boost... But performance without reliability means absolutely nothing. Eventually every computer will go down without enough warning to flush the write buffers.
REGARDLESS of the fact that they may lose. Voting for either Republican or Democrat because "no one else will win" is not only morally bankrupt it is foolish.
I would consider throwing away your vote foolish as well, and voting for who you want rather than who can potentially win, naive at best.
We don't need people to throw away their votes on Nader or Paul, we need our entire election system overhauled to allow at least something like more fair like IRV (yes, I realize that has its flaws, but it works a hell of a lot better than winner-take-all when it comes to exactly my disagreement with your quoted text).
Of course, we also need a drastically weaker federal government - Or as another poster pointed out, a more "distributed" government to make it resilient to DoS attacks by any particular interest group. "We pledge allegiance to the flag of these United States".
A machine's firewall configuration doesn't have anything to do with how it hangs off of the network.
Technically true, but then, neither does IPv6 vs IPv4. You can stick a naked machine on the internet with a real live IPv4 address; and at least historically, NAT didn't address a shortage of addresses but rather the fact that ISPs have always charged extra for them.
Anyway, the reason I mentioned firewalls - Yes, you allow or disallow whatever you want, and each machine can appear on both sides of the wall however you like. In practice, however, no one uses them like that... Typically you would have a DMZ containing the handful of servers you want publicly visible, and everything else totally unreachable from the outside world. Further, you'd almost never give your DMZ machines "real" external addresses, you just redirect ports on the firewall to the appropriate DMZ machine. And unless you need to have a dozen externally visible web servers or the like, none of that requires more than one externally visible IPv4 address.
So to reiterate - You can say what you want about address scarcity and "end-to-end" reachability, but it all amounts to trying to sell shiny glass beads once you consider actual real-world LAN configurations.
It's that end-to-end is getting less and less available as the internet grows
I don't think that has so much to do with NAT, as with the simple fact that firewalling your home PC (on a LAN or not) no longer counts as "optional". Whether or not my firewall happens to use fictional (from the perspective of the "real" internet) IP addresses for my LAN-side machines really makes no difference to most people.
To mean, this seems to imply one of two possibilities.
Either Bucky Fuller had it right in his use of "Universe" as an article-less proper noun...
Or it means basically nothing more than that God does play dice with the universe.
Hmm... Bucky right, or Einstein wrong. Tough call...
Only cheaper if your time is worth nothing.
Why does someone always have to point that out in every single thread about DIY projects?
Yes, we all know that "DIY" means spending time on the project. And yes, we all know that our time has value (I would even argue we each have a far more limited supply of time than (potentially) of money).
But in the real world, with a realistic exchange of time for money (I don't work for AIG, dontchaknow), I can afford to spend 30 hours turning $2,000 worth of supplies into a $20k finished product. I can't, however, afford the $20k directly to buy the pre-finished project.
So yes, time has value, but until the day the worms have my eyes for lunch, I have little doubt I'll have far more of the former than the latter.
All you have to do to get a copy of the blacklist is check every URL on the entire internet twice.
Given the choice between dealing with government bureaucracy or using a technical end-run around the same, I'll take the technical approach every time. At least it will deterministically give the desired results.
And as I mentioned, you don't need to get the whole page, just check the headers. This task would also parallelize perfectly... A few dozen people splitting the task between them could probably do it in under an hour. You could further optimize it by only checking the list of possible positives in the noncensoring-country phase.
But by all means, feel free to complain to the politicians, and see which of us gets an answer first... And which of us trusts the answer we get (if any).
Personally, I think this would make an interesting exercise for a potential link aggregation site... Run the same experiment daily from various known-censoring countries, and post them to the FP so everyone can instantly see the day's new "Big Brother disapproves of this" content. Sort of an automated Streisand effect.
The blacklist is secret
These guys just don't "get" it still, do they?
Step 1) Run a simple web spider that checks availability but never actually pulls content, from within Australia.
Step 2) Run the same spider in any non-censoring country.
Step 3) Compare the two lists.
Simple as that. Nothing more than a few hundred megs of shotgun-requests, and you can map the portions of the web that look dark but shouldn't.
Besides, to put it bluntly, I sincerely doubt you are more than 160 times more productive than an average developer.
For the most part, we agree. But there, you missed the point.
You can't measure the true genius coder (which I don't claim myself as, but I've known one) in terms of "x times more productive". They don't (just) churn out code faster, they solve problems in ways no one else would ever even consider.
Einstein didn't do math "faster" than Maxwell, he made a massive jump in reasoning that made the idea of the "aether" or even a rest frame completely irrelevant.
Team skills are empirically known to be the most important predictor of developer productivity, not technical skills.
"Predictor" != "Descriptive". You don't use a predictor when you have a known quantity, you use the known quantity itself.
The number of people who can do what no one else does is extremely small.
Taking that as hyperbole, lets call him "merely" one in a million... So the planet has a mere 6000+ people as good as him at his niche. And you want to hire an entire team to replace him? Talk about taking the importance of "teamwork" way too far! I agree that we shouldn't always favor gurus over reproducibility, but gurus do have their place - just not on a team, and if you try to squeeze them into one, don't blame the tools when the nail bends under repeated blows from the only monkeywrench you have handy.
a better team player with somewhat weaker technical skills is generally a better hire than a guru who can't play nicely with others
That depends greatly on what your company needs. If you need long-term solutions to a relatively stable problem set, I would agree. If you need to beat the competition to the punch or you'll find yourself on the dole next month, you want a guru.
creating far more value downstream
Put bluntly, that requires a "downstream" to exist.
Overall, I have to agree with the GP. If you told me "fire the PITA on my 'team' who saved us millions", I'd fire you instead.
I'm not convinced that there's a higher penetration of this in IT than any other profession.
CEOs, for example.
I can't help but notice that most of the qualities that various highly-modded posters have called "intolerable" in programmers, count as goddamned prerequisites for upper management.
The "Josh" in question could probably pass, in attitude if nothing else, for a Richard Branson.
If we could have gotten him to work with others, maybe he could have cured aging.
A great line of PC BS, but in practice, rarely true.
History contains almost nothing but one-man miracles. The "team" sweeps the floor and packages the the semiconductor laser as a cool new type of record player, but without the genius, they'd just sweep the floor.
You may have missed the point where it was believed that it was possible that the millions of dollars saved was due to the millions of dollars worth of screw-up in his code, or even actual sabotage
Why yes, the author of TFA does come across as extremely paranoid.
He has no evidence of that accusation, nor even and reason to believe it, other than his inability to accept Josh as "just that good".
If you can't be replaced, you can't be promoted. Hope you like your current job.
This topic deals with "really good" coders. Who, for the most part, hold management in utter disdain and don't want to climb the corporate ladder.
The mediocre programmers, who struggle through getting the job done and want nothing more than to climb above the pit, can have their sad middle-management positions. They just need to know their place, and stay out of the way of the actual talent.
I don't say that to defend the prima-donnas, BTW... We all need to understand our limits, and even superstar coders have them (just not when it comes to coding, for the most part). Me, I consider myself among the ranks of "really good" coders, though certainly not a superstar, and I have one really big humbling weakness - I suck at the business world and at marketing myself. If not for that, I'd have no use for "the company", but accepting reality, I do my part to get along with everybody that needs to work with me.
So perhaps anyone dealing with a "Josh" needs to figure out what Josh needs from the company; if "nothing", he wouldn't waste his time there.
Sometimes you need a solution NOW, and you will have time to clean it up (or re-implement it more carefully) later.
At most companies, you always need a solution "NOW", and time to do anything but deal with the next now" never comes. Thus, "Josh" will benefit most companies more than he harms them.
In part, though, that forms a self-perpetuating cycle - You'll never escape damage-control mode as long as you work in damage-control mode. On the flip side of that, however, I would encourage most people to ask themselves, honestly, what tediously documenting every step really buys you.
First of all, most "solutions" become irrelevant long before they break. We've all heard about the woes of 40-year old payroll systems that no one can upgrade, or even the Y2K fears dealing with legacy code... But those situations fall into an extreme minority. We work in a world where most software counts as "venerably ancient" if it sees five years.
Second, "cleaning up later" only matters if Josh leaves... Which he eventually will, but good luck selling that as a problem to Josh. I don't mean that as necessarily a lack of care on his part, BTW, so much as a simple statement of the fact that true superstars honestly don't think in terms of "the team" - Except as baggage they have to drag along for the ride.
Finally, even with good documentation, even on a codebase still retaining some relevance, would a semi-clean reimplementation better suit present needs (and possibly take less time thanks to newer dev tools) than trying to keep patching holes in a well-known but crumbling dike?
In particular, on that last point, I certainly don't count as a superstar, but I've made that exact argument myself. I can personally reimplement quite a lot from scratch faster than I can understand even a well-documented preexisting project. That might not always exist as an option, but more often than not, your "2000 human-years invested" legacy project only really contains perhaps six months worth of chewy goodness for a single decent programmer, with countless years worth of "Patching holes in a wall-known but crumbling dike".
Future generations will look back on this time in history and wonder why the recording industry was so hot to protect top 40 crap-pop.
Probably not. I suspect future generations will look back and ask, wide-eyed, "Wow, they could just steal arbitrary two-note sequences from other artists dead less than the full millennium required by Disney? Didn't they worry about getting the death penalty?"
long term, Sun will locate SSDs closer to the server CPUs to cut the bottleneck that occurs when powerful, multicore CPUs have to wait for data to be delivered from hard drives
So close, and yet...
SSDs allow us to stop thinking about attached "storage" devices, and instead think of them as their originally-intended purpose - Slow memory. For decades, they've run so much slower than the CPU that we can't treat them as a form of memory without paying a huge performance hit (try running XP with 64MB of RAM and a 2GB pagefile on the fastest HDD out there, and experience the suck); but finally, with SSDs, we may soon have the ability to treat them as a system's primary memory, with what we currently consider RAM acting as an L3/L4 cache. Not to say SSDs have come anywhere *near* DRAM for speed, but the no-seek-time-penalty starts putting them in the right ballpark.
I also don't know that I'd consider building them right on the motherboard a good idea... Much like the same path DRAM took, in the end the limitations (no easy upgradeability) far outweighed the convenience ("just there" as a given).
But one small step at a time, I guess, so kudos to Sun for taking even a baby-step in the right direction.
Whether the audio was originally analog or not is unrelated to hard it will be to compress.
Yes and no...
if the "original" used the same type of compression (or at least a form of compression that throws away nearly identical information) to your final format, then reencoding(1) it will lose less information than compression of (for example) a high quality analog recording of the same piece done live and on actual instruments.
If the original used purely synthetic sounds without closely-spaced frequencies and little to no noise, it will compress (via a time-to-frequency domain transformation such as the DCT used in MP3s) better than even the simplest of "real" sounds.
If, however, we compare compressing a 96KHz@48bit digital source with a similar quality analog source, then no, the results will not differ enough to call them meaningfully distinct.
1) Note that transcoding in general gives drastically worse quality results compared to the original than either alone; but in the case under consideration, the original will more closely (and cleanly) resemble those features of the sound favored by the encoder.
the cost of shipping is not worth it for whoever does it.
The Africans making a living taking care of our electronics "waste" would probably disagree with you.
Just because we don't consider it worth our health to use nasty chemicals to reclaim metals from scrap boards, doesn't mean no one should want to do it.
Maybe if they return to making real software, instead of spending all this time creating just another update cycle for a revenue stream, they will not change.
What do you mean, "return"?
Everything decent they ever produced came from Peter Norton. Once he left the scene to do the Playboy Philanthropist thing, Symantec may as well have closed up shop.
What the gov't is pissed off about is that you can see 2 nuclear subs docked ... scroll
up to the top of the bay, zoom in.
Or just click here. You can zoom in more, but that gives a nice background to go with the subs in the center.
Thousands or tens of thousands is more typical for MLC flash parts.
.NET project with roughly 25MB spread over a few thousand small files (not my choice, beyond the fact that
I like my job in general), almost a worst-case scenario for impacting write lifetimes. Getting the full
source from our repository and compiling (which effectively makes two temp files and one output file per
source file) uses roughly 25k cell-writes.
Tens of thousands - Per cell.
Wear leveling means that unless you have a filesystem 99% statically full with a small number of blocks constantly changing, those 10,000 writes will take tens to hundreds of trillions of actual writes to use up.
For some hard numbers, at 120GB, with 8GB of reserved cells, 4k cells, a cell lifetime of a mere 10k writes, and 50% static usage, you have 83 billion writes before you damage even a single cell. As the spec'd write lifetime represents a few SD south in a normal distribution, you can expect literally hundreds of trillions of writes before the wear levelling will realistically fail to keep the drive functional.
For comparison to the original question, I currently do most of my development on a rather inefficient
If I did a full get-and-compile once per minute (ignoring the fact that a full get takes around 5 minutes and a compile takes almost 15 minutes), it would take me 19 years just to reach the above-mentioned 83 billion cell-writes. To actually "wear out the device" in terms of writes, I could not possibly live long enough.
they prefer a quiet well lit office that doesn't stink of BO and stale junk food.
Some of us, regardless of age, prefer to always have music on.
For light... Well, the screen(s) make their own light.
As for BO and stale junkfood... Eeew. I don't think anyone prefers that over cleanliness and hygiene.
It just depends on how easy the publisher wants to make it to resell.
Bingo - You've just described pretty much the entire problem.
Piracy? No, publishers all understand (even if they can never admit it) that some people pay, some people pirate, and increased distribution from either means results in more people in the first category overall. But resale? That eats into the "paying" category, and publishers have a strong motivation to erect as many barriers to that as possible.
At what point will the ease of immediate downloads outweigh a manual and a box to stick on your shelf (if it doesn't already)?
At the point where I can download a DRM-less installer or ISO and do whatever the hell I want with it.
Anything short of that, and I'll keep buying physical media.