on my work network, we've got an integrated PKI that makes it easy for people to exchange their public keys. If I'm sending someone a password or other sensitive information, I'll encrypt it against their keys there. If I'm just talking to someone (ie: not doing anything sensitive), encryption is off, signing is on. If I'm sending from my personal email, the only person I encrypt to is my work email.
I think the big reason that email encryption in general hasn't taken off is that it's a huge pain to exchange keys. Some keyserver attempts have been made, but frankly there's not been enough adoption in any circle I've seen to really call it a success. The only time this stuff seems to really work well is when there's a corporate directory and a mandate from management that says "you will get a pki certificate, and you will publish it on the global address list".
So the paper talks about SBPR (sorting by prefix reversals) and MIN-SBPR. The question is not "here, sort this stack of pancakes", it's "determine what the minimal number of flips is to sort an arbitrary stack of pancakes of size n".
If I'm following this, then sorting the stack itself is relatively easy (as you said, n^2). Figuring out the optimal sorting is apparently what's hard.
"size of the problem to some power" is the definition of polynomial time. Polynomial time problems are generally considered "easy" -- for example, your typical sorting algorithm is between n*log(n) and n^2. These grow slowly enough that general polynomial algorithms, even with relatively high exponents (like n^3 and n^4) are doable for reasonably large input sets.
The time it takes to solve an NP-hard problem is more in line with "a constant raised to the power the size of the problem". So doubling the size of the input squares the computation involved. So like... no known general solution to SAT is better than 2^n.
So what that means is going from input size = 10 to input size = 20 would require a million times more power, and input size = 20 to input size = 21 would require twice the power that it would take to do input size = 20. This is WAY worse than n^x (where x is a constant).
The answer to the tinfoil-hat question: ssh protocol 2 uses diffie-hellman key exchange to establish a session key before anything sensitive starts flowing. It's pretty resistant to eavesdropping, being that the actual key is never transmitted. You shouldn't be shy about starting up new ssh connections over untrusted links, as long as the destination's server key signature is already in your known_hosts.
First: changes in traffic pattern are also information leakage. It's all a balancing act. If you're worried about your enemy discovering your location, you stay off the radio. If your location is known (eg: you're at a base), and you want to cover any activity changes, you might stay on all the time and lay down a noise floor to mask those changes. If there's scarce spectrum for you to communicate in, that's another consideration. But none of that really applies to non-military use of ssh.
Second: ssh2 handshakes use diffie-helman key exchange to establish a session key. The eavesdropper waiting for the next handshake gets nothing useful -- they're going to have to do an offline brute force of the stream they got, and that'll only reveal the session key to that user. Further, ssh re-keys every hour or every 1gb by default (configurable: RekeyLimit), so an offline brute-force of a collected data stream will be of relatively limited exposure for an attacker. And offline brute force of even a 128 bit aes-ctr stream is still somewhere deep in the realm of impractical.
Probably the only real difference between reconnecting and keeping it alive is that depending on how many times you connect, you may deplete your entropy pools faster doing one versus the other.
It's still dumb. I don't want to belabor the point here, but just from a financial perspective, accounting only for power and cooling, if you look at the 2 year mark, it's better to buy a $7000 "new hottie" that draws 300 watts at the wall than to spend $1000 on ten "old crappies" that draw 200W/ea at the wall*. And that's not even beginning to look at things like labor hours, ownership costs in years 3-5, space, storage, downtime due to a lack of in-system redundancy, software licensing costs. This "total cost of ownership", which is potentially much larger than the sticker price of the system. Especially when the counter-case is based on assumptions that a certain brand of hardware and all components therein are made out of unobtainium.
*: when you do this calculation, I recommend $0.10/Kwh, 1:1 power to cooling cost ratio, assumption that you actually need the systems you're acquiring, and acceptance of the idea that a pair of 2.53ghz quad-core nehalems with 24 gigs of ram is more than a match for 40 early-netburst 2.4ghz xeons with 20 gigs of total ram.
Redhat just released a real full-on production competitor to vmware, called RHEV (redhat enterprise virtualization). Like... last month. It's built on KVM, and designed to do a multi-host setup, with a management console and the more must-have multi-host virtualization features (incl. live migration).
Not saying it's without problems, but my office was in the beta and we're pretty much sold on it.
Basic rhel 5.4 kvm virtualization, yeah... I'd lean away from that for at least as long as it took to absorb the contents of the virtualization guide...
I'm not sure I'm convinced that it's really a good idea replacing 7 year old hardware with 5-6 year old hardware. Especially given that a single slightly-inexperienced sysadmin doing the system installs and upgrades in question is probably going to have their hands full for a year or so just on the software side. By the time the first wave of upgrades is done with, you're looking at hardware that's older than the stuff you're trying to get rid of was when you started the process.
Further, old cpus have comically bad performance compared to the latest and greatest, with performance literally an order of magnitude worse than current tech. Moreover, they don't support a lot of things that new systems do. That 10-pack you list isn't going to support virtualization extensions that make virt compelling on modern hardware. They're not going to support enough ram to let you do useful virtualization, and they don't ship with enough headroom for any modern os running a decently well-utilized application stack to be very happy. They probably don't even support 64-bit.
If you want cheap throwaway hardware to make a test lab out of, off-lease/lifecycled hardware's great. If you're doing things that live in production space, you might as well just bite the bullet, lay out a bit of capex and do it right the first time.
There was a time when we didn't have the internet and software shipped on floppies or CDs, so programmers were expected to get the software working 100% out the door. No second chances. i.e. The same constraints we hardware engineers have to deal with - get it right out the door.
Broken releases that need to be updated in the first couple days out are definitely problematic, as are regressive patches, but the "good old days" when people weren't expected to have internet connections to update stuff still had their (numerous) vulnerabilities.
Writing secure code is hard. In particular, writing code that protects against whole classes of attacks that weren't even around when you wrote your code is... challenging, to say the least.
While it'd be nice if some of the worst offenders spent a little more time on QA before they start pushing "gold" releases, expecting perfection in nontrivial software at release time, or any other time, is a joke.
And hardware manufacturers aren't immune to that either. Why do you think BIOS and firmware updates and microcode patch mechanisms exist for most nontrivial hardware devices?
Rats will chew through urethane foam like it's made out of... err... urethane foam. It's a good step, but it's insufficient against any chewing rodent who thinks there's supposed to be a path there.
As the AC nearby says, steel wool shoved into the gap that you're foaming shut will solve that problem though.
There's a lot of reasons to avoid poison that have nothing to do with arguments about humane treatment of animals.
Consider: secondary killing. Lots of things will opportunistically feed on dead or dying rats, and get poisoned and get sick or die as a result. If you succeed in killing half your rat population in a 500 yard radius, at the cost of killing 90% of the predators that eat them in a half a mile radius, the rat population will rebound faster and stronger than the predator count will, and you'll end up fighting bigger waves of insurgent rats. Of course, that only applies to areas where there's both rats and rat predators, so if you're in a massively built-up urban area with little or no green space, you can dismiss that one.
Then there's the whole carcass disposal thing to deal with. Most dying rats aren't going to crawl to a convenient place to die, they'll die in the same places they live, which means wall voids, pipes, brush piles, under raised floors, above suspended ceilings... basically everyplace that's hard to look and inconvenient to clean out. And if you don't find and remove the dead rats, the place is going to REEK for a long time. Of course, that's only really a valid argument in structures in which people spend time... so if you wanted to poison the rats in your barn, that'd be a little less relevant.
If the rats are indoors, you're better off killing them where you live (out in the open) than where they live (in the walls). Snap traps are the way to go for that.
Jobs count, but they're not the _only_ thing that counts. A tiny number of jobs doesn't make a big difference to anything, no matter how good they are... that 75 jobs number is reminiscent of a larger grocery store or a Walmart's staffing levels... albeit with maybe three times the average salary of such places.
On the other hand, giving a corporation millions in tax breaks in order for them to build a half a billion dollars worth of assessable commercial facility on what was maybe a hundred thousand dollars worth of property tax exempt agricultural land makes a pretty big difference on your local (as in municipal or county) property tax assessments when the breaks expire. A Google or Microsoft isn't going to invest that much in a facility and then relocate it and bulldoze when they start paying property tax on it... they're going to stay there and keep doing business.
If your choice, as a local or regional politician, is to give a big company or group of companies an incentive for a couple years in exchange for a quarter million or half a million a year in property tax intake starting when those breaks expire, or to have them build a city, county or state over and never give you those revenues, it makes a damned lot of sense to give them a tax break and pretty much guarantee that you're going to see that uptick in revenues in a couple years.
These tax incentives are, in general, waivers which say the state/county/local taxing authority won't assess property tax on the company for some number of years. It's not like they're writing google and microsoft a check. The state just sort of... forgets to tax the property for a couple years in exchange for the massive increase in property value of that individual parcel of land.
I wholeheartedly agree. Stovepiping a couple systems here or there is a necessary evil. Stovepiping enough resources to power a midsized research department is just plain evil.
Even with one node on all the time... you could pretty reasonably pull that off with the rest of the nodes. You could even have it dynamically scale the "awake" part of the cluster to match the number of jobs in the queue or the utilization of the awake parts. Just imagining going from 200W to 30-40kW and back automatically, on demand... yeah, that'd be handy.
You could also tie into environmental factors... scaling back the cluster if the HVAC is underperforming and the room's getting warm. Or tying in power and cooling load balancing, powering up appropriate systems to keep the room from getting hot and cold spots.
In my experience as a sysadmin, when you have a resource, your users want it to be "up" all the time, no matter what. If it's interactive, they'll leave VNC sessions or xterms or screen sessions running on it and want them to be there when they come back. If it's noninteractive (ie: a queue/batch system), your users want to be able to submit jobs now, without waiting for the sysadmin to come in and fire it all up and make it run.
Without some serious organizational political capital, it's pretty hard to pull off powering down the compute resources. It can be done, but it's going to leave a lot of people unhappy.
Seriously, after you've been in the workforce for 3 years or so, your degree just becomes a near-irrelevant checkbox on your resume unless you're going back into academia.
The details of leaked choicepoint data, for example, should indicate that that surveillance and those records aren't nearly accurate enough to be predictive.
Even if they've (in the conspiratorial sense) got enough data, filtering the noise out of the signal is not a solved problem by a longshot.
Of course, you could also point to things like the no-fly lists as examples how how such information could utterly fail in every conceivable way but still be used...
There are, in fact, statistically interesting economic models that predict the behaviors of people based on their mood, and the moods of people based on events and media influence.
You'd be surprised what economists, statisticians, and sociologists are doing with computational modeling these days.
The big problem is, indeed, that you can't give any such system real data to the degree of detail necessary to actually achieve a 1:1 mapping, without subjecting everyone to the sort of insane surveillance that nobody would submit to and nobody would subject anyone else to.
But, if the model is demonstrably predictive of trends at large, it can be useful. Nobody's saying it'll predict individual movements, or the outcome of the next election or fluctuations of a given commodity on wall street. But knowing approximately to what extent and for how long people in aggregate will react to a given stimulus is still interesting.
GCC is a particularly poor example of that sort of network effect, because most distros tend to be reticent to upgrade their "stable" gcc. Glibc would be another such poor example. Better examples might be Apache, Samba, MySQL, and any of a very large number of gnome and kde applications.
I've reported enough bugs that have been upstream problems, and seen the propagation of those fixes. Most distro maintainers don't, in fact, build their own patches to software. Instead, they turn around and file an upstream bug. If the package maintainer also happens to be an upstream dev, then maybe he'll patch it upstream himself. But either way, I've never seen the gentoo or debian teams patch samba without that patch going upstream and coming back down.
Redhat is a different story, since they've got a different set of concerns. They're willing to maintain their own patchsets because they frequently have to backport patches to keep things up to date without breaking their customers' enterprisey setups.
Wasn't it Clinton who signed the DMCA into law? And remember those awful things he tried to do to crypto? Key escrow and whatnot?
The democrats are just as much panderers to corporate interests and net stupidity as the republicans are. No more, no less. Both parties are drifting, and it's not right or left, it's just downhill.
Free speech is neither a right-wing nor a left-wing value. It's simply a value.
I probably shouldn't respond to this sort of thing at all, but... you've totally missed the point.
By "forward mail" nobody but you means "click the forward button and send the message on to someone else".
They mean "when a message arrives at blah@domain.com, have it automatically end up at whatever@somewhereelse.com. As in forwarding the entire account transparently to another location.
This is an invaluable feature for people with multiple accounts, allowing them to consolidate their mail in a single location, thus making it easier to stay on top of (and to spam-filter).
"rolling back the install" is a low-grade disaster recovery scenario. Testing the install on a non-production machine, working out the install/upgrade kinks and maybe even having a team of testers or some scripted testcases to throw at it before you start doing anything on the production systems is disaster prevention.
And any doctor, sysadmin, or person with a modicum of common sense (or at least familiarity with some common-sense aphorisms) will tell you something about the relationship between prevention and cure...
depends on the video. I've met limited success with that... some youtube videos are flash-7 compatible, some are flash-8. I don't know if there are any that are only 9-compatible yet (but I'm pretty sure flexbuilder apps and such fall in that category, and flex is neat).
Anyway, your mileage in flash player 7 depends a lot on running into compatible videos.
The kids aren't going to have any say in what distro gets chosen (which is fine, in my opinion). But each district's IT department will certainly have that degree of autonomy.
Incidentally, that's also the response to the fears of too many distros. It's not going to be the department of education (as in statewide) micromanaging things, doing OS installs and maintenance, etc. It's going to be the IT people in every individual district... the people who've been trying to get by on freeware and the cheapest possible systems management solutions for ages.
Districts need to train, hire/fire people for the required skillsets, and will probably also have time to work out a way to come into line with the state's policy. That'd be my expectation anyway.
I guess the biggest reason for rolling version control into the IDE is convenience.
I gave my developers a pretty easy-to-use setup for creating and using svn repositories, and taught them how to use tortoisesvn (this was... probably svn 1.1 times). They never bothered, because they're IDE people (java devs, working mainly in eclipse), and the IDE sticks their projects and workspaces in inconvenient places.
Then I taught them how to use subclipse about a month later, and now they generally find the repository to be indispensable.
If you give them convenience, it won't be annoying to use, and they'll be more prone to using it. That's really the whole reason for that whole approach.
Slashdot Mirror
on my work network, we've got an integrated PKI that makes it easy for people to exchange their public keys. If I'm sending someone a password or other sensitive information, I'll encrypt it against their keys there. If I'm just talking to someone (ie: not doing anything sensitive), encryption is off, signing is on. If I'm sending from my personal email, the only person I encrypt to is my work email.
I think the big reason that email encryption in general hasn't taken off is that it's a huge pain to exchange keys. Some keyserver attempts have been made, but frankly there's not been enough adoption in any circle I've seen to really call it a success. The only time this stuff seems to really work well is when there's a corporate directory and a mandate from management that says "you will get a pki certificate, and you will publish it on the global address list".
So the paper talks about SBPR (sorting by prefix reversals) and MIN-SBPR. The question is not "here, sort this stack of pancakes", it's "determine what the minimal number of flips is to sort an arbitrary stack of pancakes of size n".
If I'm following this, then sorting the stack itself is relatively easy (as you said, n^2). Figuring out the optimal sorting is apparently what's hard.
"size of the problem to some power" is the definition of polynomial time. Polynomial time problems are generally considered "easy" -- for example, your typical sorting algorithm is between n*log(n) and n^2. These grow slowly enough that general polynomial algorithms, even with relatively high exponents (like n^3 and n^4) are doable for reasonably large input sets.
The time it takes to solve an NP-hard problem is more in line with "a constant raised to the power the size of the problem". So doubling the size of the input squares the computation involved. So like ... no known general solution to SAT is better than 2^n.
So what that means is going from input size = 10 to input size = 20 would require a million times more power, and input size = 20 to input size = 21 would require twice the power that it would take to do input size = 20. This is WAY worse than n^x (where x is a constant).
The answer to the tinfoil-hat question: ssh protocol 2 uses diffie-hellman key exchange to establish a session key before anything sensitive starts flowing. It's pretty resistant to eavesdropping, being that the actual key is never transmitted. You shouldn't be shy about starting up new ssh connections over untrusted links, as long as the destination's server key signature is already in your known_hosts.
Two points of note:
First: changes in traffic pattern are also information leakage. It's all a balancing act. If you're worried about your enemy discovering your location, you stay off the radio. If your location is known (eg: you're at a base), and you want to cover any activity changes, you might stay on all the time and lay down a noise floor to mask those changes. If there's scarce spectrum for you to communicate in, that's another consideration. But none of that really applies to non-military use of ssh.
Second: ssh2 handshakes use diffie-helman key exchange to establish a session key. The eavesdropper waiting for the next handshake gets nothing useful -- they're going to have to do an offline brute force of the stream they got, and that'll only reveal the session key to that user. Further, ssh re-keys every hour or every 1gb by default (configurable: RekeyLimit), so an offline brute-force of a collected data stream will be of relatively limited exposure for an attacker. And offline brute force of even a 128 bit aes-ctr stream is still somewhere deep in the realm of impractical.
Probably the only real difference between reconnecting and keeping it alive is that depending on how many times you connect, you may deplete your entropy pools faster doing one versus the other.
It's still dumb. I don't want to belabor the point here, but just from a financial perspective, accounting only for power and cooling, if you look at the 2 year mark, it's better to buy a $7000 "new hottie" that draws 300 watts at the wall than to spend $1000 on ten "old crappies" that draw 200W/ea at the wall*. And that's not even beginning to look at things like labor hours, ownership costs in years 3-5, space, storage, downtime due to a lack of in-system redundancy, software licensing costs. This "total cost of ownership", which is potentially much larger than the sticker price of the system. Especially when the counter-case is based on assumptions that a certain brand of hardware and all components therein are made out of unobtainium.
*: when you do this calculation, I recommend $0.10/Kwh, 1:1 power to cooling cost ratio, assumption that you actually need the systems you're acquiring, and acceptance of the idea that a pair of 2.53ghz quad-core nehalems with 24 gigs of ram is more than a match for 40 early-netburst 2.4ghz xeons with 20 gigs of total ram.
Redhat just released a real full-on production competitor to vmware, called RHEV (redhat enterprise virtualization). Like ... last month. It's built on KVM, and designed to do a multi-host setup, with a management console and the more must-have multi-host virtualization features (incl. live migration).
Not saying it's without problems, but my office was in the beta and we're pretty much sold on it.
Basic rhel 5.4 kvm virtualization, yeah ... I'd lean away from that for at least as long as it took to absorb the contents of the virtualization guide...
I'm not sure I'm convinced that it's really a good idea replacing 7 year old hardware with 5-6 year old hardware. Especially given that a single slightly-inexperienced sysadmin doing the system installs and upgrades in question is probably going to have their hands full for a year or so just on the software side. By the time the first wave of upgrades is done with, you're looking at hardware that's older than the stuff you're trying to get rid of was when you started the process.
Further, old cpus have comically bad performance compared to the latest and greatest, with performance literally an order of magnitude worse than current tech. Moreover, they don't support a lot of things that new systems do. That 10-pack you list isn't going to support virtualization extensions that make virt compelling on modern hardware. They're not going to support enough ram to let you do useful virtualization, and they don't ship with enough headroom for any modern os running a decently well-utilized application stack to be very happy. They probably don't even support 64-bit.
If you want cheap throwaway hardware to make a test lab out of, off-lease/lifecycled hardware's great. If you're doing things that live in production space, you might as well just bite the bullet, lay out a bit of capex and do it right the first time.
Broken releases that need to be updated in the first couple days out are definitely problematic, as are regressive patches, but the "good old days" when people weren't expected to have internet connections to update stuff still had their (numerous) vulnerabilities.
Writing secure code is hard. In particular, writing code that protects against whole classes of attacks that weren't even around when you wrote your code is ... challenging, to say the least.
While it'd be nice if some of the worst offenders spent a little more time on QA before they start pushing "gold" releases, expecting perfection in nontrivial software at release time, or any other time, is a joke.
And hardware manufacturers aren't immune to that either. Why do you think BIOS and firmware updates and microcode patch mechanisms exist for most nontrivial hardware devices?
Rats will chew through urethane foam like it's made out of ... err ... urethane foam. It's a good step, but it's insufficient against any chewing rodent who thinks there's supposed to be a path there.
As the AC nearby says, steel wool shoved into the gap that you're foaming shut will solve that problem though.
There's a lot of reasons to avoid poison that have nothing to do with arguments about humane treatment of animals.
Consider: secondary killing. Lots of things will opportunistically feed on dead or dying rats, and get poisoned and get sick or die as a result. If you succeed in killing half your rat population in a 500 yard radius, at the cost of killing 90% of the predators that eat them in a half a mile radius, the rat population will rebound faster and stronger than the predator count will, and you'll end up fighting bigger waves of insurgent rats. Of course, that only applies to areas where there's both rats and rat predators, so if you're in a massively built-up urban area with little or no green space, you can dismiss that one.
Then there's the whole carcass disposal thing to deal with. Most dying rats aren't going to crawl to a convenient place to die, they'll die in the same places they live, which means wall voids, pipes, brush piles, under raised floors, above suspended ceilings... basically everyplace that's hard to look and inconvenient to clean out. And if you don't find and remove the dead rats, the place is going to REEK for a long time. Of course, that's only really a valid argument in structures in which people spend time... so if you wanted to poison the rats in your barn, that'd be a little less relevant.
If the rats are indoors, you're better off killing them where you live (out in the open) than where they live (in the walls). Snap traps are the way to go for that.
Jobs count, but they're not the _only_ thing that counts. A tiny number of jobs doesn't make a big difference to anything, no matter how good they are... that 75 jobs number is reminiscent of a larger grocery store or a Walmart's staffing levels... albeit with maybe three times the average salary of such places.
On the other hand, giving a corporation millions in tax breaks in order for them to build a half a billion dollars worth of assessable commercial facility on what was maybe a hundred thousand dollars worth of property tax exempt agricultural land makes a pretty big difference on your local (as in municipal or county) property tax assessments when the breaks expire. A Google or Microsoft isn't going to invest that much in a facility and then relocate it and bulldoze when they start paying property tax on it... they're going to stay there and keep doing business.
If your choice, as a local or regional politician, is to give a big company or group of companies an incentive for a couple years in exchange for a quarter million or half a million a year in property tax intake starting when those breaks expire, or to have them build a city, county or state over and never give you those revenues, it makes a damned lot of sense to give them a tax break and pretty much guarantee that you're going to see that uptick in revenues in a couple years.
These tax incentives are, in general, waivers which say the state/county/local taxing authority won't assess property tax on the company for some number of years. It's not like they're writing google and microsoft a check. The state just sort of ... forgets to tax the property for a couple years in exchange for the massive increase in property value of that individual parcel of land.
I wholeheartedly agree. Stovepiping a couple systems here or there is a necessary evil. Stovepiping enough resources to power a midsized research department is just plain evil.
That actually does sound interesting!
Even with one node on all the time... you could pretty reasonably pull that off with the rest of the nodes. You could even have it dynamically scale the "awake" part of the cluster to match the number of jobs in the queue or the utilization of the awake parts. Just imagining going from 200W to 30-40kW and back automatically, on demand... yeah, that'd be handy.
You could also tie into environmental factors ... scaling back the cluster if the HVAC is underperforming and the room's getting warm. Or tying in power and cooling load balancing, powering up appropriate systems to keep the room from getting hot and cold spots.
In my experience as a sysadmin, when you have a resource, your users want it to be "up" all the time, no matter what. If it's interactive, they'll leave VNC sessions or xterms or screen sessions running on it and want them to be there when they come back. If it's noninteractive (ie: a queue/batch system), your users want to be able to submit jobs now, without waiting for the sysadmin to come in and fire it all up and make it run.
Without some serious organizational political capital, it's pretty hard to pull off powering down the compute resources. It can be done, but it's going to leave a lot of people unhappy.
45?
More like 25.
Seriously, after you've been in the workforce for 3 years or so, your degree just becomes a near-irrelevant checkbox on your resume unless you're going back into academia.
slightly paranoid, but fair enough.
The details of leaked choicepoint data, for example, should indicate that that surveillance and those records aren't nearly accurate enough to be predictive.
Even if they've (in the conspiratorial sense) got enough data, filtering the noise out of the signal is not a solved problem by a longshot.
Of course, you could also point to things like the no-fly lists as examples how how such information could utterly fail in every conceivable way but still be used...
There are, in fact, statistically interesting economic models that predict the behaviors of people based on their mood, and the moods of people based on events and media influence.
You'd be surprised what economists, statisticians, and sociologists are doing with computational modeling these days.
The big problem is, indeed, that you can't give any such system real data to the degree of detail necessary to actually achieve a 1:1 mapping, without subjecting everyone to the sort of insane surveillance that nobody would submit to and nobody would subject anyone else to.
But, if the model is demonstrably predictive of trends at large, it can be useful. Nobody's saying it'll predict individual movements, or the outcome of the next election or fluctuations of a given commodity on wall street. But knowing approximately to what extent and for how long people in aggregate will react to a given stimulus is still interesting.
GCC is a particularly poor example of that sort of network effect, because most distros tend to be reticent to upgrade their "stable" gcc. Glibc would be another such poor example. Better examples might be Apache, Samba, MySQL, and any of a very large number of gnome and kde applications.
I've reported enough bugs that have been upstream problems, and seen the propagation of those fixes. Most distro maintainers don't, in fact, build their own patches to software. Instead, they turn around and file an upstream bug. If the package maintainer also happens to be an upstream dev, then maybe he'll patch it upstream himself. But either way, I've never seen the gentoo or debian teams patch samba without that patch going upstream and coming back down.
Redhat is a different story, since they've got a different set of concerns. They're willing to maintain their own patchsets because they frequently have to backport patches to keep things up to date without breaking their customers' enterprisey setups.
Wasn't it Clinton who signed the DMCA into law? And remember those awful things he tried to do to crypto? Key escrow and whatnot?
The democrats are just as much panderers to corporate interests and net stupidity as the republicans are. No more, no less. Both parties are drifting, and it's not right or left, it's just downhill.
Free speech is neither a right-wing nor a left-wing value. It's simply a value.
I probably shouldn't respond to this sort of thing at all, but ... you've totally missed the point.
By "forward mail" nobody but you means "click the forward button and send the message on to someone else".
They mean "when a message arrives at blah@domain.com, have it automatically end up at whatever@somewhereelse.com. As in forwarding the entire account transparently to another location.
This is an invaluable feature for people with multiple accounts, allowing them to consolidate their mail in a single location, thus making it easier to stay on top of (and to spam-filter).
err, then there's also testing.
"rolling back the install" is a low-grade disaster recovery scenario. Testing the install on a non-production machine, working out the install/upgrade kinks and maybe even having a team of testers or some scripted testcases to throw at it before you start doing anything on the production systems is disaster prevention.
And any doctor, sysadmin, or person with a modicum of common sense (or at least familiarity with some common-sense aphorisms) will tell you something about the relationship between prevention and cure...
depends on the video. I've met limited success with that ... some youtube videos are flash-7 compatible, some are flash-8. I don't know if there are any that are only 9-compatible yet (but I'm pretty sure flexbuilder apps and such fall in that category, and flex is neat).
Anyway, your mileage in flash player 7 depends a lot on running into compatible videos.
For me, this is very welcome news.
The kids aren't going to have any say in what distro gets chosen (which is fine, in my opinion). But each district's IT department will certainly have that degree of autonomy.
Incidentally, that's also the response to the fears of too many distros. It's not going to be the department of education (as in statewide) micromanaging things, doing OS installs and maintenance, etc. It's going to be the IT people in every individual district
Districts need to train, hire/fire people for the required skillsets, and will probably also have time to work out a way to come into line with the state's policy. That'd be my expectation anyway.
I guess the biggest reason for rolling version control into the IDE is convenience.
... probably svn 1.1 times). They never bothered, because they're IDE people (java devs, working mainly in eclipse), and the IDE sticks their projects and workspaces in inconvenient places.
I gave my developers a pretty easy-to-use setup for creating and using svn repositories, and taught them how to use tortoisesvn (this was
Then I taught them how to use subclipse about a month later, and now they generally find the repository to be indispensable.
If you give them convenience, it won't be annoying to use, and they'll be more prone to using it. That's really the whole reason for that whole approach.