Just so noone gets the wrong idea, I do acknowledge that Intel processors are also good. I'm not a huge AMD proponent, just someone who uses what works well (especially for the budget), and thinks that AMD sometimes gets only the respect of a second-class chip maker, when it ranks up there with the best.
Actually, that's entirely incorrect. Intel processors do not have faster floating point math; in fact, the Athlon's floating point blows away the Pentium *'s FPU. If you're referring, instead, to the K6 family, you're also wrong. The K6 family is optimized for different things than the Pentium Pro family, and one change is that on a K6-family processor, the pipelines are shorter, thus making heavy and unoptimized FP slower. However, with 3DNow!, which the K6-2 and above support, FP usage can be optimized for the K6-family's architecture.
This is evident in Gogo, a free (speech, not beer) encoder, which on my K6-2 350 can encode 16-bit 44.1kHz Stereo audio to a 192kbps MP3 at a rate of 4.5 times real-time. When I encode my CDs, I get a song converted in about a minute. That should be evidence that AMD's processors are more than able to do real-time MP3 encoding, and more than one at a time.
What do you mean, "FreeBSD is in deap trouble"? Any time you have more than 200 people working on something, you'll have some conflict. There's no huge divisive war in FreeBSD, even if there are sometimes conflicts between a few people here and there.
It shouldn't be beta in OpenBSD, since it's production in FreeBSD. I only say "should" because SoftUpdates was developed first and reached production level first on BSD/OS, and it definitely does have some deep changes necessary to the UFS and VFS code for integration.
Not all of the packages are on one CD. I don't have the 4.0 CDs (don't laugh), but in the past, as the ports have grown, packages have been spread out across multiple CDs.
FreeBSD not being supported as a compilation platform by Sun isn't that bad of a thing. Sun would do well to support installation of StarOffice using Linux compatibility on FreeBSD, since many people _do_ use that. The big advantage of compiling for FreeBSD would be to save memory/swap for people who don't normally use Linux apps; it would probably also be faster by a perecentage or two.
I don't really disagree with Sun not doing a FreeBSD release, but they should attempt to support people installing the Linux version on an OS other than Linux.
Actually, your spaghetti goto C++ program is both syntactically and semantically correct (well, if you write it correctly;), but not stylistically correct. Stylistic correctness is much more qualitative than syntactic correctness, but still definable. Think of object-oriented, procedural, etc. as programming styles; C(|++) riddled with many gotos is definitely not proper C(|++) programming style, either procedural or object-oriented.
Actually, to make a small correction to your history: NetBSD and FreeBSD were both created at a similar time as descendents of the 386bsd patchkit (aka Jolix, by Bill Jolitz). The patchkit was based upon the free (later taken to court regarding:-(, so not as "free" as it should have been) 4.3BSD NET/2 release.
Anyway, the point is that NetBSD isn't the originator of FreeBSD. OpenBSD was forked from NetBSD, but FreeBSD was always a separate project from NetBSD.
I don't know what you mean about how they would "lose that competitive advantage". Podlipec (the author of XAnim) is quite willing to work under NDA, and he releases binary-only drivers for a bunch of codecs for several platforms. How do they lose any kind of advantage by allowing Unix users to play Sorenson video?
Glad to hear you like FreeBSD =) As for the drivers, I certainly won't be buying another NVidia card because of all of this, but there may be hope for the drivers. IIRC, the module architecture that was donated to and used in XFree86 3.9+ allows for per-architecture binary modules. In other words, one for i386, one for Alpha, one for PPC... so it's possible that the i386 module will be generic and not just for Linux, and it will work on FreeBSD, too. I'm not holding my breath, though.
I'm with you 100%! I bought a TNT for two reasons. The first reason was that its quality could not be matched by any other consumer card. The second reason is that I wanted something I could use under FreeBSD. Since that time, I've been using Windoze less than ever, and having not booted it at all for months and not caring to, my gaming is going to be on FreeBSD.
Yes, I'd like to play Quake 3, but the current drivers make it a huge pain to try to do so, I can't get the quality of the rendering of the drivers in Windoze (or even software Mesa rendering), much less the frame rate. Yes, the DRI would solve this, but NVidia have truly become bastards about this. They lured in people like me with the promises of REAL support, but let us all down.
I used to want a GeForce, and would have bought one, but NVidia is not committed to anything but money and doesn't do anything special. I really have very little hope anymore for my TNT to have decent performance under Unix. At the time I bought my TNT, the only other possibility was a Voodoo which was just as closed as anything else and not having drivers _I_ could have used. Now, they've got DRI drivers released, as Matrox also has.
My next 3D accelerator is going to be a Matrox. At least with a Matrox I'll know the company is actually going through with what they said they would.
No, there are no ISO 9660 images up yet. The reason for this is that the CDs haven't actually been created, and as such it wouldn't be right to put up an ISO for a release which hasn't completely "been released". Look for it in just a few days:)
I can speak for FreeBSD, at least, here. FreeBSD 4.0-RELEASE (almost, now... still -CURRENT at the moment) has had a _huge_ push to get IPv6 in everywhere. What we (will) have now is a full, official FreeBSD release with complete IPv6 support. Things can take time to change, but that doesn't mean they're staying the same.
Until around the last decade (maybe decade and a half), 150KB for a kernel was freaking huge as all hell. The original Unix kernel was about 20KB, and around Version 7 (mid-70s), the kernel was about 60KB.
Sorry for forgetting this link: http://bento.FreeBSD.org is the moniker for the actual port-building cluster. Satoshi's documented some very good ideas there, including trying each port under its own clean chroot to make sure dependencies are correct.
It seems you've already gotten the idea of putting multiple distros in chroots on the machine, so it could be trivially extended to have a tarball containing that environment that could be unpacked and chrooted to for testing:) That's how the building for 3.X-STABLE is done, on top of a 4.0-CURRENT base.
It might be really nice to have a ports-type tree to do this, with more simplistic Makefiles which have targets for configuring, compiling, installation, and cleaning. Full SourgeForge "tree" building could be done that way =)
You either seem to have some delusions about the real world here, or it seems that you're trying to write flamebait.
Increasingly, the quality of applications can be linked to the number of supported platforms and the number of geeky libraries required. The more platforms and fewer libraries, the better.
I'm sorry, but that's simply untrue. Libraries are there so everyone and their mother doesn't have to include the same freaking code in their programs. Libraries are to simplify things and allow code sharing. Maybe you're thinking about libraries from hell which enforce a particular coding style on the users (you know what I'm talking about.) I'm sorry, but I like to see my programs that use JPEG imaging linking with libjpeg, just as I like to see programs using compression streams linking with zlib. You cannot say anything about a program's quality because the author linked it with important support libraries.
1. The GNU version of tar 2. The GNU version of make
I think you meant to say here that programs shouldn't be using GNU extensions of anything. I can agree with that for the most part, but...
3. Any particular kind of C compiler beyond specifying ANSI compliance or other standards compliance
The only real standards for inline assembly usage are in GCC. You're also kidding yourself if you think that most C compilers are nearly as closely standard-compliant as GCC is with ANSI. When something requires machdep code, it has to be done reasonably.
Also, you really need to note that many things won't compile on some extremely esoteric operating systems because they are simply not a good enough facsimile of the Unix API. Don't pretend for one minute that anyone's going to stop using the Unix API for portable software.
Encouraging cross-platform compatibility (even though it's all just Unix ferchrissakes! *G*) is a good thing, especially with all of the people using SourceForge:) They could probably take some tips from the FreeBSD Ports port-builder cluster that Satoshi Asami runs; he's been running this for quite a while, and has the same situation of doing it for multiple platforms (and yes, FreeBSD 3.4-STABLE, 4.0-CURRENT, etc. are quite different platforms, if mostly just for the ABI). I would suggest that the person who's going to be running this at SourceForge should contact him and kindly ask for some tips on it =)
The state of trolling on slashdot is just sad. At one point, trolls were actually funny. Now, what do we have? Retarded, unoriginal lameness. I'd appreciate it if the idiot trolls would go away, and maybe we'd have some insightful and intelligent trolls.
This isn't unrealistic. Here's an example, in which Unix would have the right behavior. Why is it the right behavior? You _know_ what's going to happen, and things don't break.
ln -s/foo/bigfile sed -f lamescript bigfile
With the Windows COW behavior, this would do the wrong thing and undo the link, create another (huge) file, and possibly run you out of space. The proper way to do this would be to implement a hard link, symbolic link, and THEN if there's a dire need that "COW link". Otherwise, you break POLA for experienced users, and inexperienced users are just thoroughly confused.
{"/home/green"}$ ls -l big -rw-r--r-- 1 green green 8796093022207 Jan 31 01:48 big {"/home/green"}$ uname -a FreeBSD green.dyndns.org 4.0-CURRENT FreeBSD 4.0-CURRENT #69: Mon Feb 28 00:46:42 EST 2000 green@green.dyndns.org:/usr/src/sys/compile/GREEN i386
That's not a C program. That isn't valid K&R, pre-K&R, ANSI, C9X.... If you're trying to point out that C++ doesn't do implicit conversions like C will, that's a completely moot point. Either way, you can have the compiler warn, C++ or C, about that. You can have the compiler error out compiling C code because it converts the wrong types implicitly (without promotion), too.
Anyway, you really didn't respond to what I was saying. I said that C++ makes a big deal of hiding type differences, whereas in other languages you just use the proper type.
> And excellent argument for abandoning C and sticking with assembly:-)
Huh? C is meant to be portable and standard. It is really not an abstraction in a big sense. It enables you to do things without having to think about how you'll do it on XXX machine. C isn't for abstracting things; you can do that just as well in asm (though it's harder to get comfy with and maintain asm, IMHO). C++ _is_ about abstracting things away, hiding details that would be impossible to hide with assembly (type differences? Sure, no problem with overloading in C++, but...)
He said that there were almost 10,000 bugs logged, and over 97% fixed in the _entire_distribution_, not just the Linux kernel. I think this is a great testament to free software's model of open development being superior to a closed one. Red Hat will come with an httpd, named, X servers, etc. just like Windows 2000 will come with these corollaries you mentioned.
--
Re:Quantity of Linux code in *BSD?
on
BSD Quickies
·
· Score: 2
That's true. The main thing there is the ext2fs code, by the way. It's there because, if you need to, you can rip out all of the "gnu" directories from the source tree, distribute them, and not have to distribute any more to satisfy the GPL. As I recall, restrictive-licensed stuff is kept in both "gnu" directories and "contrib" directories.
Slashdot Mirror
--
This is evident in Gogo, a free (speech, not beer) encoder, which on my K6-2 350 can encode 16-bit 44.1kHz Stereo audio to a 192kbps MP3 at a rate of 4.5 times real-time. When I encode my CDs, I get a song converted in about a minute. That should be evidence that AMD's processors are more than able to do real-time MP3 encoding, and more than one at a time.
--
--
--
--
I don't really disagree with Sun not doing a FreeBSD release, but they should attempt to support people installing the Linux version on an OS other than Linux.
--
--
Anyway, the point is that NetBSD isn't the originator of FreeBSD. OpenBSD was forked from NetBSD, but FreeBSD was always a separate project from NetBSD.
--
--
--
--
Yes, I'd like to play Quake 3, but the current drivers make it a huge pain to try to do so, I can't get the quality of the rendering of the drivers in Windoze (or even software Mesa rendering), much less the frame rate. Yes, the DRI would solve this, but NVidia have truly become bastards about this. They lured in people like me with the promises of REAL support, but let us all down.
I used to want a GeForce, and would have bought one, but NVidia is not committed to anything but money and doesn't do anything special. I really have very little hope anymore for my TNT to have decent performance under Unix. At the time I bought my TNT, the only other possibility was a Voodoo which was just as closed as anything else and not having drivers _I_ could have used. Now, they've got DRI drivers released, as Matrox also has.
My next 3D accelerator is going to be a Matrox. At least with a Matrox I'll know the company is actually going through with what they said they would.
--
--
--
--
Sorry for forgetting this link:
http://bento.FreeBSD.org is the moniker for the actual port-building cluster. Satoshi's documented some very good ideas there, including trying each port under its own clean chroot to make sure dependencies are correct.
It seems you've already gotten the idea of putting multiple distros in chroots on the machine, so it could be trivially extended to have a tarball containing that environment that could be unpacked and chrooted to for testing :) That's how the building for 3.X-STABLE is done, on top of a 4.0-CURRENT base.
It might be really nice to have a ports-type tree to do this, with more simplistic Makefiles which have targets for configuring, compiling, installation, and cleaning. Full SourgeForge "tree" building could be done that way =)
--
Increasingly, the quality of applications can be linked to the number of supported platforms and the number of geeky libraries required. The more platforms and fewer libraries, the better.
I'm sorry, but that's simply untrue. Libraries are there so everyone and their mother doesn't have to include the same freaking code in their programs. Libraries are to simplify things and allow code sharing. Maybe you're thinking about libraries from hell which enforce a particular coding style on the users (you know what I'm talking about.) I'm sorry, but I like to see my programs that use JPEG imaging linking with libjpeg, just as I like to see programs using compression streams linking with zlib. You cannot say anything about a program's quality because the author linked it with important support libraries.
1. The GNU version of tar
2. The GNU version of make
I think you meant to say here that programs shouldn't be using GNU extensions of anything. I can agree with that for the most part, but...
3. Any particular kind of C compiler beyond specifying ANSI compliance or other standards compliance
The only real standards for inline assembly usage are in GCC. You're also kidding yourself if you think that most C compilers are nearly as closely standard-compliant as GCC is with ANSI. When something requires machdep code, it has to be done reasonably.
Also, you really need to note that many things won't compile on some extremely esoteric operating systems because they are simply not a good enough facsimile of the Unix API. Don't pretend for one minute that anyone's going to stop using the Unix API for portable software.
--
--
--
ln -s
sed -f lamescript bigfile
With the Windows COW behavior, this would do the wrong thing and undo the link, create another (huge) file, and possibly run you out of space. The proper way to do this would be to implement a hard link, symbolic link, and THEN if there's a dire need that "COW link". Otherwise, you break POLA for experienced users, and inexperienced users are just thoroughly confused.
--
{"/home/green"}$ ls -l big
-rw-r--r-- 1 green green 8796093022207 Jan 31 01:48 big
{"/home/green"}$ uname -a
FreeBSD green.dyndns.org 4.0-CURRENT FreeBSD 4.0-CURRENT #69: Mon Feb 28 00:46:42 EST 2000 green@green.dyndns.org:/usr/src/sys/compile/GREEN i386
--
Anyway, you really didn't respond to what I was saying. I said that C++ makes a big deal of hiding type differences, whereas in other languages you just use the proper type.
--
Huh? C is meant to be portable and standard. It is really not an abstraction in a big sense. It enables you to do things without having to think about how you'll do it on XXX machine. C isn't for abstracting things; you can do that just as well in asm (though it's harder to get comfy with and maintain asm, IMHO). C++ _is_ about abstracting things away, hiding details that would be impossible to hide with assembly (type differences? Sure, no problem with overloading in C++, but...)
--
--
--