The problem with home-brew is, we are all inventing the same wheels, over and over again. And what for ?
Because we were told to "make it work". We weren't given a budget so we couldn't go out and buy something off the shelf. And we didn't see an open source tool that could combine all of those functions into a single easy-to-use interface. Regardless of what existing tool we started with, we would have to hack on several other systems just to make it work. Rather than reverse engineering 4-5 different software tools and hacking them all together into one interface, then figuring out how to connect it to our billing and customer support systems (also built in-house by other teams), it made sense to just code it up from scratch. This way we could customize it to support the requirements of support, sales, and management staff, as well as support however many facilities, locations, and staff members (with varying levels of access) as necessary.
I built the web interface that we are using at work to track server information. Due to the fact that it was built completely from scratch (using Perl, that language that so many people claim is dying a slow painful death), we were able to customize it to integrate into a number of other systems such as equipment locations, IP address management, Nagios service monitoring (currently monitoring over 13000 services), server bandwidth usage tracking, internal issue tracking, etc. We are using it to track nearly 10000 servers across 6 facilities in 4 different cities.
The upgrade process - I couldn't upgrade using the command line and had to use the GUI, which was very annoying...
Encryption - When booting my system, the system apparently complains that one of the partitions is unable to be mounted. This is before it tries to launch the crypto stuff. When I enter the crypto key, sometimes it works and sometimes it doesn't. If it doesn't work, I have to drop to the shell, run "cryptdisks stop", then run "cryptdisks start" before it lets me go forward. It still complains about the swap partition (not encrypted, so it is tied to another issue), even though it successfully starts swap. All this, of course, is after I had to force the system to wait long enough to let me type in the crypto key (I had to add "tries=99" to/etc/crypttab) I ran into the following issues:
The upgrade process - I couldn't upgrade using the command line and had to use the GUI, which was very annoying...
Encrypted partitions - When booting my system, the system now complains that one of the partitions listed in fstab is unable to be mounted. This is before it tries to launch the crypto stuff. (In Jaunty it just asked be for the crypto key without complaining about anything.) When I enter the crypto key, sometimes it works and sometimes it doesn't. If it doesn't work, I have to drop to the shell, run "cryptdisks stop", then run "cryptdisks start" before it lets me go forward. It still complains about the swap partition (not encrypted, so it is tied to another issue), even though it successfully starts swap. All this, of course, is after I had to force the system to wait long enough to let me type in the crypto key. (I had to add "tries=99" to/etc/crypttab before the system wouldn't try to boot without my/home partition...)
VPN - On Jaunty I was using nm-applet because knetworkmanager didn't support PPTP properly. Jaunty somewhat supported VPNC, but only when launching it from the command line. I tried using knetworkmanager on Karmic (hoping they have worked around the issues), but I am still having problems. It now allows me to configure the VPN connection (I couldn't do that at all in Jaunty), but I can't start the VPNC VPN properly. Well, actually, I can start it, and can connect to the VPN, but knetworkmanager doesn't recognize that it has started (knetworkmanager doesn't change the status and won't allow me to stop the VPN). The only way to stop the VPN is to manually kill the VPN processes from the command line.
Laptop lid close - When closing the laptop lid in Jaunty, my screen would shut off and the screen saver would start. Now, when closing the lid, the screen does not shut off.
Laptop suspend/resume - When closing the lid in Jaunty, the system would automatically suspend to RAM and power down, and the screen would be locked upon resuming. Now, closing the lid gives mixed results. The system does not always suspend to RAM. Before I started playing with the power settings, if I closed the lid after starting the screensaver, it would not suspend. If I closed it without starting the screensaver, it would *sometimes* suspend properly, but if it actually suspends to RAM it would take forever to come back.
Honestly, if these issues don't clear up soon (i.e., by next weekend before I go back to work), I will have no choice but to wipe my system and revert back to Jaunty. VPN - On Jaunty I was using nm-applet because knetworkmanager didn't support PPTP properly. Jaunty somewhat supported VPNC, but only when launching it from the command line. I tried using knetworkmanager on Karmic (hoping they have worked around the issues), but I am still having problems. It now allows me to configure the VPN connection (I couldn't do that at all in Jaunty), but I can't start the VPN properly. Well, actually, I can start it, and can connect to the VPN, but knetworkmanager doesn't recognize that it has started (knetworkmanager doesn't change the status and won't allow me to stop the VP
You have to disable the drive's spindown settings. If you don't already have it on your system, you must install "sdparm". I have a Freeagent Go and had this problem until I ran it:
The Nagios config files are atrocious. Trying to navigate through them is sometimes like an exercise in insanity.
That being said, if you are in a large organization (e.g., a large web hosting company with multiple datacenters) that needs to monitor thousands of services on thousands of hosts, it can be done. However, you can't go mucking around in the config files all willy-nilly. You have to build a framework around them. At the hosting company I work for, we have deployed Nagios collector nodes in multiple facilities that all report back to a parent node that allows us to immediately see what is down, what platform it is a part of, and what city it is in at a glance. (It also has a link back into a database that provides more details about that particular server.) I don't work a whole lot with designing the actual configuration files (most of the configs are insane), however I do manage the web-base back-end database that we use to manage all of the services and hosts. (They tell me "the config file needs to look like this, make it happen.") You can't deploy Nagios on a large scale without an administrative back end orchestrating nearly *everything* (including services that are available for monitoring, which hosts to monitor, escalation paths and contacts, templating, etc.), especially if multiple people in multiple locations have to manage various parts of it. (The fact that Nagios does not have a built-in database-driven config system was an annoyance that we had to work around.) To do so would be an exercise in futility, especially with multiple offices with different services to monitor and different escalation requirements and different host and service templates and different levels of access to manage. Somehow we (a very small team with tons of other stuff to do as well) have managed to get it right and are currently deployed in 4 (soon to be 5) different facilities.
I still get amazed when people yell at me for being offline for a few hours after maybe 3, 4, 5 years of uptime. They say that they are losing thousands of dollars per day they are offline. Yet, they don't want to pay for a $40 roll-over backup. THESE are the vast majority of customers who complain so much about 99.999% uptime.
Thousands of dollars per day? That's all? I work for a web hosting company. When one of our customers' servers goes down for more than 10 minutes, they immediately claim to be losing tens of thousands of dollars per hour.:) Of course, they *might* be paying only $100 per month for the server. And these are the same customers that can't be bothered to pay $50/month for any kind of backups for their only copy of their data.
What would the point of getting an even faster link?
Because the difference in price is almost trivial? Even at a retail brick and mortar store (e.g., Best Buy, Circuit City, etc.) a gigabit card (albeit low end) can be found for about $30. (Many new motherboards are coming with gigabit standard.) A 5 port gigabit switch maybe $60. (You don't even have to put everything on gigabit, maybe just your fileserver and main workstations.) With a little investment you can exceed 100mbit and remain somewhat future-proof for a while.
Gigabit ethernet connections have been the standard for years. Long gone are the days when an ISP/web hosting company standardized on DS3 or OC3/12/48 connections for their uplinks. All the major network providers are now supplying optical gigabit and 10 gigabit links to their customers. Even long haul links are sold in gigabit increments. *Everything* does gigabit ethernet. When you look at the network setups of the largest hosting companies, you see multiple gigabit (and 10 gigabit) connections everywhere, both on internal connections and external uplinks. When you look at the top-end networking gear from manufacturers (Cisco, Juniper, Foundry, etc.), you see line cards with multiple 10 gigabit ports spread throughout the chassis.
I'm sure the 1970's thought CRTs would continue to rule the display world, but along came LCDs, DLP, LEDs, and OLED. To predict that a current budding technology that has yet failed to get off the ground will be the new standard is hopeful at best, and more likely, entirely incorrect.
Even some of these "recent" developments are now becoming obsolete. The CRT was king for how many decades? Then Plasma came along and was subsequently de-throned by LCDs within less than 10 years. LCDs will probably be dethroned within 10 more years for newer tech such as OLED or SED screens. There is absolutely no way to guess what the tech will be 25 years from now.
Yeah, but it is not HDTV, which is the point of this discussion. Most people already have a SDTV. People with a limited income can understand spending $80 for a small TV, but they can't justify spending $300+ for a 19" LCD HDTV. Even I can't understand spending that much on such a small TV. For another few hundred you can get almost twice the diagonal size and almost 4 times the screen real estate.
But I've seen them on DVD players that only have composite and component out. (There still shouldn't be a warning anyway since just about every new TV supports at least one composite input.) They had no RF modulator in them. Actually, I don't think that I've *ever* seen a DVD player with a coax output...
It's not like people need 14 months to save up for a digital TV. A 'good enough' off-brand 32" TV runs $700 now, and it'll probably be more like $500 later.
Not everyone has access to enough disposable income to buy an HDTV. For many people, $200 is too much to spend on a TV. Even on sale a 19" HDTV starts off around $250, and is usually closer to $300. Maybe by the time the changeover comes around they will be down to under $200, but that would still be pushing it for some lower income people.
Most stores that sell electronics are still selling analog TVs. Most of them have the little cards in front of the TVs warning people about the switchover. Unfortunately, there are still some stores without the warning cards, and even the stores that have the cards only put out a very small sign with very small print. The warnings are easily overlooked by someone not looking for them (but then again, if you are looking for the cards then you already know about the changeover).
Oddly enough, I've even seen those warning cards on regular DVD players that don't even have a tuner in them...
I have a pair of 120GB drives and a 200GB drive just sitting around because they are *too small* to use anywhere else (all of the other drives I use in my other computers are at least 320GB). I remember being excited to even be able to hold that much data in my hand...
How many PC clones were sold before windows 3.1 hit? How about the Apple II series? Millions. Did the people who bought these get amnesia in 1995? No, they didn't, but we really aren't dealing with the same userbase. The number of computer users back then is significantly smaller and more computer savvy than the computer users of today.
Just because people don't know something doesn't mean they can't learn btw. Learning is good. Well, if you don't want more people using linux, then force them to learn the command line. Seriously, the average computer user doesn't even have a clue (nor do they care) what the "black box with white letters" (i.e., a MSDOS prompt window) is, what it is for, or why they need it.
The vast majority of linux systems don't have X installed btw. They don't even have monitors or keyboards. We are not talking about servers. That is a completely different (and significantly more knowledgeable) userbase. We are talking about desktop computers that "normal" people (i.e., people that don't eat, sleep, and dream about computers) will be using on a daily basis.
Most of the most advanced software for the platform does not require X at all. Regardless of how advanced a piece of software is, if it doesn't run in a window or have an icon they can click on, then it does not exist to "normal" people.
It is attitudes like this that hold back the wide-spread adoption of Linux on the desktop.
I never said that I did not want to mess with detailed setup. The best way to learn about what really happens on a linux box is to do it the hard way. What I meant was that I hate having to scour the entire internet just to find out all of the configuration options that are available to perform a particular task. (Just knowing that the configuration directives existed would have been a great start.) I shouldn't have to search random posts on nvnews.net to figure out how to get my dual LCD's working. There should be an easy to find (and easy to read) manual somewhere, since I am obviously not the first person to run dual LCD's over DVI on an NVidia card in Slackware (or any other distro).
All I am saying is that for an experienced linux user this is easy. I'm used to using google to find solutions to fix obscure error messages. For someone who just wants to add a second monitor to their linux box without tinkering with xorg.conf, this approaches impossible.
If you know *exactly* which file to edit and *exactly* which directive to fix, then yes, it is very easy. However your average user will not have had months/years of experience maintaining a linux box, and will have no clue what to do when they see a command prompt. Nor will they know what to search for in Google when they get some weird error message or failure warning. Your average user will not know that they may already most of the necessary documentation in README files on their computer.
You have to look at it this way... The average user does not like to read through pages and pages and pages of online forums and FAQs and Wikis. (They probably wouldn't even know which forums to use.) Hell, I don't like doing it, and I am what would be considered a "power user". (I've been using Slackware as my full-time desktop for nearly 5 years, and part-time for several years before that.) At least I have a clue what to look for when fixing and upgrading my linux box. But for new stuff, it can get very annoying. I upgraded to dual LCD displays last year (not too long after I upgraded to a new video card), and had to spend a few days searching for terms like "maximum pixel clock", "TwinView", "nvidia-auto-select", etc. (before setting up dual monitors, I hadn't even heard of those last two xorg directives, much less knew how to use them) before I could get my LCD's to work properly with the correct resolutions and refresh rates over the DVI connections. I don't think that the average user would be able to do something as simple as add a second monitor without giving up immediately.
Even with the tools that come with various distros, it is still an order of magnitude easier to do in Windows, and usually won't require you to reboot and hope that you didn't break your xorg.conf with some obscure typo or misdetected refresh rate (I had that a lot too).
nVidia has dropped support for cards older than the GForce4. I have a GForce2 with 64MB and TV tuner that would benefit from this driver.
My workstation at work (running a GeForce2 MX) is using the 9631 drivers. Granted, I am still running 2.6.18.5, and I don't remember if that driver works with the new kernels (haven't tried a 2.6.19.1 kernel since I upgraded the video card from a TNT2). But, I am not in dire need of any new features from 2.6.19.x as of yet.
Using more advanced forms of communications requires advanced technology with bandwidth requirements. While it may be possible with satellite phones or a PDA with a satellite uplink, it could cause unnecessary RF noise that could be picked up by other monitoring devices (e.g., like your cell phone constantly sending out signals to connect to the tower). If you are in covert ops, then it is possible to find yourself in a situation where you are surrounded by systems that listen out for unauthorized RF noise. And of course, the last thing you want to do is use some Internet cafe (even if you have your own laptop) to download and print instructions from home base, especially since they now have the ability to be intercepted (and decoded) on the fly. Email isn't always as secure and reliable as you would like. The last thing you need is a critical mission to be delayed or scrubbed because of a cable cut hundreds (or thousands) of miles away. The only way to make it secure would be to set up some form of encryption between your computer and the home base, which isn't going to be possible (or desired) because 1) you would have to trust the computer you are using isn't already compromised, 2) you have to be able to download and install whatever software is necessary to set up the link, and 3) you let the owners of the local computer network know where "home base" is.
Console over serial is for when *everything* is broken. Nobody is saying that you have to walk through a datacenter with a serial cable to connect to boxes. You use a normal KVM or keyboard and monitor for that. Serial cables are used when you 1) need to manage a piece of equipment remotely without having to be onsite, and 2) can't access the equipment through normal means (i.e., TCP/IP).
Also, console over serial is not for Windows-based servers, or any server configured to use a graphical interface. Not every server in existence supports VNC, Remote Desktop, PCAnywhere, etc. Unix servers are managed through a command line, and a console connection is often used for both security and convenience (when networking is down for whatever reason).
I have- but what part of choose your hardware carefully do you people not understand? RS232 is a rather outdated protocol at this point. My two latest computer purchases do not speak RS232 natively- but they DO have multiple USB ports.
A lot of network hardware manufacturers choose to support RS-232 natively because of the relative simplicity of the protocol when compared to TCP/IP. Often an alternative non-serial product does not exist, so "choose your hardware carefully" is not always an option. Because of this fact, most servers come with at least one serial port. (Some setups exclusively use console over serial for managing servers.) There is no possibility of network issues, routing problems, congestion, management networks, etc. Usually the most configuration that you have to do is 9600-8N1. Serial ports work even before networking is configured. Most networking hardware *requires* initial (and sometimes normal maintenance) through a serial port (you often have no choice). And when your switch/router is having routing issues, the last thing you need to worry about is whether or not your equipment will even accept your TCP/IP packets...
1) User -- For the average user, due to great advances in user-friendliness, learning how to use Linux is just about as difficult as learning how to use Windows. The names of the programs are different, however they all do similar things.
2) Admin -- This is harder in Linux. In windows, there are only a few differences between configuration locations between Win2K, XP, Win2K3, etc., and of course the registry is a common feature among all versions of Windows. In Linux, differing software package formats (rpm, deb, tgz, emerge, ports, etc.), differing configuration file locations and formats, differing startup scripts, differing authentication systems, and various other minor differences make managing one distro almost a completely different experience than managing another distro. Some distros have decided to use similar tools, however there is still enough variety to make things way more interesting than necessary.
3) Developer -- It is fairly difficult to release binary packages of your software when you don't know whether or not a particular library will be present on the target system. A package compiled for RedHat Enterprise may or may not work on a Fedora system, and will almost be guaranteed to not work on a Debian/Ubuntu system without a lot of library mangling. You can't just say "let the end-user compile the software on their system", because certain large-scale software products (i.e., ones that are very expensive and include commercial support) are not released with source code (for obvious reasons). Also, even if they did support multiple distros, they would have to deal with annoying miscellaneous issues such as whether a particular library file is present in/lib,/usr/lib, or/usr/local/lib, whether a particular distro changes library version numbers and doesn't contain a recent enough library, whether or not the distro has an autoupdate tool that can be used to update a single library without breaking anything else, etc. So, large-scale software manufacturers choose to restrict what distros they provide support for, due to the fact that they do not want to be responsible for supporting some random distro that they have not heard of or done any testing on.
I don't find cell phones to be reliable (just completed a cross-country drive, want to guess what the percentage of calls were that were either dropped, unable to connect, or interrupted/garbled?).
Forget about driving across country. What about standing still in the middle of a major metro area?
The building I work in has a cell antenna on top of it (to be fair, it isn't from my provider). The building two blocks over (right outside our window) has a cell antenna on it. The building one block over and one block up (also visible from our window) has a cell antenna on it. There are probably just as many cell antennas visible from the other side(s) of our building. Why is it that my cell phone often randomly jumps from one bar to four, and usually has problems with dropouts as well as dropped calls?
The easiest way is to block all incoming connections from anything that resolves to a.edu domain.
This makes no sense. Very few children will be accessing the Internet from a.edu address. Children in grade school will be accessing the net usually from something like a schoolname.k12.state.us IP. Children at home will be coming in from one of a thousand different ISP's. The only people coming in from.edu addresses will be college students (who are supposed to be old enough to handle porn).
Besides, this all depends on porn sites keeping up to date records of what IP is tied to a.edu address (because making your web server do reverse lookups for each browser connection is an insane waste of resources). Most of those IP databases are not free, and often don't include the ISP or anything else that may identify the possible age of the viewer.
Slashdot Mirror
The problem with home-brew is, we are all inventing the same wheels, over and over again. And what for ?
Because we were told to "make it work". We weren't given a budget so we couldn't go out and buy something off the shelf. And we didn't see an open source tool that could combine all of those functions into a single easy-to-use interface. Regardless of what existing tool we started with, we would have to hack on several other systems just to make it work. Rather than reverse engineering 4-5 different software tools and hacking them all together into one interface, then figuring out how to connect it to our billing and customer support systems (also built in-house by other teams), it made sense to just code it up from scratch. This way we could customize it to support the requirements of support, sales, and management staff, as well as support however many facilities, locations, and staff members (with varying levels of access) as necessary.
Another vote for the home-brew option.
I built the web interface that we are using at work to track server information. Due to the fact that it was built completely from scratch (using Perl, that language that so many people claim is dying a slow painful death), we were able to customize it to integrate into a number of other systems such as equipment locations, IP address management, Nagios service monitoring (currently monitoring over 13000 services), server bandwidth usage tracking, internal issue tracking, etc. We are using it to track nearly 10000 servers across 6 facilities in 4 different cities.
I ran into the following issues:
The upgrade process - I couldn't upgrade using the command line and had to use the GUI, which was very annoying...
Encryption - When booting my system, the system apparently complains that one of the partitions is unable to be mounted. This is before it tries to launch the crypto stuff. When I enter the crypto key, sometimes it works and sometimes it doesn't. If it doesn't work, I have to drop to the shell, run "cryptdisks stop", then run "cryptdisks start" before it lets me go forward. It still complains about the swap partition (not encrypted, so it is tied to another issue), even though it successfully starts swap. All this, of course, is after I had to force the system to wait long enough to let me type in the crypto key (I had to add "tries=99" to /etc/crypttab)
I ran into the following issues:
The upgrade process - I couldn't upgrade using the command line and had to use the GUI, which was very annoying...
Encrypted partitions - When booting my system, the system now complains that one of the partitions listed in fstab is unable to be mounted. This is before it tries to launch the crypto stuff. (In Jaunty it just asked be for the crypto key without complaining about anything.) When I enter the crypto key, sometimes it works and sometimes it doesn't. If it doesn't work, I have to drop to the shell, run "cryptdisks stop", then run "cryptdisks start" before it lets me go forward. It still complains about the swap partition (not encrypted, so it is tied to another issue), even though it successfully starts swap. All this, of course, is after I had to force the system to wait long enough to let me type in the crypto key. (I had to add "tries=99" to /etc/crypttab before the system wouldn't try to boot without my /home partition...)
VPN - On Jaunty I was using nm-applet because knetworkmanager didn't support PPTP properly. Jaunty somewhat supported VPNC, but only when launching it from the command line. I tried using knetworkmanager on Karmic (hoping they have worked around the issues), but I am still having problems. It now allows me to configure the VPN connection (I couldn't do that at all in Jaunty), but I can't start the VPNC VPN properly. Well, actually, I can start it, and can connect to the VPN, but knetworkmanager doesn't recognize that it has started (knetworkmanager doesn't change the status and won't allow me to stop the VPN). The only way to stop the VPN is to manually kill the VPN processes from the command line.
Laptop lid close - When closing the laptop lid in Jaunty, my screen would shut off and the screen saver would start. Now, when closing the lid, the screen does not shut off.
Laptop suspend/resume - When closing the lid in Jaunty, the system would automatically suspend to RAM and power down, and the screen would be locked upon resuming. Now, closing the lid gives mixed results. The system does not always suspend to RAM. Before I started playing with the power settings, if I closed the lid after starting the screensaver, it would not suspend. If I closed it without starting the screensaver, it would *sometimes* suspend properly, but if it actually suspends to RAM it would take forever to come back.
Honestly, if these issues don't clear up soon (i.e., by next weekend before I go back to work), I will have no choice but to wipe my system and revert back to Jaunty.
VPN - On Jaunty I was using nm-applet because knetworkmanager didn't support PPTP properly. Jaunty somewhat supported VPNC, but only when launching it from the command line. I tried using knetworkmanager on Karmic (hoping they have worked around the issues), but I am still having problems. It now allows me to configure the VPN connection (I couldn't do that at all in Jaunty), but I can't start the VPN properly. Well, actually, I can start it, and can connect to the VPN, but knetworkmanager doesn't recognize that it has started (knetworkmanager doesn't change the status and won't allow me to stop the VP
When ext2 was still common, 10GB was often half of an entire hard drive, so yeah, it was a lot of data.
You have to disable the drive's spindown settings. If you don't already have it on your system, you must install "sdparm". I have a Freeagent Go and had this problem until I ran it:
http://alienghic.livejournal.com/382903.html
sdparm --clear STANDBY -6 /dev/sde
Apparently this command will restart a stopped drive, but I've never tested it because I always leave it running when connected:
sdparm --command=start /dev/sde
The Nagios config files are atrocious. Trying to navigate through them is sometimes like an exercise in insanity.
That being said, if you are in a large organization (e.g., a large web hosting company with multiple datacenters) that needs to monitor thousands of services on thousands of hosts, it can be done. However, you can't go mucking around in the config files all willy-nilly. You have to build a framework around them. At the hosting company I work for, we have deployed Nagios collector nodes in multiple facilities that all report back to a parent node that allows us to immediately see what is down, what platform it is a part of, and what city it is in at a glance. (It also has a link back into a database that provides more details about that particular server.) I don't work a whole lot with designing the actual configuration files (most of the configs are insane), however I do manage the web-base back-end database that we use to manage all of the services and hosts. (They tell me "the config file needs to look like this, make it happen.") You can't deploy Nagios on a large scale without an administrative back end orchestrating nearly *everything* (including services that are available for monitoring, which hosts to monitor, escalation paths and contacts, templating, etc.), especially if multiple people in multiple locations have to manage various parts of it. (The fact that Nagios does not have a built-in database-driven config system was an annoyance that we had to work around.) To do so would be an exercise in futility, especially with multiple offices with different services to monitor and different escalation requirements and different host and service templates and different levels of access to manage. Somehow we (a very small team with tons of other stuff to do as well) have managed to get it right and are currently deployed in 4 (soon to be 5) different facilities.
I still get amazed when people yell at me for being offline for a few hours after maybe 3, 4, 5 years of uptime. They say that they are losing thousands of dollars per day they are offline. Yet, they don't want to pay for a $40 roll-over backup. THESE are the vast majority of customers who complain so much about 99.999% uptime.
:) Of course, they *might* be paying only $100 per month for the server. And these are the same customers that can't be bothered to pay $50/month for any kind of backups for their only copy of their data.
Thousands of dollars per day? That's all? I work for a web hosting company. When one of our customers' servers goes down for more than 10 minutes, they immediately claim to be losing tens of thousands of dollars per hour.
What would the point of getting an even faster link?
Because the difference in price is almost trivial? Even at a retail brick and mortar store (e.g., Best Buy, Circuit City, etc.) a gigabit card (albeit low end) can be found for about $30. (Many new motherboards are coming with gigabit standard.) A 5 port gigabit switch maybe $60. (You don't even have to put everything on gigabit, maybe just your fileserver and main workstations.) With a little investment you can exceed 100mbit and remain somewhat future-proof for a while.
Gigabit ethernet connections have been the standard for years. Long gone are the days when an ISP/web hosting company standardized on DS3 or OC3/12/48 connections for their uplinks. All the major network providers are now supplying optical gigabit and 10 gigabit links to their customers. Even long haul links are sold in gigabit increments. *Everything* does gigabit ethernet. When you look at the network setups of the largest hosting companies, you see multiple gigabit (and 10 gigabit) connections everywhere, both on internal connections and external uplinks. When you look at the top-end networking gear from manufacturers (Cisco, Juniper, Foundry, etc.), you see line cards with multiple 10 gigabit ports spread throughout the chassis.
I'm sure the 1970's thought CRTs would continue to rule the display world, but along came LCDs, DLP, LEDs, and OLED. To predict that a current budding technology that has yet failed to get off the ground will be the new standard is hopeful at best, and more likely, entirely incorrect.
Even some of these "recent" developments are now becoming obsolete. The CRT was king for how many decades? Then Plasma came along and was subsequently de-throned by LCDs within less than 10 years. LCDs will probably be dethroned within 10 more years for newer tech such as OLED or SED screens. There is absolutely no way to guess what the tech will be 25 years from now.
Yeah, but it is not HDTV, which is the point of this discussion. Most people already have a SDTV. People with a limited income can understand spending $80 for a small TV, but they can't justify spending $300+ for a 19" LCD HDTV. Even I can't understand spending that much on such a small TV. For another few hundred you can get almost twice the diagonal size and almost 4 times the screen real estate.
But I've seen them on DVD players that only have composite and component out. (There still shouldn't be a warning anyway since just about every new TV supports at least one composite input.) They had no RF modulator in them. Actually, I don't think that I've *ever* seen a DVD player with a coax output...
It's not like people need 14 months to save up for a digital TV. A 'good enough' off-brand 32" TV runs $700 now, and it'll probably be more like $500 later.
Not everyone has access to enough disposable income to buy an HDTV. For many people, $200 is too much to spend on a TV. Even on sale a 19" HDTV starts off around $250, and is usually closer to $300. Maybe by the time the changeover comes around they will be down to under $200, but that would still be pushing it for some lower income people.
Most stores that sell electronics are still selling analog TVs. Most of them have the little cards in front of the TVs warning people about the switchover. Unfortunately, there are still some stores without the warning cards, and even the stores that have the cards only put out a very small sign with very small print. The warnings are easily overlooked by someone not looking for them (but then again, if you are looking for the cards then you already know about the changeover).
Oddly enough, I've even seen those warning cards on regular DVD players that don't even have a tuner in them...
I have a pair of 120GB drives and a 200GB drive just sitting around because they are *too small* to use anywhere else (all of the other drives I use in my other computers are at least 320GB). I remember being excited to even be able to hold that much data in my hand...
How many PC clones were sold before windows 3.1 hit? How about the Apple II series? Millions. Did the people who bought these get amnesia in 1995?
No, they didn't, but we really aren't dealing with the same userbase. The number of computer users back then is significantly smaller and more computer savvy than the computer users of today.
Just because people don't know something doesn't mean they can't learn btw. Learning is good.
Well, if you don't want more people using linux, then force them to learn the command line. Seriously, the average computer user doesn't even have a clue (nor do they care) what the "black box with white letters" (i.e., a MSDOS prompt window) is, what it is for, or why they need it.
The vast majority of linux systems don't have X installed btw. They don't even have monitors or keyboards.
We are not talking about servers. That is a completely different (and significantly more knowledgeable) userbase. We are talking about desktop computers that "normal" people (i.e., people that don't eat, sleep, and dream about computers) will be using on a daily basis.
Most of the most advanced software for the platform does not require X at all.
Regardless of how advanced a piece of software is, if it doesn't run in a window or have an icon they can click on, then it does not exist to "normal" people.
It is attitudes like this that hold back the wide-spread adoption of Linux on the desktop.
I never said that I did not want to mess with detailed setup. The best way to learn about what really happens on a linux box is to do it the hard way. What I meant was that I hate having to scour the entire internet just to find out all of the configuration options that are available to perform a particular task. (Just knowing that the configuration directives existed would have been a great start.) I shouldn't have to search random posts on nvnews.net to figure out how to get my dual LCD's working. There should be an easy to find (and easy to read) manual somewhere, since I am obviously not the first person to run dual LCD's over DVI on an NVidia card in Slackware (or any other distro).
All I am saying is that for an experienced linux user this is easy. I'm used to using google to find solutions to fix obscure error messages. For someone who just wants to add a second monitor to their linux box without tinkering with xorg.conf, this approaches impossible.
If you know *exactly* which file to edit and *exactly* which directive to fix, then yes, it is very easy. However your average user will not have had months/years of experience maintaining a linux box, and will have no clue what to do when they see a command prompt. Nor will they know what to search for in Google when they get some weird error message or failure warning. Your average user will not know that they may already most of the necessary documentation in README files on their computer.
You have to look at it this way... The average user does not like to read through pages and pages and pages of online forums and FAQs and Wikis. (They probably wouldn't even know which forums to use.) Hell, I don't like doing it, and I am what would be considered a "power user". (I've been using Slackware as my full-time desktop for nearly 5 years, and part-time for several years before that.) At least I have a clue what to look for when fixing and upgrading my linux box. But for new stuff, it can get very annoying. I upgraded to dual LCD displays last year (not too long after I upgraded to a new video card), and had to spend a few days searching for terms like "maximum pixel clock", "TwinView", "nvidia-auto-select", etc. (before setting up dual monitors, I hadn't even heard of those last two xorg directives, much less knew how to use them) before I could get my LCD's to work properly with the correct resolutions and refresh rates over the DVI connections. I don't think that the average user would be able to do something as simple as add a second monitor without giving up immediately.
Even with the tools that come with various distros, it is still an order of magnitude easier to do in Windows, and usually won't require you to reboot and hope that you didn't break your xorg.conf with some obscure typo or misdetected refresh rate (I had that a lot too).
nVidia has dropped support for cards older than the GForce4. I have a GForce2 with 64MB and TV tuner that would benefit from this driver.
My workstation at work (running a GeForce2 MX) is using the 9631 drivers. Granted, I am still running 2.6.18.5, and I don't remember if that driver works with the new kernels (haven't tried a 2.6.19.1 kernel since I upgraded the video card from a TNT2). But, I am not in dire need of any new features from 2.6.19.x as of yet.
Using more advanced forms of communications requires advanced technology with bandwidth requirements. While it may be possible with satellite phones or a PDA with a satellite uplink, it could cause unnecessary RF noise that could be picked up by other monitoring devices (e.g., like your cell phone constantly sending out signals to connect to the tower). If you are in covert ops, then it is possible to find yourself in a situation where you are surrounded by systems that listen out for unauthorized RF noise. And of course, the last thing you want to do is use some Internet cafe (even if you have your own laptop) to download and print instructions from home base, especially since they now have the ability to be intercepted (and decoded) on the fly. Email isn't always as secure and reliable as you would like. The last thing you need is a critical mission to be delayed or scrubbed because of a cable cut hundreds (or thousands) of miles away. The only way to make it secure would be to set up some form of encryption between your computer and the home base, which isn't going to be possible (or desired) because 1) you would have to trust the computer you are using isn't already compromised, 2) you have to be able to download and install whatever software is necessary to set up the link, and 3) you let the owners of the local computer network know where "home base" is.
Console over serial is for when *everything* is broken. Nobody is saying that you have to walk through a datacenter with a serial cable to connect to boxes. You use a normal KVM or keyboard and monitor for that. Serial cables are used when you 1) need to manage a piece of equipment remotely without having to be onsite, and 2) can't access the equipment through normal means (i.e., TCP/IP).
Also, console over serial is not for Windows-based servers, or any server configured to use a graphical interface. Not every server in existence supports VNC, Remote Desktop, PCAnywhere, etc. Unix servers are managed through a command line, and a console connection is often used for both security and convenience (when networking is down for whatever reason).
I have- but what part of choose your hardware carefully do you people not understand? RS232 is a rather outdated protocol at this point. My two latest computer purchases do not speak RS232 natively- but they DO have multiple USB ports.
A lot of network hardware manufacturers choose to support RS-232 natively because of the relative simplicity of the protocol when compared to TCP/IP. Often an alternative non-serial product does not exist, so "choose your hardware carefully" is not always an option. Because of this fact, most servers come with at least one serial port. (Some setups exclusively use console over serial for managing servers.) There is no possibility of network issues, routing problems, congestion, management networks, etc. Usually the most configuration that you have to do is 9600-8N1. Serial ports work even before networking is configured. Most networking hardware *requires* initial (and sometimes normal maintenance) through a serial port (you often have no choice). And when your switch/router is having routing issues, the last thing you need to worry about is whether or not your equipment will even accept your TCP/IP packets...
1) User -- For the average user, due to great advances in user-friendliness, learning how to use Linux is just about as difficult as learning how to use Windows. The names of the programs are different, however they all do similar things.
/lib, /usr/lib, or /usr/local/lib, whether a particular distro changes library version numbers and doesn't contain a recent enough library, whether or not the distro has an autoupdate tool that can be used to update a single library without breaking anything else, etc. So, large-scale software manufacturers choose to restrict what distros they provide support for, due to the fact that they do not want to be responsible for supporting some random distro that they have not heard of or done any testing on.
2) Admin -- This is harder in Linux. In windows, there are only a few differences between configuration locations between Win2K, XP, Win2K3, etc., and of course the registry is a common feature among all versions of Windows. In Linux, differing software package formats (rpm, deb, tgz, emerge, ports, etc.), differing configuration file locations and formats, differing startup scripts, differing authentication systems, and various other minor differences make managing one distro almost a completely different experience than managing another distro. Some distros have decided to use similar tools, however there is still enough variety to make things way more interesting than necessary.
3) Developer -- It is fairly difficult to release binary packages of your software when you don't know whether or not a particular library will be present on the target system. A package compiled for RedHat Enterprise may or may not work on a Fedora system, and will almost be guaranteed to not work on a Debian/Ubuntu system without a lot of library mangling. You can't just say "let the end-user compile the software on their system", because certain large-scale software products (i.e., ones that are very expensive and include commercial support) are not released with source code (for obvious reasons). Also, even if they did support multiple distros, they would have to deal with annoying miscellaneous issues such as whether a particular library file is present in
I don't find cell phones to be reliable (just completed a cross-country drive, want to guess what the percentage of calls were that were either dropped, unable to connect, or interrupted/garbled?).
Forget about driving across country. What about standing still in the middle of a major metro area?
The building I work in has a cell antenna on top of it (to be fair, it isn't from my provider). The building two blocks over (right outside our window) has a cell antenna on it. The building one block over and one block up (also visible from our window) has a cell antenna on it. There are probably just as many cell antennas visible from the other side(s) of our building. Why is it that my cell phone often randomly jumps from one bar to four, and usually has problems with dropouts as well as dropped calls?
The easiest way is to block all incoming connections from anything that resolves to a .edu domain.
.edu address. Children in grade school will be accessing the net usually from something like a schoolname.k12.state.us IP. Children at home will be coming in from one of a thousand different ISP's. The only people coming in from .edu addresses will be college students (who are supposed to be old enough to handle porn).
.edu address (because making your web server do reverse lookups for each browser connection is an insane waste of resources). Most of those IP databases are not free, and often don't include the ISP or anything else that may identify the possible age of the viewer.
This makes no sense. Very few children will be accessing the Internet from a
Besides, this all depends on porn sites keeping up to date records of what IP is tied to a