How on earth can you find CORBA to be complicated? Using the wrong tools? Have the wrong teacher? It is amazingly easy! Given a CORBA server, here is how to build a client:
Step 1 - create header files from CORBA definition file
Step 2 - Build client code exactly as if this were a local library - the only exception is creating the reference, which you will have to agree on some mechanism (actually, if you use the CORBA naming service, this is easy as well).
Step 3 - Build and run!
Steps to build a client for other servers:
Step 1 - Decide on communication protocol - this is a huge deal, and it must take into consideration everything that the CORBA community has already taken into consideration
Step 2 - Build a library for your client so that you can use the communication protocol in a simple fashion. Again, the CORBA community already has this figured out, and you would likely end up simply re-implementing a broken version of CORBA.
Step 3 - Write your code, but you'll also have to spend time cleaning up problems you find you missed in the first two steps
Step 4 - build and run - oops, have to clean up my communication protocol up even more. Oh yeah, forgot that I need to pass around a context. Now I need to change my communication protocol - there goes my library - I need to totally rewrite it to take care of the fact that I thought it was as simple as opening a socket!
Now, some people confuse the amount of features available from the CORBA runtime to be complicated. Well, you don't have to use them, but if you need them, they are wonderful. Context passing is simply amazing. Also, for servers, the Portable Object Adapter makes writing very complex services very easy.
You missed the entire point behind my post. This is not a comparison among distributions. This is a comparison between the Enterprise RedHat and the consumer RedHat.
The point is that if RedHat STOPS posting updates for it's packages for a certain version, then the people using that version will have to work hard to maintain their systems themselves, while users of their Enterprise version will continue having updates.
As I specifically mentioned in my post, one alternative is to go to a community-supported distribution rather than a commercially-supported distribution. In fact, I specifically mentioned Debian.
This has nothing to do with Red Hat's packaging system or anything like that. This is about it's release and support practices, and choosing which version of RedHat best supports your needs, nothing more, nothing less.
Your statements are true for many cases, but not all.
First of all, just because someone puts out RPMs, doesn't mean that they will work the same way the RedHat ones will. RedHat sets many defaults which are different that what the maintainer does. There isn't anything guaranteeing that they are using the same spec file, etc. There are many maintainers who do release along RedHat's lines, but it's certainly not everyone.
As for newer versions, that's fine and all, except that the _reason_ RH backports fixes is that newer versions of software often change how that version works, introduces new bugs, and may change the configuration file format. Red Hat backports only the necessary fixes, so that you have a stable baseline.
As for commercial programs that only support specific versions of RedHat, the version that they are more and more only supporting is Advanced Server.
I'm not saying the obstacles are insurmountable, I'm just saying that there's a lot of work that goes into keeping tabs on an unsupported distribution compared to a supported one.
I've had to clean the wreckage of people who played fast and loose with versions - who downloaded and built every new release of packages on production systems. The result gets to be very messy. Red Hat does a very good job of backporting fixes (so does Debian, I might add), and that's one of the biggest reasons to use a canned, supported distribution.
Personally, I have not decided which direction to take my company for sure.
One other note - you can get the SRPMs for Advanced Server at no cost and build them yourself.
It depends on how you answer the following questions:
* Do you want to recompile each package every time you want to update it, or do you want to do rpm -i?
* Do you want to backport source patches to your current version, and then install it, or do you want to do rpm -i?
* Do you want to have to watch every mailing list for possible security problems on your software, or do you just want to look in the errata section of the RedHat web site?
I think there's essentially five options:
* Continually reinstall your servers to the latest RedHat
* Buy Advanced Server
* Form a community group dedicated to keeping up with older versions of RH - making the above changes as a group
* Use a distro that already has a community group (i.e. - Debian)
"sure, you can but not as elegant as EJBs, and if you are developing for a thin client JSPs talk very well with EJBs. not the case with your CORBA hack you will need to find a way to make your web scripts talk to your CORBA backend easily."
---
The reason you _need_ EJBs is so you can spread out your objects and let the application server manage them. Writing CORBA or RMI objects with Java is a piece of cake. The application server component is needed to manage the scalability, not the tiering.
---
"what??!! your boss wants you to switch the database vendor right now ?"
---
1) I have never, ever, ever, ever, ever, ever, ever in my entire life heard of this happening.
2) It usually isn't much of an issue anyway, as long as the vendor your switching _to_ isn't MySQL.
---
"J2EE application servers provides you with an environment where you can model your business tier easily and get data in/out easily, scaling this is a bonus and an extra feature"
---
I find that strange considering it was never difficult.
you missed the point by a mile, the main purpose of the application server is to hold your business logic tier in a multi tier application
----
You don't need an application server to do that. You need an application server to manage the scalability requirements on an n-tiered application.
It's easy to separate the business logic from the presentation logic from the database logic just using OOP. However, that doesn't help you scale your business logic across multiple servers. An application server's job is to assist in helping your n-tiered designs _scale_, you don't need them just to do the design.
You can do everything you say simply by using CORBA to communicate among the tiers and a good object model. To scale the middle tier you need an application server.
I am not familiar with JDO. However, if it is simply an object/relational mapper that is not what I was talking about. What I was talking about was an interface for object activation/deactivation, not mapping objects to databases. In the scenario I described, the object/relational mapping was done by the programmer - J2EE is responsible for activating/deactivating objects as needed and where needed.
An application server is a set of tools that do a lot of the scalability work for you. For example, let's say you have a database that 100G big. You have classes/objects that map to all of this data, each referencing each other. Now to instantiate an object, it will require data from the database. It also likely has a pointer to another object which is tied to the database. So, you have three choices:
* Have instantiation of one object bring half the database into memory
* Write code that intelligently loads and unloads references seamlessly from the database on demand (_lots_ of work)
* Get someone else's code to do it for you
Option 3 is the application server. Remember also that if you have your application spread across 13 servers, and all of them need access to the same object, where is the object going to live? If you have 13 copies of it, what happens if an instance gets modified - how do the other 12 instances know to reload their data? If you keep it on one server, how are you going to handle load balancing intelligently?
The purpose of application servers is to have a canned infrastructure capable of handling these problems well. There are many other plumbing considerations that application servers keep track of, such as nested transactions, being able to remap data items onto different tables/attributes, being able to set the environment of an application through a simple text-based descriptor, etc.
Usually I've found that for smaller-scale projects, application servers are overkill. However, for large-scale projects, they keep your project from becoming the ultimate hack-job. The trade-off probably hits when you have about 3 front-end webservers. For some items it hits as soon as you need 2 servers, for the load-balancing/synchronization problems.
Actually, Microsoft Research has a number of really good programming language experts. Unfortunately, none of their research has made it into real products.
"The masses" use what is fed to them, provided it doesn't change much.
Those who are in the know but have to work for a living use what has the greatest library base for the job we're doing. That's often Perl, Python, or similar, since they have about 70% functionality of those other languages (while Java, C, and C++ has about 40% of the functionality).
If those in the know didn't have to do real work, we would spend more time developing libraries for better languages, rather than having to use lesser ones.
As an example, since 90% of the world uses Excel, all of the data in our programs import from and export to excel. Well, Perl has a good OLE/Excel importer/exporter on UNIX, while Scheme (my language of choice) does not.
a) the reason that two people in a marriage have to work now is that the government is eating up so much of our money trying to control the economy - and in doing so is also hurting the economy - so we're being bitten twice.
b) Why does everyone leave out the fact that people are pretty smart, and when left without too many barriers tend to do pretty amazing things?
c) pre-exisiting conditions only apply if you have a period without work. In addition, medical insurance is only needed because medical costs are raised too much by an over-regulated medical industry.
Over-regulation hurts the consumer in many ways. For example, in the medical industry, it can take 8 years for a business to be allowed to sell their products on the market, thanks to the FDA. If you can imagine a company that has the stamina to weather 8 years of no profits, filling a minimum of 10 full-time jobs, you see that there is little chance of new competition. Therefore, those players that have made it came from high-money ventures themselves (otherwise they would not have been able to be there) and thus they would only take such a risk in order to take home hefty profits. Since noone else can compete, they succeed in this.
The problem is not too much market freedom, it's too little. With real competition, you would have affordable health care.
Actually, even to someone who does not believe them, the Christian stories are different than the Greek ones which are termed as myths. If you don't believe them, you may say they have some mythical elements, but all in all the Bible has been supported in a large part by archaeology. There's no reason to believe that these people didn't exist. These are major figures, much like Muhammad. A story depicting Muhammad's life is not a myth, even if a person does not believe all elements.
Some people use the word "myth" for "instructive story", whether the original story was fully true, partially true, or wholly fabricated. With this in mind, then yes, much of the Bible can be called "myth". However, for most people, the term "myth" denotes a wholly-fabricated story. "legend" is usually used for stories whose historical status is possible but in doubt, and most likely exaggerated.
I suppose you are speaking of the moral errors of people throughout the Bible?
The Bible, unlike most historical books of its time, outlines both the errors and the correct actions of the people involved. The Bible recording an event does not mean that the Bible condones the given event.
In what way would you say that the Bible condones murder, rape, and child molesting? I've never seen a passage of the sort. There are a few isolated cases of murder, true. But nothing I've seen that's an outright condoning of the behavior in general. In fact, God refused to allow David to build His temple because David's reign included so much bloodshed. The bloodshed was sanctioned by God, but it shows that although there may be times when God requires someone's blood, His heart is for peace.
"So you simply don't believe that a story communicated orally is any more susceptible to deliberate or accidental embellishment or amendment? Chinese whispers?"
Actually, people _used_ to be able to memorize oral traditions very well. We aren't able to today, because we have no need for it. You either treat history with respect or you don't. Written or oral doesn't count for a lot.
"It is also claimed in the Bible that God will not allow the Word to be corrupted, is it not?"
Haven't seen that. Maybe it does somewhere, but I certainly haven't seen it. I think that's a traditional view, but it's not in the Bible.
"That's a very unorthodox view of Christianity. Most Christians would say that the purpose of the Bible is to reveal the gospel of Jesus - not the bits about how to live your life, but that Jesus is the Son of God and that no man comes to the Father except through Him."
Yes! Quite true! That's training in righteousness. Our righteousness is more determined by our relationship with God than anything we do of ourselves. Whether my views are unorthodox or not depends on how you look at it. The current inerrant views are from when Luther used the Bible to combat corruption in the Catholic Church. He saw how the Church had decided that it was an authority over the Bible. His only answer was to say that the Bible was absolutely infallable. While that is a much better answer than what the Catholics were practicing at the time, it is not a fully adequate answer, and is not one even the Bible claims for itself.
"There is a great deal of Christianity which is a lot less self-consistent than a number of alternative spiritual and/or moral philosophies. If you're interested in discussing this, reply to me here and I'll email you."
Self-consistency is not as useful as you may think. Self-consistency is only useful if the way our rational minds put things together correspond to reality. I trust Jesus, and His word is the authority in my life. I haven't had it fail me yet, nor have I been unsure of what Jesus was asking of me in any of it.
Anyway, I'd love to continue the correspondence in email - johnnyb@eskimo.com
Only if you presume God to be Platonic. Unfortunately, God didn't consult Plato. Some of your points are valid, but not quite so much in the way you mean them. For example, whether it was written down by eyewitnesses or not does not have much bearing on its validity. Either you believe the people who said so or you don't - whether they or their grandchildren actually wrote it down is somewhat irrelevant.
In addition, the term "inspiration" has a number of different meanings. People who have an inadequate understanding of language tend to take translations a little too seriously. People have gone overboard when they read that "Inspired by God" means God-breathed in greek. Well, "inspired by God" can literally mean God-breathed in English, too - it's just that most people use the word "inspire" to mean prompting, rather than actually to breathe in, though it's a valid definition.
If you look at the Bible's own claims of authenticity (2 Timothy 3:16), you'll notice that it claims itself useful for the following activities:
teaching, rebuking, correcting and training in righteousness
None of which include correcting history. Now, I'm not saying that the events of the Bible didn't occur - I quite believe they did and have faith that the people writing them were being honest, even if they may have been at times incorrect. However, the point of the Bible is training in righteousness - something that the whole of the Bible does quite well.
Some people say that the Bible is inconsistent. It depends on what you were expecting. Life is crazy enough that any self-consistent set of rules that are completely understandable are just plain wrong. Therefore, as Christians, we have faith that what God has been saying through His people is true, even though it's much muddier than we might like, and there aren't exact answers for everything (although there are for many things).
Anyway, I love the Bible, and often feel God speaking to me as I read it. I can understand how the overzealousness of people who think Plato's idea of God is the authoritative definition can obscure God's work and working. I think that more importantly than being overly literal with the Bible, Christians should take God at His word - which is a little different and a little more human (kind of the way He's been communicating with us all along). Some people expect God to communicate to us in an extra-human way. But if He did, we would have no hope of understanding.
What's really good is that Fujitsu global services is heavily tied to EDS (at least here in Tulsa). EDS contracts support on all it's boxes to Fujitsu, so having them support RHAT is a good thing.
I think the shallowness of the philosophy in the Matrix makes it so that you can safely say "the Matrix has no philosophical content". It can spark a philosophical discussion, but so can my three-year-old.
The only one of Descartes meditations that made sense was the first one. The rest rested on very large assumptions. Many people in philosophy think that he bunged up the first one as well, but I've never seen someone argue that successfully. It's usually because they assume that Descarte's "I" implies a "soul" with all of it's trappings. If you don't take it as that, I find that the Descarte's first meditation is one of the only self-evident truths, but sadly you can't get beyond that. Descarte tried but failed miserably.
I'm sorry, you think GIMP is bad because it doesn't work on _Windows_? Windows is not it's target operating system. The fact that someone bothered to port it to Windows is a testament of the flexibility of GIMP. The fact that the developers are not concentrating their efforts there does not reflect on the GIMP as a project. Rather, it just means that if you are using GIMP in an unsupported configuration, you get what you get.
GIMP is _extremely_ stable on Linux boxes, and comes pre-installed with most distributions, so most of your argument goes out the Window there. The fact that the GIMP is unintuitive for _you_ means very little for the rest of us. My own biased opinion is that GIMP is extremely easy to use, because it doesn't restrict you to a single frame like Photoshop does. The toolbox/canvas paradigm is intuitive if you're used to it, and actually has a lot of advantages over the MDI paradigm, which even Microsoft is starting to get away from.
It doesn't break every UI convention in the book, it breaks every _Windows_ UI convention in the book. Why? *Gasp* It's not a Windows program.
It seems to me that your little mini-review is an attempt at avoiding the real issues of the capability and usability of the GIMP. Would you think I was fair if I judged Office XP based on it's performance under Wine and how well it meshed with my UNIX desktop? Of course not. Likewise, your review of GIMP on Windows tackled none of the real issues of image manipulation.
Since most of our designers use Windows, they use Photoshop. However, many times if they have to do a similar design for many pieces of text (such as headings, buttons, etc.), we will build scripts for the GIMP to handle them (and no, Photoshop Actions are not intelligent enough for what we are doing). We simply create a file of the text we want and GIMP will autogenerate images into files named using our standard naming conventions.
Anyway, I'm open to disagreement, but your review of the GIMP was very, very poorly done.
As for Mozilla, I can't live without my tabs, my popup Window blocking, or my cookie manager. What do you find lacking in it? Many people in my office have switched to Mozilla.
I can see some people disliking OpenOffice if they've invested heavily in Macros. Personally I love it for it's save as PDF features, and in the new versions I can convert PowerPoint files to Flash with a click of a button - and it is an exact replica of the PPT presentation in 10% of the file size, generally. In addition, OpenOffice handles DocBook quite well (we have many tools based around that), and it's native format is XML. In addition, it doesn't require a separate tool for database access like MS Office does. It also has a decent (but not astounding) vector graphics program with it.
Anyway, I'm sure many people disagree, and have good arguments for doing so. I found yours disingenuous.
Slashdot Mirror
How on earth can you find CORBA to be complicated? Using the wrong tools? Have the wrong teacher? It is amazingly easy! Given a CORBA server, here is how to build a client:
Step 1 - create header files from CORBA definition file
Step 2 - Build client code exactly as if this were a local library - the only exception is creating the reference, which you will have to agree on some mechanism (actually, if you use the CORBA naming service, this is easy as well).
Step 3 - Build and run!
Steps to build a client for other servers:
Step 1 - Decide on communication protocol - this is a huge deal, and it must take into consideration everything that the CORBA community has already taken into consideration
Step 2 - Build a library for your client so that you can use the communication protocol in a simple fashion. Again, the CORBA community already has this figured out, and you would likely end up simply re-implementing a broken version of CORBA.
Step 3 - Write your code, but you'll also have to spend time cleaning up problems you find you missed in the first two steps
Step 4 - build and run - oops, have to clean up my communication protocol up even more. Oh yeah, forgot that I need to pass around a context. Now I need to change my communication protocol - there goes my library - I need to totally rewrite it to take care of the fact that I thought it was as simple as opening a socket!
Now, some people confuse the amount of features available from the CORBA runtime to be complicated. Well, you don't have to use them, but if you need them, they are wonderful. Context passing is simply amazing. Also, for servers, the Portable Object Adapter makes writing very complex services very easy.
I prefer Python for scripting COM components - it really is a better language.
You missed the entire point behind my post. This is not a comparison among distributions. This is a comparison between the Enterprise RedHat and the consumer RedHat.
The point is that if RedHat STOPS posting updates for it's packages for a certain version, then the people using that version will have to work hard to maintain their systems themselves, while users of their Enterprise version will continue having updates.
As I specifically mentioned in my post, one alternative is to go to a community-supported distribution rather than a commercially-supported distribution. In fact, I specifically mentioned Debian.
This has nothing to do with Red Hat's packaging system or anything like that. This is about it's release and support practices, and choosing which version of RedHat best supports your needs, nothing more, nothing less.
Your statements are true for many cases, but not all.
First of all, just because someone puts out RPMs, doesn't mean that they will work the same way the RedHat ones will. RedHat sets many defaults which are different that what the maintainer does. There isn't anything guaranteeing that they are using the same spec file, etc. There are many maintainers who do release along RedHat's lines, but it's certainly not everyone.
As for newer versions, that's fine and all, except that the _reason_ RH backports fixes is that newer versions of software often change how that version works, introduces new bugs, and may change the configuration file format. Red Hat backports only the necessary fixes, so that you have a stable baseline.
As for commercial programs that only support specific versions of RedHat, the version that they are more and more only supporting is Advanced Server.
I'm not saying the obstacles are insurmountable, I'm just saying that there's a lot of work that goes into keeping tabs on an unsupported distribution compared to a supported one.
I've had to clean the wreckage of people who played fast and loose with versions - who downloaded and built every new release of packages on production systems. The result gets to be very messy. Red Hat does a very good job of backporting fixes (so does Debian, I might add), and that's one of the biggest reasons to use a canned, supported distribution.
Personally, I have not decided which direction to take my company for sure.
One other note - you can get the SRPMs for Advanced Server at no cost and build them yourself.
It depends on how you answer the following questions:
:)
* Do you want to recompile each package every time you want to update it, or do you want to do rpm -i?
* Do you want to backport source patches to your current version, and then install it, or do you want to do rpm -i?
* Do you want to have to watch every mailing list for possible security problems on your software, or do you just want to look in the errata section of the RedHat web site?
I think there's essentially five options:
* Continually reinstall your servers to the latest RedHat
* Buy Advanced Server
* Form a community group dedicated to keeping up with older versions of RH - making the above changes as a group
* Use a distro that already has a community group (i.e. - Debian)
* Do it all yourself
Or you could just leave your machine unpatched
"sure, you can but not as elegant as EJBs, and if you are developing for a thin client JSPs talk very well with EJBs. not the case with your CORBA hack you will need to find a way to make your web scripts talk to your CORBA backend easily."
---
The reason you _need_ EJBs is so you can spread out your objects and let the application server manage them. Writing CORBA or RMI objects with Java is a piece of cake. The application server component is needed to manage the scalability, not the tiering.
---
"what??!! your boss wants you to switch the database vendor right now ?"
---
1) I have never, ever, ever, ever, ever, ever, ever in my entire life heard of this happening.
2) It usually isn't much of an issue anyway, as long as the vendor your switching _to_ isn't MySQL.
---
"J2EE application servers provides you with an environment where you can model your business tier easily and get data in/out easily, scaling this is a bonus and an extra feature"
---
I find that strange considering it was never difficult.
you missed the point by a mile, the main purpose of the application server is to hold your business logic tier in a multi tier application
----
You don't need an application server to do that. You need an application server to manage the scalability requirements on an n-tiered application.
It's easy to separate the business logic from the presentation logic from the database logic just using OOP. However, that doesn't help you scale your business logic across multiple servers. An application server's job is to assist in helping your n-tiered designs _scale_, you don't need them just to do the design.
You can do everything you say simply by using CORBA to communicate among the tiers and a good object model. To scale the middle tier you need an application server.
I am not familiar with JDO. However, if it is simply an object/relational mapper that is not what I was talking about. What I was talking about was an interface for object activation/deactivation, not mapping objects to databases. In the scenario I described, the object/relational mapping was done by the programmer - J2EE is responsible for activating/deactivating objects as needed and where needed.
An application server is a set of tools that do a lot of the scalability work for you. For example, let's say you have a database that 100G big. You have classes/objects that map to all of this data, each referencing each other. Now to instantiate an object, it will require data from the database. It also likely has a pointer to another object which is tied to the database. So, you have three choices:
* Have instantiation of one object bring half the database into memory
* Write code that intelligently loads and unloads references seamlessly from the database on demand (_lots_ of work)
* Get someone else's code to do it for you
Option 3 is the application server. Remember also that if you have your application spread across 13 servers, and all of them need access to the same object, where is the object going to live? If you have 13 copies of it, what happens if an instance gets modified - how do the other 12 instances know to reload their data? If you keep it on one server, how are you going to handle load balancing intelligently?
The purpose of application servers is to have a canned infrastructure capable of handling these problems well. There are many other plumbing considerations that application servers keep track of, such as nested transactions, being able to remap data items onto different tables/attributes, being able to set the environment of an application through a simple text-based descriptor, etc.
Usually I've found that for smaller-scale projects, application servers are overkill. However, for large-scale projects, they keep your project from becoming the ultimate hack-job. The trade-off probably hits when you have about 3 front-end webservers. For some items it hits as soon as you need 2 servers, for the load-balancing/synchronization problems.
If you don't get into examining the facts and synthesizing until upper-level high-school, you are far behind where you should be.
We should be reading _source_ documents in gradeschoool (although translated).
Actually, Microsoft Research has a number of really good programming language experts. Unfortunately, none of their research has made it into real products.
It's fairly simple:
"The masses" use what is fed to them, provided it doesn't change much.
Those who are in the know but have to work for a living use what has the greatest library base for the job we're doing. That's often Perl, Python, or similar, since they have about 70% functionality of those other languages (while Java, C, and C++ has about 40% of the functionality).
If those in the know didn't have to do real work, we would spend more time developing libraries for better languages, rather than having to use lesser ones.
As an example, since 90% of the world uses Excel, all of the data in our programs import from and export to excel. Well, Perl has a good OLE/Excel importer/exporter on UNIX, while Scheme (my language of choice) does not.
a) the reason that two people in a marriage have to work now is that the government is eating up so much of our money trying to control the economy - and in doing so is also hurting the economy - so we're being bitten twice.
b) Why does everyone leave out the fact that people are pretty smart, and when left without too many barriers tend to do pretty amazing things?
c) pre-exisiting conditions only apply if you have a period without work. In addition, medical insurance is only needed because medical costs are raised too much by an over-regulated medical industry.
Over-regulation hurts the consumer in many ways. For example, in the medical industry, it can take 8 years for a business to be allowed to sell their products on the market, thanks to the FDA. If you can imagine a company that has the stamina to weather 8 years of no profits, filling a minimum of 10 full-time jobs, you see that there is little chance of new competition. Therefore, those players that have made it came from high-money ventures themselves (otherwise they would not have been able to be there) and thus they would only take such a risk in order to take home hefty profits. Since noone else can compete, they succeed in this.
The problem is not too much market freedom, it's too little. With real competition, you would have affordable health care.
Actually, even to someone who does not believe them, the Christian stories are different than the Greek ones which are termed as myths. If you don't believe them, you may say they have some mythical elements, but all in all the Bible has been supported in a large part by archaeology. There's no reason to believe that these people didn't exist. These are major figures, much like Muhammad. A story depicting Muhammad's life is not a myth, even if a person does not believe all elements.
Some people use the word "myth" for "instructive story", whether the original story was fully true, partially true, or wholly fabricated. With this in mind, then yes, much of the Bible can be called "myth". However, for most people, the term "myth" denotes a wholly-fabricated story. "legend" is usually used for stories whose historical status is possible but in doubt, and most likely exaggerated.
Yes, there is. However, it mostly applies to the parties that explicitly break the trade secret, not to parties after that.
I suppose you are speaking of the moral errors of people throughout the Bible?
The Bible, unlike most historical books of its time, outlines both the errors and the correct actions of the people involved. The Bible recording an event does not mean that the Bible condones the given event.
In what way would you say that the Bible condones murder, rape, and child molesting? I've never seen a passage of the sort. There are a few isolated cases of murder, true. But nothing I've seen that's an outright condoning of the behavior in general. In fact, God refused to allow David to build His temple because David's reign included so much bloodshed. The bloodshed was sanctioned by God, but it shows that although there may be times when God requires someone's blood, His heart is for peace.
"So you simply don't believe that a story communicated orally is any more susceptible to deliberate or accidental embellishment or amendment? Chinese whispers?"
Actually, people _used_ to be able to memorize oral traditions very well. We aren't able to today, because we have no need for it. You either treat history with respect or you don't. Written or oral doesn't count for a lot.
"It is also claimed in the Bible that God will not allow the Word to be corrupted, is it not?"
Haven't seen that. Maybe it does somewhere, but I certainly haven't seen it. I think that's a traditional view, but it's not in the Bible.
"That's a very unorthodox view of Christianity. Most Christians would say that the purpose of the Bible is to reveal the gospel of Jesus - not the bits about how to live your life, but that Jesus is the Son of God and that no man comes to the Father except through Him."
Yes! Quite true! That's training in righteousness. Our righteousness is more determined by our relationship with God than anything we do of ourselves. Whether my views are unorthodox or not depends on how you look at it. The current inerrant views are from when Luther used the Bible to combat corruption in the Catholic Church. He saw how the Church had decided that it was an authority over the Bible. His only answer was to say that the Bible was absolutely infallable. While that is a much better answer than what the Catholics were practicing at the time, it is not a fully adequate answer, and is not one even the Bible claims for itself.
"There is a great deal of Christianity which is a lot less self-consistent than a number of alternative spiritual and/or moral philosophies. If you're interested in discussing this, reply to me here and I'll email you."
Self-consistency is not as useful as you may think. Self-consistency is only useful if the way our rational minds put things together correspond to reality. I trust Jesus, and His word is the authority in my life. I haven't had it fail me yet, nor have I been unsure of what Jesus was asking of me in any of it.
Anyway, I'd love to continue the correspondence in email - johnnyb@eskimo.com
Only if you presume God to be Platonic. Unfortunately, God didn't consult Plato. Some of your points are valid, but not quite so much in the way you mean them. For example, whether it was written down by eyewitnesses or not does not have much bearing on its validity. Either you believe the people who said so or you don't - whether they or their grandchildren actually wrote it down is somewhat irrelevant.
In addition, the term "inspiration" has a number of different meanings. People who have an inadequate understanding of language tend to take translations a little too seriously. People have gone overboard when they read that "Inspired by God" means God-breathed in greek. Well, "inspired by God" can literally mean God-breathed in English, too - it's just that most people use the word "inspire" to mean prompting, rather than actually to breathe in, though it's a valid definition.
If you look at the Bible's own claims of authenticity (2 Timothy 3:16), you'll notice that it claims itself useful for the following activities:
teaching, rebuking, correcting and training in righteousness
None of which include correcting history. Now, I'm not saying that the events of the Bible didn't occur - I quite believe they did and have faith that the people writing them were being honest, even if they may have been at times incorrect. However, the point of the Bible is training in righteousness - something that the whole of the Bible does quite well.
Some people say that the Bible is inconsistent. It depends on what you were expecting. Life is crazy enough that any self-consistent set of rules that are completely understandable are just plain wrong. Therefore, as Christians, we have faith that what God has been saying through His people is true, even though it's much muddier than we might like, and there aren't exact answers for everything (although there are for many things).
Anyway, I love the Bible, and often feel God speaking to me as I read it. I can understand how the overzealousness of people who think Plato's idea of God is the authoritative definition can obscure God's work and working. I think that more importantly than being overly literal with the Bible, Christians should take God at His word - which is a little different and a little more human (kind of the way He's been communicating with us all along). Some people expect God to communicate to us in an extra-human way. But if He did, we would have no hope of understanding.
What's really good is that Fujitsu global services is heavily tied to EDS (at least here in Tulsa). EDS contracts support on all it's boxes to Fujitsu, so having them support RHAT is a good thing.
Nietsche, Descartes, William James, Plato, Aristotle, and some others in a more minor way.
I think the shallowness of the philosophy in the Matrix makes it so that you can safely say "the Matrix has no philosophical content". It can spark a philosophical discussion, but so can my three-year-old.
The only one of Descartes meditations that made sense was the first one. The rest rested on very large assumptions. Many people in philosophy think that he bunged up the first one as well, but I've never seen someone argue that successfully. It's usually because they assume that Descarte's "I" implies a "soul" with all of it's trappings. If you don't take it as that, I find that the Descarte's first meditation is one of the only self-evident truths, but sadly you can't get beyond that. Descarte tried but failed miserably.
I'm sorry, you think GIMP is bad because it doesn't work on _Windows_? Windows is not it's target operating system. The fact that someone bothered to port it to Windows is a testament of the flexibility of GIMP. The fact that the developers are not concentrating their efforts there does not reflect on the GIMP as a project. Rather, it just means that if you are using GIMP in an unsupported configuration, you get what you get.
GIMP is _extremely_ stable on Linux boxes, and comes pre-installed with most distributions, so most of your argument goes out the Window there. The fact that the GIMP is unintuitive for _you_ means very little for the rest of us. My own biased opinion is that GIMP is extremely easy to use, because it doesn't restrict you to a single frame like Photoshop does. The toolbox/canvas paradigm is intuitive if you're used to it, and actually has a lot of advantages over the MDI paradigm, which even Microsoft is starting to get away from.
It doesn't break every UI convention in the book, it breaks every _Windows_ UI convention in the book. Why? *Gasp* It's not a Windows program.
It seems to me that your little mini-review is an attempt at avoiding the real issues of the capability and usability of the GIMP. Would you think I was fair if I judged Office XP based on it's performance under Wine and how well it meshed with my UNIX desktop? Of course not. Likewise, your review of GIMP on Windows tackled none of the real issues of image manipulation.
Since most of our designers use Windows, they use Photoshop. However, many times if they have to do a similar design for many pieces of text (such as headings, buttons, etc.), we will build scripts for the GIMP to handle them (and no, Photoshop Actions are not intelligent enough for what we are doing). We simply create a file of the text we want and GIMP will autogenerate images into files named using our standard naming conventions.
Anyway, I'm open to disagreement, but your review of the GIMP was very, very poorly done.
As for Mozilla, I can't live without my tabs, my popup Window blocking, or my cookie manager. What do you find lacking in it? Many people in my office have switched to Mozilla.
I can see some people disliking OpenOffice if they've invested heavily in Macros. Personally I love it for it's save as PDF features, and in the new versions I can convert PowerPoint files to Flash with a click of a button - and it is an exact replica of the PPT presentation in 10% of the file size, generally. In addition, OpenOffice handles DocBook quite well (we have many tools based around that), and it's native format is XML. In addition, it doesn't require a separate tool for database access like MS Office does. It also has a decent (but not astounding) vector graphics program with it.
Anyway, I'm sure many people disagree, and have good arguments for doing so. I found yours disingenuous.
If all you have are OEM licenses, you cannot use GHOST:
g ust_IIA_2002.ppt
http://www.microsoft.com/usa/presentations/SAM_Au
FYI - I looked it up - OEM Windows versions do not give you the right to install a GHOSTED Windows onto that machine, even if it's the same version:
g ust_IIA_2002.ppt
http://www.microsoft.com/usa/presentations/SAM_Au