No, I'm proposing that all the secrecy that allowed them to corrupt government officials, launder their profits, etc is what allows them to exist in the first place. Again, look deeper. When a problem persists, despite all attempts to wipe it out you have to wonder if the problem is really understood. This is the same sort of issue that creates stupid responses to other situations, like people claiming that immigrants take jobs away from US citizens when anything beyond the most simplistic analysis shows this to be complete hogwash.
Problems need to be actually studied and understood, but instead what we get is sound bite logic like this that totally misses the point and always seems to fail when applied in the real world.
Your entire argument here rests on some fairly arbitrary parsing of the number things that are secrets and how we count them. Since this is going to be a basically arbitrary kind of enumeration it can be used to prove pretty much any point you or I care to try to prove.
A legitimate argument would IMHO be something like along the lines of a cost/benefit analysis. One of the interesting things about this leak is we are getting to see exactly how much this involuntary openness actually costs. Watch and see. I predict that there will be no appreciable cost at all. The benefit of openness is quite apparent when it saves the public money.
No, I'm proposing that this whole game of playing secrets with each other is a very stupid game. You're simply not thinking about this deeply enough.
I'd also point out that all the spying in the world has utterly failed to deal with things like organized crime, etc. It hasn't solved anyone's diplomatic or political issues either.
What it HAS done is given people in governments all over the world the excuse and cover to hide a vast array of crimes which dwarfs anything like organized crime in the way an elephant dwarfs a mole.
So a statement about how to reason from evidence is an assertion of fact? Actually it isn't. It is an assertion about how to reason, which is a totally different thing.
Maybe some perusal of basic texts on deductive reasoning would be useful.
You made an assertion that secrecy is required in order for X, Y, and Z things to be accomplished. Provide some evidence that this assertion is warranted.
No, I actually know no such thing. You've made a whole bunch of assertions but I actually work on the basis of evidence. I'd like to see these assertions backed up by some reasoning and some observations.
Quite frequently it is assumed that because things have been done in a certain way in the past that they can only be done that way. This sort of reasoning rarely holds up to careful examination.
Secrecy or the information hasn't been made public? There's a huge difference between the government claiming that information is classified and it is illegal to reveal it and a private organization that doesn't reveal information by choice. That information is easily subject to being made public and any court has the authority to demand it under penalty of law. It is a whole different animal.
The government and a private organization are entirely different in very important ways beyond that. The government supposedly is the mechanism by which the people exercise their sovereignty. Secrecy destroys the fundamental power of the people by hamstringing their AUTHORITY over the government. WikiLeaks has no such power. It doesn't exercise state power. It isn't out there potentially doing evil. If it DOES do evil, then it is answerable, the government really isn't in any practical sense.
You're also forgetting what WikiLeaks is doing. They haven't simply released information willy-nilly, they have gone through a rather careful process under which they have sought out the expertise of others with a great deal of experience in handling sensitive information. The government may not LIKE this and ideally there would be an even better process, but the truth of the matter is that all the accusations being made here are rather overblown. The only people likely to be hurt by these information releases are people that have been doing things they shouldn't be doing. I have no sympathy for them. Just because they have power is irrelevant.
There are a lot of legitimate debates that can be had on the subject of secrecy and its potential legitimate uses. The problem is that allowing ANY secrecy is a slippery slope. Once you let that cat out of the bag you can't easily put it back in and I personally see any good coming of it FAR outweighed by the evil. To the point where some small individual instance of good is almost insignificant by comparison to the evil.
I can certainly understand the people who may benefit from what could be legitimate instances of secrecy being dismayed by a denial of that option, but there is such a thing as greater good. Our criminal justice system regularly puts innocent people in prison, but yet we still believe it is necessary and has value. This is the same sort of equation.
Another factor is the temptation to do evil. If ones nefarious actions will CERTAINLY be outed for the world to see then most of them won't take place. Instead of clandestine nonsense we might actually have the facts of every situation clearly out in the open where they can be resolved fairly in the light of day. This will be a great good for society, one which far outweighs the small cost. In fact I think we would find that ultimately the cost is zero.
When the government stops using its authority to make things secret to largely cover up fraud, waste, abuse of power, and naked greed THEN we'll have a discussion about it. Until then tough shit for them. If it takes having Wikileaks and Julian Assange out there to clean it up then I say I want to see 100 or 1000 more just like them. Turn over every single rock under which any secret lurks. Secrecy is a tool of evil, pure and simple.
The problem with "everything is an object" is that there are a LOT of different ways an "object" can be laid out in memory. If the consuming program hasn't exactly the correct idea of how that works then you're SOL.
No you're not SOL. No reasonable object oriented client depends on in-memory layout, they all use properties and methods to access member data.
Yes, actually you ARE, because you have to know that you are dealing with a stream of objects of type X and write a piece of software that specifically deals with type X. The grep program will work on ANY bytestream. Furthermore on the VAST majority of them a specific invocation of grep will behave in logically the same manner. Thus I don't have to know ANY exact details of what the input I'm handling is. Thus there is a LARGE degree of decoupling. Each Unix command line program is a very flexible independent module of functionality which can be deployed with very little change (the command line parameters) and is loosely coupled with the other components of the system it is being used as part of.
Now, that can breed problems. If you have a very specific task that you need done over and over again with high confidence that the code behaves in a specific way regardless of updates and changes to the system, then you MIGHT want to compile a program to do that specific thing.
On Windows you generally have no other choice. You HAVE to write a program because the data you're processing pretty much has to be accessed via a specific procedure that won't work with any other kind of data. It will also require a lot more glue logic and etc. than a shell script would.
The power of bytestreams and small modular programs that do one thing well, plus a reasonably intelligent set of conventions for how programs represent their output in that environment is what makes Unix so great, and the OP is pointing out a pretty well-known fact, that you can create a lot of really good and highly reliable software that way.
I know in my organization Windows servers exist PURELY for legacy applications that can't be migrated.
Mine too. But, no matter how hard we try, we need more Windows servers every year. Windows is the third platform, but most new software is still deployed on it, mainly because we have a buy-over-build philosophy and most commercial software requires Windows.
Eh, it really depends on the business you are in. There is basically one application we run Windows for in our organization. If that application were to become obsolete it would probably be replaced by something that runs on Linux.
The vast majority of places that are on the Windows bandwagon on the server side got themselves locked into some proprietary technology back in the day. That may well drive Windows server upgrades and deployments for years to come, but the niche gets smaller every year. People may have literally in raw numbers more Windows every year, sure, but it is a smaller percentage of all deployed systems.
I don't know about the numbers arguments. My anecdotal experience is that Unix/Linux systems just run reliably pretty much forever and it is easy to run a lot of stuff on one box.
I've never had a problem running a lot of stuff on Windows and maybe one in a hundred servers crash due to software in a given year.
Yeah, not my experience. IME rolling out Windows patches to servers is a huge pain in the ass that is OFTEN associated with the server becoming inoperable for whatever obscure reason. I can think of one instance of this happening with a Kernel upgrade on a Linux server, ever.
It seems like basically we provision Linux like "we need one of this, it won't fail" and Windows like "we need 2 of this because one of them WILL fail". I guess if that sells 2x as many Windows licenses, well good for them, lol!
The problem with "everything is an object" is that there are a LOT of different ways an "object" can be laid out in memory. If the consuming program hasn't exactly the correct idea of how that works then you're SOL.
Now, that would be true of BINARY byte streams as well, but any record-oriented format can be processed by tools like grep, awk, sed, etc. They use a high enough level data abstraction that the details of exactly what the data MEANS doesn't have to be agreed between utilities for many purposes. I can grep out records in a stream that all contain a specific value I want to deal with, etc and not have to know a THING about the data except that pattern X will appear and when it does what to spit out, for which I just need to know a record delimiter. MANY utilities don't even need to know that much.
As others have said, I'd consider Linux to be 'Unix' for purposes of this discussion and it certainly is the same operating environment with the same characteristics.
Other advantages of Linux/Unix will include a highly unified namespace for instance which lets me use the same tools on almost ANY source of data and direct it to almost any sink. That simply isn't possible in the Windows environment.
I don't know about the numbers arguments. My anecdotal experience is that Unix/Linux systems just run reliably pretty much forever and it is easy to run a lot of stuff on one box.
Look at the latest numbers for planned deployments of Linux in the datacenter. Practically everyone is expanding their Linux usage and Windows server deployments have peaked and seem to be shrinking at larger organizations. I'm sure they will both be around for a LONG time to come, but it sure seems like the long term trajectory is Linux is the standard ubiquitous server OS. I know in my organization Windows servers exist PURELY for legacy applications that can't be migrated. That seems to be true for my clients as well at least for line-of-business applications.
Yeah, for some types of applications VMS was quite well suited.
I know what you mean about the VMS guys. Back in the 80's I was in a LARGE engineering group. They had a cluster of VMS machines that supported around 1000 interactive users. Getting them to do ANYTHING, like set up a file share with our OS9/68k testing platforms was a nightmare, lol.
Then again most of the users were running huge engineering simulations in FORTRAN batch jobs too, so it was wonderful for them.
Overall I'll take Unix. It may not make everything dirt simple, but it is far more likely your problem can be solved easily and quickly.
Sure, awk is a programming language. It is also a command line tool. A bit more flexible than most, but you can't really draw a line between something that is a programming language and something that is a 'built in tool'.
I really have no idea WHY their code was so large. It was all written in FORTRAN and VMS is honestly a nightmarishly complicated operating environment. A lot of it is probably related to the fact that Unix has a much simpler and more orthogonal environment. Of course this is also WHY Unix killed VMS dead long ago. Simplicity is a virtue. This is why Windows still hasn't entrenched itself forever in the server room. It lacks the simple elegance of 'everything is a byte stream' and 'small flexible programs that simply process a stream'. Those are powerful concepts upon which can be built a lot of really complex stuff in a small amount of code.
Oh, it was office politics. I was doing a decent job, but my boss was definitely the insecure type, lol.
I think they honestly just couldn't wrap their heads around the fact that I could reduce their code bloat to a few 100 lines of scripting. I didn't do it to make anyone look bad, I did it purely because it was the logical way to execute a task I was assigned.
Now, I may not be the MODEL employee in every respect, but I'm a pretty good team player. That particular team had its issues though, lol. Ah well, it was all good. Haven't really had to work for anyone since then pretty much, consulting suites me fine.
Once, about 20 years ago, I worked for a company who's line of business generated a VERY large amount of data which for legal reasons had to be carefully reduced, archived, etc. There were various clusters of VMS machines which captured data from different processes to disk, from where it was processed and shipped around. There were also some of the 'new fangled' Unix machines that needed to integrate into this process. The main trick was always constantly managing disk space. Any single disk in the place would probably have 2-10x its capacity worth of data moving on and off it in an given day. It was thus VITAL to constantly monitor disk usage in pretty much real time.
On VMS the sysops had developed a system to manage all this data which weighed in at 20-30k lines of code. This stuff generated reports, went through different drives and figured out what was going in where, compared it to data from earlier runs, created deltas, etc. It was a fairly slick system, but really all it did was iterate through directories, total up file sizes, and write stuff to a couple report files, and send an email if a disk was filling up too fast.
So one day my boss asks me to write basically the same program for the Unix cluster. I had a reputation as the guy that could figure out weird stuff. Even had played a small amount with Unix systems before. So I whipped out the printed Man pages and started reading. Now I figured I'd have to write a whole bunch of code, after all I'm duplicating an application that has like 30k lines of code in it, not gigantic but substantial. Pretty soon though I learned that every command line app in Unix could feed into the other ones with a pipe or a temp file. Pretty soon I learned that those apps produced ALL the data that I wanted and produced it in pretty much the format that I needed. All that I really had to do was glue it together properly. Pretty soon I (thank God it starts with A) I found awk, and then sed. 3 days after that I had 2 awk scripts, a shell script that ran a few things through sed, a cron job, and a few other bits. It was maybe 100 lines of code, total. It did MORE than the old app. It was easy to maintain and customize. It saved a LOT of time and money.
There's PLENTY to recommend the KISS principle in software design. Not every problem can be solved with a bit of shell coding of course, but it is always worth remembering that those tools are tried and true and can be deployed quickly and cheaply. Often they beat the pants off fancier approaches.
One other thing to remember from that project. My boss was the one that wrote the 30k LoC monstrosity. The week after I showed her the new Unix version, I got downsized out the door. People HATE it when you show them up...
My point was only that a system which is totally bogged down by disk IO is somehow not exactly optimum and that a lot of the less mainstream distros don't exactly seem to know a heck of a lot about tuning or what patches to use, which CAN be an issue. You want a desktop specific distribution from a reputable mainstream source.
People expect that some guy in his garage somewhere knows how to put together a well built OS, but that is largely a vain hope. The Linux kernel is a wonderful piece of software, but that doesn't mean you can't horribly misuse it and get bad results.
No doubt many older releases work fine too. I can't recall having this sort of problem in any version of Mandriva for instance, at least not in years. I don't think my particular system is special in that respect, I just use a reasonably high quality distro and things work!
Of course the OP could be dealing with some horrible bad specific device driver or hardware too. That can make a significant difference. I think the flaw in his thinking is generalizing this as a Linux desktop issue and not a hardware or OS specific issue that HE has.
Using Mandriva 2010.0 (or on any earlier builds for that matter). Not sure if their stock kernel is using scheduling patches or not but the only time I've ever seen slowdowns on my wimpy P4 machine is with really serious oversubscribing to memory, which obvious will turn it into a dog. IO seems to have little to no effect however.
So maybe you just need a better desktop distribution? A newer one perhaps? Don't expect that if you slap just any old distro on a machine and call it a workstation that you get something beyond garbage. I'd expect Suse and/or Fedora to work equally well. Ubuntu is probably doing OK but I wouldn't know. Most of the smaller/less mainstream distros however are quite random, and running something like CentOS on a desktop is just asking for a crappy desktop.
to implement say a stock exchange where you have to deal with 100's of thousands of business messages a second with absolute 100% reliability and fault tolerance. Call us whatever names you like, but in this business you walk the walk and bullshit lasts 9 seconds. There really is no other tool out there that lets you build REAL line of business application systems with anything like the scalability and with anything like the efficiency of either manpower or hardware. Anyone who doesn't know that lives under a rock from my perspective.
You can certainly do a LOT of things with other tools, but there simply IS a class of applications that are in high demand for which JavaEE is the right answer.
TDD is the best approach. Write unit tests BEFORE you write the code. First of all you'll be motivated to get it done. Second of all you'll write MUCH more testable code and thus spend a lot less time on testing. In the long run you will actually get to write more fun stuff than if you didn't do it this way.
Honestly, not all testing will ever be fun, but there's really no point to writing bad broken software and untested software is invariably bad software. Honestly though whatever organization you're working in should be insisting on this kind of process anyway. First thing I do when I set up a team is get the unit testing process up and running.
This is not 'weird' at all. It's just one bot trying to fool another by making it think there is excess liquidity on one side. Oldest trick in the book. Also entirely against the rules. So it proves there are slugs out there gaming the market, but there's no question about WHAT they are doing, that's perfectly transparent.
1 million Bbl per day is a pretty absurd number. A single well producing 500k bbl per day would be pretty absurd. If there's a trillion bbl of oil down there then how come we import from the Middle East?
Wherever this article got its numbers from they are pure fantasy.
I disagree with you. There are highly paid professional malware writers. I think you don't have your facts straight. There is plenty of money being made creating slick software to run botnets, install malware, etc. Whether it is the most technically sophisticated hacks they are using or not is really irrelevant. Its about being able to produce a salable and functional product.
I certainly don't claim to be some leading expert on this subject, but I have plenty of contacts with Eastern European and Asian contractors and I'm telling you they can make very good money in that business. If you think different I suspect you're just not really well informed on the subject.
Well, then answer this question. Why are a whole lot of people making big bucks hocking malware? They're making that money because the software they have to hock is the best there is. Now, whether or not its the most technically sophisticated product or not is irrelevant. Heck, this is Slashdot, we all can just take a gander at the market for operating systems and see that the best selling software has little to do with technical quality...
But the day you go to start selling your new wizz-bang botnet buildin' super crackin' gizmo-ware that you just spent the last 6 months putting together and 3 hours later all your potential customers have it for free. Yeah, that'll put an actual dent in those people's business. It will not solve the theft problem, but in the long run it will destroy the incentive for smart people to try to make their living selling malware (etc). That WILL do what can be done, which is to reach a kind of stasis in the arms race.
Its kind of a funny way to defend yourself, but it isn't without precedent. When you can't beat someone full up face to face you have to do it another way. In this case you just poison the whole field. At first it might even make things worse, but eventually we'll arrive at a balance, just ironically with our own tools.
Or we can continue with the already totally unsafe Internet we already have. Anyone with a couple bucks and no scruples can do whatever they want on the 'net now. That isn't going to change.
The truth is we need hell-of-a-lot-better quality software for people to use and the quickest and dirtiest way to get it is quite simple. If you go online with anything less, you get instantly robbed blind. Pretty soon we'll have better quality software. The truth is that right now most people just figure they're going to be the lucky majority that don't get hit. The threat hasn't escalated to a high enough level yet.;)
Slashdot Mirror
No, I'm proposing that all the secrecy that allowed them to corrupt government officials, launder their profits, etc is what allows them to exist in the first place. Again, look deeper. When a problem persists, despite all attempts to wipe it out you have to wonder if the problem is really understood. This is the same sort of issue that creates stupid responses to other situations, like people claiming that immigrants take jobs away from US citizens when anything beyond the most simplistic analysis shows this to be complete hogwash.
Problems need to be actually studied and understood, but instead what we get is sound bite logic like this that totally misses the point and always seems to fail when applied in the real world.
Your entire argument here rests on some fairly arbitrary parsing of the number things that are secrets and how we count them. Since this is going to be a basically arbitrary kind of enumeration it can be used to prove pretty much any point you or I care to try to prove.
A legitimate argument would IMHO be something like along the lines of a cost/benefit analysis. One of the interesting things about this leak is we are getting to see exactly how much this involuntary openness actually costs. Watch and see. I predict that there will be no appreciable cost at all. The benefit of openness is quite apparent when it saves the public money.
No, I'm proposing that this whole game of playing secrets with each other is a very stupid game. You're simply not thinking about this deeply enough.
I'd also point out that all the spying in the world has utterly failed to deal with things like organized crime, etc. It hasn't solved anyone's diplomatic or political issues either.
What it HAS done is given people in governments all over the world the excuse and cover to hide a vast array of crimes which dwarfs anything like organized crime in the way an elephant dwarfs a mole.
Right...
So a statement about how to reason from evidence is an assertion of fact? Actually it isn't. It is an assertion about how to reason, which is a totally different thing.
Maybe some perusal of basic texts on deductive reasoning would be useful.
You made an assertion that secrecy is required in order for X, Y, and Z things to be accomplished. Provide some evidence that this assertion is warranted.
No, I actually know no such thing. You've made a whole bunch of assertions but I actually work on the basis of evidence. I'd like to see these assertions backed up by some reasoning and some observations.
Quite frequently it is assumed that because things have been done in a certain way in the past that they can only be done that way. This sort of reasoning rarely holds up to careful examination.
Secrecy or the information hasn't been made public? There's a huge difference between the government claiming that information is classified and it is illegal to reveal it and a private organization that doesn't reveal information by choice. That information is easily subject to being made public and any court has the authority to demand it under penalty of law. It is a whole different animal.
The government and a private organization are entirely different in very important ways beyond that. The government supposedly is the mechanism by which the people exercise their sovereignty. Secrecy destroys the fundamental power of the people by hamstringing their AUTHORITY over the government. WikiLeaks has no such power. It doesn't exercise state power. It isn't out there potentially doing evil. If it DOES do evil, then it is answerable, the government really isn't in any practical sense.
You're also forgetting what WikiLeaks is doing. They haven't simply released information willy-nilly, they have gone through a rather careful process under which they have sought out the expertise of others with a great deal of experience in handling sensitive information. The government may not LIKE this and ideally there would be an even better process, but the truth of the matter is that all the accusations being made here are rather overblown. The only people likely to be hurt by these information releases are people that have been doing things they shouldn't be doing. I have no sympathy for them. Just because they have power is irrelevant.
There are a lot of legitimate debates that can be had on the subject of secrecy and its potential legitimate uses. The problem is that allowing ANY secrecy is a slippery slope. Once you let that cat out of the bag you can't easily put it back in and I personally see any good coming of it FAR outweighed by the evil. To the point where some small individual instance of good is almost insignificant by comparison to the evil.
I can certainly understand the people who may benefit from what could be legitimate instances of secrecy being dismayed by a denial of that option, but there is such a thing as greater good. Our criminal justice system regularly puts innocent people in prison, but yet we still believe it is necessary and has value. This is the same sort of equation.
Another factor is the temptation to do evil. If ones nefarious actions will CERTAINLY be outed for the world to see then most of them won't take place. Instead of clandestine nonsense we might actually have the facts of every situation clearly out in the open where they can be resolved fairly in the light of day. This will be a great good for society, one which far outweighs the small cost. In fact I think we would find that ultimately the cost is zero.
Really? Which secrecy is that?
Cause you have a lot to learn.
When the government stops using its authority to make things secret to largely cover up fraud, waste, abuse of power, and naked greed THEN we'll have a discussion about it. Until then tough shit for them. If it takes having Wikileaks and Julian Assange out there to clean it up then I say I want to see 100 or 1000 more just like them. Turn over every single rock under which any secret lurks. Secrecy is a tool of evil, pure and simple.
The problem with "everything is an object" is that there are a LOT of different ways an "object" can be laid out in memory. If the consuming program hasn't exactly the correct idea of how that works then you're SOL.
No you're not SOL. No reasonable object oriented client depends on in-memory layout, they all use properties and methods to access member data.
Yes, actually you ARE, because you have to know that you are dealing with a stream of objects of type X and write a piece of software that specifically deals with type X. The grep program will work on ANY bytestream. Furthermore on the VAST majority of them a specific invocation of grep will behave in logically the same manner. Thus I don't have to know ANY exact details of what the input I'm handling is. Thus there is a LARGE degree of decoupling. Each Unix command line program is a very flexible independent module of functionality which can be deployed with very little change (the command line parameters) and is loosely coupled with the other components of the system it is being used as part of.
Now, that can breed problems. If you have a very specific task that you need done over and over again with high confidence that the code behaves in a specific way regardless of updates and changes to the system, then you MIGHT want to compile a program to do that specific thing.
On Windows you generally have no other choice. You HAVE to write a program because the data you're processing pretty much has to be accessed via a specific procedure that won't work with any other kind of data. It will also require a lot more glue logic and etc. than a shell script would.
The power of bytestreams and small modular programs that do one thing well, plus a reasonably intelligent set of conventions for how programs represent their output in that environment is what makes Unix so great, and the OP is pointing out a pretty well-known fact, that you can create a lot of really good and highly reliable software that way.
I know in my organization Windows servers exist PURELY for legacy applications that can't be migrated.
Mine too. But, no matter how hard we try, we need more Windows servers every year. Windows is the third platform, but most new software is still deployed on it, mainly because we have a buy-over-build philosophy and most commercial software requires Windows.
Eh, it really depends on the business you are in. There is basically one application we run Windows for in our organization. If that application were to become obsolete it would probably be replaced by something that runs on Linux.
The vast majority of places that are on the Windows bandwagon on the server side got themselves locked into some proprietary technology back in the day. That may well drive Windows server upgrades and deployments for years to come, but the niche gets smaller every year. People may have literally in raw numbers more Windows every year, sure, but it is a smaller percentage of all deployed systems.
I don't know about the numbers arguments. My anecdotal experience is that Unix/Linux systems just run reliably pretty much forever and it is easy to run a lot of stuff on one box.
I've never had a problem running a lot of stuff on Windows and maybe one in a hundred servers crash due to software in a given year.
Yeah, not my experience. IME rolling out Windows patches to servers is a huge pain in the ass that is OFTEN associated with the server becoming inoperable for whatever obscure reason. I can think of one instance of this happening with a Kernel upgrade on a Linux server, ever.
It seems like basically we provision Linux like "we need one of this, it won't fail" and Windows like "we need 2 of this because one of them WILL fail". I guess if that sells 2x as many Windows licenses, well good for them, lol!
The problem with "everything is an object" is that there are a LOT of different ways an "object" can be laid out in memory. If the consuming program hasn't exactly the correct idea of how that works then you're SOL.
Now, that would be true of BINARY byte streams as well, but any record-oriented format can be processed by tools like grep, awk, sed, etc. They use a high enough level data abstraction that the details of exactly what the data MEANS doesn't have to be agreed between utilities for many purposes. I can grep out records in a stream that all contain a specific value I want to deal with, etc and not have to know a THING about the data except that pattern X will appear and when it does what to spit out, for which I just need to know a record delimiter. MANY utilities don't even need to know that much.
As others have said, I'd consider Linux to be 'Unix' for purposes of this discussion and it certainly is the same operating environment with the same characteristics.
Other advantages of Linux/Unix will include a highly unified namespace for instance which lets me use the same tools on almost ANY source of data and direct it to almost any sink. That simply isn't possible in the Windows environment.
I don't know about the numbers arguments. My anecdotal experience is that Unix/Linux systems just run reliably pretty much forever and it is easy to run a lot of stuff on one box.
Look at the latest numbers for planned deployments of Linux in the datacenter. Practically everyone is expanding their Linux usage and Windows server deployments have peaked and seem to be shrinking at larger organizations. I'm sure they will both be around for a LONG time to come, but it sure seems like the long term trajectory is Linux is the standard ubiquitous server OS. I know in my organization Windows servers exist PURELY for legacy applications that can't be migrated. That seems to be true for my clients as well at least for line-of-business applications.
Yeah, for some types of applications VMS was quite well suited.
I know what you mean about the VMS guys. Back in the 80's I was in a LARGE engineering group. They had a cluster of VMS machines that supported around 1000 interactive users. Getting them to do ANYTHING, like set up a file share with our OS9/68k testing platforms was a nightmare, lol.
Then again most of the users were running huge engineering simulations in FORTRAN batch jobs too, so it was wonderful for them.
Overall I'll take Unix. It may not make everything dirt simple, but it is far more likely your problem can be solved easily and quickly.
Sure, awk is a programming language. It is also a command line tool. A bit more flexible than most, but you can't really draw a line between something that is a programming language and something that is a 'built in tool'.
I really have no idea WHY their code was so large. It was all written in FORTRAN and VMS is honestly a nightmarishly complicated operating environment. A lot of it is probably related to the fact that Unix has a much simpler and more orthogonal environment. Of course this is also WHY Unix killed VMS dead long ago. Simplicity is a virtue. This is why Windows still hasn't entrenched itself forever in the server room. It lacks the simple elegance of 'everything is a byte stream' and 'small flexible programs that simply process a stream'. Those are powerful concepts upon which can be built a lot of really complex stuff in a small amount of code.
Oh, it was office politics. I was doing a decent job, but my boss was definitely the insecure type, lol.
I think they honestly just couldn't wrap their heads around the fact that I could reduce their code bloat to a few 100 lines of scripting. I didn't do it to make anyone look bad, I did it purely because it was the logical way to execute a task I was assigned.
Now, I may not be the MODEL employee in every respect, but I'm a pretty good team player. That particular team had its issues though, lol. Ah well, it was all good. Haven't really had to work for anyone since then pretty much, consulting suites me fine.
Once, about 20 years ago, I worked for a company who's line of business generated a VERY large amount of data which for legal reasons had to be carefully reduced, archived, etc. There were various clusters of VMS machines which captured data from different processes to disk, from where it was processed and shipped around. There were also some of the 'new fangled' Unix machines that needed to integrate into this process. The main trick was always constantly managing disk space. Any single disk in the place would probably have 2-10x its capacity worth of data moving on and off it in an given day. It was thus VITAL to constantly monitor disk usage in pretty much real time.
On VMS the sysops had developed a system to manage all this data which weighed in at 20-30k lines of code. This stuff generated reports, went through different drives and figured out what was going in where, compared it to data from earlier runs, created deltas, etc. It was a fairly slick system, but really all it did was iterate through directories, total up file sizes, and write stuff to a couple report files, and send an email if a disk was filling up too fast.
So one day my boss asks me to write basically the same program for the Unix cluster. I had a reputation as the guy that could figure out weird stuff. Even had played a small amount with Unix systems before. So I whipped out the printed Man pages and started reading. Now I figured I'd have to write a whole bunch of code, after all I'm duplicating an application that has like 30k lines of code in it, not gigantic but substantial. Pretty soon though I learned that every command line app in Unix could feed into the other ones with a pipe or a temp file. Pretty soon I learned that those apps produced ALL the data that I wanted and produced it in pretty much the format that I needed. All that I really had to do was glue it together properly. Pretty soon I (thank God it starts with A) I found awk, and then sed. 3 days after that I had 2 awk scripts, a shell script that ran a few things through sed, a cron job, and a few other bits. It was maybe 100 lines of code, total. It did MORE than the old app. It was easy to maintain and customize. It saved a LOT of time and money.
There's PLENTY to recommend the KISS principle in software design. Not every problem can be solved with a bit of shell coding of course, but it is always worth remembering that those tools are tried and true and can be deployed quickly and cheaply. Often they beat the pants off fancier approaches.
One other thing to remember from that project. My boss was the one that wrote the 30k LoC monstrosity. The week after I showed her the new Unix version, I got downsized out the door. People HATE it when you show them up...
My point was only that a system which is totally bogged down by disk IO is somehow not exactly optimum and that a lot of the less mainstream distros don't exactly seem to know a heck of a lot about tuning or what patches to use, which CAN be an issue. You want a desktop specific distribution from a reputable mainstream source.
People expect that some guy in his garage somewhere knows how to put together a well built OS, but that is largely a vain hope. The Linux kernel is a wonderful piece of software, but that doesn't mean you can't horribly misuse it and get bad results.
No doubt many older releases work fine too. I can't recall having this sort of problem in any version of Mandriva for instance, at least not in years. I don't think my particular system is special in that respect, I just use a reasonably high quality distro and things work!
Of course the OP could be dealing with some horrible bad specific device driver or hardware too. That can make a significant difference. I think the flaw in his thinking is generalizing this as a Linux desktop issue and not a hardware or OS specific issue that HE has.
Using Mandriva 2010.0 (or on any earlier builds for that matter). Not sure if their stock kernel is using scheduling patches or not but the only time I've ever seen slowdowns on my wimpy P4 machine is with really serious oversubscribing to memory, which obvious will turn it into a dog. IO seems to have little to no effect however.
So maybe you just need a better desktop distribution? A newer one perhaps? Don't expect that if you slap just any old distro on a machine and call it a workstation that you get something beyond garbage. I'd expect Suse and/or Fedora to work equally well. Ubuntu is probably doing OK but I wouldn't know. Most of the smaller/less mainstream distros however are quite random, and running something like CentOS on a desktop is just asking for a crappy desktop.
to implement say a stock exchange where you have to deal with 100's of thousands of business messages a second with absolute 100% reliability and fault tolerance. Call us whatever names you like, but in this business you walk the walk and bullshit lasts 9 seconds. There really is no other tool out there that lets you build REAL line of business application systems with anything like the scalability and with anything like the efficiency of either manpower or hardware. Anyone who doesn't know that lives under a rock from my perspective.
You can certainly do a LOT of things with other tools, but there simply IS a class of applications that are in high demand for which JavaEE is the right answer.
I mean really, you gotta give those Russians a break you know. They have the Chinese to compete with!
TDD is the best approach. Write unit tests BEFORE you write the code. First of all you'll be motivated to get it done. Second of all you'll write MUCH more testable code and thus spend a lot less time on testing. In the long run you will actually get to write more fun stuff than if you didn't do it this way.
Honestly, not all testing will ever be fun, but there's really no point to writing bad broken software and untested software is invariably bad software. Honestly though whatever organization you're working in should be insisting on this kind of process anyway. First thing I do when I set up a team is get the unit testing process up and running.
This is not 'weird' at all. It's just one bot trying to fool another by making it think there is excess liquidity on one side. Oldest trick in the book. Also entirely against the rules. So it proves there are slugs out there gaming the market, but there's no question about WHAT they are doing, that's perfectly transparent.
1 million Bbl per day is a pretty absurd number. A single well producing 500k bbl per day would be pretty absurd. If there's a trillion bbl of oil down there then how come we import from the Middle East?
Wherever this article got its numbers from they are pure fantasy.
I disagree with you. There are highly paid professional malware writers. I think you don't have your facts straight. There is plenty of money being made creating slick software to run botnets, install malware, etc. Whether it is the most technically sophisticated hacks they are using or not is really irrelevant. Its about being able to produce a salable and functional product.
I certainly don't claim to be some leading expert on this subject, but I have plenty of contacts with Eastern European and Asian contractors and I'm telling you they can make very good money in that business. If you think different I suspect you're just not really well informed on the subject.
Well, then answer this question. Why are a whole lot of people making big bucks hocking malware? They're making that money because the software they have to hock is the best there is. Now, whether or not its the most technically sophisticated product or not is irrelevant. Heck, this is Slashdot, we all can just take a gander at the market for operating systems and see that the best selling software has little to do with technical quality...
But the day you go to start selling your new wizz-bang botnet buildin' super crackin' gizmo-ware that you just spent the last 6 months putting together and 3 hours later all your potential customers have it for free. Yeah, that'll put an actual dent in those people's business. It will not solve the theft problem, but in the long run it will destroy the incentive for smart people to try to make their living selling malware (etc). That WILL do what can be done, which is to reach a kind of stasis in the arms race.
Its kind of a funny way to defend yourself, but it isn't without precedent. When you can't beat someone full up face to face you have to do it another way. In this case you just poison the whole field. At first it might even make things worse, but eventually we'll arrive at a balance, just ironically with our own tools.
Or we can continue with the already totally unsafe Internet we already have. Anyone with a couple bucks and no scruples can do whatever they want on the 'net now. That isn't going to change.
The truth is we need hell-of-a-lot-better quality software for people to use and the quickest and dirtiest way to get it is quite simple. If you go online with anything less, you get instantly robbed blind. Pretty soon we'll have better quality software. The truth is that right now most people just figure they're going to be the lucky majority that don't get hit. The threat hasn't escalated to a high enough level yet. ;)