Something about more sessions to track uses more cpu and memory. I'd imagine it has to do with the tables required to track the sessions.
The same is true in your workstation. There are performance limits and real serious points of diminishing return as you increase the number of concurrent sessions. Some operating systems are better than others at dealing with this, but there are limits in all cases.
Its true for now that most links are sold purely by bandwidth, so your statement about getting what you've paid for is valid -- unless what you're paying for includes by contract a cap on total use or continuous use, or something else. Most home network access contracts contain those use case caps.
What really caught my attention as I read your note is that comment about the number of open tcp connections. As I read it, I'm surprised that hasn't been used as a valid limit on use by contract.
If you think of things that add cost and hurt performance from an ISP perspective, total number of sessions is one of them. It increases the load on routers and adds overhead and latency to network (or it can, unless more money is spent on bigger and faster routers).
Limiting concurrent sessions is probably just around the corner.
I currently pay for the highest bandwidth version of consumer net access offered in my area. Its more that sufficient for downloads, but because I work from home it is slower than I'd like for uploads. I use a hosted server at a co-lo site so that my business system isn't carried over a consumer line, but I still pull down a pretty huge amount of data sometimes.
I'm completely convinced that if my ISP wanted, they could slow my links by about the third week of most months. I believe they don't only because they don't offer a higher level of service than I'm paying for. At least for me, they've always been fair and responsive.
If anyone is limited by an ISP when they've got an agreement to pay for services that doesn't support those limits being applied, they should take legal action. If not, they should pay more attention to what they purchased and either refuse to buy what's offered or live inside it.
If you can't live with what's in the agreement, lease a line and pay for your own service to somewhere. What you'll find is that without the aggregation that's done by the big ISP's, you'll never be able to afford the on-demand use you want to buy.
I want massive bandwidth on demand too -- I want to download 4gb movies in under 30 minutes whenever I want. I do not, however, want to pay for a leased line capable of doing that. When I buy into a shared provisioning system (a consumer isp arrangement) I'm agreeing to live within that ecosystem and share the cost of that high bandwidth as well as sharing that bandwidth.
The contracts are obscure and don't come right out and say so. Maybe it would be better if they did.
I've seen at least three different shows on Discovery Channel about these squid that until a few years ago were considered by most biologists to be nothing by a myth.
One was about the first ever captured specimen of a Giant Squid -- it was almost microscopic and they couldn't keep any alive.
Later, one was about actually getting fleeting video of one in the wild.
Most recent was one about another kind of giant squid that's even bigger and was caught in a net accidentally. The fishing trawler was smart enough to quickly freeze it. In the show, they were able to thaw it carefully and do a dissection. Apparently one of the problems with scientists working with these is that thy decompose extremely rapidly.
Oil exploration is pushing serious camera time deeper than ever. At the same time, an awareness of the value to science of creatures that we don't know about is making inroads into fishing crews in even the most remote places where in the past such a find might simply have been discarded as waste.
There is a LOT of volume in the oceans, and we're far from understanding it in the kind of depth we one day will.
There's an inherent architectural difference between storing mail in a database built on Microsoft's JET technology, and one which stores its data in something that is (although distinctly odd) very much like an xml data store. The Domino architecture makes segmenting the archive into manageable parts by date, by person, or by any combination thereof much simpler.
Essentially, the Domino architecture results in exactly what you describe -- throw more storage space at it and you can keep storing more data. The Microsoft architecture does not.
The Bush administration moved the White House from a Notes/Domino based system to a Microsoft Exchange based system.
Before moving, they'd had no downtime -- even when congress was taken out for 2 days by the code red word (they were on Exchange).
In moving, they mysteriously 'lost' all their backups for a period of time that was suspicious as hell, and now they can't scale to handle the capacity issues they face.
In a Notes/Domino world, this kind of archiving problem wouldn't be all that hard to deal with. You'd just need enough storage for it, and create archives per week/month/year (or an archive per individual's mailbox, or whatever) to put on as much hardware as was required. I single checkbox would be all that was needed to have it encrypted as well.
Oh well. I guess if conveniently "loosing" mail when you don't want it found is one of your design goals, than you probably want to migrate to something less reliable.
The constant push of limits on the supposed speed of the craft, capabilities of the ships, and expanded population of the available area took away too many plot devices.
In the original series, they were kind of out there on their own without help available. By the time the big war with the Borg came around in TNG, they got to the point where anything that was a threat could wipe them out entirely, and anything else was easily dealt with.
Both DS9 and Voyager were attempts to revive the sense of frontier self reliance. DS9 was more of a city, and a sort of 'futuristic cop show' was the original goal. Voyager was to be an attempt to get back to the spirit of the original series.
Going forward you have a more urban setting with the known region pretty much all settled and all the borders drawn.
Going backward just gives you more room to work in.
Historically speaking, the process of trying out a new form of government -- be it based on intelligentsia, divine right, populist appeal, military might, or financial might -- is usually a pretty messy thing.
There's all that marching and yelling, sometimes blood and death too.
Things have to be pretty bad to make that worth it. I'm not sure things are bad enough right now for it to be worth it.
I mean, I'm all for a good thought experiment now and again, but tossing out a system of government that's been working reasonably well seems like a bad idea.
All of the private data on the drive will be encrypted. They can search if they like, but between encryption and ccleaner I think they'll find it quite boring.
They can get the password, surely. Either by holding me (as I have no real plan to spend time in a cell) or by sending in the boffins from the NSA. Either of those will take long enough to require a court be involved.
I suppose waterboarding is an option. I doubt I'd hold up much past the paper cup full offered while they explain what's to come next.
Once past the encryption, they'll find the data on the drive is still, however, quite boring.
Everyone knows you keep the real secret plans for world domination with your porn -- encrypted on hidden USB drives made to look like torn cables, or on a secure linux server housed in a data center that used to be an oil rig.
I recall a few years back when they were down for days back in the code-red worm days while the executive branch was not. The executive branch was using Lotus Domino. The Bush administration pulled Domino mail and went to Exchange. Since then, they "lost" a ton of incriminating evidence by failing to make proper backups.
In any case, any system could fail under the kind of load they're likely dealing with.
If you write an object, method, function, or subroutine that has a scope outside your own code -- it can be linked to or called from anywhere else -- you can't ever change its parameter requirements or return results in such a way that previous versions will fail.
You can get around this with overloading, you can get around it with version numbers on your newer declarations (yuck), or other such hacks.
Don't write your code such that people who depend on it can't upgrade to the newer libraries simply because you've changed all the calls they have to make.
F'ing Microsoft does this and it is painful as hell.
if your original method was:
int doSomething(int var1, int var2, int var3)
and you need a fourth variable in a newer version, keep the old version around and either overload it (just create the new method with teh same name and the other variable) or give your new method a new name. Where possible, move the code from the old method to the new one, and just call the new method as the only code in the old one -- supplying the missing data.
Yeah, I know it makes for a lot more code and more methods in your libraries -- but it makes version upgrades happen a million times more smoothly.
Taking the question seriously for a minute -- something unusual for this venue --
Whatever rules you use, make sure they are the same as everyone else on the project. That includes the rules around comments, indenting, and bracket locations. I've seen huge arguments over placement of an enclosing bracket on the same line as a declaration or a new line.
Once you have a little comfort in a language, get on an open source team. They have to be very good about practices because they have hundreds of people working in different locations at different time zones around the world. You'll start with no real authority, being allowed to submit small changes specific to small branches of code. The owner of that small branch will be responsible for accepting your changes if they're good enough. Over time, you'll move up the chain. READ THEIR GUIDELINES. OSS teams have, of necessity, very rigid guidelines on code practices that allow hundreds of people to work on code together. They've had huge battles over those guidelines, and very smart people have said very smart things (you can find them hidden in the morass of garbage if you look hard enough) that have gone into those guidelines.
More Specifically:
If you're repeating the same code, put it in a sub or function (a method if you're using an object oriented language)
A subroutine or function should be as fine grained and generalized as you can possibly make it. It should accept as few parameters as it needs, and should return a single value (or perform a single action). Note: Some languages, like C, use the convention of returning a success/failure boolean as the return value, and the result of the function in a buffer passed as a parameter -- that's also a good strategy.
If your routine is longer than a single screen to read, give real thought to how you might break it out into distinct subroutines (or methods or functions)
Avoid overly complex rules for variable naming. I've seen insanely complex variable name rules that are painful to work with and attempt to encapsulate the the data type, scope, and purpose of each variable in its name. That's not necessary or helpful in modern language programming. Most programming environments let you mouse click a variable and instantly view its declaration and often even comments written by that declaration for explanation. If your variable name includes the type and scope, you'll have to refactor it if you change the type or scope (like from integer to long integer, or boolean to enumeration as is quite frequent)
Use an object oriented language where possible
REALLY learn how to use Overloading, Polymorphism, and inheritance in your object oriented language
Avoid global declarations and functions wherever possible. The smaller the scope of any variable or object, the less likely someone or something will step on it later.
draw out -- on paper -- your object model before you build it. Learn to start with an ER (Entity Relationship) diagram so you can understand the relationships between real world objects. Think in terms of "A" is always the parent of one or more instances of "B", "C", or "D", but may be either a parent or a child of "E". Figure that out using real world objects that your code object represents first, on paper. I personally do this on a whiteboard with colored pens first then transfer to software for mapping.
Trust nothing. Your methods, functions, and subroutines should stand on their own regardless of what crap someone else passes to them. In every method, sub, or function, VALIDATE all variable data, always. Check for overflows. Check to see if an object is instantiated (not null or nothing). Check to make sure values are within the expected ranges. These checks are very small in terms of system resources and program run time. Take the time.
Do your declarations, validity checking, and decision making outside your loops. Any loop you make should do as little as possible inside it. Everything you do in a loop ge
They built a malicious face book application. Big deal. They're all malicious and annoying. The whole damn site is a marketing work to pull personal data about interconnected relationships together for marketing.
"Malicious Facebook App" is like "Table Mesa" (a place in Arizona). Its redundant Mesa means Table in Spanish.
Facebook is there to make money. End of story. Sites like this are not there as a public service. Start getting used to the idea that whatever you put up there is going to be used in any way they can get away with, TO MAKE MONEY.
They don't like bugmenot, then it will get banned. Don't like that they ban it, stop using facebook. IF enough people agree, it will be no longer cost effective for facebook to ban bugmenot.
Better idea: Stop providing companies out to make money using the internet with long lists of all your friends and family in a way they can easily correlate to create massively complex webs of contact information to market toward.
When I was preparing to market some software, my own lawyer and I talked about it. This was several years ago but oddly enough I don't think the situation has changed much since.
The subject was "Click Through Agreements" be they on the web or on software installation programs. According to her (and she's the lead partner for IP in a fairly prestigious firm) the funny thing about click-through agreements is that they're entirely untested.
While everyone in the IP industry sort of goes along assuming they'll hold up, there remains this possibility that if someone ever did go to court the entire practice could get thrown out as invalid. We all declare that these agreements have meaning, and as long as we all pretend to admire his outfit, the emperor is treated as if fully clothed.
Any misunderstanding of my interpretation of this is down to me, not the lawyer who is quite good at her job.
Possibly the only programming language book I've ever read almost page by page from start to finish -- half of it in one sitting on a flight to London from Boston. I'd meant to just look at it a bit then settle in and watch dvd's. The pace was just right and it had places you could gloss through if you already know how to code in other languages.
Best language book ever. Hands down.
Also, Kathy Sierra is great, and anything that supports her can't be a bad thing.
Any project I manage, and most I am influential all, I make it a point to constantly ask "Why are we collecting this? How long do we need to keep it? When can we delete this data?"
If you don't have it, you can't lose track of it and it can't be stolen from you.
If you have to store sensitive data -- and in some cases we all do -- you try to isolate the sensitive parts of it from the identifying parts of it. Use hashed values for keys instead of actual names or account numbers, that kind of thing.
There's the obvious of course -- data on laptops should be encrypted, and the key for that encryption shouldn't be taped to the inside of the battery door.
That is like saying a nut and bolt is physics. You can't patent physics. A refrigerater using a compressor, a gas, an expansion valve, and a condenser is just physics. You can't patent physics.
You CAN patent what you've done with physics. You can patent what you've done with math.
...I would say it is much more akin to authoring music or text. You have a limited (though sometimes wide) vocabulary and syntax. Many authors will put the same vocabulary and syntax together in a strive for similar goals, yet the combination used is generally unique. The differentiation between them come out in skill and subtlety as well as application.
Copyright, IOW, is very appropriate. Patent is entirely not.
Business process falls into the same category IMO. If the drive-through window were invited in the 90's and not the 40's, only the first bank or fast food restaurant to come up with the concept could use it and all others would have to pay royalties. Then the owners of toll roads would sue for prior art, etc. etc.
....at what point as you were growing a tennis ball sized object on your ass, did you decide it may bear looking into from a medical perspective?
Not to poke fun as I'm sure it was very painful and unpleasant -- something I wouldn't wish on my worst enema (er. enemy -- sorry for the typo) -- but for the love of FSM, what where you telling yourself when this thing was say, golf ball sized?
I'm going to leave the questions about just what kind of plastic underwear you had picked as the most comfortable of programming gear aside for the time being.
This thing had to have somehow entered your mind as potentially problematic somewhere before it reached the size of say...a cherry tomato, yes?
I mean, at what point while showering or wiping your ass or getting dressed or whatever did you fail to say "Hey, that's not another ass cheek growing there is it?"
I showed this to a friend of mine (the story, thankfully without pictures) who's reaction was to suggest that if you were really smart you'd now find a way to sue the chair manufacturer.
I wish you better health and less pain - seriously, I hope this never every happens to you or anyone else again.
Now excuse me while I go watch a pig get slaughtered or click on a rickroll link just to get that image out of my head.
Slashdot Mirror
Something about more sessions to track uses more cpu and memory. I'd imagine it has to do with the tables required to track the sessions.
The same is true in your workstation. There are performance limits and real serious points of diminishing return as you increase the number of concurrent sessions. Some operating systems are better than others at dealing with this, but there are limits in all cases.
Its true for now that most links are sold purely by bandwidth, so your statement about getting what you've paid for is valid -- unless what you're paying for includes by contract a cap on total use or continuous use, or something else. Most home network access contracts contain those use case caps.
What really caught my attention as I read your note is that comment about the number of open tcp connections. As I read it, I'm surprised that hasn't been used as a valid limit on use by contract.
If you think of things that add cost and hurt performance from an ISP perspective, total number of sessions is one of them. It increases the load on routers and adds overhead and latency to network (or it can, unless more money is spent on bigger and faster routers).
Limiting concurrent sessions is probably just around the corner.
I currently pay for the highest bandwidth version of consumer net access offered in my area. Its more that sufficient for downloads, but because I work from home it is slower than I'd like for uploads. I use a hosted server at a co-lo site so that my business system isn't carried over a consumer line, but I still pull down a pretty huge amount of data sometimes.
I'm completely convinced that if my ISP wanted, they could slow my links by about the third week of most months. I believe they don't only because they don't offer a higher level of service than I'm paying for. At least for me, they've always been fair and responsive.
If anyone is limited by an ISP when they've got an agreement to pay for services that doesn't support those limits being applied, they should take legal action. If not, they should pay more attention to what they purchased and either refuse to buy what's offered or live inside it.
If you can't live with what's in the agreement, lease a line and pay for your own service to somewhere. What you'll find is that without the aggregation that's done by the big ISP's, you'll never be able to afford the on-demand use you want to buy.
I want massive bandwidth on demand too -- I want to download 4gb movies in under 30 minutes whenever I want. I do not, however, want to pay for a leased line capable of doing that. When I buy into a shared provisioning system (a consumer isp arrangement) I'm agreeing to live within that ecosystem and share the cost of that high bandwidth as well as sharing that bandwidth.
The contracts are obscure and don't come right out and say so. Maybe it would be better if they did.
I've seen at least three different shows on Discovery Channel about these squid that until a few years ago were considered by most biologists to be nothing by a myth.
One was about the first ever captured specimen of a Giant Squid -- it was almost microscopic and they couldn't keep any alive.
Later, one was about actually getting fleeting video of one in the wild.
Most recent was one about another kind of giant squid that's even bigger and was caught in a net accidentally. The fishing trawler was smart enough to quickly freeze it. In the show, they were able to thaw it carefully and do a dissection. Apparently one of the problems with scientists working with these is that thy decompose extremely rapidly.
Oil exploration is pushing serious camera time deeper than ever. At the same time, an awareness of the value to science of creatures that we don't know about is making inroads into fishing crews in even the most remote places where in the past such a find might simply have been discarded as waste.
There is a LOT of volume in the oceans, and we're far from understanding it in the kind of depth we one day will.
There's an inherent architectural difference between storing mail in a database built on Microsoft's JET technology, and one which stores its data in something that is (although distinctly odd) very much like an xml data store. The Domino architecture makes segmenting the archive into manageable parts by date, by person, or by any combination thereof much simpler.
Essentially, the Domino architecture results in exactly what you describe -- throw more storage space at it and you can keep storing more data. The Microsoft architecture does not.
The Bush administration moved the White House from a Notes/Domino based system to a Microsoft Exchange based system.
Before moving, they'd had no downtime -- even when congress was taken out for 2 days by the code red word (they were on Exchange).
In moving, they mysteriously 'lost' all their backups for a period of time that was suspicious as hell, and now they can't scale to handle the capacity issues they face.
In a Notes/Domino world, this kind of archiving problem wouldn't be all that hard to deal with. You'd just need enough storage for it, and create archives per week/month/year (or an archive per individual's mailbox, or whatever) to put on as much hardware as was required. I single checkbox would be all that was needed to have it encrypted as well.
Oh well. I guess if conveniently "loosing" mail when you don't want it found is one of your design goals, than you probably want to migrate to something less reliable.
Usually, people use Google to look at relationships...really closely.
The constant push of limits on the supposed speed of the craft, capabilities of the ships, and expanded population of the available area took away too many plot devices.
In the original series, they were kind of out there on their own without help available. By the time the big war with the Borg came around in TNG, they got to the point where anything that was a threat could wipe them out entirely, and anything else was easily dealt with.
Both DS9 and Voyager were attempts to revive the sense of frontier self reliance. DS9 was more of a city, and a sort of 'futuristic cop show' was the original goal. Voyager was to be an attempt to get back to the spirit of the original series.
Going forward you have a more urban setting with the known region pretty much all settled and all the borders drawn.
Going backward just gives you more room to work in.
Historically speaking, the process of trying out a new form of government -- be it based on intelligentsia, divine right, populist appeal, military might, or financial might -- is usually a pretty messy thing.
There's all that marching and yelling, sometimes blood and death too.
Things have to be pretty bad to make that worth it. I'm not sure things are bad enough right now for it to be worth it.
I mean, I'm all for a good thought experiment now and again, but tossing out a system of government that's been working reasonably well seems like a bad idea.
All of the private data on the drive will be encrypted. They can search if they like, but between encryption and ccleaner I think they'll find it quite boring.
They can get the password, surely. Either by holding me (as I have no real plan to spend time in a cell) or by sending in the boffins from the NSA. Either of those will take long enough to require a court be involved.
I suppose waterboarding is an option. I doubt I'd hold up much past the paper cup full offered while they explain what's to come next.
Once past the encryption, they'll find the data on the drive is still, however, quite boring.
Everyone knows you keep the real secret plans for world domination with your porn -- encrypted on hidden USB drives made to look like torn cables, or on a secure linux server housed in a data center that used to be an oil rig.
I recall a few years back when they were down for days back in the code-red worm days while the executive branch was not. The executive branch was using Lotus Domino. The Bush administration pulled Domino mail and went to Exchange. Since then, they "lost" a ton of incriminating evidence by failing to make proper backups.
In any case, any system could fail under the kind of load they're likely dealing with.
If you write an object, method, function, or subroutine that has a scope outside your own code -- it can be linked to or called from anywhere else -- you can't ever change its parameter requirements or return results in such a way that previous versions will fail.
You can get around this with overloading, you can get around it with version numbers on your newer declarations (yuck), or other such hacks.
Don't write your code such that people who depend on it can't upgrade to the newer libraries simply because you've changed all the calls they have to make.
F'ing Microsoft does this and it is painful as hell.
if your original method was:
int doSomething(int var1, int var2, int var3)
and you need a fourth variable in a newer version, keep the old version around and either overload it (just create the new method with teh same name and the other variable) or give your new method a new name. Where possible, move the code from the old method to the new one, and just call the new method as the only code in the old one -- supplying the missing data.
Yeah, I know it makes for a lot more code and more methods in your libraries -- but it makes version upgrades happen a million times more smoothly.
Taking the question seriously for a minute -- something unusual for this venue --
Whatever rules you use, make sure they are the same as everyone else on the project. That includes the rules around comments, indenting, and bracket locations. I've seen huge arguments over placement of an enclosing bracket on the same line as a declaration or a new line.
Once you have a little comfort in a language, get on an open source team. They have to be very good about practices because they have hundreds of people working in different locations at different time zones around the world. You'll start with no real authority, being allowed to submit small changes specific to small branches of code. The owner of that small branch will be responsible for accepting your changes if they're good enough. Over time, you'll move up the chain. READ THEIR GUIDELINES. OSS teams have, of necessity, very rigid guidelines on code practices that allow hundreds of people to work on code together. They've had huge battles over those guidelines, and very smart people have said very smart things (you can find them hidden in the morass of garbage if you look hard enough) that have gone into those guidelines.
More Specifically:
If you're repeating the same code, put it in a sub or function (a method if you're using an object oriented language)
A subroutine or function should be as fine grained and generalized as you can possibly make it. It should accept as few parameters as it needs, and should return a single value (or perform a single action). Note: Some languages, like C, use the convention of returning a success/failure boolean as the return value, and the result of the function in a buffer passed as a parameter -- that's also a good strategy.
If your routine is longer than a single screen to read, give real thought to how you might break it out into distinct subroutines (or methods or functions)
Avoid overly complex rules for variable naming. I've seen insanely complex variable name rules that are painful to work with and attempt to encapsulate the the data type, scope, and purpose of each variable in its name. That's not necessary or helpful in modern language programming. Most programming environments let you mouse click a variable and instantly view its declaration and often even comments written by that declaration for explanation. If your variable name includes the type and scope, you'll have to refactor it if you change the type or scope (like from integer to long integer, or boolean to enumeration as is quite frequent)
Use an object oriented language where possible
REALLY learn how to use Overloading, Polymorphism, and inheritance in your object oriented language
Avoid global declarations and functions wherever possible. The smaller the scope of any variable or object, the less likely someone or something will step on it later.
draw out -- on paper -- your object model before you build it. Learn to start with an ER (Entity Relationship) diagram so you can understand the relationships between real world objects. Think in terms of "A" is always the parent of one or more instances of "B", "C", or "D", but may be either a parent or a child of "E". Figure that out using real world objects that your code object represents first, on paper. I personally do this on a whiteboard with colored pens first then transfer to software for mapping.
Trust nothing. Your methods, functions, and subroutines should stand on their own regardless of what crap someone else passes to them. In every method, sub, or function, VALIDATE all variable data, always. Check for overflows. Check to see if an object is instantiated (not null or nothing). Check to make sure values are within the expected ranges. These checks are very small in terms of system resources and program run time. Take the time.
Do your declarations, validity checking, and decision making outside your loops. Any loop you make should do as little as possible inside it. Everything you do in a loop ge
They built a malicious face book application. Big deal. They're all malicious and annoying. The whole damn site is a marketing work to pull personal data about interconnected relationships together for marketing.
"Malicious Facebook App" is like "Table Mesa" (a place in Arizona). Its redundant Mesa means Table in Spanish.
I realize this could get my tossed off /. (and /. people know the most about tossing off) but I'm going to go ahead and agree with you here. Good point.
Facebook is there to make money. End of story. Sites like this are not there as a public service. Start getting used to the idea that whatever you put up there is going to be used in any way they can get away with, TO MAKE MONEY.
They don't like bugmenot, then it will get banned. Don't like that they ban it, stop using facebook. IF enough people agree, it will be no longer cost effective for facebook to ban bugmenot.
Better idea: Stop providing companies out to make money using the internet with long lists of all your friends and family in a way they can easily correlate to create massively complex webs of contact information to market toward.
When I was preparing to market some software, my own lawyer and I talked about it. This was several years ago but oddly enough I don't think the situation has changed much since.
The subject was "Click Through Agreements" be they on the web or on software installation programs. According to her (and she's the lead partner for IP in a fairly prestigious firm) the funny thing about click-through agreements is that they're entirely untested.
While everyone in the IP industry sort of goes along assuming they'll hold up, there remains this possibility that if someone ever did go to court the entire practice could get thrown out as invalid. We all declare that these agreements have meaning, and as long as we all pretend to admire his outfit, the emperor is treated as if fully clothed.
Any misunderstanding of my interpretation of this is down to me, not the lawyer who is quite good at her job.
Possibly the only programming language book I've ever read almost page by page from start to finish -- half of it in one sitting on a flight to London from Boston. I'd meant to just look at it a bit then settle in and watch dvd's. The pace was just right and it had places you could gloss through if you already know how to code in other languages.
Best language book ever. Hands down.
Also, Kathy Sierra is great, and anything that supports her can't be a bad thing.
Its a dessert topping AND and floor wax AND military grade privacy cracking snoop scope!
http://snltranscripts.jt.org/75/75ishimmer.phtml
Without question Ken O. Burtch's book "Linux Shell Scripting with Bash"
Its extremely practical, very well organized, and covers just the right amount of related packages and use cases.
On top of all that, its actually readable.
....well, if its happening that fast, you absolutely could get locked out of future operations...
Any project I manage, and most I am influential all, I make it a point to constantly ask "Why are we collecting this? How long do we need to keep it? When can we delete this data?"
If you don't have it, you can't lose track of it and it can't be stolen from you.
If you have to store sensitive data -- and in some cases we all do -- you try to isolate the sensitive parts of it from the identifying parts of it. Use hashed values for keys instead of actual names or account numbers, that kind of thing.
There's the obvious of course -- data on laptops should be encrypted, and the key for that encryption shouldn't be taped to the inside of the battery door.
Just make sure you're wearing a magnet bracelet, carrying a four leaf clover printed on a card, and drink 8 cups of water a day.
That is like saying a nut and bolt is physics. You can't patent physics. A refrigerater using a compressor, a gas, an expansion valve, and a condenser is just physics. You can't patent physics.
You CAN patent what you've done with physics. You can patent what you've done with math.
...I would say it is much more akin to authoring music or text. You have a limited (though sometimes wide) vocabulary and syntax. Many authors will put the same vocabulary and syntax together in a strive for similar goals, yet the combination used is generally unique. The differentiation between them come out in skill and subtlety as well as application.
Copyright, IOW, is very appropriate. Patent is entirely not.
Business process falls into the same category IMO. If the drive-through window were invited in the 90's and not the 40's, only the first bank or fast food restaurant to come up with the concept could use it and all others would have to pay royalties. Then the owners of toll roads would sue for prior art, etc. etc.
Not to poke fun as I'm sure it was very painful and unpleasant -- something I wouldn't wish on my worst enema (er. enemy -- sorry for the typo) -- but for the love of FSM, what where you telling yourself when this thing was say, golf ball sized?
I'm going to leave the questions about just what kind of plastic underwear you had picked as the most comfortable of programming gear aside for the time being.
This thing had to have somehow entered your mind as potentially problematic somewhere before it reached the size of say...a cherry tomato, yes?
I mean, at what point while showering or wiping your ass or getting dressed or whatever did you fail to say "Hey, that's not another ass cheek growing there is it?"
I showed this to a friend of mine (the story, thankfully without pictures) who's reaction was to suggest that if you were really smart you'd now find a way to sue the chair manufacturer.
I wish you better health and less pain - seriously, I hope this never every happens to you or anyone else again.
Now excuse me while I go watch a pig get slaughtered or click on a rickroll link just to get that image out of my head.