Yeah, I can understand why a lot of Java programmers have formed a deep-seated hatred of XML;-).
I think there are places where XML makes sense and places where it doesn't. Overall though, I share your bias because it all adds up.
Having said that, TestNG's configuration file is almost trivial, especially compared to the XML I'm sure you already deal with if you're using any kind of frameworks, O/RM or any J2EE stuff.
Technically, TestNG does not even require an XML file - but I've found that in practice there's not really any way to avoid it. To me, the things you have to do in TestNG's config file are the types of things that do make sense to put in XML: high level, structural and minimal meta information that is highly subject to change.
I highly recommend at least reading some of the articles about it before passing judgement. On the other hand, if you've never run into any limitations with JUnit, I guess there's no reason to waste your time.
You linked to two opposing articles. One that tries to narrowly define unit testing and then Cedric's critique of that article.
I'm interested, what exactly did you mean? Do you just think that the *term* "unit test" is becoming irrelevant or the actual act of writing unit tests?
Looks like JUnit4 is adopting most of its ideas from TestNG. This is good, as JUnit feels highly constrained and somewhat crippled compared to TestNG, but why even bother with JUnit4? TestNG can run JUnit tests unaltered, so backwards compatibility isn't really an issue.
Unless JUnit is going to add quite a few more features, it still won't be nearly as flexible as TestNG. I think the JUnit developers are stuck on this idea of independent tests, which certainly has its merits but ends up excluding a lot of powerful options or forcing you to use ugly workarounds.
TestNG is more of an all-purpose testing framework, equally adept at unit testing as well as higher level functional testing. As a developer, I want to be able to test things in whatever way fits the task at hand. For instance, sometimes it's easier or arguably makes more sense to test a multi-step process (say, user registration and verification) in a defined order. This is possible with JUnit, but it definitely goes against the grain of the framework, which does not support test dependencies and therefore doesn't support ordered tests. I don't appreciate being penalized by a framework because its developers have a very specific concept of "pure" unit testing.
Perhaps I should elaborate: I'm sure the JUnit developers know far more about unit testing that I do, but I want to write more than just unit tests. I'm perfectly happy to admit to writing functional and acceptance tests (and even tests that talk to a real database) in addition to true, pure unit tests. I understand why the differences should be recognized, but the fact remains that JUnit simply does not accomodate a broader view of testing.
I hate to be critical of something that's brought so much improvement to how we write code (JUnit), but I think we've all learned a lot about unit and other types of testing and it's time to move on to something that embodies those lessons.
That's right, Paris Hilton has now officially joined the long and distinguished list of RoR advocates. Typical of these young yet jaded programmers, she also notes that:
I've never felt the need for Postgres
And she probably never will. During a heated exchange regarding the merits of MySQL vs. more complex databases such as PostgreSQL, Ms. Hilton was reportedly heard to state that:
If you think about it, who really needs referential integrity, stored procedures, triggers, rules, constraints, user-defined data types, schemas, clustered indexes, point in time recovery, physical table partitioning or any of that other complicated stuff? I mean, come on, just learning what those words even mean will, like, totally blow my 10 minute development timeline. All of that stuff is for losers anyway and I heard it fully bloats your LoC - ewww!
I think many of you calling Bill's statements "reasonable" and so on and so forth have completely lost sight of the context in which these responses were given.
What does Bill get paid for? What is his job? Is it to teach others at Microsoft how great Linux and OSS is so that they can help their customers work better with the competition's stuff? No.
Let's enter the reality zone for a moment. In the past, what competitive technologies has Microsoft chosen to support and interoperate with rather than replace with their own? None that I can think of. They interoperate only when - from a business perspective - there is no other choice. Remember the first incarnation of MSN? They wanted to replace the internet because they couldn't control it. Had they been successful, it would have been a brilliant business move. As usual, they were not motivated by "evil" but by a standard business strategy: control the market whenever possible.
Bill's responses here indicate nothing more than a signal that Microsoft may be switching from openly aggressive competition with F/OSS to their old standby, "embrace and extend" (out of existence). Or, as Bill called it "co-opetition". This doesn't make Microsoft or its employees bad, evil, stupid, uninformed or any other negative moniker. It's just business.
Consider this quote from Bill (which I'm surprised made it past the PR filter):
One of my first demos to a high-level executive involved showing some standards-based Linux/Windows interoperability scenarios. I expected to receive an "If it's not built here, then I don't care" kind of response.
I wouldn't expect a PR-filtered response from an MS employee to contain the phrase "Well, of course we intend to stamp Linux out of existence. What do you idiots think we are, a charity?" but Bill *is* essentially saying "I didn't expect that Microsoft would want to interoperate with F/OSS." which, of course, they do not.
You can be certain that MS has and will continue to spend lots of time and money analyzing their current and potential business threats. Thus, a job for Bill. I'll bet one question they've thought about quite a bit is "why are developers willing to spend their time writing free software in the first place?" Among the many and varied answers is one that MS may be particularly concerned with: some OSS developers have a fundamental dislike of MS (why is out of scope for this post) and this dislike helps to form a group identity. If MS can change your minds by saying "we appreciate and support what you are doing" then they take away some of your motivation and help to divide the opposition into some who say "MS is horrible" and others who say "I'm changing my mind, they are not so bad."
I'm not casting judgement on any of these things, only making the observation that these are aspects of "embrace and extend" and "divide and conquer" strageties one uses against an enemy or competitor.
At the end of the day, Linux and amost all F/OSS represents competition to Microsoft - nothing more, nothing less. MS has a well-established track record of fierce aggression (including a willingness to break the law when they see it as a profitable option) and a weak one of "genuine technical curiosity", or whatever Bill called it.
So, you could say this post is a very long-winded version of "I'm calling complete and utter PR bullshit."
I suspect that the motivation behind changing the game was to de-emphasize the growing commercial aspect. If you've attended DefCon in the past few years and watched Capture the Flag, it felt like it was slowly being taken over by corporate teams (several teams were named after their company and/or displayed large company banners in the game area).
This was still a "creeping" influence the last time I attended (not too long ago), but it sure felt like a trend.
I can understand why companies are upset by the change. If I had an OS company, I'd sure love to be able to advertise that my product had been used to win Capture the Flag. Under the current rules, you can't use your own OS so the opportunity for "product placement" is decreased.
Vendors are free to set up their own events for head-to-head product comparisons (and should), but having them at Defcon felt like having a BMW race team show up at a local gearheads' track event. It's not that the non-corporate participants can't compete - it just fundamentally alters the nature of the event.
The best guidance I've found for large-scale PHP development is the book Advanced PHP Programming from George Schlossnagle.
However, not long after reading this book (along with stuff like Fowler's PoEAA) I switched to Java because I realized that all of the large-scale application design and maintenance problems I was trying to solve in PHP were already addressed in various Java tools, frameworks and features of the language itself (highly object-orientated, packages, etc.).
Whether or not Java is the best choice for large-scale systems is debatable. What seems to be more important is Java's position as a de facto standard for such systems. "Cutting edge" or even non-existent concepts in PHP like O/RM, unit testing, caching, OO component-based web development, and so on are mature and commonly used in Java. If you get into truly large-scale, clustered systems, then there is an entire laundry list of mature Java technologies that literally do not extist in PHP: distributed transactions, RMI, clustered caching, session replication (I mean actual session replication - not a central repository), JMX, application servers that deal with cluster deployment and management, etc.
In PHP, you are free to invent these things for yourself or use some of the Java project clones (propel, creole, phing) that don't see much use, but this is a far cry from having widely used, tested and in many cases standardized and vendor supported solutions at your disposal.
My point is that you might consider saving yourself a lot of headaches and "am I the only one trying to do this?" scenarios by switching to Java sooner than later. I can say with near certainty that if you move far enough in the direction of enterprise or large-scale development, you will not be doing it in PHP anyway.
At first I skimmed over the word "leftist" and thought you were describing the religious right.
Hatred, ignorance and blatant stereotypical generalizations are common on both ends of the political spectrum. Although it's sad, it's also hilarious to listen to one "side" cast hypocritical condescension on the other.
It's similar to the fact that fundamentalist Christians honestly don't seem to understand that they are no different than fundamentalist Muslims (for instance). "My God is the true God, you are a heathen. No, my God is the true God, therefore I am somehow superior", etc. ad infinitum.
Do some research. Sophos admitted the the Cowhand/A is another 'proof of concept' virus that has been around for at least a year.
Good luck finding a single incident of 'AplS/Fromr-A' actually infecting anything or even existing and MP3Virus.Gen is a well-known proof of concept that also has not spread in the wild and does not cause any damage.
Some day there will be a bona fide, bad virus for Mac OS X that actually spreads in the wild and causes damage. That day has not yet arrived.
I do insist on a college degree. I don't care what it's in, but I do insist on a college degree
This might be one reason why you are having trouble finding capable programmers. While I also prefer to hire programmers with a college degree I do not *insist* on one. There are roughly three types of people that don't make it through college: 1) people who are too stupid; 2) people who are literally too poor (have to go to work immediately); 3) people who blew their high school's IQ bell curve and couldn't imagine subjecting themselves to another 4 years of institutionalized education that could be more effeciently attained by reading a stack of books over the summer. A number of top-notch, creative programmers fall into category 3. And they are usually more than intelligent enough to put in front of a client.
I'm not putting down the value of a college education, but a gifted, self-taught programmer has a few advantages over someone with a CS degree:
1) little fear of the unknown - no one held their hand to help them understand and put into practice complex subjects in the past, so they feel confident when facing new concepts and challenges.
2) truly interested in computer science - a non-degreed programmer who has reached a high level of competency almost by definition really, really enjoys working with computers and sees computer science as a source of questions to be answered. Intellectual pursuit and attainment is obviously fostered by a true interest in the subject at hand.
3) they have mastered the art of self-learning and continuing education - I would argue that the single most important skill in IT is the ability to find and absorb new information on an ongoing basis.
So, I'm not suggesting that you alter your bias towards college-educated candidates. I'm merely suggesting that you may open yourself up to a pool of truly talented candidates by casting your net a bit wider. You obviously have the ability to thoroughly "tech out" your candidates, so I don't think you're in any danger of accidentally hiring an under-qualified person.
One last thing: a good self-taught programmer usually starts early in life. They probably started in high school or earlier and that may explain why a CS degree seemed "unnecessary".
By the way, I assume you're looking for business programmers here. Most people aren't very good at teaching themselves mathematics, so if the positions you're trying to fill require a deep mathematical background, then nevermind!
Do you honestly believe that the founding fathers encoded violent revolution into the bill of rights?
You mean the same founding fathers who dragged the colonial population into violent revolution against their government (i.e. the British)? Since it would have been the height of hypocrisy to promote violent revolution on one hand while telling the American people that violent revolution is a bad idea on the other, yeah, I'm pretty sure they not only encoded violent revolution into the bill of rights but some of them even elaborated on the idea at length (in various published works available at your local library). Remember - and I can't emphasize this point enough - having recently violently revolted against their own goverment, the idea of violent revolution was sort of a hot topic, and generally met with approval (not surprising as, once again, most of the population had first-hand experience with it).
The promotion of violent revolution was meant to be an endorsement - in no uncertain terms - of the basic idea that government should serve the people rather than the other way around. Seems like a poignant idea even today!
You misunderstood most of my points. For instance, you say that the benchmark tools were run locally (although I don't see in the article where the author clarifies that all tests were local) so their workload does not need to be isolated. What if super smack runs 15% slower on FreeBSD because it is not well-written, portable code and/or has had very little testing on FreeBSD? Since super smack is not a real-world client, that 15% performance difference MUST be isolated (are we disagreeing on the meaning of "isolated" or do you get my point?). In fact this post seems to confirm my suspicion of super smack's poor performance on FreeBSD, and even my initial guess at the percentage.
What would you have him test? Some imaginary database that is developed on FreeBSD and which runs fastest on FreeBSD? OK. Meanwhile, the rest of us will try to get some useful work done.
Alright, calm down tough guy. I can't really see how an imaginary database benchmark would help, but niether do the benchmarks we're discussing now becuase of the all the points I raised in my last post. What would be interesting is to see the tests repeated with the client workload properly isolated by alternately running each benchmark on two different client machines. The client machines would ideally have identical hardware but different OS's (say SUSE and FreeBSD 4.11). An attempt would then be made to tune all TCP/IP stacks (clients and servers) for the highest compatibility. That means only enabling common features (e.g. no SACK because NetBSD doesn't have it) and probably disabling window scaling altogether. Since this is not supposed to be a network benchmark, the goal would be to eliminate network performance variations to hide any networking advantages one OS has over another.
While using MySQL for a benchmark is useful because it is a real world app in every sense, the benchmarks would be far more useful if another similar app such as PostgreSQL was used in addition. This would still not provide anything close to a scientific control to eliminate unknown variations, it would at least be one step closer.
I'll close by mentioning that when I moved the busiest MySQL server that I administer (avg ~ 200 queries/sec) from Red Hat Linux 8 to FreeBSD 4 on a Dell 6650, I saw a drop in load average and CPU utilization of about 20% (same MySQL version and config). There was no noticeable speed difference. So FreeBSD ended up providing a meaningful benefit that would never have been reflected in this or similar benchmarks. All benchmarks have their shortcomings and holes, this one just happens to be especially riddled with them.
Funny, I had the opposite reaction. Considering that he tested optimized Gentoo (I'm assuming it was comiled from source for i686) w/ ReiserFS (isn't it still considered non-standard in Linux?) against binary installations (i.e. compiled for i486) of FreeBSD 4 & 5, I would say that FreeBSD delivered a very strong performance.
Regarding 4 vs. 5: if you consider that many code paths in FreeBSD 5 are considerably more expensive than in 4 due to the fine-grained mutexing, it's impressive that the first truly useable release of 5.x is already keeping up (for the most part) with the simpler, highly uni-processor optimized FreeBSD 4. It was also impressive that KSE delivered roughly the same performance as LinuxThreads, again considering the small amount of time that KSE has been in widespread use.
If you read the FreeBSD developer lists even a little bit, you would find that the focus of work so far has been on laying the foundation for fine-grained SMP and threading to eliminate the scalability cap of FreeBSD 4's fully locked (i.e. non-SMP) kernel. It will take some time before the fruits of that labor result in significantly higher performance (especially in the uni- and dual-processor cases). In some areas (e.g. packet throughput), FreeBSD 5 already trounces FreeBSD 4 and Linux 2.6. In others, the shorter code paths and years of optimization in FreeBSD 4 still can't be beat. This seems quite reasonable to me.
I have to point out just a few of the most significant flaws in these benchmarks in the hope that people will interpret the results appropriately:
1.) The domain socket (i.e. local, non-network) tests were performed using super smack. As the author notes, super smack does not compile out-of-the-box on FreeBSD. That's because it is developed on Linux and (obviously) the author(s) don't test or optimize it for FreeBSD. It's reasonable to assume that it's performance may therefore suffer quite a bit on FreeBSD and no benchmarks were performed to isolate this potential penalty. If you think I'm stretching, consider this: PostgreSQL was (and may still be) primarily developed on FreeBSD. If the development team never tested and optimized it to perform well on Linux, would you consider a PostgreSQL on Linux vs. PostgreSQL on FreeBSD a fair (or even meaningful) benchmark?
2.) While the author fails to clarify whether the sysbench tests were performed remotely or locally, he does mention that he thought sysbench gave meaningful results over the network, so I'm going to go out on a limb and guess that the sysbench results are over a network connection. If the sysbench tests were local, then the same criticism applies as the super smack tests - the benchmarking tool performance and load on each OS must be accounted for so that it may be isolated in the results if they are to have any meaning.
I'm sure you can see where I'm heading but, if any of these benchmarks are remote, we need to know the OS and hardware of the client machine. This is never mentioned. While remote database testing is a good idea in that the benchmark workload is automatically isolated, one must take into account that the benchmarks now reflect network performance between different OS's (assuming the same client machine is used for each test). If careful, informed TCP/IP tuning is not performed on each server to eliminate differences (and the author mentions nothing about this), the OS with the most aggressive default tuning or default tuning that most closely matches the client will certainly show superior results that have nothing to do with MySQL performance. Givens the author's obviously increased familiarity with Linux over the other OS's tested, I would guess that his client machine (if any) was running Gentoo Linux, giving that OS an extreme advantage in network performance. If you're not familiar with FreeBSD, it's default TCP/IP settings are extremely conservative. A good example is the kern.ipc.somaxconn kernel tunable which controls the maximum number of simultaneous TCP connections. It is set to
Interesting - and stark - change of tone, not to mention sig.
In my last reply to you, I said your original comment had "piqued my curiosity", it would be more correct to say that your comment struck me as sincere, and deserving of investigation. For what it's worth (not trying to be condescending), I'll consider any future comments of yours to also be sincere. I think the main reason you've been modded and repeatedly called "troll" is due primarily to the fact that most of us (FreeBSD users) fully expect some issues to come up in 5-STABLE. To make the leap from identifying some of those issues to proclaiming FreeBSD 5 "crap" (or whatever), is just silly and at the very least totally premature (and essentially baseless).
Now that there's an official release, it will receive far more testing and debugging than it has had so far (duh). I doubt that it will be truly production-quality in most sysadmin's eyes until at least a 5.4 or so release (when's the last time you rolled out a brand new major release into production - of *anything*? If you're serious about your work, probably never). In addition, the developers have made it very clear that some regressions would happen and that they have been focused on laying down a *foundation* to provide far better performance and scalability in the future. While this is not a reason to ignore whatever performance issues may exist in the current release, it does seem to be a perfectly reasonable approach. I normally do profiling and performance tuning last in my own applications as well. I'm not a C programmer - just large web/database apps, but I assume this approach is fairly common - lay down a solid foundation that stresses correctness, modularity and scalability, and you normally have many options available to improve performance. I suppose we will find out over the next few months if there are any fundamental problems with the design choices made by the FreeBSD 5 developers. In the meantime, I will continue to be highly skeptical of isolated cries of "FreeBSD is crap."
How odd, I had regressions in disk performance (and not for his reasons), and so did everyone I asked/inspired to try FreeBSD 5 too. We must all be equally unlucky.
I'm not saying that you didn't have a problem. What I'm saying is that, based on user reports that I can find, you seem to be in a small minority and there are several possible explanations for your performance issue that don't include FreeBSD 5.3 being a tangled mess, or however you put it. You're still playing the same game in this post by saying "everyone I asked..." Exactly how many people is that? One? Since "infinite posts" turned out to mean "1 post plus 1 thread (which turned out to demonstrate acceptable if not excellent FreeBSD 5.3 disk performance)", you'll excuse me if I'm inclined to estimate on the low side.
Personally I couldn't care less anymore how your machines run.
If you ever did actually care, you would have posted your issue to a FreeBSD list and sought an answer. You apparently didn't do that. You instead decided to embark on some weird "mission" to convince people that "FreeBSD sucks," which makes you just another "FreeBSD sucks" troll.
Anyone who doesn't bother testing something before saying it rules the planet doesn't deserve to have a well-oiled system.
Because I haven't tested it, and won't have a chance to do so for some time, I pay attention to other users' reports - not as gospel truth, but as an indicator of what issues I need to be aware of and test for myself. In reading through the posts I could find on this topic (essentially that one thread we both looked at - I still haven't found any others), it seems that there are isolated instances of disk performance issues (I believe 1 or 2 others posted to that thread saying "me too" on slow disk performance). The one user who actually followed through and sought out an answer got his problem fixed. The fact that you have characterized this situation as "infinite posts", "many users", and "every benchmark" confirming severe disk performance problems with FreeBSD 5 demonstrates that you're observational skills are severely impaired, thus I take any other claims you might make with a great big grain of salt, and so should others.
Anyone who doesn't bother testing something before saying it rules the planet doesn't deserve to have a well-oiled system. I thought Gentoo ricers were bad.
"Gentoo ricers?" I think that comment speaks for itself. Pretty funny. Look, the only reason I responded to your post was because it piqued my curiosity. I thought "hmmm... this guy sounds convinced - maybe there's a real problem here". I looked into it and I found your claims to be so wildly exaggerated and distorted that I felt compelled to point out the truth - there are not "infinite posts", there are not "many users" experiencing disk performance issues with 5.3 (unless they are keeping it a secret) and the benchmarks you speak of do not exist. So please, do give up, troll.
http://lists.freebsd.org/pipermail/freebsd-current/2004-October/040474.html
That's the first I could find. I had a better one that included OpenBSD as well, which many say has lousy performance but still schooled FreeBSD... I haven't found that link again. I'll keep you posted.
Read that entire thread. It was started by "Fandino." Your link is the original post by Fandino. In my last post, I included this link: http://lists.freebsd.org/pipermail/freebsd-current/2004-October/041767.html, from Fandino, where he acknowleges that his problem is due to hardware. Here's a good one from the same thread - this is Fandino happily getting 52 MB/s on the same setup he was complaining about in his first post. Here is the solution someone on the list provided for him.
If you would take the time to actually read things, maybe you could solve your problem instead of spreading FUD. Learn from Fandino, he was a bit confrontational, but at least he actually sought out a solution to his problem.
But seriously, if you're so smart, why not bench it yourself and prove me (and those other users) wrong?
Again, what other users are you talking about? So far it's you, some guy with an isolated post, and Fandino, who's problem was due to a hardware issue and was solved, so that actually leaves just two users. I'm sure other people have had disk performance problems, given that there are so many changes in 5.x that affect disk I/O (GEOM, etc.). The sane among us assume that problems will arise and be fixed as 5.x matures. In the meantime, there does not appear to be a particular issue with disk performance in most setups. I appreciate that you've aired your compaint and, in fact, when I get closer to rolling out 5.x on my production servers I will pay attention to disk performance by running some benchmarks and wall-clocking real world performance against 4.10. I'm not sure that I or most other FreeBSD users need to be "so smart" in order to accomplish basic testing, but perhaps your comment applies more to you than it does the rest of us.
At least my point has evidence.
It does? Somehow I keep missing that "evidence" part. Perhaps your mindless trolling is drowning out the "evidence."
If you can show me empirical proof that what I and many others are saying is rubbish, I'll take you seriously.
Ditto. And, yet again, where are these mysterious "many others" (and "infinite posts")?
On the other hand, you Googled for "5.3" performance, even knowing 5.3 has been out barely a couple of days now. This problem has been around since much earlier in the 5 branch (exact point escapes me since I only started tracking recently, since late 5.2-CURRENT up to 5.3-STABLE a week or two before release) and if you had Googled for, say, "freebsd 5 slow disk" or something like that, your results might be more interesting. I suggest you try it.
I did try it. The results were no different. I couln't find any reports besides that one isolated post you originally referred to and the thread to which we have both referred. That would be the thread which I suggest you actually read in its entirety. That's right, the thread where Fandino thinks that FreeBSD 5.3 disk performance sucks based on his "benchmarks" but it turns out that his motherboard's disk controllers were set to the wrong speed.
If you would actually seek out help for your disk performance problem, you might find people willing to give it and even appreciative of your problem report. You can expect a hostile and condescending response when you insist that your individual issue is somehow indicative of a general problem with FreeBSD 5.x. It makes you sound like a troll, and we have enough of those already.
If you look closely, you may notice that most of my claims are directly against FreeBSD 5.3 (or often 5.x), except those places where something affects the future and past of FreeBSD (like that kbdcontrol/moused stuff).
This is about the physical limit, plus the extras that caching provides. FreeBSD 5 is about half as fast. This is the consensus - every bench shows it to be so.
"Every bench"? OK, let's see them. Show me even one benchmark that proves your point. If there really is a disk performance problem with 5.3 I want to know about it, but I don't see any evidence. If there is a "consensus", it seems to be that disk performance in 5.3 is fine, and not a big topic of discussion (read below). Again, show me some actual posts, not just your isolated, unsubstantiated (dare I say, "trollish") opinion.
Only one of seemingly infinite posts made on this topic: http://lists.freebsd.org/pipermail/freebsd-current/2004-October/041009.html
I googled on slow disk performance freebsd 5.3 and the post you mention is the first result. It is an isolated post (no replies). I can find an isolated posted saying literally anything - it doesn't mean much. The poster claims to have seen reports of similar problems in the archives, but I can't find them and he doesn't link to any of them. Beyond that one isolated post I could find only one thread on this topic (where are the "seemingly infinite posts made on this topic" to which you refer?). It contains about 50 posts with actual disk performance numbers from many users and what appears to be a substantial effort to analyze the issue. The person who initiated the thread finally agreed that he had a "weird" motherboard and that other users' results contradicted his own: http://lists.freebsd.org/pipermail/freebsd-current/2004-October/041767.html. If you can find anything that contradicts this thread, post the link - don't just tell me about it. And remember, we are talking about issues that exist in 5.3 - I don't need to see discussion of issues that have already been resolved.
There was nothing subtle intended nor implied. I wasn't there when Clinton made the decision not to do anything in Rwanda, and even if I were, I can't read people's minds. Because of those two reasons alone, I could only guess why he didn't do anything.
OK, then to restate my point, I'm sure you won't read anything into it if I say that I can only guess why Bush is making the decision not to do anything about the genocidal atrocities being suffered by thousands upon thousands of Sudanese as we speak.
So what? Precedence has to start somewhere. The US Supreme Court had absolutely no precedence when they decided that prayer didn't belong in school in 1963 (in fact, for a hundred years, the Supremes were on record stating that the Bible should be taught in school). Just because there's no precedence for something doesn't mean it's not right to do it.
I think that's a bad example. You're talking about either Engel v. Vitale in 1962, which banned official, teacher-led, prayer in school or Abington School District v. Schempp in 1963 which held that students could not be forced to recite the Ten Commandments before school. Now I don't pretend to be an expert in this area, but these rulings were based pretty squarely on the First Amendment ("Congress shall make no law respecting an establishment of religion.") and were limited to banning state-sponsored religious practice (i.e. every student is and always has been free to pray in school as long as it is their choice rather than the government's). This is not an instance of precedence starting "out of nowhere" - it's a Constitutional interpretation. Your parenthetical statement about the Bible tries to argue that a contradictory precedent had been established. However, prayer is a religious practice, normally demonstrating an endorsement of a specific religion (I think you're splitting hairs if you want to get into defining "non-denominational prayer" and whether it relates to an "establishment of religion"). Studying the Bible in school can clearly be defended as a worthwhile educational exercise. Even as an atheist, I commonly turn to the New Testament - and even quote it from time to time - as a unique source of profound wisdom and guidance on ethical, moral and philosophical matters. I believe this is essentially what at least one of the Justices you have in mind was talking about. The Bible is also an important source of historical information. Prayer is none of these things. It's the acting out of religious conviction. Therefore, I would argue that previous rulings on the role of the Bible in school have nothing to do with coerced prayer in school. Having said all that, yes, of course precedence does have to start somewhere. It sounds like you're not arguing with the view that Bush has established new precedent with the invasion of Iraq. I'm trying to figure out exactly what that precedent is and what logic it's based on. Many if not most of the key points (WMD stockpiles, ties to Al-Queda, imminent threat to U.S., etc.) presented by Bush as justification have turned out to be false or, at the very least, highly and irresponsibly exaggerated. When our government effects a major shift in war-making policy (i.e. ignores or significantly deviates from the precedent of going to war only to defend the country), it's our duty as well as our right to ask hard questions and demand justification. This is war we're talking about after all, not a tax cut. War, due to the unique sacrifices and suffering it entails, always demands justification.
You asked how -I- justify Bush's actions.
And I thoroughly responsed to each of your justifications, which you are not continuing to defend. Then I moved on to talk about how Bush himself justified the invasion. That's hardly an illogical or misleading "leap" on my part, and it's most definitely not irrelevant.
(By the way... You do notice the date lines on your sources before you post them, right? I noticed just now that one link of yours to USA Today is from March, before the UN found anything in Jordan. Although this does not necessarily discredit this information, it may have been superceeded by other information. Of course, having read it, I wonder: if Iraq did not have WMDs, what did they do with their work into the matter? Surely, one doesn't spend the time and money into researching this sort of weaponry, just to stop and say, "Yeah. That was interesting. What's next on our plate?")
"May have been superceeded"? No, the findings of weapons inspectors in Iraq have not been superseded. The SA-2 rocket parts discovered as scrap metal in Jordan weren't exactly a big surprise to anyone who has been paying attention. I haven't yet heard anyone make the case that this finding contradicts the massive and detailed 13+ years of evidence assembled by weapons inspectors in Iraq. If you are trying to make that case, then you'll have to be quite a bit more specific than the vague statement "Although this does not necessarily discredit this information, it may have been superceeded by other information (what other information?)." Personally, I look to the Bush administration to make this case as it is their integrity which is on the line. I haven't heard them even attempt to do so, have you?
Regarding your second point about Iraq researching WMD and voluntarily ceasing such activity, please point out where I or any of the numerous sources I have linked to ever made such a claim. The point made by David Kay and the other weapons inspectors was that the inspection program had worked and was continuing to work - not that Iraq voluntarily gave up the pursuit of WMD. Let me be frank, do you think the weapons inspectors are complete idiots? Do you believe that your observation that Saddam wouldn't voluntarily decide to give up the pursuit of WMD represents the kind of original thinking of which U.N. weapons inspectors, or anyone with a high school diploma for that matter, are incapable? There's a word for that type of broadside attack on the critical thinking abilities of "everyone else", it's hubris.
You asked about Rwanda. All I can say is that this happened under Bill Clinton, and (according to one of your articles that I am reading now) he realized his mistake. Should something have been done? Certainly. All I can do is guess why Clinton didn't try, so I won't go into that here.
For Sudan, I think that the UN needs to get off their duff and do something about the problem there, before it's too late. From the article at the SundayTimes (that you quoted):
Well, you did "go into it" and managed to weaken your position by betraying a highly partisan opinion (e.g. "All I can do is guess why Clinton didn't try" - gee, maybe he was getting a blow job, or busy being the victim of a Republican witch hunt, or just an evil, Godless man. Your "subtle" inference is blindingly clear). I could play the same game by saying that the U.N. should have done something about Rwanda while Bush is solely to blame for doing nothing in Sudan. But I'm not saying that or even suggesting it - just making a broader point. I brought up Rwanda and Sudan to support the fact that there exists no clear precedent for declaring war based on the prevention of human rights abuses. By contrast, the concept of preemptive war, as expressed by Bush, is a rational one IMO. The problem is that a preemptive war (this is according to the definition I'm familiar with and is in contrast to "preventive" war which entails embarking on military conflict just because you think something might happen - other people reverse the definitions, I have no idea which is "correct") is launched in response t
I'm sure you'll be interested to know that McNamara's views on Iraq are actually on the record in a well-known Canadian paper, the Globe and Mail. He was asked about and confirmed the G&M interview when he gave a speech UC Berkeley. Salon.com picked up the story, and of course sites like disinfopedia.org, bushwatch.com, etc., mentioned and/or linked to the G&M interview - but the mainstream press was suspiciously quiet about it even though no one refutes that the interview or subsequent comments at Berkeley took place.
Re:Bush's "War on Reading" is embraced by Republic
on
Fahrenheit 9/11 Discussion
·
· Score: 2, Informative
It tells me that the site is heavily biased (they even describe themselves as "opinionated", and that they "tell you what we really think and believe about what's happening in the world"), and therefore NOT "news". (Yes, by this standard, I would also probably discount FoxNews.) Do you have other sources, or is this the best you can come up with?
How about this interview with David Kay or this overview of his final report or CNN's coverage, or this detailed report that discusses some of the reasoning behind David Kay's findings. I would have gladly linked to Fox News as well, as these official findings are virtually "unspinnable", but I can't find any Fox News coverage of Kay's final report (it may exist, I'm just saying I couldn't find it with Google - please point it out if you come across it). If you'll recall, Kay's initial, interim report also found no evidence of the type of WMD stockpiles or activities that Bush and Powell claimed we would certainly find in Iraq. However, Kay expressed great optimism that the alleged WMD would indeed be found (this was well covered and emphasized on Fox News) and attributed his lack of evidence to, in essence, timing, as there was still much work ahead at that point. Kay later stated that his initial optimism was based on the same erroneous, disproven "intelligence" that was eventually presented as justification for the invasion of Iraq. David Kay was not the only weapons inspector to carry out the task of finding Iraqi WMD. Remember Hans Blix? I've heard quite a bit of typical, hateful, conservative vitriol spewed in his direction, but I have yet to hear a factual criticism of his professional credentials or a substantive accusation of bias against him. Here is a summary of his findings within the rather enlightening context of current events. There are also the findings of Scott Ritter to consider. Even more despised than Hans Blix, the factual content of his work in Iraq and, again, his professional credentials, have not been effectively challenged. Here is an article he wrote in which he mentions his findings on Iraqi WMD among other topics and an interview in Time magazine in which they ask him some of the "tough" questions (i.e. weak and unsupported personal attacks, as is the Republican habit) his critics have raised. If you want more detailed sources on the findings of any of these weapons inspectors, Google is your friend. I challenge - no, I *defy* you to produce even one credible source (judging from your comment about Fox News, I think we more or less agree on the meaning of "credible") that contradicts the findings of these weapons inspectors. If you can't produce such a counterpoint, you are left with no rational conclusion but to accept that the Bush administration either incompetently or willfully misled the American people and the entire world by claiming that Saddam Hussein posed a threat to the United States when, in fact, he literally had no capability to attack us.
Where shall I begin? How about allowing his sons to torture Iraqi citizens? How about re-routing rivers, to punish villages that spawned political enemies? How about using chemical weapons on Kurdish people in the north? If you think for a moment that allowing such actions to go on unchecked is none of our business, then you're more of an animal than the worst Bush-basher thinks of Bush and the rest of his administration. There are, of course, other reasons involved, but if you need me to tell you what they are, then you haven't bo
Bush's "War on Reading" is embraced by Republicans
on
Fahrenheit 9/11 Discussion
·
· Score: 2, Informative
The U.S.'s own weapons inspectors don't agree with you and insisted that not only could no WMD be found, but that all evidence indicated that no WMD had existed in the first place. Our weapons inspectors are highly trained professionals, quite capable of detecting the traces of WMD storage, their means of production, and evidence of the presence of materials required to support weapons programs in general. The inspectors also enjoyed the benefits of an impending threat of U.S. military action should any doors be closed to them. If you are also a trained weapons inspector with similar resources and access to Iraq, or if you have an informed analysis to offer on the weapons inspectors' findings, I would be interested to hear what you have to say on the matter. However, I suspect you are not an expert on the logistical intricacies of producing and transporting WMD while "hiding" their chemical, biological or radioactive indicators "somewhere in the desert", so I'll stick with the official conclusions if you don't mind.
You refer to the actions of a "Head of State", meaning Saddam Hussein, as justification for the war on Iraq. Specifically, which actions are you talking about? Any and all claims made by the Bush administration that Iraq posed a threat (immediate or otherwise) to the United States have been thoroughly debunked by subsequent uncovering and investigation of the facts. There were no WMD. There were no significant Iraqi ties to Al-Queda (Our "friend" Saudi Arabia, on the other hand, not only tolerates their presence but promotes their extreme religious views in the national education system and refuses to disrupt their funding). If there remains any justifaction for spending further U.S. blood and treasure on this tragic misadventure, please let me in on the secret. I would like to believe that our boys (one of whom is my recently enlisted nephew) are not dying in vain.
Regarding the nature of documentaries: Moore's films are unusual in the sense that, unlike many documentaries, they are mostly outright position pieces. However, that fact does not weaken nor even speak to the content of the film. The term "documentary", as a film genre, means nothing more than "non-fiction", as opposed to fiction or drama. After all, people refer to Errol Morris' films as documentaries without being challenged on that choice of label. Yet Morris' films are hardly of the classic, journalistic, "objective" style. In fact, he employs many of the same cinematic techniques used in main-stream Hollywood pictures but, because his subjects are real people and events rather than actors and fictional screenplays, the result is easily accepted as "documentary", just as Moore's films are. To call something "propoganda" (not that you used the term, this is merely a "preemptive strike", you understand), you have to address its content and show it be in large part untrue. If you can provide some kind of precedent or professional opinion which supports your narrow definition of "documentary" as a work that must provide a counterpoint in addition to a point, I invite you to do so.
You link to an article on typepad.com which claims that John Kerry lied to get one of his three Purple Hearts and that some of his old "buddies" from Vietnam, the Swift Boat Vets for Truth think he's unfit to be President. The SBVFT was formed in May, 2004 and "leadership and guidance were provided by Republican activists and presidential friends from Texas -- notably Houston attorney John E. O'Neill and corporate media consultant Merrie Spaeth", according to Joe Conason of Salon.com. Dr. Louis Letson is the sole source for the Purple Heart story, but he was not the attending physician for the wound in question, according to the Navy's medical records. These are the only sources mentioned in the typepad.com article and both have been thoroughly discredited.
What surprises me a little is that you say you got everything working in FreeBSD (kudos to you, a complete Kerberos + LDAP setup isn't easy IMO) and still decided to go with RedHat. It would make more sense if you had looked into setting this stuff up on FreeBSD, saw that it would be fairly complicated, checked out RedHat authconfig, and said "screw FreeBSD, why should I pull my hair out over this?". You've already done the hard work. Pushing it out to multiple machines is easy.
Did you check out Tracking for Multiple Machines in the FreeBSD Handbook? They mention sharing the ports tree as well as the system source tree, which is one of the keys to easy software management across multiple machines. The other key is portupgrade and its pkgtools.conf file which allows you to record your port customizations and have them automatically applied when you install or upgrade software. portupgrade also makes it incredibly easy to build binary packages for stuff you don't want/need to compile on each machine. Like a lot of things in FreeBSD, it's sort of a "suffer once" proposition requiring more configuration work up front (than e.g. RedHat Linux) but easier administration in the long run plus the advantages of building from source. RedHat is almost the exact opposite - easy to get up and running but diffucult to customize because that often means moving away from RPMs which, in turn, can mean that RedHat's nifty config tools won't work because your custom source build wants to install with a different layout than the "official" RedHat RPM.
I assume you didn't run out and buy a copy of "Automating UNIX and Linux Administration", but the techniques described there would solve your "dozens of files to edit" problem - a problem you will undoubtedly encounter with RedHat as well at some point. Using automation techniques, I can bring up a server from bare metal to fully operational with dozens of custom configuration files, properly configured kernel and software built to my or my clients' needs in about an hour (~20 minutes of actual, interactive "work"). Besides saving a lot of time, this approach ensures consistency across a server farm and encourages you to make changes based on their relative merit rather than the amount of labor involved.
I doubt that my experience is normal by any stretch
No, I meant your decision to use RedHat because it is easier to get up and running while *BSD generally requires more effort and knowlege for initial deployment but is, IMO, easier to admin in the long run.
I run an OS X Network... with some Unix servers, and my Unix Servers need to play nicely with my OS X Server.
Maybe I don't get what you mean by "play nicely" but, in my experience FreeBSD plays better with OS X than RedHat since so many of the user binaries are the same. You'll find that most commands (and their man pages) are identical, which is not the case between OS X and Linux of any flavor.
However, it is typical in that even if you evaluate FreeBSD because it's "better," the fact is it doesn't function like any NOS that IT people are familiar with.
I get your point, but it's kind of funny when you consider that BSD is in many ways the "original" NOS - at least when it comes to TCP/IP. As you infer, this is more a statement of experience and perception than anything else. If your background was in Solaris or other commercial UNIXes, you would feel just the opposite. Having said that, your background is probably representative of more people overall than would be, say, an AIX sysadmin's. My own backgound is more or less normal, "corporate IT" but I (as I'm sure is painfully obvious) would have opted for FreeBSD in your situation, especially if you're talking about a half-dozen or more machines here.
Getting the machines to talk to our LDAP Server and Kerberos KDC (an OS X Server that does our central directory system) is a joke...
Which machines, RedHat or BSD? And does "joke" mean "difficult"?
It sounds like you tried to make a reasonable decision based on your needs and situation, but you don't mention any specific problems you had with your BSD machines. You mention that OpenBSD "just didn't perform", but (IMO) you should only be using OpenBSD if you have already found that the vastly more popular and better performing FreeBSD does not suit your security needs (I think it's safe to say that most sysadmins relegate OpenBSD to running firewalls and lower-traffic dedicated systems). If you're running multiple servers, you should read this section of the FreeBSD Handbook about multi-machine setup. You should also invest in a copy of Automating Unix and Linux Administration and, if you want a good introduction to "real world" FreeBSD administration, you can't beat Absolute BSD - I still refer to this friendly and straightforward book constantly.
The worst thing about a BSD is how streamlined/stripped down the core is, as making network configuration changes is just harder/more time-consuming, with multiple files to change.
Again, your problem with BSD would be more clear if you gave an actual example. For instance, if by "network configuration" you mean changing the basic network paramaters like IP address, subnet mask, default router, etc., there are actually *fewer* files to change under BSD (it's all in rc.conf) vs. the unnecessarily complex per-interface config files used by RedHat. Both systems have the traditional hosts and resolv.conf files, so there is no difference there. Perhaps you are referring to some custom RedHat administration program that edits the config files for you. One reason that such things (for the most part) don't exist in BSD is that the BSD config file layout is so clear and simple that they are just not needed. Also, if memory serves, to install those fancy RedHat admin tools, you have to install X (even you only want the command-line versions) which is of course a ridiculous and, IMO, unacceptable requirement.
Anyway, I would enjoy reading your response and trying to find out if your choice of RedHat was based on actual advantages provided by RedHat or a lack of experience with BSD. Although I am admittedly part of the "elite" FreeBSD user base, please don't mistake any part of this post for OS-bashing or other petty stuff. I'm interested in your experience because I think it's probably representative of many others who decide that RedHat is easier to use than *BSD.
Nice way to start a comment - a ridiculous stereotype labelling the entire OSS community as ignorant. Not that you deserve a response after that but...
If you would bother to actually read the posts here you would find that, except for a few fringe opinions, most of us are advocating a reasonable approach to broadcast licensing under the current FCC. Specifically, a system which takes into account the rights of individual citizens (who, by the way, legally own the radio spectrum in the first place) alongside the needs of commercial broadcasting. In other words, we don't want to abolish regulation, we want to be protected by it.
If, at the risk of upsetting your black-and-white stereotypical views, you actually researched the subject you would find that the FCC itself advocates the granting of thousands of LPFM licenses but has been overruled by corporate media lobbyists in congress. Search the posts to find supporting references - I wouldn't want to deprive you of the sorely needed mental exercise you will gain by reading some of the more detailed posts on this subject.
Slashdot Mirror
Yeah, I can understand why a lot of Java programmers have formed a deep-seated hatred of XML ;-).
I think there are places where XML makes sense and places where it doesn't. Overall though, I share your bias because it all adds up.
Having said that, TestNG's configuration file is almost trivial, especially compared to the XML I'm sure you already deal with if you're using any kind of frameworks, O/RM or any J2EE stuff.
Technically, TestNG does not even require an XML file - but I've found that in practice there's not really any way to avoid it. To me, the things you have to do in TestNG's config file are the types of things that do make sense to put in XML: high level, structural and minimal meta information that is highly subject to change.
I highly recommend at least reading some of the articles about it before passing judgement. On the other hand, if you've never run into any limitations with JUnit, I guess there's no reason to waste your time.
You linked to two opposing articles. One that tries to narrowly define unit testing and then Cedric's critique of that article. I'm interested, what exactly did you mean? Do you just think that the *term* "unit test" is becoming irrelevant or the actual act of writing unit tests?
Looks like JUnit4 is adopting most of its ideas from TestNG. This is good, as JUnit feels highly constrained and somewhat crippled compared to TestNG, but why even bother with JUnit4? TestNG can run JUnit tests unaltered, so backwards compatibility isn't really an issue.
Unless JUnit is going to add quite a few more features, it still won't be nearly as flexible as TestNG. I think the JUnit developers are stuck on this idea of independent tests, which certainly has its merits but ends up excluding a lot of powerful options or forcing you to use ugly workarounds.
TestNG is more of an all-purpose testing framework, equally adept at unit testing as well as higher level functional testing. As a developer, I want to be able to test things in whatever way fits the task at hand. For instance, sometimes it's easier or arguably makes more sense to test a multi-step process (say, user registration and verification) in a defined order. This is possible with JUnit, but it definitely goes against the grain of the framework, which does not support test dependencies and therefore doesn't support ordered tests. I don't appreciate being penalized by a framework because its developers have a very specific concept of "pure" unit testing.
Perhaps I should elaborate: I'm sure the JUnit developers know far more about unit testing that I do, but I want to write more than just unit tests. I'm perfectly happy to admit to writing functional and acceptance tests (and even tests that talk to a real database) in addition to true, pure unit tests. I understand why the differences should be recognized, but the fact remains that JUnit simply does not accomodate a broader view of testing.
I hate to be critical of something that's brought so much improvement to how we write code (JUnit), but I think we've all learned a lot about unit and other types of testing and it's time to move on to something that embodies those lessons.
What does Bill get paid for? What is his job? Is it to teach others at Microsoft how great Linux and OSS is so that they can help their customers work better with the competition's stuff? No.
Let's enter the reality zone for a moment. In the past, what competitive technologies has Microsoft chosen to support and interoperate with rather than replace with their own? None that I can think of. They interoperate only when - from a business perspective - there is no other choice. Remember the first incarnation of MSN? They wanted to replace the internet because they couldn't control it. Had they been successful, it would have been a brilliant business move. As usual, they were not motivated by "evil" but by a standard business strategy: control the market whenever possible.
Bill's responses here indicate nothing more than a signal that Microsoft may be switching from openly aggressive competition with F/OSS to their old standby, "embrace and extend" (out of existence). Or, as Bill called it "co-opetition". This doesn't make Microsoft or its employees bad, evil, stupid, uninformed or any other negative moniker. It's just business.
Consider this quote from Bill (which I'm surprised made it past the PR filter):
I wouldn't expect a PR-filtered response from an MS employee to contain the phrase "Well, of course we intend to stamp Linux out of existence. What do you idiots think we are, a charity?" but Bill *is* essentially saying "I didn't expect that Microsoft would want to interoperate with F/OSS." which, of course, they do not.
You can be certain that MS has and will continue to spend lots of time and money analyzing their current and potential business threats. Thus, a job for Bill. I'll bet one question they've thought about quite a bit is "why are developers willing to spend their time writing free software in the first place?" Among the many and varied answers is one that MS may be particularly concerned with: some OSS developers have a fundamental dislike of MS (why is out of scope for this post) and this dislike helps to form a group identity. If MS can change your minds by saying "we appreciate and support what you are doing" then they take away some of your motivation and help to divide the opposition into some who say "MS is horrible" and others who say "I'm changing my mind, they are not so bad."
I'm not casting judgement on any of these things, only making the observation that these are aspects of "embrace and extend" and "divide and conquer" strageties one uses against an enemy or competitor.
At the end of the day, Linux and amost all F/OSS represents competition to Microsoft - nothing more, nothing less. MS has a well-established track record of fierce aggression (including a willingness to break the law when they see it as a profitable option) and a weak one of "genuine technical curiosity", or whatever Bill called it.
So, you could say this post is a very long-winded version of "I'm calling complete and utter PR bullshit."
I suspect that the motivation behind changing the game was to de-emphasize the growing commercial aspect. If you've attended DefCon in the past few years and watched Capture the Flag, it felt like it was slowly being taken over by corporate teams (several teams were named after their company and/or displayed large company banners in the game area).
This was still a "creeping" influence the last time I attended (not too long ago), but it sure felt like a trend.
I can understand why companies are upset by the change. If I had an OS company, I'd sure love to be able to advertise that my product had been used to win Capture the Flag. Under the current rules, you can't use your own OS so the opportunity for "product placement" is decreased.
Vendors are free to set up their own events for head-to-head product comparisons (and should), but having them at Defcon felt like having a BMW race team show up at a local gearheads' track event. It's not that the non-corporate participants can't compete - it just fundamentally alters the nature of the event.
The best guidance I've found for large-scale PHP development is the book Advanced PHP Programming from George Schlossnagle.
However, not long after reading this book (along with stuff like Fowler's PoEAA) I switched to Java because I realized that all of the large-scale application design and maintenance problems I was trying to solve in PHP were already addressed in various Java tools, frameworks and features of the language itself (highly object-orientated, packages, etc.).
Whether or not Java is the best choice for large-scale systems is debatable. What seems to be more important is Java's position as a de facto standard for such systems. "Cutting edge" or even non-existent concepts in PHP like O/RM, unit testing, caching, OO component-based web development, and so on are mature and commonly used in Java. If you get into truly large-scale, clustered systems, then there is an entire laundry list of mature Java technologies that literally do not extist in PHP: distributed transactions, RMI, clustered caching, session replication (I mean actual session replication - not a central repository), JMX, application servers that deal with cluster deployment and management, etc.
In PHP, you are free to invent these things for yourself or use some of the Java project clones (propel, creole, phing) that don't see much use, but this is a far cry from having widely used, tested and in many cases standardized and vendor supported solutions at your disposal.
My point is that you might consider saving yourself a lot of headaches and "am I the only one trying to do this?" scenarios by switching to Java sooner than later. I can say with near certainty that if you move far enough in the direction of enterprise or large-scale development, you will not be doing it in PHP anyway.
At first I skimmed over the word "leftist" and thought you were describing the religious right.
Hatred, ignorance and blatant stereotypical generalizations are common on both ends of the political spectrum. Although it's sad, it's also hilarious to listen to one "side" cast hypocritical condescension on the other.
It's similar to the fact that fundamentalist Christians honestly don't seem to understand that they are no different than fundamentalist Muslims (for instance). "My God is the true God, you are a heathen. No, my God is the true God, therefore I am somehow superior", etc. ad infinitum.
Do some research. Sophos admitted the the Cowhand/A is another 'proof of concept' virus that has been around for at least a year.
Good luck finding a single incident of 'AplS/Fromr-A' actually infecting anything or even existing and MP3Virus.Gen is a well-known proof of concept that also has not spread in the wild and does not cause any damage.
Some day there will be a bona fide, bad virus for Mac OS X that actually spreads in the wild and causes damage. That day has not yet arrived.
This might be one reason why you are having trouble finding capable programmers. While I also prefer to hire programmers with a college degree I do not *insist* on one. There are roughly three types of people that don't make it through college: 1) people who are too stupid; 2) people who are literally too poor (have to go to work immediately); 3) people who blew their high school's IQ bell curve and couldn't imagine subjecting themselves to another 4 years of institutionalized education that could be more effeciently attained by reading a stack of books over the summer. A number of top-notch, creative programmers fall into category 3. And they are usually more than intelligent enough to put in front of a client.
I'm not putting down the value of a college education, but a gifted, self-taught programmer has a few advantages over someone with a CS degree:
1) little fear of the unknown - no one held their hand to help them understand and put into practice complex subjects in the past, so they feel confident when facing new concepts and challenges.
2) truly interested in computer science - a non-degreed programmer who has reached a high level of competency almost by definition really, really enjoys working with computers and sees computer science as a source of questions to be answered. Intellectual pursuit and attainment is obviously fostered by a true interest in the subject at hand.
3) they have mastered the art of self-learning and continuing education - I would argue that the single most important skill in IT is the ability to find and absorb new information on an ongoing basis.
So, I'm not suggesting that you alter your bias towards college-educated candidates. I'm merely suggesting that you may open yourself up to a pool of truly talented candidates by casting your net a bit wider. You obviously have the ability to thoroughly "tech out" your candidates, so I don't think you're in any danger of accidentally hiring an under-qualified person.
One last thing: a good self-taught programmer usually starts early in life. They probably started in high school or earlier and that may explain why a CS degree seemed "unnecessary".
By the way, I assume you're looking for business programmers here. Most people aren't very good at teaching themselves mathematics, so if the positions you're trying to fill require a deep mathematical background, then nevermind!
The promotion of violent revolution was meant to be an endorsement - in no uncertain terms - of the basic idea that government should serve the people rather than the other way around. Seems like a poignant idea even today!
Alright, calm down tough guy. I can't really see how an imaginary database benchmark would help, but niether do the benchmarks we're discussing now becuase of the all the points I raised in my last post. What would be interesting is to see the tests repeated with the client workload properly isolated by alternately running each benchmark on two different client machines. The client machines would ideally have identical hardware but different OS's (say SUSE and FreeBSD 4.11). An attempt would then be made to tune all TCP/IP stacks (clients and servers) for the highest compatibility. That means only enabling common features (e.g. no SACK because NetBSD doesn't have it) and probably disabling window scaling altogether. Since this is not supposed to be a network benchmark, the goal would be to eliminate network performance variations to hide any networking advantages one OS has over another.
While using MySQL for a benchmark is useful because it is a real world app in every sense, the benchmarks would be far more useful if another similar app such as PostgreSQL was used in addition. This would still not provide anything close to a scientific control to eliminate unknown variations, it would at least be one step closer.
I'll close by mentioning that when I moved the busiest MySQL server that I administer (avg ~ 200 queries/sec) from Red Hat Linux 8 to FreeBSD 4 on a Dell 6650, I saw a drop in load average and CPU utilization of about 20% (same MySQL version and config). There was no noticeable speed difference. So FreeBSD ended up providing a meaningful benefit that would never have been reflected in this or similar benchmarks. All benchmarks have their shortcomings and holes, this one just happens to be especially riddled with them.
Funny, I had the opposite reaction. Considering that he tested optimized Gentoo (I'm assuming it was comiled from source for i686) w/ ReiserFS (isn't it still considered non-standard in Linux?) against binary installations (i.e. compiled for i486) of FreeBSD 4 & 5, I would say that FreeBSD delivered a very strong performance.
Regarding 4 vs. 5: if you consider that many code paths in FreeBSD 5 are considerably more expensive than in 4 due to the fine-grained mutexing, it's impressive that the first truly useable release of 5.x is already keeping up (for the most part) with the simpler, highly uni-processor optimized FreeBSD 4. It was also impressive that KSE delivered roughly the same performance as LinuxThreads, again considering the small amount of time that KSE has been in widespread use.
If you read the FreeBSD developer lists even a little bit, you would find that the focus of work so far has been on laying the foundation for fine-grained SMP and threading to eliminate the scalability cap of FreeBSD 4's fully locked (i.e. non-SMP) kernel. It will take some time before the fruits of that labor result in significantly higher performance (especially in the uni- and dual-processor cases). In some areas (e.g. packet throughput), FreeBSD 5 already trounces FreeBSD 4 and Linux 2.6. In others, the shorter code paths and years of optimization in FreeBSD 4 still can't be beat. This seems quite reasonable to me.
I have to point out just a few of the most significant flaws in these benchmarks in the hope that people will interpret the results appropriately:
1.) The domain socket (i.e. local, non-network) tests were performed using super smack. As the author notes, super smack does not compile out-of-the-box on FreeBSD. That's because it is developed on Linux and (obviously) the author(s) don't test or optimize it for FreeBSD. It's reasonable to assume that it's performance may therefore suffer quite a bit on FreeBSD and no benchmarks were performed to isolate this potential penalty. If you think I'm stretching, consider this: PostgreSQL was (and may still be) primarily developed on FreeBSD. If the development team never tested and optimized it to perform well on Linux, would you consider a PostgreSQL on Linux vs. PostgreSQL on FreeBSD a fair (or even meaningful) benchmark?
2.) While the author fails to clarify whether the sysbench tests were performed remotely or locally, he does mention that he thought sysbench gave meaningful results over the network, so I'm going to go out on a limb and guess that the sysbench results are over a network connection. If the sysbench tests were local, then the same criticism applies as the super smack tests - the benchmarking tool performance and load on each OS must be accounted for so that it may be isolated in the results if they are to have any meaning.
I'm sure you can see where I'm heading but, if any of these benchmarks are remote, we need to know the OS and hardware of the client machine. This is never mentioned. While remote database testing is a good idea in that the benchmark workload is automatically isolated, one must take into account that the benchmarks now reflect network performance between different OS's (assuming the same client machine is used for each test). If careful, informed TCP/IP tuning is not performed on each server to eliminate differences (and the author mentions nothing about this), the OS with the most aggressive default tuning or default tuning that most closely matches the client will certainly show superior results that have nothing to do with MySQL performance. Givens the author's obviously increased familiarity with Linux over the other OS's tested, I would guess that his client machine (if any) was running Gentoo Linux, giving that OS an extreme advantage in network performance. If you're not familiar with FreeBSD, it's default TCP/IP settings are extremely conservative. A good example is the kern.ipc.somaxconn kernel tunable which controls the maximum number of simultaneous TCP connections. It is set to
Interesting - and stark - change of tone, not to mention sig.
In my last reply to you, I said your original comment had "piqued my curiosity", it would be more correct to say that your comment struck me as sincere, and deserving of investigation. For what it's worth (not trying to be condescending), I'll consider any future comments of yours to also be sincere. I think the main reason you've been modded and repeatedly called "troll" is due primarily to the fact that most of us (FreeBSD users) fully expect some issues to come up in 5-STABLE. To make the leap from identifying some of those issues to proclaiming FreeBSD 5 "crap" (or whatever), is just silly and at the very least totally premature (and essentially baseless).
Now that there's an official release, it will receive far more testing and debugging than it has had so far (duh). I doubt that it will be truly production-quality in most sysadmin's eyes until at least a 5.4 or so release (when's the last time you rolled out a brand new major release into production - of *anything*? If you're serious about your work, probably never). In addition, the developers have made it very clear that some regressions would happen and that they have been focused on laying down a *foundation* to provide far better performance and scalability in the future. While this is not a reason to ignore whatever performance issues may exist in the current release, it does seem to be a perfectly reasonable approach. I normally do profiling and performance tuning last in my own applications as well. I'm not a C programmer - just large web/database apps, but I assume this approach is fairly common - lay down a solid foundation that stresses correctness, modularity and scalability, and you normally have many options available to improve performance. I suppose we will find out over the next few months if there are any fundamental problems with the design choices made by the FreeBSD 5 developers. In the meantime, I will continue to be highly skeptical of isolated cries of "FreeBSD is crap."
You're still playing the same game in this post by saying "everyone I asked..." Exactly how many people is that? One? Since "infinite posts" turned out to mean "1 post plus 1 thread (which turned out to demonstrate acceptable if not excellent FreeBSD 5.3 disk performance)", you'll excuse me if I'm inclined to estimate on the low side.
If you ever did actually care, you would have posted your issue to a FreeBSD list and sought an answer. You apparently didn't do that. You instead decided to embark on some weird "mission" to convince people that "FreeBSD sucks," which makes you just another "FreeBSD sucks" troll.
Because I haven't tested it, and won't have a chance to do so for some time, I pay attention to other users' reports - not as gospel truth, but as an indicator of what issues I need to be aware of and test for myself. In reading through the posts I could find on this topic (essentially that one thread we both looked at - I still haven't found any others), it seems that there are isolated instances of disk performance issues (I believe 1 or 2 others posted to that thread saying "me too" on slow disk performance). The one user who actually followed through and sought out an answer got his problem fixed. The fact that you have characterized this situation as "infinite posts", "many users", and "every benchmark" confirming severe disk performance problems with FreeBSD 5 demonstrates that you're observational skills are severely impaired, thus I take any other claims you might make with a great big grain of salt, and so should others.
"Gentoo ricers?" I think that comment speaks for itself. Pretty funny. Look, the only reason I responded to your post was because it piqued my curiosity. I thought "hmmm... this guy sounds convinced - maybe there's a real problem here". I looked into it and I found your claims to be so wildly exaggerated and distorted that I felt compelled to point out the truth - there are not "infinite posts", there are not "many users" experiencing disk performance issues with 5.3 (unless they are keeping it a secret) and the benchmarks you speak of do not exist. So please, do give up, troll.
If you would take the time to actually read things, maybe you could solve your problem instead of spreading FUD. Learn from Fandino, he was a bit confrontational, but at least he actually sought out a solution to his problem.
Again, what other users are you talking about? So far it's you, some guy with an isolated post, and Fandino, who's problem was due to a hardware issue and was solved, so that actually leaves just two users. I'm sure other people have had disk performance problems, given that there are so many changes in 5.x that affect disk I/O (GEOM, etc.). The sane among us assume that problems will arise and be fixed as 5.x matures. In the meantime, there does not appear to be a particular issue with disk performance in most setups. I appreciate that you've aired your compaint and, in fact, when I get closer to rolling out 5.x on my production servers I will pay attention to disk performance by running some benchmarks and wall-clocking real world performance against 4.10. I'm not sure that I or most other FreeBSD users need to be "so smart" in order to accomplish basic testing, but perhaps your comment applies more to you than it does the rest of us.
It does? Somehow I keep missing that "evidence" part. Perhaps your mindless trolling is drowning out the "evidence."
Ditto. And, yet again, where are these mysterious "many others" (and "infinite posts")?
I did try it. The results were no different. I couln't find any reports besides that one isolated post you originally referred to and the thread to which we have both referred. That would be the thread which I suggest you actually read in its entirety. That's right, the thread where Fandino thinks that FreeBSD 5.3 disk performance sucks based on his "benchmarks" but it turns out that his motherboard's disk controllers were set to the wrong speed.
If you would actually seek out help for your disk performance problem, you might find people willing to give it and even appreciative of your problem report. You can expect a hostile and condescending response when you insist that your individual issue is somehow indicative of a general problem with FreeBSD 5.x. It makes you sound like a troll, and we have enough of those already.
OK, then to restate my point, I'm sure you won't read anything into it if I say that I can only guess why Bush is making the decision not to do anything about the genocidal atrocities being suffered by thousands upon thousands of Sudanese as we speak.
I think that's a bad example.
You're talking about either Engel v. Vitale in 1962, which banned official, teacher-led, prayer in school or Abington School District v. Schempp in 1963 which held that students could not be forced to recite the Ten Commandments before school. Now I don't pretend to be an expert in this area, but these rulings were based pretty squarely on the First Amendment ("Congress shall make no law respecting an establishment of religion.") and were limited to banning state-sponsored religious practice (i.e. every student is and always has been free to pray in school as long as it is their choice rather than the government's). This is not an instance of precedence starting "out of nowhere" - it's a Constitutional interpretation. Your parenthetical statement about the Bible tries to argue that a contradictory precedent had been established. However, prayer is a religious practice, normally demonstrating an endorsement of a specific religion (I think you're splitting hairs if you want to get into defining "non-denominational prayer" and whether it relates to an "establishment of religion"). Studying the Bible in school can clearly be defended as a worthwhile educational exercise. Even as an atheist, I commonly turn to the New Testament - and even quote it from time to time - as a unique source of profound wisdom and guidance on ethical, moral and philosophical matters. I believe this is essentially what at least one of the Justices you have in mind was talking about. The Bible is also an important source of historical information. Prayer is none of these things. It's the acting out of religious conviction. Therefore, I would argue that previous rulings on the role of the Bible in school have nothing to do with coerced prayer in school.
Having said all that, yes, of course precedence does have to start somewhere. It sounds like you're not arguing with the view that Bush has established new precedent with the invasion of Iraq. I'm trying to figure out exactly what that precedent is and what logic it's based on. Many if not most of the key points (WMD stockpiles, ties to Al-Queda, imminent threat to U.S., etc.) presented by Bush as justification have turned out to be false or, at the very least, highly and irresponsibly exaggerated. When our government effects a major shift in war-making policy (i.e. ignores or significantly deviates from the precedent of going to war only to defend the country), it's our duty as well as our right to ask hard questions and demand justification. This is war we're talking about after all, not a tax cut. War, due to the unique sacrifices and suffering it entails, always demands justification.
And I thoroughly responsed to each of your justifications, which you are not continuing to defend. Then I moved on to talk about how Bush himself justified the invasion. That's hardly an illogical or misleading "leap" on my part, and it's most definitely not irrelevant.
"May have been superceeded"? No, the findings of weapons inspectors in Iraq have not been superseded. The SA-2 rocket parts discovered as scrap metal in Jordan weren't exactly a big surprise to anyone who has been paying attention. I haven't yet heard anyone make the case that this finding contradicts the massive and detailed 13+ years of evidence assembled by weapons inspectors in Iraq. If you are trying to make that case, then you'll have to be quite a bit more specific than the vague statement "Although this does not necessarily discredit this information, it may have been superceeded by other information (what other information?)." Personally, I look to the Bush administration to make this case as it is their integrity which is on the line. I haven't heard them even attempt to do so, have you?
Regarding your second point about Iraq researching WMD and voluntarily ceasing such activity, please point out where I or any of the numerous sources I have linked to ever made such a claim. The point made by David Kay and the other weapons inspectors was that the inspection program had worked and was continuing to work - not that Iraq voluntarily gave up the pursuit of WMD. Let me be frank, do you think the weapons inspectors are complete idiots? Do you believe that your observation that Saddam wouldn't voluntarily decide to give up the pursuit of WMD represents the kind of original thinking of which U.N. weapons inspectors, or anyone with a high school diploma for that matter, are incapable? There's a word for that type of broadside attack on the critical thinking abilities of "everyone else", it's hubris.
Well, you did "go into it" and managed to weaken your position by betraying a highly partisan opinion (e.g. "All I can do is guess why Clinton didn't try" - gee, maybe he was getting a blow job, or busy being the victim of a Republican witch hunt, or just an evil, Godless man. Your "subtle" inference is blindingly clear). I could play the same game by saying that the U.N. should have done something about Rwanda while Bush is solely to blame for doing nothing in Sudan. But I'm not saying that or even suggesting it - just making a broader point. I brought up Rwanda and Sudan to support the fact that there exists no clear precedent for declaring war based on the prevention of human rights abuses. By contrast, the concept of preemptive war, as expressed by Bush, is a rational one IMO. The problem is that a preemptive war (this is according to the definition I'm familiar with and is in contrast to "preventive" war which entails embarking on military conflict just because you think something might happen - other people reverse the definitions, I have no idea which is "correct") is launched in response t
Thanks for the kind words.
I'm sure you'll be interested to know that McNamara's views on Iraq are actually on the record in a well-known Canadian paper, the Globe and Mail. He was asked about and confirmed the G&M interview when he gave a speech UC Berkeley. Salon.com picked up the story, and of course sites like disinfopedia.org, bushwatch.com, etc., mentioned and/or linked to the G&M interview - but the mainstream press was suspiciously quiet about it even though no one refutes that the interview or subsequent comments at Berkeley took place.
How about this interview with David Kay or this overview of his final report or CNN's coverage, or this detailed report that discusses some of the reasoning behind David Kay's findings. I would have gladly linked to Fox News as well, as these official findings are virtually "unspinnable", but I can't find any Fox News coverage of Kay's final report (it may exist, I'm just saying I couldn't find it with Google - please point it out if you come across it). If you'll recall, Kay's initial, interim report also found no evidence of the type of WMD stockpiles or activities that Bush and Powell claimed we would certainly find in Iraq. However, Kay expressed great optimism that the alleged WMD would indeed be found (this was well covered and emphasized on Fox News) and attributed his lack of evidence to, in essence, timing, as there was still much work ahead at that point. Kay later stated that his initial optimism was based on the same erroneous, disproven "intelligence" that was eventually presented as justification for the invasion of Iraq. David Kay was not the only weapons inspector to carry out the task of finding Iraqi WMD. Remember Hans Blix? I've heard quite a bit of typical, hateful, conservative vitriol spewed in his direction, but I have yet to hear a factual criticism of his professional credentials or a substantive accusation of bias against him. Here is a summary of his findings within the rather enlightening context of current events. There are also the findings of Scott Ritter to consider. Even more despised than Hans Blix, the factual content of his work in Iraq and, again, his professional credentials, have not been effectively challenged. Here is an article he wrote in which he mentions his findings on Iraqi WMD among other topics and an interview in Time magazine in which they ask him some of the "tough" questions (i.e. weak and unsupported personal attacks, as is the Republican habit) his critics have raised. If you want more detailed sources on the findings of any of these weapons inspectors, Google is your friend. I challenge - no, I *defy* you to produce even one credible source (judging from your comment about Fox News, I think we more or less agree on the meaning of "credible") that contradicts the findings of these weapons inspectors. If you can't produce such a counterpoint, you are left with no rational conclusion but to accept that the Bush administration either incompetently or willfully misled the American people and the entire world by claiming that Saddam Hussein posed a threat to the United States when, in fact, he literally had no capability to attack us.
The U.S.'s own weapons inspectors don't agree with you and insisted that not only could no WMD be found, but that all evidence indicated that no WMD had existed in the first place. Our weapons inspectors are highly trained professionals, quite capable of detecting the traces of WMD storage, their means of production, and evidence of the presence of materials required to support weapons programs in general. The inspectors also enjoyed the benefits of an impending threat of U.S. military action should any doors be closed to them. If you are also a trained weapons inspector with similar resources and access to Iraq, or if you have an informed analysis to offer on the weapons inspectors' findings, I would be interested to hear what you have to say on the matter. However, I suspect you are not an expert on the logistical intricacies of producing and transporting WMD while "hiding" their chemical, biological or radioactive indicators "somewhere in the desert", so I'll stick with the official conclusions if you don't mind.
You refer to the actions of a "Head of State", meaning Saddam Hussein, as justification for the war on Iraq. Specifically, which actions are you talking about? Any and all claims made by the Bush administration that Iraq posed a threat (immediate or otherwise) to the United States have been thoroughly debunked by subsequent uncovering and investigation of the facts. There were no WMD. There were no significant Iraqi ties to Al-Queda (Our "friend" Saudi Arabia, on the other hand, not only tolerates their presence but promotes their extreme religious views in the national education system and refuses to disrupt their funding). If there remains any justifaction for spending further U.S. blood and treasure on this tragic misadventure, please let me in on the secret. I would like to believe that our boys (one of whom is my recently enlisted nephew) are not dying in vain.
Regarding the nature of documentaries: Moore's films are unusual in the sense that, unlike many documentaries, they are mostly outright position pieces. However, that fact does not weaken nor even speak to the content of the film. The term "documentary", as a film genre, means nothing more than "non-fiction", as opposed to fiction or drama. After all, people refer to Errol Morris' films as documentaries without being challenged on that choice of label. Yet Morris' films are hardly of the classic, journalistic, "objective" style. In fact, he employs many of the same cinematic techniques used in main-stream Hollywood pictures but, because his subjects are real people and events rather than actors and fictional screenplays, the result is easily accepted as "documentary", just as Moore's films are. To call something "propoganda" (not that you used the term, this is merely a "preemptive strike", you understand), you have to address its content and show it be in large part untrue. If you can provide some kind of precedent or professional opinion which supports your narrow definition of "documentary" as a work that must provide a counterpoint in addition to a point, I invite you to do so.
You link to an article on typepad.com which claims that John Kerry lied to get one of his three Purple Hearts and that some of his old "buddies" from Vietnam, the Swift Boat Vets for Truth think he's unfit to be President. The SBVFT was formed in May, 2004 and "leadership and guidance were provided by Republican activists and presidential friends from Texas -- notably Houston attorney John E. O'Neill and corporate media consultant Merrie Spaeth", according to Joe Conason of Salon.com. Dr. Louis Letson is the sole source for the Purple Heart story, but he was not the attending physician for the wound in question, according to the Navy's medical records. These are the only sources mentioned in the typepad.com article and both have been thoroughly discredited.
Did you check out Tracking for Multiple Machines in the FreeBSD Handbook? They mention sharing the ports tree as well as the system source tree, which is one of the keys to easy software management across multiple machines. The other key is portupgrade and its pkgtools.conf file which allows you to record your port customizations and have them automatically applied when you install or upgrade software. portupgrade also makes it incredibly easy to build binary packages for stuff you don't want/need to compile on each machine. Like a lot of things in FreeBSD, it's sort of a "suffer once" proposition requiring more configuration work up front (than e.g. RedHat Linux) but easier administration in the long run plus the advantages of building from source. RedHat is almost the exact opposite - easy to get up and running but diffucult to customize because that often means moving away from RPMs which, in turn, can mean that RedHat's nifty config tools won't work because your custom source build wants to install with a different layout than the "official" RedHat RPM.
I assume you didn't run out and buy a copy of "Automating UNIX and Linux Administration", but the techniques described there would solve your "dozens of files to edit" problem - a problem you will undoubtedly encounter with RedHat as well at some point. Using automation techniques, I can bring up a server from bare metal to fully operational with dozens of custom configuration files, properly configured kernel and software built to my or my clients' needs in about an hour (~20 minutes of actual, interactive "work"). Besides saving a lot of time, this approach ensures consistency across a server farm and encourages you to make changes based on their relative merit rather than the amount of labor involved.
No, I meant your decision to use RedHat because it is easier to get up and running while *BSD generally requires more effort and knowlege for initial deployment but is, IMO, easier to admin in the long run.
Maybe I don't get what you mean by "play nicely" but, in my experience FreeBSD plays better with OS X than RedHat since so many of the user binaries are the same. You'll find that most commands (and their man pages) are identical, which is not the case between OS X and Linux of any flavor.
I get your point, but it's kind of funny when you consider that BSD is in many ways the "original" NOS - at least when it comes to TCP/IP. As you infer, this is more a statement of experience and perception than anything else. If your background was in Solaris or other commercial UNIXes, you would feel just the opposite. Having said that, your background is probably representative of more people overall than would be, say, an AIX sysadmin's. My own backgound is more or less normal, "corporate IT" but I (as I'm sure is painfully obvious) would have opted for FreeBSD in your situation, especially if you're talking about a half-dozen or more machines here.
It sounds like you tried to make a reasonable decision based on your needs and situation, but you don't mention any specific problems you had with your BSD machines. You mention that OpenBSD "just didn't perform", but (IMO) you should only be using OpenBSD if you have already found that the vastly more popular and better performing FreeBSD does not suit your security needs (I think it's safe to say that most sysadmins relegate OpenBSD to running firewalls and lower-traffic dedicated systems). If you're running multiple servers, you should read this section of the FreeBSD Handbook about multi-machine setup. You should also invest in a copy of Automating Unix and Linux Administration and, if you want a good introduction to "real world" FreeBSD administration, you can't beat Absolute BSD - I still refer to this friendly and straightforward book constantly.
Again, your problem with BSD would be more clear if you gave an actual example. For instance, if by "network configuration" you mean changing the basic network paramaters like IP address, subnet mask, default router, etc., there are actually *fewer* files to change under BSD (it's all in rc.conf) vs. the unnecessarily complex per-interface config files used by RedHat. Both systems have the traditional hosts and resolv.conf files, so there is no difference there. Perhaps you are referring to some custom RedHat administration program that edits the config files for you. One reason that such things (for the most part) don't exist in BSD is that the BSD config file layout is so clear and simple that they are just not needed. Also, if memory serves, to install those fancy RedHat admin tools, you have to install X (even you only want the command-line versions) which is of course a ridiculous and, IMO, unacceptable requirement.
Anyway, I would enjoy reading your response and trying to find out if your choice of RedHat was based on actual advantages provided by RedHat or a lack of experience with BSD. Although I am admittedly part of the "elite" FreeBSD user base, please don't mistake any part of this post for OS-bashing or other petty stuff. I'm interested in your experience because I think it's probably representative of many others who decide that RedHat is easier to use than *BSD.
If you would bother to actually read the posts here you would find that, except for a few fringe opinions, most of us are advocating a reasonable approach to broadcast licensing under the current FCC. Specifically, a system which takes into account the rights of individual citizens (who, by the way, legally own the radio spectrum in the first place) alongside the needs of commercial broadcasting. In other words, we don't want to abolish regulation, we want to be protected by it.
If, at the risk of upsetting your black-and-white stereotypical views, you actually researched the subject you would find that the FCC itself advocates the granting of thousands of LPFM licenses but has been overruled by corporate media lobbyists in congress. Search the posts to find supporting references - I wouldn't want to deprive you of the sorely needed mental exercise you will gain by reading some of the more detailed posts on this subject.