This release contains the 2.6.5 Kerenl. The 2.6 series kernels all are capable of (Non-Dangerous)This release contains the 2.6.5 Kerenl. The 2.6 series kernels all are capable of (Non-Dangerous) NTFS Read/Write support.
Are we talking about the same thing? I thought the Captive drivers were all copyrighted under relatively tight control and were not available for general Open Source integration. I'm aware of the Linux-NTFS module, but that only allows you to overwrite exisitng data.
Me: Give me a version that will build a FreeBSD/KDE3/OpenOffice/Java CD to my specifications and I'll be in heaven.:-D
You: Read the documentation: http://www.knoppix.net/docs/index. php/FaqCustomisi ng
*scratches head* How does Knoppix stuff help with FreeBSD?
Yes, RedHat Fedora makes that decision. It annoyed me to no end that I couldn't read my NTFS drive so I could play my kid's videos. Even worse, you can't play an MP3 file! The really screwed up part is that there's nothing "non-free" about the NTFS drivers. RedHat seems to be scared of some "IP" boogeyman that's going to sue RedHat for distributing legally reverse engineered wares. Go figure.
If you want the full review, it's here. Reviews for Mandrake and SuSE are also in my journal. Hopefully I'll have time to do a writeup of Java Desktop System very soon here.
His point that BSD source was originally used is perfectly valid. He did list an authorative source for that statement. We only have Microsoft's word that they rewrote all of the BSD code.
Putting that aside, many of the design decisions that were inherent in the BSD code will carry forward into compatible rewrites. Thus a BSD legacy exists, even if the current stack looks nothing like the original.
...for the reviews in my journal, I specifically defined what I wanted it for (ability to play cartoons off of NTFS drive) and then went through the different distros to find one that works.
As soon as I manage to get enough time to write it, I'll be adding Java Desktop System to my list of reviewed Linux Distros.
Morphix is definitely interesting, but it's not for the faint of heart. Building a Morphix ISO is one part education, one part command line voodoo, and one part dumb luck.;-)
An integrated program that would build the ISO from a bunch of selected packages would be very cool. Make it Java and you could run it on Windows, Linux, Mac OS X, Solaris, etc. I know there have been times that I've used my iBook to write a quick CD for a PC, or grab some software that I need for some other OS.
They're still using a KDE 3.2.x build, so you should be OK there. OpenOffice files haven't changed in a long time, nor has Mozilla's config stuff. The only place you could get screwed over is if you've got a bunch of KOffice files. Can't think of much else that could possibly be a problem. I'd say give it a go and see if it works.:-)
Anyone see a list of changes? I'm particularly interested to know if they've integrated the NTFS read/write libraries.
Dropping KOffice just makes sense. Why add all that extra space when 80% of the user base wants OpenOffice? Although it would be interesting to build a cross platform program (in Java perhaps?) that would allow you to custom-create these disks. Give me a version that will build a FreeBSD/KDE3/OpenOffice/Java CD to my specifications and I'll be in heaven.:-D
Yes, it does. It's gone through a few generations of development (having been a 16bit Win3x port that was bought off by Microsoft), but its origins are still BSD. Of course, there's been so much development on it at this point that it's difficult to recognize.
Did you read my response to your sibling? I already mentioned that fact and pointed out that I was referring to the stacks being exactly the same. i.e. NetBSD, FreeBSD, and OpenBSD share code and thus port all of their changes between one another.
What if I pull a UHaul trailer of DVDs and get an airlift from the handy neighborhood C-5 Galaxy? The military has to have one or two of those hanging around Sweden somewhere.:-)
True. However, the various stacks have diversified a lot since the original BSD 4.4 stack. As a result, many of the TCP/IP stacks have different performance characteristics and features. AFAIK, the three main BSDs have kept their stacks in sync because they've been sharing code. A stack from NetBSD should be almost the same as a stack from FreeBSD.
You're referring to syntax errors. That's similar to what a compiler does. Java Exceptions are more along the lines of runtime error handling. i.e. Methods for handling errors during execution. Things get a little blurred when we're talking about interpreted languages, but we can still separate syntax errors from runtime errors. (e.g. The former would be accidently typing a command like "prnt" instead of "print" while the later would be the variable "myvar" being used before it was given a value.)
I think you misunderstand me. I wasn't saying that Sound Sythesis == Raytracing, I was liking the two. i.e. Sound Sythesis::Sound as RayTracing::Video. The underlying sound calculations can be simplified in a manner similar to raytracing, and both methods are extremely CPU intensive. My end point was that we've barely started looking at realtime raytracing. Asking for realistic sound sythesis is a bit much at this stage.
You're describing a plot, not a storyline. The word "storyline" implies that the plot is developed in some fashion. Many of those old video games had a static plot, not a storyline.
Re:Where are the "Sound Acceleration" cards?
on
Cinematic Game Graphics
·
· Score: 3, Interesting
You do realize that you're asking for what amounts to RayTracing for Audio? The idea of realtime raytracing has just barely begun to penetrate the research community, and they have to cheat like hell to make it work. Trying to calculate material properties, force applied, vibration vs. tearing, listener posistioning, doppler, etc. in realtime would amount to far more CPU power than is currently in the hands of the public.
What was the "storyline" fot Mario? Or Space Invaders? Or PacMan? Storyline is only important depending on the type of game. The real focus should be on FUN. If you find the game tedious, it doesn't matter whether it has the best storyline since War and Peace. Thankfully technology can provide us with more interesting simulations, larger expolosions, better feedback, and other adrenaline pumping features.
Bridge Commander is the perfect example of how modern technology makes new games possible. Who *doesn't* want to captain a starship? Now if only other game makers would start building original and fun games instead of recycling the same old garbage.
I believe that the old Symbolics LISP machines also dumped a stack on error. However, they also allowed you to correct the problem and keep running the program from where it left off. But that isn't the point. The point is that when Java was introduced, most of the world was running on C/C++, which are very difficult to debug. Java popularized runtime stack traces and started a revolution in the way we debug programs. So what if it's old stuff? There hasn't been anything truly "new" in CompSci since the 1960's!
Java Exceptions *were* a revolution in debugging. Java stack traces tell you the exact line number something went wrong, and the path taken to get there. More often than not, that's plenty of information to track down the bug and fix it. No need to load a debugger.
What you talkin' bout foo? GOTO has been long supported by Java, it just hasn't been used by its developers. Using a GOTO statement in OO code is a rediculous thing to do. Even semi-functional languages like C have no need for GOTO statements.
A very general response--airships rarely have serious stability problems. They tend to have a very long moment arm between the center of lift (in the middle of the gas bag) and the center of mass, because fuel, payload, and a lot of structural weight tends to be down on the bottom.
But the stability is a direct result of the weight suspension. If we're talking a carrier, the weight distribution would have to be different to allow for a takeoff and landing deck. If it were suspended beneath a lift structure it would tend to swing and would create a narrow approach vector for planes. Another point is that the side suspension idea would allow the craft to use thrust in all directions instead of just forward and rudder. Rudders are a poorly suited control mechanism to such a slow craft. Assuming a thrust force like tilting rotors, the airship could be made to quickly slide, yaw, and adjust altitdude.
BTW, I ran across a "history" of the Iron Vulture here. It's such an interesting read that it's easy to believe that such development really happened!:-)
I think it comes from the fact that your post seems to be jokingly equating JDS with RH9, a common misconception
Interestingly enough, JDS was originally going to be based on RedHat. Apparently they made a (very wise, IMHO) decision to switch to SuSE half-way through development.
Slashdot Mirror
This release contains the 2.6.5 Kerenl. The 2.6 series kernels all are capable of (Non-Dangerous)This release contains the 2.6.5 Kerenl. The 2.6 series kernels all are capable of (Non-Dangerous) NTFS Read/Write support.
:-D
. php/FaqCustomisi ng
:-)
Are we talking about the same thing? I thought the Captive drivers were all copyrighted under relatively tight control and were not available for general Open Source integration. I'm aware of the Linux-NTFS module, but that only allows you to overwrite exisitng data.
Me: Give me a version that will build a FreeBSD/KDE3/OpenOffice/Java CD to my specifications and I'll be in heaven.
You: Read the documentation:
http://www.knoppix.net/docs/index
*scratches head* How does Knoppix stuff help with FreeBSD?
Thanks for the info, though.
Yes, RedHat Fedora makes that decision. It annoyed me to no end that I couldn't read my NTFS drive so I could play my kid's videos. Even worse, you can't play an MP3 file! The really screwed up part is that there's nothing "non-free" about the NTFS drivers. RedHat seems to be scared of some "IP" boogeyman that's going to sue RedHat for distributing legally reverse engineered wares. Go figure.
If you want the full review, it's here. Reviews for Mandrake and SuSE are also in my journal. Hopefully I'll have time to do a writeup of Java Desktop System very soon here.
His point that BSD source was originally used is perfectly valid. He did list an authorative source for that statement. We only have Microsoft's word that they rewrote all of the BSD code.
Putting that aside, many of the design decisions that were inherent in the BSD code will carry forward into compatible rewrites. Thus a BSD legacy exists, even if the current stack looks nothing like the original.
...for the reviews in my journal, I specifically defined what I wanted it for (ability to play cartoons off of NTFS drive) and then went through the different distros to find one that works.
As soon as I manage to get enough time to write it, I'll be adding Java Desktop System to my list of reviewed Linux Distros.
Morphix is definitely interesting, but it's not for the faint of heart. Building a Morphix ISO is one part education, one part command line voodoo, and one part dumb luck. ;-)
An integrated program that would build the ISO from a bunch of selected packages would be very cool. Make it Java and you could run it on Windows, Linux, Mac OS X, Solaris, etc. I know there have been times that I've used my iBook to write a quick CD for a PC, or grab some software that I need for some other OS.
That's a user application that uses sockets, not the implementation of the protocol stack, you disengenous fucktard.
What is? The TCP/IP stack? Or did you forget to scroll past the intro describing FTP.EXE? Oops! How embarassing!
For you that is.
And next time, please try to be a little more polite.
They're still using a KDE 3.2.x build, so you should be OK there. OpenOffice files haven't changed in a long time, nor has Mozilla's config stuff. The only place you could get screwed over is if you've got a bunch of KOffice files. Can't think of much else that could possibly be a problem. I'd say give it a go and see if it works. :-)
Anyone see a list of changes? I'm particularly interested to know if they've integrated the NTFS read/write libraries.
:-D
Dropping KOffice just makes sense. Why add all that extra space when 80% of the user base wants OpenOffice? Although it would be interesting to build a cross platform program (in Java perhaps?) that would allow you to custom-create these disks. Give me a version that will build a FreeBSD/KDE3/OpenOffice/Java CD to my specifications and I'll be in heaven.
Perhaps you should tell that to the guy who wrote the windows stack. He's posted before saying that it is not bsd.
Better double check that.
Windows does not use the BSD TCP/IP stack.
Yes, it does. It's gone through a few generations of development (having been a 16bit Win3x port that was bought off by Microsoft), but its origins are still BSD. Of course, there's been so much development on it at this point that it's difficult to recognize.
Did you read my response to your sibling? I already mentioned that fact and pointed out that I was referring to the stacks being exactly the same. i.e. NetBSD, FreeBSD, and OpenBSD share code and thus port all of their changes between one another.
What if I pull a UHaul trailer of DVDs and get an airlift from the handy neighborhood C-5 Galaxy? The military has to have one or two of those hanging around Sweden somewhere. :-)
True. However, the various stacks have diversified a lot since the original BSD 4.4 stack. As a result, many of the TCP/IP stacks have different performance characteristics and features. AFAIK, the three main BSDs have kept their stacks in sync because they've been sharing code. A stack from NetBSD should be almost the same as a stack from FreeBSD.
...but don't the three main BSD projects use pretty much the same TCP/IP stack?
I'm aware of that. But seeing a NullPointerException is often enough to infer where the Null came from. :-)
You're referring to syntax errors. That's similar to what a compiler does. Java Exceptions are more along the lines of runtime error handling. i.e. Methods for handling errors during execution. Things get a little blurred when we're talking about interpreted languages, but we can still separate syntax errors from runtime errors. (e.g. The former would be accidently typing a command like "prnt" instead of "print" while the later would be the variable "myvar" being used before it was given a value.)
Sound synthesis is more than just raytracing.
I think you misunderstand me. I wasn't saying that Sound Sythesis == Raytracing, I was liking the two. i.e. Sound Sythesis::Sound as RayTracing::Video. The underlying sound calculations can be simplified in a manner similar to raytracing, and both methods are extremely CPU intensive. My end point was that we've barely started looking at realtime raytracing. Asking for realistic sound sythesis is a bit much at this stage.
You're describing a plot, not a storyline. The word "storyline" implies that the plot is developed in some fashion. Many of those old video games had a static plot, not a storyline.
You do realize that you're asking for what amounts to RayTracing for Audio? The idea of realtime raytracing has just barely begun to penetrate the research community, and they have to cheat like hell to make it work. Trying to calculate material properties, force applied, vibration vs. tearing, listener posistioning, doppler, etc. in realtime would amount to far more CPU power than is currently in the hands of the public.
What was the "storyline" fot Mario? Or Space Invaders? Or PacMan? Storyline is only important depending on the type of game. The real focus should be on FUN. If you find the game tedious, it doesn't matter whether it has the best storyline since War and Peace. Thankfully technology can provide us with more interesting simulations, larger expolosions, better feedback, and other adrenaline pumping features.
Bridge Commander is the perfect example of how modern technology makes new games possible. Who *doesn't* want to captain a starship? Now if only other game makers would start building original and fun games instead of recycling the same old garbage.
I believe that the old Symbolics LISP machines also dumped a stack on error. However, they also allowed you to correct the problem and keep running the program from where it left off. But that isn't the point. The point is that when Java was introduced, most of the world was running on C/C++, which are very difficult to debug. Java popularized runtime stack traces and started a revolution in the way we debug programs. So what if it's old stuff? There hasn't been anything truly "new" in CompSci since the 1960's!
Java Exceptions *were* a revolution in debugging. Java stack traces tell you the exact line number something went wrong, and the path taken to get there. More often than not, that's plenty of information to track down the bug and fix it. No need to load a debugger.
What you talkin' bout foo? GOTO has been long supported by Java, it just hasn't been used by its developers. Using a GOTO statement in OO code is a rediculous thing to do. Even semi-functional languages like C have no need for GOTO statements.
Hey, I'm new to Slashdot and I am having trouble figuring things out like how I can just relpy to you directly.
:-)
Can't do it. But you can feel free to email me.
A very general response--airships rarely have serious stability problems. They tend to have a very long moment arm between the center of lift (in the middle of the gas bag) and the center of mass, because fuel, payload, and a lot of structural weight tends to be down on the bottom.
But the stability is a direct result of the weight suspension. If we're talking a carrier, the weight distribution would have to be different to allow for a takeoff and landing deck. If it were suspended beneath a lift structure it would tend to swing and would create a narrow approach vector for planes. Another point is that the side suspension idea would allow the craft to use thrust in all directions instead of just forward and rudder. Rudders are a poorly suited control mechanism to such a slow craft. Assuming a thrust force like tilting rotors, the airship could be made to quickly slide, yaw, and adjust altitdude.
BTW, I ran across a "history" of the Iron Vulture here. It's such an interesting read that it's easy to believe that such development really happened!
I think it comes from the fact that your post seems to be jokingly equating JDS with RH9, a common misconception
Interestingly enough, JDS was originally going to be based on RedHat. Apparently they made a (very wise, IMHO) decision to switch to SuSE half-way through development.