In my experience, the primary difference between NetBeans and Eclipse can be summed up in three letters: SWT.
The Eclipse team concluded, based on the common experience of many Java programmers, that AWT/Swing based UIs suck rocks. They look like crap, they don't fit the platform, and they're slow as molasses.
So they threw them away. Replaced 'em with a new, custom written, tiny, lightweight, lightning fast widget system called SWT based on platform native widgets. The result is that SWT UIs are fast, and look great.
As far as features go, NetBeans and Eclipse are quite similar. I prefer the Eclipse UI (I hate the way that NetBeans handles subwindows...), but that's really just a matter of taste. But as far as performance goes... I've been using a version of Eclipse for about two weeks now, and I still can't believe it's written in Java. I've been writing UIs in Java for the last 3 years, and I've gotten so used to the snail-crawl of Swing... Eclipse is a real eye opener.
I'm an IBMer, who's trying to open-source a related project. One of the issues that we're dealing with is that often, open-sourcing increases the cost of development.
One of the advantages of being closed is control. You get to choose exactly where each programmer works; you get to choose exactly which pieces of the system change, and which don't.
When you open it, suddenly, you lose control. You can't just make decisions anymore; you need to work with your contributor base, which is a much slower process than managerial decree. And you need to deal with the fact that people will be changing things all over the place, and be capable of integrating those changes into your own ongoing work. That costs time(possibly a lot of time), and time costs money. Not to mention the direct costs of
slowed communication, support, bug tracking and handling, patch queue management, security (as
to do open source, you need a CVS server that straddles the firewall), etc. Open-sourcing a
corporate product is not cheap.
Of course, the benefits of opening are often enormous. (I'm not trying to do this to my own system for nothing!) But anyone who open-sources a project hoping to lower their costs through free labor is in for quite a shock. It doesn't happen.
As far as Eclipse goes... I was initially a skeptic when I first heard about it. Now, I've been using it for a while. It's a damned impressive piece of work. You'll never believe it's written in Java; the startup time is a bit long (while the JIT is compiling the whole thing as it loads), but once it loads, it absolutely flies. Looks sharp, runs fast, and gives you
all the hooks you need to hack up your own tools and integrate them into it.
A universal object type is *not* a substitute
for a proper parametric type system. (Not that templates are a proper parametric type system - template are, pretty much, the most bone-headed, brain-dead way that I've ever seen of implementing parametrics.)
To give a real-world example... I'm working on
a software configuration management system, implemented in Java. (webpage).
In our system, switching from Java to GJ (java with parametric types) literally took about 25%
off the size of the code, made it easier to read,
and eliminated several bugs.
What bothered me most about this guys
proposal is that he doesn't seem to have a clue
about much of anything outside of the C/C++/Java
language family. His argument for leaving out
templates is correct, but he follows it with "I'm looking for a solution". Wake up pal, the solution
is out there, and it's been there for
over twenty years. It's just not in any
of the C++ family languages.
Just for another data point; I did the same
thing. Over the last two weeks I've developed something (undiagnosed as yet) that sure as heck
resembles CTS. It hurts like hell. The simple
pre-emptive practices didn't work for me.
If you're dealing with a web application interfaced with Apache, and communicating with
clients through the network, and data coming
through a relational database, than it's almost
definite that the speed difference of C or C++
simply won't make any difference.
You've got to focus on what causes the performance bottleneck, and address that.
In web based applications, there are generally three bottlenecks:
CGI. The time that it takes to invoke a CGI
script is generally quite significant. The load
time generally dwarfs the execution time. If you can use a system that allows you to avoid the
loading cost, you're winning, even if your
computation is a couple of orders of magnitude
slower.
Database Access. Performing an operation against a relational database is IO intensive,
and thus time consuming. Again, the time spent on
database related IO and marshalling/demarshalling usually dwarfs the time spent computing using the
data.
Network communication. Often the most significant bottleneck of all. If your user is
submitting stuff via http, then they see round-trip
times for each submission that are seconds long.
For most applications, the time savings of C
vs Perl (which are quite large) are utterly unimportant when you realize that they don't matter
once considered against the intrinsic latency.
So the real advice is: choose a language that
handles your bottlenecks best. If you are
really doing something computation intensive that
takes a long time in Perl, then it's worth
writing in a highly efficient language, like C++,
or OCaml.
But if your bottleneck isn't
really computation, then you might be much better
off using some else. If it's CGI load time killing
you, than writing in Java (with Jakarta), or
Perl (with mod_perl) or Python (with mod_python)
will be significantly faster than a C++ program
loaded through CGI. And any of the other languages
will likely be easier to use than C++.
If it's database IO time, then leaving the language alone, and redesigning your tables to
optimize database access may payoff much better
than changing languages.
The whole idea of therapeutic touch is that trained practitions can *feel* and *manipulate* the
so-called bio-electrical field of the body, and
that by doing so, can affect the healing process
of the body.
Her study demonstrated conclusively that TT practioners were full of it. Not only could they not distinguish a healthy bio-electrical field from
a sick one, but they couldn't even tell if a body
was there or not.
The vitamins analogy is totally backwards. The key
difference? The tole of perception. When you take
a vitamin, it is in some sense, the active party.
You, the patient, are inactive, and the vitamin
acts on your body. You are a passive participant.
In therapeutic touch, you have two people involved:
the patient, who is essentially passive, and the
practitioner, who is active. The *active* party
in therapeutic touch cannot perform their activity
without being able to perceive that which they
claim to manipulate.
Rosa's study looked at the active party, to see
if it was possible for them to perceive that
which they claimed to be able to perceive. And
they couldn't.
Any ongoing discussion of TT needs to explain either (A) what it was about the experiment that
prevented the practioners from be able to perceive
the fields that they claim to be able to perceive,
or (B) how therapeutic touch can possible work in
the absence of any ability to perceive the fields
being manipulated.
(B) is clearly out of the question: the practioners
of TT are quite clear about the fact that they
are *feeling* the fields, and using that perception
of the fields to guide their activities. So it falls to (A), and I have yet to see a remotely
convincing argument for it.
Feel free to prove me wrong - I'd be delighted
if something as simple and comforting as TT could
actually work. But the evidence against it is
pretty darned powerful, and in the years since
Rosa's study, I haven't heard anything that made
any sense.
Re:Just because you can ...
on
MySQL FS
·
· Score: 2
Well, but maybe you should.
Sure - a DB accessed as a filesystem doesn't present the full power of the DB through the filesystem API. And sure, a DB filesystem doesn't necessarily have the same performance characteristics as a standard filesystem.
But there are some very significant applications where a DB presented as a filesystem makes brilliant sense. Here's two simple ones off the top of my head.
Configuration management. Systems like CVS go to great trouble to get transactional behavior, so that you can't lose code if the program crashes in the middle of an update. If you're using a DBFS, you've got transactionality and rollback for free.
Micro-applications. There are a lot of simple applications which really need transactionality/rollback facilities, but which can't (either for portability or for size reasons) make use of a complete transactional database facility. Write it to access files, and let the database take care of transactions.
I don't have anything to do with this project, but I think it's a great idea, because I'm doing almost the same thing with DB2. (Why DB2? Because I work for IBM Research..) I'm building an SCM system, and I don't want the higher layers of my system to need to understand the database or the particular table layout that I'm using. So they access it as a filesystem; downbelow, it's a rock-solid database.
Of course, all of the above assumes transactionality - which is not yet fully supported by MySQL. So I'd be a little paranoid before using this, to make certain that they're using the transactional tables!
The problem isn't so much that these agencies are stockpiling information; it's that they are *not* careful about ensuring that it's correct, and that they hide behind layers of subcontractors and bureaucracy to make it impossible to determine what the facts are, and how to correct them.
To give a personal example: 11 years ago, when I was an undergraduate at Rutgers University, I worked for the university as a programmer. The university made an error my first month on the job, and overpayed me by $500. Next month, they deducted the overpayment from my paychecks, and I assumed everything was straightened out.
Two years later, the University sent me a bill demanding repayment of the overpayment. I argued with them, including producing the pay stubs showing this, and they "cleared" the record.
One year after that, they came after me again. I again showed them the pay stubs, and this time they refused to even look at them, and sent it to a collection agency. At this point, I gave in, and repayed them - again.
Now, 10 years later, I'm supposed to get a refund from my NJ income taxes. I don't get it, because a different office at the University noticed the overpayment at some time in the last ten years, and filed it with the state as a delinquency.
It's over 10 years later. I no longer have the pay stubs, or the cancelled checks to show that I've payed this stuff *twice*. I need to pay it *again*, and I've got a delinquency on my credit record.
Who's responsible? I *can't* find out. It's all carefully hidden behind an elaborate web of agencies and offices, all of which deny both responsibility and authority to correct it. There is simply *no way* that I can get this straightened out, except by paying it *again*, and in all likelyhood, even if I pay it again, it will reappear a few years from now.
That's the problem: the tangled web of information providers, none of whom take any responsibility, none of whom can correct an error. Any time you try to correct an error, it gets deleted from one source - and almost instantly reappears in that source because they exchange information with all of the others.
Nope - you're still falling into a serious oversimplification.
Orbital mechanics is *tricky*. There is basically no good way to simplify it - period.
The numbers figured by the original poster are totally irrelevant, with no bearing on reality. To
get from here to there is *not* a question of just finding two vectors. That's still making static assumptions about a dynamic system. You're inside of a gravitational orbiting system. If you take two vectors: the velocity of earth at the moment of launch, and the velocity of mars at the moment of arrival, and then you augment the original posters calculations with that information, you're still nowhere close to the *real* numbers.
The problem is: throughout the trip, you are subject to the constantly changing gravitational acceleration on the ship. (Constantly changing because your position relative to the sun is changing - so the direction of the gravitational force changes with your radial position relative to the sun, and the strength of the acceleration changes relative to your distance to the sun.)
The effect of gravity in an orbital system simply cannot be understated. It is *the* dominant factor. The relative positions and delta-Vs of the start and destination matter far less than the relative orbits in the calculation. By ignoring orbital mechanics, your calculation can be off by *orders of magnitude*. We're not talking triviality here!
If you really want to see what the math here is like, I can't do it - I'm just a lowly comp sci PhD. I do lambda calculus, not orbital mechanics! But I can point you at some great textbooks. (My father is a physicist who worked on Galileo, as well as a variety of satellite systems, so he's got the books, and I'm sure I can get him to provide some recommendations.)
Well, that would just fine if it weren't for the minor fact that every little bit of math there is complete, absolutely, and utterly wrong.
Earth and Mars are NOT stationary objects. They're both in orbit around the sun. To get from here to mars, it's not a matter of straight line travel. It's a matter of orbital mechanics: how do you change orbits in a manner that both puts you into mars orbit at approximately the same point in the orbit.
I'm not going to do the math: I'm not an orbital mechanics guy. But it's a lot harder than the trivial calculation you did.
First - I'm not a GNOME bigot. I'm a *standards* bigot. My complaint against what's going on with KDE isn't because I prefer GNOME (although, to be honest, I do), but because I dislike the reinvent the wheel syndrome.
I'm aware that KDE did use CORBA, and abandoned it. I think that their *reasons* for abandoning it sucked.
They used an ORB which had lousy performance. So what was their response? Not fix the ORB. No - it was to totally reinvent the whole idea of an ORB from scratch, and then implement their new non-standard ORB.
Yes, some ORBs are slow. What's the solution? Fix the friggin' ORB. Yes, the CORBA bindings can be a pain in the butt to program to. Is the correct answer to discard the entire standard infrastructure and invent your own from scratch? I'd much rather see someone *fix the bindings*.
CORBA presents a set of bindings which were a political compromise. No one likes them. But you can do CORBA and *not use them*. Take an IDL compiler, and have it generate something different, but keep the standard infrastructure.
The KDE folks could have optimized and ORB, and prettied up the bindings, and still taken advantage of the widely acknowledged standard for componentry. But instead, they discarded it, and then reinvented it.
What's the cost of that? You constantly need to rewrite code to work with KDE. I've got a ton of CORBA components that I can use in a UI. Can I use them in KDE? Sure - but I have to basically write a brand new kparts wrapper for each of them.
I just don't believe that when the standard is adequate, that it's appropriate to discard standard infrastructure in favor of your own homebrew. CORBA is adequate, if implemented well. So implement the standard well.
It's frustrating to watch things like this gather a lot of hype. Basically, this is *identical* to Bonobo. Big deal.
KDE has done some impressive things, but they have this unfortunate tendency to reinvent the wheel. DCOP/KParts is a reinvention of software components - AKA Corba. The KDE people originally argued that the reason for KParts was that ORBs were too slow, and they couldn't afford to pay the price of real componentry.
Since then, they've been gradually reintroducing each of the important features of an ORB, finally leading to support for out-of-process components.
Now, finally, they've reintroduced all of the features of an ORB, but in a non-standard fashion for their own desktop. Basically, they've reached the point of Bonobo, but based on a non-standard ORB. Goody.
I'm an IBM guy, who's been drafted to do some
Sash related work. I'm currently getting started
on enabling other scripting languages to work within
the Sash framework. Give me a couple of months,
and we'll probably have Perl and Python support.
Zope does not do the same thing as Sash.
To present a slightly different cast on Sash: Sash
is a scripting environment for Linux, where you can wrap any piece of code up in a component, and make it available for scripting. This is done using Mozilla as a frame, for providing both the basic componentry (through XPCom) and the UI frame wrapper.
Zope is very much a server side beast. It allows you to use scripting on the *server* side of things. Sash is sort of a client counterpart. Something like Zope serves applications to a Sash client, which then executes those applications on the client machine.
>What at this point is stopping us from just reverse engineering the stupid M$ extension and removing their last >possible thing to say about this issue? Is anybody working on this already?
The problem is that Microsoft has made that nearly impossible. To publically release a reverse engineered version of Microsoft's Kerberos extensions, the authors would need to be able to prove that they had no access to Microsoft's trade secrets. The "public release" of that information, and its posting to slashdot has made it effectively impossible for anyone to prove that they did a true "clean room" reverse engineering based reimplementation.
The GPL trick also won't work. GPL is a copyright license; without an author who owns the copyright, the copyright is meaningless. An owner of the copyright must be established in order to make the copyright enforceable.
Second, even if you could GPL it, that still wouldn't make any difference. A piece of software which was implemented by violating a trade secret will not be protected in any meaningful sense by copyright; any company who used it would still be subject to a lawsuit from Microsoft, GPL or no GPL.
>It may bother you to know this, but most >religions are inherently evangelical. If you are >against prosletyzation, you should live amongst >Buddhists.
Or Jews. Or a fair number of others. In my experience in the US, only Christians have that constant annoying habit of needing to preach to everyone with different beliefs. It's far from a universal trait of religious people.
Would you react this way if someone said that "20% of people have some chronic physical illness", where the definition of chronic physical illness includes allergies, asthma, reflux (i.e. chronic heartburn), weakened ligaments (from sprained ankles), RSI, bad back, and migraines?
Or is it just that the idea of mental illness being as common as physical illness unacceptable?
Reading responses like this illustrate exactly why mental illness is such a problem
Would anyone argue if I said that 1 out of 5 people suffered from some sort of physical illness? Would anyone make a ridiculous argument about profiling and conspiracies? Of course not!
But we view mental illness as something *different*, something *frightening*. Any suggestion that lots of people have some degree of mental illness is viewed with suspicion and paranoia.
Mental illness includes chronic stress disorders. Clinical depression. Schizophrenia. Phobias. All manner of illnesses,ranging from relatively minor to totally debilitating. Gosh, just like physical illnesses!
But when it comes to mental illness, we hide from it. We're scared of it. We try to pretend that it's not there, it's all just of a conspiracy of the media, or the government, or the drug companies.
It's not. People with mental illnesses include your friends, your relatives, and possibly yourself.
The point of things like this study is to make people realize that mental illness isn't "insanity". It's not extreme, and it's not rare, and there's *nothing* wrong with getting it treated.
I'll be bold, and use myself as an example. I haven't gotten any treatment, but to be honest, I probably should. Back in high school, I was the geek that got abused. By *everyone*. I had no friends, at all. I was beaten up on a daily basis. It left *deep* scars. I still have nightmares about being back in high school. I find it extremely difficult to cope with certain social situations, because of my severe stress reactions.
That's called post-traumatic stress disorder. It's a mental illness.
Does that make me nuts? I don't think so. I'm happily married to a lovely lady. I've got my PhD in computer science. I've got a great job as a researcher at IBM. I'm a stable, happy, productive person. But that doesn't mean that I'm perfectly healthy, mentally, any more than it means that I'm perfectly healthy physically.
Don't view things in such an absolute fashion. It's not the case that every "successful" relationship ends up in marriage.
I can think of numerous cases among my friends where a long happy relationship broke up, but where the former couple remained close friends. I consider that a successful relationship, even though it ended.
I actually disagree pretty strongly. I'm a full time Java developer. There's some pretty huge, gaping holes in Java. But I can't plug them. I've got to go through a complex bureaucratic process to get my changes approved; then Sun owns my changes.
What this means, to me, is that because of Suns license, I'm *prohibited* from improving Java, under threat of legal action. I'm not *permitted* to do what I'd need to do to make Java into a serious system for building "pretty software" that's implemented in a "high quality" fashion.
In the meantime, I'm crippled while Sun holds little "community meetings" to talk about what to do.
I understand their compatibility concerns, and I'm even sympathetic. But I don't think that the appropriate response is to seal off the code in a private little universe, and demand fealty of anyone who would dare to try to improve it.
I truly see Linux as a wonderful contrast. In Linux, I can go and change the kernel to fix whatever I believe is wrong with it. There's a central coordinator (Linus), which keeps the kernel consistent, and my code will never get into widespread distribution without going through the community and getting it accepted. That's exactly what Sun is claiming to try to accomplish with the SCSL - and it's working great under Linux, without the threat of legal action.
But the big difference with Linux is that *I* own my changes. If I create a modified linux kernel for some particular application (say, an embedded system), I can distribute and use my modified kernel, regardless of whether Linus or the rest of the community agrees to fold my changes back into the official kernel.
Here's the *real* difference, and it's the "forking" issue that ESR brought up. When I change the linux kernel, when I make the changes I mentioned in the previous paragraph, I can make changes that I know perfectly well should *never* be folded into the main kernel source. I can decide that I want to use linux is a totally different domain, and that the appropriate thing to do is to build a *new*, *incompatible* system, using the Linux kernel as a base. I can capitalize on the excellent Linux base, but take it on a new direction, different from the course being followed by Linus and the rest of the community. If I do that under SCSL, I'm not allowed to give my modified system to anyone, ever, or Sun will come after me in court.
Money isn't the be-all, end-all of existence. That's the fundamental reason why so many hackers have devoted their time and energy to contributing to linux.
There's probably not a single contributor to the kernel who couldn't have made a mint working for some Wall Street firm. But they thought that there was something more important than money.
So what if someone wants to put in the work to turn linux into a marketable product, and makes money doing it? It doesn't change anything about the people who created linux, or the reasons why they did it.
Would we put up the source code for Photoshop?" Warnock said. "Not in a million years.... Well, maybe sometime in the future. But something like that is so horrendously complex, it is just not feasible...
Um, GIMP, anyone? TIFFany? As if open source developers are somehow too stupid to figure out a graphics program...besides, don'tcha think those very same developers could actually clean up the mess that Photoshop is?
Let me throw in a little bit of reality, which a lot of people don't understand (and which I didn't believe until I was forcibly exposed to it!).
Software development in industry is more chaotic than you probably imagine. I work for one of the biggest software/hardware companies in the world. I was recently involved in a development project that cost millions of dollars to produce, and consisted of over 1 million lines of code. The company invested years of development effort into this system - it was a high profile, highly important product to us.
At one point, I needed to build a modified version of the product. I grabbed the full source code, and attempted to build it. I couldn't. I enlisted the help of local experts. They couldn't make it build. We enlisted the help of the team in charge of product builds. They could build it *in their own environment*, *on their own machiens* - but they had *no clue* of how to build it elsewhere, or what the environment dependencies that affected the build were.
There is *no one* in the company who understands the entire build process. There's a group of guys who each understand small pieces of it, and they've cobbled together a combination of lots of little makefiles bound together by kludgy perl scripts.
I'll bet that Photoshop is very much the same way. I'll bet that no one at Adobe has the slightest clue of how to build the entire system.
So. If Photoshop were ever opensourced, it would disappear in the blink of an eye, because no one would be able to build it. Would open-source hackers really spends months of effort fixing a fundamentally broken build process on a proprietary project, when they could invest their time doing useful things to an opensource competitor like GIMP? I really don't think so.
I disagree strongly. Hacking isn't all glory, but involves the nitty-gritty of making things work. Hacking termcap isn't exactly a glorious high-profile activity, but I wouldn't disqualify it out of hand as hacking.
But fetchmail is a different matter entirely. He started with a pretty typical pop-mail client. What he did was make the leap to change it from a simple pop-mail client to a sendmail interface. Rather than just acting like a typical client, he hacked together a very cool tool that reads messages from pop (and a dozen different protocols), and injects them into the local sendmail stream. That's one heck of a cool hack. If you don't grasp the elegance and creativity of that, then, well, there's no real point in arguing with you, because you just don't get it.
Slashdot Mirror
In my experience, the primary difference between NetBeans and Eclipse can be summed up in three letters: SWT.
The Eclipse team concluded, based on the common experience of many Java programmers, that AWT/Swing based UIs suck rocks. They look like crap, they don't fit the platform, and they're slow as molasses.
So they threw them away. Replaced 'em with a new, custom written, tiny, lightweight, lightning fast widget system called SWT based on platform native widgets. The result is that SWT UIs are fast, and look great.
As far as features go, NetBeans and Eclipse are quite similar. I prefer the Eclipse UI (I hate the way that NetBeans handles subwindows...), but that's really just a matter of taste. But as far as performance goes... I've been using a version of Eclipse for about two weeks now, and I still can't believe it's written in Java. I've been writing UIs in Java for the last 3 years, and I've gotten so used to the snail-crawl of Swing... Eclipse is a real eye opener.
You're just plain wrong about this.
I'm an IBMer, who's trying to open-source a related project. One of the issues that we're dealing with is that often, open-sourcing increases the cost of development.
One of the advantages of being closed is control. You get to choose exactly where each programmer works; you get to choose exactly which pieces of the system change, and which don't.
When you open it, suddenly, you lose control. You can't just make decisions anymore; you need to work with your contributor base, which is a much slower process than managerial decree. And you need to deal with the fact that people will be changing things all over the place, and be capable of integrating those changes into your own ongoing work. That costs time(possibly a lot of time), and time costs money. Not to mention the direct costs of
slowed communication, support, bug tracking and handling, patch queue management, security (as
to do open source, you need a CVS server that straddles the firewall), etc. Open-sourcing a
corporate product is not cheap.
Of course, the benefits of opening are often enormous. (I'm not trying to do this to my own system for nothing!) But anyone who open-sources a project hoping to lower their costs through free labor is in for quite a shock. It doesn't happen.
As far as Eclipse goes... I was initially a skeptic when I first heard about it. Now, I've been using it for a while. It's a damned impressive piece of work. You'll never believe it's written in Java; the startup time is a bit long (while the JIT is compiling the whole thing as it loads), but once it loads, it absolutely flies. Looks sharp, runs fast, and gives you
all the hooks you need to hack up your own tools and integrate them into it.
A universal object type is *not* a substitute for a proper parametric type system. (Not that templates are a proper parametric type system - template are, pretty much, the most bone-headed, brain-dead way that I've ever seen of implementing parametrics.)
To give a real-world example... I'm working on a software configuration management system, implemented in Java. (webpage). In our system, switching from Java to GJ (java with parametric types) literally took about 25% off the size of the code, made it easier to read, and eliminated several bugs.
What bothered me most about this guys proposal is that he doesn't seem to have a clue about much of anything outside of the C/C++/Java language family. His argument for leaving out templates is correct, but he follows it with "I'm looking for a solution". Wake up pal, the solution is out there, and it's been there for over twenty years. It's just not in any of the C++ family languages.
Just for another data point; I did the same thing. Over the last two weeks I've developed something (undiagnosed as yet) that sure as heck resembles CTS. It hurts like hell. The simple pre-emptive practices didn't work for me.
-Mark
If you're dealing with a web application interfaced with Apache, and communicating with clients through the network, and data coming through a relational database, than it's almost definite that the speed difference of C or C++ simply won't make any difference.
You've got to focus on what causes the performance bottleneck, and address that.
In web based applications, there are generally three bottlenecks:
So the real advice is: choose a language that handles your bottlenecks best. If you are really doing something computation intensive that takes a long time in Perl, then it's worth writing in a highly efficient language, like C++, or OCaml.
But if your bottleneck isn't really computation, then you might be much better off using some else. If it's CGI load time killing you, than writing in Java (with Jakarta), or Perl (with mod_perl) or Python (with mod_python) will be significantly faster than a C++ program loaded through CGI. And any of the other languages will likely be easier to use than C++.
If it's database IO time, then leaving the language alone, and redesigning your tables to optimize database access may payoff much better than changing languages.
That's a lousy analogy.
The whole idea of therapeutic touch is that trained practitions can *feel* and *manipulate* the
so-called bio-electrical field of the body, and
that by doing so, can affect the healing process
of the body.
Her study demonstrated conclusively that TT practioners were full of it. Not only could they not distinguish a healthy bio-electrical field from
a sick one, but they couldn't even tell if a body
was there or not.
The vitamins analogy is totally backwards. The key
difference? The tole of perception. When you take
a vitamin, it is in some sense, the active party.
You, the patient, are inactive, and the vitamin
acts on your body. You are a passive participant.
In therapeutic touch, you have two people involved:
the patient, who is essentially passive, and the
practitioner, who is active. The *active* party
in therapeutic touch cannot perform their activity
without being able to perceive that which they
claim to manipulate.
Rosa's study looked at the active party, to see
if it was possible for them to perceive that
which they claimed to be able to perceive. And
they couldn't.
Any ongoing discussion of TT needs to explain either (A) what it was about the experiment that
prevented the practioners from be able to perceive
the fields that they claim to be able to perceive,
or (B) how therapeutic touch can possible work in
the absence of any ability to perceive the fields
being manipulated.
(B) is clearly out of the question: the practioners
of TT are quite clear about the fact that they
are *feeling* the fields, and using that perception
of the fields to guide their activities. So it falls to (A), and I have yet to see a remotely
convincing argument for it.
Feel free to prove me wrong - I'd be delighted
if something as simple and comforting as TT could
actually work. But the evidence against it is
pretty darned powerful, and in the years since
Rosa's study, I haven't heard anything that made
any sense.
Well, but maybe you should.
Sure - a DB accessed as a filesystem doesn't present the full power of the DB through the filesystem API. And sure, a DB filesystem doesn't necessarily have the same performance characteristics as a standard filesystem.
But there are some very significant applications where a DB presented as a filesystem makes brilliant sense. Here's two simple ones off the top of my head.
Configuration management. Systems like CVS go to great trouble to get transactional behavior, so that you can't lose code if the program crashes in the middle of an update. If you're using a DBFS, you've got transactionality and rollback for free.
Micro-applications. There are a lot of simple applications which really need transactionality/rollback facilities, but which can't (either for portability or for size reasons) make use of a complete transactional database facility. Write it to access files, and let the database take care of transactions.
I don't have anything to do with this project, but I think it's a great idea, because I'm doing almost the same thing with DB2. (Why DB2? Because I work for IBM Research..) I'm building an SCM system, and I don't want the higher layers of my system to need to understand the database or the particular table layout that I'm using. So they access it as a filesystem; downbelow, it's a rock-solid database.
Of course, all of the above assumes transactionality - which is not yet fully supported by MySQL. So I'd be a little paranoid before using this, to make certain that they're using the transactional tables!
-Mark
The problem isn't so much that these agencies are stockpiling information; it's that they are *not* careful about ensuring that it's correct, and that they hide behind layers of subcontractors and bureaucracy to make it impossible to determine what the facts are, and how to correct them.
To give a personal example: 11 years ago, when I was an undergraduate at Rutgers University, I worked for the university as a programmer. The university made an error my first month on the job, and overpayed me by $500. Next month, they deducted the overpayment from my paychecks, and I assumed everything was straightened out.
Two years later, the University sent me a bill demanding repayment of the overpayment. I argued with them, including producing the pay stubs showing this, and they "cleared" the record.
One year after that, they came after me again. I again showed them the pay stubs, and this time they refused to even look at them, and sent it to a collection agency. At this point, I gave in, and repayed them - again.
Now, 10 years later, I'm supposed to get a refund from my NJ income taxes. I don't get it, because a different office at the University noticed the overpayment at some time in the last ten years, and filed it with the state as a delinquency.
It's over 10 years later. I no longer have the pay stubs, or the cancelled checks to show that I've payed this stuff *twice*. I need to pay it *again*, and I've got a delinquency on my credit record.
Who's responsible? I *can't* find out. It's all carefully hidden behind an elaborate web of agencies and offices, all of which deny both responsibility and authority to correct it. There is simply *no way* that I can get this straightened out, except by paying it *again*, and in all likelyhood, even if I pay it again, it will reappear a few years from now.
That's the problem: the tangled web of information providers, none of whom take any responsibility, none of whom can correct an error. Any time you try to correct an error, it gets deleted from one source - and almost instantly reappears in that source because they exchange information with all of the others.
Nope - you're still falling into a serious oversimplification.
Orbital mechanics is *tricky*. There is basically no good way to simplify it - period.
The numbers figured by the original poster are totally irrelevant, with no bearing on reality. To
get from here to there is *not* a question of just finding two vectors. That's still making static assumptions about a dynamic system. You're inside of a gravitational orbiting system. If you take two vectors: the velocity of earth at the moment of launch, and the velocity of mars at the moment of arrival, and then you augment the original posters calculations with that information, you're still nowhere close to the *real* numbers.
The problem is: throughout the trip, you are subject to the constantly changing gravitational acceleration on the ship. (Constantly changing because your position relative to the sun is changing - so the direction of the gravitational force changes with your radial position relative to the sun, and the strength of the acceleration changes relative to your distance to the sun.)
The effect of gravity in an orbital system simply cannot be understated. It is *the* dominant factor. The relative positions and delta-Vs of the start and destination matter far less than the relative orbits in the calculation. By ignoring orbital mechanics, your calculation can be off by *orders of magnitude*. We're not talking triviality here!
If you really want to see what the math here is like, I can't do it - I'm just a lowly comp sci PhD. I do lambda calculus, not orbital mechanics! But I can point you at some great textbooks. (My father is a physicist who worked on Galileo, as well as a variety of satellite systems, so he's got the books, and I'm sure I can get him to provide some recommendations.)
Well, that would just fine if it weren't for the minor fact that every little bit of math there is complete, absolutely, and utterly wrong.
Earth and Mars are NOT stationary objects. They're both in orbit around the sun. To get from here to mars, it's not a matter of straight line travel. It's a matter of orbital mechanics: how do you change orbits in a manner that both puts you into mars orbit at approximately the same point in the orbit.
I'm not going to do the math: I'm not an orbital mechanics guy. But it's a lot harder than the trivial calculation you did.
First - I'm not a GNOME bigot. I'm a *standards* bigot. My complaint against what's going on with KDE isn't because I prefer GNOME (although, to be honest, I do), but because I dislike the reinvent the wheel syndrome.
I'm aware that KDE did use CORBA, and abandoned it. I think that their *reasons* for abandoning it sucked.
They used an ORB which had lousy performance. So what was their response? Not fix the ORB. No - it was to totally reinvent the whole idea of an ORB from scratch, and then implement their new non-standard ORB.
Yes, some ORBs are slow. What's the solution? Fix the friggin' ORB. Yes, the CORBA bindings can be a pain in the butt to program to. Is the correct answer to discard the entire standard infrastructure and invent your own from scratch? I'd much rather see someone *fix the bindings*.
CORBA presents a set of bindings which were a political compromise. No one likes them. But you can do CORBA and *not use them*. Take an IDL compiler, and have it generate something different, but keep the standard infrastructure.
The KDE folks could have optimized and ORB, and prettied up the bindings, and still taken advantage of the widely acknowledged standard for componentry. But instead, they discarded it, and then reinvented it.
What's the cost of that? You constantly need to rewrite code to work with KDE. I've got a ton of CORBA components that I can use in a UI. Can I use them in KDE? Sure - but I have to basically write a brand new kparts wrapper for each of them.
I just don't believe that when the standard is adequate, that it's appropriate to discard standard infrastructure in favor of your own homebrew. CORBA is adequate, if implemented well. So implement the standard well.
It's frustrating to watch things like this gather a lot of hype. Basically, this is *identical* to Bonobo. Big deal.
KDE has done some impressive things, but they have this unfortunate tendency to reinvent the wheel. DCOP/KParts is a reinvention of software components - AKA Corba. The KDE people originally argued that the reason for KParts was that ORBs were too slow, and they couldn't afford to pay the price of real componentry.
Since then, they've been gradually reintroducing each of the important features of an ORB, finally leading to support for out-of-process components.
Now, finally, they've reintroduced all of the features of an ORB, but in a non-standard fashion for their own desktop. Basically, they've reached the point of Bonobo, but based on a non-standard ORB. Goody.
I'm working on it.
I'm an IBM guy, who's been drafted to do some
Sash related work. I'm currently getting started
on enabling other scripting languages to work within
the Sash framework. Give me a couple of months,
and we'll probably have Perl and Python support.
-Mark
Zope does not do the same thing as Sash. To present a slightly different cast on Sash: Sash is a scripting environment for Linux, where you can wrap any piece of code up in a component, and make it available for scripting. This is done using Mozilla as a frame, for providing both the basic componentry (through XPCom) and the UI frame wrapper. Zope is very much a server side beast. It allows you to use scripting on the *server* side of things. Sash is sort of a client counterpart. Something like Zope serves applications to a Sash client, which then executes those applications on the client machine.
>What at this point is stopping us from just reverse engineering the stupid M$ extension and removing their last
>possible thing to say about this issue? Is anybody working on this already?
The problem is that Microsoft has made that nearly impossible. To publically release a reverse engineered version of Microsoft's Kerberos extensions, the authors would need to be able to prove that they had no access to Microsoft's trade secrets. The "public release" of that information, and its posting to slashdot has made it effectively impossible for anyone to prove that they did a true "clean room" reverse engineering based reimplementation.
The GPL trick also won't work. GPL is a copyright license; without an author who owns the copyright,
the copyright is meaningless. An owner of the copyright must be established in order to make the
copyright enforceable.
Second, even if you could GPL it, that still wouldn't make any difference. A piece of software
which was implemented by violating a trade secret will not be protected in any meaningful sense by copyright; any company who used it would still be subject to a lawsuit from Microsoft, GPL or no GPL.
>It may bother you to know this, but most
>religions are inherently evangelical. If you are >against prosletyzation, you should live amongst
>Buddhists.
Or Jews. Or a fair number of others. In my
experience in the US, only Christians have that constant annoying habit of needing to preach to everyone with different beliefs. It's far
from a universal trait of religious people.
Bzzt. Wrong. IBM had nothing to do with COM. COM was developed in cooperation by Digital and Microsoft.
Would you react this way if someone said that "20%
of people have some chronic physical illness", where the definition of chronic physical illness includes allergies, asthma, reflux (i.e. chronic heartburn), weakened ligaments (from sprained ankles), RSI, bad back, and migraines?
Or is it just that the idea of mental illness being as common as physical illness unacceptable?
Reading responses like this illustrate exactly
why mental illness is such a problem
Would anyone argue if I said that 1 out of 5
people suffered from some sort of physical
illness? Would anyone make a ridiculous argument
about profiling and conspiracies? Of course not!
But we view mental illness as something *different*, something *frightening*. Any suggestion that lots of people have some degree of mental illness is viewed with suspicion and paranoia.
Mental illness includes chronic stress disorders. Clinical depression. Schizophrenia. Phobias. All
manner of illnesses,ranging from relatively minor
to totally debilitating. Gosh, just like physical
illnesses!
But when it comes to mental illness, we hide from
it. We're scared of it. We try to pretend that it's not there, it's all just of a conspiracy of
the media, or the government, or the drug companies.
It's not. People with mental illnesses include
your friends, your relatives, and possibly yourself.
The point of things like this study is to make people realize that mental illness isn't "insanity". It's not extreme, and it's not rare,
and there's *nothing* wrong with getting it treated.
I'll be bold, and use myself as an example. I
haven't gotten any treatment, but to be honest,
I probably should. Back in high school, I was the
geek that got abused. By *everyone*. I had no
friends, at all. I was beaten up on a daily basis.
It left *deep* scars. I still have nightmares
about being back in high school. I find it extremely difficult to cope with certain social
situations, because of my severe stress reactions.
That's called post-traumatic stress disorder. It's
a mental illness.
Does that make me nuts? I don't think so. I'm happily married to a lovely lady. I've got my PhD
in computer science. I've got a great job as a
researcher at IBM. I'm a stable, happy, productive
person. But that doesn't mean that I'm perfectly
healthy, mentally, any more than it means that I'm
perfectly healthy physically.
Get over your paranoia.
Don't view things in such an absolute fashion. It's not the case that every "successful" relationship ends up in marriage.
I can think of numerous cases among my friends
where a long happy relationship broke up, but where the former couple remained close friends. I consider that a successful relationship, even though it ended.
I actually disagree pretty strongly. I'm a
full time Java developer. There's some pretty
huge, gaping holes in Java. But I can't plug them.
I've got to go through a complex bureaucratic
process to get my changes approved; then Sun
owns my changes.
What this means, to me, is that because of Suns
license, I'm *prohibited* from improving Java,
under threat of legal action. I'm not *permitted*
to do what I'd need to do to make Java into a serious system for building "pretty software"
that's implemented in a "high quality" fashion.
In the meantime, I'm crippled while Sun holds
little "community meetings" to talk about what to
do.
I understand their compatibility concerns, and I'm
even sympathetic. But I don't think that the
appropriate response is to seal off the code in
a private little universe, and demand fealty of
anyone who would dare to try to improve it.
I truly see Linux as a wonderful contrast. In Linux, I can go and change the kernel to fix whatever I believe is wrong with it. There's a central coordinator (Linus), which keeps the kernel consistent, and my code will never get into widespread distribution without going through the community and getting it accepted. That's exactly
what Sun is claiming to try to accomplish with the
SCSL - and it's working great under Linux, without
the threat of legal action.
But the big difference with Linux is that *I* own
my changes. If I create a modified linux kernel
for some particular application (say, an embedded
system), I can distribute and use my modified
kernel, regardless of whether Linus or the rest of
the community agrees to fold my changes back into
the official kernel.
Here's the *real* difference, and it's the "forking" issue that ESR brought up. When I change
the linux kernel, when I make the changes I mentioned in the previous paragraph, I can make
changes that I know perfectly well should *never*
be folded into the main kernel source. I can decide that I want to use linux is a totally different domain, and that the appropriate thing to do is to build a *new*, *incompatible* system, using the Linux kernel as a base. I can capitalize on the excellent Linux base, but take it on a new direction, different from the course being followed by Linus and the rest of the community. If I do that under SCSL, I'm not allowed to give my modified system to anyone,
ever, or Sun will come after me in court.
Money isn't the be-all, end-all of existence. That's the fundamental reason why so many hackers have devoted their time and energy to contributing to linux.
There's probably not a single contributor to the kernel who couldn't have made a mint working for some Wall Street firm. But they thought that there
was something more important than money.
So what if someone wants to put in the work to
turn linux into a marketable product, and makes money doing it? It doesn't change anything about the people who created linux, or the reasons why they did it.
Would we put up the source code for Photoshop?" Warnock said. "Not in a million years. ... Well, maybe sometime in the future. But something like that is so horrendously complex, it is just not feasible...
Um, GIMP, anyone? TIFFany? As if open source developers are somehow too stupid to figure out a graphics program...besides, don'tcha think those very same developers could actually clean up the mess that Photoshop is?
Let me throw in a little bit of reality, which a lot of people don't understand (and which I didn't believe until I was forcibly exposed to it!).
Software development in industry is more chaotic than you probably imagine. I work for one of the biggest software/hardware companies in the world. I was recently involved in a development project that cost millions of dollars to produce, and consisted of over 1 million lines of code. The company invested years of development effort into this system - it was a high profile, highly important product to us.
At one point, I needed to build a modified version of the product. I grabbed the full source code, and attempted to build it. I couldn't. I enlisted the help of local experts. They couldn't make it build. We enlisted the help of the team in charge of product builds. They could build it *in their own environment*, *on their own machiens* - but they had *no clue* of how to build it elsewhere, or what the environment dependencies that affected the build were.
There is *no one* in the company who understands the entire build process. There's a group of guys who each understand small pieces of it, and they've cobbled together a combination of lots of little makefiles bound together by kludgy perl scripts.
I'll bet that Photoshop is very much the same way. I'll bet that no one at Adobe has the slightest clue of how to build the entire system.
So. If Photoshop were ever opensourced, it would disappear in the blink of an eye, because no one would be able to build it. Would open-source hackers really spends months of effort fixing a fundamentally broken build process on a proprietary project, when they could invest their time doing useful things to an opensource competitor like GIMP? I really don't think so.
I disagree strongly. Hacking isn't all glory, but involves the nitty-gritty of making things work. Hacking termcap isn't exactly a glorious high-profile activity, but I wouldn't disqualify it out of hand as hacking.
But fetchmail is a different matter entirely. He started with a pretty typical pop-mail client. What he did was make the leap to change it from
a simple pop-mail client to a sendmail interface. Rather than just acting like a typical client, he hacked together a very cool tool that reads messages from pop (and a dozen different protocols), and injects them into the local sendmail stream. That's one heck of a cool hack. If you don't grasp the elegance and creativity of that, then, well, there's no real point in arguing with you, because you just don't get it.
While I often find Eric Raymond to be annoyingly
/etc on your linux box sometime, and search for esr. Talk to any of the people who
arrogant and full of himself, the claim that he's not a hacker is simply ridiculous.
Take a look in
use fetchmail to access their pop-mail accounts.
He's a hacker all right. And a pretty darned good one.