There is sense in "encrypting" the passwords using one-way hashing. This allows users' passwords to still be resonably secure.
The reasoning behind this is: Users often use the same passwords for multiple accounts. Not storing the password in cleartext safeguards data that might be stored in a different application on a completely seperate server (Different OS, data backing store, etc.).
Of course, the best practice would be to do any authentication via LDAP and have this machine be watched closely by network security staff, but most application and web developers are lazy and do not take the extra steps required to deploy apps that make "security sense" and implement their own login schemes.
Encrypting all of the user data using reversible encryption is indeed pointless... People do this in the real world???
I've used various os' and distros inc win3.11, win95, Win98 (rtm&se), winMe, win2k, winXP, bsdi, solaris, redhat, debian, suse, gentoo. And always end up coming back to FreeBSD. It just seems to make sense, don't need to guess (I started on SysV), tried others still end up coming back to FreeBSD.
It's all a matter of personal preference. Just use whatever tool you are most comfortable with!
MacOS X precisely went away from the "FS that doesn't require extensions to the file name" because the of lack of portability of resource forks and/or associated filesystem metadata.
Let's face it, a.jpg is an image, a.doc is a word document and a.zip is an archive. This has pretty much become folklore.
If BigBusiness is not 0 and Bigwigs is not 0, then the value of DMCA.fans is true (Across the board, which in real life isn't true...). A better analogy would have been to use a logical OR, hence using DMCA.fans as a bitfield:
DMCA.fans = BigBusiness | Bigwigs;
As many fellow slashdotters, I am happy to see this case come to an end and finally see some sanity in the courts. I know a few people that work at Lexmark (In Kentucky, out of all places) that were rooting against their employer in the case... Sad, isn't it?
There have been multiple fixes to address the inefficiencies of the original design of the BSD TCP/IP stack.
FreeBSD for example, has a kernel option called ZERO_COPY_SOCKETS, which dramatically increases network throughput of syscalls such as sendfile(2). With this option enabled, as the name entails, data is no longer copied from userland to kernel space and then passed onto the network card's ringbuffers. It is copied in one swoop!
This has come to be in the server space. Select servers (Usually mid-level and higher) from the likes of Dell have had 64-bit PCI slots in them for at least 4 years now.
It is becoming more common to see onboard ethernet cards in user systems as it frees up a PCI slot. There isn't any reason (Cost aside) as to why these cards could not be interfaced to existing 133-Mhz PCI-X bridges.
Remember that a 64-bit bus alone does not give you extra throughput. Transfering data at higher clock rates, on edge and level will. There are even 64bit/33Mhz slots around and they offer very little advantage over 32bit/33Mhz ones...
First checksum offloading, now this... It is nice to see that hardware vendors are realizing that 10Gbit/s+ speeds aren't currently realistic without extra forms of computation support from the underlying network interface hardware.
I mount my NFS mounts at the command line, and I have yet to run into any major issues. I didn't bother with the GUI-stuff...:)
The XONX X-server project on Sourceforge works nicely. I switched to the "X11.app" package from Apple and it works even better. For anyone with an OSX machine that wants to install additional software that you have gotten used to on a UNIX machine, I strongly suggest that you install darwinports (From darwinports.org) and let it manage your packages for you.
OSX "UNIX-friendliness" has come a long way since 10.0!
The sale of goods with this type of clause is not permitted in the United States under the Fair Trade Act. You are entitled to resell goods (Not services) that were sold to you.
In the case of a software license, you must uninstall the software and destroy any backup copies that you may have made (As stated in the software's EULA).
I am not making an exception to the exception. In fact, I am not even talking about HyperThreading. What I did say is that using GCC 3.x with P4 as a target produced broken code until very recently and as such, the architecture has not gotten the amount of scrutiny as it could have.
The default install of FreeBSD doesn't do HTT or SMP without a kernel recompile. My beef with this benchmark is as follows: How about you test the benchmark on other platforms/cpus? In order to truly assertain that NetBSD 2.0 is faster than FreeBSD 5.3 latency-wise, more than just one target should be tested. Without doing so, all that has been "proven" is that NetBSD performed better on the given hardware and this tidbit is useless information as the board they used is designed for desktops in the first place. Care to indicate which chipset the Asus P4-800SE uses anyway (ASUS' site appears to be down)?
Moreover, Hyperthreading is really "less SMP than more". Sure you have an APIC with two target IDs, but you still have one CPU core, which presents two virtual cores to the operating system. To the uninitiated, this means that the two virtual CPUs share the L1 cache, which is suboptimal on lower end P4 with small caches (The number of cache flushes because of misses is scary).
If arguing over the technical merits (Or lack thereof) of a benchmark makes me a fanboy then congrats, you have me pinned down pretty good!:-)
Under load, I find that my RELENG_5 machines have higher network throughput than my RELENG_4 boxes. I am using mainstream server hardware with a nicely fine-grained set of network (nge) and SCSI RAID (amr) drivers. Would you care to share what kind of hardware you are using?
Matt and John aren't the only people that have worked on the locking of the kernel and drivers. Credit also goes out to Poul-Henning Kamp, Alan Cox, Jeff Robertson, Robert Watson and a lot of others that have reviewed, commented and submitted patches to all of sys/dev/ and sys/kern/.
As a sidenote, Dillon has also said a number of things that have been greatly unpopular, some of which have shown his unwillingness to think outside the box. I think the whole episode where core removed his bit, shows just how hot-headed he could be at times. That said, I have great respect for him as a programmer -- His stuff works.
OTOH, do you know what the advantage of FGL over BKL on 2-way systems is? Zero, absolutely nothing. So my bet is that NetBSD kicks FreeBSD's ass on 2-way systems as well.
Nothing could be further from the truth. Here's why:
Big Kernel Lock (BKL) systems can only have one processor doing something in the kernel at one time. There's only so much work that can be performed in user-land before re-entry into the kernel is necessary. At this point the application processor (AP) is spinning, waiting around for the mother-of-locks ("Giant" on FreeBSD) to be released by another AP. The more processors are present in the system, the bigger the contention on the single kernel lock becomes.
Fine Grained Locking (FGL) allows a system with multiple CPUs to enter the kernel and perform work that is at hand or read the process runqueue to perform work in user-land. Sure you do run into instances where two (or possibly even more) CPUs need to perform an operation within a given critical section, but at this point the granularity of the locking allows for atomic operations per CPU to be performed before the critical section's mutex is released. This effectively prevents race conditions that would be encountered, if no locking was present. It also allows as many CPUs as your system can hold to perform the various tasks (Fetch, store, etc) at near full-speed (The finer the locking, the less waiting around for mutexes/locks there is).
It is important to note that all of the tests that were performed where done on a uni-processor workstation.
The blanket statement that "NetBSD 2.0 has better threading and process management and network latency than FreeBSD 5.3" does not hold water when the test suite is run on 2 and 4-way SMP systems. FreeBSD 5.x is an amazing engineering effort in which various parts of the kernel have been locked down and decent thread concurancy can occur on multi-proc machines. Part of the latency that you see in these benchmarks are due to the mtx_lock() and mtx_unlock() overhead that is incurred.
It is also important to note that P4-systems with HyperThreading (As the one used in these tests) have been the "bastard child" on FreeBSD. For the longest of times, compiling anything with CPUTYPE=p4 would produce broken code (In all fairness, this was mostly due to a set of bugs in GCC 3.x). Significant work was put into 5.3 to ensure that the Pentium 4 lived up to the Tier-1 platform robustness standard. In short, it would be fun to see these benchmarks be run on i386/pentium3, i386/Athlon-MP, amd64/opteron and Alpha as well!
Sorry, but leaving your cell phone on during your lunchbreak is just begging to be bugged. This is definately the type of thing that would not get you hired at Google.;)
A properly designed Java app will almost always be slower than its properly-designed C counterpart. The time-to-market might be in the Java app's favor but when it comes to run-time performance, native API (Which are usually written in C) applications take the cake.
Could it be that the various manufacturers have a large stock of the smaller drives that they're trying to get rid of before putting larger ones to market?
Maybe it is due to the fact that SCSI storage has typically doubled in size... 9.1, 18.2, 36.4, 72.8, 145.6... Could it be that they're currently testing 291.2GB disks?
Slashdot Mirror
There is sense in "encrypting" the passwords using one-way hashing. This allows users' passwords to still be resonably secure.
The reasoning behind this is: Users often use the same passwords for multiple accounts. Not storing the password in cleartext safeguards data that might be stored in a different application on a completely seperate server (Different OS, data backing store, etc.).
Of course, the best practice would be to do any authentication via LDAP and have this machine be watched closely by network security staff, but most application and web developers are lazy and do not take the extra steps required to deploy apps that make "security sense" and implement their own login schemes.
Encrypting all of the user data using reversible encryption is indeed pointless... People do this in the real world???
None of your bases are belong to us. ;)
Check for UFS variants (UFS, FFS, UFS2). Pico and NanoBSD are popular choices for really small single-purpose devices.
I disagree.
I've used various os' and distros inc win3.11, win95, Win98 (rtm&se), winMe, win2k, winXP, bsdi, solaris, redhat, debian, suse, gentoo. And always end up coming back to FreeBSD. It just seems to make sense, don't need to guess (I started on SysV), tried others still end up coming back to FreeBSD.
It's all a matter of personal preference. Just use whatever tool you are most comfortable with!
This would be true... If it weren't for the fact that the Opteron can run regular x86 binaries (And operating systems) in its 32-bit mode.
Does this process descend from init? :)
MacOS X precisely went away from the "FS that doesn't require extensions to the file name" because the of lack of portability of resource forks and/or associated filesystem metadata.
.jpg is an image, a .doc is a word document and a .zip is an archive. This has pretty much become folklore.
Let's face it, a
If BigBusiness is not 0 and Bigwigs is not 0, then the value of DMCA.fans is true (Across the board, which in real life isn't true...). A better analogy would have been to use a logical OR, hence using DMCA.fans as a bitfield:
DMCA.fans = BigBusiness | Bigwigs;
As many fellow slashdotters, I am happy to see this case come to an end and finally see some sanity in the courts. I know a few people that work at Lexmark (In Kentucky, out of all places) that were rooting against their employer in the case... Sad, isn't it?
My $0.02.
There have been multiple fixes to address the inefficiencies of the original design of the BSD TCP/IP stack.
FreeBSD for example, has a kernel option called ZERO_COPY_SOCKETS, which dramatically increases network throughput of syscalls such as sendfile(2). With this option enabled, as the name entails, data is no longer copied from userland to kernel space and then passed onto the network card's ringbuffers. It is copied in one swoop!
This has come to be in the server space. Select servers (Usually mid-level and higher) from the likes of Dell have had 64-bit PCI slots in them for at least 4 years now.
It is becoming more common to see onboard ethernet cards in user systems as it frees up a PCI slot. There isn't any reason (Cost aside) as to why these cards could not be interfaced to existing 133-Mhz PCI-X bridges.
Remember that a 64-bit bus alone does not give you extra throughput. Transfering data at higher clock rates, on edge and level will. There are even 64bit/33Mhz slots around and they offer very little advantage over 32bit/33Mhz ones...
First checksum offloading, now this... It is nice to see that hardware vendors are realizing that 10Gbit/s+ speeds aren't currently realistic without extra forms of computation support from the underlying network interface hardware.
This is Good News.
1. Dig a 1-meter deep trench.
2. Install the Cat 5e.
3. ???
4. Profit!
Come on guys, how hard could spelling "Vulnerabilities" correctly be?
I mount my NFS mounts at the command line, and I have yet to run into any major issues. I didn't bother with the GUI-stuff... :)
The XONX X-server project on Sourceforge works nicely. I switched to the "X11.app" package from Apple and it works even better. For anyone with an OSX machine that wants to install additional software that you have gotten used to on a UNIX machine, I strongly suggest that you install darwinports (From darwinports.org) and let it manage your packages for you.
OSX "UNIX-friendliness" has come a long way since 10.0!
The sale of goods with this type of clause is not permitted in the United States under the Fair Trade Act. You are entitled to resell goods (Not services) that were sold to you.
In the case of a software license, you must uninstall the software and destroy any backup copies that you may have made (As stated in the software's EULA).
I am not making an exception to the exception. In fact, I am not even talking about HyperThreading. What I did say is that using GCC 3.x with P4 as a target produced broken code until very recently and as such, the architecture has not gotten the amount of scrutiny as it could have.
:-)
The default install of FreeBSD doesn't do HTT or SMP without a kernel recompile. My beef with this benchmark is as follows: How about you test the benchmark on other platforms/cpus? In order to truly assertain that NetBSD 2.0 is faster than FreeBSD 5.3 latency-wise, more than just one target should be tested. Without doing so, all that has been "proven" is that NetBSD performed better on the given hardware and this tidbit is useless information as the board they used is designed for desktops in the first place. Care to indicate which chipset the Asus P4-800SE uses anyway (ASUS' site appears to be down)?
Moreover, Hyperthreading is really "less SMP than more". Sure you have an APIC with two target IDs, but you still have one CPU core, which presents two virtual cores to the operating system. To the uninitiated, this means that the two virtual CPUs share the L1 cache, which is suboptimal on lower end P4 with small caches (The number of cache flushes because of misses is scary).
If arguing over the technical merits (Or lack thereof) of a benchmark makes me a fanboy then congrats, you have me pinned down pretty good!
Under load, I find that my RELENG_5 machines have higher network throughput than my RELENG_4 boxes. I am using mainstream server hardware with a nicely fine-grained set of network (nge) and SCSI RAID (amr) drivers. Would you care to share what kind of hardware you are using?
Matt and John aren't the only people that have worked on the locking of the kernel and drivers. Credit also goes out to Poul-Henning Kamp, Alan Cox, Jeff Robertson, Robert Watson and a lot of others that have reviewed, commented and submitted patches to all of sys/dev/ and sys/kern/.
As a sidenote, Dillon has also said a number of things that have been greatly unpopular, some of which have shown his unwillingness to think outside the box. I think the whole episode where core removed his bit, shows just how hot-headed he could be at times. That said, I have great respect for him as a programmer -- His stuff works.
OTOH, do you know what the advantage of FGL over BKL on 2-way systems is? Zero, absolutely nothing. So my bet is that NetBSD kicks FreeBSD's ass on 2-way systems as well.
Nothing could be further from the truth. Here's why:
Big Kernel Lock (BKL) systems can only have one processor doing something in the kernel at one time. There's only so much work that can be performed in user-land before re-entry into the kernel is necessary. At this point the application processor (AP) is spinning, waiting around for the mother-of-locks ("Giant" on FreeBSD) to be released by another AP. The more processors are present in the system, the bigger the contention on the single kernel lock becomes.
Fine Grained Locking (FGL) allows a system with multiple CPUs to enter the kernel and perform work that is at hand or read the process runqueue to perform work in user-land. Sure you do run into instances where two (or possibly even more) CPUs need to perform an operation within a given critical section, but at this point the granularity of the locking allows for atomic operations per CPU to be performed before the critical section's mutex is released. This effectively prevents race conditions that would be encountered, if no locking was present. It also allows as many CPUs as your system can hold to perform the various tasks (Fetch, store, etc) at near full-speed (The finer the locking, the less waiting around for mutexes/locks there is).
It is important to note that all of the tests that were performed where done on a uni-processor workstation.
The blanket statement that "NetBSD 2.0 has better threading and process management and network latency than FreeBSD 5.3" does not hold water when the test suite is run on 2 and 4-way SMP systems. FreeBSD 5.x is an amazing engineering effort in which various parts of the kernel have been locked down and decent thread concurancy can occur on multi-proc machines. Part of the latency that you see in these benchmarks are due to the mtx_lock() and mtx_unlock() overhead that is incurred.
It is also important to note that P4-systems with HyperThreading (As the one used in these tests) have been the "bastard child" on FreeBSD. For the longest of times, compiling anything with CPUTYPE=p4 would produce broken code (In all fairness, this was mostly due to a set of bugs in GCC 3.x). Significant work was put into 5.3 to ensure that the Pentium 4 lived up to the Tier-1 platform robustness standard. In short, it would be fun to see these benchmarks be run on i386/pentium3, i386/Athlon-MP, amd64/opteron and Alpha as well!
The war is over Bubba; LZW is history!
Sorry, but leaving your cell phone on during your lunchbreak is just begging to be bugged. This is definately the type of thing that would not get you hired at Google. ;)
We are the government. We know EVERYTHING.
A properly designed Java app will almost always be slower than its properly-designed C counterpart. The time-to-market might be in the Java app's favor but when it comes to run-time performance, native API (Which are usually written in C) applications take the cake.
Egg, meet Face. Face, Egg. :)
Could it be that the various manufacturers have a large stock of the smaller drives that they're trying to get rid of before putting larger ones to market?
Maybe it is due to the fact that SCSI storage has typically doubled in size... 9.1, 18.2, 36.4, 72.8, 145.6... Could it be that they're currently testing 291.2GB disks?
My $0.02.