I do not do any heavy compiles on this laptop.... for that I use one of the servers in my office, and transfer the compiled binaries. RPMs work pretty well too.
It would have taken a few days at least to compile X... but thanks to an dual xeon linux server in my office, it takes a jiffie.
Also, you need to keep an eye on your swap usage. Too much of it, and it will take your system down to a crawl.
I personally liked Perl a lot for most of our companies need, until the day till I found that good perl programmers are really hard to find, however, finding decent Java programmers was not that difficult. Not only that, the company could literally hire two Java programers at the cost of one Perl programmer... not that it was ever a concern. The migration of all the systems took over 9 man months. However, for our performance criticial systems, we still rely on good old C. Since the amount of code there is not too much, our company has agreed to stick to it.
I have written applications that run on low memory frootprint devices, offer complete CORBA Interfaces for CSAF-Configuration, Status, Alarms and Faults integeration few a dozen EMS.
I use ORBit2 for both the client and server side... it's almost natural once you know how.
I have a few pointers for stability: 1. A function should be of return type void if and only if the failure inside that function is non-critical. 2. Every possible function should have a return -- and failures should be trapped gracefully and all the way to the top. 3. try-catch-exceptions --- wrap a lot of your code to catch exceptions... and use these consistently. 4. And finally... do not trust any entity. Do not make any assumptions about things like a function succeeding, memory getting allocated etc. I call this is a "failure assumption mode" where I trap failures first, then handle successes later.
Also, if possible go through some general linux kernel code. Though it is coded in c, and is a monolithic kernel, you can see a lot of graceful handling of failures.
I manage a few hundred linux installations and in order to give avoid such issues and make management easier, I have created a shell wrapper.
The shell wrapper works exactly like the ones found on any router, it allows you to change the service configuration, and do diagnosis like ping and traceroute. If you need "shell" access, you just login as another user.
Here I have had cases where a few of these have got broken in because of weak root password, but no damage is possible because access the commands available are only a few ones, and none of them give access to the filesystem or allow launching generic processes. So probably the script sends commands to "infect", the shell simply replies with a "command not found".
The ability of a Call Center executive to to able to retrieve this sensitive data definitely means that the data was exported, in an insecure manner. Blame the bank, or blame the BPO company... fault resides with both.
What is being implied here is that , the person in question could view this data in the most raw form possible... like a database query... what this also means is that the bank, as well the call center organization failed to implement simplest of all checks that access to data directly should be absolutely denied. Storing extremely sensitive data un-encrypted also indicates lack of technical expertise.
When was the last time you could call up Helpdesk of a bank, identify yourself and you ask for your password... the standard reply is that you can select a new one at that point. So why export that data at all?
I have seen cases where certain kind of calls are routed back to the Banks country of origin. The bank could have easily setup a small call center where access to such sensitive data could be kept in-house... avoiding the export risk.
Again, all this points to an open system where the data was so easy to steal that a guy like that could simply pick it up! If that , or someone could have just broken into their network and stolen the data!
Just goes to show how careless banks and BPO organization can get when it comes to customer data. We need stricter laws for implementation of such outsourcing, blaming outsourcing itself is not valid.
The reason is not "low paid area - workers", but lack of understanding the dynamics of outsourcing, both on the part of the Call Center and the company outsourcing the task.
In a bid to reduce cost, the UK company outsources, yet does not setup procedures to make sure the customer data is safe. IMHO, it could have happened anywhere in the world, even in the UK.
Shit Happens, you can't help it. Though you can help by dumping M$ and move to Linux.
I have been using Linux as my only desktop for the past 2.5 years. Honestly, for what I use it for, I have never have had to ever use a M$ product. I code, do presentations, write technical literature etc.. all without any of M$ shit.
Slashdot Mirror
I do not do any heavy compiles on this laptop.... for that I use one of the servers in my office, and transfer the compiled binaries. RPMs work pretty well too. It would have taken a few days at least to compile X... but thanks to an dual xeon linux server in my office, it takes a jiffie. Also, you need to keep an eye on your swap usage. Too much of it, and it will take your system down to a crawl.
Here's my config:
CPU: Pentium III, 650Mhz
Memory: 192 Mb
HDD: 40Gb
CD Reader
OS : Linux, compiled from scratch. Kernel Version 2.6.15 with Pre-emptive patches. Also added support for Toshiba stuff for things like ACPI etc.
Applications: XFCE as the desktop manager, Firefox, Thunderbird, OpenOffice 2.0, GtkPOD, Gimp, GqView etc.
The performance of this system is as good as the 1.4Ghz 256Mb RAM laptops running Windoze.
I love this laptop, even if I upgrade to a better laptop, i will dd the whole OS over to the new system.
I personally liked Perl a lot for most of our companies need, until the day till I found that good perl programmers are really hard to find, however, finding decent Java programmers was not that difficult. Not only that, the company could literally hire two Java programers at the cost of one Perl programmer... not that it was ever a concern. The migration of all the systems took over 9 man months. However, for our performance criticial systems, we still rely on good old C. Since the amount of code there is not too much, our company has agreed to stick to it.
I have written applications that run on low memory frootprint devices, offer complete CORBA Interfaces for CSAF-Configuration, Status, Alarms and Faults integeration few a dozen EMS.
I use ORBit2 for both the client and server side... it's almost natural once you know how.
I have a few pointers for stability:
1. A function should be of return type void if and only if the failure inside that function is non-critical.
2. Every possible function should have a return -- and failures should be trapped gracefully and all the way to the top.
3. try-catch-exceptions --- wrap a lot of your code to catch exceptions... and use these consistently.
4. And finally... do not trust any entity. Do not make any assumptions about things like a function succeeding, memory getting allocated etc. I call this is a "failure assumption mode" where I trap failures first, then handle successes later.
Also, if possible go through some general linux kernel code. Though it is coded in c, and is a monolithic kernel, you can see a lot of graceful handling of failures.
I manage a few hundred linux installations and in order to give avoid such issues and make management easier, I have created a shell wrapper.
The shell wrapper works exactly like the ones found on any router, it allows you to change the service configuration, and do diagnosis like ping and traceroute. If you need "shell" access, you just login as another user.
Here I have had cases where a few of these have got broken in because of weak root password, but no damage is possible because access the commands available are only a few ones, and none of them give access to the filesystem or allow launching generic processes. So probably the script sends commands to "infect", the shell simply replies with a "command not found".
The ability of a Call Center executive to to able to retrieve this sensitive data definitely means that the data was exported, in an insecure manner. Blame the bank, or blame the BPO company... fault resides with both.
What is being implied here is that , the person in question could view this data in the most raw form possible... like a database query... what this also means is that the bank, as well the call center organization failed to implement simplest of all checks that access to data directly should be absolutely denied. Storing extremely sensitive data un-encrypted also indicates lack of technical expertise.
When was the last time you could call up Helpdesk of a bank, identify yourself and you ask for your password... the standard reply is that you can select a new one at that point. So why export that data at all?
I have seen cases where certain kind of calls are routed back to the Banks country of origin. The bank could have easily setup a small call center where access to such sensitive data could be kept in-house... avoiding the export risk.
Again, all this points to an open system where the data was so easy to steal that a guy like that could simply pick it up! If that , or someone could have just broken into their network and stolen the data!
Just goes to show how careless banks and BPO organization can get when it comes to customer data. We need stricter laws for implementation of such outsourcing, blaming outsourcing itself is not valid.
The reason is not "low paid area - workers", but lack of understanding the dynamics of outsourcing, both on the part of the Call Center and the company outsourcing the task.
In a bid to reduce cost, the UK company outsources, yet does not setup procedures to make sure the customer data is safe. IMHO, it could have happened anywhere in the world, even in the UK.
I don't understand what's the use of this....
Why would anyone want to replicate bad software, by a bad company trying to take over the world by monopilistic attitude.
Use Linux/Apple, pirating M$ is only benefiting M$.
A lot of us know that M$ workings are unethical. So stealing from a thief doesn't help!
Shit Happens, you can't help it.
Though you can help by dumping M$ and move to Linux.
I have been using Linux as my only desktop for the past 2.5 years. Honestly, for what I use it for, I have never have had to ever use a M$ product. I code, do presentations, write technical literature etc.. all without any of M$ shit.