I knew I was forgetting something... The cable itself is composed of 4 pair of twisted wires. Make sure to maintain your twists as far as possible -- including into the RJ45 jack.
Maintaining the twists does make the process a bit harder (especially considering stranded isn't cooperative in the first place) and it's not uncommon for IT guys to take 10 minutes to make a proper cable. Although once you've done a few the process takes considerably less time.
If you're the type that needs to make a patch cable every month or so, you may find that the 10-15 minutes it takes you to properly make a cable isn't worth the $3-5 it would take to order one from the Internet!
There are two types of cable, stranded and solid core. Solid core is generally used for the horizontal cabling (from the patch panel to the jack at the user area), where stranded is used for the patch cables.
Solid core has slightly better propagation properties (the 100M limit implies solid core for example) however it also acts similar to a wire coat-hanger. Like any metal it weakens as it bends and after a period of time it'll grow weak, thin and even completely break.
Stranded is similar to a braided rope, it can withstand constant reconnections (user area, especially common with laptops), movements (telcom closets when you're moving the cable mess to access equipment ports) and the stress that will wear down the solid-core cables.
Do yourself a favor and make sure that if you create your own patch cables:
Cable correctly. Know your color code, it makes future changes (such as to length) MUCH easier and the standards are in place for a reason. Ethernet uses pins 1, 2, 3, and 6 -- which match up exactly with the standard pinouts. Making your own pinout from left to right for example will not allow for cross-talk cancellation and will cause performance problems. Generally you want to match whatever standard your patch panel is, probably 568-B.
Use stranded cable. It's more difficult to work with (it doesn't stay in place like solid core, making it more difficult to put the ends on) but you definitely want to do this.
Use RJ45 connectors intended for stranded cable.
There's nothing wrong with making your own patch cables, and it could potentially save you big bucks (compared with buying a $35 patch cable at a local store). However if it's not done right you will kick yourself down the road -- or more likely blame the network electronics, server, network cards, or whatever you normally blame.:)
For those of us who are not so familiar with the data loss issues surrounding EXT4, can someone please explain this? The first question that came to mind when I read that is "why would the average application need to concern itself with filesystem details?" I.e. if I ask OpenOffice to save a file, it should do that the exact same way whether I ask it to save that file to an ext2 partition, an ext3 partition, a reiserfs partition, etc. What would make ext4 an exception? Isn't abstraction of lower-level filesystem details a good thing?
If you're old enough to remember back to how RAM above 640k was used in the DOS days, it was usually a RAM disk or disk cache (SmartDrv.exe). If you enabled write caching on SmartDrv.exe performance went way up, but of course you could lose data if you hit the RESET button before it had flushed.
... skip ahead a few years...
Modern operating systems automatically cache data because it increases performance. Specifics of the size of the write cache and length of time before it's written to disk may vary, and each filesystem will have its own defaults.
EXT3 defaulted to committing data to disk after a maximum of 5 seconds. EXT4 increases that time to 150 seconds. (The exact numbers vary a bit, but you get the idea). Bottom line: When there is a system crash with EXT4 you notice losing data more often because there is a larger window of when data can get lost.
This is a very basic overview, but there are two groups weighing in on this:
Group 1: Things break under EXT4 that worked under EXT3!
Group 2: Look pal, it works fine. If you want your data committed right away so that you don't lose data maybe you should be calling fsync() so that the OS knows to commit your data? Because you know what, even with EXT3 you have data loss. It becomes more noticable with EXT4 because of the longer cache times, but the problem always existed!
Group 1: It worked before! And if commit our data immediately peformance drops!
Group 2: It didn't really work before, in laptop mode the EXT3 write time increases to 30 seconds. The problem has always existed! If you don't like taking the performance hit of committing data immediately, perhaps you shouldn't be writing so many tiny files so often!
Group 1: But it worked before! EXT4 is broken!
Group 2: Okay, look. You're obviously not listening. Why don't we make EXT4 behave more like EXT3 and do some auto-commits. Poorly coded applications will not lose data as often, and properly coded applications will not perform as well as they could.
Group 1: I'm taking this to Slashdot. EXT4 is teh suxx0rz!
In all fairness regarding Exchange, things break on every release. My comments regarding backward compatibility were specifically regarding Windows the OS, not the Microsoft server applications. While there are some good ones (SQL) there are some terrible ones (Exchange, SMS) too.
Regarding performance, both APIs are functional. DirectX is more an interface to hardware where OpenGL is a generic interface that may or may not be hardware accelerated. Performance is driven largely from the drivers. In my experience games that support both DirectX and OpenGL perform better in DirectX. Does that mean it's better? No, maybe Nvidia does a better job with DirectX than OpenGL. Regardless, you can't say one is always clearly better than the other.
Your UAC rant is still misplaced. I don't know anyone who likes the implementation. But what does it have to do with performance, stability or backwards compatibility with other software? It was a bad implementation of a good idea. Well, assuming you don't want to fix security (and break compatibility) with the Win32 API it's about the best you can do. An example of how MS tried to band-aid a poor design problem maybe. An example of broken backward compatibility it is not.
Okay, I'll bite on automatic updates. It's not the best. Nor did I claim it was. apt-get is better and my personal favorite. Solaris is on-par with Windows in that it will detect a "major" update and won't detect patches for that major update until the next time the update is run (possibly after a reboot). I've seen the same thing with OS X (such as after an iTunes upgrade).
Why does Safari or iTunes reboot the computer? I have no idea. Why can't all update software look ahead and see if there are patches to what it has planned to install/upgrade? I don't know. What I do know is that Windows Update is not alone. Patching NetWare servers has to be many times worse than Windows.
I'm not sure how you miss the point of Windows (the OS) not being compatible with anyone else. They want it that way. POSIX wasn't implemented for a reason. You can't switch out Windows and replace it with something else without a huge investment (time and/or money). I am crystal clear on the issue of why it's not compatible with other operating systems. I don't suspect that it will ever change. Why would they want to compete against UNIX on equal ground when they have their own API that UNIX can't implement (or when doing so breaks apps because the API doesn't function as is publicly documented)? The only reason to be compatible with another OS is if you want to move applications between them. Microsoft doesn't want to. So what is the point of an OS that isn't compatible with anyone else? Money. And lots of it. And if you have to deal with the public sector where.DOCs are the "standard" or have to access corporate web applications that only run in IE you see the point very clearly.
As far as rarely compatible with their own legacy software? Well Vista broke some things in an attempt to lock things down better. A lot of the problems are due to bad coding -- code which if ran in *NIX would also not work due to some dubious assumptions on the part of the developer. The difference is in that *NIX software developer know (and often prefer) that their software will not run as root. Much of the MS software out there requires that it be run as an administrator. When you start locking things down (non-root users in Linux, roles in Solaris, SELinux, CSA and Vista/UAC) bad software breaks.
I'm not a fan of Windows for many reasons. One of those reasons is backwards compatibility. It's really, really hard to "fix" security problems with a bad API when you carry forward that bad API into every future release. Sure, some of the really bad API is removed (and applications break) but most of it has carried forward. At the expense of security, it has definitely allowed for backward compatibility.
Let me start with saying that I'm no fan of MS. I'm Open Source friendly -- I have several projects on SourceForge, and have contributed effort to several additional projects. But what you've stated is FUD.
WMI is supported on the newest Windows Servers, including Windows 2008.
DirectX is stable (although the same can not be said for all video drivers) and is a fantastic API for games, with excellent documentation and examples available. Quite the opposite for OpenGL.
UAC being the worst Vista feature is not only subjective, it offers no support for your argument.
Automatic Updates may not be perfect, but it's not uncommon for an OS to require multiple updates (and reboots) to complete the patch cycle -- like Solaris 10 without LiveUpdate.
So having addressed the FUD, look at your main point. "Windows OS's become less compatible with other OS's and do not reap the benefit..." Windows has never tried to be compatible with other OS. When it comes to Windows compatability I would go so far as to say they've done a damn good job (possibly *too* good) considering the mess with which they're keeping backward compatibility and the crud that keeps getting carried forward.
Microsoft may have many faults, but you seem to have missed the mark.
Slashdot Mirror
I knew I was forgetting something... The cable itself is composed of 4 pair of twisted wires. Make sure to maintain your twists as far as possible -- including into the RJ45 jack.
Maintaining the twists does make the process a bit harder (especially considering stranded isn't cooperative in the first place) and it's not uncommon for IT guys to take 10 minutes to make a proper cable. Although once you've done a few the process takes considerably less time.
If you're the type that needs to make a patch cable every month or so, you may find that the 10-15 minutes it takes you to properly make a cable isn't worth the $3-5 it would take to order one from the Internet!
Solid core has slightly better propagation properties (the 100M limit implies solid core for example) however it also acts similar to a wire coat-hanger. Like any metal it weakens as it bends and after a period of time it'll grow weak, thin and even completely break.
Stranded is similar to a braided rope, it can withstand constant reconnections (user area, especially common with laptops), movements (telcom closets when you're moving the cable mess to access equipment ports) and the stress that will wear down the solid-core cables.
Do yourself a favor and make sure that if you create your own patch cables:
There's nothing wrong with making your own patch cables, and it could potentially save you big bucks (compared with buying a $35 patch cable at a local store). However if it's not done right you will kick yourself down the road -- or more likely blame the network electronics, server, network cards, or whatever you normally blame. :)
For those of us who are not so familiar with the data loss issues surrounding EXT4, can someone please explain this? The first question that came to mind when I read that is "why would the average application need to concern itself with filesystem details?" I.e. if I ask OpenOffice to save a file, it should do that the exact same way whether I ask it to save that file to an ext2 partition, an ext3 partition, a reiserfs partition, etc. What would make ext4 an exception? Isn't abstraction of lower-level filesystem details a good thing?
If you're old enough to remember back to how RAM above 640k was used in the DOS days, it was usually a RAM disk or disk cache (SmartDrv.exe). If you enabled write caching on SmartDrv.exe performance went way up, but of course you could lose data if you hit the RESET button before it had flushed.
... skip ahead a few years ...
Modern operating systems automatically cache data because it increases performance. Specifics of the size of the write cache and length of time before it's written to disk may vary, and each filesystem will have its own defaults.
EXT3 defaulted to committing data to disk after a maximum of 5 seconds. EXT4 increases that time to 150 seconds. (The exact numbers vary a bit, but you get the idea). Bottom line: When there is a system crash with EXT4 you notice losing data more often because there is a larger window of when data can get lost.
This is a very basic overview, but there are two groups weighing in on this:
Group 1: Things break under EXT4 that worked under EXT3!
Group 2: Look pal, it works fine. If you want your data committed right away so that you don't lose data maybe you should be calling fsync() so that the OS knows to commit your data? Because you know what, even with EXT3 you have data loss. It becomes more noticable with EXT4 because of the longer cache times, but the problem always existed!
Group 1: It worked before! And if commit our data immediately peformance drops!
Group 2: It didn't really work before, in laptop mode the EXT3 write time increases to 30 seconds. The problem has always existed! If you don't like taking the performance hit of committing data immediately, perhaps you shouldn't be writing so many tiny files so often!
Group 1: But it worked before! EXT4 is broken!
Group 2: Okay, look. You're obviously not listening. Why don't we make EXT4 behave more like EXT3 and do some auto-commits. Poorly coded applications will not lose data as often, and properly coded applications will not perform as well as they could.
Group 1: I'm taking this to Slashdot. EXT4 is teh suxx0rz!
Group 2: *sigh*
In all fairness regarding Exchange, things break on every release. My comments regarding backward compatibility were specifically regarding Windows the OS, not the Microsoft server applications. While there are some good ones (SQL) there are some terrible ones (Exchange, SMS) too.
.DOCs are the "standard" or have to access corporate web applications that only run in IE you see the point very clearly.
Regarding performance, both APIs are functional. DirectX is more an interface to hardware where OpenGL is a generic interface that may or may not be hardware accelerated. Performance is driven largely from the drivers. In my experience games that support both DirectX and OpenGL perform better in DirectX. Does that mean it's better? No, maybe Nvidia does a better job with DirectX than OpenGL. Regardless, you can't say one is always clearly better than the other.
Your UAC rant is still misplaced. I don't know anyone who likes the implementation. But what does it have to do with performance, stability or backwards compatibility with other software? It was a bad implementation of a good idea. Well, assuming you don't want to fix security (and break compatibility) with the Win32 API it's about the best you can do. An example of how MS tried to band-aid a poor design problem maybe. An example of broken backward compatibility it is not.
Okay, I'll bite on automatic updates. It's not the best. Nor did I claim it was. apt-get is better and my personal favorite. Solaris is on-par with Windows in that it will detect a "major" update and won't detect patches for that major update until the next time the update is run (possibly after a reboot). I've seen the same thing with OS X (such as after an iTunes upgrade). Why does Safari or iTunes reboot the computer? I have no idea. Why can't all update software look ahead and see if there are patches to what it has planned to install/upgrade? I don't know. What I do know is that Windows Update is not alone. Patching NetWare servers has to be many times worse than Windows.
I'm not sure how you miss the point of Windows (the OS) not being compatible with anyone else. They want it that way. POSIX wasn't implemented for a reason. You can't switch out Windows and replace it with something else without a huge investment (time and/or money). I am crystal clear on the issue of why it's not compatible with other operating systems. I don't suspect that it will ever change. Why would they want to compete against UNIX on equal ground when they have their own API that UNIX can't implement (or when doing so breaks apps because the API doesn't function as is publicly documented)? The only reason to be compatible with another OS is if you want to move applications between them. Microsoft doesn't want to. So what is the point of an OS that isn't compatible with anyone else? Money. And lots of it. And if you have to deal with the public sector where
As far as rarely compatible with their own legacy software? Well Vista broke some things in an attempt to lock things down better. A lot of the problems are due to bad coding -- code which if ran in *NIX would also not work due to some dubious assumptions on the part of the developer. The difference is in that *NIX software developer know (and often prefer) that their software will not run as root. Much of the MS software out there requires that it be run as an administrator. When you start locking things down (non-root users in Linux, roles in Solaris, SELinux, CSA and Vista/UAC) bad software breaks.
I'm not a fan of Windows for many reasons. One of those reasons is backwards compatibility. It's really, really hard to "fix" security problems with a bad API when you carry forward that bad API into every future release. Sure, some of the really bad API is removed (and applications break) but most of it has carried forward. At the expense of security, it has definitely allowed for backward compatibility.
So having addressed the FUD, look at your main point. "Windows OS's become less compatible with other OS's and do not reap the benefit..." Windows has never tried to be compatible with other OS. When it comes to Windows compatability I would go so far as to say they've done a damn good job (possibly *too* good) considering the mess with which they're keeping backward compatibility and the crud that keeps getting carried forward.
Microsoft may have many faults, but you seem to have missed the mark.