You CAN disable the bits that load through the shortcut, but you can not remove the tons of stuff that gets loaded with the OS. We had to upgrade RAM on about 300 PCs after we went from MSO '97 to MSO 2000 because of all that stuff that gets loaded. Even with no MS-Office apps running (nor the little startup bit you mentioned disabling) the systems were virtually unusable in many apps.
The memory utilization nearly doubled by mearly installing MSO 2000... again... even if it wasn't being used. All the changes to the OS and.DLLs to provide nice fast MSO startup and tighter integration were the source of that extra memory use.
The students already have to deal with this problem now. In fact OOo will open MORE file formats than MS Word. And if the poster of this article is actually woried about file format compatibility, they can go with StarOffice for free (yes, free for academic use) which opens tons more formats then even OOo with fewer "alpha" filters.
Or, do you go with MS-Word and then if a student can't open their file at school say... "Sorry. Just buy a few hundred $ word processor and you can use your home computer to do homework again." ?
Same reason web browsers have caches, its not to save server bandwidth (not as a primary concern at least), its to save the real world time of the client.
Regardless, how much time/traffic are we talking about here? Even if you are talking about an extremely popular site, obeying a 1hr TTL is going to cost a couple extra packets per hour. Likewise it will only "slow down" one or two users per hour who are lucky enough to be the first to visit the site since the TTL expired.
Even if an ISP had an override set to 1 day most people complaining about this would find that acceptable. But several weeks??? That's rediculous.
If you have large netblocks your ISP is required to register that netblock to you. Not even large, actually... if you get 8 or more IPs for your business and you are in North America your ISP is supposed to tell ARIN about it. At least according to SWIP guidelines.
Most block lists which use IPs are granular to the netblock level. That's not much help to you if you only have a few IPs, but if you have a block of 8 or more from your ISP you should probably do a WHOIS search at arin.net and make sure the block you were assigned shows up.
We got burned by our ISP when they didn't do that. We were blocked because our ISP (the local cable company) had us lumped in the same netblock as their entire home cable Internet user address space.
In that case, however, the maintainer of the block list was at least willing to unblock us when I could show him that reverse DNS returned hosts with our domain name.
One really handy VMware feature, IMHO, is using host-only networking along with either NAT or bridged networking. If I think a file may be a trojan or infected it only takes a few clicks to turn off the interface which connects to the rest of the world. The remaining virtual network interface only talks to my host Linux system.
Then I can infect Windows and monitor network traffic to see if it starts trying to send spam and I can port-scan to see if it opened any new ports to listen on. When I'm done, one click restores the snapshot and Windows is as clean as it was before I started.
I agree too that it's nice to move a directory from your old PC to your new PC and you've just transfered Win98, WinNT, XP and 2000 to your new system in perfect working order. (Yes, I have licenses to cover them all... which may be required since I sometimes boot up more than one at a time in order to test apps under different OS setups.
100% right. The claim is that cell phone use makes you a bad driver. I say that the truth is that cell phone use makes already-bad drivers stand out.
If I need to pay more attention on the road, I just say, "Hold on a second." Nobody has been offended yet and I've never rear-ended somone at a red light.
The only problems I've had with a cell was that I should have put it down once or twice instead of just stop the conversation. That is a problem I could fix with a hands-free unit.
If you want to be paranoid, you could always use a seperate box for your firewall, lock out all ports except SSH which you have running on a non-standard port which is still firewalled from all but the subnets and IPs you expect to need access from... and even then only accessable if you port-knock another odd port or two first... with SSH disabled for root and both the use account and root have really strong passwords.... both of which are different from any you use on other boxes on your LAN.
Sadly I have to admit that (except for the port-knocking part and non-standard SSH port) I just almost described my home setup.
But I make up for that level of paranoia by using a cheap wireless AP with a static WEP key.
However, I *do* have a vnc port wide open, and whilst today there isn't an exploit, there may be tomorrow.
I guess I should setup the SSH tunnel for that as well.
Either that or some kind of VPN at least. The VNC authors don't consider the data stream secure even. See this FAQ for more details on that. The password is also limited to 8 chars, btw.
Since no user name is used, a hacker just needs to break your password and they have easy access to your system. During login a random string is sent to the viewer, encrypted with the user password and sent back. I suspect that someone evesdropping on the full conversation could probably work out the password with some effort.
So..
Use a VPN, SSH or some other way to encrypt the datra stream for VNC
Firewall access to VNC from the Internet
Under Windows, set preferences to log you out or lock the session when you disconnect (At least the person getting in will have to also know/guess your windows password.)
GPL is wonderful, but that doesn't make it any less viral.
Viral implies that it can somehow infect your code without any action on your part. That's BS. The claim also generally implies that your code is forever tainted. Again... complete BS.
First, to *infect* your code you have to actually steal GPL code and put it in your program. Yes, some libraries are under the GPL and using them requires a license too.. but you are still using someone else's code without authorization.
Before someone says that you have the right to use the code because it's free, hold on. Remember the GPL is a license to use the code it covers. More accurately, it gives you authority to change the code and distribute it. Without a license, you have no rights whatsoever to use the code somebody else wrote. (That's true whether it's Microsoft or the guy next door.)
BUT, like most licenses, there are restrictions. In the GPL's case, those include restrictions include requiring you to share changes you make. But perhaps the most important thing to keep in mind is that if you don't steal someone else's code and put it in your program you don't have to worry about the license... GPL or other. The GPL doesn't even try to restrict you from using the code however you wish in your organization... just don't try to distribute a program containing others' copyrighted work.
"Code forever tainted" - This one is BS because you have a few options to make things right. 1) Make all of your code GPL. 2) Stop distributing your code to others. 3) Simply remove the GPL code from your program. 4) Work out some other type of license with the person/people you stole the code from. (Because if you don't have a valid license that you are obeying, you have NO right to use their code at all.)
Only the first option cause your program to somehow become GPLed. If you say that you can't remove the GPLed code, then I guess that it's a major part of your program and apparently you wouldn't even have a viable program if you hadn't taken someone eles's code. And if you took someone else's code, you better be prepared to license it legally from them if you want to use it.
Obeying the GPL restrictions is an easy way to fix a license violation but it is not the only way.
If you produce a large system entirely from scratch then you need to be prepared to add features, and do other maintenance to that system for as long as it is used (maybe decades.)
If you customize an existing COTS package then you need to be prepared to maintain at least the portion you customized. (And hopefully you kept your customizations modular so you could still upgrade the underlying COTS software as new releases come out.)
If you start with FOSS and customize it, you can probably get some of your changes merged back into the main project (so they automatically are included in every future release.) Then you have to plan to maintain the portions you are keeping hidden inside your company.
If you can find a COTS (or FOSS) package that fits your needs exactly (or nearly enough that you don't have to customize) USE IT!
The maintenance issue really kicks in as you move on to custom project #2, #3, #4.. etc. Unless your IT staff is growing along with the maintenance needs, you'll soon find that all of your time is spent just fixing and keeping existing stuff working.
Very few OSS licenses (do any?) require you to release changes back unless you are distributing your changed apps to others. Even the GPL which MS likes to call "viral" doesn't require you to release a single change you make for use within the enterprise so long as you don't distribute your changed software outside of your enterprise.
And a reply to the person who claims that "Very little oss stuff supports Oracle/MSSQL, LDAP/AD authenication, web service or Java interfaces. Actually quite a few do support major commercial DBs and many which need authentication also support LDAP/AD. Even if they don't, support can usually be added without too much additional effort using avilable libraries and APIs.
A fair number of FOSS software was written by/for enterprises who realized that maintaining it themselves was not practicle so they released it as OSS. And guess what... many FOSS projects aren't being developed by some computer geek in his basement but instead are the results of programmers being *paid* to do the work. According to a recent Newsweek article, currently as much as 90% of the patches for the Linux kernel are being submitted by people who are being paid to program.
IBM has over 600 programers working on FOSS projects. If IBM isn't "enterprise" aware then I don't know who would be.
It's only cold during the few minutes I'm outside (between the house and the car or the car and my work.) I'll take that over having an earthquake turn my house into rubble or drop me and the rest of my state into the ocean.
Take a look at groklaw.net for any letters, documents, etc. related to the case. You can also read some VERY revealing depositions that IBM did with people directly involved with the contract negotiations... who all say that no, derivitive works were not covered so long as they do not actually include the AT&T code itself.
So, bottom line appears to be that all SCO really needs is to do a direct source-code to source-code comparison then weed out stuff they can't possibly claim ownership (such as BSD code added to SysV.)
Of course that wouldn't keep the case in the courts for a prolonged time and it wouldn't require any of the stuff they are asking for in discovery these days. (Not to mention the fact that those who have compared the code can't find any line-for-line copying... not even the millions of lines of line-for-line copying SCO claimed were in Linux when they started this whole mess.)
Even if their claim of viral licensing terms were correct, there is still the question of whether SCO actually even owns ANY of the code it claims it does. Novell (most recent undisputed owner) says that they never sold SySV to SCO... just the right to sell licenses. Even that right was tempered by Novell retaining rights to control the termination of any such license... which they did regarding IBM saying that no SCO could not terminate IBM's license.
That did seem to be the main thrust of the first article didn't it? Personally it would have gotten a lot more of my attention if the focus was on a way for me to save $1000/yr in electricity bills.
Consumers are really going to be interested in continuously buying new players or upgrading their current firmware to play new realeases because someone broke through their brand of player.
This all seems like a set-up to me.
Consumers buy scads of DVD equipment without knowing a compromized key will disable their player.
Keys start to be cracked.
Industry tells upset consumers that the reason they have to buy new equipment is evil cracker (not poor design/planning.)
Consumers buy new equipment and demand that something be done to prevent this from happening again.
MPAA and others get new super-DMCA laws passed.
Attempting to watch a DVD on Linux is now punishable by death. (At least in Texas.)
Yeah, I can see how the consumer wins in that scenario.
Or how about disaster sites. Strong enough to pick up debris and slabs of concrete but agile enough to do it without knocking everything else onto victims.
That'd be cool anyhow. Even if it wouldn't be as fun as picking up your neighbor's house and hiding it while he is gone to the store. Too bad the huge footprints leading to the new location of the home would probably give you away.
If nothing else bring recent code analysis results to his attention which show bug rates in Linux to be on the order of 1/100th to 1/150th as common as typical commercial software.
If he is failing anyone based on an expectation that open source software is going to have the same number of bugs then his premise is flawed.
I know what you mean. I keep getting mental images of a future like that in Minority Report - where ads are shown on almost every public surface and where scanners identify who you are and customize the ads with your name, etc.
If you think spam is annoying, imagine what it would be like to walk around and have computer-generated "people" calling out your name all the time. (It throws me off enough in public when someone happens to have the same first name as me and someone else calls out to them.)
No. That is incorrect. First of all XOR is NOT the same as + and -. See this explanation to brush up on XOR and RAID parity.
Here is an example:
First if three data blocks and one parity are written at once: 1010110010011 - data 1100101101100 - data 0111011010110 - data ------------- 0001000101001 - parity (XOR of all data) (Four block writes.)
Next, if two data blocks and parity are written then later a third data block and new parity is written. 1010110010011 - data 1100101101100 - data ------------- 0110011111111 - parity (XOR of original data) (3 block writes)
0110011111111 - parity (possibly read from disk) 0111011010110 - data ------------- 0001000101001 - parity (Note same result.)
One disk read and two writes... exactly as grandparent poster said. No need to read any of the original data blocks. Only the original parity block. Even then only if it isn't still cached in RAM which is quite possible.
You are absolutely right. I hadn't considered that. An XOR of the parity block would provide the same results as XORing all current data blocks against the new one.
Assume 4k blocks. I buffer up 24k (6 blocks) calculate a 4k parity block and write 7 blocks to the 7 different disks.
Lets say that so little disk activity is going on that it needs to flush buffers before it has buffered 24k of data. (I'm making an assumption how it really behaves now) I would expect it would calculate the XOR across as many 4k blocks as it had and write some blocks as blank. When it went to write more data it almost certainly has those last few 4k blocks still cached in RAM.
It should be extremely rare that it actually has to go back to disk to read data for creating the parity blocks.
I'm not sure I would go so far as to get different brands, but I would definately try to get them from different batches if possible. If there was a manufacturing problem you'd hate to get 5 out of a batch of 12 defective drives. Multiple drive failures at one time in your RAID array is painful.
Actually, I can see some sense to that. He did mention failing during rebuild. That's when we are at the greatest risk of another failure after all since they are working harder than normal.
If you have one large partition and impending drive failure wipes out any cylindar on that drive, all the data on it is shot. That drive won't be used at all during the rebuild... a rebuild of 250Gb. You are at risk if, during any time of the long rebuild, a 2nd drive fails completely or even coughs up a bad cylindar which can't be redirected.
If you have 6 partitions, only the "damaged" one has to be recovered immediately. Obviously you would want to recover them all as soon as possible since that first drive is probably going to bite the dust soon. Even if you do lose the first drive completely and then a 2nd drive during a rebuild, you at least may not lose everything. Any of the 40 Gb blocks which were rebuilt before the 2nd drive died would have been saved.
Getting a slightly different sized drive for an RMA can also be a problem. What if your original 250Gb drives were actually 250.3Gb and the replacement is 250 Gb even? You aren't going to fit that single 250.3 Gb partition onto the replacment drive. And are you going to call the drive manufacturer and complain that your original drives were too big?
I've had issues with this on hardware RAID. I had to back up 600Gb over the network, wipe the entire array out, rebuild it and restore the data. If it had been software RAID, I could have backed up the data from the last partition into one of the others just to be safe, resized the last one, reformatted and copied the data back.
LVM with multiple partitions would have made it even easier.
You CAN disable the bits that load through the shortcut, but you can not remove the tons of stuff that gets loaded with the OS. We had to upgrade RAM on about 300 PCs after we went from MSO '97 to MSO 2000 because of all that stuff that gets loaded. Even with no MS-Office apps running (nor the little startup bit you mentioned disabling) the systems were virtually unusable in many apps.
The memory utilization nearly doubled by mearly installing MSO 2000... again... even if it wasn't being used. All the changes to the OS and .DLLs to provide nice fast MSO startup and tighter integration were the source of that extra memory use.
Or, do you go with MS-Word and then if a student can't open their file at school say... "Sorry. Just buy a few hundred $ word processor and you can use your home computer to do homework again." ?
Regardless, how much time/traffic are we talking about here? Even if you are talking about an extremely popular site, obeying a 1hr TTL is going to cost a couple extra packets per hour. Likewise it will only "slow down" one or two users per hour who are lucky enough to be the first to visit the site since the TTL expired.
Even if an ISP had an override set to 1 day most people complaining about this would find that acceptable. But several weeks??? That's rediculous.
Most block lists which use IPs are granular to the netblock level. That's not much help to you if you only have a few IPs, but if you have a block of 8 or more from your ISP you should probably do a WHOIS search at arin.net and make sure the block you were assigned shows up.
We got burned by our ISP when they didn't do that. We were blocked because our ISP (the local cable company) had us lumped in the same netblock as their entire home cable Internet user address space.
In that case, however, the maintainer of the block list was at least willing to unblock us when I could show him that reverse DNS returned hosts with our domain name.
Then I can infect Windows and monitor network traffic to see if it starts trying to send spam and I can port-scan to see if it opened any new ports to listen on. When I'm done, one click restores the snapshot and Windows is as clean as it was before I started.
I agree too that it's nice to move a directory from your old PC to your new PC and you've just transfered Win98, WinNT, XP and 2000 to your new system in perfect working order. (Yes, I have licenses to cover them all... which may be required since I sometimes boot up more than one at a time in order to test apps under different OS setups.
If I need to pay more attention on the road, I just say, "Hold on a second." Nobody has been offended yet and I've never rear-ended somone at a red light.
The only problems I've had with a cell was that I should have put it down once or twice instead of just stop the conversation. That is a problem I could fix with a hands-free unit.
Sadly I have to admit that (except for the port-knocking part and non-standard SSH port) I just almost described my home setup.
But I make up for that level of paranoia by using a cheap wireless AP with a static WEP key.
Go figure.
Either that or some kind of VPN at least. The VNC authors don't consider the data stream secure even. See this FAQ for more details on that. The password is also limited to 8 chars, btw.
Since no user name is used, a hacker just needs to break your password and they have easy access to your system. During login a random string is sent to the viewer, encrypted with the user password and sent back. I suspect that someone evesdropping on the full conversation could probably work out the password with some effort.
So..
Viral implies that it can somehow infect your code without any action on your part. That's BS. The claim also generally implies that your code is forever tainted. Again... complete BS.
First, to *infect* your code you have to actually steal GPL code and put it in your program. Yes, some libraries are under the GPL and using them requires a license too.. but you are still using someone else's code without authorization.
Before someone says that you have the right to use the code because it's free, hold on. Remember the GPL is a license to use the code it covers. More accurately, it gives you authority to change the code and distribute it. Without a license, you have no rights whatsoever to use the code somebody else wrote. (That's true whether it's Microsoft or the guy next door.)
BUT, like most licenses, there are restrictions. In the GPL's case, those include restrictions include requiring you to share changes you make. But perhaps the most important thing to keep in mind is that if you don't steal someone else's code and put it in your program you don't have to worry about the license... GPL or other. The GPL doesn't even try to restrict you from using the code however you wish in your organization... just don't try to distribute a program containing others' copyrighted work.
"Code forever tainted" - This one is BS because you have a few options to make things right. 1) Make all of your code GPL. 2) Stop distributing your code to others. 3) Simply remove the GPL code from your program. 4) Work out some other type of license with the person/people you stole the code from. (Because if you don't have a valid license that you are obeying, you have NO right to use their code at all.)
Only the first option cause your program to somehow become GPLed. If you say that you can't remove the GPLed code, then I guess that it's a major part of your program and apparently you wouldn't even have a viable program if you hadn't taken someone eles's code. And if you took someone else's code, you better be prepared to license it legally from them if you want to use it.
Obeying the GPL restrictions is an easy way to fix a license violation but it is not the only way.
If you customize an existing COTS package then you need to be prepared to maintain at least the portion you customized. (And hopefully you kept your customizations modular so you could still upgrade the underlying COTS software as new releases come out.)
If you start with FOSS and customize it, you can probably get some of your changes merged back into the main project (so they automatically are included in every future release.) Then you have to plan to maintain the portions you are keeping hidden inside your company.
If you can find a COTS (or FOSS) package that fits your needs exactly (or nearly enough that you don't have to customize) USE IT!
The maintenance issue really kicks in as you move on to custom project #2, #3, #4.. etc. Unless your IT staff is growing along with the maintenance needs, you'll soon find that all of your time is spent just fixing and keeping existing stuff working.
And a reply to the person who claims that "Very little oss stuff supports Oracle/MSSQL, LDAP/AD authenication, web service or Java interfaces. Actually quite a few do support major commercial DBs and many which need authentication also support LDAP/AD. Even if they don't, support can usually be added without too much additional effort using avilable libraries and APIs.
A fair number of FOSS software was written by/for enterprises who realized that maintaining it themselves was not practicle so they released it as OSS. And guess what... many FOSS projects aren't being developed by some computer geek in his basement but instead are the results of programmers being *paid* to do the work. According to a recent Newsweek article, currently as much as 90% of the patches for the Linux kernel are being submitted by people who are being paid to program.
IBM has over 600 programers working on FOSS projects. If IBM isn't "enterprise" aware then I don't know who would be.
It's only cold during the few minutes I'm outside (between the house and the car or the car and my work.) I'll take that over having an earthquake turn my house into rubble or drop me and the rest of my state into the ocean.
So, bottom line appears to be that all SCO really needs is to do a direct source-code to source-code comparison then weed out stuff they can't possibly claim ownership (such as BSD code added to SysV.)
Of course that wouldn't keep the case in the courts for a prolonged time and it wouldn't require any of the stuff they are asking for in discovery these days. (Not to mention the fact that those who have compared the code can't find any line-for-line copying... not even the millions of lines of line-for-line copying SCO claimed were in Linux when they started this whole mess.)
Even if their claim of viral licensing terms were correct, there is still the question of whether SCO actually even owns ANY of the code it claims it does. Novell (most recent undisputed owner) says that they never sold SySV to SCO... just the right to sell licenses. Even that right was tempered by Novell retaining rights to control the termination of any such license... which they did regarding IBM saying that no SCO could not terminate IBM's license.
That did seem to be the main thrust of the first article didn't it? Personally it would have gotten a lot more of my attention if the focus was on a way for me to save $1000/yr in electricity bills.
Yeah, I can see how the consumer wins in that scenario.
Or how about disaster sites. Strong enough to pick up debris and slabs of concrete but agile enough to do it without knocking everything else onto victims.
That'd be cool anyhow. Even if it wouldn't be as fun as picking up your neighbor's house and hiding it while he is gone to the store. Too bad the huge footprints leading to the new location of the home would probably give you away.
Sure, but once he straps on the jet engines... watch out! lol
If nothing else bring recent code analysis results to his attention which show bug rates in Linux to be on the order of 1/100th to 1/150th as common as typical commercial software.
If he is failing anyone based on an expectation that open source software is going to have the same number of bugs then his premise is flawed.
I know what you mean. I keep getting mental images of a future like that in Minority Report - where ads are shown on almost every public surface and where scanners identify who you are and customize the ads with your name, etc.
If you think spam is annoying, imagine what it would be like to walk around and have computer-generated "people" calling out your name all the time. (It throws me off enough in public when someone happens to have the same first name as me and someone else calls out to them.)
Followed shortly after by laws preventing you from using "devices" that circumvent the eye-scan... including family pets.
Here is an example:
One disk read and two writes... exactly as grandparent poster said. No need to read any of the original data blocks. Only the original parity block. Even then only if it isn't still cached in RAM which is quite possible.
You are absolutely right. I hadn't considered that. An XOR of the parity block would provide the same results as XORing all current data blocks against the new one.
Lets say that so little disk activity is going on that it needs to flush buffers before it has buffered 24k of data. (I'm making an assumption how it really behaves now) I would expect it would calculate the XOR across as many 4k blocks as it had and write some blocks as blank. When it went to write more data it almost certainly has those last few 4k blocks still cached in RAM.
It should be extremely rare that it actually has to go back to disk to read data for creating the parity blocks.
I'm not sure I would go so far as to get different brands, but I would definately try to get them from different batches if possible. If there was a manufacturing problem you'd hate to get 5 out of a batch of 12 defective drives. Multiple drive failures at one time in your RAID array is painful.
If you have one large partition and impending drive failure wipes out any cylindar on that drive, all the data on it is shot. That drive won't be used at all during the rebuild... a rebuild of 250Gb. You are at risk if, during any time of the long rebuild, a 2nd drive fails completely or even coughs up a bad cylindar which can't be redirected.
If you have 6 partitions, only the "damaged" one has to be recovered immediately. Obviously you would want to recover them all as soon as possible since that first drive is probably going to bite the dust soon. Even if you do lose the first drive completely and then a 2nd drive during a rebuild, you at least may not lose everything. Any of the 40 Gb blocks which were rebuilt before the 2nd drive died would have been saved.
Getting a slightly different sized drive for an RMA can also be a problem. What if your original 250Gb drives were actually 250.3Gb and the replacement is 250 Gb even? You aren't going to fit that single 250.3 Gb partition onto the replacment drive. And are you going to call the drive manufacturer and complain that your original drives were too big?
I've had issues with this on hardware RAID. I had to back up 600Gb over the network, wipe the entire array out, rebuild it and restore the data. If it had been software RAID, I could have backed up the data from the last partition into one of the others just to be safe, resized the last one, reformatted and copied the data back.
LVM with multiple partitions would have made it even easier.