you can simulate math from a higher bit machine on a lower bit machien so it is entirely possible. I have many times performed a 16-bit multiply and 16-bit additions on a 6502 (which is an 8-bit machine with VERY limited abilities).
It is of course doable, but it would be significantly larger code, and of course slow to the point of unplayability...but you cant win em all;)
Well, I haven't read the article, and I probably should, but there is one main reason why I think humans are done evolving. We have reached a stage where we identify and correct even the slightest anomalies in our offspring; this will become even more of a factor as we delve into genetic engineering even more. This really breaks Darwin's model for evolution because we are eliminating the ability for our offspring to surpass us.
Now, if there is some global event that drastically changes the lifestyle of humans, maybe then evolution would take place, or something more subtle could probably happen as well.
Suppose there is some really bad virus out there that wipes out 90% of the human race, the 10% left just so happened to have a mutation that allowed them to fend off that virus, well that would be evolution, just not anything people would notice by looking at these new humans.
In general, unless something drastic happens, we are done.
i go to RIT and they use lexical anylysis programs to anylize work submitted for each student.
Your work is tokenized, functions are reordered, variable names, reduced to enumerations.. etc, then compared.
if the code has a high enough similarity to another persons code, it is hand checked..pretyy hard to get away with cheating, unless you are capable of changing it enough (which usually implies you could have done it by yourself anyways)
You know what would make RPM so much better
on
OpenPKG 1.0 Released
·
· Score: 1
if RPM had it's dependancies based on _files_ not other packages...then it would work so much nicer, especially with other package systems. My main complaint about RPM is that as soon as I install somthing (such as X, or a kernel) from source that a lot of things depend on, I have to "force" all packages that need it, cause i know i have it.
I mean, how hard is it to add a nightly cron task (similar to locate) that would make an inventory of your files/libraries that RPM could use for dependacy checks?
Also this would make RPM cooperate nicely with other package systems..The point is, RPM shouldnt care where the files came from, just that they are there.
actually there is a reason for that name. The original final fantasy was made when the company was in serious economic trouble...it was called final fantasy, because they thought it was the last game they'd ever make:P
heh, talk about ironony...the seamingly neverending (but awsome) series is named after a game they thought would be there last.
i haven't really delved into the KDE sources quite so much yet...but is there any real X dependant code in there? I mean it is based on QT which is multi-platform, so as long as they use QT for everything then it should as simple as a recompile to use it in windows, you could probably even use it to replace explorer.exe. The only thing i can think of off hand that might be a prob is the different directory structure, but that should be a big deal
I think a nice solution is to keep all the files in seperate directories, but then use symlinks to put the executables in the appropriate/bin dirs.
personally i prefer having lots of seperate directories for seperate apps and using the PATH variable. with the source setup of QT/KDE, i can uninstall all KDE programs with 1 command:
rm -rf $KDEDIR
and likewise with QT. It wouldn't be hard to set things up cleaner, nicer. But if the distro/package managers want to be stubborn, i'll settle for symlinks.
I am sorry to say that while you make some interesting arguments, I have to dissagree. You mention that C is "broken" because of functions like gets, but any programming worth hiring should know that they shoudl use fgets, plus many modern compilers give a warning about this unsafe function.
A agree that this particular library function is poorly designed, but there is a simple replacment that fixes the problem. One of the nice things about languages that are built on previous work are is that they are diverse and you only need to use the features you need. For example, one of the most ingenious features of C++ is that it is almost entirely backwards compatible with C, this made the adoption of C++ very quick because programmers werent intimidated by having the learn a new language.
Me on the other hand, I welcome new languages, and I agree that you must use the right tool for the right job (PHP for web based mySQL work, perl for unix shell scripting, java for binary portability)...and have spent time learning to program in more or less every language I have heard of. But the beauty of languages like C is that they can be used for ANYTHING. The only time the language is unsafe is when the programmer is unsafe. In my opinion, if you are smart enough to write programs, you shouldn't need a language that holds your hand as you go.
My Java professor loved to brag about how he could make "crash proof" programs in Java, but of course he failed to mention that a properly coded program in ANY language can be "crash proof".
C/C++ are safe languages by any definition, there is no reason why "security related" projects cannot be handled by them, most hacks I find are buffer overflow problems, well check your buffers! it isn't too hard. Or if you are really THAT lazy, use a pre-fab class in C++ that wil do some extra error checking for you.
it is easy to code right, but easier to be just plain lazy.
I am curious as to which service pack the windows 2000 machine was using. If it was sp2 (as i would think it is), then we must also take into consideration that Windows 2000 has had a lot of time for refinments through these service packs, let M$ release a few "critial updates", patch a few things up, release a SP or two, then compare.
XP just came out, but it is still going to be developed, it very well may improve over time through updates.
Wow, I was completely unware of this, that changes thing a great deal. If multiple inheritance is broken, well then the compiler is not in an acceptible state, and you have made the right choice.
The only real reason I would like to push for GCC (but not anymore in light of this news) is for a stable ABI. This is going to make a world of difference in linux. Imagine makeing a package for RH 8.0 and knowing it will work in all future versions of RH, along with all other distros based on the same compiler...it is a good thought, and a feature that has been missing from linux for a while.
OK, the binary compitbility argument is more than acceptible, if it is polocy to keep package compatibility withing major releases, well then i'll wait for 8.0 for a standfard gcc 3.01.
as for the "broken code", does it produce the problem if ALL packages are compiled with it. What I mean is, it is "broken" in the sense that it actually miscompiles, or is it not compatible with existing stuff. Because even correct code will crash if linked to libs with a different ABI.
Why is the new gcc not being used as the default compiler? The way I see it, having it as an optional compiler does very little good, here is the reason. suppose I install gcc 3.01, but use the rpm for QT library. any and all programs i compile against the library will fail to run because of the different ABI between the two compilers they were compiled under. Sure, as a C compiler it should be plenty compatible, but for a C++ compiler, you must have consistancy, or it simply wont work.
How would the RIAA know which mp3s were made from CDs that I legally own? I mean, am I not allowed to take CDs I bought and make mp3s out of them so I can listen to them on my computer?
Even though I am a big advocate for free music, I still buy the CDs of those bands which I really like.
Re:A great example of open-source at work.
on
Five Years of KDE
·
· Score: 5, Insightful
I agree that these five years worth of progress is very impressive. However comparing them to Microsoft's work isn't entirely fair. Microsoft was developing an Operating System, not just a GUI for it. KDE has the advantage of using somone else's GUI library to work with as a basis. Plus they don't have to worry about the complexities of Operating System's.
Don't get me wrong, i don't mean to not give KDE credit where credit is due...but we gotta be fair, comparing KDE to Windows is hardly an equal comparison.
C/C++ and many other languages have an equivalent to Eiffels pre/post tests....use asserts:)
I am sure that the kernel has liberal use of assertions, if not well, I would be very suprised
proxy
Slashdot Mirror
you can simulate math from a higher bit machine on a lower bit machien so it is entirely possible. I have many times performed a 16-bit multiply and 16-bit additions on a 6502 (which is an 8-bit machine with VERY limited abilities).
;)
It is of course doable, but it would be significantly larger code, and of course slow to the point of unplayability...but you cant win em all
tru about the security thing, but then they could also fix all the languages that use the CLR while changing thigns in only one spot...
Well, I haven't read the article, and I probably should, but there is one main reason why I think humans are done evolving. We have reached a stage where we identify and correct even the slightest anomalies in our offspring; this will become even more of a factor as we delve into genetic engineering even more. This really breaks Darwin's model for evolution because we are eliminating the ability for our offspring to surpass us.
Now, if there is some global event that drastically changes the lifestyle of humans, maybe then evolution would take place, or something more subtle could probably happen as well.
Suppose there is some really bad virus out there that wipes out 90% of the human race, the 10% left just so happened to have a mutation that allowed them to fend off that virus, well that would be evolution, just not anything people would notice by looking at these new humans.
In general, unless something drastic happens, we are done.
i go to RIT and they use lexical anylysis programs to anylize work submitted for each student.
Your work is tokenized, functions are reordered, variable names, reduced to enumerations.. etc, then compared.
if the code has a high enough similarity to another persons code, it is hand checked..pretyy hard to get away with cheating, unless you are capable of changing it enough (which usually implies you could have done it by yourself anyways)
if RPM had it's dependancies based on _files_ not other packages...then it would work so much nicer, especially with other package systems. My main complaint about RPM is that as soon as I install somthing (such as X, or a kernel) from source that a lot of things depend on, I have to "force" all packages that need it, cause i know i have it.
I mean, how hard is it to add a nightly cron task (similar to locate) that would make an inventory of your files/libraries that RPM could use for dependacy checks?
Also this would make RPM cooperate nicely with other package systems..The point is, RPM shouldnt care where the files came from, just that they are there.
actually there is a reason for that name. The original final fantasy was made when the company was in serious economic trouble...it was called final fantasy, because they thought it was the last game they'd ever make :P
heh, talk about ironony...the seamingly neverending (but awsome) series is named after a game they thought would be there last.
i haven't really delved into the KDE sources quite so much yet...but is there any real X dependant code in there? I mean it is based on QT which is multi-platform, so as long as they use QT for everything then it should as simple as a recompile to use it in windows, you could probably even use it to replace explorer.exe. The only thing i can think of off hand that might be a prob is the different directory structure, but that should be a big deal
I think a nice solution is to keep all the files in seperate directories, but then use symlinks to put the executables in the appropriate /bin dirs.
personally i prefer having lots of seperate directories for seperate apps and using the PATH variable. with the source setup of QT/KDE, i can uninstall all KDE programs with 1 command:
rm -rf $KDEDIR
and likewise with QT. It wouldn't be hard to set things up cleaner, nicer. But if the distro/package managers want to be stubborn, i'll settle for symlinks.
I am sorry to say that while you make some interesting arguments, I have to dissagree. You mention that C is "broken" because of functions like gets, but any programming worth hiring should know that they shoudl use fgets, plus many modern compilers give a warning about this unsafe function.
A agree that this particular library function is poorly designed, but there is a simple replacment that fixes the problem. One of the nice things about languages that are built on previous work are is that they are diverse and you only need to use the features you need. For example, one of the most ingenious features of C++ is that it is almost entirely backwards compatible with C, this made the adoption of C++ very quick because programmers werent intimidated by having the learn a new language.
Me on the other hand, I welcome new languages, and I agree that you must use the right tool for the right job (PHP for web based mySQL work, perl for unix shell scripting, java for binary portability)...and have spent time learning to program in more or less every language I have heard of. But the beauty of languages like C is that they can be used for ANYTHING. The only time the language is unsafe is when the programmer is unsafe. In my opinion, if you are smart enough to write programs, you shouldn't need a language that holds your hand as you go.
My Java professor loved to brag about how he could make "crash proof" programs in Java, but of course he failed to mention that a properly coded program in ANY language can be "crash proof".
C/C++ are safe languages by any definition, there is no reason why "security related" projects cannot be handled by them, most hacks I find are buffer overflow problems, well check your buffers! it isn't too hard. Or if you are really THAT lazy, use a pre-fab class in C++ that wil do some extra error checking for you.
it is easy to code right, but easier to be just plain lazy.
I am curious as to which service pack the windows 2000 machine was using. If it was sp2 (as i would think it is), then we must also take into consideration that Windows 2000 has had a lot of time for refinments through these service packs, let M$ release a few "critial updates", patch a few things up, release a SP or two, then compare.
XP just came out, but it is still going to be developed, it very well may improve over time through updates.
Wow, I was completely unware of this, that changes thing a great deal. If multiple inheritance is broken, well then the compiler is not in an acceptible state, and you have made the right choice.
The only real reason I would like to push for GCC (but not anymore in light of this news) is for a stable ABI. This is going to make a world of difference in linux. Imagine makeing a package for RH 8.0 and knowing it will work in all future versions of RH, along with all other distros based on the same compiler...it is a good thought, and a feature that has been missing from linux for a while.
OK, the binary compitbility argument is more than acceptible, if it is polocy to keep package compatibility withing major releases, well then i'll wait for 8.0 for a standfard gcc 3.01.
as for the "broken code", does it produce the problem if ALL packages are compiled with it. What I mean is, it is "broken" in the sense that it actually miscompiles, or is it not compatible with existing stuff. Because even correct code will crash if linked to libs with a different ABI.
Why is the new gcc not being used as the default compiler? The way I see it, having it as an optional compiler does very little good, here is the reason. suppose I install gcc 3.01, but use the rpm for QT library. any and all programs i compile against the library will fail to run because of the different ABI between the two compilers they were compiled under. Sure, as a C compiler it should be plenty compatible, but for a C++ compiler, you must have consistancy, or it simply wont work.
How would the RIAA know which mp3s were made from CDs that I legally own? I mean, am I not allowed to take CDs I bought and make mp3s out of them so I can listen to them on my computer?
Even though I am a big advocate for free music, I still buy the CDs of those bands which I really like.
I agree that these five years worth of progress is very impressive. However comparing them to Microsoft's work isn't entirely fair. Microsoft was developing an Operating System, not just a GUI for it. KDE has the advantage of using somone else's GUI library to work with as a basis. Plus they don't have to worry about the complexities of Operating System's.
Don't get me wrong, i don't mean to not give KDE credit where credit is due...but we gotta be fair, comparing KDE to Windows is hardly an equal comparison.
C/C++ and many other languages have an equivalent to Eiffels pre/post tests....use asserts :)
I am sure that the kernel has liberal use of assertions, if not well, I would be very suprised
proxy