Your fear of Java is likely more irrational than healthy. But other replies have covered the important of knowing Java as well as other languages.
Java is a step above VB in terms of having low barriers to entry, which means the market is full of people that can code in Java, but not necessarily create good software in it.
That said, if you're moving to Linux, the right answer is C. Once you know and are adept at C in a Linux environment, every other language is a small matter of syntax and semantics.
I don't think this is dramatically different from VMWare's EULA, which specifically precludes users from sharing performance analysis/comparisons of their products without their express consent. Of course, it's a bit more draconian, but it's not entirely unprecedented:
You may use the Software to conduct internal performance testing and benchmarking studies, the results of which you (and not unauthorized third parties) may publish or publicly disseminate; provided that VMware has reviewed and approved of the methodology, assumptions and other parameters of the study. Please contact VMware at benchmark@vmware.com to request such review.
Original source of the VMWare Server EULA (as an example) posted here.
And good luck getting their consent if the comparison isn't favorable...
So are you longing for the days when open source code wasn't widely usable/viable and nobody cared enough to bring lawsuits, or for a society where all code is written "for hire" and there's no disputing who owns the rights?
The legal problems don't come up until you try to "extend" someone else's work or accept contributions back into your own. Seems relatively easy to dodge these bullets.
Then again, an intentionally ambiguous license controlled by a mad-man with an agenda isn't really helping anyone out here, either...but that's a red herring in this argument.
This is pretty radical over-simplification of the situation.
The open source development model typically requires either:
a) an individual or small team to build a single-purpose utility and subsequently share it with the community (e.g., fetchmail);
b) a very compartmentalized functionality tool where pieces of significant value can be delivered by building smaller components (e.g., the gimp);
c) an individual or group with some funding source building a larger utility/application and while either sharing it or not during the development process, usually where the "partial work" is of nominal value (e.g. Linux)
Many open source projects suffer from the delusions that the world will be their free development team because they have a good idea (look at all the projects with no files uploaded on Sourceforge) or misclassify themselves in the above categories.
Open source is not a well-proven model for applications per se. You end up with either gimp-like poor UI design (compared to commercial counterparts) or a commercial organization having to co-opt development for their own, ultimately commercial, purposes (e.g., Open Office). There are very few examples that violate this, although there are a few.
Projects absolutely need management, but few fail because they're poorly managed. Most fail because they offer no immediate value to the world at large in their current form (see comment above), and still others fail because they're poor implementations or poorly architected. Yes, bigger projects require bigger and better project management, but if they're that big, they're typically funded commercially to get those resources.
Nessus has had a funded company behind it for a while now and was a well-managed product. However, funding your competitors by providing free technology and content (e.g., Nessus plug-ins) is rarely something that's understood by investors and Boards of Directors.
But I'm most intrigued by the "it's an extra password" comment...why not just add an extra password?
Create a fake telnet daemon that looks like a telnet daemon and smells like a telnet daemon, but the "shell" provided for the successful login is actually just to allow inbound SSH for 5 seconds.
No it's not as secure (due to the lack of "obscurity", assuming you by the whole security-through-obscurity argument), but it would be accessible from virtually any machine without the need for a client to do the port connects.
The whole port-knocking thing is vulnerable to traffic sniffing (as would be a telnet login), so this doesn't seem decidedly worse, while far more convenient.
Yes, there's an issue if your faux telnetd has vulnerabilities, but it's up to someone somewhere to right good code, isn't it?
It would seem that one of the biggest hurdles to Big Blue being able to successfully market Linux to its customer base is not convincing the customers, but instead, educating the "last mile" of the IBM sales force. In this case, the "last mile" is comprised of "greying" sales professionals that have, historically, made a lot of money selling OS/390, OS/400, OS/2, and AIX into enterprises.
How do you bring them up to speed so they can convince their customers that:
They know what they are talking about
Linux is the right answer (assuming, of course, that it IS the right answer), and
For this argument to make sense, Solaris and Win2K would have to be better solutions to the current problem. And in some cases, they are.
But for the most part, companies are GOING to spend more money on a solution that gives them the benefit of the software quicker and easier. Remember, no one has ever bought software for the software--they bought it for the benefits they can gain from it.
This then implies that the real business success stories in the Open Source world will actually come from companies able to deliver similar or better functionality in a package that is easy to install, easy to maintain, and provides benefits quicker than another solution. And in the cases where it is a dead heat between the ease and speed of open source solutions and closed source solutions, the winner will be the cheaper of the two. And by negating software costs, open source should win every one of these.
For those of you poised to argue the ease/speed assertion, how many contract programmers are being hired today at roughly 1.5 to 2 times the cost of hiring someone on full-time? And how many times to they end up sticking around for 2+ years? Companies hire them because it is quick and easy. End of story. --
I think people are missing the critical point.<p>
Any decision to do away with any part of the company, even if it is not consistent with the company's core business, obviously implies that the company is not only in dire straits and threatened by bankruptcy, but quite obviously, it's also a company in desperate need of executive-level consulting help from a community of techies.<p>
We also shouldn't hesitate to explore the fact that not only will this mean that Eric Raymond will be forever silenced, but that Larry Wall will likely undergo a pre-frontal lobotomy as part of the bankruptcy liquidation.<p>
Collectively, do we <i>really</i> have this little faith in Tim O'Reilly's management of the company? Can we not each examine our own bookshelves and see that O'Reilly is not only successful at acquiring customers, but selling deeper into those customers as well?<p>
Pardon me for being a late entrant to the melee, but I just don't get the reason for such concern. --
We just went through these exact discussions prior to deciding to shift our "strategic language direction" to Java from C/C++. I think we hit most of the arguments made here, as well as a few others:
We predicted (and are realizing) a considerably shorter development cycle in Java.
We anticipate that writing in a "portable" language will bring us to market MONTHS faster on multiple platforms, versus the time it would take to port our GUI/EUI components.
Performance: Do you design your applications to scream on today's hardware, or to run on today's and scream on tomorrows? We voted for the latter. (And new, high-quality JITs (referenced earlier) helped support this decision)
Is SWING a pig? Yeah, but if you design that to run only on the client, you've overcome some of your potential architectural/scalability issues with design decisions up front.
The major drawback we're finding is that ANY of the GUI-builder environments that we've worked with generate enough superfluous code (or worse yet, platform/environment-specific code!) that we've resorted to vi. As an aside, vi rocks, but it doesn't do drag-n-drop GUI development as well as it could...;-)
Slashdot Mirror
Java is a step above VB in terms of having low barriers to entry, which means the market is full of people that can code in Java, but not necessarily create good software in it.
That said, if you're moving to Linux, the right answer is C. Once you know and are adept at C in a Linux environment, every other language is a small matter of syntax and semantics.
Well, maybe not small, but you get the idea...
I don't think this is dramatically different from VMWare's EULA, which specifically precludes users from sharing performance analysis/comparisons of their products without their express consent. Of course, it's a bit more draconian, but it's not entirely unprecedented:
You may use the Software to conduct internal performance testing and benchmarking studies, the results of which you (and not unauthorized third parties) may publish or publicly disseminate; provided that VMware has reviewed and approved of the methodology, assumptions and other parameters of the study. Please contact VMware at benchmark@vmware.com to request such review.
Original source of the VMWare Server EULA (as an example) posted here.
And good luck getting their consent if the comparison isn't favorable...
So are you longing for the days when open source code wasn't widely usable/viable and nobody cared enough to bring lawsuits, or for a society where all code is written "for hire" and there's no disputing who owns the rights?
The legal problems don't come up until you try to "extend" someone else's work or accept contributions back into your own. Seems relatively easy to dodge these bullets.
Then again, an intentionally ambiguous license controlled by a mad-man with an agenda isn't really helping anyone out here, either...but that's a red herring in this argument.
This is pretty radical over-simplification of the situation.
The open source development model typically requires either:
a) an individual or small team to build a single-purpose utility and subsequently share it with the community (e.g., fetchmail);
b) a very compartmentalized functionality tool where pieces of significant value can be delivered by building smaller components (e.g., the gimp);
c) an individual or group with some funding source building a larger utility/application and while either sharing it or not during the development process, usually where the "partial work" is of nominal value (e.g. Linux)
Many open source projects suffer from the delusions that the world will be their free development team because they have a good idea (look at all the projects with no files uploaded on Sourceforge) or misclassify themselves in the above categories.
Open source is not a well-proven model for applications per se. You end up with either gimp-like poor UI design (compared to commercial counterparts) or a commercial organization having to co-opt development for their own, ultimately commercial, purposes (e.g., Open Office). There are very few examples that violate this, although there are a few.
Projects absolutely need management, but few fail because they're poorly managed. Most fail because they offer no immediate value to the world at large in their current form (see comment above), and still others fail because they're poor implementations or poorly architected. Yes, bigger projects require bigger and better project management, but if they're that big, they're typically funded commercially to get those resources.
Nessus has had a funded company behind it for a while now and was a well-managed product. However, funding your competitors by providing free technology and content (e.g., Nessus plug-ins) is rarely something that's understood by investors and Boards of Directors.
The creators of NT were way before their time
Sure, way before their time, just not way before OS/2's time, which not only did more than early NT, it did it earlier and more reliably.
But alas...
Point well taken.
But I'm most intrigued by the "it's an extra password" comment...why not just add an extra password?
Create a fake telnet daemon that looks like a telnet daemon and smells like a telnet daemon, but the "shell" provided for the successful login is actually just to allow inbound SSH for 5 seconds.
No it's not as secure (due to the lack of "obscurity", assuming you by the whole security-through-obscurity argument), but it would be accessible from virtually any machine without the need for a client to do the port connects.
The whole port-knocking thing is vulnerable to traffic sniffing (as would be a telnet login), so this doesn't seem decidedly worse, while far more convenient.
Yes, there's an issue if your faux telnetd has vulnerabilities, but it's up to someone somewhere to right good code, isn't it?
How do you bring them up to speed so they can convince their customers that:
Inquiring minds want to know!
--
But for the most part, companies are GOING to spend more money on a solution that gives them the benefit of the software quicker and easier. Remember, no one has ever bought software for the software--they bought it for the benefits they can gain from it.
This then implies that the real business success stories in the Open Source world will actually come from companies able to deliver similar or better functionality in a package that is easy to install, easy to maintain, and provides benefits quicker than another solution. And in the cases where it is a dead heat between the ease and speed of open source solutions and closed source solutions, the winner will be the cheaper of the two. And by negating software costs, open source should win every one of these.
For those of you poised to argue the ease/speed assertion, how many contract programmers are being hired today at roughly 1.5 to 2 times the cost of hiring someone on full-time? And how many times to they end up sticking around for 2+ years? Companies hire them because it is quick and easy. End of story.
--
I think people are missing the critical point.<p>
Any decision to do away with any part of the company, even if it is not consistent with the company's core business, obviously implies that the company is not only in dire straits and threatened by bankruptcy, but quite obviously, it's also a company in desperate need of executive-level consulting help from a community of techies.<p>
We also shouldn't hesitate to explore the fact that not only will this mean that Eric Raymond will be forever silenced, but that Larry Wall will likely undergo a pre-frontal lobotomy as part of the bankruptcy liquidation.<p>
Collectively, do we <i>really</i> have this little faith in Tim O'Reilly's management of the company? Can we not each examine our own bookshelves and see that O'Reilly is not only successful at acquiring customers, but selling deeper into those customers as well?<p>
Pardon me for being a late entrant to the melee, but I just don't get the reason for such concern.
--
We just went through these exact discussions prior to deciding to shift our "strategic language direction" to Java from C/C++. I think we hit most of the arguments made here, as well as a few others:
- We predicted (and are realizing) a considerably shorter development cycle in Java.
- We anticipate that writing in a "portable" language will bring us to market MONTHS faster on multiple platforms, versus the time it would take to port our GUI/EUI components.
- Performance: Do you design your applications to scream on today's hardware, or to run on today's and scream on tomorrows? We voted for the latter. (And new, high-quality JITs (referenced earlier) helped support this decision)
Is SWING a pig? Yeah, but if you design that to run only on the client, you've overcome some of your potential architectural/scalability issues with design decisions up front.The major drawback we're finding is that ANY of the GUI-builder environments that we've worked with generate enough superfluous code (or worse yet, platform/environment-specific code!) that we've resorted to vi. As an aside, vi rocks, but it doesn't do drag-n-drop GUI development as well as it could...;-)
Enough rambling, back to the Revolution!