{"/home/green"}$ ls -l big -rw-r--r-- 1 green green 8796093022207 Jan 31 01:48 big
That's 8 terabytes (not tibobytes, or whatever that SI idiocy is), the limit for file size on FFS. No, I didn't just fake that file. For what it's worth, I don't see why the files have to be limited to 64 gigabytes on JFS.
Matt Dillon is just another normal committer, the same as any other. You really shouldn't speak authoritatively on a subject if you don't know anything about the reality. Weak try at FUD you've got there.
In one word, absolutely! NFS has had a tremendous amount of work done upon it by Matt Dillon, Alfred Perlstein, and a list of other people. In short, every bug that has been found so far in NFS has been fixed. Many bugs have stuck around or crept in over the years, and Matt Dillon is largely responsible for NFS truly being a seriously usable system in FreeBSD. Regarding AMD, FreeBSD 4.0-CURRENT has a much newer version of AMD; I am pretty certain the specific deficiency you mention has been fixed. Thanks to work mostly done by Martin Blapp, mount now shows the mount parameters correctly in (what seems to be, I cannot speak in complete certainty due to that being impossible to assure) every case. Have you reported how the package system "fails to register all the files"? I haven't seen this behavior. As far as ports not having to be built as root, if you set the make/environment variable "DISTDIR" to any accessible directory, and set "WRKDIRPREFIX" to an accessible directory, you will be able to make ports as a user.
Right now it's a 1:all model (as opposed to 1:many, etc). One process is multiplexed to create many "user threads". There has been discussion on the freebsd-arch mailing list about new threading models, but other than just using the ported LinuxThreads or the builtin pthreads, the only pthreads your going to have will be 1:1 or 1:all. Of course, winethreads (?) are now being developed... and FreeBSD will have a much better (read: efficient under SMP) threading scheme not too far off.
"Larger hardware support for Linux is largely a myth. There happen to be more both closed drivers and toy drivers for Linux."
Which means:
For the most part, there really isn't hardware that Linux supports, but FreeBSD doesn't. There are a lot more drivers for weird dongles and doodads for Linux due to its very hobbyist beginnings and people using it as an easy way to run some hardware. FreeBSD is used less often for toy hardware, and doesn't have many toy drivers.
rhetorical adj 2: concerned with effect or style of writing and speaking; "a rhetorical question is one asked solely to produce an effect (especially to make an assertion) rather than to elicit a reply" [ant: {unrhetorical}]
Yes, the original poster that I had replied to was making rhetorical questions with incorrect implications. The person was not asking "newbie questions". The person who _was_ had a well-thought-out post, and that is what the troll replied to with his drivel.
Right, of course, everything corroborates your view, especially the very recent posts about the GNUstep code freeze and Linux development kernel release...
Oh please. I said that the differences are largely a myth, not that the UltraSparc is a toy. There isn't support for UltraSparc in FreeBSD because Sun pulled out its funding for it, and obviously noone's very interested in that platform enough to do it without that funding that Sun was originally providing.
Outside of Linux circles, "IP masquerading" is called NAT (network address translation). This is supported in FreeBSD in the form of natd, and more specific information on setting it up can be found in numerous places.
Yes, that's true. For many people, there wouldn't really be a compelling reason to change; people need to have a reason that they want something else.
The point of my posting was just to clarify things, since I don't want to turn someone off to FreeBSD as a desktop OS if they haven't tried it already:)
I get the feeling quite often that FreeBSD doesn't get particularly fairly represented, because some of those people who say things about it must have really never run it. Obviously, you aren't one of those people =)
First of all, it was a troll. Obviously the person knew enough that they _could_ have easily figured it out themselves. So either they're a troll, or an idiot living under a rock. It would be different if they were just an ignorant (not being used as an insult; consult the dictionary if you like) user, and didn't know where to find information. Instead, it was a post of rhetorical questions which were nothing more than a troll from an idiot.
Second of all, FreeBSD is sold in stores. Try computer stores, bookstores, et cetera.
Third, this troll was not trying "our software". The troll was accusingly issuing rhetorical questions which were just plain incorrect.
You really need to get your facts straight before trying to criticize others.
I'm certain that's not true, unless for some reason the jail()ed user is both root and jailed to no special directory (just "/"), or for some reason you mknod the wrong devices for him (like mem devices, or hard disk devices, etc).
> The ports collection isn't on the bleeding edge though, and if you want the very latest version of a particular piece of software you may well have to install it yourself.
The maintainers of various ports are by and large the users of those various ports, who track the software as well as any good user can, and update the ports whenever possible. As long as you CVSup (and/or cvs update) your ports, you'll have almost all of the latest software. The biggest reason for a port being behind, other than the port maintainer not noticing it being updated, would be sotware which is very hard to fix for the latest version.
> I don't recommend FreeBSD to casual desktop users; they'll find more software for Linux, and more people to help them out.
I wouldn't say that. You can find all the help you could want in form of helpful people on the various mailing lists (freebsd-questions comes to mind). Any Linux software I've seen that doesn't require its own proprietary kernel module runs on FreeBSD, so if you can't find something (closed) for FreeBSD, find it for Linux and run that. With over 3,000 ports, it's extremely hard to find a better collection of software.
I use FreeBSD for the "desktop", and have done so for two years. Take this as fact, not conjecture: FreeBSD makes a great desktop OS, despite the fact that someone running FreeBSD for a desktop will still have to learn just like any other OS.
Yes, you're right. We shouldn't get to hear music before we buy it because then we'd actually be an _educated_consumer_ and know that we'll enjoy what we're buying! Of course, there is also _no_ legitimate use for the MP3 formats, since MP3 was only popular because it aims to destroy the commercial music industry with piracy!
The only real difference between on-stack and on-heap allocation is that on-heap can be faster due to not having to call code to "gather" that memory. Heap and stack are both the same COW, zero-filled-on-creation, VM objects, with very little difference in semantics (i.e. growing up or down on page fault). If you tend to use "malloc()/free()/new/delete" a lot, you'll pull in more heap, causing page faults, and freeing it later, causing it to possibly be marked "unused" by the system and waiting to be page faulted again later. If you use the stack a lot, you cause the exact same kind of faulting and page reclamation (if marking stack unused). What's the big difference? Well, with dynamic memory allocation (a misnomer since "static allocation" is dynamic in much the same way) with malloc/free/etc., you run special code which allocates the memory, handles the alignment of it, etc. With on-heap allocation, you just force that work to be repeated (albeit in a smaller manner) in assembly as part of the function code. The compiler itself generates that, but it's still the same thing: managing your memory allocation with code. The difference is just in it being explicit or implicit: is it done by me, or the compiler? In any case, I'll wager that there will be absolutely no measurable difference in speed between something that uses a _good_ memory allocator to allocate everything on the heap, and a _good_ compiler while allocating things on the stack. Feel free to prove me wrong, since I'm easily swayed by that:) Note that I don't expect that I'm wrong;)
Wow, it's mostly compliant?!? Sorry, but you've got it completely backwards. Yes, Internet Exploder is closer than ever to supporting standards that are YEARS OLD, but Mozilla actually supports XML, HTML 4.0, and CSS* completely. ECMAscript compliant IE? Don't make me laugh. I'll believe it when I see all the ECMAscript compliance tests that are in Mozilla's source tree work perfectly under IE. Oh, yeah, IE is slow as hell, too.
Slashdot Mirror
-rw-r--r-- 1 green green 8796093022207 Jan 31 01:48 big
That's 8 terabytes (not tibobytes, or whatever that SI idiocy is), the limit for file size on FFS. No, I didn't just fake that file. For what it's worth, I don't see why the files have to be limited to 64 gigabytes on JFS.
--
--
Regarding AMD, FreeBSD 4.0-CURRENT has a much newer version of AMD; I am pretty certain the specific deficiency you mention has been fixed.
Thanks to work mostly done by Martin Blapp, mount now shows the mount parameters correctly in (what seems to be, I cannot speak in complete certainty due to that being impossible to assure) every case.
Have you reported how the package system "fails to register all the files"? I haven't seen this behavior. As far as ports not having to be built as root, if you set the make/environment variable "DISTDIR" to any accessible directory, and set "WRKDIRPREFIX" to an accessible directory, you will be able to make ports as a user.
--
--
"Larger hardware support for Linux is largely a myth. There happen to be more both closed drivers and toy drivers for Linux."
Which means:
For the most part, there really isn't hardware that Linux supports, but FreeBSD doesn't. There are a lot more drivers for weird dongles and doodads for Linux due to its very hobbyist beginnings and people using it as an easy way to run some hardware. FreeBSD is used less often for toy hardware, and doesn't have many toy drivers.
--
adj 2: concerned with effect or style of writing and speaking; "a
rhetorical question is one asked solely to produce an
effect (especially to make an assertion) rather than to
elicit a reply" [ant: {unrhetorical}]
--
--
--
--
--
--
--
As you can see, I already explained myself around a few posts up. You really need to try to read everything before posting.
--
Outside of Linux circles, "IP masquerading" is called NAT (network address translation). This is supported in FreeBSD in the form of natd, and more specific information on setting it up can be found in numerous places.
One place to get more informations, other than mailing list searching, is a great site called The FreeBSD Diary, where there's actually an entire section of the topics devoted to NAT :)
--
The point of my posting was just to clarify things, since I don't want to turn someone off to FreeBSD as a desktop OS if they haven't tried it already
I get the feeling quite often that FreeBSD doesn't get particularly fairly represented, because some of those people who say things about it must have really never run it. Obviously, you aren't one of those people =)
--
Second of all, FreeBSD is sold in stores. Try computer stores, bookstores, et cetera.
Third, this troll was not trying "our software". The troll was accusingly issuing rhetorical questions which were just plain incorrect.
You really need to get your facts straight before trying to criticize others.
--
--
The maintainers of various ports are by and large the users of those various ports, who track the software as well as any good user can, and update the ports whenever possible. As long as you CVSup (and/or cvs update) your ports, you'll have almost all of the latest software. The biggest reason for a port being behind, other than the port maintainer not noticing it being updated, would be sotware which is very hard to fix for the latest version.
--
I wouldn't say that. You can find all the help you could want in form of helpful people on the various mailing lists (freebsd-questions comes to mind). Any Linux software I've seen that doesn't require its own proprietary kernel module runs on FreeBSD, so if you can't find something (closed) for FreeBSD, find it for Linux and run that. With over 3,000 ports, it's extremely hard to find a better collection of software.
I use FreeBSD for the "desktop", and have done so for two years. Take this as fact, not conjecture: FreeBSD makes a great desktop OS, despite the fact that someone running FreeBSD for a desktop will still have to learn just like any other OS.
--
--
I'm now thoroughly convinced of your idiocy.
--
--
If you tend to use "malloc()/free()/new/delete" a lot, you'll pull in more heap, causing page faults, and freeing it later, causing it to possibly be marked "unused" by the system and waiting to be page faulted again later. If you use the stack a lot, you cause the exact same kind of faulting and page reclamation (if marking stack unused).
What's the big difference? Well, with dynamic memory allocation (a misnomer since "static allocation" is dynamic in much the same way) with malloc/free/etc., you run special code which allocates the memory, handles the alignment of it, etc. With on-heap allocation, you just force that work to be repeated (albeit in a smaller manner) in assembly as part of the function code. The compiler itself generates that, but it's still the same thing: managing your memory allocation with code.
The difference is just in it being explicit or implicit: is it done by me, or the compiler? In any case, I'll wager that there will be absolutely no measurable difference in speed between something that uses a _good_ memory allocator to allocate everything on the heap, and a _good_ compiler while allocating things on the stack. Feel free to prove me wrong, since I'm easily swayed by that
--
--
--