Mostly, it's bugfixes and fallout from recent changes (for new requirements). This is a concious choice - changing something that's wrong is faster than testing thoroughly, although we are working to improve our QA process. It feels like we're a small company that got big.
Sure you can outsource adminning a cisco router. Would you outsource adminning a cisco router that manages vital infrastructure that could eat your company whole?
this is why I like xargs when I can get away with it - I get to batch things up, but xargs will limit the size of its commands to avoid this problem. Actually, when I have trouble getting away with it, wrapper scripts change it to something I can get away with.
We work in a different space. I can update code in about a day in production, less if it's mostly isolated or there's an overriding need. On the flip side, we are called on to do more and different things with the same code, so it's not like a heart monitor or anything like that.
This isn't anything to do with archive.org, though. This is a contract dispute with publishers. It's alos an opportunity for new publishers to eat the existing guys' lunch.
You don't need that - just let ops guys call developers when the procedures they wrote don't solve the problems. If bad code results in you getting woken up at 2am, then you'll change things so that doesn't happen. It also helps if the ops guys know the devs pretty well; they know who owns what and also tend to develop a collaborative relationship.
And when it doesn't happen, they are fired or required to work 24x7 to pull off a miracle. Any slight flaw is seen as a complete failure. Paradoxically, budgets have been cut so severely that there is no such thing as a "test environment" and IT is expected to have some sort of magic ball to predict exactly what is going to break when massive changes are rolled out.
So break things. Send notifications out widely predicting things like 'potentially breaking domains so nobody can log in' and, when some suit asks why, tell them about testing and change control. Basically, you care too much and you're being exploited.
When presented with the impossibility of these 2 people actually handling the workload managements response was "Sorry, if you don't like it, we already talked with xyz outsourcing corp, you're lucky to have this job"
The proper response is that they can't do it either. If you get pushback, management are idiots - go somewhere else.
It's already harder to get academic papers on-line than it used to be, because researchers are reluctant to post copies on their own sites before publication for fear of never being published, and afterwards they're tied down by other legal restrictions from the publishers.
That's likely due to exclusivity deals with the publishers (I don't know - you didn't say), which is irrelevant here.
Archive.org doesn't change the copyrighted stuff significantly - it's as close as we will likely get to a library for things like websites. As such, it's more a preservation of the things already distributed. Since it only collects things that are freely distributed anyway, it's not really a disincentive to anyone that's trying to make money off their stuff.
But all else being equal, the creative solution, by virtue of a change taking place, will be more risky.
Nope. The ceative solution is less risky if you have a good testing process and more risky if you don't. Creative stuff tends to work better and adapt to changes better; stodgy code is frequently brittle, and that's a huge risk.
Of course, if the "uncreative" 1000 line version is 7-times bigger for the right reason, it is avoiding clever-clever tricks so it is easy to determine that it does what it's supposed to and it's easy to maintain.
Yeah right. I'm in the process of replacing the uncreative version of some of our stuff with a creative version that will be smaller, easier to maintain, and less painful to run.
The most bloated, boring and uncreative code I have ever seen in my life was a safety critical system that had the potential to kill hundreds of people if it went wrong. It might have been bloated, boring and uncreative but it was also blindingly obvious what it did, how it did it and that it did it right.
The disk cache can be characterized as a part of the distribution chain, especially since the objects that come down declare how long they can be cached for.
"Shell urges her readers not to cooperate with the child-protection system at any level."
She's got this part right - CPS is generally the most incompetent useless bag of trash I've ever come in contact with.
"Tape everything. If it looks like the brutes might try to remove your precious dumplings from the home, hide them. If they snatch Junior anyway, plant a bug in his teddy bear so you can monitor what goes on in the foster home."
The first part is good advice. Never no when someone needs to be reminded what they said. The other stuff is just screwball.
Arguing the state of things, any of your examples are handled by archive.org's deletion policy. Don't like it, they'll delete it.
Arguing that you can prevent dissemination of info is ridiculous. With books, you've always got older versions, so you can see that Bill Gates originally dismissed the internet as a fad. With websites, you can edit things after the fact - this is far more dangerous to society as a whole than the fact that someone's freely published information may be reproduced. Websites that are unprotected and uncontrolled are a billboard for all to see. If someone wants to say that some politician says whatever he thinks will get him elected and back it up (with something verifiable like archive.org), then too bad for the politico. Careful what you say - it'll outlive you.
Where did you live? Around here, you get the EULA when you run the installer, and the store won't take the thing back anyway. Since they aren't offering anything anyway, I just ignore them.
Consider how dangerous it would be to set a legal precedent saying that permission could be implicitly granted in such a wide-ranging way, simply by failing to use a convention that the vast majority of Internet users have never heard of.
What's so dangerous? Running a website is an invitation to its use. Since the vast majority of people don't run websites, they don't count - if they want to go run their website, it's their job to educate themselves about how that works. Getting to your specific point, what would the precedent be, aside from allowing people to spider your site due to it being an accepted (and generally desired) practice? Are you going to claim specific damages? Spiders generally read stuff that's free, so good luck with that.
Wanna bet? Leave a stack of 20s in your front yard on a table and see what the cops say when someone walks off with them. Simply having a website is an invitation for people to use it. Don't like that? Use a password.
robots.txt is a way tofix things. There's also the option of denying known bad user-agents, but you can always change that. Really, robots.txt is about traffic levels - if you want to secure something, slap a password on it.
I have a website that is accessible on the net, but i haven't give you, or any service, company, non-profit, etc. the directions to, the content contained therein, etc. It is a private website solely for the purposes of showing content to the friends and family I explicitly direct to it.
It's still public, just obscure. This is the moral equivalent of leaving a photo album on a stand necxt to the sidewalk and complaining that strangers are looking at it. If you want to keep people out, you have to do something, like password protection.
Slashdot Mirror
Mostly, it's bugfixes and fallout from recent changes (for new requirements). This is a concious choice - changing something that's wrong is faster than testing thoroughly, although we are working to improve our QA process. It feels like we're a small company that got big.
Sure you can outsource adminning a cisco router. Would you outsource adminning a cisco router that manages vital infrastructure that could eat your company whole?
MS for helpdesk?! And they say there's a shortage...
this is why I like xargs when I can get away with it - I get to batch things up, but xargs will limit the size of its commands to avoid this problem. Actually, when I have trouble getting away with it, wrapper scripts change it to something I can get away with.
We work in a different space. I can update code in about a day in production, less if it's mostly isolated or there's an overriding need. On the flip side, we are called on to do more and different things with the same code, so it's not like a heart monitor or anything like that.
This isn't anything to do with archive.org, though. This is a contract dispute with publishers. It's alos an opportunity for new publishers to eat the existing guys' lunch.
You don't need that - just let ops guys call developers when the procedures they wrote don't solve the problems. If bad code results in you getting woken up at 2am, then you'll change things so that doesn't happen. It also helps if the ops guys know the devs pretty well; they know who owns what and also tend to develop a collaborative relationship.
all those upgrades, outages, and man hours don't generate revenue
Yes they do. Or have you never experienced the lack of IT?
And when it doesn't happen, they are fired or required to work 24x7 to pull off a miracle. Any slight flaw is seen as a complete failure. Paradoxically, budgets have been cut so severely that there is no such thing as a "test environment" and IT is expected to have some sort of magic ball to predict exactly what is going to break when massive changes are rolled out.
So break things. Send notifications out widely predicting things like 'potentially breaking domains so nobody can log in' and, when some suit asks why, tell them about testing and change control. Basically, you care too much and you're being exploited.
When presented with the impossibility of these 2 people actually handling the workload managements response was "Sorry, if you don't like it, we already talked with xyz outsourcing corp, you're lucky to have this job"
The proper response is that they can't do it either. If you get pushback, management are idiots - go somewhere else.
Heh. I'll jump across the lake for $159k :)
It's already harder to get academic papers on-line than it used to be, because researchers are reluctant to post copies on their own sites before publication for fear of never being published, and afterwards they're tied down by other legal restrictions from the publishers.
That's likely due to exclusivity deals with the publishers (I don't know - you didn't say), which is irrelevant here.
Archive.org doesn't change the copyrighted stuff significantly - it's as close as we will likely get to a library for things like websites. As such, it's more a preservation of the things already distributed. Since it only collects things that are freely distributed anyway, it's not really a disincentive to anyone that's trying to make money off their stuff.
But all else being equal, the creative solution, by virtue of a change taking place, will be more risky.
Nope. The ceative solution is less risky if you have a good testing process and more risky if you don't. Creative stuff tends to work better and adapt to changes better; stodgy code is frequently brittle, and that's a huge risk.
Of course, if the "uncreative" 1000 line version is 7-times bigger for the right reason, it is avoiding clever-clever tricks so it is easy to determine that it does what it's supposed to and it's easy to maintain.
Yeah right. I'm in the process of replacing the uncreative version of some of our stuff with a creative version that will be smaller, easier to maintain, and less painful to run.
The most bloated, boring and uncreative code I have ever seen in my life was a safety critical system that had the potential to kill hundreds of people if it went wrong. It might have been bloated, boring and uncreative but it was also blindingly obvious what it did, how it did it and that it did it right.
But is it fragile or hard to update?
The disk cache can be characterized as a part of the distribution chain, especially since the objects that come down declare how long they can be cached for.
Who says the EULA is ever in force? It doesn't give you anything in return for the restrictions, since I've already bought the software.
In civilized countries, spanking your child is fine. The problem is that some people can't tell spankings from beatings.
"Shell urges her readers not to cooperate with the child-protection system at any level."
She's got this part right - CPS is generally the most incompetent useless bag of trash I've ever come in contact with.
"Tape everything. If it looks like the brutes might try to remove your precious dumplings from the home, hide them. If they snatch Junior anyway, plant a bug in his teddy bear so you can monitor what goes on in the foster home."
The first part is good advice. Never no when someone needs to be reminded what they said. The other stuff is just screwball.
Arguing the state of things, any of your examples are handled by archive.org's deletion policy. Don't like it, they'll delete it.
Arguing that you can prevent dissemination of info is ridiculous. With books, you've always got older versions, so you can see that Bill Gates originally dismissed the internet as a fad. With websites, you can edit things after the fact - this is far more dangerous to society as a whole than the fact that someone's freely published information may be reproduced. Websites that are unprotected and uncontrolled are a billboard for all to see. If someone wants to say that some politician says whatever he thinks will get him elected and back it up (with something verifiable like archive.org), then too bad for the politico. Careful what you say - it'll outlive you.
Where did you live? Around here, you get the EULA when you run the installer, and the store won't take the thing back anyway. Since they aren't offering anything anyway, I just ignore them.
Consider how dangerous it would be to set a legal precedent saying that permission could be implicitly granted in such a wide-ranging way, simply by failing to use a convention that the vast majority of Internet users have never heard of.
What's so dangerous? Running a website is an invitation to its use. Since the vast majority of people don't run websites, they don't count - if they want to go run their website, it's their job to educate themselves about how that works. Getting to your specific point, what would the precedent be, aside from allowing people to spider your site due to it being an accepted (and generally desired) practice? Are you going to claim specific damages? Spiders generally read stuff that's free, so good luck with that.
What makes you think any of Http is regulated?
Wanna bet? Leave a stack of 20s in your front yard on a table and see what the cops say when someone walks off with them. Simply having a website is an invitation for people to use it. Don't like that? Use a password.
robots.txt is a way tofix things. There's also the option of denying known bad user-agents, but you can always change that. Really, robots.txt is about traffic levels - if you want to secure something, slap a password on it.
No, it's a convention, and it's fairly widely accepted. Why make a standard if everyone's already using it?
You have to intentionally seek out a website.
Websites are by default accessible to everyone.
I have a website that is accessible on the net, but i haven't give you, or any service, company, non-profit, etc. the directions to, the content contained therein, etc. It is a private website solely for the purposes of showing content to the friends and family I explicitly direct to it.
It's still public, just obscure. This is the moral equivalent of leaving a photo album on a stand necxt to the sidewalk and complaining that strangers are looking at it. If you want to keep people out, you have to do something, like password protection.