So let me get this right: you posted to a forum about a fairly exoteric subject, the answer to which was already availble if you had searched, and you gave up within a day? Why, shame on you!
I'm no expert, but according to wikipedia, it would appear that GPS is not used at all. I think I once heard that landing uses an airport generated homing beacon, but I just don't know.
When flying, if you veer around by 100 feet or so, you are still OK. An airplane has GPS, which can pinpoint the position to within 10 feet, and there are not obstacles. In short, a GPS and a computer will do you just fine (as long as air traffic control does their job properly).
Modern planes do take-offs and landings, too. I don't think missing the runway by 30m is an acceptable error:)
That said it is much more difficult to make autonomous cars, though I still hope and think I'll live to see it. It's not the precision --- computer system are good at precision, and when Galleio goes up we can use that for dm scale precision. It's the road system that we humans have built for humans thatis going to be difficult. Marking the middle of the road with anything ranging from nothing over a single white stripe over complicated marking over a green area and a fence isn't precisely easy for a computer+sensor to navigate by. Then there are road signs, pedestrians and the odd cow.
Still, I'm told that that plane automatics have brought down the accident rate by a factor 100. Even if the real number is 10, that's 50 kills a year in little Denmark, and scaled to the world, it's 50000 people. Thats a lot of people --- enough to warrant forcibly introducing such a system if need be, IMHO.
Gentoo does have this, but reading documentation is no fun when you can grep in the qpkg -l output;-)
Actually, I just scroll up to the emerge output and pick the/usr/bin/.. name from there.
Currently, it isn't even a chip (or at least, last I heard). It was (a lot of) molekyles with 7 "mutable" spots (I think it was rotation). The state was read using NMR spectroscopy).
It is about as close to a chip as a printing press to a photocopier;-)
Q: Why is there no Open Source (GNU GPL) version of Qt on Windows ?
A: We have regrettably not found a way of making GPL versions for Windows available without risking the very business model we depend upon to be able to further develop and support Qt.
Please note that if you make the source code for your project available and your license allows it, any holder of a commercial Qt Windows license can create binaries for your project.
I didn't miss templates, I didn't mention them because I feel they are an extension to classes. My post was in response to a post that suggested there was nothing in C++ that wasn't in C that didn't have something to do with classes and inheritence.
Template function are quite useful, and do not have anything to do with OO. E.g.
template<typename T> void swap(T& a,T& b) { T tmp(a); a=b; b=tmp; }
Sailing much in fog without a radar is not a very good idea... better to find shore and anchor quickly.
If you do have radar, the GPS is not exactly critical for anything, just a convenience... as you can navigate by radar alone no problem. Unless you're crossing the ocean, in which case a compas is good enough until the fog clears, not that fog is that common on the open ocean.
As I said, QT is not for cross-platform free development. But if you're writing to the POSIX standard (Using fork()? Using mmap()? X? Assuming the presence of/tmp?) I would definitely recommend QT. As would I if you're writing cross-platform, GUI code in a proprietary setting. If not, not. I do not believe that QT hides this fact, so I do not find anything wrong with it. It is not as if there is no alternative.
It seems that Trolltech is using the free edition to promote itself, and to reap the odd patch, while selling QT for proprietary development. I do not know or care why they only use this model in Linux as, frankly, I regard windows as yesterdays tech. I am, however, very pleased that QT is availble under Linux under GPL.
Personally, I always advocate for more windmills and more atomic power. That way, most people disagree. It even makes sense, yet there are very few who think it is a good idea. It seems to be
Seriously QT is great for *nux with a perfect license for "really free software" from the R. Stallman school. If you want "less free", ie. usable by non-free projects, or free crossplatform, you should use GTK.
For crying out loud. No it is as much a 3D matrix as Fortrans, which is that a 3D matrix is mapped onto a 1D arrays, because that is the way computers work. The point is:
There are several libraries that do exactly what you want, with the same syntax.
writing x[1][2][3] is better than the C++ STL way, which would be x(1*(3*4)+2*(4)+3), but a simple utility class would render this as x(1,2,3), which is better than the Fortran way, IMHO. And as I said, this is by unfairly crippling C++ by not using an appropriate library.
And before you start, you can do slices in both these libraries AND in the STL, though I can't remember the syntax offhand. It is listed in my man pages, though, should I ever need them.
I'm sure you can use pointers in Fortran if you really wanted to. In C++, you would either use a library, or, if forced to rely on only standard stuff, something like
It's not just "supposed", it actually does work very well in practice. Most of the time you just run "star-merge" against someone else's branch and it Just Works, pulling in only the unmerged changes.
OK, I said supposedly because I haven't used it yet, but comments such as yours have given me that impression.
(Re speed)[...]More a case of non-optimal defaults, IMO.
You're probably right. The slowness was my experience backed with mailing list complaints and Tom's half-admittance to performance problems. I hear that it is horrid under cygwin.
Re need to know graph theoryYou are right that the special case where there is a central repository, everything is simple and peachy. But arch could IMHO do better than that, and make it simple and peachy even without a central repository, e.g. by tracking what change sets has been applied. I mentioned this because one of arch's most pronounced strengths is not having to have a central repository. But be warned that if you use arch for this, basic graph theory is recommended (by me, at least).
OK, where I work most of my fellow collegues do not have a CS degree. To be exact, out of twenty there would be a couple of engineers (not software), someone with a different slightly related degree (e.g, I'm a master of math, no CS) and maybe one CS master. That's it. The rest has various short and middle term programming education, which means that they can just about handle auto_ptr. But unlike using C++ templates, which can be handled by a few and used without too many problems by many, a versioning system has to be usuable for anybody and everybody. And some of these people have problems with CVS. And it is not because they are stupid or anything --- but their talents lies in other directions, which is nice when such is needed. Those people could never grasp graph theory, not should they have to.
Oh, and in my experience, CEO are self-taught as often as not.
Firstly, I don't care much about performance, as long as it's usable. I was trying to give a short breakdown on what arch strengths and weaknesses, and performance is one of the weaknesses as I see it.
Revision libraries: 0 explicitly created. My tree contains less than 20 patches, so I hardly think this is an issue.Anyway, I believe that creating rev. libs. is a ugly, HD wasting method that should be solved by a temporary cache instead. Ask me, and I'll give you reasons.
None. I use tools that do not handle hard links properly.
The non-broken one. Explicit.
The repository is on NFS (which itself is reiserfs 3.6), the local version is on reiserfs.
It's not that the performance is horrible in this setup, it's just much worse than CVS (and I use both, even though CVS is unsafe in this setup. I have my reasons, the details are irrelevant.) As I said, the performance from arch is comparable to using CVS from e.g. KDE's public mirror.
As for the flame war, it would seem so, and finally the talk of forking has begun. Tla needs forking, worse than XFree did. This last paragraph is just my take, of course.
Changeset orientation --- patches are project oriented, not file-oriented, which is better (IMHO)
Easy to make a private branch of a repository which you do not have access to
Supposedly good merge mechanism
Revisions are stored as simple changesets (patches) with only tarring and bzip2'ing.
It has a lot of advanced features.
The first two are why I use arch. The bad things are
In Tom Lord's words, tla (the arch implementation) is a box of sharp knives. In other words, the interface is dangerous, uncomfortable, extremely badly documented and very clunky. E.g. simple operations like switching branch requires several commands and until all commands are executed the local version is in an inconsistent and unusable state
It's very slow. When working from a local repository, it feel roughly like cvs on a public mirror. A patch to partly fix this was rejected.
It uses just about every character available to the UNIX file system, including comma, =, {,} and more, and generates insanely long name. Some work is supposedly going on to fix the long names, though.
To use safely, you have to know some graph theory. (I do, but I don't believe everyone should)
Some commands are only safe if you have perfect knowledge of other users actions (star-merge).
Oh yeah, the development has just sun-flared just when it had begun starting up again. A huge flame war (where Tom's primary contribution seemed to be "Grow up", "You're childish" and worse) arch is now without a release manager, and understandable nobody wants to take that role.
In short, arch has great promise, but needs some drastic changes.
It seems outsourcing costs money and resources as well as saving some. Language, time zone, cultural differences and geographic distances all contribute to the costs. But the resources used to overcome such obstacles are seldom recorded separately, and so do not show up --- leaving the management believing that they have saved money that they have not, in fact, saved.
searching for "DVD burning linux" (excluding free) would get you such links as "DVD Editing/Authoring/Burning with Linux" and "How to burn a DVD-Video under Linux with mkisofs and dvdrecord".
So in this case, the asker-of-questions didn't do his homework. Searching for 5 variations on google is common courtesy. And yes, this includes clicking on those 5 links.
Also, when asking Linux question, searching his/hers distribution, a Wiki and perhaps linuxquestions.org would be in order, too.
In other words, do 1 hour worth of research before wasting 5 minutes of hundreds of people's time.
In my experience, well-written code beats documentation every time. Documentation is always out of date, or just slightly wrong.
On the other hand, user manuals and such are very important. Linux generally shines in this area (compared to windows, at least), but still, the more the better. Writing such is, however, not a skill every developer has. Try tla help if you doubt me:) And besides, lots and lots of users could conceivable write these, and thus pay back some of what they have gained for free:-D
No, theories aren't evidence. Evidence would be, e.g., if primitive carbon-based self-replication could be constructed in a laboratory, using condition that might have been present when the earth was young.
What we do know fairly certain is that primitive organic compounds (such as amino acid) can be created spontaneously in conditions which seems likely at the time. From there to self-replication is the "missing link", though there is no lack of theories to bridge this gap. They are all and one pure speculation, as far as I know.
And given unicorns, elves may be quite likely (though I fail to see the connection:) )
I'll try to be more clear: We have several theories about how self-replication could start. None of these are backed by experimental data. From there, the evidence for evolution is quite strong.
Slashdot Mirror
So let me get this right: you posted to a forum about a fairly exoteric subject, the answer to which was already availble if you had searched, and you gave up within a day? Why, shame on you!
I'm no expert, but according to wikipedia, it would appear that GPS is not used at all. I think I once heard that landing uses an airport generated homing beacon, but I just don't know.
Modern planes do take-offs and landings, too. I don't think missing the runway by 30m is an acceptable error :)
That said it is much more difficult to make autonomous cars, though I still hope and think I'll live to see it. It's not the precision --- computer system are good at precision, and when Galleio goes up we can use that for dm scale precision. It's the road system that we humans have built for humans thatis going to be difficult. Marking the middle of the road with anything ranging from nothing over a single white stripe over complicated marking over a green area and a fence isn't precisely easy for a computer+sensor to navigate by. Then there are road signs, pedestrians and the odd cow.
Still, I'm told that that plane automatics have brought down the accident rate by a factor 100. Even if the real number is 10, that's 50 kills a year in little Denmark, and scaled to the world, it's 50000 people. Thats a lot of people --- enough to warrant forcibly introducing such a system if need be, IMHO.
Gentoo does have this, but reading documentation is no fun when you can grep in the qpkg -l output ;-)
Actually, I just scroll up to the emerge output and pick the /usr/bin/.. name from there.
Currently, it isn't even a chip (or at least, last I heard). It was (a lot of) molekyles with 7 "mutable" spots (I think it was rotation). The state was read using NMR spectroscopy).
It is about as close to a chip as a printing press to a photocopier ;-)
Indeed. Not so long ago I heard that a team had succesfully factorized 12 (into 4*3) using a quantum computer. (It was a 7 qubit 'puter) :)
Quantum computer has a way to go, even by paranoid standards.
You are wrong, as this Q&A points out:
Template function are quite useful, and do not have anything to do with OO. E.g.
Sailing much in fog without a radar is not a very good idea... better to find shore and anchor quickly. If you do have radar, the GPS is not exactly critical for anything, just a convenience... as you can navigate by radar alone no problem. Unless you're crossing the ocean, in which case a compas is good enough until the fog clears, not that fog is that common on the open ocean.
As I said, QT is not for cross-platform free development. But if you're writing to the POSIX standard (Using fork()? Using mmap()? X? Assuming the presence of /tmp?) I would definitely recommend QT. As would I if you're writing cross-platform, GUI code in a proprietary setting. If not, not. I do not believe that QT hides this fact, so I do not find anything wrong with it. It is not as if there is no alternative.
It seems that Trolltech is using the free edition to promote itself, and to reap the odd patch, while selling QT for proprietary development. I do not know or care why they only use this model in Linux as, frankly, I regard windows as yesterdays tech. I am, however, very pleased that QT is availble under Linux under GPL.
Personally, I always advocate for more windmills and more atomic power. That way, most people disagree. It even makes sense, yet there are very few who think it is a good idea. It seems to be
What's the sense in that?
You mean GPL? An evil license to be sure ;-) All my microsoft friends tell me it's a viral license that must be eradicated!
source
Seriously QT is great for *nux with a perfect license for "really free software" from the R. Stallman school. If you want "less free", ie. usable by non-free projects, or free crossplatform, you should use GTK.
And before you start, you can do slices in both these libraries AND in the STL, though I can't remember the syntax offhand. It is listed in my man pages, though, should I ever need them.
I'm sure you can use pointers in Fortran if you really wanted to. In C++, you would either use a library, or, if forced to rely on only standard stuff, something like
valarray<double> x(2*3*4);
OK, that sounds extremely interesting. Thanks for the heads-up. I'll go google :)
It's not just "supposed", it actually does work very well in practice. Most of the time you just run "star-merge" against someone else's branch and it Just Works, pulling in only the unmerged changes. OK, I said supposedly because I haven't used it yet, but comments such as yours have given me that impression.
(Re speed)[...]More a case of non-optimal defaults, IMO. You're probably right. The slowness was my experience backed with mailing list complaints and Tom's half-admittance to performance problems. I hear that it is horrid under cygwin.
Re need to know graph theoryYou are right that the special case where there is a central repository, everything is simple and peachy. But arch could IMHO do better than that, and make it simple and peachy even without a central repository, e.g. by tracking what change sets has been applied. I mentioned this because one of arch's most pronounced strengths is not having to have a central repository. But be warned that if you use arch for this, basic graph theory is recommended (by me, at least).
OK, where I work most of my fellow collegues do not have a CS degree. To be exact, out of twenty there would be a couple of engineers (not software), someone with a different slightly related degree (e.g, I'm a master of math, no CS) and maybe one CS master. That's it. The rest has various short and middle term programming education, which means that they can just about handle auto_ptr. But unlike using C++ templates, which can be handled by a few and used without too many problems by many, a versioning system has to be usuable for anybody and everybody. And some of these people have problems with CVS. And it is not because they are stupid or anything --- but their talents lies in other directions, which is nice when such is needed. Those people could never grasp graph theory, not should they have to.
Oh, and in my experience, CEO are self-taught as often as not.
Firstly, I don't care much about performance, as long as it's usable. I was trying to give a short breakdown on what arch strengths and weaknesses, and performance is one of the weaknesses as I see it.
Revision libraries: 0 explicitly created. My tree contains less than 20 patches, so I hardly think this is an issue.Anyway, I believe that creating rev. libs. is a ugly, HD wasting method that should be solved by a temporary cache instead. Ask me, and I'll give you reasons.
None. I use tools that do not handle hard links properly.
The non-broken one. Explicit.
The repository is on NFS (which itself is reiserfs 3.6), the local version is on reiserfs.
It's not that the performance is horrible in this setup, it's just much worse than CVS (and I use both, even though CVS is unsafe in this setup. I have my reasons, the details are irrelevant.) As I said, the performance from arch is comparable to using CVS from e.g. KDE's public mirror.
As for the flame war, it would seem so, and finally the talk of forking has begun. Tla needs forking, worse than XFree did. This last paragraph is just my take, of course.
The good things about arch is:
The first two are why I use arch. The bad things are
Oh yeah, the development has just sun-flared just when it had begun starting up again. A huge flame war (where Tom's primary contribution seemed to be "Grow up", "You're childish" and worse) arch is now without a release manager, and understandable nobody wants to take that role.
In short, arch has great promise, but needs some drastic changes.
It seems outsourcing costs money and resources as well as saving some. Language, time zone, cultural differences and geographic distances all contribute to the costs. But the resources used to overcome such obstacles are seldom recorded separately, and so do not show up --- leaving the management believing that they have saved money that they have not, in fact, saved.
But it is just a gut feeling.
What features do you need, exactly? Have you tried googling?
searching for "DVD burning linux" (excluding free) would get you such links as "DVD Editing/Authoring/Burning with Linux" and "How to burn a DVD-Video under Linux with mkisofs and dvdrecord".
So in this case, the asker-of-questions didn't do his homework. Searching for 5 variations on google is common courtesy. And yes, this includes clicking on those 5 links.
Also, when asking Linux question, searching his/hers distribution, a Wiki and perhaps linuxquestions.org would be in order, too.
In other words, do 1 hour worth of research before wasting 5 minutes of hundreds of people's time.
In my experience, well-written code beats documentation every time. Documentation is always out of date, or just slightly wrong.
On the other hand, user manuals and such are very important. Linux generally shines in this area (compared to windows, at least), but still, the more the better. Writing such is, however, not a skill every developer has. Try tla help if you doubt me :) And besides, lots and lots of users could conceivable write these, and thus pay back some of what they have gained for free :-D
No, theories aren't evidence. Evidence would be, e.g., if primitive carbon-based self-replication could be constructed in a laboratory, using condition that might have been present when the earth was young.
What we do know fairly certain is that primitive organic compounds (such as amino acid) can be created spontaneously in conditions which seems likely at the time. From there to self-replication is the "missing link", though there is no lack of theories to bridge this gap. They are all and one pure speculation, as far as I know.
And given unicorns, elves may be quite likely (though I fail to see the connection :) )
I'll try to be more clear: We have several theories about how self-replication could start. None of these are backed by experimental data. From there, the evidence for evolution is quite strong.
Sorry for being so muddy :-(