Maybe I'm missing something, but would it be possible to fork the code, toss out Qt, rewrite to accommodate whatever would replace it, and then license it under whatever terms?
That approach (obviously) takes sagans more time than using an adaptable library license in the first place, but I imagine it would be legally permissible.
I shouldn't answer, but I will anyway... more fool me. Yes, a package of tests would be easy. But it isn't enough, and it never WILL be. Because there are always variations that the tests won't cover. On the other hand, educating oneself as to what broad categories of vulnerabilities exist, and making sure that one's server is not vulnerable (or at least minimally vulnerable) to the entire category, is a much more efficient and realistic way of going about it. Even so, having run the package, you will have security information regarding that one point in time -- NOT a security blanket for always and ever. As soon as you are finished running it, or even concurrently, some cracker somewhere could be testing his new exploit code on YOU.
If you want *easy*, I can't help you. Humans write code, and humans are prone to error. If you want the most secure server possible, you will need to learn buckets about system administration. A starting point is to use an OS that is built for security: OpenBSD comes to mind, and maybe something like SELinux, I don't know enough about it to say. Then, run only the minimum of services you need, and make sure that the software providing those services is the most secure possible. Check out Bastille, the Linux hardening system. As others have pointed out, there are simpler, easier, more secure web servers available than Apache. Apache is stable, reliable, reasonably (though not the best) performant, and HIGHLY configurable. It is the kitchen sink of web servers -- everything gets thrown into it, and it does a darn good job of it all. But having lots of options means there is a good chance that some of those options will allow you to leave your system unsecured in some way.
Use intrusion detection systems, keep your system up to date at all times (and THIS is where the BugTraq mailing list is optimally useful, as a notification method for newly discovered problems), go to insane lengths and go bald, blind, and crazy trying to keep up with it all. Because, while a black hat only has to come up with ONE new exploit, YOU have to stay on top of ALL of them.
So, easy is nice, and I'll very likely check out the suggestions others have posted. But security isn't easy on the whole, you're either uber-paranoid or too complacent. You just have to figure out where your level of complacency lies. In all truth and honesty, on my own server I make sure that I'm fully patched, and aren't using anything too obviously open for intrusion, and that's about it. But then, I don't have any massively important data on my server anyway, and as a result, I don't NEED to be uber-paranoid. So, I know where my level of complacency is and I'm not unhappy about it. At the same time, I realize that I'm not on the cutting edge of security, and I also realize that easy isn't really an option to obtain true security. What you seek will give you something that you shouldn't have, and that's a false sense of security. You need to be aware, deep down in your heart, that as long as there are people out there who care enough to spend enough time at it, nothing -- say it with me, now -- NOTHING is truly secure.
And, oh yeah, people who become well-versed with everything that comes out on BugTraq to the point where they start contributing are called security experts, and are typically very well paid for that expertise. If you want to have security to that level, that's what you have to do. And by that time you are too paranoid to ever feel secure again...;)
Um, you may want to consider that the tool is yer brain and yer hands.
Somewhat more seriously, go check out the BugTraq mailing list at securityfocus.com. You will find there just about everything you so obnoxiously demand. Also, get on the main and developer mailing lists for whatever software you use, Apache httpd, mod_perl, whatever. Third, read, read, READ!!!! Read ALL the fine manuals, how-tos, etc, etc. Read the Source, Luke.
This book (at least from the review, haven't seen it myself) will clue you in as to what CATEGORIES of exploits exist, and how to prevent them from being used against you. If you "need a detailed list of exploits" after that, if you really truly NEED a set of cookie-cutter recipes, then please do your employer a favor, and quit now.
It is possible to make lists of every KNOWN exploit. It is nearly pointless to do this, though, since for every known exploit, there are inevitably going to be unknown exploits and unknown variations. However, learning about the KINDS of exploits and preventing them is much more efficient, intelligent, and effective.
The author works for Dr. Dobb's Journal, and this is probably either a word-for-word copy of a book review in a recent copy of the magazine, or possibly got cut due to space and relevance issues.
In other words, the review bloody well should be well-written, as the author gets paid for this sort of thing on a very regular basis.
One little piece of common sense to remember, though, is that it doesn't matter that e.g. Python would only take 10 lines and is easier to read, if there is only one person at the company who knows Python, and the other 30 developers only know C/C++/Java. You can argue that Python is easy to learn, and easy to use, and I will agree with you to the ends of the earth, but that doesn't mean that a particular individual will find it easy to learn or use.
The additional factors of training expenses and/or recruiting and hiring someone who knows the language should be taken into account when evaluating the tools used on a given project. This is a basic thing in managing a project. It is only my personal opinion that sending all 30 developers out to learn Python is the obviously correct solution, that will save the PHBs (and developers) time, money and frustration in the long run.;)
Re:Programming for the Java Virtual Machine
on
The Future of Java?
·
· Score: 1
Well, you certainly seem like the person to ask, then, so I will: is there a cross-platform VM out there that IS really good? Would it be possible to build one? For that matter, would it be worth the effort?
IMHO, the Java language is okay, but clunky. The libraries kick butt, but the real prizes are the JVM platform, and the coherency of direction provided by the JCP and the corporate buy-in to the JCP. I'd like to see the good parts of this available to the rest of the world. I'd like to see a great target VM available that is multi-platform. I'd like to see lots of easy-to-use, comprehensive libraries available for the VM, and those libraries should be callable from whatever language I write in, so long as the VM can handle it. I'd like to see industry buy-in and cooperation on defining the direction of the platform.
From what I can tell from your post, you have intimate knowledge of the JVM and at least passing knowledge of the CLI, enough to compare. Can you tell us where to look for a really great VM? Or at least, can you point us in the right direction for specs on what that VM should be able to do?
Honestly, my background is not computer science, and I suspect that this topic is something that gets taught at the grad-school level, but maybe it wouldn't hurt to get a little publicity on the topic and get others with better backgrounds thinking about it.
All very valid points. I apologize for and retract the "irrelevant" comment. Or, perhaps I should stand by it, but modify it to say that any such performance argument is irrelevant, due to the relative closeness in processing time between Java and Python.
Personally, I care most about total development time and making programming fun. Each of Java and Python excel in these areas, but in different (and complimentary) ways.
I must admit, that's the major reason I prefer programming in Python to Java -- it is more fun, and takes less time. On the other hand, I often become frustrated by the general lack of maturity, the redundancy, and the lack of coherence evidenced by the libraries, toolkits and projects available for Python. All of which are NOT problems in Java.
As far as the original story goes, I have no argument with that one way or the other -- the JVM is a very handy tool, it can indeed be used by multiple languages, and that is a competitive advantage. I'm not, however, at all sure that it really means that much. I think it is highly useful to see a given VM with wide-spread adoption throughout the world of computing be used as a target VM for multiple languages. I just don't see it as a competitive feature of Java, as such. A competitive feature of the JVM over the CLR, definitely. But then, Sun hasn't visibly realized that the JVM is, or should be, more important than the Java language. The language, by itself, is just a language -- a slightly awkward, but generally easy to use programming language with a lot of libraries, tools, and corporate uptake. On the other hand, the JVM is a *platform*; the JCP is an industry process for deciding how the parts of the platform should run. And thus, the JVM and JCP are potentially of MUCH greater value than the language. That fact is why we should all be cheering Motz' decision to force MS to bundle the JRE. And I think all of us who appreciate Java and the JVM are just reiterating that.
As for my comparison, it was something I did for fun. I agree completely, the Jakarta project is very much better coordinated, and for the most part there is not so much redundancy. However, I would point (nitpick alert!:) out that Struts uses (or can use) Velocity as a component -- the redundancy, in my understanding, is between Turbine and Avalon, both of which are web app frameworks/toolkits that address more-or-less the same space as J2EE. And while your point is well-taken, the same can be said for various Python projects, so long as one remains within the project. Webware, for example, has subprojects that address user management (UserKit), database connectivity (MiddleKit), presentation (PSP), and general web-logic (WebKit). Zope has lots of Products that address many of the different areas. Some of them are redundant, many of them are upgrades or modifications of earlier Products. And, as soon as we go outside of the Jakarta project in the world of Java, we see similar problems -- how many times have we heard massive complaints regarding how hard it is to make a web app built for WebLogic work in WebSphere? The difference, though, is the JCP, which *greatly* improves the world of Java by (in this case) realizing there is a problem and addressing it by starting up a specification for web-app deployment. But the overall maturity, coherence and sense of united vision demonstrated by this is decidedly lacking from the Python world, and that problem frustrates me a great deal. I don't know what to do about it, if anything.
On the other hand, the comparison itself is, I hope, useful if for no other reason than to show that Python at least has a darn good start in addressing the areas of concern, and often has projects that can easily compete on both features and quality of code.
In the end, though, I bow to your conclusions. The Java community is indeed better integrated and does dwarf, in this case, Python's. And yes, the previous poster was indeed pulling his points out of thin air. But, I suppose, I have a question for all and sundry: Java has a great advantage in its JVM and with the JCP (all Sun/Apache politics aside). How can we achieve such integration of community in other languages? Does anyone have any ideas?
According to Bagley's site, we should all be using Ocaml anyway. Who knows, he may even be right...
In reference to the Bagley test, Java was more performant than Python, true. But Python won over Java on both memory and lines of code. Also, his tests, as all artificial benchmarks, are both accurate only for the point-in-time and are only accurate within the limits of the test conditions themselves. More recent versions of both Java and Python are faster. On top of that, special-purpose optimizations exist for both Java and Python if you really need that extra spurt of speed -- think Jikes or TowerJ for Java and Psyco for Python. More to the point, though, Java may be faster than Python, but it isn't faster by an order of magnitude. The difference in speed between them is not enough to worry about -- if you really need that much speed, you won't be programming in either Java *or* Python, you'll be coding in C and assembler. Your performance argument is irrelevant.
Your libraries argument is somewhat more compelling. However, you may not be aware that there are two major versions of Python, standard Python implemented in C and Jython, implemented in Java. Using Jython, you can write Python that has full access to all of Java's libraries.
On top of that, I'll make a very rough comparison between the various projects on Jakarta and extant Python libraries. I don't think I've seen anything like this, as Python has a poor record for collating their libraries and apps in one place, so the effort is worth it simply for educational purposes, if nothing else.
Disclaimer: I am not terribly familiar with most of these projects, and they have varying states of completeness and maturity. I merely aim to show that analogs of the various Jakarta projects do exist in the Python world. Please feel free to peruse them yourself and come to your own conclusions.
Alexandria -- I don't know of any comparable Python applications. However, the individual components of Alexandria (doc generation, CVS access, etc.) are available: check out HappyDoc , and various modules for use with the Zope application server, including CVSFile
Okay, now I'm going to lump together a bunch of Jakarta projects. Individual authors and users of these projects will inevitably scream, but my justification is that they are all web application servers of one sort or another. Their purposes are all the same. They have many differences in approach, philosophy, scope, and implementation, but at heart, they are all web application servers or web application server frameworks. Those projects are: Avalon, Jetspeed, Struts, Turbine, Velocity, Slide, and Tomcat itself. Oh, and I might as well throw James in here, too. Python web app servers and frameworks are equally numerous, and several are in advanced stages of maturity: again Zope, Twisted, Webware, Quixote, CherryPy, and SkunkWeb. There are more, but I'll leave that as an exercise for the reader. Google is your friend.
Lucene has no real counterpart in Python. David Mertz has put together a text indexer and search program, available at his site, but it looks small compared to Lucene. There is also something called WePaSe, but there is no information on it aside from its freshmeat release announcement.
Gump also has no counterpart. Cactus has an equivalent in WebUnit and PyUnit. Log4J's Python copy is called, naturally, Log4Py.
ORO and Regexp provide regular expressions for Java. Python has regular expressions built in to the standard library.
OJB provides an object-relational bridge for Java, similar in concept to Sun's JDO specification. Python counterparts are Modeling , PyDO, which is a subproject of the above-mentioned SkunkWeb, and MiddleKit, a subproject of WebWare.
ECS, JMeter, and POI have no Python counterparts. BSF also has no counterpart, since it embeds a scripting language in compiled Java. Perhaps its "counterpart" is Jython. Likewise, BCEL has no counterpart, nor does Watchdog.
Taglibs has no direct counterpart. Instead, Python has Spyce, Cheetah, PSP, and probably close to a dozen other implementations of the ASP/JSP theme, each with their own library of tags. Lack of a standard is perhaps not a good thing, but the existence of bunches of competing implementations is not a bad thing. Perhaps the most direct counterpart would be Zope's built-in technologies, DTML and ZPT. ZPT has also been built out into a standalone version, SimpleTAL.
Jakarta Commons has too many small projects for me to want to research Python equivalents. If you are looking for something in particular, check the Vaults of Parnassus first.
As for Apache XML, Python has SOAPy and ZSI implementing SOAP, and DOM, SAX, and XML-RPC are built in to the standard library. 4Suite implements DOM, SAX, RDF, XSLT, XInclude, XPointer, XLink and XPath, and has an XML and RDF data repository and server built on top, which would make it very roughly equivalent to both Cocoon and Xindice. I don't know of any Python equivalents for Batik, FOP or XMLSecurity.
Python has relational database access through its DBAPI standard, with adaptors for just about every database. There are a number of object databases coded specifically for (and often in) Python, the most well known being ZODB, which was developed by Zope. There are adaptors for other object databases as well.
There are really two spaces where Java outstrips Python, and the second space is IMHO directly caused by the first: standardization, and J2EE. Python puts out a language implementation and a lot of very useful libraries, but does not have any standardization body like the JCP. The result is lots of fragmentation. Individual developers write their own libraries and applications that compete with each other while offering wildly differing APIs and programming approaches. There has been some push to organize, through the official Python SIGs, but their efforts, while noble, have not been massively effective. Only this month has an initial implementation of a Python library repository similar to CPAN been released. Kudos to Andrew Kuchling, who made it happen, but it is LONG overdue.
Regarding J2EE, the only viable competitor is Zope. Even then, Zope really doesn't address the same problem space. The shortfall here comes from a number of different factors: corporate buy-in, public perception, lack of an established problem-space solution, and lack of published standards. Zope is a great solution, and has been used by a number of high-profile companies, but its focus is different.
Well, I hope you find this comparison to be useful. *I* certainly found it enlightening.
Err, no. Or, not really. Or maybe, just not quite. You see, on one level, CSS is used to separate presentation from HTML, leaving structure & semantic meaning only in the HTML code. Struts is used to enforce separation of business logic from presentation logic. So, at a really REALLY high level, they do similar things. But the analogy dissolves as soon as you get to even 50000'.
With Perl/CGI + (X)HTML + CSS, you very likely are coding in a procedural style (feel free to correct me if I'm wrong -- or, just don't take it personally, let me explain the idea) in your CGI script. With Struts + (Tomcat or other servlet container) + JSP + HTML + CSS, well, things get more complicated -- yet easier to code and maintain.
With just Tomcat + JSP, you can code up a servlet, the Java equivalent of/successor to a CGI script, and that one servlet will handle all input, all business logic, and all output. But this style of coding is generally considered bad, because it is much more complex than it should be -- it hinders maintenance, updates, performance, clarity, etc. Java, being object-oriented, allows the programmer to separate business logic from web app control flow from presentation. However, it doesn't enforce it. And that separation is not necessarily easy, it requires discipline and creates more work if the coder starts from scratch. Which is where Struts comes in to play. Struts is a framework of Java code that works with Tomcat (or other servlet container), that enforces separation of business logic from control from presentation, and provides lots and lots of goodies that make it much much easier to code the application.
So, if you have an application that isn't throw-away, one that will need to be maintained and possibly changed later, Struts makes building the application easier because it keeps unrelated parts from bumping into each other, and has lots of pre-fabbed goodies.
That is, what about their own internal servers? What about the rest of the servers they host? Do they not have ANY of them that are syncing up to an NTP source somewhere?
Try asking the ISP if they have an internal NTP server you could sync against, one that itself is properly synced to a reliable source. If you don't want to/can't switch ISPs, this alternative may be (somewhat) practical -- it depends on how much you trust your ISP to have their NTP server set up properly...
Your choice of CPU configuration should depend on your estimated workload. If you are going to be running a database that will support many simultaneous connections, each of which performs only a short transaction, then the 4-way configuration would seem to be more appropriate. On the other hand, if you have an app where you will have relatively few connections, but each task is both computationally expensive and not particularly able to be spread over multiple threads, the higher-powered dually-CPU config looks more tempting.
The best option, to my eye, is the one others have suggested: get a 4-way chassis with only 2 CPUs, and pay more licensing if you find yourself really needing it. And, realistically, if you find yourself needing more iron in the future, it will be cheaper to throw 2 more CPUs into an existing box and pay the additional licensing fees than it would be to buy another computer.
I have a couple of other options for you to consider, though I realize before I say it that the decision has already been made and that I'm sure there are dozens of reasons not to, but you still might want to consider them:
Run Linux and PostgreSQL -- the REALLY low-cost option
Run Linux and DB2 -- you are buying IBM hardware, why not check out their database offering as well?
Now I'm sure that your developers don't know Linux, PostgreSQL, or DB2, and the decision has already been made, etc. ad nauseam, but I figured I'd go ahead and toss these possibilities out for the sake of argument.
One difference between you, dschuetz, and the original poster is the quality of your writing. Simply put, and no offense intended to the original poster, your writing is better than his. If (please note the conditional) writing styles can be used as indicators of overall communication skills, then I am tempted to suggest that the original poster was not able to articulate to his boss his concerns in a way that would not cause offense.
On the other hand, I also think the original poster made a mountain out of a molehill. As others have stated, corporate email is an entirely corporate-owned resource. In addition, the request to withdraw occurred before receipt, not after. So the intended recipient does not own the message, the corporation does. And if the CEO decides that the company's interests are best served by deleting that email prior to receipt, then that is indeed what the original poster should have done.
On top of that, what right, legal or moral, does the intended recipient have to an email message that has not even been received? I just don't even comprehend the moral issue, for which I apologize to the original poster.
On the face of it, the CEO intended to send the email, and then changed his intention prior to receipt. The original poster had the power to enable the overriding intention, but refused, while his immediate superior acceded to the request.
I think that no moral imperative to deliver a piece of email exists. I just don't see that there is some moral good attached to delivering mail, e- or snail-. I see a lot of utility inherent in communication, but no moral requirement for communication in general. I think that some moral good may be facilitated or hindered by communication, but now we are speaking in terms of particular instances, rather than in general terms. So, we must evaluate this particular instance.
In this particular case, the original poster has not specified that there was something in the email message that would have caused or facilitated something morally good. In fact, he specified that the email message was a hasty flame that the CEO, on further reflection, decided to withdraw -- in other words, the message would have hurt the recipient, without justification, thus being a moral wrong.
So, with no a priori moral reason to deliver email, and with the particular message's contents being morally wrong, I conclude that the original poster was, in fact, morally wrong to have refused to delete the email.
Please forgive the descent into philosophy, but that is my background, and I couldn't resist the temptation...
Much more to the point, Red Hat 7.3 has 1.5.2 as "python", but has 2.1 (IIRC) as "python2". And Red Hat 8 has 2.2.1 as its "python". And, as you said, it is eminently possible to download and compile the latest version, though you do have to be careful that you link in 2.2.x as "python2" rather than "python" on Red Hat 7.3, or many of the system apps break (up2date comes to mind...).
Okay, I am not familiar with the SourceCast product from CollabNet, so I can't speak to its features, and I'm talking out of my wazoo. However. Every piece of software on www.tigris.org is open source, most using the Apache license. And, while I'm sure that CollabNet is doing something really interesting to add value to the packaged-up whole that is SourceCast, I'd be willing to bet that what they are doing isn't THAT much more than building an integrated package. If anyone out there has more info, please chime in, but my bet is that SourceCast is an extremely cleanly-integrated packaging of www.tigris.org components such as Subversion, Scarab, Anzu, Eyebrowse, etc. And, frankly, those individual components look very useful in their own right. So, maybe your first project might be to find individual components that meet some of your requirements, and integrate them yourself.
To the original poster: I don't know if it could be adapted for your purposes, but you may well want to check out Forrest, at xml.apache.org. I have been examining it for my own use, and it looks like it might make a very interesting part of a distributed development framework.
Let me reformulate your question a bit. You wrote:
As an author take a template and fill in the bits of information to create an html page. Then have that data propagated to a similar template for a pdf, word doc, etc.
What you really want is not a template, fill in the bits to make an html page. What you really want is to do the exact same thing, but substitute XML for HTML. Once you are using a dialect of XML as your source, you can use XSL to transform the source into other formats, including HTML, PDF, and RTF. Take a look at the Apache XML project for technologies that will help you. Apache FOP will generate PDF for you, and Cocoon will give you a framework in which to do all this XML manipulation. You can use Xindice as your XML data store. But buy a couple of really good books on XML before you start...
Except that the GPUL is not the next best thing. If you read the eWeek article, you'll find that the projected time-line reads, basically, the G5 first and then the next best thing after that. And it is very much up in the air what that next best thing will be. I know that Apple has had a long history of working with IBM and Motorola, and that adds a certain amount of probability to the conjecture that the GPUL will be the next best thing, but the existence of Apple's Marklar project shows that we cannot discount the possibility of a switch to x86 architecture. I think the most likely candidate within the x86 world is AMD's Hammer -- it will be available at desktop-processor-level prices, and will also be available in versions more suitable for servers. Since both markets are areas Apple has targeted, this makes the Hammer more appropriate than, say, a combination of Intel's Pentium4 on desktop and Itanium for servers.
Again, though, let me reiterate that this is all just conjecture until "The Steve" makes some sort of formal announcement.
If your company is of any size whatsoever, you'll need more than just a lawyer who specializes in HIPAA compliance issues. You'll need to acquire the services of a HIPAA compliance and remediation consulting group. Our hospital is using Ernst & Young.
It sounds like you have multiple areas to look at -- your data storage, your data transmission (you aren't just creating those medical records from thin air, are you?), your partner companies, and how you handle the Patient Identifying Health Information on the desktop. Not to mention that your company should have been preparing for this for QUITE some time now.
First, you'll need to make sure that your data storage, transmission and handling (includes handing paper copies around), and desktop security are all compliant. Next you'll find that you are also responsible for making sure that any business partner companies are compliant. This task basically means getting your partner companies to sign "HIPAA Business Partner Agreement" contracts that means the partner company states that they are contractually obligated to handle any patient data of yours in a means that is also HIPAA compliant.
Finally, and most important of all, you'll need to be able to document all of the above, in a form that the government inspectors can easily use to check your compliance. Yay.
Get yer HIPAA-lovin' lawyers on the stick as fast as you can, and file for any extensions that may apply. You will need a complete inventory of any and all computing infrastructure (servers, workstations, network, and software) that touches identifying patient medical data. You will need to have this inventory so your CIO, lawyers, computer security experts and your HIPAA remediation consultants can check the compliance of everything on the list. Anything failing compliance, you'll need to fix or replace.
One last thing: you are also responsible for making sure that the source of your medical data is asking permission to use that medical data, and is asking that permission in a way that is compliant.
I hope this provides you with a decent starting point. Good luck, you have a hard task ahead of you.
There were a couple of points in the article and in some other posts that I feel a need to address.
Customization v. Standardization
One poster mentioned that he completely customized his Linux box so that "no one else could use it". And someone else replied, "You won't be able to use anyone else's computer". There's an interesting point to be noticed in this exchange: UI efficiency is the driving force behind both of these viewpoints. For the first poster, s/he probably only works on one computer, or one of a small set of similarly-configure computers. As a result, the poster can massively customize the UI to make it as efficient as possible. The second poster, on the other hand, probably works with multiple computers that can either have different UI configurations, or all must be configured for the "standard" interface in order to support as many "average" users as possible.
Personal Productivity
There are a couple of entirely different problems inherent in these two scenarios, and I don't begin to know how to solve them. For the first poster, s/he has found enormous gains in productivity through customization, but might well see a re-training learning curve when moving to someone else's computer. This problem might be solved by putting together a means of carrying around one's personal UI environment configuration -- something like a microdrive with all of one's preferences and customizations stored in it. The problem with this solution is that we cannot guarantee enough underlying environment similarity (choice of OS, apps, hardware) to make this scenario practical in the world-at-large. Within a standardized business environment ("Everyone shall have a Dell!"), this might be possible and even desirable, from the user's perspective.
Corporate Standardization But then comes the perspective of the second poster: in a business environment, there are a couple of competing forces, the need to standardize platforms as much as possible in order to reduce support costs, and thus TCO, and the equally important need to maximize productivity of, ideally, each individual employee. Standard platforms allow the company to hire support personnel who can specialize in the standard platform, and do not need to have knowledge of many different platforms -- depth over breadth. These support personnel are more efficient, and thus the company can hire fewer of them. Hardware standards allow for greater reusability of spare parts, and OS and software standards guarantee compatibility of data throughout the institution and beyond. OS and application standards also mean the ability to consolidate training, and increase the likelihood of finding personnel who are already familiar with the use of the computer platform. In addition, if the institution chooses to standardize on a platform that has a low learning curve, and is thus quick to pick up for newcomers, training time can be reduced and costs lowered. If the hardware is ubiquitous and more-or-less commoditized, and thus interchangeable, and the OS and apps interoperate smoothly with each other, then an easy-to-learn and generally productive work environment is available to any employee who sits down in front of any computer.
Competing Imperatives
These are the typical arguments for standardization of platform within an organization, and one of the main factors that contributes to Microsoft's monopoly. These arguments point out some important things for us all to think about. We need to maximize a few different, competing areas: the OS and apps bundle needs to interoperate well, both internally and with the rest of the world; the whole package needs to be easy to learn for newbies; ideally there should be a well-established user-base to provide a pool of "community knowledge" to allow users to help each other ("Hey, Jane, how do I go about sending an email on the company's systems?" "Simple, George, just run this...") and to provide a reasonably large pool of pre-trained support personnel; the platform needs to provide a reasonable level of productivity throughout the company.
I'd like to elaborate that last point a bit. As much extra efficiency as the first poster may gain from a completely customized UI environment, s/he will find it hard to use all the rest of the computers in the company, and no one else will be able to use the customized computer, and no one will be able to support it. Now, if the company is small, or is built around the genius of a few individuals, then a comfortable work environment that caters to these individuals may well be cost-effective in order to maintain their productiviy. On the other hand, if that poster works for a company with a lot of employees, then customization isn't cost-effective at all. The individual's productivity gains are completely washed away by the extra expense of handling and supporting those customizations.
Article Points
The article makes a few basic points: Linux on the desktop isn't easy enough; Linux doesn't have the same software available; Linux desktops basically copy existing Windows and/or Mac desktops -- and don't do it well; uneducated Linux adopters don't want a copy of Windows, they want something radically new; and the standard WIMP interface is boring and no fun.
Ease of Use
Okay, this one's easy: yes, Linux isn't easy enough. We need to keep working on this one. No points for originality here. One poster mentioned that the reason things aren't easier is because it is hard. Well, that makes sense.
Available Software
I think we all realize that the brand name on a software package is less important than its functionality. In areas like word processing, as long as the document format is completely interchangeable (no small feat with closed and ever-changing formats), and the feature-set is complete, then we can easily substitute one word processor for another.
But this assumes that the skills necessary to use a given type of software are extremely common. By this I mean that, in the case of word processing, the necessary skill (language use) is external to the program. Efficiency of use comes from the skill of typing -- and this skill, again, is not inherently related to the software. In other words, typing is useful for WAY more stuff than just word processing. In contrast, good graphics designers (for example -- though I am not a designer, and my ignorance may well show) specialize in a particular package within a few related software types. That is to say, the ability of a particular application to specialize in one area of competency leads to greater fitness for a particular type of task. Thus you have Adobe Illustrator competing against Macromedia Freehand, or Photoshop competing against, um, well, nothing I know. Illustrator and Freehand are, very specifically, vector-based drawing and illustration tools. Photoshop is very specifically designed for manipulating raster images. They do different things, and don't compete directly. Now, slightly less specialized programs do exist, such as Canvas or CorelDraw. They are designed as "all-in-one" programs that handle both vector graphics and raster images. But the designers I know generally display a certain amount of contempt for these packages, as they don't measure up. It takes a great deal of skill (and thus training time) to become especially good at using Photoshop to its fullest extent. That time spent acquiring that skill is valuable. As a result, it will be very hard for Linux to do anything other than copy Photoshop, if we desire to take that market. And I don't think that anyone in their right mind would even suggest that such a thing is possible -- people who invest time in acquiring a given skill are justly wroth with those who suggest they acquire a new, different skill, thus implying that the original skill isn't worth much. The conclusion being that the Linux world would have to demonstrate conclusively that our software is greatly better than existing commercial alternatives, in very concrete ways. Shaking the carrot of intellectual freedom won't help -- most people have a hard time understanding the concept. In short, it isn't better because it's free-as-in-speech, and it is only *slightly* better because it is free-as-in-beer.
Copying Existing UIs Okay, Krul's point that Linux desktops don't do a good job of copying the functionality of existing UIs is valid, but again isn't new. However, I think that there isn't much that can be done about it until someone comes up with a radically different means of interacting with computers. I hate to break it to the poster who mentioned voice recognition, but it really isn't going to be terribly efficient even AFTER the technology is perfected. From a business perspective, voice recognition is unusable. Can you imagine a cubicle farm full of people yakking at their PCs all day? Utter insanity! And virtual reality in its current incarnation is equally futile. Imagine someone wearing a headset and a glove or two. Now imagine how hard it will be for that person to switch back and forth between interacting with the computer and interacting with the rest of the world -- how do you talk to a coworker? How do you pick up a business card, or a report? And for those of you who reply that the office can be paperless, and all communication can be done using email/telephony, I laugh at you. Loudly. I see some definitely useful applications of VR technology, and I'd be very surprised if VR weren't in use in several different areas already, but it will not take over as the standard means of human-computer interaction until the interface is drastically improved.
Frankly, I see the most added utility in terms of VR (and, really, computers as a whole) as a means of adding information in the context of the real world. That is, VR only becomes useful to the masses when it doesn't interfere with day-to-day reality, and adds something useful in the bargain. Basically, we're talking science fiction: brain implants that interact wirelessly with the completely ubiquitous world-wide computer network, and provide an informative and appropriately (contextually) filtered overlay or addition to the physical world, as well as extending human interaction, communication, and control. Cool stuff, and we're already seeing the beginnings of this sort of technology in the research into computer control through central nervous system activity, as well as the ongoing efforts at repairing blindness with an artifical imaging device connected directly to patients' optic nerves. Again, neat but not near-term.
Boring Old WIMP v. "Pleasure"
Um, yeah, I suppose I agree that WIMP isn't much fun. Frankly, I'd make the assertion that CLI isn't much fun either (ducks the flames). Instead, I'd assert that what makes the command line more fun than windows and a mouse is the control, the efficiency, the efficacy of typing in a command. When you type in a command, don't you get a thrill from seeing your precisely-formulated desires responded to by the computer? In fact, I quickly lose interest in CLI when whatever process doesn't provide immediate feedback, e.g., formatting a hard drive. BOOOORRRING... And I become very quickly frustrated, whether in GUI or CLI, when my desires are thwarted. However, the precision, control, and more tangible feeling of accomplishment I receive from CLI makes it more fun. And yes, WIMP takes that away. But I don't know what else we could use that would give us as much control. Anyone have any ideas?
Have everyone bring over their laptop, set up a small LAN, and have at it. You get real-time discussion without interfering gadgetry, all the benefits of getting together (swapping tales, an excuse to eat large quantities of junk food, etc.), AND you have a nice game engine for dealing with all the rules and putting up pretty pictures of whatever you're doing.
What's not to like? Er, aside from BO, tall tales, bad food, off-topic/out-of-character chatting, coordination of times, and a lack of physical space (for people with small apartments). All in all, just play the way you want to...
The basis of a valid electronic signature is a combination of policy and code. As per Schneier's article and the E-Sig Act, deniability is the key factor. If you can provide the technology necessary to keep the means of signing secure, and can put in place a set of policies for which you have agreement on record, then you have a legally binding electronic signature.
The exact means you use to implement the technology, whether it be digital certificates or simple password authentication, is nearly irrelevant. Okay, you want to make it as secure as possible, and local regulations and/or your contracting partners may dictate your means. But aside from that, all you have to do is make sure that you have taken reasonable precautions to ensure that the signature corresponds to the person, and that intent to sign is implied in the signature. The first half is done through authentication of some sort. The second half is embodied in your company's documented policy.
For the policy, make sure that your company holds training sessions for all current and new employees who will use the system. Let them know that security of their job depends on the security of their passwords. If possible, get them to sign a form that spells out the policy, the usage, the consequences of misuse, and that they acknowledge that by using the system, the employee consents to be bound by the signature. We in healthcare call this informed consent. It maintains an audit trail that disallows deniability. The interesting point, on rereading the E-Sig Act, is that the employee may signal their intention not to be bound by the electronic signature -- but this must be written. In your policy, you may specify that the employees must agree to and comply with the electronic signature as a requirement for employment. At which point, you may remind them if they wish to withdraw their consent that they may be endangering their job in so doing.
As another poster mentioned, though, get a lawyer's (or insert other domain-specific expert here) advice on the topic. And, if you expect your electronic signature to be taken as valid by other companies, you must discuss the matter with them beforehand.
Okay, all ribbing aside, as someone who programs Java for money, let me give you the skinny: Java applets bite. More specifically, they are slow to download, prone to crashing, and subject to problems due to lack of control over the Java runtime available to the browser.
Java has, instead, found its niche on the server. Server-side programming is where Java works really, really well. Development is generally faster than with C/C++, and Sun and others (go Apache!:) have provided some seriously amazing libraries/frameworks/etc. that help programmers avoid reinventing the wheel -- or the bucket seat, the 5-speed automatic transmission, or even the 10-disc CD changer.
The other benefit that Java on the server provides is that web designers don't have to monkey with the code, and programmers don't have to deal (so much) with HTML.
Needless to say, everything above is a generalization, all generalizations are false (including this one), and YMMV.
I know it's a bit of a stretch, but consider Python. Prototype the heck out of the system in Python, profile the application, then recode the bottlenecks in C. Use SWIG to generate your interfaces. Easier to program, easier to extend, easier to read/maintain. Shorter programming time, too.
You'll be happier, your fellow programmers will be happier, your successor programmers will be happier, and the chewy parts of your code will still be really fast. Think about it.
Slashdot Mirror
Maybe I'm missing something, but would it be possible to fork the code, toss out Qt, rewrite to accommodate whatever would replace it, and then license it under whatever terms?
That approach (obviously) takes sagans more time than using an adaptable library license in the first place, but I imagine it would be legally permissible.
I shouldn't answer, but I will anyway... more fool me. Yes, a package of tests would be easy. But it isn't enough, and it never WILL be. Because there are always variations that the tests won't cover. On the other hand, educating oneself as to what broad categories of vulnerabilities exist, and making sure that one's server is not vulnerable (or at least minimally vulnerable) to the entire category, is a much more efficient and realistic way of going about it. Even so, having run the package, you will have security information regarding that one point in time -- NOT a security blanket for always and ever. As soon as you are finished running it, or even concurrently, some cracker somewhere could be testing his new exploit code on YOU.
;)
If you want *easy*, I can't help you. Humans write code, and humans are prone to error. If you want the most secure server possible, you will need to learn buckets about system administration. A starting point is to use an OS that is built for security: OpenBSD comes to mind, and maybe something like SELinux, I don't know enough about it to say. Then, run only the minimum of services you need, and make sure that the software providing those services is the most secure possible. Check out Bastille, the Linux hardening system. As others have pointed out, there are simpler, easier, more secure web servers available than Apache. Apache is stable, reliable, reasonably (though not the best) performant, and HIGHLY configurable. It is the kitchen sink of web servers -- everything gets thrown into it, and it does a darn good job of it all. But having lots of options means there is a good chance that some of those options will allow you to leave your system unsecured in some way.
Use intrusion detection systems, keep your system up to date at all times (and THIS is where the BugTraq mailing list is optimally useful, as a notification method for newly discovered problems), go to insane lengths and go bald, blind, and crazy trying to keep up with it all. Because, while a black hat only has to come up with ONE new exploit, YOU have to stay on top of ALL of them.
So, easy is nice, and I'll very likely check out the suggestions others have posted. But security isn't easy on the whole, you're either uber-paranoid or too complacent. You just have to figure out where your level of complacency lies. In all truth and honesty, on my own server I make sure that I'm fully patched, and aren't using anything too obviously open for intrusion, and that's about it. But then, I don't have any massively important data on my server anyway, and as a result, I don't NEED to be uber-paranoid. So, I know where my level of complacency is and I'm not unhappy about it. At the same time, I realize that I'm not on the cutting edge of security, and I also realize that easy isn't really an option to obtain true security. What you seek will give you something that you shouldn't have, and that's a false sense of security. You need to be aware, deep down in your heart, that as long as there are people out there who care enough to spend enough time at it, nothing -- say it with me, now -- NOTHING is truly secure.
And, oh yeah, people who become well-versed with everything that comes out on BugTraq to the point where they start contributing are called security experts, and are typically very well paid for that expertise. If you want to have security to that level, that's what you have to do. And by that time you are too paranoid to ever feel secure again...
Um, you may want to consider that the tool is yer brain and yer hands.
Somewhat more seriously, go check out the BugTraq mailing list at securityfocus.com. You will find there just about everything you so obnoxiously demand. Also, get on the main and developer mailing lists for whatever software you use, Apache httpd, mod_perl, whatever. Third, read, read, READ!!!! Read ALL the fine manuals, how-tos, etc, etc. Read the Source, Luke.
This book (at least from the review, haven't seen it myself) will clue you in as to what CATEGORIES of exploits exist, and how to prevent them from being used against you. If you "need a detailed list of exploits" after that, if you really truly NEED a set of cookie-cutter recipes, then please do your employer a favor, and quit now.
It is possible to make lists of every KNOWN exploit. It is nearly pointless to do this, though, since for every known exploit, there are inevitably going to be unknown exploits and unknown variations. However, learning about the KINDS of exploits and preventing them is much more efficient, intelligent, and effective.
The author works for Dr. Dobb's Journal, and this is probably either a word-for-word copy of a book review in a recent copy of the magazine, or possibly got cut due to space and relevance issues.
In other words, the review bloody well should be well-written, as the author gets paid for this sort of thing on a very regular basis.
Um, IBM's planning on using these things in blade servers. Low power and heat generally (though not always) go hand-in-hand with blades...
One little piece of common sense to remember, though, is that it doesn't matter that e.g. Python would only take 10 lines and is easier to read, if there is only one person at the company who knows Python, and the other 30 developers only know C/C++/Java. You can argue that Python is easy to learn, and easy to use, and I will agree with you to the ends of the earth, but that doesn't mean that a particular individual will find it easy to learn or use.
;)
The additional factors of training expenses and/or recruiting and hiring someone who knows the language should be taken into account when evaluating the tools used on a given project. This is a basic thing in managing a project. It is only my personal opinion that sending all 30 developers out to learn Python is the obviously correct solution, that will save the PHBs (and developers) time, money and frustration in the long run.
In short, yes it does.
Well, you certainly seem like the person to ask, then, so I will: is there a cross-platform VM out there that IS really good? Would it be possible to build one? For that matter, would it be worth the effort?
IMHO, the Java language is okay, but clunky. The libraries kick butt, but the real prizes are the JVM platform, and the coherency of direction provided by the JCP and the corporate buy-in to the JCP. I'd like to see the good parts of this available to the rest of the world. I'd like to see a great target VM available that is multi-platform. I'd like to see lots of easy-to-use, comprehensive libraries available for the VM, and those libraries should be callable from whatever language I write in, so long as the VM can handle it. I'd like to see industry buy-in and cooperation on defining the direction of the platform.
From what I can tell from your post, you have intimate knowledge of the JVM and at least passing knowledge of the CLI, enough to compare. Can you tell us where to look for a really great VM? Or at least, can you point us in the right direction for specs on what that VM should be able to do?
Honestly, my background is not computer science, and I suspect that this topic is something that gets taught at the grad-school level, but maybe it wouldn't hurt to get a little publicity on the topic and get others with better backgrounds thinking about it.
I must admit, that's the major reason I prefer programming in Python to Java -- it is more fun, and takes less time. On the other hand, I often become frustrated by the general lack of maturity, the redundancy, and the lack of coherence evidenced by the libraries, toolkits and projects available for Python. All of which are NOT problems in Java.
As far as the original story goes, I have no argument with that one way or the other -- the JVM is a very handy tool, it can indeed be used by multiple languages, and that is a competitive advantage. I'm not, however, at all sure that it really means that much. I think it is highly useful to see a given VM with wide-spread adoption throughout the world of computing be used as a target VM for multiple languages. I just don't see it as a competitive feature of Java, as such. A competitive feature of the JVM over the CLR, definitely. But then, Sun hasn't visibly realized that the JVM is, or should be, more important than the Java language. The language, by itself, is just a language -- a slightly awkward, but generally easy to use programming language with a lot of libraries, tools, and corporate uptake. On the other hand, the JVM is a *platform*; the JCP is an industry process for deciding how the parts of the platform should run. And thus, the JVM and JCP are potentially of MUCH greater value than the language. That fact is why we should all be cheering Motz' decision to force MS to bundle the JRE. And I think all of us who appreciate Java and the JVM are just reiterating that.
As for my comparison, it was something I did for fun. I agree completely, the Jakarta project is very much better coordinated, and for the most part there is not so much redundancy. However, I would point (nitpick alert!
On the other hand, the comparison itself is, I hope, useful if for no other reason than to show that Python at least has a darn good start in addressing the areas of concern, and often has projects that can easily compete on both features and quality of code.
In the end, though, I bow to your conclusions. The Java community is indeed better integrated and does dwarf, in this case, Python's. And yes, the previous poster was indeed pulling his points out of thin air. But, I suppose, I have a question for all and sundry: Java has a great advantage in its JVM and with the JCP (all Sun/Apache politics aside). How can we achieve such integration of community in other languages? Does anyone have any ideas?
Heh, hehe, okay.
According to Bagley's site, we should all be using Ocaml anyway. Who knows, he may even be right...
In reference to the Bagley test, Java was more performant than Python, true. But Python won over Java on both memory and lines of code. Also, his tests, as all artificial benchmarks, are both accurate only for the point-in-time and are only accurate within the limits of the test conditions themselves. More recent versions of both Java and Python are faster. On top of that, special-purpose optimizations exist for both Java and Python if you really need that extra spurt of speed -- think Jikes or TowerJ for Java and Psyco for Python. More to the point, though, Java may be faster than Python, but it isn't faster by an order of magnitude. The difference in speed between them is not enough to worry about -- if you really need that much speed, you won't be programming in either Java *or* Python, you'll be coding in C and assembler. Your performance argument is irrelevant.
Your libraries argument is somewhat more compelling. However, you may not be aware that there are two major versions of Python, standard Python implemented in C and Jython, implemented in Java. Using Jython, you can write Python that has full access to all of Java's libraries.
On top of that, I'll make a very rough comparison between the various projects on Jakarta and extant Python libraries. I don't think I've seen anything like this, as Python has a poor record for collating their libraries and apps in one place, so the effort is worth it simply for educational purposes, if nothing else.
Disclaimer: I am not terribly familiar with most of these projects, and they have varying states of completeness and maturity. I merely aim to show that analogs of the various Jakarta projects do exist in the Python world. Please feel free to peruse them yourself and come to your own conclusions.
Jakarta Ant -- PyAnt , SCons
Alexandria -- I don't know of any comparable Python applications. However, the individual components of Alexandria (doc generation, CVS access, etc.) are available: check out HappyDoc , and various modules for use with the Zope application server, including CVSFile
Okay, now I'm going to lump together a bunch of Jakarta projects. Individual authors and users of these projects will inevitably scream, but my justification is that they are all web application servers of one sort or another. Their purposes are all the same. They have many differences in approach, philosophy, scope, and implementation, but at heart, they are all web application servers or web application server frameworks. Those projects are: Avalon, Jetspeed, Struts, Turbine, Velocity, Slide, and Tomcat itself. Oh, and I might as well throw James in here, too. Python web app servers and frameworks are equally numerous, and several are in advanced stages of maturity: again Zope, Twisted, Webware, Quixote, CherryPy, and SkunkWeb. There are more, but I'll leave that as an exercise for the reader. Google is your friend.
Lucene has no real counterpart in Python. David Mertz has put together a text indexer and search program, available at his site, but it looks small compared to Lucene. There is also something called WePaSe, but there is no information on it aside from its freshmeat release announcement.
Gump also has no counterpart. Cactus has an equivalent in WebUnit and PyUnit. Log4J's Python copy is called, naturally, Log4Py.
ORO and Regexp provide regular expressions for Java. Python has regular expressions built in to the standard library.
OJB provides an object-relational bridge for Java, similar in concept to Sun's JDO specification. Python counterparts are Modeling , PyDO, which is a subproject of the above-mentioned SkunkWeb, and MiddleKit, a subproject of WebWare.
ECS, JMeter, and POI have no Python counterparts. BSF also has no counterpart, since it embeds a scripting language in compiled Java. Perhaps its "counterpart" is Jython. Likewise, BCEL has no counterpart, nor does Watchdog.
Taglibs has no direct counterpart. Instead, Python has Spyce, Cheetah, PSP, and probably close to a dozen other implementations of the ASP/JSP theme, each with their own library of tags. Lack of a standard is perhaps not a good thing, but the existence of bunches of competing implementations is not a bad thing. Perhaps the most direct counterpart would be Zope's built-in technologies, DTML and ZPT. ZPT has also been built out into a standalone version, SimpleTAL.
Jakarta Commons has too many small projects for me to want to research Python equivalents. If you are looking for something in particular, check the Vaults of Parnassus first.
As for Apache XML, Python has SOAPy and ZSI implementing SOAP, and DOM, SAX, and XML-RPC are built in to the standard library. 4Suite implements DOM, SAX, RDF, XSLT, XInclude, XPointer, XLink and XPath, and has an XML and RDF data repository and server built on top, which would make it very roughly equivalent to both Cocoon and Xindice. I don't know of any Python equivalents for Batik, FOP or XMLSecurity.
Python has relational database access through its DBAPI standard, with adaptors for just about every database. There are a number of object databases coded specifically for (and often in) Python, the most well known being ZODB, which was developed by Zope. There are adaptors for other object databases as well.
There are really two spaces where Java outstrips Python, and the second space is IMHO directly caused by the first: standardization, and J2EE. Python puts out a language implementation and a lot of very useful libraries, but does not have any standardization body like the JCP. The result is lots of fragmentation. Individual developers write their own libraries and applications that compete with each other while offering wildly differing APIs and programming approaches. There has been some push to organize, through the official Python SIGs, but their efforts, while noble, have not been massively effective. Only this month has an initial implementation of a Python library repository similar to CPAN been released. Kudos to Andrew Kuchling, who made it happen, but it is LONG overdue.
Regarding J2EE, the only viable competitor is Zope. Even then, Zope really doesn't address the same problem space. The shortfall here comes from a number of different factors: corporate buy-in, public perception, lack of an established problem-space solution, and lack of published standards. Zope is a great solution, and has been used by a number of high-profile companies, but its focus is different.
Well, I hope you find this comparison to be useful. *I* certainly found it enlightening.
Err, no. Or, not really. Or maybe, just not quite. You see, on one level, CSS is used to separate presentation from HTML, leaving structure & semantic meaning only in the HTML code. Struts is used to enforce separation of business logic from presentation logic. So, at a really REALLY high level, they do similar things. But the analogy dissolves as soon as you get to even 50000'.
/successor to a CGI script, and that one servlet will handle all input, all business logic, and all output. But this style of coding is generally considered bad, because it is much more complex than it should be -- it hinders maintenance, updates, performance, clarity, etc. Java, being object-oriented, allows the programmer to separate business logic from web app control flow from presentation. However, it doesn't enforce it. And that separation is not necessarily easy, it requires discipline and creates more work if the coder starts from scratch. Which is where Struts comes in to play. Struts is a framework of Java code that works with Tomcat (or other servlet container), that enforces separation of business logic from control from presentation, and provides lots and lots of goodies that make it much much easier to code the application.
With Perl/CGI + (X)HTML + CSS, you very likely are coding in a procedural style (feel free to correct me if I'm wrong -- or, just don't take it personally, let me explain the idea) in your CGI script. With Struts + (Tomcat or other servlet container) + JSP + HTML + CSS, well, things get more complicated -- yet easier to code and maintain.
With just Tomcat + JSP, you can code up a servlet, the Java equivalent of
So, if you have an application that isn't throw-away, one that will need to be maintained and possibly changed later, Struts makes building the application easier because it keeps unrelated parts from bumping into each other, and has lots of pre-fabbed goodies.
That is, what about their own internal servers? What about the rest of the servers they host? Do they not have ANY of them that are syncing up to an NTP source somewhere?
/can't switch ISPs, this alternative may be (somewhat) practical -- it depends on how much you trust your ISP to have their NTP server set up properly...
Try asking the ISP if they have an internal NTP server you could sync against, one that itself is properly synced to a reliable source. If you don't want to
Read: games...
The best option, to my eye, is the one others have suggested: get a 4-way chassis with only 2 CPUs, and pay more licensing if you find yourself really needing it. And, realistically, if you find yourself needing more iron in the future, it will be cheaper to throw 2 more CPUs into an existing box and pay the additional licensing fees than it would be to buy another computer.
I have a couple of other options for you to consider, though I realize before I say it that the decision has already been made and that I'm sure there are dozens of reasons not to, but you still might want to consider them:
Now I'm sure that your developers don't know Linux, PostgreSQL, or DB2, and the decision has already been made, etc. ad nauseam, but I figured I'd go ahead and toss these possibilities out for the sake of argument.
Either way, good luck!
One difference between you, dschuetz, and the original poster is the quality of your writing. Simply put, and no offense intended to the original poster, your writing is better than his. If (please note the conditional) writing styles can be used as indicators of overall communication skills, then I am tempted to suggest that the original poster was not able to articulate to his boss his concerns in a way that would not cause offense.
On the other hand, I also think the original poster made a mountain out of a molehill. As others have stated, corporate email is an entirely corporate-owned resource. In addition, the request to withdraw occurred before receipt, not after. So the intended recipient does not own the message, the corporation does. And if the CEO decides that the company's interests are best served by deleting that email prior to receipt, then that is indeed what the original poster should have done.
On top of that, what right, legal or moral, does the intended recipient have to an email message that has not even been received? I just don't even comprehend the moral issue, for which I apologize to the original poster.
On the face of it, the CEO intended to send the email, and then changed his intention prior to receipt. The original poster had the power to enable the overriding intention, but refused, while his immediate superior acceded to the request.
I think that no moral imperative to deliver a piece of email exists. I just don't see that there is some moral good attached to delivering mail, e- or snail-. I see a lot of utility inherent in communication, but no moral requirement for communication in general. I think that some moral good may be facilitated or hindered by communication, but now we are speaking in terms of particular instances, rather than in general terms. So, we must evaluate this particular instance.
In this particular case, the original poster has not specified that there was something in the email message that would have caused or facilitated something morally good. In fact, he specified that the email message was a hasty flame that the CEO, on further reflection, decided to withdraw -- in other words, the message would have hurt the recipient, without justification, thus being a moral wrong.
So, with no a priori moral reason to deliver email, and with the particular message's contents being morally wrong, I conclude that the original poster was, in fact, morally wrong to have refused to delete the email.
Please forgive the descent into philosophy, but that is my background, and I couldn't resist the temptation...
Much more to the point, Red Hat 7.3 has 1.5.2 as "python", but has 2.1 (IIRC) as "python2". And Red Hat 8 has 2.2.1 as its "python". And, as you said, it is eminently possible to download and compile the latest version, though you do have to be careful that you link in 2.2.x as "python2" rather than "python" on Red Hat 7.3, or many of the system apps break (up2date comes to mind...).
Okay, I am not familiar with the SourceCast product from CollabNet, so I can't speak to its features, and I'm talking out of my wazoo. However. Every piece of software on www.tigris.org is open source, most using the Apache license. And, while I'm sure that CollabNet is doing something really interesting to add value to the packaged-up whole that is SourceCast, I'd be willing to bet that what they are doing isn't THAT much more than building an integrated package. If anyone out there has more info, please chime in, but my bet is that SourceCast is an extremely cleanly-integrated packaging of www.tigris.org components such as Subversion, Scarab, Anzu, Eyebrowse, etc. And, frankly, those individual components look very useful in their own right. So, maybe your first project might be to find individual components that meet some of your requirements, and integrate them yourself.
To the original poster: I don't know if it could be adapted for your purposes, but you may well want to check out Forrest, at xml.apache.org. I have been examining it for my own use, and it looks like it might make a very interesting part of a distributed development framework.
Good luck, and let us know how it turns out.
Except that the GPUL is not the next best thing. If you read the eWeek article, you'll find that the projected time-line reads, basically, the G5 first and then the next best thing after that. And it is very much up in the air what that next best thing will be. I know that Apple has had a long history of working with IBM and Motorola, and that adds a certain amount of probability to the conjecture that the GPUL will be the next best thing, but the existence of Apple's Marklar project shows that we cannot discount the possibility of a switch to x86 architecture. I think the most likely candidate within the x86 world is AMD's Hammer -- it will be available at desktop-processor-level prices, and will also be available in versions more suitable for servers. Since both markets are areas Apple has targeted, this makes the Hammer more appropriate than, say, a combination of Intel's Pentium4 on desktop and Itanium for servers.
Again, though, let me reiterate that this is all just conjecture until "The Steve" makes some sort of formal announcement.
If your company is of any size whatsoever, you'll need more than just a lawyer who specializes in HIPAA compliance issues. You'll need to acquire the services of a HIPAA compliance and remediation consulting group. Our hospital is using Ernst & Young.
It sounds like you have multiple areas to look at -- your data storage, your data transmission (you aren't just creating those medical records from thin air, are you?), your partner companies, and how you handle the Patient Identifying Health Information on the desktop. Not to mention that your company should have been preparing for this for QUITE some time now.
First, you'll need to make sure that your data storage, transmission and handling (includes handing paper copies around), and desktop security are all compliant. Next you'll find that you are also responsible for making sure that any business partner companies are compliant. This task basically means getting your partner companies to sign "HIPAA Business Partner Agreement" contracts that means the partner company states that they are contractually obligated to handle any patient data of yours in a means that is also HIPAA compliant.
Finally, and most important of all, you'll need to be able to document all of the above, in a form that the government inspectors can easily use to check your compliance. Yay.
Get yer HIPAA-lovin' lawyers on the stick as fast as you can, and file for any extensions that may apply. You will need a complete inventory of any and all computing infrastructure (servers, workstations, network, and software) that touches identifying patient medical data. You will need to have this inventory so your CIO, lawyers, computer security experts and your HIPAA remediation consultants can check the compliance of everything on the list. Anything failing compliance, you'll need to fix or replace.
One last thing: you are also responsible for making sure that the source of your medical data is asking permission to use that medical data, and is asking that permission in a way that is compliant.
I hope this provides you with a decent starting point. Good luck, you have a hard task ahead of you.
There were a couple of points in the article and in some other posts that I feel a need to address.
Customization v. Standardization
One poster mentioned that he completely customized his Linux box so that "no one else could use it". And someone else replied, "You won't be able to use anyone else's computer". There's an interesting point to be noticed in this exchange: UI efficiency is the driving force behind both of these viewpoints. For the first poster, s/he probably only works on one computer, or one of a small set of similarly-configure computers. As a result, the poster can massively customize the UI to make it as efficient as possible. The second poster, on the other hand, probably works with multiple computers that can either have different UI configurations, or all must be configured for the "standard" interface in order to support as many "average" users as possible.
Personal Productivity
There are a couple of entirely different problems inherent in these two scenarios, and I don't begin to know how to solve them. For the first poster, s/he has found enormous gains in productivity through customization, but might well see a re-training learning curve when moving to someone else's computer. This problem might be solved by putting together a means of carrying around one's personal UI environment configuration -- something like a microdrive with all of one's preferences and customizations stored in it. The problem with this solution is that we cannot guarantee enough underlying environment similarity (choice of OS, apps, hardware) to make this scenario practical in the world-at-large. Within a standardized business environment ("Everyone shall have a Dell!"), this might be possible and even desirable, from the user's perspective.
Corporate Standardization
But then comes the perspective of the second poster: in a business environment, there are a couple of competing forces, the need to standardize platforms as much as possible in order to reduce support costs, and thus TCO, and the equally important need to maximize productivity of, ideally, each individual employee. Standard platforms allow the company to hire support personnel who can specialize in the standard platform, and do not need to have knowledge of many different platforms -- depth over breadth. These support personnel are more efficient, and thus the company can hire fewer of them. Hardware standards allow for greater reusability of spare parts, and OS and software standards guarantee compatibility of data throughout the institution and beyond. OS and application standards also mean the ability to consolidate training, and increase the likelihood of finding personnel who are already familiar with the use of the computer platform. In addition, if the institution chooses to standardize on a platform that has a low learning curve, and is thus quick to pick up for newcomers, training time can be reduced and costs lowered. If the hardware is ubiquitous and more-or-less commoditized, and thus interchangeable, and the OS and apps interoperate smoothly with each other, then an easy-to-learn and generally productive work environment is available to any employee who sits down in front of any computer.
Competing Imperatives
These are the typical arguments for standardization of platform within an organization, and one of the main factors that contributes to Microsoft's monopoly. These arguments point out some important things for us all to think about. We need to maximize a few different, competing areas: the OS and apps bundle needs to interoperate well, both internally and with the rest of the world; the whole package needs to be easy to learn for newbies; ideally there should be a well-established user-base to provide a pool of "community knowledge" to allow users to help each other ("Hey, Jane, how do I go about sending an email on the company's systems?" "Simple, George, just run this...") and to provide a reasonably large pool of pre-trained support personnel; the platform needs to provide a reasonable level of productivity throughout the company.
I'd like to elaborate that last point a bit. As much extra efficiency as the first poster may gain from a completely customized UI environment, s/he will find it hard to use all the rest of the computers in the company, and no one else will be able to use the customized computer, and no one will be able to support it. Now, if the company is small, or is built around the genius of a few individuals, then a comfortable work environment that caters to these individuals may well be cost-effective in order to maintain their productiviy. On the other hand, if that poster works for a company with a lot of employees, then customization isn't cost-effective at all. The individual's productivity gains are completely washed away by the extra expense of handling and supporting those customizations.
Article Points
The article makes a few basic points: Linux on the desktop isn't easy enough; Linux doesn't have the same software available; Linux desktops basically copy existing Windows and/or Mac desktops -- and don't do it well; uneducated Linux adopters don't want a copy of Windows, they want something radically new; and the standard WIMP interface is boring and no fun.
Ease of Use
Okay, this one's easy: yes, Linux isn't easy enough. We need to keep working on this one. No points for originality here. One poster mentioned that the reason things aren't easier is because it is hard. Well, that makes sense.
Available Software
I think we all realize that the brand name on a software package is less important than its functionality. In areas like word processing, as long as the document format is completely interchangeable (no small feat with closed and ever-changing formats), and the feature-set is complete, then we can easily substitute one word processor for another.
But this assumes that the skills necessary to use a given type of software are extremely common. By this I mean that, in the case of word processing, the necessary skill (language use) is external to the program. Efficiency of use comes from the skill of typing -- and this skill, again, is not inherently related to the software. In other words, typing is useful for WAY more stuff than just word processing. In contrast, good graphics designers (for example -- though I am not a designer, and my ignorance may well show) specialize in a particular package within a few related software types. That is to say, the ability of a particular application to specialize in one area of competency leads to greater fitness for a particular type of task. Thus you have Adobe Illustrator competing against Macromedia Freehand, or Photoshop competing against, um, well, nothing I know. Illustrator and Freehand are, very specifically, vector-based drawing and illustration tools. Photoshop is very specifically designed for manipulating raster images. They do different things, and don't compete directly. Now, slightly less specialized programs do exist, such as Canvas or CorelDraw. They are designed as "all-in-one" programs that handle both vector graphics and raster images. But the designers I know generally display a certain amount of contempt for these packages, as they don't measure up. It takes a great deal of skill (and thus training time) to become especially good at using Photoshop to its fullest extent. That time spent acquiring that skill is valuable. As a result, it will be very hard for Linux to do anything other than copy Photoshop, if we desire to take that market. And I don't think that anyone in their right mind would even suggest that such a thing is possible -- people who invest time in acquiring a given skill are justly wroth with those who suggest they acquire a new, different skill, thus implying that the original skill isn't worth much. The conclusion being that the Linux world would have to demonstrate conclusively that our software is greatly better than existing commercial alternatives, in very concrete ways. Shaking the carrot of intellectual freedom won't help -- most people have a hard time understanding the concept. In short, it isn't better because it's free-as-in-speech, and it is only *slightly* better because it is free-as-in-beer.
Copying Existing UIs
Okay, Krul's point that Linux desktops don't do a good job of copying the functionality of existing UIs is valid, but again isn't new. However, I think that there isn't much that can be done about it until someone comes up with a radically different means of interacting with computers. I hate to break it to the poster who mentioned voice recognition, but it really isn't going to be terribly efficient even AFTER the technology is perfected. From a business perspective, voice recognition is unusable. Can you imagine a cubicle farm full of people yakking at their PCs all day? Utter insanity! And virtual reality in its current incarnation is equally futile. Imagine someone wearing a headset and a glove or two. Now imagine how hard it will be for that person to switch back and forth between interacting with the computer and interacting with the rest of the world -- how do you talk to a coworker? How do you pick up a business card, or a report? And for those of you who reply that the office can be paperless, and all communication can be done using email/telephony, I laugh at you. Loudly. I see some definitely useful applications of VR technology, and I'd be very surprised if VR weren't in use in several different areas already, but it will not take over as the standard means of human-computer interaction until the interface is drastically improved.
Frankly, I see the most added utility in terms of VR (and, really, computers as a whole) as a means of adding information in the context of the real world. That is, VR only becomes useful to the masses when it doesn't interfere with day-to-day reality, and adds something useful in the bargain. Basically, we're talking science fiction: brain implants that interact wirelessly with the completely ubiquitous world-wide computer network, and provide an informative and appropriately (contextually) filtered overlay or addition to the physical world, as well as extending human interaction, communication, and control. Cool stuff, and we're already seeing the beginnings of this sort of technology in the research into computer control through central nervous system activity, as well as the ongoing efforts at repairing blindness with an artifical imaging device connected directly to patients' optic nerves. Again, neat but not near-term.
Boring Old WIMP v. "Pleasure"
Um, yeah, I suppose I agree that WIMP isn't much fun. Frankly, I'd make the assertion that CLI isn't much fun either (ducks the flames). Instead, I'd assert that what makes the command line more fun than windows and a mouse is the control, the efficiency, the efficacy of typing in a command. When you type in a command, don't you get a thrill from seeing your precisely-formulated desires responded to by the computer? In fact, I quickly lose interest in CLI when whatever process doesn't provide immediate feedback, e.g., formatting a hard drive. BOOOORRRING... And I become very quickly frustrated, whether in GUI or CLI, when my desires are thwarted. However, the precision, control, and more tangible feeling of accomplishment I receive from CLI makes it more fun. And yes, WIMP takes that away. But I don't know what else we could use that would give us as much control. Anyone have any ideas?
Here's an alternative thought for you:
LAN game it.
Have everyone bring over their laptop, set up a small LAN, and have at it. You get real-time discussion without interfering gadgetry, all the benefits of getting together (swapping tales, an excuse to eat large quantities of junk food, etc.), AND you have a nice game engine for dealing with all the rules and putting up pretty pictures of whatever you're doing.
What's not to like? Er, aside from BO, tall tales, bad food, off-topic/out-of-character chatting, coordination of times, and a lack of physical space (for people with small apartments). All in all, just play the way you want to...
The basis of a valid electronic signature is a combination of policy and code. As per Schneier's article and the E-Sig Act, deniability is the key factor. If you can provide the technology necessary to keep the means of signing secure, and can put in place a set of policies for which you have agreement on record, then you have a legally binding electronic signature.
The exact means you use to implement the technology, whether it be digital certificates or simple password authentication, is nearly irrelevant. Okay, you want to make it as secure as possible, and local regulations and/or your contracting partners may dictate your means. But aside from that, all you have to do is make sure that you have taken reasonable precautions to ensure that the signature corresponds to the person, and that intent to sign is implied in the signature. The first half is done through authentication of some sort. The second half is embodied in your company's documented policy.
For the policy, make sure that your company holds training sessions for all current and new employees who will use the system. Let them know that security of their job depends on the security of their passwords. If possible, get them to sign a form that spells out the policy, the usage, the consequences of misuse, and that they acknowledge that by using the system, the employee consents to be bound by the signature. We in healthcare call this informed consent . It maintains an audit trail that disallows deniability. The interesting point, on rereading the E-Sig Act, is that the employee may signal their intention not to be bound by the electronic signature -- but this must be written. In your policy, you may specify that the employees must agree to and comply with the electronic signature as a requirement for employment. At which point, you may remind them if they wish to withdraw their consent that they may be endangering their job in so doing.
As another poster mentioned, though, get a lawyer's (or insert other domain-specific expert here) advice on the topic. And, if you expect your electronic signature to be taken as valid by other companies, you must discuss the matter with them beforehand.
Been under a rock for a while, haven't you? ;)
:) have provided some seriously amazing libraries/frameworks/etc. that help programmers avoid reinventing the wheel -- or the bucket seat, the 5-speed automatic transmission, or even the 10-disc CD changer.
Okay, all ribbing aside, as someone who programs Java for money, let me give you the skinny: Java applets bite. More specifically, they are slow to download, prone to crashing, and subject to problems due to lack of control over the Java runtime available to the browser.
Java has, instead, found its niche on the server. Server-side programming is where Java works really, really well. Development is generally faster than with C/C++, and Sun and others (go Apache!
The other benefit that Java on the server provides is that web designers don't have to monkey with the code, and programmers don't have to deal (so much) with HTML.
Needless to say, everything above is a generalization, all generalizations are false (including this one), and YMMV.
I know it's a bit of a stretch, but consider Python. Prototype the heck out of the system in Python, profile the application, then recode the bottlenecks in C. Use SWIG to generate your interfaces. Easier to program, easier to extend, easier to read/maintain. Shorter programming time, too.
You'll be happier, your fellow programmers will be happier, your successor programmers will be happier, and the chewy parts of your code will still be really fast. Think about it.