Unfortunatly, it looks like nVidia has a fast product cycle, they release a new card every 6 months.
Only in their marketing. If that was really the case, they would have released NV20 6 month ago. Instead they released GeForce 2 Ultra which was more of the same but clocked slightly higher.
Oh, incidentally, what is the state of Radeon drivers for XFree86? Didn't ATI release the specs for it? ___
I'm not allowed to change into directory X, but since file.txt is world readable, I can go vi/home/X/file.txt
and see what is there...)
That's not true. r controls whether you can read the directory (i.e. do ls in it). x controls whether you can cd into a directory or access any files in it. If both r and x are disabled, then you can neither ls a directory nor access any files in it. The Unix permission system has its problems but this is not one of them. ___
Fat/vfat file systems don't have the concept of an "owner," but NTFS does. Ideally this ownership
information (and ACL permissions) will be retained even if someone sticks an NTFS-formatted zip disk into
a Linux box.
Well, this is not what happens now and I don't see it as a problem. NTFS is sufficiently different from a Linux native file system that this kind of ACL mapping would be next to impossible. But I don't see a problem with treating NTFS as a foreign file system and mapping everything on it to a single UID & GID. This is how it works now and even without introducing ACLs into VFS this is extremely unlikely to change because M$ is not releasing the specs for NTFS.
Once again, I would be perfectly happy with having ACLs only on Linux native file systems. The foreign file systems could (and in fact should) still be treated the same way they are now. I don't see the need of mapping NT ACLs into Linux ACLs, especially if removable media is involved. ___
I just don't see how you can assign one group ownership rights, one group read/write, and yet another group read only while not allowing "everyone" any kind of access
Me neither. But since you're talking about NT file server, the clients are windows boxes. In this case you can use Samba which supports just that. So at the local file system level you will not have this kind of flexibility. But when you export a share over samba you can specify just that.
How about allowing a group of folks the right to write to a file, but not delete it?
That's easy. Just give them write access to the file but not to the directory where the file lives. Well, the side effect of that is that they will not be able to create new files in that directory either.
Thing is, without
the granularity of ACL's I can't leave NTFS behind when it comes to the more complex task of file sharing
to a bunch of users on a LAN.
Ever heard of Solaris or Digital Unix or AIX? They all support ACLs too, you know.
Additionally, I've gotten quite used to the notion of leaving the OS permissions to Everyone on my files on
the server, then restrict access via the share permissions. The server itself is physically locked in a room so
I'm not normally concerned with local security. As cool as Samba is, it makes no provisions for
implementing permissions of any sort.
What a pile of BS! Samba can do just that. Why don't you RTFM before you spit out nonsence! ___
Hang on. Even though Linux supports lots of file systems, very few of them are "native". The native Linux file systems include ext2, ReiserFS, and the original ext (is it still around?). (Yes, I'm aware of XFS, JFS and ext3 but they are not ready yet). Files on these file systems have all the proper attributes (UID, GID and permissions). However, files on foreign file systems do not. For example, all files on fat16/fat32/ntfs/ have exact same UID, GID, and permissions. You can configure which UID, GID and umask it is via/etc/fstab, but whatever you specify there applies to *all* files on the file system. You cannot chown/chmod a file on a fat/ntfs/whatever partition simply because those file systems do not support that. (So basically chmod/chown on those file systems is a no-op).
Why couldn't Linux use the same paradigm for ACLs? All the native file systems would support the same ACL semantics and all the non-native ones would continue to be mapped to a single set of permissions. Or am I missing something? ___
Give me a break. His wording may not be 100% correct, but the point stands: Microsoft's Kerberos breaks interoperability with MIT Kerberos. And MS did this specifically to embrace and extend Kerberos. What part of that do you disagree with? ___
Both are 'by using this software, you're agreeing to the terms' type licenses.
Big factual error #1. Microsoft EULA (and most/all other EULAs) start off with the premise that they "grant" you the right to use the software if you agree to the following terms. If you disagree, you can refund the software (well, not really as we have already found out...).
Well, guess what? This "granting" of the righs is completely bogus. You have the right to use the software in any way you want. But only the copyright holder can distribute it. This is the premise the GPL starts off with. You can use the software in any way you want, but if you wish to distribute it, you must agree to the license. Thus, GPL is actually on a stronger legal ground than MS EULA (the copyright law covers the distribution, not use). This is the big error I wanted to point out. Other people did a good job at explaining the spirit of GPL. ___
So let me get this straight: You are going to file a frivolous lawsuit because Symantec chose not to file a frivolous lawsuit based on an obvious and unenforcible patent. God bless America! ___
You really don't understand Linux's abilities (and surprisingly not many people do since no one mentioned it in the replies yet). These boxes would have made perfect X terminals. The only thing they need to run is the X server itself; everything else runs on the app server. You could have donated them *one* mid-class machine and it would serve perfectly for several labs of X terminals. Also, since all applications run on the server, the clients never need upgrading (they are basically glorified monitors attached to the network). This would have helped the school a lot. When the server becomes too slow, they can just add another one and transfer some of the load to it. This is much cheaper than upgrading every computer in the lab.
My university has 5 labs of X terminals, except they are thin clients, not reused PCs. The advantage there is that these little boxes have no HDs (= no moving parts except for the tiny fan), and are really small and cheap. ___
I actually think it's stupid that the companies choose to use these formats. Not just because they are proprietary but also because they are inferior. Why not use mpeg? Its quality is much higher than RealPlayer/QuickTime/WindowsMedia, etc. and it's available on all platforms. ___
The Linux crowd sometimes also forget that the big Internet sites run OpenBSD, NOT Linux (a good example is Yahoo!).
First of all that's FreeBSD, not OpenBSD. I am not aware of any big web site that runs OpenBSD. Would you care to point one out?
Secondly, I can name quite a few big web sites that do run Linux: dejanews, google, amazon, etoys, walmart, salon magazine,... I'm not trying to knock *BSD in here, but check your facts before you post. ___
...but not quite. Last I heard (and that was *two years* ago), cdrom.com got upgraded to a *single* Xeon 450 (or 500?) with 4 GB RAM. Also, the number of simultaneous conntections was increased to 5000. ___
You don't get it. If remote root login is enabled, the attacker only needs to brute-force root password. If it is disabled, then you first need to break into a regular user account (and before that, you need to somehow find out the username), and then get root. The latter is considerably harder. ___
He explicitely said that these benchmarks are not scientific and are merely his opinion. Therefore, this error is permissible. Besides, this optimization depends highly on the compiler used. My understanding is that gcc does not do as good a job optimizing as some other compilers. Furthermore, even if this stuff did get optimized out, I don't see how it would change the outcome of this comparison.
All in all, this is the best comparison between FreeBSD and Linux I've seen yet. Everything else I've heard up until now was basically anecdotal evidence and hearsay. Yes, this is not a real benchmark. But at least it shows some evidence.
Notice how he says that tweaking Linux improved performance a lot. If anything, this shows that out of the box, FreeBSD is better tweaked for a server than Linux, which makes sence -- FreeBSD is primarily a server OS, while Linux is targeted for both desktop and server, and different distributions configure the kernel differently. What I would like to see is a benchmark of fully-tweaked Linux (once 2.4.x tree stabilizes) and fully-tweaked FreeBSD. ___
Slashdot Mirror
Does anyone know if the QT that comes with Mandrake 7.2 was compiled with exceptions disabled?
___
Why is he not representing the government? Did Bush decide to get rid of him?
___
Only in their marketing. If that was really the case, they would have released NV20 6 month ago. Instead they released GeForce 2 Ultra which was more of the same but clocked slightly higher.
Oh, incidentally, what is the state of Radeon drivers for XFree86? Didn't ATI release the specs for it?
___
That's not true. r controls whether you can read the directory (i.e. do ls in it). x controls whether you can cd into a directory or access any files in it. If both r and x are disabled, then you can neither ls a directory nor access any files in it. The Unix permission system has its problems but this is not one of them.
___
Oh, and Veritas FS does not support ACLs :-)
Which one do want more?
___
Solaris does *not* have journalling. Unless you want to spend $10K for Veritas
___
Well, this is not what happens now and I don't see it as a problem. NTFS is sufficiently different from a Linux native file system that this kind of ACL mapping would be next to impossible. But I don't see a problem with treating NTFS as a foreign file system and mapping everything on it to a single UID & GID. This is how it works now and even without introducing ACLs into VFS this is extremely unlikely to change because M$ is not releasing the specs for NTFS.
Once again, I would be perfectly happy with having ACLs only on Linux native file systems. The foreign file systems could (and in fact should) still be treated the same way they are now. I don't see the need of mapping NT ACLs into Linux ACLs, especially if removable media is involved.
___
Me neither. But since you're talking about NT file server, the clients are windows boxes. In this case you can use Samba which supports just that. So at the local file system level you will not have this kind of flexibility. But when you export a share over samba you can specify just that.
How about allowing a group of folks the right to write to a file, but not delete it?
That's easy. Just give them write access to the file but not to the directory where the file lives. Well, the side effect of that is that they will not be able to create new files in that directory either.
Thing is, without the granularity of ACL's I can't leave NTFS behind when it comes to the more complex task of file sharing to a bunch of users on a LAN.
Ever heard of Solaris or Digital Unix or AIX? They all support ACLs too, you know.
Additionally, I've gotten quite used to the notion of leaving the OS permissions to Everyone on my files on the server, then restrict access via the share permissions. The server itself is physically locked in a room so I'm not normally concerned with local security. As cool as Samba is, it makes no provisions for implementing permissions of any sort.
What a pile of BS! Samba can do just that. Why don't you RTFM before you spit out nonsence!
___
Can somebody please explain what this means?
___
Hang on. Even though Linux supports lots of file systems, very few of them are "native". The native Linux file systems include ext2, ReiserFS, and the original ext (is it still around?). (Yes, I'm aware of XFS, JFS and ext3 but they are not ready yet). Files on these file systems have all the proper attributes (UID, GID and permissions). However, files on foreign file systems do not. For example, all files on fat16/fat32/ntfs/ have exact same UID, GID, and permissions. You can configure which UID, GID and umask it is via /etc/fstab, but whatever you specify there applies to *all* files on the file system. You cannot chown/chmod a file on a fat/ntfs/whatever partition simply because those file systems do not support that. (So basically chmod/chown on those file systems is a no-op).
Why couldn't Linux use the same paradigm for ACLs? All the native file systems would support the same ACL semantics and all the non-native ones would continue to be mapped to a single set of permissions. Or am I missing something?
___
Give me a break. His wording may not be 100% correct, but the point stands: Microsoft's Kerberos breaks interoperability with MIT Kerberos. And MS did this specifically to embrace and extend Kerberos. What part of that do you disagree with?
___
Where the hell did you get that idea? There is no legal basis for this. And who is "everyone"?
___
Can somebody please clarify the star treck reference?
___
Big factual error #1. Microsoft EULA (and most/all other EULAs) start off with the premise that they "grant" you the right to use the software if you agree to the following terms. If you disagree, you can refund the software (well, not really as we have already found out...).
Well, guess what? This "granting" of the righs is completely bogus. You have the right to use the software in any way you want. But only the copyright holder can distribute it. This is the premise the GPL starts off with. You can use the software in any way you want, but if you wish to distribute it, you must agree to the license. Thus, GPL is actually on a stronger legal ground than MS EULA (the copyright law covers the distribution, not use). This is the big error I wanted to point out. Other people did a good job at explaining the spirit of GPL.
___
So let me get this straight: You are going to file a frivolous lawsuit because Symantec chose not to file a frivolous lawsuit based on an obvious and unenforcible patent. God bless America!
___
You really don't understand Linux's abilities (and surprisingly not many people do since no one mentioned it in the replies yet). These boxes would have made perfect X terminals. The only thing they need to run is the X server itself; everything else runs on the app server. You could have donated them *one* mid-class machine and it would serve perfectly for several labs of X terminals. Also, since all applications run on the server, the clients never need upgrading (they are basically glorified monitors attached to the network). This would have helped the school a lot. When the server becomes too slow, they can just add another one and transfer some of the load to it. This is much cheaper than upgrading every computer in the lab.
My university has 5 labs of X terminals, except they are thin clients, not reused PCs. The advantage there is that these little boxes have no HDs (= no moving parts except for the tiny fan), and are really small and cheap.
___
Let me guess - Amazon?
___
I actually think it's stupid that the companies choose to use these formats. Not just because they are proprietary but also because they are inferior. Why not use mpeg? Its quality is much higher than RealPlayer/QuickTime/WindowsMedia, etc. and it's available on all platforms.
___
read ipchains howto at www.linuxdoc.org
___
Well, you could run it remotely. But I'm not sure if the network speed would be enough to watch movies. Sun claims it is.
___
So the most advanced OS is one which has the most drivers. OK. I never knew windows 95 was the most advanced. Thanks for enlightening me.
___
First of all that's FreeBSD, not OpenBSD. I am not aware of any big web site that runs OpenBSD. Would you care to point one out?
Secondly, I can name quite a few big web sites that do run Linux: dejanews, google, amazon, etoys, walmart, salon magazine,... I'm not trying to knock *BSD in here, but check your facts before you post.
___
...but not quite. Last I heard (and that was *two years* ago), cdrom.com got upgraded to a *single* Xeon 450 (or 500?) with 4 GB RAM. Also, the number of simultaneous conntections was increased to 5000.
___
You don't get it. If remote root login is enabled, the attacker only needs to brute-force root password. If it is disabled, then you first need to break into a regular user account (and before that, you need to somehow find out the username), and then get root. The latter is considerably harder.
___
He explicitely said that these benchmarks are not scientific and are merely his opinion. Therefore, this error is permissible. Besides, this optimization depends highly on the compiler used. My understanding is that gcc does not do as good a job optimizing as some other compilers. Furthermore, even if this stuff did get optimized out, I don't see how it would change the outcome of this comparison.
All in all, this is the best comparison between FreeBSD and Linux I've seen yet. Everything else I've heard up until now was basically anecdotal evidence and hearsay. Yes, this is not a real benchmark. But at least it shows some evidence.
Notice how he says that tweaking Linux improved performance a lot. If anything, this shows that out of the box, FreeBSD is better tweaked for a server than Linux, which makes sence -- FreeBSD is primarily a server OS, while Linux is targeted for both desktop and server, and different distributions configure the kernel differently. What I would like to see is a benchmark of fully-tweaked Linux (once 2.4.x tree stabilizes) and fully-tweaked FreeBSD.
___